"Hi, I'm Acme's virtual assistant." Eleven words. One line. The hardest sentence to ship in a multinational customer-service operation in May 2026. Article 50(1) of the EU AI Act says providers of AI systems intended to interact directly with natural persons must inform those persons they are interacting with an AI system, in a clear and distinguishable manner, at the latest at the time of the first interaction. That clause looks like a one-paragraph compliance task. In practice, it is a multi-channel rollout (web, mobile, voice, in-store kiosk), a multi-language coverage matrix (every Member State language where the service is offered in that language), a defensible carve-out memo (when "obvious from the circumstances" really applies), and a refresh-cadence calendar (because voice synthesis quality moves faster than legal text). This lesson is the L2 Chapter 4 Lesson 1 playbook: the per-channel disclosure copy, the obviousness-carve-out rationale, the multi-language coverage matrix, and the refresh cadence you can hand to a legal-and-product working group on Monday morning.

Article 50(1) - The Text and What It Actually Requires

The operative sentence in Article 50(1) reads: "Providers shall ensure that AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system, unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect, taking into account the circumstances and the context of use. This obligation shall not apply to AI systems authorised by law to detect, prevent, investigate or prosecute criminal offences, subject to appropriate safeguards for the rights and freedoms of third parties, unless those systems are available for the public to report a criminal offence."

Article 50(1) imposes the obligation on the provider (the entity that develops the AI system or has it developed and places it on the market under its own name), not exclusively on the deployer. The deployer side has overlap with Article 26 and with Article 50(3) for emotion-recognition systems, but the chatbot-disclosure design obligation sits with the provider. A bank that buys a customer-service chatbot from a vendor sees the provider obligation flow through procurement contracts (the vendor designs the disclosure capability into the system; the bank as deployer configures and delivers it).

The clause about "clear and distinguishable manner" is the operational floor. A disclosure buried in the terms-and-conditions modal at sign-up does not satisfy "clear and distinguishable." A disclosure in 4-point grey text below the chat window does not satisfy "clear and distinguishable." A disclosure delivered three messages into the conversation does not satisfy "at the latest at the time of the first interaction." The Commission's draft Article 50 guidelines (published early 2026, finalized expected H2 2026) elaborate that "clear" means understandable to the average natural person, not a legal-text formulation, and "distinguishable" means visually or audibly distinct from the surrounding interface.

The clause "at the latest at the time of the first interaction" is the timing floor. The disclosure can be earlier (e.g., a launcher banner before the chat opens), but it must be at the latest at the first substantive exchange. The provider does not have to repeat the disclosure on every message, but the affected person must encounter it at the entry point and have a reasonable means to recall it (e.g., persistent "AI assistant" icon in the chat header).

The "Obvious From Circumstances" Carve-Out - Narrower Than Vendors Argue

The carve-out is the most-litigated clause in Article 50(1). It applies where the AI interaction is "obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect, taking into account the circumstances and the context of use." Vendors regularly argue the carve-out applies to their deployment. Regulators and consumer-advocacy groups regularly argue it does not. The defensible operational position in 2026 is: default to disclosure unless the context is irrefutably obvious to a reasonable user.

Three reference scenarios mark out where the carve-out lives:

• Voice agent answering a customer-service line (carve-out FAILS). Voice synthesis quality in 2026 (ElevenLabs, OpenAI Realtime API, Google Cloud Text-to-Speech, Amazon Polly Generative) is such that the average caller cannot reliably distinguish a synthetic voice from a human one. The "obvious from circumstances" carve-out does not apply. Verbal disclosure at call start is required. This is the lesson's highest-priority operational scenario because voice deployments are scaling fastest and the disclosure design is the easiest to overlook.
• Web-form auto-complete suggesting answers (carve-out BORDERLINE). The user is typing into a form field; the AI suggests completions. The interaction is light; the AI assistance is contextual. The carve-out is arguable but not safe. Defensible practice is a small inline "AI suggestion" badge near the field plus an aria-label for screen readers, minimum-friction disclosure rather than a chat-window-style banner.
• Developer IDE plug-in for code completion (carve-out arguably PASSES). The user is a developer using a known IDE plug-in branded as AI (GitHub Copilot, Cursor, Codeium, Tabnine, Amazon Q Developer). The context unambiguously signals AI interaction. The carve-out is defensible. Operational best practice still includes a visible "AI-powered" badge in the IDE chrome, the carve-out invocation is documented in the deployment record, but the badge satisfies any residual concern at near-zero cost.

