Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
Compliance›AIBOM

You know what code you ship. Do you know what models?

An AI Bill of Materials inventories every AI model, dataset, and ML dependency your software uses — including fine-tuned weights, third-party model APIs, and embedded inference engines. Required for EU AI Act compliance.

Generate your AIBOM See capabilities
AI Model Inventory
4 models detected
gpt-4oAPI · OpenAICustomer-facing chat
Limited risk
llama-3-8b-instructLocal · Meta (self-hosted)HR screening tool
High risk
text-embedding-3-largeAPI · OpenAISemantic search
Minimal risk
whisper-large-v3Local · OpenAI (self-hosted)Transcript generation
Minimal risk

✓ EU AI Act Article 13 transparency obligations mapped for 4 systems

AI MODEL INVENTORY

Every AI model in your stack. Classified and inventoried.

Discovers every AI model — local inference, embedded engines, third-party APIs — and classifies each under EU AI Act risk tiers.

AI models loaded from disk or embedded
Third-party APIs (OpenAI/Anthropic/Hugging Face) as declared deps
High/limited/minimal risk classification per model
Continuous discovery as new models are integrated
O3 ·AI Model Inventory
4 models detected
ModelTypeProviderRisk
gpt-4oAPIOpenAILimited
llama-3-8b-instructLocalMetaHigh
text-embedding-3-largeAPIOpenAIMinimal
whisper-large-v3LocalOpenAI self-hostedMinimal
✓ EU AI Act Article 13 transparency obligations mapped for all 4 systems
TRAINING DATA LINEAGE

Know what data trained every model. And who fine-tuned it.

Records datasets used to train or fine-tune each model — version, source, data governance declarations, and the full provenance chain from base model to fine-tuned weights.

Dataset source and version for every training run
Fine-tuned weight chain (base → adapted → deployed)
Training framework and compute provider recorded
Data quality and bias disclosures linked to model record
O3 ·Weight Provenance — llama-3-8b-instruct
Provenance chain
Base model
meta-llama/Llama-3-8B
Source: Hugging Face · License: Apache 2.0
v1.0
fine-tuned ↓
Fine-tune step
Fine-tuned by:Acme Corp Internal
Dataset:HR-decisions-v2.1
Framework:QLoRA / PEFT
Compute:AWS p4d.24xlarge
deployed as ↓
Deployed
llama-3-8b-instruct
Used in: HR candidate screening workflow
High Risk
⚠ HR screening tool — EU AI Act Article 6(2) high-risk classification applies
EU AI ACT COMPLIANCE

Transparency obligations. Automatically documented.

Generates structured compliance evidence for EU AI Act requirements — transparency obligations, human oversight documentation, and risk system classification for every high-risk model.

Article 13 transparency obligations mapped per model
High-risk system technical documentation auto-generated
Human oversight mechanism documentation
Post-market monitoring plans tracked
O3 ·EU AI Act Checklist — llama-3-8b
High Risk System
Risk classification documented (High-risk — Annex III, §4)Done
Technical documentation — model architecture and training methodologyDone
Training dataset lineage and data governance declarationDone
Human oversight mechanism implemented and documentedDone
Accuracy, robustness, and cybersecurity measuresPending
Conformity assessment procedure completedPending
Post-market monitoring plan establishedPending
THIRD-PARTY API MAPPING

External model calls are dependencies. Treat them like one.

Maps every outbound call to external model APIs and records them as declared dependencies with SLA, data residency, and version pinning information.

OpenAI, Anthropic, Hugging Face, Cohere APIs mapped
Model version and API endpoint recorded
Data residency and retention policies captured
Dependency alert when API provider updates model
O3 ·External Model API Map
3 providers
Outbound API calls
openai.com/v1/chat/completions200ms p95
gpt-4oCustomer chatUS-East
openai.com/v1/embeddings
text-embedding-3-largeSearchUS-East
api.anthropic.com/v1/messages
claude-3-haikuInternal botUS
✓ All external model calls versioned and tracked in AIBOM manifest
AIBOM, explained

