PII Redaction for AI Voice Agents: A GDPR Guide for 2026

PII Redaction for AI Voice Agents: GDPR-Safe Transcripts, Recordings and Logs

Short answer first: you do not have to choose between observability and data protection. Personal data can be redacted automatically from transcripts, audio recordings, traces and logs before anything is stored permanently. The analytical layer survives, the raw values do not.

Getting there comes down to three levers: a redaction stage at ingestion time, a short and documented retention period, and a clean legal basis including a disclosure at the start of the call. With Famulor you configure retention, consent mode and memory behaviour per account — without giving up the ability to analyse your calls.

The trigger for this article: on 20 August 2026 LiveKit shipped PII Redaction for its Agent Observability product and explained in detail why spoken conversations have to be handled differently from form data. The mechanics they describe make a useful reference model, regardless of which platform runs your phone agents.

Why spoken conversations are the hardest PII problem

In a web form the phone number sits in a field called phone. On a call it sits nowhere. It emerges across several turns, with corrections, spelled-out letters and clarifying questions. That is exactly where classic approaches break.

LiveKit names three patterns that show up constantly in phone conversations and that defeat pattern matching: people spell things out loud, they split a single value across turns, and they correct themselves mid-turn. A regular expression for a card number will not fire when the digits are spread over four utterances and one of them is retracted.

A second practical example: the caller says "Smith — no, with a Y, so S as in Sierra, M, Y, T, H". A dictionary lookup on surnames finds the first token at best. The spelled-out remainder stays in plain text, and therefore in your storage.

Third: automatic speech recognition does not produce perfectly reliable word-level timestamps. Anyone who believes they can surgically cut individual words out of an audio file is overestimating the precision of current STT models. LiveKit draws the conservative conclusion and removes the entire conversational turn from the recording instead of trimming word windows. A soft tone plays in place of the original speech.

The four layers where personal data accumulates

A common mistake in privacy designs for AI telephony: only the transcript gets attention. In reality personal data is created in at least four places, and each one needs its own decision.

The third row is the one teams underestimate. When your agent calls a function mid-conversation — an inventory lookup, an appointment booking — the parameters it passes usually land unfiltered in the log. How to define and constrain those parameters is covered in the documentation on tools and functions.

Redaction approaches compared

There are three common ways to strip personal data from conversational records. They differ sharply in recall, effort and auditability.

The honest assessment: LLM-based redaction is not error-free, and it tends to over-redact rather than under-redact. For a compliance control that is the right direction to fail in. The pragmatic compromise most teams land on is to keep catching structured formats with rules and add a model-based pass over the conversational context.

LiveKit's implementation covers 41 PII types across ten groups: names, contact details, demographics, credentials, network identifiers, organisations, financial data, locations, calendar dates and government identifiers. That grouping doubles as a workable checklist for your own design, whichever vendor you use.

What the legal framework actually requires

For AI telephony, data protection is not an afterthought — it determines the architecture. Four requirements drive the design.

Data minimisation. Article 5 GDPR requires you to process only what the purpose demands. If you analyse calls to improve your agent, you need the conversational flow — not the caller's bank details. That is precisely what redaction delivers: it separates the analytically valuable part from the legally risky one.

Storage limitation. A retention period has to be defined, justified and technically enforced. LiveKit deletes observability data automatically after 30 days. Whether 30, 60 or 90 days fits your case depends on your purpose — what matters is that the period appears in your record of processing activities and that the system genuinely applies it.

Transparency at the start of the call. The caller must learn that they are speaking to an AI system and whether the call is being recorded. That belongs in the greeting, not in the small print. How to anchor that wording properly is described in the documentation on the system prompt.

Processing agreements and processing location. Every service in your chain — telephony, speech recognition, language model, speech synthesis, storage — potentially processes personal data. You need a data processing agreement with each one and clarity about where processing happens. That chain is the real reason European operators insist on EU hosting.

A frequent misconception: that zero data retention at the model provider replaces redaction. It does not. Zero data retention means the model provider does not persist your content. It says nothing about what ends up in your observability store, your CRM and your logs. The two measures complement each other; neither substitutes for the other.

What observability costs — and what it saves

The economics are rarely worked through properly. Observability without a privacy design is not a saving, it is a deferred invoice. Three cost blocks stand against each other.

First, operations. Storage for transcripts and recordings is cheap; redaction itself costs compute. Both land in the range of fractions of a cent per conversation minute and are negligible next to telephony and model costs. A breakdown of per-minute costs is on the pricing page.

Second, the upside. Teams that can analyse calls find the points where callers drop off, where the agent transfers incorrectly, or where a tool call fails. In practice those are the percentage points of completion rate that decide whether a project pays for itself. Without observability you are optimising blind.

Third, the risk. A store full of unredacted conversation data is an access-and-erasure-request problem, a notification problem after an incident, and in the worst case a fine. The cost is rare but unbounded — exactly the profile you insure against.

Run both sides against each other before you decide whether to enable recording and analysis at all:

Implementing this on Famulor: step by step

The following sequence has proven itself in rollout projects. None of it requires engineering resources.

