PII Redaction for AI Avatars: Protect Seven Data Paths

PII redaction for an AI avatar should not be a single filter placed in front of the language model. A real-time avatar moves data through audio capture, transcription, retrieval, reasoning, business actions, speech, captions and operational telemetry. Sensitive information can enter—or reappear—at every one of those points.

The practical design is to classify each data type, preserve only the minimum context required for the approved purpose, and apply the right transformation at seven control points. Sometimes that means deleting a value. Sometimes it means masking it, replacing it with a stable token or releasing the original only to an authorised action service.

This article provides an architecture that bank, government and regulated-enterprise teams can use in a design review. It complements a data-classification policy for AI avatars: classification decides what the system may process; redaction decides what each component is allowed to see.

Redaction is not the same as anonymisation

Teams often use “redacted”, “pseudonymised” and “anonymous” as if they were interchangeable. They are not.

• Redaction removes a detected value from a particular representation.
• Masking hides part or all of a value while potentially preserving a recognisable form, such as the final four digits of an account number.
• Tokenisation or pseudonymisation replaces the value with a reference. If a mapping or key can restore or link it to a person, the transformed data remains sensitive. The ICO’s anonymisation and pseudonymisation guidance states that pseudonymised data is still personal data.
• Anonymisation is a higher bar. NIST SP 800-188 recommends evaluating disclosure risk and measuring the performance of de-identification techniques; merely obscuring obvious identifiers does not establish that a dataset is anonymous.

That distinction matters in procurement. A product that masks names in transcripts may reduce exposure, but it has not necessarily anonymised the conversation, removed biometric information from the original audio, or protected identifiers returned by a knowledge base.

Map the seven PII redaction points

A useful architecture review follows the data in both directions. The user supplies speech and other media; enterprise systems return records; the model creates text; and the avatar presents speech and captions. Each path needs an explicit control.

1. Capture: minimise the raw signal

A transcript filter cannot redact a voiceprint, a face in a camera stream, a bystander’s speech or personal information shown during screen sharing. Start by deciding which modalities the service genuinely needs. Do not capture video merely because the interface can accept it, and avoid retaining raw media when the approved purpose only needs transient speech recognition.

Document where raw audio is processed. If speech recognition happens in a remote service, redaction performed on the transcript occurs after the raw audio has crossed that boundary. Customer-hosted speech recognition can keep that first transformation inside the customer environment, subject to a properly scoped implementation, but it also places model operation and updates with the customer.

2. Transcription: detect across streaming boundaries

After speech recognition, apply text detection before the general reasoning path. Combine deterministic patterns and checksums for structured identifiers with organisation-specific dictionaries and context-aware or named-entity models. Evaluate the languages, dialects, accents and acoustic conditions the service will actually encounter.

Streaming complicates detection. An identifier may arrive as “AB12” in one partial transcript and “34CD” in the next. A detector that examines each chunk independently can miss the complete value. Use a bounded look-back window or delay release until the relevant pattern can be resolved, then measure the latency cost. More scanning is not automatically better: Google’s Sensitive Data Protection documentation notes that scanning unnecessary information types adds latency.

3. Retrieval: transform queries and returned passages

Redacting only the user’s prompt protects half the path. A retrieval system can return names, case numbers, medical details or transaction information from an otherwise authorised source.

Apply permission checks before retrieval, because redaction is not authorisation. Then transform both the query and the passages released into model context according to purpose. Avoid permanently corrupting the source of truth; create a redacted view for the conversational workload. A field-level avatar data-flow map should identify the source, transformation, permitted location and destination for each sensitive class.

4. Model context: preserve references, not secrets

The model may need to understand that two sentences concern the same customer without seeing the customer’s name. A stable token such as CUSTOMER_17 can preserve that relationship across a turn. If no continuity is needed, deletion is safer.

Stable tokens still enable linkage. Their scope should therefore be as narrow as the purpose permits: a session token is usually less revealing than a persistent enterprise-wide token. Where tokens are reversible, keep the mapping service and its cryptographic material outside the model’s trust zone. Do not send both the token and its lookup table to the same remote component.

5. Actions: re-identify only at an authorised broker

Some business actions genuinely require the original value. A bank transfer needs an account reference; a citizen-service workflow may need a case number; an appointment system may need contact details. Removing every identifier would make the service useless.

The safer pattern is selective re-identification. The avatar and language model work with a token. A tightly bounded action broker checks the authenticated user, current consent or authority, intended operation, data class and policy version before resolving that token. The original value is released only to the destination that needs it, not back into the conversation by default.

This separation prevents a persuasive prompt from becoming an access-control decision. The model can propose an action; trusted application policy decides whether it may occur.

6. Output: align speech, captions and screen content

Run output controls before text reaches text-to-speech, captions or the visual layer. A model can repeat a retrieved identifier, infer a sensitive attribute or generate a plausible but false personal detail. Input redaction alone will not stop that.

Use one policy decision for every presentation channel. If captions mask an identifier while the avatar speaks it aloud, the control has failed. Conversely, aggressive masking may make a regulated disclosure incomprehensible. Define when to replace, summarise, ask the user to switch to a private channel or hand the interaction to a human.

