AI Governance Guide: Policies, Inventories and Oversight

Many organisations are already running AI in production without a complete list of where it is, who owns it, what risk it carries or who can switch it off. AI governance closes that gap: the policies, roles, inventories, approval gates and oversight that let an organisation adopt AI deliberately and prove it did so. This guide covers the NIST AI Risk Management Framework and its Generative AI Profile, ISO/IEC 42001, the EU AI Act as amended by the Digital Omnibus on AI and OMB M-25-21, and turns them into an operating model: register, risk tiers, oversight and decommissioning. It is written for CISOs, risk and compliance leads, AI platform owners and the people asked to chair or staff an AI governance committee.

Key takeaways

The inventory comes first. NIST GOVERN 1.6 asks for mechanisms "to inventory AI systems"; every other control (tiering, oversight, incident response, decommissioning) depends on knowing what exists and who owns it.
Tier by use case, not by technology. The same model can be minimal risk in a drafting tool and high-risk when it screens job applicants, so approval depth should follow the decision the AI influences.
Human oversight needs authority, not just a reviewer. The EU AI Act requires overseers with "the necessary competence, training and authority" and the means to override or stop the system.
The EU AI Act timeline moved. The Digital Omnibus on AI (Regulation (EU) 2026/1744) pushed Annex III high-risk obligations to 2 December 2027 and Annex I to 2 August 2028; prohibitions and general-purpose AI rules already apply.
Plan the exit at approval time. NIST GOVERN 1.7 and MANAGE 2.4 expect processes to deactivate and decommission AI systems safely, including their data, credentials and integrations.

Frameworks and laws compared

Most programmes combine a management system, a risk method and the applicable law. They overlap heavily, so pick one backbone and map the others to it.

Instrument	Type	What it asks for	Key artefacts
NIST AI RMF 1.0 (AI 100-1, January 2023)	Voluntary framework	Four functions: GOVERN, MAP, MEASURE, MANAGE; seven trustworthy characteristics from "valid and reliable" to "fair with harmful bias managed"	Policies, AI inventory, risk tolerances (MAP 1.5), monitoring plans
NIST AI 600-1 Generative AI Profile (July 2024)	Voluntary profile of the AI RMF	12 generative AI risks, such as Confabulation, Data Privacy and Information Security, with suggested actions per subcategory	Inventory entries with foundation model, version and access mode (GV-1.6-003); incident criteria (GV-4.3-002)
ISO/IEC 42001:2023	Certifiable management system standard	Requirements for an AI management system (AIMS) for organisations developing, providing or using AI	AI policy, scope, risk and impact assessments, statement of applicability against Annex A
ISO/IEC 42005:2025	Guidance standard	How to conduct AI system impact assessments on individuals, groups and society	Impact assessment records
EU AI Act (Regulation (EU) 2024/1689), amended by Regulation (EU) 2026/1744	Law, risk-based	Prohibitions, high-risk duties for providers and deployers, transparency, general-purpose AI model rules, AI literacy	Classification records, FRIA, logs, registration, instructions for use
OMB M-25-21 (3 April 2025)	US federal policy for agencies	Chief AI Officer, AI Governance Board, annual AI use case inventory, minimum practices for high-impact AI	Public inventory, AI impact assessments, waivers

NIST AI RMF: a free, outcome-based risk vocabulary that maps well to the NIST CSF 2.0 GOVERN function; its seven trustworthy characteristics make a ready set of responsible AI principles for policy.
ISO/IEC 42001: for when customers or regulators want third-party assurance. Annex A has 38 controls in nine areas, A.2 Policies related to AI to A.10 Third-party and customer relationships, and the standard shares the ISO management system structure with ISO/IEC 27001.
OMB M-25-21: binds only US federal agencies, but its high-impact definition and seven minimum practices are a good template.

Roles and the governance operating model

NIST GOVERN 2.1 asks for documented "roles and responsibilities and lines of communication", and GOVERN 2.3 puts responsibility for AI risk decisions on executive leadership. M-25-21 gives a concrete pattern: each agency designates a Chief AI Officer within 60 days, and CFO Act agencies convene an AI Governance Board chaired at Deputy Secretary level with the CAIO as vice-chair.

