Third-Party AI Risk Management: Map Avatar Responsibilities

Third-party AI risk management for a real-time avatar should begin with one question: who is responsible when a control crosses company boundaries? The answer cannot be “the contract”. A bank or public body may remain accountable for the service while an avatar provider, model supplier, cloud or GPU operator, systems integrator and customer team each perform different parts of the control.

The practical answer is a responsibility boundary for every material service and interface. For each control, name who is accountable, who operates it, who supplies evidence, who must be notified and who can stop the service. Then test the boundary during model change, security incident and provider failure—not just during procurement.

This guide gives regulated buyers a five-party service map, seven control domains, a responsibility record and twelve review questions. It complements an AI bill of materials for avatar dependencies: the bill shows what the release contains; third-party AI risk management shows who must govern each dependency throughout its life.

Start with the service, not the vendor list

An avatar is rarely one supplier and one API. A typical service can combine speech recognition, translation, retrieval, a language model, policy services, voice, rendering, real-time media, identity and business-system connectors. A provider may develop some elements, licence others and operate the assembled service on infrastructure owned by a third party or the customer.

A flat vendor register hides that structure. Build a service graph with at least five possible parties:

• Service owner: the bank, government body or enterprise accountable for the outcome and user relationship.
• Avatar technology provider: the party supplying proprietary avatar, orchestration or video technology.
• Component supplier: a speech, language, retrieval, safety or voice provider whose service or model sits inside the chain.
• Hosting operator: a public-cloud, sovereign-cloud, private-cloud or customer data-centre team operating compute, storage and network services.
• Integrator or managed-service provider: the party connecting identity, knowledge, channels, monitoring and business APIs.

One organisation may occupy several roles. That is acceptable, provided the record describes the role actually performed. “Vendor” is too broad to show whether a party trains a model, hosts weights, applies patches, handles transcripts or merely supplies licensed software.

This is also why on-premise deployment does not remove third-party risk. It changes the boundary. Customer-hosted GPUs may reduce some data-location and infrastructure dependencies while transferring patching, capacity, physical security and recovery duties to the customer. Model licences, update channels and specialist support can remain external.

Use current guidance proportionately

Third-party risk frameworks are converging on a risk-based lifecycle rather than identical treatment for every supplier. On 11 September 2026, the US federal banking agencies issued proposed third-party risk management guidance. It is non-binding and not final, but its stated direction is useful: align effort to the magnitude and likelihood of harm from each relationship, and avoid process-driven treatment that assumes every relationship is inherently high risk.

The Financial Stability Board’s third-party risk toolkit similarly promotes lifecycle controls, identification of critical services and attention to systemic dependencies while recognising differences between jurisdictions. The NIST AI Resource Center provides voluntary AI risk-management and evaluation resources that can help define evidence for AI components.

These are reference points, not a universal compliance recipe. Legal teams should map the exact obligations that apply to the organisation, sector, jurisdiction and deployment.

Assign seven control domains

A useful responsibility model covers the entire operating service. For each domain, record an accountable owner, operating party, evidence provider, notification recipient and stop authority.

1. Data, identity and permitted use

Specify which party defines acceptable data classes, obtains any necessary notices or consents, enforces identity context, filters retrieved knowledge and approves retention. Map whether raw audio, video, transcripts, prompts, retrieved passages and outputs cross the boundary. A statement that “data stays private” is incomplete unless it names the component, location, purpose and deletion rule.

The service owner normally remains accountable for the lawful and appropriate use case. A provider may operate technical controls, but it cannot infer the customer’s complete legal basis, classification policy or user entitlements.

2. Model and component assurance

Record who selects each model, verifies licence rights, tests the use case, approves limitations and tracks the running version. Supplier benchmarks can inform evaluation; they do not replace customer-specific testing across accents, languages, policies, adversarial inputs and consequential actions.

Join this responsibility to the organisation’s AI model risk management process. A component supplier may provide model cards or test results, while the service owner decides whether the composite avatar is acceptable for the intended outcome.

3. Security, secrets and configuration

Allocate responsibility for image provenance, software dependencies, workload identities, secrets, network routes, hardening, vulnerability triage, patches and configuration baselines. The customer may control identity and firewall policy while a provider supplies signed releases and security advisories. The integrator may deploy them. Without a written hand-off, every party can reasonably believe another party rotated the credential or applied the fix.

4. Capacity, latency and availability

Define who forecasts demand, reserves GPU capacity, manages queues, tests network paths and declares reduced-service mode. A sub-second target in one deployment is not a universal guarantee. End-to-end response time includes capture, speech, retrieval, reasoning, voice, rendering and transport, often across several operational owners.

Measure the user-visible service rather than accepting isolated component uptime. A healthy language-model endpoint is not useful if WebRTC cannot establish, captions lag or the business API is unavailable.

5. Change and release management

State which changes require notice, regression evidence and customer approval. Include model versions, voices, avatar assets, prompts, guardrails, retrieval indexes, GPU runtimes, codecs, browsers and dependencies. Set emergency-change rules and a rollback authority.

Do not rely only on semantic version numbers. A hosted service can change behaviour without the customer receiving new binaries. The evidence should identify the effective runtime or service version that actually handled a session.