The carve-out invocation requires documentation. The obviousness-carve-out rationale memo records the deployment scenario, the rationale for non-disclosure, the legal review, the refresh trigger conditions (e.g., user-experience changes that may break obviousness, regulatory developments narrowing the carve-out). The memo is retained for regulator inquiry. A program that invokes the carve-out across multiple deployments without a memo for each is unprepared for the first regulator question.

The Law-Enforcement Exception - Narrow and Conditioned

Article 50(1) carves out AI systems "authorised by law to detect, prevent, investigate or prosecute criminal offences, subject to appropriate safeguards for the rights and freedoms of third parties, unless those systems are available for the public to report a criminal offence." The exception is narrow on three dimensions:

• Authorised by law. The deployment must be on the basis of a legal authorisation (an EU regulation, a national law, or a court order with statutory backing). A general "we're a law-enforcement agency" claim does not satisfy "authorised by law." The legal basis must be specific to the AI use.
• Criminal-offence purpose. The purpose must be detection, prevention, investigation, or prosecution of criminal offences. Civil enforcement, administrative enforcement, intelligence-gathering for non-criminal purposes, or general policing functions outside criminal-offence handling do not qualify.
• Appropriate safeguards. The deployer must have safeguards in place for the rights and freedoms of third parties. The CJEU and the European Data Protection Supervisor have a substantial body of case law on what "appropriate safeguards" means for law-enforcement processing under the LED (Law Enforcement Directive 2016/680); the Article 50(1) safeguards expectation borrows from that framework.
• Public-reporting exclusion. The exception does not apply where the AI system is available for the public to report a criminal offence, e.g., a public-facing crime-tip chatbot is subject to Article 50(1) disclosure even if operated by a law-enforcement authority.

For a commercial enterprise, the law-enforcement exception will rarely apply directly. The relevance is in adjacent scenarios: fraud-detection chatbots in financial services (not law enforcement; full Article 50(1) disclosure applies); customer-service chatbots used for KYC handling (full disclosure; the KYC angle does not trigger law-enforcement exception); abuse-reporting chatbots on social platforms (where the platform helps users report abuse to the platform itself, not to police, full disclosure).

Disclosure Design Principles - Six Rules That Hold Up Under Audit

The audit-defensible disclosure design rests on six principles. Each one maps to a specific failure pattern that auditors and regulators check first.

