# AI Governance Reference model

Canonical page: https://vikrammohan.com/thought-leadership/ai-governance-reference-model/

An operating model for AI that the delivery platform enforces, so that a control is applied every time rather than remembered.

The EU AI Act timetable changed on 27 July 2026. **Duties for Annex III high-risk systems now apply from 2 December 2027.** Facts checked on 6 October 2026. See the dates that apply now.

## AI Governance - Underpinned by Three Standards and a Control Library

The NIST AI Risk Management Framework (NIST AI RMF) is adopted by organisations as a standard and used to oversee and govern their AI adoption; it is not a legal or regulatory requirement. Where the EU AI Act applies, its duties prevail over an organisation's choice of standards and frameworks.

### NIST AI RMF 1.0

Published in January 2023 as NIST AI 100-1, with the Generative AI Profile (NIST AI 600-1), which was released in July 2024.  
It is voluntary and free.  
Its four functions, Govern, Map, Measure and Manage, contain 19 categories and 72 subcategories.  
A revision is in progress; the core remains version 1.0.

Provides the vocabulary of AI risk and the activities across the lifecycle. It cannot be certified.

### ISO/IEC 42001:2023

An AI management system built on the ISO harmonised structure: clauses 4 to 10, and Annex A with 38 controls under nine objectives.  
ISO/IEC 42005 (May 2025) guides impact assessment and ISO/IEC 42006 (July 2025) governs certification bodies.  
UKAS accredited BSI to certify against it on 15 January 2026.

Activities within the system are auditable, through a Statement of Applicability, internal audit and management review. It can be certified.

### EU AI Act

Regulation (EU) 2024/1689.  
Its duties depend on the organisation's role (provider, deployer, importer or distributor) and on the system's risk category.  
It reaches organisations outside the EU whose systems are placed on the EU market or whose output is used in the EU (Article 2(1)(c)).  
For prohibited practices, fines could be up to €35 million or 7% of worldwide annual turnover, whichever is higher.

Establishes the legal baseline. ISO/IEC 42001 certification does not create a presumption of conformity with it.

## A practical approach towards moving from Principles to Controls

Each layer is narrower and more testable than the one above it. A control at the bottom must trace to a principle at the top; a principle with no control beneath it is an aspiration.

- **Principles**: Seven statements, approved by the board and stable for years, derived from the NIST trustworthy characteristics.
- **AI policy**: One document approved by the executive. It meets clause 5.2 of ISO/IEC 42001: suited to the organisation's purpose, a framework for objectives, and commitments to meet requirements and to improve continually.
- **Standards**: Mandatory and measurable: risk classification, AI lifecycle, acceptable use of generative AI, third party AI, AI data and AI incidents.
- **Procedures**: How compliance is achieved: the intake workflow, assessment templates, approved architectures and evaluation playbooks.
- **Controls**: Testable, owned and evidenced. Each is written once and cited against all three standards, so the organisation never runs three parallel programmes.

### Seven principles

1. **Accountable.** Every AI system has a named responsible and accountable owner.
2. **Valid and reliable.** It does what the organisation claims, measured before and after release.
3. **Safe and secure.** It resists misuse, attack and failure.
4. **Fair.** Harmful bias is identified, measured and managed.
5. **Transparent and explainable.** People and users should be informed when AI is used and receive an explanation in proportion to its effect on them.
6. **Privacy respecting.** Data is used lawfully, minimally and securely.
7. **Human directed.** People can oversee, override and switch them off.

### Register before build

Every AI system is registered in the AI inventory with an accountable owner, intended purpose, AI Act role and tier before any environment or model access is provisioned.

**Control ID**: AIG-INV-01

**Applies to**: Tiers 1, 2 and 3

**Type**: Preventive and automated

**Owner**: The system owner, in the first line

**Enforced by**: Gateway keys and cloud projects are issued only against an inventory ID

**Evidence**: The inventory record and the key issuance log

**Test**: A monthly reconciliation of gateway keys to inventory IDs; any key without an ID is an exception

**NIST AI RMF**: GOVERN 1.6; MAP 1.1

**ISO/IEC 42001**: Clause 4.3; A.4.2

**EU AI Act**: No standalone duty; a prerequisite for Articles 6, 26 and 49

A control written once and cited three times. The AI Act imposes no general duty to keep an inventory, but none of Articles 6, 26 or 49 can be applied without one.

## The EU AI Act timetable after the Digital Omnibus

