If you are a commercial or functional leader looking at a list of AI use cases, one question can save you a surprising amount of time and money:
Does this job actually need AI?
It sounds obvious. In practice, it is easy to skip.
You find a painful process. You understand what is wrong. You redesign it. Then the conversation moves immediately into solution mode.
Which model should we use? Could we build an agent? Which platform should we buy? What should the architecture look like?
Architecture has already started, while one important decision is still open:
What should actually solve this problem?
That is the job of the AI Fit gate.
The first 3 stages need 2 different gates
In the previous article, I covered the first 2 stages of the FDO transformation method: Diagnose and Redesign. In the full method, G1 Business Fit sits between them.
The 6 stages remain:
Diagnose → Redesign → Architect → Build → Deploy → Prove
The gates are explicit decision points between stages.
After Diagnose, G1 Business Fit asks whether the problem is worth solving. We should be able to name the business outcome, the current baseline, the owner and the measure of success before we invest further.
Then comes Redesign.
Here the job is to understand how the work should operate. Where decisions happen. Where people wait. Where information gets lost. Which steps create value. Which steps should disappear. Which decisions still require human judgment.
By the end of Redesign, we should have a better design for the work.
The technology choice is still open.
That is where G2 AI Fit begins.
Start with the simplest solution that can do the job
I use a simple ladder:
Process → Rule → Existing software → Automation → AI → Agent
Start from the left.
Move right only when the simpler option cannot perform the job well enough.
A broken handoff may need a process change.
A decision with stable conditions may need a rule.
A recurring task may already be covered by software the company owns.
A fixed sequence may need ordinary automation.
A task involving variable language, ambiguity, unstructured information or context may justify AI.
A bounded job that must reason across information, use tools and take several actions may justify an agent.
An agent is still an AI system. I separate it on the ladder because it usually introduces another level of architecture, permissions, monitoring and operating complexity.
Google’s current guidance is unusually clear on this point. It says to start with the business goal, decide whether the goal needs predictive ML, generative AI or a non-ML approach, and avoid a complex ML solution when a simpler non-ML solution works. Google also recommends using the non-ML solution as a benchmark for the quality, cost and maintenance case for ML.
That is almost exactly the decision discipline I want this ladder to create.
Easy to build does not mean necessary to build.
The FDO Qualify Card
Once the work has been redesigned, I run the proposed intervention through 6 decisions:
Value → Simplest solution → AI advantage → Evidence → Consequence → Economics
The card is deliberately simple. Each decision has to be answered before we move on, and serious red conditions stay visible instead of disappearing inside an average score.
1. Value: keep the business outcome attached to the AI decision
Business Fit should already have established that the problem deserves attention.
At AI Fit, we carry that evidence forward.
Ask:
What business outcome changes?
What is the current baseline?
Who owns that outcome?
How will we know it improved?
This is not a second business case. It is an anchor.
Technical discussions can quickly drift toward model quality, response time, token cost or accuracy. Those measures may matter later. The business outcome tells us why the system exists.
Google’s current generative AI guidance starts the same way: define measurable business goals and success criteria first, then decide whether AI is the right approach.
My kill condition is simple:
If we cannot name the outcome and the owner, the use case does not move forward.
2. Simplest solution: move through the ladder from left to right
Now take the redesigned job and ask:
What is the simplest reliable way to perform it?
Run through the ladder:
Process → Rule → Existing software → Automation → AI → Agent
Suppose every sales team submits the same report in a different format. You may need a template and a clearer operating rule.
Suppose the decision is fully deterministic: when condition X and condition Y are both true, raise an alert. That is a rule.
Suppose someone spends hours every Monday moving information between systems in the same sequence. That may be an automation problem.
The burden of proof should increase as you move right because complexity has a cost. You pay for it in design, testing, integration, maintenance, monitoring and human attention.
3. AI advantage: name what AI contributes
If AI still looks useful, make the contribution explicit.
Ask:
What can AI do here that the simpler options cannot do well enough?
Possible answers include:
understanding messy language
working with unstructured documents
generating or transforming content
extracting useful patterns from complex information
making predictions under uncertainty
adapting to variable inputs
reasoning across several pieces of information
The exact list is less important than the discipline.
Write the AI advantage in one sentence.
For example:
AI is useful here because customer requests arrive as free text and the system must interpret intent before routing them.
That sentence tells us why AI is being considered. “We want to automate customer service with AI” does not.
4. Evidence: can the system actually contribute to the job?
Here I borrow the decision-decomposition logic from the AI Canvas developed by Ajay Agrawal, Joshua Gans and Avi Goldfarb.
Their original canvas separates a decision into 7 elements: prediction, judgment, action, outcome, input, training and feedback. It was designed around prediction systems, so I am adapting the structure rather than copying it directly for modern LLM and agent systems.
For G2 AI Fit, I use:
Input → AI contribution → Judgment → Action → Outcome → Feedback
Then ask:
Input
What information does the system need?
Is it available?
Can the system access it?
Is it trustworthy enough?
AI contribution
What exactly will the AI produce?
A recommendation? A classification? A draft? A prediction? A decision? An action?
Judgment
Who decides whether the output is good enough?
Sometimes this is a person. Sometimes it is a deterministic check. Sometimes the system can operate inside tightly defined boundaries.
Action
What happens because of the output?
If nobody acts on it, the output has limited business value.
Outcome
Can we observe what happened afterwards?
Feedback
Can we compare the result with what the system recommended or did?
If the outcome and feedback are invisible, the evidence chain is weak. We may have built something that produces outputs without a reliable way to learn whether those outputs create value.
5. Consequence: understand one wrong answer before discussing averages
Ask:
What actually happens in the business when this system gets one wrong?
More specifically:
What happens after a false positive?
What happens after a false negative?
What happens after an invented or unsupported answer?
Can the error be reversed?
Who is affected?
How quickly would somebody notice?
This changes the autonomy decision.
A low-consequence use case may tolerate more autonomy. A high-consequence use case may need stronger review, tighter boundaries, better evidence or a narrower AI role.
NIST’s AI Risk Management Framework Playbook recommends identifying the likelihood and magnitude of beneficial and harmful impacts. It explicitly says those estimates can inform go/no-go decisions, and it gives qualitative scales such as red, amber and green as one possible assessment method.
This is why I would not average consequence away inside a single score.
A serious red condition stays red until it is resolved.
6. Economics: price the reliable system
The useful question at this point is:
Is this still a good business intervention after we include everything required to make it reliable?
Include the whole system:
build effort
integrations
data work
human review
maintenance
model and runtime cost
monitoring
change and adoption effort
cost of errors
A cheap model call can sit inside an expensive operating system.
AWS puts these questions early in its generative AI lifecycle. Its scoping phase asks whether generative AI is relevant to the problem and calls for risks, investment costs, success metrics, technical and organisational feasibility, and data availability and quality to be considered before model selection and development.
That is the economic case I care about: the cost of the reliable intervention, not just the cost of calling the model.
Three fast tests expose weak AI cases
Before passing G2, I run 3 final tests.
These are working FDO tools, not established external frameworks.
The reverse-AI test
Ask: If AI disappeared from the proposal tomorrow, how would we solve this problem?
This exposes solution bias quickly.
You may discover that a process change, a rule or existing software already solves most of the problem.
The 80% test
Ask: Can a deterministic solution deliver roughly 80% of the value with much less complexity?
The 80% is a forcing function, not an empirical threshold.
If the answer is yes, I want a clear reason for accepting the extra complexity.
Sometimes that reason is strong. The remaining value may be commercially important, the inputs may vary too much for fixed logic, or the deterministic solution may become difficult to maintain at scale.
Then AI may earn the next step.
The failure question
Ask: What happens in the business when this system gets one wrong?
The same technical accuracy can have very different business meaning depending on what the misses do.
A wrong output might create a few minutes of correction. It might send an incorrect customer communication. It might influence a material decision. It might create a compliance problem.
The consequence gives the technical metric meaning.
Finish AI Fit with a decision record
At the end of the gate, I want a decision record:
Outcome (select one):
PROCESS | RULE | SOFTWARE | AUTOMATION | AI | AI + HUMAN | AGENT | STOP
Why
One sentence.
Evidence still missing
One sentence.
Conditions before Architect
Any unresolved red items.
Then route the decision clearly.
If the outcome is AI, AI + HUMAN or AGENT, and the red conditions are resolved, G2 passes and the work moves to Architect.
If PROCESS, RULE, SOFTWARE or AUTOMATION is enough, route the work to that simpler intervention. There is no reason to continue down the AI path just to protect the original idea.
If the answer is STOP, stop or park it.
If important evidence is missing, hold the decision until the evidence exists.
This is why I prefer a decision record to a score. It shows what was decided, why, and which assumptions still matter.
Passing G2 gives Architect a much cleaner job
Once G2 passes, the architecture question becomes much more precise.
We already know why AI belongs in the redesigned work, what contribution it should make, what evidence is available, what can go wrong and what economics the intervention has to survive.
Now Architect can focus on how the chosen system should work:
human and machine responsibilities
components and interfaces
data and context
deterministic logic and AI reasoning
approvals and escalation
tools and integrations
evaluation and controls
That is a much better place to start architecture.
Run one use case through the gate on Monday
Take one AI idea currently being discussed in your team.
Use this page:
Business outcome - What should improve?
Baseline - What happens today?
Owner -Who owns the outcome?
Simplest solution
PROCESS → RULE → SOFTWARE → AUTOMATION → AI → AGENT
Where does the problem first become adequately solvable?
AI advantage - What specifically does AI add?
Evidence
INPUT → AI CONTRIBUTION → JUDGMENT → ACTION → OUTCOME → FEEDBACK
What is missing?
Consequence - What happens when the system gets one wrong?
Economics - What does the reliable version really cost?
Decision
PROCESS | RULE | SOFTWARE | AUTOMATION | AI | AI + HUMAN | AGENT | STOP
Conditions before Architect - What must be resolved before you move?
That is the whole gate.
Redesign gives you the better work. AI Fit decides whether AI deserves a role in it. Architect begins after that decision is clear.
Sources:
Google Cloud, Evaluate and define your generative AI business use case. Updated 18 September 2026. https://docs.cloud.google.com/docs/ai-ml/generative-ai/evaluate-define-generative-ai-use-case
Google for Developers, Understand the problem (Machine Learning Problem Framing). Updated 25 August 2025. https://developers.google.com/machine-learning/problem-framing/problem
AWS Well-Architected Framework, Generative AI Lens: Generative AI lifecycle. https://docs.aws.amazon.com/wellarchitected/latest/generative-ai-lens/generative-ai-lifecycle.html
NIST AI Risk Management Framework Playbook, Map 5.1. https://airc.nist.gov/airmf-resources/playbook/map/
Ajay Agrawal, Joshua Gans and Avi Goldfarb, Prediction Machines official site. https://www.predictionmachines.ai/
Agrawal, Gans and Goldfarb, The AI Canvas (official template linked from the Prediction Machines site). https://docs.google.com/presentation/d/1TAJ2A4NvMLFi7b0mTvNyL1pMVRy84UhzhgcsXknhR2g/edit