AI Governance Guide for UK Organisations

This guide gives UK organisations a practical, step-by-step approach to building an AI governance framework that satisfies board-level accountability requirements, meets current and upcoming regulatory obligations, and can be demonstrated to auditors, insurers, and counterparties. It is not legal advice. For your specific circumstances, seek qualified legal counsel and a professional governance assessment.

Why AI governance matters now

AI governance is no longer a future consideration for UK organisations. Several converging pressures make it an immediate operational and legal requirement:

• EU AI Act (Regulation 2024/1689) applies to any organisation deploying AI systems that affect EU persons — which includes most UK organisations with EU customers, staff, or partners. High-risk AI systems face conformity assessment obligations, and prohibited systems must be identified and decommissioned. The Act is in phased enforcement, with prohibitions from February 2025 and high-risk obligations building through 2026–2027.
• UK GDPR and the Data Protection Act 2018 already impose obligations where AI systems make automated decisions about individuals (Article 22), process special category data, or carry out profiling. The ICO has published specific AI guidance.
• ISO/IEC 42001:2023 provides an internationally recognised standard for AI management systems, increasingly required in supplier questionnaires and enterprise procurement.
• FCA, PRA, and sector regulators have published or are developing AI-specific guidance for financial services, healthcare, and other regulated sectors.
• Board liability for AI-related harm is increasing. Directors who cannot demonstrate active governance oversight of AI risk face personal and corporate reputational and legal exposure.

Step 1 — AI system inventory

Many organisations underestimate the breadth of their AI estate. AI is embedded in SaaS tools (CRMs, HR platforms, email filtering), third-party APIs, internal ML models, cloud services, and now increasingly in agentic AI tools used informally by staff. Your inventory must capture all of these.

What your AI register should capture

• System name and description — what it does and how it is used
• Type — LLM, ML classifier, recommendation engine, computer vision, NLP, AI agent, generative AI, etc.
• Deployment context — internal tool, customer-facing, automated decision-making, advisory/support
• Data inputs — what personal data or sensitive data does it process?
• Outputs and consequences — what decisions or actions does it influence or make?
• Affected persons — employees, customers, third parties, vulnerable populations?
• System owner — named accountable individual
• Supplier / third-party involvement — is this a vendor-supplied model or API?
• Date deployed and date last reviewed
• Regulatory classification — EU AI Act risk tier (prohibited, high-risk, limited, minimal)

Step 2 — Risk classification

For each AI system in your register, apply a structured risk classification. The EU AI Act provides the most developed regulatory framework for this and is a useful baseline regardless of whether the Act directly applies to you.

EU AI Act risk tiers (summary)

• Prohibited (Article 5): AI systems that pose unacceptable risks — social scoring by public authorities, real-time biometric surveillance in public spaces, manipulation of vulnerable groups. These must be identified and decommissioned.
• High-risk (Annex III): AI used in: critical infrastructure, educational/vocational assessment, employment decisions (CV screening, performance monitoring), essential private and public services (credit scoring, benefits assessment), law enforcement, migration management, justice administration, and AI in safety components of regulated products. These face the most extensive obligations.
• Limited risk: AI systems with specific transparency obligations — chatbots must identify themselves as AI, deepfake content must be labelled.
• Minimal risk: Spam filters, AI in video games, etc. No additional regulatory requirements, but still subject to your own governance standards.

In addition to the EU AI Act tiers, assess each system for: data protection impact (UK GDPR DPIA triggers), business criticality, reputational risk, and sector-specific regulatory requirements.

Step 3 — Governance framework design

A minimum viable AI governance framework for a UK organisation should include:

• AI Use Policy: Defines permitted and prohibited uses of AI by employees, covering personal data handling, output verification, prohibited categories, and escalation procedures for edge cases.
• AI Risk Register: Live document capturing assessed risks for each system, with likelihood/impact ratings, existing controls, residual risk, and review schedule.
• AI System Register: The inventory from Step 1, maintained as a live document with a named owner.
• Data Protection Impact Assessments (DPIAs): Required under UK GDPR for any AI processing that is likely to result in high risk to individuals. Must be completed before deployment.
• Procurement and Vendor Assessment: Standards for evaluating AI tools before adoption — see Step 6.
• Acceptable Use Guidelines: Employee-facing guidance (shorter and more practical than the formal policy) covering day-to-day AI tool use.
• AI Incident Response Plan: Procedures for identifying, containing, and reporting AI-related incidents — see Step 7.

Step 4 — Board and senior management accountability

Effective AI governance requires accountability to be assigned at senior management and board level, not delegated entirely to IT or data teams.

Accountability structure essentials

• Designated AI lead: A named senior individual (CISO, CTO, CDO, or equivalent) with formal responsibility for the AI governance programme and reporting line to the board.
• Board AI oversight: AI risk should appear on the board risk register and be reported on at least annually. For organisations with significant AI exposure, quarterly reporting is appropriate.
• System owners: Each AI system in the register should have a named individual owner responsible for its governance, DPIA, and compliance with applicable policies.
• Three lines of defence: Apply standard risk management structure — operational teams (first line), risk/governance function (second line), internal audit (third line) — to AI risk.

Step 5 — Human oversight and intervention capability

• Human review mechanisms: For AI systems influencing decisions about individuals, document how human review is carried out, who is responsible, and how decisions can be overridden.
• Kill switches and disable capability: All AI systems should be capable of being suspended without loss of core business function. Document shutdown procedures for each system.
• Staff awareness and capability: Staff operating or reviewing AI outputs must have sufficient training to meaningfully assess those outputs — "human in the loop" is meaningless if the human cannot evaluate what they are reviewing.
• Audit trails: Maintain logs of AI-influenced decisions sufficient to support challenge, review, and regulatory inquiry. Retention periods should align with your business context and legal obligations.
• UK GDPR Article 22: Where AI is used in fully automated decision-making producing legal or similarly significant effects on individuals, you must provide a mechanism for human intervention, and the right to contest the decision.

Step 6 — Vendor and third-party AI risk

Your organisation is responsible for AI systems it deploys even when they are provided by third parties. Key areas to assess for vendor-supplied AI:

• Model transparency: Can the vendor explain how the model works, what data it was trained on, and what bias testing has been conducted?
• Data processing: Is your data (including personal data) used to train the vendor's models? Is it shared with third parties?
• Contractual protections: Does your contract include appropriate AI-specific provisions covering accuracy, bias, data use, audit rights, and liability?
• EU AI Act compliance: For high-risk AI systems, providers should be able to supply EU AI Act technical documentation and a declaration of conformity (from August 2026).
• Security posture: What are the security controls around the vendor's AI infrastructure? Can they demonstrate compliance with relevant standards?
• Continuity and dependency: What is your contingency if the vendor changes, withdraws, or significantly modifies the AI system?

Step 7 — Incident management for AI

AI-specific incidents to plan for include:

• Biased or discriminatory output — systematic errors affecting protected characteristics
• Prompt injection attacks — adversarial inputs causing AI to act outside its intended scope
• Data exfiltration via AI systems — sensitive data leaking through model outputs or logs
• Model drift — performance degrading over time as real-world data diverges from training data
• AI impersonation — deepfakes, synthetic voice, or AI-generated content used in fraud or social engineering targeting your organisation
• Regulatory enforcement action — ICO investigation, EU AI Act supervisory authority inquiry

For each incident type, your AI incident response plan should specify: detection mechanisms, initial triage steps, escalation path (including board notification thresholds), containment actions, regulatory notification requirements (UK GDPR breach notification within 72 hours to the ICO where applicable), and post-incident review process.

Step 8 — Regulatory mapping