How to implement AI in your company

Most guides to implementing AI open with choosing a tool. That is the worst possible starting point — not because the tool is irrelevant, but because it is the last decision that matters. Before you reach it, you have to settle four things no tool will settle for you: which process, what success looks like, where the data comes from, and who owns the outcome when the system gets it wrong.

What follows are seven steps in the order they actually need doing. This is a guide for the person inside the company — useful whether you run the project yourself or with a supplier. How such a project looks from the supplier’s side, broken into stages with a concrete deliverable at the end of each, is set out separately in our implementation methodology.

Step 1. Pick one process, not “AI in the company”

“Implementing AI” is not a project. It is a category of projects. Until it is narrowed to a single process with a name and an owner, the work can be neither costed nor judged a success.

A good first candidate meets five conditions at once:

1. It recurs often — tens of times a month or more. A process run five times a month rarely justifies the cost of an integration, because that cost is largely fixed.
2. Its rules are reasonably stable. If two people do it differently today and both believe they are right, somebody has to settle which one is — automation will not do that for you.
3. The input data exists in a form a machine can process.
4. A mistake is detectable and reversible. For a first project, avoid any process where an error only surfaces at the customer or the regulator.
5. It has an owner — a specific person who can resolve questions and cares about the result.

If no process meets all five, choose the one missing only the third. Absent data is a task. An absent owner or undefined rules are problems technology will not solve — it will entrench them.

Step 2. Name the number that has to change

Before anything is built, write one sentence in the form: “Today this figure is X. After the implementation it should be Y.”

The number must be measurable today, before the project starts. That sounds trivial and is regularly the hardest step in the whole exercise: it very often turns out nobody knows how long handling one case really takes, or how many come back for rework. If that is your position, spend two weeks measuring before going further. Without a baseline you cannot later tell a working solution from the impression that things feel better.

Avoid goals that cannot be falsified — “improve customer service” is not a goal, it is an intention. “Cut the average response time on a quote request from 26 hours to 8” is a goal, because in three months anyone can check whether it happened.

Step 3. Check the data before you build anything

There is one test and it takes an afternoon: try to export the last hundred instances of the process as a single table. Not describe how you would — actually do it.

Whatever you run into during that attempt is the real scope of the project’s first stage. If the data sits in one system and the export takes fifteen minutes, you are in a good position. If it is scattered across mailboxes, scans and spreadsheets on local drives, you have just seen where the first — and often largest — part of the budget goes. That cost is not wasted, but it does surprise people, because nobody calls it “implementing AI”.

While you are there, establish whether that data includes personal data and, if so, who the controller is. That single fact changes the scope of the project more than the choice of model does; we cover it at length in our note on security and GDPR.

Step 4. Decide where the human stands in the process

This is the decision with the largest effect on cost, schedule and risk — and it is often made by accident, late, during roll-out. In practice there are three options:

• A human approves every output. The system drafts, a person accepts or corrects. The cheapest and fastest to launch, and the only one that hands you quality data about the system’s behaviour from day one.
• A human handles the exceptions. The system acts on its own where it is confident and routes the rest to a person. This requires defining what “not confident” means, and someone genuinely working the exception queue.
• A human supervises statistically. The system runs without a person in any individual case, and oversight means monitoring indicators and sampling periodically. Cheapest to operate and dearest to build, because that monitoring has to be built.

Start with the first option even when the third is the goal. Moving between them is far easier than retreating after an incident — and a few weeks of human approval yields data you cannot otherwise obtain.

A separate note: where an outcome has a significant effect on a specific person — bearing on employment, credit, or access to a service — two distinct regimes come into play, and it is worth not conflating them, because they turn on different things.

The GDPR restricts decisions taken solely by automated means where they produce legal effects or similarly significantly affect someone. The word doing the work is “solely”: where a person genuinely considers the case and could decide otherwise, the provision does not bite — though rubber-stamping, with no actual assessment, does not make a decision non-automated.

