Most organisations have already bought AI, and few have anything to show for it. People are working faster, but the business isn't doing any better. The cause is rarely the technology. AI speeds up work that wasn't holding anything back, it spreads without anyone owning it, and it runs on fear, so people hide how they use it. This guide sets out the way of working we built to fix that.
What is the Deployment Framework?
The Deployment Framework is a free AI adoption framework: set an aim, find the bottleneck that holds it back, improve the work before you build anything, and own what runs, all inside guardrails that make the safe way the easy way. It's how an organisation makes AI pay off and keeps it safe, and anyone can use it.
It's for leaders and everyone who works for them, in organisations of about 20 to 1,000 people. Firms of 10 to 20 can use a lighter version. Larger organisations run it unit by unit.
It isn't two things:
- A guide to any one AI product. The tools change every month. This way of working shouldn't.
- A risk standard. It works alongside the NIST AI Risk Management Framework, ISO/IEC 42001 and the EU AI Act. Those say how to manage AI risk. The framework adds the part they leave out: where the value comes from.
Our guide to AI deployment covers the wider job of putting AI to work. This page is the framework itself, in the same words our courses use.
Why do most AI rollouts return nothing?
MIT's NANDA project reported in July 2025 that 95% of organisations were getting zero return from their spending on generative AI, and that most pilots showed no measurable effect on profit and loss. It's a directional study, built on interviews at 52 organisations, a survey of 153 senior leaders and a review of over 300 public AI initiatives. McKinsey's 2026 global survey of 1,719 people points the same way: 80% of respondents said AI had improved their own productivity, but only 37% attributed any of their organisation's EBIT (earnings before interest and taxes) to it.
The technology isn't the problem. These are:
- AI speeds up work that wasn't holding anything back.
- It spreads without anyone owning it.
- It runs on fear, so people hide how they use it.
How does the framework work?
In one breath: set an aim, find the bottleneck that holds it back, improve the work before you build anything, and own what runs. Do all of it inside guardrails that make the safe way the easy way.
An organisation moves only as fast as its slowest step. Speeding up any other step just piles more work in front of the bottleneck. That's why AI can make individuals faster without making the organisation any better, and why so much AI output lands on someone else's desk to fix. In a September 2025 survey of 1,150 full-time US desk workers by BetterUp Labs and the Stanford Social Media Lab, 40% had received AI-generated "workslop" in the previous month.
The fix is to find the one step that limits what you're trying to do, and aim the effort there.
Fixing one bottleneck always exposes the next one. That makes this a loop, not a project.
Where do you start?
Implementing the framework starts with five steps, in this order:
- Leaders write the aim and sign the promises.
- Put the six starting guardrails in place.
- Hold the first AI session, and invite everyone to add their AI use to the AI list.
- Within two weeks, name the bottleneck and write down what you expect to change.
- Improve for 90 days, then measure.
Our free course, Your first 90 days with AI, takes you through those steps one module at a time. The rest of this guide covers each part.
The aim
The aim is a single page. The leadership team agrees it and announces it to everyone before anything else happens. It's restated every quarter, taking account of what customers and competitors are doing, and reviewed once a year. It's done when it has been announced, everyone has had a first AI session, and a sample of staff can repeat the goal and the promises.
The aim says:
- The goal: something you can measure, with a date. It can be about efficiency, growth or both.
- Where freed-up time goes: to the bottleneck, to lower costs, to quality or to growth. Time saved only counts once it has actually gone there, so keep a record of where it went.
- Money and time: a spending ceiling, a small budget for experiments, and protected hours each month for everyone to learn and improve their own work.
- Who's responsible: a sponsor, meaning the executive who visibly backs this, and one named person who runs the loop from quarter to quarter.
- Pace: the first loop runs 90 days, and its first result comes from improving the work, not from building anything.
Module 1 of the course covers the goal and where freed time goes, and ends with your aim page, ready to sign.
The promises
The promises are the required minimum. They come before anything else, because nothing in this guide works if people hide how they use AI.
- Telling us is safe. Nothing anyone discloses about how they use AI is used in performance reviews or in decisions about who leaves.
- A mistake you disclose is handled as coaching, not discipline. That holds even if it exposed regulated data or caused harm. Only wilful or criminal conduct is outside this promise.
- Individual disclosures are held outside the management chain, by compliance, or by an outside partner in small firms. Leaders see only totals.
- Breaking this promise is itself treated as an incident.
- No one is punished for improving their own work.
- If roles are ever cut, that happens through a separate, announced process that offers redeployment first. It never happens through what people disclosed or improved.
- Leaders say plainly what happens to roles that shrink. We recommend putting growth first.
The four promises lesson explains why disclosure has to be safe before anything else can work.
The four moves: find the bottleneck, improve, build, own
The loop runs Find → Improve → Build → Own, with shortcuts. The line between Improve and Build is money. Improve spends no new money or engineering time. Build does.
1. Find the bottleneck
Ask: what AI is already in use? Where does work wait, pile up or get redone, tracing back from the customer? Which one thing is holding the aim back?
- Start the AI list, a record of every AI tool and use in the organisation, and the friction list, a record of where work gets stuck. The friction list describes the work, not the person, and anyone can add to it.
- Name one bottleneck: the step that most limits the aim. Put a value on it by what it holds back, and name someone to lead work on it. Leaders can be the bottleneck too.
- Before touching anything, write down what you expect to change. Include how long you'll measure for, and the early dip you expect while people learn.
Done when the bottleneck has a lead and the prediction is written down.
Module 4 of the course teaches this move, from tracing work back from the customer to naming one bottleneck and writing down your prediction. Module 3 builds your AI list.
2. Improve
Ask: can we get more out of the bottleneck without spending new money or engineering time?
- Redesign the work around the bottleneck before automating any of it.
- Train people on their own work, with approved tools, in their protected hours. Managers go first.
- Get more out of the bottleneck with what you already have, and pace everything else to what it can absorb. Faster AI output elsewhere only piles up in front of it, so meet the output standard and stop rewarding speed for its own sake.
- Everyone removes their own everyday friction. Time a person saves is spare capacity. It only counts as value once it goes where the aim says.
- Anything this produces that others will rely on goes to Own: a shared prompt, template or workflow, for example. Setting up an approved tool counts as Improve.
Redesign comes first for a reason. In McKinsey's 2026 survey, nearly three-quarters of AI high performers (the 6% of respondents who attribute at least 5% of EBIT to AI and call its impact significant) had fundamentally redesigned workflows because of AI. Only a quarter of the other respondents had.
Done when the bottleneck has been measured again against your prediction. Then take one of three routes:
- It moved. Go back to Find for the next bottleneck.
- It didn't move, and the gap is worth paying for. Raise it at the front door for Build.
- It didn't move, and it isn't worth paying for. Keep improving, or accept it and name the next bottleneck.
Module 5 starts with redesigning before you automate and covers getting more from the bottleneck and pacing everything else to it.
3. Build
Ask: what can't improvement fix, and is it worth paying for? Build means spending new money or engineering time, whether you build it, buy it or pay for setup.
- Write a one-page case. It covers:
- the value: what it frees at the bottleneck, the cost it removes, or what an experiment will teach
- the full running cost
- an owner and a backup
- who builds it
- a data check
- what's at stake
- a stop-loss
- kill criteria
- the options: reuse, set up, buy (after the vendor checklist), build, or don't
- Prove it in two stages. First, prove it's safe in a sandbox that can't reach live systems. Second, run a limited live trial with real users, in the systems they already use. The proof has to show that it works, that it's fair wherever it helps decide things about people, and that it's safe. For anything high-stakes, that evidence comes from someone who didn't build it.
- Run new products and services as experiments. Fund them from the experiment budget, and give each one a customer problem, a riskiest assumption, milestones, kill criteria and a customer owner. Inventing whole new business models is outside this guide.
Done when each item has been kept or killed on the evidence. What's kept goes to Own.
Module 6 covers the front door, the one-page case and two-stage proof.
4. Own
Ask: who answers for it? How do we know it's healthy? How do we stop it and undo it? What happens when the vendor changes it?
- Own covers everything shared, plus the approved tools behind any high-stakes personal use.
- Each one needs:
- an owner, and a backup who can stop it
- monitoring, an off switch and a tested undo (for a way of using AI rather than a tool, this means the named check and the records)
- a way to learn from corrections
- the records the stakes require
- a plan for vendor changes
- a next review date, where you keep it, fix it or retire it
- When you retire something, cover its data, anything that depends on it, and the people who relied on it.
- Review findings go onto the friction list, which feeds the next Find.
Done when every item in scope has all of this filled in and a review date in the calendar.
Module 7 sets up owners and backups, the off switch and a tested undo and review dates.
Shared and stakes: what does each use of AI need?
Two questions decide what anything made with AI needs, and they apply to any way AI gets used, too. A recruiter ranking CVs builds nothing, but both questions still apply.
Is it shared? This covers tools, workflows and standing practices, not one-off outputs. Something is shared if any of these is true:
- someone else depends on it
- it acts beyond your own work
- it writes into a system the business runs on, such as the CRM or payroll
- people outside the organisation use it directly, with no person in between
What's at stake? There are two levels, low and high. Something is high stakes if any of these is true:
- it helps decide something about a person
- it touches regulated or confidential data
- it takes action outside your own work without a person checking
- it speaks or makes commitments for the organisation
- it could harm someone who never uses it
Put the two answers together and each combination tells you what it needs. Personal, low-stakes use needs approved tools and the output standard. Anything shared needs an owner, a backup who can stop it and a review date. Personal, high-stakes use needs a proven tool and a named person who checks the output. Shared and high-stakes needs both stages of proof and full ownership. Whenever the stakes are high, the people affected are told and the records are kept.
A check without time or authority is a rubber stamp. What a proper check involves depends on the use: for a court filing, for example, it means checking every citation. The Shared and stakes lesson works through four examples, the recruiter among them.
The guardrails
Guardrails make the safe way the easy way. They work because they're built into the tools, not buried in a policy document. Six have to be in place before the first loop starts:
- Approved tools: what people can use, including AI features vendors switch on in software you already have. Each new tool passes a vendor checklist before it's approved, and there's a sandbox for trying things out.
- The AI list, started: every approved tool, every AI feature a vendor has switched on, and everything shared. It's complete when what people disclose matches what monitoring finds. Monitoring counts tools, not people. The one exception: if monitoring finds regulated data exposed, the person is followed up with, as coaching under the first promise.
- Data map: which data can go into which tools.
- Output standard: anything AI helped make is labelled, owned, kept short, and checked before it goes to someone else.
- Spending limits: seat limits and cost circuit breakers. Usage is never a performance measure.
- Stop, tell, fix, learn: a blame-free path for when something goes wrong.
Two more come next:
- Stakes rules say who has to be told when AI is involved: customers, patients, applicants or workers. They also say when workers must be consulted.
- Rules for agents: each agent gets its own login with limited reach, never a borrowed human account. It stops itself when its output looks wrong, and anyone can stop it. New builds can't reach live systems until they're promoted to a limited trial, and they only get full reach once they're kept.
The guardrails are reviewed every year. Law differs by place and industry, so the specific rules live in a separate layer that is kept current as laws change.
Module 2 of the course sets up all six starting guardrails, and rules for agents has a lesson of its own.
The rhythm
The loop runs on three meetings and two service levels. The principles and the promises never change, so no meeting reviews them.
| When | Who | How long | What happens |
|---|---|---|---|
| Weekly | Every team | 15–30 min | Go through the friction list, raise problems with AI output, and check which reviews are due. This fits inside meetings you already hold |
| Quarterly | Leadership | Half a day | Restate the aim, check where freed-up time actually went, confirm or name the bottleneck, fund builds, and review roles that changed and reviews that are due |
| Yearly | Leadership, with IT, security and compliance | One day | Review the aim, the guardrails, vendors and the AI list |
The two service levels:
- The front door. Anyone can raise anything: a friction, a tool they made, or a request. The aim says where the front door is, whether that's a form, an inbox or a channel. The person running the loop answers within 10 working days, and the answer is one of three:
- Adopt it. This is the default for something someone already made, and the maker gets credit. If it's shared, it goes to Own.
- Park it on the friction list.
- Build it, once redesign and approved tools have been ruled out.
- Checking the bottleneck. The person leading work on the bottleneck checks the handoffs between teams every two weeks during the first loop, then monthly after that.
The three meetings lesson sets up the rhythm in your calendar.
The four principles
The four principles and the promises are fixed. The moves can change between versions, but these don't.
- Fix the bottleneck, and don't flood it.
- The more that's at stake, the more care it gets.
- Everything shared or high-stakes that runs has an owner, a backup who can stop it, and a review date. Every output traces to someone who answers for it, directly or as the owner of the system. Whoever checks it has the time, information and authority to reject it.
- Measure outcomes, never usage. Freed-up time only counts once it has gone where you promised.
Everyone's part
The same loop works for one person's week, a team's month and the whole organisation's quarter. The CEO and the assistant use the same words.
| Your week | |
|---|---|
| Aim | What is my team trying to do more of, and what have we been promised? |
| Find | What AI do I use? Where does my week wait, pile up or get redone? |
| Improve | Can I fix my worst recurring task with approved tools, without dumping work on someone else? |
| Build | Would fixing it cost money or engineering time? Then I raise it at the front door. I'll get an answer within 10 working days, and credit if it's adopted. |
| Own | Is it shared or high stakes? Then I raise it so it gets an owner or a proven tool. On Friday: what did it save, where did the time go, what's next? |
Everyone's five duties:
- use approved tools
- follow the data rules
- meet the output standard
- know the tools' limits
- report problems without fear
Our second free course, Everyone's first hour with AI, teaches all staff the aim, the promises and the five duties.
Who does what:
| Role | Their part |
|---|---|
| Leadership and the sponsor | Set the aim, keep the promises, confirm the bottleneck, protect the hours, fund builds |
| The person running the loop | Keeps the rhythm and answers the front door |
| The person leading work on the bottleneck | Maps the bottleneck, makes the prediction, checks the handoffs |
| Managers | Explain the aim, coach, and run the weekly meeting |
| Everyone | Discloses their AI use, adds to the friction list, and improves their own work |
| Builders, in-house or outside | Build, buy or set up, then run and improve what's kept |
| IT, security, compliance, HR | Write and maintain the guardrails, hold individual disclosures, and run checks and records |
Words we use
The framework uses nine terms. Everything else is plain English.
| Term | What it means |
|---|---|
| Aim | The one-page goal, where freed-up time goes, and the promises |
| AI list | Every AI tool and use in the organisation, including features that vendors switched on |
| Bottleneck | The one step that most limits the aim right now |
| Friction list | Where work waits, piles up or gets redone. It records the work, not the person |
| Guardrails | The always-on rules, built into the tools, that make the safe way the easy way |
| Output standard | Anything AI helped make is labelled, owned, kept short, and checked before it's passed on |
| Owner | The person who answers for something shared or high-stakes |
| Shared | Others rely on it, or it acts beyond your own work |
| Stakes | How much harm it could do, rated low or high |
Where it came from
The framework borrows openly. The bottleneck, and getting more out of it before anything else, come from Eliyahu Goldratt's The Goal (1984). Redesigning work before automating it comes from Michael Hammer's "Reengineering Work: Don't Automate, Obliterate" (1990). Machines that stop themselves come from Toyota's production system, and reporting without fear, which underpins the first promise, from aviation's safety reporting system. The split between personal and business use, the build-or-buy options and the data check come from Microsoft's AI adoption framework. Stakes, human oversight and records come from the NIST AI RMF, ISO/IEC 42001 and the EU AI Act.
Sources
- The GenAI Divide: State of AI in Business 2025, MIT NANDA, July 2025: the report (a copy hosted by MLQ.ai). We used its 95% finding, its method and its stated limits.
- The state of AI in 2026: On the road to ROI, McKinsey, August 2026: the global survey of 1,719 people. We used the 80% and 37% figures and the high performers' workflow redesign.
- Workslop, BetterUp Labs and the Stanford Social Media Lab, September 2025: the survey of 1,150 full-time US desk workers and its 40% figure. Written up in Harvard Business Review (secondary).
- AI Risk Management Framework, NIST, January 2023: what the AI RMF is and when it was released.
- ISO/IEC 42001:2023, ISO, December 2023: what the standard specifies.
- AI Act, European Commission: the EU's risk-based legal framework for AI.
- AI strategy, Microsoft Cloud Adoption Framework, June 2026: individual work against business automation, the build-or-buy models and the data check.
- Reengineering Work: Don't Automate, Obliterate, Michael Hammer, Harvard Business Review, July 1990.
- Toyota Production System, Toyota: jidoka, the machine that stops itself and the stop cord anyone can pull.
- ASRS program overview, NASA Aviation Safety Reporting System: voluntary safety reporting, and the protections that come with it.
- The Goal, Wikipedia (secondary): Goldratt's 1984 book on bottlenecks and the theory of constraints.