Where AI Actually Fits in a Business Process (And Where It Doesn’t)

The board question I hear most often isn’t “should we use AI.” It’s “where” — and it’s almost always asked after money has already been spent on the wrong answer.

Most AI adoption I see follows the same pattern: a pilot gets built around whatever is most demoable, not whatever is most valuable, because demoable is what gets budget approved. Six months later, the pilot either quietly dies or limps into production doing something marginal, while the actual high-value use case in the business — the one nobody built a demo for because it wasn’t flashy — remains untouched. The fix isn’t a better AI strategy document. It’s a clearer way of sorting where AI genuinely fits from where it’s being deployed because it’s fashionable.

The test that actually sorts it

A business process is a reasonable AI candidate when three things are true simultaneously, and weak on any one of them is usually enough to sink the deployment even if the other two look strong.

The output is checkable. Not “a human could theoretically review it” — genuinely, structurally checkable, ideally by something other than re-reading the AI’s own output and taking it on faith. A drafting task where a lawyer reviews the draft against source documents is checkable. A summarisation task where the only way to verify accuracy is to read the entire original anyway has quietly eliminated its own time-saving, because the check costs as much as doing the task without AI in the first place.

The error cost is bounded. A wrong suggestion in a low-stakes, easily-corrected context costs little. A wrong output that flows silently into a regulatory filing, a financial calculation, or a safety-critical decision costs a great deal, and the cost is often invisible until well after the error has propagated. The same underlying technology is a good fit in one context and a governance liability in the other — the technology didn’t change; the blast radius of being wrong did.

The volume actually justifies the investment. AI implementation, done properly rather than as a demo, carries real integration and governance cost — the total-cost point I’ve written about elsewhere applies here too. A process run five times a month rarely justifies that overhead, however impressive the pilot demo looked. A process run five thousand times a month, with meaningfully consistent structure each time, usually does.

Where this rules things out, and where it doesn’t

Run that test honestly and a lot of currently-fashionable AI deployments fail it plainly. High-stakes judgment calls with unbounded error cost and no real check beyond “does this look right” are consistently the worst candidates, and they are also, not coincidentally, the ones every AI vendor’s demo is built to make look most impressive — because unbounded, high-judgment tasks are precisely where a slick demo is hardest for a non-expert audience to interrogate in the room.

The strongest candidates are usually the least glamorous: high-volume, structurally repetitive, genuinely checkable tasks that nobody wants to demo to a board because they don’t look like the future. Document classification against an existing taxonomy. First-pass triage that a human confirms before anything downstream happens. Drafting that a domain expert reviews against source material as a matter of course, not as an afterthought. None of that photographs well in a pitch deck. All of it is where the actual return sits.

Two examples, same technology, opposite verdicts

A financial services firm considering AI for two different tasks illustrates the test cleanly. First: using a model to draft first-pass responses to routine customer information requests, checked by a compliance officer before anything is sent — high volume, bounded error cost because nothing goes out unreviewed, genuinely checkable because the officer is comparing the draft against a known policy. Strong candidate. Second: using a similar model to help interpret ambiguous regulatory guidance and suggest a compliance position — low volume, unbounded error cost because a wrong interpretation could shape a filing or a supervisory conversation, and barely checkable because the people qualified to check it are the same people who would otherwise have done the interpretation themselves from scratch. Same underlying technology, same vendor even, in some cases. One is a strong candidate. The other is exactly the kind of high-stakes judgment call the test is built to catch before budget gets spent finding out the hard way.

This is also where retrieval quality and classification discipline becomes directly relevant to whether an AI deployment succeeds at all — the highest-value, checkable use cases are almost always the ones that depend on the underlying content being well organised, which is precisely the layer most AI pilots skip in the rush to get a demo working.

Getting the fit wrong is one of the most common reasons a pilot never leaves the proof-of-concept graveyard.

Sorting genuine AI opportunity from AI theatre is a scoping exercise, not a strategy workshop — it’s most useful done before budget is committed, not after a pilot has quietly failed. A technology control assessment can run this test against your actual process inventory.