Nobody gets promoted for tidying up a data platform. Everybody gets a round of applause for shipping a flashy AI feature. That mismatch in incentives is quietly responsible for a huge share of the AI spend in UK businesses that never turns into measurable return, and it shows up in almost exactly the same way each time, regardless of sector or company size.
Here’s the pattern, repeated across more organisations than anyone in this industry likes to admit. A business buys into the AI story. It picks an exciting use case — a customer-facing chatbot, an automated report generator, an agent that triages support tickets. It builds a prototype fast, because prototypes are supposed to be fast. Then it tries to put that prototype in front of real data and real users, and everything slows to a crawl.
The Problem Was Never the Model
It’s rarely the AI itself that causes the slowdown. Off-the-shelf models, particularly the ones built on Azure OpenAI and similar platforms, are now good enough for the overwhelming majority of practical business use cases. What causes the slowdown is everything underneath the model: data that’s duplicated across five systems with five different definitions of “customer,” access controls nobody’s audited in three years, and no clear owner for the question of what “good governance” even means for this particular use case.
None of that gets fixed by a better prompt or a newer model. It gets fixed by unglamorous infrastructure work that has to happen before the feature, not after it. And crucially, it’s work that doesn’t scale down just because a business considers itself a fast follower rather than an AI pioneer — a smaller data estate is still a messy data estate if nobody’s ever cleaned it up.
Why Foundations Keep Losing the Budget Argument
Foundational work is a hard sell internally, and it’s worth being honest about why. It doesn’t demo well. “We’ve spent three months classifying and securing our data estate” does not land in a board meeting the way “we’ve built an AI agent that cuts ticket resolution time by 30%” does. So budget gravitates toward the feature, the foundation gets skipped or rushed, and the feature either never makes it to production or makes it there in a form nobody fully trusts.
The organisations that avoid this trap tend to do one thing differently: they treat foundational data, security and governance work as part of the AI budget, not a separate IT cost to be justified on its own. If the business case for a use case doesn’t include the cost of making the underlying data trustworthy, it’s not a real business case. It’s a demo with a spreadsheet attached.
See also: “The Science Behind Ozempic Was Wrong” Headlines: What Actually Changed and What Didn’t
What Foundations-First Actually Buys You
This isn’t an argument for endless preparation before shipping anything. It’s an argument for sequencing. Get the data landing zone, the access model and the governance guardrails right once, and every subsequent use case gets faster and cheaper to build, because the expensive, slow part only has to happen once. Skip it, and every new use case pays the foundational tax all over again, usually discovered halfway through a project when someone finally asks where the training data actually came from.
This is essentially the argument behind treating AI delivery as a production line rather than a series of bespoke projects — building the foundations once, properly, so that use cases can be delivered repeatedly on top of them. Transparity sets out this foundations-first approach on its AI Factory page, positioning secure data and AI landing zones as a distinct stage that comes before any use case gets built, rather than something retrofitted once a prototype has already proven popular.
The Boring Version Wins
If there’s one piece of advice worth taking from organisations that have actually got AI ROI to show up on a balance sheet, it’s this: resist the pressure to lead with the exciting use case. Lead with the boring infrastructure question instead — is our data trustworthy enough to build on — and let the exciting use case follow once the answer is genuinely yes. It’s a less impressive story to tell at the kickoff meeting. It’s a considerably better one to tell twelve months later, when the feature that shipped is still running, still trusted, and still delivering the number someone originally put in the business case.
