The transparency obligations in Article 50 of the EU AI Act started to apply on August 2, 2026. That day, the European Commission account on X posted:
A quick fact check confirmed: the claim “The label says it all” is, at best, simplified. The Commission’s own page says that not all AI-generated or manipulated content needs to be labelled. The icons are optional, and using one does not establish compliance by itself.
I remembered an exception for text that had passed through human editorial control, so used Claude and Codex to research the background.
(I am not a lawyer. The links below lead to the underlying Act or the closest supporting passage in the Commission material. The guidelines themselves are non-binding; only the Court of Justice of the European Union can ultimately give an authoritative interpretation.)
What Article 50 covers
Article 50 separates obligations for providers of AI systems from obligations for professional users of those systems (“deployers” in the Act).
Under Article 50(2), providers of generative AI systems - like OpenAI - must make synthetic audio, image, video and text outputs detectable in a machine-readable format. This is a technical marking layer, but not necessarily a label visible to a reader.
Deployers - so the rest of us - have a narrower visible-disclosure obligation under Article 50(4) in case of:
image, audio or video content that constitutes a deepfake, and
AI-generated or manipulated text published to inform the public on matters of public interest.
Text
For text, three conditions have to apply: it must be published, informative to the public, and concern a matter of public interest. The Commission’s examples include politics, public administration, public health and safety, but also economic, scientific and cultural developments that may be the subject of public debate.
The same provision contains the exception I remembered: the disclosure obligation does not apply when the text has undergone human review or editorial control and a natural or legal person holds editorial responsibility for its publication.
So the rule is not “AI touched it, add a label”. For qualifying public-interest text, substantive human editorial control can remove the Article 50 labelling obligation.
Images
The image case is different. The Act’s definition says a deepfake is AI-generated or manipulated image, audio or video content that resembles a person, object, place, entity or event and could falsely appear authentic or truthful. The Commission interprets this to include something that exists, can plausibly exist or could plausibly have existed. A generic photorealistic person is therefore not automatically outside the definition merely because no specific real person was copied. Context and audience expectations matter; illustrative or fictional work is less likely to appear authentic in a context where the audience does not expect authenticity.
My Aileen 3 video appears to be an edge case. Its synthetic narrator opens with “Hi, I’m Aileen, an AI office assistant”, calls me “my creator”, and appears in black and white with bright blue eyes, pointed ears and an AI necklace. In the context of a Kaggle AI-agent submission, there is little ambiguity about the narrator’s identity. The guidelines give one example that is not a deepfake: AI voices for fictional characters when the narrator’s identity is not deceptive. But they also include realistic AI-generated human avatars or personas in the possible definition, and say that informative content prevails when a deepfake mixes informative and creative elements.
For a new Aileen video, Codex with GPT-5.6 Sol therefore recommends to not rely on her appearance or a bare “AI” icon alone. The Commission says that an icon does not establish compliance by itself, and reserves “fully AI-generated” for cases where the entire deepfake content is fully generated. “AI-generated narrator and voice” would say precisely what is artificial. (The existing Aileen videos not need to be labelled retroactively).
Human review
According to the Commission’s final Article 50 guidance published on July 20, human review means deliberate examination of the substance by someone with relevant knowledge and professional judgement. Fact-checking is a minimum part of that review.
Spell-checking however, grammar correction, an automated review or cursory human approval are not sufficient. A substantive AI change after human sign-off also makes the exception void for the resulting version.
This can create a versioning problem. “I reviewed this article” is ambiguous when the article changed afterwards. When using git a versioning system, “I reviewed commit 7c41e2a” is not.
I found no requirement in Article 50 or the final guidelines to create an individual review record for every publication, though. The voluntary Code of Practice asks relevant non-media signatories to identify the person with editorial responsibility and describe how human review is organised. It explicitly excludes documenting individual instances of review.
Nevertheless, a small record may make sense as a matter of due diligence. It identifies the reviewed version, makes an accidental edit after sign-off apparent, and leaves some history for later corrections or doubts. This would be an engineering recommendation, not a requirement grounded in Article 50.
Recording revisions
For Markdown content, YAML frontmatter is an obvious place. Google Cloud’s Open Knowledge Format uses Markdown with YAML frontmatter and version 0.2 added optional sources and generated and verified fields. OKF is a knowledge-exchange format rather than an AI Act compliance standard, but it provides a useful starting vocabulary:
---
type: article
generated:
by: "<provider/model>"
role: research-and-draft
verified:
- by: human:nils-durner
at: "<ISO timestamp>"
editorial_review:
checks: [claims, sources, quotations, final_wording]
reviewed_commit: "<git commit>"
editorial_responsibility: Nils Durner
---
These fields should only be completed after the review. In particular, reviewed_commit prevents a review claim from silently moving to a later version.
A sidecar file such as article.provenance.yml can carry the same information without putting process metadata into the published Markdown, and works also for other file formats. Including a content hash makes separation from, or modification of, the file detectable.
Git can carry the record directly. Commit trailers support fields such as AI-Assisted-By: and Reviewed-By:. A signed commit or release tag can bind a signing key to the reviewed bytes. (This proves that a key signed a particular version, not that a thoughtful review took place; the review scope still needs to be stated).
Conclusion
„The label says it all“ - that‘s unfortunately not the case. As the campaign fails to reflect on the difference between deployers and providers, the FUD it sows seems like a net-negative.
Das ist ein neuer Absatz.