AI chat under the new EU rules: 9 checks for transparency and privacy

A website AI chat is no longer only about producing a good answer. Visitors need to understand that they are talking to AI, know what happens to their data and have a safe route to a person. The transparency requirements in Article 50 of the EU AI Act have applied since 2 August 2026. GDPR principles — lawfulness, transparency, purpose limitation, data minimisation, storage limitation and security — continue to apply independently of the newer regulation.

This article is an operational checklist, not legal advice. Exact roles and obligations depend on the solution, purpose and data involved. Review sensitive deployments with your data protection officer or legal adviser.

A good AI chat does not pretend to be human, collect data “just in case” or leave a visitor trapped without human help.

What changed in August 2026

European Commission guidance explains that systems designed for genuine two-way interaction with people — including chatbots and AI agents — should inform users that they are interacting with AI unless this is obvious. The AI Act frames this primarily as a provider obligation, while a business or municipality deploying the chat should verify that the disclosure remains visible once the widget is embedded on its own site.

The AI Act does not replace GDPR. If the chat accepts a name, email address, order number, case details or other information linked to a person, purpose, legal basis, notice, access, retention and security need separate attention. Using an external AI model does not automatically make data anonymous; the EDPB stresses that anonymity must be assessed case by case.

Nine checks before launching an AI chat

1. State clearly that AI is answering

Show the disclosure before the first message or at the start of the interaction, not only in terms and conditions. A plain sentence such as “You are chatting with an AI assistant” works. Visually distinguish automated replies from human operator messages.

2. Define the purpose

Website navigation, product advice and order tracking are different purposes. Describe the purpose specifically and do not reuse conversations for an incompatible purpose without another assessment. The controller should be able to explain why every field or item of data is processed.

3. Collect the minimum

A question about opening hours does not need a name or email address. Ask for contact details only when a person needs to follow up. For an order, use only what is necessary for secure matching. Never request passwords, full payment-card data or identity-document copies in an ordinary chat.

4. Warn against sensitive data

A short message next to the input can prevent visitors from sending health records, national identifiers or login credentials. If sensitive data is genuinely necessary, a general website chat is usually the wrong channel; build a separate secured process.

5. Link concise privacy information

Provide an easy-to-find explanation of the controller, purposes, legal bases, data categories, recipients, transfers outside the EU, retention periods and individual rights. The wording should describe the real data flow, not the generic fact that the organisation “uses AI”.

6. Set retention and access rules

Do not keep conversations forever merely because storage is cheap. Set periods for normal chats, open requests and audit records, then delete or anonymise data securely. Access should be limited to people who need it for support, quality or security.

7. Map vendors and transfers

Document where the widget, application, database, analytics and AI model run. Check contractual roles, subprocessors, processing regions and transfer arrangements. “We do not use data for training” can be useful, but it is not a complete record of processing.

8. Offer a person and a safe exit

For a complaint, uncertain identity, sensitive case or repeated failure, offer a live operator or another contact route. Make it clear when a person takes over and carry forward only the context they need.

9. Test failure and abuse cases

Try sending personal data, requesting deletion, inserting a malicious instruction, using another person's order number and triggering human handoff. Check logs, permissions, rate limits, error messages and model outages. Repeat the test after material changes to sources, models or integrations.

Practical example: an order question

A customer asks, “Where is order 1248?” A poor flow reveals status from the order number alone. A better flow discloses AI, requests only the value needed for secure verification, limits the returned details and does not reveal whether an order exists after a mismatch. If verification fails, it offers a human without asking for a password or payment details.

The same principle applies to a municipal website. Finding a form or a waste-collection date does not require a citizen's identity. A question about an individual proceeding should move to an authorised channel rather than collecting the whole case file in an anonymous chat window.

A 15-minute review

• Is it clear before the first message that this is AI?
• Does the visitor know the purpose and what not to enter?
• Are mandatory fields genuinely necessary?
• Is privacy information one short step away?
• Does each conversation category have a retention period?
• Can you name every processor and processing region?
• Does human handoff work during an AI outage?
• Can you handle access, correction and deletion requests?
• Do you have a record of the latest security and content test?

Informio lets organisations build an AI assistant on controlled sources, restrict allowed domains, limit abuse and hand a conversation to a live operator in the same widget. Those technical controls still need to be paired with your own purpose, retention rules and processing information.

Want to review an AI chat design for your business or municipality? Contact Informio.

Sources

• European Commission — Article 50 transparency guidelines
• European Commission — Article 50 questions and answers
• European Commission — GDPR principles
• EDPB — opinion on AI models and GDPR