AI GDPR Compliance UK: What Businesses Need to Know in 2026

Last updated: August 2026 · Written by Rodi Taze, Co-Founder of AI Workforce

Deploying AI without first understanding the personal data involved can create significant compliance risk for UK businesses. This is general information rather than legal advice, but it sets out how UK GDPR actually applies to AI systems: which rules already cover your AI use, what changed under the Data (Use and Access) Act 2025, when the EU AI Act becomes relevant, and the practical steps that hold up to scrutiny if the ICO ever asks you to explain your approach.

Quick Answer: UK GDPR applies to AI in the same way it applies to any processing of personal data: you need a lawful basis, you must follow the seven data protection principles, and you carry extra duties where the AI makes solely automated decisions with a significant effect, or handles special category data. The Data (Use and Access) Act 2025 changed the automated decision-making rules, and the EU AI Act may apply separately if you place AI on the EU market, are established in the EU, or your AI's output is used in the EU. None of this requires a specific "AI licence", but it does require you to map what your AI actually does with personal data and document your reasoning.

What's Covered

1. Does UK GDPR Apply to Your AI Use?

2. How UK GDPR, the DPA 2018, the DUAA 2025 and PECR Fit Together

3. The Seven UK GDPR Principles

4. Personal, Anonymised and Pseudonymised Data

5. Mapping Personal Data Across the AI Lifecycle

6. Who Is the Controller, Processor or Joint Controller?

7. The AI Workforce AI Data Protection Check

8. Choosing and Documenting a Lawful Basis

9. Special Category and Biometric Data

10. Automated Decisions Under the Post-DUAA Rules

11. When You Need a DPIA

12. Vendors, Contracts and International Transfers

13. Vendor Due Diligence Checklist

14. Transparency and Individual Rights

15. GDPR Transparency vs AI Disclosure: Two Different Duties

16. Data Accuracy, Testing and Human Oversight

17. When Does the EU AI Act Apply?

18. Employee Use of AI Tools

19. What to Do If an AI System Causes a Personal Data Breach

20. A Security Checklist for AI Systems

21. Records, Monitoring and Review

22. A Practical Compliance Checklist

23. Frequently Asked Questions

24. Key Takeaways

Does UK GDPR Apply to Your AI Use?

If an AI system processes information that relates to an identified or identifiable person, UK GDPR applies, regardless of how the system is described or marketed. This covers far more than a chatbot handling customer names: it also covers a recruitment tool scoring CVs, a voice agent transcribing calls, an AI receptionist handling customer calls, a model fine-tuned on support tickets, and a tool that summarises staff emails.

UK GDPR does not create a separate regime solely for AI; it applies the existing framework to AI-related processing. However, the way a system is used may trigger additional duties relating to automated decisions, special category data, high-risk processing that needs a DPIA, and international transfers. The starting question for any AI project is the same as for any new system: what personal data does it touch, at which stages, and on what basis. This applies equally whether the system is a customer-facing AI voice agent, a back-office AI agent, or a broader digital workforce combining several tools.

How UK GDPR, the DPA 2018, the DUAA 2025 and PECR Fit Together

These four things get referred to almost interchangeably in casual conversation, and that causes real confusion, so it is worth being precise.

UK GDPR is the core data protection regulation, retained in UK law after Brexit, setting out the principles, lawful bases, individual rights and accountability requirements that apply to most processing of personal data.

The Data Protection Act 2018 sits alongside UK GDPR rather than replacing it, filling in areas UK GDPR leaves to individual countries, including law enforcement processing, national security, and specific exemptions.

The Data (Use and Access) Act 2025 amends both UK GDPR and the DPA 2018 rather than replacing either. Its most significant change for AI is to the automated decision-making rules, covered below. ICO guidance was still being updated to reflect it at the time of writing.

PECR, the Privacy and Electronic Communications Regulations, is a separate regime governing electronic marketing, cookies and similar technologies. It is not a UK GDPR lawful basis, and a UK GDPR basis does not automatically satisfy PECR. If an AI tool sends marketing emails, texts or calls, PECR must be assessed separately, involving consent, the soft opt-in for existing customers, suppression lists, or the stricter rules for automated calls, depending on recipient and channel.

