Data Governance for AI

01What data governance for AI means

Classic data governance grew up in service of business intelligence, and its instruments show it. Catalogues document what data exists, who owns it and what each field means. Stewardship programmes assign responsibility for quality. Quality rules run on schedules and raise exceptions for a person to review. Access is requested through a ticket, judged by a human and granted for a quarter at a time.

None of that was wrong. It worked because consumption happened at human speed. An analyst wrote a query, a report went out monthly, a dashboard refreshed overnight, and human judgement sat between the data and every decision that used it. Governance could afford to be descriptive, because a person was always present to interpret the description.

AI removes that person from the loop and multiplies the speed. The consequence is not that classic governance becomes optional; it is that governance must change register, from describing data to controlling consumption. The gap between those two postures is where most enterprise AI programmes stall, and it sits underneath many of the reasons why generative AI projects fail.

02Why AI breaks classic data governance

The break is structural, not a matter of maturity. Five properties of AI consumption defeat governance that was designed for people.

AI consumes at machine speed and scale. A single copilot can issue more data requests in an afternoon than an analyst team issues in a quarter, and an agent fleet never sleeps. Approval queues, quarterly access reviews and steward inboxes were sized for human demand. At machine volume they either become the bottleneck that kills the programme or get bypassed, and bypassed is worse.

Unstructured data carries most of the meaning. Contracts, case notes, clinical letters, emails and policy documents are precisely what language models are best at consuming, and precisely what classic governance never covered. The catalogue describes tables and columns. It has nothing to say about the shared drive a retrieval pipeline just indexed.

Models retain and recombine what they see. A database query returns a result and ends. Data shown to a model can shape outputs long after the request, and retrieval systems can combine sources that were individually harmless into a disclosure nobody approved. Governance has to reason about exposure over time, not access at a moment.

Outputs are new data. Every generated answer, summary, score and draft is a fresh data asset with provenance, sensitivity and retention questions of its own. Classic governance has no register for these assets, so they accumulate ungoverned, then get quoted, forwarded and fed into the next model.

Agents act rather than answer. A wrong figure on a dashboard misleads a person, who might catch it. An agent working from the same wrong figure updates the record, sends the email or executes the transaction. Autonomy converts data quality and entitlement errors from embarrassments into incidents, and no risk function will accept that trade without enforcement it can inspect.

03Five principles

Programmes that succeed vary in tooling and sequence, but they hold to the same five principles. Each corrects a specific habit inherited from the classic model.

1. Enforce at the moment of consumption

A policy that is not executed at request time is advice. The defining move of governance for AI is placing an enforcement point between data and model, so that every retrieval, prompt context and agent action passes through policy before it happens. If the enforcement point is down or bypassed, access stops. It does not silently continue on goodwill.

2. Least privilege access

Every model, copilot and agent should receive the minimum access necessary to the underlying data sets, and no more. The default is closed, access is scoped to what a given use case genuinely requires, and the same rule is enforced consistently on every AI interaction rather than applied unevenly system by system. Access that is granted narrowly and enforced the same way everywhere is what keeps least privilege real once AI, not a person, is the consumer.

3. Lineage in both directions

Classic lineage answers where data came from. AI adds the reverse obligation: what fed the model, and what the model produced, and where the product went. When a source turns out to be wrong, or a regulator asks about an output, the organisation must trace upstream into sources and downstream into every answer, report and action the data touched. One direction without the other is half an audit.

4. Policy as executable rules, not prose

Residency requirements, purpose limits, retention rules, prohibited uses and human-in-the-loop conditions must exist as versioned, testable rules that systems apply automatically. Prose policy still matters as the statement of intent, but the rule is the governing artefact: it can be reviewed like code, tested before release and shown to an auditor as the thing that actually ran.

5. Evidence as a by-product of operation, not a project

If assembling evidence for an audit is a project, the evidence is stale by definition and the project recurs forever. The correct posture is that normal operation writes the record: every access decision, policy evaluation and output validation lands in an immutable trail as it happens. When the question arrives, the answer already exists.

04A working framework: five layers

The principles compress into a working framework of five layers. Each layer answers one question that risk, security or an auditor will eventually ask, and each depends on the one before it.

