Reviewer note: Editorial draft written for launch. Review, edit and approve before publishing.
Most AI pilots look impressive in a demo. Far fewer survive contact with a real operation, and the reason is rarely the model. It is that nobody designed what happens when the model is unsure, wrong or unavailable.
Start with the exception path
Take document extraction — reading an ID card, a form or an invoice. A good model will be confident about most documents and uncertain about some. The useful design question is not how to make it perfect but what happens below a confidence threshold: who reviews the item, in which queue, with which fields highlighted, and how their correction is captured.
When that path is designed first, the threshold becomes a business dial. Raise it and more items go to people; lower it and more flow straight through. Operations teams can tune it with evidence rather than faith.
Validate against systems of record
An extracted value is a claim, not a fact. Before it is written anywhere, check it against what the organisation already knows — an existing customer record, a purchase order, a registry entry. Most costly errors are caught here, cheaply, before they reach a ledger or a decision.
Make every automated decision explainable later
Every automated step should leave a trail: the input, the model or rule that acted, the confidence, the outcome and who approved any exception. That trail is what makes automation acceptable to auditors, regulators and the staff whose work it changes — and it is the data you need to improve the system over time.
Design these three things — exception path, validation and audit trail — and the choice of model becomes the easy part.
Related capabilities