• Clear language, not legal text. The disclosure should be in plain language understandable to the average user, not a legal formulation buried in jargon. "I'm Acme's AI assistant" satisfies clarity. "This service may incorporate algorithmic processing technology subject to the European Union's Artificial Intelligence Regulation" does not. The Commission's draft guidelines reinforce that the disclosure does not require explaining how the AI works, which model is used, or which provider built it. Those are documentation choices, not legal requirements under Article 50(1).
• Distinguishable, not blended. The disclosure must be visually or audibly distinct from the surrounding interface. A banner above the chat window distinguished by colour and weight satisfies "distinguishable." A grey line of small text in a footer does not. For voice channels, the disclosure should be spoken clearly at normal volume, not at the tail of a long greeting where it can be missed.
• First interaction, not deferred. The disclosure must be at the latest at the first substantive exchange. The provider can disclose earlier (e.g., before the chat opens) but cannot defer to later. Common failures: disclosure on a "consent to use cookies" modal that pre-dates the chat (acceptable only if it explicitly identifies the AI assistant in clear language); disclosure in the email confirming the chat transcript after the session ends (fails, too late); disclosure in the terms-of-service the user accepted at account creation months ago (fails, not at first interaction with the chat).
• Available in the user's language where the service is offered in that language. A French-language customer-service interface requires French-language disclosure. The Commission's draft guidelines confirm the disclosure should match the language of the service. For multi-language deployments, the disclosure copy needs translation by qualified translators with legal-review fitness, not machine-translated without review.
• Multi-channel consistency. A customer can encounter the same AI assistant on the web chatbot, the mobile app, the voice IVR, and an in-store kiosk. Each channel needs its own disclosure adapted to the channel format. The disclosure copy should be consistent in spirit ("I'm Acme's AI assistant" or "Hi, I'm Acme's virtual assistant") across channels even when the format differs (visual banner on web; spoken greeting on voice; signage at the kiosk plus on-screen disclosure on first interaction).
• Recoverable, not one-shot. The first-interaction disclosure does not have to repeat on every message, but the affected person should be able to recall it, e.g., a persistent "AI assistant" badge in the chat header, an "AI" icon next to assistant messages, or an explicit "you're chatting with an AI" reminder if the conversation transitions to a sensitive topic.

Worked Examples - Actual Disclosure Language By Channel

The L2 Chapter 4 Lesson 1 playbook commits to a per-channel disclosure copy that you can adapt with brand wording. Each example is sized for the channel format and tested against the six design principles.

Example 1 - Customer-Service Web Chatbot

The web channel is the canonical Article 50(1) deployment. The chatbot launcher opens; the first message is from the assistant; the disclosure rides in the first message.

"I'm Acme's AI assistant. I can answer billing questions, help you manage your account, and connect you with a human agent at any time. How can I help today?"

Design notes. First sentence identifies the AI nature directly. Second sentence sets capability scope and a clear escalation path to a human. Third sentence opens the engagement. The chatbot launcher icon includes an "AI" badge. The chat header includes a persistent "AI assistant" label and a one-click escalation button.

Example 2 - Customer-Service Voice Agent (IVR or Outbound Call)

The voice channel is the highest-priority Article 50(1) operational scenario. Voice synthesis quality in 2026 means the carve-out fails by default; the disclosure is verbal at the start of the call.

"Hi, I'm Acme's virtual assistant. I can help with account questions, billing, or connect you with a human agent. How can I help you today?"

Design notes. The disclosure is the first thing the caller hears after the standard greeting. The phrase "virtual assistant" is more natural in voice than "AI assistant" and satisfies clarity. The escalation path to a human agent is explicit and is operationally backed (the caller can say "human" or "agent" at any point). For outbound calls (where the caller did not initiate the contact), the disclosure should also identify the caller as Acme: "Hi, this is Acme. I'm a virtual assistant calling about your recent service request. Is now a good time?"

Example 3 - Mobile In-App Assistant

The mobile channel typically combines a first-launch banner (when the user first taps the assistant icon) with an in-conversation indicator.

First-launch banner: "Welcome to Acme's AI assistant. I can help with billing, account questions, and connect you with a human agent anytime. Tap to start."

In-conversation: persistent "AI" badge in the chat header; assistant message bubbles include a small "AI" icon; a footer link "Talk to a human" is always visible.

Design notes. The first-launch banner serves the "at first interaction" requirement; the in-conversation indicators serve the "recoverable" principle. Mobile screen real-estate is tight, so the disclosure copy is terser than the web version. The escalation path is one tap away.

Example 4 - In-Store Kiosk

The in-store kiosk combines physical signage at the approach with on-screen disclosure at the first interaction.

Approach signage: "AI Assistant Kiosk - Powered by Acme. Get help with returns, store information, and account questions."

On-screen first interaction: "I'm Acme's AI assistant. Tap a topic below to get started, or tap 'Get a Person' to find a store associate."

