GMD AutomationVisit Website →
← Back to blog

UK AI Compliance: Six Step Action Plan for Legal Teams

September 29, 2026
UK AI Compliance: Six Step Action Plan for Legal Teams

There is no single UK AI Act. AI compliance UK means applying existing law, principally UK GDPR, the Data Protection Act 2018 and sector rules, together with government AI assurance principles. The one action to take today is to run a Data Protection Impact Assessment and document the lawful basis and human oversight for any decision made about a person. The Information Commissioner's Office, the Department for Science, Innovation and Technology and procurement guidance PPN 017 are the primary references.

TL;DR:

  • UK AI compliance mainly relies on existing laws like UK GDPR and sector-specific rules, rather than a dedicated AI statute.
  • Running a Data Protection Impact Assessment and documenting lawful basis and human oversight are immediate steps to demonstrate compliance.
  • Sector regulators enforce principles differently across contexts, requiring organizations to map applicable laws and demonstrate cross-regulator coordination.
  • Most AI systems that process personal data must meet GDPR obligations, including lawful basis, transparency, bias testing, and safeguards against automated decision-making.
  • Future regulatory focus will likely emphasize vendor governance and assurance practices more than new legislation, making ongoing documentation and oversight critical.
Gmdautomation
Build AI Compliance Into Automation
Explore enterprise-grade AI systems designed for UK businesses, with security, compliance, maintenance and optimisation covered in one subscription.
Explore AI automation

Table of Contents

At-a-glance: the UK regulatory landscape for AI

The UK has chosen not to legislate a single cross-sector AI law. Instead, the government's pro-innovation approach to AI regulation asks existing regulators to apply a shared set of principles within their own remits, while the Department for Science, Innovation and Technology (DSIT) coordinates risk monitoring and builds regulator capability across government. This is described as a context-based framework: the same underlying model, say a large language model used for customer service, can trigger different obligations depending on whether it is deployed by a bank, a school or an online retailer.

The government's cross-cutting principles cover safety and robustness, appropriate transparency and explainability, fairness, accountability and governance, and contestability and redress. These are not standalone legal duties. They translate into obligations through the regulators that already oversee a sector: the ICO enforces data protection law, the Financial Conduct Authority (FCA) oversees financial services conduct, and so on. A compliance officer's first job is therefore not to find "the AI law" but to map which existing regulators and statutes apply to a given AI use case.

In practice, that means AI in the UK is governed by a patchwork that already exists: UK GDPR and the Data Protection Act 2018 for personal data processing, the Equality Act 2010 for discrimination risk, the Online Safety Act 2023 for platforms hosting user content or recommender systems, and whatever sector-specific rulebook applies on top. The House of Commons Library briefing on AI regulation confirms this decentralised model is deliberate: rather than one regulator with AI expertise, the UK relies on sector regulators applying the same core principles differently depending on context. For legal teams, this makes regulator-mapping an essential first step, not an afterthought, before any deeper compliance work begins.

At-a-glance: the UK regulatory landscape for AI — overview diagram

Most AI compliance work in the UK is data protection work wearing a different label. If an AI system processes personal data, and most commercially deployed systems do, UK GDPR applies in full. That means identifying a lawful basis before processing begins, giving individuals clear information about how their data is used, limiting collection and use to the stated purpose, and respecting individual rights including access, correction and erasure. Data minimisation matters particularly for generative AI systems trained or fine-tuned on customer data, where it is tempting to retain more than the specific task requires.

The sharper edge sits in the Data Protection Act 2018's provisions on automated individual decision-making, set out in Part 3 alongside the safeguards described under UK GDPR rights related to automated decision-making. These rules restrict decisions made solely by automated means where the decision produces a legal effect or similarly significant impact on a person, such as automated credit refusals, automated CV screening that ends a job application, or algorithmic tenancy checks. Where such a decision is permitted, the individual retains rights to obtain human intervention, to express their point of view, and to contest the outcome. The Data Protection Act 2018's automated decision-making provisions give the Secretary of State power to set further regulations on how these safeguards must operate, so this is an area to watch rather than treat as settled.

"Significant" is doing a lot of work in that test, and it is worth reading narrowly rather than generously. A recommendation that merely narrows a shortlist for human review is unlikely to meet the threshold; a decision that ends an application, denies a service or sets a price with no meaningful human check is far more likely to. Where a system sits close to that line, the safer assumption is that it counts, and the safeguards should be built in regardless.

