Skip to content
Diosh Lequiron
AI & Technology13 min read

Data Governance in the Age of AI: What Changes

AI changes the data governance problem fundamentally. Training data provenance, consent coverage, and model accountability require governance artifacts most organizations do not yet have.

Data governance — the policies, processes, and accountability structures for how data is collected, stored, used, and protected — was designed primarily for a world where humans use data to make decisions. In that world, governance concentrated on three things: ensuring data quality (accurate, consistent, complete data for human analysis), protecting privacy (limiting data access to authorized parties), and establishing accountability (knowing who accessed what data and for what purpose).

These concerns remain valid. The governance frameworks that address them — data classification, access controls, retention policies, audit logging — remain necessary. What has changed is that they are no longer sufficient.

AI changes the data governance problem in ways that existing frameworks are not designed to address. AI systems use data to train models that then make decisions at scale without human review of each instance. The data used in training encodes assumptions, biases, and limitations into the model in ways that persist through its operational life. The relationship between data and decision is no longer direct and traceable — it passes through a model that transforms, compresses, and encodes information in ways that cannot be fully audited after the fact. The volume of decisions produced from a trained model vastly exceeds the volume of decisions that could be traced to specific data inputs.

Organizations that apply pre-AI data governance frameworks to AI-powered systems are not wrong to do so. They are incomplete. The existing frameworks handle data quality, access, and retention for the pre-AI part of the data lifecycle. They do not handle training data provenance, model accountability, automated decision governance, or the consent implications of data used to train systems that make decisions at scale.

This article describes what changes about data governance when AI is part of the data infrastructure, the governance artifacts that need to exist before AI is trained on organizational data, how to audit current governance for AI readiness, and the data governance failures that produce legal and ethical problems in AI systems.


What AI Changes About the Data Governance Problem

Training Data Provenance

In pre-AI data governance, provenance — the record of where data came from and how it was processed — is primarily relevant for debugging data quality issues and satisfying audit requirements for specific analyses. If a report is questioned, you trace the data used to produce it back to its source.

AI changes the provenance requirement in two ways. First, training data provenance is required not for specific analyses but for the entire model — the record of what data was used in training is the foundation for evaluating the model''s validity, fairness properties, and legal compliance. Second, provenance must be maintained at training time, because it cannot be reconstructed after the fact. A model trained on data whose provenance is poorly documented cannot be adequately audited for bias, cannot be assessed for compliance with data use restrictions, and cannot be evaluated for legal exposure arising from data included in training without authorization.

The governance requirement is: before any data is used for AI training, its provenance must be documented at a level of specificity that would support post-training audit. This means: source system and collection method, original purpose for which data was collected, date range of collection, applicable consent or authorization basis, any processing or transformation applied before training, and the rationale for including this data in the training set.

This is more detailed provenance documentation than most organizations currently maintain. The gap between current provenance practice and AI training requirements is one of the primary governance deficiencies in organizations attempting to use their existing data assets for AI training.

Data Quality as Model Quality

In pre-AI governance, data quality affects analysis quality. A dataset with systematic errors produces analyses with systematic errors. The relationship is direct and, with effort, diagnosable. The analyst can examine the data, identify quality issues, and either correct them or qualify the conclusions accordingly.

In AI training, data quality becomes model quality in a way that is more durable and less transparent. Quality problems in training data — systematic missingness, sampling bias, label errors, temporal drift, distribution shifts between training and deployment contexts — are encoded into the model during training. They express as model behaviors that are frequently not traceable to specific data quality failures after the fact.

The governance implication: data quality requirements for AI training are more stringent than data quality requirements for standard reporting or analysis, and they need to be validated before training rather than detected in the model after training. A model trained on poor-quality data does not just produce poor analyses — it produces a poor model that must be retrained, not just corrected.

Organizations need to establish AI-specific data quality requirements as a precondition for training approval. These requirements should be defined by the governance function, not by the AI team that wants to use the data. The conflict of interest in the latter design is predictable: teams that want to train models have incentives to lower quality bars to use data that is available rather than waiting for data that is adequate.

Privacy consent frameworks were designed for a world in which data use was the end point. A user provides data; the organization uses data to serve the user or for its own purposes; the user has consented to specified uses. The consent framework governs what the data can be used for.

