AI Avatar Data Residency: Map Every Data Flow

AI avatar data residency is not proved by the location of one database. It is proved by tracing every relevant data class through capture, speech recognition, identity, retrieval, language inference, voice synthesis, avatar rendering, media transport, telemetry, support and backup—and documenting where each stage stores, processes and exposes it.

For a bank, government department or regulated enterprise, the useful deliverable is a component-level data-flow register. It should show what crosses each boundary during a normal conversation, a failure, a support incident and an update. “Hosted in the UK”, “private cloud” or “zero retention” may be useful statements, but none describes the complete system.

This guide provides a practical map for architecture, security, risk and procurement teams evaluating a real-time AI avatar.

Start with five separate residency questions

Residency conversations often combine controls that need different evidence. Ask five questions for every data class and component.

1. Where is data stored?

Include primary databases, object stores, vector indexes, caches, transcripts, recordings, logs, backups and disaster-recovery copies. A service can store its main data in one region while diagnostic logs or replicated backups sit elsewhere.

2. Where is data processed?

Real-time audio may exist only for seconds, yet still be processed by a speech service in another jurisdiction. Text may be sent to a language model without being written to a conventional database. Residency therefore covers data in use as well as data at rest.

3. Who can access it, and from where?

Customer administrators, supplier operations staff, cloud operators and subprocessors may have different access paths. Geographic storage does not by itself restrict remote administration or support access.

4. What leaves through support and operations?

Crash dumps, traces, screenshots, packet captures and support bundles can contain prompts, tokens, document fragments or identifiers. Treat the support path as a data export, not an exception to the architecture.

5. Can data be reused?

Separate service delivery from model training, evaluation, product improvement and human review. A contractual “not used for training” commitment answers an important purpose question; it does not answer processing location, retention or support access.

Microsoft’s current EU Data Boundary documentation makes this distinction visible: its commitments cover storage and processing for specified services, while also documenting limited transfer circumstances. Every provider and component will have its own terms, so buyers should verify the actual service rather than infer from a cloud region.

Map eight data classes through the avatar pipeline

A real-time avatar is a chain of services, not one model. The following eight classes should appear separately in the data-flow register.

1. Raw media: microphone audio, optional camera frames, voice-activity signals and temporary media buffers.
2. Conversation content: partial and final transcripts, prompts, model responses, captions and conversation history.
3. Identity and session data: user identity, roles, entitlements, device information, session identifiers and authentication tokens.
4. Enterprise knowledge: source documents, database results, embeddings, retrieved passages, citations and permission metadata.
5. Generated media: synthesised speech, phoneme or timing data, animation controls, rendered frames and encoded video.
6. Avatar assets: licensed source footage, voice assets, visual models, persona configuration and pronunciation dictionaries.
7. Operational evidence: latency, error codes, GPU metrics, safety events, audit decisions, traces and support artefacts.
8. Software and model supply chain: model weights, containers, drivers, licences, update manifests and configuration packages.

The NCSC’s secure AI development guidance recommends identifying and tracking models, data, prompts, software, logs and assessments, knowing where those assets reside and treating logs as sensitive. That is a useful minimum for the register.

Draw the normal path and the side paths

The main interaction path is straightforward to sketch:

Client or kiosk → media gateway → speech recognition → identity and policy → retrieval → language model → safety controls → text-to-speech → avatar renderer → real-time media transport → client.

Now add the side paths that are commonly missed:

• telemetry emitted by every component;
• content filters or moderation APIs;
• licence and entitlement checks;
• knowledge ingestion and permission synchronisation;
• model, voice and avatar-asset downloads;
• backups and failover regions;
• support access, crash reporting and screen sharing; and
• cloud fallback when a local component is unavailable.

The restricted-network design guide shows how small dependencies such as browser assets, registries and licence checks can undermine an otherwise private runtime. The same discipline applies when the requirement is regional rather than fully disconnected.

Build a data-flow register that procurement can test

A diagram explains the design; the register makes it reviewable. Create one row for every meaningful combination of data class and processing step. At minimum, record:

• data class and example fields;
• purpose and lawful or policy basis;
• source, destination and component owner;
• storage location and processing location;
• normal, failover and support routes;
• subprocessor and administrative-access location;
• encryption and key owner;
• retention trigger and deletion method;
• backup, cache and recovery treatment;
• training, evaluation and human-review status;
• contractual evidence and technical verification; and
• named customer and supplier owners.

A statement such as “transcripts are not retained” should become several testable rows: partial speech buffers in memory, final transcript in session context, transcript fragments in safety logs, error payloads in telemetry and any text copied into a support case.

Use a retention ladder, not one global period

Different records serve different purposes. A defensible architecture selects the lowest retention level that still meets the service requirement.

1. In-memory only: data exists during processing and is released when the request or session ends.
2. Transient buffer: short-lived media or text supports streaming, retries or interruption handling.
3. Short diagnostic window: tightly controlled content is retained temporarily for an approved investigation.
4. Governed interaction record: selected evidence is retained for audit, complaint handling, safety or a business process.
5. Required archive: a defined legal, regulatory or records-management requirement justifies longer retention.

