Enterprise AI Governance Framework: The Working Version

The CISO who hired me in early 2025, in a Munich-headquartered manufacturer with operations in seventeen countries, opened the engagement with a question I have been asked a variant of seven times since. We have a NIST cybersecurity framework, an ISO 27001 certification, a SOC 2 attestation, and a Group risk policy. The board has asked for an AI governance framework by the end of the quarter. Do we write a new one, or do we extend the ones we have. The answer matters more than the question implies, because the wrong choice produces two parallel control sets that drift apart within twelve months and saddle the organisation with a complexity tax — doubled or tripled audit overhead, for the next decade. We extended. The annex that resulted was eleven pages, the cross-walk was fourteen, and the operating framework went live across all seventeen countries in roughly nine weeks. The new ISO certification cycle absorbed it without restructuring. The audit posture for the EU AI Act August 2026 deadline was defensible. None of the existing risk artefacts had to be rebuilt.

This is the working version of the enterprise AI governance framework discussion, written for the CISO or CAIO who has been handed the deliverable and is deciding whether to start a parallel programme or extend the existing one. The governance hub is the landscape map; this piece is the working framework. The two should be read together — the hub frames the question, the framework operates on it.

The choice that defines the next ten years of audit cost

Before any control language, before any artefact, before any platform: decide whether you are building a new framework or extending the existing risk and security control set. The decision is binary, irreversible without significant cost, and almost always made wrong in the direction of new framework. The reason is that the consultancy proposals — and the internal political pressure inside large risk functions — bias heavily toward a standalone deliverable. A new framework is visible. It has a name. It produces a launch event, a steering committee, a budget line. An extension is invisible. It produces an amended policy document and a new annex to an existing standard. Visibility is not the right optimisation function.

The cost of two parallel control frameworks is structural and compounds. Two policy hierarchies have to be maintained. Two audit cycles, or one audit cycle that has to traverse two frameworks. Two control attestation processes. Two sets of training material. Two RACI matrices for incident response. Two cross-walks to every regulatory regime the enterprise operates under. Within twelve months the frameworks will have drifted in language and scope; within twenty-four they will produce conflicting answers to the same question; within thirty-six the internal-audit function will be reconciling them quarterly. Every enterprise I have seen take this path has regretted it.

The extension pattern is straightforward. The existing information-security control framework — typically ISO 27001 or NIST CSF, often both — covers the data-and-systems half of AI governance reasonably well. What it does not cover is the model-lifecycle half: training-data provenance and consent, evaluation regimes and acceptance criteria, drift and degradation monitoring, post-deployment incident classification, model deprecation and retirement procedures. The model-lifecycle annex is the discrete add-on that covers exactly this surface. Eleven to twenty pages depending on enterprise scale. Same policy hierarchy as the parent framework. Same audit cycle. Same RACI. Same cross-walks, extended once rather than maintained twice.

The diagnostic question that surfaces the right choice is which existing framework does our risk function actually operate against day to day. If the answer is ISO 27001 plus a Group risk policy, extend them. If the answer is we have policies but nothing operates against them, the AI governance framework is not your first problem. Fix the underlying GRC before adding a new domain to it; an AI control set bolted onto a non-functional GRC produces only paperwork.

The skeleton: NIST AI RMF as the operating loop

The NIST AI Risk Management Framework (AI RMF 1.0, plus the Generative AI Profile that landed in mid-2024) is the cleanest skeleton available for the operating framework. It is voluntary, vendor-neutral, openly published, and structured around four functions — Govern, Map, Measure, Manage — that map onto how a working risk function actually runs. ISO 42001 is heavier and more formal; the EU AI Act is legally binding but is a compliance framework with specific procedural hooks (Article 9 risk management systems, Article 72 post-market monitoring) rather than a complete operating model. NIST gives you the loop the Act’s procedural hooks plug into.

Govern is the policy and accountability surface — risk appetite, ownership, decision rights, integration with the broader enterprise risk function. For an enterprise extending an existing framework, Govern is the layer where the model-lifecycle annex bolts onto the existing risk register, the existing control library, and the existing ownership model. The output is a one-page extension to the risk policy and a named ownership map for AI-specific controls.

Map is the use-case context surface — for each model or system, what is the use case, what is the risk tier, what are the impact pathways, what are the affected parties. Map is where the model inventory lives, and it is where the EU AI Act’s risk-tier categorisation produces the most leverage; mapping every inventory item to unacceptable, high, limited, or minimal risk drives the rest of the framework. About 80% of items will land in limited or minimal; the heavy machinery applies to the remaining 20%.