Design notes. The physical signage satisfies "before the interaction" for users who notice it on approach; the on-screen disclosure satisfies the "at latest first interaction" for users who do not. The "Get a Person" button is the escalation path. The signage and on-screen disclosure are localised to the local language for the store location.

Example 5 - Developer IDE Plug-In (Carve-Out Invocation)

The developer-IDE scenario is one of the few defensible obviousness carve-out invocations. The plug-in is branded as AI; the user is a developer who installed the plug-in knowing it is AI-powered; the context is irrefutably obvious to the user.

Carve-out invocation: documented in the deployment record. The rationale memo cites the user persona (developer), the plug-in branding (named as AI tool, e.g., "Acme AI Code Assistant"), the installation context (the user opted in by installing the plug-in), and the IDE chrome (the plug-in icon is visible at all times).

Visible badge (still recommended even with carve-out): the plug-in chrome includes an "AI-powered" badge near the suggestion area; assistant messages in any inline chat are prefixed with an AI icon. The badge is cheap insurance against the carve-out being narrowed in future Commission guidance.

Multi-Language Coverage Matrix - The Most-Overlooked Operational Step

A SaaS chatbot rolled out across multiple Member States needs disclosure in each language where the service is offered in that language. The multi-language coverage matrix is the per-language tracking artifact that turns this from "we'll translate eventually" into an operational deliverable.

Matrix columns: language code (e.g., en, fr, de, es, it, nl, pl, sv, da, fi, pt, ro, cs, hu, sk, sl, bg, hr, et, lv, lt, el, mt, ga); service-availability status (offered in this language: yes/no); disclosure-copy status (translated: yes/no, by whom, on what date); legal-review status (reviewed by local-language counsel: yes/no, by whom, on what date); refresh date; channel coverage (web, mobile, voice, kiosk) per language.

Common failure: a SaaS deployment offers customer support in 8 EU languages but ships disclosure copy in only English and French. The 6 missing languages are an Article 50(1) failure for users in those Member States. The matrix surfaces the gap before the audit does.

Translation quality matters. Machine-translated disclosure copy without human review is a legal-and-product risk: subtle phrasing issues (e.g., the translated word for "assistant" carrying gendered or hierarchical connotations in some languages) can undermine clarity. The defensible practice is qualified human translation followed by local-language legal review for any high-risk deployment (financial services, healthcare, employment, education).

Integration With Adjacent Regulatory Overlays

Article 50(1) is the AI-Act-specific floor. It almost always operates alongside other regulatory overlays that may require additional information.

• GDPR Article 13/14 transparency notices. GDPR transparency typically requires more detailed information than Article 50(1): the purposes of processing, the legal basis, the recipients of personal data, the retention period, the data-subject rights, the DPO contact. The Article 50(1) disclosure is the AI-specific minimum; the GDPR notice is the data-protection overlay. The two are typically delivered separately: the Article 50(1) disclosure is in the chat opening; the GDPR notice is in the privacy policy linked from the chat or surfaced when the user first inputs personal data.
• Consumer-protection law (EU Consumer Rights Directive; FTC Section 5 in the U.S.). The EU Consumer Rights Directive and national consumer-protection law may add requirements on commercial communications, dark patterns, and misleading representations. The FTC's enforcement focus on AI misrepresentation (under Section 5 unfair-or-deceptive-acts authority) sets U.S. expectations even though Article 50(1) is an EU provision. A multinational deployment should integrate Article 50(1) with consumer-protection considerations in each operating jurisdiction.
• Sector-specific overlays. Regulated industries (banking, insurance, healthcare, telecommunications) have sector-specific customer-communication standards. A bank's customer-service chatbot disclosure should satisfy Article 50(1) and the banking-regulator expectations on customer communications (e.g., CFPB UDAAP in the U.S.; EBA / national-supervisor guidance in the EU). A healthcare chatbot disclosure should satisfy Article 50(1) and any medical-information-disclosure requirements (e.g., HIPAA business-associate communications in the U.S.; national health-data protections in the EU).
• Article 50(3) and 50(4) stacking. A customer-service voice agent that infers caller mood triggers Article 50(3) emotion-recognition notice on top of Article 50(1) chatbot disclosure. A chatbot that generates synthetic content triggers Article 50(2) machine-readable marking. A chatbot that produces deepfake-style audio responses triggers Article 50(4). Each sub-article is a separate obligation; Article 50(1) does not absorb the others.
• High-risk classification stacking. Article 50(1) stacks on top of any high-risk classification. A chatbot used in Annex III §3 education contexts (e.g., a student-facing tutoring chatbot) carries Annex III high-risk obligations plus Article 50(1) chatbot disclosure plus Article 4 AI literacy plus GDPR Article 13/14 transparency.

