GDPR and AI: what you need to know

GDPR and AI: What You Actually Need to Know

Most professionals who use ChatGPT, Claude, or Gemini at work assume they have a reasonable handle on GDPR compliance. They've sat through the data protection training, they know not to email customer lists to strangers, and they figure AI tools are just another piece of software covered by the same rules. That assumption is wrong in ways that carry real legal and reputational risk. GDPR was written before large language models existed as commercial products, and the regulation's core concepts — consent, purpose limitation, data minimisation — apply to AI in ways that are genuinely surprising, even to experienced compliance teams. Three beliefs in particular show up repeatedly among smart professionals who are new to AI, and all three are either false or dangerously incomplete.

Myth 1: 'We Agreed to the Terms of Service, So We're Covered'

When a company signs up for ChatGPT Enterprise or Claude's API, they receive a Data Processing Agreement (DPA) from OpenAI or Anthropic. Many compliance officers file that DPA and consider the matter closed. The logic feels sound: GDPR requires a DPA between data controllers and processors, you have one, therefore you're compliant. But a DPA only governs what the vendor does with data. It says nothing about whether your organisation had a lawful basis to input that data into the AI system in the first place. Those are two entirely separate legal questions, and conflating them is one of the most common GDPR mistakes in AI deployments today.

Consider a marketing analyst who pastes a spreadsheet of 500 customer email addresses, purchase histories, and demographic data into ChatGPT to ask it to segment the audience. The analyst's company may have a perfectly valid DPA with OpenAI. But the customers whose data just entered that prompt never consented to their personal information being processed by a third-party AI system. The original lawful basis for collecting that data — probably contract performance or legitimate interests for marketing — almost certainly did not anticipate that use. Under GDPR Article 5(1)(b), the purpose limitation principle requires that data collected for one purpose not be repurposed in ways incompatible with the original intent. Feeding customer records into a generative AI tool is almost always a new purpose that needs its own legal justification.

There's a further complication with free-tier and consumer-facing AI tools. OpenAI's standard ChatGPT (non-Enterprise) terms historically allowed the company to use conversation data to improve its models, though users can opt out. If an employee uses a free ChatGPT account for work tasks and pastes in personal data about colleagues, clients, or customers, the organisation may have no DPA at all — and the employee has potentially triggered an unauthorised data transfer. The Italian data protection authority, the Garante, temporarily banned ChatGPT in March 2023 for exactly this kind of systemic failure. The ban lasted a month and ended only after OpenAI implemented specific transparency and data-rights mechanisms for Italian users.

Myth 2: 'AI Tools Don't Store My Data, So There's No GDPR Issue'

A second myth is the 'it's just a chat window' fallacy — the belief that because a conversation disappears when you close the browser, no meaningful data processing has occurred. This misunderstands what GDPR means by processing. Under Article 4(2), processing includes collection, recording, organisation, structuring, storage, adaptation, retrieval, consultation, use, disclosure, dissemination, and erasure. The moment personal data enters an AI model's context window, processing has occurred — regardless of whether the vendor retains that data afterward. The transmission itself is processing. The inference the model performs on that data is processing. Even a zero-retention policy on the vendor's side doesn't undo the fact that your organisation transferred personal data to a third-party system.

The data transfer angle is particularly significant for European organisations using US-based AI services. ChatGPT, Claude, Gemini, and GitHub Copilot are all operated by US companies. Sending personal data to their servers constitutes an international data transfer under GDPR Chapter V. Since the invalidation of Privacy Shield in 2020 (Schrems II), such transfers require either Standard Contractual Clauses (SCCs), Binding Corporate Rules, or a specific adequacy decision. The EU-US Data Privacy Framework, adopted in July 2023, restored a mechanism for transfers to certified US companies — OpenAI, Anthropic, and Google are among the companies that have pursued certification — but your legal team still needs to verify certification status and document the transfer basis. Assuming it's fine because the company is well-known is not a compliance strategy.