Measure is the evaluation surface — for each model, what metrics are measured, against what baselines, with what cadence, against what acceptance thresholds. Measure is where the framework intersects with the technical evaluation work the engineering team already does or should be doing. The framework’s job is to standardise what gets measured and what counts as passing; it is not to specify the evaluation tooling, which lives in the tooling cluster.

Manage is the deployment-gate and monitoring surface — the procedural control that decides what goes into production, with what controls, against what evidence, and the runtime monitoring that catches the failure modes once deployed. Manage is the CISO’s primary surface and is the load-bearing piece of the operating framework. The CISO piece covers the deployment-gate detail; the framework names Manage as the function and points at the gate procedure as the operating artefact.

Four functions, one loop, one set of artefacts per inventory item. That is the operating shape of the framework. ISO 42001 is the certification overlay you bolt on top if a customer or regulator demands it; the EU AI Act is the legally-binding obligation set you cross-walk to. Both ride on the same underlying loop.

The inventory-first methodology, stated as a sequence

Every framework I have seen succeed starts with the inventory and uses it to drive every subsequent decision. Every framework I have seen fail started with policy, then platform, then inventory, and discovered three quarters in that the policy did not match the inventory and the platform did not cover it. The sequence is the load-bearing detail.

Step one is the inventory itself. Every model in production, every model in development, every third-party API the company’s code is calling. Owner, use case, deployment surface, data sources, last review date. The work is calendar-light — about a week of focused effort by two senior engineers plus the CISO’s right of inquiry across business units — and politically heavy because it exposes the shadow AI the organisation has been pretending does not exist. Brooks’s old line about plan to throw one away; you will, anyhow applies to the first inventory; the first cut will be incomplete, will need a second pass, and will surface inventory items that nobody on the governance team has ever heard of. That is the inventory doing its job, not failing at it.

Step two is risk tiering against the EU AI Act categories. Even if you do not operate in the EU, the Act’s tiers — unacceptable, high, limited, minimal — are the cleanest forcing function the field has produced. Mapping every inventory item to a tier takes a working session of half a day with the CISO, CAIO (or CIO), DPO, and a representative from the business that owns the item. The output is a tiered inventory and an immediate diagnostic: if more than 30% of items are landing in high, either the tiers are being applied too tightly or the inventory is concentrated in regulated use cases. If less than 5% are landing in high, either the tiers are being applied too loosely or the organisation genuinely is not running customer-facing decision systems and the framework can be lighter than the consultancy proposals suggest.

Step three is control selection. The four-function loop applies to every inventory item; the control set inside each function scales with the risk tier. A limited-risk internal productivity assistant requires Govern (owner named, risk tier recorded), Map (use case documented), Measure (model card, prompt and tool surface documented), and Manage (thirty-minute deployment review, low-touch monitoring). A high-risk customer-facing system requires Govern (board-level reporting cadence), Map (fundamental-rights impact assessment where applicable), Measure (evaluation regime with stated metrics, baselines, and thresholds; quarterly red-team cadence), and Manage (external red-team sign-off, post-market monitoring per Article 72, full technical documentation per Annex IV). The control selection is mechanical once the tier is set; the tier is the load-bearing decision.

Step four is platform procurement, driven by the inventory shape. The tools comparison walks the four archetypes — model-lifecycle, policy and risk, LLM observability, hyperscaler-native — and the procurement question is which archetype does our inventory require. An inventory dominated by MLOps-deployed models needs model-lifecycle. An inventory dominated by third-party LLM API calls needs LLM observability and gateway tooling. An inventory dominated by hyperscaler-native models needs the hyperscaler suite plus a multi-cloud overlay. Procuring before the inventory exists is procuring blind.

Step five is operating-cost projection. The three-year operating cost of the framework is the platform licence plus the integration cost plus the FTE time the framework will demand. For a mid-sized enterprise with a model inventory of fifty to two hundred items, the realistic three-year envelope is between €800,000 and €2.6M, dominated by the FTE cost more than the licence cost. Knowing the number lets the CFO and board ratify the framework as an operating cost rather than discovering it incrementally; the discovery path is where most programmes die politically, even when they were technically sound.

The sequence is one week to inventory, one day to tier, one week to select controls, four to eight weeks to procure platform, ongoing to operate. The total elapsed time from board approval to operating framework is roughly twelve weeks for an enterprise that runs the sequence cleanly. Twelve weeks is fast in absolute terms and is achievable; the path to twelve weeks runs through doing the inventory first.

The three-owner boundary, operationalised

