The short answer
Two questions produce very different use-case lists.
"Where could we apply AI?" starts from the technology and produces ideas ranked by how well they fit what the technology does. The list is enthusiastic, technically interesting, and only accidentally connected to where the business loses money.
"Where is work slow, expensive, repetitive, risky, or inconsistent?" starts from the operation and produces problems. Some of them have an AI response, some have a process response, and some have a system response. All of them are grounded in something that is actually costing the organization.
The second question is harder to ask, because it requires reaching the people who experience the friction rather than the people who attend the strategy session. That is the real constraint on use-case identification, and it is a logistics problem more than an analytical one.
Organizations that solve it find that the resulting portfolio looks different: fewer initiatives, better grounded, and several of them turn out not to need AI at all.
Key takeaways
- Technology-first questions produce ideas. Operation-first questions produce problems.
- The people who experience friction are usually not the people in use-case workshops.
- Seven friction signals predict value reliably and are easy to ask about.
- A use case without a named consequence and frequency is a preference.
- Some of the best findings from a friction-first process have no AI component, and that is a good outcome.
- Identification and prioritization are separate steps, and merging them degrades both.
Why the technology-first question underperforms
It filters for fit rather than for value
Asking where AI could be applied selects for problems that resemble what AI does well. Document-heavy tasks, classification, summarization, drafting.
Those are real opportunities. They are also a specific subset, and there is no reason the organization's most expensive friction should fall inside it. The question has pre-selected the answer space.
It surfaces the visible work
The people who can answer "where could we apply AI" are people who understand both the technology and a function. That group is senior, and senior visibility is of the documented process.
The friction that matters is frequently in exception handling, reconciliation and coordination, which is invisible from that vantage point.
It skips consequence
A use case generated from technology fit arrives without a cost attached. Nobody asked how often the problem occurs or what happens when it does, because the question was about applicability.
Prioritization then has nothing to rank on except plausibility and sponsorship.
It produces solutions in search of a step
The most common outcome is an initiative that would work correctly and address a step that was not the constraint. The build succeeds, the metric does not move, and nobody can explain why.
The seven friction signals
These predict value reliably, they are easy to ask about, and people answer them readily because each one describes something that makes their work harder.
1. Work done more than once
Re-entry between systems, duplicate checks performed by different teams, information collected that already exists elsewhere. Duplication scales with volume and is invisible from inside any single team.
2. Work that waits
Cases sitting in queues for approvals, inputs or clarifications. High wait time points to decision rights and queue structure rather than to capacity, and the response is frequently not an AI response.
3. Work that comes back
Rework caused by errors introduced upstream, incomplete inputs, or requirements that changed after work started. Rework is expensive and its cause is almost always somewhere other than where it is experienced.
4. Work that depends on one person
Steps that only a specific individual can perform, or that slow materially when they are unavailable. This is both an operational risk and a signal that the process depends on undocumented knowledge.
5. Work assembled by hand
Reports, status views and consolidations built manually from several sources each cycle. This is one of the most consistently recoverable categories and one of the least reported, because it is periodic.
6. Work that varies without reason
The same process performed differently by different teams or markets, where the difference is not explained by a regulatory or contractual requirement. Variation multiplies the cost of every subsequent change.
7. Work that carries risk
Steps where an error produces material consequence, currently controlled by manual checking. The checking is the cost, and the question is whether the control can be supported rather than removed.
From signal to use case
Each signal names a question, and the answer determines whether AI is the right response.
| Signal | Diagnostic question | Common response |
|---|---|---|
| Done more than once | Which system should own this, and why does it not | Integration or ownership, rarely AI |
| Waits | Who is the case waiting for, and why | Decision rights, sometimes routing support |
| Comes back | Which upstream step produces the error | Fix upstream, sometimes validation support |
| Depends on one person | What do they know that is not written down | Knowledge capture, sometimes assistive support |
| Assembled by hand | Where does the data live and why is it not joined | Pipeline or reporting, rarely AI |
| Varies without reason | Which variation is required and which is inherited | Standardization, then automation |
| Carries risk | What does the control catch, at what cost per item | Analysis support with human decision |
The right column is the useful part of this exercise. A friction-first identification process consistently produces findings where the best response is integration, ownership clarification or standardization.
Treating those as failures of the AI programme is a mistake. They are cheaper, more durable, and they frequently remove the condition that would have made an AI deployment necessary.
Friction to response
What each signal implies
| Signal class | Underlying cause | AI is the answer when |
|---|---|---|
| Duplication | Systems or ownership | The join cannot be built and the matching is judgement-heavy |
| Waiting | Decision rights | Routing or triage requires interpretation |
| Rework | Upstream quality | Validation at intake requires interpretation |
| Single-person dependency | Undocumented knowledge | The knowledge can be captured and applied at the point of work |
| Manual assembly | Data plumbing | The consolidation requires interpretation, not just joining |
| Unexplained variation | Governance | Rarely, standardize first |
| Risk control | Consequence | The analysis can be automated and the decision stays human |
The pattern across the right column: AI fits where the work requires interpretation. Where the work requires a connection, build the connection.
Running identification at the right scale
The method above is straightforward. The constraint is reach.
Three requirements, and the third is what most attempts fail on.
Include the people who handle exceptions. The friction signals concentrate in non-standard work, and non-standard work is handled by people who are not in strategy sessions.
Cover every market and business unit. Variation is one of the seven signals and it is only visible when the same process is examined in several places at once.
Do not require their calendar time. The people experiencing the most friction have the least availability, which is a direct consequence of the friction. An identification process requiring scheduled interviews produces a sample weighted toward whoever was free.
Separate identification from prioritization
A common failure is running both in the same session.
Identification should be generous. Every friction signal that someone reports is worth recording, including the ones that turn out to be local, minor or already known.
Prioritization should be strict, applied afterward, against consistent criteria: business value, evidence strength, feasibility, adoption readiness, effort and strategic fit.
Merging them means findings get filtered during collection by whoever is in the room, and the filter is usually whether the item sounds important rather than whether it is expensive.
Where Horizon fits
Horizon is an AI-powered continuous discovery platform. It addresses the reach constraint, which is what determines whether friction-first identification is possible in a large organization.
Discovery Cycles run AI-led interviews asynchronously across every role that touches a process, adapting questions to each role and following up on the gaps. Asking about exceptions, artifacts and difficulty rather than about process is what surfaces the seven signals, and doing it without scheduling is what makes coverage a matter of participation rather than logistics. The Insights Dashboard groups findings by process, system and cause, so a signal appearing in several teams becomes one finding, and the Initiatives Dashboard converts the priorities into business cases with owners.
AFAP SURA, a pension fund administrator in Uruguay with 600 employees and part of the regional SURA group, ran identification this way on its ANR process for international transfers and its BPC workflows.
The starting condition contained several of the signals directly. Information was scattered across five systems, which is the manual assembly signal. The team had to request status updates continuously to understand where each case stood, which is both assembly and waiting. An error in an international transfer could produce a financial loss that is difficult to recover, which is the risk control signal. Understanding the process had previously required weeks of manual interviews reaching only a small portion of the team, which is the reach constraint.
In under seven days Horizon delivered 63 prioritized insights covering bottlenecks, repetitive tasks and operational risk points, with a complete view integrating all five systems and evidence-based recommendations to improve traceability, reduce risk and accelerate processing times. The manual comparison was three weeks. The pilot returned 186% ROI.
The composition of the findings is the point for this method. Bottlenecks, repetitive tasks and operational risk points are three distinct signal classes with three distinct responses, and separating them at identification is what stopped the output from becoming an undifferentiated list of things to automate.
That is one engagement under specific conditions rather than a projection for any organization.
Identification checklist
- Are you asking where AI could be applied, or where work is difficult?
- Which roles will contribute, and do they include exception handlers?
- Does the coverage include every market and business unit running the process?
- Does participation require calendar time from people who have none?
- For each finding, do you have a frequency and a consequence?
- Have you classified each finding by signal type?
- For each, have you asked whether AI is the right response or whether integration, ownership or standardization is?
- Are identification and prioritization separate steps?
- Do findings appearing in several teams get consolidated into one?
- Does each surviving finding have a named business owner?
Common mistakes
Starting from the technology. Pre-selects the answer space and filters for fit rather than for value.
Running identification in a workshop. Produces the view of whoever was invited, which is the documented process.
Recording findings without frequency or consequence. Leaves prioritization nothing to rank on.
Treating a non-AI finding as a failure. Integration and ownership fixes are cheaper and more durable, and finding them is a good outcome.
Merging identification and prioritization. Findings get filtered during collection by the wrong criterion.
Consolidating too late. Several teams reporting one underlying cause should become one initiative, and that only happens if findings are grouped by cause rather than by reporter.
FAQ
How do you identify AI use cases in an enterprise?
Start from operational friction rather than from technology fit. Ask where work is done more than once, where it waits, where it comes back, where it depends on one person, where it is assembled by hand, where it varies without reason, and where it carries risk. Then ask, for each, whether AI is the right response.
What is wrong with asking where AI could be applied?
The question pre-selects for problems that resemble what AI does well, which is a specific subset of the organization's friction and not necessarily the expensive part. It also tends to be answered by people whose visibility is of the documented process, which misses the exception handling where cost concentrates.
Who should be involved in AI use case identification?
The people who handle exceptions, perform the work, receive its output and clean up downstream problems, in every market and business unit in scope. Process owners and functional leads contribute design intent. The friction signals concentrate in non-standard work handled further from the org chart.
What makes a good AI use case?
One tied to a friction signal with a known frequency and consequence, where the work requires interpretation rather than a missing connection, where a business owner will sponsor the workflow change, and where the process is understood well enough to scope the exception handling.
Should every finding become an AI initiative?
No, and a process that produces only AI initiatives was probably a technology-first exercise. Many friction findings are better answered by integration, clearer decision rights, or standardization. Those are cheaper and more durable, and finding them is a successful outcome of identification.
How do you prioritize AI use cases once identified?
Separately from identification, against consistent criteria: business value, evidence strength, feasibility, adoption readiness, effort and strategic fit. Merging the two steps causes findings to be filtered during collection by whoever is present, using the wrong criterion.
Ask about the work, not about the technology
The quality of a use-case portfolio is determined by the question that generated it, and that question is asked before any analysis begins.
Starting from where work is difficult produces fewer initiatives, better grounded, and a portion of them turn out to need something cheaper than AI. All three are good outcomes.
See it. Fix it. Lead it.