Even within an enterprise-grade deployment with full data residency in the EU — Microsoft Azure OpenAI Service offers EU data residency, for example — the 'no storage, no problem' logic still fails for a different reason. If a model is fine-tuned on your organisation's data, or if retrieval-augmented generation (RAG) pipelines pull from databases containing personal information, that data is absolutely being stored and processed in ways that trigger full GDPR obligations including data subject access rights, retention limits, and the right to erasure. The architecture of modern AI deployments is rarely as simple as 'prompt in, answer out, nothing retained.'

Myth 3: 'GDPR Is a European Problem — It Doesn't Affect Our Global AI Use'

Non-European companies routinely dismiss GDPR as someone else's regulation. This is legally incorrect. GDPR's territorial scope, defined in Article 3, follows the data subject, not the company's headquarters. If your US, Australian, or Singapore-based organisation processes personal data about people who are in the EU — customers, website visitors, job applicants, research participants — GDPR applies to that processing. The regulation's extraterritorial reach has been enforced in practice: Meta was fined €1.2 billion by the Irish DPC in May 2023, and that fine directly concerned the transfer of EU user data to US servers, a core AI infrastructure issue. The question 'does GDPR apply to us?' is almost always answered yes for any organisation operating at scale with international users.

Beyond strict legal applicability, GDPR has become the de facto global standard that other privacy regimes benchmark against. Brazil's LGPD, California's CPRA, Canada's proposed Bill C-27, and India's Digital Personal Data Protection Act 2023 all share GDPR's conceptual DNA — consent requirements, purpose limitation, data minimisation, and rights for individuals. If your AI data practices are GDPR-compliant, you're well-positioned for most other jurisdictions. If they're not, you likely have compliance gaps across multiple regimes simultaneously. The EU AI Act, which entered into force in August 2024, adds a further layer specifically for AI systems — including requirements that interact directly with GDPR obligations around automated decision-making and high-risk AI use cases.

What Actually Works: Building GDPR-Compliant AI Practices

The organisations that handle this well start with a data classification framework before they deploy any AI tool. This means categorising the types of data employees work with daily — customer records, employee data, financial information, health data — and establishing clear rules about which categories can enter which AI systems. Microsoft Purview, for example, integrates with Microsoft 365 Copilot to apply data sensitivity labels that can block certain classified content from being processed by the AI. Even without enterprise tooling, a simple internal policy that says 'no special category data, no identified customer records, no employee personal data in public AI tools' gives employees a workable rule and creates an audit trail showing the organisation took reasonable steps.

Anonymisation and pseudonymisation are underused tools in this context. GDPR does not apply to truly anonymised data — data from which individuals cannot be identified, directly or indirectly, even with additional information. If an analyst needs to ask ChatGPT to analyse customer feedback patterns, replacing actual customer names and email addresses with generic identifiers (Customer_001, Customer_002) before inputting the data removes the personal data element entirely, assuming the remaining data isn't re-identifiable from context. Pseudonymisation — replacing identifiers with codes while keeping the key separately — doesn't remove GDPR applicability, but it does reduce risk and satisfies the data minimisation principle under Article 5(1)(c). The discipline of stripping out personal identifiers before AI prompts should become as automatic as checking the 'To' field before sending an email.

Documentation is the third pillar. GDPR's accountability principle, Article 5(2), requires organisations to demonstrate compliance — not just achieve it. For AI tools, this means updating your Record of Processing Activities (RoPA) to include AI-assisted processing, conducting Data Protection Impact Assessments (DPIAs) for high-risk AI use cases, and keeping records of which AI vendors you use, under what contractual terms, and for what purposes. The Article 29 Working Party guidelines (now the European Data Protection Board) specify that DPIAs are required for systematic processing using new technologies, automated decision-making with significant effects, and large-scale processing of sensitive data — all of which commonly arise in enterprise AI deployments. A DPIA is not a bureaucratic formality; it's a structured risk assessment that frequently surfaces practical problems before they become regulatory incidents.

Frequently Asked Questions

