EU AI Act Article 50: Transparency Duties in Practice

Article 50 of the EU AI Act is no longer a future requirement. Since 2 August 2026, it has applied to specific AI interactions, system outputs and uses. The practical challenge is not to label everything that involved AI. It is to identify the right trigger, the responsible role and the form of transparency that the law requires.

For organisations buying, building or publishing with AI, this matters because the duties are split. Providers must design certain notices and machine-readable marking into systems. Deployers must inform people in specific operational and publication contexts. A provider-side technical mark does not automatically satisfy a deployer’s human-facing disclosure duty.

Disclosure design also affects interpretation. In Altay and Gilardi's 2024 experiments with US and UK participants, an AI-generated label reduced perceived accuracy of news headlines, including true ones. This does not show that labels reliably identify falsehoods or justify omitting a legally required disclosure. It supports explaining what a label means and keeping provenance distinct from factual verification.

Transparency under the AI Act is role- and trigger-specific

A provider develops an AI system, or has it developed, and places it on the market or puts it into service under its own name or trademark. A deployer uses an AI system under its authority, except in a strictly personal, non-professional activity. One organisation can be a provider for one system and a deployer for another, so role allocation belongs at system and use-case level rather than in a generic corporate policy.

The following matrix is a non-normative Ada Studio navigation aid that summarises the operational split. It is not a substitute for the legal text or the Commission’s guidelines.

The AI Act can also reach organisations outside the EU through the connections in Article 2, including placing systems on the Union market and situations where a third-country provider’s or deployer’s AI output is used in the Union. This does not mean that every Swiss organisation is automatically in scope. The territorial connection, legal role, system and actual use still need to be assessed.

What providers must build into systems

Inform people during direct AI interaction

Under Article 50(1), providers must design and develop systems intended to interact directly with natural persons so that people are informed they are interacting with AI. The information must be clear and distinguishable and arrive no later than the first interaction. A general AI statement hidden in a privacy policy does not meet that timing by itself.

There is an exception where the AI nature is obvious to a reasonably well-informed, observant and circumspect person in the circumstances and context of use. Commission guidance treats this exception restrictively. A robot-shaped avatar may be obvious in one setting; a natural voice, human name or realistic persona may create a very different impression. Providers should record the audience, interface cues, context and evidence behind any obviousness decision instead of relying on intuition.

Mark synthetic outputs in a machine-readable way

Article 50(2) covers providers of systems, including general-purpose AI systems, that generate synthetic audio, image, video or text. Their outputs must be marked in a machine-readable format and be detectable as artificially generated or manipulated. As far as technically feasible, the technical solution must be effective, interoperable, robust and reliable, taking account of content-specific limits, implementation costs and the generally acknowledged state of the art.

This is a system-design duty. In practice, provider teams should retain evidence showing which outputs are covered, where marking is added, whether common processing or export paths preserve it, how detection is tested, what failure conditions are known and how changes in models or media pipelines are controlled.

For deployers procuring generative systems, this creates a concrete vendor-evidence need. Ask what marking method is used, which formats and output channels it covers, how detectability was validated, what transformations remove it and how the provider monitors the state of the art. Ada Studio’s vendor review guidance offers a wider procurement frame; Article 50 turns transparency into one specific evidence lane within it.

What deployers must disclose in operation or publication

Article 50(3) requires deployers of emotion-recognition or biometric-categorisation systems to inform the natural persons exposed to their operation. The notice must reach those people no later than first exposure, and the associated personal-data processing must still comply with applicable data-protection law. A vendor assurance does not replace the deployer’s responsibility at the point of use.

Article 50(4) then addresses two cases in which the artificial origin of content must be disclosed:

• Deepfakes: a deployer using a system to generate or manipulate image, audio or video content that constitutes a deepfake must disclose that the content was artificially generated or manipulated.
• Public-interest text: a deployer publishing AI-generated or manipulated text to inform the public on matters of public interest must disclose the AI involvement unless both conditions are met: (1) the text has undergone a process of human review or editorial control; and (2) a natural or legal person holds editorial responsibility for its publication.

These are human-facing duties. The information and disclosures must be provided to the natural persons concerned in a clear and distinguishable manner, no later than first exposure, and must meet the applicable accessibility requirements. The right treatment depends on the medium: on-screen wording, an audible disclosure, an accessible label or another perceivable method may be needed. The question is whether the person exposed can understand the content’s artificial origin at the required time, not whether a technical metadata field exists somewhere in the file.

Where the exceptions stop

Article 50 contains limits, but they should not become general escape routes:

• Obvious AI interaction is contextual and restrictive; brand familiarity or a policy link is not enough by itself.
• Standard editing and outputs that do not substantially alter the deployer’s input data or its semantics can fall outside Article 50(2). Spell-checking and formatting are different from generating a new argument, image or voice.
• Law-enforcement exceptions always require specific legal authorisation. For the duties in Article 50(1) and (3), appropriate safeguards for the rights and freedoms of third parties are also required; under paragraph 1, the duty still applies where the system is available for the public to report a criminal offence. These are not general public-sector exemptions.
• Evidently artistic, creative, satirical, fictional or analogous deepfake works remain subject to an appropriate disclosure, but the manner must not hamper display or enjoyment of the work.
• Strictly personal, non-professional activity sits outside deployer obligations. Regular commercial, occupational or freelance activity should not be relabelled as personal use merely because one individual operates the tool.

