How to Go From One AI Use Case to a Program: The 4 Gaps That Stall Enterprises

TLDR: Most enterprises that ask how to go from one AI use case to a program are not short of ideas or technology. They are short of an owner, an intake process, a prioritization method, and a way to handle functional pushback. The first win hides all four gaps because one motivated person carried them informally. The second use case exposes them.

Best For: Heads of Transformation, Heads of AI, CAIOs, and COOs or finance leaders carrying the AI mandate at enterprises with 1,000 to 15,000 employees in manufacturing, distribution, healthcare services, hospitality, or insurance, who have one live AI use case and a CEO asking for more.

An AI program is an operating arrangement that turns individual AI use cases into a repeatable pipeline with a named owner, a standard way to accept and rank requests, and a shared method for measuring results. It differs from a pilot, which proves one thing once, and from a platform, which is infrastructure waiting for work. In an enterprise that has just landed its first live use case, the program is the missing layer between "that worked" and "we do this every quarter." This post explains why the first success conceals that layer, what the four gaps look like in practice, and how to close them without building a bureaucracy that outlives the CEO's patience.

Why the First Win Hides the Missing Operating Model

The first AI use case succeeds because one person did the work of an operating model by hand. They chose the process, negotiated with the function head, found the data, defined success, and stayed until it ran. None of it was written down, so the enterprise concludes it has a repeatable capability when it has a repeatable person.

That distinction matters more than it sounds. In the McKinsey State of AI survey, nearly nine in ten organizations use AI in at least one function, but only 44% report scaling it across the enterprise and only 6% qualify as high performers with meaningful profit impact. The gap between the first and the second number is the population this post is written for. They have a use case. They do not have a program.

The first use case is also, almost always, the easiest one. It was picked by someone who knew where clean data lived and which function head would say yes. The BCG value gap study puts 60% of companies in the group with minimal material value despite real investment, and the pattern behind that number is familiar: a good first result, followed by a second and third attempt that inherit none of the conditions that made the first one work.

The second use case is the real test

The second use case is where a transformation lead learns whether they have a program. It arrives from a different function, with a different data owner, and a different definition of done. If the first use case took ten weeks and the second is on week fourteen with no go-live date, the technology is rarely the reason. Bain's executive survey found that 80% of generative AI use cases met or exceeded expectations, yet only 23% of respondents could tie their initiatives to new revenue or cost reduction. The tools worked. The organization around them did not.

What "stall" looks like from the CEO's chair

From above, a stall looks like a slowdown in a program that seemed to be accelerating. The CEO saw one result in a quarter and expects three the next. What they get is a status update. IBM's 2025 CEO study found that only 25% of AI initiatives delivered their expected return over the prior few years and only 16% had scaled enterprise-wide, while 64% of CEOs admitted to investing out of fear of falling behind before they understood the value. That is the environment a transformation lead is working in. The sponsor is impatient, the track record is one data point long, and nobody has said no to anything yet.

How to Go From One AI Use Case to a Program: The 4 Gaps

Going from one AI use case to a program means closing four gaps that the first success masked: no named owner for the pipeline, no intake process for requests, no prioritization method grounded in operating data, and no plan for functional pushback. Each gap is invisible while one person carries it and becomes a bottleneck the moment volume arrives.

The table below is the stall diagnostic. It is worth running before the next steering meeting, because each gap has a specific symptom and a specific fix that does not require a new department.

1. No owner: the pipeline belongs to everyone, so it belongs to nobody

After the first win, ownership defaults to the person who delivered it, usually in addition to a day job. That works for one use case and fails at three. The Deloitte State of AI in the Enterprise report, based on 3,235 senior leaders, found that 37% of companies use AI without changing any process at all, and that only one in five has a mature model for overseeing autonomous AI agents. Ownership is the first thing those numbers are describing. Somebody has to be accountable for the queue and the results that come out of it, and that accountability has to be written into a role. Enthusiasm runs out around the third request.

2. No intake: requests arrive faster than anyone can qualify them

Once the first result is known, requests multiply. Some are good. Many are a vendor demo someone saw. Without an intake process, every request costs the lead a meeting to understand, and the queue becomes a list of conversations rather than a list of candidates. PwC's AI agent survey found that 88% of executives plan to increase AI budgets in the next twelve months, but only 42% are redesigning processes around the agents they are buying. Money is arriving ahead of method. An intake form is the cheapest piece of method there is, and it is the one most leads skip because it feels too small to matter.

3. No prioritization: the workshop vote replaces the operating data

