What Belongs in an AI Acceptance Contract

Before an AI or transformation engagement is signed, the buyer should hold an acceptance contract: testable criteria, phase gates, kill triggers and fee caps. Here is what it must contain.

Most AI engagements fail quietly. The vendor delivers what the statement of work describes, the invoices are paid, and twelve months later nobody can say whether the system works. The problem is rarely bad faith. It is that the contract never defined what "working" means.

An acceptance contract fixes that. It is a short document the buyer writes before the vendor drafts the SOW, and the vendor signs it first. It turns the outcome the buyer is paying for into tests that either pass or fail.

1. Testable acceptance criteria

Every deliverable needs a test that a third party could run and get the same answer. "Improve invoice processing" is not a criterion. "Extract vendor, amount and due date from at least 95 percent of invoices in a 500-document holdout set, measured by the buyer" is.

• Name the metric, the threshold and who measures it.
• Define the test data: a holdout set the vendor never sees during development.
• Specify the measurement protocol, including how edge cases and exceptions are counted.
• State what happens on a near miss: a cure period, a fee reduction or rejection.

2. A phase-gate plan with kill triggers

Large AI engagements should be bought in phases, with a decision point after each one. The acceptance contract lists the gates, what must be true to pass each gate, and the conditions under which the buyer can stop without penalty.

• Discovery ends with a documented baseline: current volumes, error rates and cost per transaction.
• The pilot ends with the acceptance tests run on real data, not a demo set.
• Scale-up begins only when pilot results meet the threshold.
• Kill triggers are written in advance, for example two missed gates or a data access problem the vendor cannot resolve in 30 days.

3. Fee caps that bind later phases

The most expensive clause in many engagement letters is the one that is missing: a cap on Phase 2. Vendors often price the first phase competitively and leave later phases to be scoped "based on findings." The acceptance contract sets a ceiling on later phases now, while the buyer still has leverage.

4. Ownership, data and exit

• Who owns prompts, fine-tuned models, evaluation sets and integration code.
• Where the buyer's data is processed and whether it may be used to train anything.
• What the buyer receives on exit: code, documentation, model weights where applicable, and a transition period.
• How lock-in is limited, for example by requiring standard formats and open interfaces.

5. Recovery terms

If a gate is missed, what does the buyer get back? Credits, refunds, rework at the vendor's cost, or the right to terminate and keep the deliverables paid for. Writing this down before signature is the difference between a negotiation and a dispute.

A short checklist before you sign

1. Can every deliverable be accepted or rejected by a test the buyer controls?
2. Is there a holdout data set the vendor never trains on?
3. Does each phase end in a go or no-go decision with written criteria?
4. Are later phases capped in the engagement letter, not left to future scoping?
5. Does the buyer own the artifacts it pays for, and can it leave with them?
6. Is there a defined remedy for each missed gate?

If any answer is no, the contract is describing activity, not outcomes. That is fixable, but only before signature.