Role	Accountable for	Typical holder
Board or executive sponsor	AI risk appetite, policy approval, high-risk acceptance	Board risk committee, executive committee
AI governance committee (AI review board)	Approving high-tier use cases, exceptions and waivers; reviewing metrics and incidents	Chaired by a senior executive; members from security, privacy, legal, risk, HR, data and the business
Chief AI Officer or AI governance lead	The inventory, tiering process, policy upkeep, reporting	CAIO, CDO or head of AI risk
AI system owner	A named use case through its life: register entry, controls, monitoring, decommissioning	Business owner, not the vendor or data scientist
Human overseer	Reviewing, overriding or stopping the system in operation	Trained operator with authority to act
Second line (risk, compliance, model risk)	Independent challenge, validation, testing standards	Model risk management, compliance
Security and privacy	Threat models, data protection impact assessments, access, red teaming	CISO and DPO teams

Charter the committee: scope, decision rights, quorum, escalation path and the tiers it must see. Without decision rights it becomes a discussion group.
Keep ethics and approval together: an AI ethics board that cannot block deployments tends to be ignored; give it approval authority or a formal veto on defined tiers.
Diverse input: NIST GOVERN 3.1 asks for decisions "informed by a diverse team", and GOVERN 5.1 for external feedback.

Policies and the AI use case register

An AI policy states principles; the register makes them enforceable. NIST AI 600-1 action GV-1.6-001 asks organisations to "Enumerate organizational GAI systems for incorporation into AI system inventory", and GV-1.6-003 adds the underlying foundation models, versions and access modes. M-25-21 requires agencies to inventory AI use cases at least annually and publish a public version.

Ownership: unique ID, business and technical owners, supplier, status (proposed, pilot, production, retired).
Purpose and context: intended purpose and users (NIST MAP 1.1), decisions influenced, affected people.
Technology: model and version, provider, hosting, retrieval sources, tools and agents, AI-BOM reference.
Data: data used for training, retrieval and prompts, personal or special category data, retention.
Risk: internal tier, EU AI Act category and role (provider or deployer), link to impact assessments, DPIA and FRIA.
Controls: human oversight design, monitoring, logging, last test date, open findings, exceptions.
Access: the service accounts, API keys and agent identities the system uses, and their owners.
Exit: deactivation procedure, fallback process, decommissioning date when known.

Do not rely on self-declaration: procurement data, SaaS discovery, cloud AI usage, OAuth grants and network logs all reveal unregistered AI. See the Shadow AI Discovery Guide. The Vercel Context.ai OAuth breach shows how a forgotten AI app's stolen token can expose customer secrets.

Risk tiers and use case approval

Tiering decides how much review a use case gets. Align tiers to EU AI Act categories where in scope, and add tiers for risks the Act ignores, such as confidential data exposure or autonomous actions.

Internal tier	Examples	EU AI Act link	Approval and controls
Prohibited	Social scoring, emotion recognition in the workplace, untargeted facial image scraping	Article 5 prohibited practices	Not approved; policy bans and procurement checks
High	Recruitment screening, credit decisions, access to essential services, safety components	High-risk under Article 6 and Annexes I and III	Committee approval, impact assessment, FRIA where required, documented oversight, logging, testing, annual review
Elevated	Customer-facing chatbots, agents with write access, AI handling confidential data	Article 50 transparency duties for chatbots and synthetic content	Owner plus security and privacy sign-off, red teaming, disclosure to users, monitoring
Standard	Internal drafting, summarisation of non-confidential content, code assistants on approved platforms	Minimal risk; AI literacy still applies	Register entry, approved tool list, acceptable use policy

Article 6(3) derogation: an Annex III system is not high-risk if it performs "a narrow procedural task", improves a completed human activity, detects deviations from prior decisions without replacing human review, or does preparatory work. Profiling is always high-risk, and a provider using the derogation must document it beforehand and register under Article 49(2).
Provider or deployer: putting your name on a high-risk system, substantially modifying it or changing its intended purpose can make you the provider under Article 25, with far heavier duties. Record the role per use case.
Approval gates: intake, tiering, security and privacy review, test evidence, decision, register update. Re-tier on any change of model, purpose, data or autonomy.

The EU AI Act timeline after the Digital Omnibus

Regulation (EU) 2026/1744 of 8 July 2026, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It amended Article 113 and several obligations.

Date	What applies
2 February 2025	Chapters I and II: definitions, AI literacy (Article 4) and the original Article 5 prohibitions
2 August 2025	General-purpose AI model obligations (Chapter V), governance, penalties
27 July 2026	Omnibus in force; Articles 102 to 110 apply
2 August 2026	General date of application, including Article 50 transparency duties
2 December 2026	New prohibitions on non-consensual intimate deepfakes and child sexual abuse material (Article 5(1)(ba) and (bb)); end of the Article 50(2) marking grace period for generative systems placed on the market before 2 August 2026
2 December 2027	High-risk obligations for Annex III systems (Article 6(2)), previously 2 August 2026
2 August 2028	High-risk obligations for Annex I product safety systems (Article 6(1))
2 August 2030	Deadline for high-risk systems intended for use by public authorities that were placed on the market before the application dates

