Your AI assistant has to say it’s an AI

Someone visits a company’s website, opens the chat and asks about an order. Something kind, fast and self-assured replies. If the answer is right, nobody wonders who wrote it. If it’s wrong, the first question is inevitable: did a person say this, or a machine?

Since 2 August 2026, in the European Union, that question has a mandatory answer. The AI Act requires that whoever is talking to an AI system knows they’re talking to one.

Complying with a one-line notice is easy. But useful transparency isn’t a notice stuck on top: it’s deciding what the AI does, what it doesn’t do and what is calculated outside it. No legal text solves that part. It has to be designed.

What the rule requires and what hasn’t changed

Article 50 of the AI Act requires systems intended to interact with natural persons to be designed so that those people are informed they’re interacting with an AI system, unless it’s obvious. The information has to be given clearly and distinguishably, at the latest at the first interaction.

In July the Digital Omnibus on AI was published, Regulation (EU) 2026/1744 of 8 July 2026. It postponed the obligations for high-risk systems, and many people read the headline as “the AI Act is delayed”. It isn’t: the Article 50 transparency obligations have applied since 2 August 2026.

This isn’t legal advice: if you have doubts about your specific case, consult a specialist. What I can explain is what it means when you design the system.

The notice is the easy part

Putting “You’re talking to an AI assistant” above a chat takes five minutes. The problem is that the notice, on its own, tells the reader nothing useful:

• What can it answer about, and what can’t it?
• Where does what it says come from?
• Which part of the answer did the system calculate, and which part did the model write?
• What data of mine goes to an external provider?

If the system has no answer to those questions, the problem isn’t communication. It’s architecture. And you can see that in three systems I’ve built, each with a different question.

What the AI does and doesn’t do: RetoQ

RetoQ assesses photographs with a vision model and proposes three edits with Lightroom values. It’s AI from start to finish, and nobody doubts it. What’s interesting is how it splits the work:

• The model judges; the server calculates. The final score is the sum of the five criteria times two, and the server calculates it. Arithmetic isn’t entrusted to a model.
• The .xmp file is written by the system. The model proposes; building the preset is deterministic and it’s always valid.
• The product says what it doesn’t do. A mask called “Sky” comes with the right values, but it doesn’t detect the sky: it’s geometric. RetoQ explains this instead of letting the user find out.

That’s transparency too. It isn’t enough to say “this is AI”; you have to say which part is.

What the model can access: AtalayaIQ

AtalayaIQ is an intelligence layer over seven years of a national events company’s operational data. It has an assistant for asking about the day’s report. The question that matters here is a different one: what can that assistant touch?

• The model chooses an operation from a closed catalogue; the server validates the parameters and runs a fixed query.
• The model doesn’t write SQL and never sees credentials or tables outside the catalogue.
• Only the question, the text history and aggregated results go to the provider.

When access is bounded by design, explaining what the assistant does is simple, because there’s a list of what it can do. When a model has free access to everything, nobody can write that list honestly.

What it answers about: Rocio.com

Rocio.com has a public assistant that answers about an editorial archive going back to 1992. Here the question is where each answer comes from.

The decision was that the database is in charge. The index the AI uses is disposable: it’s rebuilt entirely from the database and no provider identifier lives inside the editorial content. The assistant answers about that archive, not about what the model thinks it knows about the world.

And there’s an internal conversation viewer with cost, latency and ratings. Being transparent outwards requires being able to see what happens inside.

Five questions to review your assistant

If your company already has a chat, an assistant or an internal tool with AI, these questions help you tell whether the transparency is real or just a label:

1. Is it disclosed at the first interaction? Not in the footer or the terms of use: where the person starts talking.
2. Can you say in one sentence what it does and what it doesn’t? If you can’t, the scope isn’t defined.
3. What is calculated outside the model? Prices, deadlines, amounts, scores and permissions should come from rules, not generated text.
4. What data does it access, and what goes to the provider? If the answer is “everything”, there’s work to do.
5. Does anyone review what it answers? A conversation log with cost and ratings turns doubt into data.

If all five have an answer, the legal notice is the minor part: the system is already transparent because of how it’s built.

Saying it’s an AI is mandatory. Being able to explain what it does is what builds trust.

For the underlying question (what deserves a model and what doesn’t) I wrote when NOT to use artificial intelligence. AI automation for businesses explains how I design systems that use AI with clear limits, tidy data and the server in charge of what has to be exact. And if what you need is an assistant for your customers or your team, chatbot for businesses explains how I build one that says it’s an AI, cites its sources and hands over to a person when it should.