Using AI without breaking GDPR
If you handle other people's personal data, client names, emails, notes from a call, then GDPR applies to how your system uses AI. This module covers the few things you need to understand to stay on the right side of it, in plain language.
Last reviewed: June 2026. The rules and the platform terms change over time, so re-check the linked sources and this page now and then.
Important: this is for reflection, not legal advice
Every business, system, and setup is different, and this module explains the general principles so you know what to ask and what to check. Nothing in this course or in your system is automatically GDPR compliant. Compliance is your responsibility as the person running your business. It sits with you, not with The Four Languages and not with the tools you use. This module is for reflection, so for your own situation, always get advice from a lawyer in your own country.
Who this applies to
GDPR is European law. It covers you if you or your business sit in the European Union or the wider European Economic Area, and it can still reach you from outside Europe when you handle the personal data of people who are in the EU. The United Kingdom runs its own near-identical version, called UK GDPR.
If you and all of your clients are fully outside these places, GDPR may not apply to you. Your own country will still have its own privacy law, so check what actually applies where you and your clients are. The links at the bottom of this page point to the law itself.
Start here: the terms you run Claude under
There are two ways to run Claude inside your system, and only one of them is built for client data.
A personal Claude subscription (Free, Pro, or Max) runs on Anthropic's Consumer Terms. Those terms let Anthropic use your content to improve its models unless you switch training off in settings, and they come with no data-processing agreement. Turn the switch off either way, and know its limits: the data-protection lawyers in our session were clear that the switch does not change the GDPR picture, because with or without it, a personal plan still has no data-processing agreement. For a business handling client personal data, consumer terms are a suboptimal footing.
Anthropic's Commercial Terms work differently. They cover the API and the Console, and the Team and Enterprise plans. Under them, Anthropic may not train models on your content, and Anthropic's data-processing agreement (the DPA) is built into the terms by reference. For customers in the European Economic Area, the contract is with Anthropic Ireland, Limited, and the DPA carries the EU Standard Contractual Clauses.
The Commercial Terms take effect on their own. In Anthropic's words, they are effective on the earlier of the date you first electronically consent to them and the date you first access the services. In practice: creating a Console account, or making your first API call, is the moment they bind, and the data-processing agreement binds at the same moment because it is part of the terms. Adding credit or creating an API key involves nothing further to sign.
A personal subscription is still fine for your own drafting and anything that holds no real person's data. What decides it is whether real personal data is involved.
Claude Code follows whichever account it is signed into, in the same terminal, on the same machine. Signed in with a personal Pro or Max plan, your sessions run on the Consumer Terms. Signed in with a Console account or an API key, the same sessions run on the Commercial Terms, with the data-processing agreement in force. Switch with /login inside Claude Code, and check which account you are on before client data goes in.
The honest version, because this is where people overpromise
Being on Anthropic's Commercial Terms is the footing you need, and it is also where the limits start. The data-processing agreement is built into the standard terms, which means you accept it by using the service rather than getting a separate, negotiated agreement signed for you. For some situations, and especially when your own clients ask you for a signed agreement, that standard arrangement can fall short, and a Team or Enterprise plan is the firmer route. Read the terms yourself (linked at the bottom), check what your own account actually puts in place, and get legal advice for anything serious. Being on the right terms makes a processor agreement exist. Staying compliant is still on you.
What counts as personal data
Personal data is any information that points to a real, identifiable person. Client names and emails, obviously. Also your notes about a client, a contact's history in your system, and details inside a document that identify who wrote it. If a real person can be picked out from it, treat it as personal data.
The cleanest escape: take the personal data out
If you strip out everything that points to a real person, so nobody could be picked out from what is left, the data stops being personal data, and GDPR stops applying to it. For a lot of tasks this is the simplest path of all: anonymize first, and most of this question goes away.
It is harder than it sounds, though. Everything that points to a person has to go, and a file can carry other people's personal data, a client named in your notes or another author's comments inside a document, even after you take your own details out. Whether it works for you depends on your use case, your risk tolerance, the kind of business you run, and the data you handle.
Sensitive data is a different game
Some data needs far stricter protection than the rest. The law treats a whole category this way: health data, biometric and genetic data, and information about someone's ethnicity, religion, politics, or sex life. GDPR calls this special category data.
For this kind of data, a normal setup falls short. Putting a client's health data through a standard Claude plan takes much more than a privacy notice and a legitimate interest. It needs specific, stronger arrangements, such as a zero-data-retention agreement or HIPAA-grade compliance with a signed agreement in place, which standard plans leave out. Keep special category data out of your system unless those protections are already set up, and get advice from a specialist lawyer before you go anywhere near it.
Give Claude the smallest folder, not your whole drive
This one matters more than people expect, and it is specific to how you run Claude.
The web version of Claude makes you choose each file or folder once. If you change that folder later, it does not reach back in. The data it touches stays easy to control.
Claude Code and the desktop app work differently. You can point them at a whole folder, or even a whole drive, and everything inside, including files you add later, can be pulled in. That is what makes them powerful for real work, and it is also a much wider door. As the data-protection lawyers in our session put it, once you let an agent run free, it can process far more data than a tool that only sees the one file you handed it.
The part that surprises people
Under GDPR, the access itself counts. It does not matter whether Claude ever opens a given file. Having access to it is already processing in the eyes of the law, because data processing is everything you do with data. So a folder full of client files that Claude could reach is already in scope, read or not.
What to do: keep your system in one dedicated project folder, and start Claude inside that folder. Do not hand it your whole Documents folder or your whole drive. Client files, trade secrets, and anything sensitive that does not belong to this work should live outside the folder Claude can see.
Permissions that outlive the session
The folder boundary resets at every launch: close the terminal, start Claude in a smaller folder tomorrow, and yesterday's wider access is gone. Saved permission rules are the exception. When Claude asks to do something and you answer with a "don't ask again" option, that choice is written into a settings file and keeps working in every future session until you remove it. These rules accumulate quietly, hundreds of them within a few months on a working system, so audit them now and then: type /permissions inside Claude Code to see every standing rule. To start from scratch, ask Claude to empty the allow list in .claude/settings.local.json while keeping everything else in the file, and approve each access on purpose from then on. The What Claude can reach lesson in Module 2 walks through this step by step.
For some work, the browser is the wiser choice. If your use case does not need Claude reaching into your files at all, running Claude or Cowork in the browser keeps things tight: the web version only sees what you hand it, once. Whether that fits comes down to your use case, your risk tolerance, the kind of business you run, and the kind of data you handle.
Local files still go to Anthropic when Claude reads them
This one trips people up. Storing files on your own machine keeps them off other companies' clouds. Anthropic is the exception: the moment Claude Code reads a local file, its contents travel to Anthropic to be processed. That is simply how the model works, it can only work with text it has been given. So your local root file, your notes, your logs, anything Claude reads, goes to Anthropic under whatever plan you are on.
What actually keeps data away from Anthropic is whether Claude reaches it at all, wherever it lives. Your dashboard is the clear example: when you open it, your browser pulls the rows straight from your database and shows them to you. Claude plays no part in that, so that data stays between your browser and your database. Ask Claude to read those same rows, and now it goes to Anthropic.
Think in terms of reach, not use
What matters is what Claude can reach, not only what you actively ask it to use. Anything inside the folder you start Claude in, and any database or tool you connect, is within reach. Within reach means it can travel to Anthropic the moment Claude looks, and under GDPR that access counts as processing whether Claude looks or not. So decide what Claude can reach, and keep everything else out of reach.
Connectors and MCPs: on-demand, ask first, and trust on purpose
Connectors and MCPs are how you let Claude reach into other tools and pull in data: your email, your calendar, your database, and whatever else you wire up. Set them to pull data only when you actually trigger them, rather than an automatic setting that can reach for data on its own, and set them to ask your permission on each call. That keeps Claude from quietly pulling in something you did not mean to hand over. It is also gentler on your usage costs.
Be deliberate about which ones you install. A custom MCP you found on GitHub is code from a stranger that you are handing access to your system, so treat it as a risk and look at what it does before you trust it. Even an MCP from a known company is your call: you decide, every time, whether you actually trust it with your data and your clients' data before you connect it.
One thing the access settings do not solve: a connector is its own vendor relationship. Anthropic's data-processing agreement, when you are on terms that include one, covers what Anthropic does with your data. It does not cover the company behind a connector. An email connector talks to your email provider under that provider's terms, a transcription connector processes your call audio under its own, and the same applies to anything else you wire in. What a connector pulls into the conversation is covered by your Anthropic terms, because it goes to the model like anything else you type. The vendor's side never is. So each connector is a separate processor decision: before client data flows through one, check whether that vendor offers a data-processing agreement of its own. A tool you host yourself is the exception, because there is no vendor behind it.
You build it, and you are responsible for it
Your root system is a set of template folders you take, edit, and run on your own machine. Like a document template, it sits there until you fill it in. You are the one who configures it and runs it, and the law treats you as the person responsible for the data. A setup put together wrong is on you.
Two parts are easy to get wrong, so they are worth calling out:
- Where your data is stored is your choice. When you create your database, you pick the region yourself. If you want your data held in the EU, choose an EU region (for example, Frankfurt) at setup. Nothing picks this for you, and the wrong region puts your data somewhere you may not want it.
- The compliance pieces are yours to build and keep working. A consent record, a way to export and delete a person's data on request, signed unsubscribe links: these are things you set up, test, and maintain. They exist once you build them.
Telling clients, and your legal basis
You do not usually need a consent checkbox to use AI. The normal basis is legitimate interest: you write down why your use is reasonable, weigh it against your client's interest, and mention it in your privacy notice. You do need to disclose that you use AI when it touches their data. You do not have to name the specific tool.
The AI built into other platforms does not get you out of this. When a platform runs AI under the hood, that AI is another processor in the chain that you are still responsible for.
Trade secrets
Keep anything you do not control out of reach. A secret shared without protection stops being protected. Your own material is your risk to take. A client's material is your liability, so do not feed it in without their say-so. This is one more reason to scope Claude to a small folder rather than your whole machine.
The EU AI Act, briefly
The AI Act is separate from GDPR and sorts AI uses by risk. Most solopreneur uses, drafting, summarizing, organizing, sit in the low or limited-risk band. Transparency duties for limited-risk uses begin in August 2026. It gets stricter for AI that decides something about a person, like screening a job application. If your AI makes a decision about someone, look closer.
See for yourself
Do not take our word for any of this. Read the sources and check that they still say what this page says.
Anthropic's own terms
The law itself
Read these with your own situation in mind, and then check it with your local lawyer. Different countries and jurisdictions apply these rules differently, so confirm what actually applies where you and your clients are. Your business is yours, and so is your risk tolerance. How cautious to be is your call to make.
Your setup checklist
- 1For client data, use Anthropic's Commercial Terms (the API, or a Team or Enterprise plan), not a personal Pro or Max subscription. Treat that as the floor, and confirm it is enough for your case.
- 2Keep your system in one dedicated project folder. Do not give Claude your whole drive.
- 3When you set up your database, choose an EU region if you want your data held in the EU. You make this choice.
- 4Set connectors and MCPs to on-demand access and to ask on each call, and only install MCPs you have looked at and trust. Each connector's vendor is its own processor relationship, outside Anthropic's agreement: check what that vendor offers before client data flows through it.
- 5Keep your privacy notice current: say that you use AI, and why.
- 6Keep client and contractor trade secrets out unless you have permission.
- 7Audit your standing permissions now and then: type
/permissionsin Claude Code, and clear rules you no longer want. - 8Re-check Anthropic's terms, the law, and this page over time. They change.
One more time, because it matters
This is for reflection, to help you ask the right questions, not legal advice for your specific business. When a real situation gets complicated, talk to a lawyer in your country. Reviewed June 2026.