The most common substitute for a prioritization method is a two-hour workshop where function heads score ideas on a one-to-five scale. The scores reflect who spoke last. The S&P Global survey reported by CIO Dive found that 42% of companies abandoned most of their AI initiatives in 2025, up from 17% the year before, and that 46% of proofs of concept were scrapped before production. A large share of those were never the right candidate in the first place. Prioritization with operating data, meaning transaction volume, hours consumed, error and rework rates, and cycle time by step, is what separates the second use case that ships from the one that gets quietly cancelled. A full prioritization rubric for AI use cases is a Tier 2 problem; at this stage, the rule is simply that no request enters the queue without a number attached.

4. No plan for pushback: agreement in the room, delay in the calendar

Functional leaders rarely object to AI in a steering committee. They object by not making their data owner available, by asking for one more requirements review, or by discovering a compliance question in week nine. Gartner's agentic AI forecast expects more than 40% of agentic AI projects to be cancelled by the end of 2027, citing unclear business value and inadequate risk controls. Both of those are things a function head can legitimately raise. The plan for pushback is a decision about who owns the result. It is covered in the next section, and it fits in one sentence.

Why Functional Pushback After a Successful Pilot Is Rational

Functional leaders slow down the second and third AI use cases because the first one changed the risk without changing the reward. The AI lead got the credit, the function head inherited the exceptions, and nothing in their scorecard moved. Until the business owner of a process also owns the outcome of AI in that process, resistance is sensible.

Consider what the first use case looked like from the AP or procurement director's side. Their team's work was measured, sometimes in ways that felt close to surveillance. A new step was inserted into a controlled process. When something went wrong, their staff handled it. When it went right, the transformation lead presented it. The MIT NANDA report covered by Fortune found that 95% of generative AI pilots delivered no measurable profit impact, and that the largest returns sat in back-office automation while more than half of budgets went to sales and marketing tools. The functions with the best use cases are often the ones with the least reason to volunteer.

Move the result onto the function head's scorecard

The fix is ownership transfer, and it is uncomfortable for the transformation lead because it means giving away the slide. The transformation lead owns the pipeline, the standard, and the measurement method. The function head owns the individual use case and reports its result to the CEO or CFO. This one change converts a passive stakeholder into an interested one, because the number on their slide is now their number. It also settles the human-in-the-loop question in the right place: the person accountable for the process decides which steps keep a reviewer, not the person accountable for the technology.

Treat compliance questions as intake fields, not objections

SOX controls, segregation of duties, and reviewer requirements are real constraints in a finance or procurement workflow. When they surface in week nine they are a stall. When they are fields on the intake form they are a filter. Asking "which approval thresholds does this touch, and who signs today" at intake removes the most common late objection before it can be used as one. This is also why the honest answer to where to start with AI agents in a traditional industry is high-volume back-office intake rather than customer-facing work: the control surface is known and the reviewer is already there.

How to Go From One AI Use Case to a Program Without Building a Bureaucracy

The smallest working AI program has four parts: one named owner with allocated time, a one-page intake form, a sequencing rule for what enters delivery next, and a business owner per use case. It can be stood up in a month and does not need a center of excellence, a platform decision, or a headcount request to start.

The temptation after a first win is to build the full apparatus. A committee gets chartered. A governance framework gets drafted. Someone opens a platform evaluation. The Informatica CDO Insights survey found that 97% of organizations struggle to demonstrate the business value of generative AI and that 67% failed to move even half of their pilots into production. Infrastructure did not solve that for them. It will not solve it for a transformation lead with no team either. What does solve it is a short list of decisions, made once and applied the same way every time.

The intake form: seven fields, one page

Every request, including the CEO's, answers the same seven questions before it enters the queue. Process name and the step where work piles up. Monthly volume of the transactions or documents involved. Hours per month currently spent, taken from timesheets, ticket systems, or a two-week count. Not a survey. Error or rework rate, and where exceptions go today. Systems of record touched, and whether the AI would read from them or write back. Controls in scope: approval thresholds, segregation of duties, audit trail requirements. Named business owner who will report the result. A request with blanks does not get a meeting. It goes back with the blanks highlighted, which is slightly annoying for the requester and exactly the point.

The sequencing rule: second use case, same neighborhood

The second use case should come from the same function or the same data as the first. If the first win was in AP invoice intake, the second is AP exception handling or procurement intake, not a customer service pilot in another division. The reason is that the conditions that made the first one work, meaning a known data owner, a willing function head, and understood controls, are already in place. KPMG's AI pulse survey found that 53% of organizations have deployed agents but only 26% have full visibility into what they cost to run; spreading early across unrelated functions is how that visibility gets lost. The rule has a second half: do not start the third use case until the second has a baseline and a business owner. Repetition in one area produces volume. Breadth produces a slide with many logos on it.

