That gives the implementation a useful quality test. Ask whether a normally attentive customer understands the nature of the interaction before relying on it—not whether the information exists somewhere on the page.
A strong default pattern is:
- Say it at the start. Identify the organization and state plainly that the customer is interacting with an AI system.
- Say what it can do. Describe the bounded purpose without marketing language that implies unlimited competence.
- Offer a real choice. Explain how to reach a person or another suitable channel where the service design or applicable requirement calls for it.
- Repeat when context resets. A transferred, resumed, deep-linked, or voice caller may not have received the first disclosure.
- Do not imitate a named person. A human name, avatar, typing indicator, and synthetic voice can contradict a tiny AI label even when the label is technically present.
For example: “You’re chatting with Acme’s AI support assistant. It can help with order status and returns. Ask for a person at any time.” The right words depend on qualified review and actual capability, but the structure is useful: identity, nature, scope, and choice.
Avoid “powered by AI.” It describes technology, not the interaction. Avoid “digital teammate” or a human first name when the surrounding design encourages a customer to believe a person is speaking. Avoid placing the only notice after the customer has already shared their problem.
Voice needs an audible implementation
A caller cannot inspect a badge next to a message. Disclose in the opening audio at a pace and volume that a caller can understand. Repeat after a warm transfer, callback, or resumed call when the original notice may no longer be part of the current interaction.
Give callers more than one escape route. Natural requests such as “person,” “agent,” or “I do not want the bot” should work, and a keypad fallback can protect callers whose speech is not recognized reliably. The agent should not argue, repeat its capability, or require three failures before transferring.
Disclosure also must coexist with any call-recording, consent, privacy, and authentication notices. Do not compress several obligations into a fast paragraph that no caller can process. Sequence the information, test comprehension, and preserve an accessible alternative.
The complete operating model is in the voice AI support playbook.
Make the human path part of the same service
Transparency without agency can feel like a warning attached to a trap. The customer learns a machine is answering and then discovers there is no practical route to accountable help.
Define human transfer for:
- an explicit request
- low confidence or repeated misunderstanding
- missing or contradictory source material
- identity or authorization failure
- an action the AI cannot verify
- cancellation disputes, complaints, financial impact, or exceptions
- vulnerable customers, accessibility needs, safety, fraud, privacy, or legal risk
- service degradation, tool failure, or a triggered circuit breaker
Transfer the customer goal, identity state, transcript or faithful summary, sources consulted, actions attempted, exact tool result, reason for escalation, and next promise. The receiving person should see that context before greeting the customer. A handoff that forces repetition tells the customer the company disclosed the technology but did not operate it.
Separate disclosure from consent and correctness
Three controls are easy to blur:
- Disclosure tells the customer what they are interacting with.
- Consent or other lawful basis governs particular data and processing where applicable.
- Quality and authority determine whether the answer or action is correct, supported, and permitted.
Passing one does not pass the others. A perfectly disclosed AI agent can still fabricate a policy, mishandle personal data, or perform an unauthorized refund. A consent record does not make a wrong answer accurate. A correct answer does not erase the need for an applicable notice.
Keep these controls separate in the requirements, interface, test plan, logs, and sign-off. It makes failures easier to diagnose and prevents one approval from being stretched into permission for the entire system.
Build evidence as an event, not a screenshot
A screenshot proves one visual state on one day. An operated control should produce structured evidence. For each covered interaction, consider recording only what qualified owners determine is necessary, such as:
- disclosure version and locale
- timestamp and channel
- entry point and interaction identifier
- whether the notice rendered or played successfully
- customer choice or routing event
- human-transfer request and result
- model, flow, and policy version needed for investigation
- exception or degraded-mode behavior
Protect the evidence like customer data. Minimize it, control access, set retention and deletion rules, and do not preserve entire conversations merely because the disclosure log was poorly designed. The aim is traceability, not unlimited surveillance.
Test journeys, not components
The notice can pass a design review and still fail in production. Test the whole path:
- new, returning, transferred, and deep-linked customers
- authenticated and unauthenticated experiences
- web, app, messaging, email, and voice
- supported languages and right-to-left layouts where relevant
- screen readers, keyboard navigation, zoom, captions, relay, and slower interaction
- poor networks, blocked scripts, audio failure, provider outage, and fallback models
- bot-to-human and human-to-bot transitions
- explicit and indirect requests for a person
- experiments and feature flags
- old links, cached clients, and third-party embeds
Ask a human tester what they believe they are interacting with and what choices they think they have. Rendering the required string is weaker evidence than comprehension.
Assign owners before 2 August
The implementation needs several named decisions:
- Legal or compliance owner: interprets scope, exceptions, wording requirements, and jurisdictional interaction.
- Support or service owner: owns the customer promise, eligible work, human path, and outcome.
- Product and engineering owner: implements interface behavior, events, failure handling, and release control.
- AI operations owner: maintains inventory, evaluation, production monitoring, change records, and incident readiness.
- Privacy and security owners: govern data, vendors, access, retention, threats, and evidence.
- Accessibility owner: verifies effective communication across modes and assistive technology.
- Knowledge owner: controls the sources the AI may use and their lifecycle.
One person can hold several roles in a small company. One role cannot silently make all the decisions.
The emerging support specialty is mapped in the AI support operations lead guide.
The implementation sprint
If the work is starting late, run a controlled sprint:
Days 1–2: find exposure
Inventory customer-facing AI, entry points, owners, regions, channels, actions, current notices, and human alternatives. Restrict or disable paths nobody can account for.
Days 3–5: approve the standard
Obtain qualified interpretation, write channel and locale variants, define timing and repetition, and separate disclosure from consent, recording, and privacy notices.
Days 6–8: implement the journey
Add disclosure, choice, human transfer, context handoff, structured evidence, accessibility behavior, and degraded-mode fallback. Update training and the supervisor runbook.
Days 9–10: test and release
Run the full journey matrix, remediate failures, rehearse incident and rollback, sign off with named owners, and schedule the first post-launch review.
Use the AI customer disclosure checklist to run this work without turning the article into a project plan.
What happens after the deadline
The system will change. Vendors replace models, teams add languages, campaigns deep-link into old flows, and an experiment becomes permanent because nobody turns it off. Treat the control as living operations:
- review the inventory monthly during the initial rollout
- test disclosure and handoff in every material release
- add missed journeys and incidents to regression tests
- monitor human requests, complaints, failed notices, and transfer recovery
- re-review when the model, vendor, purpose, action, channel, customer population, or legal interpretation changes
- retire old disclosures and prove unreachable flows are actually gone
The Commission published a transparency code in June and continues to clarify implementation questions.
