Data Integrity for LLM Systems: The Upstream Dependency Nobody Owns Yet

The first time I asked a room full of LLM operators which person on their team owned the integrity of the retrieval corpus, the answer came in three flavours, all bad. The platform team said the application owners pick what to index. The application owners said the platform team runs the pipeline. The data team said they own the warehouse, not whatever the AI is reading. Nobody owned the corpus the assistant was grounding against, and the assistant was answering compliance questions for paying customers on a Friday afternoon.

That is the shape of the problem. The harness around a language model has five sides, and this one lives below the other four. Retrieval, guardrails, evaluation, mitigations: every one inherits the quality of the corpus underneath. If documents are stale, contradictory, misclassified, or unprovenanced, the model reads them with the same calm confidence it reads a perfect source, and the assistant says the wrong thing in a voice that sounds correct. In 2026 that upstream dependency has no owner on most org charts.

I am writing about it now and not in six months because the expert conversation moved hard in May. Data integrity was one of the fastest-rising influence concepts in the discipline the week of 19 May 2026, climbing roughly fifty-six percent in real influence in a single week. That velocity is the signature of a topic crossing from specialist concern into general buyer concern. The operators are starting to ask the question the auditors will ask next.

The chain, drawn honestly

Before naming the audit, it is worth seeing what an integrity failure does to the chain. The weak link, circled in everyone’s incident review and almost no one’s pre-mortem, sits at the corpus stage.

Every box to the right of the weak link can be excellent and the answer will still be wrong if the box itself is rotten. A clean retrieval and grounding stack on a stale corpus is a faster way to deliver wrong answers, not a fix.

What an LLM-facing data integrity audit actually looks like

Most teams I sit with have audited their data warehouse. They have rarely audited the documents the model reads. In many organisations the corpus is a parallel pipeline that pulls from Confluence, SharePoint, ticket systems, vendor PDFs, and a handful of S3 buckets someone set up for the AI thing in 2024. None of it went through the data-quality discipline the warehouse did. The audit is the first time it gets that scrutiny.

A real audit walks four passes, in this order. Skip any one and the rest is theatre.

Pass 1: corpus inventory. A complete list of every document store the model can retrieve from, with source, ingest timestamp, responsible team, and policy governing what may live there. Most organisations discover here that nobody has a complete list. The Shadow corpora (the engineer who indexed their team’s wiki for a demo, the PoC that quietly went to production) are the surprise, and where the worst documents tend to live.

Pass 2: freshness audit. Per document class: maximum age, median age, policy on stale content. A pricing page from 2023 in a corpus serving sales questions in 2026 is a liability with a delivery mechanism. When the first two numbers violate the third, you have found work.

Pass 3: source-of-truth identification. When the corpus contains multiple documents that speak to the same fact (the refund policy in the contract, on the website, in the help centre, in the 2024 reorg memo that was never archived), which one is authoritative. The model has no way to know. Either the corpus contains only the authoritative copy, or every non-authoritative copy is tagged so retrieval can prefer the right one. This is master data management applied to unstructured content, and the discipline borrows directly from the DAMA-DMBOK Data Quality chapter, which has been answering this question soberly since long before LLMs needed it.

Pass 4: contradiction detection. For each topic the model is asked about, run a retrieval at audit time and compare the top-k results. If two chunks contradict each other on the same fact, the model will hallucinate to resolve them, and the resolution will not be predictable. The fix is upstream in the corpus, not downstream in the prompt. Yao and colleagues’ 2024 survey on data selection and curation for large language models is one of the first practitioner write-ups to formalise this discipline; it is also what the deep dive on audit trails for LLM applications leans on to make a corpus state reconstructable after an incident.

This is data governance, applied to a new consumer

Nothing in the four passes above is new. The data governance discipline (data quality, data lineage, provenance, master data management) has been doing this work for thirty years against analytical warehouses. What is new is the consumer. The corpus is being read by a language model that will confidently synthesise across documents at the speed of an inference call rather than the speed of a quarterly report.

The EU AI Act, in Article 10, names this dependency in law for high-risk systems. It requires training, validation, and testing data sets to be relevant, representative, free of errors, and complete in view of the intended purpose, with appropriate data governance practices. The clause was written for training data, but the post-2023 reality is that retrieval-augmented systems treat the retrieval corpus as a continuously updated input that shapes every answer. The regulator’s question will not stop at what the model was trained on; it will reach what the model was reading on the day a given answer was produced. The corpus is in scope whether your legal team has decided that or not.

The NIST AI 600-1 Generative AI Profile reaches the same conclusion from the US-flavoured Govern/Map/Measure/Manage angle. Its data integrity guidance for generative systems, stripped of acronyms, is the same four-pass audit. The discipline is old. The application is new. The instrumentation gap is the work.

Why teams discover this AFTER an incident, not before

Data integrity sits unowned not because it is hard, but because until something breaks the corpus looks like infrastructure rather than a control surface. The pipeline runs. The vectors index. The chatbot answers. The dashboards stay green. Whatever was wrong with the corpus did not show up, because the model resolved the contradiction by picking one and sounding certain.

The incident surfaces it. A customer complaint, a regulator inquiry, an auditor asking which version of a document the system was reading on a given day, and suddenly the team is reconstructing a corpus state nobody logged. By then the fix is harder by an order of magnitude: standing up the integrity discipline AND back-filling the audit trail that proves it held on the dates in question.

The teams that internalise this earlier tend to have someone from regulated infrastructure (banking, healthcare, telecom) on board, where the lesson that instrumentation is not a feature but a contract with the people who can shut you down was learned two careers ago. They look at the retrieval pipeline and ask the inventory question. The earlier they ask, the smaller the eventual remediation.

If your stack does not have that voice yet, commission the four passes as a one-time exercise this quarter and a quarterly rhythm thereafter. The first run will surface Shadow corpora you did not know existed. The second will be shorter. By the fourth, the audit is a regular operational step, the corpus has an owner, and the harness inherits a foundation defensible to an auditor. The audit trail deep dive covers how to log corpus state so the four passes leave evidence; the LLM observability deep dive covers the live signals (cache-hit shifts, freshness alarms, contradiction-rate trends) that turn the quarterly audit into a continuous read.

The harness is only as honest as the corpus it grounds against. Until the corpus has a name on it, the harness carries a quiet liability nobody is paid to fix.

Resources

• Observability and audit for LLM systems (parent)
• Audit trails for LLM applications (deep dive)
• LLM observability: the production view of the harness (deep dive)
• Retrieval and grounding (deep dive)
• The LLM harness (pillar)
• Practitioner reference: NIST AI 600-1, Generative AI Profile of the AI Risk Management Framework
• Discipline reference: DAMA-DMBOK, Data Management Body of Knowledge (Data Quality chapter)
• Regulatory reference: Regulation (EU) 2024/1689 (AI Act), Article 10 (data and data governance)
• Research reference: Yao et al., A Survey on Data Selection and Curation for Large Language Models (2024)