For an enterprise where the first use case touched a controlled process, such as payment release, financial close, or regulated customer data, and the CEO wants five more before year end, a generic approach is not enough; the answer is a dedicated program build that does three things: it assigns a single pipeline owner with time carved out of an existing role and a business owner per use case before any work starts, it installs the intake form and the operating-data scoring standard so every candidate carries a baseline before it is ranked, and it sequences delivery within one function until the second and third use cases have shipped and been measured, with reviewer steps and approval thresholds designed at intake rather than discovered in testing.

What the owner actually does each month

The pipeline owner's job is smaller than it sounds. They run the intake, keep the ranked list current, confirm each in-flight use case has a baseline and a business owner, and hold one monthly review where the CEO sees the queue, the two or three items in delivery, and the results of anything live. That review is where momentum is kept without theater. A baseline established before deployment, following the kind of pre-deployment measurement method that finance will accept, is what makes the results slide credible when the board eventually asks what the AI budget returned.

What Separates an AI Program From a String of Use Cases

An AI program is defined by what persists between use cases: an owner, an intake standard, a ranking method, a measurement standard. A string of use cases is defined by what does not persist, which is everything except the people. Two use cases and an owner is a program; nine use cases and no owner is not.

The vocabulary here is often muddled, and it helps to draw boundaries. A pilot tests whether something works. A use case is a live, measured deployment in one process. A program is the machinery that produces use cases on a schedule. An AI center of excellence is one possible home for a program, but a program does not require one; a lean AI operating model can sit with a single owner inside operations or finance. A platform is infrastructure, and the most expensive mistake at this stage is to buy one before there is a queue to run on it.

Industry thinking on this has moved, and fairly quickly. Two years ago the standard advice was to run many pilots and let the winners emerge. The Gartner prediction that 30% of generative AI projects would be abandoned after proof of concept marked the turn; the current consensus, visible in the McKinsey finding that 73% of high performers fundamentally redesigned workflows against 25% of everyone else, is that the operating arrangement around the use case matters more than the number of use cases. The structural problems that stall enterprise AI strategies in year two are, in most cases, the four gaps above left open for another twelve months.

The Hardest Questions Transformation Leads Get Asked

The hardest questions transformation leads get asked after a first AI win are about speed, process, and measurement: why the second use case is slower, whether an intake process is bureaucracy, and how to baseline time without surveilling staff. Each has a direct answer, and none of the answers requires a framework, a committee, or a platform decision.

"The first one took ten weeks. Why is the second taking longer?" Because the first one was chosen by someone who already knew the data owner and the function head, and the second was not. The delay is the cost of the missing intake and ownership decisions, paid in calendar time. Fix those and the third one will be faster than the first.

"Why do we need a process for this? Just do more of what worked." What worked was a person, not a process, and that person does not scale. The process is one page and one monthly meeting. It exists so that the CEO's next idea and the AP director's next idea are judged the same way, with the same numbers, which is also what keeps function heads from feeling that the queue is political.

"Isn't an intake form just bureaucracy?" A seven-field form that takes twenty minutes is not bureaucracy. A steering committee that meets monthly to discuss ideas nobody has quantified is. The form is what lets the lead say no to a weak request without a meeting, and yes to a strong one without a debate.

"How do we baseline team time without it looking like surveillance?" Take the numbers from systems, not from people: ticket volumes, invoice counts, cycle time stamps, rework queues. Where a count is needed, count the work for two weeks, not the workers. The business owner of the process should be the one who explains the measurement to their team, because it is their result.

What to Do in the Next 30 Days

In the next 30 days, a transformation lead with one live use case should name the pipeline owner, write the seven-field intake form, choose the second use case from the same function as the first, and book the first monthly review with the CEO. Those four actions close the gaps that stall most enterprises at exactly this point.

Put the owner's time in their role description this month, even if it is a fraction of one person. Route every open request through the intake form, including the ones that arrived from above. Confirm the second use case's business owner before any technical work starts. Keep the monthly review to three items: the queue, what is in delivery, and what is live. None of this is visible from the outside, which is the point. The CEO will see the second result arrive faster than the first, and the function heads will see a queue they can trust.

This analysis was developed using methodologies and operating experience from Assembly.

Frequently Asked Questions

Why do AI programs stall after the first use case?

AI programs stall after the first use case because one person carried the operating model informally. They chose the process, found the data, negotiated with the function head, and defined success. The second use case arrives from a different function with none of those conditions, and the missing owner, intake, and prioritization method become visible as delay.

