The Decision a Pilot Was Never Asked to Make: What Leadership Needs to See Before Scaling AI

Why Do AI Pilots End Instead of Becoming Systems?

Because the pilot was asked to work, and was never asked to make a decision possible. A pilot designed only to show that the tool can do the job produces a demonstration. A scale-up needs something else: a comparison, an owner and a limit. If those were not designed in at the start, they are hard to recover at the end.

It helps to see what the two questions ask for. "Did it work?" is a question the people who used it can answer from memory, and a favourable answer is not yet a finding. "Should the firm now depend on it?" is answered by evidence that outlasts the enthusiasm: what the work looked like before, what changed, who is accountable for what the system does next, and what would make the firm stop.

That is why a pilot can succeed on its own terms and still stall. A good result is not the same thing as a decision that is easy to take. The first comes from the tool. The second comes from how the pilot was set up.

A pilot that depends on one enthusiast has a second problem, which I have written about separately as the Handover Test: until the team can run the system without the person who built it, there is nothing yet to scale.

Is Governance the Brake on Scaling AI?

No. It is the instrument panel. Without evidence, decision rights and a stopping rule, the honest answer to "should we scale this?" is "we cannot tell", and a firm that cannot tell either stalls or scales on enthusiasm.

In my experience, executives expect governance to be the thing that slows a rollout down. I think that expectation has it backwards. Stalling is what the absence of governance looks like from the inside: more discussion cannot produce information that was never collected, so the discussion continues.

The other outcome is to scale on enthusiasm and find out afterwards. Neither is a decision.

A pilot without those 3 things is not a small deployment. It is an unmeasured one.

In the operating-model framework I use, this is the work of the third verb, govern: named decision rights, a gate for sensitive material, and measurement before any return is claimed. What follows is that verb applied to one specific moment.

A word about the examples

The examples below come from 5 pages published by just 2 organisations: 4 by OpenAI and 1 by Anthropic. Each publisher is describing its own products, customers or decisions. None is independent research, and none is treated as such here. Every pattern below can be tested against your own firm without believing anybody's number, and the 3 questions I use to read a vendor's claims apply to these pages as much as to any other.

What Evidence Should Leadership Ask For Before Scaling an AI Pilot?

Not "it worked". Ask for a comparison that was captured before the pilot started, an adoption signal that is not enthusiasm, and a plain account of what was connected to the firm's own context, tools and permissions. Those 3 can be checked. A good feeling cannot.

The most useful outside evidence I know of is OpenAI's August 2026 account of its own enterprise customer base. Each month it ranks those customers by output tokens per active user, and compares the top 10% with a middle band between the 45th and 55th percentiles. That ranking measures how deeply AI is used, not how well the business performs. OpenAI itself calls the measure "a proxy for depth of use".

What makes the comparison interesting is the page's own remark that companies may have access to the same models either way. What separates the 2 groups tracks what they built around the model, not what they bought. OpenAI reports that the widening gap "appears alongside greater adoption of capabilities that connect agents to company context, tools, and repeatable workflows". That is an association in the vendor's own data, not a demonstrated cause.

The sharpest figure measures a capability wired in, not volume consumed: OpenAI reports 19% of weekly active users in the top group using skills, against 3% in the middle band. As of June it put the top group at 8.3 times as many output tokens per active user as the middle band, against 2.6 times in January. Each figure compares that month's top and middle bands and does not track a fixed set of firms.

The same page draws a modest conclusion from its 2 reports: that "access alone may not be enough to scale AI". I would put it more plainly. Scaling is not a procurement question about a better model. It is a wiring question about your own context, tools and permissions.

What counts as evidence, and what does not

• Counts: how the job ran before anything was built, recorded at the time, or reconstructed from the firm's records and labelled as a reconstruction.
• Counts: who still uses the new way of working when nobody is watching, and for which tasks.
• Counts: what the pilot was connected to: which files, which tools, on whose permissions.
• Does not count on its own: a satisfaction score, a demonstration, or an hours-saved figure answered from recall.

