Does This Task Need AI? Three Filters to Help You Decide

Disclaimer: I create this content entirely on my own time, and the views expressed here are mine alone (not my employer’s). Because I love leveraging new tech, I use AI tools like Gemini, ChatGPT, Claude, Perplexity and others as a “digital team” to help research and polish these articles so I can share the best possible insights with you!

Before adding AI to a workflow, evaluate predictability, complexity, and risk.

Not every business problem needs AI.

Sometimes the right answer is a database query. Sometimes it is a script, a clearer process, or a better way to apply rules you already understand.

The question is not, “Can AI do this?”

It is, “Is AI the most effective, reliable, and economical way to get this done?”

That distinction changes the conversation. Instead of starting with a model and looking for somewhere to use it, start with the task and work toward the appropriate solution.

My approach is to run the task through three filters: Predictability, Complexity, and Risk.

Can we define the rules? Can simpler tools handle the work? And what happens when the system gets it wrong?

Before You Automate, Get Two Things Clear

Before applying the three filters, establish clarity about two things: the workflow you are trying to automate or replace, and the outcome you need to achieve.

1. Understand the Workflow

Map how the work actually happens—not just how the process documentation says it happens. Identify the inputs, steps, systems, handoffs, decisions, and people involved. Include the workarounds and informal judgments that keep things moving.

Keep the scope narrow enough to assess. “Process an invoice” contains several different tasks: reading the document, extracting fields, checking amounts, matching a purchase order, and authorizing payment.

Those tasks do not necessarily need the same technology—or the same level of oversight. Otherwise, you risk automating an incomplete understanding of the process.

2. Define the Outcome—and Explore the Exceptions

“Use AI to improve operations” is not specific enough to evaluate.

“Read incoming service requests, identify the issue, and suggest the appropriate support queue” is a task you can evaluate—once you define what acceptable performance looks like.

Be specific about the result you need, how you will measure success, and what makes an outcome unacceptable. Then explore what could fall outside the normal path: missing information, conflicting instructions, unusual requests, policy exceptions, or cases requiring human judgment.

Brainstorm these scenarios with the people who do the work. You may not anticipate every exception, but you should define how unexpected cases will be recognized, escalated, and resolved.

Once you understand the workflow, the intended outcome, and how exceptions should be handled, you are ready to apply the three filters: Predictability, Complexity, and Risk.

Filter 1: Predictability—Can We Define the Rules?

Start by asking whether the task follows explicit, stable logic.

If you know the inputs, the formula, and the conditions that determine the answer, conventional software is the natural starting point.

Consider calculating a shipping charge. Given the package weight, destination, service level, and approved rate table, the system should apply the specified calculation. There is no need to ask a language model to interpret what the charge might be.

Now consider this customer message:

“The replacement arrived, but it has the same issue as the first one. I need this resolved before Friday.”

That task involves interpretation. The system needs to recognize a repeat problem, understand the deadline, and identify the appropriate next step.

The useful distinction is not “easy versus difficult.” It is:

Are we applying known rules, or interpreting information whose meaning varies?

Start with non-AI when the task is primarily a calculation, lookup, validation, or explicit policy check. Consider testing AI when interpretation or learned patterns are central to the work.

One important qualification: predictable execution does not guarantee correct software. Rules can be incomplete, code can contain bugs, and source data can be wrong. The advantage is that the intended behavior can be explicitly specified and tested—not that traditional software is infallible.

Filter 2: Complexity—Can Simpler Tools Handle the Work?

A task may be possible to describe with rules but impractical to maintain that way.

Imagine routing support requests using keywords. A small list might work initially. Over time, the list could expand to cover synonyms, spelling mistakes, multiple languages, overlapping issues, and exceptions.

At that point, ask:

Are the rules still solving the problem, or has maintaining the rules become the problem?

This is where AI becomes a candidate—not an automatic winner.

Compare it against practical alternatives:

A database query.
A script or rule engine.
A template or structured form.
A search system.
A process change that removes unnecessary variation.

Google’s machine-learning guidance explicitly advises teams not to be afraid to launch without machine learning. Anthropic offers a similar principle for LLM applications: start with the simplest solution and add complexity when it produces a measurable improvement.

