Choosing where to start with AI
Updated 17 October 2026
Several executives want an AI pilot. Each has a promising demonstration, and the technology team is asked which one to launch first.
The choice should begin with the business problem. A compelling demonstration says little about the work required to connect data, change a process or check outputs. Leadership needs to compare proposals on a common basis before enthusiasm becomes a spending commitment.
Start with a short list of specific uses and the decision each pilot would support. “Improve productivity” needs considerably more definition.
Choose a process you can examine
Name the task, users and workload. Establish how the work performs today and why that performance is unsatisfactory. Ask whether the problem arises from missing information, unclear responsibilities, a poor process or a capability that AI may usefully provide.
An ordinary process improvement may solve part of the problem. Include that option in the comparison. The sponsor should explain why the proposed technology is appropriate and what would remain difficult after introducing it.
A proposal without a business owner or a usable baseline may need preparation before it needs a pilot budget.
Compare the work behind the demonstration
For each proposal, examine the information required, the ability to access it appropriately and the effort needed to integrate the tool. Include the staff time required for testing and reviewing results.
Then examine consequences. A tool helping an employee search an internal manual raises different questions from one taking actions in a customer account. An apparently simple use can become more consequential when it gains access to additional information or systems.
NIST's AI Risk Management Framework offers a voluntary reference for considering risk throughout development and use. Its relevance here is practical: the proposed business use and its context need examination, alongside technical performance. [1]
Design a first test you can interpret
Consider an illustrative internal knowledge assistant. Limit the first test to an agreed collection of documents and a defined user group. Test whether it produces accurate, supported answers, recognises when it lacks enough information and respects access permissions.
Compare the complete task with the existing approach, including the time users spend checking answers. A quick response that sends employees to the wrong procedure can create more work than it saves.
Agree the evidence needed to expand, revise or stop the test. Document limitations so that a successful result on one workload is not treated as approval for every department.
Make the first approval small and specific
Leadership should approve a scope, budget and review date, with responsibility for business outcomes and technical operation clearly assigned. Establish how incidents will be reported and who can pause the use.
Keep a record of other proposed uses. A first pilot should create evidence for the next choice rather than encourage uncoordinated experimentation across the organisation.
Keep the approval narrow enough that the organisation can honour its safeguards. Wider access or autonomy deserves a fresh decision, even when the first demonstration went well.
[1] NIST AI Risk Management Framework Read the source