Where Should Your Company Use AI? A Decision Framework

A team can fill a whiteboard with AI ideas in an hour.

Customer service chatbot. Sales assistant. Internal knowledge bot. Meeting summaries. Automated reporting. Proposal generation. An agent that handles part of operations.

The list is easy.

The decision is not.

Most of those ideas start with the technology and work backward until someone finds a problem that seems to fit. That can produce an interesting demo. It does not tell us whether anything important in the business should actually change.

I prefer to start somewhere else.

The first AI question is not what can be automated. It is what should change.

That sounds like a small distinction. In practice, it changes the entire investigation.

Instead of searching the company for places to install AI, start by looking for operating pressure. Where are customers waiting? Where does skilled capacity disappear into preparation and coordination? Where does information exist but fail to arrive when a decision has to be made? Where does work lose context at a handoff? What useful capability is not happening at all because it has historically been too expensive?

Only after that do I ask whether AI belongs there.

And even then, "AI can do it" is not enough.

A worthwhile opportunity has to survive a harder test: it has to create a meaningful change, beat the simpler alternatives, fit the nature of the work, respect the right authority boundaries, produce evidence we can measure, and become a system somebody can actually operate.

That is the difference between collecting AI ideas and making an AI decision.

Start with the business, not the model

When someone asks where a company should use AI, I do not think the best starting point is a catalog of use cases.

A better investigation begins with the operating system of the business.

Customer and Employee Wait States

A customer may be waiting for an answer. An employee may be waiting for information. A manager may be waiting for analysis. A deal may be waiting for the one person who knows how to interpret an issue.

Waiting is useful because it exposes friction without presuming a solution.

The question is not yet whether a model can answer faster. The question is why the work is waiting and what would change if it stopped.

Capacity Lost to Preparation

Repetitive work is the obvious version, but it is not the only one.

A highly paid employee may spend hours gathering information before using five minutes of actual judgment. A technical specialist may repeatedly explain the same context to different teams. A manager may spend more time preparing the decision than making it.

The opportunity may not be "replace the task." It may be to remove the preparation that keeps a person from doing the part of the job that actually requires that person.

Information Trapped Across Systems

Companies often have more information than they can use.

It sits across documents, conversations, tickets, emails, systems and individual experience. The constraint is not necessarily a lack of data. It can be the inability to bring the right evidence together when somebody needs to act.

That is a very different problem from "we need an internal chatbot."

Expensive Handoffs Between Departments

A process can work well inside each department and still fail between them.

Context gets lost. Someone re-enters information. Another person has to interpret what the first person meant. Work stops while ownership changes.

A handoff can be a technology problem. It can also be a process problem, an ownership problem, or an information design problem. We should know which one before introducing AI.

Quality Variation Beyond Judgment

Two people receive the same information and produce very different outcomes.

Sometimes that variation represents legitimate judgment. Sometimes it exposes a process that depends too heavily on memory, individual experience or inconsistent access to information.

AI may help. A clearer standard may help more.

The variation is the signal. AI is only one possible intervention.

Expertise as a Bottleneck

Some work stops because the next step depends on a specialist.

That might be a lawyer, engineer, analyst, senior operator, product expert, sales leader or simply the one person who knows how a system really works.

The opportunity is not automatically to automate the expert. It may be to let more of the organization arrive at the expert with the evidence already gathered, routine questions already resolved, and the real judgment call clearly isolated.

That protects expertise instead of pretending it is unnecessary.

Capabilities That Were Not Economical Before

This is the category I find more interesting than repetitive work.

A company may want every inbound interaction answered, every account researched, every document reviewed, every anomaly inspected, every proposal adapted, or every employee to have access to specialist-level assistance.

Historically, the economics may have made that impossible.

AI can change that boundary.

That is different from automation. It is not only doing existing work cheaper. It can make a previously unavailable capability possible.

This is where some of the more valuable opportunities hide because nobody is complaining about a broken workflow. The workflow does not exist yet.

Turn the pressure into a change

Once an operating pressure appears, I still do not call it an AI use case.

I try to describe the change first.

"Build a customer service bot" is a technology idea.

"Reduce the number of customers who wait until the next business day for a basic answer" is a business change.

"Use AI for reporting" is a technology idea.

"Give an operating leader the evidence needed for a weekly decision without spending six hours assembling it" is a business change.

"Create a knowledge assistant" is a technology idea.

"Reduce how often work stops because only one experienced employee knows where the answer is" is a business change.

The second version gives us something important that the first does not.

It gives us something to investigate and eventually measure.

The Opportunity Card

Before discussing models, vendors or architecture, capture the opportunity in a simple record:

Notice what is absent.

There is no model.

There is no vendor.

There is no architecture.

