AI and GDPR Compliance for UK Businesses: A Practical Guide

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. Mapping Personal Data Across the AI Lifecycle

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

6. Choosing and Documenting a Lawful Basis

7. Special Category and Biometric Data

8. Automated Decisions Under the Post-DUAA Rules

9. When You Need a DPIA

10. Vendors, Contracts and International Transfers

11. Transparency and Individual Rights

12. Data Accuracy, Testing and Human Oversight

13. When Does the EU AI Act Apply?

14. Employee Use of AI Tools

15. Records, Monitoring and Review

16. A Practical Compliance Checklist

17. Frequently Asked Questions

18. 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 obvious cases like a chatbot handling customer names and order details. It also covers a recruitment tool scoring CVs, a voice agent transcribing calls, a model fine-tuned on support tickets, and an internal tool that summarises staff emails.

UK GDPR does not create a separate lawful regime solely for AI; it applies the existing data protection framework to AI-related processing. AI does not create a separate regime simply because the technology is labelled AI. However, the way a system is used may trigger additional duties relating to matters such as automated decisions, special category or criminal offence data, high-risk processing that needs a DPIA, children's information, electronic marketing and international transfers. The starting question for any AI project is the same one that applies to 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 with technical amendments so it functions as a standalone UK regime. It sets 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 being replaced by it. It fills in areas UK GDPR leaves to individual countries, including provisions for law enforcement processing, national security, and specific exemptions.

The Data (Use and Access) Act 2025 amends both UK GDPR and the DPA 2018. It does not replace either. Its most significant change for AI is to the rules on automated decision-making, covered in detail below, but it also touches areas including scientific research processing and complaint handling. Several pieces of ICO guidance were still being updated to reflect it at the time of writing.

PECR, the Privacy and Electronic Communications Regulations, is a separate regime that governs electronic marketing, cookies and similar technologies. It is not a UK GDPR lawful basis, and having a lawful basis under UK GDPR does not automatically satisfy PECR. This matters directly for AI: if an AI tool sends marketing emails, texts or calls, PECR must be assessed separately from UK GDPR. Depending on the recipient, channel and circumstances, this may involve consent, the soft opt-in for existing customers, TPS or CTPS screening, suppression lists, identification requirements, or the stricter rules that apply to automated calls specifically.

Getting this right at the outset saves a lot of confusion later. 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.

Mapping Personal Data Across the AI Lifecycle

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

Collection: where does the data going into the system 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 being trained or fine-tuned on your own data? Training or fine-tuning on personal data is a materially different, and 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 as a result?

Monitoring and logging: call recordings, transcripts, prompts and outputs are commonly logged for quality, security and debugging. This logging is itself personal data processing and must be covered by an appropriate lawful basis, documented purpose, retention period and access controls. It does not necessarily need a different lawful basis from the main activity, but it does need to be accounted for. This applies directly to AI call centre agents, where call volume can make logging and retention decisions easy to overlook.

Review and deletion: what happens to the data once it is no longer needed, and how quickly can it actually be deleted, particularly if it has been used to train or fine-tune a model rather than simply stored in a database?

Mapping these stages is one of the most useful exercises for establishing the rest of the compliance position, because most of the harder questions, including lawful basis, DPIA screening, vendor contracts and retention, only become answerable once you know what happens to the data at each stage. If you are 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 specifically 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, not on the commercial relationship alone.

You are likely acting as the controller, with your vendor as processor, where the vendor processes personal data strictly on your instructions, for your purposes only, and does not use your data for its own purposes such as improving its general-purpose model.

A vendor may be an independent controller for some processing even while providing you a service, for example if it uses interactions with its tool to improve its own foundation model, for its own security and fraud purposes, or for its own analytics, beyond what you specifically instructed.

You and a vendor may be joint controllers where you jointly decide the purposes and means of some processing together, for example co-designing a scoring model or sharing decision-making responsibility for how an AI tool is configured and used.