The Digital Omnibus on AI entered into force on 27 July 2026. It deferred the high-risk duties; it did not cancel them, and several obligations already apply.

| Date | What applies |
| --- | --- |
| 1 Aug 2024 | Legislation enters into force. |
| 2 Feb 2025 | Article 5 prohibitions and Article 4 AI literacy apply. |
| 2 Aug 2025 | Obligations for providers of general-purpose AI models (Articles 53 to 55); governance and penalties. |
| 27 Jul 2026 | Digital Omnibus in force. Article 4 now requires providers and deployers to support AI literacy rather than ensure it. The legal basis for processing special category data to detect bias is extended to all AI systems. Relief for small and medium enterprises is extended to small mid caps. |
| 2 Aug 2026 | Article 50 transparency duties for chatbots, synthetic content and deepfakes. |
| 2 Dec 2026 | Article 50(2) marking for generative systems already on the market before 2 August 2026. New Article 5 prohibition of systems that generate non-consensual intimate imagery or child sexual abuse material. |
| 2 Aug 2027 | Deadline for national regulatory sandboxes (deferred by one year). General-purpose AI models placed on the market before 2 August 2025 must comply. |
| 2 Dec 2027 | High-risk duties for Annex III systems (deferred from 2 August 2026). |
| 2 Aug 2028 | High-risk duties for systems covered by the product legislation in Annex I (deferred from 2 August 2027). |

### What this means for organisations

1. The deferral moves the deadline; it does not mean any in-flight work or activities should be deferred. The Article 5 prohibitions, the duties for general-purpose AI models and the Article 50 transparency duties already apply, so any system that touches them needs attention now.
2. Organisations that provide or deploy Annex III systems have until 2 December 2027, and those whose systems fall under the Annex I product legislation until 2 August 2028. That time is best spent on the inventory, the classification of each system and the role the organisation plays in relation to it, because no high-risk duty can be met without them.
3. The high-risk duties themselves (risk management, data governance, technical documentation, logging, human oversight and, for certain deployers, a fundamental rights impact assessment) take time to evidence. A programme that begins late in 2027 is unlikely to be ready by the date they apply.

## One control, three citations

Each component of the AI Governance Reference model, cited against the three standards. The mapping is interpretive and should be read alongside the AI RMF to ISO/IEC 42001 crosswalk that NIST publishes on its AI Resource Center. The AI Act column notes whether a duty falls on providers or deployers.

| Component | NIST AI RMF | ISO/IEC 42001 | EU AI Act |
| --- | --- | --- | --- |
| Principles and AI policy | GOVERN 1.1, 1.2, 1.4 | Clause 5.2; A.2.2 to A.2.4 | **Art 17(1)**, quality management strategy (providers of high-risk systems) |
| Leadership, roles and accountability | GOVERN 2.1, 2.3 | Clauses 5.1, 5.3; A.3.2 | **Art 17(1)(m)**; **Art 26(2)**, competent human oversight (deployers) |
| AI literacy and competence | GOVERN 2.2 | Clauses 7.2, 7.3; A.4.6 | **Art 4**, support for AI literacy since the Omnibus |
| AI inventory and scope | GOVERN 1.6 | Clause 4.3; A.4.2 | No standalone duty; a prerequisite for **Arts 6, 26 and 49** |
| Risk appetite and tiering | GOVERN 1.3; MAP 1.5 | Clauses 6.1.1 to 6.1.3 | **Art 5**; **Art 6** with **Annex III**; **Art 50** |
| Impact assessment | MAP 1.1, 5.1, 5.2 | Clause 6.1.4; A.5.2 to A.5.5, with ISO/IEC 42005 | **Art 27**, fundamental rights impact assessment (certain deployers); **Art 9(2)** |
| Data governance | MEASURE 2.10, 2.11 | A.7.2 to A.7.6 | **Art 10** |
| Testing, evaluation and validation | MEASURE 1.1, 2.3, 2.5, 2.7 | A.6.2.4 | **Art 9(6) to (8)**; **Art 15** |
| Human oversight | MAP 3.5; GOVERN 3.2 | A.9.2 to A.9.4 | **Art 14**, design (providers); **Art 26(2)**, assignment (deployers) |
| Documentation and transparency | MEASURE 2.8, 2.9 | A.6.2.7; A.8.2, A.8.5 | **Art 11** with **Annex IV**; **Art 13**; **Art 50** |
| Logging and monitoring | MEASURE 2.4; MANAGE 4.1 | A.6.2.6, A.6.2.8 | **Arts 12, 19**; **Art 26(5) and (6)**; **Art 72** |
| Approval, stopping and decommissioning | MANAGE 1.1, 2.4; GOVERN 1.7 | A.6.2.5 | **Art 14(4)(e)**, stop procedure; **Arts 20, 43** |
| Third parties and the general-purpose AI supply chain | GOVERN 6.1, 6.2; MAP 4.1; MANAGE 3.1 | A.10.2 to A.10.4 | **Art 25**, change of role; **Art 53(1)(b)**, information for downstream providers |
| Incidents and concerns | GOVERN 4.3; MANAGE 4.3 | A.3.3; A.8.4 | **Art 73**, serious incidents; **Art 26(5)** |
| Audit, review and improvement | GOVERN 1.5 | Clauses 9.1 to 9.3, 10 | **Art 17**; **Art 72**, post-market monitoring |