An AI project needs to check UK GDPR and, where marketing or automated calls are involved, PECR, as two separate questions.

The Seven UK GDPR Principles

UK GDPR is built on seven principles, not six. Accountability is a full principle in its own right, not an administrative afterthought, and AI projects can expose accountability gaps because their data sources, model behaviour, vendors and outputs may be harder to document and explain than those of conventional systems.

• Lawfulness, fairness and transparency: you need a valid lawful basis, the processing must not be misleading or unfair to the individual, and you must tell people what you are doing with their data

• Purpose limitation: collect data for specified, explicit purposes, and do not reuse it for a materially different purpose without a fresh basis, for example using customer support transcripts to train a general-purpose model when customers were only told the transcripts would be used to resolve their query

• Data minimisation: use only the data the AI system actually needs for its stated purpose, not everything you happen to hold

• Accuracy: keep personal data accurate and up to date, and correct or delete what is wrong, including where an AI system has generated or inferred incorrect information about someone

• Storage limitation: do not keep personal data, including logs, transcripts and training datasets, for longer than necessary

• Integrity and confidentiality: apply appropriate security to personal data processed by or stored for an AI system, including data sent to and returned from third-party model providers

• Accountability: you must be able to demonstrate compliance, not just achieve it. For AI this means keeping records of processing, DPIAs where required, legitimate interests assessments, vendor due diligence, testing and monitoring evidence, staff training records and a documented decision-making trail, not simply a policy that says you comply

Illustrative summary. See the ICO's own guidance on the principles for the full detail.

Personal, Anonymised and Pseudonymised Data

Whether UK GDPR applies at all often comes down to a distinction that AI projects blur more easily than traditional databases do: the difference between personal data, pseudonymised data and genuinely anonymised data.

Personal data is any information relating to an identified or identifiable living person, directly or indirectly. A name is an obvious example, but so is a customer ID that can be linked back to a name through another dataset, a voice recording, or a written profile detailed enough to single someone out even without naming them.

Pseudonymised data has identifying details replaced or removed, for example a name swapped for a reference number, but it remains personal data if the organisation, or anyone it could practically obtain the means from, can still link it back to an individual. Pseudonymisation is a recognised security measure that can reduce risk, but it is not a route out of UK GDPR on its own.

Anonymised data has had identifying elements removed to the point where no living person can reasonably be identified from it, by anyone, using any means reasonably likely to be used. The bar for this is higher than it first appears: the ICO's anonymisation guidance is clear that removing an obvious name or ID is not enough if the remaining detail could still single someone out. Small datasets, free-text fields and rich behavioural logs are particularly hard to anonymise reliably, which matters directly for AI systems that log prompts and outputs by default.

Do not assume "we removed the name" means the data has left UK GDPR's scope, or that training data internally labelled "anonymised" would meet the ICO's test if challenged. Document the specific technique used and why it is effective, rather than relying on the label alone.

Mapping Personal Data Across the AI Lifecycle

Personal data moves through an AI system at several distinct stages, each raising slightly different questions.

Collection: where does the data come from, and were people told it might be used this way.

Preparation and training or fine-tuning: is the AI using a pre-trained general model, or is it trained or fine-tuned on your own data. Fine-tuning on personal data is a materially different, often higher-risk activity than simply querying an existing model.

Deployment and inference: what personal data does the system process each time it runs, and what does it produce or decide.

Monitoring and logging: call recordings, transcripts, prompts and outputs are commonly logged for quality, security and debugging. This logging is itself processing and needs a lawful basis, documented purpose, retention period and access controls. This applies directly to AI call centre agents, where call volume can make logging decisions easy to overlook.

Review and deletion: what happens to the data once it is no longer needed, and how quickly it can actually be deleted, particularly if it trained a model rather than sitting in a database.