AI literacy was softened, not removed: amended Article 4 says "Providers and deployers of AI systems shall take measures to support the development of AI literacy of their staff", without requiring a specific level for any individual.
Deployer duties (Article 26): use high-risk systems per the instructions, assign human oversight, ensure input data is "relevant and sufficiently representative", monitor and suspend use on risk, report serious incidents, keep logs "of at least six months", inform workers' representatives and affected people.
Fundamental rights impact assessment (Article 27): required before first use for public bodies, private entities providing public services, and deployers of Annex III point 5(b) and (c) systems such as credit scoring and life and health insurance pricing; it complements the GDPR DPIA. See the DPIA Guide.
Penalties (Article 99): up to EUR 35 million or 7% of worldwide turnover for prohibited practices, and EUR 15 million or 3% for most other obligations including Articles 26 and 50; SMEs pay the lower of the two figures.

See the Agentic AI Compliance Guide for how these duties apply to agents.

Human oversight that works

Article 14(4) lists what overseers of high-risk systems must be enabled to do: understand the system's "capacities and limitations", stay aware of automation bias, interpret output correctly, decide not to use or to "disregard, override or reverse" output, and intervene through a "'stop' button or a similar procedure". M-25-21 asks for "human oversight, intervention, and accountability suitable for high-impact use cases", plus timely human review and appeal for affected individuals.

Design the review, not just the reviewer: show inputs, confidence and reasons, give reviewers authority to reject output without penalty and time to do it, and measure how often they disagree. An override rate near zero usually signals rubber-stamping.
Match oversight to autonomy: human-in-the-loop approval for consequential actions, human-on-the-loop monitoring with a kill switch for lower-risk automation. The Replit AI agent database deletion happened during a code freeze that the agent ignored, which is why oversight must be enforced by permissions, not instructions.
Own the answers: the Air Canada chatbot ruling made the airline liable for its bot's wrong answer; customer-facing AI needs an owner who reviews what it says.

Monitoring, incidents and decommissioning

NIST MANAGE 4.1 expects post-deployment monitoring plans that include user input, "appeal and override, decommissioning, incident response" and change management. MANAGE 2.4 requires mechanisms to "supersede, disengage, or deactivate" systems that perform inconsistently with intended use.

Monitoring: accuracy and drift against the launch baseline, complaints and appeals, override rates, cost, and provider model changes you did not initiate.
Incidents: define what counts as an AI incident (NIST AI 600-1 GV-4.3-002 asks for minimum reporting criteria), route it through the existing incident process, and for EU high-risk systems inform the provider and authorities as Article 26(5) requires.
Third parties: GOVERN 6.1 and 6.2 cover third-party AI risk and contingency plans; GV-6.2-004 asks for continuous monitoring of third-party generative AI. Contract for notice of model changes, incidents and data use limits.
Decommissioning: GV-1.7-001 asks that systems "are able to be deactivated when necessary"; GV-1.7-002 lists data retention and post-decommissioning leakage among the factors. Retire the endpoint, revoke API keys, service accounts and OAuth grants, delete or archive prompts, logs, embeddings and fine-tuning data per retention rules, move users to the fallback process, and close the register entry with evidence.

Choosing your approach

Small organisations: one accountable lead, a short acceptable use policy, an approved tools list, a lightweight register and three tiers, with the NIST AI RMF as reference; certification is rarely worth it yet.
Vendors selling AI to enterprise or public buyers: ISO/IEC 42001 certification gives buyers evidence; build it on an existing ISO/IEC 27001 ISMS to reuse document control, internal audit and management review.
Large or regulated organisations: a committee with decision rights, a CAIO or equivalent, integration with model risk management, and EU AI Act role mapping per use case, with tiering embedded in procurement and change management.
Building versus buying: builders carry provider-style duties (data governance, testing, documentation); buyers focus on due diligence, contracts, oversight and monitoring.

Implementing an AI governance programme

