You have a software bill of materials for licences and CVEs. It cannot answer the questions your board and your regulator have started asking: where does our software call AI, whose models, and where does the data go?
An AI Bill of Materials is the AI-specific layer a conventional SBOM misses: which models and providers your code calls, which agent frameworks it constructs, every inference call site, what model output can reach (execution, filesystem, network), and where data egresses — including to which jurisdictions. It covers your own code and your dependencies, because a transitive package that calls a model is part of your AI surface whether you chose it or not.
Three pressures arrive together. Regulation: the EU AI Act expects organisations to know and document where AI sits in their systems. Governance: boards asking "where do we use AI?" currently get answers assembled from memory and vendor claims. Security: code that executes model output is the mechanism by which prompt injection — OWASP's top risk class for LLM applications — becomes arbitrary code execution, and you cannot review the risk you haven't located.
The honest way to build the inventory is from the artifact itself: static analysis of imports, dependency manifests, call sites and data flow. Deterministic — the same codebase produces the same AI-BOM every run — and current, because it regenerates on every scan rather than decaying in a spreadsheet.
CodeDelta emits an AI-BOM in its native format or CycloneDX (the industry SBOM standard) from the same scan that measures churn and finds embedded agents, with an optional policy gate: block the merge when code starts calling an unapproved provider or model output reaches execution. Runs in CI or as a GitHub Action, entirely inside your own infrastructure. Generate one for a repository you own — it is one command, and the first one is usually a surprise.