Most disappointing AI features share a structure: a capable model was attached to a step that cannot tolerate being wrong, with no way for a person to see how the answer was reached or to correct it. The model performed as advertised. The design was the problem.
So the design question isn't 'where could we use AI'. It's 'where in this process is a good-but-not-certain answer worth more than no answer' — and, immediately after, 'what does being wrong cost here'.
Sorting the steps by cost of error
Every step in a workflow has an error cost, and it's usually easy to sort:
- Cheap and reversible — drafting a first version, suggesting a tag, grouping similar records, summarising a thread. A wrong answer costs a moment. These are where AI earns its place immediately.
- Expensive but reviewable — extracting figures from a document, matching records, proposing a decision with reasons. Useful, but only with the evidence attached and a person in the loop.
- Consequential and hard to reverse — approving a payment, rejecting an application, publishing to a customer, changing a clinical or legal record. Automating the judgment here buys a small amount of speed for a large amount of risk.
Put AI where being wrong is cheap and being fast is valuable. Keep judgment where being wrong is expensive.
Design the wrong answer
A feature is only as good as its failure mode, and with probabilistic systems the failure mode is not an edge case — it's a normal Tuesday. Which means the interface has to be designed for the wrong answer as deliberately as for the right one.
- Show the source. An extracted figure should point at the line it came from. Traceability turns an unverifiable claim into a checkable one.
- Make correction cheap and durable. If fixing an output takes longer than doing it manually, the feature is a tax. And the correction should teach the system, not evaporate.
- Say what it is. Label a suggestion as a suggestion. Confidence theatre — a guess presented as a fact — is how users learn to distrust everything the product tells them.
- Never hide the manual path. The moment automation becomes the only route, its bad days become the organization's bad days.
Automation before intelligence
One more thing worth saying plainly: a large share of the value people hope to get from AI is available from ordinary automation. Removing a re-keying step, connecting two systems that were exchanging PDFs, generating a document from data that already exists — deterministic, testable, and boring.
Do that work first. It makes the process legible, which is exactly the condition under which it becomes clear where a model would actually help.
We map the workflow before proposing anything intelligent, because you can't judge where a model helps until you can see where the time actually goes. Often the first fix isn't a model at all — and the second one lands much better for it.
Working on something this touches? We're usually happy to talk it through before anyone commits to a project.
Start a conversation