Why data protection is rarely the problem when an AI project sits untouched for six months

Who is really blocking: the law or its interpretation

In many first conversations we see the same dynamic. The technical side wants to automate. Finance sees the margin shrinking. Management gives the green light. Then someone says: “We need to clear this with the data protection officer first.”

Six months later, nothing has moved. No project was rejected. None was approved. There is a long assessment nobody has read. The actual function of this process is not data protection. It is the defence against change.

The problem is not GDPR. GDPR is a set of rules that can be implemented technically. The problem is that “data protection concerns” are an argument inside companies that nobody can argue against without appearing negligent. Whoever uses the argument does not have to justify it. Whoever pushes back has to disprove it.

Why blocking is reasonable from the individual’s point of view

Regulatory economics knows the pattern as regulatory capture, first described by George Stigler. After a while, an oversight body no longer serves the purpose it was set up for but the interests of those around it. Inside companies the same thing happens on a small scale.

The data protection officer has a lopsided incentive structure. If they approve a project and something goes wrong, they carry the risk. If they block it, nobody carries visible costs. The costs of a wrong approval are visible: fines, headlines. The costs of a wrong block are invisible: lost efficiency, eroded competitiveness, shrinking margins. Anyone acting rationally in this structure blocks, regardless of the legal situation.

The result is predictable. Innovation does not die from prohibitions. It dies from omission. From review loops, from assessments that require further assessments, from committees that keep themselves busy. The legacy mindset disguises itself as caution.

This is not a criticism of the person. It is a criticism of the task you give them. Ask a data protection officer “Are we allowed to use AI?” and you rightly get no answer. Show them a concrete architecture and you get one.

What has changed since 2023

In 2023, blanket AI bans were a common reaction. Samsung prohibited its employees from using ChatGPT in May 2023 after engineers had pasted source code into the tool. Many companies followed. The scepticism was understandable at the time: there were hardly any standard contracts with the providers, no clear commitments on storage and little experience in building language models into your own systems.

In 2026 it looks different. The large providers offer programming interfaces, APIs for short, through which your systems talk to the model directly. For these interfaces, OpenAI and Anthropic both state by default that inputs are not used for training. Storage for abuse monitoring is limited, at OpenAI to up to 30 days, at Anthropic to seven days. Both offer business customers a zero-retention agreement on request. Data processing agreements, DPAs for short, meaning the contract that governs what a service provider may do with your data, exist as standard documents. Building blocks for pseudonymization run as open-source software on your own server.

The difference: in 2023, “we are not allowed to” was a defensible position. In 2026 it is usually a sign that nobody has looked. Anyone who claims today that AI cannot be used in compliance with GDPR should be able to say which provision exactly stands in the way.

Three objections and what is behind them

”The data leaves the country”

The most common objection. Decision-makers hear “AI” and think of servers in the United States. The architecture we build looks different.

The actual data processing runs on servers at Hetzner in Germany, ISO 27001 certified. Customer data, documents and logs stay there. Only the individual request goes to the model provider and it goes through a filter. This filter on your server replaces personal details with placeholders. “John Smith, born 15 March 1985, customer number 47291” becomes “Person A, Date B, Customer C”. The model processes the pattern, never the identity. The translation back happens on your server again.

What reaches the provider therefore no longer identifies a person. That is the pseudonymization GDPR itself defines in Article 4 and names as a protective measure in Article 32. Data sovereignty is not a hope. It is a decision about where each step runs.

An honest limitation: with free text, pseudonymization is never perfect. A customer who describes their address and their daughter’s illness in an email will not be fully recognised in every case. That is why the DPA and the provider’s storage commitment belong in as a second layer. One measure does not replace the other.

”The AI trains on our data”

Two different products get confused here. ChatGPT in the browser and the OpenAI API are not the same thing. With the browser product, the individual user accepts terms that may allow use for product improvement. With the interface, your company signs a contract. The provider is then a processor under Article 28 GDPR, just like an external payroll provider that processes your salary data.

For the interfaces of the large providers, the default is that inputs do not flow into training. That is not a matter of trust, it is in the contracts. Still check the DPA for storage duration and whether subprocessors sit outside the EU. For transfers to the United States you need a legal basis, usually standard contractual clauses or the provider’s certification under the EU-US Data Privacy Framework. That is an afternoon’s work, not six months.

