GDPR-Compliant AI: What Actually Changes?

Nothing in GDPR changed because of AI. What changed is that AI makes it much harder to follow rules that were already there. If your system touches personal data, whether that's a chatbot reading customer emails or a model trained on your CRM, you need a lawful basis for that processing, you need to tell people what's happening, and you need a way to answer when someone asks "why did your AI decide this about me." Most companies I talk to in Sweden have none of that written down. They have a vendor contract and a hope.

Does GDPR apply if we use a third-party AI tool instead of building our own?

Yes. Completely. GDPR doesn't care who wrote the code. It cares who processes the data and for what purpose. If you feed customer data into ChatGPT, Claude, or any SaaS AI tool, you are the data controller and the vendor is your processor. That means you need a data processing agreement with them, you need to know where the data goes, and you need to know if it's used to train their models.

This is where most companies get caught out. They sign up for a tool, paste in customer records to "test it," and never check the terms of service. Many consumer-facing AI tools reserve the right to use input data for training unless you're on an enterprise plan. That's not a GDPR violation by itself, but if that data includes personal data and you didn't disclose that processing to the people it belongs to, you have a problem. Using a third party does not transfer your liability. It just adds a second party who is also liable.

What counts as personal data when it is used to train or prompt an AI model?

Same definition as always: any information relating to an identified or identifiable person. The AI context doesn't loosen that definition, it widens what falls under it. A support ticket with a name and email is personal data. A prompt that includes a customer's purchase history is personal data. Even an anonymized dataset can stop being anonymous once a model is good enough at drawing inferences and connecting fragments.

Training data gets scrutiny too. If you fine-tune a model on historical customer interactions, every one of those interactions is personal data processing, and you need a lawful basis for using it that way, not just the original basis you used to collect it. "We already had the data" is not a defense. Purpose limitation is a real GDPR principle, and AI projects violate it constantly because teams reach for whatever data exists instead of asking what they're actually allowed to use it for.

Do we need a Data Protection Impact Assessment before deploying an AI system?

If the AI system does automated decision-making, profiling, or processes data at scale, yes, a DPIA is mandatory under GDPR Article 35. Most real-world AI deployments touching personal data clear that bar. Think hiring tools, credit scoring, customer segmentation, fraud detection, even a sophisticated recommendation engine depending on what it infers about people.

A DPIA is not a form you fill in once. It's an honest assessment of what could go wrong, who gets hurt if the model is biased or wrong, and what you do about it. Swedish companies tend to skip this because it feels like paperwork. Then they get a request from the Swedish Authority for Privacy Protection, IMY, and discover the paperwork was the point. Do the DPIA before you deploy, not after someone complains.

How does the EU AI Act interact with existing GDPR obligations?

They stack. The AI Act doesn't replace GDPR, it adds a second layer of obligations on top, specifically about the AI system itself rather than just the data. The AI Act classifies systems by risk and imposes requirements like documentation, human oversight, and transparency depending on that classification. GDPR still governs the data flowing through the system.

This matters right now because of timing. U.S. and other non-EU companies selling into Europe are watching deadlines tied to the AI Act's rollout, and the compliance pressure is real even for companies outside the EU if they serve EU customers, as Holland & Knight covered. If you're building or buying AI that touches EU residents' data, you can't treat GDPR and the AI Act as separate projects. One team, one compliance map, both laws on it.

What rights do individuals have over AI-driven decisions made about them?

Article 22 gives people the right not to be subject to a decision based solely on automated processing if it has legal or significant effects on them, unless specific conditions are met. That covers things like automated loan rejections, automated hiring screens, automated pricing. People also have the right to get a human review, to contest the decision, and to get an explanation of the logic involved.

"Explanation of the logic involved" is the hard part. If your AI system is a black box even to you, you cannot meet this obligation. This is one of the real, practical reasons to care about model choice and architecture, not just compliance theater. You need to be able to say, in plain language, what inputs drove the output. If you can't, you've built something you can't legally deploy for decisions that matter to people.

Can on-premise or local AI deployment reduce our GDPR exposure?

It reduces some exposure, not all of it. Running your own model on servers you control, rather than sending data to a third-party API, removes the cross-border transfer question and the "what does the vendor do with our data" question. That's real, and it's one of the main reasons companies ask us about on-premise or local LLM deployment. You still need a lawful basis, you still need a DPIA if the processing qualifies, and you still owe people their Article 22 rights.

What local deployment does buy you is control and a shorter list of parties who touch the data. Fewer processors means fewer data processing agreements, fewer unknowns, fewer places where something can go wrong that you don't find out about until it's a complaint to IMY. It doesn't make GDPR go away. It makes your compliance story easier to tell and easier to prove.

What drives the cost

There's no fixed price for "making AI GDPR-compliant" and anyone who quotes you one on the first call is guessing. The real cost drivers are: how much personal data your system actually touches and how sensitive it is, whether you need a DPIA and how deep that assessment has to go, how many third-party integrations you're running (each one is a processor relationship to manage), whether you host on shared cloud infrastructure or move to dedicated or local deployment, and how much ongoing monitoring and documentation you're willing to pay people to maintain once the system is live. Compliance isn't a one-time cost, it's a maintenance line item, same as security.

The honest trade-off: cutting corners on DPIAs and data mapping is cheap today and expensive the day a regulator or a customer asks a question you can't answer.

Next step

If you want to know exactly where your AI system stands against GDPR, look at our GDPR-Compliant AI service. If your real goal is to stop sending personal data to third-party APIs altogether, read about On-Premise LLM deployment and what that actually takes.

Read next

• Can We Run an LLM on Our Own Servers? A Practical Answer
• How Much Does a Custom AI Agent Cost?
• Sweden's AI Silence Should Terrify Every Founder Building Here

Fredrik Brunnberg builds AI and software at HEIMLANDR.IO in Jönköping, Sweden. Is this your real question? Book 20 minutes, we answer straight.