Open Workflow GraphPre-release
Ecosystem

AI disclosure and compliance

How EU AI Act Article 50 disclosure becomes a lineage query, and the six schema fields that make a per-asset disclosure manifest computable.

View as markdownMachine-readable source for agents and scripted implementers

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:

CategoryTreatment
AI-generated — created or substantially altered by AIDisclosure required
AI-assisted — standard editing assistance, no substantive semantic alterationExempt
Depicts a real personTriggers the deepfake provisions

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:

FieldLevelValues / purposeArticle
ai_roleTaskgenerative | assistive | none50(2)
depicts_real_entityAssetDoes this depict an identifiable real person?50(4)
assuranceAssetattested (verified credential) | asserted | inferred—
work_typeContextcreative-fictional | factual-news | advertising | sports | other50(4)
editorial_signoffTaskNamed editor accepting responsibility50(4)
disclosure_gateGovernanceBlocks delivery until certified50

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.

From v0.93, the asset a task produces can also say how it came to be in IPTC terms (asset.iptc). That is the vocabulary C2PA and image and video metadata already use. The validator checks that the label agrees with the task's ai_role (OWG_IPTC_AI_MISMATCH). See IPTC.

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.

RuleCheckSeverity
R1A task whose executor can involve AI (agent, saas_api, comfyui_graph, comfyui_node) leaves ai_role unsetError
R2A delivered asset whose lineage contains a generative task carries no disclosure markingError
R3A delivered asset whose lineage contains both a generative task and an asset with depicts_real_entity: true carries no deepfake disclosureError
R4An AI-generated text asset delivered in a factual-news context has no editorial_signoff by a participant with role: "editor" in its lineageError
R5governance.disclosure_gate is true and a delivery task completed without a certified manifest asset in its used[]Error
R6A disclosure-relevant value (ai_role, depicts_real_entity) rests on an inferred relationship with no accepted_byWarning

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.