Most organizations do not lack AI principles. They lack a working system that turns those principles into decisions, controls, and evidence. This framework is that system. It gives governance, risk, compliance, and legal leaders a single operating model for standing up AI governance and running it across the full life of every model, application, and agent in the estate.
It is deliberately practical. Rather than restating what the NIST AI Risk Management Framework, ISO/IEC 42001, and the EU AI Act say, it shows how to implement all three at once through one set of processes, roles, and controls. Every control domain below maps back to those references so a single piece of work counts against more than one obligation.
What this framework is and how to use it
A control framework, not a new standard. It operationalizes the references you already answer to, so one program satisfies several at once.
The reference documents in this space answer different questions. The NIST AI Risk Management Framework (AI RMF 1.0) is a voluntary, outcome-based framework built on four functions: Govern, Map, Measure, and Manage. Govern is cross-cutting and sets the policies, accountability, and culture that make the other three possible; Map establishes context and identifies risks; Measure analyzes and tracks them; Manage acts on them and feeds results back into Govern. ISO/IEC 42001, published in December 2023, is the first certifiable management-system standard for AI. It follows the Plan-Do-Check-Act cycle and adds a set of AI-specific control objectives and supporting controls in its Annex A. The EU AI Act is binding law with a tiered, risk-based structure and financial penalties.
This framework sits underneath all of them. It defines the concrete processes and controls that let you demonstrate the outcomes NIST describes, the management system ISO requires, and the obligations the EU AI Act imposes. Use it in three ways:
- As a build plan. If you have no program yet, work top to bottom: principles, then lifecycle, then control domains, then operating model, following the phased sequence in Part 07.
- As a gap assessment. If you already govern AI informally, score yourself against the maturity model in Part 06 and target the next level.
- As a crosswalk. If you report against multiple references, use the control domains table in Part 04 to show auditors and regulators how one control answers several requirements.
Scope first. Before adopting any control, agree on what counts as an AI system in your organization. A definition that covers machine-learning models, statistical decision tools, third-party AI features inside purchased software, and generative and agentic systems will keep shadow use from falling outside the program.
Guiding principles
Seven principles set the intent every control serves. They are drawn from the OECD AI Principles, the NIST AI RMF, and the EU AI Act so the program stays consistent with all three.
The OECD AI Principles, adopted in 2019 and updated in 2024, are built on five values: inclusive growth and well-being, human-centered values and fairness, transparency and explainability, safety and security, and accountability. The following seven principles carry that intent into enterprise practice and give each control domain a reason to exist.
- Accountability. A named owner is answerable for every AI system, and the board or an equivalent body holds ultimate responsibility. Roles, decisions, and sign-offs are recorded.
- Transparency. The organization can explain, in proportion to the risk, how a system works, what data it uses, and where it is deployed. People interacting with AI are told when they are.
- Fairness. Systems are tested for discriminatory outcomes against protected groups, and material disparities are measured, documented, and addressed before deployment.
- Safety and robustness. Systems perform reliably across expected conditions and degrade predictably under stress. Accuracy and error rates are measured against defined thresholds, echoing EU AI Act Article 15.
- Privacy and security. Data is collected, used, and retained lawfully, and systems are protected against threats including data poisoning, model theft, and adversarial inputs.
- Human oversight. A person can understand, intervene in, and override consequential automated decisions, in line with EU AI Act Article 14.
- Contestability. People affected by an AI decision have a route to question it and seek human review, and the organization acts on what those challenges reveal.
Write these principles into policy once and reference them everywhere else. Each control in Part 04 should trace to at least one principle, which keeps the program defensible and stops it drifting into a checklist with no purpose.
The AI governance lifecycle
Eight stages, each with its own gate and controls. The lifecycle is where principles become decisions, and it mirrors the continuous, iterative loop that both NIST and ISO describe.
Governance fails when it is a one-time review at launch. It works when controls attach to each stage of a system's life and no system advances without passing the gate for its risk tier. The eight stages below apply to models you build, models you buy, and agents you assemble.
- Intake and risk tiering. Every proposed or existing use case is registered in a central inventory and assigned a risk tier. Tiering should reflect the EU AI Act structure: prohibited practices are rejected, high-risk uses (those in Annex III or safety components of regulated products) trigger the full control set, and limited or minimal-risk uses carry lighter obligations. The output is a triage decision and an assigned owner.
- Data governance. Training, validation, and input data are checked for lawful basis, quality, representativeness, and known bias, consistent with EU AI Act Article 10. Data lineage and consent are documented.
- Development. Design choices, model selection, and dependencies (including third-party models and datasets) are recorded. Documentation begins here, not at the end.
- Validation and assurance. The system is tested independently of the build team against performance, fairness, robustness, and security criteria. High-risk systems undergo bias testing and adversarial evaluation. Results are written up as evidence.
- Approval and deployment. A defined authority signs off against the risk tier. Higher tiers require sign-off from the governance committee, not the project team alone. Transparency notices and human-oversight mechanisms are in place before go-live.
- Monitoring. In production, systems are tracked for performance drift, fairness degradation, and misuse. Post-market monitoring of this kind is an explicit EU AI Act obligation (Article 72) for high-risk systems.
- Incident and change management. A defined process handles failures, harmful outputs, and material changes. Serious incidents involving high-risk systems must be reported to authorities under EU AI Act Article 73. Any significant change reopens validation.
- Retirement. When a system is decommissioned, data is handled per retention rules, documentation is archived for the required period, and downstream dependencies are checked.
Gates only work if they bite. If a project can reach production without a recorded intake and, for higher tiers, an independent validation, the lifecycle is decorative. Wire the gates into existing release, procurement, and change-management processes so they cannot be skipped.
Control domains and how they map
Nine domains cover the controls a program needs. Each row shows the objective, example controls, and the reference it satisfies, so one piece of work counts several times.
| Domain | Objective | Example controls | Maps to |
|---|---|---|---|
| Governance and accountability | Clear ownership, policy, and oversight for all AI | AI policy, risk appetite, governance committee, named system owners, decision logs | NIST Govern; ISO 42001 Clauses 5 and 6, Annex A policy controls; EU AI Act Art. 17 (quality management) |
| Inventory and use-case intake | Know every AI system and classify its risk | Central AI inventory, mandatory intake form, risk-tiering rules, shadow-AI discovery | NIST Map; ISO 42001 impact-assessment controls; EU AI Act Art. 6 and Annex III (classification) |
| Risk management | Identify, assess, and treat risks over the life of each system | Continuous risk assessment, treatment plans, residual-risk sign-off | NIST Map and Manage; ISO 42001 risk controls; EU AI Act Art. 9 (risk management system) |
| Data governance | Lawful, quality, representative data | Data lineage, bias screening, consent and lawful-basis checks, retention rules | NIST Map and Measure; ISO 42001 data controls; EU AI Act Art. 10 |
| Documentation and records | Evidence of how each system was built and run | Technical documentation, model cards, event logs, retained records | NIST Govern; ISO 42001 documented information; EU AI Act Art. 11 and 12 |
| Testing, validation, and assurance | Independent proof a system meets its criteria | Performance and fairness testing, adversarial evaluation, independent review before approval | NIST Measure; ISO 42001 verification and validation; EU AI Act Art. 15 |
| Transparency and human oversight | People can understand, be told about, and override AI | Disclosure notices, explainability artifacts, defined intervention and override points | NIST Map and Manage; ISO 42001 controls for interested parties; EU AI Act Art. 13, 14, and 50 |
| Monitoring and incidents | Detect and respond to problems in production | Drift and fairness monitoring, misuse detection, incident and serious-incident reporting | NIST Manage; ISO 42001 Check and Act; EU AI Act Art. 72 and 73 |
| Third-party and supply chain | Extend control to bought models, data, and providers | Vendor due diligence, contractual obligations, provider documentation review, GPAI reliance checks | NIST Govern and Map; ISO 42001 supplier controls; EU AI Act Art. 25 (value chain) |
Two distinctions run through the table. First, the EU AI Act assigns different duties to a provider (which develops or places a system on the market, obligations in Article 16) and a deployer (which uses one under its authority, obligations in Article 26). Map each system to your role, because building on a third-party model can make you a provider of the resulting high-risk system. Second, general-purpose AI models carry their own provider obligations, including technical documentation and a training-content summary, which have applied since 2 August 2025. When you build on a general-purpose model, the supply-chain domain is where you confirm the upstream provider has met them.
Roles and operating model
Governance needs an owner, a forum, and independent challenge. The three-lines model supplies the structure; a RACI keeps decisions from stalling.
Put a cross-functional AI governance committee at the center, chaired by an accountable executive and drawing in risk, compliance, legal, security, data, and the business. It owns the policy, sets risk appetite, and approves high-risk systems. Below it, structure responsibilities using the Institute of Internal Auditors' Three Lines Model (updated in 2020). The first line owns and operates the systems and the day-to-day controls. The second line, risk and compliance, sets standards, advises, and challenges. The third line, internal audit, provides independent assurance that the whole thing works. The governing body sits above all three.
| Activity | Board / Committee | Business and product (1st line) | Risk, compliance, legal (2nd line) | Internal audit (3rd line) |
|---|---|---|---|---|
| AI policy and risk appetite | A | C | R | I |
| Use-case intake and risk tiering | I | R | A | I |
| Development and documentation | I | R | C | I |
| Independent validation and approval | A (high-risk) | C | R | I |
| Production monitoring and incidents | I | R | A | I |
| Independent assurance | A | I | C | R |
R is responsible (does the work), A is accountable (owns the outcome, one per row), C is consulted, and I is informed. The pattern that matters: the people who build a system do not approve their own high-risk work, and internal audit reviews the program without owning any control in it. That separation is what makes the assurance credible to a regulator or a board.
Maturity model
Five levels describe how far a program has come. Score yourself honestly, then target one level up rather than reaching for the top in a single step.
| Level | Name | What it looks like |
|---|---|---|
| 1 | Ad hoc | No AI inventory and no owner. Governance happens project by project, if at all, and depends on individuals. Shadow AI is unknown and unmeasured. |
| 2 | Developing | A policy is drafted and a partial inventory exists. Reviews are informal and inconsistent. Risk tiering is not yet standardized, and evidence is scattered. |
| 3 | Defined | A documented framework is in force. Intake and risk tiering are mandatory, a governance committee meets, and roles are assigned across the three lines. |
| 4 | Managed | Controls are measured. Production systems are monitored, evidence is collected as a matter of course, and the program is mapped to NIST, ISO 42001, and the EU AI Act. |
| 5 | Optimized | Monitoring is continuous and evidence is largely automated. Findings feed back into policy, coverage extends to agents and general-purpose AI, and the organization can pursue ISO 42001 certification. |
Two moves account for most of the progress between levels. Getting from Level 1 to Level 3 is mainly about the inventory and mandatory intake: you cannot govern what you cannot see. Getting from Level 3 to Level 5 is mainly about evidence and monitoring: turning point-in-time reviews into a continuous, audit-ready record.
Implementation sequence
A phased path from a standing start to a running program in roughly a year. Sequence matters: visibility and mandate come before controls, and controls come before automation.
Treat 2 August 2026 as the planning horizon. That is the date the EU AI Act sets for high-risk obligations to apply, and it anchors the sequence above even though specific dates have been subject to amendment proposals. Working backward from it keeps the program honest about pace.
From framework to running system. The hardest part of the work above is not writing the policy; it is keeping a live inventory, assessing each system against the right obligations, and holding audit-ready evidence as models change. Dedicated AI governance platforms give governance teams one place to inventory, assess, and monitor models and agents against frameworks like the EU AI Act, NIST AI RMF, and ISO 42001.
Frequently Asked Questions
Does this framework replace NIST, ISO 42001, or the EU AI Act?
No. It operationalizes them. NIST AI RMF gives you outcomes, ISO/IEC 42001 gives you a certifiable management system, and the EU AI Act gives you binding obligations. This framework is the set of processes and controls that lets one program satisfy all three, with the crosswalk shown in the control domains table.
Where should we start if we have nothing in place?
Build the AI inventory and make intake with risk tiering mandatory. You cannot govern systems you cannot see, and tiering tells you where to spend effort. That is Phase 1 and Phase 2 of the implementation sequence, and it moves most organizations from ad hoc to a defined program.
Who owns AI governance?
Ownership is shared and structured through the three lines. The business owns and operates each system, risk and compliance set standards and challenge, and internal audit provides independent assurance. A cross-functional committee coordinates, and the board or an equivalent body holds ultimate accountability.
How is a system classified as high-risk under the EU AI Act?
A system is high-risk if it is listed in Annex III (uses such as employment, credit, and essential services) or is a safety component of a product covered by existing EU product-safety law. High-risk systems must meet the requirements in Articles 9 to 15, covering risk management, data governance, documentation, logging, transparency, human oversight, and accuracy, robustness, and cybersecurity.
Do we need ISO 42001 certification?
Certification is optional, not a legal requirement. It is useful when you want an independent body to verify your management system, which can reassure customers, regulators, and boards. Many organizations first build to the standard, reach the managed maturity level, and pursue certification once controls are demonstrably running.
How does this apply to generative AI and agents?
The same lifecycle and control domains apply, with additions. Providers of general-purpose AI models carry specific obligations, including technical documentation and a training-content summary, which have applied since August 2025. Agents add controls around tool access, autonomy limits, and human oversight of chained actions. The supply-chain domain is where you confirm upstream providers have met their duties.