There is not even an assumption that AI is the answer.

That is intentional.

AI has to beat the simpler intervention

One of the easiest mistakes in an AI program is comparing AI with the status quo.

That is the wrong comparison.

If the current process is painful and an AI prototype looks better, the project can appear compelling.

But perhaps the real alternatives are a better form, a cleaner process, an integration between two systems, a deterministic rule, ordinary software automation, or simply removing a step that should not exist.

So the first gate I apply is simple:

Can a simpler intervention solve enough of the problem?

If it can, AI has to demonstrate why the additional complexity is justified.

This matters because every AI system introduces another operating surface.

Something has to provide context. Access has to be controlled. Outputs have to be evaluated. Failure has to be handled. Costs change with usage. Models and vendors change. Somebody has to decide what happens when the system is uncertain or wrong.

That does not mean AI should be avoided.

It means complexity has to earn its way into the system.

Is the work actually shaped for AI?

If the opportunity survives the simpler-alternative test, then I look at the nature of the work.

Some problems are well suited to current AI capabilities because they involve messy language, interpretation, classification, synthesis, generation, pattern recognition, variable inputs or decisions where useful evidence is distributed across a lot of information.

Other problems are better expressed as deterministic software.

If the correct behavior can be written as:

If X happens, always do Y.

then an AI model may be unnecessary.

If the work is closer to:

Understand what this person is asking, retrieve the relevant context, apply several constraints, produce a useful response, know when confidence is inadequate, and escalate.

then the AI case becomes more interesting.

The distinction matters because "AI" is not one capability.

A useful AI system can include models, deterministic rules, retrieval, APIs, permissions, workflow logic, human approvals and conventional software.

The goal is not to find a place for a model.

The goal is to design the smallest system capable of producing the desired change.

Then ask what the AI is allowed to do

This is where many use-case frameworks become too shallow.

They ask whether an idea has value and whether it is feasible.

I think there is another question that matters just as much:

What authority are we giving the system?

An AI system that drafts something for a person to review is not the same system as one that communicates directly with a customer.

A system that recommends a refund is different from one that issues it.

A system that finds information is different from one that modifies the source.

A system that proposes an appointment is different from one that changes a calendar.

A system that summarizes a decision is different from one that makes it.

The technology may look similar. The operating consequences are not.

For any meaningful use case, I want to know:

• What can the AI see?
• What can it infer?
• What can it say?
• What systems can it reach?
• What can it change?
• What can it trigger?
• What requires human approval?
• Who is responsible when an action crosses that boundary?

This is one place where opportunity discovery intersects with work I have done on Cognitive Systems Management and the Instruction Stack Audit Framework.

The point is not to turn every opportunity conversation into a governance exercise.

It is to recognize that an AI capability eventually becomes part of a larger system of instructions, data, permissions, tools, people and decisions.

In ISAF, I use a similar principle for accountability: if behavior matters, we should be able to trace where relevant instructions entered the system and who owns the layer that influenced the outcome.

At the opportunity stage, the executive version of that question is simpler:

If we give this system authority, will we still understand who controls what?

If we cannot answer that, we do not yet understand the system we are proposing.

Failure tells us more than the happy path

I also want to know what happens when the system is wrong.

Not because every AI application is dangerous.

Because failure exposes the real architecture.

Consider a system answering a basic internal policy question.

A wrong answer might create minor confusion and be corrected quickly.

Now consider a similar model communicating contractual information to a customer, making a hiring recommendation, approving a financial action or controlling part of an operational process.

The probability of an incorrect output might be similar.

The consequence is not.

That changes the evidence, controls and human authority we need.

So I do not think an opportunity should be evaluated only on expected value.

It should also be understood through its failure path.

What happens if the system is wrong?

Can the action be reversed?

Will anyone know?

Can the system fail safely?

Can a human intervene?

Can we identify which data, instruction, tool call, rule or human decision produced the behavior?

If the answer to that last question is no, production may become difficult long before a demo reveals the problem.

If we cannot measure the change, we do not have a decision yet

Another weakness in AI opportunity discussions is vague success.

"Improve productivity."

"Enhance customer experience."

"Use AI to make employees more efficient."

These may describe the intent. They do not give us a decision threshold.

Before committing to an AI initiative, I want a baseline.

How long does this take today?

What does it cost?

How often does it fail?

How much work waits?

How much skilled capacity is being consumed?

How much variation exists between operators?

What demand goes unanswered?

Then we can define what meaningful improvement would look like.

Maybe the proposed system reduces response time from hours to minutes.

Maybe it gives ten employees access to knowledge that previously depended on two specialists.

Maybe it shortens a research process without reducing decision quality.

Maybe the expected productivity benefit disappears after we include review time.

