AI Bill of Materials: Inventory Every Avatar Dependency

An AI bill of materials (AI BOM) for a real-time avatar should be a versioned relationship map, not a spreadsheet dump. It should identify the exact models, datasets, software, services, infrastructure, configurations, licences and identity rights required to operate a particular release. It should also show how those elements depend on one another, who owns them and what must happen when one changes.

That gives architecture, security, procurement and operations teams a shared answer to a practical question: what are we actually running? Without it, an organisation may know which avatar platform it bought but not which speech model handled a citizen's voice, which GPU runtime rendered the response, whether an external API was called, or whether a voice licence still permits that use.

The concept is becoming more concrete. In May 2026, the G7 Cybersecurity Working Group published minimum requirements for an AI software bill of materials. CycloneDX supports machine-learning models, datasets, configurations and provenance, while SPDX provides an ISO-standardised format for software, AI, data and security references. These are useful foundations, but an avatar system needs an inventory shaped around its full conversational and media pipeline.

Why a normal SBOM is not enough

A conventional software bill of materials records packages, libraries and dependencies. That remains essential: a vulnerable transitive library can affect an AI service just as it affects any other application. UK government supply-chain guidance recommends combining an SBOM with continuous monitoring and keeping the inventory current when components change.

But a real-time avatar is more than application code. A single conversation can pass through microphone capture, voice-activity detection, speech recognition, language routing, retrieval, a language model, safety rules, text-to-speech, a licensed voice, animation, video encoding, WebRTC delivery and browser or kiosk software. It may use several GPU-accelerated runtimes and call internal or external services.

Each layer can introduce a different failure, data flow, licence condition or update cycle. That is why an avatar AI BOM must sit alongside the component architecture for an on-premise avatar stack, not replace it. The architecture explains how the system should work; the BOM records exactly what was approved and deployed.

The ten layers an avatar AI BOM should cover

1. System and release identity

Start with an unambiguous name, release identifier, intended purpose, deployment environment and approval status. State whether the record covers development, test, production or disaster recovery. A BOM labelled simply “customer-service avatar” becomes useless as soon as two versions exist.

2. Model artefacts

Record every model, including speech recognition, language, moderation, translation, voice, emotion or expression control, animation and rendering. Capture the supplier or source, exact version, cryptographic hash where available, weights or adapter reference, tokenizer and model-card location. Distinguish a base model from a fine-tuned derivative.

3. Speech, voice and visual identity

An avatar's identity has dependencies that an ordinary AI application does not. Record the voice asset, likeness or character asset, pronunciation dictionaries, gesture profiles and rendering configuration. Link each asset to its consent, permitted purpose, territory, channel, expiry and revocation record. The BOM should reference controlled evidence rather than copying sensitive identity documents into a widely shared file.

This operational link matters because avatar consent, disclosure and provenance can change independently of software. A technically unchanged release may still need to stop if a right expires or is withdrawn.

4. Data and knowledge references

List the datasets and knowledge sources used to train, fine-tune, evaluate or ground the system. Record provenance, owner, permitted use, version and quality evidence. For retrieval-augmented generation, include the index, embedding model, source collection, access-control method and last synchronisation point.

Do not put raw training data, conversation content or personal data in the BOM. The inventory should identify the governed source and evidence location, with access controlled separately.

5. Application software and containers

Include orchestration services, APIs, user interfaces, safety services, media servers, containers, operating packages and transitive libraries. Where an established SBOM format already captures these dependencies, link or embed that artefact rather than duplicating it manually.

6. GPU and runtime infrastructure

Record the approved operating system, GPU family, driver, accelerator libraries, inference server, container runtime and orchestration version. These are not background details. A driver or runtime change can alter compatibility, performance and even output behaviour without changing the application version.

7. Services, APIs and media paths

Identify every internal and external call: identity, knowledge, logging, speech, language, translation, monitoring and human-handover services. Include API version, data classes handled, network destination, authentication method reference and fallback behaviour. Record WebRTC signalling, relay and media dependencies separately from ordinary HTTPS traffic.

8. Configuration and policy

Prompts, routing rules, safety policies, confidence thresholds, language settings and feature flags can materially change the service. Give them versioned identifiers and hashes. Never place passwords, tokens, private keys or other secrets in the BOM; reference the secret-management location and rotation owner instead.

9. Licences and contractual rights

Software licences are only one part of the picture. Capture model terms, dataset restrictions, voice and likeness rights, open-source obligations, commercial-use limits and any constraint on geography, sector, concurrency or deployment model. A component may be technically portable but contractually restricted from customer-hosted use.

10. Operational ownership and limitations

For each material dependency, record the business owner, technical owner, supplier, support status, end-of-life date, known limitations, monitoring source, update route and rollback route. This turns an inventory into an operational control rather than a static compliance attachment.

