AI Governance Reference model

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.

PrinciplesSeven statements, approved by the board and stable for years, derived from the NIST trustworthy characteristics.
AI policyOne 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.
StandardsMandatory and measurable: risk classification, AI lifecycle, acceptable use of generative AI, third party AI, AI data and AI incidents.
ProceduresHow compliance is achieved: the intake workflow, assessment templates, approved architectures and evaluation playbooks.
ControlsTestable, owned and evidenced. Each is written once and cited against all three standards, so the organisation never runs three parallel programmes.

Seven principles

Accountable. Every AI system has a named responsible and accountable owner.
Valid and reliable. It does what the organisation claims, measured before and after release.
Safe and secure. It resists misuse, attack and failure.
Fair. Harmful bias is identified, measured and managed.
Transparent and explainable. People and users should be informed when AI is used and receive an explanation in proportion to its effect on them.
Privacy respecting. Data is used lawfully, minimally and securely.
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

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.
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.
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 CommitteePrinciples, AI policy, risk appetite, Tier 1 portfolio

AI Governance CouncilStandards, Tier 1 decisions, Tier 1 exceptions, tier disputes

AI Review BoardTier 2 decisions, Tier 1 recommendations

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

AI Centre of ExcellenceEnables: platform, gateway, patterns, evaluation tooling, literacy

AI Risk OversightChallenges: tiering, control library, validation, exceptions, reporting

Business unit AAI lead and risk champion

Business unit BAI lead and risk champion

Group functionsAI lead and risk champion

Internal AuditIndependent 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.

IntakeEvery system is registered and its tier is computed by rules.
ProvisioningNo inventory ID, no cloud project and no model key.
ReleaseThe pipeline checks the artefacts the tier requires and a current approval.
Runtime gatewayApproved models only, data loss prevention, guardrails, logging and cost limits.
AgentsAn identity per agent, a limited set of tools, and human approval for consequential actions.
DiscoveryUnsanctioned AI use is found and reconciled against the inventory.
MonitoringDrift, quality and fairness are measured, and evidence is filed against each control.
ResponseA 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.

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.

The inventory stays complete, because registration is the only route to access.
Only approved models can be called.
Logs exist by default, which supports Articles 12 and 26(6).
Each system has its own failsafe and termination switch.
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 LinkedIn