## Hub and spoke, with the hub divided

The hub has two halves. A Centre of Excellence enables delivery and reports through technology. AI Risk Oversight challenges delivery from the second line. They share one inventory and one control library; a single team that both builds and approves cannot give independent assurance.

**Board or Risk Committee**: Principles, AI policy, risk appetite, Tier 1 portfolio

**AI Governance Council**: Standards, Tier 1 decisions, Tier 1 exceptions, tier disputes

**AI Review Board**: Tier 2 decisions, Tier 1 recommendations

The Central Hub - Underpinned by a Central Inventory and a Unified single control library

**AI Centre of Excellence**: Enables: platform, gateway, patterns, evaluation tooling, literacy

**AI Risk Oversight**: Challenges: tiering, control library, validation, exceptions, reporting

**Business unit A**: AI lead and risk champion

**Business unit B**: AI lead and risk champion

**Group functions**: AI lead and risk champion

**Internal Audit**: Independent assurance over all of the above, reporting to the board and audit committee

| Body | Line | Does | Does not |
| --- | --- | --- | --- |
| Board or Risk Committee | Oversight | Approves principles, the AI policy and risk appetite. Receives the Tier 1 portfolio each quarter. | Approve individual systems. |
| AI Governance Council | Executive: CRO, CDAO, CISO, General Counsel, DPO, business unit heads | Approves standards, Tier 1 systems, Tier 1 exceptions and tier disputes. Meets monthly. | Review technical detail. |
| AI Review Board | Cross functional, technical | Decides Tier 2 systems and recommends on Tier 1. Meets fortnightly against a published service level. | Set policy. |
| AI Centre of Excellence | First Line of Defence (1 LoD) / Controls Team | Runs the platform and gateway, approved patterns, evaluation tooling, the literacy programme and the spoke community. | Approve systems it helped to build. |
| Spokes | First Line of Defence (1 LoD) | Intake, tier proposals, control operation and local literacy. Each has an AI lead and a risk champion with about one day a week protected. | Approve their own Tier 1 or Tier 2 systems. |
| AI Risk Oversight | Second Line of Defence (2 LoD) | Owns tiering, the control library, independent validation of Tier 1, the exceptions register and reporting. | Build or own AI systems. |
| Internal Audit | Third Line of Defence (3 LoD) | Independently audits the whole system, including the ISO/IEC 42001 internal audit (clause 9.2) where no separate team performs it. Reports findings to the board and audit committee. | Design controls. |

## Classify a system

Prohibited practices are screened out first and never receive a tier. Organisation policies define evaluation parameters which decide scoring criteria based on risk appetite.

### 1. The prohibited screen

A system that falls within Article 5 receives no tier and does not proceed. The screen covers practices such as social scoring, emotion recognition from biometric data in the workplace or in education, untargeted scraping of facial images, and the generation of non-consensual intimate imagery. The organisation's own red lines are applied at the same point.

### 2. Validation criteria

A system is Tier 1, whatever its other characteristics, if any one of the following is true:

- it is an Annex III use, or a safety component under Annex I, and the Article 6(3) derogation does not apply;
- it has a legal or similarly significant effect on a person, for example in employment, credit, insurance, housing, benefits or education;
- it can move money, change records of account or take irreversible actions without a person approving each action;
- it identifies or categorises people using biometric data;
- the safety of people or of critical infrastructure depends on it.

### 3. Six dimensions

