Google open-sourced k8s-aibom, a Kubernetes controller that watches AI workloads and emits CycloneDX 1.6 ML-BOM documents.
That sentence sounds like a compliance lab had too much coffee.
But stay with it, because the interesting part is not the acronym pile. The interesting part is that the industry is slowly admitting a very boring truth: you cannot govern AI systems you cannot inventory.
Not in a spreadsheet.
Not from the deployment plan someone wrote three releases ago.
Not from the architecture diagram that still has "TODO: add vector db" in the corner.
From the runtime.
From the cluster.
From the thing actually serving traffic, calling model APIs, holding embeddings, running evaluation jobs, and burning GPU budget.
the model is not the whole system
The mistake people keep making with AI governance is treating the model as the unit of concern.
Which model are we using?
Where did it come from?
Is it open source?
Did legal approve it?
Those are good questions. They are also not enough.
A production AI workload is not a model. It is a stack. Usually a slightly ridiculous one.
There is the model runtime: vLLM, Triton, Hugging Face TGI, Ollama, Ray Serve, SGLang, or whatever won the internal bake-off this month. There are containers, image digests, environment variables, API keys, tracing settings, and a few "temporary" flags that have been temporary since February.
There may be an agent framework, a vector database, a training job, an evaluation harness, a telemetry system, and a dashboard that says everything is fine because the only alert it has is CPU.
That whole thing is the AI system.
The model has the best marketing.
build-time inventory is a nice intention
SBOMs trained us to ask what is inside a software artifact. That was useful. Painful, but useful.
For normal application software, build-time inventory gets you pretty far. You can inspect dependencies, package versions, licenses, vulnerabilities, provenance, and signatures. You can make policy decisions before deployment.
AI workloads make this harder.
Some important facts only appear at runtime. Which model did the pod actually load? Which image digest got pulled? Which external LLM provider is the agent configured to call? Which vector store is wired in? Which dataset volume is mounted into the training job? Which workload changed after the nice reviewable YAML became reality?
This is why the k8s-aibom idea is interesting. The controller observes workloads through the Kubernetes API and generates an ML-BOM as a side effect of normal cluster operation. It is asking a more useful platform question:
What is running here?
The word "here" matters.
Not "what did the repo say?"
Not "what did the golden path template intend?"
What is running in this cluster, in this namespace, right now?
confidence is not a footnote
My favorite detail in the project is not that it emits a BOM.
It is that attributes have confidence.
The controller can mark a value as declared, inferred, or unresolved. A model name from a container argument is declared. A runtime guessed from an image name is inferred.
This sounds like tiny metadata until you have sat in a compliance review where everyone pretends certainty because uncertainty looks bad in a slide deck.
There is a huge difference between:
"This workload runs vLLM and serves model X."
and:
"The workload declares model X in an environment variable, the runtime looks like vLLM based on the image name, and the digest is unresolved because the pod has not pulled yet."
The second version is less pretty.
It is also much more honest.
Honesty is not just a moral preference here. It is operationally useful. Declared facts can be checked against policy. Inferred facts can be reviewed or improved with annotations. Unresolved facts can become a queue. Someone can ask why the production inference service cannot produce a verified model identity.
That is boring work.
Good.
Boring work is where governance becomes real.
runtime inventory changes ownership
Once AI inventory becomes a cluster resource, the ownership conversation changes.
The platform team is no longer only providing a way to deploy model-serving containers. It is providing a way to answer questions about them.
Which teams are running inference?
Which workloads call external LLM APIs?
Which namespaces have agent frameworks?
Which runtime versions are drifting?
Which model identities are only inferred?
Which BOMs changed after the last deployment?
That is not dashboarding for its own sake. Please, we have enough dashboards. Some of them are legally classified as furniture now. It is a control loop.
If the cluster can produce an AI bill of materials, security, compliance, platform, and product teams can stop arguing from vibes. They can argue from evidence. Still loudly, probably. But at least with object names.
This is also where the Kubernetes shape makes sense. Kubernetes already became the place where infrastructure intent turns into runtime state: Deployments, Jobs, Services, GPU claims, secret references, service accounts, labels, annotations, events. It is ugly sometimes, but it is also where reality gathers.
So yes, of course AI inventory wants to become a controller.
Everything eventually becomes a controller if you leave it near Kubernetes long enough.
compliance needs evidence, not theater
The k8s-aibom README talks about EU AI Act logging and transparency obligations, NIST AI RMF controls, and ISO/IEC 42001 inventory and lifecycle clauses. That is the kind of paragraph engineers skip until the audit calendar invite appears.
I get it.
Compliance language can feel detached from the work. It often arrives as a PDF, a checklist, and a meeting where the main output is mild despair.
But the underlying requirement is not absurd. If you deploy AI systems, you should know what they are, where they run, what they depend on, and how they changed.
The bad version is theater. A team fills in a form saying "we use approved models" while production has three experimental agents and a CronJob named final-final-eval. Everyone nods. The spreadsheet is green. Reality continues enjoying its freedom.
The better version is evidence.
Let the cluster produce facts. Store immutable BOMs somewhere boring. Diff them. Attach confidence. Keep external sinks narrow. Make it possible to answer what changed without asking five humans to reconstruct the week from Slack.
This does not make compliance easy.
It makes it less fake.
That is a meaningful improvement.
the alpha label matters
There is an important caveat: k8s-aibom is alpha.
The README is clear about that. It calls v1.0 production-suitable for non-critical observation use cases, not a magic compliance machine. It also says Google does not host a prebuilt image or Helm repo. You build and push your own image before deploying.
That caveat does not weaken the signal.
It makes the signal cleaner.
Early tools often show where the architecture is going before the enterprise packaging arrives. The useful pattern is simple:
- observe AI workloads at runtime
- include evidence locators
- distinguish declared facts from inferred guesses
- make drift visible
That pattern will show up in more products.
It has to.
Because AI systems are becoming too distributed and too important to govern from memory.
what platform teams should steal
Even if you never run this controller, steal the questions.
Can you list every model-serving workload in your clusters?
Can you tell which runtime each one uses?
Can you identify agent stacks and the external LLM APIs they call?
Can you distinguish facts declared by the team from facts inferred by tooling?
Can you prove the inventory, or are you trusting a wiki page with old screenshots?
The answer does not need to be perfect tomorrow. But if the answer is "we would ask around," that is not governance. That is archaeology with notifications.
The practical path starts small. Label namespaces. Require model and runtime annotations. Track image digests. Inventory external AI providers. Connect BOMs to ownership. Treat unresolved fields as work items.
Visibility first.
Then control.
Then the arguments can become useful.
the punchline
AI bills of materials sound like compliance paperwork because, unfortunately, they partly are.
But the runtime version is more interesting than paperwork.
It is cluster inventory for AI systems.
That matters because the production AI system is not just the model. It is the runtime, the container, the agent framework, the vector store, the training job, the external API dependency, the telemetry setting, the namespace, the service account, and the weird annotation someone added during an incident and forgot to remove.
If you cannot see those pieces, you cannot govern them.
You can only hope the diagram is still true.
And if years of software engineering have taught us anything, it is that the diagram is never still true.
To test my projects, I use Railway. If you want $20 USD to get started, use this link.
Top comments (0)