Gabriel EspinheiraFounder · senior software engineer
The EU AI Act’s chatbot transparency rule now applies. If an AI system talks directly to people, the person should know it is AI from the start of the first interaction.
For a business owner, that makes the disclosure line the first check, not the whole audit. A visible “AI assistant” label can sit above a system that invents answers, hides uncertainty, sends people into a dead end and has nobody reviewing what goes wrong.
TL;DR: Check five things in every website chatbot: the AI identity is visible from the first interaction; answers stay inside approved knowledge; uncertainty produces an honest fallback; conversations can be reviewed; and one named owner controls changes. SharpOS Support builds these operating choices around the label rather than treating it as compliance theatre.
What changed for website chatbots on 2 August 2026?
Article 50 of the EU AI Act applies from 2 August 2026. The European Commission’s guidance says providers of AI systems that directly interact with people, including chatbots and AI agents, must design them so people are informed they are interacting with AI unless that fact is obvious.
The notice should appear from the start of the first interaction, be clear and distinguishable, and follow accessibility requirements. The Commission also says the “obvious” exception should be interpreted restrictively because it removes transparency from the person using the system (European Commission Article 50 FAQ).
There is an important role distinction. The legal duty in Article 50(1) is framed around the provider of the AI system. A provider develops the system, has it developed, or puts it into service under its own name or trademark. A business using another company’s system under its authority may instead be a deployer. The facts of the implementation decide the role, so this article is an operational audit, not legal advice.
That distinction does not make the customer experience someone else’s problem. The visitor is on your website, asking about your offer and deciding whether to trust your answer. Even when a vendor carries the provider duty, the business owner still needs to verify that the disclosure actually appears, the assistant behaves honestly and failures reach a useful next step.
Is an “AI assistant” label enough?
No. It addresses identity, but not the quality of the interaction.
Use these five checks together.
1. Identity is visible before the first answer
Open the widget as a new visitor. Do not rely on the assistant introducing itself after the person has already typed a question.
The interface should identify the system as AI in a place that does not disappear when the welcome message changes. Test it on a small phone, at 200% zoom, with keyboard navigation and with a screen reader. A muted label below the fold is technically present and practically hidden.
2. Answers stay inside approved knowledge
Disclosure does not excuse invention.
The useful test is not whether the chatbot sounds fluent. It is whether it recognises the edge of its evidence. A confident answer about an unavailable service is worse than a short admission that the information is missing.
Knowledge also expires. Assign an owner to every source, record when it changed and remove obsolete claims. Otherwise the assistant can repeat an answer that was once approved and is now wrong.
3. Uncertainty produces an honest fallback
Many chatbot flows use “human handoff” as a reassuring phrase when no person is waiting.
Test what happens when the assistant cannot answer. Does it invent a likely response? Promise that “someone will be with you shortly”? Create a ticket nobody owns? Or does it say that it lacks a confident answer and point to a real contact route?
An honest fallback can be simple:
- name the limit;
- provide the correct email, phone or WhatsApp route;
- say what the visitor should include;
- avoid promising a response time the business has not operationally guaranteed.
AI-only support is not inherently dishonest. Pretending an unattended queue is live human support is.
4. Conversations can be reviewed
If nobody reads the conversations, the business will not know which questions the website failed to answer.
Review should cover more than sentiment or message count. Sample unanswered questions, low-confidence replies, repeated objections and suggestions from visitors. Separate a knowledge gap from a product gap: sometimes the assistant needs a better source; sometimes the offer itself is unclear.
The useful output is a change queue. Update a support answer, rewrite a service page, clarify a price, fix a broken contact route or decide that a requested capability is outside the offer.
5. One person owns the system
Ask five operational questions:
- Who can change the assistant’s instructions?
- Who approves knowledge sources?
- Who reviews failures and suggestions?
- Who checks the contact fallback?
- Who can disable the assistant during an incident?
If every answer is “the vendor”, the business is exposed. If every answer is “the founder”, the process will eventually stall. Name an accountable owner and a backup, then make the review cadence proportionate to volume and risk.
How should the fallback work when the chatbot does not know?
Start by rejecting a false binary. The choice is not “perfect AI” or “24-hour human team”. Most owner-operated businesses have neither.
The better pattern is bounded automation with a truthful exit.
For common, well-documented questions, the assistant can answer immediately in the visitor’s language. For anything outside the approved knowledge, it should stop, state the limitation and direct the person to a contact channel the business actually monitors.
Test that exit like a form: confirm the address or number is current, the destination works on mobile, the visitor knows what happens next and the business can see how often the fallback appears.
This is where support becomes part of the website’s conversion system. A chatbot that handles routine questions but loses every complex enquiry may reduce visible workload while quietly losing the most valuable conversations.
Who should review conversations and change the knowledge?
Keep the loop small.
For a lower-volume service business, a weekly review is often enough. Pull the questions that produced no useful answer, group them by theme and make one of four decisions:
- add or update approved knowledge;
- improve the relevant website page;
- change the fallback route;
- decline to answer because the question is outside scope or too sensitive.
Measure useful signals: answer coverage, fallback frequency, recurring question themes, contact-route clicks and accepted suggestions. Do not inflate the report with total messages if message volume has no connection to resolved questions or qualified enquiries.
What does this look like in SharpOS Support?
SharpOS Support is the AI support feature included with every SharpHaw subscription. It is designed as AI-only support, not a disguised live-chat desk.
The widget carries a permanent disclosure line: “AI assistant · May make mistakes.” The AI label links to a transparency page, and the disclosure is part of the product shell rather than an organisation setting that can be switched off.
Each assistant answers from an approved knowledge base, can respond in multiple languages and can be instructed to state its limits rather than fill gaps. When it cannot help confidently, the fallback can point to a real email, WhatsApp or phone route. It does not pretend a human has joined the chat.
Inside SharpOS, the business can review conversations, capture visitor suggestions, see usage and update the knowledge that grounds future answers.
This is an implementation pattern, not a claim that installing one feature proves compliance with every part of Article 50. The wider rules also cover areas such as marking certain generated content, deepfakes and public-interest text. The voluntary Commission Code supports parts of those obligations but does not replace the Act or official guidelines (European Commission Code of Practice).
For a website owner, the immediate work is narrower and more practical: make the AI identity impossible to miss, constrain what it can claim, give uncertainty an honest exit, review what people ask and put one person in charge.
That is the difference between a label and an operating system.
See how SharpOS Support works inside the shared workspace.
FAQ
Does every website chatbot need an AI label?
Article 50(1) covers AI systems designed for genuine, direct two-way interaction with people, unless it is obvious that the person is interacting with AI. The legal obligation is framed around the provider, and the exact provider/deployer role depends on how the system is built and offered. Get legal advice for your implementation.
When did the EU AI chatbot transparency rule start?
Article 50 applies from 2 August 2026. The Commission says people should be informed from the start of the first interaction in a clear, distinguishable and accessible way.
Is a disclaimer enough for AI chatbot compliance?
No single interface line proves compliance. A visible disclosure is one requirement. Businesses should also verify role allocation, accessibility, knowledge governance, fallback behaviour, review access, data handling and any other AI Act or privacy duties that apply.
Does SharpOS Support hand conversations to a human agent?
No. SharpOS Support is AI-only. When it cannot answer confidently, it can point the visitor to a real contact route such as email, WhatsApp or phone. The interface should not promise a live human handoff that does not exist.
What should an owner review in chatbot conversations?
Review unanswered questions, low-confidence replies, repeated objections, suggestions and fallback use. Turn each pattern into a knowledge update, website change, contact-route fix or explicit decision not to answer.