Mapping these stages is a useful exercise, since lawful basis, DPIA screening, vendor contracts and retention only become answerable once you know what happens at each stage. If specifying a new AI agent, our guide on how to write an AI agent brief covers where data handling and permissions should be defined before the system is built.

Illustrative lifecycle. Not every stage applies to every AI tool, particularly where you are only using a vendor's pre-trained model.

Who Is the Controller, Processor or Joint Controller?

It is tempting to default to "we are the controller, our AI vendor is the processor" for every AI tool you use. That is sometimes right, but treating it as a universal rule is a mistake the ICO has flagged in guidance on outsourced and AI-supported processing. The correct answer depends on what each party actually decides and does with the data, assessed activity by activity.

You are likely the controller, with your vendor as processor, where the vendor processes data strictly on your instructions and does not use it for its own purposes, such as improving its model. A vendor may be an independent controller for some processing, for example using interactions to improve its own foundation model or for its own security and analytics purposes. You and a vendor may be joint controllers where you jointly decide the purposes and means of some processing, such as co-designing a scoring model.

Read the actual contract and privacy documentation before assuming which applies, and check what the vendor's terms say about using your data to train its own models. Regulated sectors carry extra weight here: our guide on AI for law firms covers how these same questions apply where client data is involved. Some general-purpose AI services retain prompts or outputs for service improvement under particular account types; check current terms rather than assuming consumer and enterprise accounts are treated the same way.

Illustrative starting questions. The right answer depends on the specific processing activity, not the commercial relationship as a whole.

The AI Workforce AI Data Protection Check

Working through UK GDPR compliance one document at a time can miss how the pieces connect. AI Workforce uses an internal sequence, the AI Data Protection Check, to walk through the questions above in order for a new or existing AI deployment. This is an AI Workforce framework, not an ICO tool, and does not replace a DPIA or legal advice.

1. DATA: what personal data does the system actually touch, at collection, training, inference, logging and deletion

2. PURPOSE: what specific purpose justifies each use of that data, and has the purpose changed since the data was first collected

3. ROLE: for each processing activity, who is the controller, processor, independent controller or joint controller, and what does the contract say each party may do

4. LAWFUL BASIS: which of the six bases applies, documented with reasoning, not assumed by default

5. MINIMISE: does the system use only the data it needs, or is it processing more than the purpose requires

6. RISK: does this processing meet the ICO's high-risk indicators, and does it need a DPIA

7. VENDOR: is the vendor a processor under a proper Article 28 contract, and what does it do with your data beyond your instructions

8. TRANSFER: where is the data actually processed and stored, and what safeguard covers any transfer outside the UK

9. RIGHTS: can access, rectification, erasure and the other applicable rights actually be fulfilled for data used by this system

10. OVERSIGHT: is there a named person who can meaningfully review, question and override the system's outputs

11. RECORD: is the reasoning behind every step above written down, not just the conclusion

An AI Workforce framework, not an ICO or regulatory checklist. Use it alongside, not instead of, a formal DPIA where one is required.

Choosing and Documenting a Lawful Basis

UK GDPR gives six possible lawful bases: consent, contract, legal obligation, vital interests, public task, and legitimate interests. There is no basis specific to AI. The right one depends on the purpose, not the technology.

A purpose-led way to think about common AI scenarios:

• Responding to a customer enquiry: contract may apply where processing is objectively necessary to perform a contract or steps requested before entering one. A general prospect enquiry will not always meet that test; legitimate interests, with a documented balancing assessment, may be more appropriate.

• Marketing emails or texts drafted by AI: needs both a UK GDPR basis, commonly legitimate interests or consent, and separate PECR compliance, since a UK GDPR basis does not satisfy PECR and PECR consent does not by itself satisfy UK GDPR.

• Analysing employee data: treating this as automatically covered by "part of the employment contract" is too broad. Monitoring and profiling engages fairness, proportionality and the ICO's employment practices guidance; document a specific assessment.

• Fraud detection or security monitoring: legitimate interests may apply, subject to purpose, necessity and balancing tests, though another basis may suit a regulated context.