All of those are useful outcomes because they tell us something.

A negative finding can be valuable too.

It may save an organization from scaling an idea that looked impressive in a demo but did not change the economics of the work.

A score comes later

Use-case prioritization matrices are useful.

I use structured evaluation too.

But I do not think a weighted score should be allowed to rescue an idea that fails a fundamental decision gate.

A project might have high expected value, strong executive enthusiasm and easy technical feasibility.

That still does not make it a good AI project if ordinary automation solves the problem better.

Or if the system needs access the organization cannot responsibly provide.

Or if the outcome cannot be measured.

Or if nobody will own the system once the project team leaves.

A score is most useful after qualification, when several legitimate opportunities need to be compared.

Before that, the harder questions matter more.

Current enterprise guidance already does useful work around use-case discovery, repetitive work, skill bottlenecks, ambiguity, impact-versus-effort prioritization and workflow mapping. I see this framework as a complement to that work, not a replacement for it. The additional question I want to force earlier is whether the opportunity deserves to become an AI system at all.

This is also where I depart from a common impact-versus-effort approach. Impact and effort are useful portfolio dimensions, but they answer a later question: which qualified opportunities deserve attention first? They do not tell us whether a candidate should have entered the portfolio in the first place.

The AI Opportunity Decision Map

I move an opportunity through six decisions.

1. Find the pressure

Identify what is waiting, constrained, fragmented, inconsistent, expensive, underused or currently impossible.

Do not name the technology yet.

2. Define the change

Describe the operating outcome before describing the solution.

Establish a baseline and an outcome owner.

If we cannot explain what should be different, the idea is not ready.

3. Test the simpler intervention

Ask whether process change, existing software, deterministic automation, integration or removal of unnecessary work solves enough of the problem.

AI has to beat the simpler intervention, not merely the current pain.

4. Qualify the AI fit and authority

Determine what AI contributes that matters.

Then define what information it needs, what it may do, what remains human and what failure would mean.

This is where a feature idea begins to become a system decision.

5. Decide what must be proved

List the assumptions that would change the decision if they turn out to be wrong.

Define the baseline, success threshold, failure criteria and evidence needed before a larger commitment.

The test is not "can we make a demo work?"

The test is "what evidence would justify the next decision?"

6. Test whether the system can be operated

Ask who owns:

• quality
• access
• exceptions
• cost
• monitoring
• vendor and model changes
• human escalation
• failure recovery
• improvement after deployment

A project that has no operating owner is not production-ready, even if the prototype is excellent.

That sequence mirrors how I think about AI more broadly:

Research, Reframe, Prove and Decide, Architect, Mobilize, Improve.

Research the situation.

Reframe the problem before choosing the technology.

Prove what matters and make the decision.

Architect the system, including authority and failure paths.

Mobilize the people, ownership and controls around it.

Improve it from production evidence.

The idea is not to slow AI down.

It is to avoid spending speed on the wrong decision.

One example from building a voice AI system

When I worked on Kestrel Voice, "build an AI voice agent" was never a useful enough problem statement.

The technology was obvious.

The business problem was more interesting.

What should happen when a business cannot answer every customer interaction?

A voice model that can carry a conversation solves only part of that.

The useful outcome may require the system to understand why someone called, answer from approved information, collect what the business needs, book something, transfer the conversation when appropriate, preserve the result, and make sure somebody knows what happened.

Once you look at the whole operating outcome, the architecture changes.

Correct escalation can matter more than sounding perfectly human.

Business rules have to exist before they can be automated.

Cost, monitoring and failure recovery become product features instead of afterthoughts.

That experience reinforced something I now use as a general test:

The use case is not the AI capability. The use case is the operating change the capability has to produce.

"AI voice agent" names a technology.

"Make sure valuable customer demand does not disappear when the team cannot answer" describes something worth investigating.

One produces a demo.

The other can produce an operating decision.

The same opportunity can end in different decisions

A good investigation does not have to result in "deploy AI."

I would expect opportunities to leave this process in several different states.

Explore

The pressure appears important, but important assumptions remain.

We need more evidence before deciding whether an AI intervention is worth testing.

Prove

The opportunity is strong enough to justify a bounded evidence test.

The next step should be designed around the assumptions that could kill the idea.

Pursue

The opportunity has enough evidence and operating clarity to move into solution design, vendor selection or architecture.

This does not mean "build immediately." It means the problem has earned the next commitment.

Not AI

The problem matters, but another intervention is better.

That can be a successful result.

Wait

AI may fit later, but capability, economics, data, authority, ownership or another dependency is not ready.

A Wait decision should include a revisit trigger.

Stop

The opportunity does not justify further investment.

A company that can stop weak AI ideas is in a better position to fund the strong ones.