1. Define the purpose. Write down in one sentence why you analyse transcripts — quality assurance, prompt optimisation, evidentiary obligations. No purpose means no legal basis and no sensible retention period.
2. Configure retention. Set the retention period for recordings and transcripts to the shortest value that still serves your purpose. Automatic deletion is far more reliable than any process that depends on a person remembering.
3. Choose the consent mode. Decide whether and how consent to recording is captured, and anchor the disclosure in the assistant's opening message.
4. Constrain the data fields. Review every function your agent calls mid-conversation for its parameters. Pass a case reference instead of a full customer record wherever that is possible.
5. Control conversational memory. If your agent should recognise returning callers, decide deliberately which attributes get stored — and make sure an erasure request actually removes the entry.
6. Scope what leaves the platform. Data exits through integrations and webhooks. Define per destination which fields are passed instead of forwarding the entire conversation record.
7. Test instead of hoping. Run test calls in which you deliberately state a name, an address, a date of birth and a payment detail — once in one go, once spelled out, once with a correction. Then inspect transcript, recording and log. How to set this up systematically is covered under testing.
8. Document it. Record purpose, retention, the services involved and the controls applied in your record of processing activities. The effort is one-off; the benefit shows up at the first audit.

Best practices and common mistakes

Redact before storing, not after. If raw values reach storage first and are overwritten later, they existed in the meantime — in backups, in replicas, in search indexes. LiveKit solves this with an upstream ingestion service that runs redaction before artefacts reach the actual store. Apply the same principle to your own chain.

Keep the context, remove the value. A transcript with every second line missing is useless for optimisation. A transcript with markers such as [phone_number] or [address] stays readable and simultaneously shows what was removed. Typed markers even let you analyse at which points in a conversation sensitive data typically appears.

Decide on recording and transcript separately. For many use cases the redacted transcript is entirely sufficient. The audio file additionally contains the voice as a biometric identifier and is therefore the far more sensitive asset. Ask per use case whether you genuinely need the recording.

Do not forget the other channels. If your phone agent is part of an omnichannel setup, the same data appears in chat, in the web widget and in messenger threads. A design that covers telephony only is incomplete. This matters especially for setups built around an AI call center spanning several channels.

Audit your own analysis routines. Feeding redacted transcripts into a further model for summarisation creates a new processing activity. It needs documenting like any other.

The most common mistake in practice, though, is not technical. Teams switch recording off entirely out of uncertainty, lose every avenue for improvement, and wonder six months later why the drop-off rate has not moved. The choice is not "store everything" versus "store nothing" — it is "store the right thing".

Three industry examples

A dental practice handling 80 patient contacts a day. Calls surface names, dates of birth, insurance numbers and frequently symptoms — health data under Article 9 GDPR. The right configuration here is usually: no audio recording, redacted transcript with a short retention period, appointment booking through a function that transmits only a case reference and a time slot. The practice keeps the ability to verify that the agent understands scheduling requests correctly.

An estate agency with 30 active listings and 15 first enquiries a day. The motivation differs: the agent pre-qualifies prospects. Names, budget figures and financing status are highly sensitive, but the conversational pattern is the actual object of optimisation. Redacted transcripts are entirely sufficient to see which question makes prospects drop out.

A tax firm during filing season. An AI agent takes callback requests and document queries. Client data and tax numbers must be redacted without exception, and professional secrecy tightens the requirements further. At the same time, knowing which questions recur is worth real money — it shows what belongs in the next client bulletin.

In all three cases the decision is the same: not whether to analyse, but what to analyse from. If you want to compare industry fits, examples are collected under industries.

Conclusion

Data protection and observability are not in conflict in AI telephony — they simply need the right order of operations. Redact personal data before it is stored. Set a short, technically enforced retention period. Constrain what your functions and webhooks hand outward. And test the result with calls that deliberately spell things out and correct themselves.

The industry is clearly moving this way: vendors now ship redaction as a standard capability rather than an add-on product. For European operators, processing location adds a second dimension — which is why EU hosting on Famulor is the default setting rather than a paid extra.

Concrete next step: create a test assistant, run five calls with deliberately scattered personal details, then inspect transcript, recording and log. Half an hour tells you where your chain leaks. You can start directly with the no-code voice agent.

FAQ

What is PII redaction for AI voice agents?

PII redaction is the automatic removal of personal data from a phone agent's transcripts, audio recordings and logs. Detected values are replaced with typed markers before the data is stored permanently.

Is a regular expression enough to redact transcripts?

No. On a call, values get spelled out, split across turns and corrected mid-sentence. Pattern-based methods miss exactly those cases and should only supplement context-aware detection, never replace it.

Why is the whole turn removed from an audio recording?

Because speech recognition models do not produce perfectly reliable word-level timestamps. A precise cut could leave fragments of the sensitive value behind. Removing the entire turn is the safe option.

How long may I keep call recordings?

As long as your documented purpose requires. In practice, quality-assurance retention typically runs between 30 and 90 days. What matters is that the period is justified, documented and enforced automatically by the system.

Does zero data retention replace redaction?

No. Zero data retention only governs whether the model provider persists your content. Your own transcripts, logs and CRM records are unaffected. The two controls complement each other.

Must I tell callers they are speaking to an AI?

Yes. The disclosure about the AI system, and about recording where applicable, belongs at the start of the call. Anchor it in the assistant's opening message rather than in downstream documents.

Can I still analyse calls if everything is redacted?

Yes. Only the personal values are removed, not the conversational structure. Drop-off points, incorrect transfers and failed tool calls remain fully visible and measurable.

What happens when a caller requests erasure?

You must remove every copy — transcript, recording, conversational memory and records in downstream systems. That is exactly why limiting what you forward to third-party systems pays off from day one.

Does this apply to chat and WhatsApp too?

Yes. The same requirements apply to every channel on which your agent talks to customers. A privacy design covering telephony alone leaves half the data ungoverned in an omnichannel setup.