A governance framework is a list of the things a program has to cover, so that gaps are visible rather than discovered. This one has fourteen domains. Few organizations start with all of them, and the order they are built in matters more than the list, which is why the order has a page of its own.
If you are looking for what AI governance is rather than what it contains, start with the definition.
Where these domains come from
They are not invented. They are the intersection of three publicly available bodies of work, expressed as things an organization has to decide rather than as functions of a framework.
The NIST AI Risk Management Framework organizes AI risk management into four functions, GOVERN, MAP, MEASURE and MANAGE, with GOVERN cutting across the other three. The GAO AI Accountability Framework is organized around Governance, Data, Performance and Monitoring, and sets out key practices beneath each, with questions addressed to entities, auditors and third-party assessors. ISO/IEC 42001:2023 specifies requirements for an AI management system, which is a different kind of instrument again: a certifiable management system rather than voluntary guidance.
All three are voluntary. None of them is law, and adopting the domains below does not make an organization compliant with anything. What they do is give a governing body, an auditor or a customer a recognized point of comparison.
Leadership and accountability
Who decides what AI is adopted, who owns each system in the sense of being answerable for it, and who is told when one behaves unexpectedly.
The test of this domain is whether a specific person can decline a specific request. If approval is a process nobody owns, everything downstream is decoration. In a small organization this is one named person with an escalation route; at scale it is a standing group with representation from technology, legal, records and the service areas.
AI inventory
A current record of the AI systems in use, including features switched on inside products the organization already licenses.
Every other domain depends on this one, which is why it is usually the first thing built and why a policy written before it governs an organization nobody has described. What to record and how to keep it current is covered in AI inventory and use-case management.
Risk classification
A consistent way to sort systems by consequence, so that oversight is proportionate rather than uniform.
Uniform oversight fails in both directions at once: it makes trivial requests slow and gives genuinely consequential systems no more scrutiny than a meeting-notes summariser. The usual dividing line is effect on a person. A system that drafts internal text is not in the same category as one bearing on eligibility, employment, discipline, grading, safety or a benefit, and the classification should say so explicitly rather than leaving it to judgment each time.
ISO/IEC 42005:2025 addresses AI system impact assessment specifically, and is the natural reference if you want a published treatment of this domain.
Policy
The documents that turn the governance structure into decisions staff can apply without asking anyone.
The failure mode is a policy that states AI must be used responsibly and gives nobody a way to decide whether a specific tool, on a specific dataset, is permitted. A policy set that works usually contains an acceptable-use position, a data rule, a procurement position and a statement of where human review is required. What belongs in an AI acceptable use policy covers the first of those in detail.
Data governance and privacy
What data may be used, where it goes, how long it is retained, who may see the outputs, and what the vendor may do with any of it.
This is the domain most often assumed to be covered by an existing privacy program and most often not. AI systems introduce categories that predate nothing in a classic data map: prompts, retrieval indexes, embeddings, conversation history, and model outputs that may themselves contain regulated information. GAO reported in March 2026 that OMB guidance to federal agencies did not fully address the privacy risks and challenges it identified, which is a reasonable indication that this is genuinely difficult rather than merely neglected.
Security
Identity, access control, logging, secure integration, and the controls specific to AI systems rather than to software generally.
AI inherits permissions. A retrieval system indexed over a shared drive will answer questions using everything the requesting account can reach, including material the person never knew they could open. That is a governance problem before it is a technical one. The NIST Cybersecurity Framework 2.0 and current CISA guidance cover the general controls; the AI-specific risks are set out in the AI cybersecurity risks to assess before deployment.
Vendor management
What you ask a supplier before adoption, and what your contract says when their model changes.
Most AI in most organizations arrives inside a product bought for another reason, under terms agreed before the feature existed. The questions worth asking, and the contract terms worth having, are in AI vendor risk assessment.
Human oversight
Where a person must review before an output takes effect, where a person may override, and where automation is acceptable without review.
The clause usually missing is authority. A reviewer who cannot in practice overturn a recommendation is a rubber stamp, and describing them as human oversight in a policy is worse than claiming no oversight at all. Record who the reviewer is, what information they have, and that they may disagree.
Testing and validation
What is checked before a system is deployed, against what expectation, and what evidence is kept.
For most organizations adopting third-party AI this is not model evaluation in a research sense. It is narrower and more answerable: does this system do the specific job we are adopting it for, on our data, well enough, and how would we know if that stopped being true.
Monitoring
How a system is watched after go-live, and what triggers a review rather than a renewal.
Approval without a review date is a decision about a system that no longer exists. Vendors update models, switch capabilities on by default and revise terms, and use cases drift from the one that was approved. Monitoring is the GAO framework's fourth principle for the same reason.
Incident management
What counts as an AI incident, who is told, how quickly, and how it is recorded.
The definitional work is most of the value here. An AI incident is not only a breach. It includes an output that was wrong in a way that reached someone, a system used outside its approved purpose, and a vendor change that invalidates an earlier assessment. If none of those has a reporting route, they will be handled informally and invisibly.
Documentation
The record that lets you show a decision was made, by whom, and on what basis.
This is the domain that turns governance from a practice into something a board, an auditor, a customer or a regulator can examine. It is also the cheapest to build while decisions are being made and the most expensive to reconstruct afterwards.
Workforce training
What staff are told they may do, and how they are told when it changes.
Training that consists of circulating a policy does not change behavior. What changes behavior is a short, current, findable statement of what is approved, what is prohibited, and where to ask, published somewhere people already look.
Continuous improvement
The review cycle that keeps the other thirteen current as tools, vendors and obligations change.
Set a cadence and a trigger list rather than a date. Reassessment on a schedule catches drift; reassessment on a trigger, such as a vendor changing its model or terms, catches the things that matter most and would otherwise wait for the schedule.
Using this as a gap list
The framework is most useful read as fourteen questions rather than fourteen projects. For each domain, ask whether a specific person could answer it today for a specific system, and record the answer. What comes out is a gap list ordered by how exposed the organization actually is, which is a better starting point than any generic maturity model.
If you would rather work through it as a checklist, the AI governance checklist is the same material in a form you can take into a meeting. Public bodies have four additional constraints that change several of these domains, covered in AI governance for public-sector organizations.
LABUSA's our AI governance services assess these domains against what an organization actually has, and produces the gap list rather than the framework. If you want that done with you, get in touch.