The Equality Act 2010 adds a separate but overlapping risk. An AI system trained on historical data can reproduce and amplify existing bias, and doing so through an algorithm rather than a human decision-maker does not remove liability for discrimination based on protected characteristics such as sex, race, disability or age. Bias testing is therefore not just good practice, it is a control against a distinct legal exposure that sits alongside, not inside, data protection law.

Who enforces what: the regulators and their roles

The ICO is the default regulator for most AI compliance questions because most AI systems touch personal data. Its priorities are visible in its published guidance: it expects organisations to run Data Protection Impact Assessments for AI projects, it has run consultations specifically on generative AI, and it places heavy emphasis on purpose limitation, meaning organisations must be clear about what a model is for at each stage of its lifecycle rather than repurposing data informally later.

Beyond the ICO, sector regulators apply the same cross-cutting principles within their own remits. The FCA takes the lead where AI is used in lending decisions, insurance pricing or trading systems. Ofcom's interest grows where AI drives content recommendation or moderation on platforms in scope of the Online Safety Act. The Medicines and Healthcare products Regulatory Agency (MHRA) becomes relevant the moment an AI tool makes or supports a clinical or diagnostic claim. Employment tribunals and the Equality and Human Rights Commission sit behind AI used in recruitment or workforce management.

Because several regulators can have an interest in the same system, for example an AI credit-scoring tool touching both the ICO and the FCA, government has set up coordination mechanisms such as the Digital Regulation Cooperation Forum (DRCF), which brings together regulators with overlapping digital remits to share expertise and, where needed, run joint enquiries. Practitioners should expect that a serious AI compliance failure rarely stays with one regulator. The practical task is to identify, for each AI system, which regulator would take the primary enquiry and which would likely be consulted, then build documentation that would satisfy both.

DPIAs, high-risk assessment and practical documentation requirements

The ICO's guidance on AI and data protection states plainly that most AI projects processing personal data will meet the threshold for a Data Protection Impact Assessment under UK GDPR's Article 35, because such processing typically presents a high risk to individuals' rights and freedoms, as set out in the ICO's guidance on accountability and governance implications of AI. This is not optional paperwork. It is the accountability principle in action: an organisation must be able to demonstrate compliance, not merely assert it.

A defensible DPIA for an AI system should cover:

  1. Purpose and scope: what the system does, what decision or output it produces, and who is affected.
  2. Lawful basis: which UK GDPR basis applies, and why, documented against the specific processing activity rather than the organisation's activities generally.
  3. Risk analysis: likelihood and severity of harm to individuals, including bias, error rates and the consequences of a wrong output.
  4. Mitigations: the controls in place, such as human review, testing thresholds or access restrictions.
  5. Monitoring and review: how the assessment will be revisited as the system or its data changes.
  6. Decision log: a dated record of who approved the assessment and on what evidence.

Where a compliance team concludes a project is not high risk, that conclusion needs the same rigour as one that finds high risk. The record should state the criteria applied, the evidence considered and who signed off the decision, to an auditable standard that would survive scrutiny from the ICO or a claimant's solicitor months later.

Pro Tip: Treat the DPIA as a living document tied to model versions, not a one-off form completed at launch: a retrained model is, in effect, a new processing activity.

Transparency, explainability and meaningful human oversight

UK GDPR's Articles 13 to 15 require organisations to give individuals meaningful information about the logic involved in automated decisions that affect them, not a technical description of the model architecture, but a plain explanation of what factors drove the outcome and what it means for the person. The ICO's ongoing work on generative AI, including its call for evidence on generative AI, pushes this further by asking for stronger transparency about the data sources used to train models and clearer purpose definitions at each stage of a system's life.

Meaningful human oversight is the other half of this duty, and it is where organisations most often fail without realising it. A routine mistake is treating human oversight as a checkbox: a person technically reviews an output, but has neither the time, information nor authority to change it. Genuine oversight must be capable of reversing the decision and must leave an audit trail; otherwise the system risks falling within the restrictions on solely automated decision-making regardless of the label given to the process.

Practical controls that separate token review from substantive oversight include:

  • Decision logging that records what the AI recommended, what the human reviewer decided and why.
  • Documented review procedures setting out what a reviewer must check before approving an output.
  • Escalation routes for cases the reviewer is uncertain about, rather than a binary approve or reject.
  • Vendor contract clauses requiring suppliers to provide the information needed to explain a decision, not just the decision itself.

