AI consulting contracts: what to include

Standard consulting agreements were not written with this work in mind. They handle fees and confidentiality competently and say nothing useful about who owns a prompt, what happens to your customer data, or who is responsible when a system tells a customer something wrong.

This is not legal advice and you should have somebody qualified look at anything you sign. It is a list of the places AI engagements actually go wrong.

Deliverables described as artifacts, not intentions

"Strategic roadmap" is not a deliverable, it is a genre. Write down what physically arrives: a written document, a prioritized list with estimates attached, named build-or-buy recommendations, a sequence with dates.

The test to apply: could a competent third party execute this without the author in the room? If the deliverable definition does not require that, you can receive a presentation and have received what you agreed to.

Acceptance criteria and a review window

How do you establish the work is done? Vague completion is how disputes start.

For a diagnostic engagement, a review period during which you can raise gaps is usually enough. For a build, you want defined behavior: it handles these cases, escalates those, does not do these things. Which requires somebody to write down what "working" means before construction starts, and that exercise is valuable regardless of the contract.

Who does the work, by name

The commonest bait and switch in all of consulting. You meet a senior person, you sign, and delivery goes to somebody far more junior.

Name the individuals and put a clause on substitution: you get notice, and you get a say if the replacement is materially less experienced.

Data: where it goes, who touches it, what is retained

The clause standard templates handle least well and the one with the largest downside.

Specify which systems the supplier may access and at what permission level. Specify where your data is processed and stored. Specify whether any of it goes to third-party model providers, because in most AI work it does, and you should know which ones and under what terms. Specify retention: what is deleted at the end, and when.

And specify, explicitly, that your data is not used to train anybody's models. This is worth stating even if you assume it, because assumptions are not terms.

Confidentiality that survives the engagement

Ordinary, but check it covers the operational detail rather than just documents. In this work a supplier learns how your business runs, which is more sensitive than any single file they see.

Intellectual property, including the configuration

Say who owns the deliverables, the code, and the configuration. That last word is the one to insist on: in AI work the prompts, rules, escalation conditions, and thresholds are the product, and they frequently live only inside a platform the supplier administers.

Decide whether you own it or hold a license, and if it is a license, know what happens to it when the relationship ends. Do not accept "our prompts are proprietary" without understanding that it means the thing running your operation is not yours.

Accounts and infrastructure in your name

Put it in the agreement rather than trusting it to setup convenience. Third-party services the solution depends on should be registered to you, billed to you, with administrator access your side.

This single provision does more to protect you than any exit clause, because it means leaving is possible in the first place. The full anti-lock-in list.

Exit terms, agreed while everyone is happy

What you receive on termination, in what format, within how many days, at what cost. The cost should be nothing.

Watch the notice period against the term length. A long commitment with a narrow exit window is a lock-in device regardless of what the rest of the document says. And put a break point after the diagnostic phase, so you can stop before the expensive half with a clean conscience.

Liability, scoped to what AI actually does

Standard templates cap liability and stop there. Worth thinking a step further: these systems talk to your customers, and they will occasionally produce something wrong.

Agree in advance which categories of output require human review, so responsibility is allocated by design rather than argued about afterward. Anything involving money, legal commitments, safety, or a promise you have to honor should be on that list. Do not expect a supplier to accept unlimited liability for model behavior, and do expect them to have thought about the boundary.

What we would add

Two things not in most agreements and worth putting in yours.

A milestone that depends on documentation. Handover material is the most promised and least delivered item in this field, and attaching a payment to it is the only mechanism that reliably works.

A review date after the work is live. Three months out, somebody checks whether the ownership and maintenance arrangements you agreed are happening. Costs nothing and it is what stops good work drifting into irrelevance.

Our own structure keeps the diagnosis and the build as separate decisions with the roadmap yours either way, which is on the consulting page. A client who negotiates hard on the list above is a client we would rather have, because the alternative is discovering the disagreement in month eight.