AI governance · Playbook
The CIO’s AI governance playbook.
A practical, seven-part AI governance playbook for CIOs: inventory, risk tiering, decision rights, guardrails, value tracking, monitoring and board reporting, mapped to NIST AI RMF, ISO/IEC 42001 and the EU AI Act.
Effective AI governance for a CIO has seven parts, built in order: an inventory of every AI use case, a risk-tiering rule, written decision rights, guardrails on the highest tier first, value tracking, monitoring and incident response, and a one-page board report. Align the vocabulary with NIST AI RMF, the operating system with ISO/IEC 42001, and the top risk tier with the EU AI Act where it applies.
What AI governance is
AI governance is the system of decision rights, policies, controls and oversight that keeps an organization’s AI valuable, safe, lawful and accountable across its life cycle. It covers every AI use case, from a vendor’s embedded copilot to a model your team fine-tunes. It covers the whole life of each one: proposal, build or buy, deployment, monitoring and retirement.
AI governance is not the same as an AI ethics statement. A statement says what the organization values. Governance decides who approves which AI use case, on what evidence, with which controls, and what happens when something goes wrong.
Why AI governance lands on the CIO
AI governance usually lands on the CIO because the CIO already owns the systems, data flows, vendor contracts and security controls that AI depends on. Legal, risk and business leaders all have a stake, but the CIO’s organization is where AI actually gets procured, integrated and run.
That does not mean the CIO decides alone. It means the CIO is often best placed to build the machinery: the inventory, the intake process, the controls and the reporting. Other executives then use that machinery to make decisions.
The seven-part AI governance playbook
The seven parts below are ordered by dependency. Each one makes the next possible.
1. Build an AI use-case inventory
An AI inventory is a living register of every AI system in use or in development, with its owner, purpose, data, vendor and risk tier. You cannot govern what you cannot see. Start with procurement records, SSO and expense data, and a short survey to business units. Include AI embedded in SaaS products you already own, because that is often where most exposure sits.
2. Tier every use case by risk
Risk tiering sorts AI use cases into a few categories so that oversight scales with potential harm. A practical rule uses three or four tiers based on who is affected, whether the AI decides or only assists, which data it touches, and how reversible its errors are. Where the EU AI Act applies, align your top tier with its high-risk categories so you are not maintaining two taxonomies.
| Tier | Typical example | Approval | Controls |
|---|---|---|---|
| Prohibited | Uses your policy or applicable law bans | None, blocked | Detection and enforcement |
| High | AI influencing hiring, credit, health or safety decisions | Executive council | Impact assessment, human oversight, testing, logging, monitoring |
| Medium | Customer-facing assistants, internal decision support | Domain owner + risk | Evaluation, disclosure, escalation path |
| Low | Drafting, summarization, coding assistance on non-sensitive data | Pre-approved pattern | Acceptable-use policy, data rules |
3. Assign decision rights
Decision rights specify who can approve, pause or retire an AI use case at each risk tier. Write them down in a one-page matrix. The most common failure is a council that can discuss everything and decide nothing. Name one accountable executive per tier.
4. Ship guardrails for the top tier first
Guardrails are the technical and procedural controls that constrain what an AI system can do. Examples include data-access limits, human review for consequential outputs, evaluation before release, prompt and output logging, and a kill switch. For agentic AI, add explicit limits on which actions an agent can take without approval. Start with the high tier. Low-tier use cases mostly need clear data rules, not a review board.
5. Track value, not just risk
AI value tracking ties each funded use case to a measurable business outcome and a date to check it. Governance that only says “no” loses the room. Put a value hypothesis and a review date on every approved use case, and retire those that don’t deliver. This is what earns the governance program a seat in budget conversations.
6. Monitor, and plan for incidents
AI monitoring watches deployed systems for drift, failure, misuse and harm, and AI incident response defines what happens when they occur. Extend your existing incident process instead of inventing a new one. Add AI-specific triggers, such as harmful outputs, data exposure or unexpected agent actions, and a clear owner for each system.
7. Report to the board in one page
A board-level AI report shows the inventory by tier, the value delivered, material incidents and open decisions on a single page. Boards need to see that AI is under control and producing value. They do not need a model-by-model walkthrough.
Mapping NIST AI RMF, ISO/IEC 42001 and the EU AI Act
The three reference points most CIOs use are complementary. NIST AI RMF organizes risk activities, ISO/IEC 42001 defines a certifiable management system, and the EU AI Act sets legal obligations where it applies.
| Reference | What it is | Use it for |
|---|---|---|
| NIST AI RMF 1.0 (Jan 2023) | Voluntary US framework: Govern, Map, Measure, Manage. Generative AI Profile added July 2024. | Structuring your risk activities and vocabulary |
| ISO/IEC 42001:2023 | International standard for an AI management system; certifiable | Operating the program and giving external assurance |
| EU AI Act (in force Aug 2024) | Risk-based EU law with phased obligations | Legal requirements where you place or use AI in the EU. Confirm current dates with counsel. |
A 90-day starting plan
- Days 1-30: see it. Name the accountable executive, stand up the council, publish a one-page acceptable-use policy and start the inventory.
- Days 31-60: sort it. Agree the tiering rule, tier the inventory and write the decision-rights matrix. Offer a sanctioned tool for low-tier use.
- Days 61-90: control it. Apply guardrails to every high-tier system, attach value hypotheses to funded use cases, and send the board its first one-page report.
Where AI governance programs stall
- Governing models instead of use cases. The same model can be low-risk in one use and high-risk in another. Tier the use, not the technology.
- A council with no owner. Discussion without decision rights produces backlog, not governance.
- Ignoring embedded AI. AI features inside existing SaaS contracts often carry more exposure than the pilots everyone is watching.
- Only saying no. Programs that don’t track value lose sponsorship, and the business works around them.
Frequently asked questions
Who should own AI governance: the CIO, the CDO or a committee?
One named executive should be accountable, often the CIO or CDO. A cross-functional council (legal, risk, security, data, business) advises. Committees without a single owner tend to stall decisions rather than make them.
Do we need ISO/IEC 42001 certification?
Not necessarily. Certification helps when customers, regulators or procurement ask for independent assurance. Many organizations align their AI management system to ISO/IEC 42001 first and decide on certification later.
How do we handle employees already using public AI tools?
Offer a sanctioned, secure alternative quickly, publish a one-page acceptable-use policy with clear data rules, and monitor for high-risk data flows. Blanket bans mostly push usage out of sight. See shadow AI.
This playbook is a synthesis for discussion, not legal or regulatory advice. Confirm obligations with counsel. Spotted something out of date? Tell the editors.