Also, avoid treating “AI” as synonymous with “LLM.”

Predicting an outcome from historical records and drafting a response to a customer are different tasks. Evaluate the appropriate approach rather than defaulting to a conversational model for both.

The same caution applies to data formats. A spreadsheet does not rule out machine learning, and a PDF does not automatically require generative AI. Focus on what the task requires—not the file extension.

Filter 3: Risk—What Happens When It Is Wrong?

This filter determines how much responsibility a system should receive.

An awkward draft, an incorrect support classification, and an unauthorized payment are different failures with different consequences.

Instead of asking whether a general accuracy percentage is “good enough,” ask:

Which errors matter most?
Can we detect them before they cause harm?
Can the resulting action be reversed?
What information or permissions does the system need?
Who handles exceptions and remains accountable?

Separate interpretation from authorization.

For example, an AI component could read a refund request and extract the customer’s explanation. Conventional code could check the transaction and apply refund limits. A person could approve exceptions.

That is a proposed division of responsibilities—not a claim that adding a reviewer automatically makes the workflow safe.

“Human in the loop” only becomes meaningful when you specify what the person checks, what evidence they receive, and whether they can realistically detect a mistake.

If a failure would be consequential and difficult to detect or contain, do not treat successful demonstrations as permission for autonomous execution.

The Three-Filter Decision Table

Use this table to decide what to evaluate first.

Filter	Key question	Start with non-AI when…	Consider AI when…
Predictability	Can we explicitly specify the required behavior?	Rules, formulas, and lookups adequately describe the task	Interpretation or learned patterns are essential
Complexity	Can a simpler solution remain practical?	Queries, scripts, rules, or process changes meet the requirement	Variation makes simpler approaches difficult to maintain effectively
Risk	Can we detect and contain important failures?	AI errors would be unacceptable and difficult to control	Validation, restricted actions, or effective review can manage the consequences

Passing these filters makes a task a candidate for AI. It does not establish that AI is the best solution.

That requires evidence.

Then Prove the Business Case

Test the proposed approach against the current process and a reasonable non-AI alternative.

Use representative examples, including routine work, incomplete inputs, unusual cases, and consequential exceptions.

Measure:

Quality of the completed task.
Frequency and severity of important errors.
End-to-end completion time.
Human review and correction effort.
Total cost per accepted result.

That last measure matters. A low-cost model response is not necessarily a low-cost business outcome if someone must repeatedly verify or rewrite it.

Include integration, infrastructure, monitoring, support, and exception handling in the comparison. Apply the same accounting discipline to the non-AI alternative.

Evaluation should also precede unnecessary architectural complexity. Anthropic’s guidance emphasizes measuring performance and establishing comprehensive evaluations when developing more autonomous systems.

Often, the Right Answer Is Hybrid

Consider a proposed monthly financial-reporting workflow:

Retrieve approved figures using database queries.
Calculate totals and variances with conventional code.
Use an LLM to draft commentary from the validated results.
Check the draft’s numerical claims against those results.
Have the accountable owner review the interpretation.

The model helps explain the numbers. It does not become the authority for calculating them.

This is why “AI or non-AI?” is often more useful at the task level than at the process level.

One workflow can contain rule-based calculations, AI-assisted interpretation, and human decisions. The objective is to assign each responsibility deliberately.

The Bottom Line

Use the three filters to challenge the proposed solution:

Predictability: Can we define the rules?
Complexity: Can simpler tools handle the work?
Risk: Can we manage being wrong?

Then test whether AI actually improves the outcome after accounting for cost, verification, and operating effort.

If explicit rules solve the task well, use them. If AI improves one part of the workflow, use it there. If the risks cannot be controlled, redesign the task before automating it.

The goal is not to put AI everywhere. It is to put the right capability in the right place.

References and Resources

Google for Developers — Rules of Machine Learning: Best Practices for ML Engineering. A practical foundation for starting without ML, establishing useful metrics, and managing the complexity of machine-learning systems.
Anthropic — Building Effective Agents. Guidance on choosing simpler approaches, distinguishing workflows from agents, and evaluating whether additional autonomy and complexity are justified.