• Training or fine-tuning a model on customer data: requires its own assessment distinct from the original collection basis. If people were told data would be used to deliver a service, using it afterwards to train a model is a new purpose needing its own basis and fresh transparency.

• Legitimate interests generally: one of six equally valid bases, not a default fallback. Using it properly requires a documented assessment covering purpose, necessity and a balancing test, not an assumption it is the easiest option.

Special Category and Biometric Data

Special category data, information revealing racial or ethnic origin, political opinions, religious beliefs, trade union membership, genetic data, biometric data used for identification, health data, or sex life or sexual orientation, needs both a UK GDPR Article 6 lawful basis and a separate Article 9 condition. An inferred characteristic can count as special category processing where the system is deliberately used to infer it, or the organisation intends to treat the person differently on that basis, regardless of how confident the inference is.

This is a genuine risk with generative AI and profiling tools, since a model can infer or imply something about a protected characteristic, such as likely health status or ethnicity from writing style or behavioural patterns, without anyone deliberately designing it to do so. Check this before deployment rather than after a complaint.

Biometric data used to uniquely identify a person, such as facial recognition or voice-based identity verification, is special category data needing an Article 9 condition. A photograph or voice recording only becomes biometric data in this sense once technically processed into a template used for identification.

Automated Decisions Under the Post-DUAA Rules

This is one of the areas most guides get wrong, because the rules changed materially under the DUAA 2025 and much of what circulates online still describes the pre-2025 position.

Before the DUAA 2025, UK GDPR Article 22 gave individuals a right not to be subject to a decision based solely on automated processing, including profiling, that produced legal or similarly significant effects, subject to narrow exceptions for contract necessity, authorisation by law, or explicit consent.

The DUAA 2025 replaced this with a new framework under Articles 22A to 22D. Rather than a general prohibition with narrow exceptions, the new rules widen the circumstances in which solely automated significant decisions can be made, provided safeguards are in place: information about the decision, the ability to make representations, the ability to contest it, and the ability to obtain meaningful human intervention.

Special category data still sits under tighter conditions within this broadened framework, and the underlying protection individuals are entitled to, meaningful information and a working path to human review, remains the same even though the legal mechanism has changed. ICO guidance was still being finalised to reflect the DUAA 2025 at the time of writing. This lines up with what customers themselves report: our customer-service AI research found that 95% of consumers want to know why AI makes a decision, while only 37% of CX leaders currently explain that reasoning.

In practice, before deploying any AI system that makes or materially informs a decision about a person, for example credit scoring, recruitment shortlisting or eligibility for a service, work out honestly where it sits:

• Supports a human decision: the AI provides information or a recommendation, and a person makes the actual decision with genuine discretion to depart from it. This carries lighter obligations, provided the human review is real rather than a formality.

• Solely automated, but not significant: the AI decides without human involvement, but the effect on the person is minor. Fewer safeguards apply, though transparency and accuracy still matter.

• Solely automated with a significant effect: the AI decides without meaningful human involvement, and the outcome has a legal or similarly significant effect, for example refusing credit, rejecting a job application, or restricting access to a service. This is where the DUAA 2025 safeguards apply in full: information, representations, contestability and human intervention need to be genuinely available, not just written into a policy document.

When You Need a DPIA

A Data Protection Impact Assessment is not automatically required for every AI project, and treating it as a blanket rule for "any large-scale or automated" use overstates the position. The legal trigger is processing that is likely to result in a high risk to individuals, and the ICO provides screening criteria to help you assess this rather than a fixed list of technologies.

Relevant ICO indicators include systematic and extensive profiling with significant effects, large-scale processing of special category or criminal offence data, systematic monitoring of a publicly accessible place, innovative technology combined with other risk factors, profiling used to decide access to a service, and processing that combines or matches data from multiple sources.

Many everyday AI tools will not individually meet this bar, but combinations often do, for example a recruitment tool profiling candidates at scale. Use the ICO's screening checklist for each AI system rather than assuming DPIAs never apply, or that every project automatically needs one. Where a DPIA is not required, document that reasoning; it is the accountability principle in practice.

Vendors, Contracts and International Transfers

