Practical AI
Map the exceptions before you put AI into a workflow
The fastest-looking workflow is not always the safest one. Start by making its exceptions, decisions, and recovery path explicit.
The normal path is only part of the design
A workflow description often ends at the happy path: a request arrives, information is processed, and an output is sent. Real operating work also contains missing information, conflicting records, unclear approvals, unusual customer requests, and provider outages.
Before using AI, write down what should happen when the input is incomplete, the confidence is low, a private account would be needed, or the outcome could materially affect a customer. Those situations are not edge cases to hide. They define where human judgment belongs.
Give every automated step a boundary
For each step, name the trigger, permitted data, proposed action, reviewer, timeout, error state, and recovery action. A useful first AI application normally drafts, classifies, summarizes, or prepares work for review. It does not silently make commitments on behalf of the business.
The boundary should be visible to the people responsible for the workflow. If they cannot pause, correct, or explain a step, it is not ready for a consequential production role.
Measure the process, not just the model
A responsible pilot has a limited scope and a review point. Track the time saved, corrections required, exceptions encountered, and any work shifted to people elsewhere in the process. If the exception burden rises, stop and redesign the workflow rather than increasing automation.
This approach aligns AI adoption with ordinary operating discipline: map the context, identify risks, measure behavior, and manage the result over time.
Sources and further reading
- AI Risk Management FrameworkNational Institute of Standards and Technology