The AI Strategy Guide logo The AI Strategy Guide at the cusp of AI Subscribe →
CISO AI Governance Responsibilities: The Monday-Morning Version — Governance illustration

CISO AI Governance Responsibilities: The Monday-Morning Version

Tom Prommer · CIO/CTOUpdated 2026-05-289 min read

The first AI deployment gate I helped a CISO design, in a Swiss insurer in mid-2024, replaced a four-page policy document with a one-page checklist and a thirty-minute review meeting. The policy document had existed for nine months. Three models had been deployed under it. Nobody on the engineering team could remember what the policy said. The checklist took forty minutes to write. Within six months the engineering team was using it as the actual deployment standard, the auditors had a clear evidence trail, and the policy document had been retired in favour of a one-page summary that pointed at the checklist. Governance had not become weaker. It had become operational.

This is the structural insight about the CISO role in AI governance, and it is the one Big-4 audit firms cannot write because they sell the policy document. A CISO’s job in AI governance is not to write the policy. It is to make the policy executable. Policy that is not executable is theatre; theatre that the engineering team cannot operate against produces shadow AI; shadow AI is exactly what the policy was supposed to prevent. The whole stack collapses if the CISO treats the policy document as the deliverable instead of as the input to the four artefacts that actually run the programme.

The four artefacts an auditor will ask for

Skip the policy document. The auditor will look at it for fifteen minutes, note that it exists, and ask for these four things. If you do not have them, the policy does not save you.

One. The model inventory. Every model in production, every model in development, every third-party API the company’s code is calling. Owner, use case, risk tier, last review date, deployment-gate decision record. The inventory is the floor of the entire programme, and most enterprises do not have a real one. The work of producing it is calendar-light (about a week of focused effort) and politically heavy, because the inventory exposes the shadow AI everybody has been pretending does not exist. The CISO owns this inventory because the CISO is the only person in the building who already has the right of inquiry across every business unit’s tech stack.

Two. The deployment-gate procedure with documented criteria. A written procedure that says: to deploy a model into production, the team must produce X, Y, and Z; the gate is reviewed by these named roles; the criteria are these. The criteria themselves vary by risk tier, but the procedure is uniform. A high-risk customer-facing system might require external red-team sign-off, a fundamental-rights impact assessment, a documented evaluation regime, and a post-market monitoring plan. A low-risk internal tool might require a model card, a data-source manifest, and a thirty-minute review. Both go through the same procedure. The CISO owns the procedure; the CAIO or business owner inputs the criteria; legal inputs the regulatory minimum.

Three. The incident-response runbook for AI-specific failure modes. A runbook that says: when a model in production produces an output that triggers an incident — hallucination causing customer harm, drift causing decision-quality degradation, prompt-injection causing data exfiltration, jailbreak causing policy violation — these are the steps, these are the owners, this is the communication tree, this is the rollback procedure. The runbook is AI-specific. Generic incident response does not cover model-output incidents because the failure modes are different. The CISO owns the runbook because incident response is already a CISO function; AI just extends it.

Four. The red-team evidence log. A documented programme of adversarial testing against deployed models, with named owners, cadence (quarterly for high-risk, annually for the rest), findings, remediation actions, and re-test results. The log is the single artefact that distinguishes a governed AI programme from a documented one. Programmes without red-team evidence look identical to programmes with it on paper; under audit, the difference is the only thing that matters.

If those four artefacts exist and are kept current, the policy document can be a one-page index. If those four artefacts do not exist, no policy document saves the programme.

The CISO ↔ CAIO ↔ DPO boundary, made operational

The boundary discussion gets a lot of airtime and produces few useful answers. Here is the one I have seen work in three engagements, and I have not yet seen it fail when it is written down clearly.

The CISO owns operational governance — the deployment gate, the runbook, the red-team programme, the technical controls. The CISO answers the question “is it safe to run this in production this week?” with reference to a documented procedure.

The CAIO (or CIO acting as CAIO) owns portfolio governance — the decision about which models exist, which use cases the organisation will pursue, what the risk appetite is, what the budget envelope is. The CAIO answers the question “should we be doing this at all?” with reference to the strategy document and the four-question diagnostic.

The DPO owns data-rights governance — what training data is permitted, what consent applies, what subject-access response looks like for a model output, what data-residency constraints bind. The DPO answers the question “are we allowed to do this under GDPR and adjacent rights regimes?”

Three owners, three questions, one shared evidence trail. The trail is what binds them together. The CISO’s deployment gate cannot be passed without the CAIO’s portfolio approval and the DPO’s data-rights sign-off; the CAIO’s portfolio decisions are constrained by what the CISO’s gate will accept and the DPO’s data-rights review will permit; the DPO’s reviews depend on documentation produced by the CISO’s gate procedure. Each one’s artefacts feed the other two. This is the structure that survives an auditor for a high-risk system, and it is the structure that does not slow engineering down to the point where shadow AI starts growing.

The legal-led variant — where Group Counsel owns the gate and approves deployments — fails predictably. Legal cannot operate a gate that requires technical evaluation evidence because legal does not have the technical evaluation function. The gate becomes a queue, the queue grows, engineering routes around it, and the policy document covers nothing that is actually shipping. This is the failure mode I see most often in organisations where governance reports up through the Chief Legal Officer instead of through technology.