• Can we use ChatGPT for work tasks if we have a paid subscription? A paid ChatGPT Plus subscription is an individual consumer product — it does not include a Data Processing Agreement. For work use involving personal data, you need ChatGPT Enterprise or the OpenAI API with a signed DPA.
• Does anonymising data before inputting it into AI fully remove GDPR obligations? Truly anonymised data falls outside GDPR's scope, but anonymisation must be irreversible and robust. Pseudonymised data — where a key exists to re-identify individuals — is still personal data under GDPR and remains subject to the regulation.
• Is Microsoft 365 Copilot GDPR-compliant out of the box? Microsoft provides a DPA and EU data residency options for 365 Copilot, but compliance still requires your organisation to have a lawful basis for the underlying data processing, properly configured sensitivity labels, and a completed DPIA if the use case is high-risk.
• What is the maximum GDPR fine for misusing personal data in AI tools? GDPR fines reach up to €20 million or 4% of global annual turnover, whichever is higher. For reference, Meta's €1.2 billion fine in 2023 was calculated at 4% of global revenue and related directly to data transfer practices.
• Do employees need specific training on GDPR and AI? Yes — and generic GDPR training is insufficient. Employees need role-specific guidance on which AI tools are approved, what data they can input, and how to anonymise data before using AI. Regulators increasingly treat inadequate training as evidence of systemic non-compliance.
• Does the EU AI Act replace or supplement GDPR for AI use cases? The EU AI Act supplements GDPR — it doesn't replace it. The AI Act focuses on risk classification of AI systems and prohibited uses, while GDPR governs personal data processing. High-risk AI systems under the AI Act will typically also trigger GDPR obligations, and organisations must comply with both simultaneously.

Key Takeaways

1. A DPA with your AI vendor is necessary but not sufficient — your organisation independently needs a documented lawful basis under GDPR Article 6 before inputting personal data into any AI system.
2. GDPR processing begins the moment personal data enters an AI context window — transmission and inference are processing activities even if the vendor retains nothing afterward.
3. GDPR applies to any organisation processing EU residents' data, regardless of where the organisation is headquartered — extraterritorial enforcement is real and increasing.
4. Free consumer AI tools (standard ChatGPT, free Gemini) lack DPAs and are not appropriate for any work use involving personal data.
5. True anonymisation removes data from GDPR's scope; pseudonymisation reduces risk but does not remove GDPR obligations.
6. The accountability principle requires documented evidence of compliance: updated RoPA entries, DPIAs for high-risk use cases, and records of vendor transfer mechanisms.
7. GDPR compliance for AI is a cross-functional responsibility — legal, IT, HR, and operational leads all have roles that cannot be delegated entirely to any single team.

Myth 1: Anonymising Data Before Sending It to AI Tools Means You're GDPR-Safe

This belief is so widespread that entire internal AI policies have been built around it. The logic feels airtight: strip out names and email addresses, and the data is no longer personal. GDPR no longer applies. You're free to feed it into ChatGPT or Claude without a second thought. The problem is that this mental model was built for a world of simple databases — not for large language models that can cross-reference, infer, and reconstruct identity from seemingly innocuous fragments. Anonymisation is not a binary switch. It exists on a spectrum, and the GDPR's own guidance, reinforced by the Article 29 Working Party's Opinion 05/2014 on anonymisation techniques, makes clear that data is only truly anonymous if re-identification is 'reasonably impossible' — a bar that is far harder to clear than most professionals realise.

Consider what 'anonymised' often looks like in practice: you remove a customer's name but leave their job title, company size, industry sector, region, and complaint history. Any decent analyst — human or AI — can re-identify that individual with high confidence. Researchers at MIT demonstrated this in a landmark 2015 study, showing that just four spatiotemporal data points were enough to uniquely identify 95% of individuals in a supposedly anonymised mobile dataset. LLMs don't even need four points. They pattern-match across everything in your prompt simultaneously, and if your 'anonymised' dataset is rich enough, the model can surface inferences that effectively reconstruct identity — inferences that your output then contains. At that point, you've processed personal data, and the legal obligation attached to that processing follows you regardless of what you called the data going in.

The better mental model is pseudonymisation, not anonymisation — and even that comes with strings attached. GDPR explicitly names pseudonymisation as a risk-reduction technique (Article 25), not an exemption from compliance. Pseudonymised data — where names are replaced with tokens but re-identification is possible with a key — is still personal data under the Regulation. If you pseudonymise a dataset and send it to an AI vendor, you still need a Data Processing Agreement with that vendor, you still need a lawful basis for the transfer, and if that vendor is outside the EEA, you still need to address international transfer rules. Pseudonymisation reduces your risk profile in the event of a breach; it does not dissolve your compliance obligations.