Why the first 30 days decide this

The chance to observe the first item on that list directly is the one thing here that expires. In Before You Claim a Return I argued for capturing a baseline before the build and an adoption signal that is not enthusiasm, and for separating validated capacity, the credible saving from workflows that are built, tested and ready but not yet habitual, from realised recovery, time that has actually left the week.

At this gate those measurements become the evidence. A firm that skipped that month still has options, and a weaker hand. The state of the work before the system arrived is no longer observable, so the comparison has to be reconstructed from whatever records exist, and labelled as a reconstruction. Adoption is different: it can be measured from today, although a month never observed does not come back.

The honest course is to say which parts of the evidence are records, which are recollection and which are missing, and to take the baseline for the next job before that job moves.

Who Decides What an AI System May Do?

The people who already hold that authority for the same work done by hand. Scaling does not call for a new, AI-specific permission system. It calls for the firm's existing permissions and sign-offs to be made legible to a new actor: whose role it works within, what it returns for inspection, and which actions a person sees before they are applied.

A pilot can be low-risk for a reason that is easy to miss. Where it is read-only, or a person retypes the output before anything happens, the system itself changes nothing in the firm's records: every action is still taken by a person. Once a wider deployment lets the system act directly, that stops being true. The question changes from what may it read to what may it do, on whose authority, and who sees it before it happens.

My reading is that firms stall here because they assume write access needs a governance apparatus they have not built. It does not. It needs the one they already own.

One vendor's pattern, worth borrowing

OpenAI's August 2026 description of its own administration tooling has 3 elements worth pulling out. I do not run this product, and this is not a recommendation of it. The transferable object is the pattern.

• It works within the role the person already has. In OpenAI's words, the tool "works within each user’s existing role and permissions; it does not grant broader access".
• It returns a structured result. Each request is mapped to a supported read or write action, and for each change the administrator can see what was requested, whether the action completed, and what changed.
• Review is available for the actions that matter most. Administrators "can review actions with broader impact before those actions are applied". Elsewhere on the page, feature-access requests that meet predefined criteria can be granted automatically, with exceptions routed for review.

Not one of those 3 requires a new, AI-specific governance principle. Role permissions and review are ordinary internal controls pointed at a new actor. The structured result is what makes that actor's work inspectable afterwards; that last point is my inference, not the vendor's claim.

Notice also what the pattern does not do. It does not put a person in front of every action. Review is offered for actions with broader impact, the workspace's existing approval requirements still apply, and in the one workflow mentioned above, requests that meet predefined criteria go through without a person. In my view, a firm that routes every action to a person has not governed the system. It has rebuilt the manual process with an extra step.

The permission sheet

A professional firm already owns the surface this pattern needs: who may see which client matter, who approves spend, who signs off work before it leaves. The work is not to invent a permission system. It is to say which of your existing permissions this system inherits, and from whom.

In practice that is one line for each action the system will take, with 4 entries:

• The action: what it does, in the words the firm already uses for that task.
• Whose authority it borrows: the role that is allowed to do this by hand today.
• What it leaves behind: the record a reviewer can inspect afterwards.
• Who sees it first, if anyone: the named person who reviews before it is applied, for the actions where that is warranted.

Where the work reaches a client, my own map is stricter. In the 3 zones of expert work, client-facing output asks for the heaviest setup and a senior reviewer for every output before it reaches a client. The sheet is where that rule gets a name beside it.

Where client material may go is a real question, and a separate one. It belongs to the tier line of the firm's AI doctrine, and it is best settled before this sheet is filled in.

What Is a Stopping Rule, and Why Write It in Advance?

A stopping rule answers 4 things: what condition pauses the system, who is allowed to pause it, within what time, and what has to be true before it restarts. It is written before the system scales because nobody negotiates it fairly in the middle of an incident, when stopping costs something concrete and carrying on costs nothing yet.