The ordering is load-bearing. Access cannot be controlled to data nobody has found. Outputs cannot be governed when the meaning of their inputs was never resolved. Nothing can be proved about behaviour that was not recorded as it happened. Organisations that jump straight to layer three, usually by wiring an approval step in front of a pilot, discover that they have governed a demo rather than an estate.

Each layer must also operate as enforcement rather than documentation. A register of the estate refreshed annually is a photograph; layer one is a camera feed. The same test applies all the way up: if the layer stops working and AI consumption continues unchanged, it was documentation.

05The regulatory floor

Data governance for AI is no longer an internal preference. A regulatory floor now sits underneath it, and the instruments below are the ones most boards will be measured against. Their details differ; their direction does not. Control the data going in, trace the outputs coming out, and keep evidence of both.

The EU AI Act. Regulation (EU) 2024/1689 makes data governance an explicit legal obligation for high-risk AI systems. Article 10 requires that training, validation and testing data be subject to documented governance and management practices covering design choices, provenance and collection, preparation, and examination for bias, gaps and shortcomings, with datasets that are relevant and appropriately representative for the intended purpose. Logging and traceability obligations sit alongside, and the high-risk requirements phase in through 2026 and 2027. The Act reaches any organisation whose systems touch the EU market, not only those headquartered inside it.

Sector and prudential rules. Financial regulators are converging on the same expectation from different starting points, and an AI system inside a regulated operation inherits whichever regime applies. In Australia, APRA’s CPS 234 requires an information security capability commensurate with the sensitivity and criticality of information assets, which includes the data feeding models, and CPS 230, in force since July 2025, extends the obligation to operational risk across critical operations and material service providers. In the United Kingdom, the PRA and FCA hold regulated firms to operational resilience and outsourcing standards that reach the same systems. In the United States, banking and securities regulators apply comparable expectations for model risk and data controls. The label differs by jurisdiction; the obligation to govern the data feeding models does not.

NIST AI RMF. The United States framework is voluntary, but its Govern function has become the shared vocabulary for AI accountability: policies, roles, risk tolerance and monitoring arranged so that the path from written intent to measured practice is explicit. Procurement teams and audit committees increasingly ask for it by name.

ISO/IEC 42001. The first certifiable management system standard for AI. Its controls reach data directly: provenance, quality, preparation and documentation across the lifecycle of each system in scope. For organisations that want an external attestation of governance posture, this is the current instrument.

Privacy law and purpose limitation. Nearly every privacy regime limits the use of personal information to the purposes for which it was collected. In the European Union the GDPR makes purpose limitation an explicit principle; in the United Kingdom the UK GDPR and the Data Protection Act 2018 carry the same rule; in the United States sectoral laws such as HIPAA constrain how protected data may be reused; and in Australia the Privacy Act 1988 and its Australian Privacy Principles do the same. Data gathered to administer an account does not automatically become training material or retrieval context. Purpose limitation is the privacy question AI raises most often, and answering it requires knowing, per interaction, which data a system consumed and why.

The common demand across all of these is evidence: show what data the system used, under whose authority, and how the output was produced. The bar sits highest where automated decisions touch citizens, a theme examined separately in Enterprise AI in Government.

06Roles and the operating model

Infrastructure without accountability produces a well-instrumented mess. The operating model that works splits accountability along lines the organisation already trusts. The chief data officer owns meaning: the semantic model, quality thresholds and the definition of each governed domain. The CISO owns enforcement integrity: that the access path cannot be circumvented and that IAM remains the single source of identity. Risk owns the framework: it sets tolerance, challenges the controls as second line and consumes the evidence they produce. Where these accountabilities blur, every AI approval becomes a negotiation. Where they are explicit, approval becomes a checklist.

The data governance council changes shape. As a documentation review board it met quarterly, approved definitions and closed tickets. Under AI it becomes the owner of executable policy: it approves rules before they reach enforcement, reviews the evidence those rules generate and arbitrates the genuine trade-offs between speed and control that now surface weekly. Its cadence follows the rate of change, not the calendar.

Stewards move from documenters to policy owners. The steward who once maintained a glossary entry for their domain now owns its ruleset: which AI uses may consume the domain, under what conditions, with what validation on outputs. Their deliverable stops being prose and becomes tested policy, and their standing rises accordingly, because their decisions now execute.

