AI customer disclosure & human-choice checklist

Use this checklist to turn an AI-transparency requirement into an operated customer journey. It is designed for chatbots, persistent messaging, automated email, in-product assistants, and voice agents that interact directly with customers.

The EU AI Act's Article 50 includes transparency obligations for covered AI systems that interact directly with people, and the European Commission says the rules begin to apply on 2 August 2026 (European Commission implementation timeline; official regulation text). This checklist is operational guidance, not legal advice. Your qualified legal or compliance owner must determine scope, exceptions, roles, wording, jurisdiction, and evidence requirements for your situation.

The pass condition: a customer understands when AI is involved at the moment it matters, can make an informed choice, can reach an appropriate human or alternative path, and does not lose context. The organization can prove which experience was delivered and can correct or disable it when the system changes.

Control record

No owner may be a team name alone. A group can contribute; a person or defined duty role must be able to decide and act.

1 — Inventory every reachable path

• Listed every public, authenticated, embedded, deep-linked, campaign, partner, and third-party entry point
• Included web chat, mobile, messaging, automated email, social, voice, callbacks, and regional or multilingual variants
• Included experiments, feature flags, fallback models, after-hours modes, and old flows reachable from bookmarks or cached clients
• Recorded which organization is the provider, deployer, processor, controller, or other relevant actor as qualified specialists define those roles
• Documented the purpose, customer population, data, knowledge, model, vendor, tools, actions, human path, and owner
• Searched for shadow AI used by frontline staff outside the approved customer experience
• Disabled or restricted any path whose owner, data, action authority, or current behavior cannot be established

Evidence: current AI-use inventory, entry-point map, screenshots or recordings, configuration export, and named owners.

2 — Obtain the qualified interpretation

• Legal or compliance owner has documented whether and how the applicable transparency obligation applies
• Exceptions and assumptions are written rather than remembered from a meeting
• Countries, languages, customer classes, channel variants, and transition dates are explicit
• Disclosure requirements are separated from consent, call recording, privacy notice, cookie, contract, and marketing obligations
• Requirements for human choice, accessibility, records, retention, and complaint handling are documented by the appropriate owners
• A trigger list states when model, vendor, purpose, action, customer group, channel, region, or guidance changes require re-review

Evidence: dated advice or policy decision, approver, scope, version, and next review. Do not attach privileged material to a broadly accessible operating document; link to the controlled record.

3 — Write the disclosure as service language

The default structure is organization + AI nature + bounded purpose + customer choice. Adapt only after qualified review.

Working pattern

You are chatting with [Company]'s AI support assistant. It can help with [bounded tasks]. [Ask for a person / use this alternative] at any time.

• Names the organization responsible for the interaction
• Says plainly that the customer is interacting with an AI system
• Describes real capability without implying general intelligence, certainty, or authority
• Gives the approved human or alternative path in understandable language
• Avoids a human name, portrait, job title, typing behavior, or synthetic voice that contradicts the disclosure
• Avoids “powered by AI” as the only description; it does not clearly state the nature of the interaction
• Avoids legal jargon, euphemism, dark patterns, and a link that requires the customer to leave the conversation to understand it
• Has approved translations reviewed for meaning, not produced and shipped by machine alone
• Fits the channel without being hidden: visible text for chat and messaging, audible paced language for voice, clear context for automated email

Evidence: approved copy by channel and locale, version identifier, reading or listening review, and sign-off.

4 — Put it at the right moment

• Appears or plays before the customer reasonably relies on the interaction or shares the substance of the problem
• Remains perceivable long enough to read or hear and is not covered by animation, keyboard, cookie controls, or other UI
• Repeats when a customer enters through a path that bypasses the normal opening
• Repeats or remains available after resume, callback, transfer, reconnect, or material change in the interacting system
• Voice disclosure is not compressed into an unintelligible block with recording and privacy notices
• Automated email clearly identifies the automated nature before inviting the customer to continue the exchange
• Bot-to-human and human-to-bot transitions state the change when a reasonable customer could otherwise be confused
• Failure to render or play the disclosure routes to an approved fallback rather than silently continuing

Evidence: journey recordings for every entry and transition, render or playback telemetry, and fallback test.

5 — Make human choice operational

• Explicit requests such as “human,” “agent,” “person,” or equivalent locale variants work immediately
• Indirect requests and repeated automation failure can trigger human review under the approved rule
• Voice offers a simple spoken and keypad route; chat and messaging offer a visible, keyboard-accessible control
• The AI does not argue, advertise itself, restart troubleshooting, or require a magic phrase after a human request
• Human access is staffed or the customer receives an honest wait, callback, or appropriate alternative
• Transfer preserves queue time and priority rather than treating the customer as a new arrival
• Unsupported, high-risk, sensitive, disputed, inaccessible, low-confidence, or failed-action paths route to trained humans as defined
• A customer who declines AI is not denied an available service or given a deliberately worse path unless a qualified policy explicitly governs the difference

Evidence: transfer tests, queue configuration, staffed-hours plan, callback behavior, and sampled customer journeys.

6 — Transfer context, not just the connection

The receiving person must get this before greeting the customer:

• Customer goal, impact, preferred language, and accessibility need
• Identity or authentication state and what still must be verified
• Transcript or faithful summary with uncertainty labeled
• Knowledge sources consulted and their versions where material
• Actions proposed, attempted, completed, failed, or reversed, including exact system result
• Reason for transfer and the decision or capability required
• Time already spent, current promise, next owner, and fallback if the connection fails
• Sensitive-data warning with evidence stored only in the approved system

Evidence: receiving-agent screen, raw transfer event, QA sample, and customer repetition rate.

7 — Separate disclosure, data, and correctness controls

• Disclosure approval does not stand in for consent, privacy, security, accessibility, or quality approval
• Data categories, purposes, providers, subprocessors, regions, retention, deletion, training use, and access are governed separately
• The model cannot treat customer text as authorization for a consequential action
• Identity assurance is separate from conversational confidence
• Prices, policies, account state, transaction results, and other controlled facts come from approved sources or typed tools—not generated memory
• Consequential actions require validation, permission, confirmation, limits, audit, and verified result
• Low confidence, contradictory knowledge, missing data, or tool failure produces refusal or transfer rather than improvisation

Evidence: data-flow diagram, approved sources, action specification, permission tests, and evaluation cases.

8 — Build proportionate evidence

Record only what qualified owners determine is necessary. A disclosure log should not become an excuse to retain every conversation forever.

• Interaction or journey identifier
• Timestamp, channel, entry point, country or policy scope, and locale where required
• Disclosure version and whether it rendered or played successfully
• Customer choice, explicit human request, and routing result
• AI flow, policy, model, and knowledge version needed to investigate material behavior
• Exception, degraded mode, or fallback used
• Access control, retention, deletion, export, and audit process approved
• Evidence survives vendor export and contract exit in a usable form
• Logging failure creates an alert and approved operating response

Evidence: event schema, sample export, access review, retention job, deletion test, and vendor-exit test.

9 — Test comprehension and accessibility

Do not stop at “the string rendered.” Ask testers what they believe they are interacting with and what choices they have.

• New, returning, resumed, transferred, deep-linked, callback, and reconnected journeys
• Authenticated and unauthenticated customers
• Every supported channel, locale, device class, and right-to-left layout where applicable
• Screen reader announcement order, keyboard access, visible focus, zoom, contrast, and text scaling
• Captions or transcripts for relevant audio or video and a non-voice alternative
• Slower interaction, cognitive load, plain-language comprehension, and enough time to respond
• Accent, dialect, speech disability, background noise, silence, interruption, and keypad fallback for voice
• Poor networks, blocked scripts, provider failure, audio failure, logging failure, and fallback model
• Explicit, indirect, and repeated requests for a person
• Customers who are vulnerable, distressed, disputing a decision, or seeking an accommodation
• Disabled users or qualified accessibility practitioners included in acceptance testing

Evidence: test matrix, participant notes, defects, remediation, and re-test result.

10 — Rehearse failure and rollback

• One person or duty role can stop the experience quickly without vendor approval
• Circuit breakers can disable a risky action, intent, language, model, channel, region, or the entire system
• The customer receives an honest message and reachable alternative during degradation
• Open interactions route safely and do not disappear when the system stops
• Evidence is preserved without retaining unnecessary sensitive data
• Legal, security, privacy, accessibility, service, and incident owners have severity and notification triggers
• Restore requires a passed regression set, verified monitoring, owner approval, and a controlled exposure ramp
• Post-incident review adds the failure to tests and changes a system, control, or decision—not only the prompt

Evidence: rehearsal record, timestamps, routing result, communications, discovered gaps, completed remediation, and restore sign-off.

11 — Release gate

All must be true before launch or material expansion:

• Inventory is current and this path has a named accountable owner
• Qualified scope and wording decision is dated and linked
• Disclosure works at every entry, resume, and transition where required
• Human or alternative path is reachable, staffed, and tested
• Context transfer prevents unnecessary repetition
• Data, identity, action, knowledge, accessibility, and quality controls passed separately
• Evidence is structured, minimized, accessible to authorized reviewers, and exportable
• Representative and high-risk journey tests passed with no open critical failure
• Monitoring, alert, circuit breaker, incident, rollback, and restore are rehearsed
• Frontline and supervisors know how to explain, override, report, transfer, and recover
• Launch exposure, observation period, review date, and expansion criteria are written

Decision: [launch / restricted launch / do not launch]

Decision owner: [name / role]

Conditions: [scope, traffic, intents, actions, languages, hours]

Signed: [owners / dates]

12 — Keep the control alive

• Review inventory, complaints, human requests, failed notices, transfers, and incidents [weekly during launch / monthly when stable]
• Test disclosure and handoff in every material model, prompt, knowledge, tool, vendor, interface, or policy release
• Re-review when purpose, action, country, customer group, channel, or qualified interpretation changes
• Add missed journeys and incidents to regression tests
• Remove old versions and verify old links and cached clients cannot reach them
• Reconfirm owners, backups, access, retention, and circuit breaker at least [quarterly]
• Schedule the next legal, accessibility, privacy, security, and service review now

A disclosure that exists only in copy is fragile. A disclosure with an inventory, owner, interface behavior, human path, evidence event, regression test, circuit breaker, and review date is an operating control.