AI training adds a use that existing consent frameworks typically did not anticipate: using personal data to train systems that will make automated decisions about other people. The data is not used to make a decision about the person who provided it — it is used to train a model that will make decisions about many people based on patterns learned from the training population.

This creates two consent questions that existing frameworks do not cleanly resolve. First: does consent to data use for specified purposes include consent to use that data in AI training? The answer is jurisdiction-dependent and frequently legally uncertain. In contexts where regulatory interpretation or litigation is active, the uncertainty is material. Organizations building AI on data collected under pre-AI consent frameworks should obtain legal assessment of whether training use is covered before proceeding.

Second: what disclosure is required to users whose data is used in training about what that training means for them and for people who are subsequently affected by model decisions? This is a disclosure question that extends beyond standard privacy notice — it requires disclosing not just that data will be used but what class of outcomes data use contributes to.

Retention Policies That Account for Model Training

Standard data retention policies specify how long data is kept before deletion or archiving, and they are designed to balance data utility against storage cost and privacy risk. A common model: data is retained for a defined period, then deleted, with some categories retained longer for audit or regulatory purposes.

AI training disrupts this model because training data that has been deleted continues to influence the model. The model is, in a meaningful sense, a compressed and transformed representation of its training data. A model trained on data that has since been deleted cannot have that data ''removed'' from the model — the data has been encoded into the model''s weights in a way that cannot be selectively reversed.

This creates a regulatory exposure when data is deleted under applicable privacy law (including data deletion in response to individual requests) but the model trained on that data continues in operation. The regulatory analysis of whether a trained model constitutes "processing" of data for which deletion was requested is unsettled in most jurisdictions and actively contested in others.

The governance requirement is to establish, before AI training, policies that address this lifecycle issue: whether retention periods for AI training data should differ from standard retention; what the organization''s position is on data-deletion requests for data used in training; whether model retraining or model retirement is required when significant amounts of training data are deleted; and how these policies interact with standard retention and deletion workflows.


Governance Artifacts Required Before AI Training

These are the minimum governance artifacts that should exist before any organizational data is used to train an AI model. Absence of any of these is a governance gap that creates legal, ethical, or operational risk.

Training Data Registry: A documented record of every dataset included in AI training — source, provenance, applicable consent or authorization basis, quality assessment results, and the rationale for inclusion. The registry should be maintained for the operational life of any model trained on the data, not only during the training period.

Data Use Authorization: For every dataset in the training registry, a documented authorization confirming that use of this data for AI training is within the scope of the data''s original collection purpose, or that appropriate consent or legal basis exists for training use. This authorization should come from the data governance function, not from the AI development team.

Quality Assessment Record: Documentation of data quality evaluation conducted before training approval — the criteria applied, the results, the deficiencies identified, and the disposition of those deficiencies (corrected before training, accepted with qualification, or excluded from training).

Model Accountability Record: A document specifying, for each deployed AI model: the training data used (pointer to the Training Data Registry), the optimization target (what the model was trained to maximize or minimize), the validation methodology, the fairness evaluation results, and the defined scope of deployment (what decisions the model is authorized to inform, and what is outside its authorized scope).

Automated Decision Register: A register of all AI-driven automated decisions — decisions made without human review — that are produced using trained models. The register should include the decision type, the model used, the affected population, the applicable accountability owner, and the challenge process available to affected parties.

Consent Coverage Assessment: A documented assessment of whether the consent basis for each training dataset covers AI training use, conducted by legal counsel with specific analysis of the applicable regulatory environment.

These six artifacts are not comprehensive. Organizations in regulated industries, or using sensitive categories of data (health, financial, biometric), need additional governance artifacts appropriate to their regulatory context. These six represent the minimum for any organization using AI on data about people.


Auditing Current Data Governance for AI Readiness

Organizations with established data governance frameworks typically discover, on audit, that their frameworks address pre-AI requirements reasonably well and AI-specific requirements poorly. The audit questions that surface the most significant gaps are:

On provenance: Can you produce, for any dataset you are considering for AI training, a complete record of its source, collection method, original purpose, consent basis, and any processing applied before it reaches you? If not, what percentage of your data assets have adequate provenance documentation?