Our guide to AI system transparency sets out how these information duties apply in more operational detail.

AI assurance, standards and practical conformity routes

Assurance is the practical bridge between the government's high-level principles and evidence a regulator, auditor or board can actually inspect. The government's Introduction to AI assurance sets out a range of assurance techniques, from internal audits and impact assessments to formal conformity assessment against recognised standards, and explains the role of the UK AI Standards Hub in helping organisations navigate this landscape.

For most businesses, assurance starts with internal documentation: risk assessments, testing records and monitoring logs that show a system has been checked against defined criteria before and after deployment. Where the stakes are higher, such as AI used in recruitment, credit decisions or health-adjacent services, UKAS-accredited third-party conformity assessment adds independent weight that internal sign-off cannot. This becomes particularly relevant where a supplier's AI system is being brought in from outside; on-premise or sovereign deployment options, of the kind described by enterprise providers such as VOICERAcx's AI technology partnerships, can also form part of an assurance conversation where data residency or model control is a specific concern.

Assurance evidence is not just a defensive measure for a regulatory enquiry. It is increasingly the currency of procurement, where public and private buyers alike expect suppliers to demonstrate how a system was tested and what risks were mitigated, and it gives a board something concrete to review rather than a general assurance that "AI is being handled responsibly."

Good governance turns the principles above into repeatable processes rather than one-off exercises. Accountability starts with naming a role, not necessarily a new hire, but someone with clear responsibility for AI risk sign-off, an escalation path when a system behaves unexpectedly, and authority to pause deployment if needed.

Operational testing should cover:

  1. Model validation before deployment and after any retraining or significant data change.
  2. Bias testing across the protected characteristics most relevant to the use case, repeated periodically rather than once.
  3. Access controls restricting who can query, retrain or override the system.
  4. Retention policies setting how long inputs, outputs and logs are kept, tied to the stated purpose rather than indefinite storage.
  5. Audit logs capturing decisions and reviewer actions in a format that can be exported for a regulator or claimant.

Supplier governance deserves equal weight, because most organisations buy AI capability rather than build it. Procurement questions should ask suppliers to evidence how their system was tested, what data it was trained on, and what safeguards exist for automated decisions. Contracts should carry warranties on data provenance and bias testing, audit rights allowing the buyer to inspect assurance evidence, and termination clauses that trigger if a supplier cannot substantiate its compliance claims. Our guide to AI governance for businesses covers how to build a risk register that ties these controls together, and our UK AI regulation guide for policymakers and business leaders sets out the wider operational framework these checks sit inside.

Pro Tip: Build the vendor questionnaire once and reuse it for every AI supplier, including internal teams: consistency here is what makes an audit trail credible.

Procurement and public-sector obligations (PPN 017 and disclosure expectations)

Public bodies buying AI-enabled services must apply Guidelines for AI procurement, PPN 017, which requires disclosure of AI use in tenders and recommends proportionate due diligence from bidders. Suppliers should expect to answer specific questions about where AI is used in their service, what data trains it, and what risk-mitigation controls are in place, rather than a general assurance that the offering is "AI-powered."

The guidance also flags a more particular risk: the use of large language models in drafting tender responses themselves, where buyers are advised to verify claims rather than accept generative output at face value and to confirm that confidential tender data has not been used to train a supplier's models.

Private-sector buyers can borrow the same discipline even without a legal obligation to do so. Due diligence should ask a supplier to evidence testing, provenance and human oversight arrangements, not just describe them. Where a supplier resists disclosure on intellectual property grounds, a workable middle ground is to require assurance evidence and testing summaries rather than full model access, protecting confidentiality while still giving the buyer something to inspect. Our procurement checklist for questions to ask AI vendors sets out a fuller list of the questions worth building into any tender or contract.

Compliance work lands better when it is time-boxed rather than left as a standing intention. A practical sequence looks like this.

  1. This week: build or update an inventory of every AI system in use, including shadow deployments by individual teams, and triage each one for whether it makes a solely automated decision with a legal or similarly significant effect.
  2. This week: flag any system meeting that threshold and confirm human intervention rights exist and are documented.
  3. This quarter: run or refresh DPIAs for every system identified, including a documented rationale for any system assessed as not high risk.
  4. This quarter: audit existing AI suppliers against the contractual and disclosure standards set out above, and close any gaps found.
  5. This year: update the organisation's AI risk register to reflect new deployments and retraining events.
  6. This year: assemble assurance evidence, testing records and DPIA outcomes into a form suitable for board reporting and for a regulator's request.

