Most failed AI pilots fail at the selection stage, not the technology stage. Teams pick something visible, run it for a quarter, and discover too late that no one defined what success would look like, who would judge it, or what the system was never meant to do. A pilot is an evidence-generating instrument. If you cannot specify in advance what evidence it will produce, you have chosen a demonstration, not a pilot.
This memo sets out a selection method drawn from the structure of the NIST AI Risk Management Framework (AI RMF 1.0). The framework is voluntary, and its actions are explicitly not a checklist or an ordered set of steps; they are outcomes a team can select and adapt to its own resources and circumstances.
What makes a pilot evaluable
An evaluable pilot has four properties before it starts. First, a documented purpose: what the system is for, in what setting, for whom. Second, a defined value proposition the organisation has written down, not assumed. Third, known limits: where the system's knowledge or reliability ends, and what happens at that boundary. Fourth, an identified human oversight arrangement, with a named person accountable for the outcome.
The AI RMF locates most of this work in the map function, which "establishes the context to frame risks related to an AI system." The framework states that an initial go/no-go decision about whether to design, develop, or deploy an AI system is informed by mapping, and that map outcomes are the basis for measure and manage. In practice this means the pilot selection decision and the evaluation design are the same conversation. Choosing a pilot you cannot measure is a way of deferring the decision, not making it.
A useful screen is to ask three questions of every candidate: can we state the benefit in operational terms before we start; can we observe whether the benefit occurred inside the pilot period; and can we stop, reverse or contain the pilot if it goes badly. A candidate that fails any of these is a candidate for a later round.
Document intended purpose and context
Map 1.1 calls for documenting intended purposes, beneficial uses, and the context-specific laws, norms and expectations that apply. For pilot selection this translates into a short written paragraph, agreed by the sponsor, that names the workflow, the users, the decision or task being supported, and the boundary of the system's role.
Map 1.4 asks for the business value or context of use to be defined. That is the sentence your finance or operations lead will test first. "Reduce time to draft routine correspondence" is a value proposition. "Explore generative AI in the business" is not. Only the first can be evaluated.
A worked hypothetical
Consider a hypothetical mid-sized services firm evaluating two pilots. Candidate A: an assistant that drafts first-pass responses to a high-volume email queue, with a human reviewer sending every message. Candidate B: an internal assistant answering staff questions about policy documents.
For Candidate A, the team can document the workflow (the queue), the users (reviewers), the intended purpose (drafting support, not autonomous sending), the value measure (draft acceptance rate and reviewer time per message), the knowledge limit (the model drafts from the message and approved templates; it is not authorised to give commitments), and the oversight (each reviewer approves or rejects every draft, with rejection reasons logged). The pilot produces evidence on a defined question within a defined period.
For Candidate B, the same team would struggle to define what a satisfactory answer looks like without a policy owner, and the volume of edge cases may be large. Candidate B is not a bad idea; it is a worse first pilot because the evaluation question is fuzzier and the failure mode is harder to observe. This example is illustrative, not a report of any organisation's results.
Human oversight and knowledge limits
Map 2.2 calls for documenting how the system's output may be used and overseen by humans, and the system's knowledge limits. Map 3.5 calls for defining, assessing and documenting human oversight processes in line with governance policies. For pilot selection these two subcategories are the most useful filter available.
If you cannot name the human who oversees the output, the pilot is not ready. If you cannot describe where the system's knowledge ends and what should happen there, you cannot evaluate failures, only successes, and that is not evaluation. A pilot in which every output is reviewed before use has a natural containment mechanism and a natural evidence trail. A pilot in which outputs flow directly to customers or into records has neither.
The framework also ties oversight back to governance: Govern 3.2 calls for policies defining roles and responsibilities for human-AI configurations, and Govern 2.1 for documented roles and clear lines of communication. A pilot whose oversight role is undefined is a governance gap wearing a pilot's clothes.
Benefits, costs and risk tolerance
Map 1.5 calls for documenting organisational risk tolerances. This is the input most often missing from pilot conversations, and it is the one that should govern sequencing. Take an explicit position on which risks are acceptable in a pilot (for example, errors confined to internal drafts corrected before sending) and which are not (for example, anything touching regulated advice, pricing commitments or personal data without defined handling). Then choose the pilot that sits comfortably inside the acceptable set.
Cost and benefit should be assessed together, in the pilot's own terms: reviewer time, integration effort, licence or inference cost, and the cost of the oversight you are choosing to retain. A pilot that looks cheap because it removes review is not cheaper; it has moved the cost to risk.
Third-party dependencies belong here too. Govern 6.1 addresses third-party entity risks, including infringement of third-party intellectual property or other rights, and Govern 6.2 calls for contingency processes for failures or incidents in third-party data or AI systems deemed high-risk. If the pilot depends on a vendor's model or data, ask what happens on the day it fails, changes or is withdrawn, before you commit.
Measurement caveats
Be honest about what you are measuring. The crosswalk between AI RMF 1.0 and ISO/IEC 23894:2023 maps the measure function to ISO clauses including risk evaluation, monitoring and review, and recording and reporting. That is a structure for judgement, not a template for metrics. You still have to choose the few indicators that would change your mind.
One caution: the framework is being revised, and specific subcategory wording may change. Use the current subcategories as prompts for your own documentation, not as a certification standard. The AI RMF is voluntary and describes outcomes, not compliance obligations. Nor does it tell you which pilot to run; that judgement is yours and should carry the name of the executive who made it, consistent with Govern 2.3.
The selection memo
Before you commit, write one page covering: intended purpose and context; the documented business value; the measure of benefit and how it will be observed; the system's knowledge limits and what happens at the boundary; the named human overseer and their review process; the risks accepted and excluded; third-party dependencies and contingencies; the stop conditions; and the date of the go/no-go review. If a section is blank, the pilot is not yet evaluable.
Next step: draft that one-pager for your strongest candidate, and give it to a sceptical colleague for ten minutes. If they cannot restate the measure of success and the stop condition in their own words, revise the pilot scope before you spend anything. When the memo is ready, use the board brief builder to turn it into a short decision record for your board, and see The first 90 days of AI leadership for the governance groundwork the pilot will depend on.
For the underlying framework text, read the AI RMF Core and the AI RMF resources page. NovCog advises on these decisions; contact details are at novcog.com.