Where no validation criteria apply, the system is scored on six dimensions across Low, Medium and High levels.

| Dimension | Low | Medium | High |
| --- | --- | --- | --- |
| Effect on people | It has no effect on people, or only an indirect one | It affects people in minor ways that are easily remedied | It has a significant effect on people |
| Autonomy | It makes suggestions; a person decides and acts | A person reviews each output before it takes effect | It acts without a person reviewing each output |
| Reach | It is used by one internal team | It is used across the whole organisation | It reaches the public or customers at scale |
| Data sensitivity | It uses only public data | It uses confidential or personal data | It uses special category data or data about children |
| Reversibility | Its outcomes are easily undone | Its outcomes can be undone, with effort | Its outcomes are irreversible or hard to detect |
| Opacity and provenance | It is built in house and well understood | It is a documented third party model | It is opaque and cannot be evaluated |

### 4. Classification tiers

- Tier 1 applies if any of the validation criteria is met, or if two or more dimensions score High.
- Tier 2 applies if one dimension scores High, or if three or more score Medium.
- Tier 3 applies in every other case.

AI Risk Oversight may increase the criticality and consider raising tiers. Only the Council, in accordance with organisation policies and risk appetite, may lower tiers. The thresholds should be calibrated against the organisation's own portfolio. The tier sets how much governance a system receives. Separate obligation tags (Article 50 transparency, a data protection impact assessment, sector rules and the organisation's EU role) set which specific duties apply.

## What each tier requires

Most systems fall in Tier 3 and proceed on automated controls and the responsible owner's certification.  
Governance effort is concentrated where the classifier places it.

| Control area | Tier 3 | Tier 2 | Tier 1 |
| --- | --- | --- | --- |
| Inventory and approved platform | Required | Required | Required |
| Literacy and acceptable use attestation | Required | Required | Required, with role training for oversight staff |
| Impact assessment | None | Short form | Full assessment, with an Article 27 assessment where it applies |
| Evaluation before release | Basic functional test | Documented evaluation against acceptance criteria | Independent validation by the second line, and red teaming |
| Human oversight | Not required | A named reviewer with power to override | Designed and tested, with a stop mechanism |
| Approval | The owner certifies | AI Review Board | Council, subject to a second line veto |
| Monitoring | Platform logs | Quality metrics and drift alerts | Continuous monitoring, fairness metrics and a quarterly report |
| Documentation | Inventory record | System card | Full technical file (Annex IV where the organisation is the provider) |
| Third party due diligence | Standard vendor process | AI questionnaire | Contract clauses, audit rights and model provenance |
| Review | On material change | Annually | Every six months and on change |
| Incidents | Standard IT process (ensuring it caters to the specific requirements tailored to AI systems) | AI incident runbook | Runbook, with Article 73 reporting rehearsed where it applies |

### Illustrative examples of AI driven systems and their classifications

One defensible reading of each. The reasoning matters more than the label.

**A tool that screens and ranks job applicants**

Tier 1. Annex III point 4 covers employment. The deployer carries Article 26 duties, including informing workers' representatives under Article 26(7).

**A customer service assistant that answers questions from a knowledge base**

Tier 2, with an Article 50(1) tag: people must be told they are dealing with an AI system. Its reach is wide, but it makes no decisions about people.

**A meeting summariser on the approved platform, not used for HR purposes**

Tier 3. Internal, on an approved platform, and read by a person. It becomes Tier 1 as soon as summaries feed performance reviews.

**A model that sets credit limit increases**

Tier 1. Annex III point 5(b) covers creditworthiness. For UK banks the model also falls within model risk management under PRA SS1/23.

**Transaction fraud detection**

Annex III point 5(b) expressly excludes fraud detection, so the system is not high-risk under the Act. Internally it is Tier 2, rising to Tier 1 if it blocks accounts without human review. The Act's category and the organisation's tier are different questions.

**An agent that issues customer refunds of up to £500 on its own**

Tier 1, under the third validation criterion, because it moves money without approval of each action. A transaction cap and sampled human review may justify a Council decision to operate it under Tier 2 controls. That is a documented exception with an expiry date, not a change of tier.

**Marketing image generation**

Tier 2, for brand and intellectual property risk, with an Article 50 tag. The provider of the generator marks its output under Article 50(2); the deployer discloses a deepfake under Article 50(4).

**Sentiment analysis of employees' chat messages**

