EU AI Act Article 50 is usually explained as a provider-versus-deployer checklist. The operational problem is the handoff between them. Providers build interaction notices and machine-readable provenance into systems. Deployers control the final interface, content workflow, transformations, and publication. Compliance fails when each party assumes the other owns the last mile.
Legal snapshot: 1 August 2026. This operational guide is not legal advice.
Reading time: 9 minutes · About 1,850 words
TL;DR
- Most Article 50 obligations apply from 2 August 2026. Under the 2026 AI Omnibus, the Article 50(2) marking obligation has a grace period until 2 December 2026 for generative AI systems placed on the market before 2 August.
- Providers own system-level disclosure design and machine-readable marking. Deployers own notices for emotion recognition or biometric categorisation and disclosures for deepfakes and certain public-interest text.
- Machine-readable provenance and human-visible disclosure are separate controls. One does not automatically satisfy the other.
- A company can hold both roles, and one workflow can trigger several paragraphs at once.
- Contracts should specify legal owner, control operator, evidence owner, and the artifacts exchanged at every handoff.
Start with a current legal snapshot
The European Commission published its final Article 50 guidelines on 20 July 2026 and updated the related pages at the end of July. The transparency obligations start applying on 2 August 2026.
One timing detail changed through the AI Omnibus. The Commission's current Quick Facts give generative AI systems placed on the market before 2 August a grace period until 2 December 2026 for the machine-readable marking obligation in Article 50(2). This is a targeted transition, not a general postponement of Article 50.
The distinction matters because the AI Act Service Desk currently warns that its displayed provision has not yet been updated to reflect the Omnibus amendments. A compliance snapshot should therefore record the source and date used, rather than copying one consolidated page and treating it as timeless.
The Commission's Code of Practice on Transparency of AI-Generated Content is also easy to misclassify. The final code was published on 10 June. The Commission and AI Board consider it an adequate voluntary tool for demonstrating compliance with the marking and labelling duties. It does not replace the Act or the guidelines, and signing it is not conclusive proof of compliance. Non-signatories remain responsible for demonstrating that their alternative measures are adequate.
Classify the activity, not the company logo
Article 50 assigns duties to roles in relation to a specific AI system and use. A foundation-model vendor may be a provider. A company that integrates a third-party model into a branded customer-facing AI system may also need to analyse whether it is the provider of that downstream system. The same company may then deploy that system in its own support or publishing workflow.
Use four questions for each system and channel:
- Who places the relevant AI system on the market or puts it into service under its name or trademark?
- Who uses the system under its authority in a professional activity?
- Who controls the first user interaction or exposure?
- Who controls the output after export, editing, transcoding, CMS ingestion, or platform upload?
The answers may name different entities. A procurement contract can allocate implementation work, but it does not automatically move the legal obligation attached to a role.
The four trigger families
| Trigger | Primary role | Required outcome | Important boundary |
|---|---|---|---|
| Direct interaction with a person, Article 50(1) | Provider | design the system so the person is informed they are interacting with AI | exception where AI involvement is obvious in context; specific law-enforcement carve-out |
| Synthetic audio, image, video, or text, Article 50(2) | Provider | machine-readable marking and detectability, using effective, interoperable, robust, and reliable measures where technically feasible | standard editing or no substantial alteration; specific law-enforcement carve-out; targeted Omnibus transition |
| Emotion recognition or biometric categorisation, Article 50(3) | Deployer | inform exposed people and comply with applicable data-protection law | permitted law-enforcement uses have a specific carve-out |
| Deepfakes and certain public-interest text, Article 50(4) | Deployer | disclose artificial generation or manipulation | adjusted disclosure for evident artistic or satirical works; public-interest text exception requires human review or editorial control plus editorial responsibility |
Article 50(5) adds a horizontal requirement. Information must be clear, distinguishable, accessible, and provided no later than the first interaction or exposure.
These duties can stack. A voice agent can trigger direct-interaction disclosure. Its generated audio can trigger provider-side machine marking. If a deployer publishes cloned-voice media that meets the deepfake definition, a human-facing disclosure may also be required.
Machine marking and human disclosure are different controls
Article 50(2) targets machine-readable provenance and detectability. Article 50(4) targets disclosure to people exposed to certain content. A metadata field may help a detector and remain invisible to an audience. A visible AI label may inform a viewer while carrying no durable machine-readable provenance.
A robust implementation therefore uses layers:
- a machine-readable origin or manipulation signal;
- modality-appropriate human disclosure;
- records that connect both signals to the system and content version;
- tests that show what survives the real distribution path.
OpenAI's July 31 transparency statement illustrates why layering matters. It describes Content Credentials and watermarking as complementary, and acknowledges that metadata can be removed, labels can disappear across platforms, and no single signal is perfect. That is a useful engineering observation, not a declaration that any specific technology automatically satisfies Article 50.
The practical test is end to end. Export an image, take a screenshot, compress a video, transcode audio, insert content into the CMS, and upload it to the actual distribution platforms. Record whether the machine signal and human disclosure remain detectable after each transformation.
Build a provider-to-deployer evidence contract
Most checklists assign one owner per obligation. Production systems need three:
| Responsibility | Question | Typical artifact |
|---|---|---|
| Legal owner | Which entity and role remains accountable? | role analysis, legal basis, approved exception |
| Control operator | Who can implement or preserve the control? | product configuration, CMS rule, channel template, release gate |
| Evidence owner | Who can prove the control worked for this version and channel? | screenshots, recordings, detector results, approval and test logs |
The provider should deliver an evidence pack with the system, not a paragraph that says compliant with Article 50. A minimum pack can include:
- Role and scope statement: the system, modalities, intended channels, and obligations the provider supports.
- Interaction-disclosure interface: default notices, localisation and accessibility support, configuration boundaries, and API hooks for downstream interfaces.
- Marking specification: format, version, coverage by modality, detector or verification method, known failure modes, and test vectors.
- Transformation guidance: operations known to preserve or destroy the mark, including export, compression, cropping, transcription, and transcoding.
- Change record: model and product versions, marking changes, compatibility notes, and migration dates.
- Incident path: contact, response target, and remediation process when marks or disclosures fail.
The deployer then adds its own evidence:
- system and channel inventory;
- trigger and exception decision for each use case;
- first-interaction or first-exposure screenshots and recordings;
- accessibility tests;
- transformation-survival results from actual publishing paths;
- human-review and editorial-responsibility records where relevant;
- release approvals, exceptions, and control failures.
This evidence pack is an engineering recommendation. Article 50 does not prescribe one universal folder structure. Its value is that it makes responsibility testable across organisational and vendor boundaries.
Treat exceptions as paragraph-specific decisions
An exceptions register with a single yes or no field is too coarse. Article 50 contains different boundaries for different duties:
- obvious AI interaction belongs to Article 50(1);
- standard editing and no substantial semantic alteration belong to Article 50(2);
- authorised law-enforcement uses appear in several paragraphs with different wording;
- evident artistic, creative, satirical, or fictional works receive an adjusted deepfake disclosure under Article 50(4);
- public-interest text needs both human review or editorial control and an identifiable natural or legal person holding editorial responsibility to use that exception.
Record the paragraph, facts, approver, evidence, expiry or review date, and affected channels. Reassess the decision when the model, interface, audience, or publishing workflow changes.
A release gate that teams can run
Before launch or publication, ask:
- Has the system and each professional use been classified by role?
- Have all four trigger families been tested, including cumulative triggers?
- Is the current Omnibus transition rule applied only to the eligible Article 50(2) systems?
- Are machine-readable marking and human-facing disclosure tested separately?
- Does the disclosure appear by first interaction or exposure and pass accessibility checks?
- Have marks and labels survived the real transformation and distribution path?
- Is every exception tied to the correct paragraph and documented facts?
- Can one evidence bundle reconstruct the provider and deployer controls for the released version?
This control model complements broader enterprise AI governance and the production approval gates used for generative content. Article 50 turns those governance ideas into role-specific transparency outcomes.
FAQ
Does Article 50 apply only to high-risk AI systems?
No. Its transparency duties are triggered by the covered interactions and content uses, including systems that are not classified as high-risk.
Is a provider's machine-readable mark enough for a deployer?
No general assumption is safe. The deployer may have a separate duty to inform exposed people, and the provider's mark may be lost during downstream processing. Test both legal triggers and signal survival.
Does human review always remove the disclosure duty for AI-generated text?
The Article 50(4) exception for public-interest text requires human review or editorial control and a natural or legal person holding editorial responsibility. The facts and the quality of the process matter.
Is signing the Code of Practice mandatory?
No. It is a voluntary, EU-recognised route for demonstrating compliance with the covered marking and labelling obligations. Non-signatories must be ready to demonstrate adequate alternative measures.
Is C2PA compliance the same as Article 50 compliance?
No. Content Credentials can contribute to provenance, but Article 50 covers several roles, human disclosures, timing, accessibility, exceptions, and use cases. No single technical signal covers the entire article.
References
- European Commission: final Article 50 guidelines
- European Commission: Article 50 Quick Facts
- EUR-Lex: Regulation (EU) 2026/1744
- EU AI Act Service Desk: Article 50
- European Commission: Code of Practice on Transparency of AI-Generated Content
- European Commission: assessment of the Code of Practice
- EUR-Lex: Regulation (EU) 2024/1689
- OpenAI: Advancing responsible AI across Europe