A team at a healthcare organisation wants to use a tool that records and summarises meetings. The privacy officer opens the vendor's website and reads: ISO 27001, EU hosting, "GDPR compliant". Three ticks. She knows that is not an answer, but nor does she know straight away what the questions should be.
The risk of an AI tool cannot be captured in one score. It lies in a set of dimensions you can work through one by one, two of which concern not the tool but your organisation. So the same tool can be low risk for one department and high risk for another.
Why does a single score not work?
A score is useful when you want to rank hundreds of tools. But when you take a decision on one tool, that is exactly when you want to know where the number came from. A tool with an average score can be mediocre on every dimension, or excellent on six and unacceptable on one. That difference decides the outcome, and the number hides it.
There is a second reason. A score for a tool can only tell you about the tool. It cannot tell you whether a team is going to put client data into it. An assessment that looks only at the vendor is half an assessment, however thorough.
Which dimensions matter?
Nine, roughly in order of how much they usually tell you. Each comes with one question. If you can answer all nine, you have enough to base a decision on; if you cannot answer three of them, you at least know where the remaining work lies.
| Dimension | The question you ask |
|---|---|
| Input | What happens to what someone enters: is it stored, for how long and who can access it? |
| Training | Is input used to improve the model, and does that differ by account type? |
| Processing and law | Where does processing take place, and which law governs the vendor and its parent company? |
| Data processing agreement | Is a data processing agreement available, and on which plan? |
| Certifications | Which certifications does the vendor hold, and which are relevant to this processing? |
| Integrations | Which other systems can the tool reach: calendar, email, documents, source code? |
| Incidents | Which incidents are known, how were they handled and is the source verifiable? |
| Intended use | What will the organisation use the tool for: summarising, writing, transcribing, code? |
| Personal data | Which personal data is likely to go in with that use, and how sensitive is it? |
The first seven questions go to the vendor, or to its documentation. The last two go to the team that wants to use the tool. They matter just as much, and they are the ones most often skipped.
What happens to the input?
This dimension carries the most weight, and its question is the one most often reduced to "is it trained on?" Training is one thing that can happen to your input. Storage, retention, human review on suspicion of abuse and technical logging are four others, and they happen even at vendors that do not train on your input. What the training promise does and does not cover is set out in our explainer on what "no training" really means.
So ask about each category: conversation content, attachments, technical logs. Ask for the retention period and whether it can be configured. And ask whether the answer differs between the free account, the business account and the API, because at nearly every vendor it does.
Where is it, and who owns it?
Two questions that tend to get asked as one. A vendor running in Frankfurt may be an American company, in which case the location of the data centre does not tell you which government can compel disclosure. What comes into play then, and why the retention period often matters more than the region, is covered in our article on where your data goes.
For the assessment, note three things: the processing region, where the contracting party is established and whether there is a parent company under another jurisdiction. "We host in the EU" is one of the three.
Is there a data processing agreement, and for whom?
If the tool processes personal data on behalf of your organisation, the vendor is a processor and a data processing agreement goes with that. The major vendors offer one, but only on their business plans. The free account runs under consumer terms, without one. When you need one and what it must contain is explained in our article on data processing agreements for AI tools.
For the assessment, then, the answer is never "yes" or "no" but "yes, on plan X". That immediately determines which account the organisation has to buy if it wants to allow the tool.
What does a certification tell you, and what does it leave out?
An ISO 27001 certificate says the vendor has organised its information security according to a standard and that an external party has audited it. That is valuable. It says nothing about training, jurisdiction, the retention of your prompts or what your people enter.
So do not count logos; look at relevance. For a healthcare organisation, NEN 7510 (the Dutch standard for information security in healthcare) is relevant; for an education provider, FERPA in the United States or the Dutch agreements on pupil data. A certification that does not fit the processing does not count. And mind the difference between "our hosting is certified" and "we are certified". Both can be true, and they mean different things.
Which systems can the tool connect to?
A chatbot you paste text into sees what you paste. An assistant with access to your calendar, your email and your documents sees everything it can reach, including things you never meant it to see. So a tool's reach changes with every integration, and a tool that was low risk when you bought it can stop being so one feature later.
For each integration, ask: under whose permissions does it run, with what scope and can that be narrowed? A tool allowed to search "everything in SharePoint" inherits every overly broad permission granted there over the years.
Which incidents are known?
Every major vendor has had incidents. On its own that is no reason to reject a tool. What counts is the pattern: how quickly it was reported, how it was resolved and whether the source can be checked. The Grok chats that Google indexed through share links in August 2025 are a useful example: Forbes broke the story, which gives you a source to record. An incident without a verifiable source is a rumour, and a rumour does not belong in an assessment.
Record the source for each incident. An assessment that someone rereads a year later should still show where each judgement came from.
What is the intended use, and which data?
This is where the assessment turns from vendor research into a decision. Using a tool to draft slogans and using the same tool to summarise performance reviews are two different processing operations. In the first, personal data is unlikely to be involved; in the second it certainly will be, and sensitive data at that.
Ask the team what it plans to do, and work out from that which data is likely to go in. Not "which data is permitted", because that is in the policy, but which data will actually go in. That answer determines whether you need a data processing agreement, whether a DPIA is on the cards and which condition goes with the decision.
Why can the same tool be both low and high risk?
Because the dimensions are not all about the tool. Two of them, intended use and personal data, are about your organisation. And of the other seven, several change with the account: training, data processing agreement, retention and admin settings differ between the business account of a tool and its free account. That difference is large enough to justify two separate assessments, as explained in free versus business AI accounts.
An accountancy firm assessed a chatbot for two teams. The marketing team wanted to use it to rewrite copy, on the business licence with a data processing agreement: fine on every dimension, low risk, allowed. The assurance team wanted to use it to summarise annual accounts, and turned out to be doing so already through a few staff members' free accounts: no data processing agreement, training not switched off, client data in the input. Same tool, two decisions. For the assurance team, the decision was: not allowed on a free account, allowed on the licence, provided client names are replaced first.
The questions you put to the vendor to fill in the first seven dimensions are written out in approving an AI tool: what to ask the vendor, with a good answer and an evasive one for each.
How does this become a decision?
An assessment is only worth something once it leads to a decision that is recorded and that people see while they work. Otherwise it is just a document in the archive. The decision takes one of four statuses, and "Limited use" carries the condition that follows from the assessment.
BeeSensible maintains a catalogue of over 1,000 AI tools, listing for each tool the vendor, its country, certifications, the training policy, whether a data processing agreement is available and documented incidents with a source. Each tool gets a risk score across six weighted dimensions: data governance (weight 6), jurisdiction (4), compliance (3), incidents (3), integration (2) and vendor trust (2), up to a maximum of 100. The bands are Low below 40, Medium from 40 to 59, High from 60 to 79 and Critical from 80. Free and business versions of the same tool are listed as separate rows, each with its own score.