Model the relationships, not just the rows

A useful AI BOM can answer more than “is component X present?” It should express relationships such as depends on, fine-tuned from, trained with, evaluated against, calls, renders, protected by, licensed under and deployed to.

Consider a voice update. The relationship map should show which languages use that voice, which text-to-speech model produces it, which avatar identities are authorised to use it, which evaluation suite covers it and which production releases contain it. Security can then scope an incident, procurement can check rights and operations can plan a rollback without searching five disconnected registers.

At minimum, each record needs:

• a unique component reference and exact version or hash;
• supplier, source and evidence location;
• licence, consent or rights reference;
• upstream and downstream relationships;
• data classes processed and deployment locations;
• business owner, technical owner and support status;
• update, rollback and end-of-life route; and
• last verification date and approved environment.

Maintain three views of the truth

One document cannot serve every stage equally well. A governed programme should maintain three connected views.

1. Design BOM: the components and relationships proposed during architecture and procurement review.
2. Release BOM: an immutable, signed snapshot generated for the exact build approved for deployment.
3. Runtime inventory: observed components, versions, services and infrastructure in each environment, compared continuously with the approved release.

The difference between the release and runtime views is drift. An emergency patch, changed endpoint, replaced container or altered prompt should create a visible exception. The organisation can then approve the change, roll it back or restrict service while it investigates. The release and rollback process for on-premise avatars should therefore update the BOM as part of the same change, not as later documentation.

Use the BOM throughout the service lifecycle

During procurement, require suppliers to state what they can disclose, in which format, at what depth and how quickly they will notify customers of changes. A list produced once during due diligence is not enough.

During build and release, generate machine-readable software and model inventories from the pipeline where possible. Add the human-governed records—purpose, rights, evaluation and ownership—then bind the result to the release identifier.

During operations, compare observed runtime state with the baseline. During an incident, query the graph to find affected deployments, data flows and owners. During decommissioning, use it to remove endpoints, credentials, cached artefacts, model copies and identity assets. A well-maintained inventory also supports the exit plan for an avatar supplier or component.

Cloud and on-premise deployments need different evidence

Customer-hosted deployment can provide deeper inspection of containers, models and GPU runtimes, but it also transfers more patching, monitoring and inventory ownership to the customer. Public or private cloud services may reduce that operational burden while exposing less of a provider's internal supply chain.

Neither model is automatically better. The BOM should make the boundary explicit. For a managed component, record the service version, supplier commitment, data path, region, subprocessor evidence, change-notification terms and exit route. For a customer-operated component, record the exact artefact, infrastructure compatibility, owner and maintenance process.

On-premise hosting does not create a complete inventory by itself. Equally, a supplier need not disclose proprietary weights or trade secrets to give a buyer useful component identity, provenance, risk, rights and change information. The disclosure depth should be risk-based and contractually agreed.

What enterprise delivery teaches about dependency mapping

Yepic's enterprise avatar integration with Abu Dhabi Aviation and Oracle covered development and production environments, API and iframe integration, streaming, captions, microphone behaviour, WebRTC and corporate-network testing, browser remediation, cybersecurity support and ongoing maintenance. That is evidence of why the dependency boundary extends from AI models into media, network, interface and operating environments.

It is not evidence that this project used a formal AI BOM or was customer-hosted. Yepic's private, sovereign and customer-hosted deployments are properly scoped custom implementations: the exact inventory depends on the chosen speech, language, voice and rendering components, the customer's GPUs, licences and operating model.

Twelve questions for an architecture or procurement review

1. Does the BOM identify a specific release and environment?
2. Does it cover models, data references, software, services and infrastructure?
3. Are base models, fine-tunes, adapters and tokenizers distinguishable?
4. Can reviewers trace voice and likeness assets to valid rights?
5. Are direct and transitive software dependencies included?
6. Are GPU drivers and inference runtimes versioned?
7. Does it show external calls, media relays and data classes handled?
8. Are prompts, policies and feature flags versioned without exposing secrets?
9. Can the team compare the approved release with observed runtime state?
10. Who updates the BOM after an emergency patch or supplier change?
11. Can an incident team find every affected deployment quickly?
12. Will the inventory remain usable during migration or supplier exit?

Make the inventory a release requirement

The best time to request an AI bill of materials is before procurement closes. Specify the required scope, relationship depth, format, delivery frequency, confidentiality controls and change-notification process. Then make a release-specific BOM—and evidence that runtime matches it—an acceptance criterion for production.

For a private real-time avatar, the result should let security, architecture, risk and operations look at the same dependency map and reach the same conclusion about what is running, why it is permitted and who must act when it changes. That is the difference between possessing an inventory and governing a system.