Read the actual contract and the vendor's privacy documentation before assuming which of these applies, and check what the vendor's terms say about using your data to train or improve its own models. Some general-purpose AI services may retain or use prompts, outputs or feedback for service improvement under particular account types or default settings. Check the current product terms, privacy documentation and administrative controls rather than assuming consumer and enterprise accounts are treated the same way; this is an important point to check during an AI vendor review.

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

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:

• Using an AI tool to respond to a customer enquiry: contract may apply where the processing is objectively necessary to perform an existing contract with that individual, or to take steps they requested before entering one. A general enquiry from a prospect will not always meet that test; in other cases, legitimate interests may be more appropriate, subject to a documented necessity and balancing assessment.

• Sending marketing emails or texts drafted or personalised by AI: needs both a UK GDPR basis, commonly legitimate interests or consent, and separate compliance with PECR, which may require consent unless an applicable exception or different rule applies, such as the soft opt-in for existing customers or the different rules for corporate subscribers. Having a UK GDPR basis does not satisfy PECR, and having PECR consent does not by itself satisfy UK GDPR.

• Using AI to analyse employee data, for example emails, call transcripts or performance metrics: treating this as automatically covered by "part of the employment contract" is too broad. Monitoring and profiling employees engages fairness, proportionality and, often, the ICO's employment practices guidance separately; document a specific assessment rather than relying on the existence of an employment relationship alone.

• Using AI for fraud detection or security monitoring: legitimate interests may apply, subject to the purpose, necessity and balancing tests, although another basis may be more appropriate in a regulated or statutory context.

• Training or fine-tuning a model on customer or user data: requires its own assessment distinct from the basis used to originally collect that data; if people were told their data would be used to deliver a service, using it afterwards to train a model is a new purpose that needs its own lawful basis and, in many cases, fresh transparency to the people concerned.

• Legitimate interests generally: it is one of six equally valid bases, not a default fallback. Using it properly requires a documented legitimate interests assessment covering purpose, necessity and a balancing test against the individual's rights, not just an assumption that 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 data about sex life or sexual orientation, needs both a UK GDPR Article 6 lawful basis and a separate Article 9 condition before you can process it. An inferred characteristic can amount to special category processing where the system is deliberately used to infer that characteristic, or where the organisation intends to treat the person differently on the basis of that inference, regardless of how confident the inference actually is.

This is a genuine risk with generative AI and profiling tools specifically, because a model can infer or imply something about a protected characteristic, for example, inferring likely health status or ethnicity from writing style, images or behavioural patterns, without anyone deliberately designing it to do so. If your AI tool profiles people in a way that could reveal a special category, check this before deployment rather than after a complaint.

Biometric data used for the purpose of uniquely identifying a person, such as facial recognition or voice-based identity verification, is special category data and needs an Article 9 condition. A photograph or voice recording is not automatically biometric data in this sense; it becomes so when it is technically processed to create a template used for identification. Businesses using AI for identity verification, access control or fraud checks involving facial or voice matching should treat this as special category processing and assess it accordingly.

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 appropriate safeguards are in place. Those safeguards include giving the individual information about the decision, the ability to make representations, the ability to contest the decision, and the ability to obtain meaningful human intervention. The DUAA 2025 also gives the Secretary of State power to specify further safeguards and to clarify what counts as a "significant decision" in secondary legislation.

Special category data still sits under tighter conditions even within this broadened framework, and the general direction of the rules- meaningful information about the logic and significance of a decision, a working path to human review- remains the underlying protection individuals are entitled to, even though the specific legal mechanism has changed. The ICO's guidance on automated decision-making was still being finalised to reflect the DUAA 2025 at the time of writing, so treat this as an evolving area and check current guidance before finalising a significant automated decision workflow.

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.

