A related piece, why 95% of enterprise AI pilots fail inside regulated institutions, looked at a number worth sitting with: 95% of enterprise AI pilots deliver no measurable impact, and the reason is not that the models are weak. There is a specific mechanism by which these projects die inside a regulated institution, and it has almost nothing to do with the AI itself.
A common assumption is that the decision about an AI system gets made in the demo: the tool reads a document, drafts a response, the room is impressed, and the deal moves forward or does not, based on output quality.
The evidence from how banks and payment companies actually procure software points to a different room. The demo is rarely where the project dies. It dies later, quietly, in a review most AI teams never sit in on.
The first question is not about the model
When a regulated institution evaluates software, one of the earliest questions, often the very first, is not "how accurate is it?" It is:
"Where does our data go?"
For AI specifically, that question has a sharp edge. Nearly every AI product on the market works the same way underneath: data is sent to the provider's servers, the model runs there, and the answer comes back. That is the shape of almost the entire industry, an API a customer sends data to.
For a consumer application, that is a reasonable trade. For a bank, it can be disqualifying before anyone has looked at a single output. Sending customer records, transaction data, or account information to an external, multi-tenant AI service is, for many institutions, not a negotiable preference. It is a data-residency or data-sovereignty problem, and in plain terms, it is often simply not permitted, regardless of model quality.
The sequence plays out predictably. The vendor delivers a strong demo. The room is impressed. The project moves to security review. Someone asks where the data goes. The answer is "our cloud." The project ends, not because the AI underperformed, but because the delivery model was incompatible with the institution on a level the demo never touched.
This almost certainly happens more often than the 95% figure alone suggests, and it gets miscounted as "the AI did not deliver." In many of these cases, the AI never had the opportunity. It failed procurement, not performance.
The industry's default is the exact thing regulated buyers reject
This is not an edge case the AI industry overlooked. It is the industry's default delivery model running directly into the one constraint a regulated buyer cannot waive.
The frontier labs are informative here, because their own enterprise strategy quietly concedes the problem. The most valuable enterprise AI engagements are rarely sold as "call our API." They are delivered by teams embedded inside the customer, deploying into the customer's own environment. When the organisations with the most capable models in the world conclude that reaching serious enterprises means going to the data rather than pulling the data to them, that says something about where the real constraint sits.
The constraint is not intelligence. It is location.
The question flips
Once the delivery model is understood as the actual bottleneck, the operative question stops being "how good does the model have to be?" and becomes something structurally different:
If a regulated institution cannot send its data out, what does an AI system have to look like so that it never has to?
That means the entire delivery model inverts: the AI runs inside the institution's own environment, on its own infrastructure, so that no customer data ever leaves the perimeter. No new data-sharing agreement. No cross-border transfer. Nothing new added to a compliance register. The institution runs the software, rather than sending its data to a service.
That is a materially different kind of product than "an AI API." It changes what can be built, how it is deployed, and even what can be charged for. It may be the difference between landing in the 95% or the 5%.
This is the deployment model CaseClear is built on: the system runs inside the institution's own VPC, so customer data never leaves the perimeter. Deploying inside the walls raises its own questions, which model runs there, who keeps it current, and what it is allowed to do without a human in the loop. That last question is the more interesting one: not where the AI runs, but what it should be permitted to decide on its own, covered in what AI has to be before a compliance officer signs off.
Related. What AI has to be before a compliance officer signs off works through what it actually takes for a compliance or risk owner to sign off on an AI system touching regulated casework.