Quick answer: An AI governance framework is the set of policies, roles, processes and controls that decide which AI systems an organization builds or buys, how their risks are assessed, and how they are overseen through their lifecycle. Data governance governs the data; AI governance governs the models and decisions built on it. You need both, and the AI framework should extend your data governance, not replace it.
Every large enterprise already has data governance of some kind: stewards, a classification scheme, a catalog, retention rules, a privacy program. Then generative AI arrived and a new question landed on the CDO's desk: is this the same discipline with new inputs, or something structurally different that needs its own framework, committee and budget?
The question matters in 2026-2027 because regulators have answered it in their own way. The EU AI Act regulates AI systems by risk class and explicitly requires data governance as one obligation among many. The Australian Privacy Act reforms sharpen individual rights around automated decisions. ISO/IEC 42001 defines an AI management system distinct from, but dependent on, information security and data management. The regulators treat AI governance as its own thing. Most organizations have not yet caught up internally.
This article is for Chief Data Officers, Chief Privacy Officers, CISOs and the AI governance leads who are being asked to build or merge these programs. It sets out what genuinely changes, what you should reuse, and how to avoid running two governance bodies that disagree.
What is an AI governance framework?
An AI governance framework answers five questions for every AI system in scope:
- Do we know it exists? An inventory of AI systems and use cases, including vendor-embedded AI and self-built agents, not only in-house models.
- How risky is it? A tiering method based on impact on people, money, safety, rights and regulated data. NIST AI RMF and the EU AI Act both supply usable tiering logic.
- Is it allowed, and under what conditions? Policy on acceptable use, prohibited uses, required controls per tier and approval gates.
- Who is accountable? A named owner per system, an accountable executive for the program, and defined second- and third-line roles.
- How do we know it still behaves? Monitoring, evaluation, incident handling, human oversight and periodic review through the lifecycle.
Everything else in a framework — model cards, impact assessments, templates, committees — exists to answer one of those five. If a proposed artifact does not, it is overhead.
What is the difference between AI governance and data governance?
The two disciplines overlap heavily, which is exactly why they get confused. The cleanest way to see the difference is by object, question and failure mode.
- Object governed — Data governance: Data assets: datasets, fields, flows · AI governance: AI systems: models, applications, agents and the decisions they make
- Core questions — Data governance: Is the data accurate, classified, lawfully held, accessible to the right people, retained correctly? · AI governance: Is the system appropriate for the purpose, is its risk understood, does it behave acceptably, who oversees it?
- Key artifacts — Data governance: Catalog, classification scheme, lineage, data quality rules, retention schedule, DPIAs · AI governance: AI inventory, risk tiering, use-case approvals, model cards, evaluation results, oversight plans
- Typical owner — Data governance: Chief Data Officer with data stewards; privacy for personal data · AI governance: Accountable executive (CDO, CAIO or CISO) with cross-functional pillar owners
- Primary regulation — Data governance: GDPR, Privacy Act, sector data rules, data sovereignty requirements · AI governance: EU AI Act, ISO 42001, NIST AI RMF, sector AI guidance
- Characteristic failure — Data governance: Wrong, exposed or unlawfully held data · AI governance: Harmful, biased, insecure or unaccountable decisions and actions
What genuinely changes with AI:
- Behavior is probabilistic. A database either returns the record or it does not. A model's output varies, so governance needs evaluation, monitoring and human-oversight design, which data governance never required.
- The system acts. Agents send, write, execute and approve. Data governance has no concept of an asset that takes actions.
- New data flows appear. Prompts, retrieval corpora, fine-tuning sets, embeddings and model outputs are all data, often regulated, often unclassified. This is where data governance is pulled into AI and where it most often breaks.
- Purpose limitation becomes operational. Data collected for one purpose used to train or ground a model for another is a privacy problem that data governance tools do not automatically flag.
Do you need a separate AI governance framework?
You need a distinct AI governance framework. You do not need a separate governance organization. The practitioner pattern that works:
- Extend, do not duplicate. Keep one classification scheme, one catalog, one privacy impact process. Add AI-specific fields and gates to them rather than inventing parallel versions. Your retrieval corpora go in the data catalog; your models go in an AI inventory that references it.
- One accountable executive, shared pillars. Whether the CDO, a Chief AI Officer or the CISO is accountable matters less than having exactly one. Risk and security pillars are what AI TRiSM organizes; the data pillar is your existing data governance with AI inputs added.
- One forum, two agendas. Where a data governance council exists, add AI use-case review as a standing agenda item with the right people in the room (security, legal, privacy, the business owner). Two councils with overlapping remits guarantee contradictory rulings on the same system.
- Separate the evidence. Auditors and regulators will ask for AI-specific evidence: the inventory, tiering rationale, oversight plans, evaluation results. Keep those artifacts clearly labeled even if the process that produces them is shared.
What should an AI governance framework include?
A workable framework for a large enterprise fits in a handful of documents and one register. If a template runs to 60 pages before a single system is governed, it is the wrong template.
Policy layer (two or three documents)
- AI acceptable-use and prohibited-use policy for employees, covering vendor tools and self-built agents.
- AI risk and lifecycle policy: tiering method, required controls per tier, approval gates, review cadence, incident handling.
- Data-for-AI standard: which data classifications may be used for prompting, retrieval, fine-tuning and training, under what consent and purpose conditions, and in which jurisdictions. This is the bridge document into data governance and where data sovereignty requirements live.
Process layer
- Intake and risk assessment (ideally one form combining data protection impact assessment and AI impact assessment).
- Approval gates by tier, with named approvers.
- Evaluation and red-team requirements for high tiers before go-live.
- Monitoring and periodic review, with triggers for re-assessment (model change, data change, new jurisdiction, incident).
Register layer
- AI inventory: every system, its tier, owner, data sources (linked to the catalog), controls applied, last review date.
Control layer
- Technical controls delivered by security and data teams: gateways, logging, access control, classification and labeling, data security posture management. The framework references these; it does not re-specify them.
How do the EU AI Act, GDPR and Australian Privacy Act reforms shape the framework?
Regulation does not tell you how to organize governance, but it dictates what your framework must be able to prove. Three regimes matter most for the audience of this site.
EU AI Act. Classifies systems as prohibited, high-risk, limited-risk (transparency obligations) or minimal-risk, with separate obligations for general-purpose AI models. For high-risk systems, providers and deployers must demonstrate risk management, data governance and quality, technical documentation, logging, transparency, human oversight, accuracy, robustness and cybersecurity. The practical effect on your framework: your tiering must be able to identify EU high-risk systems, and your register must hold the evidence for each obligation. Deployers outside the EU are in scope when outputs are used in the EU.
GDPR and UK GDPR. AI does not create new principles; it stresses existing ones. Lawful basis and purpose limitation for training and retrieval data, data minimization in prompts and corpora, individual rights including those around automated decision-making under Article 22, and DPIAs for high-risk processing. The ICO's AI and data protection guidance is the most practical regulator-authored resource on applying these to models.
Australian Privacy Act reforms. The reform program has introduced a statutory tort for serious invasions of privacy, tighter transparency obligations around automated decision-making, and larger penalties, with further tranches under consultation. For AI governance, the operational implication is that any system making or substantially assisting decisions about individuals must be identifiable in your inventory and explainable in your privacy policy. APRA-regulated entities layer CPS 234 (information security) and CPS 230 (operational risk, including material service providers, which now includes AI vendors) on top.
Regional notes for other cities. Singapore's IMDA Model AI Governance Framework for Generative AI and MAS's expectations for financial institutions emphasize accountability, data provenance and testing. US federal rules remain sector-driven; state laws (notably Colorado's AI Act) and regulator guidance from the FTC, OCC and SEC fill the gap. Data sovereignty requirements across all of these regions increasingly determine where inference can run and whether a model vendor's region commitments are sufficient.
Who should own AI governance?
Three models appear in practice, each with a known weakness:
- CDO-led. Natural when AI is mostly analytics and models are built in-house. Weakness: security and runtime enforcement lag.
- CISO-led. Natural when the dominant risk is data leakage and agentic action. Weakness: fairness, explainability and business accountability lag.
- Chief AI Officer-led. Natural when AI is a board-level strategy. Weakness: a new executive with no existing control functions tends to produce policy faster than enforcement.
Whichever model you choose, the same three conditions predict success: one accountable executive; pillar owners with budget to deliver controls, not just write them; and a governance forum that reviews evidence, not only proposals. The disagreements between the CISO and CDO about which of them owns the retrieval corpus are healthy. The absence of anyone who owns it is not.
Key takeaways
- AI governance is a distinct discipline because models behave probabilistically and agents act; data governance has no concept of either.
- Build a distinct framework, not a separate organization. One classification scheme, one catalog, one impact process, one forum.
- Inventory and classification come first; most governance failures trace back to an AI system or a data source nobody had registered.
- Regulators dictate what you must prove, not how to organize. Map EU AI Act, GDPR and Privacy Act obligations to the evidence your register holds.
- Pick one accountable executive and give pillar owners budget for controls. Councils that only approve proposals do not govern anything.
- Keep the framework short enough that the second AI use case is faster to approve than the first.
Join your peers at AI + Data Security World 2027
Six cities, one room where security, data and privacy leaders compare notes on exactly these problems: Melbourne, May 5 · San Francisco, July 15 · London, September 15 · Singapore, September 30 · Sydney, October 14 · New York, November 11.
Not ready to register? Sign up for updates and we will send agenda releases and practitioner insights as they publish.