AI Governance and Compliance

Why the EU AI Act changes everything about how your organisation must govern artificial intelligence, and what to do about it.

The world's first comprehensive AI law is here

The European Union's Artificial Intelligence Act, Regulation (EU) 2024/1689, is the first comprehensive, horizontal legal framework for artificial intelligence anywhere in the world. It entered into force on 1 August 2024 and its obligations phase in over a multi-year transition period, with the bulk of high-risk requirements applying from 2 August 2026.

If your organisation develops, sells, or simply uses AI systems that touch the EU market, this regulation applies to you, regardless of where in the world you are headquartered. Like the GDPR before it, the AI Act has extraterritorial reach, and its fines are deliberately set at a level boards cannot ignore: up to €35 million or 7% of global annual turnover for the most serious violations.

What this whitepaper gives you

This 15-page guide translates the 177 recitals and 113 articles of the Act into a clear governance agenda. Across the following pages you will find:

• A plain-language explanation of the risk-based framework, the four tiers that determine your obligations;
• The prohibited practices that applied from February 2025;
• What qualifies as a high-risk AI system and the full lifecycle obligations that follow;
• The distinct duties of providers, deployers, importers and distributors;
• The special regime for general-purpose AI (GPAI) models;
• Conformity assessment, CE marking and the EU database;
• The enforcement architecture, the AI Office, national authorities and the AI Board;
• Penalty exposure and how it compares to GDPR;
• A phase-by-phase implementation timeline and a 12-step compliance programme.

Who should read this

This whitepaper is written for boards and executive committees, chief risk and compliance officers, general counsel, CIOs and CDOs, and the emerging class of Chief AI Officers and AI governance leads who must turn legal text into an operating reality.

Structure, scope and logic of Regulation (EU) 2024/1689, the foundations you need before diving into the detail.

One regulation, one internal market

The AI Act is an EU regulation, not a directive. That means it applies directly and uniformly in all 27 member states without national transposition. Its stated dual objective is to promote trustworthy AI uptake while protecting health, safety and the fundamental rights enshrined in the EU Charter.

Extraterritorial scope

The Act catches organisations far beyond Europe's borders. It applies to:

• Providers placing AI systems or GPAI models on the EU market, wherever they are established;
• Deployers (users) of AI systems located in the EU;
• Third-country providers and deployers whose AI system's output is used in the EU;
• Importers, distributors, product manufacturers, and authorised representatives along the value chain.

What counts as an "AI system"?

Article 3(1) defines an AI system as a machine-based system designed to operate with varying levels of autonomy, that may exhibit adaptiveness after deployment, and that infers from the input it receives how to generate outputs, such as predictions, content, recommendations or decisions, that can influence physical or virtual environments. Recital 12 helpfully excludes simpler rule-based systems, but the definition still covers machine learning, logic- and knowledge-based approaches, and generative AI.

How the Act is organised

The philosophy: risk proportionality

The Act deliberately does not regulate all AI equally. A spam filter and a CV-screening algorithm are both "AI", but they do not carry the same risk to people. Obligations therefore scale with risk, from nothing at all for minimal-risk systems, to outright prohibition for practices deemed unacceptable. Understanding which tier each of your systems falls into is the single most important governance exercise you will perform.

Four risk tiers, unacceptable, high, limited and minimal, determine everything from outright bans to light-touch transparency duties.

The four tiers at a glance

Every AI system in scope of the Act maps to one of four risk categories. This classification drives the entire compliance burden.

Tier 1, Unacceptable risk

Practices that contravene EU values and fundamental rights are banned outright under Article 5: manipulative or exploitative techniques, most real-time remote biometric identification in public spaces for law enforcement, social scoring by public authorities, untargeted facial-image scraping, emotion recognition in workplaces and schools, and biometric categorisation inferring sensitive traits. These prohibitions have applied since 2 February 2025.

Tier 2, High risk

High-risk systems are permitted, but only under a demanding compliance regime covering risk management, data governance, documentation, transparency, human oversight, accuracy, robustness and cybersecurity. Two routes lead here:

• Annex I route, AI used as a safety component of products already covered by EU harmonisation legislation (medical devices, machinery, toys, aviation, automotive, etc.);
• Annex III route, AI used in listed sensitive domains such as biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration and the administration of justice.

Tier 3, Limited risk

Systems interacting with humans or generating content carry transparency obligations under Article 50: chatbots must disclose they are AI; AI-created or manipulated content (deep fakes and synthetic text, audio, image and video) must be labelled as such. Users must be able to make an informed choice about whether to continue interacting.

Tier 4, Minimal risk

The vast majority of AI, spam filters, inventory optimisation, game AI, most recommendation engines, faces no new obligations. The Commission encourages voluntary codes of conduct, but nothing is mandated.

The classification challenge

Classification is not always obvious. Annex III categories have nuance and exceptions (Article 6(3) carve-outs for narrow procedural or preparatory tasks), and a single system may move tiers as its use case evolves. Governance must therefore include a standing re-classification process, triggered whenever a system's purpose, data, or deployment context changes.

The eight red lines of Article 5, banned across the EU since 2 February 2025, with the highest fines in the Act.

Red lines that already apply

Article 5 prohibits AI practices considered a clear threat to fundamental rights. These bans took effect on 2 February 2025, the first substantive obligations of the Act, and violations attract the maximum penalty tier. Every organisation should already have verified that none of its systems, pilots or vendor tools cross these lines.

The prohibited practices

1. Manipulative and deceptive techniques

AI that deploys subliminal, manipulative or deceptive techniques to materially distort behaviour in a way that causes, or is likely to cause, significant harm.

2. Exploitation of vulnerabilities

AI exploiting the vulnerabilities of specific groups, due to age, disability, or social or economic situation, to distort behaviour and cause significant harm.

3. Social scoring

AI evaluating or classifying people based on social behaviour or personal characteristics, where the resulting score leads to detrimental treatment in unrelated contexts or disproportionate to the behaviour.

4. Predictive policing based on profiling

Risk assessments predicting criminal offending based solely on profiling or personality traits, rather than objective and verifiable facts.

5. Untargeted facial scraping

Building facial-recognition databases through untargeted scraping of the internet or CCTV footage, the practice that made Clearview AI notorious.

6. Emotion recognition at work and school

AI inferring emotions in workplace and educational settings, except for medical or safety reasons (e.g., pilot fatigue detection).

7. Biometric categorisation of sensitive traits

Systems categorising people by biometric data to deduce race, political opinions, trade-union membership, religious or philosophical beliefs, sex life or sexual orientation.

8. Real-time remote biometric identification for law enforcement

Real-time RBI in publicly accessible spaces for law-enforcement purposes is banned, subject to narrow, judicially authorised exceptions (imminent threats, terrorism, finding specific victims).

Practical compliance steps

• Screen your entire AI inventory, including vendor-supplied features, against all eight prohibitions;
• Pay special attention to HR tools (emotion inference can hide in "engagement analytics"), marketing personalisation (manipulation boundaries), and security tooling (biometrics);
• Embed an Article 5 check as a mandatory gate in every new AI use-case intake;
• Document the screening outcome per system: supervisors expect evidence, not assertions.

Which systems qualify as high-risk under Article 6 and Annex III, and the seven requirement areas that follow from classification.

Two routes into the high-risk regime

Route 1, Annex I products. AI that is itself a product, or a safety component of a product, covered by EU harmonisation legislation (medical devices, machinery, lifts, toys, pressure equipment, aviation, automotive, marine equipment) and requiring third-party conformity assessment. These follow the product-safety route with a longer transition to 2 August 2027.

Route 2, Annex III use cases. Stand-alone AI systems used in eight sensitive domains:

The Article 6(3) escape hatch, use it carefully

An Annex III system is not high-risk if it performs only a narrow procedural task, improves a previously completed human activity, detects decision-making patterns without replacing human assessment, or performs a purely preparatory task. But any system performing profiling of natural persons is always high-risk. Documenting why a carve-out applies is itself a governance obligation, expect supervisors to probe it.

The seven requirement areas (Articles 8–15)

1. Risk management system, a continuous, iterative process across the entire lifecycle;
2. Data and data governance, training, validation and testing datasets that are relevant, representative and, as far as possible, free of errors and bias;
3. Technical documentation, drafted before market placement, kept up to date, demonstrating conformity (Annex IV);
4. Record-keeping, automatic logging of events across the system's lifetime;
5. Transparency and instructions for use, deployers must be able to interpret outputs and use the system correctly;
6. Human oversight, natural persons must be able to effectively oversee, intervene in, and override the system;
7. Accuracy, robustness and cybersecurity, appropriate levels declared and maintained, resilient against errors, faults and adversarial attack.

The heaviest duties in the Act fall on those who develop AI systems and place them on the market, a full compliance stack from design to post-market monitoring.

Who is a "provider"?

A provider develops an AI system or GPAI model, or has one developed, and places it on the market or puts it into service under its own name or trademark. Crucially, you can become a provider without writing a line of code: putting your trademark on an existing system, making a substantial modification, or repurposing a general system for a high-risk use all transfer provider obligations to you.

The provider compliance stack (Article 16–17)

1. Ensure conformity with all requirements of Articles 8–15;
2. Quality management system (QMS), documented policies, procedures and instructions covering development, testing, data management, risk management, post-market monitoring and incident handling;
3. Technical documentation (Annex IV), drawn up before placing on the market and continuously maintained;
4. Automatic logging capabilities retained under the provider's control;
5. Conformity assessment, the relevant procedure (internal control or third-party, depending on the category) before market placement;
6. EU declaration of conformity and CE marking;
7. Registration in the EU database of high-risk AI systems;
8. Corrective actions and duty to inform authorities when a non-conforming system is on the market;
9. Cooperation with authorities, including demonstrating conformity upon reasoned request;
10. Accessibility requirements for persons with disabilities.

Non-EU providers: authorised representative

Providers established outside the EU must appoint an authorised representative established in the Union before placing a high-risk system on the market. The representative holds documentation at the authorities' disposal and acts as the regulatory contact point, terminating the mandate if the provider violates its obligations.

The substantial-modification trap

Post-market duties

Obligations do not end at launch. Providers must operate a post-market monitoring plan proportionate to the system's risks, analyse interactions with other systems, and report serious incidents to market surveillance authorities, generally within 15 days, and within 2 days for widespread infringements or incidents affecting critical infrastructure, and 10 days where a death has occurred.

Using a high-risk AI system creates real legal duties too, the value-chain obligations most organisations underestimate.

Deployer duties: using AI is regulated too

Most organisations will encounter the AI Act as deployers, professional users of systems developed by others. Article 26 imposes substantive obligations:

