Implementation

AI Implementation in Business: A Practical Playbook

An AI implementation is not a technology project with a business case attached. It is a business project that happens to use AI, and the order of work decides the outcome long before the model does. What follows is the sequence, the numbers, and the questions that separate implementations that pay from implementations that demonstrate.

Companies that begin an implementation with the technology spend a quarter producing something impressive that nobody uses. Companies that begin with a repeating, expensive decision produce a number they can defend in a management report. The difference is not budget or talent. It is sequence.

Implementation starts with a repeating cost, not a technology

The first artefact of a serious implementation is not an architecture diagram or a model comparison. It is a shortlist of processes that share three properties: they repeat at meaningful volume, they consume expensive time or produce expensive errors, and their outcome is already recorded somewhere in your systems.

AI economics are per-unit: a process running eight times a month cannot repay integration work, however painful each instance feels. Traceability matters most and is ignored most often — if the outcome is not recorded anywhere, you cannot prove the effect afterwards, and the project will be judged on impressions.

Four questions rank candidate processes quickly:

• Frequency. How many times per month does this happen? Hundreds and thousands are the interesting range.
• Unit cost. How much qualified human time does one instance consume, end to end, including the waiting and the rework?
• Error cost. What does one wrong outcome cost — a lost order, a penalty, a re-done delivery, a churned client?
• Traceability. Is the result of each instance written down in a system, or does it live in someone's inbox and memory?

A process that scores high on frequency and cost but low on traceability is not disqualified. It means the first weeks of the project go into instrumentation, and the plan should say so rather than discover it in week five.

The five stages of an implementation

1. Assess processes and data

This stage answers two questions: how the work is actually done, and whether the data required to do it automatically exists in a usable form. Both are field questions, not workshop questions. The documented process and the real one differ in almost every company, and the gap is usually where the cost sits.

On the data side, the practical test is not whether a database exists. It is whether the information a competent employee uses to make the decision is machine-readable, complete enough, and accessible without a three-month permissions negotiation. Scanned PDFs, knowledge held in a senior manager's head, and fields filled in inconsistently across three years are the normal findings — solvable, but schedule and budget items.

2. Choose exactly one scenario

The output of assessment is a single scenario, described narrowly enough to be built: this process, these inputs, this output, this system, this user. Programmes that start with three parallel use cases finish none of them, because attention and integration effort are the scarce resources, not model capacity.

A well-specified scenario states what the system will not do. Boundaries are what make evaluation possible: a system that handles four request types well and refuses the fifth is deployable, while a system that attempts everything at uncertain quality is not.

3. Run a pilot with a measurable result

The pilot exists to produce evidence, not a demonstration. That requires a test set built from real historical cases with known correct answers, a quality threshold agreed before the build, and a comparison against how the process performs today.

Two rules keep pilots honest. Real data, not curated samples — the messy cases are the ones that decide whether the system works. And a defined failure condition: the criteria under which the project stops, stated in advance. A pilot that cannot fail is a marketing exercise.

4. Integrate into working systems

A pilot that lives in a separate interface has proven capability but not value. Value appears when the output lands where the work already happens: the CRM record, the ERP document, the ticket queue, the messenger the team uses. This stage is conventional software engineering: API integrations, permissions, error handling, logging, fallback to a human when confidence is low.

It is also where most unplanned effort appears, because integration exposes every earlier assumption about data quality and process boundaries. Budget it as a stage, not a final week.

5. Operate

An AI system is not a build-once asset. Inputs change, processes change, model versions change, and quality drifts quietly rather than failing loudly. Operation means a named owner, a dashboard showing quality and volume, periodic re-evaluation against the test set, and a route for users to flag bad outputs that leads to an actual fix.

How to measure the effect in money

The measurement problem is almost always a baseline problem. After go-live nobody can reconstruct what the process cost before, so the discussion collapses into opinion. Fix the baseline while the process is still manual.

Four numbers, recorded over a representative period before anything is built:

• Volume. Instances per month, with seasonality noted.
• Cycle time. Elapsed time from trigger to completed outcome — not the time someone is actively working, the full duration.
• Labour cost per instance. Active minutes multiplied by loaded hourly cost, including review and rework.
• Quality. Error rate, rework rate, or escalation rate, measured the same way it will be measured afterwards.

