AI disclosure and compliance

Article 50 of the EU AI Act came into force on 2 August 2026. It requires deployers to disclose AI-generated public-interest content and deepfakes, with penalties reaching EUR 15M or 3% of global turnover.

Disclosing correctly requires knowing, per asset, what is synthetic. That is a lineage question — and no tracker, asset manager, or render manager can answer it, because none of them held the whole chain. OWG holds the lineage as an ordinary by-product of running the work, so the obligation becomes a query rather than a project.

What the regulation distinguishes

Three distinctions matter, and conflating them is the most common mistake:

The exemption is narrower than people hope and wider than they fear. Denoise, up-res, and grammar fixes are assistive. A voice clone, synthetic imagery, AI-written text, or a lip-sync dub is generative.

The six fields

Disclosure is declared at the point of work and computed at the point of delivery. Six schema fields carry the declarations:

The critical design choice: the per-asset conclusion is computed from lineage, not stored. An asset is synthetic, hybrid, or traditional because of what its ancestry says, not because someone remembered to tick a box on it. Storing the conclusion would let it drift out of agreement with the work that produced it.

Declaring AI involvement

ai_role is declared on the task, and AI-ness is never inferred from the executor type. The schema says so explicitly. An agent executor might be doing deterministic file shuffling; a saas_api executor might be running a diffusion model. Only the explicit declaration is authoritative.

{
  "id": "dub_es_419",
  "type": "work",
  "label": "Spanish (LatAm) lip-sync dub",
  "executor": { "type": "saas_api" },
  "ai_role": "generative",
  "performed_by": "agent_dubber",
  "used": ["master_audio_en", "reference_perf_v2"],
  "produced": ["dub_es_419_v1"]
}

{
  "id": "denoise_plate_0140",
  "type": "work",
  "executor": { "type": "local_app" },
  "ai_role": "assistive",
  "performed_by": "a.rivera",
  "used": ["plate_0140_raw"],
  "produced": ["plate_0140_dn"]
}

The second is exempt from marking, and the graph records why it is exempt rather than leaving the exemption as an undocumented assumption.

Editorial sign-off

Where the regulation expects a named human to take responsibility, editorial_signoff names one. The editor field is required within it:

{
  "id": "review_copy_final",
  "type": "review",
  "performed_by": "j.mbeki",
  "editorial_signoff": {
    "editor": "j.mbeki",
    "statement": "Reviewed for factual accuracy; accepts editorial responsibility.",
    "timestamp": "2026-08-19T14:22:00Z"
  }
}

A participant with role: "editor" is the one eligible to provide it.

Governance ceilings

Run-level ceilings sit alongside the disclosure gate, which is what makes the gate more than advisory:

{
  "governance": {
    "disclosure_gate": true,
    "max_total_reroutes": 12,
    "budget_usd": 4800
  }
}

With disclosure_gate set, delivery-typed tasks are blocked until the compliance validator certifies the project and emits the disclosure manifest. Compliance stops being a pre-delivery scramble and becomes a condition of delivery.

The baseline rule pack

The specification defines a baseline rule pack — six rules a conformant compliance validator must implement. Rules are evaluated against a delivery-typed task and the lineage of the assets it delivers.

Three of these deserve a note.

R1 is deliberately conservative. Silence is not a declaration of innocence. An unset ai_role on a task that could involve AI is a finding, not a default of "no AI" — which is why declaring ai_role: "none" explicitly is an authoring rule rather than optional politeness.

R3 is independent of work_type. The deepfake provisions attach to depicting a real person, not to the genre. A synthetic likeness in a drama triggers R3 exactly as one in a news package does.

R6 is a warning rather than an error, because an inferred disclosure input is not wrong — it is unconfirmed. A human accepting it clears the finding, which is the acceptance record doing its job. Certifying on an unaccepted inference is a defensible choice; doing it without knowing you did is not.

Extending the pack

The baseline is the floor, not the ceiling. Jurisdiction- and client-specific rules are added as a versioned pack layered over it, because obligations differ by territory and regulation keeps developing — binding every rule into the core would date the specification.

Two requirements on any pack:

• It must version, and a certification must record which pack version judged it. When regulation changes you need to know what standard a past delivery was held to.
• It may add and tighten, never remove. A pack that disables a baseline rule is not conformant.

See Implementation considerations for how to structure one.

The deliverable

The output is a signed, per-asset AI disclosure manifest — the document a broadcaster can hand a regulator.

It is itself an asset, produced by a task, performed by a responsible participant. Compliance has provenance too: the manifest can answer who generated it, from what graph state, and when. A manifest that could not account for its own origin would be a strange thing to hand a regulator.

Where OWG sits

Three layers, often conflated:

1. Creation-time marking — C2PA content credentials, applied at capture or generation.
2. Production-time tracking — the lineage OWG produces as a side effect of running the work. This is the layer that was missing.
3. Publication-time labelling — the EU icon set, applied at distribution.

Layers 1 and 3 already existed. Without layer 2, an organization can mark at creation and label at publication and still be unable to say which of ten thousand delivered assets needs the label — because nothing tracked the chain in between.