Where a vendor is genuinely acting as your processor, UK GDPR Article 28 requires a written contract covering the subject matter, duration and purpose of processing, the data and individuals involved, security measures, sub-processor conditions, assistance with individual rights requests, and deletion or return of data at contract end. Standard vendor terms may not address every controller-specific requirement, so review the data processing addendum rather than product or marketing documentation.

International transfers are a frequent blind spot with AI tools, since the underlying model provider may process or store data outside the UK even when marketed to UK businesses. A restricted transfer requires an applicable mechanism: UK adequacy regulations, a safeguard such as the International Data Transfer Agreement or the UK Addendum to the EU's Standard Contractual Clauses, or a narrow exception. Ask any AI vendor directly where your data, including prompts and any fine-tuning data, is actually processed and stored, rather than assuming "the cloud" means it stays in the UK.

Vendor Due Diligence Checklist

A short due diligence pass before signing catches most of the problems that surface later. The table below sets out what to ask an AI vendor and why each question matters.

Transparency and Individual Rights

People are entitled to know when an AI system is processing their personal data and, broadly, what it is used for and how significant decisions are made. Privacy information should explain the relevant purposes, data use, recipients, retention and any significant automated decision-making. AI Workforce publishes its own AI transparency notice as a working example of this kind of disclosure.

UK GDPR rights, including access, rectification, erasure, restriction, objection and portability, may apply to data used by AI systems where the legal conditions for each right are met; portability, for example, generally depends on processing based on consent or contract and carried out by automated means. Two rights are genuinely harder to fulfil with AI than with a conventional database. Rectifying or erasing data baked into a trained or fine-tuned model, rather than simply stored in a record, is technically difficult, and vendors vary in what they can do about it; ask how a vendor handles this before relying on that capability. Where automated decision transparency provisions apply, you should be able to provide meaningful information about the main factors and likely consequences, though this does not mean disclosing source code or every internal calculation.

GDPR Transparency vs AI Disclosure: Two Different Duties

These two things get treated as the same requirement, and they are not. UK GDPR transparency is a data protection duty: telling people what personal data you collect, why, on what basis and for how long, regardless of whether AI is involved.

AI disclosure, in the sense used by the EU AI Act's Article 50, is a separate duty about the technology itself: telling a person they are interacting with an AI system, even where the underlying data processing is minimal. A voice agent stating "you are speaking with an AI assistant" meets an AI disclosure expectation; it does not, on its own, meet your UK GDPR transparency obligations, which still need a privacy notice covering the data itself.

A compliant AI deployment needs both: a privacy notice explaining the data processing, and, where applicable, a clear statement that the person is dealing with an AI system. Treating one as satisfying the other is a common and avoidable gap.

Data Accuracy, Testing and Human Oversight

Generative AI systems can produce inaccurate personal data about a real, identifiable person, for example fabricating a claimed employment history or a false criminal record. This is a live, recognised issue, not a hypothetical one, and it engages the accuracy principle directly: inaccurate personal data generated by your AI system must be addressed through appropriate correction and challenge processes.

Testing an AI system before deployment, and monitoring it afterwards, is part of demonstrating accountability, not an optional step: test with realistic inputs, check outputs for errors involving real individuals, provide a route to challenge an AI-generated statement, and review performance periodically rather than treating go-live as the end of the process.

Meaningful human oversight means more than a person being technically able to intervene. The reviewer needs genuine authority to override the output, enough understanding to spot an implausible or biased result, enough time to actually review rather than rubber-stamp, and a clear escalation route when unsure. A person who clicks "approve" on every AI decision without the authority or information to meaningfully question it does not satisfy a human oversight requirement.

When Does the EU AI Act Apply?

The EU AI Act is a separate framework from UK GDPR, and it may apply to a UK business alongside UK data protection law, not instead of it. Its territorial reach is more specific than "used by EU customers": broadly, it applies to providers placing an AI system on the EU market or putting it into service there, to providers and deployers established in the EU, and to providers and deployers outside the EU where the system's output is used in the EU. Check your own facts rather than assuming either full exposure or full exemption.

