Two suppliers pitch the same enterprise. One shows a more capable system. The other can produce, on demand, a complete record of every decision its system made over the past two years, who approved each one, and what data was involved.
The second wins. Increasingly, the first supplier does not even reach the shortlist. This is already true in financial services and healthcare, and it is spreading to every sector where somebody eventually has to answer a question.
The argument of this piece is simple. Capability is becoming a commodity, while provability remains scarce. The firms building for provability are in a much stronger position than they currently look.
Capability is getting easier to copy
The gap between the best available model and a good enough one has narrowed sharply, and the direction is consistent. What was frontier eighteen months ago is now cheap, fast and available from several providers.
The more important issue is procurement. Everyone buys from the same handful of suppliers. If your differentiation is the model, your differentiation is a procurement decision your competitor can replicate in an afternoon.
This has already happened in other layers of the stack. Nobody wins enterprise deals on database performance any more. They win on operability, support and compliance posture. The model is following the same path, faster.
Provability means answering a specific question from records
Provability means the ability to answer a specific question about a specific past event, from records, without reconstruction. A policy document or a general statement about how the system works does not give a buyer that.
An auditor asks about a decision made on a Tuesday fourteen months ago. A provable system can say what the system saw, which version processed it, what it produced, who accepted it, and what the applicable policy was at that moment. It can do that within minutes, from a query rather than an investigation.
Most systems cannot do this. They log outputs and not inputs. They log the prompt template rather than the assembled input. They never recorded the model version. Or the underlying data has since changed, so the request cannot be reproduced.
That last detail matters. If the data has changed, a later reconstruction may look tidy, but it cannot prove what the system actually saw at the time.
The audit record has to capture five things
Concretely, provability requires five things recorded at the time and retained for as long as the question can be asked.
- The exact input. The assembled content, rather than the template. This is the one most often missing and the one auditors ask for first.
- The version composition. Model and version, prompt version, retrieval configuration, code release. Four things that move independently.
- The output as produced. Before any downstream transformation, so you can distinguish a model error from a processing error.
- The human decision. Who reviewed it, what they did, when. An unreviewed output and an approved one are different artefacts and must be distinguishable.
- The policy in force. What the threshold, the routing rule and the permitted scope were at that moment, because they change and the record must reflect what applied then rather than now.
These records need to be captured when the system runs. Keeping them later is too late, because the later record cannot prove the original event.
Provability is a moat because history cannot be recreated
Three properties make provability defensible in a way that capability is not.
- It cannot be retrofitted. You cannot generate historical records you did not keep. A competitor who decides tomorrow to become provable starts accumulating evidence tomorrow, and the enterprise asking for two years of it will wait two years.
- It compounds. Every month of clean records makes the position stronger, and the gap between a firm that started early and one that started late widens rather than closing.
- It is unglamorous. It does not demonstrate well, it does not attract engineers, and it produces nothing visible. That means most competitors will underinvest in it for exactly as long as it remains a differentiator.
This is why the moat is real. A more capable model can be bought. A history of clean records has to be lived through.
Regulators are asking for evidence after the event
This is less a prediction than a reading of what is already in force or drafted across several jurisdictions.
The consistent themes are records of automated decision-making, the ability to explain a decision affecting an individual, human oversight of consequential decisions, and demonstrable governance rather than asserted governance.
Those themes all point in the same direction. They constrain what you must be able to show afterwards. The regulatory burden is falling on evidence, not on capability, which is precisely why the evidence is becoming the competitive asset.
An evidence request becomes specific very quickly
Suppliers who have not been through one imagine a questionnaire. The questionnaire is the easy part and it arrives first. What follows is more specific and less answerable by marketing.
The buyer may pick a transaction from a list and ask you to walk through it. Show the input as the system received it, not as it was stored afterwards. Which model version, and how do you know. Who reviewed the output and what did they change. What was the confidence threshold that day, and when did it last change, and who approved that change.
Then they ask for the same thing for a case the system got wrong. How did you find out. How long between the error and the detection. What did you do about the outputs produced in between.
Then they ask for the evaluation results for the last twelve months as a series, annotated with deployments and model changes.
Every one of those is a query against records that either exist or do not. There is no way to prepare for it in the week before. That property makes provability a moat rather than a hurdle.
Small suppliers can build the evidence layer early
The reasonable complaint is that this favours incumbents. A well-resourced firm can afford compliance apparatus that a small one cannot, and the requirement becomes a barrier to entry that has nothing to do with quality.
That is partly true and less than it appears. The expensive part of compliance is the certification, the auditors, the annual cycle. The part that matters here is architectural: recording the right five things at the point of inference, meaning the moment the model is used to produce an answer or decision. That costs a few days of engineering at the start of a project and nothing thereafter.
A three-person firm that stamps versions and keeps immutable audit records from day one is more provable than a large one that bolted logging on afterwards. Immutable audit records are records designed so they cannot be silently changed later. We have seen exactly that comparison decide a procurement.
What genuinely disadvantages small suppliers is the certification requirement, and that is a real barrier. The evidence requirement is not, and conflating them lets small firms talk themselves out of a position they could hold cheaply.
Documentation without records turns into theatre
The common failure mode is to produce documentation rather than records.
A policy stating that all AI decisions are logged is not evidence that they were. A governance framework is not a query result. An architecture diagram showing an audit component is not the same as the component containing anything useful.
The distinction an auditor applies is simple and most organisations fail it: can you show me, for this specific case, or can you only tell me what your policy says should have happened. Documentation is necessary and it is the part everyone does, because it can be written in a fortnight by people who are not engineers.
Buyers should ask what the supplier can show
If you are procuring, the useful shift is from asking what can it do to asking what can you show me.
The useful questions are specific because evidence is specific.
- Ask for the audit record of a specific request from three months ago. A supplier who can produce it in minutes has built the thing properly. A supplier who needs a week has an investigation process rather than a record.
- Ask what happens when the model changes. If the answer does not involve a pinned version and a scheduled evaluation, their system’s behaviour is outside their control and therefore outside yours.
- Ask how they know it is still working. The answer should be a number produced on a schedule, not user satisfaction.
These questions move the conversation away from the demonstration and toward the operating reality of the system.
Suppliers have eighteen months if the model is the whole story
For suppliers, the hard version is this: if your differentiation is that you use a better model, you have eighteen months.
The constructive version is that the investment that matters is boring. The work is:
- Lineage from day one.
- Version stamps on everything.
- Immutable audit records.
- Scheduled evaluation.
- Named human accountability in the data model rather than in a policy document.
Lineage means the record of where an input, output or decision came from as it moves through the system. It matters because a later question usually starts with one decision and then works backwards.
None of that is expensive if built at the start. All of it is painful to retrofit, and the retrofit produces nothing for the period before it existed, which is exactly the period an enterprise will ask about.
The cost is small at the start and much larger later
Numbers matter here, because otherwise the recommendation sounds aspirational.
On a typical engagement, designing the audit record properly is about two days of work at the start: deciding what to capture, where it is written, how it is retained and how it is queried. Stamping versions on every inference is a few hours. Making the human acceptance a first-class recorded event rather than an implicit one is perhaps a day, mostly spent deciding what acceptance means.
Storage is the ongoing cost and it is smaller than people expect, because the records are text and identifiers rather than payloads. On a system processing forty thousand items a month, the audit trail is a few gigabytes a year.
Against that: retrofitting the same capability onto a running system is weeks rather than days, requires a migration, and produces nothing for the historical period. Every engagement we have joined where this was absent has paid several times the original cost to add it, and still could not answer questions about the year before.
Our own position is strongest on new engagements
We hold ISO 9001 and a CMMI Level 4 appraisal, both re-assessed on their published cycles. SOC 2 Type II readiness is underway and we do not claim it, because the report does not exist yet and claiming a certification you are working toward is exactly the behaviour this piece argues against.
What we do build on every engagement: audit records designed in from the first schema rather than added at review, model and prompt versions stamped on every inference, human acceptance recorded as a first-class event, and scheduled evaluation so a behaviour change is detected in a day rather than a quarter.
Where we are weaker is the same place most firms are weaker: on older engagements, before we treated this as a competitive position rather than a compliance chore, the records are thinner than we would now want. That is not fixable retroactively, which is the whole argument.
Enterprise AI procurement will move before the demonstration
Within three years, enterprise AI procurement will look like enterprise software procurement has looked for a decade. A questionnaire, an evidence request, a review of controls, and a shortlist decided long before anyone sees a demonstration.
The firms that win will not be the ones with the most impressive systems. They will be the ones who can answer what did it do, when, and on whose authority, without anyone having to go and find out.
Our full position on data handling, subprocessors and the AI policy is on the trust centre, and the sector-specific version for regulated work is on the financial services and healthcare pages.