Finally, governance runs as a product, not a programme. Programmes end, and governance that ends is a contradiction. Governed data is an internal product that AI teams consume: it has users, a roadmap, service levels and an adoption curve. The health metrics worth tracking are operational ones: how long a policy change takes to reach enforcement, how often the governed path is bypassed (the target is zero), and what share of AI consumption flows through it.

07The tooling map

No single tool class delivers the framework, and several will claim to. The practical question is which governance function each class serves, and what remains open once it is in place. Most organisations already own several rows of this table; the point of the map is that recording intent and enforcing it are different capabilities.

A control plane connects to the systems already in place and materialises a governed, unified semantic layer from them, resolved once and stored: it inherits identity from the IAM in force, can read what the catalogue documents, and gives quality and GRC tooling a live enforcement point to attach to. The selection question is therefore narrower than it first appears: which layer will be the enforcement point, and can it see both the data and the AI at once.

08A maturity model

Four stages describe most organisations. The labels matter less than the mechanism that moves an organisation up a stage, which is named for each.

• Documented. Policy lives in prose, the estate is partially catalogued and AI reaches data by ticket and goodwill. Moving up takes a genuine gate: no use case touches data without a recorded decision against stated criteria.
• Gated. Every AI use case passes a review board before it may consume data. Deliberate but slow, and each approval decays as systems change. Moving up takes policy encoded as executable rules rather than judged case by case.
• Enforced. Rules execute in the request path, access is least privilege and non-compliant requests are prevented rather than reported. Moving up takes lineage in both directions and evidence written continuously rather than assembled on demand.
• Evidence-producing. The audit trail exists before anyone asks for it, and each new use case inherits the governed path on day one. The work at this stage is keeping it true as the estate, the models and the rules change.

Most organisations sit between Documented and Gated. The jump that hurts is Gated to Enforced, because it is the point where governance stops being a meeting and becomes infrastructure. It is also where the return arrives: at Enforced, approval times collapse, because most of the answer is already encoded.

09The first 90 days

None of this requires a multi-year prelude. The sequence below assumes nothing exotic: existing systems stay where they are, and the governed foundation is built from them, resolved once and stored. What it produces by day 90 is the one artefact that changes the internal conversation, which is evidence.

Days 0 to 30: see the estate as it actually is

Inventory by scanning, not workshops. Automated discovery against the priority systems surfaces what exists, where it lives and how sensitive it is, including the unstructured stores no workshop would have named. Then pick one domain that matters commercially, customer, claims or positions, and unify its meaning: entities resolved, definitions reconciled, owners confirmed. One domain done properly beats an estate-wide statement of intent.

Days 30 to 60: encode the policies that always come up

Every AI review in the organisation circles the same short list: residency, sensitive classes, purpose limits, who may see what, and where a human must stay in the loop. Encode the top ten as executable rules, version them and test them the way code is tested. Then put one real AI use case through the governed path from source to output, with enforcement live. A modest use case governed properly is worth more than an ambitious one running on an exception.

Days 60 to 90: show risk the audit trail

Take the lineage and audit evidence from the live use case to risk and compliance before they ask for it. This is the moment the programme changes character: the conversation stops being about whether AI can be trusted and becomes a review of a specific artefact everyone can read. Formal activation follows, and the second use case inherits the semantic model, the rules and the evidence machinery, which is why it lands in a fraction of the time.

10Frequently asked questions

11Sources and further reading

• European Union, Regulation (EU) 2024/1689 (the EU Artificial Intelligence Act), Article 10 on data and data governance for high-risk systems.
• US National Institute of Standards and Technology, AI Risk Management Framework, the Govern function.
• US Department of Health and Human Services, Health Insurance Portability and Accountability Act (HIPAA), the Privacy and Security Rules for protected health information.
• UK Information Commissioner’s Office, UK GDPR and Data Protection Act 2018 guidance, including the purpose limitation principle.
• International Organization for Standardization, ISO/IEC 42001:2023, Artificial intelligence management systems.
• Office of the Australian Information Commissioner, Privacy Act 1988 and the Australian Privacy Principles, limits on the use and disclosure of personal information.
• DataReadyAI, Enterprise AI Control Plane: definition, architecture and buyer’s guide.