Article 50: transparency for limited-risk AI

What Article 50 actually says

Article 50 sits in Chapter IV of the AI Act, titled "Transparency obligations for providers and deployers of certain AI systems." It applies to a broader set of systems than the high-risk obligations in Article 9 or Article 14. Where those articles target Annex III high-risk systems, Article 50 catches chatbots, image generators, deepfake tools, emotion recognition systems, and any AI that interacts directly with a person.

The article breaks down into seven paragraphs, each addressing a different category of system and obligation.

Article 50(1) — AI systems interacting with persons

Providers must design AI systems that interact directly with natural persons so that the persons are informed they are interacting with an AI system. This applies "unless this is obvious from the circumstances and the context of use." The obligation sits with the provider at the design stage: the disclosure mechanism must be built into the system, not bolted on by the deployer afterwards.

There is an exception for AI systems authorised by law for the detection, prevention, investigation, or prosecution of criminal offences, subject to appropriate safeguards for the rights of third parties.

In practice, this means chatbots, conversational agents, voice assistants, and any system where a user might reasonably think they are talking to another person. If your Python application has a chat interface backed by a language model, Article 50(1) applies.

Article 50(2) — synthetic content marking

Providers of AI systems that generate synthetic audio, image, video, or text content must mark those outputs in a machine-readable format so they are detectable as artificially generated or manipulated. The technical marking must be "effective, interoperable, robust and reliable" as far as technically feasible.

This covers text generators, image generators, voice synthesis tools, and video generation systems. The obligation is on the provider, not the deployer. If you build the tool that generates the content, you must mark the output.

The exception here is for AI systems performing an assistive function for standard editing (where the AI does not substantially alter the input), and for systems authorised by law for law enforcement purposes.

Article 50(3) — emotion recognition and biometric categorisation

Deployers of emotion recognition systems or biometric categorisation systems must inform the natural persons exposed to them. They must also comply with Regulation (EU) 2016/679 (GDPR) when processing personal data. Note that certain uses of these systems are outright prohibited under Article 5, particularly emotion recognition in the workplace and in educational institutions.

The exception again covers law enforcement use authorised by law.

Article 50(4) — deepfakes

Deployers of AI systems that generate or manipulate image, audio, or video content constituting a deepfake must disclose that the content has been artificially generated or manipulated. This is the user-facing side of the obligation: where Article 50(2) requires providers to mark content technically, Article 50(4) requires deployers to tell people about it.

There are two exceptions. First, for artistic, satirical, or fictional work, the disclosure must not hamper the display or enjoyment of the work. The obligation still exists, but it can be placed alongside the work (e.g. in credits or metadata) rather than interrupting it. Second, for AI-generated text published for the purpose of informing the public on matters of public interest, disclosure is required unless the content has undergone human editorial review and a natural person or legal entity holds editorial responsibility for it.

Article 50(5) — form of disclosure

All information required under paragraphs 1 to 4 must be provided in a clear and distinguishable manner, at the latest at the time of the first interaction or exposure, and must conform to applicable accessibility requirements. This is a design constraint: the disclosure must be upfront and understandable, not buried in terms of service.

Article 50(6) — relationship to Chapter III

Article 50 is without prejudice to the requirements in Chapter III. If your system is both high-risk and falls under Article 50 (for example, an AI recruitment chatbot that is also classified as high-risk under Annex III), you must comply with both sets of obligations.

Article 50(7) — codes of practice

The AI Office is tasked with facilitating the drawing up of codes of practice at Union level to help implement the detection and labelling obligations. The Code of Practice on AI content marking was published in early June 2026. The Commission may adopt implementing acts to approve these codes or specify common rules if it considers them inadequate.

Who has obligations and when

Article 50 splits obligations between providers and deployers. Understanding which role you fill determines what you must do.

Providers (those who develop or commission the AI system):

• Design AI-to-person interaction systems with built-in disclosure (50(1))
• Mark synthetic content outputs in machine-readable format (50(2))

Deployers (those who put the AI system to use under their authority):

• Inform persons exposed to emotion recognition or biometric categorisation (50(3))
• Disclose deepfake content as artificially generated or manipulated (50(4))

You can be both. If you build a chatbot and deploy it to your own customers, you are both provider and deployer, and both sets of obligations apply. If the AI Act applies to you, work out which role you hold for each system.

How Regula detects transparency obligations

Regula's check command scans your codebase for patterns that indicate limited-risk AI components subject to Article 50. When it finds chatbot frameworks, conversational AI patterns, or content generation code, it flags them as limited-risk.

$ regula check sample_chatbot.py

Regula Scan: sample_chatbot.py
============================================================

  Verdict: LIMITED-RISK
  Your project has limited-risk AI components (Article 50 transparency).
  You must disclose AI usage to users.
  Files scanned:      1
  Limited-risk:       1

  LIMITED-RISK (Article 50):
    [INFO] [ 47] sample_chatbot.py:9 — Chatbots and conversational AI [develop]

The output tells you two things. First, the system has been classified as limited-risk under Article 50. Second, the specific line of code that triggered the detection. The [develop] tag indicates this is a development-phase pattern, meaning you are building the system (provider role).

