Popular AI Tools: What About Data Protection?

The question always arrives at the end of the meeting. The strategy part is finished, people are picking up their laptops, and someone remembers they have to do something real on Monday. Can we use this tool with this data? For a long time I gave the correct answer. It depends on the tier you are on, on the processing agreement behind that tier, and on whether the tool reaches the web. Every part of that is true. None of it helps a team lead who has to make the call this week and does not have a lawyer to hand. I used to think giving that answer was intellectual honesty. It was not. It was handing the hardest part of the question back to the person in the room least equipped to answer it, and then feeling rigorous about having done so. So I read the documents and built the thing I wanted to exist: an interactive reference at kilga.io/tools/ai-data-protection that maps roughly 38 mainstream AI tool tiers against DACH data-protection law. Germany and Austria under GDPR, Switzerland under the revised FADP. Ten providers (OpenAI, Microsoft, Anthropic, Google, xAI, Mistral, Perplexity, GitHub, Aleph Alpha, DeepL), from consumer accounts through to API. You pick the class of data you are protecting, and it ranks and colour-codes every tier against six questions:

Can you use it with personal data?
Can you use it with confidential data?
Can you use it with professional secrets (§203 StGB in Germany, Art. 321 StGB in Switzerland)?
Does the provider reserve the right to use your inputs for its own purposes, including training?
Is it usable inside a company at all?
Can it be driven from a bring-your-own-key Office add-in?

That last question looks like a technical footnote and is not. It is the shape of what people actually ask me for. They do not want another chat window, they want the model inside the document they are already working in, and whether that path exists for a given tier is a separate question from whether the browser app is usable.

Nobody reads twelve documents before picking a tool

Every provider on that list publishes its terms, its processing agreements and its position on training across roughly a dozen documents, written by lawyers for lawyers, versioned independently, each one referring you to the next. Multiply that by ten providers and several tiers each. The reading is not difficult. It is long, it is dull, and it has to be redone whenever anything moves. So it does not happen. The AI policies I get shown name a handful of approved tools and route everything else through an exception process that nobody uses, because filing an exception takes three weeks and the deadline is Thursday. What that produces is not caution. It is a policy covering four tools and an organisation running on forty.

A colour is not a reason

First design decision. Traffic-light matrices are everywhere in this space, and most of them are decoration. A cell that says yes or no answers the question once, for the one person looking at the screen, and then it dies. The moment that person has to defend the decision to a data protection officer, a client's security team or an auditor, they need the clause. The colour is worth nothing in that room. So every verdict in the tool opens into its reasoning. Which agreement governs that tier. What the provider reserves the right to do with your inputs. Whether web access changes the contractual terms. A link to the governing document, so you can read the paragraph yourself and decide whether I have read it correctly. The colour exists so that you can find the paragraph quickly. The paragraph is the thing you take into the room. I assumed the hard part of building this would be the interaction design. Ranking 38 tiers against six questions without producing something unreadable is a genuine problem and I spent real time on it. It was not the hard part.

There are three answers, and the third one is mine

The hard part was refusing to round. Almost none of these tiers resolve to a clean yes or a clean no. They resolve into one of three states: it meets the requirement, it is workable if you add measures on your side, or it is technically permitted and I would not recommend it. The third state has no home in a compliance framework, because it is not a legal finding. It is a judgement. The tool labels it as mine rather than dressing it up as a rule, which means you can look at the same clause, weigh it differently and land somewhere else. That is a legitimate outcome and the format has to allow for it. Quietly promoting my judgement into a green cell does not allow for it. Two states would have been easier to build and far easier to put on a slide. It would also have made the tool actively misleading, because a green cell gets read as permission and nobody reads the footnote qualifying it. The middle state is where most real enterprise usage sits, and it is precisely the state a binary destroys. Round it up and you have told someone a tool is safe when it is only safe with work they have not done. Round it down and you have banned a tool the organisation is already using every day, which teaches everyone that the policy is detached from reality and can be ignored. Both failures are worse than the "it depends" I was trying to get away from, because both of them sound authoritative.

A governance answer has to survive being pasted into a channel

Second design decision. Decisions like this do not get made inside the tool. They get made in a thread on a Thursday afternoon, between someone who needs an answer and someone who has to put their name on it. So the state round-trips through the URL. Filters, pinned comparisons and the open drawer all live in the query string. A specific view is a link. You paste it, the other person opens exactly what you were looking at, and the sources travel with it. The alternative is a screenshot, and a screenshot is how governance artefacts die. It arrives with no date, no source and no way to tell whether the terms behind it have moved. Nine months later someone quotes it back at you as settled fact.

The contract is the easy half

What this tool does is read contracts. It is not legal advice, and I am not going to soften that with a disclaimer paragraph, because there are two specific gaps it cannot close. The first is configuration. A tier can be contractually clean and still wrong in your environment, because a setting was left on, a connector was wired to a data source nobody reviewed, or the licence someone actually bought is not the tier the assessment covers. The contract describes what the provider may do. It tells you nothing about what your instance is currently doing. The second is that the risk assessment stays yours. Personal data, confidential data and professional secrets are different problems with different consequences, and those consequences depend on your sector, on what you have promised your own clients, and on how much residual risk your board is willing to carry. The tool ranks tiers against the class of data you tell it you are protecting. Deciding which class your data is actually in is work it cannot do for you, and it is usually the decision that matters most.

These verdicts have a shelf life

Some of what is in there will be wrong by autumn. Terms get revised, tiers get split and renamed, and there is no feed you can subscribe to that tells you a clause you relied on has changed. I will maintain it, and I will still be behind sometimes. That is not a flaw I can engineer away, and it is the reason every cell carries its source rather than my authority. Showing the reasoning is what makes it possible for you to check whether I am still right, instead of trusting that I am. Governance work in this area is not blocked on frameworks. There is no shortage of frameworks. It is blocked on somebody doing the reading and then being willing to write down a position specific enough to be wrong. I did the reading for 38 tiers. The positions are on the screen next to the paragraphs that produced them, and if you think I have called one incorrectly, the clause is right there.