Operating Model & Maturity

Every organisation that adopts AI passes through the same four stages — experimentation, standardisation, scaling, and what the industry now calls the AI factory — and the transition between them is not smooth. It follows a pattern closer to a step function: long plateaus of apparent progress punctuated by a single structural shift that either happens or does not. The shift that matters most, the one that separates organisations that use AI from organisations that run on it, is the move from Stage 2 to Stage 3. That move is not a technology problem. It is an operating-model problem — a question of roles, governance, and reuse infrastructure — and it is where the majority of enterprises are stalled right now.

The four stages

The maturity model has four stages. Each describes not just what an organisation is doing with AI but how the organisation is structured around it — because the structure determines what scales and what stays a pilot.

To make this concrete, follow a single organisation through all four: a mid-size European bank — call it Rheinbank — with 4,000 employees, a legacy core-banking platform, and a board that approved an AI strategy eighteen months ago.

Stage 1 — Experimentation. Individual teams run ad-hoc pilots. There is no shared infrastructure, no governance, no catalogue of what has been built. Success depends entirely on hero developers — the one data scientist in credit risk who built a churn model in a notebook over a weekend, the operations analyst who wired a chatbot to the internal knowledge base. At Rheinbank, three teams are running pilots independently: fraud detection, customer-service triage, and document extraction for compliance. None of them knows about the others. Each chose its own model provider, its own deployment method, its own evaluation approach. Two of the three will be abandoned within six months, not because they failed technically but because nobody owns them.

Stage 2 — Standardisation. A central team — often branded an AI Centre of Excellence — appears. It selects a shared model provider, publishes prompt templates, and begins writing governance policies. First patterns emerge: a standard way to call the model, a shared vector store, a template for evaluation. At Rheinbank, the CoE has consolidated the three pilots onto a single platform, written an acceptable-use policy, and started a quarterly review of AI initiatives. The fraud model is in production. The chatbot has been rebuilt using the shared stack. This feels like progress, and it is — but the CoE is still doing most of the work itself, and every new use case queues behind the same four people.

Stage 3 — Scaling. Reusable assets replace bespoke builds. A platform team maintains shared infrastructure — model gateway, evaluation harness, prompt registry, observability stack — and business units build on top of it without waiting for a central team. Governance shifts from approval-based (everything passes through a gate) to standards-based (the platform defines what is required; teams demonstrate compliance). At Rheinbank, the credit-risk team deploys its own model using the platform's standard pipeline, monitored by the platform's standard observability, evaluated by the platform's standard evals. The CoE no longer builds; it enables. The catalogue lists fourteen production systems, and the newest three were built by teams the CoE has never spoken to.

Stage 4 — AI Factory. AI is embedded in every workflow that benefits from it, not as a separate initiative but as a default capability. Self-service tooling means any team can build, evaluate, and deploy a model-backed process within the platform's guardrails. Continuous improvement is structural — evaluation data flows back into prompt refinement, model upgrades propagate automatically, governance is encoded in the platform itself. Rheinbank no longer has an AI strategy. It has a strategy, and AI is how parts of it execute.

The distance between stages is not uniform. Stage 1 to Stage 2 is a staffing decision — hire a central team, pick a stack, write a policy. Stage 3 to Stage 4 is a cultural shift that takes years. But Stage 2 to Stage 3 is the wall, and most organisations are pressed against it right now.

The wall

Here is the provocation this page earns: the wall between Stage 2 and Stage 3 is not technical. The technology to scale AI — model gateways, evaluation frameworks, deployment pipelines, observability platforms — has been available for years. The wall is organisational, and it has three faces.

The bottleneck face. At Stage 2, every AI initiative flows through the CoE. The CoE is the team that knows how to build, evaluate, and deploy. When demand doubles, the CoE does not double — it queues. The median enterprise CoE in 2025 had six to eight people; McKinsey's State of AI report found that 88% of organisations reported using AI in at least one function, but only 7% had scaled it across the enterprise. The gap between those two numbers is the queue outside the CoE's door.

The governance face. Stage 2 governance is approval-based: the CoE reviews every initiative, every prompt, every deployment. That model works when there are five initiatives. It collapses at fifty. Scaling requires a shift to standards-based governance — published guardrails, automated compliance checks, self-service within boundaries — and that shift demands that the CoE give up control it is accustomed to holding.

The reuse face. At Stage 2, each team builds from scratch, guided by the CoE but not building on shared assets. At Stage 3, teams build on a platform — shared evaluation harnesses, prompt registries, model routing, cost controls — and the existence of that platform is what makes self-service possible. Building the platform is an investment that returns nothing until it is used by multiple teams, which means it competes for resources against the next pilot, and the next pilot always has a clearer short-term ROI.