7. Logs and support: redact before storage or export

Telemetry is a common route for sensitive content to escape an otherwise private workload. Inspect transcripts, traces, exception payloads, prompt-debug records, crash dumps and support bundles before they are stored or exported. A privacy-minimised AI audit trail can preserve the event type, entity category, transformation, policy version, request identifier and outcome without preserving the original value.

Avoid logging raw content merely to explain why redaction fired. Decision evidence can often use character offsets, a salted position hash, detector version, confidence range and transformation type. If a restricted diagnostic sample is necessary, give it a separate purpose, access path and retention period.

Choose the transformation by purpose

“Redact all PII” is not an implementable policy. Use a decision matrix that connects the business purpose to one of six treatments.

• Delete: the downstream component does not need the value.
• Mask: a person needs partial recognition, such as the final digits of a reference.
• Stable token: the system needs to recognise the same entity across an approved scope.
• Reversible token: an authorised downstream action must recover the original.
• Generalise: analytics need an age band, district or category rather than an exact value.
• Keep: the precise value is necessary and approved within the current trust zone.

Google documents comparable de-identification transformations including redaction, replacement, masking, cryptographic tokenisation, bucketing and date shifting. Open-source components such as Microsoft Presidio support configurable PII analysis plus replace, mask, redact and encrypt operations. These are implementation options, not guarantees: each organisation needs its own evaluation data and policy.

Measure both privacy and utility

False negatives expose information. False positives destroy context and may cause an action to fail. A detector that removes the word “May” as a person’s name, corrupts a flight number or masks a medicine dosage can make the avatar less safe.

Test precision and recall by data type, language, channel and acoustic condition. Then measure the effect on task completion and end-to-end latency. Set the response to low-confidence detections according to consequence: a public-information avatar might safely ask the user to rephrase, while a clinical or financial workflow may require a private channel or human handover.

No universal confidence threshold is appropriate. Record why the chosen threshold and failure behaviour fit the service.

Create a redaction control record

For each sensitive data class, maintain a record that architecture, privacy, security and operations teams can review together. Include:

• the data type and approved purpose;
• where it can enter and which component detects it;
• the transformation and permitted processing zone;
• whether tokens are linkable or reversible;
• the owner of any mapping service or key;
• retention and export rules;
• latency budget and evaluation evidence;
• failure, escalation and human-handover behaviour;
• monitoring metrics and the trigger for re-evaluation.

Connect this record to the service’s AI data protection impact assessment where one is required. The ICO’s anonymisation guidance is under review following UK legislative changes, so legal teams should confirm the current position rather than treating an architectural pattern as legal advice.

Cloud, private cloud or customer-hosted redaction?

The right location depends on the sensitivity of the raw signal, latency target, regional obligations, operating capability and approved vendors.

Customer-hosted detection can keep raw media, tokens and mappings within the customer environment and on customer-controlled compute. It can suit regulated or sovereign architectures, but the customer must operate detectors, language packs, policy releases and monitoring. Hosting locally does not make an inaccurate detector effective or processing automatically lawful.

Managed cloud services may offer mature detectors, rapid updates and elastic capacity. They can also introduce an additional data processor, network dependency, regional constraint and round-trip latency. The data must be approved to reach that service before it can be redacted there.

Hybrid designs can keep raw audio and the token vault local while sending approved, transformed text to a cloud model. That can reduce exposure without forcing every component on-premise. It also creates more boundaries to test, including explicit AI egress controls.

Yepic can support cloud, private-cloud and custom private or on-premise avatar architectures. The appropriate boundary needs to be scoped around the complete speech, knowledge, reasoning, rendering and action path—not selected from a hosting label alone.

Run twelve production tests

1. Every sensitive data type has a documented purpose, transformation and owner.
2. The processing location of raw audio and other media is explicit.
3. Identifiers split across streaming chunks are detected.
4. Retrieved passages and tool responses are scanned as well as user input.
5. Tokens remain stable only for the scope that needs continuity.
6. The token mapping service is separated from the model.
7. Re-identification requires both workload identity and current user authority.
8. Speech, captions and screen content receive the same output decision.
9. Logs, traces and support bundles exclude prohibited raw content.
10. Tests cover supported languages, accents, noise and domain vocabulary.
11. Detector failure produces a safe response or handover rather than silent bypass.
12. Precision, recall, latency and re-identification controls have repeatable evidence.

Make the control part of the avatar architecture

Yepic’s enterprise avatar work with Abu Dhabi Aviation and Oracle illustrates why the whole delivery path matters: the project covered development and production environments, API and iframe integration, real-time streaming, captions, microphone behaviour, WebRTC and network testing, browser remediation, cybersecurity support and ongoing maintenance. It is evidence of integration and operational experience, not a claim that this customer used the redaction design described here or ran a customer-hosted deployment.

For a new pilot, begin with one page: list the sensitive classes, draw the seven paths, identify where an original value is truly required and make every other component justify seeing it. That turns “we redact PII” from a vendor assurance into a testable system property.