Air-Gapped AI Avatars: Restricted-Network Design Guide

An AI avatar can operate without internet access only when every runtime dependency has been made local. That means more than placing the visual renderer on a customer-owned GPU. Speech recognition, the language model, knowledge retrieval, text-to-speech, identity, session control, licences, monitoring and browser assets must either run inside the approved boundary or be deliberately removed from the experience.

This is possible for appropriately scoped systems, but it is not a universal switch labelled “air-gap mode”. A cloud-first avatar can remain dependent on external model registries, voice services, telemetry endpoints or licence checks even when its main application is installed on-premise.

For banks, governments and regulated enterprises, the first design decision is therefore not which GPU to buy. It is which network boundary the service genuinely requires, which capabilities must survive inside it and how updates will cross that boundary safely.

On-premise, restricted and air-gapped are not interchangeable

Teams often use “on-premise” to describe several materially different architectures. A useful review starts by naming the actual network condition:

1. Customer-hosted with normal egress: the avatar runs on customer infrastructure but can call approved internet services.
2. Allowlisted egress: outbound traffic is limited to named APIs, registries, identity providers or monitoring endpoints.
3. Brokered or one-way exchange: the runtime has no direct internet access, but approved data or updates move through a controlled intermediary.
4. Disconnected environment: the production network has no routine external connection, although an authorised transfer process exists.
5. Strict air gap: there is no electronic network path across the boundary; software, models and evidence move only through a separately governed process, potentially using controlled physical media.

These are not ascending product tiers. They are risk choices. Strict isolation may be justified for classified, defence-adjacent or critical environments, but it increases the operational burden. An allowlisted or brokered design can be more maintainable for many regulated services while still preventing conversation content from reaching public endpoints.

Yepic’s deployment-model comparison explains the broader cloud and private-infrastructure trade-offs. Government teams can also use the sovereign AI avatar framework to assess data, infrastructure, model, operational, governance and language control. The restricted-network question goes one level deeper: what breaks when external connectivity is removed?

Build a runtime dependency map before promising offline operation

A real-time avatar is a chain of services. Put every component into one of three columns: required locally, permitted through a controlled connection or not available in this mode.

Conversation and media

• microphone and camera capture;
• voice activity and turn detection;
• automatic speech recognition;
• retrieval, orchestration, LLM inference and tool calls;
• text-to-speech, pronunciation dictionaries and voices;
• avatar animation, rendering and video encoding;
• real-time media transport, signalling and client playback.

Control and security

• user identity, roles and service accounts;
• secrets, certificates, time synchronisation and internal DNS;
• content policies, approved prompts and moderation rules;
• licence validation and entitlement checks;
• audit logging, metrics, traces and alerting.

Software supply chain

• container images and package repositories;
• GPU drivers, runtimes and operating-system dependencies;
• model weights, tokenisers, voice and avatar assets;
• web fonts, JavaScript, media libraries and other client assets;
• vulnerability intelligence, patches and rollback artefacts.

This map exposes hidden calls before they become production incidents. Common examples include a browser fetching a font from a public content-delivery network, a speech component checking a cloud entitlement, a container attempting to pull at restart or a support library uploading a crash report.

Official NVIDIA guidance illustrates the infrastructure issue clearly. Its air-gapped GPU Operator documentation explains that disconnected clusters may need local image registries and package repositories because installation would otherwise pull containers and operating-system packages from the internet. The same principle applies to the complete avatar stack.

A reference architecture for a disconnected AI avatar

A practical design can be divided into four zones. The exact technologies will vary, but the responsibilities should remain explicit.

1. Interaction edge

Kiosks, browsers, workstations or room systems capture speech and display the avatar. Client assets are served locally. Device configuration, microphones, cameras, accessibility controls and real-time media behaviour are tested under the same policies used in production.

2. Application and inference zone

Session orchestration, speech recognition, retrieval, the selected language model, speech generation, avatar rendering and encoding run on approved compute. Components may share GPUs or use separate pools depending on latency, isolation and capacity requirements.

The Yepic GPU capacity-planning framework shows how to establish validated session density and failure reserve. In a disconnected design, reserve matters more because public-cloud bursting is normally unavailable.

3. Data and security services

Approved knowledge sources, vector indexes, conversation policies, identity, secrets, certificates, audit stores and monitoring remain inside the chosen boundary. Access should follow the service’s existing authorisation model rather than creating a parallel identity system solely for the avatar.

4. Transfer and maintenance zone

A controlled staging area receives proposed software, model, knowledge and policy updates. Artefacts are inventoried, scanned, verified, tested and approved before entering production. Operational evidence leaving the environment follows a separate export policy.

NVIDIA’s current NIM air-gap guidance uses a two-phase pattern: prepare assets on a connected machine, then transfer and run them from local storage without remote registries. This is a useful pattern, not proof that every speech, avatar or enterprise component automatically supports the same deployment.

