How to Implement AI in Business

Most AI implementation advice is a maturity model: assess readiness, build a centre of excellence, develop a data strategy, upskill the organisation. By the time you finish step two you have spent a quarter and shipped nothing, and the enthusiasm that funded it is gone.

This is the other version. It assumes you are an operator with a business to run, some budget, and no appetite for a transformation programme.

The whole approach in one sentence: get one unglamorous thing working in production, then let it tell you what the second thing should be.

Step 1: Pick the Candidate on Volume, Not Annoyance

The instinct is to start with the task everyone complains about. That task is usually infrequent and emotionally irritating rather than expensive, and it is a bad first project.

Rank candidates on three axes:

1. Frequency. How many times a week does this happen? Below about twenty, be sceptical.
2. Variation. Does it go the same way most times, or is every instance bespoke? High variation means judgment, which means higher cost and a lower success rate.
3. Verifiability. Could a person, or better a piece of code, tell within seconds whether it was done right?

That third one is the filter people skip and it matters most. If you cannot cheaply check the output, errors accumulate silently and you discover them in a quarterly review. Every AI project I have seen go badly failed this test at the scoping stage and nobody noticed.

Then do the arithmetic, honestly:

(times per week) x (minutes each) / 60 x (fully loaded hourly cost) x 52

Fully loaded means salary plus employment costs. Compare against build cost plus one year of maintenance, which runs 15% to 25% of build annually. A surprising number of candidates fail here, and finding that out costs nothing. The ROI calculator does this properly.

Step 2: Test Feasibility on Your Real Data

Not a clean sample. Not the vendor's demo dataset. Your actual records, including the ones with the missing fields and the free-text notes someone wrote in 2019.

This step is deliberately cheap and designed to fail fast. Take fifty real cases, run them through whatever you are considering, and check the output by hand. You are looking for one number: how often is it right enough to use.

Two things usually surface here, and both are worth knowing in week two rather than month four.

Your data is dirtier than you think. This is the most common reason AI projects run long. Nobody knows how dirty their data is until something tries to use it programmatically.

The task is harder than it looked. Often because the humans doing it are quietly applying context nobody wrote down.

If feasibility fails, you have spent a few days rather than a quarter. That is a good outcome.

Step 3: Decide Whether to Build At All

Before anyone writes code, answer honestly: does a product already do this?

For most businesses, most of the time, the answer is yes, and buying wins on cost, timeline, and who maintains it next year. Building is right when the process is genuinely specific to how you work, touches systems no vendor integrates with, and runs often enough to justify owning it.

A firm that never recommends buying is telling you something about their incentives rather than your problem.

Step 4: Build the Narrow Version

The smallest thing that removes the work. Not a platform. Not phase one of four.

Three engineering decisions determine whether it survives:

Use AI only where the input is unstructured and the output tolerates ambiguity. Reading an email, classifying free text, summarising a call, drafting a reply someone approves. Everything expressible as an if statement should be one, because it is cheaper, faster, and it does not surprise you. Never let a model do arithmetic. It will be right 97% of the time, which is worse than a calculator being right always, because the 3% is silent.

Make it idempotent. If the same event arrives twice, the result must be identical to it arriving once. Retries happen and webhooks get redelivered. Without this you get duplicate records and double messages, and you hear about it from a customer.

Instrument failure. Automations degrade rather than crash. They keep running, keep reporting success, and produce subtly wrong output for weeks. You need an alert to a person, the same day, with the payload attached.

Step 5: Roll Out Through People, Not Around Them

A system nobody uses is a write-off, and adoption failures are more common than technical ones.

The people whose work changes should see it before launch and have a route to say "it got this wrong." That feedback is also your evaluation data, which you need anyway. Teams that deploy AI at their staff rather than with them get quiet non-adoption, which is harder to diagnose than an outage because nothing appears broken.

Step 6: Name an Owner

Before it goes live, one person owns it. Not a committee, not "IT."

Models drift, APIs deprecate, and the process you automated in March is not the process being run in September. An automation with no owner has a shelf life of about a year and it fails silently at the end of it.

The Three Ways This Goes Wrong

Automating a broken process. Automation is an amplifier. A process with an unclear owner and three exceptions a week becomes an automated one with the same problems and less visibility. If it is not written down, writing it down is the project.

Starting with the whole department. A six-month programme that has shipped nothing is not a project, it is a sunk cost accruing. One process, in production, being used, then the next.

Treating the model as deterministic. Trying it three times and seeing it work is evidence it worked three times. Anything feeding a consequential action needs a validation gate or a human.

A Realistic First 90 Days

• Weeks 1 to 2: list repetitive work, score on frequency, variation, verifiability. Do the arithmetic. Pick one.
• Weeks 3 to 4: feasibility on real data. Fifty cases, checked by hand. Decide build or buy.
• Weeks 5 to 10: build the narrow version with monitoring and a fallback.
• Weeks 11 to 12: roll out with the affected team, name an owner, measure against the baseline from week one.

That produces one working thing and, more valuably, a realistic sense of what the second project should be. Which is the actual output of a first AI implementation, and no maturity model gets you there faster.

If you want the candidate assessment done with you, that is what a free strategy session covers, including when the honest answer is that nothing on your list clears the bar. Our approach is on the AI automation consulting page.