A tender specifies that processing must happen inside 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 working memory and does not keep the text.
All three can explain why their answer is correct. And all three leave you with a materially different risk. That is why the region is only one of the questions, and not even the most important one.
The three questions behind where your data sits
Which law the provider falls under. Usually asked as "where does the server sit", 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 sits in Europe. The question that separates providers is not where the machines are but who owns them: a European company with no US parent has nobody who can receive such an order.
How long it stays there. The question that matters most and gets asked least. For as long as text is kept somewhere, it exists: it falls under a retention period, it can sit in a breach, it can be subpoenaed, and it can be read back later. If it disappears right after the check, none of that happens.
Who can read it. Inside a vendor, that is a separate question. Can staff reach content, and if so what for: support, quality, model training? Is it closed off technically, or only in a policy document?
Those three together decide your actual risk. An American vendor with a European region that keeps text for thirty days and allows human review is a heavier story for your DPIA than a European vendor that holds on to 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 goes back. It is never written to disk, so there is no file, no backup, and no conversation history it can later be pulled from.
That is not the same as "we keep nothing longer than necessary", a sentence that can mean almost anything. The difference is verifiable, with two questions:
- Which tables exist, which fields do they hold, and how long do they stay? A retention table that names this per type of data is a different kind of answer from a reassurance.
- What goes into the logs? A vendor that keeps nothing but logs full requests is still keeping your text, just somewhere nobody looks for it.
For a DPIA this saves 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 deletable when someone asks, so it brings its own work.
That is why "what do you keep" is a more important question than "how do you secure what you keep". The second is a control. The first is a design decision, and it weighs more.
Statistics that hold no people
There is one more place where data stays behind, and it is easy to miss: the reporting. A tool can keep no text at all and still record exactly who did what.
So the question is not only whether content is kept, but whether the numbers carry a user id. If they do, every number can be traced back to a person afterwards, whatever the dashboard chooses to show today. If they do not, that possibility simply does not exist, not even for the vendor.
Push on two things: does the data carry a user id, and is there a per-employee view. That is the difference between insight into patterns and monitoring of people, and it is the difference your works council will want to hear.
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 reach the content, including inside your own organisation?
- Do the numbers carry a user id, and does a per-employee view exist?
Answer those four and you have explained an architecture. Say only "we process in Europe" and you have said a marketing line.
How we do it
We get these questions too, so here are our answers.
Detection runs on our own servers at European providers: the application, the database, and the storage on Scaleway in the Amsterdam region, the models on a dedicated server at Hetzner in Germany. Those are not European regions of an American cloud but European companies: Scaleway is 96% owned by the French Iliad group, and Hetzner Online GmbH sits 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 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 working memory and discarded straight after. It is not written to disk, not logged, and not used to train models. What we do keep is one row per marking: which type of sensitive data it was, the level, the app, the moment, and what the user did with it. No text, and no user id, because the database has no column for one. Those figures are kept for at most 24 months.
So the dashboard shows patterns and never people. There is no drill-down to an individual employee, and who did something cannot be reconstructed afterwards, not even by us. That is not a setting you switch on, it is how it is built.
To hold it 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 arranged.
