An AI assistant can draft a response in seconds and still make a service team slower. Someone has to check the answer, find the supporting policy, correct the exceptions, and decide whether it can be sent. If that work takes longer than drafting the response manually, the pilot has moved effort around without saving any.
The investment question is therefore specific: can this system improve a defined workflow at an acceptable cost and error rate? Answering it requires a baseline, a realistic evaluation set, and someone accountable for the service after launch.
Measure the whole task
Choose a workflow with a clear beginning and end. For a support assistant, measure elapsed time to a correct resolution, including retrieval, review, correction, and escalation. Separate routine requests from unusual ones. An average improvement is not enough if the system makes the highest-risk cases harder to handle.
Calculate cost per accepted result. Include inference, retrieval, monitoring, human review, and the cost of rework. Test at the expected peak volume. A demonstration with a handful of users tells you little about queueing, rate limits, or the support capacity required for a wider rollout.
Make the release decision testable
Build an evaluation set from representative work, with appropriate controls for sensitive data. Include incomplete requests, conflicting documents, expired policies, and cases the system should decline. Keep a held-out set so prompt tuning does not quietly become memorization of the test cases.
A fluent response is not evidence of a correct response. Define what a reviewer must verify and what counts as a material error. For systems that retrieve documents, test whether the cited passage supports the answer and whether the user is entitled to see it. An aggregate quality score can conceal a permissions failure.
- Compare with the current workflow and a simpler automation option.
- Agree which errors block release, regardless of the average score.
- Record model, prompt, and retrieval versions for each evaluation.
- Set a fallback for unavailable services and uncertain answers.
Fund the service after the pilot
Google Research’s ML Test Score treats production readiness as a broader testing and monitoring problem. That distinction remains useful for generative AI: a successful experiment does not establish that the surrounding system can be operated reliably.
Name the team that will respond when quality drops, a source document changes, or a provider updates a model. Give that team a release process and a way to roll back. Begin with bounded assistance where people can inspect the output; extend autonomy only when task-level evidence supports it.
Before the next funding decision, ask for three artifacts: a baseline comparison, an exception log, and the operating cost at expected volume. Together, they make a stronger case than a collection of impressive example responses.
THE PRACTICAL TAKEAWAYScale when the complete workflow improves, including the time and cost of checking what the AI produces.