The question that comes up most often is whether GDPR lets us roll out AI. It is the wrong question, because it implies a provision somewhere that speaks to language models. There is none. GDPR governs the processing of personal data and applies just as much in a spreadsheet, in a CRM, and in an integration with a model. What a language model changes is not the legal regime — it is the number of places where data can travel beyond the scope anyone planned for.
Below are seven things worth settling before anything is built, because each of them is expensive to change afterwards. This describes the technical and organisational side, not legal advice — the legal assessment belongs to your lawyer or data protection officer.
1. Establish whether personal data is involved at all
It sounds trivial, yet it determines the scope of the whole project — and surprisingly often the answer is no. A model classifying service tickets by fault description, a model predicting machine failures, an assistant searching technical documentation: none of them has to see a single item of personal data, provided somebody arranged for that at the input.
Check it against specifics rather than by assertion. Take ten real requests the system would have to handle and read them line by line. Usually one of two things emerges: either there genuinely is no personal data and the project is far simpler than assumed, or it is sitting somewhere nobody remembered — an email signature, a filename, a free-text notes field.
2. Settle the lawful basis before anything is sent
A lawful basis is established before processing, not after it, and one arrived at retrospectively repairs nothing. This is one of the more common failures around pilots: data goes into a tool “to try it out”, and the question of basis only surfaces when the pilot is due to become production.
Consent tends to be the reflexive choice and is usually not the best one. It can be withdrawn at any moment, and in an employer-employee relationship it is hard to show as freely given. In business processes, performance of a contract or legitimate interests more often fit. The first of those carries a condition that is easily overlooked: the processing must be necessary for a contract with the data subject themselves — and in a B2B process that person is frequently somebody other than your counterparty. The second requires a documented balancing test, which has to be carried out rather than assumed.
Special categories of data — health, beliefs, trade union membership — are a separate matter. If they can appear in what reaches the model, even incidentally in the description of a ticket, an Article 6 basis alone is not enough: a condition under Article 9 is needed as well, and that list is noticeably narrower. Check it against the same ten requests as in point one.
It also matters that adding a model to a process where you already process the data is not automatically covered by the existing basis. If the purpose or the scope changes, that change needs its own assessment.
3. Send less
This is the most effective safeguard in the whole project and simultaneously the cheapest: data that was never sent needs no contractual guarantees, no processing region, and no deletion procedure on the provider’s side.
In practice it means a middle layer that decides what leaves your systems — which fields are genuinely needed, what can be omitted, and what can be replaced by an identifier. A model deciding whether a complaint is well founded does not need the customer’s name; it needs the text of the complaint and the order history.
A note on terms: replacing a name with an identifier is pseudonymisation, and pseudonymised data is still personal data. It is very good practice, but it does not take the project out of GDPR — only genuine anonymisation does, meaning data from which the link to a person cannot be reconstructed by any reasonable means.
4. Get the roles straight: who is controller, who processes
A typical rollout involves three parties in three distinct roles. You are the controller, because it is your data and your purposes. The supplier building the system acts as a processor, on your documented instructions.
The model provider’s role, by contrast, is not settled in advance, and the contract alone does not decide it. Under GDPR the role follows from who determines the purposes and means of a given processing operation — the contract should reflect that rather than create it. In practice: for the requests run on your instructions the provider acts as a processor — a sub-processor where your supplier engages it, in which case your authorisation for sub-processing is required, or your own processor where you contract with it directly. To the extent it uses the same data for its own purposes — the norm in consumer tiers — it is a separate controller for that part.
The two roles can hold at once: the same service may be a processor for one operation and a controller for another. So the role is established per operation, not once for the provider as a whole.
The consequences are practical rather than formal. It is the controller who answers for the lawful basis, for the information duty towards individuals, and for the record of processing activities — including when a party they entrusted data to fails. That is why choosing a model provider is never purely a technical decision.
A practical scheduling point follows, with one qualification. A processing agreement is required where somebody processes personal data on your behalf — if the pilot involves no personal data, as in point one, none arises at that stage at all. Where personal data is involved, though, the agreement is a precondition for starting rather than a document tidied up at handover: signed after the pilot goes live, it means the pilot ran without one.
5. Decide on region and on training — deliberately, not by default
Two things have to be checked in the terms of the specific service, because in both the default is often not what you would expect.
The first is the processing region. The major model providers now offer processing in European regions, but it is not the default everywhere, and changing region after go-live can amount to a migration. If you are allowing transfers outside the EEA, you need a basis for that transfer — and that is a decision for the start, not for later. An EU region does not settle the question on its own, though: if support staff or a sub-processor outside the EEA can reach the data, a transfer takes place regardless of the fact that the data physically sits in Europe. So ask not only where the data is stored, but where it can be reached from.
The second is whether your content is used to train the model. The business tiers of the large providers’ services exclude it as standard; consumer tiers are frequently the reverse — which is the real difference between using the same model through a company account and through an employee’s personal one. Which applies to your project should follow from the contractual terms rather than from an assumption.
6. Keep GDPR and the AI Act apart instead of conflating them
The two regimes must be satisfied in parallel and neither displaces the other, yet they are confused in both directions.
From GDPR comes a restriction on decisions based solely on automated processing, where those decisions produce legal effects concerning a person or similarly significantly affect them. The word “solely” is decisive here: human involvement is not enough if it amounts to rubber-stamping a suggestion with no real ability to change it.
The AI Act works differently. Its duties follow from the classification of the system, not from the weight of any single decision — and some of them apply whether or not any personal data features in the conversation. Telling a person they are speaking to an AI system is one such duty: it covers systems intended to interact directly with a person, does not bite where that is obvious from the context, and says nothing at all about personal data. What that means in engineering terms is set out alongside our AI Act readiness audit.
Put briefly: GDPR asks whose data you are processing and on what basis. The AI Act asks what the system you built is, and in what context it operates. It is entirely possible to satisfy one and breach the other.
7. Design for data subject rights before anyone exercises one
This point is most often left until last, and it is the only one that cannot be retrofitted cheaply. A data subject may request access, rectification, or erasure — and the answer depends on where their data came to rest.
If the model merely processed a request and retained nothing, erasure comes down to your systems and to logs: yours, the middle layer’s, and the provider’s. That is achievable, provided it is known in advance what is logged and for how long.
If the data reached a search index — as in a RAG-style solution — erasure is entirely achievable, but it has to be designed: deleting the chunks and rebuilding the index is a distinct capability, not a side effect of deleting the record in the source system. A training set is a different matter: data that has gone into a model’s weights cannot in practice be taken back out — and that is the case worth not creating in the first place.
Hence the design rule that solves the problem at source: personal data stays in your systems, and the model receives as narrow a slice as the task allows. Rights are then honoured where they have always been honoured, and the integration with a model complicates that far less — provided the same procedure also covers logs, model outputs, and any index built from them.
While you are at it, settle the retention of request logs. They tend to be treated as technical data, yet they can hold complete document contents — including precisely what the middle layer had just carefully stripped out of the request to the model.
A checklist before you start
Before you launch even a pilot, work through six points. They take one meeting, and they save the conversations that otherwise happen later and in worse circumstances:
- Does personal data reach the model? Checked against ten real requests, not assumed.
- What is the lawful basis, and does it cover the new purpose if the purpose is changing.
- Exactly which fields leave your systems, and what can still be removed from that set.
- Whether a processing agreement is needed at all — and if so, whether it covers the arrangement with the model provider: authorising sub-processing where your supplier engages it, or a direct agreement where you contract with it yourself.
- Which region the service runs in, and whether the terms exclude training on your content.
- What is logged, for how long, and how you would satisfy an erasure request.
If any of those has no written answer today, that is the scope of the first stage — not a reason to avoid the project.
Where this sits in the project schedule
In practice these are settled during the audit phase, alongside choosing the process and checking the state of the data, because all of them bear on the same thing: scope. What such a project looks like stage by stage, and what each stage produces, is set out on our page on AI implementation.
If you would rather see the same questions from the supplier’s side — exactly where the data flows and what to ask any supplier, not only us — we have collected that under data security and GDPR.