“Can we use this tool with this data?” is a question I hear regularly. It often comes after the strategy discussion, when someone has to decide what their team can use the following week.
My answer used to stop at the dependencies: the license tier, its processing agreement, the kind of data involved, and whether the tool sends information to the web. Those distinctions are necessary. They still leave someone with a lot of reading before they can make a decision.
I wanted to help with that part, so I built an interactive reference at kilga.io/tools/ai-data-protection. It compares 38 tool tiers from ten providers: OpenAI, Microsoft, Anthropic, Google, xAI, Mistral, Perplexity, GitHub, Aleph Alpha and DeepL. The assessment considers the GDPR context in Germany and Austria and the revised FADP in Switzerland, alongside confidentiality and professional-secrecy requirements.
You choose the type of data you are protecting, then compare tiers against six questions:
- Can you use it with personal data?
- Can you use it with confidential data?
- Can you use it with professional secrets, including those covered by §203 StGB in Germany and Art. 321 StGB in Switzerland?
- Does the provider reserve the right to use inputs for its own purposes, including training?
- Is the tier intended for use within a company?
- Can it be used through a bring-your-own-key Office add-in?
The Office question comes from conversations with people who want to work in the document they already have open. An API connection through an add-in needs its own assessment. Permission to use a browser application does not answer every question about that integration.
Making the terms easier to check
A provider’s relevant commitments may be spread across general terms, product terms, privacy notices and processing agreements. Different tiers can refer to different documents, and those documents change independently.
I have seen policies that name a few approved tools and send every other request through an exception process. That can work if the process gives people an answer in time. When it cannot, teams start making their own decisions, and the written policy stops describing what is happening.
The reference brings the documents and my reading of them together. It should make it easier to prepare a specific question for a data protection officer, security team or legal adviser. It cannot remove the need for those conversations.
Showing the reason behind an assessment
A rating helps you scan a comparison. It does not explain a decision to someone else.
Each assessment therefore opens into its reasoning: the agreement behind that tier, the provider’s stated rights over inputs, any relevant conditions on web access, and a link to the source. You can check the wording and decide whether you agree with my interpretation.
I spent time on the interaction design because a comparison of this size can become unreadable. The more difficult part was deciding how to show conditions without making the overview unusably dense.
Keeping conditions and judgment visible
The tool distinguishes between meeting minimum requirements, requiring additional measures, failing the requirements, and cases where a question does not apply. The details also identify reservations that reflect my judgment.
That separation matters. A tier may be usable only after a processing agreement is in place or a feature has been disabled. Another may meet a contractual minimum while still leaving me uncomfortable with the proposed use. Those are different conclusions, and readers should be able to see how I reached them.
A simple yes can conceal work the organization has yet to do. A blanket no can exclude a workable option. I would rather show the condition and leave the decision open to scrutiny. Someone else may read the same clause and judge the remaining risk differently.
Sharing the assessment
These decisions often happen in a message thread between the person who needs a tool and the person responsible for approving it.
Filters, pinned comparisons and the open detail panel are included in the URL. Sharing a link lets another person open the same view and follow its sources. That is more useful than passing around a screenshot whose date and underlying terms are difficult to recover later.
What the reference cannot decide
The reference is my assessment of published terms, not legal advice or approval for a particular deployment. Two pieces of work remain with the organization using it.
First, configuration. The license actually purchased, enabled settings, connected data sources and access rights need to match the intended use. A favorable contract assessment does not show what a particular account or integration is doing.
Second, the organization’s own risk assessment. Personal data, confidential information and professional secrets involve different obligations. The right decision also depends on the sector, commitments to clients and the proposed workflow. The tool cannot classify an organization’s data or make those decisions on its behalf.
Keeping the reference current
Terms change, and providers rename or split their offerings. I intend to maintain the reference, but there may be a delay between a provider’s change and my update.
That is another reason to show the source beside the assessment. Before relying on a conclusion, check that the linked terms still apply to the tier and use you have in mind. If my interpretation seems wrong, the source gives us something specific to discuss.