Choose an enterprise AI pilot.

Define the decision the pilot must support.

Start with a recurring operating problem and one accountable process owner. Write the decision in practical terms: whether to introduce a capability into a particular workflow, change its scope, or stop. Specify where the workflow starts and ends, who uses the result, and what happens next.

Consider a process change or conventional automation alongside AI. A pilot is useful when it resolves uncertainty about the work. Choose a scope small enough to observe, with consequences the team can contain and a credible path into the systems it already uses.

Establish the baseline and the prerequisites.

Observe representative work before estimating improvements. Record monthly volume, hands-on effort, elapsed time, rework, and unusual cases. Identify the measurement period and evidence behind each number. Use the workflow mapping worksheet to expose handoffs and delays that a task-level demonstration might miss.

Check whether the required information is usable and whether access is approved. Identify system interfaces, permission requirements, testing constraints, and the people needed to resolve integration problems. An unavailable dependency is a reason to revise the scope before building.

Set the operating boundaries.

Describe what the proposed system may read, produce, and change. Distinguish a draft for human review from an action that changes a business record or sends information. Decide who approves consequential actions, who can suspend operation, and how the team handles ambiguous inputs.

NIST's voluntary AI Risk Management Framework organizes risk work around Govern, Map, Measure, and Manage. Use that broader guidance when establishing responsibilities and reviewing risks throughout the system's life. The checklist here is our practical planning aid.

Test the complete workflow.

Agree the test set and acceptance thresholds before reviewing results. Include normal inputs, missing information, misleading source content, access failures, and cases that require escalation. Measure output quality together with review time, operating cost, latency, and exception handling.

Follow the result into its next step. Verify that a reviewer can find supporting information, correct a mistake, and recover after an interrupted run. Check that retries do not repeat an external action. Have the operating team use the proposed process and explain how they would manage a failure.

Compare the evidence with the original objective. Expand only when the remaining uncertainty and operating burden are acceptable. Revise or stop when required access is unavailable, errors cannot be contained, or the expected benefit depends on assumptions the pilot did not support.

Pilot readiness checklist.

Review these items with the process owner, implementation team, and the people who will operate the capability. Print a copy and record the evidence or open question beside each item.

• Operating objective. One process owner has named the problem and the decision the pilot will inform.
• Measured baseline. Volume, handling time, elapsed time, quality, and exception rates have a stated measurement period.
• Suitable information. Representative inputs are available through approved access, with sensitive information handled appropriately.
• Integration path. The systems, permissions, dependencies, and test environment needed for the workflow are identified.
• Action boundaries. Allowed actions, required human approvals, and prohibited actions are explicit.
• Acceptance evidence. The test set, quality threshold, operating cost, and acceptable review effort are agreed before testing.
• Failure and recovery. The team can detect an error, stop further action, and return to a workable process.
• Adoption and ownership. Named people will review outputs, handle exceptions, maintain the capability, and assess the result.

A bounded pilot in practice.

Hypothetical example. An operations team spends time turning incoming supplier requests into internal summaries. The pilot prepares a draft summary and flags missing fields. A person checks the source and approves every update; the pilot cannot create a supplier or send a message.

The team compares drafts with a reviewed sample, measures checking time, and deliberately tests incomplete requests and unavailable source documents. It also rehearses returning to manual handling. A faster first draft alone would leave the operating decision unresolved.

Use the automation business-case calculator to examine whether the remaining review effort and recurring costs still support the proposal. An enterprise diagnostic can help establish the baseline and resolve the dependencies before implementation.