For every twenty AI projects a company starts, nineteen never reach the bottom line.
The figure comes from MIT's NANDA initiative and its report The GenAI Divide: State of AI in Business 2025, published in August 2025 after analysing 300 real deployments: 95% of generative-AI pilots produce no measurable impact on the P&L. Only one in twenty actually moves the business.
Faced with that number, many leadership teams hunt for the culprit in the wrong place, usually the model, the vendor, or the lack of a strong in-house technical team. And out of that comes the most expensive conclusion of all: that without a robust IT department you can't do AI sensibly.
A company without a large IT department actually holds an advantage the big enterprise has lost, because nobody inside the organisation gets paid to defend a pilot that doesn't work. What's missing is a criterion for deciding what gets done first, what gets parked, and what doesn't get touched at all. This article is that criterion, and you can apply it on Monday morning.
The year AI stopped being an experiment
In 2026 the conversation has shifted phase. McKinsey's most recent global survey on the state of AI shows that nearly nine in ten organisations now use it regularly, so the question "should we adopt AI?" has stopped meaning anything, because the answer is already yes, whether the committee likes it or not.
The question that matters now is a different one: of everything AI can do, what does your company do first?
For a mid-market company the danger has a specific name, the fear-driven portfolio. The committee watches competitors announce initiatives, gets nervous, and approves eight or ten pilots at once so as not to fall behind. Six months later there are eight invoices, no clear owner, and nothing to show.
One finding from the same MIT study is worth keeping in view while you prioritise, because more than half of AI budgets go to sales and marketing tools while the biggest return shows up in back-office automation, meaning cutting administrative work, reducing the cost of outsourced processes, and tidying up operations. The place where money is easiest to recover rarely matches the place the committee wants to spend it.
Why this isn't a decision for your technical team
Prioritising AI use cases is, at bottom, allocating capital, and allocating capital is the job of general management and finance, not of a technical role.
This is the reclassification that changes the outcome. When the committee treats prioritisation as a technical matter it delegates it, and whoever receives it optimises for technical criteria (what is elegant to build, what uses the newest technology) instead of optimising for euros. The order of projects has to be set by whoever answers for the margin.
The underlying fear in many mid-market firms is "I don't have engineers for this." The same MIT study defuses it with a useful number, because buying AI tools from specialised vendors works roughly 67% of the time, while building the solution in-house works only about a third of the time. For a company without a large IT department, the path with the best odds of return is to buy proven product and connect it, rather than launch an engineering project.
Put another way, the absence of an internal technical team doesn't block you from doing this: it pushes you toward the approach that, on the evidence, works best anyway.
The framework: score each use case on three axes
The framework is deliberately simple, because it has to fit on one page and survive a committee meeting. Each candidate use case is scored from 1 to 5 on three axes.
Economic impact. How many euros it moves per year, expressed in a metric the CFO already recognises: work hours freed and valued at cost, unit-cost reduction, cash cycle, retained revenue. If the sponsor can't state this week's starting figure, impact stays a question mark rather than a 5.
Effort. What it costs to get it running, and here the cost is rarely the licence. It's preparing the data, integrating with what you already have, and above all the change of habit in the people who will use the tool. A case that requires cleaning three databases before it starts is high-effort even if the software costs four euros a month.
Risk. What happens when the system gets it wrong. An assistant drafting internal documents is low-risk, because a human reviews before anything goes out. A system that replies directly to customers, sets prices, or touches personal data is high-risk, and it also carries the European regulatory filter.
The common trap is to average the three numbers. Don't. Impact and effort get compared against each other, but risk works as a barrier, so any high-risk case stays out of the first 90-day batch however good it looks, because your initial goal isn't the most ambitious project, it's proving the method works without betting your reputation on the first attempt.
The matrix: four boxes and what you do with each
With high-risk cases already set aside, place the rest on an impact-versus-effort matrix. Four boxes appear.
Quick wins (high impact, low effort). These are your first-90-days batch. They almost always live in the back office: document summaries, first drafts of recurring reports, email triage, data prep for meetings.
Big bets (high impact, high effort). They matter, but not now. They go onto a twelve-month roadmap and only get funded once a quick win has shown the company can execute. Starting here is the most common and most expensive mistake.
Fill-ins (low impact, low effort). Done only if there's spare capacity after the quick wins. They never compete for the committee's attention.
Money pits (low impact, high effort). Dropped today, in the meeting itself. If someone insists, that insistence usually signals the case had an internal champion and no return.
"A company's first AI use case shouldn't be chosen for how ambitious it sounds in the boardroom, but for how fast it proves the method works."
Why so much discipline about starting small? Because AI's internal credibility is won or lost with the first project. A quick win that moves a real metric in 90 days buys you permission for the big bets. An ambitious first project that stalls kills the committee's appetite for two years.
The 90-day roadmap
The framework above becomes a calendar. What follows is something a CEO or CFO can take into this week's committee and set in motion without hiring anyone.
1. Days 1 to 15: inventory and score. Pull every AI use case anyone in the company has proposed, started, or imagined into a single list, and score each one on the three axes. The list is usually longer and messier than the committee expected, and that itself is information.
2. Days 1 to 15: assign a business owner to each case. A person with a P&L, not an IT role, who wins or loses money on the affected process. A case with no owner doesn't get scored: it gets dropped. Orphanhood is the first symptom of a pilot going nowhere.
3. Days 16 to 30: pick two or three quick wins and measure the baseline. Two or three, not ten. For each, write down today's starting number: minutes per task, cost per process, errors per batch. Without a baseline measured now, in 90 days you'll prove nothing and the project will coast on "it seems to be going well."
4. Days 16 to 30: buy, don't build. For each quick win, look for a specialised-vendor tool before proposing your own development. It's faster, it's cheaper to reverse if it fails, and on the evidence it's twice as likely to work.
5. Days 31 to 75: run it with a checkpoint on day 50. Let the team actually use the tool. On day 50, review: if the metric hasn't moved at all halfway through, it probably won't by the end, and it's worth knowing in time to correct or cut.
6. Days 76 to 90: measure against the baseline and decide. Compare the final number with the starting one. Each quick win lands in one of two columns: the one that moved the metric, which becomes a candidate to scale, and the one that didn't, which closes without drama. That clean close is part of the method, not a failure.
Ninety days, two or three tools bought, no engineer hired, and at the end, evidence instead of opinions.
Who signs off, and what happens on day 91
The framework loses its value if the person asking for the budget is the one applying it. It has to be held by someone with cross-functional authority, and in a mid-market company that's the CEO or the CFO, sitting at the same table. The reason is simple, because step 2 and the money-pit box force you to say no to projects with internal champions, and only whoever answers for the whole does that comfortably.
On day 91 your company is somewhere different. It no longer argues about whether AI works, because it has a metric that genuinely went up or down. It has learned to run the full loop (inventory, score, prioritise, measure, decide), and that loop repeats every quarter with new cases, now with the big bets on the table.
The matrix fits on a napkin. The hard part comes after: holding the line when ten proposals arrive with a champion and a deadline, and keeping a cool head about what moves the business and what merely sounds good. That conversation, how a leadership team builds and defends its own AI roadmap rather than delegating it, is what we work on at Shift Directivo, Stradiax's in-person program for executives.
Next time an AI proposal reaches the committee, before asking which model it uses, run it through the three axes. If it has no measurable impact, no business owner, and no manageable effort, that proposal isn't ready to execute yet, IT department or not. Its place is the waiting list.
