Documenting Synthetic Data for AI Audits

Documenting Synthetic Data for AI Audits: What to Record and How to Make It Verifiable

If you trained a model on synthetic data, an auditor will want to know where that data came from, how it was generated, what was done to it afterwards, and how you know it’s fit for purpose. A good answer is a set of records covering the generator and its version, the seed data and settings, the generation run, any filtering or relabelling, and the evaluation results. The records should be fixed in time before training starts, so nobody can suspect they were written afterwards to fit the story.

The last part gets skipped more than it should. Plenty of teams keep decent notes. Far fewer can show that those notes existed on the date they claim.

Why auditors look harder at synthetic data

Real data has a paper trail, however messy: a collection process, a legal basis, a source system. Synthetic data has a different problem. It looks clean because someone, or something, made it that way, and the cleanness hides a long chain of decisions.

Which model produced it? What was it prompted with, or trained on? Did the generator memorise records from a real dataset and quietly reproduce them? Did it inherit the skews of whatever it learned from, or sharpen them? An auditor can’t answer any of this from the dataset alone. They need the story around it.

There’s also a quieter risk. Synthetic data is cheap to regenerate, which means it’s easy to regenerate differently. If a team re-runs a pipeline six months later with a newer generator and the same file name, the evidence of what the model was actually trained on can vanish without anyone intending it.

Why auditors look harder at synthetic data

Real data has a paper trail, however messy: a collection process, a legal basis, a source system. Synthetic data has a different problem. It looks clean because someone, or something, made it that way, and the cleanness hides a long chain of decisions.

Which model produced it? What was it prompted with, or trained on? Did the generator memorise records from a real dataset and quietly reproduce them? Did it inherit the skews of whatever it learned from, or sharpen them? An auditor can’t answer any of this from the dataset alone. They need the story around it.

There’s also a quieter risk. Synthetic data is cheap to regenerate, which means it’s easy to regenerate differently. If a team re-runs a pipeline six months later with a newer generator and the same file name, the evidence of what the model was actually trained on can vanish without anyone intending it.

The record that holds up

Think of it as five layers. You don’t need a hundred-page report, but each layer should be answerable.

The generator:

Name it exactly: model or tool, version, and where the weights or software came from. “A large language model” won’t do. If it’s a third-party service, note the version or date range you used, because hosted models change underneath you. If you built the generator, record the code commit and the data it was trained on.

The seed and the source:

Most synthetic data starts from something real: a sample of production records, a schema, a set of prompts, a simulation config. Record what that starting material was, how it was selected, and whether it contained personal data. If real data fed the generator, say so plainly. This is the layer privacy reviewers care about most.

The run itself:

Parameters, random seeds where the process is seed-driven, prompt templates, date and duration of generation, volume produced. The aim is that a competent colleague could rerun the process, or at least understand why a rerun wouldn’t match exactly. Language-model generation often isn’t reproducible bit for bit, and it’s better to say that than to leave an auditor guessing.

What happened afterwards:

Filtering, deduplication, relabelling, human review, augmentation, the split into training, validation and test sets. This is where datasets quietly change character. Record what was removed and why, and how large any human-reviewed sample was.

The evaluation:

How you checked that the data was useful and safe. For utility, that might be comparing model performance on synthetic versus real holdout data. For privacy, results from tests such as membership inference or nearest-neighbour distance checks against the source records. For bias, how you examined representation across the groups that matter for your system. Report the weak results too. An evaluation section where everything passed makes experienced auditors suspicious.

One more item deserves its own line: the mix. If the final training set blends real and synthetic data, record the proportions. Many of the questions that come up later, including model collapse concerns, bias amplification and privacy exposure, depend on how much of the model’s diet was synthetic.

Where the EU AI Act fits

For providers of high-risk AI systems, Article 10 of the AI Act sets out data governance requirements for training, validation and testing data. Article 10(2) calls for documented practices covering how data was collected and where it came from, preparation operations such as labelling and cleaning, bias examination, mitigation measures, and the identification of data gaps. The Act doesn’t carve synthetic data out of this. If anything, it treats synthetic data as something to be evaluated like any other: one industry summary notes that synthetic data used to augment or replace real datasets still has to be assessed for quality, bias and representativeness.

Synthetic data also shows up in the Act directly. When providers want to process special categories of personal data to detect and correct bias, one of the conditions is that the bias work can’t be done effectively with other data, including synthetic or anonymised data. In practice that means a regulator may ask you to show you tried the synthetic route first. A dated record of that attempt is worth having.

The broader technical documentation duty sits in Article 11 and Annex IV. Annex IV expects detail on data collection methods, sources, the rationale for choosing the data, split methodology, preparation steps, labelling procedures and bias detection results.

A word on timing, because the dates have moved. The Digital Omnibus on AI has now entered into force, and it defers the stand-alone high-risk obligations under Annex III from 2 August 2026 to 2 December 2027. Systems embedded in products covered by certain sector-specific EU legislation move to 2 August 2028. That’s breathing room, not a reason to wait. Documentation about a dataset is cheapest to produce while the people who built it still remember the details. If you’re unsure which category your system falls into, or how any of this applies in your jurisdiction, that’s a question for qualified legal counsel. This article describes the documentation, not your legal position.

