Start with one decision, not a general AI trial
A useful pilot answers a decision such as: should this team use this tool for first-pass customer-email drafts? “Explore AI” is not a testable objective. Choose one repeated task with a clear owner, enough examples to compare and a result a person can accept or reject.
Write down the current process before introducing the tool. Record how often the task occurs, how long it takes, common errors, who reviews it and what a failure costs. That baseline prevents a polished demonstration from being mistaken for a measured improvement.
Week 1: define the test and protect the data
Select 30 to 50 representative examples. Include routine work, difficult cases and examples that previously caused errors. Do not use personal, confidential, customer or regulated information until the organisation has approved the data pathway.
Define success in observable terms. Suitable measures can include completion rate, factual accuracy, time to an accepted result, rework, customer impact and total cost per completed task. Set a minimum acceptable result and a stop condition before testing begins.
The Office of the Australian Information Commissioner recommends, as a matter of best practice, not entering personal information, particularly sensitive information, into publicly available generative AI tools. Privacy obligations depend on your organisation and circumstances; check the OAIC guidance linked below.
Review the product terms and configuration. Confirm where data is processed, how long prompts and outputs are retained, whether they can be used to train models, which administrators can access them and how an incident is reported. Record the model and product tier because consumer and business offerings can have different controls.
Week 2: run a controlled comparison
Ask the same staff to process comparable examples with the current method and the proposed AI-assisted method. Keep instructions stable enough to compare results. If prompt design changes during the test, record the version so an improvement can be traced to the change.
Do not measure only the time taken to generate an answer. Measure the time until a person accepts the finished work. Include prompt preparation, checking sources, corrections, formatting, retries and escalation. An answer generated in seconds can still be expensive if it takes ten minutes to verify.
Use a simple assessment sheet for every example:
- Was the task completed?
- Was the result factually and operationally correct?
- How many minutes of human review and correction were required?
- Did the output create a privacy, security, fairness or customer risk?
- Would the reviewer use the result without knowing which method produced it?
Week 3: test failure and oversight
Deliberately test boundary cases. Give the system incomplete information, conflicting instructions and requests outside the intended scope. Check whether it invents details, ignores restrictions or produces confident language when evidence is missing.
Confirm that staff know when to stop and escalate. A human approval step is meaningful only if the reviewer has time, authority and information to reject the output. Avoid designs where a person is nominally responsible but sees only a final answer with no supporting evidence.
For connected tools or agents, test access separately. Give the pilot the least privilege necessary, separate read and write permissions and require explicit approval before consequential external actions. Review logs to ensure the organisation could reconstruct what happened after an incident.
Week 4: calculate value and decide
Calculate cost per accepted result. Include subscription or API charges, implementation time, staff review, corrections and ongoing administration. Compare the result with the baseline and show the range, not only the average. A workflow that saves time on ordinary cases but fails badly on rare important cases may not be suitable.
Make one of four decisions:
- Adopt: the tool met the threshold and controls are ready.
- Extend: the result is promising but more evidence is needed.
- Change: another product, model or workflow should be tested.
- Stop: the benefit does not justify the cost or risk.
Document the reason. A stopped pilot is useful when it prevents a larger, poorly supported rollout.
A practical approval checklist
Before production use, confirm there is an accountable owner, an approved purpose, staff guidance, access control, a data classification decision, vendor contacts, monitoring, an incident response path and a review date. Re-test when the model, product terms, connected data or business process changes materially.
The key measure
The goal is not to prove that AI can perform the task. It is to determine whether the complete AI-assisted workflow produces an accepted business result more reliably or efficiently than the current method. That is the evidence a decision-maker can use.