AI implementation for business: where to start

InsightsDevelopment

This is artificial intelligence for business: an implementation guide, not a market survey. AI implementation for companies comes down to three questions, in order: is your case ready, what to build first, and why most pilots never reach production.

No list of models and no promised payback percentages: both depend on the process, not on the technology. Written for people choosing their first process and their first vendor.

The numbers here come from three studies published in 2025, and every one of them points the same way: adoption is easy, impact is not.

AI implementation for business: where to start

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

Adoption turned out to be the easy part

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
Readiness comes down to the process and the data, not the budget

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

  1. Review

    A call where we look at your processes and your data. Free

  2. Pilot

    A small working version on one process and real data

  3. Build

    Full functionality, if the pilot showed a result

  4. Support

    Retraining on new data, or the model decays along with the process

The pilot fee counts toward the build, so the decision rests on evidence

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 needWhat to do without it
An export covering several monthsStart collecting now, return in a quarter
A description of how the process works todayWatch 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 resultDo 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”.

An executive with a finished pilot and nobody to hand it to

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
The line runs through the role of AI, product or process

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.

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.

  1. When it pays off and when it is too early
  2. Steps to implement AI without burning the budget
  3. What you need before you start
  4. Why pilots never reach production
  5. Build in-house or hire
  6. What to read next

Frequently asked questions

  • How much data is enough to start
    It depends on the task, but the order of magnitude is this: a few thousand examples for classification, a few hundred labeled ones to measure quality. With less, you start with an off-the-shelf model and prompts, and postpone your own tuning until data accumulates. No data at all is the one case where the project should wait.
  • Will AI replace employees
    In the processes we automate, usually not. The composition of the work changes: a person stops doing the mechanical part and starts handling the cases the machine routes to them. On large volumes that shows up as speed rather than headcount. Companies redistribute people more often than they cut them.
  • What if the data is confidential
    Run the model inside your own perimeter or with a local provider. It costs more than a cloud subscription, and the data never leaves. Decide this before the pilot, because the choice determines the model and the architecture.
  • How do I tell whether a vendor knows what they are doing
    Ask under what conditions they would decline the project. A competent one names them immediately: no data, no process owner, cost of error above cost of the work. Anyone who takes on everything either does not understand the limits or plans to ship a demo and leave.
  • How long does a deployed solution last without support
    Roughly a quarter. After that the process shifts, new document and request types appear, and the model starts missing on them. Agree on retraining in the contract rather than discovering the question six months in.