Myth 2: Your AI Vendor's Privacy Policy Covers Your Compliance Obligations

When a professional signs up for a business tier of an AI tool, reads the privacy policy, sees the words 'we do not train on your data' and closes the browser — they feel covered. This is understandable. Privacy policies are designed to be reassuring. But a vendor's privacy policy addresses the vendor's obligations to you as a customer. It does not — and legally cannot — address your obligations to the data subjects whose information you are processing through that tool. These are two entirely separate legal relationships, and confusing them is one of the most consequential GDPR mistakes organisations make with AI tools today.

Here is what actually governs the relationship between your organisation and an AI vendor from a GDPR standpoint: a Data Processing Agreement. Article 28 of GDPR mandates that when a controller (you) engages a processor (the AI vendor) to handle personal data on your behalf, a DPA must be in place. This agreement must specify the subject matter and duration of processing, the nature and purpose, the type of personal data and categories of data subjects, and the obligations and rights of the controller. OpenAI, Anthropic, Google, and Microsoft all offer DPAs for their enterprise and API tiers — but many organisations are using free or basic consumer tiers, where no DPA exists, which means any personal data processed through those tiers is being handled without the legal framework GDPR requires.

The stakes here are concrete. In 2023, Italy's data protection authority, the Garante, temporarily banned ChatGPT specifically because OpenAI lacked a transparent legal basis for processing Italian users' data and had no mechanism for data subjects to exercise their rights. The ban was lifted after OpenAI made structural changes — but the episode demonstrated that supervisory authorities are willing to act against AI tools at scale, and that 'the vendor has a privacy policy' is not a defence. Your organisation needs its own documented basis for processing, its own DPA with the vendor, and its own record of processing activities (ROPA) that includes AI tools as data processors.

Myth 3: GDPR Only Applies to the Data You Deliberately Share

The third myth is perhaps the most subtle — and the most dangerous for organisations that have done everything else right. The belief is this: as long as your team is careful about what they type into AI tools, you're managing your GDPR exposure. But GDPR's scope is not limited to deliberate data sharing. It covers any processing of personal data, and 'processing' is defined extraordinarily broadly in Article 4(2) to include collection, recording, organisation, structuring, storage, adaptation, retrieval, consultation, use, disclosure, erasure — essentially any operation performed on personal data, whether automated or not. When an employee pastes a document into ChatGPT to summarise it, and that document happens to contain a single reference to a named individual, GDPR is triggered — whether or not the employee noticed the name was there.

This has practical implications for how organisations govern AI use at the workflow level, not just the policy level. A marketing analyst summarising a competitor report might not realise it contains a named executive's salary projection. A consultant drafting a slide deck might paste in interview notes that include a client contact's direct quote attributed by name. A manager asking an AI to reformat a spreadsheet might not notice the spreadsheet has a 'Notes' column with personal details. None of these people intended to share personal data — but under GDPR, intent is irrelevant. What matters is whether personal data was processed. This is why governance frameworks need to go beyond training employees on what not to share, and extend to building technical controls — like input scanning, approved template libraries, and pre-submission review checklists — that catch inadvertent sharing before it happens.

What Actually Works: Building a Defensible AI Data Governance Framework

Understanding what the myths get wrong is only useful if it drives better practice. The organisations that have navigated GDPR and AI most successfully share a common structural approach: they treat AI tools as data processors from day one, they build governance at the workflow level rather than the policy level, and they designate someone — a DPO, a privacy lead, or a trained AI governance owner — with explicit accountability for keeping the framework current. This last point matters more than it might seem. GDPR's accountability principle (Article 5(2)) requires not just that you comply, but that you can demonstrate compliance. A policy document that nobody owns, that was written eighteen months ago and hasn't been updated since your organisation adopted three new AI tools, is not a defensible position.

