A tender specifies that processing must take place within the EU. Three vendors tick the box. The first runs on a European region of an American cloud. The second is a European company with its own servers, and keeps prompts for thirty days for debugging. The third processes in memory and does not keep the text.
Each of them can explain why its answer is correct, and each leaves you with a materially different risk. Which is why the region is only one of the questions, and not even the most important one.
The three questions behind "where is the data?"
Which law the provider falls under. Usually asked as "where is the server?", which makes it too easy to answer. An American provider with a data centre in Frankfurt still falls under the US CLOUD Act, which obliges it to hand over data even when that data is held in Europe. What separates providers is not where the machines are but who owns them: a European company with no US parent has nobody who can be served with such an order.
How long it stays there. The question that matters most and is asked least. For as long as text is kept somewhere, it exists: it is subject to a retention period, it can turn up in a breach, it can be subpoenaed and it can be read later. If it disappears straight after the check, none of that happens.
Who can read it. A separate question, and one that applies inside the vendor too. Can staff access content, and if so, for what: support, quality checks, model training? Is that access shut off technically, or only in a policy document?
Together, those three decide your risk. An American vendor with a European region that keeps text for thirty days and allows human review makes for a harder DPIA than a European vendor that keeps nothing.
What volatile processing actually means
Volatile processing means the text exists only for as long as the check takes. It arrives, is processed in the server's memory and disappears once the answer has gone back. It is never written to disk, so there is no file, no backup and no conversation history to retrieve it from later.
That is not the same as "we keep nothing longer than necessary", a sentence that can mean almost anything. You can verify the difference with two questions:
- Which tables exist, which fields do they hold and how long is the data kept? A retention table that sets this out for each type of data is a different kind of answer from a reassurance.
- What goes into the logs? A vendor that says it keeps nothing, yet logs full requests, is still keeping your text, just somewhere nobody thinks to look.
For a DPIA, this saves you a whole column. Processing that does not happen needs no justification.
Why storage is the real risk
Stored text is not risky because someone means harm. It is risky because it exists.
What exists can end up in a breach, even when the vendor did nothing wrong. What exists can be demanded by a court or a regulator, as happened in the case about retained chat logs. What exists can be read years later by someone who had nothing to do with it at the time. And what exists has to be erased when someone asks, which is work in its own right.
That makes "what do you keep?" a more important question than "how do you secure what you keep?". The second is about a control. The first is about a design decision, and that carries more weight.
Statistics with no people in them
There is one more place where data is left behind, and it is easy to overlook: the reporting. A tool can keep no text at all and still record exactly who did what.
So the question is also whether the numbers carry a user ID. If they do, the person behind every number can be identified afterwards, whatever the dashboard chooses to show today. If they do not, that possibility simply does not exist, not even for the vendor.
Press the vendor on two points: does the data carry a user ID, and is there a per-employee view? That is the difference between seeing patterns and monitoring people, and it is the difference your works council will want to hear about.
What to ask a vendor
Four questions that separate an architecture from a brochure:
- What data is kept, in which fields and for how long?
- Is content used for model training or human review, and where is that written down?
- Who can access the content, including within your own organisation?
- Do the numbers carry a user ID, and is there a per-employee view?
A vendor that answers those four has explained an architecture. One that says only "we process in Europe" has given you a marketing line.
How we do it
We get these questions too, so here are our answers.
Detection runs on our own servers, hosted by European providers: the application, database and storage on Scaleway in the Amsterdam region, and the models on a dedicated server at Hetzner in Germany. These are not European regions of an American cloud but European companies: Scaleway is 96 per cent owned by the French Iliad group, and Hetzner Online GmbH is based in Gunzenhausen, Germany. So there is no US parent that has to comply with a CLOUD Act order. Both are ISO 27001 certified; Scaleway also holds HDS certification for hosting health data. No external AI service is involved: nothing goes to ChatGPT, Google or any other party, and the detection model is our own.
The text someone types is checked in memory and discarded straight afterwards. It is not written to disk, not logged and not used to train models. What we do keep is one row per highlight: the type of sensitive data, the level, the app, the time and what the user did about it. No text and no user ID, because the database has no column for one. In the cloud, the only addition is a one-way check value, used so that repeats within the same hour are not counted twice. Those figures are kept for at most 24 months.
So the dashboard shows patterns, never people. There is no drill-down to an individual employee, and because the figures carry no user ID, we cannot look up afterwards who did what either. Figures only appear once there are 5 active users. That is not a setting you switch on; it is how the product is built.
If you want to check all this against your own requirements, the full account is in the Trust Center: what we store, for how long, with which sub-processors and how access is managed.
