Where does our data go? AI, GDPR and the AI Act for decision-makers
Before any AI project, your DPO asks where the data goes. The questions to settle first on hosting, model providers, GDPR and the AI Act, in plain terms.
6 min read
Most AI projects we see do not stall on the model. They stall in a meeting room, when the DPO asks where the customer data goes and nobody in the room can answer.
The short answer: where you decide. Hosted in Europe, in your cloud or on-premise. The real work is settling it on day one, not after the prototype works.
This post lists the questions we settle before writing any code. It is not legal advice: your lawyer or DPO has the last word on your case.
Start with the data, not the model
Before choosing a model, write down what the system will read. Customer emails, contracts, health records, payslips, support tickets: each one carries a different weight under the GDPR.
Then follow one record through the system. Where is it stored, where is it processed, who can read it, and how long does it stay there. If the answer to any of these is "somewhere at the provider", you have found your first task.
In practice, three questions cover most of it:
- Is there personal data in it? Names in a PDF count. So does a customer ID that links back to a person.
- Does it need to leave your systems? Often only a fragment does. A support assistant may need the question and the relevant help article, not the customer's full history.
- Can it be removed or masked before it leaves? Pseudonymising names and IDs before a call to a model is cheap to build at the start and painful to add later.
A first version that sends less data is usually faster to approve. That alone can save weeks of back and forth with legal.
GDPR and model providers: read the terms, not the homepage
When you call a model through an API, the provider becomes a processor of whatever you send. Under the GDPR, that means a data processing agreement, and you need to know what it says.
- Training. Most large providers state that data sent through their business APIs is not used to train their models by default. Consumer apps often follow other rules. Check which offer your teams actually use.
- Retention. Some providers keep prompts and outputs for a limited period for abuse monitoring. Some offer reduced or zero retention on request. Know the number of days, in writing.
- Location. Where are requests processed, and where are logs stored. Several providers now offer processing in the EU, sometimes only on specific plans or regions.
- Subprocessors. The provider's own list of who else touches the data. It changes; someone on your side should get the notifications.
- Everything around the model. Prompts often end up in logging and monitoring tools, and documents end up in a search index as embeddings. Each of those is another processor, with its own location and retention. And when someone asks for their data to be erased, it has to leave the index too.
If the provider is a US company, the data transfer needs a legal basis: the EU–US Data Privacy Framework or standard contractual clauses. Hosting in an EU region helps, but some DPOs also look at which jurisdiction the provider itself falls under, since some US laws can reach data held by US companies abroad. How much weight that carries for your data is a question for your legal counsel.
Hosting AI in Europe, in your cloud or on-premise
We build all three. Which one fits depends less on the model than on your data and on who will run the system after launch.
A managed model, hosted in Europe. You call a commercial model through an EU region. Fastest to ship, best model quality, lowest upfront cost. The trade-off is dependence on the provider's terms and pricing.
Your own cloud. The model runs in your AWS, Azure or Google Cloud account, either through the provider's managed offering or as an open-weight model you deploy. Data stays inside the perimeter your security team already audits. It takes more setup and someone to run it.
On-premise. An open-weight model on your own servers. Nothing leaves the building, which some sectors require. You pay for the hardware, and the strongest models are not always available this way.
The choice is rarely all or nothing. A common pattern: sensitive documents are processed by a model in your own cloud, everything else goes to a managed model in Europe.
What the AI Act changes, by risk level
The AI Act (Regulation (EU) 2024/1689) does not regulate AI in general. It regulates uses, sorted by risk. Most company projects land in the lower tiers, and knowing which one you are in sets the workload.
- Unacceptable risk: banned. Social scoring, manipulative systems, emotion recognition at work, among others. These prohibitions have applied since February 2025.
- High risk: heavy obligations. Systems used in hiring, employee evaluation, credit scoring, access to education or essential services. They need risk management, documentation, logging, human oversight and data quality controls. These obligations apply in stages, and their timetable is under discussion at EU level: check the current dates with your legal counsel.
- Limited risk: transparency. A chatbot must tell people they are talking to a machine. Generated images, audio or video that could pass for real must be marked as such. Their start dates are worth checking too.
- Minimal risk: nothing specific. Summarising internal documents, classifying tickets, drafting replies a person reviews. The GDPR still applies; the AI Act adds little.
Two points catch companies off guard. First, the Act distinguishes the provider who builds a system from the deployer who uses it, and a company that deploys a third-party tool still has duties. Second, the Act expects the people who use AI systems in a company to have a sufficient level of AI literacy, and what that requires in practice is worth checking with your counsel.
A useful exercise before any project: write one paragraph on what the system decides, about whom, and who checks it. If it touches hiring, credit or someone's access to a service, involve your lawyer before the scope is signed.
Put it in the scope, not in a later review
Compliance done at the end costs the most. A model swapped because the provider's terms do not pass review means rebuilding the integration. A missing log means reconstructing decisions after the fact.
Write the answers into the scope instead. Your DPO reads one page instead of chasing answers across a project.
The one-page data sheet your DPO will ask for
| Question | What to write down |
|---|---|
| 1. Data in | Which sources, and whether they contain personal data |
| 2. Where it is processed and stored | Region, cloud account or servers, including logs and indexes |
| 3. Model provider and DPA | Which provider, which offer, signed processing agreement |
| 4. Retention | How many days, at the provider and on your side |
| 5. AI Act risk tier | Minimal, limited or high, and why |
| 6. Who reviews outputs | Which person checks what, before it reaches a customer |
Answered early, these also shape the build: masking, logging and human review are cheaper to design in than to add after launch. We write a scope at the start and build inside your data rules, with a first version in 3 to 6 weeks.
Settle the data question first
If data is the first question your team will ask, bring the person who will ask it. Book a free audit with your DPO or CTO in the room: one hour on your business, then a short document that says what is worth building, with what data, and what is not.
