Disclosure, consent, and compliance for AI phone agents

Voice is the most regulated channel we deploy AI into, and the rules are moving. This is a practical summary of what applies today across the three jurisdictions our clients most often operate in, and the checklist we build against — which is deliberately stricter than the minimum, for reasons that are commercial rather than legal.

The usual caveat applies: this is how we build, not legal advice. Take it to your counsel, who will have opinions about your specific circumstances.

Disclosure: the settled question

Whether to tell callers they are speaking to an AI system used to be a design debate. It is now largely settled by regulation, and where it is not, it is settled by risk.

The EU AI Act requires that people be informed when they are interacting with an AI system unless it is obvious from the circumstances. This is a transparency obligation rather than a high-risk classification, which means it catches far more deployments than the headline high-risk rules do — including ordinary customer service voice agents and chatbots that nobody thinks of as regulated AI. It also applies extraterritorially: if your system’s output is used in the EU, being established elsewhere does not exempt you.

In the United States, several states have enacted bot-disclosure requirements, with California’s the most cited, and the direction of travel across states is consistent. In India there is currently no general AI-disclosure statute, though telecom regulations govern outbound calling independently and consumer-protection principles around misleading practices apply.

Our position is simpler than the patchwork: disclose on every call, in the opening line, regardless of jurisdiction. It costs one sentence. It eliminates the entire category of "we were misled" complaints, which are reputationally expensive and impossible to defend after the fact. And it turns out not to hurt containment — in our deployments, disclosure has no measurable effect on whether callers complete their task with the agent.

Recording consent

Voice agents record by necessity — transcription is how they work — which means recording consent applies from the first word, not from the point where you decide to keep the audio.

The rules split broadly into one-party and two-party consent jurisdictions. In one-party jurisdictions, a notice at the start of the call is generally sufficient. In two-party jurisdictions, explicit consent from the caller is required before recording begins, which means the agent must ask and receive an affirmative answer, and must have a path for callers who decline.

Three implementation details matter. Consent must be captured verifiably and stored alongside the recording, with the timestamp and the wording used — a claim that consent was obtained is worth little without the record. The declined path must actually work: an agent that cannot proceed without recording should transfer to a human rather than dead-end. And in the EU, recording implicates GDPR separately from the AI Act, which means a lawful basis, a retention period, and honouring erasure requests.

Payments: keep card data out of the transcript

This is where we see the most avoidable risk created. A voice agent that accepts card numbers spoken aloud puts primary account numbers into the audio recording, the transcript, the model context, and any logging in between. Every one of those becomes a PCI DSS scope problem, and most teams do not realise they have created one until an assessor asks.

The two patterns that avoid it entirely: send a secure payment link by SMS mid-call and confirm completion conversationally, or transfer to a PCI-compliant IVR for the payment portion and resume the AI conversation afterwards. Both keep card data outside every system the AI touches.

The SMS link is generally the better experience as well as the safer architecture — the caller gets a receipt, the payment page handles authentication, and there is no risk of a misheard digit. We have not built a voice flow that takes card numbers by voice and do not intend to.

Retention, redaction and access

Recordings and transcripts are personal data, frequently containing far more than the caller intended. Retention should be configured before launch rather than discovered during an audit.

• Redact before storage, not after. Identifiers, health information and financial details are stripped or tokenised as the transcript is written, so the stored artefact is already minimised.
• Set retention by purpose. Quality assurance needs weeks; dispute resolution may need months; nothing needs indefinite retention, and "we might want it" is not a purpose.
• Honour erasure. A caller in scope of GDPR or India’s DPDP Act can request deletion, which needs to work across recordings, transcripts, derived data and backups.
• Restrict access. Recordings should be accessible to defined roles with the access logged, not available to anyone with a login to the contact-centre platform.

For healthcare deployments in the US, the whole chain — telephony provider, speech vendor, model provider, storage — needs to be covered by business associate agreements. It is worth checking each one specifically rather than assuming, because the speech-to-text vendor is the link most often missed.

What we will not build

Some voice applications are technically straightforward and commercially available and we decline them anyway. It is worth being explicit about which, because clients ask.

Agents designed to sound human without disclosing. The technology can pass; the exposure when it is discovered is not survivable, and it makes every other AI deployment in the organisation harder to defend.

Cold calling and collections. Both sit in a dense regulatory environment where the addition of AI raises the reputational stakes considerably, and neither is a use case where the customer benefits from automation.

