This page covers steps 4 to 6 of our AI governance framework. It assumes you have an AI tool register and a risk classification, which steps 1 to 3 in AI inventory, risk classification and acceptable use policy set up. Vendors, incidents and regulation follow in steps 7 to 10.
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.