On quality: Do you have documented data quality standards specifically for AI training data? Are those standards distinct from your standard reporting quality standards? Who evaluates quality for training data, and is that person or function independent from the AI development team that wants to use the data?

On consent: Has legal counsel assessed whether your existing consent frameworks cover AI training use? For data collected before AI training was a foreseeable use, has a retrospective consent analysis been conducted?

On retention: Do your retention policies address the interaction between data deletion obligations and model training? Is there a defined policy for how deletion requests are handled for data that has been used in training?

On accountability: For each AI system currently in operation, can you identify: who is accountable for the system''s aggregate performance, who is accountable for specific harmful decisions, and what the escalation path is for systemic problems?

On automated decisions: Do you have an inventory of the automated decisions currently being made by AI systems? Does that inventory include accountability mapping and challenge process documentation?

Most organizations answer "no" or "partially" to the majority of these questions. The value of the audit is not to produce a negative assessment — it is to establish a specific set of gaps that require remediation before AI use is expanded, and to sequence remediation in order of legal and ethical risk.


Data Governance Failures That Produce AI Problems

The following are data governance failures that recur in AI systems with legal, ethical, or operational consequences. They are not theoretical risks — each has produced documented outcomes in organizations operating at scale.

The training data bias laundering failure: An organization uses historical decision data to train a model that will make similar decisions at scale. The historical decisions reflect biases present in the original decision-making process — biases that were known, documented, and considered acceptable at the time. The model learns to replicate those biases at scale. The organization''s defense ("we trained the model on our historical decisions") is both legally insufficient and ethically incoherent. The governance failure is using historical data without auditing it for embedded bias and without making an explicit governance decision about whether those historical patterns should be perpetuated in automated decisions.

The scope creep authorization failure: A model is trained for a defined decision scope — for example, prioritizing customer service requests — and its scope is gradually expanded without corresponding governance review. The model is now informing decisions it was not evaluated for, on populations it was not validated against, with data it was not authorized to incorporate. The accountability record specifies the original scope; actual operation has migrated far beyond it. The governance failure is the absence of a change control process for AI model scope that requires governance re-authorization when scope expands.

The third-party data residency failure: An organization trains a model using data purchased from or shared by a third party. The third-party data agreement specifies use limitations that include model training. The model is deployed in a jurisdiction where the residency and processing rules for the third-party data are more restrictive than in the jurisdiction where training occurred. The model is operating in violation of the data agreement and applicable law, without the organization''s knowledge, because the data governance process did not include cross-border analysis before training. The governance failure is the absence of residency and use-restriction analysis as a step in training data authorization.

The retroactive consent failure: An organization responds to increased regulatory attention by announcing it will obtain consent for AI training uses of existing data. It discovers that a substantial portion of its user base either cannot be contacted, will not respond, or will decline consent. It is now operating AI systems trained on data for which it has conducted retroactive consent solicitation that failed. Its legal position — continuing to operate models trained on data where consent has been explicitly declined or cannot be confirmed — is significantly worse than its position before the consent solicitation. The governance failure is not obtaining consent analysis before training rather than discovering its exposure through retroactive solicitation.


Building Data Governance That Is Ready for AI

The organizations that navigate AI data governance well are not those with the most sophisticated frameworks — they are those whose governance processes generate the right artifacts before AI use begins rather than investigating exposure after problems surface.

The practical shift is sequential: governance review before training authorization, not governance documentation after deployment. Training data provenance, quality assessment, consent coverage, and retention policy alignment are pre-conditions for training approval, not post-deployment audit items.

This requires governance functions to be involved in AI development decisions at the point where training data is selected, which is earlier than most current governance processes operate. It requires AI development teams to treat governance authorization as a prerequisite for training, not a compliance step that follows development.

The investment is front-loaded. The alternative — discovering consent exposure, accountability gaps, or scope creep violations after systems are in production — is substantially more expensive, both in remediation cost and in the reputational and legal consequences that accompany visible governance failures in AI systems. Data governance for AI is not more complex than standard data governance. It requires applying the same discipline — clarity about what data is used, why, under what authority, and with what accountability — to a part of the data lifecycle that existing frameworks were not designed to govern.

The frameworks exist. The discipline is what is typically missing.

ShareTwitter / XLinkedIn

Explore more

← All Writing