The most expensive sentence in a contract for AI consulting services is usually the one that is missing. Buyers negotiate hard on day rate, on timeline, on the number of senior engineers named in the statement of work, and then sign a document that never says who owns the trained model, who holds the training data, or what happens the first time the system's accuracy drifts. Six months later the pilot works, the consultants have rolled off, and nobody inside the company can retrain the thing.
That gap is not the result of bad faith on either side. It is the result of a market that grew faster than its own paperwork. Stanford's Human-Centered AI institute has tracked the surge in corporate adoption in its annual AI Index Report, and McKinsey has run its State of AI survey through the same period. Both point at the same shape: plenty of organisations have deployed something, far fewer can show what it returned. Ownership is one of the reasons why. A system you cannot maintain stops producing value the moment the people who built it leave the building.
This is a guide to the handover side of AI consulting services, written for the person signing the purchase order rather than the person writing the code. It covers the four things worth settling before work starts, the questions that change a proposal when you ask them early, and what a competent firm will volunteer without being pushed.
One invoice, three very different endings
Sold under the single label of AI consulting services, an engagement can finish in one of three states, and the difference is worth more than the fee.
In the first, you own a working system and the ability to operate it. The code is in your repository, the model weights or the fine-tuning configuration are in your storage account, the data pipeline runs on infrastructure you pay for directly, and two of your own engineers have shipped a change to it under supervision before the engagement closed. The consultancy could vanish tomorrow and the system would keep running.
In the second, you own a working system and nothing else. The code was delivered, but it deploys through a pipeline the firm built on its own tooling, the model was trained in an account you do not control, and the only documentation is the slide deck from the final readout. The system runs until it does not, and the only people who can fix it send an invoice.
In the third, you own a report. This is more common than the industry admits, and it is not always a failure. A genuine assessment engagement that tells a company not to build something has earned its fee. The failure is paying assessment prices for what you believed was a build.
| Ending | What you hold afterwards | What it costs you later |
|---|---|---|
| Operable system | Code, data, model artifacts, deployment path and a team that has shipped a change to it | Your own maintenance hours, and a firm you can re-hire by choice |
| Dependent system | A running system on tooling and accounts you do not control | A retainer you cannot competitively bid, priced by the only firm that can do the work |
| Report only | A recommendation, a roadmap and no working software | A second procurement round, unless the report was what you bought |
Which of the three you end up with is decided in the statement of work, not in the final month. If you are still comparing firms, the questions in our guide to what to ask before hiring an AI agency are the place to start, and our first-time hiring checklist covers the procurement mechanics around them.
The model is not the deliverable
Buyers tend to picture the trained model as the thing they are purchasing, in the way a building is the thing you purchase from a contractor. The comparison breaks down quickly. A trained model is a snapshot of a dataset at a moment in time, and its value decays as the world it was trained on moves. What you actually need to own is the ability to produce the next model, which is a different asset made of different parts.
That asset has four components, and a contract should name all four:
- The training pipeline. The code that takes raw data and produces a candidate model, including the feature engineering, the preprocessing and the evaluation suite. Without the evaluation suite you cannot tell whether the next model is better or worse than the current one.
- The training data, and the right to keep using it. If any part of the dataset was licensed, purchased, scraped or supplied by a third party, the agreement should say what happens to that right when the engagement ends.
- The model artifacts themselves. Weights, adapters, fine-tuning configurations, prompt templates, retrieval indexes. Stored where you can reach them, not only where the consultancy can.
- The deployment path. How a new model gets from a laptop into production, and who is allowed to push the button.
A firm that builds custom systems for a living will have an opinion about each of these before you raise them. A firm that hesitates on the second one is telling you something useful about how the dataset was assembled.
Who holds the keys to the data
Ownership of data is rarely the contested point. Almost every reputable firm will agree in writing that your data remains yours. The contested point is access, and access is what decides who holds the upper hand two years in.
Three arrangements are common. The consultancy works inside your cloud account under credentials you issue and can revoke, which is the cleanest and the one to ask for. The consultancy works inside its own environment and your data is copied there for the duration, which is workable if the contract sets a deletion date and names who confirms it. Or the consultancy works inside a shared platform it operates for several clients, which can be perfectly well run and is still the arrangement that leaves you with the least recourse if the relationship sours.
Ask where the data will physically sit, ask who at the firm can read it, and ask what the offboarding procedure is. The answer to the third question is the one that separates firms that have offboarded clients before from firms that have not.
Regulated industries add a further layer. If you operate under sector rules covering personal data, financial records or clinical information, the contract needs to carry those obligations down to the consultancy and to any subprocessor it uses. Our notes on what belongs in an AI agency contract go through the clauses in more detail.
Retraining is a cost, not a courtesy
Every AI system built on real-world data degrades, and no contract for AI consulting services repeals that. Customer behaviour shifts, product catalogues change, the upstream vendor updates its API, a model provider deprecates the version you fine-tuned against. None of that is a defect in the original work. It is the ordinary weather of running a model in production, and it costs money every year.
Most proposals for AI consulting services price the build and treat the running of it as a conversation for later. Push that conversation forward. Before signing, get a number for what it costs to keep the system honest for twelve months: monitoring, periodic re-evaluation, retraining when the evaluation says so, and the engineering hours to ship the retrained model. If the firm cannot produce that number, it has either not run a system in production before or it is hoping you will not ask until you are locked in.
The number itself is less important than what it does to your comparison. A build quoted at one price with a heavy annual maintenance tail can easily cost more over three years than a build quoted higher with a genuine handover. Our breakdown of what AI agency work actually costs sets out the ranges across the common engagement types.
The runbook nobody asks for
The single cheapest thing you can add to a statement of work is a named operational document, delivered before final payment, that a competent engineer who has never seen the project could follow.
It should cover how to run the training pipeline end to end, how to read the evaluation output and what each number means in business terms, the failure modes the team hit during the build and how they resolved them, the thresholds at which someone should intervene, and the escalation path when the model produces something it should not. Ask for it as a deliverable with acceptance criteria, not as a line in the closing deck.
Firms resist this less often than buyers expect. Writing it is a day or two of work, and a firm that intends to win the maintenance contract has an interest in the system being legible. The firms that resist are usually the ones whose margin depends on being the only people who understand what they built.
Pair the runbook with a transfer session that is a working session rather than a presentation. Your engineers should make a real change, run the evaluation, and deploy it while the consultancy is still on the clock and still liable. A handover nobody has rehearsed is a document, not a handover. The same principle drives the comparison in our piece on AI integration with an agency versus in house.
Six questions that change the proposal
Ask these before the second meeting, and the proposals that come back will be more honest and easier to compare.
- At the end of this engagement, which of the three endings above are we buying? Ask them to answer in those terms.
- Where will the model artifacts live, in whose account, and who can delete them?
- What does it cost to keep this running for twelve months after you leave?
- Which parts of the training data are not ours, and what happens to our right to use them?
- Name a client whose team took over operating what you built. What did the transfer look like?
- If we wanted to move this to another firm in eighteen months, what would that firm need from you?
The sixth question is the one worth watching. A firm confident in its work answers it directly, because it expects to win on results rather than on friction. A firm that treats it as a hostile question has told you how the relationship ends.
Where to start looking
There is no single right kind of firm selling AI consulting services, and no ranking that settles it for you. A strategy-led consultancy is the right call when the decision itself is unresolved and the risk is building the wrong thing. A delivery-led engineering firm is the right call when the decision is made and the risk is the build. A data science specialist is the right call when the hard part is the model rather than the system around it. What matters is that the firm you pick is honest about which of the three it is, and that the contract reflects it.
The directory sorts firms by exactly that distinction. Browse AI strategy and consulting firms when the question is what to build, machine learning and data science specialists when the model is the hard part, and AI integration firms when the work is connecting a model to systems you already run.
If you would rather describe the problem once and have suitable firms come to you, tell us what you are trying to build and we will point you at the agencies in our directory that match the work. It costs nothing and there is no obligation to hire anyone.
Buy AI consulting services on the terms of the handover rather than the terms of the invoice. Settle ownership before you settle price. The firms worth hiring will respect you for asking, and the ones that flinch have saved you a year.
Sources
- Stanford Institute for Human-Centered Artificial Intelligence, AI Index Report, annual.
- McKinsey & Company, The State of AI, annual survey.