Voice cloning of a specific real person, including a client’s own executives, without a documented consent and use agreement — and even then, only for narrow applications. The technology is available; the misuse case is one incident away.

Who is accountable when the agent gets it wrong

The question comes up in every compliance review and the answer is simple enough to state plainly: your organisation. Accountability for what a voice agent says to a customer sits exactly where accountability for what an employee says sits, and no vendor arrangement moves it.

That has design consequences. If the agent can make a statement that creates an obligation — a quoted price, a confirmed appointment, an assurance about coverage — then either the statement must be within a bounded set you have approved, or a human must approve it before it is made. We implement the first far more often than the second, because a bounded set is fast and an approval step in a live call is not.

It also means the remediation path needs designing before launch rather than after the first incident. When an agent says something incorrect, three things should happen automatically: the call is flagged for review, the customer-facing consequence is identified from the transcript, and the failure enters the regression suite. Organisations that improvise this discover that the transcript is the only record and nobody has read it.

The upside of complete transcription is worth stating: the evidence is better than it was. A dispute about what a human agent said resolves from memory and a QA sample; a dispute about what an AI agent said resolves from a recording, a transcript and a timestamped log. Several clients have found that the strongest argument for the deployment came from their own risk function.

Sector rules that sit on top of the general ones

General AI and telecom regulation is the floor. Several sectors add requirements that materially change what a voice agent may do.

Healthcare. Any voice agent handling patient information is processing protected health data, which means business associate agreements across the whole processor chain — telephony, speech-to-text, model provider, storage — not just the one you contracted with. It also means the agent must not offer clinical advice, triage or interpretation of results without a defined clinical sign-off path. Booking, reminders, verification and routing are fine; anything that a patient could reasonably act on medically is not.

Financial services. Identity verification by voice carries its own requirements, and the agent must not give advice that would constitute a regulated recommendation. Where an agent handles anything approaching a complaint, most regimes have specific handling and timing obligations that the agent must trigger rather than absorb — a complaint identified by the agent should enter the formal process immediately, not be resolved conversationally.

Insurance. Statements made during a call can affect a policy, so an agent discussing coverage needs tight boundaries and a recording that evidences exactly what was said. This is one of the clearest cases where the audit trail is a product feature rather than an operational detail.

The general pattern: sectors where a spoken statement creates an obligation need the agent scoped narrowly and evidenced completely. We map this during discovery rather than discovering it during a compliance review.

Designing the escalation path as a compliance control

Escalation is usually treated as a quality feature. In regulated deployments it is a control, and it should be specified with the same care as the disclosure wording.

Four triggers should always route to a human immediately and without argument: an explicit request for a person, detected distress or vulnerability in the caller, any topic outside the agent’s configured scope, and any mention of a complaint, legal action or regulatory matter. None of these should require the agent to attempt resolution first, and none should be rate-limited.

Vulnerability detection deserves particular attention. Callers who are confused, distressed, or appear not to understand they are speaking to a machine should reach a person quickly, and the threshold for that should be deliberately generous. Getting this wrong is both a regulatory exposure in several jurisdictions and the single worst outcome available in terms of reputation.

Finally, escalation should be logged as a category rather than an event. Reviewing which triggers fire, how often and on which intents is how you find out that a scope boundary is in the wrong place — usually well before a caller complains about it.

The checklist we deploy against

1. AI disclosure in the opening line of every call, in every jurisdiction, with the human-transfer option offered at the same time.
2. Recording consent captured according to the strictest applicable rule, stored verifiably with the recording, and a working path for callers who decline.
3. No card data by voice — SMS payment link or transfer to a PCI-compliant flow.
4. Redaction applied before storage; retention configured per purpose; erasure requests honoured across all artefacts.
5. Access to recordings restricted by role and logged.
6. Immediate transfer on request, on detected distress, or after three failed clarification attempts — the agent never insists.
7. Processor chain reviewed for the sector: BAAs for healthcare, DPAs everywhere, subprocessor list maintained.
8. Every call automatically scored, including for disclosure delivery — which is a compliance control, not just a quality metric.

That last point is underrated. Because a voice agent deployment can score 100% of calls rather than the 2% a manual QA team samples, disclosure compliance becomes continuously verifiable rather than periodically audited. It is one of the few areas where automating a process genuinely improves the compliance posture rather than complicating it — and it is worth saying so to the risk function early, because they usually expect the opposite.