The Act's obligations are phasing in on a schedule that shifted during 2026. Prohibited practices and AI literacy obligations have applied since 2 February 2025, governance rules for general-purpose AI models since 2 August 2025, and Article 50 transparency obligations since 2 August 2026, requiring providers of AI systems that interact directly with people to design them so individuals are informed they are interacting with AI, unless this is already obvious. Following a Digital Omnibus package in force from late July 2026, the main high-risk obligations for Annex III standalone systems have been deferred to 2 December 2027, and Annex I embedded systems to 2 August 2028.

For most UK small and medium businesses, transparency disclosure is therefore the most immediately relevant EU AI Act obligation right now, not the high-risk system requirements. Our guide to AI agents for small businesses covers where this duty typically applies. If your AI use might fall into a high-risk category, for example recruitment or credit scoring, it is worth understanding the requirements now rather than waiting.

Illustrative timeline based on the current schedule as of August 2026. This has changed once already and could change again.

There is currently no comprehensive UK AI Bill progressing through Parliament. Lord Holmes of Richmond introduced a private member's Artificial Intelligence (Regulation) Bill in the previous parliamentary session, but that session has since ended and the bill will make no further progress. As of August 2026, UK businesses should plan primarily around the existing legal framework, including UK GDPR, the DPA 2018 as amended by the DUAA 2025, PECR, consumer and equality law, and applicable sector-specific regulation.

Employee Use of AI Tools

Staff use of public AI tools for drafting, summarising and coding, including AI-assisted email triage, is increasingly common, and it creates data protection exposure a general IT policy does not fully address. This applies just as much to AI used in a CRM system or an outbound sales automation tool as to a general-purpose chatbot, since each processes customer data by design. A clear acceptable-use policy should set out what data staff may not paste into a public AI tool, which tools are approved and under what account type, since free-tier and enterprise accounts often have different data-use terms, and how AI-assisted work should be reviewed before it is relied on or sent externally.

Recording and transcribing meetings through an AI note-taker must be covered by an appropriate documented lawful basis. That may form part of the wider meeting-processing activity, but it must account for the recording, transcription, storage and any vendor processing involved. Where a note-taker is used with external parties, check whether their own policies permit it.

If AI is used to inform decisions about staff, for example screening applications or assessing performance, treat this with the same rigour as automated decision-making and employee monitoring guidance more broadly: employees are entitled to know it is happening and understand how it affects them.

What to Do If an AI System Causes a Personal Data Breach

An AI-related breach looks like any other personal data breach in legal terms, but AI systems introduce distinctive causes: a misconfigured prompt exposing one customer's data to another, a logging pipeline retaining transcripts too long, or a vendor incident affecting a model you rely on. A workable response follows the same core steps as any breach:

1. Contain the issue as soon as it is identified, for example disabling the affected feature or revoking exposed access.

2. Assess the risk to individuals, including whether special category or financial data was involved and how many people are affected.

3. Notify the ICO within 72 hours of becoming aware of the breach where it is likely to result in a risk to individuals' rights and freedoms, using the ICO's breach reporting service.

4. Notify affected individuals without undue delay where the breach is likely to result in a high risk to them, describing the breach in plain language and the steps they can take.

5. Record the breach internally, including facts, effects and remedial action taken, even where you conclude notification is not required, since the accountability principle requires this regardless of the notification decision.

6. Review the cause, particularly where an AI vendor or configuration was involved, and confirm the vendor's own breach notification obligations to you under your contract.

Where the vendor acts as your processor, your organisation remains responsible for assessing its controller notification obligations. A vendor acting as an independent controller may have separate notification duties for its own processing. The contract should require a processor to notify you without undue delay so you can meet any applicable reporting deadline.

A Security Checklist for AI Systems

• Data sent to and returned from any third-party AI or model provider is encrypted in transit and at rest

• Access to AI tools handling personal data is restricted to staff who need it, with role-based permissions, and API keys are stored securely and rotated periodically

• Logs, transcripts and prompts are retained only for a defined period, not indefinitely by default