The practical architecture of a defensible framework has four layers. First, a tiered approved-tools list: tools are categorised by data sensitivity tier, with clear rules about which categories of data each tier can handle. ChatGPT Enterprise and Claude for Teams, with signed DPAs, might sit in Tier 1 — approved for pseudonymised operational data. Consumer-tier tools sit in Tier 3 — approved only for non-personal, non-confidential tasks. Second, a pre-use data classification habit: before any AI interaction involving work data, employees run a ten-second mental check (or a literal checklist) against four questions — Does this contain names? Roles linked to individuals? Behavioural or financial data? Data from a restricted jurisdiction? Third, a DPA register: a living document tracking every AI vendor, their DPA status, their data residency commitments, and the date of last review. Fourth, a breach response protocol specific to AI: what happens if an employee realises they pasted a document containing personal data into an unapproved tool.

The breach response protocol deserves particular attention because it's the layer most organisations skip entirely. Under GDPR Article 33, a personal data breach must be reported to the relevant supervisory authority within 72 hours of becoming aware of it — if it's likely to result in a risk to individuals' rights and freedoms. 'I accidentally sent client data to ChatGPT's consumer tier' is a breach. The 72-hour clock starts the moment your employee tells their manager. If you have no protocol, that 72 hours evaporates in internal confusion while you try to figure out who to call. Organisations that have run tabletop exercises on AI-specific breach scenarios — where did the data go, can the vendor confirm deletion, what was the likely risk level — respond faster, report more accurately, and face lighter regulatory scrutiny as a result.

Frequently Asked Questions

• Can we use ChatGPT Free or Claude.ai (free tier) for any work tasks? Only for tasks that involve zero personal data and no confidential business information — think brainstorming generic content or drafting public-facing copy from scratch. Consumer tiers have no DPA and may use inputs for model training, making them unsuitable for anything involving individuals' data.
• Does GDPR apply if our company is based outside the EU but we have EU customers? Yes. GDPR's territorial scope (Article 3) applies to any organisation that processes personal data of individuals in the EU, regardless of where the organisation itself is established. Having EU customers means GDPR applies to how you handle their data through AI tools.
• What counts as a 'lawful basis' for using AI tools to process personal data? The six lawful bases under Article 6 include consent, contract, legal obligation, vital interests, public task, and legitimate interests. For most commercial AI use cases, legitimate interests (Article 6(1)(f)) or contract performance are the most commonly relied upon — but each requires a documented assessment, not just a label.
• If an AI vendor says they don't store my data, does that mean no DPA is needed? No. Even transient processing — data passing through a system and being deleted immediately — constitutes processing under GDPR. A DPA is required whenever a processor handles personal data on your behalf, regardless of retention duration.
• How do we handle employee data — for example, using AI to analyse staff survey responses? Employee data is personal data. Using AI to process it requires a lawful basis (typically legitimate interests or legal obligation), a DPA with the AI vendor, and — if the processing is likely to result in high risk — a Data Protection Impact Assessment (DPIA) under Article 35.
• What happens if a supervisory authority audits our AI tool usage and we don't have DPAs in place? Fines under GDPR Article 83(4) for failing to meet processor obligations (including Article 28 DPA requirements) can reach €10 million or 2% of global annual turnover, whichever is higher. Beyond fines, supervisory authorities can issue processing bans — as Italy did with ChatGPT in 2023 — which can halt business operations.

Key Takeaways from This Section

1. Anonymisation is not a GDPR exemption unless re-identification is genuinely impossible — rich datasets rarely clear this bar, and pseudonymised data remains in-scope personal data.
2. A vendor's privacy policy is not a Data Processing Agreement. Article 28 requires a formal DPA; without one, any personal data processed through that tool is handled outside your legal framework.
3. GDPR covers all processing of personal data, not just deliberate sharing — inadvertent inclusion of personal data in an AI prompt triggers the same obligations as intentional processing.
4. Consumer-tier AI tools are categorically different from enterprise tiers for compliance purposes: no DPA, potential training data use, and no contractual data residency commitments.
5. A defensible governance framework operates at four layers: an approved-tools list, a pre-use data classification habit, a live DPA register, and an AI-specific breach response protocol.
6. The 72-hour breach notification clock under Article 33 starts the moment your organisation becomes aware of a breach — not when legal completes their review. Protocol clarity before an incident is essential.
7. Quarterly governance reviews are the minimum cadence for keeping AI data policies current given the pace of AI tool development and vendor policy changes.

