Step 1 — Ready: the readiness question most scale-ups skip 

The pilots have worked. The next question is whether the rest of the organisation can pick up where they left off and that’s the part most readiness assessments miss. Most assessments stop at technical capability. The data is in order, the licensing is sorted, the architecture diagrams look credible. That work matters, and this step covers it but on its own it isn’t what predicts whether you’ll deliver. The question that predicts whether you’ll deliver is much simpler, and almost nobody asks it directly: 

When this rollout gets hard six months from now, and it will, does your business sponsor and your IT lead have a shared definition of “done”? 

If the answer is yes, the technical work is straightforward. If the answer is no, no amount of architecture will save you. The first step is where that conversation happens, on purpose, before it has to happen by accident. It produces four things: 

• A confirmed technical baseline: data, licensing, architecture, and the integrations the rollout will lean on 

• A small set of outcomes everyone agrees actually matter this year 

• A named owner for each. Not a committee, a person 

• A definition of success that survives a budget conversation 

The signal you’ve done this step well: when someone asks “why are we doing this AI thing?”, three different leaders give roughly the same answer. 

Step 2 — Accelerate: optimise for transfer, not proof 

This is where most programmes lose their second year before they’ve finished their first. The conventional measure of pilot success is whether the use case worked. Did the team save time? Did the output get better? Did people use it? It’s the wrong measure. The measure that actually predicts whether your programme scales is this: could the next team adopt this use case without your help? That single shift, from optimising pilots for proof to optimising them for transfer, is what separates programmes that scale from programmes that produce a great case study and stall. 

In practice, it changes three things about how a pilot is run: 

• The use case is documented while it’s being built, not after 

• The success criteria include “second team adopts in under [X] weeks” 

• The pilot team’s job isn’t done when their use case goes live. It’s done when someone else’s does

It feels slower for the first pilot. It is dramatically faster from the third onward. 

Step 3 — Protect: embed trust as you scale 

Most programmes treat governance and security as a cleanup phase. The Rapid AI Framework treats Protect as a parallel discipline that moves with adoption, so trust scales at the same pace AI does. Because here’s what most rollouts learn the hard way: AI doesn’t create new data risks. It exposes the ones you’ve been getting away with. 

Protect covers three layers: 

• Your information estate. Microsoft Purview, sensitivity labels, permissions hygiene, and document and content structures, so AI surfaces the right information to the right people. 

• Security and compliance posture. Identity governance, conditional access, Defender, DLP, and the sector-specific compliance obligations that come with operating in government, healthcare, or education. 

• Responsible use. Clear guardrails, ownership of risk decisions, and reading Shadow AI as a signal of where official AI hasn’t reached yet, not as a violation to suppress. 

In practice, this step delivers an audit of where you stand today, a gap analysis against where you need to be, the guardrails to close that gap, and a roadmap that keeps trust and adoption moving together. 

The aim isn’t to slow AI down. It’s to make sure adoption never outruns the trust that lets it keep growing. 

Step 4 — Infuse: from deployment to daily practice 

This is where AI stops being “something new” and starts becoming the way we work. 

Infuse is the phase where we embed AI into the fabric of the organisation: how people learn to trust AI, build it into their day-to-day, and start to rely on it. It’s delivered through a structured rollout: training, champions, communications, and change plans tailored so each business unit understands what AI means for them specifically. The goal isn’t awareness. It’s real behavioural shift. Because the gap most rollouts hit is the same one: The technology works. People don’t change how they operate. 

This step is built to close that gap. In practice, it does three things: 

• Makes AI part of real workflows, not an extra step 

• Helps each team understand what it means for their role, in practice 

• Reinforces new behaviours so they stick beyond initial use 

This is where roles start to shift, teams collaborate differently, and decisions get made with AI in the loop. 

The earlier steps prove AI can work. Infuse is what makes sure people actually use it, know how to use it, and want to keep using it. Consistently, at scale.

 Step 5 — Drive: somebody has to own the question “what’s next?” 

Most AI programmes have an owner for AI delivery, the person responsible for shipping the next use case, running the next training, fielding the next request. Far fewer have an owner for AI value, the person responsible for the question “is this still working, what should we be doing differently, and where is our risk posture out of date?” Those are different jobs. Conflating them is what makes a plateau. 

Drive is the discipline of separating them. It looks like: 

• A named owner for AI value and risk evolution, distinct from AI delivery 

• A regular cadence — quarterly, at minimum — to review usage, impact, what’s next, and where governance needs to catch up 

• A live pipeline of new use cases, and the governance work that needs to move alongside them 

• Honest conversations about what’s not working, before the dashboards force them 

It’s the least glamorous step in the framework. It’s also the one that decides whether AI keeps compounding for your organisation, or quietly becomes the thing everyone used to be excited about.