Regula detects patterns, not compliance. A detection means your code has characteristics that match Article 50 obligations. Whether you have actually satisfied those obligations requires checking that your disclosure mechanisms are in place, clear, and presented at first interaction.

What code scanning covers and what it does not

Regula can detect:

• Chatbot and conversational AI frameworks in your codebase
• Content generation patterns (text, image, audio, video synthesis)
• Emotion recognition and biometric categorisation libraries
• Whether disclosure strings or notification mechanisms exist near the detected patterns

Regula cannot verify:

• Whether the disclosure is actually shown to end users at first interaction
• Whether synthetic content outputs carry machine-readable provenance markers
• Whether the disclosure is "clear and distinguishable" as Article 50(5) requires
• Whether your deepfake disclosure meets the artistic/satirical exception correctly
• Whether your GDPR processing for emotion recognition data is lawful

Code scanning and self-assessment questionnaires are complementary. Regula finds the technical indicators. A legal review determines whether the implementation satisfies the regulation. Neither replaces the other.

Common transparency patterns in code

Article 50(1) compliance at the code level typically looks like a disclosure check at the start of an interaction. Here is a minimal example:

# No transparency disclosure (Article 50 problem)
def handle_message(user_input):
    response = model.generate(user_input)
    return response

# With transparency disclosure (Article 50 pattern)
def handle_message(user_input, session):
    if not session.get("disclosure_shown"):
        send_disclosure("You are interacting with an AI system.")
        session["disclosure_shown"] = True
    response = model.generate(user_input)
    return response

For Article 50(2), synthetic content marking is typically metadata embedded in the output:

# Synthetic image without provenance (Article 50 problem)
def generate_image(prompt):
    image = model.generate(prompt)
    return image

# With machine-readable marking (Article 50 pattern)
def generate_image(prompt):
    image = model.generate(prompt)
    image.metadata["ai_generated"] = True
    image.metadata["generator"] = "model_v2"
    image.metadata["timestamp"] = datetime.utcnow().isoformat()
    return image

These are simplified examples. Production implementations will vary based on your framework, content type, and output format. The point is structural: the disclosure or marking must exist in the code path, not just in documentation.

Transparency versus risk classification

Article 50 transparency obligations are independent of risk tier classification. A chatbot classified as limited-risk under Article 50 can also be classified as high-risk under Annex III if it operates in a regulated domain (recruitment, credit scoring, healthcare services). In that case, both sets of obligations apply simultaneously.

Regula handles this by reporting all applicable classifications. If your codebase contains both high-risk patterns and limited-risk transparency indicators, the scan output will show both.

The practical implication: do not assume that a "limited-risk" classification means lighter obligations. Article 50 obligations are specific and enforceable, with penalties for non-compliance. They are "limited" in the sense that they require transparency rather than the full conformity assessment process of Chapter III, not in the sense that they are optional.

Practical steps

1. Run regula check . to identify which files in your codebase trigger limited-risk (Article 50) classifications.
2. Map each detection to a paragraph. Is it a person-facing interaction (50(1))? Synthetic content generation (50(2))? Emotion recognition (50(3))? Deepfake generation or manipulation (50(4))?
3. Check for disclosure mechanisms. For each flagged pattern, verify that your code includes a disclosure, notification, or marking mechanism in the same execution path.
4. Verify timing. Article 50(5) requires disclosure "at the latest at the time of the first interaction or exposure." A disclosure buried in settings or shown only after several interactions does not meet this.
5. Check machine-readable marking. If you generate synthetic content (50(2)), verify that outputs carry metadata identifying them as AI-generated. Text, images, audio, and video each have different technical standards for provenance marking.
6. Review exceptions. If you believe an exception applies (obvious context, law enforcement, artistic work), document the legal basis. Do not assume an exception applies without analysis.
7. Use regula conform --organisational to generate a structured self-assessment covering Article 50 alongside your other obligations.

Deadline

Article 50 transparency obligations take effect on 2 August 2026, per Article 113 of Regulation (EU) 2024/1689. Unlike the Annex III high-risk obligations, Article 50 was not deferred by the Digital Omnibus (provisional agreement 7 May 2026, approved by European Parliament 16 June 2026 and by the Council 29 June 2026, pending OJ publication). The Omnibus defers Annex III high-risk obligations to 2 December 2027 and Annex I product-embedded AI to 2 August 2028, but transparency obligations under Chapter IV remain on the original timeline.

This means Article 50 is among the earliest substantive obligations to become enforceable, alongside the prohibited practices in Article 5 (which took effect 2 February 2025).

---

Related

• Article 5: prohibited AI practices
• Article 9: risk management system requirements
• Article 14: human oversight for high-risk AI
• EU AI Act risk tiers explained with code examples
• Does the EU AI Act apply to you?
• EU AI Act compliance for Python developers
• EU AI Act requirements for AI in recruitment
• Regula web assessment tool
• About Regula: what it does and does not do

---

Last verified: 25 June 2026 · Author: Kuziva Muzondo · Not legal advice. Regula identifies risk indicators in code for developer review. It does not determine compliance or replace professional legal counsel.