Data protection is no reason to skip AI. It is a requirement for how you build it.

Why fear costs more than technology

Many first conversations with managing directors follow the same script. First, interest in automation with AI. Then the question: “Are we even allowed to do this?” Then standstill. Not because someone checked and said no. Because nobody checks and therefore nobody says yes.

That standstill has a cost. Not as a fine, but as work that keeps being done by hand while competitors automated it long ago. The General Data Protection Regulation, GDPR for short, does not prohibit the use of AI. It requires you to know which data flows where, on what legal basis and for how long it is stored. That is not purely a legal question. It is first a question of how you build the technology. If you sit on old systems, you have a harder time, because nobody there knows any more which data lives where.

One caveat up front: this article is not legal advice. What you read here is the technical part. Whether your specific workflow is permissible is for your data protection officer to assess. They will have an easier time if the technology is built the way described below.

What has changed since 2022

2022. Every AI integration was a one-off. Providers had no data processing agreements a German data protection officer would sign. Whether inputs were used for training was stated nowhere clearly. Anyone who wanted to use AI mostly did so through the consumer chat window, with no control at all.

2026. The major providers offer standard data processing agreements for the API, meaning the access built for software rather than for people at a screen. The terms state that inputs are not used for training. Tools that replace names and addresses with placeholders before sending are available as free software. Data centres in Germany are certified to ISO 27001 and comparable in price to the big US providers. The building blocks for a legally sound setup exist. They just have to be put together.

Three building blocks that carry a review

In projects we keep seeing the same three building blocks that get a privacy review through. None of them is new. Together they turn a gut feeling into an architecture you can document.

The API instead of the chat window

The most common mistake is confusing ChatGPT in the browser with the access built for companies. In the consumer chat window, inputs can be used for training unless the user switches that off. Through the API that does not apply. OpenAI states that data sent through the API is not used for training. By default it is retained for up to 30 days for abuse monitoring and then deleted. For certain use cases you can arrange on request that nothing is stored at all. Other providers have similar rules. Read them before you sign.

Legally, the provider becomes a data processor under contract when you use the API. Transmission is encrypted. That answers the first item on every review: who receives the data, on what basis and how long they keep it.

Servers in Germany

Everything that runs around the model, we operate on Hetzner servers in Germany. The data centres are certified to ISO/IEC 27001:2022. That is where the database, the logs, the workflow engine and the filter from the next section live. In most projects the model itself still runs at the provider, because the large models are better and cheaper there.

In fairness: the server in Germany does not solve everything. As long as the request goes to a model in the US, that is a transfer to a third country with everything that entails. For workflows with particularly sensitive data, such as health data, we therefore run smaller open models directly on the company’s own server. They are less capable, but the data never leaves the building.

Placeholders instead of names

For workflows involving personal data, such as applicant management, invoice processing or customer follow-up, the data passes through a filter on your own server before it is sent to the model. “Mr Mueller, born 12 May 1980, 4 Sample Street” becomes “Person A, born on Date B, Address C”. The model works with the pattern, not the identity. The mapping back to the real name happens on your own server once the answer is back.

Here too there is a limit. The filter reliably detects names, addresses, dates of birth, account numbers and similar patterns. Free text is harder. If an email says “the managing director of the bakery on the high street”, the person may be identifiable even though no name appears. A filter lowers the risk considerably. It does not bring it to zero. Anyone who promises that has not tested it.

Review question	Without a setup	With the three building blocks
Who receives the data?	Unclear, often the chat window	Provider via API under contract
Training on our data?	Possible	Excluded by contract
Where do database and logs live?	In whichever tool	On your own servers in Germany
Does the model see names?	Yes	Placeholders only, with known limits
Who can trace what happened?	Nobody	Every request in the log

What can be reviewed once instead of every time

The economist Ronald Coase described how every transaction carries effort that appears on no invoice. A privacy review is that kind of effort. If every new use case gets its own route to the model, each one has to be reviewed separately. With three use cases a year that works. With thirty it does not. Then either the review or the automation falls by the wayside.

If instead all workflows run through the same route, with the same API, the same server and the same filter, that foundation is reviewed once. A new use case then only needs one question: which data is added and does it fit the reviewed foundation? That is usually a page of text rather than a project. Why the pure computing costs play an ever smaller role in this is covered in the article on cognitive deflation.

That is the difference between a company that needs a lawyer for every new workflow and one that sees its data protection officer for an hour once a quarter.

What you can check this week

1. Ask around your company who uses AI today and through which route. If the answer is “ChatGPT in the browser”, you already have the privacy problem, just without a contract and without a log.
2. Ask your data protection officer which questions they need answered for an approval. Usually it is the five from the table above.
3. Check whether your workflows with customer data could work without names. For most tasks, such as sorting, summarising or matching, the model does not need the identity.

If you then want to know what such a setup would look like for you, write to us. If you want to grow without adding headcount, the article on revenue per employee has the second half of the argument.