Appoint and charter: name an executive sponsor and AI governance lead, and charter the committee with decision rights within the first month.
Discover and register: run discovery and register everything found, including pilots, with a named owner.
Publish policy and tiers: AI policy, acceptable use rules, tiers and the intake form; pilot the intake with two or three business units first.
Back-assess existing systems: tier everything in the register, highest exposure first; pause or restrict use cases that cannot meet their tier's controls, as M-25-21 requires agencies to "safely discontinue" non-compliant high-impact AI.
Build oversight and monitoring: define overseers, override paths, logs, metrics and incident criteria for high and elevated tiers.
Train: role-based AI literacy for all staff, deeper training for owners, overseers and committee members (NIST GOVERN 2.2).
Review and improve: quarterly committee review of metrics, incidents and exceptions; annual policy review and internal audit. Make exceptions time-limited so they expire rather than accumulate.

Measuring the programme

Register coverage: AI use cases found by discovery that were already registered, as a percentage; target above 95%.
Ownership: share of register entries with a current named owner; target 100%.
Assessment currency: high-tier use cases with an impact assessment and test results less than 12 months old.
Approval cycle time: median days from intake to decision per tier; long times drive shadow AI.
Override and appeal rates: per high-tier system, tracked for trend rather than target.
Exception age: open exceptions and waivers past their expiry date; target zero.

Where identity fits

Every registered AI system acts through identities: provider API keys, retrieval service accounts, OAuth grants and agent identities. Governance that tracks models but not these credentials cannot enforce oversight or complete a decommission. Link each register entry to its non-human identities and their owners, apply least privilege per tier, and include credential revocation in the exit procedure. See the NHI Ownership Guide and the Agentic AI Identity Guide.

Framework mapping

Governance activity	NIST AI RMF	ISO/IEC 42001 Annex A area	EU AI Act	NIST CSF 2.0
AI policy and risk appetite	GOVERN 1.1 to 1.4, MAP 1.5	A.2 Policies related to AI	Article 9 (providers' risk management)	GV.RM, GV.PO
Roles and committee	GOVERN 2.1, 2.3, 3.2	A.3 Internal organization	Article 26(2) oversight assignment	GV.RR
Inventory and register	GOVERN 1.6	A.4 Resources for AI systems, A.6 AI system life cycle	Article 49 registration (high-risk)	ID.AM
Impact assessment and tiering	MAP 1.1, MEASURE 2	A.5 Assessing impacts of AI systems	Articles 6 and 27	ID.RA
Human oversight	GOVERN 3.2, MANAGE 2.4	A.9 Use of AI systems	Articles 14 and 26	GV.OV
Third-party AI	GOVERN 6.1, 6.2	A.10 Third-party and customer relationships	Article 25 (value chain)	GV.SC
Monitoring, incidents, decommissioning	GOVERN 1.7, MANAGE 4.1	A.6 AI system life cycle	Articles 26(5), 72, 73	DE.CM, RS.MA

Common failure patterns

Policy without a register: nobody can say which systems the principles apply to, so every audit and incident starts with a hunt.
Bans instead of approved alternatives: the Samsung ChatGPT source code leak led to a ban; without a sanctioned tool, use tends to move to personal devices and accounts.
Tiering once: a use case approved as low risk later gains tools, new data or a new audience and is never re-tiered.
Oversight on paper: a reviewer named in the assessment who lacks time, information or authority to override.
Forgotten AI integrations: pilots end but their OAuth grants and API keys live on, as the Vercel Context.ai breach showed.
Working to old dates: plans built on the original 2 August 2026 high-risk deadline that ignore the Omnibus changes and the prohibitions already in force.

Practitioner checklist

Appoint an executive sponsor and AI governance lead, and charter a committee with decision rights.
Build an AI use case register with owner, purpose, model, data, tier, EU AI Act role and linked identities.
Run discovery across procurement, SaaS, cloud and OAuth grants and register what you find.
Define three or four risk tiers aligned to Article 5, Article 6 and Article 50, with controls per tier.
Require an impact assessment, and a FRIA where Article 27 applies, before high-tier deployments.
Give named overseers the information, authority and stop mechanism Article 14(4) describes.
Define AI incident criteria and route them through the existing incident process.
Write a decommissioning procedure covering endpoints, credentials, data, logs and fallback.
Deliver role-based AI literacy training and keep records.
Recheck your EU AI Act plan against the dates set by Regulation (EU) 2026/1744.

Standards and references

Related NHI Mgmt Group resources: Agentic AI Compliance Guide · Shadow AI Discovery Guide · AI and Privacy Guide · Agentic AI Security Policy Template · NHI Governance Maturity Model. This guide summarises the NIST AI RMF, ISO/IEC 42001, the EU AI Act as amended by the Digital Omnibus on AI and OMB M-25-21 and is not legal advice.