The one-page AI Opportunity Card

For each candidate, I would preserve the decision in a record like this:

That last field matters.

AI capability changes. Vendor economics change. Regulations change. Internal data improves. Integration becomes easier. A "Wait" decision today may become a strong opportunity later.

A decision framework should preserve that context instead of forcing every idea into approved or rejected.

After an opportunity survives

Finding the opportunity is only the first decision.

If it survives, a different set of questions begins.

Should we buy a product, configure something we already have, integrate a vendor capability, build a differentiated layer ourselves, or wait?

If we need a proof of concept, what exactly must it prove?

If a vendor is involved, what dependency are we accepting along with the capability?

What architecture preserves the right authority boundaries?

What must be observable once the system is live?

Those deserve separate treatment because each is a substantial decision on its own.

The important part is that we do not jump to them too early.

A company will always be able to find more places where AI could be used than it has the capacity to pursue.

The harder question is which part of the business is worth changing, whether AI materially improves the intervention, and what evidence would justify the next commitment.

If those answers are still unclear, the next step is not implementation.

It is investigation.

Companion Artifact: AI Opportunity Decision Map

The complete decision flow in one view:

1. FIND THE PRESSURE
   Waiting, capacity, information, handoffs, variation, expertise bottleneck, unserved demand, previously uneconomic capability
2. DEFINE THE CHANGE
   Current baseline to desired operating outcome to accountable owner
3. TEST THE SIMPLER INTERVENTION
   Process change? Existing software? Deterministic automation? Integration? Remove the work?
   If a simpler intervention solves enough of the problem, the answer is NOT AI. If not, continue.
4. QUALIFY AI FIT AND AUTHORITY
   What does AI uniquely contribute? What can it see? What can it say? What can it change? What remains human? What happens when it is wrong? Can the behavior be traced?
5. DEFINE THE EVIDENCE GATE
   Baseline, hypothesis, success threshold, failure threshold, key assumptions.
   Insufficient evidence means EXPLORE. Enough to test means PROVE.
6. OPERATING READINESS
   Owner, monitoring, cost, access, exceptions, escalation, change, fallback, improvement.
   Ready means PURSUE. Not ready but potentially viable means WAIT. Not justified means STOP.

Source and methodology notes

This article is intentionally not a list of AI use cases. Current enterprise guidance already covers common AI opportunity discovery patterns such as repetitive work, skill bottlenecks, ambiguity, use-case gathering, impact-versus-effort prioritization and workflow mapping. The framework above adds a different layer: operating pressure first, simpler alternatives before AI, explicit authority and failure boundaries, evidence gates, traceability, and production ownership.

For context on existing enterprise use-case guidance, OpenAI's Identifying and scaling AI use cases covers repetitive low-value work, skill bottlenecks, ambiguity, use-case primitives, impact-versus-effort prioritization and department workflow mapping. OpenAI's How enterprises are scaling AI emphasizes workflow design, ownership, quality before scale, governance as an enabler and protecting human judgment.

Internal methodology references: Cognitive Systems Management (CSM) supplies compatible operating principles around ownership, risk, monitoring and continuous operation. The Instruction Stack Audit Framework (ISAF) supplies compatible principles around instruction traceability, layer ownership and accountability. The AI Opportunity Decision Map is a separate executive opportunity framework authored for this article. It is not part of ISAF.

FAQ

How is this framework different from an AI use case prioritization matrix?

A prioritization matrix is useful after qualification, when several legitimate opportunities need to be compared. This framework handles the earlier question: whether a candidate should enter the portfolio at all. It applies decision gates before scoring.

Should every AI opportunity go through all six decisions?

Yes for any opportunity that would require production resources. For very small experiments, a compressed version still helps: identify the pressure, test the simpler intervention, and define what would count as evidence.

What is the most common mistake in AI use case discovery?

Starting with the technology instead of the operating pressure. Teams search the company for places to install AI rather than looking for what should change. That produces demos, not decisions.

When should a company decide Not AI for an opportunity?

When a simpler intervention solves enough of the problem. Process change, existing software, deterministic automation, or removing an unnecessary step may be the better answer. Not AI is a successful result when it saves the organization from unnecessary complexity.

How does this connect to ongoing AI advisory?

The framework identifies qualified opportunities. For recurring decisions across multiple opportunities, ongoing advisory through AI Advisor for Business provides continuous judgment support. For assessing one specific workflow, the AI Opportunity and Workflow Assessment applies this methodology to a real opportunity.

Trying to determine whether a workflow is actually worth pursuing with AI?

The AI Opportunity and Workflow Assessment examines one opportunity, the current workflow, the alternatives, the evidence and the path forward before you commit to implementation.