How to write acceptance criteria for an AI implementation pilot

Choose a narrow outcome with a named owner. “Improve operations with AI” leaves too much room for a successful demo that changes nothing. “Prepare a source-linked draft record for a reviewer” gives the team a concrete output to inspect.

Specify where the workflow begins and ends. Does it begin when an email arrives, when an approved form is submitted, or when an operator starts a job? Does it end at a draft, an approved record, or a verified update in another system?

Write the exclusions beside the outcome. If external sending, payment, or deletion is outside the pilot, say so. Those boundaries should be enforced in the available tools and permissions, not left as a paragraph in the project document.

The acceptance owner should be someone who understands the operational result. Engineering can establish that the code ran; the process owner needs to establish that the output is usable.

List the input formats, required fields, source systems, and volume assumptions the pilot supports. Include the conditions that make an item ineligible.

A document workflow might support a particular digital form and explicitly route unreadable scans to manual handling. That can be a useful first release if the boundary is visible. It becomes misleading when the demo is described as handling all documents.

Create representative test cases before tuning the implementation. Include ordinary cases, difficult valid cases, and inputs that should be rejected or deferred. Keep some cases separate from development examples so the team can check whether improvements generalize beyond the material used to build the workflow.

Document how the sample was selected. A convenient handful of clean examples can establish that the basic path works, but it cannot establish performance across the full operating workload.

A criterion should name the trigger, expected result, and evidence. For example: when a required identifier is missing, the workflow creates a review item and makes no destination write. The evidence is the review record and the destination's unchanged state.

Avoid criteria based only on what the agent says. A message claiming that a record was created is not proof that the record exists.

Anthropic's evaluation guidance distinguishes the recorded interaction from the final state of the environment and describes repeated trials for variable model behavior. That is a useful foundation for checking both what the system attempted and what actually happened. Anthropic evaluation guidance

For each criterion, identify the checker: deterministic assertion, human review, or another bounded evaluation method. A subjective writing-quality review and a duplicate-record check should not use the same vague pass label.

The pilot can have graded quality measures, such as the share of extracted fields accepted without correction. It should also have explicit prohibited behaviors, such as writing to an unauthorized account or sending an unapproved message.

Agree which failures stop release regardless of the average score. A strong average extraction result does not compensate for a permission failure. The criteria should make that decision visible before the team is invested in shipping.

Test denied actions directly. Give the workflow an input that asks it to exceed its scope and verify that the protected action does not occur. Test the tool layer and destination state, not just whether the response contains a refusal.

Also test stale approval. If the payload changes after review, the old approval should not authorize the new action. That behavior is easy to miss in a demo that uses one uninterrupted happy path.

A pilot should explain what happens when a connector times out, a provider rate-limits requests, or a destination accepts a write but the response is lost.

Define what is retried automatically, what is held for review, and how duplicate effects are prevented. An operator should be able to identify the affected business case and its last known state.

Write an acceptance case for recovery. Interrupt the workflow at a consequential point, then follow the runbook. The expected result should include the final business state and the absence of unintended duplicates.

A recovery procedure that only the developer can perform is a limitation to record. The pilot may still be useful, but it should not be described as ready for independent operations until the handoff has been tested with its owner.

Set a measurement window and identify which costs are included. Model usage is only one component; review, retries, extraction, infrastructure, and operating effort can matter.

Distinguish elapsed completion time from active work time. A workflow waiting for a person can have low compute latency and a long business turnaround. Both may be relevant, but they answer different questions.

Use accepted outcomes as one denominator, and report unresolved cases separately. A system that completes easy cases cheaply while abandoning difficult cases should not receive an unqualified cost-per-case claim.

Any target should be agreed using the actual process and available evidence. Avoid copying a percentage from another company's case study and treating it as a commitment for this implementation.

Record the application version, model configuration, relevant rule versions, test inputs, and results. Protect sensitive test material and use synthetic or sanitized data where appropriate.

When a change fixes one failure, rerun the relevant cases and a stable regression set. Otherwise, the team may improve a narrow example while breaking behavior that previously worked.

Review failed cases individually before summarizing them. A configuration error, an ambiguous requirement, and a model limitation need different responses. The acceptance report should preserve those distinctions so the next decision is actionable.

If a human grades output, provide a rubric and examples of acceptable and unacceptable results. Check disagreements rather than averaging them away without understanding why reviewers differ.

Acceptance of a pilot should authorize a defined next step. It might permit a limited production trial, a broader evaluation, or a handoff to a staffed operating team. It should not automatically authorize every future feature or a much larger workload.

Write the rollout limits, monitoring owner, stop conditions, and rollback path. A successful test set is evidence about the tested conditions, not a guarantee that the system will never fail.

I would close the pilot with a short decision record: accepted behaviors, unresolved limitations, evidence links, operating owner, and the next approved scope. That gives both the buyer and implementation team a concrete basis for continuing.

Bring the workflow you want to improve, representative inputs, and the person who will decide whether the result is usable.