Written to be forwarded. Take it into the room and use it on us.
A control you can describe is a policy. A control that emits a record every
time it fires is evidence — and in a review, only the second one counts for
much.
That single distinction is what most AI vendor conversations turn on once a data
protection officer joins them, and it is why those conversations so often go
badly for the vendor. Not because anyone is hostile. Because the vendor arrived
prepared to describe capabilities and was asked to produce artefacts.
Below are ten questions. They are written to be pasted into a procurement pack
and used verbatim. Use them on us as readily as on anyone else — we have
published them because a vendor unwilling to be asked has told you something.
This post is about what makes an answer good. It is not legal advice and it
makes no claim about what any regulation requires — your counsel owns that
question, and it deserves its own conversation.
1. Show me the record
For a request made three months ago, produce what was asked, what was
retrieved, which model answered, and what was returned.
Not a description of the logging capability. The record.
This is the first question because it is the one that separates systems that
were designed to be reviewable from systems that have a logging feature. If the
answer involves "we could enable that" or "it depends on your retention
settings", you have learned the answer.
A good answer: a record produced on the spot, showing the request, the
retrieval set, the model version and the output.
2. Show me it has not been edited
What makes that record tamper-evident, and how would I detect alteration?
A log file that an administrator can edit is a note, not a record. The question
is what property makes after-the-fact modification detectable.
A good answer: a described mechanism — a hash chain, an append-only store —
and an explanation of what a reviewer would check.
3. Where does processing physically occur, and what would have to change for
that to stop being true?
The second half is the real question. Anyone can answer the first half.
If processing stays where it stays because of a configuration setting, it is a
setting — and settings get changed, by people, during incidents, at speed. If it
stays because no route out exists in the code path, that is a property.
A good answer: an explanation of what enforces it, and an admission of what
would have to be rebuilt for it to change.
4. What happens when a control is unavailable?
Does the request fail, or does it proceed?
Fail-closed and fail-open are different products and the difference only
becomes visible under load, which is exactly when nobody is watching.
A control that can be skipped when a component is unhealthy is not a control; it
is a default. Ask specifically about the privacy or redaction step, and about
what happens if the retrieval layer is down — a system that answers from the
model's own knowledge when retrieval fails has just changed what it is, silently.
A good answer: refusal, described plainly, with the trade-off acknowledged.
5. Who else is in the processing path?
Name every sub-processor. What is the notification mechanism when that list
changes, and does my consent gate it?
The list matters less than the change mechanism. A list is a snapshot. What
you are procuring is a relationship that will outlive the snapshot.
A good answer: a complete list, a notification commitment, and an honest
statement of whether you get to object.
6. What can I read, rather than be told?
Which components can my security team inspect as source code?
Most vendors' answer is "none", and that is not automatically disqualifying —
but it establishes that everything else in the conversation is being taken on
trust, which is worth naming out loud.
A good answer: something specific and checkable. In our case the privacy
filter is published as an MIT-licensed library, which means the code that
inspects your data can be read rather than described. We point at it because it
is the one claim we make that you can verify without our cooperation.
7. How is personal data handled before inference, not after?
Detection after a model has seen the data is cleanup, not minimisation.
This question separates architectures cleanly. If the screening step runs on the
output, the model already processed the raw material — whatever the output looks
like.
A good answer: a screening stage that sits between the input and the model,
and a description of what it detects, including identifiers relevant to your
jurisdiction.
8. How is scope enforced between projects or departments?
Show me the configuration and the log that proves it held.
Ask the follow-up that matters: is the constraint expressed in the agent's
instructions, or enforced beneath it? A constraint expressed in a prompt is a
suggestion to a language model. A constraint enforced in the retrieval layer is
a boundary.
And ask how your existing document permissions reach the system. An index that
does not inherit your source estate's access model will surface documents to
people who could not open them where they came from — and it is invisible in
testing, because pilot users usually have broad access.
A good answer: entitlement captured at ingestion, enforced at retrieval, and
a log demonstrating it.
9. Which model version answered, and can you prove it?
Silent model updates are a governance problem in a reviewable context whatever
they do to output quality, because they destroy your ability to explain why an
answer changed between March and June.
A good answer: pinned versions, a change log, and the version recorded
against each request.
10. Sort your own controls into two columns
What in your proposal is a contractual promise, and what is a structural
property?
The sorting is more informative than the answer. A vendor who can do it
quickly has thought about the difference. A vendor who resists the exercise has
told you which column most of their controls belong in.
How to read the answers
Three patterns are worth watching for.
Contract language where an artefact was requested. "We are contractually
obliged not to" is an answer to a different question than "show me". Both may be
true; only one is evidence.
Capability described in the conditional. "That can be configured", "that
would be available", "we can enable that for you" — all of these mean it is not
currently true, and all of them will read in your notes as though it were.
Discomfort with question 10. Nobody enjoys it. The useful signal is whether
the discomfort comes with an attempt or instead of one.
And the question to ask us
The same ten. If our answer to any of them is a promise where you asked for a
record, write it down and hold it against us — that is what publishing this list
is for.