Design clear AI disclosure and risk-based human handoff states for marketing chatbots without pretending every escalation rule is a legal requirement.
Short answer: A marketing chatbot should disclose its AI nature before or at the start of a direct interaction when required by applicable rules and whenever a person could reasonably mistake it for a human. Human handoff should be triggered by risk, inability or user choice—especially for disputes, vulnerability, consequential decisions, sensitive data, repeated failure or a direct request for a person.
Disclosure and handoff solve different problems. Disclosure lets a person calibrate trust and decide whether to continue with an automated system. Handoff moves the conversation to a person or controlled specialist process when the automated path lacks authority, evidence or safety. A chatbot can disclose correctly and still trap the user; it can also offer a human option while misleading the user about who is responding.
The policy must be visible in the journey and executable in operations. “Talk to a human” is not a control if it loops back to the bot, produces no service ticket or operates only during undocumented hours. CDM’s state machine connects conversational signals to deterministic actions, evidence and ownership.
What the official evidence establishes
The European Commission’s Article 50 guidance states that providers of certain AI systems must design them so people are explicitly informed when interacting directly with AI, subject to the provision’s scope and qualifications. The guidance applies from 2 August 2026 and should be reviewed with counsel for the specific role and experience.
NIST’s Generative AI Profile is a voluntary risk-management resource that emphasises governance, measurement and management across the lifecycle. It supports testing and monitoring but does not create a universal legal list of chatbot handoff triggers.
CDM recommendation: provide a clear human route for high-consequence, sensitive or repeatedly unsuccessful interactions and when the user requests one. That is a risk and service design position. Whether a particular handoff is legally mandatory depends on jurisdiction, sector and facts.
The CDM Disclosure-and-Handoff State Machine
Treat each state as a product behaviour with a visible message, allowed actions, transition, owner and audit event. Do not bury the logic in prompt prose alone.
| State | User-facing treatment | Allowed automation | Handoff trigger |
|---|---|---|---|
| Entry / disclosure | Identify the assistant as AI and state purpose and limits | Low-risk navigation and information | User declines, asks for human or purpose is out of scope |
| Routine guidance | Cite current approved information and show next action | Answer bounded product/process questions | Low confidence, unavailable source or repeated correction |
| Data collection | Explain fields, use and required/optional status | Collect minimum approved data | Sensitive/unexpected data or consent uncertainty |
| Commercial recommendation | Explain basis and material constraints | Present approved options without hidden commitment | Consequential eligibility, vulnerability or conflict |
| Complaint / dispute | Acknowledge and provide reference | Capture facts and preserve evidence | Dispute, refund exception, legal threat or user distress |
| Human queue | Confirm transfer, timing and continuity | Summarise with user-visible consent | Queue failure, urgent risk or user revokes sharing |
How to run the Disclosure-and-Handoff State Machine
1. Inventory conversation purposes
List every marketing, sales, support and research task the chatbot performs. Name prohibited decisions and data types. A product finder, lead qualifier and account-support bot require different controls even when they share a model and interface.
2. Design disclosure in context
State that the user is interacting with AI, the organisation responsible and the task boundary in plain language. Place it before or at the start, not after data collection. Test reopen, deep-link, voice, embedded and returning-user states so the disclosure is not skipped.
3. Define deterministic trigger classes
Specify triggers outside the model where possible: explicit human request, complaint keywords plus confirmation, sensitive-data detection, repeated fallback count, unsupported account action, vulnerable-customer signal, low source confidence or service outage. Avoid claiming perfect automated detection.
4. Build a real handoff contract
Create the ticket or live transfer, carry only approved context, tell the user what will be shared and provide timing or queue status. Give the human agent the source trace and bot actions, not a persuasive generated summary without evidence. Preserve a manual fallback when the transfer service fails.
5. Test adversarial and edge journeys
Try indirect requests for a human, misspellings, language changes, frustration, contradictory personal data, inaccessible UI states and off-hours. Confirm that disclosure remains visible and the bot cannot override hard limits. Include users who choose not to provide optional information.
6. Monitor outcomes and false routing
Track disclosure rendering, human requests, transfer completion, abandonment, repeat contacts, complaint escalation and incorrect handoffs. Review transcripts with privacy controls and representative sampling. Update rules when business authority, law, service availability or model capability changes.
Decision rules
The safest design makes critical transitions deterministic and visible. The model can help classify context, but it should not be the sole authority for whether a user receives human review.
| Signal | Decision | Evidence to retain |
|---|---|---|
| User asks for a person | Offer the defined human route without argument | Request, transition and ticket/queue result |
| Bot lacks an approved source or gives repeated fallback | Stop improvising and transfer or provide safe offline route | Retrieval trace and fallback count |
| Conversation moves into complaint or dispute | Preserve evidence and route to authorised handler | Conversation reference and case record |
| Sensitive or unexpected personal data appears | Minimise further collection and apply approved privacy/escalation process | Detection event and handling decision |
| Human queue is unavailable | State that clearly and provide bounded alternative and timeframe | Availability state and user-facing message |
Build the evidence record before launch
Prove both what the user saw and what the organisation did. A transcript alone may omit UI disclosure, queue state and downstream case creation.
- Use-case inventory, permitted tasks, prohibited actions and responsible business owner.
- Disclosure copy, languages, interface states and accessibility test evidence.
- Trigger catalogue, thresholds, hard rules and model-assisted classifications.
- Handoff payload, user consent, ticket/queue event and human ownership.
- Source citations, confidence or fallback evidence for material answers.
- Edge-case test set, false handoffs, missed handoffs and remediation.
- Monitoring metrics, transcript access controls and policy review date.
Minimise stored conversation data and separate product telemetry from case records. Limit transcript access, define retention and redact test reports. High-risk sectors need additional controls beyond this general marketing framework.
Separate fact, CDM inference and the operating decision
Documented fact
The Commission describes transparency obligations for certain direct AI interactions under Article 50; NIST provides voluntary generative-AI risk-management guidance.
CDM inference
A deterministic state machine with evidence-backed handoff should reduce deceptive experiences and dead ends, but effectiveness depends on staffing, queue integration and representative testing.
Operating decision
Launch only when AI disclosure is reliably rendered, users can request a person, high-risk states stop unsupported automation and every advertised handoff produces an owned operational outcome.
Worked example: a product adviser that encounters a billing dispute
A fictional subscription service uses an AI product adviser to explain plan features. At entry, it identifies itself as an AI assistant and links to a human contact route. The user asks which plan supports a team of ten, a routine question grounded in an approved product source.
The user then says the company charged the wrong amount last month and asks for a refund. The state machine moves from routine guidance to dispute. The bot stops making plan recommendations, confirms that a specialist must review the account and asks permission to transfer the relevant conversation summary.
A service ticket is created with the transcript reference and source trace; the user receives the case number and expected response window. If ticket creation fails, the interface provides the approved offline route rather than saying “someone will contact you”. No rule here establishes the legal requirement for that exact journey; it demonstrates the control.
Limitations and review boundary
Disclosure wording, timing and handoff duties vary by jurisdiction, sector and use case. The Article 50 analysis requires current official guidance and specialist counsel. Other consumer, privacy, equality, accessibility and sector obligations may apply.
Automated detectors can miss distress, vulnerability, sensitive data or indirect human requests and can also over-route benign conversations. Use conservative limits, user choice, monitoring and human review. Do not claim the state machine makes a chatbot safe in every context.
Related guides
Frequently asked questions
Is an AI name or avatar enough disclosure?Not necessarily. A person should be explicitly informed in clear language where required, and the disclosure must appear in the actual interaction. A fictional name alone may increase confusion.
Must every marketing chatbot offer live chat?There is no universal rule in this article. The appropriate human route can be live or asynchronous, but it should be real, accessible and accurately described. Legal and sector requirements need separate review.
Can the model decide when to hand off?It can contribute a signal, but critical triggers should use deterministic controls and user choice where possible. The model should not be able to override prohibited actions or suppress a direct human request.
What context should transfer to the human?Only the approved minimum needed to continue the case, with clear user-facing information. Include source and action evidence; avoid an unverified generated summary that could distort the user’s issue.
How do we measure whether handoff works?Measure requested and completed transfers, queue failures, repeat contacts, resolution, abandonment, missed high-risk cases and user complaints. Report denominators and audit samples rather than one aggregate success rate.
Method and publication status
This prepublication draft was researched from the primary materials linked at the claims they support and checked on 12 October 2026. It requires the named specialist review, live-product retesting where indicated, a real 16:9 editorial image and final URL verification before publication. It is operational analysis, not legal, security or compliance advice.
This article is editorial guidance. Apply the principles in proportion to your market, evidence, and responsibilities.