Article 5(1)(f) prohibits emotion recognition in the workplace based on biometric data. Text is not biometric data, so the practice is probably not prohibited. It remains Tier 1 as monitoring of employees with significant effect, a strong candidate for an internal red line, and likely to require a DPIA.

**Predictive maintenance on factory machinery**

Tier 3 or Tier 2 depending on effect. If it is a safety component of machinery within Annex I, it is Tier 1, with duties applying from 2 August 2028.

**Further training a model with published weights and offering it to other companies under the organisation's own name**

The organisation becomes a provider. Article 25 and, depending on the extent of the modification, the general-purpose AI rules may apply. The tier follows the intended purpose, but the change of role is a matter for the Council in its own right.

## AI Governance - Decision Framework and areas of ownership

Anyone with a stop right may halt a system on their own authority; only the body that approved it may restart it. Every exception expires within stipulated timeframes (90 days), and the release pipeline enforces the expiry.

- D decides
- R recommends
- V may veto
- C consulted
- I informed
- S may stop

| Decision | Board | Council | Review Board | Centre of Excellence | AI Risk | System owner | Legal, DPO, CISO | Internal Audit |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Principles, AI policy, risk appetite | D | R |  | C | R | I | C | I |
| Standards and control library |  | D | C | R | R | C | C | I |
| Tier assignment |  | D on dispute |  | C | D | R | C |  |
| Tier 3 approval |  |  |  | I | I, sampled | D |  |  |
| Tier 2 approval |  |  | D | C | V | R | C |  |
| Tier 1 approval | I | D | R | C | V | R | C | I |
| Exception, at most 90 days |  | D for Tier 1 |  | C | D for Tiers 2 and 3 | R | C | I |
| Pause or switch off |  | I |  | S | S | S | S |  |
| Restart after a stop |  | D the body that approved release | C | V | R | C |  |  |
| Add a model or vendor to the approved list |  |  | C | R | D |  | V |  |
| Serious incident and notification to a regulator | I | I |  | C | R | R | D | I |

## AI Centre of Excellence charter

The charter gives the Centre of Excellence its authority and sets its limits. It should be short and approved by the AI Governance Council.

**Purpose**:

The charter should state that the Centre exists to help the organisation use AI safely, lawfully and at pace. It does so by providing the platform, patterns, skills and community that make the governed route the easiest route.

**Mandate and authority**:

The Centre should be established by the AI Governance Council under the AI policy. It operates the AI platform and gateway, and it may suspend a system's access to the platform under the stop right in the decision rights matrix. It does not approve systems; approval rests with the bodies named in that matrix.

**Scope**:

Every AI system that the organisation builds, buys or receives embedded in purchased software should fall within scope, in every business unit and jurisdiction. Generative features that vendors enable in existing software services are included.

**Structure**:

The Centre should be led by a head who reports to the Chief Data and Analytics Officer or the Chief Technology Officer and who attends the Council. The core team needs three further roles:

- a platform and gateway owner;
- a responsible AI engineering lead, who owns evaluation tooling and patterns;
- a literacy and community lead.

Each business unit contributes an AI lead and a risk champion to the spoke network, each with about one day a week protected for the work.

**Services**:

The Centre should offer support with intake and triage, approved architectures, evaluation as a service, guardrail configuration, and patterns for prompts and agents. It should also run AI literacy training by role, in support of Article 4, maintain a community of practice, and scan regulatory and standards developments each quarter.

**Interfaces**:

The charter should name the functions the Centre works with and what each contributes: AI Risk Oversight for tiering, validation and the control library; the Data Protection Officer for data protection impact assessments; Information Security; Model Risk Management, where the organisation has it; Procurement for third party AI; Legal; Data Governance; and Internal Audit.

**Service levels**:

The Centre should publish and report against its service levels: a decision on a Tier 3 intake within 2 working days, a Tier 2 case before the Review Board within 15, and a Tier 1 case before the Council within 40, each counted from the point at which the evidence is complete.

**Measures**:

The Centre's performance should be judged on seven measures:

- inventory coverage, meaning the share of gateway traffic that carries a valid inventory ID, with a target of 100%;
- the median time from intake to decision, by tier;
- the share of Tier 1 and Tier 2 systems with a current assessment;
- exceptions past their expiry, with a target of none;
- detections of unsanctioned AI use, which should fall over time;
- the share of controls whose evidence is collected automatically;
- completion of literacy training, by role.

**Funding**:

The core team should be funded centrally, platform costs recharged according to use, and spoke time funded by the business units.

**Review**:

The Council should review the charter each year, as an input to the ISO/IEC 42001 management review under clause 9.3.

## Eight points where the platform enforces the AI Governance Reference model

A policy held only in a document depends on memory and goodwill. Each control below sits at a point every system must pass through, and that point produces the evidence. The strongest is the simplest: a system that is not in the inventory cannot call a model.

1. **Intake**: Every system is registered and its tier is computed by rules.
2. **Provisioning**: No inventory ID, no cloud project and no model key.
3. **Release**: The pipeline checks the artefacts the tier requires and a current approval.
4. **Runtime gateway**: Approved models only, data loss prevention, guardrails, logging and cost limits.
5. **Agents**: An identity per agent, a limited set of tools, and human approval for consequential actions.
6. **Discovery**: Unsanctioned AI use is found and reconciled against the inventory.
7. **Monitoring**: Drift, quality and fairness are measured, and evidence is filed against each control.
8. **Response**: A single system can be stopped in minutes, and the incident clock starts.

## Mechanisms and evidence

The eight control points above say where enforcement takes place. This table says how each one works: what the control point enforces, the mechanism that enforces it, the evidence it leaves behind, and where the control is cited in NIST AI RMF, ISO/IEC 42001 and the EU AI Act.

The mechanisms are patterns rather than products. A gateway, a policy check in the release pipeline or a cloud organisation policy can each be built from more than one vendor's tools, and the products named here are examples of each pattern, not recommendations. What matters is that the control sits at a point every system must pass through, so that it applies whether or not anyone remembers it.

The evidence column is what makes the design auditable. Each mechanism produces a record in the ordinary course of operating: an inventory entry, a gate decision, a request log, a stop event. Each record can be filed against the control it proves, so that an internal auditor or a certification body can test the control from its evidence rather than from interviews.

| Control point | What is enforced | Mechanism | Evidence left behind | Cites |
| --- | --- | --- | --- | --- |
| 1. Intake | Registration, and a tier computed by rules | AI governance or GRC platform workflow with deterministic tier rules | Inventory record and tier rationale | GOVERN 1.6; A.5.2; **Art 6** |
| 2. Provisioning | No inventory ID, no project or key; approved services and regions only | Infrastructure as code tags; Azure Policy, AWS service control policies, Google Cloud organisation policy | Tagged resources and policy compliance state | GOVERN 1.6; A.4.4 |
| 3. Release | Artefacts required by the tier, and a current approval | Open Policy Agent (Rego) through Conftest in CI; model registry stage gates in MLflow, SageMaker, Azure ML or Vertex AI | Gate decision log | MANAGE 1.1; A.6.2.5; **Art 43** |
| 4. Runtime gateway | Approved models, data loss prevention, prompt injection and content guardrails, cost limits | Azure API Management AI gateway, Kong AI Gateway, LiteLLM, Cloudflare AI Gateway; Bedrock Guardrails, Azure AI Content Safety, NeMo Guardrails, Llama Guard | Request logs per system | MEASURE 2.7; A.6.2.8; **Arts 12, 26(6)** |
| 5. Agents | An identity per agent, a limited set of tools, approval for consequential actions, transaction caps | Workload identities, short lived scoped tokens, approval steps in the orchestrator | Audit trail of tool calls | MAP 3.5; A.9.2; **Art 14** |
| 6. Discovery | Unsanctioned AI found; unapproved endpoints blocked or coached | Secure service edge and CASB tools (Netskope, Zscaler, Defender for Cloud Apps); reconciliation of keys to the inventory | Discovery reports and reconciliation exceptions | GOVERN 1.6; A.10.3 |
| 7. Monitoring | Drift, quality, fairness and evaluation regressions | Evaluation harness in CI and on a schedule; Arize, Fiddler, Evidently | Metric history; evidence filed to GRC by control ID | MEASURE 2.4; A.6.2.6; **Art 72** |
| 8. Response | One system stopped in minutes; the incident clock started | A stop switch per system at the gateway or a feature flag; incident workflow | Stop events, incident record, notification log | MANAGE 2.4; A.8.4; **Art 73** |

### Release gates governed by policy templates

A release gate is an automated check in the delivery pipeline that decides whether a system may be deployed. The pipeline describes each release as a structured record in JSON: the system's inventory ID, its tier, the artefacts produced for it, and the approval it relies on, with that approval's expiry date.

