# EU AI Act Article 50: Implementation Guidance **QCK-EUAI-ART50-001-GDE | ODA3 Institute | Companion Guidance | Version 1.0 | Published | 5 August 2026** ## 1. Purpose and relationship to the QCK and WKS This document provides operational, interpretive and worked-example guidance for organizations applying QCK-EUAI-ART50-001 (Public Applicability Quick Check) and QCK-EUAI-ART50-001-WKS (Evidence Worksheet). The three documents serve distinct, non-overlapping purposes: - **QCK** answers: does Article 50 potentially apply to this system? - **WKS** answers: what evidence supports our answer to each question? - **GDE (this document)** answers: how should we interpret and implement the applicable obligation? This document does not itself constitute legal advice, does not determine compliance, and does not replace system-specific legal review. Where this guidance and a qualified legal opinion diverge for a specific system, the legal opinion governs. ## 2. Provider vs. deployer determination guide ### 2.1 Core definitions (plain-language, not a substitute for the Act's own text) - **Provider**: the organization that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. - **Deployer**: the organization that uses an AI system under its own authority, other than for purely personal, non-professional use. ### 2.2 Why this determination must happen per obligation, not once per system A single system can put the same organization in different roles for different Article 50 obligations. Common pattern: | Scenario | Article 50(1) role | Article 50(2) role | Article 50(4) role | |---|---|---|---| | Organization builds a chatbot in-house on a licensed third-party foundation model, publishes AI-generated marketing images through it | Provider (built the interactive system) | Deployer for the model itself (the marking obligation for the underlying model would typically sit with the foundation model provider — confirm per system); provider only if the org performs the generation/manipulation step | Deployer (publishes the output) | | Organization procures a fully off-the-shelf AI chatbot product, deploys it on its own website with no modification | Deployer | Not applicable unless generation/manipulation occurs | Deployer, if applicable | ### 2.3 Decision tree 1. Did the organization develop the system, or have it developed, and place it on the market or put it into service under its own name or trademark, for this specific function? → **Provider** for that function. 2. Does the organization use the system under its own authority for a professional purpose, regardless of who built it? → **Deployer** for that use. 3. Both may be true simultaneously for different functions within the same product. Document each separately. 4. Procurement of a third-party system does **not** by itself resolve the question — a deployer role persists regardless of vendor terms describing the vendor as "responsible for compliance." ### 2.4 Worked example A retail company licenses a third-party generative image tool, embeds it in its own product-customization feature under its own brand, and publishes the resulting AI-generated product images on its e-commerce site. - The company is the **deployer** of the underlying generative model (it did not build the model). - The company may be the **provider** of the customer-facing feature if it materially shapes how generation occurs (e.g., custom prompt templates, fine-tuning, packaging as a named feature) — this requires case-specific analysis, not a default assumption either way. - The company is the **deployer** for Article 50(4) purposes when it publishes the resulting images, regardless of its role in Article 50(2). ## 3. Article 50 obligation-by-obligation implementation guidance Each subsection below follows a consistent structure: Scope, Practical Implementation, Evidence Expectations, Common Pitfalls, and Cross-Reference to Exceptions. This structure is adopted to keep the section maintainable as future Article 50 interpretation and guidance evolves. ### 3.1 Article 50(1) — Direct interaction disclosure **Scope.** Applies to providers of AI systems intended to interact directly with a natural person, through any interface type (text, voice, avatar, agent). The disclosure must occur before or at the time of first interaction. **Practical implementation.** Disclosure must be effective regardless of interface type. Agentic systems acting on a user's behalf, including those that take actions rather than only conversing, fall within scope. For long-running or multi-session interactions, a person could reasonably lose track of the AI nature of the interaction after disclosure at first contact alone; ODA3 recommends organizations consider persistent or re-triggered disclosure for extended sessions as a practical implementation measure, distinct from the strict text of the obligation. **Evidence expectations.** UI/UX screenshots or recordings showing disclosure at the point of interaction; product specifications documenting where and how disclosure fires; for extended sessions, evidence of re-triggered or persistent disclosure design. **Common pitfalls.** Relying on the obviousness exception without documented, obligation-specific rationale; treating disclosure at session start as sufficient for long-running interactions; overlooking agentic or action-taking systems as in scope. **Cross-reference to exceptions.** See Section 4.1 (Obviousness exception). ### 3.2 Article 50(2) — Machine-readable marking and detectability **Scope.** Applies to providers of AI systems that generate or manipulate synthetic audio, image, video or text content. Requires outputs to be marked in a machine-readable format and detectable as artificially generated or manipulated, using technical solutions that are effective, interoperable, robust and reliable, as far as technically feasible given the state of the art. **Practical implementation.** "State of the art" is a moving target; document the specific technical approach considered and the basis for concluding it meets the effectiveness/interoperability/robustness/reliability criteria at the time of assessment. Content already in circulation before the applicable date is generally understood not to require retroactive marking — this reflects the broader external legal commentary reviewed for this guidance, but is not itself independently confirmed against ODA3's pinned Stage 0 sources and should be verified before being relied upon for a specific system. The limited transition to 2 December 2026 applies only to this obligation, only for qualifying systems placed on the market before 2 August 2026, under the AI Omnibus grandfathering amendment. It does not extend to 50(1), 50(3) or 50(4). *Illustrative technical reference points (non-exhaustive).* Organizations may evaluate publicly recognized content provenance, metadata or watermarking specifications — including, where appropriate, C2PA and IPTC — when assessing the "state of the art." Their inclusion here is illustrative and does not imply regulatory endorsement or mandatory use, and does not reflect a Stage 0 pinned-source finding. **Evidence expectations.** Model cards or vendor technical documentation addressing marking/detectability; documented technical evaluation of the approach against the effectiveness/interoperability/robustness/reliability criteria; placement-on-market date, where a transition claim is made. **Common pitfalls.** Treating the transition as a general Article 50 grace period and delaying 50(1)/(3)/(4) work as a result; claiming a technical approach meets "state of the art" without a documented evaluation; retroactively marking content that predates the applicable date (not required, but sometimes mistakenly attempted). **Cross-reference to exceptions.** See Section 4.2 (Assistive editing). ### 3.3 Article 50(3) — Emotion recognition and biometric categorisation disclosure **Scope.** Applies to deployers of systems performing emotion recognition or biometric categorisation on natural persons. Requires that each exposed person be informed of the system's operation, and that applicable data-protection requirements (GDPR, Regulation (EU) 2018/1725, Directive (EU) 2016/680, as applicable) are addressed. Article 50(3) itself is a deployer obligation; a provider may separately carry other obligations (e.g. Article 50(1) or 50(2)) with respect to the same underlying system, but not under Article 50(3). **Practical implementation.** The obligation is to make the information available to the exposed person, not to obtain confirmation that the person received or understood it — an information-provision standard, not a comprehension standard. ODA3's interpretive guidance: treat "exposed person" as broader than "user" — including anyone subject to the system's operation, such as bystanders in workplace or public-facing deployments — pending any more specific Commission clarification. **Evidence expectations.** Documentation of the notice mechanism and where/how it reaches exposed persons (not just users); data-protection assessment addressing the same processing. **Common pitfalls.** Limiting disclosure design to the primary "user" and overlooking bystanders or other exposed persons; treating this obligation as resolving a possible prohibited-practice question under other Articles — it does not. **Cross-reference to exceptions.** No dedicated exception boundary in Section 4; screen separately for prohibited-practice classification under other Articles of the Act. ### 3.4 Article 50(4) — Deepfake and public-interest text disclosure **Scope.** Applies to deployers who generate, publish or otherwise deploy AI-generated or manipulated content resembling existing persons, objects, places, entities or events that could falsely appear authentic or truthful to a reasonably well-informed person (deepfakes), and to deployers who publish AI-generated or manipulated text intended to inform the public on matters of public interest. Note: this audience test is assessed against the actual exposed audience's diversity (including foreseeable exposure to children, elderly persons, or audiences with lower digital/AI literacy) — it is a distinct standard from the Article 50(1) "obviousness" exception in Section 4.1, not an identical formulation applied to a different obligation. **Practical implementation.** Deepfake disclosure is triggered at time of publication or deployment. As a practical implementation standard (ODA3's restatement, not a statutory quotation), ODA3 treats disclosure as adequate only where it is clearly and distinguishably visible or audible to the audience — organizations should verify this framing against the specific obligation text and applicable Guidelines. Public-interest text disclosure requires two elements together, both evidenced: (a) the content underwent human review or editorial control, and (b) a specific natural or legal person holds editorial responsibility and takes responsibility for publication. Neither element alone satisfies the exception. **Evidence expectations.** For deepfakes: recordings or screenshots showing the disclosure as presented to the audience. For public-interest text: editorial policy documents naming an accountable editorial-responsibility holder, plus evidence the specific content was actually reviewed. **Common pitfalls.** Labeling content "creative" or "satirical" to claim the artistic-treatment attenuation without documented analysis of the work's actual character — note this reduces how disclosure must be presented, it does not remove the disclosure obligation; treating a general "we have an editorial process" statement as sufficient without naming the accountable person; confusing the content-level test ("would falsely appear authentic or truthful") with the observer-level test ("reasonably well-informed person") as though they were a single standard — they are assessed together but are analytically distinct. **Cross-reference to exceptions.** See Section 4.2 (Assistive editing), 4.3 (Editorial responsibility), 4.4 (Artistic/creative/satirical/fictional treatment). ## 4. Exception boundaries ### 4.1 Obviousness exception (Article 50(1)) Narrow. The standard is whether the AI nature of the interaction would be obvious to a reasonably well-informed, observant and circumspect person drawn from the actual audience (context-dependent — e.g. a lower threshold applies where children, elderly people or persons with disabilities are foreseeably part of that audience) — not whether the organization itself considers it obvious, and not merely because AI-driven interfaces are now common in the relevant sector. ### 4.2 Assistive editing (Article 50(2) and Article 50(4) — assessed separately) The exception applies to editing that does not substantially alter input content or its semantic meaning (e.g., grammar correction, minor color correction, standard compression). It does not apply to generation or substantive manipulation. Because the exact boundary of "substantial alteration" differs by content type (text, image, audio, video) and by which obligation is being assessed, document the specific facts of the editing operation rather than applying a general assumption. ### 4.3 Editorial responsibility (Article 50(4), public-interest text) Requires an identifiable natural or legal person who holds and exercises editorial responsibility for the specific published content — not merely an organizational policy stating that editorial review occurs in general. ### 4.4 Artistic, creative, satirical, fictional or analogous-work treatment (Article 50(4), deepfakes) This is an attenuated disclosure requirement, not an exemption. Where content is part of an evidently artistic, creative, satirical, fictional or analogous work or programme, the disclosure obligation is limited to disclosing the existence of the generated or manipulated content in a manner that does not hamper the display or enjoyment of the work — disclosure is still required. Requires case-specific evaluation of the work's actual character and context of publication, documented at the time of the determination — not applied retroactively to justify a decision already made for other reasons. ## 5. Evidence expectations Evidence should demonstrate not only that a control exists, but also that it is attributable to the relevant provider or deployer obligation, current for the assessed system version, and retrievable during regulatory review. This section consolidates the obligation-specific evidence expectations from Section 3 into a single cross-obligation reference; it does not introduce new requirements. ### 5.1 Acceptable evidence (illustrative, not exhaustive) - Contract clauses or Data Processing Agreements allocating provider/deployer responsibility - Product specifications or design documents showing disclosure implementation - UI/UX screenshots or recordings showing disclosure at the point of interaction - Model cards or vendor technical documentation addressing marking/detectability - Vendor attestations, with validation date - Editorial policy documents naming an accountable editorial-responsibility holder - Regulatory correspondence addressing the organization's role or approach ### 5.2 Insufficient evidence (illustrative, not exhaustive) - A general statement that "editorial review occurs" without naming a responsible person - A vendor contract that assigns "compliance" to the vendor without addressing the deployer's own Article 50 obligations - An internal assumption that disclosure is "obvious" without a documented rationale - A claim of assistive-editing exception without documenting the specific editing operation performed ## 6. Common implementation mistakes This section consolidates the obligation-specific pitfalls from Section 3 into a single cross-obligation reference. - Treating the Article 50(2) transition as a general Article 50 grace period, and delaying 50(1)/(3)/(4) work as a result. - Assuming a third-party vendor's compliance claims resolve the deploying organization's own deployer obligations. - Applying a single provider/deployer determination to an entire system rather than per obligation. - Relying on the obviousness exception without documented, obligation-specific rationale. - Treating "we have an editorial process" as sufficient evidence of editorial responsibility without naming the accountable person. - Confusing the content-level test ("would falsely appear authentic or truthful") with the observer-level test ("reasonably well-informed person") as though they were a single standard — they are assessed together but are analytically distinct. ## 7. Illustrative scenarios **Scenario A — Customer service chatbot on licensed foundation model.** Company deploys a third-party LLM as a customer-facing chatbot under its own brand. Provider for Article 50(1) (built the interactive system); deployer with respect to the underlying model's Article 50(2) marking (which rests with the foundation model provider, not this company, unless this company itself performs synthetic content generation as a distinct function). **Scenario B — AI-generated marketing images published on social media.** Company uses a third-party image generator to create product images, publishes them without disclosure. Deployer obligation under Article 50(4) if the images could falsely appear authentic (e.g., photorealistic lifestyle imagery); the assistive-editing exception does not apply because the images are generated, not edited. **Scenario C — AI-assisted news summary published by an in-house team with named editor.** Deployer obligation under Article 50(4) public-interest text provision is narrowed if both human review and a named editorial-responsibility holder are documented; without both elements evidenced, the exception does not apply. ## 8. Relationship to GAISSF, UAIF and AI-IRF This engagement uses GAISSF as the primary framework, UAIF for classification of transparency failures, and AI-IRF for detection and escalation/response guidance where an Article 50 gap is identified during implementation. This guidance document sits downstream of framework-level crosswalk work already completed for this engagement and does not restate that framework mapping. ## 9. Notably Absent This guidance does not contain a compliance scoring method, a certification pathway, or a determination that any specific implementation satisfies Article 50. It does not substitute for legal review of a specific system, and does not constitute an assurance opinion. The scenarios in Section 7 are illustrative only and do not cover every fact pattern an organization may encounter. ## Required limitation > Organization-led implementation guidance, used alongside QCK-EUAI-ART50-001 and QCK-EUAI-ART50-001-WKS. It does not constitute independent assurance, certification, regulatory approval, legal advice or a determination of compliance. ## 10. Methodology Note This guidance is derived from ODA3 Institute's closed Stage 0 evidence baseline and public European Commission materials, including the final Article 50 Guidelines adopted 20 July 2026, the Commission's Article 50 Q&A and the dedicated AI Act enforcement framework. ODA3 Institute holds no proprietary enforcement, complaint or non-compliance dataset for this subject. Copyright © 2026 ODA3 Pvt Ltd. All rights reserved.