- Start with an inventory. You cannot govern what you have not catalogued. Shadow AI is widespread, and vendor AI is often enabled by default in tools you already pay for.
- Classify tools by the data they process and the decisions they influence. A low-risk AI tool and a high-risk one need different controls.
- An AI acceptable use policy does one job: tell staff what they can use, what data they cannot enter, and what review is required before acting on AI outputs.
- UK GDPR Article 22 restricts solely automated decisions with significant effects on individuals. HR screening tools, credit decisions, and insurance pricing can trigger this depending on how the decision is made and the degree of meaningful human involvement.
- Human oversight means a human who genuinely evaluates the AI output before a consequential decision is made. Rubber-stamping is not oversight.
- The EU AI Act may apply to UK organisations with EU customers or operations. High-risk AI obligations apply from December 2027.
- ISO 42001 certification is not necessary for most UK SMEs. Implementing its governance controls is.
What AI governance actually is
AI governance is the combination of policies, controls, and accountability structures that determine how your organisation uses AI tools, which data those tools can access, how AI-influenced decisions are made and reviewed, and who is responsible when something goes wrong.
It is not an ethics statement, an AI strategy document, or a list of principles. Those are starting points for conversations, not controls. Governance means specific rules that apply to specific tools, specific accountability for specific decisions, and a review process that actually runs.
Most UK organisations at the start of 2026 have none of this. They have staff using ChatGPT, Copilot, Gemini, and a dozen SaaS tools with AI features enabled, with no policy, no training, and no visibility into what data is being processed. The governance gap is not theoretical: it is a UK GDPR exposure, a reputational risk, and, for organisations with EU operations, an EU AI Act compliance question.
Establish ownership first
Before inventorying tools or writing policy, decide who is accountable for AI governance. Without a named owner and clear decision rights, the inventory does not get maintained, the policy does not get enforced, and incidents do not get escalated. In most UK organisations the structure looks like this:
| Role | AI governance responsibility |
|---|---|
| Board / Executive | Set risk appetite for AI use. Receive quarterly reporting on AI risk posture. Approve high-risk AI use cases. |
| AI Governance Owner (IT lead, DPO, or vCISO) | Maintain the AI tool register. Approve or reject new tool requests. Coordinate DPIA completion. Own the acceptable use policy. Report incidents upward. Run the review cadence. |
| DPO / Privacy | Lead DPIA assessments. Advise on Article 22 applicability. Review vendor DPAs. Handle subject access requests involving AI. |
| IT / Security | Assess AI tool security controls. Manage access permissions for enterprise AI tools. Detect shadow AI. Monitor for data exfiltration. Handle AI-related security incidents. |
| Legal / Compliance | Review AI-related vendor contracts. Advise on sector-specific regulatory obligations. Track EU AI Act developments for relevant use cases. |
| Business / Department Owners | Own AI tool use cases within their function. Ensure staff follow the acceptable use policy. Escalate new AI tool requests through the formal approval process. Own human oversight within their workflows. |
| End Users | Follow the acceptable use policy. Use only approved tools. Report incidents and shadow AI use. Complete AI awareness training. |
In a smaller organisation, several of these roles will sit with the same person. That is fine. What matters is that the responsibilities are explicitly assigned, not that each has a dedicated headcount. A 50-person business with a named AI governance owner, a defined escalation path, and a quarterly review meeting has more functional governance than a large organisation with a governance framework document and no one running it.
Step 1: Map what you are already using
Before writing a policy, find out what AI tools are in use. Most organisations find more than expected when they look properly.
Four categories to check
Survey department heads and run a discovery pass across your SaaS estate. The shadow AI risks guide covers the discovery process in more detail. The inventory becomes your control baseline: every tool on it either has a governance record or gets one before it stays approved.
AI tool register: minimum fields
Record each AI tool in a central register. This becomes the living record that your AI governance owner maintains and your auditors or regulators can inspect.
| Field | Example |
|---|---|
| AI tool | Microsoft 365 Copilot |
| Business owner | Head of Marketing |
| Purpose | Content drafting, email summarisation |
| Data processed | Internal business data, employee emails |
| Personal data involved | Yes |
| Vendor | Microsoft |
| Data processing / hosting location | UK / EU |
| DPA in place | Yes, via Microsoft Data Processing Agreement |
| Risk level | Medium |
| DPIA required | Yes, completed 24 Aug 2026 |
| Article 22 assessment | Not applicable (advisory use only, human review required) |
| Approved users | Marketing, Sales (licensed users only) |
| Approval date | 24 Aug 2026 |
| Next review date | 24 Feb 2027 |
Keep the register in a location your AI governance owner and DPO can both access and update. A shared document or a row in your existing risk register works. The format matters less than the discipline of keeping it current.
Step 2: Classify tools by risk
Not every AI tool needs the same level of control. A grammar checker and a CV screening system are both AI, but the governance requirement for each is completely different. The classification framework below uses two axes: what data the tool processes, and what decisions it influences.
Additional classification dimensions
Beyond the three tiers above, four additional dimensions refine the classification and identify where enhanced controls are needed:
- Autonomy level: is the AI purely assistive (draft text for a human to review), advisory (recommends an action), semi-automated (requires human approval to proceed), or fully automated (acts without human intervention)?
- External exposure: does the AI process or produce output that goes to customers, partners, or the public, or does it stay entirely internal?
- Regulatory exposure: does the use case fall under a sector-specific regime such as FCA, NHS DSP Toolkit, DORA, or the EU AI Act for organisations with EU operations?
- Data sensitivity: public and non-personal data, internal business data, personal data, confidential or legally privileged material, or special category data such as health or biometric information?
A tool that scores medium on the primary risk tier but also involves full automation, customer-facing outputs, and special category data should be treated as high risk in practice. Use the dimensions to sense-check the primary classification rather than override it mechanically.
Step 3: Write an AI acceptable use policy
An AI acceptable use policy sets the rules staff follow when using AI tools at work. It does not need to be long. A policy that staff can read in five minutes and apply without asking for clarification is more valuable than a comprehensive document that no one reads.
What to include
Assign a named owner for the policy and set a review date. Given how fast AI capabilities and vendor terms change, a six-month review cycle is more useful than an annual one.
Employees may only use AI tools approved by the organisation. Confidential, personal, customer, financial, legal, or otherwise restricted information must not be entered into any AI system unless the tool and use case have been explicitly approved. AI-generated content must be reviewed by an appropriately authorised employee before being used in consequential decisions or external communications.
Step 4: UK GDPR obligations
UK GDPR applies to any AI processing that involves personal data. The obligations that most commonly arise in practice are:
Individuals have the right not to be subject to a decision based solely on automated processing if that decision produces a legal or similarly significant effect on them. If an AI system makes solely automated decisions about job applicants, creditworthiness, insurance eligibility, or benefit entitlement without meaningful human intervention, Article 22 may apply. Meaningful human review must genuinely influence the outcome: rubber-stamping an AI recommendation does not satisfy the requirement. Article 22 has specific exceptions (explicit consent, contractual necessity, or statutory authorisation) that must be distinguished from the Article 6 lawful basis required for the underlying personal data processing. Both analyses are required separately. Document your assessment of whether Article 22 applies to each high-risk AI tool and retain that documentation.
A DPIA is required before processing that is likely to result in a high risk to individuals. The ICO's DPIA guidance lists AI processing that involves systematic profiling, special category data, automated decision-making with significant effects, or large-scale monitoring as likely to require a DPIA. Run a DPIA for every high-risk AI tool before deployment. For medium-risk tools, a DPIA is good practice even where not strictly required. See our AI DPIA requirements guide for a worked framework.
Processing personal data through an AI tool requires a lawful basis under Article 6, and special category data requires an additional condition under Article 9. Your privacy notices should tell individuals when AI significantly processes their data. If you are using AI tools that process employee data, update your staff privacy notice. If you are processing customer data through AI, update your customer-facing privacy notice.
These are separate concepts assessed under different frameworks. A DPIA is required where processing is likely to result in a high risk to individuals under UK GDPR: a data-protection risk assessment. This is not the same as classifying an AI system as "high-risk" under the EU AI Act, which uses different criteria based on the application domain. A tool with a low EU AI Act risk classification may still require a DPIA under UK GDPR if it involves large-scale profiling, special category data, or automated decisions with significant effects on individuals.
International data transfers
Most generative AI vendors process data in the United States. Check your vendor's data processing agreement to confirm what transfer mechanism is in place: an adequacy decision, standard contractual clauses, or binding corporate rules. The ICO-approved international data transfer agreement (IDTA) is the UK-specific equivalent of EU standard contractual clauses for transfers from UK organisations. If your vendor only offers EU SCCs without a UK IDTA addendum, get clarification in writing before using the tool for personal data.
Step 5: Build human oversight into workflows
Human oversight is only meaningful when the person reviewing an AI output has the information and time to make a genuine judgment. A workflow where a manager clicks "approve" on an AI-generated HR assessment in under a minute is not oversight. It is a liability dressed as a process.
For each consequential workflow that uses AI, define:
- Who reviews the AI output and what their review should cover
- What information they need to make that judgment, including any context the AI did not have access to
- What they can change before the decision is recorded, and how changes are documented
- How the decision and the AI involvement are logged in case of a later challenge or audit
- Who the individual can contact to request human review of a decision that affected them
The log requirement is particularly important. If a recruitment decision or a credit application decision is challenged, you need to be able to demonstrate what the AI produced, what the reviewer changed, and who made the final call. Verbal processes leave you exposed.
For Microsoft 365 Copilot deployment, oversight is less about individual decisions and more about data access controls: which data Copilot can surface, who can see what, and whether overpermissioned SharePoint sites are visible to staff who should not have access to that content.
Step 6: Security controls for AI
AI tools introduce security risks that most existing controls were not designed to address. Governing AI without governing its security profile leaves a significant gap, particularly as organisations connect AI to internal data, APIs, and business processes.
Access control and least privilege
Enterprise AI tools, particularly those integrated with your Microsoft 365 environment, CRM, or file systems, surface data based on what the user can access. If your SharePoint permissions are overly broad, Copilot will surface documents the user should not see. Audit permissions in your connected systems before enabling AI tools that can query them. Apply least privilege: users should access only the data their role requires, not everything their account technically permits.
Prompt injection
Prompt injection is an attack in which malicious instructions embedded in content the AI processes cause it to take unintended actions or leak information. In customer-facing AI deployments: chatbots, AI-assisted email processing, document analysis: an attacker can craft input that overrides the system's instructions. Mitigations include output validation, sandboxed execution environments, limiting the AI's ability to take autonomous actions, and logging all inputs and outputs for review.
Data leakage and sensitive content in prompts
Staff routinely include more information in AI prompts than they intend. Credentials, personal data, client names, financial figures, and confidential strategy documents appear in prompts without the user considering where that data goes. Training reduces the frequency, but technical controls matter more: classify data at rest, restrict which data categories can be accessed by AI-enabled applications, and configure DLP policies to flag or block prompts containing sensitive patterns.
Shadow AI and unsanctioned integrations
Shadow AI is not a one-time discovery problem. New tools launch constantly, staff accounts change, and browser extensions accumulate. Periodic scanning of your SaaS estate, egress traffic analysis, and a clear reporting channel for staff to flag AI tools they want to use are all part of ongoing shadow AI management. Staff who cannot get a tool approved quickly will use it anyway and not tell anyone.
Supply chain and model risk
Foundation models powering commercial AI tools may be updated without notice, changing their behaviour, outputs, or data handling characteristics. AI plugins and third-party integrations extend trust to additional parties your original due diligence did not cover. Review the sub-processor list in vendor DPAs, monitor vendor release notes for material changes, and test AI output behaviour after significant model updates in critical workflows.
Logging and incident detection
Log AI tool usage: who used what, when, and with what data where possible. Logs enable incident investigation, satisfy audit requirements, and detect abnormal patterns such as unusual data volumes being processed or access from unexpected accounts. Ensure log retention aligns with your incident response and regulatory requirements, typically a minimum of 12 months.
Step 7: Vendor due diligence
Every AI tool your organisation uses involves a third-party vendor processing your data. The due diligence questions below apply to any new AI tool before approval, and should be revisited when a vendor makes significant changes to their terms or product.
| Question | Why it matters |
|---|---|
| Does the vendor train their models on customer data by default? | Many free-tier tools do. Business tiers typically offer an opt-out. Confirm it is off and get it in writing. |
| Where is data processed and stored? | Determines which transfer mechanism you need for UK GDPR compliance. EU-hosted does not automatically mean GDPR-compliant for UK transfers. |
| Who are the sub-processors? | Your vendor's AI infrastructure may run on AWS, Azure, or Google Cloud in a different jurisdiction. Check the sub-processor list in the DPA. |
| What happens to data when you cancel? | Confirm deletion timelines. Some vendors retain data for model improvement purposes after contract termination unless you explicitly request deletion. |
| What security certifications does the vendor hold? | ISO 27001 and SOC 2 Type II provide useful assurance for AI tools processing sensitive data, but certification should be assessed alongside the vendor's security controls, contractual commitments, data handling practices, and independent assurance. Request the current certificate where applicable. |
| What is the data retention period for prompts and outputs? | Some platforms retain conversation history for extended periods. This is relevant for your data retention policy and for responding to subject access requests. |
| How does the vendor classify their system under the EU AI Act? | Relevant if you have EU operations. Ask whether the vendor has conducted a conformity assessment and what risk tier they assign their system. |
Add the vendor's data processing agreement and a summary of answers to these questions to the AI tool register. When a vendor updates their terms, your register tells you which tools to re-evaluate.
Step 8: AI incident management
Governance needs to cover what happens when something goes wrong. AI incidents are not the same as general IT incidents, and your existing incident response process may not account for them. Define what counts as an AI incident and ensure the escalation path reaches your AI governance owner and, where relevant, your DPO.
What counts as an AI incident
- Confidential or personal data entered into an unauthorised or unapproved AI tool
- AI-generated content sent to a customer or published externally without appropriate review
- Discriminatory or harmful AI output affecting an individual
- An incorrect automated decision with a significant effect on an individual
- Prompt injection causing data exposure or unintended AI behaviour
- A security breach at an AI vendor affecting your data
- Prohibited AI use by a member of staff
- AI-generated content causing legal, regulatory, or reputational harm
- Unexpected model behaviour after a vendor update
Response process
AI incidents that involve a personal data breach connect directly to your broader incident response capability. If your organisation does not have a tested incident response process, an AI incident is a poor time to discover that.
Step 9: EU AI Act applicability
The EU AI Act is EU law. UK organisations are not directly subject to it solely by virtue of being UK-based. However, if your organisation places AI systems on the EU market, deploys AI that affects people in the EU, or supplies AI systems to EU customers, the Act may apply to you regardless of your location. The UK government is developing its own AI regulation approach, which is expected to differ from the EU model.
The EU AI Act applies a four-tier risk framework: unacceptable risk (prohibited), high risk, limited risk (transparency obligations), and minimal risk. For UK organisations with EU exposure, the most practically relevant provisions are:
Prohibited AI
Examples of prohibited AI practices that have applied since February 2025 (this is not an exhaustive list of Article 5 prohibitions):
- AI systems that use subliminal techniques to manipulate behaviour in ways that cause harm
- Social scoring systems used by public authorities
- Real-time remote biometric identification in public spaces (with limited law enforcement exceptions)
- AI that exploits vulnerabilities related to age, disability, or social situation to distort behaviour
High-risk AI
Under the revised implementation timeline, the rules for high-risk AI systems covered by Annex III apply from 2 December 2027. Certain high-risk systems embedded in regulated products apply from 2 August 2028. High-risk categories include AI used in recruitment and employment decisions, educational assessment, credit scoring, insurance risk assessment, critical infrastructure management, and law enforcement. If your organisation deploys AI in any of these areas and has EU operations or EU-affected individuals, begin compliance preparation now. The EU AI Act compliance guide covers the full risk tier structure and what each requires.
GPAI models
General-purpose AI model rules have applied since August 2025. These primarily affect model developers and providers rather than organisations using AI tools commercially, but organisations that fine-tune or adapt foundation models for their own products should take specific advice.
Step 10: ISO 42001 as a management system
ISO/IEC 42001:2023 is the international standard for AI management systems. It sets requirements for how an organisation establishes, implements, maintains, and continually improves its management of AI-related activities. If you already hold ISO 27001, many of the management system elements transfer directly.
ISO 42001 certification makes most sense for:
- Organisations developing or deploying AI systems at scale
- Regulated entities where auditors or customers ask for formal AI governance evidence
- Organisations with EU AI Act high-risk AI obligations, where ISO 42001 can contribute to a conformity assessment
- Businesses where AI governance is a sales differentiator in their market
For most UK SMEs using AI tools commercially rather than building them, formal ISO 42001 certification is not proportionate. Implementing its governance controls, including an AI policy, a risk assessment process, human oversight requirements, and a review cadence, gives you the substance without the certification overhead. Our ISO 42001 guide covers what the standard requires in detail.
Your first 90 days
Most organisations find that AI governance feels overwhelming in the abstract but manageable when broken into a sequenced 90-day programme. The goal at the end of 90 days is to be able to answer: what AI do we use, who owns it, what data does it process, what risks exist, and what controls are in place?
Governance cadence
AI governance is not a project with an end date. The tools change, vendor terms update, new capabilities emerge, and your organisation's use evolves. Build a review cadence that keeps the programme current without consuming disproportionate time.
Assign a named owner for AI governance, whether that is your DPO, IT lead, or a vCISO carrying the function. Without a named owner, the review cadence does not happen.
Minimum viable AI governance for SMEs
If your organisation does not have a dedicated compliance team, start here. These eight actions give you meaningful governance without requiring a large programme.