6. Incident response and forensic evidence

Define the incident clock before an event: who detects, classifies, contains, communicates, preserves evidence and decides whether sessions may resume? Include incidents originating at fourth parties. Notification must carry enough information for the customer to assess impact without requiring the supplier to expose other customers’ data.

Test a scenario in which the avatar provider is healthy but a speech supplier, cloud region or identity service fails. Escalation contacts and evidence routes should work outside ordinary account-management hours.

7. Exit, recovery and retirement

Document how data, configurations, licensed assets, model artefacts, logs and credentials are returned, transferred or destroyed. Identify replacement interfaces and the minimum evidence needed to rebuild or recover the service. Yepic’s guide to AI vendor exit planning explains this migration problem in detail; the responsibility boundary should point to that plan rather than duplicate it.

Create one responsibility record per material service

A conventional RACI chart is a useful start, but real-time AI needs two extra dimensions: evidence and emergency authority. For each control, record:

• Accountable: who accepts the residual risk and outcome.
• Operates: who performs the control day to day.
• Provides evidence: who can prove the control ran and at what version.
• Must be notified: who receives change, failure or incident information, and within what agreed period.
• May stop: who can disable a model, component, action or complete service.

Add the control objective, systems covered, deployment, data classes, evidence artefacts, dependency, testing frequency, fallback and open assumptions. Keep the record versioned and linked to the live architecture. A contract clause that cannot be traced to an operational control, telemetry source or named decision-maker is not yet an implemented control.

Map fourth parties and concentration separately

The supplier named on the purchase order may depend on a cloud, model API, voice provider, content-delivery network or open-source maintainer. Ask for the material dependency chain and the conditions under which it may change.

Then analyse concentration in two directions:

• Service concentration: how many critical customer journeys depend on the same provider, model family, region or GPU stack?
• Provider concentration: which apparently separate suppliers depend on the same underlying cloud, model or network?

A portfolio can look diversified at contract level while sharing one technical failure domain. Conversely, using one provider may be rational if the organisation has strong evidence, tested recovery and bounded use. Count dependencies; do not assume more vendors automatically means less risk.

Deployment choice changes the matrix

Managed public cloud usually gives the provider greater operational control and can simplify updates, scaling and support. The customer needs clear evidence access, data-location terms, dependency disclosure and change notification.

Private or sovereign cloud can place infrastructure and data within a defined jurisdiction or tenant while retaining managed services. Responsibility often becomes more fragmented: the customer may own policy, a cloud operator owns the platform, and the avatar provider owns application releases.

Customer-hosted inference can keep selected models, media and session data inside the customer environment on customer-controlled GPUs, subject to a properly scoped implementation. It also moves capacity planning, platform patching, monitoring and recovery towards the customer. The supplier still needs a secure way to deliver artefacts, advisories and support evidence.

Select the architecture that places each control with a party able to perform and evidence it. “On-premise” is not a substitute for the matrix.

Test the boundary before production

Tabletop reviews are necessary but insufficient. Run three cross-company exercises:

1. Change: a speech or language model version changes. Can the team identify affected services, obtain evidence, test, approve and roll back?
2. Incident: a fourth-party component may have exposed transcripts. Can the parties scope sessions, preserve evidence, contain access and notify the right decision-makers?
3. Failure: the primary provider or hosting region is unavailable. Can the service enter a safe reduced mode, fail over or shut down without misleading users?

Measure elapsed time, missing evidence and ambiguous decisions. Update the responsibility record from the exercise, not just the incident playbook.

Twelve questions for procurement and architecture review

1. Which organisations and fourth parties can process, store or infer from each data type?
2. Who remains accountable for the user outcome and any consequential business action?
3. Who selects, validates, approves and can disable each model or material component?
4. What immutable identifier proves which release or hosted service version handled a session?
5. Which security, configuration and patch controls sit with the customer, provider, host and integrator?
6. What evidence can each party provide without exposing another customer’s information?
7. Which changes require notice, regression testing, approval or rollback?
8. How are fourth-party changes and incidents communicated?
9. Where do apparently different suppliers share the same cloud, model, region or network dependency?
10. Who can suspend one component, block actions or stop the whole avatar service?
11. How do managed cloud, private cloud and customer-hosted options move duties and costs?
12. Has the complete responsibility boundary been exercised under change, incident and failure?

Turn integration experience into governed operation

Yepic’s Abu Dhabi Aviation and Oracle enterprise avatar integration involved separate development and production environments, API and iframe integration, real-time streaming, captions and microphone behaviour, WebRTC and network testing, browser remediation, cybersecurity support and ongoing maintenance. That is useful evidence of the cross-team integration work a live avatar requires.

It is not presented as a completed customer-hosted third-party risk programme. For a private, sovereign or on-premise deployment, Yepic can work with the customer to scope which avatar components run in the customer environment, which dependencies remain external and how operational responsibilities are divided. The result should be explicit enough that architecture, risk, security, procurement and operations teams can test the same boundary.

The production gate is simple: for every material avatar control, can the organisation name the accountable party, the operator, the evidence source, the notification path and the person who can stop the service? If any answer is “the vendor”, the boundary is not yet specific enough.