Recording, Consent & Redaction

Inventory the copies before you write a single rule.

A human contact centre produced one durable artefact per call and had a documented path to delete it. A voice agent fans the same audio out across systems that were procured separately, retained on different clocks, and in several cases operated by different vendors.

• The audio — the only copy your existing policy names, and usually the only one anybody deletes.
• The transcript — produced by your ASR provider, often retained by them as well as by you, and far easier to search than audio, which is precisely what makes it worse.
• The model context — the rolling transcript sent on every turn, which may be logged by your inference provider under a different retention agreement than the one your procurement team read.
• Tool arguments — the date of birth, the account number, the address you passed into a lookup call. These land in application logs that nobody classified as call data.
• The trace — spans, prompts and completions in your observability vendor, with a default retention that was chosen for debugging convenience. See trace sampling and retention.
• The write-back — the disposition, summary and notes the agent puts into the CRM, which are read for years by people who will never hear the call. That artefact has its own failure modes.

Disclosure is a state the agent must hold, not a line it says once.

Since 2 August 2026 the EU AI Act's Article 50 transparency obligations have applied directly to systems that interact with people, and an AI voice agent is the canonical example: the caller has to be aware they are talking to an AI unless it is obvious from context, with exposure up to €15 million or 3% of worldwide turnover behind it. The obligation applies to systems already in the market, so there is no grandfathering to wait out.

The engineering consequence is that "we say it in the greeting" is an incomplete implementation, because a call has more entry points than the greeting.

• Warm transfer in both directions. A caller handed from a human to the agent never heard the greeting. A caller handed from the agent to a human should be told the handover happened; both paths belong in the transfer design.
• Callbacks and outbound. An outbound call starts with a caller who has no context at all, and the disclosure competes with the first three seconds in which people hang up.
• Barge-in. A caller who interrupts the greeting did not hear the end of it. If your disclosure lives in a sentence that can be talked over, it is not reliably delivered — put the flag on the session and re-assert on the first substantive turn.
• Ask-the-question. "Am I talking to a robot?" should trigger a truthful, unambiguous answer from a hard-coded path, not from whatever the model feels like generating.

Track it as session state — disclosure_delivered_at, with the surface that delivered it — and write it into the same record as consent. A regulator's question is not "what does the script say" but "prove it happened on this call".

Consent gates the buffer, and the buffer usually starts too early.

Twelve US states — California, Connecticut, Delaware, Florida, Illinois, Maryland, Massachusetts, Montana, New Hampshire, Oregon, Pennsylvania and Washington — require every party to consent to a recording; the rest follow the federal one-party standard. That much is well known. What breaks in practice is ordering: media typically starts flowing the instant the call connects, the recorder is attached at the same moment, and consent arrives four seconds later. Those four seconds are a recording made without consent, and they exist in every one of the six sinks above.

• Attach the recorder on the consent event, not on call setup. If your platform cannot do that, buffer in memory and discard on refusal — but know that a buffer you never flush is still a copy, and say so in your assessment rather than pretending it is not.
• Do not resolve jurisdiction from the phone number. An area code has told you nothing about where a person is standing for a decade. Resolve by the strictest rule that could apply, which in practice means defaulting to all-party consent everywhere and treating one-party states as an optimisation you probably do not need.
• Refusal must be a supported path, not an error. Decide in advance whether the agent continues without recording, offers a human, or ends the call — and make the choice per task, because some tasks genuinely cannot proceed unrecorded.
• Consent to recording is not consent to training. These are separate purposes and increasingly separate legal bases. If your evaluation set is built from production calls, the permission for that is its own record; the same discipline applies to the eval corpus you build from them.

Card data must never reach the agent leg at all.

This is the one place where post-hoc redaction is not an option, and where the voice-agent version is genuinely harder than the human one. Under PCI DSS v4.0.1 the manual pause-and-resume that contact centres relied on is treated as a partial control at best, because it depends on someone remembering: the standard expects cardholder data to be excluded from scope automatically and predictably. The architecture that survives an assessment keeps the digits out of the agent leg, the recording and the desktop entirely — DTMF masking, where the caller keys the number and the tones are intercepted and replaced with a comfort tone, or a handoff to an IVR or payment link that the agent never sees.

An LLM-driven agent adds two wrinkles a human agent does not have.

• The model cannot "not look". A human agent can be trained to look away from a screen. Anything spoken on the agent leg is in the context window by definition, and from there it is in the provider's request payload, your trace, and possibly a prompt-cache prefix. There is no equivalent of averting your eyes.
• Callers volunteer. People read their card number aloud unprompted, mid-sentence, before any payment flow starts. You need a detector on the inbound audio path that can suppress and drop, not a rule in the prompt asking the model to ignore what it has already received — the same reason a prompt-level rule is the wrong place for any boundary that matters.

Generalise the pattern beyond cards. Health details, government identifiers and full dates of birth all deserve the same question: does this value need to reach the model to complete the task, or does it only need to reach a tool? Where it only needs to reach a tool, collect it in a channel the model does not observe and pass a reference.

One redaction service, in front of every sink, at write time.

The common failure is per-sink redaction: a scrubber in the ASR pipeline, a different regex in the logging library, and nothing at all on the tracing SDK. You now have three detectors with three different definitions of a phone number, and your compliance posture is the weakest of them.

• Redact on the write path, not the read path. A masking view over stored raw data protects against a curious employee and against nothing else — not a backup, not a breach, not a subpoena, not a vendor's own retention.
• Run one detector and version it. When the detector improves, you need to know which artefacts were written under the old one. Stamp the detector version alongside the consent record.
• Redaction is lossy and that is a feature, so plan the reversible case deliberately. If a dispute needs the original, the answer is a tightly access-controlled vault with its own audit trail — not "we kept the raw copy in the trace, just in case".
• Redact before the summary, not after. The agent's own write-back can reconstruct what you scrubbed: "the caller confirmed the last four digits" is fine, a summary that helpfully restates the full number is a new copy of the data in a system you never classified.
• Measure the miss rate. Sample redacted transcripts, have a human check them, and publish the number. A detector nobody has measured is a detector everybody assumes is perfect.

Prove deletion reaches all six, with a drill.

Every control above is a promise about the future. The only way to know it holds is to exercise it against a real call, end to end, before someone external asks you to.

• Run a deletion drill quarterly. Place a call, note the session id, wait a day, then issue an erasure request and verify each of the six sinks. Time it. The number you get is your honest answer when a customer asks, and it is usually much worse than the policy claims.
• Name the sinks your vendors control. ASR providers, inference providers and observability platforms each have their own retention and their own deletion API or lack of one. This is a procurement question with an engineering answer, and it belongs in vendor risk.
• Reconcile deletion with legal hold. These obligations conflict by design, and the conflict has to be resolved by a documented rule rather than by whichever job runs first — see retention and legal hold.
• Remember the memory. If the agent personalises across calls, the caller's data is also in a memory store that no recording-retention policy has ever mentioned; erasure against agent memory is a genuinely separate problem.

Related: caller authentication for the other half of the trust problem on a phone line, data governance for the classification this all hangs off, and the EU AI Act for agents for the obligations beyond disclosure.