None of these steps require waiting for new legislation. They are achievable now, using the legal framework and assurance guidance already in force, and they are the record a regulator or claimant's solicitor will ask for first if something goes wrong.

Practitioner perspective: how an experienced UK managed-AI provider operationalises compliance

Compliance obligations do not disappear because a business outsources its AI deployment, but a managed provider can absorb much of the operational burden if it treats compliance as part of the build rather than an afterthought. A managed AI provider can deploy AI systems, including voice-based AI agents for call handling and lead qualification and AI-driven social media management, under a managed subscription model that covers implementation, operation and ongoing support.

In practice, that means the DPIA groundwork, decision logging and human oversight arrangements described throughout this guide are built into deployment from the outset rather than retrofitted once a system is live, and reviewed on an ongoing basis as part of the subscription rather than left to the client to maintain alone. This does not remove a business's own accountability under UK GDPR, but it does mean the practical scaffolding, logs, review points, documented lawful basis, is already in place when a DPIA needs updating or a regulator asks a question.

Author's perspective on near-term regulatory change and priority actions

My own view is that the next meaningful pressure on UK AI compliance will not come from a new AI Act, it will come from tighter expectations on assurance and vendor governance. The government's own direction of travel, visible in its emphasis on the AI Standards Hub and conformity assessment, suggests that "we have a policy" will stop being an adequate answer to a regulator's question well before any new statute arrives. I would also expect continued tightening around highly capable models and training-data transparency, echoing the direction of the ICO's generative AI consultations, rather than a wholesale rewrite of data protection law.

For legal teams working with limited resource, my advice is to prioritise ruthlessly: get the DPIA and human oversight basics right for any system touching a significant decision about a person, then spend remaining effort on vendor governance rather than internal audit theatre. Most AI compliance failures I expect to see over the next two years will trace back to a supplier's undocumented claim, not an internal team's technical error.

— Ravi

How GMD Automation helps UK businesses meet compliance obligations

Building the governance described in this guide from scratch takes time most legal and operations teams do not have, and delays adoption of AI tools that could otherwise free up capacity. GMD Automation deploys AI systems, including voice AI agents and social media automation, as a fully managed service with compliance groundwork built into deployment rather than left to the client to assemble afterwards, under a single monthly subscription with no upfront cost.

Gmdautomation

Two services illustrate the model: Your AI answers, qualifies and books, from £300 per month, and Your AI credit controller for lettings, from £250 per month. Both are supplied on a rolling contract with ongoing support and optimisation included. If you want to see how compliance-first AI deployment would work for your business, get in touch through the GMD Automation services page to arrange a walkthrough.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Sources

FAQ

Are there any AI regulations in the UK?

There is no single UK AI Act; AI is regulated through existing law, principally UK GDPR and the Data Protection Act 2018's automated decision-making provisions, alongside the Equality Act, the Online Safety Act and sector regulator rules. The government's pro-innovation, context-based approach asks each regulator to apply shared principles within its own remit rather than creating one AI regulator.

Is there a specific law in the UK regarding AI in 2026?

There is no dedicated UK AI statute in force in 2026; compliance rests on applying UK GDPR, the Data Protection Act 2018 and sector-specific law to AI use cases. The House of Commons Library briefing confirms the UK continues to favour this decentralised, sector-led model over a single cross-cutting AI act.

Does the UK have to comply with the EU AI Act?

The UK is not bound by the EU AI Act because it is a separate jurisdiction with its own regulatory approach, based on existing UK data protection law and sector regulation rather than that EU framework. A UK business trading into the EU or processing EU residents' data may still need to consider the EU AI Act separately, and should take specific legal advice on that cross-border exposure.

Which jobs are most exposed to AI automation?

There is no reliable, agreed list of specific jobs that will not survive AI, and any such claim should be treated with caution. Roles built around repetitive data processing, routine call handling and basic content drafting face the most visible automation pressure, but the more accurate framing is task-level change within roles rather than wholesale job elimination.