Drawing the Real Boundaries Between SBOM, Data Lineage, and the AI Bill of Materials
Three disciplines. One conflation crisis. What good looks like in 2026.
Enterprise buyers often treat SBOM, data lineage, and AIBOM as one "AI transparency" checkbox. This piece separates what each covers, where they overlap, and what a mature 2026 governance stack looks like when all three work together.
The Conflation Crisis
Security and procurement teams have spent the better part of a decade building muscle memory around the Software Bill of Materials (SBOM), a manifest of every library, package, and dependency inside an application, popularized after supply-chain incidents like SolarWinds and cemented by regulatory pressure (Executive Order 14028 in the US, and equivalent procurement requirements that followed). That muscle memory is now being applied, almost by reflex, to AI systems. The assumption baked into most vendor security questionnaires today: "We already do SBOMs, so an AIBOM is just SBOM-for-models, check the box, move on."
It isn't, and treating it that way is where the gap opens up. A traditional SBOM answers a fundamentally deterministic question: what code is running, and what does it depend on? Every entry in an SBOM is a discrete, versioned artifact, a package, a library, a container base image, with a clear provenance chain and a matching CVE database to check it against.
An AIBOM has to answer a different kind of question entirely: what shaped this model's behavior, and where did each of those inputs come from? That includes:
- Base model lineage, which foundation model this system was built on, who trained it, and under what license
- Fine-tuning datasets, every corpus used to adapt the base model, its source, and its own provenance chain
- Evaluation and benchmark lineage, what the model was tested against before being called "production ready," and by whom
- Embedding stores and retrieval indices, for RAG-based systems, what data populates the retrieval layer the model draws from at inference time
- Third-party inference dependencies, any external API, model host, or intermediate service the request passes through before a response comes back
- Licensing terms attached to each of the above, not just the model's license, but the license terms of every dataset that touched it
None of these map cleanly onto a package manifest. A model isn't a discrete artifact with a clean dependency tree the way a Python package is, it's a statistical object shaped by potentially billions of tokens of training data that can't be individually re-inspected, re-audited, or "patched" the way a vulnerable library can. This is precisely why AppSec teams applying SBOM tooling to AI vendors keep hitting a wall: the tool can enumerate which Python packages a vendor's API wrapper imports, and it will do that job well. It has no mechanism whatsoever for telling you what data trained the model living behind that API, or what changed the last time the vendor pushed a fine-tune.
Why This Isn't Just a Terminology Problem
It's tempting to treat this as a semantic argument, "AIBOM" vs "SBOM" vs "data catalog", that doesn't actually change what teams need to do. It changes quite a lot, in practice, because each discipline answers to a different owner, runs on a different cadence, and gets audited by a different function inside most enterprises:
- SBOMs typically live with AppSec/DevSecOps and are refreshed on every build.
- Data lineage and cataloging typically live with data engineering or data governance, and are refreshed whenever a pipeline changes.
- AIBOM, where it exists at all today, tends to live nowhere specific, sometimes bolted onto AppSec's existing SBOM tooling (which misses the training-data layer entirely), sometimes bolted onto data governance (which misses the model-behavior layer entirely), and often owned by no one until a security review or a customer contract forces the question.
That ownership gap is exactly where shadow AI risk accumulates. If nobody owns the question "what trained this model and did anything change," the answer defaults to "we don't know", and "we don't know" is not an answer that survives a serious enterprise security review, a regulator's inquiry, or a breach post-mortem.
The Definitional Matrix
| Category | Target Architecture Layer | What It Flags | The Gaps It Leaves | Typical Owner | Refresh Cadence |
|---|---|---|---|---|---|
| SBOM | Application / dependency layer | Known-vulnerable libraries, license conflicts, package provenance, container base image drift | No visibility into model weights, training data, or inference-time behavior | AppSec / DevSecOps | Every build |
| Data Lineage / Catalog | Data pipeline layer | Where a dataset originated, how it was transformed, who accessed it, retention and access controls | Doesn't track how that data was used inside a model, or what the model learned from it | Data Engineering / Data Governance | Per pipeline change |
| AI Bill of Materials (AIBOM) | Model / inference layer | Base model origin, fine-tuning datasets, third-party model dependencies, evaluation lineage, licensing of training corpora, retrieval index composition | Still maturing, no single enforced standard yet (unlike SPDX/CycloneDX for SBOM); coverage and depth vary widely vendor to vendor | Often unowned, or split between AppSec and AI/ML platform teams | Ideally per model/fine-tune deployment; in practice, often static or absent |
The overlap matters as much as the distinction, and it's worth being explicit about where each discipline hands off to the next:
- An AIBOM without upstream data lineage is incomplete, you can't credibly attest to a training dataset's provenance if the data catalog underneath it has no chain of custody in the first place. The AIBOM is only as trustworthy as the data lineage feeding it.
- A data lineage system with no AIBOM tells you your source data was clean and well-governed at the point of collection, but says nothing about what a downstream model actually absorbed from it, how it was transformed during fine-tuning, or which third-party base model your vendor quietly built on top of using that data.
- An SBOM with neither gives you a clean, auditable application layer sitting on top of a completely opaque model layer, which is functionally the situation most enterprises are in today, and precisely why AI-specific security incidents keep surprising organizations whose AppSec posture is otherwise mature.
Anatomy of a Shadow AI Pipeline
Here's where the conflation becomes a real, operational risk rather than an abstract taxonomy debate. A typical enterprise AI deployment in 2026 looks something like this:
Each arrow in that diagram represents a transition, a handoff between systems, teams, or organizational boundaries, and each one is a potential blind spot depending on which governance discipline, if any, is actually watching it:
- The arrow from Internal Data Store → Fine-tuning Job is usually covered by data lineage tooling, if the organization has invested in it.
- The arrow from Fine-tuning Job → Third-Party Base Model API is where AIBOM coverage needs to begin, and where most organizations have nothing at all, there's frequently no record of exactly which base model version was used, what its own training lineage looked like, or what license governs derivative fine-tunes.
- The arrow from Third-Party Base Model API → Vendor's Own Fine-Tunes is entirely outside your organization's visibility unless your vendor contract explicitly requires disclosure, this is the vendor doing their own fine-tuning on top of the base model, on their own schedule, using their own data.
- The arrow from Production Inference Endpoint → Agentic Orchestration Layer is where model behavior stops being a chatbot answer and starts triggering real-world actions, tool calls, API requests, database writes, and it's covered by neither SBOM nor data lineage nor, in most organizations today, anything at all.
Your SBOM tooling monitors the application code calling the inference endpoint at the bottom of that diagram. Your data catalog, if you have a mature one, might track the internal data store at the top. But almost nothing in most enterprise stacks today tracks the base model's origin, what it was fine-tuned on before your organization ever touched it, whether the vendor silently swapped the underlying model version last quarter, or what the agentic layer is actually authorized to do with the model's output. That's a shadow pipeline, fully operational, fully invisible to existing governance tooling, and exactly the layer an AIBOM is designed to illuminate.
What "Good" Looks Like: A Unified Posture
Treating SBOM, data lineage, and AIBOM as three separate checkbox exercises, run by three separate teams on three separate cadences, guarantees gaps at exactly the seams where each discipline hands off to the next. The organizations getting this right in 2026 are building a single governance posture that traces one continuous line from raw data, through training and fine-tuning, through the model artifact itself, and into the production application and any agentic actions it triggers, with each transition documented, versioned, and auditable end to end.
Practically, that tends to mean three things:
- A shared inventory schema. Even if SBOM, data lineage, and AIBOM stay owned by different teams, they need to reference each other, a data lineage record should be linkable to the AIBOM entries that consumed it, and an AIBOM entry should be linkable to the SBOM of the application serving it.
- A single accountable owner for the AIBOM layer specifically, rather than leaving it to fall between AppSec and data governance by default. Someone needs to be the person who can answer "what trained this, and did anything change" on demand.
- Vendor contracts that require disclosure, not just self-attestation at signing. A one-time security questionnaire tells you about the model your vendor had at the time of signing, it says nothing about the model they're running six months later.
That doesn't mean ripping out existing SBOM or data catalog investments, those remain necessary, just not sufficient. It means treating AIBOM as the missing middle layer, and requiring it explicitly in vendor due diligence rather than assuming it's already covered by whatever security questionnaire procurement happens to be sending out today.
The next post in this series goes one level deeper: what actually happens when that middle layer is missing, walking through a concrete exploit path that becomes possible when an organization has no AIBOM, and why the traditional AppSec controls sitting on top of that gap don't catch it.