Freeze it before anyone asks

Here’s the practical heart of it. An auditor reading your dataset card will reasonably wonder when it was written. Was it assembled during development, or reconstructed in a hurry once someone asked? A cryptographic timestamp answers that question in a way a file’s “last modified” date never can, since that field can be edited by anyone with access.

The workflow is short:

1- Finish the dataset. Generation, filtering, splitting, all of it. Nothing should change after this point.

2- Write the documentation: the five layers above, plus a manifest listing every data file with its own SHA-256 hash.

3- Bundle the documentation into a single file (a PDF or a plain archive), or simply use the manifest and documentation as the files you anchor.

4- Hash that file and anchor the hash to a blockchain before training begins.

5- Store the anchored file, the datasets, and the certificate information together.

A hypothetical example, to be clear that it’s illustrative: a team generates 400,000 synthetic customer-support transcripts. They write dataset-card-v1.pdf and a manifest.json listing 80 shard files with a hash for each. They anchor the hash of manifest.json and of the dataset card, then start training. Fourteen months later an auditor asks which data the deployed model saw. The team produces the manifest, shows the shard hashes match the stored files, and shows the manifest’s anchored hash matches the blockchain record. The chain from “this model” to “these exact bytes” holds together, and the date is not something the team merely asserts.

Two practical notes from experience with hashing workflows generally. First, a manifest is the right unit for large datasets, because you can hash a short file that points at everything else. Second, keep the original archive. Archive formats like zip and tar often embed timestamps and ordering details, so rebuilding “the same” archive later usually produces a different hash. If you anchored a particular file, that exact file is what needs to survive.

How Certelo handles the anchoring step

Certelo calculates the SHA-256 hash locally, in the browser, so the dataset card and manifest stay on your device. For synthetic data that matters more than usual. Seed data and manifests can reference confidential or personal material, and the point of the exercise is to prove a record existed, not to hand a copy to another party. Only the hash is anchored to the Electra Protocol blockchain, and later anyone holding the original file can recompute the hash and check it against the blockchain record.

That’s the whole extent of the claim. It’s a verifiable timestamp on a digital fingerprint.

What a timestamp will not tell an auditor

It’s worth being blunt about the limits, because an overclaim here would do more harm than having no timestamp.

A blockchain record shows that a particular hash existed at or before a particular time. It doesn’t show the dataset is good. It doesn’t show the documentation is truthful or complete, that the generator you named is the one you used, or that the privacy tests were run properly. It doesn’t establish who made the data, and it says nothing on its own about legal compliance in any jurisdiction.

What it does is narrow the room for doubt about when. If the documentation is anchored before training and the model’s lineage links back to it, an auditor can concentrate on whether the content is right, rather than whether it was invented later. Those are different questions, and only the second one is a judgement about your work.

It also works best alongside the other controls, not instead of them: version control for code, signed model artifacts, proper access logs, content credentials where they apply to media. A timestamp is one piece of an audit trail.

Mistakes that cost teams time later

A few patterns come up repeatedly. Documenting only the training set and forgetting validation and test data, which auditors do check. Describing the generator by family name rather than exact version. Recording the evaluation conclusions but not the method, so nobody can repeat the test. Overwriting a dataset in place instead of versioning it. And writing the dataset card last, from memory, when the people who made the decisions have moved on.

None of these are hard to avoid. They just require treating documentation as part of the pipeline rather than an afterthought.

Frequently asked questions

Is synthetic data exempt from AI Act data governance requirements?

No. Article 10 applies to the training, validation and testing data of high-risk systems regardless of whether it’s real or synthetic, and synthetic data is expected to be assessed for quality, bias and representativeness like any other source. Whether your system counts as high-risk is a legal question worth putting to counsel.

Do I need to keep the synthetic data itself, or just the documentation?

Ideally both, because the manifest’s hashes only mean something if the files they describe can still be produced. If the data is too large to retain, record that decision and what you kept instead, such as the generator version, seeds and configuration, so a rerun is at least possible.

Can a blockchain timestamp prove my synthetic dataset is privacy-safe?

No. It can show that your privacy test results existed on a given date. Whether those tests were adequate is a separate judgement for you and your auditor.

What if a generator isn’t deterministic?

Say so in the record, and store the output rather than relying on regeneration. For language-model-based generation, the dataset you saved is the evidence; the process is context.

How do I document human review of synthetic samples?

Record who reviewed (by role, not necessarily name), how many samples, how they were chosen, the criteria used, and what was rejected. A dated review log, anchored along with the rest, is plenty.

Does Certelo see my dataset?

No. The hash is generated locally and the original file isn’t uploaded to create the record.

Closing thought

Synthetic data makes it very easy to produce a lot of material quickly, and that’s precisely why the paper trail matters. Write down the five layers, freeze the record before training, and anchor it. If you want to see how the verification side works in practice, Certelo’s walkthrough covers it step by step.