EU AI Act Article 50 in Practice: How Do You Tell Users They Are Talking to AI?

Under Article 50(1) of Regulation (EU) 2024/1689, providers of systems intended to interact directly with people must ensure that people know they are interacting with AI. For a company preparing a chatbot, this raises a specific issue to resolve with the supplier: where users will receive this information and at what point.

A company that provides a system should not be confused with one that deploys it. Article 50 distinguishes between providers and deployers and assigns them different obligations. We recommend determining which role applies to your case with a lawyer, based on the specific service arrangement.

From a product perspective, we recommend starting with the screen where the conversation begins. Users should recognise the nature of the assistant before they start relying on its answers. The service name, visual design and notice should not contradict one another.

This article describes interface recommendations and selected transparency obligations. It is not a legal assessment of a specific application. For your own deployment, we also recommend reviewing with a lawyer the transparency guidelines issued by the European Commission in July 2026.

Under Article 50(5), the information must be provided in a clear and distinguishable manner no later than the first interaction or exposure. It must also meet applicable accessibility requirements. We therefore do not recommend using a link hidden in the footer as the only place where users learn who they are communicating with.

For a chat, we recommend combining the following elements. This is an interface proposal, not a set of elements prescribed by law:

• Introductory notice: clearly states at the start of the conversation that the answers come from AI.
• Persistent label: reminds users of the assistant's nature in the header, even after the introductory message has scrolled out of view.
• Link to details: leads to an explanation of the AI's role, its limitations and human involvement.

We recommend keeping the wording short and specific. The word “assistant” alone leaves room for different interpretations; “AI assistant” communicates the essential information directly. If you add a claim about human review, it must match how the service actually works.

For the planned chat on the Iterus website, we have approved this wording:

You are talking to Iterus's AI assistant. A human reviews everything before it becomes an offer.

The chat on our website has not launched yet. We are therefore presenting the prepared wording, not an example of a live feature.

When reviewing the design, we also recommend checking the mobile view and use with a screen reader. The notice must not depend on colour alone or on an unobtrusive icon. Accessibility requirements must be assessed for the specific interface; the mere presence of text does not replace that assessment.

Article 50(1) contains an exception for situations where it is obvious to a reasonably well-informed, observant and circumspect person, taking into account the circumstances and context of use, that they are interacting with AI. This is a much more specific standard than the product author's belief that “everyone can tell.”

We therefore recommend not treating the exception as the default design approach. A robot icon, an unusual name or the speed of the answers are not, by themselves, proof that the user understands the nature of the system. Whether a specific interface falls within the exception is a question for legal assessment.

A useful design check is to ask someone unfamiliar with the application to describe who they think is answering them. If they expect a customer support employee, the wording and visual design need adjustment. This kind of test helps identify ambiguity, but it does not demonstrate legal compliance.

We also recommend paying attention to the different ways users can enter the service. A user may open the assistant from an order detail, a link in an email or another part of the application. The design should not assume that they have already read the homepage and the explanation of how the product works.

A notice in a chat and the labelling of published content are different situations. Under Article 50(4), deployers must disclose that deepfake content has been artificially generated or manipulated. For text, the purpose for which it is published also matters.

The same paragraph applies to text published to inform the public about matters of public interest. Such text must be identified as artificially generated unless it has undergone human review or editorial control and someone bears editorial responsibility for it. This wording cannot be turned into a general rule that every text created with AI assistance requires the same notice.

Before publication, we therefore recommend describing the purpose of the content, how it was reviewed and who assumes editorial responsibility for it. Simply reading a draft without clear responsibility is not the same as the stated exception. We recommend confirming the exception's application to specific content with a lawyer.

Machine-readable marking under Article 50(2) is a separate issue. Under the political agreement on the “Digital Omnibus” reported in May 2026, providers of generative systems placed on the market before 2 August 2026 have a transition period until 2 December 2026. This point concerns machine-readable marking; it is not a reason to delay the user notice in a chat interface.

Our own product Innea has an EU AI Act transparency layer in production. Innea is our Czech AI support between therapy sessions. We cite it as our own product, which shows how transparency can be handled.

The transparency layer is a specific part of the application. Its existence is neither a certification nor a declaration that the entire product fully complies with every obligation.

The following statement summarises how we work:

We work AI-native: delivery is accelerated with Claude Code and Codex, and quality is secured by automated tests, independent code review and specialists on demand.

For companies choosing a supplier, we recommend asking to see the actual start of the conversation. Check the notice wording, whether it remains available during the conversation and whether the promised human review matches how the application works. A general statement about transparency in a proposal does not answer these questions on its own.

We offer connections between a model and company data, answer-quality controls and a transparency layer as part of our AI integrations. For a specific proposal, it helps to bring an example of the intended conversation and a description of what the user will do with the answer afterwards.

1. Do we need a confirmation checkbox before users enter the chat?

   The stated rules in Article 50 do not impose a general requirement for a confirmation checkbox. The requirement is to inform users in a clear, distinguishable and accessible manner. Ask a lawyer to assess any separate reasons for obtaining consent.

2. What if a human operator joins the conversation?

   We recommend marking the change explicitly within the conversation. Users should be able to tell who is currently answering, including when they return to the conversation history later.

3. Is the notice supplied by the chat-tool provider enough?

   We recommend checking how it appears in your actual application and whether visual customisation or a different entry point hides it. The mere existence of text in the tool's settings does not show what users will actually see. Ask a lawyer to assess how obligations are divided between you and the provider for the specific deployment.

4. Does a correctly written notice guarantee reliable AI answers?

   No. The notice explains the nature of the system, not the accuracy of its answers. Answer-quality controls and the definition of the AI's role must be addressed separately. Clear wording in the chat header also does not demonstrate the application's overall legal compliance.