If You Can't Point at the Evidence, Don't Write the Sentence

Enterprise buyers have stopped asking whether you use AI and started asking exactly what you use, where it runs, and what happens to their data. The questions are fair. The catch is that your answers expire.

Ask me which region inference runs in and I'll tell you straight away. Ask me to show you where that's written down, evidenced, and still true this morning, and that used to be a much slower answer.

That gap is the whole problem, and it's the one nobody's talking about while everyone argues about model benchmarks.

The questions have changed

The AI section of enterprise due diligence used to be a tick box. Somewhere near the cyber insurance questions, asking whether any "artificial intelligence or machine learning" was involved, and nobody read the answer.

That's gone. What lands now runs to eight distinct areas, and it's written by people who know exactly what they're asking:

Who's the model provider, and where are they incorporated. Which region does inference actually run in, not which region your application sits in. Which models, which versions. Whether the parameters are documented and who can change them. Whether customer data trains or fine tunes anything. How tenant data is isolated in a shared index. Under what mechanism data transfers if it leaves the region. What's retained, by whom, for how long.

This is progress, not friction. Every one of those maps to a real way it goes wrong. "Where does inference run" isn't pedantry when your app is in the UK and your model endpoint quietly isn't. "Does customer data train anything" is the single question that decides whether a regulated buyer can touch you at all. "How is tenant data isolated" stops one customer's documents surfacing in another customer's search results, which is a failure mode that didn't exist in the software these buyers were procuring five years ago.

They're asking better questions than most vendors can answer. Good.

Every answer is a claim about behaviour, written on a date

Here's the bit people miss.

When you fill that form in, you're not describing a policy. You're describing what a running system does right now. "Inference runs in UK South." "Customer content isn't used for training." "Tenant vectors are isolated at index level."

Those are behavioural claims. They're true because of a config value, a deployment definition, a filter on a query, a term in a provider contract. And you record them in prose, in a document, on a Tuesday, and then you file it.

The code carries on moving. The document doesn't.

Nothing dramatic has to happen for the two to come apart. A model gets deprecated and you move to its successor, which is hosted differently. You add a region for latency. Someone changes a retention setting to knock a bit off the storage bill. A provider updates their terms. Every one of those is a sensible engineering decision made by someone who's never read the brief you sent a customer, and has no reason to.

So the honest position: a claim you can't currently point at evidence for isn't a true statement. It's a statement that used to be true. You don't know which until you check, and most people find out at the exact moment a buyer asks them to prove it.

AI speeds the drift up, and it won't warn you

Two reasons this is sharper now than it was three years ago.

Model swaps have become trivial. Changing which model serves a feature is often one line of config, shipped on a Tuesday afternoon by someone doing something entirely reasonable about cost or latency. That one line can invalidate three separate answers on a due diligence form: provider, version, and possibly region. Nothing about the size of the change signals the size of the consequence.

And this is the one I'd underline: the same assistant that writes your code will happily write your security documentation, and it has no idea whether the two agree. This is the same underlying failure mode I've written about before with LLM outputs being inconsistent by default: the model isn't checking itself against reality, it's producing plausible text.

It'll produce a confident, well structured paragraph on tenant isolation. It isn't lying, and it isn't hallucinating in the usual sense. It's describing what a sensible system of that shape would do, based on what you told it. It hasn't read your deployment definition. It can't diff prose against behaviour. It writes both artefacts in the same voice with the same authority, and that authority is doing a lot of work it hasn't earned.

If you're building fast with AI on both sides of that line, your documentation and your code can start drifting in week one, and it'll all look fine, because it all reads well.

How I run it now

Small artefact, not a programme.

I keep a register of the claims I make externally about system behaviour, in the same spirit as the governance and compliance intelligence work I've built to stop tender and certification evidence from going stale between audits. Three columns: the claim, the evidence I'd show, and what would break it. Evidence means something a second person can open. A test that fails if the behaviour changes. A config file in source control. A deployment definition. A signed provider term. A query that demonstrates the isolation.

Evidence isn't my memory of how I built it. It isn't a paragraph I wrote confidently and haven't looked at since. And it definitely isn't the assistant's description of it, however plausible that description reads.

The only real discipline in the whole thing is the review trigger, and it's a deployment, not a calendar date. Claims decay when the system changes, not when the quarter ends. Review them quarterly and you'll spend most of the year holding statements you haven't checked.

The trade-off, honestly

It's overhead, and I'm not going to pretend it isn't.

If you're early, pre first enterprise customer, still finding out whether the thing works at all, building the register now is premature and you shouldn't. The right minimum at that stage is three answers you can give without looking anything up: which models you use, which region they run in, and whether your provider's terms allow training on your data. That's it. Those three cover most of what gets asked first and all of what kills you if you're wrong.

The register earns its place the day the first questionnaire lands, because that's when your prose becomes contractual. Build it then, from what you actually had to prove, not from a template.

The bigger trade is worth naming. This slows down the part of the process AI has made fastest. I can ship a capability in a morning and describe it in ten minutes, and attaching an evidence requirement to the describing is a deliberate brake on the cheapest step in the chain. It feels disproportionate.

It isn't. The code gets checked by whether it runs. The claims get checked by nothing at all, right up until a buyer checks them for you.

The part that's actually an advantage

Answering these precisely, with evidence, on the first pass, is a differentiator. Most vendors can't. They send back marketing language where a specific answer was asked for, and the buyer's security team reads that exactly the way you'd expect them to.

Coming back with the region, the model, the version, the isolation mechanism and the provider term, without a three week gap while someone goes and finds out, tells a buyer more about your engineering discipline than any capability demo will.

The questions are fair. Be the one who can answer them on the day.