A DPIA is required where the overall processing is likely to create a high risk. 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 on a large scale, use of innovative technology in combination with other risk factors, profiling used to decide access to a service, opportunity or benefit, large-scale profiling generally, or 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 an AI recruitment tool that profiles candidates at scale to shortlist for a role. Use the ICO's screening checklist for each AI system rather than assuming either that DPIAs never apply, or that every AI project automatically needs one. Where you decide 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, nature and purpose of processing, the types of personal data and categories of individuals involved, your rights and the vendor's obligations, security measures, conditions for using sub-processors, assistance with fulfilling individual rights requests, deletion or return of data at the end of the contract, and your right to audit. Standard vendor terms may not address every controller-specific requirement, so review the data processing addendum rather than relying only on product or marketing documentation.

International transfers are a frequent blind spot with AI tools specifically, because the underlying model provider may process or store data outside the UK even when the product is marketed to UK businesses, and this is not always obvious from the product interface. A restricted transfer, broadly, a transfer of personal data outside the UK where the recipient is not covered by UK adequacy regulations, requires an applicable transfer mechanism or exception: reliance on UK adequacy regulations for that country, an appropriate safeguard such as the UK's International Data Transfer Agreement, the UK Addendum to the EU's Standard Contractual Clauses, or binding corporate rules, or a specific, narrow exception where none of those apply. See the ICO's international transfers guidance for the full detail. Ask any AI vendor directly where your data, including prompts, transcripts and any data used for fine-tuning, is actually processed and stored, rather than assuming "the cloud" means it stays in the UK.

Transparency and Individual Rights

People are entitled to know when an AI system is processing their personal data and, in broad terms, what it is being used for and how significant decisions are made. Privacy information should explain the relevant purposes, personal data use, recipients or categories of recipients, retention and any significant automated decision-making. Where the use of AI materially affects how people's data is handled or how decisions are made, explaining that use explicitly is generally the clearest approach.

UK GDPR rights, including access, rectification, erasure, restriction, objection and portability, may apply to personal 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 being carried out by automated means, and erasure and objection each carry their own exceptions. Two of these rights are genuinely harder to fulfil with AI than with a conventional database. Rectifying or erasing data that has been baked into a trained or fine-tuned model, rather than simply stored in a record, is technically difficult, and vendors vary considerably in what they can actually do about it; ask how a vendor handles a deletion or correction request that touches training data before you rely on that capability being straightforward. Where the automated decision transparency provisions apply, you should also be able to provide meaningful information about the main factors involved, the significance of the processing and its likely consequences; this does not generally mean disclosing source code or every internal model calculation, and it is not automatically required for every subject access request that happens to involve an AI tool.

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, a false criminal record, or an incorrect account of an event involving them. This is a live, recognised data protection issue, not a hypothetical one, and it engages the accuracy principle directly: inaccurate personal data about someone, generated by your AI system, must be addressed through appropriate accuracy, correction and challenge processes where your organisation is responsible for that processing.

Testing an AI system before deployment, and monitoring it afterwards, is part of demonstrating accountability, not an optional quality step. This means testing with realistic inputs, checking outputs for errors involving real individuals, having a route for someone to challenge or correct an AI-generated statement about them, and reviewing performance periodically rather than treating a go-live date as the end of the process. Meaningful human oversight- someone genuinely able to review, question and override an output- matters here as much as it does for automated decision-making specifically.

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, depending on your activities. 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 in the EU, to providers and deployers established in the EU, and to providers and deployers outside the EU where the output produced by the AI system is used in the EU. A UK business with no EU presence can still fall in scope if it is providing a system used in the EU market or if the system's output is used there; 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 significantly during 2026. Prohibited practices and AI literacy obligations have applied since 2 February 2025. Governance rules for general-purpose AI models have applied since 2 August 2025. From 2 August 2026, Article 50 transparency obligations apply. Providers of AI systems intended to interact directly with people must design them so individuals are informed that they are interacting with AI, unless this is already obvious from the circumstances; providers and deployers may have additional transparency duties depending on the system and use case. Following a political agreement on a Digital Omnibus package reached in May 2026 and in force from late July 2026, the main high-risk obligations for standalone systems listed in Annex III have been deferred to 2 December 2027, and high-risk obligations for AI embedded in already-regulated products under Annex I have been deferred to 2 August 2028.

