When it pays off and when it is too early
AI pays off where the same action repeats many times and its result can be verified mechanically. Request triage, document extraction, first-line support, reconciling data between systems. The duller the work and the more often it happens, the faster the effect shows up in numbers.
The gap between adoption and impact is wide. McKinsey found that 88% of organizations use AI in at least one function, yet only 39% can point to any effect on company-level EBIT — and for most of them that effect sits below 5%. Above 5%, there were 109 respondents out of nearly 2000, roughly 5.5%.
Adoption versus impact
-
88 %
use AI in at least one function
-
39 %
report any effect on company-level profit
-
5,5 %
get more than 5% of EBIT from AI — 109 of nearly 2000
McKinsey, “The state of AI in 2025”, nearly 2000 respondents
Here is what readiness looks like, and what too early looks like.
Ready
The process repeats and can be verified
- It runs dozens of times a day with the same steps
- There is an export covering at least a few months
- A mistake shows up immediately and is cheap to undo
- One person owns the result
Too early
The model goes stale before it pays off
- The process gets rewritten every quarter
- The data lives in people's heads and unarchived email
- The cost of an error exceeds the cost of the work
- The process being automated should not exist
The cost of an error deserves a separate note. If a wrong decision means a lawsuit or a lost license, you need a human in the loop first and automation second.
Data deserves one too, because this is where arguments start. There are three cases and they call for different decisions:
- no data — the process cannot be exported: it lives in people’s heads and in email nobody archived. This is the only case where the project waits;
- little data — the export exists but is short. Start with an off-the-shelf model and prompts, and postpone your own fine-tuning;
- the process should not exist — automating what ought to be cancelled. Sometimes the honest outcome of a review is “nobody has read this report in a year”. That is cheaper than any implementation.
Steps to implement AI without burning the budget
Start with one process that hurts and can be measured. The strategy comes later, once there is a working loop and you know what it cost and what it returned.
The temptation runs the other way, and it is expensive. A strategy written before the first implementation rests on assumptions about timelines, cost and data quality. All three are usually wrong, and you find out on the first project anyway.
Our own sequence is deliberately inverted. A free review of one process first — thirty minutes on the actual workflow and the actual data. Then a pilot on that single process: a small working version running on the client’s real records, not on a curated demo set. Then the full build, then monthly support, because a model without retraining drifts away from the process it was built for.
How the work runs
-
Review
A call where we look at your processes and your data. Free
-
Pilot
A small working version on one process and real data
-
Build
Full functionality, if the pilot showed a result
-
Support
Retraining on new data, or the model decays along with the process
When you pick the first process, look at frequency rather than size. The dullest stretch of work is usually the best candidate — that is where a person does something mechanical and where the output can be compared against a known answer.
One more rule: make the first process internal. A mistake in request triage is visible to you. A mistake in a reply to a customer is visible to the customer.
What you need before you start
Two things: data in machine-readable form and a person who owns the result. Hardware, models and integrations are decided along the way.
The data does not have to be clean. It has to be exportable. A raw dump of tickets from your CRM beats a polished dashboard nobody can extract from.
| What you need | What to do without it |
|---|---|
| An export covering several months | Start collecting now, return in a quarter |
| A description of how the process works today | Watch someone do it for a shift |
| A definition of “done correctly” | Label a hundred examples by hand — two or three days |
| An owner who can accept the result | Do not start: there will be nobody to sign off |
The last row is the most common reason projects stall. When nobody owns the outcome personally, the discussion turns into endless review cycles while the model quietly ages.
What is missing most often, in our experience, is access rather than data. An export promised in a week arrives six weeks later, because the records sit in a system maintained by a vendor who left two years ago. Budget for that delay up front and request access on day one, not when the queue reaches it.
Labeling deserves a note of its own, because it is the step people skip. Without it you cannot answer whether anything improved: there is nothing to compare against. A hundred hand-labeled examples take two or three days, and they save months of arguing about whether the thing works.
Why pilots never reach production
The cause is almost never the model. MIT’s NANDA project reviewed corporate generative AI initiatives and found that 95% of pilots produce no measurable return, against 30–40 billion dollars of investment. The authors add a qualifier that gets lost in retelling: the divide is driven by approach, not by model quality and not by regulation.
That qualifier matters. Read without it, the number sounds like a verdict on the technology. The report says the opposite — the technology works and the rollout does not.
Gartner’s forecast for agentic systems has the same shape: more than 40% of agentic AI projects will be canceled or paused by the end of 2027. The reasons are named plainly — rising costs, unclear business value, weak risk controls. The survey covered more than 3400 organizations.
What actually stops projects, in our experience:
The pilot ran on invented data. The demo was built on examples the vendor prepared. On real records quality drops, because real records are dirty, incomplete and stored in three different formats. There is one cure: run the pilot on the client’s export from day one, however ugly it is.
Nobody agreed on what success means. The project ends, everyone is pleased, and no one can say whether anything improved. Write the criterion down before you start, in one line: “handling time drops from forty minutes to ten”. Not “improve efficiency”.

There was nobody to hand it to. The pilot lived on the vendor’s side and no one inside picked it up. A quarter later the process changed, the model started missing, and people quietly stopped opening it. This is why support is not an upsell: without retraining, a solution stays useful for about a quarter.
Build in-house or hire
An AI implementation business model splits along one line: is the model part of what you sell, or part of how you work?
An in-house team pays off when AI is the product — recommendations inside the service, scoring, generation for end users. There model quality is the competitive advantage, and outsourcing it is strange.
A vendor makes more sense when AI sits inside internal processes. Document extraction, request routing, a support assistant — these are standard problems, and building a team for them is expensive. Knowing how to implement AI in business at that level takes weeks; hiring an ML engineer takes months.
In-house team
AI is part of what you sell
- Recommendations inside the service, scoring, generation for users
- Model quality is the competitive advantage
- Hiring an ML engineer takes months
Vendor
AI sits inside internal processes
- Document extraction, request routing, a support assistant
- Standard problems, an in-house team for them is expensive
- The first working loop takes weeks
- 78 % of companies use ready-made partner solutions
And plainly: when a vendor is not needed. If an off-the-shelf subscription solves the task and your process does not require integration with internal systems, buy the subscription. We say so during the review, and it is more honest than selling a project that will not pay for itself.
One more signal: if AI is needed for a single monthly report, leave it alone. Automating rare processes almost never pays — the hours saved are too few and the support costs the same.
What to read next
If you are still mapping the territory, three things are worth reading in this order. The MIT report, for what separates the 5% from everyone else. The McKinsey survey, for how thin the impact is even among adopters. And your own ticket log for the last quarter — it will tell you more about where the repetition is than any study.
When you have a specific process in mind, we do a free thirty-minute review of it: what the data looks like, where AI would earn its keep and where it would be overkill.