What to log on every generation for compliance
A per-asset record of model, version, prompt, references and human edits answers registration, regulator and client-audit questions. The fields to capture.
The record you need is created at the exact moment nobody wants to create it: while the render is still going and the next shot is already queued. Nine months later somebody asks which model made shot three of the autumn campaign, and the only surviving artefact is an MP4 with a filename ending _final_v4_REAL.
This is the asset-level layer, not the job-level one. One record per generation, captured automatically where possible, and small enough that capturing it costs nothing. Get it right and three completely different questions get answered from the same rows.
Informational, not legal advice.
Three people ask, and they ask different questions
The registrar wants to know what a human did. US registration practice requires disclosure of AI-generated material, per the Copyright Office's guidance of 16 March 2023, and the Part 2 report of 29 January 2025 confirmed that human selection, arrangement and modification are the protectable parts. So the fields that matter here are the ones separating machine output from human decision.
The regulator wants to know whether the thing was marked and labelled. EU AI Act Article 50 applies from 2 August 2026: providers must mark synthetic audio, image, video and text in machine-readable form, and deployers must label deepfakes to the viewer on first exposure rather than burying it in metadata. Systems already on the market before that date have until 2 December 2026, and only for the marking obligation. Penalties run to €15M or 3% of global turnover. California's AI Transparency Act, as amended by AB 853, brought latent provenance marking by covered providers to the same 2 August 2026 date. New York's synthetic-performer disclosure has applied to ads reaching NY consumers since 9 June 2026, at $1,000 for a first violation and $5,000 thereafter. China's labelling measures have required both visible and embedded labels since 1 September 2025.
The client's legal team wants to know where the inputs came from and what you were allowed to do with them. Reference images, voice sources, likeness, and the terms in force on the day you generated.
One record serves all three, but only if you capture fields that none of them would obviously ask for.
The field list
| Field | Example entry | Primarily serves |
|---|---|---|
| Asset ID | nf-autumn_sh03_g0007 |
All three |
| Parent asset | nf-autumn_sh03_g0004 (this was an edit of that) |
All three |
| Model and version | Full version string, not the family name | All three |
| Provider | Who actually ran the inference | Client legal |
| Timestamp | UTC, on the generation not the file write | Regulator |
| Prompt | Verbatim, exactly as sent | Registrar |
| Prompt modifications | Any expansion, rewrite or system additions applied | Registrar |
| Seed | The value, or "not fixed" | Registrar, client |
| Settings | Resolution, duration, frame rate, aspect, sampler settings | Client |
| Reference inputs | Hash + source + rights basis for each | Client legal |
| Human edits after | "Retimed to 37f, masked and replaced sky, graded" | Registrar |
| Terms captured | Dated copy of the licence page for that model | Client legal |
| Marking applied | Machine-readable marking present, and the visible label text | Regulator |
| Delivered in | Which deliverables this asset appears in | All three |
Fourteen fields. Most of them should come from the generation call itself rather than from a person.
The five fields people get wrong
Model version, not model name. "Kling" is not an answer. Model families ship new versions that change behaviour, change terms, and sometimes change training-data claims, and the version in force when you generated is the only one your record can honestly assert. A record that says "generated with Veo" cannot tell anyone which terms applied. Standardising on the version string is the single highest-value change most teams can make, and it belongs in the filename too, which asset naming and version discipline covers properly.
Reference inputs and their rights basis. This is the field that actually causes incidents. A reference image is someone else's file until proven otherwise, and "we found it in the shared drive" is not a rights basis. Log a hash so the exact file is identifiable later, plus one short phrase: client-supplied, shot in-house, stock licence number, or model-generated with its own asset ID. The same applies to voice sources, which carry likeness exposure on top of copyright. Digital replica rights is the fast-moving half of that risk.
The human-edit line. One sentence, specific, written while you remember. "Cleaned up" is worthless. "Retimed to 37 frames, masked and replaced the sky, regraded to the brand LUT" is a description of authorship a registrar can work with, and it is the exact field the Part 2 report's selection-arrangement-modification framing is asking about. If you cut in an EDL-based editor, the timeline revision already is this description, and pointing at the revision beats retyping it.
Seed, and whether it was fixed. Reproducibility is not a compliance requirement, but it is what lets you answer "can you regenerate that shot without the logo?" without rebuilding the whole prompt from guesswork. Seeds and reproducibility explains what a fixed seed does and does not guarantee once the model version moves under you.
Terms as they stood. Provider terms change without a version number and without notice. "We complied with the terms" is undefendable unless you can produce the terms you complied with. One dated capture per model per campaign is enough, and it matters most where an indemnity is involved, because the copyright indemnities that exist are generally enterprise or API-tier and conditioned on using the provider's safety filters. Consumer-tier terms frequently disclaim IP warranties outright.
Capture at generation, not at delivery
The fields above are cheap to write and expensive to reconstruct. Every one of them exists in memory at generation time and in nobody's memory a quarter later.
Two design rules make this stick:
- The record is emitted by the pipeline, not typed by a human. Anything that depends on someone remembering to fill in a form will be 60% complete within a month. Model, version, prompt, seed, settings, timestamp and references are all available to whatever made the call. Only the human-edit line needs a person, and it needs one sentence.
- The unit is the generation, not the deliverable. If a shot went through generate, extend, then upscale, that is three records chained by parent asset ID. Collapsing them into one loses the version history that the whole record exists to preserve. When one prompt fans out across several named models in a single request, that is several records, not one.
Where a workflow assembles dozens of assets into one deliverable, the record should aggregate the same way the budget does: written per asset, read per deliverable.
What the file cannot carry for you
There is a persistent hope that Content Credentials make all of this unnecessary. They do not, for a structural reason.
The current public C2PA spec family is 2.x, with a Conformance Program and Trust List now gating who can sign credibly. But a C2PA manifest is a hard binding to a specific file. Any re-encode, screenshot, format conversion or non-C2PA-aware editing step destroys or invalidates it, and major social platforms re-encode on upload. Raw manifests routinely do not survive distribution.
Durable Content Credentials mitigate that with three layers: the manifest, an invisible watermark that lives in the pixels and survives recompression, and a perceptual fingerprint resolved by database lookup. That is genuinely more robust, and still defeated by heavy cropping, deliberate removal, or an unreachable fingerprint database. How invisible watermarks work and where they stop is the detail layer, and what C2PA records on design files covers what is actually inside a manifest.
Treat provenance metadata as a compliance aid for the marking obligation, not as your record. Your record is a database row you control. The file is a copy that travels and gets damaged. Whether the marking obligation lands on you at all depends on which role you occupy, which provider or deployer unpacks.
FAQ
Is this overkill for a two-person studio?
The field list is long to read and short to implement, because almost all of it is already in the API response. The only manual field is the human-edit sentence. A two-person studio that skips it is not saving work, it is deferring work to the version of itself that gets a rights question from a client's counsel with a two-day deadline.
Do I need this for internal or unpublished work?
Keep the generation record regardless, because the cost is near zero and internal work has a habit of becoming external. The disclosure and marking fields only become live when something is distributed, so those rows can stay empty until the asset ships.
How long should these records be kept?
Longer than the campaign. The useful clock runs from last use rather than from delivery, because a rights question arrives about content that is still visible somewhere. Assets that get re-cut into new deliverables restart that clock every time, which is another reason the parent-asset chain earns its place.
Does logging the prompt create a problem if it is ever disclosed?
It can, which is an argument for writing prompts you would be comfortable reading back, not an argument for not keeping them. Prompts naming a living artist, a specific film, or a real person are the ones that read badly out of context, and they are also the ones most likely to produce output you should not ship. The log is a useful forcing function on that habit.