For most UK small and medium businesses using AI for customer service, sales, or internal operations, this means transparency disclosure is the most immediately relevant EU AI Act obligation right now, rather than the high-risk system requirements that dominate a lot of earlier commentary. Our guide to AI agents for small businesses covers where this kind of transparency duty typically applies in practice. That said, the compliance runway for high-risk obligations is shorter than it looks. If your AI use might fall into a high-risk category, for example in recruitment, credit scoring or safety-relevant functions, it is worth understanding the requirements now rather than waiting until closer to the new deadlines.

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 is increasingly common across businesses, and it can create data protection exposure that a general IT policy does not fully address. A clear acceptable-use policy should set out what categories of data staff may and may not paste into a public AI tool, particularly customer personal data, special category data and confidential business information, which AI tools are approved for work use and under what account type, since free-tier consumer accounts frequently have different data-use terms to enterprise agreements, and how AI-assisted work should be reviewed before it is relied upon or sent externally.

AI note-takers and meeting transcription tools deserve their own specific mention, since they are now common in day-to-day use. Recording and transcribing a meeting involving other people's personal data needs its own lawful basis and, in most cases, needs those participants to be told the meeting is being recorded and transcribed by an AI tool, not just that "the meeting is being recorded" in general terms. Where an AI note-taker is used with external parties, check whether their own policies permit it.

Finally, if AI is used to inform decisions about staff, for example screening internal applications, monitoring productivity 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 to understand, at a meaningful level, how it affects them.

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. Maintain a record of processing that specifically identifies AI systems, the personal data involved, the lawful basis, and whether the system makes or informs decisions about people. Keep DPIAs, legitimate interests assessments and vendor due diligence documentation up to date as systems change, not just at initial launch. Log AI-generated outputs and decisions to a degree proportionate to the risk involved, so that a specific decision can be explained and reviewed later if challenged. Review AI systems on a schedule, since model updates, prompt changes and new use cases can all shift the risk profile of a system that was assessed as low risk when it launched. Retire or reassess systems that no longer match their original documented purpose.

A Practical Compliance Checklist

Data and purpose

• We have listed every AI system in use across the business, including tools individual staff have adopted informally

• We know what personal data each AI system processes, and at which lifecycle stage

• We have a documented lawful basis for each AI system's use of personal data

• We have checked PECR separately for any AI 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

• Where a decision is solely automated with a significant effect, individuals can get meaningful information, make representations, contest the decision and obtain human intervention

• Our privacy notices explain the relevant processing, including any significant automated decision-making, in a meaningful way

• 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 we are joint controllers

• We have reviewed our AI vendor contracts for genuine Article 28 processor terms, and checked what happens to our data if it is used to improve the vendor's own model

• 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, and documented the outcome either way

• We have assessed whether the EU AI Act applies to any of our AI activities, and specifically checked 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

• We have a retention period defined for AI logs, transcripts and training data, not an indefinite default

• We have a named owner for AI compliance, not just an IT or product owner for the tool itself

• 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 on who built the underlying model. Using a third-party AI tool does not remove your obligations; it adds a vendor relationship you need to assess alongside them.

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 are often more appropriate for routine AI-supported customer service, 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 on its own almost certainly does.

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 actual contract and the vendor's own data-use terms. A vendor can be a processor, an independent controller for some of its own purposes, 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. These can often be addressed once identified, but they are easy to overlook unless vendor location, retention and DPIA screening are included in the review process.

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.

Reviewed: August 2026

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.