In most regulated organisations, an AI pilot is judged by a single question: does it work? A model is trained on a sample, the results look promising, the business sponsor is convinced. Then the use case is handed over for approval, and the project stalls.
It rarely stalls because someone says no. It stalls because the people who have to approve it ask for things the pilot never produced. Which data was used, and on what terms? How was the model tested? Who set the threshold, and what happens when it is wrong? None of this was part of the pilot’s definition of success, so it has to be reconstructed after the fact, or the work has to be redone.
My view is that this sequence, more than the technology or the governance function itself, is one of the main reasons AI use cases in regulated entities remain pilots. The problem is not that innovation and control disagree. It is the moment at which they first meet.
The alternative is to treat the pilot as the first draft of the approval file: not an experiment that precedes governance, but the place where the evidence governance will need starts being produced. Following a single use case from pilot to approval, into production and through its life afterwards, shows what that changes in practice.
These four moments are a simplification. Each contains its own steps, decisions and sub-stages, and in a real organisation they overlap and loop back on each other: a finding in production can send a use case back to the pilot, and an approval can be conditional on changes to the design. They are not the full method. They are the points where the handovers between teams most often go wrong.
The pilot: built to be approved, not only to work
Before the pilot is even scoped, there is a question that is easy to skip: is the use case adding AI to the current process, or redesigning the process around what AI makes possible? In most cases, the real benefit depends on the second. A model that produces a recommendation in seconds adds little if the process around it still waits for the same chain of signoffs and the same weekly batch. Redesigning the process is also what governance will end up reviewing, because what goes to production is not a model but a new way of working. A pilot that tests the model inside a process that will have to change anyway is testing the wrong thing.
Once the scope is clear, results are not the only test in a regulated entity. A second one matters as much: could someone who was not in the room understand why the system produces what it produces, and decide whether it should continue?
Passing that test does not require a heavier pilot. It requires writing down, before the work starts, a few things the team usually knows on the first day and has forgotten by the last. What decision does this use case support, and who remains accountable for that decision once the system is involved? What data will it use, where does that data come from, and are there restrictions on how it can be used? And what would the pilot need to show to justify going further, including the result that would mean stopping?
The stopping condition matters most. A pilot without one tends to continue by default and arrives at approval with momentum but without an argument.
The approval: governance that arrives at the end can only say no
When a risk or governance function sees a use case for the first time at the approval stage, its options are narrow. It can approve something it cannot fully assess, ask for more work, or reject it. From the business side, each of those looks like obstruction. From the governance side, each is a responsible answer to an incomplete file.
The way out is not to make governance approve the pilot. It is to involve governance at the start in a specific and limited role: agreeing, in advance, on what the eventual approval will require. A short conversation at the beginning replaces a long negotiation at the end, and it gives the pilot team a target they can design for rather than a review they have to survive.
This matters more for AI than for traditional models. Many regulated entities already have processes for reviewing risk models, but an AI use case often falls into a grey area: not clearly a model under existing policy, not clearly ordinary software. If nobody decides early which process applies, the first review becomes the place where that is settled, which is the slowest place to settle it.
Production: a model that works alone is not yet a process
Approval of a model is not approval of the process it will run inside. Once a use case moves to production, new questions appear. Which systems feed it, and how often? What happens to a case the model cannot handle? Who handles the exceptions, and where are they recorded?
These questions often fall between the team that built the pilot, technology and the business, and none of them treats the connection as theirs. In a regulated entity, that gap is not only an operational risk; it is also a part of the process that a review can ask about, and one where the answer is rarely written down.
After go-live: the work that did not exist before
With most traditional technology, going live is close to the end of the story: a rules engine, once deployed, keeps doing exactly what it was built to do until someone changes it. AI does not behave that way. A model learns from data that reflects a particular period, and the world it learned from keeps moving: customer behaviour shifts, products change, and the mix of cases drifts away from the sample the model was trained on. Its performance can erode without anyone touching it.
That means production is not where the project ends. It is where a new, permanent process begins, one that many organisations have not needed for their other technology. Someone has to watch how the model performs against what was approved, decide when it needs retraining or adjusting, and occasionally accept that a different model, or another provider’s model, would now do the job better. Each of those changes is, in effect, a smaller version of the original approval: it needs evidence, a decision and someone accountable for it.
This is easy to underestimate, both in the budget and in the organisation chart. If the plan funds the pilot and the integration but not the ongoing care of the model, the use case goes live with an owner on paper and nobody in practice. The question to settle before go-live is not only who operates the system, but who looks after the model, how often, with what criteria for acting, and how those decisions will be recorded for the next review.
Designing the four moments together
The practical implication is simple to state and less common to see: one plan covering all four moments, including the one that never ends, with owners known from the first day. Before approving the budget for an AI pilot, I would recommend that a leadership team ask four questions. Is this use case adding AI to a process, or redesigning the process, and does the pilot test the right one? Who will approve this for production, and have they seen the plan? What will the approval file contain, and which parts of it will the pilot itself produce? Who will own this once it runs inside a real process, and who will look after the model once it is live, including deciding when to retrain, adjust or replace it?
A pilot designed only to work proves that something is possible.
A pilot designed to be approved proves that it can be run, explained and defended. In a regulated entity, only the second one reaches production, and only one that someone keeps looking after stays there.
At Rhisco, three of our services work across these moments. Our Innovation & AI Lab designs and builds cost-efficient AI to specification, with the appropriate governance architecture. Our Risk, Models & AI Governance practice builds AI governance architecture and carries out independent reviews of risk models. And our Integration Consulting team, which speaks both business and technology language, integrates third-party components into the client’s operation and delivers end-to-end, production-ready solutions for critical processes, with proven experience in highly regulated entities. If you are moving an AI use case from pilot to production, we would be glad to talk.
This article was co-created with the assistance of artificial intelligence under strict supervision, editing, and verification of our team.