// gdpr · ai_compliance
GDPR-compliant AI: how to build AI that survives an audit
Most AI projects at Swedish companies stall in the same place: with the lawyer or the data protection officer. Someone wants to connect the customer database to a language model, someone else asks where the data ends up, and nobody has a good answer. So the project dies.
It does not have to go that way. GDPR does not ban AI. GDPR requires that you know which data is used, why, by whom, where, and for how long. Those are questions you can answer, if the system is built to answer them.
We build AI systems that pass that review. Servers in the EU that we operate, open-weights models on your own hardware when needed, no training on your data, and a log of everything an agent does. This page explains what is required and how we solve it.
What GDPR actually requires when customer data goes into a language model
This is the core, without legal jargon.
Legal basis. You must be able to say why you process the data. Usually a contract with the customer or a legitimate interest. Decide it before you run, not after.
Data minimisation. Send only what the model needs for the task. If an agent answers a question about delivery status, it needs the order number, not the whole customer history. We build so that unnecessary fields never reach the model.
A data processing agreement with every processor. Every party that touches personal data on your behalf is a processor and needs an agreement. That includes us, whoever runs the server, and the model provider if the model runs somewhere else. No list of processors, no compliance.
Where the data is processed. You should know in which country and at which company the computation happens. Not roughly. Exactly.
Retention and deletion. How long are prompts, answers and logs kept? Who deletes them? An AI system that stores everything forever is not GDPR-compliant no matter where the server sits.
Logging. Can you show afterwards what the system did with a specific person's data? If the answer is no, you cannot handle a subject access request or an incident.
Why a US cloud is a problem, in plain words
Two things make US cloud AI hard for a Swedish company handling personal data.
The first is third-country transfer. When data leaves the EU, the transfer needs a legal basis. The rules for the US have changed several times in ten years and been tested in court. What is allowed today may be invalid next year. That is uncertain ground to build on.
The second is the CLOUD Act. US law lets US authorities request data from companies headquartered in the US, even when the server is physically in Europe. A datacenter in Frankfurt run by a US company therefore does not fully solve the problem. We are not claiming that means data leaks. We are saying it is a risk your DPO has to take a position on, and that the risk goes away when the operator is European.
Put simply: if the model runs at a US company, you must be able to explain why that is fine. If it runs on a server in the EU operated by a European company, you do not need that explanation.
How we build it
We have a fixed set of build rules for every AI system that touches personal data. They are not optional extras.
EU servers we operate
The model and the data run on servers in Germany and Finland that we operate, or on Swedish hosting when you want it. European operator, European jurisdiction.
Open-weights models on your own hardware
When the data may not leave the building, we run an open-weights model such as Mistral, Llama or Qwen on a server at your site. Then there is no external party at all.
No training on your data
What you feed in is used to do the job and nothing else. No prompts or documents go into any model training, ours or anyone else's. It is written into the agreement.
Signed audit trail per agent action
Every time an agent reads, writes or calls a tool, it is logged with a timestamp and signature. You can show afterwards exactly what happened with a specific person's data.
Human in the loop
Decisions that genuinely affect a person, like rejecting an application or changing a contract, always pass through a human. The agent prepares, the human decides.
DPA and deletion built in
We sign a DPA with you, hold agreements with our sub-processors, and build retention periods and deletion in from the start instead of bolting them on later.
NIS2 and the EU AI Act, briefly and honestly
NIS2 applies to companies in essential sectors and sets requirements for risk management, incident reporting and control over the supply chain. An AI system is part of that chain. We build so you can show where the system runs, who has access, and how an incident is detected and reported.
The EU AI Act sorts AI systems by risk. Most systems we build, like support agents and internal search, land in the lower risk class with transparency and documentation requirements. Systems that affect people's rights, like hiring or credit decisions, are classed higher and require more. We tell you which class your system lands in before we build, not after.
Honesty about our own status: we are not ISO 27001 certified, we work aligned to its principles. We are ready for NIS2 and the AI Act in the sense that we build so the requirements can be met and documented. We issue no certificates and promise nothing an auditor would question.
A checklist to hand to your DPO
Print this and put the questions to any AI vendor, us included. If you do not get straight answers on every point, the system is not ready.
- 01What is our legal basis for each type of personal data that goes into the model?
- 02Which fields are sent to the model, and have we removed the ones that are not needed?
- 03In which country and at which company does the model run? Who owns the operator?
- 04Is there a DPA with every party that touches the data, including sub-processors?
- 05Are our prompts, documents or answers used to train any model?
- 06How long are prompts, answers and logs kept, and who deletes them?
- 07Can we retrieve everything the system did with a specific person's data for a subject access request?
- 08Which decisions does the system take on its own, and where does a human stay in the loop?
- 09Which risk class does the system fall into under the AI Act, and who assessed it?
- 10How is an incident detected and reported, and within what time?
// faq
Frequently asked questions
Are we allowed to put customer data into an AI service?
Yes, if you have a legal basis, a DPA with the provider, know where the data is processed and can delete it. The problem with many public AI services is that you do not get clear answers on those points. Then you should not send personal data. We build so that the answers exist.
Does the model have to run in Sweden?
No. GDPR requires the EU or EEA, not Sweden. Servers in Germany or Finland operated by a European company are enough for most. Some industries and public bodies have their own requirements on Swedish operation, and then we arrange Swedish hosting or a server at your site.
Do you train on our data?
No. What you feed in is used to do the job and nothing else. It is written into the agreement, and it applies to both us and the models we use. When the model runs on your own server, there is not even a technical path for the data to leave the building.
Are you ISO 27001 certified?
No, and we do not claim to be. We work aligned to ISO 27001 principles and can show how we do it in practice. If your procurement needs a certified party in the operations chain, we solve that with certified hosting and are open about where the line is.
Can you help with a data protection impact assessment?
We deliver the technical basis: data flows, retention periods, logs, where everything runs and which decisions the system takes. We are engineers, not lawyers, so the assessment itself is done by your DPO or legal advisor. But they get a complete basis to work from.
// read_next
Has legal said no to your AI project?
Tell us what you want to do and what stopped it. We walk through the data flow, say what is required, and build so that your DPO can say yes.