The AI Act imposes its obligations — event logging, human oversight, technical documentation — according to the system’s classification, not the weight of any individual decision. Recruitment and the creditworthiness assessment of natural persons are high-risk uses; many other uses, including a good deal of internal automation, are not. Classification has to be settled on its own terms rather than inferred from a decision feeling consequential.

What that means in practice is set out alongside our AI Act readiness audit.

Step 5. Build the narrowest version that settles the question

A pilot is not there to save money. It is there to answer whether this process and this data are suitable for automation at all — before you spend a multiple of its cost finding out.

A very practical scoping rule follows from that: a pilot should contain exactly the parts you are uncertain about, and nothing else. If you do not know whether the model will read your documents correctly, build the document reading — no integration, no interface, results in a spreadsheet. If the uncertainty is about the ERP integration, build that integration against one simple case.

Write down in advance which result you will treat as sufficient and which as disqualifying. A pilot with no defined threshold always ends in “looks promising”, and that is not a result anyone can decide on.

Step 6. Run it alongside before you run it instead

Once the solution works, let it run next to the existing process for the first few weeks rather than in place of it. People work as before, the system processes the same items in the background, and you compare.

That period is not free: every case runs through the system a second time, so the per-operation model and infrastructure charges accrue exactly as they would in production. In exchange it buys two things you cannot acquire later: a real agreement rate on your own data, and a list of the cases the system gets wrong. That list is usually the most valuable output of the whole pilot, because it tells you where the boundary actually belongs between what the system does alone and what goes to a person.

Switch to production in stages — one team first, or one category of cases. Plan how to revert if something goes wrong. If reverting is not possible, you are not ready to switch.

Step 7. Plan the upkeep before declaring success

Going live is not the end of the project, it is the start of running it. Before you call the implementation closed, settle four things:

• who looks at the results, and how often;
• how you will know quality has dropped — which indicator, and at what threshold;
• who is responsible for fixes when an integrated system changes;
• what happens when the model provider retires the version this was built on.

The last point catches people out most often. Model providers do retire older versions, and a solution built and tested against a version that stops being available has to be tested again. The provider sets the timing of that, not you — which is why upkeep belongs in the budget as a standing line rather than a margin for error. We break those costs down in our note on what an AI implementation costs.

Who needs to be in the room

Implementations rarely come apart over technology. Far more often, one of four roles was missing:

In a smaller company these roles collapse into two or three people, and that is fine. The problem is never the headcount — it is any one of those responsibilities that nobody has picked up.

In-house, off-the-shelf, or with a supplier

The order of consideration never changes, and it starts with the cheapest option:

• An off-the-shelf tool, where a product exists for your process and integrates with the systems you already run. Do not build what you can subscribe to.
• In-house, where the process can be handled without integrating internal systems and somebody on the team will maintain it. A caveat: “someone will put it together after hours” is not a maintenance plan.
• With a supplier, once internal integrations, personal data or oversight requirements are in play — that is, once the cost of getting it wrong exceeds the cost of doing it properly.

If you are considering the third route, ask for more than a price: a stage-by-stage scope, the expected monthly cost after go-live at your volume, and the conditions under which the supplier would themselves recommend stopping. A supplier who cannot name such conditions has probably not carried an implementation through to the maintenance phase before.

Four reasons implementations fail

• The scope was a category, not a process. “We’ll implement AI in customer service” has no completion condition, so the project never finishes — at some point it simply stops.
• There was no baseline. Without a number measured before the start, any discussion of the effect reduces to impressions, and impressions depend on who is describing them.
• Nobody owned the outcome after the project ended. A system without an owner degrades quietly: a document format changes, quality drops, and nobody notices for a quarter.
• The bottleneck was somewhere else. Sometimes cases are not held up because nobody is processing them, but because they are waiting on a decision, or on a form nobody fills in. Automation then speeds up the part that was never the problem.

Check that last point earliest, because it is the cheapest to verify: trace one case end to end and write down where it genuinely waited longest.

What comes next

If you have worked through steps 1–3 and have a chosen process, a measured number and a clear view of your data, you hold everything needed for a conversation about scope and cost. What such a project involves on the delivery side — the scope, the stages, and what each produces — is set out on our AI implementation page.