• Staff have been told what data must not be pasted into public or unapproved AI tools

• Vendor security certifications and any available audit reports have been requested and reviewed, not just claimed on a marketing page

• There is a documented incident response process covering AI vendor and configuration failures, not only internal system breaches

• Fine-tuning or training pipelines, where used, have their own access controls and retention rules distinct from the production system

Records, Monitoring and Review

Ongoing accountability for AI systems looks similar to accountability for any other significant processing activity, with a few AI-specific additions: a record of processing that identifies each AI system, the data involved and whether it makes or informs decisions about people; DPIAs and vendor due diligence kept current as systems change, not just at launch; outputs and decisions logged proportionately to risk so a specific decision can be explained later; and a review schedule, since model updates and new use cases can shift a system's risk profile after launch. The checklist below turns this into a working reference.

A Practical Compliance Checklist

Data and purpose

• We have listed every AI system in use, including tools individual staff have adopted informally, and know what personal data each one processes and at which lifecycle stage

• We have a documented lawful basis for each AI system, and have checked PECR separately for any use involving marketing emails, texts or automated calls

• We have identified any special category or biometric data our AI systems touch, and the Article 9 condition that applies

Decisions and individual rights

• We have classified whether each AI-supported decision supports a human, is solely automated but not significant, or is solely automated with a significant effect, and where the latter applies, individuals can get meaningful information, make representations, contest the decision and obtain human intervention

• Our privacy notices explain the relevant processing in a meaningful way, and we have a workable process for AI-generated inaccuracies about a real person to be corrected

• We have tested and are monitoring our AI systems for accuracy, fairness and unexpected outputs

Vendors and transfers

• We have assessed, for each AI vendor, whether we are the controller, the vendor is an independent controller or processor, or we are joint controllers, and reviewed contracts for genuine Article 28 terms

• We know where our AI vendors actually process and store data, and have a valid safeguard for any international transfer

• We have run DPIA screening for each AI system against the ICO's criteria, documented the outcome either way, and assessed whether the EU AI Act applies, specifically the Article 50 transparency requirement

Governance and monitoring

• We have an acceptable-use policy covering staff use of public AI tools, including AI note-takers, and the security checklist above has been worked through

• We have a named owner for AI compliance, not just an IT or product owner for the tool itself, and we review our AI systems on a schedule, not only at initial launch

• We can produce documentation showing our reasoning, not just our conclusions, if the ICO ever asks

Frequently Asked Questions

Does UK GDPR apply if we only use an off-the-shelf AI tool rather than building our own model?

Yes. UK GDPR applies based on what happens to personal data, not who built the model. A third-party tool adds a vendor relationship to assess, not an exemption.

Do we need consent to use AI on customer data?

Not necessarily. Consent is one of six lawful bases, not a universal requirement. Contract necessity or legitimate interests may be available, depending on the purpose, necessity and circumstances, provided you can justify the choice and document it.

Is an AI chatbot making an automated decision under the new rules?

Only if it decides something with a legal or similarly significant effect on the person without meaningful human involvement. A chatbot answering FAQs or booking an appointment is unlikely to meet this bar. A chatbot approving or declining a credit application without meaningful human involvement is likely to make a solely automated significant decision, depending on the process and its effect on the individual.

Do we need a DPIA every time we use AI?

No. A DPIA is required where the processing is likely to result in a high risk, assessed against the ICO's screening criteria, not automatically for every AI system. Document your screening decision either way.

Is our AI vendor automatically our data processor?

Not automatically. Check the contract and the vendor's data-use terms. It can be a processor, an independent controller, or a joint controller, depending on what it actually does with the data.

Does the EU AI Act apply to a UK-only business?

It can, depending on your activities, particularly if your AI system's output is used in the EU or you are providing services into the EU market. Check the specific territorial conditions rather than assuming either full exposure or full exemption based on where your business is registered.

What is the single most common AI compliance gap you see?

AI Workforce Insight: three practical gaps worth checking early are whether DPIA screening has actually been recorded, whether logs and transcripts have a defined retention period, and whether anyone has confirmed where the provider processes the data.

