Chatbots and AI agents on websites: what the AI Act requires
A chatbot and AI-agent checklist covering first-interaction disclosure, human escalation, data, logging, testing and operating limits.
AI ACT · CONVERSATIONAL INTERFACES
Chatbot transparency is not solved by a legal page hidden in the footer. From the outset, people should understand that they are speaking with an AI system, what it can do and when a human should take over.
First establish whether interaction is direct
Article 50(1) concerns AI systems designed to interact directly with people. Commission guidance uses four cumulative criteria: it is an AI system, enables a genuine two-way exchange, communicates directly without a human intermediary and interacts with a natural person. Machine-to-machine processes and background functions fall outside this disclosure duty. [EU-REG] [EU-A50] [EU-A50-G]
A form collecting data and returning a fixed response does not become a chatbot because it uses a chat bubble. Conversely, an agent that responds contextually, asks follow-up questions and executes actions may meet the criteria even if called an “assistant”. Assess behaviour, not the interface name. [EU-A50]
Disclosure appears at the start, not afterwards
People must be informed clearly and distinctly from the start of the first interaction, in an accessible manner, unless it is obvious to an average reasonably informed and observant person that they are interacting with AI. The Commission says this exception should be interpreted restrictively. [EU-A50] [EU-A50-G]
Useful wording directly states “AI assistant” and briefly explains its purpose: answering product questions, finding information or preparing a request. Avoid using an avatar, human name and “online” indicator in a way designed to imply that the operator is a person. A details link may supplement, not replace, the initial notice. [EU-A50] [EU-A50-G]
Separate answers, recommendations and actions
An informational chatbot searching a knowledge base has a different profile from an agent that changes an account, places an order or publishes in WordPress. For each function document sources, permissions, consequences of error, required confirmation and reversibility. Autonomy should be limited to what the user understands and authorises. [EU-REG] [EU-NAV]
Actions with financial, legal or hard-to-reverse effects should require explicit confirmation and a pre-execution summary. Do not turn an ambiguous sentence into a command. Keep content in draft and clearly show what will change, where and under whose identity. [EU-LIT] [EU-REG]
Human escalation is part of the product
Define stop conditions: no reliable source, sensitive data, a disputed answer, an emergency, a request outside mandate or repeated error. “Talk to a person” should be easy to find and transfer the necessary context without forcing the user to repeat everything. [EU-LIT] [EU-A50]
Escalation alone does not prove compliance, but it reduces operational risk and misplaced trust. Human staff need to know what the system said, which sources it used and which actions it attempted; otherwise they receive only a long transcript and an already amplified problem. [EU-A50] [EU-REG]
Data and logs need boundaries
State which information is needed and warn users not to enter passwords, payment data, medical information or other sensitive data into a channel not designed for it. The AI Act does not replace the GDPR. Legal basis, minimisation, access, retention and involved vendors require separate assessment. [EU-REG]
Retain logs only for a defined purpose such as security, debugging, approval evidence or controlled improvement. Set access and deletion periods. Article 50 does not impose universal logging on every chatbot, so logging should be proportionate and not a pretext for unlimited collection. [EU-A50] [EU-REG]
Test conversations, not isolated answers
Testing should include normal, ambiguous, adversarial and out-of-scope questions; language changes; data requests; attempts to bypass rules; tool failures; confirmation and cancellation. Measure correct answers, correct refusals, sources, escalation and executed effects, not merely conversational fluency. [EU-LIT] [EU-A50-G]
For CanUHelp APP, a possible local-services assistant should be treated as a hypothetical scenario with visible disclosure, clear limits and support handoff. For a WordPress agent, a prudent pattern keeps changes in draft and requires approval before publishing. These are product patterns, not claims about live features. [EU-A50] [EU-LIT]