Do not assign all transcripts, recordings and logs the same period merely because it simplifies configuration. The ICO’s storage-limitation guidance says organisations should justify how long personal data is retained, set standard periods where possible, review them and erase or anonymise data that is no longer needed. It does not prescribe one universal period.

Deletion testing must include searchable indexes, caches, exports and restored backups. Taking a record offline is not the same as deleting it. Where immediate removal from an immutable backup is impractical, document how the data is put beyond use and how deletion is re-applied after restoration.

Four ways a private design can quietly leak

Cloud fallback

A locally hosted speech or language component may switch to a managed endpoint during overload or failure. Failover is part of the data boundary. If the alternative route is not approved, the safer behaviour may be degraded service or human handover.

Content-rich telemetry

Prompts, transcripts and retrieved passages make debugging easier, but they can turn an observability platform into a second conversation store. The private observability framework separates content from service, model, infrastructure and security signals so most monitoring can remain useful without routine conversation export.

Support bundles

An engineer may request a recording or database extract to reproduce a fault. Require an approved purpose, minimised dataset, secure transfer, named recipients, expiry and deletion evidence. Synthetic test sessions should be the default where they can reproduce the problem.

Secondary knowledge copies

Retrieval-augmented generation may copy documents and permissions into an index. That index, its embeddings and backups have their own residency and deletion requirements. See the permission-aware RAG architecture for copied, live and hybrid retrieval patterns.

Choose deployment by the required boundary

Customer-hosted inference can give a regulated organisation direct control over compute, networks, keys, logs and data access. It can keep the full conversational path inside the customer environment when every selected component supports that architecture. It also transfers capacity, patching, monitoring, recovery and hardware responsibilities to the customer and supplier.

A private cloud can provide dedicated resources, controlled networking and regional placement without customer-owned hardware. Buyers still need to establish operator access, connected services, backup locations and external control-plane dependencies.

Public cloud is often the most practical option for a fast pilot, geographically distributed users or volatile demand. Strong contractual residency, retention and access controls may satisfy the use case. The right choice follows the classification and operating model, not an assumption that one deployment is always more secure. Yepic’s deployment-model comparison sets out the wider trade-offs.

Verify residency in production-like conditions

Contractual evidence is necessary, but architecture teams also need technical tests:

1. Capture outbound DNS, IP and protocol activity for a complete session.
2. Repeat the test during startup, scaling, failover, recovery and update.
3. Inspect logs, traces, error payloads and support bundles for content fields.
4. Use synthetic sensitive data with unique markers and search every permitted store.
5. Disable an external dependency and confirm the service follows its approved degradation path.
6. Delete a session and verify removal from indexes, caches, exports and restored backups according to policy.
7. Exercise supplier support and record exactly what an engineer can see and export.
8. Compare observed flows with contracts, subprocessor lists and the data-flow register.

Network capture alone cannot prove that a remote service does not retain data. A contract alone cannot prove that an undocumented endpoint is never called. Use both forms of evidence.

What Yepic’s enterprise work demonstrates

In the Abu Dhabi Aviation and Oracle enterprise avatar integration, authorised users could query operational information through a role- and clearance-aware layer, receive charts and hear results narrated by a real-time avatar. Delivery included separate development and production environments, APIs and iframe integration, streaming, captions and microphone behaviour, WebRTC and corporate-network testing, browser remediation, cybersecurity support and ongoing maintenance.

That is relevant evidence for governed enterprise integration and production data paths. It is not presented as proof of a completed customer-hosted deployment or of the exact residency architecture in this guide. Yepic can scope cloud, private-cloud and customer-hosted avatar systems, including deployment on customer GPUs, but component placement, hardware, network, support and governance must be validated for each implementation.

Twelve questions for the architecture review

1. Which raw media, content, identity, knowledge, asset and telemetry fields exist?
2. Where is each field processed, even when it is never stored?
3. Where do live, cached, backed-up and failover copies reside?
4. Which administrators and subprocessors can access each copy, and from where?
5. Do support and incident routes follow the same approved boundary?
6. Can any component fall back to an unapproved region or public endpoint?
7. Which content is used for training, evaluation, moderation or human review?
8. What retention purpose and trigger applies to each data class?
9. How are deletion and permission revocation propagated to indexes and backups?
10. Which model, licence, registry and telemetry dependencies require outbound access?
11. What technical evidence proves the diagram matches deployed behaviour?
12. Who owns the register after go-live and approves every material change?

Make residency a demonstrable system property

Begin with one bounded workflow and one representative conversation. Trace every field through normal operation, failure, support and deletion. Mark any unknown location or access path as an open risk, not a blank cell.

A credible private AI avatar architecture does not promise that “data stays here” as a single sentence. It shows what data exists, why it moves, where it is processed, who can see it, how long it survives and what evidence will prove those answers after the system changes.