Deployment-gate criteria, by risk tier

The gate criteria are the load-bearing detail. A working set for an EU-operating enterprise in 2026 looks roughly like this.

Limited or minimal risk (internal productivity, low-stakes assistance). Model card, documented prompt and tool surface, data-source manifest, thirty-minute review. The gate exists to keep the inventory accurate and to confirm the use case really is limited-risk. About 80% of an enterprise’s AI inventory should clear this gate.

High-impact internal (decision support, knowledge work amplification, code generation in production-bound paths). Adds: evaluation regime with stated metrics and baselines, performance-degradation monitoring plan, defined incident classification, semi-annual red-team cycle. A named technical owner accountable to the CISO. Roughly 15% of the inventory.

High-risk customer-facing or regulated (aligned with EU AI Act Annex III categorisation, or industry-specific equivalents). Adds: independent external red-team sign-off, fundamental-rights impact assessment where applicable, full technical documentation per Annex IV of Regulation (EU) 2024/1689, quarterly red-team cadence, post-market monitoring per the Act’s Article 72, board-level reporting cadence. About 5% of the inventory.

The percentages are the diagnostic. If 40% of your inventory is clearing the high-risk gate, the gate is set too tight and engineering will route around it. If 100% is clearing the limited-risk gate, the gate is set too loose and the auditor will notice. The right shape is a heavy tail of low-risk items, a meaningful middle of high-impact internal items, and a small head of high-risk customer-facing items each of which gets serious attention.

Why this is unwriteable by a Big-4 firm

The structural problem with audit-firm-authored governance content is that the firm sells both the audit and the remediation. The incentive runs toward documents that produce billable remediation work, not toward documents that make the governance programme operate. A one-page checklist that replaces a forty-page policy is the right answer for the operator and the wrong answer for the audit firm. Predictably, the audit firms write the forty-page policy.

This is not a moral failing of the firms; it is the predictable consequence of who pays the bills. A CISO who wants to design a working AI governance programme should read the audit-firm material for the regulatory cross-walk and ignore it for the operational design. The operational design comes from people who have run the programme, and from the underlying source documents — the EU AI Act text, the NIST AI Risk Management Framework, ISO/IEC 42001:2023 — read directly rather than via consultancy summary.

The honest signal of a working AI governance programme is that the engineering team uses the gate as their actual deployment standard, not as a hoop to clear. The signal that the programme is failing is that engineering treats the gate as compliance theatre. The CISO’s job, more than anything else in the AI governance brief, is to make the gate useful enough that engineering uses it voluntarily. Once that is true, the rest of the governance programme runs. Until that is true, no amount of policy documentation rescues it.

If you are a CISO starting this work, the highest-leverage move I can recommend is to spend the first week producing the inventory yourself, with two senior engineers, before commissioning any platform or any consulting engagement. The inventory will resolve more open questions than the next three meetings combined, and it will tell you which 5% of your stack actually needs the high-risk gate. Everything else follows from that.

Sources

The deployment-gate checklist referenced above is published under CC-BY-4.0 and linked from the governance hub. Fork it, change the weights, publish a fork with different criteria, and send the link — I will reference it from the next refresh.

Frequently asked questions

Should the CISO or the CAIO own AI governance day-to-day?
The CISO owns the deployment gate, incident response, and red-team cadence. The CAIO, if you have one, owns the portfolio decision — which use cases, which risk appetite, which models. The boundary is operational versus portfolio. When the CAIO writes deployment-gate criteria, the gate becomes negotiable; when the CISO writes the portfolio strategy, the portfolio becomes risk-averse. Both failures are common.
What is the minimum set of artefacts a CISO needs for AI governance?
Four. A model inventory, a deployment-gate procedure with documented criteria, an incident-response runbook for AI-specific failure modes, and a red-team evidence log. If those four exist and are kept current, the policy document can be one page. If those four do not exist, no length of policy document compensates.
Why does the legal-led governance model fail?
Because legal is incentivised to write controls that prevent risk in the abstract, and engineering is incentivised to ship working systems. When legal owns the deployment gate without engineering signoff, the gate becomes a queue that engineering routes around. Shadow AI then grows, governed by nobody. The fix is to have engineering — usually under the CISO — own the gate, with legal owning the criteria input. The CISO becomes the translator between the two.
How often should an AI red-team cycle run?
Quarterly for high-risk customer-facing systems, semi-annually for internal high-impact systems, annually for the rest. The cadence is less important than the evidence trail; a once-a-year exercise that produces written findings and tracked remediation is more useful than a continuous-monitoring tool whose findings go to a Slack channel nobody reads. The red-team work I respect most is run by a named owner who reports findings to the CISO directly and the board annually.
Does the EU AI Act change what a CISO has to do?
It formalises what a good CISO was already doing and adds documentation obligations for high-risk systems. Risk management systems, technical documentation, logging and traceability, accuracy and robustness, and post-market monitoring are all CISO-adjacent. The Act is not a new model of governance; it is a documentation standard for a governance model that already existed. CISOs who ran a tight AI gate in 2024 are largely Act-compliant in 2026 with paperwork additions, not structural ones.