The most common mistake in enterprise AI planning isn’t picking the wrong model — it’s picking the wrong process to apply AI to in the first place. Most organizations start with “where can we use AI” and end up scattering pilots across a dozen loosely-connected use cases. A better starting question is narrower: which of our existing processes has the specific characteristics that make AI actually valuable there, versus the characteristics that make it a waste of a pilot slot.

Why “where can we use AI” is the wrong starting question

Almost any process can technically incorporate AI somewhere — that’s exactly the problem. Technical feasibility isn’t the constraint; value capture is. A framework built around “can AI touch this” produces a long list and no prioritization. A framework built around “does this process have the shape that makes AI actually pay off” produces a short list with a clear first move.

Three questions that actually diagnose fit

Is the process high-frequency and repeatable? AI’s economics depend on volume — a model that improves with usage needs usage to improve on. A decision made twice a year, however important, doesn’t generate enough signal to compound. A decision made a thousand times a week does, even if any single instance is lower-stakes.

Does the process currently rely on judgment applied inconsistently? If ten experienced people would make the same call ten different ways given the same inputs, that inconsistency is both the symptom of a real opportunity and the reason it’s hard to solve with a simple rulebook. AI is well-suited to processes where the right answer depends on weighing many soft signals the way experienced judgment does — not to processes with one clear correct procedure that a checklist already handles fine.

Is there a fast, honest feedback signal on whether the decision was right? A model can only improve if the organization eventually learns whether its output was correct — a fraud call gets confirmed or reversed within days, a pricing decision shows up in conversion within a week. Processes where the “was this right” answer takes a year to surface, or never surfaces cleanly, are much harder to build a genuine improvement loop around, however appealing the use case looks on a whiteboard.

Applying the framework: two examples, one clear answer

Compare “AI-assisted contract review” against “AI-assisted customer support triage” using these three questions. Contract review: moderate frequency, meaningfully inconsistent across reviewers, but feedback on whether a clause assessment was “right” often takes months and is genuinely ambiguous. Support triage: extremely high frequency, meaningfully inconsistent across agents, and feedback (did this ticket get resolved correctly, did it get escalated back) arrives within hours. Both are legitimate AI use cases eventually — but the framework says triage is the better first move, because the feedback loop closes fast enough to actually compound, and contract review is better attempted once the organization already has a working pattern to reuse.

What this means for a CIO building the roadmap

The framework isn’t a filter for “good AI use case, bad AI use case” — almost everything clears that bar eventually. It’s a sequencing tool: start where the three conditions are strongest, build the operating pattern (ownership, monitoring, feedback loop) there, and only then extend the same pattern to a use case with a slower feedback loop, using lessons already learned instead of starting from zero. Enterprises that sequence this way build one genuinely successful pattern and replicate it. Enterprises that pick use cases by executive interest instead of by this kind of fit tend to end up with the dozen-pilots-zero-systems problem described in almost every AI maturity report published in the last two years.

Run your own top five AI-candidate processes through these three questions — which one clears all three, and is it the one currently getting the most attention?