Somewhere in your company there is an AI tool that a team put together in a week, and nobody has thought about it since. That part is fine. A tool built fast can be a perfectly good experiment, and killing it now would teach you nothing at all.
Nobody, though, can answer for it. Where the data sits, what touches it, who answers when it is wrong: none of it was written down. That gap has been counted.
The most recent Finnish count is from spring 2025, when 38 per cent of enterprises reported using AI technologies, fourteen percentage points more than a year before. Only 15 per cent had documented any rules for using them (Statistics Finland, published 27 November 2025). That is still the newest reading. It shows adoption climbing more than three times faster than the documentation meant to keep up with it. So, five questions to ask about any AI system in your company.
Buying the tool does not move the accountability
Start with what is already settled. Under the GDPR, your company is responsible for the processing that tool performs, and it must also be able to demonstrate that it complies. Those two duties are Articles 5(2) and 24. Neither of them moves when you buy the software from somebody else, and neither moves when your own people build it in a weekend.
Which is why the questions below are not curiosity, and not an audit of the team who built the thing. They are the account you already owe. Asking them collects what is already yours.
The five questions
Ask them one system at a time. Put them to the person who actually built or bought the tool, rather than to the vendor’s website. A vendor page answers a slightly different question, beautifully.
- Where does the data sit? Name the country and the provider. Include the uploaded files and the search index as well, not just the row in the database.
- What touches it? List every service and model that sees the data. Ask in writing whether they train on it.
- What can it do without a human? Name the authority the automation holds. Ask whether every write it makes is attributed to it, and whether a single switch stops the whole thing.
- How do you get everything out? Ask for the export formats. Then ask who has ever run a full export.
- Who answers when it is wrong? Ask for a name. A shared inbox is not a name.
None of these is a technical question. Each has a short answer. Where the answer is missing, you have found the work.
Grade the answer, not the confidence
The answers will arrive sounding confident. Confidence is not the signal you want. Grade them on two other things.
First, whether the limit arrives with the fact. An answer that says plainly what has not been done yet is worth more than a polished one that lists only successes. So you find the gap yourself, later.
Second, whether the answer describes structure or intention. “Nobody is allowed to look at another customer’s data” is a policy. “There is no shared table with a customer column, because there is no shared table” is an architecture. A policy can be misconfigured. An absent table cannot. Both signals are free to check, and both of them work on any supplier you have been paying for years.
Where the law already answers for you
Two of the questions have a legal floor under them, and it has been there long enough to be unremarkable. Since September 2025 a cloud or software provider must publish the jurisdiction its infrastructure sits under (EU Data Act). So somebody owes you that answer. Exit has a floor of its own, because a cloud or software contract must support your exit.
A floor is not an answer, though. Somebody underneath that tool still owes you the specifics, and the law only stops them treating the question as unreasonable.
The same five questions, about us
It is only fair to turn the five questions around, so here are our own answers, in short form.
Each installation runs inside the European Union, in the AWS Europe region in Ireland. The database, the uploaded files and the search index all sit inside that one deployment, and nowhere else. Each customer gets a deployment of their own. Own database, own backend, own address. Nothing is shared.
Nothing in a customer’s installation trains a model, ours or a provider’s, because the models are reached through business APIs whose terms exclude API traffic from training. That is contract language, not preference.
Automation writes as a named service account with less authority than an administrator, and cannot delete data or manage users. Every write is attributed. Revoking it is one switch.
Every record exports as JSON. Documents keep their Markdown text, and the uploaded files come back exactly as they were handed over. Full exports of live deployments have been taken. That is the only version worth anything.
Every engagement has a named senior owner. No support desk stands between you and the people accountable.
Now the limits, in the same breath. There is no security certification today. We will not imply one. Nor is there a published response time for export requests, because timing belongs in the contract, where it is enforceable.
Start with one tool
Without the five questions, the answer arrives during an incident. That is the worst moment to learn where the data sits, and by some distance the most expensive. With them, the answer arrives on a quiet Tuesday, in writing, from somebody who had time to check.
So pick the AI tool that touches the most sensitive data, and ask the five questions about that one. Write the answers down. Including the ones that come back missing. Then set a date to ask again.
You do not have to invent the framework. NIST, the United States standards body, publishes a free AI risk management framework built on four functions. Govern, map, measure and manage.
Using it is voluntary.
A tool nobody can vouch for is not a security problem. It is an ownership problem, and the owner has been named the whole time.