Data governance is upstream of AI governance evidence
AI governance evidence, capability declaration, system classification, tamper-evident audit logs, answers "what did this system do, and can you prove it." Every one of those artifacts still points back at data: the training set, the retrieval corpus, the prompt context assembled at inference time. If a regulator or an incident review asks why a model answered the way it did, the honest answer traces back to what data it saw. An audit log that records only the model's output, with no record of the input's provenance, stops the investigation exactly where it gets interesting.
Data governance is the discipline that makes the upstream half of that question answerable. It is not a separate compliance track from AI governance, it is the layer AI governance evidence sits on top of. Four practices do the work: classification (what category of data is this), lineage (where did it originate and what transformations has it undergone), retention (how long is it kept and on what documented basis), and quality (is it accurate, complete, and fit for the purpose it is being used for). DAMA-DMBOK, the Data Management Body of Knowledge published by DAMA International, treats these as distinct knowledge areas rather than one undifferentiated blob called "governance." That separation is useful because each one fails differently and gets fixed by a different team.
Classification: what category of data is this
Classification is the first gate. Before data touches a training run, a retrieval index, or a prompt template, someone has to answer a plain question: is this public information, internal-but-unremarkable, confidential business data, or does it carry personal or health information (PII or PHI) that triggers its own set of obligations. DAMA-DMBOK treats this as a standing governance activity, not a one-time tagging exercise, because the same dataset can need reclassifying as it moves, gets joined with other data, or gets put to a new use.
- Public: already disclosed, no restriction on reuse, still worth tracking so nobody has to re-derive that fact under pressure later.
- Internal/confidential: contracts, pricing, unreleased product detail, needs access controls with no regulatory trigger required.
- PII/PHI: personal or health data carrying its own legal obligations, the category most likely to change what a model is allowed to do with it.
An unclassified dataset is not neutral. It defaults to the assumption that whoever touches it next guesses correctly, and in a pipeline feeding a model, that guess happens automatically, with no human in the loop to catch it before it becomes training data.
Lineage: where it came from and what happened to it
Lineage is the record of a dataset's path: source system, ingestion date, every transformation, join, filter, or aggregation applied before it reached the model, and every place it was copied along the way. Without that record, "where did this training or retrieval data come from" has no answer, which means "why did the AI system behave this way" has no answer either. Those are the same question asked from opposite ends of the pipeline.
The common failure mode does not require naming a real company: a retrieval-augmented system answers from a document store nobody can fully account for. Some documents were scraped, some uploaded manually, some are stale versions sitting next to current ones, with no record of which is which. The system produces a confident answer sourced from a document that was withdrawn months earlier, and there is no lineage trail to catch it before a user acts on it. A hash-chained, signed record of what changed and when, the kind of artifact covered in tamper-evident audit logs, is itself a lineage artifact once pointed at the data layer instead of only at model outputs.
Retention and minimization: what GDPR Article 5 actually requires
GDPR Article 5 is worth citing precisely because it is easy to overstate. It does not set a specific retention period, and it predates the current wave of model training and retrieval pipelines by years. What it establishes is a set of data protection principles, among them purpose limitation (data collected for specified, explicit purposes), data minimization (adequate, relevant, limited to what is necessary), and storage limitation: personal data kept in a form permitting identification for no longer than necessary for the purpose it was collected for.
Storage limitation is a principle, not a countdown timer. It requires a documented purpose and a defensible answer to "why do we still have this," not a fixed number of days in policy. That is a lower bar than people assume, and a real one: "we kept it because deleting things is hard" is not a documented basis. For any property with EU-relevant data feeding a model or a retrieval index, retention is where classification and lineage cash out into an actual obligation, because storage limitation can't be honored on data whose origin and purpose were never recorded.
Quality: fit for the purpose it is being used for
Quality is the DAMA-DMBOK area most often skipped, because it's the least glamorous: is the data accurate, complete, consistent, and fit for the purpose a model is being asked to use it for. A dataset can be perfectly classified and fully lineage-tracked and still be wrong, incomplete, or duplicated in ways that make a model's output unreliable, regardless of how clean the governance paperwork looks. Quality failures don't announce themselves the way an access-control failure does. They surface as a pattern of subtly wrong answers nobody can explain until someone traces the output back and finds the same malformed record feeding three different systems.
That tracing only works if classification, lineage, retention, and quality checks were already in place before the incident, not assembled retroactively for one auditor's question. Data governance is what makes the evidence in AI governance & evidence stand up to scrutiny instead of describing a system nobody can verify from the ground up.