Buyer guide
What an AI implementation partner does, and how to scope one
An AI implementation partner owns the path from a working model to a system your team runs alone. Digiton scopes that work in Europe as one problem, a named owner on both sides, and a handover.
Advisory, build, managed service. Three contracts, three failure modes
Almost every disappointing AI engagement is a mismatch between what was bought and what was needed. The three shapes on the market are genuinely different products.
| Engagement | What you are buying | What goes wrong |
|---|---|---|
| Advisory | A decision. Which problem, which approach, what it is worth, what it would cost. | The deliverable is a document, and the document assumes a team that can build from it. If you do not have that team, you have bought a plan you cannot execute. |
| Build | A system in production against one defined problem, handed to your team with the runbook. | Scope drift, and a handover that never happens because nobody named the receiving owner at signature. |
| Managed service | Someone else runs it, indefinitely, against an availability commitment. | The capability never moves inside. Two years later the exit costs more than the original build. |
A partner is usually the middle one with a defined end. Digiton scopes build work with an exit written into the statement of work, because the alternative is a dependency that quietly becomes a managed service nobody chose.
What a scoped statement of work actually names
If a proposal is missing any of these, the gap will be filled later by whoever is loudest in the room.
- One problem, stated as a decision or a task. Not a technology and not a department. "Classify inbound supplier invoices and route the exceptions" is a scope. "AI for finance" is a budget line.
- The success test, written before the build. An evaluation set with the right answers in it, agreed by the people who will judge the output. Numbers that come after the build are marketing.
- Named owners on both sides. One person who can approve, and one who will run the thing afterwards. The second name is the one most proposals leave blank.
- The systems it touches, and who grants access. Access is the most common cause of a slipped date, and it is never a technical problem.
- What happens to the code and the data at the end. Ownership, repository, model weights where they exist, and the deletion path.
- The exit. What is handed over, to whom, and the date after which the partner is no longer in the loop.
The handover artefacts
Five things. A handover that is a meeting rather than a set of files is not a handover.
- The runbook. How to restart it, how to change a prompt or a rule, what the alerts mean, and the three failures that have already happened with what was done about each.
- The evaluation set. The cases with agreed correct answers, plus the score the system holds today. Without this, your team cannot tell an improvement from a regression, and every future change becomes a debate.
- The access map. Every credential, service account, key and integration, with the owner and the rotation path. This is the artefact that decides whether the exit is clean or a six-week archaeology project.
- The decision log. What the system did, on what input, and what a human changed. Article 26(6) of Regulation (EU) 2024/1689 sets a six-month floor for deployers of high-risk systems, and the log is also the only way to debug a system whose behaviour depends on data you no longer have.
- The on-call path. Who gets paged, at what hour, and what they are allowed to switch off without asking.
Five questions that separate a partner from a supplier
Ask these on the first call. The answers take a minute each and they sort the field faster than a proposal does.
- What is running in production right now that you built, and who operates it? A live system with an operator named is the only claim that cannot be staged.
- What does the handover contain, and on what date does it happen? A partner answers with a list and a date. A supplier answers with a phase.
- Which of your last five projects did you turn down or stop, and why? A firm that has never stopped a project has never had an opinion about scope.
- Who is my named owner, and will that person still be here in six months? Team churn during a build is the quiet killer, and it is a fair question to ask directly.
- How do I leave? Ownership of the code, the data and the model artefacts, the notice period, and what the first month without you looks like.
Digiton's own answer to the first one is a live system operated on a named on-call path, and average deployment across engagements is 45 days from signed scope to production. The right response to any of these is a specific one, from any firm you are considering.
Europe changes the scope, and it does it early
The same build in the same industry is a different piece of work here, and the difference lands in week one rather than at launch.
Lawful basis and retention are decided before the first record is processed, which shapes the data model. Article 50 transparency applies to systems people interact with, which shapes the interface. Article 26 of the AI Act puts human oversight, monitoring and log retention on the deployer, which is you and not your partner, so the oversight step has to be built into the system rather than promised in a policy. A partner that treats all of this as a legal review at the end is going to reopen the architecture. Ask when compliance work starts, and the honest answer is the first week.
When an internal team wins
Three cases, and they are common enough to say plainly.
You already have engineers who ship to production and the problem is close to what they build every day. Bringing in a partner buys you weeks and costs you the context they already hold.
The problem is not yet agreed. Two directors want different things and a supplier will build whatever the person paying describes. Settle it internally, then buy.
The system will change weekly and forever. Anything living inside a product roadmap belongs to the team that owns the roadmap. A partner is the right call for a first production system, a capability the team has not built before, or a deadline that will not move.
Frequently asked questions
What is the difference between an AI consultant and an AI implementation partner?
A consultant sells a decision and leaves you a document. An implementation partner owns the build and the handover, and the contract names what is delivered, to whom, and on what date the partner steps out. The two are worth buying separately when the problem is not yet agreed.
What should an AI implementation statement of work contain?
One problem stated as a decision or a task, an evaluation set agreed before the build, named owners on both sides, the systems it touches and who grants access, what happens to the code and data at the end, and the exit date.
What should a handover include?
The runbook, the evaluation set with its current score, the access map, the decision log and the on-call path. A handover that is a meeting rather than a set of files is not a handover.
How long does an AI implementation take?
Digiton's average across engagements is 45 days from signed scope to a system running in production. The variable is rarely the model. It is access to the systems the AI has to read and write, which is why access ownership belongs in the statement of work.
Does working in Europe change the scope?
Yes, and it changes it in the first week rather than at launch. Lawful basis and retention shape the data model. Article 50 transparency shapes the interface. Article 26 of Regulation (EU) 2024/1689 puts human oversight, monitoring and log retention on the deployer, which is the buyer, so the oversight step is built into the system.
When should we build with an internal team instead?
When your engineers already ship to production and the problem is close to their daily work, when the problem is not yet agreed internally, or when the system will change weekly and forever. A partner fits a first production system, a capability the team has not built before, or a fixed deadline.
Related
Ready to put AI to work?
Book a discovery call and we will map the highest-value AI agents and automations for your business.
Book a discovery call