A robust review record should therefore show who examined the substance, what expertise and sources they used, what was challenged or changed, who could approve, reject or rewrite the text, and who accepts editorial responsibility. See Ada Studio’s human-review workflow guidance for the wider operating-model question.

Article 13, Article 50 and Article 53 are different transparency layers

“AI transparency” is not one control with one deadline.

• Article 13, high-risk systems: providers must give deployers instructions and information that make operation sufficiently transparent for appropriate interpretation and use. This includes capabilities and limitations, accuracy and robustness, foreseeable risks, human-oversight measures and relevant logging information. Chapter III Sections 1 to 3 apply from 2 December 2027 to Article 6(2)/Annex III systems and from 2 August 2028 to Article 6(1)/Annex I systems. These dates remain subject to Article 2: Article 13 does not apply to Article 6(1) systems related to products covered by the legislation in Annex I Section B, and delegated limitations may apply to Section A systems. Under Article 111(2), other pre-existing high-risk systems are generally covered only if they undergo significant design changes from the applicable date; pre-existing systems intended for use by public authorities must comply by 2 August 2030.
• Article 50, certain systems and outputs: providers and deployers handle notices, machine-readable marking and human-facing disclosure for the specific triggers described above.
• Article 53, general-purpose AI models: providers of GPAI models maintain model documentation, provide information to downstream system providers, implement an EU copyright-compliance policy and publish a sufficiently detailed training-content summary. Under Article 53(2), the documentation and downstream-information duties do not apply to models released under a free and open-source licence with publicly available parameters, unless the model is a general-purpose AI model with systemic risk. Chapter V has applied since 2 August 2025, but Article 111(3) gives providers of GPAI models placed on the market before that date until 2 August 2027 to comply.

These layers can apply together. A generative feature embedded in a high-risk product may raise provider-to-deployer information duties, public-facing disclosure questions and GPAI supply-chain documentation at different points. GDPR and other information duties also remain separate and require their own scope and legal-basis analysis.

A practical transparency control model

The following is a non-normative Ada Studio implementation aid, not a control model prescribed by Article 50:

1. Inventory the system and use case. Record intended purpose, audiences, media outputs, publication channels and EU connections.
2. Assign legal roles. Identify the provider and deployer for the real configuration, including white-labelling, integration, contracting and publication arrangements.
3. Record triggers and exceptions. Decide which Article 50 paragraph applies, what evidence supports the decision and who approves any exception.
4. Set provider and vendor requirements. Specify interaction notices, machine-readable marking, detectability tests, preservation across transformations, limitations and change notifications.
5. Design human-facing disclosure. Define wording, placement, timing, persistence, accessibility and treatment when content is reshared or separated from its original interface.
6. Retain review and release evidence. Capture substantive editorial review, responsibility, test results, approvals, versions and the final published output.
7. Operate governance and change control. Assign an owner, train relevant staff, monitor failures and complaints, and reassess when systems, models, audiences or channels change.

Seven questions to test readiness

This checklist is a non-normative readiness aid from Ada Studio. It is not a checklist prescribed by the AI Act or the Commission.

The Code of Practice and EU icons are tools, not substitutes for compliance

The Code of Practice on Transparency of AI-generated Content is voluntary; Article 50 is not. The Commission and the AI Board assessed the Code as an adequate route for signatories to demonstrate compliance with the obligations covered by Article 50(2), (4) and (5). The Commission also states that adherence is not conclusive evidence of compliance. Signatories still need to implement the relevant commitments, while organisations using other approaches must be able to demonstrate that their alternative measures are adequately effective.

The EU icons are also optional. They can support consistent human-facing labels for deepfakes and certain public-interest text, but using an icon does not establish compliance by itself. The disclosure still has to match the applicable duty, medium, timing, clarity and accessibility requirements.

Sources and status note

Legal status and guidance pages checked on 26 September 2026:

Legislation and consolidated reference

• Consolidated Regulation (EU) 2024/1689 as at 27 July 2026: Articles 2, 3, 5, 13, 50, 53, 111 and 113: EUR-Lex documentation view of the amended text
• Regulation (EU) 2026/1744: binding amending act (Digital Omnibus on AI); four-month Article 50(2) transition, new Article 5(1)(ba) and (bb) prohibitions from 2 December 2026 and amended high-risk timetable; in force since 27 July 2026
• Directive 2011/93/EU: definitions referred to in Article 5(1)(bb)

Official Commission and AI Board guidance and implementation material

• European Commission: Guidelines on transparency obligations: overview updated 6 August 2026
• European Commission: Article 50 Guidelines: published 20 July 2026 with Communication C(2026) 5054, which approved their content and stated that formal adoption would follow once all language versions are available; non-binding guidance on the Commission’s interpretation
• European Commission: Article 50 questions and answers: explanatory FAQ updated 24 July 2026
• Code of Practice on Transparency of AI-generated Content: voluntary final code and signatory information; updated 31 July 2026
• Commission opinion and AI Board adequacy assessment: official assessment of the voluntary Code against Article 50(2), (4) and (5)
• EU icons for labelling AI-generated content: optional labelling aid; updated 24 September 2026

Ada Studio helps organisations turn AI transparency duties into workable role decisions, technical requirements, review evidence and accessible disclosures. To discuss your Article 50 readiness, get in touch.