Security reviews for conversational AI have settled into a recognisable shape. After enough of them you can predict the order of the questions, and it is not the order most vendor documentation is written in.
What follows is the list as reviewers actually ask it, with the answer shape that ends the conversation rather than extending it.
Where does the data physically sit
The first question is always residency, and it has three parts that get conflated: where conversations are processed, where they are stored, and where any derived artefacts — embeddings, logs, evaluation samples — end up.
Answering only the first is what triggers the follow-up. A review goes faster when you volunteer all three, name the regions, and say plainly which components cannot be regionalised, if any.
How long is it kept, and who decides
Retention questions are really about control. Reviewers want to know the default, whether the customer can change it, what the floor is, and what happens at deletion — whether records are removed or merely made inaccessible.
State the defaults as numbers, not as “configurable”. “Transcripts 90 days, redacted analytics 13 months, model training never” ends the thread. “Retention is configurable to your policy” starts three more emails.
What is the model allowed to see
This is the question with the most variance in how well vendors answer it, and the one reviewers care most about.
- Which fields are passed into the model context, and which are masked before they get there.
- Whether the customer’s data is used to train or fine-tune anything — and if the answer is no, whether that is contractual or merely current practice.
- What the sub-processor list looks like, including the model providers, and how customers are notified when it changes.
“We do not train on customer data” is a sentence that belongs in a contract, not in a slide. Reviewers check.
Access, on your side
Who at the vendor can read a production conversation, under what circumstances, with what approval, and is it logged in a way the customer can audit? Break-glass access is normal and acceptable; unlogged break-glass access is not.
Proving it afterwards
Every claim above eventually gets tested by an auditor or an incident. That means the answer to “how would you prove this?” has to exist before anyone asks: immutable logs, retention jobs that record what they deleted, redaction that is verifiable on a sample, and a report a customer can pull themselves rather than request.
The questions that come from the business, not from security
Two more turn up late and derail timelines when they are unplanned. What happens to the data if we leave — format, timeline, cost. And what does the assistant do when it is uncertain, which is a safety question that risk teams increasingly ask directly.
The honest version of the second answer is the strong one: it declines, it says why, and it routes to a person. A system that always has an answer is a system that will eventually have a wrong one.