GDPR and AI: The Myths That Put Your Organisation at Risk

Most professionals operating with AI tools carry three beliefs that feel reasonable but collapse under scrutiny. First: that anonymising data before feeding it to an AI tool removes all GDPR obligations. Second: that using a reputable vendor like Microsoft or Google means compliance is handled for you. Third: that GDPR only applies when something goes wrong — a breach, a complaint, a fine. Each of these beliefs leads to real decisions that real regulators have already penalised. Understanding exactly where and why they fail gives you a far more durable compliance posture than any checklist.

Myth 1: Anonymised Data Is Outside GDPR's Reach

Anonymisation sounds like a clean solution. Strip out names, swap in IDs, remove postcodes — and suddenly you're handling data that GDPR no longer governs. The regulation itself supports this reading: truly anonymous data falls outside its scope. The problem is the word 'truly.' The Article 29 Working Party (now the European Data Protection Board) has consistently held that anonymisation must be irreversible and robust against re-identification — a bar that most operational anonymisation techniques do not clear. When you feed a large language model 'anonymised' customer records, the model may retain statistical patterns that, combined with other data, re-identify individuals.

Re-identification risk is not theoretical. In 2019, researchers re-identified 99.98% of individuals in an 'anonymised' dataset using just 15 demographic attributes. AI models trained or prompted on pseudonymised data can surface quasi-identifiers — job titles, team sizes, project names — that make re-identification straightforward for anyone with moderate context. The GDPR test is not whether you removed obvious identifiers; it is whether re-identification is reasonably possible by anyone, including the AI vendor processing the data on your behalf.

The better mental model is to treat anonymisation as a spectrum, not a switch. Techniques like k-anonymity, differential privacy, and data synthesis move data further along that spectrum, but each requires validation. Before routing data through ChatGPT, Claude, or any external AI, ask: could a motivated actor with access to public data re-identify these records? If the honest answer is 'possibly,' GDPR still applies, and you need a lawful basis for the processing.

Myth 2: Your Vendor's Compliance Covers Your Compliance

Microsoft, Google, and OpenAI publish detailed compliance documentation. They hold ISO 27001 certifications, sign Data Processing Agreements, and operate under EU Standard Contractual Clauses. It is easy to read this and conclude that using their AI products makes you compliant by association. It does not. Under GDPR, you are the data controller. The vendor is your data processor. The controller determines the purposes and means of processing — and bears primary accountability for ensuring that processing has a lawful basis, that data subjects' rights are honoured, and that privacy impact assessments are conducted where required.

The DPA with your vendor is a necessary condition, not a sufficient one. It governs how the processor handles data on your instruction. It says nothing about whether your instruction itself is lawful. If you direct Microsoft Copilot to process employee health data to generate productivity reports, and you lack explicit consent or another lawful basis for that purpose, the DPA is irrelevant — you have violated GDPR regardless of how well Microsoft handles the data technically. The French data protection authority (CNIL) fined a company in 2022 precisely because it used a compliant cloud vendor for a purpose that lacked lawful basis.

Practically, this means your compliance obligations begin before you open any AI tool. You need to identify the personal data involved, confirm your lawful basis (consent, legitimate interest, contract, etc.), check whether a Data Protection Impact Assessment is required (mandatory for high-risk processing under Article 35), and verify your DPA with the vendor covers the specific processing activity. The vendor's compliance infrastructure supports your compliance; it does not replace it.

Myth 3: GDPR Only Matters When Something Goes Wrong

The breach-triggers-compliance mindset is widespread and genuinely dangerous. GDPR is not a reactive framework — it is a proactive one. The regulation requires privacy by design and by default (Article 25), meaning compliance must be built into systems and processes from the start, not retrofitted after an incident. Regulators assess organisations' ongoing practices, not just their incident response. The UK ICO's £17.5 million fine against British Airways in 2020 was not solely about the breach itself; it was about the systemic absence of adequate technical and organisational measures that made the breach possible.