Refresh Cadence - Why The Disclosure Is Not Static

Article 50(1) disclosure is not a one-time deliverable. The refresh cadence calendar records the triggers that prompt a disclosure review. The triggers fall into four categories:

• User-experience changes that may break obviousness. A voice agent upgraded to a new TTS model with higher naturalness; a chatbot moved to a new launcher format; a mobile assistant integrated into a system-level surface (e.g., the OS-level assistant) where the AI nature is less explicit. Any UX change that affects how the disclosure is encountered or how the AI nature is perceived triggers a review.
• Language additions. A new Member State language added to the service offering triggers a translation, legal review, and matrix update.
• Regulatory developments. Finalisation of the Commission's Article 50 guidelines (expected H2 2026); national-implementing-rules developments under Article 99(7); CJEU or EDPB guidance that affects disclosure design; consumer-protection-authority enforcement actions that narrow the obviousness carve-out. Each regulatory development is a refresh trigger.
• Audit and post-incident review. An ISO 42001 surveillance audit finding; an internal-audit finding; a customer complaint that surfaces a disclosure issue; a regulator inquiry that surfaces a disclosure gap. Each finding feeds the refresh cycle.

The refresh cadence is typically annual baseline plus triggered updates. The annual review covers all channels and languages; the triggered updates are surgical. The artifact retained for audit: the refresh log with date, trigger, scope, reviewer, sign-off.

Six Common Article 50(1) Mistakes

Mistake 1 - Burying the Disclosure in Terms and Conditions

A disclosure in the terms-and-conditions modal at account creation does not satisfy "clear and distinguishable" or "at first interaction with the chat." Even if the user accepted T&Cs that mention the chatbot is AI, the chat itself must surface the disclosure at first interaction. The T&Cs are a documentation artifact; the chat disclosure is the legal compliance artifact.

Mistake 2 - Using Ambiguous Language Like "Powered by AI"

"Powered by AI" or "Smart assistant" is ambiguous. The user reasonably might read these as marketing claims rather than disclosure of AI interaction. The defensible phrasings are explicit: "AI assistant," "virtual assistant," "automated assistant," "I'm an AI." The phrasing is short and direct.

Mistake 3 - Skipping the Voice Channel

Voice deployments are the fastest-growing customer-service channel in 2026 and the highest-risk for Article 50(1) failure. The "obvious from circumstances" carve-out fails for voice agents with realistic synthesis quality. A program that has shipped disclosure on web and mobile but not voice is six months behind. The verbal disclosure at call start is the operational floor.

Mistake 4 - Missing Multi-Language Coverage

A SaaS deployment offers support in multiple Member State languages but ships disclosure copy in only English (or English plus one or two other languages). The missing languages are Article 50(1) failures for users in those Member States. The multi-language coverage matrix is the surfacing artifact; without it, the gap stays invisible until the regulator surfaces it.

Mistake 5 - Over-Relying on the Obviousness Carve-Out

The carve-out is narrow. Vendors regularly argue it applies to their deployment; regulators regularly disagree. Default to disclosure unless the context is irrefutably obvious. Where the carve-out is invoked, document the rationale memo with legal sign-off and refresh-trigger conditions. A program that invokes the carve-out across multiple deployments without rationale memos for each is unprepared for the first regulator question.

