EU AI Act Content Labeling Requirements for Developers

On August 2, 2026, one compliance shortcut dies: adding an “AI-generated” badge and calling the job finished. The EU AI Act content labeling requirements split the work into two separate systems—machine-readable marks for providers and human-readable disclosures for deployers. One lives inside the asset. The other must survive contact with an actual person.

That distinction matters because the maximum fine can reach €15 million or 3% of worldwide annual turnover. It also matters because a visible badge cannot prove provenance, while pristine metadata is useless to a viewer who never sees it. The regulation has, quite sensibly, declined to let one icon cosplay as an architecture.

This guide turns Article 50’s legal text into a developer checklist. It is implementation guidance, not legal advice: classify each output, apply the right machine marks, add the required human disclosure, test every transformation, and retain evidence.

EU AI Act content labeling requirements: two jobs, not one

The first job belongs to providers: companies that place AI systems on the EU market or put them into service under their name. Generative systems producing synthetic audio, images, video, or text must make covered output machine-readable and detectable as artificially generated or manipulated.

The second belongs to deployers: businesses, agencies, and professionals using an AI system under their authority. They must disclose deepfakes and AI-generated or manipulated text published to inform the public on matters of public interest—unless that text received substantive human review, editorial control, and accountable editorial responsibility.

Location is not an escape hatch. A provider outside the EU is covered when its system’s output is used there as intended—not through merely incidental, unforeseeable, or unauthorised downstream use. Inside a company, the legal entity normally remains the deployer when employees or contractors operate under its control. Compliance ownership does not fragment into one person per prompt.

Role	Trigger	Control
Provider	System generates synthetic content	Machine-readable marking plus detection
Deployer	Deepfake reaches people	Visible or audible disclosure
Deployer	Unreviewed public-interest text is published	Clear label at first exposure

The Commission’s Article 50 FAQ clarifies two useful boundaries. Content generated and published before August 2 does not need retroactive labels; in-scope text generated earlier but first published on or after that date still does. Systems already on the market get until December 2, 2026—but only for the provider marking-and-detection duty, not every transparency obligation.

The final code is voluntary; the legal duties are not. About 190 organisations had signed by the end of July, and alternative implementations must demonstrate equivalent adequacy. That is a meaningful distinction in a field where invisible AI processing already carries a trust cost.

Step 1: classify every output before release

Start with an output-release gate, not a label component. For every asset, record the system, model version, modality, generation time, intended audience, and whether your organisation acts as provider, deployer, or both. Then classify the content before an export or publish action can run.

def article_50_controls(asset):
    controls = []

    if asset.provider_output and asset.is_synthetic and not asset.standard_edit:
        controls += ["machine_mark", "detector", "test_record"]

    if asset.is_deepfake and not asset.law_enforcement_exception:
        controls += ["visible_or_audible_disclosure"]

    reviewed = asset.substantively_reviewed and asset.editorial_owner
    if asset.public_interest_text and not reviewed:
        controls += ["visible_disclosure"]

    return sorted(set(controls))

Do not turn the booleans into vibes. A deepfake must resemble an existing or plausibly existing person, object, place, entity, or event and falsely appear authentic or truthful. An obviously synthetic illustration is not automatically a deepfake. Standard editing and closed-loop production uses also have narrower exceptions.

Human review is equally specific. Spell-checking, grammar fixes, and someone clicking “approve” are not enough. The reviewer needs relevant knowledge and authority to alter or reject the substance, while a person or organisation accepts editorial responsibility. Treat that approval trail like any other layered AI control: named owner, recorded decision, reproducible evidence.

Step 2: build the provider marking stack

The final transparency code uses multiple layers because no single current technique reliably satisfies effectiveness, interoperability, reliability, and resistance to alteration. For audio, images, video, and containerised text, its main path combines digitally signed, time-stamped metadata with an imperceptible watermark.

Output	Metadata layer	Watermark layer
Image, audio, video	Signed and time-stamped	Required under the code’s main path
PDF, DOCX, containerised text	Signed and time-stamped	Required under the main path
Free-form text over 200 tokens	Not transportable	Applied despite lower reliability
Free-form text under 200 tokens	Not transportable	Below the code’s current reliable-marking threshold

C2PA’s Content Credentials specification is a practical option for the signed-metadata layer. Its manifests bind claims and edit history to an asset with cryptographic signatures and timestamps. That maps neatly to provenance, but it is not a legal magic wand—and the code does not mandate C2PA.

You still need the complementary watermark for covered formats, plus a matching detector. Detection may be a public specification, portable library, executable, or API, and it generally must be available free. Preserve recognized incoming marks during transformations, prohibit intentional removal in documentation or terms, and protect signing keys as production secrets rather than adventurous environment variables.

Step 3: add the disclosure people can perceive

Deployers need a separate presentation layer. The EU’s downloadable AI icons are optional, but a compliant label is not. The basic visual element uses “AI,” may distinguish fully generated from partially modified content, and must be clear at first exposure without requiring a hover, click, or archaeological expedition through a terms page.

• Images: place the label where overlays do not block it and preserve it through downloads or sharing where possible.
• Video: show it at the beginning, after interruptions, and where possible at regular intervals.
• Audio-only deepfakes: begin with a plain-language audible disclaimer and repeat it when long-form audio is interrupted.
• Public-interest text: place the label near the headline, at the top, or in an equally clear opening position.

For a synthetic-audio pipeline, put the audible disclosure after generation but before distribution, then test the final encoded file. Visual labels need sufficient contrast, screen-reader support, and useful alt or ARIA text. An accessibility failure does not become compliant merely because the badge looked tasteful in Figma.

Step 4: test failure modes, not the happy path

A valid source file proves very little. Run the released asset through every transformation your pipeline or audience will use: resizing, recompression, transcoding, screenshots, clipping, document conversion, content-delivery optimization, and social uploads. Then test each layer independently.

• Validate the metadata signature, certificate chain, timestamp, and asset binding.
• Measure watermark false positives, false negatives, and survival after common edits.
• Confirm the visible or audible disclosure remains perceptible at first exposure.
• Record the generator version, detector version, test corpus, results, and approval owner.
• Provide a route for users and researchers to report missing or incorrect labels.

Fail the release if any required layer disappears. Optional output fingerprints or privacy-preserving logs can help investigate failures, but the code does not treat either as a standalone substitute. The evidence bundle should be versioned alongside the product release, because “we tested it once” ages about as gracefully as an unsigned certificate.

Set acceptance thresholds before running the test, then publish who owns failures and how quickly they must be corrected. Track results by format, generator version, transformation, and detector version. Otherwise, one excellent PNG result can conceal a watermark that vanishes from JPEGs, a label cropped from vertical video, or a signature broken by the publishing platform.

The release gate is the product

The hard question is not whether a team can attach two marks to a clean demo asset. Can an ecosystem built from lossy exports, reposts, screenshots, and third-party platforms keep machine provenance and human disclosure attached to the same content?

Article 50 does not turn a badge into truth. It turns provenance, disclosure, and evidence into release criteria—and that is a much more useful engineering constraint.

August 2 starts the obligations. December 2 ends the narrow marking grace period for systems already on the market. Between those dates, the teams with a tested release gate will have an implementation; everyone else will have an icon and a meeting.