This is narrower, and I think more useful, than the broader question: what is our AI policy. A policy describes what is allowed. A stopping rule describes what happens when something looks wrong and nobody is sure.

An organisation that wrote it down

The next example is an organisation that reports "great cost and delays" to its own research from meeting its standard, and wrote the rule down anyway. OpenAI, describing its own research programme in August 2026, sets 2 clocks, not 1.

• The first clock is on raising the alert. "We aim to issue an alert within 30 minutes after concerning activity is surfaced through our monitoring system."
• The second is on deciding. For its highest-priority alerts, the teams that are paged have 30 minutes: if they "cannot conclusively determine within 30 minutes that the flag is a false positive, those teams are expected to pause the activity".

It also put a number on the monitoring itself: a current estimate of roughly 20% of the inference compute being monitored, hedged in the same sentence as varying substantially from one workload to another. That is its own estimate of its own overhead. It is not a benchmark, and no other firm should plan on it.

And it stopped work to meet its own standard. The same page reports a 2-week pause in reinforcement-learning training on its latest models intended for deployment, and says that its largest planned run of that kind was still on hold when the page was published on 18 August.

What happened next is the part worth copying

A later page completes the story. In a follow-up dated 1 September, OpenAI wrote that on 28 August it "restarted the large frontier RL run that was previously paused after the new safety and security requirements were put in place", while continuing to hold back some smaller experimental runs.

As I read the 2 pages together, the hold had a condition, and when the condition was met the work resumed. A stop with no restart condition is how a pause can quietly turn into an abandonment, which is the pilot problem again in a different place.

What transfers to a professional firm

None of the engineering does. On my reading, the posture does.

• Oversight is priced, not asserted: a published estimate, however hedged, in place of a value in a policy document.
• For the most serious alerts, the default when nobody can clear the flag is to stop, not to carry on: written down, with a clock on it.
• The rule says what restarts the work: a named requirement, so that a pause has an end.
• The standard is set by the risk of the environment, not by the convenience of the team working in it.

For an expert-led firm the equivalents are ordinary. As illustrations, not reports of anything that happened: an output that reaches a client without its named review, a figure that does not reconcile with its source, a reviewer who says outputs are being approved unread. Name the condition, name the person who may pause, name the hours within which they must decide, and name what has to be true before the work restarts.

Does All of This Have to Be in Place Before You Start?

No. Start with the boundary tight, measure what it wrongly blocks, and loosen it on evidence. Read together, the 3 sections above could be heard as do all this before you are allowed to begin. That would be bad advice, and it is not what the next example did.

Anthropic, describing one of its own models in August 2026, launched with a safety classifier it describes as very broad, knowing that this would produce "a high number of false positives in the near term", with the affected requests sent to a less capable model. It costed the alternative out loud: holding the model back until much more progress had been made on safeguards would have delayed general access "by weeks or months". It chose not to wait.

It then did the second half. It rewrote the classifier's rules to carve out benign uses, took feedback from experts inside and outside the company, retrained the classifier, and reported from its own testing a substantial reduction in false positives. It also kept part of the boundary where it was: the page says plainly that some categories of request are still blocked, and that some false positives will remain.

The transferable rule: an over-restrictive boundary you can measure and relax beats a perfect policy you have not shipped. And the loosening is selective. Evidence earns more room for the work it covers, not for everything at once.

The other branch is, in my experience, a familiar one in expert-led firms: the decision goes to a committee, a policy is drafted over months, and adoption stays where it was. So this is not gate-keeping. It is instrumentation.

My own production routines run to the same shape. They stop and report when they cannot complete a task, and they do not improvise. The rule that makes them stop is written into the routine's specification, not decided in the moment by whoever happens to be watching.

What Does a Scale-Up Decision Look Like When It Is Ready?