Is anonymised data covered by UK GDPR?

No, genuinely anonymised data falls outside UK GDPR. The bar is high: if any person or organisation could reasonably re-identify someone from the data, using any means reasonably likely to be used, it remains personal data. Pseudonymised data, where a key could reverse the process, stays within scope.

Does telling people "you are speaking with an AI" satisfy our GDPR transparency obligations?

No. AI disclosure and UK GDPR transparency are separate duties. Disclosing that a system is AI meets a technology-disclosure expectation; you still need a privacy notice explaining the personal data processing itself, including purpose, lawful basis and retention.

What happens if our AI vendor has a data breach?

Where the vendor acts as your processor, your organisation remains responsible for assessing its controller obligations, including notification where required. An independent-controller vendor may have separate notification duties for its own processing. Your vendor contract should require the vendor to notify you promptly so your own timeline is achievable.

Do we need to run a DPIA before signing with any AI vendor, or only for high-risk systems?

Only where the processing is likely to result in high risk under the ICO's screening criteria. Documenting the screening outcome even where a full DPIA is not required is good accountability practice and helps demonstrate how the organisation assessed the risk.

Can employees paste customer data into a public AI tool?

Only where the organisation has approved the tool and the processing is lawful, necessary, transparent and appropriately secured. Check the account terms, vendor role, data retention, model-training settings and international transfers before employees enter customer data. Special-category or confidential information may need to be prohibited entirely.

Can AI process special category data, such as health or biometric information?

Yes, but only with both a UK GDPR Article 6 lawful basis and a separate Article 9 condition, including data the system infers rather than data explicitly entered.

Can an AI provider use our customers' data to train its own model?

Potentially, but contractual permission alone is not enough. You must establish the vendor's role, the purpose of the reuse, your lawful basis, compatibility with the original purpose, appropriate transparency, retention and transfer arrangements, and whether individuals' rights can be fulfilled. Where those conditions cannot be met, customer data should not be used for model training. Consumer, API and enterprise terms can differ materially, so check the current terms and administrative settings for the specific service and account.

Does PECR apply to AI-drafted marketing emails or calls?

Yes, separately from UK GDPR, for any AI use involving marketing emails, texts or automated calls, regardless of the lawful basis used for the underlying processing.

How long should AI prompts and transcripts be retained?

There is no fixed statutory period; retention must be proportionate and documented, not indefinite by default.

Key Takeaways

• UK GDPR has seven principles, not six; accountability requires documented evidence, not just a compliant outcome

• UK GDPR, the DPA 2018, the DUAA 2025 and PECR are four related but distinct frameworks; check PECR separately for any AI use involving marketing

• The DUAA 2025 replaced Article 22 with a broader framework that permits more solely automated significant decisions, provided information, representations, contestability and human intervention are genuinely available

• A DPIA is required only where processing is likely to result in high risk, assessed against ICO screening criteria, not automatically for every AI system

• Do not assume your AI vendor is automatically your processor; it can be an independent or joint controller depending on what it actually does with your data

• International transfers are a common blind spot with AI tools; check where a vendor actually processes and stores data, not just where it is marketed from

• Article 50 transparency duties have applied since 2 August 2026. Where the direct-interaction requirement applies, the system should inform people that they are interacting with AI unless that is already obvious. The EU AI Act's high-risk obligations have been deferred to December 2027 and August 2028

• There is currently no comprehensive UK AI Bill progressing through Parliament; businesses should plan around the existing legal and sector-regulatory framework as it stands today

About the Author

Rodi Taze is Co-Founder of AI Workforce. He works with UK businesses to map AI workflows, identify operational data protection questions and put practical documentation in place before deployment, alongside specialist legal advice where required.

Editorially reviewed and updated: August 2026

Compliance note: this article is general information, not legal advice. Data protection law affecting AI is actively developing, including ICO guidance still being updated to reflect the Data (Use and Access) Act 2025. Take independent legal advice for any AI deployment involving special category data, solely automated significant decisions, or cross-border data transfers.