For AI tools specifically, this means maintaining records of processing activities (Article 30) that include AI-assisted workflows, conducting DPIAs before deploying high-risk AI systems, and reviewing those assessments when the AI tool is updated or its use expands. Supervisory authorities in Germany and the Netherlands have begun auditing organisations' AI usage proactively — not waiting for complaints. The cost of a reactive posture is not just fines; it includes remediation, reputational damage, and the operational disruption of having to halt AI workflows mid-project.

What Actually Works: Building a Defensible AI Compliance Practice

Effective GDPR compliance for AI tools is built on three habits: classify before you process, document as you go, and review when things change. Classification means knowing, before any AI task begins, whether the data involved is personal, special category, or genuinely anonymous — and which lawful basis applies. This takes two to five minutes for routine tasks and prevents the most common violations. Organisations that build this into their AI usage policies — even informally — dramatically reduce their exposure compared to those that treat each AI interaction as a one-off judgment call.

Documentation is where most teams fall short, because it feels like overhead. But Article 30 records of processing activities and Article 35 DPIAs are also your best defence if a regulator ever asks questions. A lean DPIA template for AI tasks — covering the data involved, the purpose, the lawful basis, the risks, and the mitigations — takes under an hour to complete for a standard workflow. Tools like OneTrust, TrustArc, and even well-structured Notion databases can make this manageable without a dedicated compliance team. The discipline of documentation also forces you to think clearly about what you're actually doing with data.

Review cadence matters because AI tools evolve fast. ChatGPT's data handling policies changed three times between 2023 and 2024. Gemini introduced new enterprise data retention options in mid-2024. When a tool updates its terms, your existing DPA and lawful basis assessment may no longer be valid for the same workflow. Schedule a quarterly review of the AI tools your team uses, cross-referenced against your processing records. This is not a legal formality — it is how you avoid discovering a compliance gap at the worst possible moment.

Frequently Asked Questions

• Can I use ChatGPT for client work without a DPA? Not if any personal data is involved. OpenAI offers a Data Processing Addendum for ChatGPT Team and Enterprise plans — free consumer accounts do not include one, making them unsuitable for personal data processing.
• Is a legitimate interest assessment (LIA) the same as a DPIA? No. An LIA documents why legitimate interest applies as a lawful basis for a specific processing activity. A DPIA is a broader risk assessment required for high-risk processing, regardless of which lawful basis you use.
• Do GDPR rules apply if I'm based outside the EU? Yes, if you process personal data of people in the EU or EEA, GDPR applies to you — regardless of where your organisation is based. This is the extraterritorial scope defined in Article 3.
• What counts as 'high-risk' processing that triggers a DPIA? Processing that is large-scale, involves special category data, uses systematic profiling, or applies automated decision-making with significant effects on individuals. AI tools used for performance scoring, credit assessment, or health analysis typically qualify.
• If an employee pastes personal data into an AI tool without authorisation, who is liable? The organisation is liable as data controller — employee actions taken in the course of work bind the employer. This is why acceptable use policies for AI tools are a compliance necessity, not just an IT preference.
• How often should I review vendor DPAs? At minimum annually, and immediately whenever a vendor updates its terms of service or data handling policies. Set up alerts for vendor policy change announcements — Microsoft, Google, and OpenAI all publish these.

1. Anonymisation under GDPR requires irreversibility — pseudonymisation (replacing identifiers with codes) still falls within the regulation's scope.
2. You are the data controller when using AI tools; vendor compliance certifications and DPAs support your compliance but do not substitute for it.
3. GDPR is proactive: privacy by design (Article 25) requires compliance to be built into AI workflows from the start, not applied after incidents.
4. Lawful basis must be established before processing begins — the six options are consent, legitimate interest, contract, legal obligation, vital interests, and public task.
5. Article 35 DPIAs are mandatory for high-risk AI processing and serve as your primary documentation defence with regulators.
6. AI tool terms and data handling policies change frequently; quarterly review of your processing records keeps your compliance posture current.
7. A simple pre-task checklist — data type, lawful basis, DPA coverage — prevents the majority of common GDPR violations in AI workflows.