AI and GDPR: a guide for companies what you settle before the pilot starts
AI does not change the rules of the GDPR. It changes where your personal data turns up: in a prompt sent to a model, in an integration log, and at a vendor you have no processing agreement with yet. Below is what you settle before the pilot: what data goes into the model, how to narrow the scope, who acts as processor, and who makes the decision about a person.
- Art. 28 GDPRa processing agreement with the model vendor, signed before the first personal data leaves your company
- Art. 22 GDPRa human closes a decision about a person, the model at most prepares the material
- Art. 35 GDPRan impact assessment at large scale and systematic monitoring, done before the start, not after
- 5 questionswhat data, what for, who processes it, where it sits, how long; without the answers the pilot does not start
Short answer
How do you roll out AI in line with the GDPR?
Start with the scope, not with a tool. Write down what data enters the model in a given process, and cut everything the purpose does not require. Data minimisation under Art. 5 GDPR works like a filter: if an AI agent is there to summarise a service ticket, it does not need the customer's national identification number or their purchase history.
Then settle the roles. A model vendor you send data to over an API acts as a processor, so you need a processing agreement under Art. 28 GDPR, the list of sub-processors, and clarity on where the processing happens. Add retention: how long the vendor keeps the content of prompts, and whether that period can be shortened.
Decisions and transparency come last. If the model output affects a natural person, a human has to have real influence over the outcome (Art. 22), and the person the data is about has to know the processing is happening (Art. 13 and 14). This page is not legal advice. Confirm the lawful basis, the risk assessment and the wording of your notices with a lawyer or your data protection officer.
What data actually goes into the model?
The first sentence of every review sounds the same: nobody knows exactly what ends up in the chat window. Before you settle a lawful basis, settle the facts. Process by process, write down which fields reach the model and where they come from.
Separate three streams, because each carries a different risk: data typed in by hand, data pulled from a system (CRM, mailbox, ERP), and data the model receives as context from documents. The third one gets skipped, and it is the one holding the attachments nobody planned to send.
- Identifiers: name, email address, phone number, customer number
- The body of correspondence, where the customer volunteers more than you need
- Attachments: scanned contracts, service tickets, invoices carrying people's details
- Special category data under Art. 9 GDPR, for example a health detail mentioned in a complaint
- Prompt metadata: who asked, when, from which account; that is employee personal data too
How do you narrow the data before it reaches the model?
Minimisation is not a sentence in a policy, it is code in the integration. Between your system and the model sits a layer that decides what gets through. It is the cheapest part of a rollout and the one that cuts risk hardest.
Four techniques work, and they combine. The earlier in the flow you apply them, the less data you have to police later in logs and backups.
In our rollouts the AI agent answers from company data rather than from the model's memory, so the scope can be pinned to sources: this database, this folder, this view. Narrowing the sources narrows what can reach a prompt. How that works is on the BOND business AI agent page, the company AI agent answering from your company data in 5 to 10 seconds.
- Field selection: only the columns the task needs go to the model, the integration does not fetch the rest
- Masking: document numbers, national identifiers and bank accounts swapped for tokens before sending
- Pseudonymisation: a technical identifier instead of customer data, with the mapping kept on your side
- Aggregation: the model gets a summary or a count instead of a list of people, when the task allows it
Who is the processor when you use a model vendor's API?
When you send data over an API, you remain the controller and the model vendor acts as a processor. Art. 28 GDPR then calls for a contract setting out the subject matter, duration, nature and purpose of the processing, the type of personal data and the categories of data subjects.
Follow the chain further. A vendor usually runs on somebody else's infrastructure, so you have sub-processors and you need to know who they are. Below are the questions we ask before connecting anything. The technical controls sit in our guide to AI security in business.
| Question for the vendor | What you want in the answer | Where it sits in the GDPR |
|---|---|---|
| Is there a processing agreement? | a signed document with the purpose, the scope and the list of sub-processors | Art. 28 |
| Where does the processing happen? | an EU region, or a transfer covered by standard contractual clauses | Chapter V |
| How long do you keep the content of prompts? | a retention period stated plainly, and the option to shorten it | Art. 5 |
| Is our data used to train the model? | training on data sent through the API switched off, in writing | Art. 5 and Art. 6 |
| Who on your side has access? | a description of permissions, encryption and access logging | Art. 32 |
| What happens when the contract ends? | a deletion deadline and confirmation that deletion happened | Art. 28 |
Put the answers into your record of processing activities together with the tool name, the purpose, the data scope and the retention. A record that does not know about the AI tool your team uses is out of date from the first day of the pilot.
When do you need a data protection impact assessment?
Art. 35 GDPR calls for an impact assessment (DPIA) where the processing is likely to result in a high risk to the rights and freedoms of individuals. With AI, two cases keep coming back: processing on a large scale, and systematic monitoring of people's behaviour.
The assessment happens before the start, because its point is to change the design rather than describe what is already running. What comes out of it is a list of constraints: fewer fields, shorter retention, tighter permissions, a human at the decision.
- Large scale: the whole ticket database or the whole workforce instead of one team in a pilot
- Systematic monitoring of how people behave, including evaluation of a team's work
- Special category data under Art. 9 GDPR, such as health or biometric data
- Automated decisions producing legal effects for a person, which is the territory of Art. 22
Can a model decide about a person on its own?
Not in the way it usually gets planned. Art. 22 GDPR restricts decisions based solely on automated processing where they produce legal effects or similarly significantly affect a person. Rejecting an application, appraising an employee, scoring somebody: those are such decisions.
The fix is organisational, not technical. The model prepares the material, a human rules on it and can genuinely change the outcome. Genuinely means with time to read the case and the right to a different answer, not an „approve” button at the end of a list.
The transparency duty from Art. 13 and 14 stays: the person has to know their data is being processed, for what purpose and on what basis. A privacy notice written five years ago, one that knows nothing about any AI tool, does not discharge that duty.
- List the decisions in the process and mark the ones that concern a natural person
- Next to each one, name the human who rules on it, by name and job title
- Log what the model proposed and what the human changed; that log is your evidence
- Update the privacy notice and the privacy policy to cover the new tool
How do you roll out AI under the GDPR step by step?
Order matters, because the cheapest corrections are made before the pilot, not in production. Here it looks like this: a process workshop, a pilot on real data in a narrow scope, production, and measurement after 30 and 90 days. Those 5 steps below are in the order we run them.
Data inventory for the process
Write down which fields enter the model, where they come from and who has access to them. That document is the basis for updating your record of processing activities.
Purpose, basis, scope
Settle the purpose and the lawful basis with a lawyer or your data protection officer, then cut from the scope everything that purpose does not require.
Contracts and place of processing
Sign the processing agreement with the model vendor, check the sub-processors and the processing region. Set prompt retention wherever the vendor lets you.
Pilot on a narrow scope
One process, one team, data masked everywhere it can be. A pilot shows which data really passes through the integration, rather than which data you planned to send.
Production and review
After 30 and 90 days you check the logs, the data scope and how much a human really contributes to decisions. Changing the process without coming back to this list is the short road to documentation that no longer matches reality.
How does the GDPR differ from the AI Act in your rollout?
The GDPR asks about personal data: what data, what for, on what basis, for how long. The AI Act, regulation 2024/1689, looks at the system itself: what it is for, what risk the use case carries, and whether a person knows they are dealing with an AI system. The two regimes overlap, and neither replaces the other.
The practical consequence: one analysis is not enough. GDPR compliance does not exempt you from risk classification or transparency duties, and transparency does not settle your lawful basis. In a typical internal rollout the weight sits on the GDPR side, but the classification still has to be done.
Common mistakes
Six mistakes we see most often with AI and personal data
Consent used as the default lawful basis
Consent can be withdrawn at any moment, and then the process has to stop and the data has to be cleaned up. For an operational process another basis under Art. 6 is often the better fit, but that choice belongs to a lawyer, not to the integrator.
The whole database in the context, because it is easier that way
Instead of five fields, the model gets the customer's full history with attachments. The scope grows, so does retention at the vendor, and so does what you have to describe in the record of processing activities.
No processing agreement with the model vendor
Personal data goes out to a processor without the relationship Art. 28 requires. An agreement signed later does not repair the period when there was none. This is usually the easiest thing to sort out and the one most often skipped.
Logs with no deletion deadline
The content of prompts sits for years in the automation tool, in the database and at the vendor. Retention described in a policy but not set in the configuration does not exist.
A human in the loop on paper only
Someone clicks „approve” on thirty cases a day, so the decision is automated in fact. In a dispute that shows up in the logs immediately.
A record of processing activities with no AI tools in it
The team has been using a model for six months and the documentation describes the state before the rollout. The first question from a customer or from a supervisory authority exposes the gap.
Checklist
Checklist before you start the pilot
If any line is a no, the pilot should not start yet.
- A written list of the fields that enter the model in each process
- Purpose and lawful basis confirmed with a lawyer or your data protection officer
- Processing agreements with the model vendor and the automation platform, with the sub-processor list
- Processing region agreed, and any transfer outside the EEA based on standard contractual clauses
- Retention of prompts and logs set in the configuration, not only described in a policy
- Masking or pseudonymisation wherever the process does not need the data in the clear
- Decisions about people ruled on by a human, with a record of what they changed
- Record of processing activities and privacy notice updated to cover the new tool
Let us do this on your process
The data scope gets settled before the pilot, not after it
On a free 30-minute consultation we take one of your processes and write down what data would enter the model and what can be cut out of it. The process workshop costs EUR 3,500 net per week and ends with a process map listing the fields, the agreements and the settings to confirm with your own lawyer or data protection officer. You write directly to Paweł.
Book a free consultationFrequently asked questions
Are you allowed to send personal data to an AI model?
Yes, if you have a purpose and a lawful basis, a processing agreement with the vendor, and a scope limited to what the task needs. The more useful question is a different one: how much of that data really has to go there. Confirm the lawful basis with a lawyer or your data protection officer.
Do I need the customer's consent for AI to process their data?
Not necessarily. Consent is one of the bases in Art. 6 GDPR, not the only one, and for operational processes it is often awkward: it can be withdrawn at any moment, and then the process has to stop. Choosing the basis is a legal decision rather than a technical one, so make it with a lawyer or your data protection officer.
What is a data processing agreement and when do you need one?
It is the contract required by Art. 28 GDPR between a controller and a processor. You need one with every vendor processing personal data on your behalf, so with the model vendor and with the automation platform too. It sets out the purpose, the scope, the duration, the type of data and the sub-processors.
Does the data have to be processed inside the European Union?
It does not, but a transfer outside the European Economic Area needs a basis from Chapter V of the GDPR, most often standard contractual clauses. If the vendor lets you pick an EU region, picking it makes the documentation simpler. Check this before production, because changing region later means a migration.
When do you have to run a DPIA for an AI rollout?
When the processing is likely to result in a high risk to people's rights and freedoms: large scale, systematic monitoring, special category data under Art. 9, or automated decisions under Art. 22. The assessment happens before the start, because its point is to change the design rather than describe what already runs.
Can an AI agent reject a customer's claim or appraise an employee?
Not on its own. Art. 22 GDPR restricts decisions based solely on automated processing where they produce legal effects or similarly significantly affect a person. Set the process up so the model prepares the material and a human rules on it, with the ability to change the outcome.
What does the GDPR say if the vendor trains a model on our data?
Settle it in the contract: whether the content of prompts is used for training and how long it is stored. Training switched off for data sent through the API, plus short retention, is easier to defend in your documentation than explaining why customer data fed somebody else's model.
Does the AI Act replace the GDPR?
No. Regulation 2024/1689 covers AI systems: risk classification and transparency duties towards people. The GDPR covers personal data and applies independently. In practice you run both analyses, although in a typical internal rollout the weight sits on the GDPR side.