“Could AI Do This?” Is the Wrong First Question

AI is getting very good at making the first question easy.

“Could AI summarize this?”

Probably.

“Could AI answer these questions?”

Probably.

“Could an agent automate this workflow?”

Maybe.

“Could we put AI into this process somehow?”

Almost certainly.

But capability is a surprisingly weak filter for deciding what we should actually build.

The more useful question is:

Should AI do this?

That question leads somewhere very different.

Instead of starting with models, prompts, agents, or tools, you start with the work itself.

Who is doing it?

What problem are they actually having?

How do they handle it today?

What would meaningfully improve?

What information would the AI need?

And what happens when the AI is wrong?

That might sound obvious, but a lot of AI work gets into trouble because those questions are answered too late.

Microsoft's current AI adoption guidance explicitly recommends starting with business problems before considering AI at all. Look for things like repeated manual work, slow processes, and outcomes that aren't meeting expectations. Only then should those problems be translated into potential AI use cases.

That feels like a much healthier way to approach AI.

Not:

Where can we put AI?

But:

Where is work actually breaking down, and could AI make it meaningfully better?

A TECHNICALLY POSSIBLE IDEA IS NOT AUTOMATICALLY A GOOD USE CASE

This distinction becomes important very quickly.

RAND researchers interviewed experienced AI practitioners in industry and academia about why AI projects fail. Their research found recurring problems around poorly understood business problems, mismatches between the technology and the real workflow, data problems, infrastructure constraints, and technological limitations. The study was based on semi-structured interviews conducted with experienced practitioners rather than a survey trying to produce a catchy universal failure percentage.

There are plenty of dramatic statistics floating around about AI projects failing. The more useful lesson is why projects struggle.

Sometimes the model isn't really the problem.

The problem was never defined well enough in the first place.

Or the workflow wasn't understood.

Or the necessary data isn't usable.

Or the system technically works, but nobody actually wants to use it.

This is where I think AI enablement gets much more interesting than simply teaching people how to prompt better.

You need some way of taking:

“Hey, maybe AI could do this.”

…and turning it into something you can actually evaluate.

START BY TURNING THE IDEA INTO A USE CASE

I've been experimenting with a deliberately simple intake process.

Before evaluating an AI idea, I want answers to six things:

• User: Who actually has the problem?
• Pain point: What is slow, repetitive, frustrating, confusing, expensive, or error-prone?
• Current process: How is the work handled today?
• Desired outcome: What would meaningfully improve?
• Risk: What happens if the AI gets something wrong, misses something important, or behaves unexpectedly?
• Data involved: What information would the AI need to access, and is that information appropriate for the proposed system?

That's it.

This isn't supposed to become a 30-page requirements document.

The goal is to make vague ideas concrete enough that people can reason about them.

And there is overlap between those simple questions and much heavier AI governance frameworks.

NIST's AI Risk Management Framework emphasizes establishing context before making decisions about an AI system. Its Map function asks organizations to understand intended users, intended purpose, operating environment, expected benefits, potential negative impacts, limitations, data, human oversight, and alternatives. NIST also explicitly recommends considering non-AI approaches.

My six questions aren't a replacement for that kind of framework.

They're a lightweight front door into the same kind of thinking.

I think of the intake less as paperwork and more as structured curiosity.

Before changing the workflow, understand the workflow.

NARROW BEATS VAGUE

Take a help-desk example.

“Use AI in IT support” isn't a particularly useful use case.

It's an aspiration.

Even “use AI to make tickets easier” is still fuzzy.

But this is much easier to reason about:

Help the technician taking ownership of an existing ticket understand the issue, troubleshooting already performed, current status, and unresolved questions without manually reconstructing a long ticket history.

Now we have something.

The user is clear.

The problem is clear.

The current process can be observed.

The desired result can potentially be measured.

The data requirements become visible.

And the failure modes start appearing.

What happens if the AI says a troubleshooting step occurred when it didn't?

What if it leaves out the detail that completely changes the next action?

What ticket information is being sent to the model?

Does the technician treat the summary as a convenience, or as authoritative?

Those questions are much easier to ask once the use case has been narrowed.

NIST makes a similar point: narrower scopes tend to make risks easier to map, measure, and manage. MIT Sloan's guidance on generative-AI adoption likewise recommends breaking workflows down into individual tasks instead of treating whole jobs or processes as one giant automation target.

THEN COMES PRIORITIZATION

Understanding a use case still doesn't mean you should pursue it.

Suppose five departments bring five legitimate AI ideas.

You probably don't have unlimited people, money, time, or attention.

Some method of prioritization becomes necessary.

Microsoft recommends ranking AI opportunities based on factors including strategic value, implementation feasibility, business impact, complexity, available resources, and organizational fit. Its newer guidance for AI-agent projects uses three dimensions: business impact, technical feasibility, and user desirability.

For early-stage triage, I wanted something even lighter.

So I've been using three questions:

• Impact: How meaningful could the improvement be?
• Effort: How difficult or expensive would this be to implement and adopt?
• Risk: How much could go wrong?

I score each from 1–3 and use this small heuristic:

Priority Score = (Impact × 2) − Effort − Risk

This is not an industry-standard AI formula.

It isn't supposed to be.

It's just a quick decision aid.

Impact is weighted because an easy AI project that accomplishes almost nothing isn't automatically better than a slightly harder project that solves a painful problem.

The numbers force me to explain my reasoning.

That's the useful part.