The update process becomes part of the product

An isolated service cannot be treated as a sealed appliance that never changes. GPU drivers, operating systems, libraries, speech models, language models, avatar runtimes, knowledge and security policies all have different release cycles.

A defensible update path should include:

1. Prepare: assemble the exact release in a connected build environment.
2. Inventory: record software, models, prompts, data assets, dependencies and versions.
3. Verify: scan artefacts, record cryptographic hashes and validate signatures from trusted sources.
4. Transfer: move the approved package through the customer’s authorised channel.
5. Quarantine and test: inspect the package again inside a staging zone and run security, safety, language and performance regression tests.
6. Deploy gradually: drain or isolate capacity, update a controlled node and compare it with the previous version.
7. Roll back: preserve a known-good release and the evidence needed to restore it.
8. Record: update the authoritative configuration and change record.

The NCSC’s secure AI development guidance recommends tracking models, data, software, prompts and logs, protecting the supply chain and documenting artefact hashes or signatures, retention and failure modes. Its guidance on secure updates also stresses verifying that an update came from a trusted source and was not altered.

Isolation changes the route by which an update arrives; it does not remove the need to patch vulnerabilities promptly. Procurement should establish who prepares releases, which dependencies are covered, how urgent fixes are handled and what happens when a component reaches end of support.

Monitor the service without exporting conversations

Air-gapped does not mean unobservable. Architecture teams still need to detect queue growth, model failures, malicious inputs, abnormal resource use and changes in response behaviour.

Keep operational metrics, traces and security logs locally. Separate them from raw audio, camera frames, transcripts and retrieved content wherever possible. Useful operational records can include:

• request and session identifiers;
• per-stage latency, queue depth and error category;
• GPU, CPU, memory, encoder and network utilisation;
• component, model, prompt and knowledge-base versions;
• authentication, configuration and administrative events;
• fallback, reset and human-handover events.

The NCSC advises treating AI logs as sensitive assets and monitoring behaviour, inputs and performance for compromise or drift. That does not require retaining every conversation indefinitely. Retention should follow a documented purpose, access model and deletion schedule. Where support evidence may leave the boundary, define an approved, minimised export format before go-live.

Why an air gap is not automatically safer

Removing external network paths can reduce exposure and prevent routine data egress. It can also create different risks:

• patches and threat intelligence may arrive more slowly;
• removable media and transfer workstations become high-value controls;
• local administrators may gain broader privileges;
• supplier support and incident diagnosis become harder;
• capacity cannot fail over to an external service;
• stale models or knowledge may produce incorrect answers;
• security teams may receive less central visibility.

The correct comparison is therefore between complete operating models, not between “connected equals risky” and “disconnected equals secure”. The best boundary is the least restrictive architecture that still satisfies the organisation’s threat model, data policy and service obligations.

Acceptance tests for a restricted-network deployment

Before procurement approval or go-live, ask the delivery team to demonstrate the following in the proposed environment:

1. Block every unapproved outbound route and complete representative conversations.
2. Restart clients, services and GPU nodes without access to public registries or package repositories.
3. Switch between required languages, voices and avatar identities using only local assets.
4. Authenticate users and enforce role boundaries during an identity-service interruption.
5. Update approved knowledge without replacing the whole system.
6. Revoke a certificate, secret or administrator and verify the effect.
7. Lose one compute node and confirm the agreed degraded experience.
8. Apply a signed update in staging, reject a tampered package and roll back the accepted release.
9. Restore the service and its configuration from approved backups.
10. Investigate a simulated incident using local logs without exporting conversation content.
11. Confirm that clocks, certificates and licence conditions remain valid for the planned disconnection period.
12. Document every unavailable cloud-dependent feature rather than allowing silent failure.

These tests should be paired with user and network testing. Yepic’s work with Abu Dhabi Aviation and Oracle included dedicated development and production environments, real-time streaming, captions, microphone behaviour, browser remediation, WebRTC and corporate-network testing. See how the enterprise avatar integration was tested. It is relevant integration evidence, but it should not be described as a completed air-gapped deployment.

Where Yepic fits

Yepic has spent years developing proprietary talking-photo and real-time avatar technology, optimising inference for commercial GPUs and integrating multilingual avatar experiences with enterprise systems. A customer-hosted or sovereign implementation can be designed around local components and customer-controlled infrastructure where the use case, hardware and licences permit.

Restricted-network and air-gapped support must nevertheless be scoped as a custom implementation. Yepic should not promise that every language, voice, model, integration or support workflow will operate in every isolated environment without engineering and acceptance testing.

The useful first deliverable is a disconnected-operation dossier: network classification, dependency map, local asset manifest, data flows, capacity plan, update route, observability model, failure behaviour and acceptance tests. That gives security and architecture teams something concrete to approve—and prevents “on-premise” from becoming a vague promise discovered too late.