How do you go from one AI use case to a program?

Going from one AI use case to a program requires four decisions: a named pipeline owner with allocated time, a standard intake form, a prioritization method based on operating data, and a business owner per use case. These can be in place within a month and need no center of excellence, platform purchase, or new headcount to start.

What is the difference between an AI pilot, a use case, and a program?

A pilot tests whether something works; a use case is a live, measured deployment in one process; a program is the machinery that produces use cases on a schedule. The program is defined by what persists between use cases: the owner, the intake standard, the ranking method, and the measurement standard. Without those, an enterprise has a series of pilots.

Who should own AI use cases in an enterprise with no AI team?

One named person should own the pipeline, with time formally allocated in their role, while the function head owns each individual use case and reports its result. This split keeps the queue, the standard, and the measurement method consistent, and gives functional leaders a direct stake in outcomes. Ownership by enthusiasm rather than by role is the most common failure.

Why do functional leaders resist AI after a successful pilot?

Functional leaders resist because the first use case changed their risk without changing their reward. The transformation lead presented the result while the function absorbed the exceptions and the measurement. Moving the reported result onto the function head's scorecard, and letting them decide which steps keep a reviewer, turns a passive stakeholder into an interested one.

What is an AI use case intake process?

An AI use case intake process is a standard one-page form every request completes before entering the queue. The seven fields cover process and step, monthly volume, hours spent from system data, error and rework rate, systems touched and write-back needs, controls in scope, and a named business owner. Requests with blanks go back instead of getting a meeting.

How should the second AI use case be chosen?

The second AI use case should come from the same function or the same data as the first. The data owner, the willing function head, and the understood controls are already in place, so delivery is faster and the result is comparable. Spreading early across unrelated divisions loses those conditions and, according to KPMG, cost visibility along with them.

How many AI use cases should an enterprise run at once?

Two or three use cases in delivery at once is the practical limit for an enterprise with a single pipeline owner and no dedicated team. The sequencing rule is to hold the third until the second has a baseline and a business owner. Repeating in one area produces volume faster than starting several things at once.

What share of enterprises actually scale AI beyond the first use case?

Only 44% of organizations report scaling AI across the enterprise and just 6% qualify as high performers, according to McKinsey's State of AI survey. Nearly nine in ten use AI somewhere, which means most of the gap sits between the first use case and a functioning program rather than at adoption.

Why do AI use cases get cancelled before production?

AI use cases get cancelled before production mainly because they were never the right candidate, not because the technology failed. S&P Global found 42% of companies abandoned most AI initiatives in 2025 and 46% of proofs of concept were dropped before production. Prioritizing with operating data instead of workshop votes removes most weak candidates at intake.

How do you prioritize AI use cases without a workshop vote?

Prioritize AI use cases by attaching operating data to every request: transaction volume, hours consumed, error and rework rate, and cycle time by step. A workshop vote reflects who spoke last; operating data reflects where work piles up. At the program stage, the rule is simply that no request enters the queue without a number attached to it.

How do you handle SOX and human-in-the-loop requirements in an AI program?

Handle SOX and reviewer requirements as intake fields rather than late objections. Ask at intake which approval thresholds the use case touches, who signs today, and where segregation of duties applies. The business owner of the process then decides which steps keep a human reviewer, which places the control decision with the person accountable for the process.

How do you baseline team time before deploying AI without surveillance?

Baseline team time from systems rather than from people: ticket volumes, invoice counts, cycle time stamps, and rework queues. Where a manual count is needed, count the work for two weeks, not the workers. The function head should explain the measurement to their team because the result belongs to them, which removes the surveillance concern at its source.

What does the pipeline owner do each month?

The pipeline owner runs intake, keeps the ranked list current, confirms every in-flight use case has a baseline and a business owner, and holds one monthly review with the CEO. That review covers three items: the queue, what is in delivery, and what is live. It is where momentum is maintained without status theater or additional committees.

Does an enterprise need an AI center of excellence to run a program?

No, an enterprise does not need an AI center of excellence to run a program. A single owner inside operations or finance, an intake form, a sequencing rule, and a monthly review are enough to start. A center of excellence can house the program later, but building one before there is a queue adds overhead without adding use cases.

What should a transformation lead do in the first 30 days after the first AI win?

In the first 30 days, name the pipeline owner, write the seven-field intake form, route every open request through it, and choose the second use case from the same function as the first. Confirm its business owner before technical work starts and book the first monthly review with the CEO. Those actions close the gaps that stall most enterprises here.