GDPR-compliant AI tools: the practical check for companies

You can recognise GDPR-compliant AI tools by three verifiable features: a signed data processing agreement, processing inside the EU, and a written commitment that your inputs will not feed the training of someone else's models. A certification badge on a vendor page proves nothing. Clarify those three points before you roll a tool out, and the conversation with the supervisory authority never has to happen.

What makes an AI tool GDPR-compliant?

It is never the tool that is compliant, but the specific use. The same text model can be entirely unproblematic for drafting a blog post and inadmissible for screening job applications. So the question is never "is this tool allowed?" but "which data am I putting in, for what purpose, and who sees it afterwards?"

Four checkpoints follow from that question, and you can ask the vendor to evidence each one. First: is there a data processing agreement you can sign, and does it name the sub-processors? Second: where is the data processed, and what happens in a support case – does anyone outside the EU reach your content? Third: are your inputs used for training, and can that be excluded contractually rather than by a toggle in the account? Fourth: how long are prompts and outputs stored, and can you demand deletion?

These four points are deliberately dry, because they can be evidenced. A vendor who answers them produces documents: contract text, a list of data centres, a statement on retention. A vendor who points to security promises and awards instead has not answered the question. The difference is barely visible in a sales call and obvious in an audit.

You will usually have answers within a few days. If one of them stays open, that is already the result: the tool is not suitable for personal data. It may still be useful for anonymised or purely internal content with no personal reference. Which categories are worth considering for smaller firms at all is covered in our overview of which AI tools actually pay off for small companies.

Which EU AI Act obligations apply to companies that only use AI?

Most small and medium-sized companies are not providers but deployers, and for deployers the list is short. You need to know what you are using a system for, refrain from prohibited applications, have results reviewed by people, and make sure your staff broadly understand the system in use. That literacy obligation from Article 4 of the AI Act, Regulation (EU) 2024/1689, has applied since 2 February 2025.

Your role	What follows from it	From when
Deployer: you use someone else's system in your business	AI literacy in the team, a clear purpose, human review of results	since 2 February 2025
Prohibited practices, such as emotion recognition at the workplace	Use is banned, regardless of company size	since 2 February 2025
High-risk use, such as pre-screening job applications	Additional documentation; supervision and penalties apply in full	from 2 August 2026
Provider: you place your own system on the market	Full risk, documentation and conformity obligations	staggered

The literacy obligation is often overestimated and therefore postponed. It does not mean programming knowledge, but an understanding of how a system arrives at its results, where it is reliable and where it is not. A one-hour briefing, a single page of rules for daily use and a named contact for questions do the job in a company of fifteen people. Record the date and who attended, and the obligation becomes provable too.

The distinction from the GDPR matters: the AI Act governs the product and its risk, the GDPR governs personal data. Both apply side by side. A tool can be uncritical under the AI Act and still inadmissible under the GDPR – the more common case in practice.

Why is processing on your behalf the critical point with AI tools?

Because this is where nearly every review fails. As soon as you enter personal data into an external system, the vendor processes that data on your behalf – and for that, Art. 28 of the General Data Protection Regulation requires a contract with prescribed content. Without it the processing is not covered, even if nothing has technically gone wrong.

Processing on your behalf through AI tools differs from classic software in three ways. The vendor often brings in further service providers for computing power, and they have to be listed in the contract. The inputs are unstructured, so nobody knows in advance which data actually ends up inside. And the processing is not reproducible, which makes access and deletion requests technically demanding.

The contract itself is quickly checked once you know what to look for. It has to name the subject matter and duration of the processing, the type of data and the categories of data subjects, the technical and organisational measures, the rules for further service providers, and the duty to delete or return the data at the end. If one of those is missing, the contract is incomplete and the responsibility stays entirely with you.

In practice this means: settle the contractual position before the first team uses the tool productively. A free account someone sets up on a Friday afternoon is the same legal event as a corporate procurement – only without a contract. That is how the cases arise that nobody can reconstruct later. If you are redesigning processes anyway, cut the data flows cleanly from the start; that is the core of any AI automation that survives daily operations.

What does a practical data protection checklist for AI tools look like?

It has seven steps and takes about half a day per tool. The order matters: purpose comes first, product second.

1. Write the purpose in one sentence: which recurring task should the tool take over?
2. Name the data types: does the input contain names, customer data, health or application data?
3. Request the data processing agreement and check the list of sub-processors.
4. Exclude training use contractually, not just by switching it off in the account.
5. Extend the processing register: tool, purpose, data types, legal basis, retention period.
6. Brief the team: what may go in, what may not, and who checks the output before it is used?
7. Define access rights and retention periods, and set a review date in the calendar.

Step five is the one companies skip most often, and also the one a supervisory authority asks about first. The record of processing activities is not a formality: it is the only place where it is traceable which tools work with which data. A table with five columns is enough, and it takes an hour to set up.

For the substantive assessment, the German conference of independent data protection authorities has published guidance on artificial intelligence and data protection that you can place next to this list as a review grid. For getting started, though, the list alone is enough: it forces a decision per tool and makes visible which tools are in use at all.

Which mistakes cost small companies the most time?

The most expensive mistake is the debate on principles. Companies commission an opinion on "AI in the business" while five tools have long been running without a contract in day-to-day work. The reverse order makes sense: first record what is actually being used, then decide tool by tool.

The second most expensive mistake is trusting the server location. "Hosted in Frankfurt" says nothing about who looks into the data in a support case, or which sub-processors are involved for computing power. That is in the contract, not in the product description.

The third mistake concerns the output rather than the input. A model can produce a plausible but wrong answer; if that answer reaches customers unchecked, the damage is commercially real, quite apart from data protection. That is why every productive use needs a named person who signs off. Our article on AI chatbots in customer service shows how this works in customer-facing applications. For technical safeguards, the German Federal Office for Information Security collects recommendations on the secure use of AI.

A fourth point comes from our own project data from 2025 and 2026: companies commit too early to one large tool and too late to clear rules. Two or three tightly scoped use cases carry further than a broad rollout nobody uses after four weeks.

Introducing GDPR-compliant AI tools — mit ZeuZ IT

We work in the order described above: an inventory of the tools actually in use, an assessment per purpose, a contract review, and only then the technical connection to your processes. We say openly when a project does not justify the effort – a tool that saves two hours a month and costs four hours of review is one we will not recommend.

We work with fixed prices for the implementation, so the cost is settled before the start. Tell us in a short first conversation the one task where you want to use AI – we will answer with a data protection assessment and a fixed price for the rollout.