AI governance needs a structure that names who builds, who tests and who decides, plus recognized frameworks to organize the work. NIST AI RMF and ISO/IEC 42001 supply the vocabulary and controls, and governance runs through development, deployment, operation and change.
ADG (Adopt, Defend, Govern) splits AI work into three jobs that must not collapse into one person: Adopt builds and runs, Defend tries to break and protect, and Govern authorizes and oversees. It is the same idea as keeping the cashier, the auditor and the manager who signs off as separate people. When Adopt and Defend cannot agree, they escalate to Govern.
diagram
Adopt and Defend each escalate to Govern, which decides and sets the conditions. Defend's test results go back to Adopt before any release.
Key points
EC-Council's ADG (Adopt, Defend, Govern) framework has three pillars: ADOPT executes and delivers, DEFEND secures and validates, and GOVERN oversees, assures and decides.
Each pillar asks its own question: can we deploy it effectively (Adopt), can it be abused or cause harm (Defend), and should we approve it, on what terms and at what risk (Govern).
Adopt roles include the AI product owner and prompt designer; Defend roles include the AI red team lead, guardrail engineer and bias auditor; Govern roles include the model risk officer and privacy counsel.
Minimum Control MC-3 (Separation of Duties) splits deployment ownership, security validation and approval authority, evidenced by a RACI (responsible, accountable, consulted, informed) matrix per system.
Adopt escalates blockers and Defend escalates unresolved risks to Govern, which resolves the tension and sets go/no-go and exception policy.
ISO/IEC 42001 Annex A area A.3 (internal organization) requires defined AI roles and responsibilities and a way to report concerns.
NIST AI Risk Management Framework (AI RMF) GOVERN 2.3 makes executive leadership responsible for AI risk decisions, and GOVERN 5 engages relevant external AI actors for feedback.
Exam tip
If one team both ships a model and signs off its safety testing, separation of duties (MC-3) is broken. The fix is independent validation by Defend and approval by Govern.
Every AI program eventually hits a standoff: the delivery team wants to ship and the security team says it is not safe. ADG's (Adopt, Defend, Govern) AI Governance Council is the referee with the authority to decide, set conditions and record any exception. Without a named tie-breaker, the loudest voice or the deadline wins.
diagram
A disputed release escalates from both Adopt and Defend to the AI Governance Council. The Council decides against the risk appetite, records any exception with an expiry and reports high-risk decisions to the board.
Key points
EC-Council's ADG (Adopt, Defend, Govern) framework calls for a cross-functional AI Governance Council with members from ADOPT, DEFEND and GOVERN as the escalation and tie-breaking body.
The Council resolves disputes between delivery and safety, sets go/no-go thresholds for deployment and owns the Governance Exception Register.
Its decision rights tie to Minimum Controls MC-3 (Separation of Duties) and MC-10 (governance reviews with exception handling and board reporting for high-risk systems).
GOVERN owns the Council charter, defines AI risk appetite and escalation paths, and sets board reporting; the Council is chartered in the Foundation phase (months 0 to 3).
Every exception carries a justification, risk acceptance and an expiry date, and MC-10 review records capture findings, decisions and exception dispositions.
Choosing the oversight model, human in the loop (HITL), on the loop (HOTL) or out of the loop (HOOTL), is a GOVERN step that needs a documented rationale.
ADG positions the Council as what peer frameworks rarely name: they say to govern AI, while ADG names who decides when the pillars conflict.
Exam tip
When Adopt and Defend disagree about a release, escalate to the AI Governance Council; neither team, nor the vendor, decides alone. Exceptions are recorded and time-bound, never open-ended.
ADG RACI matrix record for MC-3 (illustrative) · json
The NIST AI Risk Management Framework (AI RMF) is a free, voluntary playbook for handling AI risk, built around four verbs. Govern sets up people and policy, Map understands the context, Measure tests and tracks, and Manage acts on what was found. Govern wraps around the other three like the frame of a house.
diagram
GOVERN informs every other function. MAP, MEASURE and MANAGE then cycle iteratively across the AI lifecycle.
Key points
The NIST AI Risk Management Framework (AI RMF 1.0, NIST AI 100-1), released 26 January 2023, is voluntary; its Core has four functions: GOVERN, MAP, MEASURE and MANAGE.
GOVERN is cross-cutting and infused through the others; once it is in place, MAP, MEASURE and MANAGE can run in any order across the lifecycle, iteratively.
GOVERN has 6 categories (policies, accountability, workforce diversity, culture, stakeholder engagement, third-party risk); MAP has 5, MEASURE has 4 and MANAGE has 4.
MAP establishes context, categorizes the system, maps benefits, costs and component risks including third parties, and characterizes impacts on individuals, groups and society.
MEASURE selects methods and metrics, evaluates trustworthy characteristics through test, evaluation, verification and validation (TEVV), tracks risks over time and checks measurement efficacy.
MANAGE prioritizes and responds to risks (mitigate, transfer, avoid or accept), manages third-party risk and runs post-deployment monitoring, incident response, recovery and decommissioning.
The AI RMF Playbook gives suggested actions per outcome; AI RMF 1.0 remains current while NIST revises it under the July 2025 White House AI Action Plan.
Exam tip
GOVERN is the cross-cutting foundation, not just step one of a straight line. Establishing context is MAP, testing and metrics are MEASURE, and responding to risk is MANAGE.
The NIST AI Risk Management Framework (AI RMF) describes what trustworthy AI looks like and lets each organization tailor the framework through profiles. A profile is like a fitness plan: where you are now, where you want to be and the gap between them. NIST also publishes ready-made profiles, such as one for generative AI.
Current Profile
Target Profile
What it describes
Today's state
How AI risk is managed now
Outcomes already achieved
Desired state
Outcomes needed to meet goals
Set by risk tolerance and context
How it is used
Baseline
Starting point for gap analysis
Destination
Drives priorities and the roadmap
A temporal profile compares today's AI risk management outcomes with the outcomes the organization needs. The gap between them becomes the improvement plan.
Key points
Under the NIST AI Risk Management Framework (AI RMF), trustworthy AI is valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair.
The fairness characteristic is fair with harmful bias managed; valid and reliable is the necessary base for the others, and accountable and transparent relates to all of them.
Profiles tailor the Core: use-case profiles (for example hiring), temporal profiles comparing a Current Profile with a Target Profile to find gaps, and cross-sectoral profiles.
NIST AI 600-1, the Generative Artificial Intelligence (GAI) Profile released 26 July 2024, is a cross-sectoral profile and companion resource to the AI RMF.
AI 600-1 names 12 risks novel to or worsened by GAI, including confabulation, information integrity, data privacy, intellectual property, and value chain and component integration.
On 7 April 2026 NIST released a concept note for an AI RMF Profile on Trustworthy AI in Critical Infrastructure.
NIST publishes crosswalks that map the AI RMF to other frameworks and standards, so one control set can serve several obligations.
Exam tip
A Current versus Target Profile gap analysis is the AI RMF way to plan improvement. Confabulation is NIST's word for confidently stated false output, the colloquial hallucination.
ISO/IEC 42001 is to AI what ISO/IEC 27001 is to information security: a management system an organization can be certified against. It does not judge a single model; it checks that the organization has a repeatable way to set AI policy, assess risk and impact, run controls and improve. Auditors look for evidence that this cycle actually runs.
diagram
ISO/IEC 42001 runs Plan-Do-Check-Act across Clauses 4 to 10. Planning includes the AI risk and impact assessments, and Clause 10 feeds corrections back into planning.
Key points
ISO/IEC 42001:2023 (published December 2023) is the world's first AI management system standard, setting requirements to establish, run and continually improve an AI management system (AIMS).
It applies to any organization that develops, provides or uses AI-based products or services, of any size, including public sector agencies and non-profits.
It uses the common management system structure, Clauses 4 to 10 (context, leadership, planning, support, operation, performance evaluation, improvement), with Plan-Do-Check-Act (PDCA).
Planning requires an AI risk assessment (6.1.2), risk treatment with a Statement of Applicability (6.1.3) and an AI system impact assessment (6.1.4) on individuals, groups and society.
Annex A holds 38 reference controls in nine areas: policies (A.2), internal organization (A.3), resources (A.4), impact assessment (A.5), life cycle (A.6), data (A.7), information (A.8), use (A.9), third parties (A.10).
Annex B gives implementation guidance for the Annex A controls, Annex C lists potential AI objectives and risk sources, and Annex D covers use across domains and sectors.
It is a voluntary, certifiable standard, not a law; certification bodies follow ISO/IEC 42006:2025, and a working AIMS produces the evidence regulators expect.
Exam tip
Pick ISO/IEC 42001 when a question mentions certification, an AI management system or a Statement of Applicability. The NIST AI Risk Management Framework is voluntary guidance with no certification scheme.
ISO/IEC 42001 sits inside a family of AI standards, each with one job. One defines the words, one guides risk management, one guides impact assessment, one tells boards how to govern AI and one tells auditors how to certify. Matching the number to the job is a classic exam question.
diagram
Each standard in the family does one job. Only ISO/IEC 42001 is certified against, and EN 18286 is the EU harmonised quality management standard for the AI Act.
Key points
ISO/IEC 22989:2022 establishes AI concepts and terminology, and ISO/IEC 23053 sets a framework for describing AI systems that use machine learning (ML).
ISO/IEC 23894:2023 gives guidance on managing risk specifically related to AI and on integrating risk management into AI-related activities.
ISO/IEC 42005:2025 (May 2025) guides AI system impact assessments: how AI systems and their foreseeable applications may affect individuals, groups or society.
ISO/IEC 42006:2025 (July 2025) adds requirements, on top of ISO/IEC 17021-1, for bodies that audit and certify AI management systems against ISO/IEC 42001.
ISO/IEC 38507:2022 guides members of the governing body on enabling and governing AI use so that it is effective, efficient and acceptable.
ISO/IEC 42001 is the requirements standard an organization certifies its AI management system (AIMS) against; 22989, 23894, 42005 and 38507 give terminology and guidance.
In the EU, EN 18286:2026 is the first harmonised standard under the AI Act: a quality management system (QMS) standard built to layer on ISO/IEC 42001, ISO 9001 or a sector QMS.
Exam tip
Match the number to the job: 22989 terms, 23894 risk, 42001 management system, 42005 impact assessment, 42006 certification bodies, 38507 board governance.
Development governance puts checkpoints into how AI is sourced, trained and assembled, before anything reaches users. It is like building inspections during construction instead of one look at the finished house. ADG (Adopt, Defend, Govern) treats the lifecycle as a loop, so lessons from retired systems shape the next sourcing decision.
diagram
ADG's six lifecycle stages form a loop. Retire/Learn feeds lessons back into sourcing, so governance never ends at deployment.
Key points
EC-Council's ADG (Adopt, Defend, Govern) framework governs six lifecycle stages in a loop: Pre-training/Sourcing, Post-training/Alignment, Build/Integrate, Deploy/Authorize, Run/Monitor and Retire/Learn.
At Sourcing, Adopt selects fit-for-purpose datasets, Defend checks provenance abuse and contamination risk, and Govern approves licensing, jurisdictional limits and data ethics.
At Post-training, Defend tests for regressions, bypasses, safety loss and fairness drift, while Govern reviews alignment objectives, documentation sufficiency and responsible AI criteria.
At Build/Integrate, Govern classifies the use case and sets its risk tier and oversight needs (Minimum Control MC-2), while Defend validates interfaces, secrets and input validation.
ISO/IEC 42001 Annex A area A.6 covers the AI system life cycle, from objectives for responsible development and requirements specification onward; A.7 covers data quality and provenance.
NIST AI Risk Management Framework (AI RMF) MAP 1.6 elicits system requirements from relevant AI actors and weighs socio-technical implications in design decisions.
For EU high-risk systems, training, validation and testing data must meet Article 10 quality criteria, and technical documentation (Article 11) is drawn up before market placement.
Exam tip
Governance belongs at every stage, not only at release; ADG's principle is that no single gate is sufficient. Data provenance and licensing are approved by Govern at sourcing.
Deployment governance is the release gate: nothing goes live until testing is complete, the right level of human oversight is chosen and someone with authority signs. Think of a pre-flight checklist where the captain, not the mechanic, gives the final go. If something is not ready, the system ships under a recorded, time-limited exception or not at all.
diagram
A release candidate passes MC-4 testing and gets an oversight tier before Govern decides. The outcome is go-live, a time-limited exception with conditions, or a return to Adopt.
Key points
ADG (Adopt, Defend, Govern) Minimum Control MC-4 requires quality, safety, security, fairness and failure-mode testing before production, evidenced by a signed report covering all four harm classes.
ADG's four harm classes are Technical (security and integrity), Societal (bias and rights), Operational (reliability and accuracy) and Systemic (emergent AI-to-AI risk).
The AI Release Gate Checklist verifies security, fairness, safety and governance approval; at Deploy/Authorize, Govern grants formal approval or an exception with documented conditions.
Human in the loop (HITL) approves every output, human on the loop (HOTL) monitors and can intervene, and human out of the loop (HOOTL) gets periodic review; Govern picks the tier.
Higher autonomy needs stronger controls: ADG marks the Agentic Orchestration, Agent and Agentic Hardening overlays as required for HOTL and HOOTL systems.
NIST AI Risk Management Framework (AI RMF) MANAGE 1.1 decides whether deployment should proceed, and MEASURE 2.6 requires residual risk not to exceed the risk tolerance.
EU AI Act Article 14 requires high-risk systems to be built so people can effectively oversee them in use, and Article 26 has deployers assign competent, trained overseers.
Exam tip
The best answer gives go-live authority to Govern after Defend's independent testing, with the oversight tier documented. A deadline never justifies skipping the gate; use a recorded, expiring exception instead.
AI systems change after launch: data drifts, users find new tricks and someone quietly edits a prompt. Operations governance watches production continuously and checks that what is running is still what was approved. It is the difference between passing a driving test once and having a dashcam plus regular inspections.
diagram
Production telemetry is checked continuously against approved behavior. Drift, abuse or bias triggers containment, reporting and a governed change before the system returns to service.
Key points
ADG (Adopt, Defend, Govern) Minimum Control MC-8 watches production for abuse, drift, data leakage, unsafe actions, bias emergence and configuration drift, with alert thresholds and response times.
ADG post-deployment practices: configuration drift detection, usage authorization monitoring, change control for new capabilities, continuous automated evaluation and roadmap re-evaluation.
NIST AI Risk Management Framework (AI RMF) MEASURE 2.4 monitors system behavior in production, and MANAGE 4.1 runs monitoring plans covering appeal, override, incidents and change.
EU AI Act Article 72 requires high-risk providers to run a documented post-market monitoring system based on a plan that is part of the technical documentation.
Regulation (EU) 2026/1744, the AI Omnibus, has the Commission adopt guidance and a template for the post-market monitoring plan by 2 September 2027.
Deployers monitor high-risk systems per the instructions for use, inform the provider of risks and serious incidents, and keep automatic logs for at least six months (Article 26).
ADG outcome metrics include mean time to detect (MTTD) and mean time to contain (MTTC) AI incidents and the share of systems running within approved configuration.
Exam tip
Configuration drift means production no longer matches what was approved, and it is a governance finding even when accuracy looks fine. Post-market monitoring is the provider's duty; deployers monitor and report.
Every change to a model, prompt, tool or data source is a chance for the system to behave differently from what was approved. Maintenance governance treats those changes like changes to a bridge design: logged, reviewed, retested and, if big enough, certified again. It also plans how to roll back or retire a system safely.
diagram
A planned, pre-assessed change follows normal change control and retesting. An unplanned change that affects compliance or purpose is a substantial modification and needs a new conformity assessment.
Key points
ADG (Adopt, Defend, Govern) Minimum Control MC-5 routes changes to prompts, tools, models and retrieval sources through governed change control, evidenced by a Model and Prompt Change Log.
MC-11 requires fairness re-evaluation after model or data changes, and new features on a deployed system are re-assessed against its original risk classification and approval conditions.
Under the EU AI Act, a substantial modification is an unplanned change that affects compliance or the intended purpose; the high-risk system then needs a new conformity assessment (Article 43(4)).
Changes in a learning system that the provider pre-determined and assessed at the initial conformity assessment are not a substantial modification (Recital 128).
A deployer or distributor that substantially modifies a high-risk system, or changes a system's purpose so it becomes high-risk, becomes its provider under Article 25.
NIST AI Risk Management Framework (AI RMF) MANAGE 2.4 assigns how to supersede, disengage or deactivate systems acting outside intended use, and GOVERN 1.7 covers safe decommissioning.
At ADG's Retire/Learn stage, Adopt decommissions, Defend preserves evidence and validates closure, and Govern updates policy and feeds lessons back into sourcing.
Exam tip
If an update was not foreseen in the original conformity assessment and changes compliance or purpose, think substantial modification and a new conformity assessment. Rollback readiness is part of every controlled release.
Pin an approved model file and tag the release to its change ticket · bash
sha256sum contoso-claims-v2.3.safetensors > contoso-claims-v2.3.sha256
git add contoso-claims-v2.3.sha256 prompts/system-prompt.md
git commit -S -m "CHG-1042: model v2.3 and prompt update, Council approved"
git tag -s model-v2.3 -m "Approved release, rollback target model-v2.2"
sha256sum -c contoso-claims-v2.3.sha256