A useful AI pilot starts with a task you can describe and a result you can check. Before handing a tool more responsibility, write down the process, the reviewer, and what success would look like. Use this worksheet to turn an interesting demonstration into a decision your team can explain.
1. Choose a bounded task
Start with one recurring piece of work: drafting a procedure from approved notes, organizing release information, or preparing a comparison for review. Describe the input and the expected output in ordinary language. If the task is still unclear, an impressive demonstration will not tell you whether it worked.
For example, a pilot could draft a summary of approved release notes for a payroll administrator to check. The trial ends at a reviewed draft. It does not make a configuration change or release a payment.
2. Write down today's baseline
Observe the task before changing it. Record preparation time, review time, common corrections, and how often the task happens. Include the work required to get data into a usable form. This gives the team something concrete to compare with the pilot.
- What starts and ends the task?
- How long does the existing process take, including review?
- Which errors would make the result unusable?
3. Set the boundaries before the trial
Choose an approved environment and data suitable for the trial. Describe what the tool may read, suggest, or change. A suggestion and an executed action deserve different checks. If the pilot could alter a record, identify the person who approves that change and how the team would reverse it.
Brandon Toombs' episode includes browser-use examples in a demo HR system with dummy data. Keep that context when discussing the example with your team; it is not a production deployment recipe.
4. Test ordinary work and awkward cases
Build a small set of examples from the kinds of work the process actually sees, using approved or synthetic data. Include incomplete inputs, conflicting instructions, and cases where the right answer is to stop and ask a person. Have a qualified reviewer compare the output with a known acceptable result.
Keep a record of corrections instead of polishing away the failures. A trial that works only after its creator repeatedly intervenes may still be useful, but that intervention belongs in the result.
- Can the reviewer tell where an answer came from?
- Does the tool recognize missing information?
- What happens when a source, screen, or input format changes?
5. Measure the whole cost
Compare total preparation, execution, review, and repair time with the baseline. Include usage charges and maintenance effort. Saving ten minutes of drafting while adding twenty minutes of checking is a result worth seeing clearly. It is not a reason to hide the review time.
Useful evidence includes a completed task, its inputs, the checked output, the corrections, and the time and cost needed to reach an acceptable result. Record the tool and version so the team can understand what was tested.
6. Make an explicit decision
Choose among continuing the trial, changing its scope, stopping it, or proposing a controlled next step. Name the owner and the condition that would trigger another review. A promising experiment can remain an experiment while the team resolves reliability or data-handling questions.
This is a PayrollBADIes discussion worksheet, not a certification or a substitute for your organization's policies. NIST's AI Risk Management Framework offers a broader reference for defining responsibilities, understanding context, evaluating systems, and managing their use over time.
Make it useful
Your working notes.
Use these prompts on your own or with your team. Notes stay on this page and are cleared when you leave or refresh. Save a copy before you go. Use task descriptions and test examples, not personal employee details.
No signup needed. Your notes are not submitted to PayrollBADIes.
