Two decades of delivery inside regulated financial services teaches you things about execution that you cannot learn any other way. Core banking migrations. ISO 20022 transitions. UAT governance programmes spanning multiple jurisdictions. These programmes share a pattern: they are technically hard, but they almost never fail for technical reasons.
The same pattern is repeating itself in AI programmes right now. The technology works. The use case is real. The delivery still breaks. And it breaks in the same places — for the same reasons — that regulated delivery programmes have always broken.
Here is what structured delivery teaches you that most AI teams have not yet learned.
The hardest problems are human, not technical
Every experienced delivery practitioner knows this. It takes most AI programmes a long time to discover it.
The assumption going in is that model quality, architecture decisions, and testing infrastructure are where the difficulty lives. They matter. But the programmes that succeed or stall do so almost entirely on the basis of stakeholder alignment, process clarity, and whether the right people were involved at the right moments.
In banking transformation programmes, you learn early that the technical work is the easy part to plan. The hard part is knowing who needs to be in the room before a decision is made — and what happens when they are not. AI programmes face exactly the same challenge. The difference is that AI teams often have no prior experience of large-scale delivery programmes to draw on. They learn it the expensive way.
Organisations do not know their own processes as well as they think
This one consistently surprises people, but it should not. Before you can automate anything with AI, you need to understand what you are automating. That sounds obvious. It turns out that most organisations have a material gap between how they believe their processes work and how those processes actually run on a Wednesday afternoon when someone is off sick and the system encounters an edge case it has never seen.
In regulated delivery, process discovery is a formal discipline. You do not assume you understand a process because someone has drawn a diagram of it. You go and watch it run. You find the exceptions that never made it into the documentation. You map what actually happens, not what the policy says should happen.
AI programmes that skip this step — or compress it — routinely discover mid-build that the training data does not reflect reality, that the edge cases are far more common than estimated, or that the process they were automating had informal human steps that were never captured.
The regulatory learning curve is steeper than expected
Even organisations that have thought carefully about AI governance are often surprised by what regulators actually want. The gap between having a policy and being able to demonstrate compliance is larger than most teams realise — and it grows as the AI system becomes more consequential.
In financial services, this is familiar territory. You write the policy. You build the controls. You document the rationale. Then you sit in front of a regulator and discover that the question is not whether you have a policy, but whether you can demonstrate that it actually governed behaviour in specific, evidenced instances.
AI governance is moving in the same direction. Model cards and risk assessments are the beginning, not the end. Organisations deploying AI in regulated contexts need to think about audit trails, explainability, and documented human oversight from the design stage — not as a retrospective compliance exercise.
The integration layer is always more expensive than the model layer
Foundation models are, increasingly, the cheap and fast part of an AI programme. Getting a capable model producing useful outputs in a controlled environment takes weeks. Getting that model reliably integrated into production systems — with appropriate data pipelines, API contracts, latency budgets, escalation paths, and monitoring — takes considerably longer and almost always costs more than the initial estimate.
This is not a new problem. Enterprise technology programmes have always underestimated integration complexity. The data is messier than expected. The legacy systems have undocumented constraints. The downstream dependencies create coordination overhead that compounds. AI programmes add a further dimension: the model's behaviour changes when the data distribution shifts, which means integration is not a one-time exercise but an ongoing discipline.
What this means for how to run an AI programme
The delivery patterns that work for regulated technology programmes apply directly here. Fixed scope. Staged delivery. Explicit process discovery before build begins. Governance designed in from day one, not added at the end. Human oversight paths defined before the first line of integration code is written.
None of this is new. It is what structured delivery has always required. The organisations that get AI to production reliably are the ones that treat it as a delivery discipline — not as an experiment that needs a production environment eventually.
If you are navigating the gap between a working prototype and a reliable production deployment, our approach to AI delivery sets out how we think about this.