The irony: while companies block their official automation out of fear of training, their employees copy data every day into exactly the browser products the concerns are about. The ban creates the risk it was supposed to prevent.

”AI decisions are not transparent”

Article 22 GDPR governs automated individual decisions with legal effect, such as a credit refusal without human involvement. The reflex: “AI decides, that is prohibited.” Most applications in companies do not fall under it. They prepare, sort, extract and suggest. A human makes the decision. Or there is no decision with legal effect at all.

Where a decision really is made automatically, a human belongs in the loop. Technically that means: the system states with every answer how confident it is. Below a defined threshold, the case goes to a person. Every call is logged with input, output and purpose. That makes it possible to trace at any time why something happened. That is more traceability than most manual processes offer.

What an architecture looks like that carries the review

The data protection officer can only approve a project if there is something concrete to review. These four layers give them that.

Layer 1: Pseudonymization. Before any contact with the model, the data passes through the filter on your server. Personal details are replaced with placeholders and put back locally.

Layer 2: Contract with the provider. The interface is used under a DPA. No training, limited or no storage, documented subprocessors, legal basis for the third-country transfer.

Layer 3: Data storage in Germany. Everything stored permanently sits on your server in Germany: customer data, knowledge store, logs. No detour through other people’s data centres.

Layer 4: Log and deletion. Every call is recorded with timestamp, pseudonymized input, output and purpose. Deletion periods are stored as rules and run automatically. An access request under Article 15 can then be answered from the log instead of being pieced together from mailboxes.

For automated invoice processing, the German GoBD apply on top, the principles for proper bookkeeping and record retention. Every posting is stored immutably with a timestamp. The path from invoice receipt through extraction to posting is fully documented. Retention periods run automatically, since 2025 eight years for accounting records and still ten years for annual financial statements. After expiry, data is deleted. A system does not forget that. A person does.

Reviewer’s question	Manual process	Automated process with this architecture
Can something go to the wrong recipient	Yes, through a typo or wrong attachment	Recipient is defined by rule
Are deletion periods kept	Depends on whether someone remembers	Rule runs automatically
How long does an Art. 15 access request take	Days to weeks, pieced together from mailboxes	Retrievable from the log
Who saw what and when	Usually not traceable	Every call logged

Why not automating is also a data protection risk

Manual processes cause data protection breaches in their own way. An employee who manages customer data in Excel can send the file to the wrong recipient. Someone processing job applications by hand can forget to delete them on time. Someone booking invoices manually copies data into tools that were not meant for it.

An automated system does not make these mistakes because the recipient, the deletion period and the system boundary are stored as fixed rules. It makes other mistakes, such as a wrongly extracted number. That is why human review belongs in. But the class of errors that comes from forgetting and mistyping disappears.

Then there is shadow IT. When a company officially bans AI, usage does not stop. It becomes invisible. Employees use ChatGPT in a private browser, upload customer lists to draft emails and paste contract texts into translation services. In projects we see this regularly as soon as we ask before the start. These data flows run without a DPA, without a storage commitment, without a log. The data protection officer who blocked official use has thereby forced uncontrolled use.

What the block costs you

An honest calculation needs no averages from other companies. You only need your own numbers.

First: list the processes that could be automated with AI, for instance maintaining the customer database, invoice processing, customer enquiries, procurement. Second: work out what one case costs today in staff time. Third: estimate what the case costs automated, meaning server plus model calls plus the time for human review. Fourth: the difference times annual volume is the amount every month of delay costs.

The result depends on where you start. For a process with a few hundred cases a year, the block is cheap. For thousands of cases with a quarter of an hour of manual work each, it is not.

What you can check now

The strategic question is not “Are we allowed to use AI?”. The question is which project you put in front of the data protection officer in a form they can review.

• Take one concrete project, not “AI in the company”. One process, one type of data, one purpose.
• Write down which data flows where and at which point it is pseudonymized.
• Get the model provider’s DPA and check training, storage duration, subprocessors and the legal basis for the transfer.
• Define where a human decides and how that is logged.
• Ask your employees which AI tools they already use today. The answer is usually the strongest argument for a controlled offering.

If the data protection officer still blocks after that, they have a concrete objection you can fix. Or it is not about data protection. We are happy to discuss what such an architecture looks like in your environment in a conversation.