Begin with the work, not the technology
A broad instruction to “use AI” creates pressure to find a place for a capability. That reverses the order of a sound product decision. First identify work that is slow, inconsistent or constrained by the effort required to interpret information. Then determine whether software, process change, conventional automation or an AI-assisted step is the most suitable response.
This distinction matters because many workflow problems are caused by unclear policy, fragmented data or missing ownership. Adding a probabilistic system to an unclear process can make the ambiguity faster without making the outcome better.
Observe the workflow at task level
Job titles and process diagrams are too coarse for opportunity discovery. Observe the actual sequence of tasks: gathering context, checking completeness, classifying, comparing, drafting, approving, recording and following up. Note where people switch tools, reconstruct missing information or make the same judgement repeatedly.
Capture exceptions as carefully as the normal path. They reveal the knowledge and discretion that a simplified workflow description leaves out. An automation that works only for ideal inputs may still be valuable, but its boundary must be explicit.
- Volume: how often does the task occur?
- Effort: where is time spent reading, moving or reformatting information?
- Variation: how consistent are the inputs and desired outputs?
- Judgement: which decisions require context, policy or expertise?
- Consequence: what happens when the output is wrong, late or incomplete?
- Traceability: what evidence must be retained for review?
Choose an assistance boundary
Automation is not a binary choice between manual work and full autonomy. A useful design decision is the boundary between what the system proposes and what a person controls. The right boundary depends on consequence, reversibility, data sensitivity and the ability to detect poor output.
For lower-consequence work, the system might complete a routine transformation and expose an audit trail. For higher-consequence work, it might retrieve sources, summarise evidence or draft a recommendation while a named person remains responsible for the decision.
- Assist: organise information or draft an output for review.
- Recommend: present an option with rationale and supporting evidence.
- Act with confirmation: prepare an action that requires explicit approval.
- Act within limits: execute reversible, well-monitored steps under defined rules.
- Escalate: route uncertainty or policy exceptions to the right person.
Design evaluation before rollout
A demonstration can show that a system produces plausible output. It cannot show that the output is dependable for a specific workflow. Evaluation needs representative examples, explicit quality criteria and known failure categories. Where possible, compare the assisted process with the current baseline rather than judging the generated content in isolation.
Measures should combine task performance with operational and human signals. Time saved has little value if review effort increases, exceptions become harder to detect or users stop trusting the system. The evaluation should also reveal who decides whether performance is sufficient and what happens when it is not.
- Task quality against an agreed rubric.
- Time to a reviewed, usable outcome.
- Rate and type of corrections or escalations.
- Coverage of important input variations.
- User confidence calibrated to actual performance.
- Cost, latency and reliability under expected volume.
Make governance part of the experience
Governance is not only a policy document. It appears in the product through permissions, source visibility, consent, retention, review controls, logging and clear communication about what the system is doing. These features shape whether a workflow is safe to operate and understandable to the people affected by it.
Teams should define data boundaries, accountable owners and incident paths before expanding access. They should also make it possible to change or disable the AI-assisted step without disabling the entire service. That separation keeps the operating model adaptable as requirements, vendors and model behaviour change.
Scale learning before scale of use
A narrow pilot is valuable when it is designed to answer specific questions. Select a bounded workflow, known participants and a manageable consequence of error. Record where the system helps, where people compensate for it and which new work the automation creates.
Expansion should follow evidence that the workflow, assistance boundary and controls are sound. Reusing a proven pattern across adjacent tasks is usually more durable than launching disconnected experiments whose only common feature is the technology.
- Define the decision and baseline before the pilot.
- Test with representative inputs, including difficult cases.
- Keep a clear human owner and a safe fallback path.
- Review performance, operating cost and unintended work together.
- Expand only when the evidence supports the next level of consequence.