The CISO, the CAIO (or CIO acting as CAIO), and the DPO together own the operating framework. The CISO piece covers the operational ownership in detail; the framework piece states it as a boundary.

The CISO owns Manage — the deployment gate, the incident-response runbook, the red-team cadence, the technical controls. The CISO’s question is is it safe to run this in production this week, answered with reference to a documented procedure.

The CAIO (or CIO) owns Govern and Map — the portfolio decision about which models exist, which use cases the organisation will pursue, what the risk appetite is, what the budget envelope is, and the use-case mapping that drives tiering. The CAIO’s question is should we be doing this at all, answered with reference to the strategy document and the four-question diagnostic.

The DPO owns the data-rights and privacy surface across all four functions — 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’s question is are we allowed to do this under GDPR and adjacent rights regimes.

The boundary that fails is the one where ownership is assumed rather than written. Each of the three roles tends to assume that one of the others owns model-lifecycle governance; none of them do, by default, and the framework runs for nine months under the assumption that somebody else is managing it. The fix is to write the boundary into the framework itself — name the owner of each function, name the artefact each owner produces, name the dependency between artefacts — and to ratify the boundary in a single steering meeting that includes all three roles plus the CEO or executive sponsor. Once the boundary is written and ratified, the framework can operate. Conway’s Law applies brutally here: the governance posture will end up shaped like the ownership map, whether or not the map is right. Getting the map right is therefore the highest-leverage move available.

The legal-led variant — where Group Counsel owns the deployment gate — fails predictably and is worth naming explicitly. 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. If your existing governance model has legal in this position, the highest-priority structural change is to move operational ownership to the CISO with legal owning the criteria input. The CISO becomes the translator between legal’s regulatory minimum and engineering’s deployment reality.

The regulatory cross-walk, not a parallel framework

The instinct, faced with operations in the EU, the US, Singapore, and the UK, is to build four governance frameworks. This is the most expensive and least defensible answer. The right pattern is one operating framework against the NIST RMF skeleton plus a regulatory cross-walk maintained as documentation rather than as a parallel control set.

The cross-walk is a single document, typically a spreadsheet or a structured page in the policy library, that maps each control in the operating framework to the obligations it satisfies under each applicable regulatory regime. The EU AI Act’s Annex IV documentation requirements, the Article 72 post-market monitoring obligations, the Article 9 risk management system requirements. The Colorado AI Act and California’s emerging regulatory regime. The Singapore IMDA AI Verify and Model AI Governance Framework. The UK’s pro-innovation regulatory approach as it firms up through 2026. Industry-specific overlays — EBA and OCC for banking, FDA AI/ML SaMD for healthcare, NAIC for insurance.

The cross-walk does two useful things. First, it lets the CISO and DPO show, for any control, which regulators we are compliant with and on what evidence. This is the question every internal-audit function will ask and every external regulator will eventually ask, and a control framework without the cross-walk produces an audit response that takes weeks rather than hours. Second, it surfaces the gaps — controls that satisfy three regulators but not a fourth, or obligations that no existing control satisfies — and produces a prioritisation queue that the framework owner can work through deliberately rather than discovering reactively.

The maintenance cost is real but bounded. A working cross-walk requires roughly two days of effort per quarter to keep current — to update for regulatory changes, to add controls that the framework’s evolution has produced, to retire obligations that no longer apply. Two days a quarter, run by the DPO or a dedicated regulatory analyst, is materially cheaper than maintaining four parallel frameworks and produces a better audit posture.

ISO 42001 as the certification overlay

ISO/IEC 42001:2023 is the AI management system standard. It is to AI governance what ISO 27001 is to information security — a certifiable management-system standard that an external auditor can attest against. Whether to certify is a procurement question, not a framework question, and the answer depends on customer demand and regulatory posture rather than on whether the framework needs ISO 42001 to operate.

The honest position on 42001 is that it is heavier than necessary for the operating framework but useful as a certification target if customers or regulators require third-party attestation. The framework itself can run cleanly against the NIST RMF skeleton without 42001; the 42001 documentation can be produced as an overlay on the framework if and when certification is needed. The mistake is to start with 42001 as the framework, because 42001’s management-system shape produces a heavier paperwork footprint than the operating reality requires, and enterprises that start there end up with policy documents that engineers never read.

The diagnostic for whether to certify is whether your sales cycles or regulatory environment specifically require ISO 42001. Most do not in 2026; the standard is too new and customer-side awareness is still building. By 2027 or 2028 the customer demand pattern will be clearer, and the cost-benefit of certifying will look different. If your competitive position requires certification today — typically because you sell into European public sector or into regulated industries where customers are starting to ask — certify. If it does not, build the framework against NIST, document it to 42001 requirements as a precaution, and defer certification until the customer signal is unambiguous.

