When does a workflow need AI, and when does it just need better software?
The decision framework I actually use with clients to separate problems that need AI from problems that just need a decent automation, and why getting this wrong is expensive.
When does a workflow need AI, and when does it just need better software?
The most useful thing I can do in an early client conversation is talk someone out of using AI.
Not because AI isnt valuable. It often is. But because a lot of the problems I am brought in to solve dont actually need AI. They need a better process, or a basic automation, or someone to finally clean up the data pipeline that has been broken for eighteen months.
If I built an AI solution for every problem a client described as "an AI problem," I would be building a lot of expensive, fragile systems where a spreadsheet formula or a simple workflow tool would have done the job better.
So here is the framework I actually use.
Start with the question: is the input variable?
The first thing I look at is the nature of the input.
If the same input always produces the same output, you dont need AI. You need a rule.
If a field on a form contains a date, and you always need to reformat that date the same way, that is a transformation. Write the function and move on.
AI adds value when the input is variable and the right response depends on understanding the context, not just applying a rule. Documents that differ significantly from each other. Requests that come in different phrasings and need to be interpreted, not just matched. Data that needs to be synthesised, not just transformed.
The rule of thumb: if you can write down exactly what to do in every case, you dont need AI. If you cant, you might.
The three categories
I tend to put workflows into three buckets.
1. Rule-based automation
These are workflows where the logic is deterministic and can be expressed explicitly. File routing based on metadata. Formatting transformations. Triggered notifications. Data validation against a known schema.
For these, use an automation tool. Power Automate, a Python script, a scheduled job, a webhook. Fast to build, easy to maintain, cheap to run. AI adds nothing here except complexity and cost.
2. Structured decision support
These are workflows where the input varies but the decision criteria are well-defined. Think: does this expense claim meet policy? Does this application meet eligibility criteria? Does this patient record match triage category X?
These can often be handled with structured logic, scoring rules, or lightweight ML models. You dont need a large language model. You might need a well-designed decision tree, a regression model, or a rules engine with good test coverage.
Reaching for a GPT-4 class model to answer a binary policy question is like using a combine harvester to cut your lawn.
3. Generative and semantic tasks
This is where LLMs earn their place. Tasks where the output needs to be generated, not retrieved or selected. Tasks where understanding meaning matters, not just matching keywords. Tasks where the input is unstructured and the right output requires interpretation.
Drafting. Summarising. Searching by semantic similarity. Extracting structured data from unstructured documents. Answering questions over a document corpus. Triaging requests that arrive in natural language.
These are genuinely hard problems for traditional software and genuinely tractable for modern LLMs. This is where AI is worth the investment.
The cost-of-error question
One filter I apply regardless of category is: what happens when this gets it wrong?
AI systems make mistakes. The question is whether the workflow can tolerate those mistakes, and what the consequences are.
For drafting a first version of a proposal that a human will review: the cost of an error is low. A human catches it.
For automatically approving a patient care decision or releasing a payment: the cost of an error is high. A human needs to be in the loop, and the system design needs to account for that.
I see organisations try to deploy AI in high-stakes, low-tolerance workflows without thinking this through. That is how you get an incident, and then a blanket ban on AI that sets the whole programme back by a year.
If the cost of a wrong output is high, build the human review into the workflow before you build the AI.
The volume question
The other factor that changes the calculus is volume.
A workflow that happens five times a week might not be worth automating at all, with AI or otherwise. The overhead of building and maintaining the system exceeds the time saved.
A workflow that happens five hundred times a week is a different conversation entirely. The break-even point on development cost arrives quickly, and the compounding gains from removing that bottleneck are significant.
Before building anything, I ask: how many times does this happen? How long does it take each time? What would a 90% reduction in that time actually be worth?
If the numbers dont support investment, they dont support investment. That is true for AI and it is true for any software project.
When I actually recommend AI
After all of the above, here is when I recommend an AI-based solution:
- The input is genuinely variable and cannot be handled by rules or simple logic
- The volume is high enough to justify the development and operational cost
- The cost of error is manageable, either because stakes are low or a human review step is built in
- The organisation has the data needed to make the system work
- There is someone who will own the system after I build it
If all five are true, AI is likely the right tool. If two or three are shaky, we talk about whether a simpler approach would serve better.
The honest bottom line
Most buyers right now are primed to hear "AI" as the answer before they have fully defined the question. My job is not to validate that assumption. My job is to figure out what actually solves the problem.
Sometimes that is a large language model over a document corpus. Sometimes it is a Python script and a scheduled task.
The organisations that get the most value from AI are the ones that use it precisely. Not everywhere, but in exactly the places where it changes the equation. Everything else gets solved with the simplest tool that works.
If youre not sure which category your workflow falls into, that is what the free audit call is for.