Then express the effect in the currency the business already uses. Hours saved are an intermediate metric, not a result: they become money only as headcount not hired, capacity redeployed to revenue work, faster cash collection, or fewer paid errors. State which conversion applies before the project starts, and have finance agree to it. An implementation that saves hundreds of hours a month in a team that hires nobody and sells nothing more has produced a statistic.

Keep the ROI calculation conservative and full-cost: build, integration, licences, and twelve months of operation against the measured effect, with the pre-existing process as the comparison rather than an idealised alternative.

What the cost is actually made of

The model is rarely the main line. In most business workloads the API spend is a small, predictable operating cost, while the budget is dominated by the work around it:

• Data and access. Locating sources, cleaning inconsistencies, resolving permissions and legal review. Routinely the largest and most underestimated item.
• Integration. Wiring the system into CRM, ERP, ticketing and identity, with error handling and audit logging.
• Quality evaluation. Building the test set and the measurement harness. Skipping it does not remove the cost; it relocates it to production, where mistakes are more expensive and more visible.
• Iteration. The distance between works in a test and works on real inputs, measured in rounds of refinement.
• Operation. Monitoring, re-evaluation, model and prompt updates, support. Modest against the build, but never zero.

Treating an AI project as a one-time capital expense is the most common budgeting error: a proposal that quotes development only is quoting the beginning of the cost.

Realistic timelines

Four to six weeks is enough to assess a process, prepare a test set, build a working pilot on real data, and measure quality against the current baseline. That is a genuine decision point: continue, adjust, or stop.

What does not fit into six weeks: integration into a regulated core system, migration of unstructured archives, anything requiring new data collection that does not exist yet, organisation-wide rollout with training and change management, and formal security or compliance review in a large enterprise. Those are quarters, and compressing them produces a pilot that never reaches production.

A workable rhythm is six weeks to evidence, one to two months to production integration for one scenario, then expansion on infrastructure already paid for.

Why implementations fail

The failure modes are consistent and predictable:

• Started from the technology. A tool was selected first, then a use case was found for it. The use case is usually the wrong one.
• No process owner. No manager whose numbers improve when the system works. Without that person, adoption does not happen and nobody defends the budget.
• No way to measure quality. Without a test set and a threshold, good enough becomes a matter of taste and the project cannot be approved for production.
• The pilot was never connected to real systems. Impressive in a demo, orphaned in practice, and the integration cost surfaces after the budget is spent.
• Operation was not planned. The system launches, degrades over months, and quietly stops being trusted.
• Baseline never captured. The effect is real but unprovable, so the next round of funding does not come.

Choosing a vendor

Vendor selection is easier when the questions are about method rather than technology. Useful ones:

• How will we measure quality, and what threshold do you propose before the build starts?
• What will you need from our data, and what happens if it turns out to be incomplete?
• Which of our systems will this write to, and who owns the integration work?
• Under what result would you recommend stopping this project?
• What does year two cost us if nothing new is built?
• Who operates this after handover, and what does our team need to be able to do?

A vendor who answers with model names is selling a component. One who answers with process, measurement and boundaries is describing an implementation. Be equally attentive to what they refuse: a specialist willing to say a scenario does not justify its cost is worth more than one who agrees with everything.

What must remain with the company

Ownership is decided in the contract, not at handover. Three things should be yours without negotiation: the source code and configuration, including prompts, evaluation sets and integration logic; the data, in exportable form, along with anything derived from it; and the infrastructure — systems running in your cloud accounts, under your credentials, with your team holding administrative access.

The practical test is exit cost. If the vendor relationship ended next month, could the system keep running and could another team maintain it? If the answer depends on a proprietary platform, an undocumented environment, or accounts you do not control, the project has purchased a dependency rather than an asset.

The short version: find a process that repeats and costs money, record what it costs today, build one narrow scenario to measured evidence in six weeks, integrate it where the work actually happens, fund its operation, and keep the code, the data and the infrastructure. The technology decisions are downstream of all of it, and they are the easy part.

AKVANT Technologies is an AI consulting and engineering firm. We work with companies to find where AI pays off — and build only there.