Pilot Programs
Part of AI procurement and pilot programmes
Deciding when a tool is not ready for business adoption
Use AI pilot evidence to approve a narrow use, hold for a specific fix or decline adoption.
Hold or decline an AI tool when the proposed use fails a mandatory condition, a material purchase claim remains unverified, or staff lack a workable way to recover from failure. Decide for the tested task and conditions. A pilot need not deliver a verdict on every possible use of the product.
Separate a repairable gap from a stop
Read the pilot record against criteria agreed before testing. A correction staff can reliably make within the task’s time and effort limit may support a narrow, reviewed use.
A consequential wrong answer that escapes the planned check, an unapproved data flow, or a critical action without a recovery route calls for a hold. The decision depends on the task’s consequences and controls shown to work.
| Decision | Appropriate when | Record |
|---|---|---|
| Narrow approval | Mandatory conditions passed for a defined task and account | Users, inputs, review and monitoring conditions |
| Hold and retest | A specific source, setting, process or term may resolve the gap | Owner, required change and affected cases to rerun |
| Decline | An essential requirement cannot be met on acceptable terms or effort | Failed requirement and approved alternative |
A planned control remains unproven until it has been checked under the relevant conditions.
Decision Outcomes in AI Tool Piloting
- Narrow ApprovalMandatory conditions met for a defined task and account; requires ongoing monitoring and review.
- Hold and RetestA specific issue identified (e.g. data flow, process) can be fixed; retest required after correction.
- DeclineAn essential requirement cannot be met on acceptable terms or effort; alternative path must be documented.
Check ordinary operation
Can a reviewer inspect the source behind an important claim? Does the proposed account provide the required controls? Can work continue when the tool refuses, fails or reaches a limit? Can the result reach the right record without duplicate action? Are support and exit arrangements adequate for the task? A good isolated response cannot settle these questions.
Examine recovery in the intended workflow, including whether an alternative pathway exists for critical functions.
Success on non-sensitive cases does not settle a later use involving personal information. Keep that later data flow outside the approval until the intended account, agreement and use have been assessed.
Write a decision that can be revisited
Record the task, account, inputs, date, acceptance rule, material failures, repair effort and uncertainty. Give each open issue an owner and name the evidence that would reopen the decision. A changed feature, source or contract may justify another pilot; it does not turn an earlier failed result into a pass.
If adoption is declined, preserve the requirement that failed, along with any viable manual or narrower route. If a narrow use is approved, set a review date and a way for staff to report failures.
How to Write a Revisitable AI Adoption Decision
- Record task, account, inputs, date, and acceptance ruleEnsure clarity for future reference and audit purposes.
- Document material failures and repair effortSupport transparency and accountability in decision-making.
- Assign owners to open issuesEnable clear responsibility for follow-up actions.
- Define evidence that would reopen the decisionSet criteria for when a new pilot or review is warranted.
- Set review date and failure reporting methodFor approved narrow uses, ensure ongoing oversight.
