Does Your AI Chatbot Clearly Identify Itself?

By Greg Nowak. Last updated 2026-08-25.

Customers should not have to play detective to work out whether there is a human at the other end. Yet many chatbots still open with a neutral "Hello, how can I help?" without mentioning that their responses are generated by AI.

This is no longer simply a matter of good practice. As a general rule, the AI Act’s transparency obligations apply from 2 August 2026. Users must be clearly informed when they are interacting with an AI system such as a chatbot or AI agent.

For Danish companies, this means getting two things right: customers must understand who is responding, and the company must control what the bot is allowed to do with customer data and internal systems.

Disclose it as the conversation begins

The Danish Agency for Digital Government explains that systems intended to interact directly with people must be designed so users know they are interacting with AI. An exception may apply when this is obvious, but that requires a specific assessment from the perspective of a reasonably well-informed, observant and circumspect person. The assessment must also take vulnerable groups into account, including vulnerability due to age or disability.

The phrase "our digital assistant" is therefore not necessarily clear enough. It could just as easily sound like a human employee responding through a digital channel. Instead, write something along these lines: "You are chatting with our AI assistant. It can help with order status and bookings. You can always ask for your case to be passed to a member of staff."

The notice should appear at the start of the conversation and be visible within the normal user journey. If the conversation moves from web chat to an app or another channel, the same clarity must carry over. The information should not appear only in the terms and conditions or behind a small information icon.

Customers should quickly be able to see three things: that the response comes from AI, which tasks the bot can handle and how to reach a human.

An AI disclosure is only the beginning

A bot can introduce itself correctly and still be poorly governed. It may request information it does not need, use customer data in an opaque way or attempt an action that should be controlled by a member of staff.

If conversations contain personal data, data protection rules continue to apply. The Danish Data Protection Agency highlights principles including lawfulness, transparency and data minimisation. The company may collect and process only what is necessary for the purpose, and it must have both a relevant legal basis for processing and fulfil its obligation to provide information.

Extra care is required if the chatbot profiles the customer. Profiling is automated processing that evaluates personal characteristics, for example to predict spending habits or future needs. When profiling is used for direct marketing, the individual has the right to object.

If a decision based solely on automated processing produces legal effects or similarly significantly affects the individual, the Danish Data Protection Agency also stresses the need for a genuine opportunity for human intervention.

This leads to very practical decisions. Should the entire conversation be stored in the CRM? May the bot infer that the customer is price-sensitive? May previous purchases determine which offer the customer sees? And can a member of staff review a decision? The answers must be in place before launch, not after the first complaint.

System access changes the risk profile

A chatbot that only answers general questions has a relatively limited role. An AI agent that can retrieve an order status, reschedule a booking or create a case in the CRM requires much tighter controls.

OpenAI describes function calling as a way to connect models to external tools and systems. With Structured Outputs and strict: true, the arguments supplied to a function call on supported models and configurations can be required to follow a fixed JSON schema.

A booking change might, for example, require a booking number, an approved date and the customer’s explicit confirmation. The fixed schema is an important technical safeguard because free text alone should not be able to trigger an action.

Schema validation is not the same as secure operation, however. You still need to decide which functions the bot may call, which data it may access and when the process must stop. A correctly completed JSON field proves neither that the customer has been identified correctly nor that the change makes business sense.

Situation	How the bot can help	Controls that should be in place	When a human takes over
General question	Explain opening hours, delivery or a process	Limited knowledge base and clear AI disclosure	When the answer is uncertain or outside the defined scope
Order status	Retrieve an existing status	Identity verification, read-only access and data minimisation	When there is no match or sensitive information is involved
Booking change	Suggest and carry out a permitted change	Fixed function schema, access controls, confirmation and logging	When validation fails or special terms apply
Complaint or refund	Collect the necessary information and create a case	No uncontrolled or irreversible decision	Before a significant decision is made
Personalised offer	Show relevant options within an approved flow	Clearly defined purpose, legal basis for processing and opportunity to object	When questions arise about profiling or the customer’s rights

A simple rule of thumb: the more the bot can see and change, the stronger the controls and human handover must be.

The route to a member of staff must lead somewhere

A button labelled "Talk to a member of staff" creates confidence only if it works. When a case is passed on, the relevant context should accompany it so the customer does not have to start again. At the same time, the handover must be limited to the information the employee actually needs.

Define in advance what triggers a handover: repeated misunderstandings, identification problems, complaints, sensitive information, requests for human review or actions outside the bot’s mandate.

Also decide what happens outside business hours. If the bot promises immediate contact with a member of staff but simply places the customer in an empty queue, transparency has not made the experience more credible.

Review the flow before your next customer does

Map the entire journey from the first message to the completed case. Mark where AI is used, which personal data is collected, which systems are contacted and which actions the customer can initiate.

Also clarify the roles of the company and its suppliers. The obligation to provide information under the AI Act depends on the specific role involved. Responsibility should therefore not rest on the assumption that the platform provider has already taken care of everything.

The review can be divided into four layers. Start with the user interface: is the AI identity clear from the outset? Then review the data: is every field necessary, and has its use been explained? Next, check the actions: are function calls restricted through fixed schemas, permissions and confirmations? Finally, review operations: are relevant events logged, and have both failure scenarios and human escalation been tested?

Test more than the order that goes smoothly. Use an incorrect order number. Enter an ambiguous date. Have a test customer refuse to provide more information. Interrupt the integration and ask directly for a human. These are the journeys that show customers whether the controls actually work.

Turn the chatbot into a controlled business process

Greg can help map conversation flows, personal data and system access, draft a clear AI disclosure and make human escalation work in practice. The work can also include secure connections to CRM, order status or booking systems using fixed data schemas, restricted permissions, logging and testing of failure scenarios.

Through nowa.dk, Greg’s AI automation service for Danish companies, the work can be built around the specific business process instead of a standard chatbot. Customers should not merely know that the bot is a bot. They should also understand its role, trust its actions and be able to move forward when their case requires a human.

Related on GrN.dk

Need help with this kind of work?

Get your chatbot flow reviewed Get in touch with Greg.

Sources

Last modified

2026-08-25