The pilot worked because people helped. Scaling means replacing that help with data access, sign-off, funding and support that the next team can use without asking.
List every favor your pilot relied on. Score the four lanes with the Scale Plumbing Check, repeat the data and security review for the scaled setup, cost one workflow for month twelve, and keep a register with a support route on every row before any workflow gets a wave date.
Pilots tend to work because of arrangements nobody wrote down. Someone in IT agreed to switch the tool on for one team. A data owner exported a folder by hand. The licenses went on a team budget small enough that nobody questioned it. None of that is a flaw in the pilot, and all of it stops working the moment a second team asks for the same thing.
That’s the infrastructure side of scaling AI: turning each of those favors into something the next team can use without asking anyone. It’s a different problem from the one in our companion piece on why AI pilots never scale, which is about the decision to expand and the behavior around it. This guide starts after that decision is made, when the answer to “so how do the other regions get started?” turns out to be a string of separate conversations.
A sales operations lead who ran a successful pilot gets messages from three other regions on the same Monday, all asking how to join. She forwards the questions on. IT replies that the tool was approved for her team’s shared drive and nothing else. Finance points out the licenses were bought on a team card. The people who own the other regions’ CRM exports say nobody has looked at who can see what in there. The pilot worked. Nobody can say, in one sentence, how a second team gets the same result.
Plenty of organizations are heading into this stretch. In McKinsey’s 2026 State of AI survey, 44% of respondents said AI was scaling across their enterprise, up from 38% a year earlier.[1] That’s self-reported and says nothing about how well it’s going, so I’d read it as a sign that more teams will hit this wall soon.
Everything below is our own working model, built from how rollouts tend to go, not a research-validated framework.
Every pilot borrows something from four places. The pilot lead usually can’t see the borrowing, because it happened through friendly conversations and it worked.
A Future Factors working model based on our own judgment. The four lanes are where we most often see a pilot’s informal arrangements run out.
Whatever the pilot got as a favor, the rollout has to get as a service.
Different people own the lanes. Data access sits with whoever owns the data, rarely the pilot team. Sign-off sits with IT, security and sometimes legal. Money sits with a finance partner and the function head who will carry the cost. Rollout support sits with the people who’ll field the questions, and in many organizations nobody has been asked yet.
A pilot lead can’t fix all four alone. Each lane needs its own owner who agrees, in writing, to provide the service, and where no one will, you want to know before the rollout date is announced.
Before planning waves, find out which lane is weakest. The check below has twelve questions, three per lane. Score each one 2 if the answer is yes and it’s written down somewhere a new team could find it, 1 if it’s true but informal, and 0 if it’s not true or nobody knows.
| Lane | Question | Score (0, 1 or 2) |
|---|---|---|
| Data | Does every data source the tool will reach have a named owner? | |
| Data | Do you know who can see that data today, not who was meant to? | |
| Data | Could a second team connect to the same sources without a custom export? | |
| Sign-off | Was the pilot’s security review repeated for the scaled setup, not just carried over? | |
| Sign-off | Are the conditions for using the tool written where a new team can read them? | |
| Sign-off | Is there a logged record of what the tool is used for and by whom? | |
| Money | Is there a monthly run cost per workflow, not just a pilot spend? | |
| Money | Does a named person hold the budget for year two? | |
| Money | Is there a ceiling, and an alert before you reach it? | |
| Support | Does a new team know exactly where to ask for help? | |
| Support | Is there a written order for who joins when, and why? | |
| Support | Does someone outside the pilot team own each new team’s start? |
Total your score out of 24. A Future Factors working tool, not a validated instrument. Have each lane’s owner answer their own three questions, not the pilot lead alone.
Here’s how I’d read the total:
The zeros matter more than the total. A 15 with a zero on every money question is a different situation from a 15 spread evenly, because a rollout with no run budget tends to get cut at the first review.
Data is the lane teams tend to underestimate most, in our view, because the pilot makes it look settled. The pilot team’s data was probably tidy, known and small. At scale, the tool meets everyone else’s.
Gartner’s February 2025 release on AI-ready data reported that 63% of organizations either don’t have, or are unsure they have, the right data management practices for AI.[2] I’d take “unsure” seriously, because it’s the realistic answer in many organizations. Nobody has had a reason to find out who can see what until a tool started surfacing it.
For assistants built into workplace software, that surfacing is the point. Microsoft’s documentation for Microsoft 365 Copilot says it can only summarize or reference content the user is authorized to access.[3] That’s a sensible design, and it also means the tool is only as careful as your existing permissions. Before a wider rollout, a security analyst might check what the assistant can reach for a sample user in each department. Finance sees the budget files it should. It may also see a project folder from a closed deal that was shared company-wide years ago and left unreviewed. The access was already there, and the assistant made it findable.
The sign-off lane has the same shape. The pilot’s review covered one team, one data set and a handful of users. The scaled setup is a different thing to review, which is why a pilot’s approval doesn’t carry over by itself:
| Question | What the pilot’s review usually covered | What the scaled setup needs |
|---|---|---|
| Whose data? | One team’s folder or export | A list of sources, each with a named owner and a known audience |
| Who can see it? | The pilot team | Permissions checked for the wider group, with oversharing cleaned up first |
| Who is using it? | A few named people | Identity and licensing managed through the same route as other company tools |
| What is logged? | Whatever the vendor logs by default | A record of use and review that someone is responsible for reading |
| What are the vendor terms? | The pilot agreement or trial terms | Contract terms checked for the scaled volume, data handling and exit |
| What if it stops? | Not discussed | A named fallback if the tool changes, rises in price or is switched off |
A working comparison based on our own judgment. Your security and legal teams will have their own list; the point is that the review is repeated for the scaled setup.
None of this needs a new committee, only the data owner, the IT or security lead, the function head and the pilot lead in one conversation with that table in front of them. If waiting for the answer is where your rollouts slow down, our piece on governance speed covers how to shorten the wait, and our AI trust checklist covers whether the output can be relied on once access is sorted.
Pilot money and run money are different kinds of money. A pilot is paid for once. A rollout is paid for every month, and someone has to say which budget that is before it starts.
Gartner’s July 2024 release predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, escalating costs or unclear business value. It also quoted an analyst saying costs “aren’t as predictable as other technologies.”[4] That’s a forecast, not a measured outcome, and I’d read the cost part as a warning about the planning habit more than about any one number: if the run cost isn’t written down before the rollout, nobody can notice it escalating.
Below is a cost table filled in for one workflow. The figures are round example inputs to show the shape, so swap in your own contract prices and rates. The point is that every line has an owner and that the total can be compared with something the work saves.
| Cost line | How it’s worked out | Example per month | Who holds it |
|---|---|---|---|
| Licenses or usage | Users x price per user (or expected usage x rate) | 40 users x $30 = $1,200 | Function head |
| Usage buffer | A margin above the base for usage-based charges | 15% of $1,200 = $180 | Function head, with a finance alert at the ceiling |
| Review time | Hours spent checking outputs x loaded hourly rate | 6 hours x $60 = $360 | Team lead |
| Support | Hours of help-desk or champion time x rate | 4 hours x $60 = $240 | IT or the support owner |
| Data upkeep | Hours keeping sources and permissions current x rate | 3 hours x $60 = $180 | Data owner |
| Total | Sum of the lines above | $2,160 | Finance partner reviews quarterly |
Example inputs, not benchmarks: the prices and rates are round numbers to show the shape. Training time for new teams is better treated as a one-off line for each wave.
With those example inputs, the total is $2,160 a month. Divide by the $60 hourly rate and the workflow has to save about 36 hours a month to break even, which for 40 users is under an hour each. That’s a more answerable question than “is AI worth it?”, and your pilot’s persistence data can speak to it.
Don’t fund a rollout until someone has written down what month twelve costs and who pays it.
Each role needs something different here. A function head wants the per-workflow number and a ceiling. A finance partner wants to know whether the cost is fixed or varies with usage. An IT lead wants support hours counted rather than absorbed. Who has authority to approve the spend is part of the scale decision itself, which the companion piece covers.
The last lane is the one the pilot lead has been doing personally: answering questions, nudging people, fixing the odd broken connection. At scale that has to live somewhere other than one person’s inbox. The simplest place is a register, one row per workflow, with the columns that tell the next team what they need.
| Workflow | Team and wave | Data source and owner | Sign-off status | Run cost per month | Support route | Next check |
|---|---|---|---|---|---|---|
| Weekly supplier exceptions list | Operations, wave 1 (pilot team) | Supplier delivery notes; operations data owner | Reviewed for scaled setup, conditions published | Costed, with ceiling | Operations champion, then IT help desk | End of month: still in use? |
| Variance commentary draft | Finance, wave 2 | Monthly reporting pack; finance operations lead | Reviewed, no customer data in scope | Costed, with ceiling | Finance operations lead | After the first two closes |
| Proposal first drafts | Sales, wave 2 | Past proposals library; sales ops, permissions check open | Waiting on a permissions check | Not yet costed | None named yet | Blocked until the check closes |
| Candidate screening summaries | HR, wave 3 | Applicant system exports; HR systems owner | Not started, personal data in scope | Not yet costed | None named yet | Needs its own review before a date |
The two blank-looking columns, sign-off status and support route, are the ones teams tend to leave vague, and they’re the ones a new team reads first. A row with no support route doesn’t get a wave date.
The register also fixes the order of waves, which is a design choice rather than a popularity contest. I’d order by readiness of the lanes, not by who asked loudest. The first rows are the workflows where the data owner is named, permissions are checked and the cost is written down. Rows blocked by one lane stay visible, with the lane named, so everyone can see what unblocks them.
A rollout is ready when the second team can start without calling the first team.
If a new team has to find the pilot lead to learn where the data lives, who approved the tool or who pays for it, the favors are still in place. If they can read the register and ask a named person for help, the plumbing has replaced them.
Plumbing also gets blamed for what training and reinforcement should have done. Training builds capability, so people can use the tool well in principle. Workflow design gives that capability a recurring task to land in, and the register is part of that design. Reinforcement, through managers who check and teams who repeat the work, turns it into behavior. Adoption is what you see when all three have happened. A team can build much of this internally, and structured training shortens the learning curve and builds shared capability across a team rather than in one enthusiastic person, which is where the second and third waves usually need the most help.
A fair amount of scaling work is paperwork: inventories, summaries and status updates. AI can take much of that preparation, and the decisions stay with people.
| What AI does | What people still own | How it gets checked |
|---|---|---|
| Drafts a first-pass inventory of data sources from pilot notes, tickets and exports | Confirming each source is real, who owns it and who can see it | The data owner signs each row. Anything unconfirmed stays marked as unconfirmed |
| Summarizes a permissions report into a short list of sites and folders that look broadly shared | Deciding what to restrict, and what’s shared on purpose | The IT or security lead reviews the whole report, not only the summary |
| Turns usage and cost data into a one-page monthly note per workflow | Whether the cost is justified and which workflows continue | The finance partner and function head review quarterly |
| Drafts the register and keeps its dates and statuses up to date | Wave order, and whether a row is really ready | The scale owner reads the register before every wave decision |
Use only tools your own policy already approves for internal documents. Nobody should accept a permissions summary without reading the underlying report.
The register is where AI saves the most time, because most of its content already exists in scattered documents. Here’s a prompt to start it:
| I’m attaching notes, tickets and emails from our AI pilot. Build a rollout register with one row per workflow. For each row give: workflow, team, data source, data owner, who can see the data (if stated), sign-off status, support route, estimated monthly cost lines (if stated), and the next check date. Use only what the documents say. Where something isn’t stated, write [MISSING] instead of guessing, and add a list at the end of every [MISSING] item grouped by who could answer it (data owner, IT or security, finance, team lead). Don’t suggest wave order or approve anything. |
Only attach documents you’re allowed to share with your approved tool. The output is a draft for the scale owner to check against the source documents.
To judge whether the rollout is holding, look past license counts. Use asks whether people are working through the new route. Persistence asks whether each team is still doing so a month or two later, without the pilot lead nudging. Impact asks whether the work is different, with named examples, and whether the team would notice if it stopped. A rollout that only reports licenses assigned has measured access.
I wouldn’t announce a rollout date yet. I’d spend a few weeks finding out what the pilot was quietly borrowing.
A pilot lead gathers the favors and drafts the register. A data owner and the IT or security lead take the first two lanes, a function head and a finance partner take the money, and a team lead or local champion takes support for each new team. Start this week by writing down, on one page, who opened what for the pilot. That page is the list of services you still need to build.
They run in parallel, but the first wave should be chosen by infrastructure readiness. A team can’t adopt a tool it can’t reach, doesn’t have a license for, or isn’t cleared to use on its data. Once the first wave is plumbed, the behavior work in our pilots companion piece matters most.
Both, for different lanes. IT or security owns sign-off and identity, the data owner owns access to the data, a finance partner and the function head own the money, and a named lead in each new team owns its start. One person, often a program lead, keeps the register and chases the gaps.
We don’t know of a research benchmark worth quoting, and Gartner’s own warning is that costs for generative AI are less predictable than for other technologies. A practical approach is to cost one real workflow for a full year before rollout, set a ceiling with an alert before you reach it, and revisit the number quarterly.
Not necessarily at the start. A small organization can run this with one coordinator, part-time, plus the existing IT and data owners. A dedicated team starts to make sense when the register grows past what one person can keep current, or when the same questions keep arriving faster than anyone can answer them.
That’s why the register is built around workflows, not products. Data sources, owners, conditions, costs and support routes mostly survive a change of tool, and the sign-off and contract rows are the ones to redo. Keep the fallback question from the review table somewhere visible, so a vendor change or price rise is a planned event instead of a surprise.
Sources were read on October 8, 2026: McKinsey’s State of AI survey (August 2026 edition), Gartner’s February 2025 release on AI-ready data, Gartner’s July 2024 release on generative AI projects abandoned after proof of concept, and Microsoft’s documentation on Microsoft 365 Copilot data protection. The McKinsey figures are self-reported by survey respondents. The Gartner project figure is a forecast, not a measured outcome, and we have left out the sample size of the AI-ready data survey because the release gave two different numbers. The four lanes, the Scale Plumbing Check, the rollout register and the cost table are Future Factors working methods based on our own judgment, not research-validated models, and the cost figures are round example inputs. The scenes are illustrations, not client stories.
Weekly tips. Real examples. Practical help for busy professionals.
We care about your data, check out our privacy policy.