A company-wide AI promise is too vague to operate. A useful first project is one piece of work with a clear trigger, owner, finish and review point. The goal is not to prove that a model can answer. It is to improve a process your team can observe.
Choose a process, not a department
“Improve operations” is not a workable starting point. “Prepare the daily delivery-exception report for a manager to review” is. The second statement identifies an event, an output and the person who remains accountable. NIST’s AI Risk Management Framework likewise begins by defining the specific task an AI system will support.[1]
This MAJLS framework uses three hard gates and two preference signals. A candidate must pass every hard gate; a high score cannot compensate for unsafe authority or missing accountability.
Hard gates
- Accountable ownership: a named person owns the process, the approval points and the response to an exception.
- Acceptable consequence: early outputs are reversible or reviewed before they create a legal, financial, safety or customer commitment.
- Usable evidence: the required inputs, rules and common exceptions are available and traceable.
Preference signals
- Useful repetition: the process happens often enough to learn from.
- Visible performance: the team can measure time, errors, rework, backlog or another useful baseline.
Human oversight must be designed for the actual risk of the work, not added as a vague promise. NIST calls for oversight processes to be defined, assessed and documented; UK government guidance says humans should validate high-risk decisions influenced by AI.[1][2]
Reject the wrong first candidate
Do not begin with a process nobody owns, one built on unreliable data, or one whose exceptions are poorly understood. Avoid a first deployment where a wrong action could create a legal, financial, safety or customer commitment before a person reviews it.
A difficult process may still be worth redesigning. It is simply a poor first learning environment when the team cannot distinguish a system error from a broken process.
Map the work on one page
Build the map with the people who do the work. Policies describe the intended process; handovers, spreadsheets and workarounds reveal the real one.
Turn the map into one role
Define the first Virtual Employee around one outcome. State what it may read, prepare, recommend and execute. State what it may not do. Name the uncertainty or consequence that triggers escalation, and name the person who receives it.
For an illustrative delivery-exception role, the first version might collect delayed orders, check agreed rules, prepare a prioritized review list and explain why each item appears. A manager still decides which customer commitments change.
Set the pilot contract
Before the first shadow run, record four things: the current baseline, the target improvement, a representative test set that includes known exceptions, and the conditions that stop or advance the pilot. For example: no unauthorized action attempts, every high-impact case escalated, and an agreed reduction in preparation time without an increase in reopened cases.
Pilot in controlled stages
- Baseline: measure the current process before changing it.
- Shadow: let the role prepare outputs without affecting live work.
- Assist: let the team use those outputs while reviewing every handover.
- Operate: allow only the proven actions, with approvals and logs intact.
- Improve: review corrections, exceptions and missing information each week.
The first process is successful when the team can explain what improved, what still requires judgment and what the next role should learn—not when a demo looks impressive. Full testing before deployment and regular checks after launch are part of the operating model, not a one-time demonstration.[2]
Sources
Start with one process. Build from there.