The rules the gate applies are held as policy templates in JSON, one for each tier, listing the artefacts the tier requires and the conditions a release must meet. A policy engine evaluates each release record against its template and either allows the release or blocks it with the reason. Because the templates are data rather than prose, changing a requirement changes every pipeline at once, and every decision is logged as evidence. The example below writes the same three templates directly in Rego, the policy language of Open Policy Agent.

```rego
package aigov.release

import rego.v1

# Artefacts each tier must hold before release
required := {
  3: {"inventory_id"},
  2: {"inventory_id", "impact_assessment",
      "eval_report", "approval_id"},
  1: {"inventory_id", "impact_assessment",
      "eval_report", "approval_id",
      "independent_validation", "red_team_report",
      "oversight_design"},
}

deny contains msg if {
  some artefact in required[input.tier]
  not input.artefacts[artefact]
  msg := sprintf("Tier %d release blocked: missing %s",
                 [input.tier, artefact])
}

# Approvals and exceptions expire
deny contains msg if {
  input.tier < 3
  expiry := time.parse_rfc3339_ns(input.approval.expires)
  expiry < time.now_ns()
  msg := sprintf("Approval %s expired",
                 [input.approval.id])
}
```

A release gate in Rego. A Tier 1 system without a current approval and an independent validation does not deploy, and an expired exception fails in the same way.

### Why the gateway carries most of the weight

When every model call passes through one gateway, and the gateway issues keys only to systems with an inventory ID and a tier, five things follow.

1. The inventory stays complete, because registration is the only route to access.
2. Only approved models can be called.
3. Logs exist by default, which supports Articles 12 and 26(6).
4. Each system has its own failsafe and termination switch.
5. Unsanctioned use appears as traffic without an ID and is logged.

## Questions organisations ask

**Why treat NIST as the primary standard rather than ISO/IEC 42001?**

NIST gives the fullest vocabulary for AI risk and the activities across the lifecycle, including the Generative AI Profile, and it is free and outcome based. ISO/IEC 42001 is how those activities are run as an auditable management system and certified. The AI Act is law, so its duties prevail wherever it applies. Primary means the organising vocabulary, not legal priority.

**Does ISO/IEC 42001 certification demonstrate compliance with the AI Act?**

No. It is not a harmonised standard under the Act and gives no presumption of conformity. It helps to structure the Article 17 quality management system and produces much of the evidence. A presumption of conformity will come from the harmonised standards being drafted by CEN and CENELEC Joint Technical Committee 21, once they are cited in the Official Journal.

**We only buy AI. Does this apply to us?**

Yes, in proportion. Deployers carry Article 26 duties for high-risk systems, Article 50 duties for deepfakes and emotion recognition, and the Article 4 literacy duty. Under Article 25 a deployer becomes a provider if it puts its own name on a high-risk system, modifies it substantially, or changes its purpose so that it becomes high-risk. Generative features switched on inside existing software services are the commonest blind spot.

It is a common misconception that risk can be outsourced; the accountability for procuring and implementing AI lies with the organisation.

**How is the hub kept from becoming a bottleneck?**

Most volume is Tier 3, which proceeds on the owner's certification and automated controls on an approved platform. Each tier has a published service level, reported monthly. The hub sets standards and runs the platform; the spokes do the first line work. Time from intake to decision is measured, and acted on when it slips.

**Where should the Centre of Excellence report?**

Enablement reports to the CDAO or CTO; oversight reports to the CRO. Both use the same inventory and control library, but the reporting lines differ so that second line challenge remains independent.

**How is unsanctioned AI use found?**

Through secure service edge and CASB discovery of generative AI traffic, reconciliation of gateway keys, procurement and expense data, vendor release notes for AI features enabled in existing services, and a time limited amnesty that lets teams register without penalty.

**What is different about governing generative AI?**

Outputs are open ended and vary between runs, so governance relies on evaluation suites, guardrails and monitoring of outputs rather than a single validation. NIST AI 600-1 identifies twelve generative AI risks, among them confabulation, information security (including prompt injection), data privacy, intellectual property, and the integrity of the value chain.

**How are AI agents governed?**

By what the agent can do, not by which model it uses. Each agent has its own identity, a limited set of tools, human approval for consequential actions, transaction caps, a complete log of tool calls, and a stop switch at the gateway.

**How is the effectiveness of governance measured?**