• Use the system in accordance with the instructions for use;
• Ensure human oversight by persons with the necessary competence, training, authority and support;
• Ensure input data is relevant and sufficiently representative in view of the intended purpose, where input is under your control;
• Monitor operation and inform the provider when risks or anomalies appear;
• Retain logs generated by the system for at least six months (where under your control);
• Inform workers before deploying high-risk AI in the workplace;
• Inform affected natural persons that they are subject to a high-risk system producing legal or similarly significant effects (with the right to an explanation of the decision-making procedure and a clear and meaningful explanation of the system's role);
• Cooperate with market surveillance authorities.

The FRIA obligation

Deployers that are public bodies, or that deploy systems for creditworthiness assessment or life & health insurance risk-pricing, must perform a Fundamental Rights Impact Assessment (FRIA) before deployment. The FRIA describes the deployment context, affected groups, risks of harm, human-oversight measures and materialisation-response plans, and complements (not replaces) the GDPR's DPIA.

Importers and distributors

Importers must verify, before placing a system on the market, that the provider has completed conformity assessment, drawn up technical documentation, affixed CE marking and appointed an authorised representative where required. Distributors must verify CE marking and documentation and act when they have reason to believe a system is non-conform. Both must ensure storage and transport conditions do not jeopardise conformity.

The deployer-provider boundary

Practical deployer checklist

1. Inventory every AI system in operational use, including shadow-AI and SaaS-embedded features;
2. Classify deployer vs. provider role per system, per use case;
3. Obtain and actually read the instructions for use for each high-risk system;
4. Assign named human-oversight owners with training and authority;
5. Stand up log retention and worker-notification processes;
6. Determine whether a FRIA applies, and schedule it before go-live.

A dedicated regime for foundation models, transparency duties for all, and systemic-risk obligations above the 10^25 FLOPs threshold.

Why GPAI got its own chapter

Foundation models, large language models and other general-purpose AI, do not fit neatly into product-safety logic. A single model can power thousands of downstream applications, so the Act regulates the model layer directly, in Chapter V, applying from 2 August 2025.

Baseline obligations for all GPAI providers

• Technical documentation (Annex XI), training process, capabilities, limitations, compute and energy consumption;
• Information to downstream providers, sufficient documentation for them to understand capabilities and limitations and meet their own obligations;
• Copyright policy, compliance with EU copyright law, including the text-and-data-mining opt-out (Art. 4(3) DSM Directive);
• Training-data summary, a sufficiently detailed, publicly available summary of content used for training, following an AI Office template.

Providers of models released under free and open-source licences are exempt from the first two duties, unless the model presents systemic risk. The copyright and training-summary duties apply regardless.

Systemic-risk models: a higher bar

A GPAI model has systemic risk when cumulative compute used for training exceeds 10^25 FLOPs, or when the Commission designates it based on capabilities and impact criteria. Providers of such models must additionally:

1. Perform model evaluations, including adversarial testing, to identify and mitigate systemic risk;
2. Assess and mitigate possible systemic risks at EU level;
3. Track, document and report serious incidents to the AI Office without undue delay;
4. Ensure an adequate level of cybersecurity protection for the model and its infrastructure.

Codes of practice

The AI Office facilitates codes of practice, developed with industry, academia and civil society, through which GPAI providers can demonstrate compliance. The first General-Purpose AI Code of Practice gives providers a concrete, recognised path to meet their transparency, copyright, and safety-and-security obligations.

Enforcement of the GPAI regime

The European Commission, through the AI Office, has exclusive competence to supervise and enforce GPAI obligations, with powers to request information, conduct evaluations and impose fines of up to €15 million or 3% of global turnover.

How high-risk AI systems prove compliance: assessment routes, the EU declaration of conformity, CE marking and database registration.

The conformity assessment logic

High-risk AI follows the EU's familiar New Legislative Framework: before a system reaches the market, it must pass a conformity assessment, receive a declaration of conformity, bear CE marking, and be registered in the EU database. The assessment route depends on the system's category.

Route 1, Internal control (Annex VI)

Most Annex III systems can use internal control: the provider verifies its own QMS and technical documentation against the requirements. This is self-assessment, but it is not a formality. The QMS and documentation will be scrutinised by market surveillance authorities after the fact, and false declarations carry serious penalties.

Route 2, Third-party assessment (Annex VII)

Certain systems, notably biometric identification and categorisation systems where harmonised standards are not applied, require assessment by a notified body: an independent conformity assessment organisation designated by member states. For Annex I product-embedded AI, the existing product conformity route applies, integrated with AI-specific requirements.

The EU declaration of conformity

The declaration (Annex V) is a legally binding statement, signed on behalf of the provider, asserting that the system meets all applicable requirements. It identifies the system, references applied standards, names the notified body where relevant, and must be kept available to authorities for 10 years after market placement.

CE marking

High-risk AI systems bear the CE marking, visibly, legibly and indelibly for physical products, or digitally for software systems. The CE mark signals conformity to deployers and authorities across the single market.

Registration in the EU database

Providers (or their authorised representatives) must register themselves and their high-risk systems in the EU database before placing them on the market. Deployers who are public authorities must also register their use. Sections of the database are publicly accessible, transparency is part of the design.

Harmonised standards: the compliance shortcut

Systems built in conformity with harmonised European standards (being developed by CEN-CENELEC) benefit from a presumption of conformity. Following standards is therefore the most efficient, and most defensible, path to compliance, and your governance framework should track standardisation work as it matures.

Who polices the AI Act: the EU AI Office, the AI Board, national market surveillance authorities and notifying bodies.

A two-level enforcement model

The Act creates a new institutional landscape combining EU-level coordination with national enforcement:

EU level

• AI Office, a Commission service with exclusive competence over GPAI models, powers to request information, run evaluations, and fine GPAI providers; it also supports implementation, standardisation and codes of practice;
• AI Board, one representative per member state, advising and assisting the Commission and ensuring consistent application across the Union;
• Scientific Panel of independent experts, supporting the AI Office on GPAI capabilities, systemic risk and methodological questions;
• Advisory Forum, stakeholder input from industry, SMEs, civil society and academia.

National level

• Market surveillance authorities (MSAs), enforce the rules for high-risk AI systems on their territory: document requests, access to systems, evaluations, corrective orders, withdrawals and recalls;
• Notifying authorities, designate and monitor the notified bodies performing third-party conformity assessments;
• Fundamental rights authorities (e.g., data protection, equality, consumer bodies), gain access to documentation needed to fulfil their own mandates.

What supervisors can do

Market surveillance authorities may request technical documentation and logs, access training/validation/testing datasets, and, where needed for evaluation, obtain access to source code under strict safeguards. They can require corrective action, restrict or withdraw systems from the market, and coordinate cross-border through the AI Board and safeguard procedures.

Complaints and remedies for individuals

Any natural or legal person may lodge a complaint with a market surveillance authority. Deployers of high-risk systems making decisions with legal or similarly significant effects must provide the affected person a clear and meaningful explanation of the system's role in the decision, a genuine new individual right.

Regulatory sandboxes

Each member state must establish at least one AI regulatory sandbox by August 2026, a controlled environment where (especially smaller) providers can develop and test innovative AI under supervisory guidance. Sandboxes offer a pragmatic route to validate compliance approaches before full market deployment.

Up to €35 million or 7% of global turnover, the penalty architecture, how it compares to GDPR, and what boards should quantify.

The three-tier penalty structure

For SMEs and start-ups, fines are capped at the lower of the two amounts; for all other undertakings, at the higher. Member states lay down national rules on enforcement, including whether fines apply to public authorities.

How this compares to GDPR

The GDPR's maximum, €20 million or 4%, reshaped global privacy practice. The AI Act's top tier is 75% higher in relative terms (7% vs 4%) and 75% higher in absolute terms (€35M vs €20M). The signal is deliberate: prohibited-practice violations are treated as the most serious category of digital-regulation offence in EU law.

GDPR fines stack on top

The AI Act applies without prejudice to the GDPR. A single AI incident, say, biased biometric processing, can simultaneously trigger AI Act fines, GDPR fines, and member-state liability regimes. The new EU AI Liability Directive landscape and revised Product Liability Directive additionally open civil damages exposure, including for defective AI software.

What boards should quantify now

• Maximum theoretical exposure, 7% of global turnover, presented next to cyber and privacy scenarios in the risk register;
• Inventory-based exposure, which prohibited-adjacent or high-risk systems create the realistic exposure;
• Contractual exposure, indemnities and liability caps in AI vendor and customer contracts;
• Insurance, whether existing cyber/D&O policies cover AI regulatory fines and civil claims (many do not, yet);
• D&I and reputational scenarios, enforcement decisions and EU-database entries are public.

The phase-in calendar from February 2025 to August 2027, and the organisational roadmap that should already be running.

The statutory phase-in calendar

Phase 1, Foundation (now → Feb 2025 was the legal deadline; catch up fast if needed)

1. Appoint an accountable executive owner for AI governance;
2. Build the enterprise AI system inventory, including vendor-embedded AI;
3. Screen all systems against the Article 5 prohibitions;
4. Launch the AI literacy programme for staff dealing with AI;
5. Establish the AI governance committee and charter.

Phase 2, Classification & gap analysis (→ mid 2026)

1. Classify every inventory item: prohibited / high / limited / minimal risk;
2. Map roles per system: provider, deployer, importer, distributor;
3. Run gap analyses for high-risk systems against Articles 8–15;
4. Determine FRIA applicability for deployer use cases;
5. Renegotiate vendor contracts: documentation, change control, incident flow, GPAI evidence.

Phase 3, Build & conform (→ Aug 2026)

1. Implement risk-management, data-governance, logging and human-oversight controls;
2. Produce technical documentation and instructions for use;
3. Execute conformity assessments; prepare declarations of conformity and CE marking;
4. Stand up the EU-database registration process;
5. Deploy transparency measures for limited-risk systems (chatbot disclosure, content labelling).

Phase 4, Operate & monitor (ongoing)

1. Run post-market monitoring and serious-incident reporting;
2. Re-classify on change; trigger re-assessment on substantial modification;
3. Maintain AI literacy and role-based training;
4. Audit the programme annually; report to the board.

The AI Act does not stand alone, it stacks on GDPR, product liability, DSA, NIS2 and sectoral rules. Governance must integrate, not duplicate.

A layered legal landscape

AI systems sit at the intersection of multiple EU regimes. The AI Act is explicitly without prejudice to data protection, consumer protection, employment, product-safety and fundamental-rights law. Governance teams must therefore orchestrate several frameworks simultaneously.

AI Act × GDPR

Smart governance integrates the FRIA and DPIA into one assessment workflow, overlapping questions answered once, distinct legal outputs produced for each regime.

AI Act × product liability

The revised Product Liability Directive brings software, including AI, into strict product liability, with disclosure duties and rebuttable presumptions of defectiveness. The proposed AI Liability Directive addresses fault-based claims and evidence access. Together they convert AI governance failures into civil damages exposure, not just regulatory fines.

AI Act × DSA & platform rules

Very large online platforms using AI for recommender systems or content moderation face the Digital Services Act in parallel: risk assessments, transparency reports and algorithmic accountability obligations that overlap, but do not merge, with AI Act duties.

AI Act × NIS2 & DORA

AI systems in essential-entity infrastructure inherit NIS2 cybersecurity requirements; financial entities face DORA resilience rules. The AI Act's Article 15 cybersecurity requirement should be implemented as part of these existing security frameworks rather than as a standalone control set.

AI Act × sectoral regulation

Medical devices (MDR), aviation (EASA), automotive type approval, financial services and employment law all impose their own AI-relevant duties. The Act is designed to interface with them, e.g., conformity for Annex I products follows the sectoral route, extended with AI requirements.

Twelve building blocks for an AI Act compliance programme that stands up to supervisory scrutiny, from inventory to evidence.

The twelve building blocks

1. Executive accountability

Name a board-level owner, Chief AI Officer, CRO or equivalent, with budget, mandate and a direct reporting line. Accountability cannot be delegated to a project team.

2. Governance committee

A cross-functional AI governance committee (risk, legal, data, security, business, HR) that approves use cases, classifications and policy exceptions, with documented minutes.

3. AI system inventory

A living register of every AI system: purpose, model, vendor, data, users, affected persons, risk class, role (provider/deployer), owner, and lifecycle status. This is the programme's single source of truth.

4. Classification methodology

A documented, repeatable method for tiering systems against Articles 5 and 6 and Annex III, including carve-out analysis, with legal sign-off for borderline cases.

5. Use-case intake gate

No AI use case proceeds without a classification, a role determination, and (where applicable) a DPIA/FRIA trigger check. Embed the gate in procurement and SDLC processes so it cannot be bypassed.

6. Risk management system

A lifecycle risk process per Article 9: identification, analysis, evaluation, mitigation and residual-risk acceptance, integrated with enterprise risk management.

7. Data governance controls

Dataset provenance, representativeness, bias examination and quality documentation for training, validation and testing data (Article 10).

8. Documentation & logging

Annex IV technical documentation templates, automatic event logging, log retention rules, and instructions-for-use management.

9. Human oversight design

Named oversight roles with competence requirements, intervention rights, and override capability, designed into workflows, not appended to them.

10. Vendor & contract management

AI-specific contract clauses: documentation access, substantial-modification notification, incident reporting, GPAI compliance evidence, audit rights and liability allocation.

11. Incident & monitoring operations

Post-market monitoring plans, serious-incident detection and the 2/10/15-day reporting clocks, plus corrective-action workflows.

12. Training & AI literacy

Role-based programmes: board briefings, oversight-role certification, developer deep-dives, and general AI literacy for all staff dealing with AI (Article 4).

From legal text to operating reality: the five moves that turn AI Act compliance into trustworthy-AI advantage.

The strategic reframing

The EU AI Act is often framed as a compliance burden. Organisations that lead, rather than follow, read it differently: as a blueprint for trustworthy AI at scale. The same inventory, classification, documentation and oversight machinery that satisfies supervisors also reduces model failures, accelerates procurement, and builds the customer and regulator trust that unlocks bolder AI adoption.

Five moves to make this quarter

1. Appoint the accountable owner. One named executive, one mandate, one budget. Everything else follows from this.
2. Complete the inventory and Article 5 screen. You cannot govern what you cannot see, and the prohibitions have applied since February 2025.
3. Classify and gap-assess your high-risk candidates. Know your August 2026 exposure in systems, effort and money.
4. Fix the contracts. Vendor documentation, change control and incident flow are the most common, and cheapest, programme gaps to close.
5. Launch AI literacy. Article 4 is already in force; a documented training programme is the fastest demonstrable compliance win.

Continue the series

This whitepaper is the first in a five-part series on operational AI governance:

• Whitepaper 2, Governance Roles & Skillz: who must do what, and the competencies each role needs;
• Whitepaper 3, AI Governance Operating Model: how to structure governance that actually scales;
• Whitepaper 4, AI Governance Blueprint: the eight-pillar reference architecture for your programme;
• Whitepaper 5, AI Readiness Scan: assess your organisation's maturity and build the roadmap.

AI governance fails without people: the roles, skills and accountability structures that turn policy into practice.

Technology doesn't govern itself, people do

Every framework, policy and control in AI governance ultimately depends on a person: someone who approves a use case, someone who reviews a model, someone with the authority to say no. Yet when organisations are asked "who is accountable for your AI?", the most common honest answer is silence, or a committee with no teeth.

Regulation has ended that ambiguity. The EU AI Act explicitly requires human oversight by persons with the necessary competence, training and authority, and mandates a sufficient level of AI literacy for all staff dealing with AI systems. Roles and skills are no longer an HR topic; they are a legal compliance surface.

What this whitepaper gives you

• A complete role map from boardroom to model developer;
• Detailed profiles of the emerging Chief AI Officer and AI risk & compliance roles;
• The skills framework: technical, risk and leadership competencies per role;
• A practical RACI matrix for the full AI lifecycle;
• Training and certification pathways that satisfy Article 4 AI literacy duties;
• Guidance on sizing and structuring the governance team for your organisation.

Who should read this

CHROs and talent leads building AI capability; boards appointing accountable executives; Chief AI Officers designing their teams; and risk, compliance and audit leaders who must know where their responsibilities begin and end.

The accountability gap is the #1 failure mode of AI governance, and the first thing regulators now test.

The accountability gap

Analyses of AI incidents consistently find the same root cause: not malicious intent, not model failure, but diffuse accountability. Everyone assumed someone else had checked the training data. Nobody owned the monitoring dashboard. The "AI team" built it, the business used it, risk never saw it, and legal heard about it from a journalist.

This is why governance frameworks from the OECD, NIST and ISO/IEC 42001 all begin with the same move: define roles, responsibilities and accountability before anything else. Structures and processes only work when people with the right skills fill them.

Regulation made it explicit

The skills shortage is real

Demand for AI governance talent, risk-savvy technologists, tech-savvy lawyers, model validators, AI auditors, vastly outstrips supply. Organisations cannot hire their way out; they must build capability internally, combining upskilling, selective hiring and smart use of external expertise.

The three failure patterns to avoid

• The everything-committee, governance by consensus where nobody can actually decide;
• The bottleneck officer, one overloaded "AI person" through whom all decisions must pass;
• The shadow organisation, formal roles on paper, while real AI decisions happen in business units and vendor demos.

The pages that follow show how to design against all three.

Separating building, overseeing and auditing, the structural backbone every AI role hangs from.

Borrow a proven structure

Financial services solved this problem decades ago with the three lines of defence model. It maps almost perfectly onto AI governance and is the structure supervisors and auditors instinctively understand.

Why separation matters for AI

AI concentrates two risks that make self-policing fail: technical opacity (the builder is often the only one who understands the system) and deployment pressure (business incentives to ship fast). A genuine second line, with the skills to challenge models and the authority to block releases, is the single most important structural investment.

Where the AI governance office sits

Most mature organisations position the AI governance office in the second line, reporting to the CRO or directly to the CEO via a Chief AI Officer. It owns policy, classification methodology, the AI inventory, training programmes, and the governance committee secretariat, while first-line ownership of each system stays with the business.

Scaling by organisation size

• Small organisations: one accountable executive, a part-time governance lead, external review for high-risk use cases, contracted audit;
• Mid-size: dedicated AI governance lead, virtual committee, model-risk support from risk function;
• Large enterprises: AI governance office (3–10 FTE), embedded governance champions per business unit, dedicated model validation, AI audit capability in internal audit.

Tone at the top: risk appetite, oversight duties and the questions every board should ask about AI.

AI is now a board topic

With penalties up to 7% of global turnover, workforce transformation and strategic disruption all driven by AI, oversight of AI governance belongs squarely in the boardroom. Supervisors increasingly test the "tone at the top": what did the board know, decide and challenge?

Core board responsibilities

1. Set AI risk appetite, which AI risks the organisation will accept, in which domains, and where the red lines sit (often stricter than the law);
2. Approve the AI governance framework, policy, operating model and accountable executive;
3. Oversee strategy alignment, AI investments consistent with values, brand and risk appetite;
4. Challenge management, probe exposure, incidents, compliance status and talent;
5. Ensure board competence, AI literacy at board level, via training, advisors or board composition.

Ten questions the board should ask

• Do we have a complete inventory of all AI systems, including vendor-embedded AI?
• Which systems are high-risk under the EU AI Act, and what is our conformity status?
• Who is personally accountable for AI risk, and to whom do they report?
• What is our maximum regulatory and liability exposure, quantified?
• Which AI incidents occurred this quarter, and what did we learn?
• Can every high-risk system be overridden by a human, and has that been tested?
• Where does AI touch employees, customers and vulnerable groups?
• Are our AI literacy obligations met, and can we evidence it?
• Which third-party AI dependencies could harm us if they fail or are withdrawn?
• What would make us stop using an AI system, and who can pull that brake?

Board skill profile

Board members do not need to code. They need: AI conceptual fluency (what ML can and cannot do), regulatory awareness (AI Act, GDPR, liability), risk judgement (translating technical risk into business impact) and the confidence to challenge technical management.

Executive ownership across the C-suite, who carries which part of the AI governance load.

CEO, ultimate accountability

The CEO owns the organisation's AI posture: strategy, risk appetite execution, and culture. In enforcement and reputational scenarios, the CEO is where the buck stops. Key duties: appointing the accountable AI executive, resourcing the governance programme, and personally sponsoring the trustworthy-AI narrative internally and externally.

CIO, AI in the IT estate

The CIO governs AI as enterprise technology: architecture standards, platform choices, integration, and the shadow-AI problem, unsanctioned tools and SaaS features entering the estate. The CIO typically owns the technical AI inventory infrastructure, environment controls, and the interface between governance requirements and the software delivery lifecycle.

CDO, data foundations

AI governance stands or falls with data governance. The CDO owns data quality, lineage, provenance and representativeness, the Article 10 training-data requirements in practice. In many organisations the CDO also owns analytics-model governance for non-AI models, making the role the natural anchor for a unified model inventory.

CISO, AI security

The CISO extends security governance to AI-specific threats: adversarial attacks, prompt injection, data poisoning, model theft and extraction, and the security duties of Articles 15 (high-risk systems) and the GPAI regime. AI security testing and red-teaming belong here, integrated with NIS2/DORA programmes where applicable.

CRO & General Counsel, the risk and legal spine

The CRO integrates AI into enterprise risk management: risk taxonomy, appetite metrics, second-line challenge. The GC/DPO handles the legal surface: AI Act classification sign-off, GDPR interplay, contracts and liability, and the legal quality of individual-rights processes.

The emerging keystone role: mandate, profile, team design and the first 100 days.

Why this role is emerging now

AI governance requires someone who can talk transformer architectures with engineers in the morning and risk appetite with the board in the afternoon. No traditional C-suite role combines that breadth, hence the rise of the Chief AI Officer (CAIO) or Head of AI Governance: a single executive accountable for both AI value and AI control.

Mandate and responsibilities

1. Own the enterprise AI strategy and governance framework;
2. Chair the AI governance committee; run the use-case approval process;
3. Own the AI system inventory and classification methodology;
4. Accountable for regulatory compliance (AI Act, GDPR interplay, sectoral rules);
5. Own the AI literacy and training programme;
6. Report to the board on AI risk, incidents and compliance status;
7. Arbitrate the build/buy/retire decisions for AI systems.

The skill profile

Where should the CAIO report?

• To the CEO, signals strategic weight; best when AI is core to the business model;
• To the CRO, fits regulated industries; risks under-weighting innovation;
• To the CIO/CDO, pragmatic for tech-heavy organisations; ensure independent escalation to the board on risk matters.

Team design

A mid-size CAIO office typically comprises: an AI governance lead (policy & committee), an AI compliance manager (regulatory tracking, documentation), a model risk manager (validation & monitoring oversight), and an AI literacy/training lead, complemented by business-unit governance champions in a hub-and-spoke pattern.

The second line in action: classification, challenge, conformity and the daily machinery of control.

The role family

Under the CAIO's umbrella sit the specialists who make governance operational. Three profiles dominate:

1. AI Risk Manager

• Owns the AI risk taxonomy and assessment methodology;
• Runs risk assessments for new and changed use cases (Article 9 alignment);
• Maintains the AI risk register; tracks mitigations and residual risk;
• Designs KRIs: incident rates, override frequency, drift events, assessment coverage.

2. AI Compliance Manager

• Tracks the regulatory landscape (AI Act, GDPR, sectoral) and translates it into requirements;
• Performs and signs off risk classifications (prohibited / high / limited / minimal);
• Owns conformity artefacts: technical documentation quality, declarations of conformity, CE-marking process, EU-database registrations;
• Manages FRIA/DPIA workflows with legal and the DPO;
• Prepares the organisation for supervisory interactions.

3. Model Risk / Validation Specialist

• Independently validates models before deployment and periodically thereafter;
• Reviews data quality, bias testing, performance and robustness evidence;
• Oversees post-deployment monitoring: drift, degradation, incident signals;
• Owns the model-tiering logic that calibrates validation depth to risk.

Skill profiles

The first line: builders carry governance duties too, from data quality to documentation to human-oversight design.

Governance is part of the build

Data scientists and ML engineers are not "regulated by" governance, they are governance, first line. Most technical requirements of the AI Act (Articles 8–15) are executed by the people who build the systems: risk management, data governance, documentation, logging, robustness. Policies fail when builders experience them as external bureaucracy rather than engineering practice.

First-line governance duties

• Use-case intake honesty, describe the system's true purpose, data and affected persons so classification is correct;
• Data governance, provenance, representativeness, bias examination, quality documentation for training/validation/test sets;
• Technical documentation, Annex IV artefacts created during development, not reverse-engineered before audit;
• Logging by design, automatic event recording built into the system;
• Evaluation & testing, accuracy, robustness, cybersecurity testing proportionate to risk;
• Human-oversight engineering, interpretable outputs, confidence signals, override interfaces;
• Monitoring handover, production metrics, drift alarms and incident signals wired into operations.

The skill upgrade

Embedding governance in the workflow

1. Put classification and intake inside the SDLC, not beside it;
2. Automate documentation from the pipeline (model cards, data sheets);
3. Add governance checks to CI/CD: no production release without sign-offs;
4. Give engineers a named governance contact who answers in hours, not weeks.

Counsel in the loop: classification sign-off, rights handling, contracts and the ethics advisory function.

Legal counsel: the classification conscience

General counsel (or dedicated AI counsel) owns the legal judgement calls: prohibited-practice screening, Annex III interpretation, the Article 6(3) carve-out analysis, and provider/deployer role determinations. These are legal determinations with 7%-of-turnover consequences, they should not rest with engineers or product managers alone.

The DPO's expanded territory

AI systems processing personal data sit under the DPO's GDPR mandate: DPIAs, lawful basis, Article 22 automated-decision safeguards. The smart design merges DPIA and FRIA workflows so one assessment serves both regimes, with the DPO advising on the privacy half and legal on the fundamental-rights half.

Contracts: where governance becomes enforceable

Legal owns the contract machinery that makes vendor AI governable:

• Documentation and information-access clauses (Annex IV support, instructions for use);
• Substantial-modification notification and change control;
• Serious-incident reporting flows with defined clocks;
• GPAI compliance evidence as a procurement condition;
• Audit rights, liability allocation, indemnities and insurance;
• Exit and continuity provisions for critical AI dependencies.

The ethics advisory function

Beyond strict legality, leading organisations maintain an AI ethics board or advisory panel, internal experts plus external voices, that reviews borderline use cases: legal but reputationally dangerous, technically permissible but values-misaligned. Its role is advisory, but its minutes give the board a defensible record of values-based deliberation.

Skill profile

AI counsel needs genuine technical curiosity (the ability to interrogate what a system actually does), mastery of the AI Act/GDPR interplay, contract engineering skills, and the diplomacy to be seen as an enabler of good AI rather than the department of "no".

Article 4 makes AI literacy a legal duty, HR becomes a governance function, from training to workforce transition.

HR joins the governance table

Two forces put HR inside AI governance. First, the AI literacy obligation (Article 4): providers and deployers must ensure staff dealing with AI have sufficient literacy for their role and context. Second, workplace AI, recruitment screening, performance analytics, task allocation, is heavily represented in Annex III, making HR systems some of the highest-risk AI an organisation runs.

The AI literacy programme

A compliant literacy programme is role-based and evidenced:

Records matter: completion tracking, assessments and refresh cycles form the Article 4 evidence trail supervisors will request.

HR-owned governance duties

• Worker notification, informing employees before high-risk AI is deployed in the workplace (Article 26(7));
• Works-council consultation, co-determination rights in many EU jurisdictions;
• Role design, job profiles for governance roles; competence requirements for oversight positions;
• Performance systems, ensuring governance duties appear in objectives and evaluations of first-line owners;
• Workforce transition, reskilling pathways where AI changes or displaces roles.

The hard skills of AI governance, from model literacy to evaluation, security and data engineering.

A competency architecture

Effective governance teams blend four technical competency domains. Not everyone needs all four, but the team must cover them, and every governance professional needs the foundation layer.

Domain 1, AI/ML literacy (foundation for all)

• How ML systems learn; training/validation/test logic; overfitting and generalisation;
• Model families: supervised, unsupervised, reinforcement, generative and agentic systems;
• What LLMs can and cannot do: hallucination, grounding, context limits;
• The difference between model performance and system performance in the real world.

Domain 2, Data governance engineering

• Provenance and lineage tracking; dataset documentation (datasheets);
• Representativeness analysis and bias measurement;
• Synthetic data, labelling quality, data drift;
• Privacy techniques: minimisation, pseudonymisation, PETs.

Domain 3, Evaluation & validation

• Metric selection beyond accuracy: fairness metrics, calibration, robustness testing;
• Red-teaming and adversarial evaluation; human-in-the-loop evaluation design;
• Monitoring design: drift detection, performance decay, alerting thresholds;
• Documentation: model cards, evaluation reports, conformity evidence.

Domain 4, AI security

• Threat landscape: prompt injection, data poisoning, model extraction, evasion;
• Secure deployment patterns, access control, secrets management;
• Article 15 robustness/cybersecurity mapping to ISO 27001 and NIS2 controls.

Proficiency levels

The human skills that make governance stick: judgement, influence, challenge and communication.

Beyond the technical

Governance failures are rarely caused by missing technical knowledge. They are caused by missing judgement and influence: the risk manager who didn't push back, the executive who didn't ask, the committee that filed the report unread. These competencies deserve equal billing with the technical ones.

Domain 5, Regulatory & legal reasoning

• Working fluency in the AI Act's risk logic; GDPR interplay; liability exposure;
• Ability to translate legal text into control requirements, and back;
• Regulatory horizon scanning: standards, guidance, enforcement signals.

Domain 6, Risk judgement & decision-making

• Calibrated risk thinking: likelihood × impact under uncertainty;
• Proportionality: matching control depth to actual exposure;
• Comfort with documented trade-offs, knowing when residual risk is acceptable and owning that call.

Domain 7, Challenge & influence

• Constructive challenge of technical teams and senior sponsors;
• Escalation judgement: when to push, when to escalate, when to accept;
• The ability to say "no" to revenue pressure, and survive it organisationally.

Domain 8, Communication & translation

• Translating between board, legal, engineering and business dialects;
• Incident communication: clear, fast, non-defensive;
• Writing that supervisors and auditors can act on: crisp assessments, unambiguous minutes.

The competency matrix in practice

One page to end ambiguity: accountable, responsible, consulted and informed across every governance activity.

Why RACI, and why now

The RACI matrix is unfashionable but undefeated: it forces the two conversations organisations avoid, who decides and who does. Below is a reference RACI for the core AI lifecycle governance activities. Adapt it, sign it off in the governance committee, and publish it.

R = ResponsibleA = AccountableC = ConsultedI = Informed

Design rules

• Exactly one A per activity. Two accountable parties means zero;
• Business owners are always R for their systems, governance cannot outsource ownership;
• Audit is never R or A for first/second-line activities, independence is its value;
• Review the RACI after every incident and reorg; matrices decay.

From awareness to certification: building the Article 4-compliant learning architecture that evidences AI literacy.

The learning architecture

AI literacy is not one course. It is a layered pathway system tied to roles, refreshed on a cycle, and evidenced for regulators. A robust architecture has four layers:

Layer 1, Enterprise awareness (all staff)

• 60–90 minute e-learning: what AI is, where we use it, acceptable-use rules, escalation routes;
• Annual refresh; completion tracked; 100% coverage target.

Layer 2, Role-based practitioner training

• Deployers/users: system-specific instruction, output interpretation, oversight duties (half-day);
• Builders: data governance, evaluation, documentation, security (1–2 days + labs);
• HR, procurement, legal: domain modules for their Annex III exposure.

Layer 3, Certified oversight & governance roles

• Human-oversight certification: intervention rights, override drills, incident simulation;
• Governance professionals: internal certification or external credentials (e.g., IAPP AIGP, ISO/IEC 42001 lead-implementer/auditor tracks);
• Validators: model-risk and evaluation methodology deep-dives.

Layer 4, Executive & board briefings

• Semi-annual sessions: regulatory shifts, portfolio risk, incident lessons, strategy trade-offs;
• External speakers to challenge internal narratives.

Evidence: the compliance half of training

Operating model for learning

• Ownership: HR/L&D delivers; CAIO owns content standards and compliance reporting;
• Trigger-based training: new system deployment, role change, or incident lessons push targeted modules;
• Effectiveness measurement: scenario assessments and behavioural KPIs (escalation quality, oversight interventions), not just completion rates;
• Vendor content caution: generic AI courses rarely meet role-specificity, use them as base layer, customise for your systems.

People make governance real: the staffing moves that complete your AI governance puzzle.

The human layer is the control layer

Frameworks, inventories and policies are necessary, but they are inert without people who are accountable, competent and empowered. The organisations that pass supervisory scrutiny and survive AI incidents are those where every governance activity has a name attached, and every name has the skills to match.

Seven staffing moves to make now

1. Name the accountable executive, CAIO or an explicitly mandated CRO/CDO, with board visibility;
2. Stand up the second line, at minimum an AI compliance manager and validation capacity, with a written right to challenge;
3. Sign and publish the RACI, end accountability ambiguity in one document;
4. Assign human-oversight persons for every high-risk system, trained, authorised, evidenced;
5. Launch the role-based literacy programme, Article 4 compliance with records;
6. Audit the HR tech stack, your highest-risk AI may be in recruitment and workforce tools;
7. Build internal capability, hire scarce technical validators, grow judgement through rotation and incident exercises.

Continue the series

• Whitepaper 1, EU AI Act Governance: the regulatory framework these roles must implement;
• Whitepaper 3, AI Governance Operating Model: how these roles combine into structures that scale;
• Whitepaper 4, AI Governance Blueprint: the eight pillars, including structure & accountability;
• Whitepaper 5, AI Readiness Scan: measure your people-and-skills maturity today.

Policies don't scale, operating models do. How to design the structure, processes and machinery that govern AI at enterprise pace.

The scaling problem

Most organisations govern their first three AI systems fine: a committee reviews them, a lawyer checks them, everyone knows everyone. Then AI adoption accelerates, ten systems, fifty, two hundred, plus vendor-embedded AI arriving with every SaaS update. The committee drowns, reviews take months, and the business starts routing around governance entirely.

The problem is not commitment; it is design. What worked for three systems cannot work for three hundred. What is needed is a deliberate operating model: a documented set of structures, processes, decision rights, tooling and metrics that make governance repeatable, fast and scalable.

What this whitepaper gives you

• The three operating-model archetypes, centralised, federated, hub-and-spoke, and how to choose;
• The governance bodies and their charters: committees, boards, working groups;
• The policy architecture: principles → policy → standards → procedures;
• End-to-end lifecycle processes: from use-case intake to retirement;
• The tooling stack: inventory, workflow, monitoring and evidence;
• KPIs and KRIs that demonstrate the model is working;
• An implementation roadmap and the pitfalls that sink most designs.

Who should read this

Chief AI Officers and governance leads designing their function; CIOs and transformation leaders integrating governance into delivery; CROs aligning AI oversight with enterprise risk; and consultants building governance for clients.

Beyond policy documents: the six components that make governance operational rather than aspirational.

Policy ≠ operating model

An AI policy says what must happen: "high-risk systems require human oversight." An operating model defines how it actually happens: who classifies the system, using which criteria, in which workflow, with what SLA, recorded where, checked by whom. The gap between the two is where most AI governance quietly dies.

The six components

1. Structure, governance bodies, roles and reporting lines: who governs, who decides, who executes;
2. Decision rights, which body or role can approve, condition or reject each class of decision;
3. Processes, the repeatable workflows (intake, assessment, approval, monitoring, incident, retirement) with entry and exit criteria;
4. Rules, the policy architecture that processes enforce: principles, policies, standards, procedures;
5. Tooling, inventory, workflow automation, monitoring and evidence systems that make processes executable at scale;
6. Measurement, KPIs and KRIs proving the model works and showing where it degrades.

The design tension: speed vs control

Every operating model balances two legitimate forces. Too much control and governance becomes the innovation tax everyone avoids; too little and you accumulate invisible risk until an incident or supervisor forces the issue. The resolution is risk proportionality by design: minimal-risk systems flow through automatically, high-risk systems get deep review, so governance effort concentrates where it matters.

Eight principles that separate operating models that scale from those that stall.

Principle 1, Risk proportionality

Calibrate governance depth to risk tier. A content-recommendation engine and an employee-attrition predictor must not face the same review. Proportionality is both a regulatory requirement (the AI Act's entire logic) and a speed enabler.

Principle 2, First-line ownership

The business owns its AI risk. Governance sets rules, reviews and challenges, but never becomes the de facto owner of systems it did not build. Ownership diffused is ownership lost.

Principle 3, Embed, don't bolt on

Governance steps live inside existing workflows: procurement gates, SDLC pipelines, change management, vendor onboarding. A parallel governance process that teams must remember to invoke will be forgotten.

Principle 4, Evidence by default

Every process produces its compliance evidence automatically: classification records, assessment outcomes, approval minutes, training logs. If evidence requires separate effort, it will be missing exactly when a supervisor asks.

Principle 5, Single source of truth

One AI inventory, one classification methodology, one policy repository. Parallel registers and divergent criteria are how systems slip between governance cracks.

Principle 6, Lifecycle coverage

Governance runs from idea to retirement, not just pre-launch approval. Drift, incidents, model updates and vendor changes are lifecycle events that re-trigger governance automatically.

Principle 7, Transparency inside the walls

Everyone building or buying AI knows the rules, the process, the SLA and the escalation route. Governance that surprises people generates workarounds.

Principle 8, Continuous improvement

The model is itself governed: metrics reviewed quarterly, design adjusted after incidents and regulatory change, maturity reassessed annually.

One central authority approves everything, maximum control, and its limits.

How it works

All AI decisions flow through a single central body: a central AI office with strong authority, approving use cases, owning the inventory, running assessments and monitoring centrally. Business units propose; the centre decides.

Strengths

• Consistency, one methodology, one standard, one risk bar across the enterprise;
• Visibility, complete oversight of the AI estate in one place;
• Efficiency of expertise, scarce governance talent concentrated where it has full context;
• Clear accountability, no ambiguity about who approved what.

Weaknesses

• Bottleneck, throughput limited by central capacity; review queues breed workarounds;
• Distance from the business, central reviewers may lack domain context, producing slow or tone-deaf decisions;
• Shadow-AI incentive, frustrated teams procure AI outside the process;
• Single point of failure, the model's quality equals the centre's quality.

When it fits

Making centralised work anyway

1. Impose SLAs on central reviews (e.g., classification in 5 days, full assessment in 20);
2. Automate the low-risk tier out of the queue, no human review for minimal-risk systems;
3. Publish decision criteria so teams can self-prepare;
4. Track the shadow-AI signal: if teams route around you, the model is telling you something.

Business units govern themselves under group rules, maximum scale, and its risks.

How it works

Group governance sets the framework, principles, policies, risk taxonomy, minimum standards, but business units execute: they classify, assess, approve and monitor their own AI within the group guardrails, with their own governance roles and budgets.

Strengths

• Scale, governance capacity grows with the business; no central queue;
• Domain fit, assessments made by people who understand the use case and its context;
• Ownership culture, first-line accountability is structurally real, not rhetorical;
• Speed, decisions made close to the work.

Weaknesses

• Inconsistency, the same system may be classified differently across BUs;
• Capability variance, governance quality equals the weakest BU's capability;
• Aggregation blindness, nobody sees enterprise-wide exposure; small risks sum to large ones;
• Duplication, every BU reinvents templates, tooling and training.

When it fits

Federation suits large, diverse organisations with mature risk cultures in each unit, global banks with strong divisional risk functions, industrial groups with autonomous divisions, provided group-level assurance mechanisms exist.

The non-negotiable guardrails

1. Group-owned methodology, classification criteria and risk taxonomy are not negotiable locally;
2. Central inventory, local decisions, one register: every BU system visible at group level;
3. Escalation floor, high-risk classifications automatically escalate to group review regardless of local authority;
4. Independent assurance, group second-line spot-checks and thematic reviews across BUs;
5. Certification of local roles, BU governance staff trained and certified to a group standard.

A strong centre for standards and high-risk decisions, empowered spokes for execution, the model most enterprises converge on.

How it works

Hub-and-spoke combines the strengths of both archetypes: a lean central hub owns methodology, policy, the inventory platform, training and high-risk decisions; embedded governance champions in each business unit handle intake, classification, documentation and monitoring for their unit, trained and certified by the hub.

Division of labour

Why it wins in practice

• Scale without dilution, capacity in the units, consistency from the centre;
• Career-path design, champion roles create the talent pipeline the hub needs;
• Proportional effort, the hub's scarce experts concentrate on the high-risk minority;
• Cultural reach, champions translate governance into local language and practice.

Sizing guidance

Rule of thumb from organisations running this model: a hub of 3–8 FTE for a large enterprise, plus 0.2–1 FTE champions per business unit (scaled by AI volume), refreshed through an annual certification cycle. Champions typically report solid-line to their unit, dotted-line to the hub, with hub sign-off on their appointment.

Committees, boards and working groups: charters, cadence, quorum and the decision-rights matrix.

The governance body stack

1. Board / Audit & Risk Committee, risk appetite, framework approval, quarterly oversight;
2. Executive AI Governance Committee, the decision-making core: strategy, policy, high-risk approvals, exception handling;
3. AI Review Board, operational assessments: use-case reviews, classification challenges, technical deep-dives;
4. Working groups, standing groups for data governance, security, legal/regulatory, and literacy.

The Executive AI Governance Committee: charter essentials

• Composition: CAIO (chair), CRO, CIO, CDO, GC, CISO, CHRO, rotating BU executives;
• Cadence: monthly, with ad-hoc sessions for serious incidents;
• Quorum & authority: defined in writing, which decisions it takes itself, which it recommends upward;
• Standing agenda: inventory & risk posture, approvals pipeline, incidents, regulatory watch, KPIs;
• Minutes: decisions, rationale and dissent recorded, supervisory evidence by design.

Decision-rights matrix

Cadence design

Principles → policy → standards → procedures: a four-layer rulebook that is short enough to read and deep enough to run.

Why architecture matters

Organisations typically fail in two directions: a 3-page "AI policy" too vague to execute, or a 200-page tome nobody reads. The fix is a four-layer architecture where each layer has a distinct job, owner and change cadence.

Layer 1, AI Principles (board-owned, stable)

5–7 statements of intent: e.g., human agency, fairness, transparency, privacy, safety, accountability, sustainability. Approved by the board, changed rarely, referenced everywhere. Principles answer "what do we believe?"

Layer 2, AI Policy (executive-owned, annual review)

The binding framework, 10–20 pages: scope, roles & accountability, risk classification, mandatory controls per tier, exceptions process, non-compliance consequences. Policy answers "what must we do?"

Layer 3, Standards (hub-owned, semi-annual)

Domain-specific requirements: data-governance standard, model-documentation standard, human-oversight standard, vendor-AI standard, AI-security standard, literacy standard. Standards answer "to what level?"

Layer 4, Procedures & templates (process owners, continuous)

The executable layer: intake forms, classification decision trees, assessment templates, FRIA/DPIA workflows, incident runbooks, conformity checklists. Procedures answer "how, exactly?"

Layering in practice

The front half of the AI lifecycle: intake, classification, assessment, approval and release gates.

Process map: the five front gates

Gate 1, Intake

Every AI initiative, build, buy or configure, enters through a single intake: a structured form capturing purpose, users, affected persons, data categories, vendor involvement and expected impact. Intake lives inside existing channels (procurement, project office, SDLC) so bypassing is structurally hard.

Gate 2, Classification

Using the group decision tree: prohibited? high-risk (Annex I/III, carve-outs)? limited-risk transparency duties? minimal? Output: a recorded classification with rationale, signed by the accountable classifier. Classification SLA: days, not weeks.

Gate 3, Risk assessment

Proportionate to tier. Minimal: none beyond intake. Limited: transparency checklist. High: full assessment, risk management plan, data-governance review, DPIA/FRIA triggers, oversight design, security review, vendor evidence.

Gate 4, Approval

Per the decision-rights matrix: automatic for minimal, champion-level for limited, Review Board for high-risk with conditions documented. Approvals record scope: this use case, this data, this user group, changes re-trigger review.

Gate 5, Release

Pre-production checklist: documentation complete, logging live, oversight persons trained, monitoring wired, transparency measures deployed, EU-database registration where required, worker notification where applicable. Then, and only then, go-live.

Target cycle times

The back half where governance usually decays: monitoring, change, incident response and decommissioning.

Gate 6, Operational monitoring

Post-launch, governance shifts to surveillance: performance metrics, drift indicators, fairness monitoring, usage patterns and override statistics flowing into dashboards reviewed at proportionate cadence. High-risk systems: continuous. Limited: periodic sampling. Each system has a named monitoring owner.

Gate 7, Change management

The silent killer of AI compliance: systems change after approval. Model retrains, vendor updates, new user groups, new data sources, expanded purposes. The operating model must define re-trigger thresholds:

• Material change → re-assessment (possibly re-classification);
• Substantial modification of a high-risk system → new conformity assessment;
• Vendor model version upgrades → evidence refresh and regression review;
• Purpose expansion → full re-intake.

Gate 8, Incident response

An AI-specific incident process, integrated with enterprise incident management:

1. Detect, monitoring alerts, user reports, oversight observations, vendor notices;
2. Triage, severity classification: is it a "serious incident" under the AI Act?
3. Contain, throttle, suspend or roll back; CAIO holds immediate suspension authority;
4. Report, regulatory clocks: 2 days (widespread/critical-infrastructure), 10 days (death), 15 days (other serious incidents); GDPR breach clocks may run in parallel;
5. Learn, post-incident review feeding methodology and training.

Gate 9, Retirement

Systems must leave as cleanly as they entered: decommission plan, data and log retention per schedule, EU-database deregistration, vendor contract closure, and a lessons-learned record. "Zombie systems", still running, nobody owning them, are a classic audit finding.

The platform layer: AI inventory, workflow automation, monitoring and evidence, what to buy, build or configure.

Why tooling is non-negotiable

Beyond ~20 AI systems, spreadsheet governance collapses: inventory drifts, assessments scatter across email, evidence can't be found, SLAs are unmeasurable. The tooling layer is what makes the operating model executable at scale, and what produces supervisory evidence on demand.

The four-platform stack

1. AI inventory & register

The system of record: every AI system with purpose, tier, owner, vendor, data, lifecycle status, approvals and monitoring links. Requirements: workflow integration, API to CMDB/procurement, EU-database export formats, audit trail. Options: GRC platforms' AI modules, dedicated AI-governance platforms, or (initially) a rigorously maintained register in your existing GRC tool.

2. Workflow & assessment automation

Intake forms, classification decision trees, assessment templates, approval routing with SLAs and escalation. The goal: the process enforces itself, a high-risk classification automatically routes to the Review Board; a missing DPIA blocks the release gate.

3. Model & system monitoring

Drift detection, performance and fairness metrics, override statistics, alerting into the incident process. For GenAI: output sampling, guardrail effectiveness, usage analytics. Integrate with existing observability stacks where possible.

4. Evidence & documentation

Versioned repository for technical documentation, assessments, declarations of conformity, minutes, training records, retrievable per system within hours, with retention schedules matching the 10-year documentation duties.

Buy, build or configure?

Prove it works: the measurement layer that turns governance from a cost centre into a demonstrated control environment.

Why measure governance itself

"Is our AI governance working?" must have a data answer, not a vibes answer. Metrics serve three audiences: the board (assurance), the governance function (improvement), and supervisors (evidence of a functioning programme, a genuine mitigating factor in enforcement).

Coverage metrics

• % of AI systems in the inventory vs discovered estate (target: 100%, verified by periodic discovery scans);
• % of systems with current classification;
• % of high-risk systems with complete documentation and conformity status;
• % of staff with current role-based AI-literacy training.

Process metrics

• Median intake-to-decision time per tier vs SLA;
• Approval rate and conditions rate (both extremes are signals: ~100% approval suggests rubber-stamping; very low suggests intake failure);
• % of deployments passing release gate first time;
• Re-trigger rate: % of changed systems correctly re-assessed.

Risk metrics (KRIs)

• AI incidents per quarter by severity; serious incidents and regulatory reports;
• Override/intervention frequency for high-risk systems (zero interventions may indicate rubber-stamping humans);
• Drift/performance alerts open beyond SLA;
• Shadow-AI discoveries (procurement/network scans finding unregistered systems);
• Vendor AI concentration and high-risk third-party dependencies.

The quarterly board pack

From zero to operating model in 12 months: four phases, sequenced deliverables and the capacity plan.

Phase 1, Mobilise (months 0–2)

• Appoint accountable executive; secure mandate and budget;
• Draft the operating-model design on one page: archetype choice, bodies, decision rights;
• Stand up the Governance Committee with signed charter;
• Start the AI inventory discovery sweep (procurement, CMDB, network, interviews);
• Quick win: prohibited-practice screen + literacy programme launch.

Phase 2, Foundation (months 2–5)

• Publish AI principles and policy v1;
• Deploy intake + classification workflow (even on basic tooling);
• Recruit/train BU champions; first certification cohort;
• Complete classification of the discovered estate;
• Stand up the Review Board; run first high-risk assessments.

Phase 3, Operationalise (months 5–9)

• Full lifecycle process live: release gates, monitoring owners, incident runbook;
• Tooling decision executed; inventory migrated to platform;
• Standards layer published (documentation, oversight, vendor, security);
• First incident tabletop exercise; first board quarterly report;
• Conformity programme for high-risk portfolio on track for AI Act dates.

Phase 4, Mature (months 9–12)

• KPI/KRI dashboard live with targets;
• Evidence drill: produce a supervisory-grade pack for a random system in 24 hours;
• Independent review (3rd line or external) of model design and operation;
• Annual framework review: lessons, adjustments, v2 policy;
• Roadmap for next maturity level (see Whitepaper 4's maturity model).

Capacity planning

The eight failure patterns observed across real implementations, and the countermeasures for each.

Pitfall 1, The paper programme

Beautiful policy, no inventory, no workflow, no evidence. Countermeasure: start with the inventory and intake process; policy follows practice.

Pitfall 2, Committee as bottleneck

Every decision waits for a monthly meeting; queues grow; shadow AI explodes. Countermeasure: risk-tiered decision rights, automated low-risk routing, published SLAs, weekly operational review.

Pitfall 3, Governance of build only

Procured and SaaS-embedded AI slips past because the process targets internal development. Countermeasure: intake embedded in procurement and vendor onboarding; contract clauses requiring AI disclosure.

Pitfall 4, The frozen classification

Systems classified once, never revisited as they evolve. Countermeasure: change-trigger thresholds, annual re-classification cycle, vendor update monitoring.

Pitfall 5, Champions in name only

Dotted-line roles with 5% time and no authority decay within a quarter. Countermeasure: protected time, certification, hub sign-off on appointments, community of practice.

Pitfall 6, Metric-free operation

No SLAs, no KRIs, no board reporting, governance invisible until an incident. Countermeasure: measurement layer from Phase 3; three acted-on metrics minimum.

Pitfall 7, Compliance-only framing

Governance positioned purely as legal defence gets minimal cooperation. Countermeasure: frame as quality + trust + speed; publish success stories where governance improved systems.

Pitfall 8, Ignoring the GenAI channel

The register covers models, but staff use consumer GenAI tools with sensitive data daily. Countermeasure: acceptable-use policy, sanctioned enterprise alternatives, network-level visibility, targeted literacy.

Governance as operating system: the design decisions that let you scale AI with confidence.

The operating model is the strategy

Organisations don't experience your AI governance as principles or policies, they experience it as the intake form, the review SLA, the champion who helps them, the dashboard the board reads. The operating model is where governance becomes real, and where the difference between scaling AI safely and stalling (or losing control) is actually decided.

The five design decisions that matter most

1. Archetype: start centralised, plan for hub-and-spoke as volume grows;
2. Decision rights: risk-tiered, written down, with SLAs, one accountable decider per decision class;
3. Embedding: governance gates inside procurement, SDLC and change management, never parallel;
4. Lifecycle balance: as much machinery after launch as before it;
5. Measurement: a board-visible dashboard proving coverage, speed and control.

Checklist: is your model real?

• Can you produce a complete, current AI inventory today?
• Does every system have a recorded classification with rationale?
• Can you trace any approval to a named decider under a written decision-rights matrix?
• Do minimal-risk systems clear governance the same day?
• Is there a tested incident runbook with regulatory clocks?
• Can you assemble supervisory-grade evidence for any system within 24 hours?
• Does the board see AI governance metrics quarterly?

Continue the series

• Whitepaper 1, EU AI Act Governance: the regulatory requirements your model must implement;
• Whitepaper 2, Governance Roles & Skillz: the people and competencies that staff the model;
• Whitepaper 4, AI Governance Blueprint: the eight-pillar architecture and maturity path;
• Whitepaper 5, AI Readiness Scan: baseline your current model and prioritise the build.

One blueprint, eight pillars: the reference architecture that turns scattered AI controls into a coherent governance system.

Why a blueprint?

Most organisations don't lack AI governance activity, they lack AI governance architecture. A policy here, a review board there, a DPIA process from privacy, some model documentation from data science. Individually reasonable; collectively incoherent: gaps nobody owns, overlaps everyone pays for, and no way to tell a board or supervisor "here is our governance system, complete and working."

The AI Governance Blueprint solves this with a reference architecture: eight pillars that together cover the full governance surface, a maturity model to locate yourself, and sequenced implementation plans to close the gaps. It synthesises the EU AI Act's requirements, ISO/IEC 42001, the NIST AI Risk Management Framework and observed leading practice into one buildable design.

The eight pillars at a glance

1. Strategy & Alignment, why we use AI and what we'll never do;
2. Structure & Accountability, who governs and decides;
3. Risk Management, how we identify, assess and treat AI risk;
4. Policies & Standards, the rulebook;
5. Data Governance, the foundation everything stands on;
6. Model Lifecycle Management, control from build to retirement;
7. Third-Party & Vendor Governance, the extended estate;
8. Culture & Awareness, the human operating system.

How to use this whitepaper

Read pages 2–10 as a design reference: assess each pillar against your current state. Use the maturity model (page 11) to score yourself, the 90-day quick start (page 12) to mobilise, and the 12-month plan (page 13) to execute. Page 14 lists the artefacts that accelerate every build.

How the eight pillars fit together, and how the blueprint maps to the EU AI Act, ISO 42001 and NIST AI RMF.

Architecture logic

The eight pillars form three layers:

• Direction layer, Pillars 1–2: strategy and structure set intent and accountability;
• Control layer, Pillars 3–7: risk, policy, data, lifecycle and vendor governance execute control;
• Foundation layer, Pillar 8: culture makes everything else function.

Remove any pillar and the system develops a characteristic failure: no strategy → governance without direction; no structure → nobody accountable; no risk management → blind spots; no policy → inconsistent practice; no data governance → unreliable models; no lifecycle control → post-launch decay; no vendor governance → ungoverned external estate; no culture → widespread circumvention.

Mapping to frameworks

Design properties

• Complete: every major regulatory and framework requirement maps to at least one pillar;
• Non-overlapping: each requirement has one primary pillar owner;
• Scalable: pillar depth scales with risk exposure and organisation size;
• Auditable: each pillar produces its own evidence artefacts.

Governance starts with intent: AI ambition, risk appetite, ethical red lines and the use-case portfolio.

Purpose of the pillar

Strategy answers the questions governance cannot answer on its own: What is AI for in this organisation? What risk will we accept to get it? What will we never do, regardless of legality? Without these, every governance decision is improvised.

Components

1. AI ambition statement

A one-page articulation, board-endorsed: where AI creates value (efficiency, products, decisions), the investment thesis, and the trust position ("we deploy AI our customers and regulators can trust").

2. AI risk appetite

Quantified where possible: maximum exposure thresholds, domains of low tolerance (employment decisions, vulnerable customers, safety-critical), and escalation triggers. Approved by the board, reviewed annually.

3. Ethical red lines

Beyond legal prohibitions: uses the organisation refuses, e.g., covert manipulation, employee emotion inference, deceptive anthropomorphism. Red lines simplify governance: they pre-decide the hard cases.

4. Use-case portfolio governance

A managed portfolio view: value vs risk per use case, strategic coverage, concentration risks. Governance effort is allocated by portfolio analysis, not first-come-first-served.

Key artefacts

• Board-approved AI ambition & risk appetite statement;
• Ethical red-line register with rationale;
• Quarterly portfolio review (value delivered vs risk posture);
• Strategy-to-policy traceability: every principle grounded in the ambition.

Evidence of operation

Appetite referenced in actual committee decisions; red lines invoked (and honoured) in real cases; portfolio reviews influencing which use cases get funded and which get retired.

Bodies, roles and decision rights, the skeletal system of governance.

Purpose of the pillar

Structure converts strategy into accountable execution: the bodies that decide, the roles that execute, the matrix that removes ambiguity. (Whitepapers 2 and 3 cover this in depth; here the blueprint view.)

Components

1. Governance bodies

Board oversight → Executive AI Governance Committee → AI Review Board → working groups, each with written charters, cadence and quorum.

2. Accountable executive

One named executive (CAIO or mandated CRO/CDO) with mandate, budget and board access. Personal accountability, not committee diffusion.

3. Three lines of defence

First-line business ownership, second-line risk/compliance/validation challenge, third-line independent assurance, with the second line holding a written right to block.

4. Decision rights & RACI

Risk-tiered decision matrix: who approves what, at which tier, with which SLA; a signed RACI covering the full lifecycle.

5. Hub-and-spoke capacity

A lean hub for methodology and high-risk decisions; certified BU champions for scale.

Key artefacts

• Committee charters and minutes;
• Executive mandate letter;
• Signed RACI matrix, published;
• Champion certification records.

The engine room: taxonomy, assessment methodology, FRIA/DPIA integration and treatment tracking.

Purpose of the pillar

Risk management is where governance meets reality: identifying what can go wrong with each AI system, assessing it honestly, treating it proportionately, and tracking residual risk with eyes open. Article 9 of the AI Act makes this a legal system, not a workshop exercise.

Components

1. AI risk taxonomy

A shared vocabulary: performance risk, bias/fairness, opacity/explainability, security threats, privacy, safety, third-party concentration, misuse, societal and reputational risk. Every assessment speaks this language.

2. Assessment methodology

A documented, repeatable method: likelihood × impact calibrated for AI, tier-calibrated depth, mandatory challenge by the second line for high-risk systems, documented rationale for every acceptance.

3. Regulatory assessment integration

One workflow producing FRIA (fundamental rights), DPIA (privacy) and security assessments without duplication, shared data collection, distinct legal outputs.

4. Treatment & residual risk

Mitigation plans with owners and dates; residual-risk acceptance at the correct authority level (never below the tier's decision authority); periodic re-acceptance as context changes.

5. Enterprise integration

AI risks flow into the enterprise risk register and board reporting; AI is not a side-register nobody aggregates.

Key artefacts

• AI risk taxonomy and assessment handbook;
• Assessment records per system, with challenge notes;
• Residual-risk acceptance log with authority levels;
• Integrated FRIA/DPIA workflow and templates.

The rulebook: four layers from board principles to executable procedures, and the discipline of keeping them alive.

Purpose of the pillar

Policies translate strategy and law into binding organisational rules. The blueprint uses the four-layer architecture: principles → policy → standards → procedures (detailed in Whitepaper 3, page 8), each layer with its own owner, audience and change cadence.

Components

1. Principles

Board-level statements of belief: human agency, fairness, transparency, privacy, safety, accountability. Stable, quoted in every assessment.

2. AI policy

The binding core: scope, roles, classification, tier-mandatory controls, exceptions, consequences. Ten to twenty pages, annually reviewed.

3. Standards

Six domain standards: data governance, model documentation, human oversight, vendor AI, AI security, AI literacy. Each defines measurable requirements ("shall" statements testable in audit).

4. Procedures & templates

Intake forms, classification trees, assessment templates, runbooks, the executable layer that lives in the workflow tooling.

Policy lifecycle discipline

• Version control: every document versioned, approved, published in one repository;
• Review cadence: annual for policy, semi-annual for standards, continuous for procedures;
• Regulatory watch: legal reviews each layer against new guidance, standards and enforcement;
• Exception register: every deviation recorded with expiry and compensating controls.

The foundation: provenance, quality, representativeness and privacy for the data that trains and feeds AI.

Purpose of the pillar

AI systems are frozen data decisions. Biased, unrepresentative or unlawful data in, biased, unreliable or unlawful outcomes out, no matter how good the model. Article 10 of the AI Act elevates data governance from good practice to legal requirement for high-risk systems.

Components

1. Data provenance & lineage

Where did training/validation/test data come from, under what rights, through which transformations? Lineage tracking from source to model, documented in datasheets.

2. Quality & representativeness

Relevance, completeness and representativeness analysis for the intended deployment population, with examination of possible biases and gaps, as the Act requires.

3. Privacy & lawful use

Lawful basis for training and inference data; minimisation; retention; the GDPR interplay for personal data in models, including the hard questions around data subject rights and trained models.

4. Data operations

Labelling quality management, synthetic-data governance, drift monitoring on input distributions, and access controls for sensitive datasets.

5. Vendor & external data

Rights verification for licensed and scraped datasets; GPAI providers' training-data summaries reviewed as procurement evidence.

Key artefacts

• Dataset datasheets with provenance and representativeness analysis;
• Data-quality standards and measurement results;
• Privacy assessments for AI data flows;
• Drift-monitoring dashboards and thresholds.

Control from conception to retirement: validation, documentation, conformity, monitoring and incident response.

Purpose of the pillar

Pillar 6 governs the machines themselves across their full life: how models are built, validated, documented, approved, monitored, changed and retired. It operationalises Articles 8–15 of the AI Act and the conformity machinery of Chapter III.

Components

1. Development controls

Reproducible pipelines, versioning of data/code/models, evaluation requirements per tier, and documentation-as-code so Annex IV artefacts accumulate during development.

2. Independent validation

Second-line review before deployment: data quality, performance, fairness, robustness, security, depth scaled to tier, findings tracked to closure.

3. Conformity & release

Conformity assessment execution, declarations of conformity, CE marking, EU-database registration, release-gate checklists (logging live, oversight trained, transparency deployed).

4. Operational monitoring

Performance, drift, fairness and usage dashboards; override statistics; alert thresholds wired to incident response; post-market monitoring plans for providers.

5. Change & incident management

Re-trigger thresholds for re-assessment; substantial-modification handling; serious-incident detection and the 2/10/15-day regulatory reporting clocks.

6. Retirement

Decommissioning plans, retention schedules, deregistration, lessons learned.

Key artefacts

• Model cards and Annex IV technical documentation;
• Validation reports with challenge notes;
• Conformity declarations and registration evidence;
• Monitoring dashboards and incident log.

Your AI estate is mostly other people's software: procurement gates, contract machinery and concentration risk.

Purpose of the pillar

For most organisations, the majority of AI exposure arrives through vendors: SaaS platforms embedding models, GPAI APIs, AI-enabled services. Article 25 of the AI Act distributes obligations across the value chain, but accountability for your deployment stays with you.

Components

1. Procurement gates

AI disclosure mandatory in RFPs; no contract without classification of the AI involved; GPAI compliance evidence (documentation, training-data summary, copyright policy) as standard procurement requirements.

2. Contract machinery

Documentation and information access; substantial-modification notification; incident reporting flows with defined clocks; audit rights; liability and indemnities; exit and continuity provisions.

3. Role-boundary management

Clear determination per system: are we deployer, or have we drifted into provider territory (trademark, substantial modification, repurposing)? The most expensive surprise in the Act.

4. Vendor monitoring

Tracking vendor model updates, conformity status, incidents and financial/operational health for critical AI dependencies; concentration analysis (how many critical processes ride on one GPAI provider?).

5. Shadow-AI discovery

Periodic scans: procurement records, expense data, network traffic, SSO logs, finding the AI nobody registered.

Key artefacts

• AI-specific contract clause library;
• Vendor AI assessments and evidence files;
• Third-party AI register with role determinations;
• Concentration-risk report for critical dependencies.

The human operating system: AI literacy, psychological safety to escalate, and governance as a shared reflex.

Purpose of the pillar

Culture determines whether the other seven pillars operate on Monday morning when nobody from the governance office is watching. It is also the only pillar with its own explicit legal duty: Article 4's AI-literacy obligation.

Components

1. Role-based AI literacy

The four-layer training architecture (awareness → practitioner → certified oversight → executive), evidenced with completion records, assessments and refresh cycles.

2. Speak-up & escalation culture

People must be able to raise AI concerns, biased outputs, uncomfortable use cases, near-misses, without career risk. Near-miss reporting is the cheapest risk intelligence you will ever get.

3. Incentive alignment

Governance duties in objectives and evaluations; recognition for good escalation and documentation; consequences for circumvention. What gets rewarded gets repeated.

4. Leadership signalling

Executives visibly using the process for their own AI initiatives; board members completing literacy sessions; "how did governance improve this?" stories in internal comms.

5. Community of practice

Champions network, practitioner forums, lessons-learned circulation, governance knowledge flowing laterally, not just top-down.

Key artefacts

• Literacy curriculum map and completion records;
• Escalation statistics and near-miss log;
• Culture survey items on AI governance confidence;
• Community-of-practice calendar and outputs.

From ad-hoc to optimised: score each pillar honestly and find your true constraint.

Five levels

Score per pillar, not on average

The critical method rule: assess each of the eight pillars separately. An average score of "3" can hide a level-1 data pillar undermining everything. Your true maturity is your weakest load-bearing pillar, governance chains break at their weakest link.

Assessment questions per pillar (sample)

• Strategy: "Is there a board-approved AI risk appetite, and was it referenced in a real decision this year?"
• Structure: "Can we name the accountable owner of every system in the inventory?"
• Risk: "Do high-risk assessments include documented second-line challenge?"
• Policy: "When did a procedure last change because of an incident lesson?"
• Data: "Can we evidence representativeness analysis for high-risk training data?"
• Lifecycle: "Are monitoring alerts wired to an incident process with regulatory clocks?"
• Vendor: "Do all critical AI contracts include modification notification and audit rights?"
• Culture: "How many AI concerns were escalated last quarter, and is anyone worried it's too few?"

Ninety days to a defensible baseline: the minimum viable blueprint every organisation can execute now.

The philosophy: defensible baseline first

Perfection is a multi-year project; a defensible baseline is a 90-day sprint. The quick start delivers the five artefacts a supervisor, board or journalist would ask for first, and the machinery to keep them current.

Days 1–30: See and assign

1. Appoint the accountable executive (day 1, everything else waits on this);
2. Run the discovery sweep: procurement records, CMDB, SSO/app logs, interviews, produce inventory v1;
3. Prohibited-practice screen across the inventory (Article 5, already in force);
4. Shadow-AI containment: acceptable-use policy + sanctioned enterprise GenAI alternative;
5. Convene the governance committee with a signed one-page charter.

Days 31–60: Classify and control

6. Classify the inventory with the standard decision tree; legal sign-off on borderline cases;
7. Publish AI policy v1 (10 pages max), classification, tier controls, intake gate;
8. Stand up intake: one form, embedded in procurement and project channels;
9. Assign owners to every system; assign oversight persons to high-risk candidates;
10. Launch literacy layer 1 (all-staff awareness) with completion tracking.

Days 61–90: Prove and plan

11. Gap-assess high-risk systems against Articles 8–15; build the conformity roadmap to Aug 2026;
12. Fix priority contracts: top-10 vendor AI contracts get the clause library applied;
13. Write the incident runbook with regulatory clocks; run a tabletop exercise;
14. Deliver the first board report: inventory, exposure, quick-start results, 12-month plan;
15. Evidence drill: produce a complete file for one random system in 24 hours, fix what failed.

Quarter by quarter: the full blueprint build from baseline to measured operation.

Quarter 1, Foundation (pillars 1, 2, 4)

• 90-day quick start executed (see previous page);
• Board approves ambition statement and risk appetite;
• Policy v1 published; standards drafting begins;
• Committee rhythm established; champion cohort 1 recruited.

Quarter 2, Control core (pillars 3, 5, 6)

• Risk taxonomy and assessment methodology approved;
• High-risk assessments executed with second-line challenge;
• Data-governance standard live; datasheets for high-risk datasets;
• Validation process operating; release gates enforced in SDLC;
• Champion cohort 1 certified; intake SLA measured.

Quarter 3, Extended estate (pillars 6, 7, 8)

• Monitoring dashboards live for high-risk systems; incident runbook tested;
• Vendor clause library deployed; top-quartile contracts remediated;
• Concentration-risk analysis for GPAI dependencies;
• Literacy layers 2–3 rolled out (practitioner + oversight certification);
• Tooling decision executed; inventory migrated to platform.

Quarter 4, Measured operation (all pillars)

• KPI/KRI dashboard with targets; first annual board deep-dive;
• Conformity assessments underway for the high-risk portfolio;
• Independent (3rd-line or external) review of the governance system;
• Maturity reassessment; policy v2 incorporating lessons;
• Year-2 roadmap: depth where maturity is weakest.

Resource envelope (typical mid-large enterprise)

The working documents that operationalise the blueprint, what each artefact must contain.

Governance charters

• Executive mandate letter, scope, authority, budget, board access, review date;
• Committee charter, purpose, composition, cadence, quorum, decision rights, minute standards;
• Champion role description, selection criteria, protected time, certification, dotted-line terms.

Classification & assessment

• Classification decision tree, Article 5 screen → Annex I/III → carve-outs → transparency tier, with legal sign-off points;
• High-risk assessment template, taxonomy-based risks, affected persons, mitigations, residual-risk acceptance block;
• FRIA/DPIA integrated template, shared sections once, regime-specific sections clearly separated.

Lifecycle artefacts

• Model card template, purpose, data, performance, fairness, limitations, oversight, contacts;
• Annex IV documentation skeleton, the seven requirement areas pre-structured;
• Release-gate checklist, documentation, logging, oversight training, transparency, registration, worker notification;
• Incident runbook, severity matrix, regulatory clocks (2/10/15 days), suspension authority, communication tree;
• Retirement checklist, retention, deregistration, contract closure, lessons learned.

Vendor artefacts

• AI clause library, documentation access, modification notification, incident flows, audit rights, liability, exit;
• Vendor AI assessment questionnaire, conformity status, GPAI evidence, subprocessors, data usage;
• Role-determination worksheet, deployer vs provider analysis per contract.

Reporting artefacts

• Board quarterly pack skeleton, posture, risk, operations, horizon;
• Supervisory evidence pack, the 24-hour file: inventory extract, classification, assessments, minutes, training records, incident log.

From blueprint to building: how to turn eight pillars into your organisation's working governance system.

The blueprint is a promise of completeness

The value of a reference architecture is not any single pillar, every pillar exists somewhere in the literature. The value is the system property: eight pillars, no gaps, explicit owners, demonstrable operation. When the board asks "is our AI governed?", the blueprint lets you answer with structure instead of hope.

Your next ninety days, compressed

1. Score yourself on the maturity model, eight pillar scores, no averaging;
2. Appoint the accountable executive if one doesn't exist;
3. Run the discovery sweep and prohibited-practice screen;
4. Launch the 90-day quick start toward the defensible baseline;
5. Commit the 12-month plan anchored to August 2026 high-risk conformity.

The series in context

• Whitepaper 1, EU AI Act Governance: the legal requirements the blueprint implements;
• Whitepaper 2, Governance Roles & Skillz: staffing pillars 2 and 8;
• Whitepaper 3, AI Governance Operating Model: the deep design of pillars 2, 4 and 6;
• Whitepaper 5, AI Readiness Scan: the assessment instrument that operationalises the maturity model.

You can't govern what you haven't measured: the scan that baselines AI readiness and turns it into an actionable roadmap.

The starting question

Every AI governance journey begins with the same deceptively simple question: where are we today? Not where the policy says we are, not where last year's strategy deck claims we are, where we actually are, measured honestly across the dimensions that determine whether AI adoption will create value or exposure.

The AI Readiness Scan answers it: a structured, six-dimension assessment that scores your organisation's AI readiness, benchmarks it against peers, and converts the result into a prioritised roadmap. It is the diagnostic that makes the other four whitepapers in this series actionable.

What this whitepaper gives you

• The case for assessment, why scans precede strategy (page 2);
• The methodology, how a rigorous scan is designed and run (page 3);
• Deep-dives on all six dimensions, what to look for and what good looks like (pages 4–9);
• The scoring model, maturity levels and weighting (page 10);
• A 60-question sample instrument you can adapt (page 11);
• Interpretation guidance, reading profiles, not averages (page 12);
• The bridge from score to roadmap (page 13);
• Benchmarking and re-assessment practice (page 14).

Who should read this

Executives commissioning a readiness baseline; CAIOs and governance leads preparing their roadmap; transformation and strategy teams; and assessors running scans for clients.

The five triggers that make assessment the right first move, and the cost of skipping it.

Trigger 1, Before strategy

AI strategies built without a readiness baseline are fiction: they assume data that isn't there, skills nobody has, and governance that doesn't exist. The scan replaces assumptions with facts, so the strategy is a plan rather than a wish.

Trigger 2, Before regulation bites

With the EU AI Act's high-risk regime applying from August 2026, organisations need to know their exposure now: what AI they run, which of it is high-risk, and how far current practice is from conformity. A scan with a regulatory lens is the fastest way to quantify that gap.

Trigger 3, Before scale

Pilots forgive weak foundations; production at scale does not. Organisations moving from experimentation to enterprise deployment need to know whether their data, platform, people and governance can carry the load.

Trigger 4, After an incident or near-miss

A biased output, a data leak into a public chatbot, a failed model in production: incidents reveal that something was unmeasured. The scan finds the other things that are unmeasured before they find you.

Trigger 5, As periodic hygiene

Mature organisations scan annually: readiness decays as technology, regulation and the organisation change. The re-scan is also the proof of progress that justifies governance investment to the board.

The cost of skipping assessment

• Misallocated investment, spending on platforms when the gap is data quality, or on hiring when the gap is decision rights;
• Invisible exposure, high-risk systems running unclassified, prohibited-adjacent practices undiscovered;
• Unprovable progress, no baseline means no demonstrated improvement, to boards or supervisors;
• Strategy whiplash, plans rewritten as hidden constraints surface mid-execution.

How a rigorous scan is designed: evidence-based, interview-rich, and sized to the organisation.

Design principles

1. Evidence over opinion

Every maturity claim must be backed by an artefact: an inventory extract, an assessment record, a training completion report, a dashboard. "We do risk assessments" scores on what's shown, not what's asserted.

2. Triangulation

Three lenses per question: documentation review, structured interviews, and artefact sampling. When the policy says one thing, the interview says another, and the artefact shows a third, the artefact wins.

3. Multi-level input

Board/executive interviews, governance-function deep-dives, business-unit practitioner sessions and front-line sampling. Readiness looks different from each altitude; the scan captures all of them.

4. Proportionate depth

Scan intensity scales with AI exposure: a financial-services firm running credit models needs deeper governance and lifecycle examination than a manufacturer with three chatbots.

The four-phase scan process

1. Scope & prepare (week 1): define scan boundaries, gather documentation, select interviewees, tailor the instrument;
2. Collect (weeks 2–3): documentation review, 15–30 interviews, artefact sampling, optionally an all-staff pulse survey;
3. Score & analyse (week 4): dimension scoring, evidence calibration, profile construction, gap analysis;
4. Report & roadmap (weeks 5–6): findings, benchmark position, prioritised roadmap, executive readout and board summary.

Inputs checklist

• AI inventory (or its absence, a finding in itself);
• Policies, standards, committee charters and minutes;
• Risk assessments, DPIAs/FRIAs, validation reports;
• Training curricula and completion records;
• Incident log and monitoring dashboards;
• Vendor contracts for critical AI dependencies;
• Strategy documents and board reporting.

Is AI direction real? Ambition, portfolio, value tracking and the risk appetite that guides it all.

What this dimension measures

Whether the organisation knows why it uses AI, where it is placing bets, and what it will not do. Strategy readiness is the difference between a portfolio and a pile of pilots.

Assessment areas

1. Ambition & direction

Is there an articulated AI ambition, endorsed at executive level, that connects AI to business strategy? Is it specific (domains, value pools) or generic ("we will leverage AI")?

2. Use-case portfolio

Is there a managed portfolio: an overview of all initiatives with value hypotheses, risk tiers and stage? Are kill decisions actually made, or do pilots live forever?

3. Value realisation

Are benefits defined before build and measured after deployment? Can leadership name the three most valuable AI systems and quantify their contribution?

4. Risk appetite & red lines

Has the board articulated what AI risk is acceptable, and what is off-limits regardless of legality? Is appetite referenced in actual approval decisions?

5. Investment alignment

Does funding match stated ambition, including the unglamorous parts: data foundations, governance capacity, training?

Maturity indicators

The control core: inventory, classification, decision rights, lifecycle control and regulatory readiness.

What this dimension measures

Whether the organisation can see its AI estate, control it, and demonstrate that control, the dimensions the EU AI Act, ISO 42001 and every serious audit probe directly.

Assessment areas

1. Visibility

Complete AI inventory? Including vendor-embedded and shadow AI? Verified by discovery methods, or self-reported only?

2. Classification & regulatory mapping

Is every system classified against the AI Act's tiers with documented rationale? Prohibited-practice screen performed? Provider/deployer roles determined?

3. Structure & decision rights

Accountable executive? Committee with charter? Risk-tiered decision rights with SLAs? A signed RACI?

4. Risk management operation

Assessments with second-line challenge? FRIA/DPIA integration? Residual-risk acceptance at proper authority? AI risks in the enterprise register?

5. Lifecycle control

Release gates enforced? Monitoring owners named? Incident runbook with regulatory clocks tested? Re-classification on change?

6. Evidence capability

Can the organisation produce a supervisory-grade file for any system in 24 hours?

Maturity indicators

The make-or-break dimension: availability, quality, provenance, representativeness and privacy of AI data.

What this dimension measures

Whether the data foundations can support the AI ambitions on top of them. Data is the most common binding constraint on AI readiness, and the least fixable by budget alone.

Assessment areas

1. Availability & access

Can teams find and access the data AI use cases need, or is it locked in silos, spreadsheets and tribal knowledge? Are there catalogued, documented datasets?

2. Quality management

Are accuracy, completeness and consistency measured for critical datasets? Do data-quality issues surface through monitoring or through angry users?

3. Provenance & lineage

Can training-data origins, rights and transformations be documented for AI systems, the Article 10 requirement in practice?

4. Representativeness & bias

Is training data examined for representativeness against the deployment population? Are bias analyses performed and acted on?

5. Privacy & lawful use

Lawful bases established for AI data flows? Minimisation and retention applied? Are the hard questions (subject rights vs trained models) addressed rather than avoided?

6. Data operations for AI

Labelling quality, synthetic-data governance, drift monitoring on input distributions.

Maturity indicators

The platform question: can your architecture build, run, monitor and secure AI at the scale you're planning?

What this dimension measures

Whether the technical estate supports governed AI in production: platforms, pipelines, environments, observability and security, for classical ML and generative AI alike.

Assessment areas

1. Development platform

Standardised environments for experimentation and training? Reproducible pipelines? Version control for data, code and models?

2. Production & operations

Reliable deployment paths (CI/CD for models)? Rollback capability? Environment separation? Capacity for GenAI workloads where relevant?

3. Observability

Monitoring of model performance, drift and usage in production? Alerting wired to owners? Logging that satisfies regulatory record-keeping?

4. Security

AI-specific threat coverage: prompt injection, data poisoning, model theft, adversarial inputs? Red-teaming for high-risk and GenAI systems? Secrets and access management?

5. Integration & architecture

Reference architectures? Reusable components (evaluation harnesses, guardrails, documentation generators)? Integration with the governance workflow tooling?

6. Vendor & cloud strategy

Deliberate build/buy/host choices? Portability and exit options for critical dependencies? EU data-residency considerations handled?

Maturity indicators

The scarce dimension: roles filled, competencies mapped, literacy evidenced and oversight staffed.

What this dimension measures

Whether the organisation has, or can grow, the human capability its AI ambition requires: builders, governors, overseers and a literate workforce. (The deep role-by-role treatment is Whitepaper 2; here the assessment lens.)

Assessment areas

1. Key roles filled

Accountable executive? Governance lead? Validation capacity? Oversight persons per high-risk system? Or a single overloaded "AI person"?

2. Competency coverage

Is there a skills framework mapping the eight competency domains (technical, data, evaluation, security, legal, risk judgement, challenge, communication) against roles? Where are the gaps?

3. AI literacy operation

Role-based curriculum? Completion tracking? Assessment of effectiveness? The Article 4 evidence trail, produceable in an hour?

4. Talent pipeline

Deliberate build/buy/borrow strategy for scarce skills? Retention risk for key AI staff? Community of practice transferring knowledge?

5. Incentive alignment

Do governance duties appear in objectives and evaluations? Is good escalation rewarded? Is circumvention consequential?

Maturity indicators

The invisible dimension that decides everything: psychological safety, adoption dynamics and change capability.

What this dimension measures

Whether the organisation's culture will execute what its strategy and governance design: do people trust AI appropriately, escalate concerns, follow processes, and adapt to AI-driven change?

Assessment areas

1. Calibrated trust

Neither blind trust ("the AI said so") nor blanket rejection, do teams understand what their AI can and cannot do? Are outputs checked proportionately to stakes?

2. Speak-up & escalation

Do people raise AI concerns? Are near-misses reported and thanked? What happened to the last person who escalated, promoted or sidelined?

3. Process adherence

Is the intake gate used or routed around? What do shadow-AI discovery scans find? Circumvention is a culture metric, not just a compliance one.

4. Change capability

Does the organisation have the change machinery for AI-driven workflow transformation: communication, involvement, reskilling, works-council partnership?

5. Leadership signalling

Do executives visibly follow their own AI rules? Is governance framed as quality and trust, or as tax and delay?

Measurement approach

Culture is measured differently from the other dimensions: a short pulse survey (trust calibration, escalation comfort, process perception), interview probes ("tell me about the last AI concern raised here"), and behavioural data (escalation volumes, circumvention discoveries, training engagement).

Maturity indicators

How answers become numbers: the five-level scale, dimension weighting and the rules that keep scores honest.

The five-level scale

Each assessment area is scored on the shared maturity scale:

Scoring rules

1. Evidence-anchored: no score above 2 without an artefact; no score above 3 without demonstrated operation across the organisation, not just pilot areas;
2. Half-point granularity: scores like 2.5 allowed for "operating in most units, evidenced in some";
3. Consensus calibration: assessor + accountable owner must agree each score, with disagreement recorded;
4. Weakest-link flagging: any assessment area below 2 in a dimension flags the dimension, regardless of the dimension average.

Dimension weighting

Default: all six dimensions weighted equally. Adjust deliberately, and document why, e.g., a regulated financial institution may weight Governance & Risk at 1.5×; a data-platform company may weight Data at 1.5×. Never adjust weights to improve the score.

Overall readiness bands

A ready-to-adapt question set: ten questions per dimension, phrased for evidence-based scoring.

How to use this instrument

Ten core questions per dimension. Each is scored 1–5 using the evidence-anchored scale from the previous page. Tailor phrasing to your context, but keep the evidence demand.

Dimension 1, Strategy & Vision

1. Is there a current, executive-endorsed AI ambition statement linked to business strategy?
2. Is there a complete portfolio of AI initiatives with owners, stages and value hypotheses?
3. Are benefits defined pre-build and measured post-deployment?
4. Has the board articulated an AI risk appetite?
5. Are ethical red lines documented and have they been applied?
6. Are kill/scale decisions made on portfolio reviews, with examples?
7. Does investment match stated ambition, including governance and data?
8. Is there a strategy for GenAI specifically (build/buy/govern)?
9. Are strategic dependencies on single AI vendors assessed?
10. Is the strategy revisited at defined intervals with portfolio data?

Dimension 2, Governance & Risk

1. Is there a complete, current AI inventory, verified beyond self-reporting?
2. Is every system classified against the AI Act with documented rationale?
3. Has a prohibited-practice screen been performed and recorded?
4. Is one named executive accountable for AI governance?
5. Do written decision rights with SLAs govern approvals by tier?
6. Do high-risk assessments receive documented second-line challenge?
7. Are FRIA/DPIA workflows integrated where applicable?
8. Is there a tested AI incident runbook with regulatory clocks?
9. Can supervisory-grade evidence be produced per system within 24 hours?
10. Does the board receive quarterly AI governance reporting?

Dimension 3, Data

1. Can teams discover and access needed datasets via a catalogue?
2. Is data quality measured for datasets feeding AI systems?
3. Is training-data provenance documented for high-risk systems?
4. Is representativeness analysed against deployment populations?
5. Are bias examinations performed and acted on?
6. Are lawful bases established for AI data processing?
7. Is input drift monitored in production?
8. Is labelling quality managed with defined standards?
9. Are rights verified for external/licensed training data?
10. Are data-retention rules applied to AI datasets and logs?

Dimension 4, Technology

1. Are standardised development and training environments provided?
2. Are data, code and models versioned in reproducible pipelines?
3. Is there a gated deployment path with rollback for AI systems?
4. Is production monitoring (performance, drift, usage) implemented and owned?
5. Is AI-specific security testing (injection, poisoning, evasion) performed?
6. Are logs retained to meet regulatory record-keeping duties?
7. Do governance checks integrate into CI/CD or release workflows?
8. Are reference architectures and reusable governance components available?
9. Is there a deliberate cloud/residency strategy for AI workloads?
10. Are evaluation harnesses and guardrails standard for GenAI deployments?

Dimension 5, People

1. Is the accountable AI executive role filled with mandate and budget?
2. Is second-line governance/validation capacity in place?
3. Are human-oversight persons assigned, trained and authorised per high-risk system?
4. Is there a competency framework mapping skills to AI roles?
5. Does a role-based AI literacy programme operate with completion records?
6. Is training effectiveness assessed (not just completion)?
7. Is there a build/buy/borrow strategy for scarce AI skills?
8. Do governance duties appear in objectives and evaluations?
9. Is succession planned for critical AI and governance roles?
10. Is there an active AI community of practice?

Dimension 6, Culture

1. Do teams demonstrate calibrated trust, checking AI outputs proportionately?
2. Are AI concerns and near-misses reported, and is volume healthy?
3. Was the last escalation handled visibly well?
4. Do discovery scans find little unregistered shadow AI?
5. Is the intake gate used rather than routed around?
6. Is there change-management capability for AI-driven workflow change?
7. Are works-council/employee-representative relationships proactive?
8. Do executives visibly follow AI governance processes themselves?
9. Is governance framed internally as quality and trust?
10. Is AI culture measured through surveys or behavioural data?

From scores to insight: reading the profile, spotting the archetypes and finding the real constraint.

Read the profile, not the number

The dimension profile is the diagnostic surface. Plot the six dimension scores, mark weakest-link flags, and compare against your ambition: the gap between where a dimension is and where your strategy needs it to be is the roadmap.

The five common archetypes

1. The Pioneer (Strategy 4, Governance 1.5)

Bold adoption, weak control. High incident and regulatory exposure. Move: 90-day governance quick start before anything else scales.

2. The Fortress (Governance 3.5, Strategy 1.5)

Heavy control, thin adoption, often post-incident or in cautious sectors. Move: rebuild portfolio ambition; use governance strength as the scaling enabler it should be.

3. The Sandcastle (Strategy 3, Data 1.5)

Real ambition on unready data. Pilots demo well and die in production. Move: redirect investment to data foundations; re-sequence the portfolio to data-ready use cases.

4. The Key-Person Dependency (People 1.5, others 2.5–3)

Everything works because of three people. One resignation from crisis. Move: succession, documentation, distribution of knowledge, champion programme.

5. The Silent Organisation (Culture 1.5, decent elsewhere)

Structures exist; nobody uses them; shadow AI thrives. Move: leadership signalling, incentive alignment, escalation celebration, culture work, not more process.

Calibration checks

• Compare interview claims against artefact samples, divergence is a finding;
• Compare executive perception vs practitioner perception per dimension, a gap >1 level signals communication failure;
• Compare against the shadow-AI discovery results, governance scores above 3 with heavy shadow AI are inconsistent.

Converting assessment into action: prioritisation logic, quick wins and the sequencing that respects dependencies.

The prioritisation logic

Not all gaps are equal. Prioritise on three axes:

1. Risk urgency, regulatory deadlines (August 2026 high-risk conformity), active exposure (unclassified high-risk systems, prohibited-adjacent practices), single points of failure;
2. Dependency order, inventory before classification; classification before conformity; data foundations before data-hungry use cases; roles before processes;
3. Leverage, actions that unlock multiple downstream improvements (the intake gate, the literacy programme, the clause library).

The standard roadmap skeleton

Horizon 1, Stabilise (0–3 months)

• Close any prohibited-practice and classification gaps;
• Appoint/account for the accountable executive; stand up the committee;
• Contain shadow AI: acceptable-use policy + sanctioned alternative;
• Launch literacy layer 1; assign oversight persons;
• Fix the top-10 vendor contracts.

Horizon 2, Operationalise (3–9 months)

• Embed intake and release gates; activate monitoring and incident machinery;
• Execute the high-risk conformity programme;
• Address the binding-constraint dimension (typically Data or People);
• Champion certification; tooling rollout.

Horizon 3, Optimise (9–18 months)

• Measurement layer with targets; evidence drills;
• Independent assurance; maturity re-scan;
• Automation of governance workflows; culture measurement.

Roadmap quality tests

• Every action has an owner, a date and a deliverable artefact;
• Dependencies respected (no conformity before classification);
• The binding constraint is explicitly addressed, not deferred;
• Quick wins in the first 90 days to build political capital;
• A re-scan date is set before the roadmap is approved.

Context for your score: peer comparison, sector patterns and the discipline of periodic re-measurement.

Why benchmark

A 2.4 means little in isolation. Against a peer median of 2.8 it is a call to arms; against a sector median of 1.9 it is a leadership position worth protecting. Benchmarks give the board context and give the roadmap urgency calibration.

Typical sector patterns (indicative)

Re-assessment discipline

• Cadence: full scan every 12 months; light-touch pulse (top-20 questions) at 6 months;
• Consistency: keep the core instrument stable so deltas are real; version additions separately;
• Independence rotation: alternate internal and external facilitation to balance cost and calibration;
• Delta analysis: report movement per dimension with causal attribution, what action moved what score;
• Target-setting: the board sets the next-period target profile; the scan measures arrival.

Using scores externally

Mature organisations increasingly deploy readiness evidence outward: supervisory dialogue, client due-diligence questionnaires, insurance negotiations, and investor ESG conversations. A credible, recent, independently-facilitated scan is becoming a trust asset in its own right.

Measure, move, re-measure: the scan as the heartbeat of your AI governance journey.

The scan is the heartbeat

AI governance is not a project with an end date, it is a permanent capability. The Readiness Scan is its heartbeat: the recurring, honest measurement that tells leadership where the organisation truly stands, where the constraint now sits, and whether the last year's investment actually moved anything. Organisations that measure, move and re-measure compound their readiness. Those that guess, drift.

Your immediate next steps

1. Decide the scope and independence level, internal first pass or externally facilitated baseline;
2. Assemble the inputs, inventory, policies, assessments, training records, incident logs;
3. Run the scan, 60 questions, six dimensions, evidence-anchored scoring;
4. Read the profile, find the archetype, name the binding constraint;
5. Commit the roadmap, three horizons, owned actions, re-scan date fixed;
6. Report to the board, exposure, position, plan, and the target profile for next year.

The complete series

• Whitepaper 1, EU AI Act Governance: what the law demands;
• Whitepaper 2, Governance Roles & Skillz: who must deliver it;
• Whitepaper 3, AI Governance Operating Model: the structure that scales it;
• Whitepaper 4, AI Governance Blueprint: the architecture that completes it;
• Whitepaper 5, AI Readiness Scan: the measurement that drives it, this document.