SOME RISKS SHOULDN'T BE AVERAGED AWAY

There's one additional rule I like:

If Risk = 3, stop and review the risk separately before allowing the overall score to drive the decision.

That's intentionally conservative.

Imagine an idea with enormous potential impact but serious privacy, security, compliance, safety, or operational concerns.

I don't want a spreadsheet saying:

“Well, 5 points of value minus 4 points of danger still equals GO!”

Some risks need investigation rather than arithmetic.

NIST's Manage guidance reflects this broader principle. Organizations are expected to prioritize and respond to risk, weigh benefits against negative consequences, and explicitly decide whether development or deployment should continue.

The scoring model helps start the conversation.

It shouldn't end it.

“NO AI NEEDED” IS A VALID RESULT

Sometimes a successful AI assessment ends with:

Don't use AI here.

Maybe the task is completely deterministic and normal software handles it better.

Maybe the underlying process is broken and automating it would just make the broken process move faster.

Maybe nobody actually has the problem you thought they did.

Maybe the required data is inaccessible or inappropriate.

Maybe human review costs erase the expected savings.

Maybe today's models simply aren't reliable enough for that specific task.

NIST states this unusually plainly: AI systems may not necessarily be the right solution to a given business problem, and organizations should consider non-AI alternatives. Microsoft's current agent guidance similarly tells organizations to rule out cases where agentic AI adds unnecessary complexity before searching for good agent use cases.

I think that's worth emphasizing because the current AI environment creates a strange incentive.

Everyone wants use cases.

Every vendor wants adoption.

Every new capability makes us want to find somewhere to put it.

But good AI enablement can't just be a machine for generating more AI projects.

Sometimes judgment means knowing when not to build.

PASSING INTAKE DOESN'T MEAN “SHIP IT”

Let's go back to the ticket-summary example.

Say I estimate:

Impact: 3

It could significantly reduce the amount of time technicians spend reconstructing complicated ticket histories.

Effort: 1

Assume we already have an approved AI environment and accessible ticket information.

Risk: 2

Bad summaries could affect troubleshooting, but the output is advisory and a technician remains responsible for reviewing the actual record.

Using my little heuristic:

(3 × 2) − 1 − 2 = 3

That's a strong candidate.

But here's the important part:

A strong score doesn't mean build it and roll it out.

It means the idea has earned the next conversation.

Now I want a small pilot.

I want to know how long the existing process actually takes.

I want examples of difficult tickets.

I want to measure whether the summaries are accurate and genuinely useful.

I want technicians to tell me what the model consistently misses.

I want to understand how much human verification is required.

And I want to know whether any time saved survives once that verification cost is included.

MIT Sloan specifically recommends accounting for the cost of monitoring and correcting generative-AI output, then comparing the full cost of automation against the existing process. Promising use cases should move into controlled pilots with rigorous evaluation rather than straight into production.

Microsoft's adoption guidance similarly recommends proofs of concept that test technical feasibility and business value before full-scale implementation.

That gives us a much more useful sequence:

Discover → Define → Prioritize → Pilot → Measure → Decide

Not:

Discover cool AI thing → deploy cool AI thing.

THE MODEL IS ONLY ONE PART OF THE SYSTEM

Even after deployment, the work isn't finished.

The workflow can change.

The users can change.

The data can change.

The model can change.

People can start using the system in ways nobody predicted.

GAO's AI Accountability Framework organizes responsible AI practice around governance, data, performance, and monitoring, including monitoring whether systems remain reliable and relevant over time.

That matters because an AI system isn't valuable just because it worked in the demo.

It has to remain useful in the actual environment where people depend on it.

AI ENABLEMENT NEEDS A LITTLE RESTRAINT

As AI gets better, “Could AI do this?” is going to become less interesting.

The answer will increasingly be yes.

What matters more is everything that comes afterward.

Who benefits?

What improves?

How much does that improvement matter?

What will implementation really cost?

What information does the system require?

What can go wrong?

Will people actually use it?

And is AI the best intervention in the first place?

The goal shouldn't be finding the maximum number of places where we can insert AI into people's work.

It should be finding the places where AI makes that work meaningfully better — and having enough judgment to leave the rest alone.

To me, that's becoming one of the most important parts of AI enablement.

Not just knowing what AI can do.

Knowing what is actually worth doing with it.

RESEARCH REFERENCES

1. NIST AI Risk Management Framework — Map https://airc.nist.gov/airmf-resources/playbook/map/
2. NIST AI Risk Management Framework — Manage https://airc.nist.gov/airmf-resources/playbook/manage/
3. RAND — Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed https://www.rand.org/pubs/research_reports/RRA2680-1.html
4. Microsoft — AI Strategy and Use-Case Identification / Cloud Adoption Framework https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai/
5. Microsoft — Business Planning and Prioritization for AI Agents https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/business-strategy-plan
6. Microsoft — Plan for AI Adoption https://learn.microsoft.com/azure/cloud-adoption-framework/scenarios/ai/plan
7. MIT Sloan — How to Find the Right Business Use Cases for Generative AI https://mitsloan.mit.edu/ideas-made-to-matter/how-to-find-right-business-use-cases-generative-ai
8. Google PAIR — User Needs + Defining Success https://pair.withgoogle.com/chapter/user-needs/
9. U.S. Government Accountability Office — Artificial Intelligence Accountability Framework https://www.gao.gov/products/gao-21-519sp

Originally published on X.