Acceptance Criteria for AI Projects: Examples That Actually Protect You
Most AI projects fail at the end, in the argument about whether the delivered thing is the bought thing. Acceptance criteria are how you have that argument at the start, when it costs nothing - with examples you can copy.
When every proposal on the table looks perfect, the question that separates them is not "what will you build?" It is "how will we both know it worked?" A supplier who welcomes that question is worth talking to. A supplier who answers it with adjectives is telling you something useful too.
What acceptance criteria are
Acceptance criteria are the checkable conditions under which you will accept and pay for a piece of work. Not the requirements (what it should do), and not the specification (how it will do it). The test at the end: pass and it ships, fail and it goes back.
In conventional software these are often written as scenarios - given this situation, when this happens, then this must result. That format still works for AI projects. What changes is that an AI system is probabilistic: it will not behave identically every time, so "works correctly" is not a checkable condition any more. Your criteria have to say how often, measured how, on what.
Why AI work needs different criteria
A deterministic system either passes or it does not. An AI system passes 94% of the time, and the whole commercial question lives in whether 94% is good enough, who measured it, and what happens to the other 6%.
That means every useful acceptance criterion for AI work has four parts: a measure, a threshold, a test set, and an owner for the failures. Miss any one of the four and the criterion will not protect you when it matters.
Examples you can copy
These are shapes to copy, not numbers to copy. The thresholds belong to you: set them from what the work is worth and what an error costs, not from what a demo achieved.
Document processing. "On a held-out set of 200 real invoices we select, the system extracts all six required fields correctly on at least 95%. Every document below the confidence threshold is routed to a named human queue, not guessed."
An assistant or chatbot. "When the system does not know, it says so and hands over; it must not fabricate. We will sample 100 production answers each month, and any answer citing a source that does not exist or does not say what is claimed counts as a critical failure."
Research synthesis. "Every claim in the output is traceable to a source document the reviewer can open. An untraceable claim is a defect, however plausible it reads."
Performance and cost. "Nineteen out of every twenty responses arrive within the agreed time, measured over a normal working week, and the monthly running cost stays under the agreed ceiling at our actual volumes, not the pilot's volumes."
Data handling. "Client data is processed and stored only in the agreed locations, nothing we send is used to train anyone else's model, and on exit our data is deleted and the deletion confirmed in writing."
Notice what these have in common. Each one names the evidence. None of them contains the words "user-friendly", "high accuracy" or "seamless", because none of those is checkable, and an uncheckable criterion is a decoration.
The criteria that do not protect you
You will see these in real proposals: "the system will be highly accurate", "outputs will be of professional quality", "the model will minimise hallucinations". Each one fails the same test - two reasonable people could disagree about whether it was met. If a criterion cannot be failed, it is not a criterion.
The subtler trap is the right measure on the wrong data. A 95% accuracy figure demonstrated on the supplier's own test set tells you about the supplier's test set. Your criteria should name who supplies the evaluation data, and the answer should be you.
Writing yours
Start from the failure, not the feature. Ask what a bad month looks like - the wrong invoice paid, the fabricated citation in a client deliverable, the quiet cost overrun - and write the criterion that would have caught it. Then make each one measurable, agree the test set, tie the thresholds to payment milestones, and give every criterion a named owner on your side.
If you want a head start, the Acceptance Criteria Generator in our Toolkit turns four plain answers into a copy-ready set shaped exactly this way - and nothing you type leaves your browser.
And keep the list short. Five criteria that everyone understands and one person owns will protect you better than forty that nobody reads. The verification debt still has to be paid by someone; acceptance criteria are how you decide who, in writing, before the invoice arrives.
One honest caveat: acceptance criteria protect the project you scoped. They cannot rescue the wrong project. If you are not yet sure the process is worth automating at all, that question comes first - the AI Opportunity Mapper exists for exactly that, and comparing supplier promises line by line is what the proposal comparison guide is for.
Related Articles
When Every Proposal Looks Perfect
You are evaluating five AI vendors and every proposal is immaculate, and you cannot tell them apart. That uniformity is the market telling you the signal you relied on has died. AI made polish free, so polish stopped meaning anything. Here is what is still expensive to fake, and what to demand instead.
Using AI to Compare Vendor Proposals: Where It Helps and Where It Doesn't
Mozart's string quartet still takes twenty-five minutes. A finance director's judgement still cannot be hurried. But everything around the decision can be compressed. A £15M procurement, 1,200 pages of supplier documentation, and what context-first AI actually surfaces.
The Verification Debt Nobody Budgeted For
The agent worked in the demo. The bill arrives in month four. Verification debt, comprehension debt, and operational debt are the three categories of operational cost that nobody budgeted for. Practitioners are talking about them constantly. Buyers are not.
The Hidden Costs in Your Vendor Proposals
We found £200,000 hidden in a vendor proposal - not through negotiation, but by understanding what normal looks like in the industry and spotting what was missing.