The AI Bill of Materials Arrives: Shadow AI, k8s-aibom, and Provable Compliance

You cannot govern an inventory you do not have. Most enterprises running AI in production cannot answer the first question a regulator will ask: which models, agent frameworks, and vector stores are live in our clusters right now, and can we prove it six months from now? Google open-sourced its answer in July 2026. k8s-aibom generates an AI Bill of Materials directly from a running Kubernetes cluster, without privileged access, and writes it to a record that cannot be altered after the fact.

Per Google Cloud’s announcement, k8s-aibom scans Deployments, StatefulSets, DaemonSets, Jobs, and KServe resources. It identifies AI runtimes such as vLLM, Triton, and Ollama. It finds agent frameworks including LangChain, AutoGen, and CrewAI. It catalogs vector stores like Milvus, Qdrant, and pgvector. The output is a CycloneDX 1.6 ML-BOM, the same machine-readable format the software supply-chain world already treats as the standard for describing what a system is built from.

The name is deliberate. A Software Bill of Materials became mandatory infrastructure after Log4Shell and the US executive order on supply-chain security, because nobody could answer “which of our systems ship this vulnerable library?” fast enough. The AI Bill of Materials is that primitive for the agent era. It answers a narrower and more urgent question: what AI is actually running, under whose control, and against which policy.

Shadow AI is an inventory problem before it is a policy problem

The typical failure sequence is quiet. A data scientist spins up an Ollama pod to test a local model. A product squad wires a LangChain agent into a service without telling platform security. Someone attaches pgvector to a namespace for a retrieval prototype that never gets decommissioned. None of this appears in a central register. Security learns the topology during an incident, or during an audit, which is the worst possible time to start drawing the map.

Policy written on top of an unknown surface is theater. You can publish an AI usage standard, require model cards, and mandate human review, but every one of those controls assumes you know where the AI is. The register is the substrate every downstream control depends on, and until now it has been maintained by hand, in a wiki, out of date the day it was written.

k8s-aibom attacks that directly with a three-tier confidence model. Each component it finds is marked Declared when explicit configuration names it, Inferred when a pattern match strongly suggests it, or Unresolved when the tool sees a signal it cannot classify. The Unresolved tier is the interesting one. It converts shadow AI from an invisible risk into a reviewable queue with a name attached to each row. Instead of “we think we run some models somewhere,” a platform team gets a list, sorted by confidence, that a human can triage in an afternoon.

The design choices are what make it auditable

Discovery tools are easy to build badly. The ones that require a privileged sidecar, an eBPF probe, or a mutation to every pod spec get vetoed by the platform team on day one, because the cost of the instrument exceeds the value of the inventory. k8s-aibom runs unprivileged under a minimal Workload Identity, holding roles/storage.objectCreator and nothing more. No sidecars. No eBPF. No changes to how workloads are defined. That combination is what gets a security tool through change review instead of stuck in it.

Two more properties matter for anyone who has to defend the output in an audit. First, the run is deterministic: identical cluster state produces byte-identical BOMs, which means the artifact fits into GitOps and diffs cleanly, so a reviewer can see exactly what changed between two points in time. Second, immutability is enforced at write time. BOMs land in Cloud Storage under a DoesNotExist precondition, so the object either writes once or fails. An attacker who compromises the cluster cannot quietly rewrite yesterday’s inventory to hide what was running. The audit record becomes evidence, not a mutable log that a determined adversary can launder.

This is the property that separates a real audit trail from a dashboard. A dashboard tells you the current state. An immutable, timestamped, standards-conformant BOM tells a regulator what was true on a specific date, and lets you prove you did not edit the story afterward.

The regulatory mapping is concrete, not aspirational

The value here is not a benchmark or a performance claim. It is that a runtime-generated ML-BOM lines up cleanly with the record-keeping obligations that are already law or standard.

The EU AI Act, Article 12, requires high-risk AI systems to keep automatic logs and maintain traceability of their operation across the lifecycle. An immutable, timestamped inventory of the AI components in production is exactly the kind of automatically generated record that obligation was written for. Article 50 adds transparency duties around AI systems and their outputs, and you cannot be transparent about a system you have not catalogued. The NIST AI Risk Management Framework opens with its MAP function, which is inventory and context before anything else. ISO/IEC 42001, the AI management system standard, treats asset inventory as a foundational control in the same way ISO 27001 does for information security. In every one of these frameworks, the first obligation is knowing what you have, and the BOM is the concrete artifact that discharges it.

We wrote earlier about the content provenance stack and the PhotoDNA precedent, which governs where an artifact came from. Inventory sits upstream of that question. Provenance describes a single output and its origin. The ML-BOM describes the machinery: which models, agents, and stores exist in the cluster that produced any output at all. You need both, and the inventory is the one most programs are missing.

A caveat worth stating plainly. This is a single vendor announcement, not an independent benchmark, and it lands inside Google’s GKE story. The durable value is the standard and the mapping, not a specific tool. CycloneDX 1.6 ML-BOM is an open format, the regulatory obligations are vendor-neutral, and the design pattern (unprivileged runtime discovery writing immutable records) is portable to any Kubernetes platform. Treat k8s-aibom as the first credible reference implementation of a primitive that is about to be table stakes.

Do this now

Run a discovery pass against one production cluster this quarter, even a rough one, and produce a first ML-BOM. The goal is not a perfect register. The goal is to see your Unresolved tier, because that list is your shadow AI, and its length is the honest measure of how much of your AI estate you were governing on faith. Then decide where that BOM lives, who reviews the Unresolved rows, and how you will show it to an auditor who asks what was running on a given date. The inventory is the foundation every AI control you deploy next year will stand on. Build it before the regulator asks you to.

---

This analysis synthesizes Introducing k8s-aibom on GKE for Automated AI Bills of Materials (Google Cloud, July 2026).

Victorino Group helps enterprises build the AI inventory and audit records that survive regulatory scrutiny. Let’s talk.