What is an AI Bill of Materials (AIBOM)?

An AIBOM is a list of every AI part your software relies on: the models it loads or calls, the datasets those models were trained on, the fine-tuned weights you produced, and the ML libraries in your dependency tree. If you have shipped an SBOM before, the idea is the same — write down what is actually in the system so you can answer questions about it later.

The reason it gets its own name is that AI components do not behave like normal packages. A model can be a file on disk, a weight checkpoint in a bucket, or an HTTP call to someone else’s API. A plain dependency scanner walks past all three. An AIBOM is the artifact that records them in one place.

AIBOM vs SBOM: what is the difference?

An SBOM covers your software packages — the npm, PyPI, and Maven dependencies, their versions, and their licenses. It does not know that a function quietly calls openai.chat.completions, or that a 4 GB file in your repo is a fine-tuned Llama checkpoint.

An AIBOM fills that gap. It captures the model layer an SBOM cannot see: which models, from which providers, trained on what, used where. Most teams keep both — the SBOM for the code supply chain, the AIBOM for the AI supply chain — and O3 produces them from the same scan.

Does the EU AI Act require an AIBOM?

The Act does not use the word “AIBOM,” but it asks for exactly what one contains. Providers of high-risk systems have to keep technical documentation describing the models, the training data, performance, and risk measures. An AIBOM is the structured version of that paperwork — and it is far easier to keep current than a document someone edits by hand. See how it maps to the EU AI Act and the broader BOM compliance requirements.

How do you generate an AIBOM?

O3 reads your codebase the way a reviewer would. It picks up AI library imports, model config and environment variables, weight files, and the outbound API calls your code makes at runtime. Each one becomes a recorded entry with its provider, version, and where in the app it is used.

It runs in CI — GitHub Actions, GitLab, Jenkins, or the CLI — so the AIBOM regenerates on every build instead of going stale the moment someone adds a new model. You get the inventory, the provenance chain for anything you fine-tuned, and a risk tier per system, without a separate documentation project.

Explore the full O3 BOM Suite

One platform for every bill of materials — software, cryptographic, AI, hardware and quantum — unified for supply-chain visibility and compliance.

FAQ

Questions,
answered.

Everything teams ask before rolling this out. Still stuck? Reach our team.

  • An AI Bill of Materials (AIBOM) is a structured inventory of every AI component in a software system, including AI models (local and API-accessed), training datasets, fine-tuned weights, and ML framework dependencies. Like an SBOM for traditional software, an AIBOM provides transparency into the AI supply chain and is required for EU AI Act compliance documentation.
  • The EU AI Act (effective August 2024, with obligations phasing in through 2026) requires providers of high-risk AI systems to maintain technical documentation covering model specifications, training data, performance metrics, and risk management measures. An AIBOM is the structured artifact that satisfies these documentation requirements and provides evidence for conformity assessments.
  • O3 scans source code for AI library imports (transformers, torch, tensorflow, openai, anthropic, etc.), configuration files, environment variables referencing model endpoints, and runtime API call patterns. It detects both locally loaded model weights and outbound calls to third-party model APIs, recording each as a declared AI dependency with its provider, version, and use context.
  • O3 classifies AI systems according to EU AI Act risk tiers: Unacceptable risk (prohibited), High-risk (Annex III systems including biometric identification, employment screening, credit scoring, law enforcement), Limited risk (systems with transparency obligations like chatbots), and Minimal risk (all other AI). Classification is based on the system's intended purpose and deployment context.
  • Yes. O3 records the full provenance chain for fine-tuned models: the base model (including provider, model card, and license), the fine-tuning dataset, the training framework and version, and the output weight checkpoint. This chain is required for EU AI Act technical documentation and is also useful for internal model governance and audit.