Mistake 6 - Static Disclosure Without Refresh

Article 50(1) disclosure is not a one-time deliverable. UX changes, language additions, regulatory developments, and audit findings all trigger refresh. A disclosure shipped in 2024 and unchanged in 2026 is likely to be out of step with current TTS quality (which may have broken obviousness for a voice deployment that previously relied on the carve-out), out of step with Commission guidance, or out of step with new Member State language additions.

L2 Chapter 4 Lesson 1 Artifact Bundle

The L2.Ch4.L1 artifact you ship at the end of this lesson is a four-part bundle:

• Per-channel disclosure copy. Web, mobile, voice, in-store kiosk, developer IDE, with brand wording adapted for your organization. Each entry includes the copy, the rationale, the design notes, and the channel-specific implementation details.
• Obviousness-carve-out rationale memo. For each deployment where the carve-out is invoked, the rationale memo with deployment scenario, user persona, context analysis, legal sign-off, refresh-trigger conditions, and retention policy.
• Multi-language coverage matrix. Per-language tracking with service-availability status, disclosure-copy status, legal-review status, refresh date, channel coverage. Includes a gap list for any language with service availability but missing disclosure.
• Refresh cadence calendar. Annual baseline review plus triggered updates with the four trigger categories (UX changes, language additions, regulatory developments, audit and post-incident review). Includes the refresh log retention policy.

The bundle integrates with the broader L2 governance program: the per-channel copy feeds the procurement contracts for any vendor-supplied chatbot capability; the carve-out memo feeds the deployment record for each system; the multi-language matrix feeds the AI inventory tier-4-notice tracking; the refresh cadence feeds the management-review calendar.

Key Takeaways

• Article 50(1) requires AI-interaction disclosure in a clear and distinguishable manner, at the latest at the time of the first interaction. The obligation sits with the provider; deployer-side overlap exists with Article 26.
• The "obvious from circumstances" carve-out is narrower than vendors argue. Default to disclosure unless the context is irrefutably obvious to a reasonable user. Voice agents with realistic synthesis quality fail obviousness in 2026; developer-IDE plug-ins arguably pass.
• The law-enforcement exception is narrow. Requires authorisation by law, criminal-offence purpose, appropriate safeguards, and excludes public-reporting AI systems.
• Six design principles hold up under audit. Clear language; distinguishable formatting; first-interaction timing; user's language; multi-channel consistency; recoverable not one-shot.
• Worked examples by channel. Web chatbot ("I'm Acme's AI assistant…"); voice agent ("Hi, I'm Acme's virtual assistant…"); mobile in-app (first-launch banner plus in-conversation icon); in-store kiosk (signage plus on-screen); developer IDE (carve-out invocation plus visible "AI-powered" badge).
• The multi-language coverage matrix is the most-overlooked operational step. Each Member State language where the service is offered requires translated and legally-reviewed disclosure copy. The matrix surfaces gaps.
• Article 50(1) integrates with adjacent overlays. GDPR Article 13/14 transparency (more detailed); EU Consumer Rights Directive / FTC Section 5 in U.S.; sector-specific overlays (banking, healthcare); Article 50(3)/(4) sub-article stacking; high-risk classification stacking.
• Refresh cadence is annual baseline plus triggered updates. Triggers include UX changes that may break obviousness; language additions; regulatory developments; audit and post-incident review.
• Six common mistakes. Burying disclosure in T&Cs; ambiguous language ("powered by AI"); skipping voice channel; missing multi-language coverage; over-relying on obviousness carve-out; static disclosure without refresh.
• L2 artifact bundle. Per-channel disclosure copy + obviousness-carve-out rationale memo + multi-language coverage matrix + refresh cadence calendar. Integrates with procurement, deployment records, AI inventory, and management-review calendar.