Inventory coverage against gateway traffic, decision time by tier, assessments in date, exceptions past expiry, the trend in unsanctioned use, incidents and the time taken to contain them, and the share of controls with automated evidence.

**How does this fit with model risk management?**

One inventory with a flag for models, not two registers. Systems that are models pass through model risk validation, which serves as the independent validation for Tier 1. For UK banks, PRA SS1/23 already covers AI models.

**Which fairness metric should be used?**

It depends on the decision and the harm, because the metrics conflict with one another. The metric is chosen for each use and the reason is recorded. NIST AI RMF MEASURE 2.11 calls for fairness and bias to be evaluated and the results documented. For a high-risk system, Article 10(2)(f) and (g) of the EU AI Act require the data to be examined for possible biases, and those biases to be detected, prevented and mitigated. The results are then tested against the anti-discrimination law of each jurisdiction in which the system is used.

**How are exceptions handled?**

Each exception has an owner, compensating controls and an expiry no later than 90 days. The release gate enforces the expiry, and the Council sees any exception renewed twice.

**What is the position in the UK?**

The UK has no AI Act. Existing regulators, including the ICO, the FCA and the CMA, apply five cross sector principles. The EU Act still reaches UK organisations that place AI on the EU market or whose output is used in the EU. Designing to the EU standard and applying UK regulators' guidance on top is the safer course.

## The first 90 days of an AI governance programme

An organisation with little formal AI governance can put the AI Governance Reference model into effect in about 90 days. The plan below divides that period into three phases of roughly a month each. The first establishes which AI systems exist and agrees the rules; the second builds the controls and the platform that enforces them; and the third puts both into operation, so that evidence begins to accumulate.

### Days 1 to 30: discover and decide

Inventory sweep, including software services and unsanctioned use; risk appetite; draft policy; Council terms of reference; the tier rubric.

### Days 31 to 60: build

Control library version 1; the gateway in front of generative AI traffic; the intake workflow; Tier 1 triage of existing systems.

### Days 61 to 90: operate

First Council decisions; the exceptions register; the measures pack; an ISO/IEC 42001 gap assessment; the internal audit plan.

## Vikram Mohan

A London based technology consultant who has a background in cybersecurity, risk, assurance and controls, covering their design, testing and reporting.

Vikram audited the controls of one of Europe's largest banks from within its Economic Crime and Cybersecurity Audit team, including third party risk reviews of its largest cloud and outsourcing partners, and reported to its audit committee. He has more than ten years of consulting, transformation and cybersecurity experience at Capgemini Invent, Deloitte, Accenture and Tata Consultancy Services, across the public sector, financial services and several other industries.

The AI Governance Reference model described above is a discipline that applies to AI adoption and governance: obligations mapped to controls, controls mapped to policies and frameworks, and evidence produced by systems.

- Frameworks: NIST Cybersecurity Framework, COSO Internal Control, GDPR and DPIA, UK operational resilience (PRA SS1/21, FCA PS21/3), DORA
- BCS Chartered IT Professional (CITP); CISSP in progress
- MBA, SP Jain School of Global Management; MSc Distributed Systems and Networks, University of Kent

[Contact Vikram](https://vikrammohan.com/contact) [LinkedIn](https://www.linkedin.com/in/mohanvikram/)

## Sources

- [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)
- [NIST AI 100-1, AI RMF 1.0](https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf)
- [NIST AI 600-1, Generative AI Profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf)
- [NIST AI Resource Center: Playbook and crosswalks](https://airc.nist.gov/)
- [ISO/IEC 42001:2023](https://www.iso.org/standard/42001)
- [ISO/IEC 42005:2025](https://www.iso.org/standard/42005)
- [Regulation (EU) 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj)
- [Gibson Dunn: the Omnibus agreement](https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes/)
- [Morgan Lewis: EU approves the delays](https://www.morganlewis.com/pubs/2026/06/eu-approves-delays-and-other-amendments-to-certain-eu-ai-act-obligations-what-businesses-should-know)
- [Open Policy Agent documentation](https://www.openpolicyagent.org/docs/latest/)

Regulatory facts checked on 6 October 2026. The crosswalk is an interpretive mapping and should be read alongside legislation and official guidance from regulators.

Vikram Mohan is not a solicitor or barrister. Nothing on this page is legal advice. For legal advice, speak to a regulated legal professional.

© Vikram Mohan. [vikrammohan.com](https://vikrammohan.com/)