Rheinbank hit the wall nine months after forming its CoE. The fraud model was in production, the chatbot was live, and six more teams had submitted proposals. The CoE could onboard one new team per quarter. At that rate, the backlog would take eighteen months to clear — by which time half the proposals would be obsolete. The technology was ready. The operating model was not.

The operating model that crosses the wall

Crossing the wall requires an operating model with three components, and all three must be in place simultaneously — any two without the third reproduces the bottleneck in a different location.

Roles: hub-and-spoke, not centre-and-queue

The CoE must evolve from a delivery team into a platform team. In the hub-and-spoke model, the hub — a small, senior group — owns infrastructure, standards, the approved component library, the observability platform, and security. The spokes are embedded AI practitioners who sit within business units, own use-case prioritisation, and build on the platform without waiting for the hub's permission. The hub sets what is required; the spokes demonstrate compliance.

At Rheinbank, the six-person CoE split into two roles: three engineers became the platform team (the hub), and three became embedded advisors assigned to the highest-priority business units (the first spokes). The platform team stopped building use cases entirely. Their only deliverable was the platform — and their success metric shifted from "number of models deployed" to "number of teams deploying models independently."

Governance: guardrails, not gates

Approval-based governance asks: "May I do this?" Standards-based governance asks: "Does this meet the standard?" The difference is who initiates. In an approval model, the team waits. In a standards model, the team acts and the platform verifies — automated checks for data-privacy compliance, model-card completeness, evaluation thresholds, cost projections. Human review is reserved for genuinely novel risk, not for routine deployments that fit established patterns.

The governance shift is the one most organisations resist longest, because it requires the central team to trust the guardrails it has published. If the guardrails are good, teams operating within them will produce acceptable results without human review. If the guardrails are not good, no amount of human review will compensate at scale — the reviewers will be overwhelmed, and quality will drop anyway.

Reuse infrastructure: the platform as product

The platform must be treated as an internal product, not a side project. That means a product owner, a backlog prioritised by internal-user feedback, documentation, versioning, and a service-level commitment. The minimum viable platform for Stage 3 contains five components:

Rheinbank built the gateway first — it took six weeks and gave the platform team immediate visibility into every model call across the organisation. The prompt registry came second, seeded with the prompts the CoE had already built during Stage 2. Within four months, three business units had deployed new AI-powered processes without any CoE involvement beyond a fifteen-minute architecture review.

What pilot purgatory actually is

The industry calls the stall "pilot purgatory" — a state where an organisation runs pilots continuously but never graduates them to production at scale. The term is widely used and poorly understood. Pilot purgatory is not a failure of pilots. The pilots often succeed. It is a failure to build the operating model that would let successful pilots become standard practice.

The pattern is consistent across industries. A team builds a working prototype. It demos well. Leadership approves a production rollout. The rollout stalls — not because the technology broke but because there is no deployment pipeline, no evaluation framework, no governance process, no monitoring, and no team whose job it is to maintain the system once the builders move on. The pilot was an engineering exercise. The rollout is an organisational one, and the organisation was never changed to support it.

The research confirms the scale of the problem. Gartner estimated that 30% of generative-AI projects would be abandoned after proof of concept by the end of 2025. The McKinsey State of AI survey found that while 88% of organisations were using AI in at least one function, only 7% had scaled it enterprise-wide. The gap between "using" and "scaled" is not a technology gap. It is an operating-model gap — and closing it requires the three shifts described above: hub-and-spoke roles, standards-based governance, and a platform treated as an internal product.

Maturity is measured by what teams can do alone

There is a simpler way to assess where an organisation sits on the maturity curve, and it does not require a formal assessment framework. Ask one question: what can a business-unit team do without help from the central AI team?

At Stage 1, the answer is nothing — the central team does not exist. At Stage 2, the answer is also nothing — the central team exists but every initiative depends on it. At Stage 3, the answer is "build, evaluate, and deploy a standard AI-powered process using the platform." At Stage 4, the answer is "all of the above, plus improve it continuously using the platform's feedback loops."

The entire maturity journey reduces to expanding the set of things a team can do independently, within guardrails, without waiting. Every structural investment — the platform, the governance framework, the role redesign — exists to widen that set. Every structural failure narrows it back to "queue behind the CoE and wait."

Rheinbank's board, twelve months after forming the CoE, stopped asking "how many AI models are in production" and started asking "how many teams can deploy an AI model without CoE involvement." The first question measured activity. The second measured maturity. The answer to the second question — the number that actually predicted whether AI would compound across the organisation or remain a collection of isolated successes — was the one worth tracking.

The operating model is the ground the rest of the Blueprint builds on. Once it is in place — roles defined, governance encoded, platform running — the next question becomes strategic: for any given capability, do you build it, buy it, or boost what you already have. That is the question the next page takes up.