How to Scope an AI Workflow Pilot Before You Build

Describe the job from trigger to accepted result

A useful pilot brief begins with an observable trigger and ends with a result a named person can accept. ‘Use AI in support’ is too broad. ‘Draft a response to eligible product questions from approved documentation, for a support specialist to review’ gives the team a boundary it can build and test.

Write the current steps before proposing automation. Include the queue where work arrives, the information staff look up, the decision they make, and the destination of the result. If two teams disagree about what a completed task means, resolve that disagreement before putting a model between them.

This article covers the pilot brief after a candidate workflow has been selected. For the earlier selection decision, use the custom AI system readiness checklist. The AI workflow pilot page connects the brief to the wider delivery process.

Make inclusions, exclusions, and authority explicit

The scope must say which inputs qualify and which actions are permitted. Restrict the first release by request type, data source, team, or product line. Exclude the cases that require unresolved policy judgments, inaccessible data, or an owner who is not available to review them.

Separate proposal from execution. A draft-only pilot can still be useful: the team learns whether drafts are accurate, whether they save effort after review, and which context is missing. If the pilot writes to another system, specify the authorized fields, approval rule, and recovery procedure in the brief.

A practical brief should also identify data access and retention boundaries. The NIST AI Risk Management Framework provides a voluntary framework for considering trustworthiness through the AI lifecycle. The brief below is Arrow AI's proposed planning method; it is not a NIST certification or a compliance determination.

A worked pilot brief for support drafts

Illustrative planning example, not a customer result: a product team wants help drafting answers about exports. Its proposed pilot could read as follows:

The exclusions are part of the deliverable. They prevent a useful drafting experiment from quietly becoming an account-management system. A new request type should enter a new review of scope rather than be added because it resembles the first one.

Measure the complete task and decide what happens next

Measure the current process using the same eligible request types the pilot will handle. Record handling time, lookup time, corrections, and the fraction routed elsewhere. Agree on what counts as a material error before comparing outputs.

For the pilot, include review and correction effort. A fast draft that takes longer to verify can increase total work. Report the number and mix of reviewed requests, the accepted and rejected outputs, and the reason for each rejection. Keep uncertain or unmeasured outcomes visible rather than converting them into a success rate.

Define a decision date and three possible outcomes. Continue when the bounded workflow meets the agreed criteria. Revise when a specific, testable issue explains the failures. Stop or return to manual work when the source material, ownership, or controls are inadequate. Choose thresholds with the team before observing results; there is no universal pass percentage for every AI workflow.

Before broader use, document the operational handoff. For technical patterns behind source handling and execution, see the Arrow AI Tech architecture guide.

Sources and editorial scope

Original operating guidance by Arrow AI. Published and reviewed October 15, 2026. Worked examples are illustrative and are not customer outcomes. Acceptance criteria depend on the workflow and its operating context.

• NIST: AI Risk Management Framework