Using AI in line with the GDPR: the practical guide for companies

Between "AI is banned here" and "the staff just do whatever" lies the state of most companies we talk to. Both are risky — just differently. A practical guide from people who build and operate such systems.

One thing up front, because it belongs here: we are software builders, not a law firm. This text is hands-on experience from projects, not legal advice — for your specific case, a data protection officer or specialist lawyer belongs at the table.

The two real risks

Risk one is the obvious one: customer data in a US cloud chatbot. An employee copies a customer complaint including name, address and contract details into a freely available chatbot — and with that, personal data has been transferred to a provider with no data processing agreement in place, onto infrastructure whose location nobody has checked, under terms that, depending on the account type, allow training on the inputs. That's not a theoretical scenario; it's the status quo in companies without rules.

Risk two is the underrated one: shadow AI. Where the company provides no tool, people use their private accounts — on their private phones, outside any control. In our experience a ban changes little; it just moves the usage to where IT can no longer see it. Our impression from first conversations is unambiguous: asked who in the company uses AI, management says "nobody" — and the department smiles. The most productive data protection measure is therefore, paradoxically, a permitted tool.

What the GDPR actually requires

The good news first: the GDPR doesn't ban AI. For AI it requires the same things as for any other data processing — it's just that here, the questions often have to be answered honestly for the first time:

• Data processing agreement (Art. 28). If an AI provider processes personal data for you, you need a DPA. Serious providers have one as a standard document; whoever doesn't offer one is out. Full stop.
• Legal basis and purpose limitation. Data collected for order processing must not wander freely into AI tools or even into model training. The question "for what exactly?" has to be answered per use case.
• Technical and organisational measures (Art. 32). Access control, encryption, logging — for AI additionally: who may enter what, and what happens to the inputs on the provider's side?
• Third-country transfers. US providers aren't automatically off-limits — but the transfer needs a documented basis, such as certification under the EU-US Data Privacy Framework. "It'll be fine" isn't one.
• Data subject rights and deletion. Access and deletion have to work even when data has passed through an AI system. Practically that means: inputs must not sit with the provider indefinitely.
• Data protection impact assessment. Systematic processing of sensitive data can trigger a DPIA. Uncomfortable — but incidentally the best tool for thinking your own use case through properly once.

Just as important is what the GDPR does not require: no renouncing the cloud, no renouncing US technology, and no one-hundred-percent error-free models. It requires that someone understands, documents and takes responsibility for the processing. That's work — but the kind of work an afternoon with the data protection officer takes care of, not a six-month project.

EU hosting or on-prem?

For the technical side there are three tiers, each with honest trade-offs:

1. EU processing with a major provider. The large model providers and cloud platforms now offer processing in EU data centres, DPAs and the written commitment not to train on your data. For most mid-market use cases the pragmatic standard: strong models, manageable costs.
2. Your own instance in your own cloud tenant. The model runs in your cloud environment, logs and network under your control. More operational effort, but clear boundaries — sensible from an elevated protection level upwards.
3. On-premises with open models. For highly sensitive data — health data, client files — open models run entirely in-house. Maximum control, honestly bought with weaker models, your own hardware and considerably more upkeep.

Our practice: we build AI tools in the EU cloud or on-prem depending on the protection level — and we decide that per use case, not per worldview. How we approach such projects, prototype on real data first, is on our AI development page. The most common mistake, by the way, isn't the wrong tier but tier three on principle: an on-prem project whose operation nobody has costed, for data that tier one would have covered cleanly.

The vendor checklist

Six questions for every AI provider — and the answers belong in the binder, not in someone's memory:

1. Is there a DPA we can actually sign?
2. Is training on our inputs excluded — contractually, not as a blog post?
3. Where is data processed and stored — can an EU region be selected?
4. How long are inputs retained, and can that be switched off or shortened?
5. Which sub-processors are involved — and are we informed about changes?
6. Are there security certifications (say, ISO 27001, SOC 2) and a named contact person?

Human in the loop — obligation and quality assurance in one

Art. 22 GDPR places tight limits on automated individual decisions with legal effect — no model may reject a job application or decide on a loan by itself. But beyond the obligation, the approval step is the difference between a tool and a risk: the model drafts, sorts and extracts — a human signs off where it counts. In our projects, the review step for everything that leaves the building or gets booked is non-negotiable. How much loop is needed depends on the risk: the internal search result needs no sign-off, sending a quote needs one, and the personnel decision stays entirely with a human. Side effect: the review step is exactly where employees' trust in the tool is built.

The EU AI Act, short and honest

Alongside the GDPR, the EU AI Act now applies — and for most mid-sized companies it's less dramatic than the headlines. It sorts AI systems into risk classes: prohibited practices (social scoring, for instance), high-risk systems (AI in hiring or credit decisions, say — real obligations kick in here), and below that limited and minimal risk with manageable transparency duties. Receipt extraction, email sorting, knowledge search — the typical mid-market tools — land in the lower classes.

Two things already apply, though, and are easily overlooked: since February 2025, Article 4 obliges companies that use AI to equip their staff with sufficient AI literacy — training is no longer optional, it's a duty. And whoever plans AI in high-risk areas should take the transition periods seriously instead of hoping for leniency. Practically, for a start, that means one thing above all: record which AI systems run in the company and for what — the same list that emerges anyway during the stocktake below. For everything beyond that, the sentence from the beginning applies: practitioner's assessment, not legal advice.

The order that works

1. Take stock. Ask — anonymously if need be — who is already using which AI tools today. In our experience the answer is: more than you thought.
2. Provide a permitted tool. With a DPA, EU processing, no training on your data. That dries up the shadow AI — bans don't.
3. A one-page policy. What may go in, what never (special categories of data, credentials, customer data without a basis), who signs off. One page that gets read beats twenty that nobody does.
4. Training. Short, concrete, with real examples from your own company — and with that, Article 4 is ticked off along the way.
5. Build one process properly. Instead of ten experiments: one use case with a human in the loop, cleanly integrated, honestly measured after eight weeks.

GDPR-compliant AI isn't wizardry, it's craft: DPA, purpose limitation, EU processing, a review step, training. Whoever takes these five points seriously is ahead of most — and gets to use the technology instead of experiencing it through the back door in ban mode. And in case the occasion for this text is a concrete project: the compliance questions answer themselves most easily while the tool is still on the drawing board. Retrofitting is always more expensive than planning in.