What “defensible” looks like under audit

The framework is defensible if it produces the artefacts an auditor will ask for and the artefacts pass an evidence-quality bar. The four-artefact set from the CISO piece — model inventory, deployment-gate procedure with documented criteria, incident-response runbook, red-team evidence log — is the floor. Above the floor, defensibility comes from three additional properties.

The first is currency. The artefacts have to be kept current to be defensible. An inventory dated eighteen months ago is worse than no inventory because it positively misrepresents the estate. The framework’s operating model has to include a refresh cadence — quarterly for inventory and deployment-gate decisions, semi-annually for red-team programmes, annually for the regulatory cross-walk — and the cadence has to be evidence-backed. Auditors check dates.

The second is traceability. For any model in the inventory, the auditor should be able to walk a chain from this model exists to this is the use case it serves to this is the risk tier it was assigned to these are the controls that apply at this tier to here is the evidence each control was satisfied to here is the deployment-gate decision and the named approver. The chain is the operating substrate of the framework. Platforms that produce the chain as a byproduct of normal use are worth their licence; platforms that require the chain to be assembled from disparate sources at audit time are not.

The third is honest negative evidence. The framework is more defensible if it documents what it does not cover and why, than if it pretends to cover everything. An inventory item flagged as out-of-scope for governance because it predates the framework and is being deprecated is a better artefact than an item silently omitted. A red-team finding documented as accepted-risk by a named owner is a better artefact than a finding silently closed. Auditors are trained to look for omissions, and frameworks that surface their own gaps consistently outperform frameworks that polish their evidence.

Goodhart’s Law applies sharply to AI governance evidence: any metric that becomes a target ceases to be a good measure. An organisation that targets 100% of models pass the deployment gate will produce a gate that passes everything; an organisation that targets 80% of inventory items in limited or minimal risk will tier its inventory to hit the target. The defensible framework reports the metrics as evidence rather than as targets, and the steering committee discusses the metric movements without setting them as objectives. The discipline is unfashionable. It is also what produces audit responses that survive scrutiny.

What I would do this quarter

If you are starting the framework work this quarter, the sequence I would run is straightforward. Week one, produce the inventory yourself with two senior engineers, against the four-question methodology in the CISO piece. Week two, tier the inventory against the EU AI Act categories in a half-day working session with the CISO, CAIO or CIO, DPO, and a business representative. Week three, draft the model-lifecycle annex to the existing risk policy, against the NIST RMF four-function loop. Weeks four through seven, run the four-week proof of concept for platform procurement against the tools comparison methodology. Week eight, sign the platform contract, ratify the annex through the existing risk governance committee, and brief the board.

Total elapsed time, eight weeks. Total internal effort, roughly the equivalent of one full-time risk analyst plus 20% of the CISO’s calendar plus 10% of the CAIO’s and DPO’s calendars. Total external cost, the platform licence and roughly €40,000–€80,000 in supporting professional services. The result is an operating governance framework with a documented decision trail, an inventory the CISO can defend, a deployment gate the engineering team can operate against, and a regulatory cross-walk that produces a defensible audit posture for the EU AI Act August deadline and any adjacent regulatory regime.

The frameworks that fail in 2026 will fail because they tried to build a parallel framework rather than extend an existing one, or because they procured platform before producing inventory, or because they let legal own the deployment gate, or because they targeted metrics rather than reporting them. None of these failure modes are subtle. All of them are recoverable from if caught early. The single highest-leverage move available, for any CISO or CAIO starting this work today, is to do the inventory first, with the framework owner’s own hands, in the first week. Everything that matters in the next twelve months of governance work follows from how well that inventory is done.

---

Sources

• EU AI Act, Regulation (EU) 2024/1689 — Article 9 risk management system; Annex IV technical documentation; Article 72 post-market monitoring
• NIST AI Risk Management Framework (AI RMF 1.0) — Govern, Map, Measure, Manage loop and the Generative AI Profile
• ISO/IEC 42001:2023 — AI management systems
• OECD AI Principles (2019, updated 2024)
• Singapore IMDA AI Verify and Model AI Governance Framework, second edition
• Related: governance hub, CISO governance responsibilities, governance tooling comparison, framework cluster

The model-lifecycle annex template referenced throughout is published under CC-BY-4.0 and linked from the governance hub. Fork it, change the language to match your existing control framework, publish a fork with a different structure and send the link — I will reference it from the next refresh.