From Raw Table to LLM Response: The Lineage Chain

Most data lineage tools can tell you which pipeline populated a table. Almost none of them can tell you which row in that table produced the sentence an LLM just showed a customer. That gap — the last mile between a governed data warehouse and an ungoverned model response — is where AI governance is actually breaking down in 2026, and it’s a database problem before it’s a model problem.

Why this matters now

Regulatory pressure has made this gap expensive to ignore. The EU AI Act’s Article 10 data governance requirements for high-risk AI systems carry an enforcement deadline of August 2, 2026, and they require documented provenance, not just documented pipelines. Meanwhile the market has already voted with its wallet: Gartner projects AI governance platform spending will reach $492 million in 2026, and the data lineage tooling market itself is projected to grow from $1.66 billion in 2025 to $2.07 billion in 2026, a 24% jump in a single year. Vendors are racing to close this gap because enterprises are asking for it, not because it’s a hypothetical concern.

The core issue is scope creep in what “lineage” has to mean. As one industry analysis put it, the scope of lineage has expanded from a database column to an ML feature to an AI-generated recommendation — and most lineage stacks were architected for the first of those, not the third. A dbt DAG or an Airflow graph will happily show you that customers.orders fed a fct_revenue model. It will not show you that the same table, three transformations and an embedding step later, is the reason your support agent’s chatbot told a customer their refund was approved.

Key takeaways

  • Traditional lineage tools trace pipelines, not the full path from source row to LLM output — that gap is now a compliance and trust liability, not just a nice-to-have.
  • EU AI Act Article 10 makes documented data provenance a legal requirement for high-risk AI systems as of August 2, 2026.
  • The chain that actually needs tracing is: raw table → transformation → embedding/semantic layer → retrieval → response.
  • Closing the gap is achievable today with existing database features — column-level tags, retrieval logging, and embedding metadata — without buying a new platform.
  • Treat “what fed this answer” as a database-layer question, answerable with a query, not a forensic exercise.

What changes when the chain extends past the pipeline

Traditional lineage answers “where did this column come from.” AI-era lineage has to answer “where did this sentence come from,” and that means tracking through stages a conventional data catalog was never built to see:

Raw table. The system of record — the row-level source of truth that everything downstream depends on.

ETL/pipeline. Joins, transforms, and aggregations that a mature catalog like OpenMetadata, Atlan, or DataHub already tracks reasonably well.

Embedding/semantic layer. The point where a row becomes a vector, and where most lineage tooling goes dark. A single embedding can blend fields from several source tables into one opaque numeric representation, and once that happens, most systems have no mechanism to unwind which fields contributed what.

RAG retrieval. The context window assembly step, where a retriever pulls some subset of embedded chunks based on a query. Which chunks got pulled, and why, is rarely logged anywhere durable.

LLM response. The final surface. By the time a fact reaches this stage, the typical enterprise stack has no path back to the row it came from — which is exactly the gap regulators and analysts are now flagging as a governance blind spot.

Why can’t existing catalog tools just extend forward?

They can, technically — vendors like Atlan and DataHub are actively building this — but the harder problem isn’t tooling, it’s that the database layer has to expose the right hooks in the first place. If your embedding pipeline doesn’t tag each vector with its source row ID and transformation version, no downstream catalog can reconstruct that link no matter how good its UI is. Lineage that stops at the pipeline isn’t a tooling gap you can buy your way out of; it’s a schema and metadata design decision that has to be made where the data lives.

Closing the gap without buying a new platform

You don’t need an enterprise AI governance suite to start closing this. Three concrete, database-layer moves get you most of the way there:

Tag embeddings with source provenance at write time. When a row gets embedded, store the source table, primary key, and transformation version alongside the vector — not in a separate system, in the same row or a tightly joined provenance table. This turns “which row produced this vector” from an archaeology project into a join.

Log retrieval, not just generation. Most teams log the LLM’s prompt and response. Far fewer log which specific chunks the retriever selected and why. That retrieval log is the missing middle link — without it, you can prove what the model was told but not what it was told to consider and rejected.

Version your semantic layer like you version schema. If the business definition of “active customer” changes, every embedding built against the old definition is now semantically stale, even though the underlying rows haven’t changed. Treat semantic layer changes with the same change-control discipline you’d apply to a schema migration.

None of this requires ripping out an existing catalog. It requires deciding, at the database layer, that provenance is a first-class column, not an afterthought bolted on when a regulator asks for it.

Where this connects to the rest of the platform

This is a governance problem, but it can’t be solved by governance policy alone — it has to be solved by database design decisions made upstream of any policy document. It’s also tightly coupled to semantic readiness — an embedding without provenance metadata is exactly the kind of drift risk that silently degrades trust over time — and to the broader question of whether your database is actually AI-ready in the first place.

If your team can’t currently answer “which row produced this answer” for a production LLM feature, that’s a database modernization gap, not a model problem. Get in touch if you want a straight assessment of where your lineage chain actually breaks.

Ivan Lima is a data engineer specializing in database modernization for AI systems. Get in touch if your database needs to be ready for what’s next.