Selecting AI pilot tests with clear expected decisions
A small case plan sets expectations before an AI test. The example separates routine inputs, ambiguity and requests outside the task.
Agree the task and expected routing
A fictional software company plans an AI pilot for support messages. The AI is to suggest routing: bug, access, review or out-of-scope. Granting access, changing statuses and closing tickets remain the support team's tasks. The assessment therefore concerns the suggestion, not an automatically completed support service.
Set the expected decision with domain staff before the model output is known. If the people responsible cannot agree, clarify the rule first. The NIST AI RMF recommends documenting test conditions and assessing performance under conditions similar to deployment.
Choose example cases with different purposes
The following selection is fictional. The texts illustrate the cases; the real pilot would record approved original inputs with their language and provenance.
Case | Example message | Expected routing | Reason |
|---|---|---|---|
| The app crashes when I save a project note. |
| Clearly described failure symptom |
| Please give me access to my project. |
| Clear access request; not yet approval |
| I cannot get in. |
| Access request versus technical failure unresolved |
| Saving gives an error; I also need project access. |
| Mixed requests; this pilot expects one category per message |
| Sign up for our promotional seminar. |
| Not a support request in the agreed catalogue |
The final label does not cause deletion in this example. The selection makes different decisions visible; it proves neither case frequency nor a sufficient test dataset size. Later collection should also cover the languages, input forms and missing information actually needed.
Separate development cases from the later check
Examples used by the team to change prompts or routing rules are development cases. Reserve other cases for a later check that have not previously guided optimisation. Copies and close rewordings of the same original message should not be split across both sides as independent evidence.
Google explains how repeated use of test data and duplicates can distort machine-learning evaluation. A practical precaution follows for prompt development: known examples help diagnose problems, but a later check should include additional unseen cases. Editing a prompt is not model training.
Record results by case and error type
In a later test, record the model, prompt and test-set versions, expected routing, actual output and domain assessment. Expected manual review is an appropriate result for an unclear case. A premature definitive assignment can instead be an error.
Report routine, unclear and out-of-task inputs separately. If an error is used to adapt the solution, retain the original finding in the report; the case then serves development and checks for recurrence of the known error. A new independent check needs further suitable reserved examples. The table is a reasoned starting point for selection, not an executed test or proof of production suitability.
Sources
Read more
All articles
AI & Automation with ASES
AI assistants and automated workflows