It has 3 possible answers, and all 3 are respectable: yes, not yet, and no. The test of whether the pilot was set up properly is whether each of them could have been reached, and whether the people in the room know what would have produced each one.

• Yes means all 4 answers exist and the comparison shows what the firm said it would have to show. The permission sheet has names on it, the stopping rule is written, and the system joins the way the firm runs, with an owner.
• Not yet means one of the 4 answers is missing, and the next step is to produce that answer, not to run the pilot again. Where the missing answer is the baseline, the remedy is to reconstruct it from the records that exist, label it as a reconstruction, and take a proper one for the next job before that job moves.
• No means the answers exist and the comparison did not show it. That is a result too.

What is not on the list is the outcome described at the top of this article: the pilot that is neither continued nor stopped. That is what the absence of a decision looks like.

For a regulated firm there is a further reason to keep the page. When I read what the SRA, the FCA, the ICAEW and the ICO have published side by side, each pointed at duties a firm already carries, among them supervision and accountability. A dated page that records what was measured, who holds the authority and what stops the system is designed to be a small, concrete piece of that.

The Verdict

A pilot earns its scale-up by making the decision easy to take, not by making the result look good. Those are different achievements, and only the first can be designed in.

If nobody can say what would have made it a no, it was never a decision.

This is the work I do, and I run my own practice on the same kind of system. If your firm is holding something that went well and nobody can say what happens next, see how the engagements work and send a note. I am happy to talk the 4 questions through with you. The thinking continues in The AI Operating System, my fortnightly LinkedIn newsletter, where an earlier version of this argument first appeared.

Frequently Asked Questions

How long should an AI pilot run before the firm decides?

Length is the wrong variable. What matters is whether there is a comparison to decide against, and whether the new way of working has had time either to become habit or to fade. A pilot can run for months and still leave nothing to decide with. A short one with a baseline, an owner and a stopping rule can be ready sooner.

What is the difference between an AI pilot and an AI system?

A pilot is watched by the person who built it. A system is something the firm depends on when that person is not in the room. The difference is not size or technology. It is whether there is a named owner, a record of what it may do and on whose authority, and a written condition that stops it.

Who should own the decision to scale?

The people who would be accountable for the same work done by hand. The decision is about the firm's work and its risk, so it belongs with the leadership team, informed by whoever ran the pilot. It is not a technical decision, and in my view it should not rest with whoever is most enthusiastic about the tool.

Does every AI action need a human to approve it?

No. In the vendor pattern described above, review is available for actions with broader impact, existing approval requirements stay in force, and one workflow grants feature-access requests automatically when they meet predefined criteria, with exceptions routed for review. The useful design question is which actions deserve a person in front of them, and the answer belongs on the permission sheet. Client-facing work is where I set that bar highest.

What if the pilot started without a baseline?

Reconstruct one now, and label it honestly as a reconstruction. Start from whatever records already exist, and only then ask the people who do the work, recording their estimates as estimates. Built on good records, a reconstruction can be strong. Built on recollection alone it is weaker, because a figure answered from recall measures what people believe happened. Then take the baseline for the next job before that job moves.

Sources

Each page was read at the publisher's own site on 13 October 2026. Each is an organisation describing its own products, customers or decisions.

• OpenAI, From assistance to execution: How enterprises put AI to work, 12 August 2026.
• OpenAI, Introducing the Admin plugin for ChatGPT Work and Codex, 25 August 2026.
• OpenAI, Pacing model development in an era of cyber-critical capabilities, 18 August 2026.
• OpenAI, Path to Astra: critical capabilities and frontier safeguards, 1 September 2026.
• Anthropic, Improving Fable 5's biology safeguards, 7 August 2026.

Dr Bruno Oliveira — PhD · Associate Professor, University of Bath. Founder of GustoMind.ai. Builds and installs AI operating systems for expert-led firms, running the same system daily in his own work.