AI Implementation Services: What You Actually Get

Twelve weeks, and three or four of them are yours.

AI implementation services means one thing: a supplier takes a defined business process, builds a system that runs it, connects that system to the software you already own, trains the people who will use it, and hands over the code and the documentation. For a mid-sized European company the usual shape is twelve weeks. Two weeks of audit, two of scoping, six of build, two of rollout, then a measurement window that runs after everyone has gone home. Most of that is predictable work on a supplier’s side. The part that is not predictable, and the part that decides whether the date holds, sits on yours: data access, one named person who can decide, and hours from the people who do the process today. Compare implementation quotes on what each supplier asks of you, not only on what they promise to deliver.

AI implementation is not a pilot, a proof of concept, or an AI strategy

Four different things get sold as AI implementation services, and the difference is not academic, because each one leaves you holding something else at the end.

• Proof of concept. One to three weeks. It answers a single technical question: can a model do this at all, on our actual documents, at a quality anyone would accept. It ends in a notebook, a short write-up and a demo. Nothing runs afterwards. This is the cheapest useful thing you can buy and it is frequently the correct purchase.
• Pilot. Four to eight weeks. A real system with real users, deliberately kept small: one team, one workflow, shallow integrations or none. It ends in a decision rather than a rollout. A pilot that was quietly bought as an implementation is the single most common reason a company ends the year with a working demo and no operational change.
• Implementation. Eight to sixteen weeks for most SME projects. Production access, real permissions, error handling, monitoring, training, documentation, and a person to call at 8am when it stops. The model is a component. Everything else is what you are paying for.
• AI strategy. A document. Prioritised use cases, a sequencing argument, a budget shape. Genuinely valuable when several business units are competing for the same budget, and completely inert on its own, because no strategy document has ever processed an invoice.

The price gap between a pilot and an implementation is mostly integration and operational work, not model work. That is why a supplier who quotes an implementation at pilot prices is usually quoting a pilot. We wrote about the specific ways this stalls in why AI pilots do not reach production, and the pattern there is the same one: the last 20 per cent of the work is 80 per cent of the reason the system is trusted.

The AI implementation process, five stages over twelve weeks

Read the five stages below as a checklist against whatever plan you are quoted. An AI implementation process with no measurement stage is a build rather than an implementation, and a plan that opens at week 3 is asking you to pay for a scope somebody guessed.

Weeks 1 and 2, audit. Somebody maps the process as it is actually performed, which is rarely the process as documented. They inspect the data, count the exceptions, and measure the baseline: how long the task takes now, how often it is wrong now, what it costs now. That baseline is the most valuable artefact of the whole engagement, because after go-live it is the only thing that lets you prove anything. Our audit produces a written scope and that number before any code is committed.

Weeks 3 and 4, scoping and design. Interface decisions, the integration contract for each system the work touches, an explicit list of edge cases with a stated behaviour for each, and acceptance criteria you sign. An evaluation set gets built here too: fifty to two hundred real examples with known correct answers, which is how anyone later argues about quality with evidence rather than impressions. Skipping this stage does not save four weeks. It moves them into the build, where they cost more.

Weeks 5 to 10, build. The model work is a small share of these six weeks. The rest is authentication, field mapping, retries when a third-party API returns a 503, permission rules that match your existing roles, logging that a non-engineer can read, and the fallback path for when the model is not confident. Engineers describe this as plumbing and buyers hear it as filler. It is the difference between a system that survives its first bad Monday and one that gets switched off.

Weeks 11 and 12, rollout. A parallel run, where the system and the humans do the same work side by side for one to two weeks and the disagreements get inspected. Training for the people who will use it, which takes two sessions, not one. A rollback path that somebody has actually tested. Then the switch, usually on a Tuesday, never on a Friday.

Then measurement, four to eight weeks after go-live. The same numbers taken in week 1, taken again. This is the stage that gets dropped when the budget tightens, and dropping it means the next AI proposal inside your company has no evidence behind it. Book the measurement week into the contract at signing, because nobody schedules it voluntarily two months after everyone has moved on.

What you have to supply, and where the date actually slips

Three client-side inputs sit on the critical path. When a twelve-week project lands at eighteen, the extra six weeks are usually here rather than in engineering, and no supplier can schedule around them for you.

Data access, with credentials, in a sandbox. Not a sample export. Real access to the systems the work touches, which means an IT security review, a supplier questionnaire, sometimes a data-processing agreement and a penetration-test certificate. In a company with a formal procurement function that sequence runs two to six weeks on its own, and it can start before the contract is signed. Almost nobody starts it early.

One named owner who can decide. Not a steering committee. A person who can approve an interface, settle a disagreement between two departments about what the correct answer is, and sign off acceptance without escalating. Every hour that decision waits is an hour the build is guessing. A committee will produce a decision eventually, at a cadence set by its meeting schedule, and a two-week meeting cycle inside a twelve-week project is a large tax.

Subject-matter-expert time, three to five hours a week. From the person who currently does the work, for the length of the engagement, not a single kickoff workshop. This is the input companies underestimate most, partly because that person is busy precisely because the process is manual. If they cannot be freed for three hours a week, that is a real finding, and it is worth surfacing before signing rather than in week seven. Internal capacity is one of the three inputs that also decides which type of partner you should be hiring at all.

What lands on your side, and what AI implementation cost looks like

A complete handover is a short list and you should ask for it in writing before signing: source code in a repository you own, prompts and the evaluation set, infrastructure defined as configuration rather than as somebody’s memory of what they clicked, an architecture note a new engineer can read in an hour, a runbook covering the six things most likely to break, and recordings of the training sessions. If any of those is described as available on request, it does not exist yet.

The integration surface is what moves the price more than anything else. SAP, Salesforce, HubSpot, a hospital information system, an in-house tool written in 2011 by somebody who has left: the brand matters far less than three questions. Does it expose an API, who owns the credentials internally, and is there a non-production environment to test against. A system that fails the first question turns your implementation into a data-extraction project with an AI component attached, and that is a different budget.

For AI implementation cost, a useful first project for a European SME lands between €3,000 and €50,000, and the four-tier breakdown behind that band is in our note on what AI consulting costs in 2026. Two things move a quote inside it: the number of systems the work touches, and the condition of your data. Neither is a model decision.

The LexAlert legislative monitoring platform is a reasonable picture of what the shape produces. It ingests from three official gazettes, deduplicates, summarises against a firm’s active matters, and runs unattended every three hours. Almost none of the engineering effort there was model work; it went into the ingestion, the deduplication and the alert routing, which is exactly where implementation budgets go. Our other case studies follow the same distribution.

Three situations where implementation is the wrong purchase

The process is not agreed. If two departments describe the same workflow differently, an implementation will encode one of the two descriptions and the other department will reject the system. Fix the process first. This is a two-week piece of work with a facilitator and it is far cheaper than discovering the disagreement in acceptance testing.

Nobody knows whether it is technically possible. If the question is genuinely open, buy a proof of concept for a fraction of the price, get an answer in three weeks, and then decide. A supplier who will not sell you the small version first is telling you something about how they prefer to be paid.

Nobody internally will own it afterwards. A system with no owner degrades quietly: an API changes, a prompt drifts against a new document format, an alert goes to a mailbox nobody reads. Either budget for the person alongside the build, or buy the system as a managed service and accept that you are buying a service rather than an asset. Both are honest answers. The dishonest one is assuming somebody will pick it up.