Every client brief mentions AI now. "Use AI to process this." "Can we add AI to automate that?" In 2026, AI has become the default answer before anyone has even asked the question properly.
After 120+ automation projects, here's what we've learned: most of the time, you don't need it. And when you add AI where it isn't needed, you get slower workflows, higher per-run costs, unpredictable outputs, and something that's genuinely harder to debug when it breaks.
But sometimes AI is the only thing that makes an automation possible at all.
Here are two real projects that show both sides.
The ask: A client wanted AI to extract data from supplier invoices — vendor name, invoice number, date, line items, totals — and push it into a Google Sheet for processing.
Reasonable ask. Invoice formats vary. Fields are in different positions on every document. AI seems like the obvious tool.
What we found first: Before building anything, we looked at 3 months of invoice history. Of all invoices received, 95% came from just 12 vendors. The same 12 vendors, every month, with identical formats. The remaining 5% were one-off suppliers with low value and low frequency.
What we built instead: Template-based extraction with OCR and validation rules. One template per vendor (12 templates total). Each template maps exact field positions for that vendor's format. Validation rules catch anomalies — if a total doesn't match the sum of line items, it flags for human review instead of silently passing bad data downstream.
The result:
If we'd used AI, we would have added per-call cost, introduced occasional hallucination risk on amounts (the worst field to get wrong on an invoice), and built something harder to audit when an extraction goes wrong.
The 5% of irregular invoices? Those go to a human. That's the right answer for edge cases — not an AI model that might confidently extract the wrong number.
The ask: A client ran a marketplace connecting two sides — customers looking for something, and sellers offering it. Both sides filled intake forms. The problem: the fields were open text. No dropdowns, no categories, no structured data. It had to be that way — the use case was too varied to force into fixed options.
They needed the right sellers to be surfaced for each customer. Rule-based matching — keyword matching, exact field comparison, fixed scoring weights — wasn't going to work. Two sellers might describe the same offering in completely different words. A customer might describe their need in a way that matched a seller perfectly but shared zero keywords.
What we built: A JotForm → Google Sheets → Claude API pipeline.
The key detail: the matching isn't fully automated. Claude surfaces the best matches and explains why. A human makes the final decision. That's intentional — the client wanted judgment in the loop, not a fully automated introduction.
Why AI was the right call here: The input was genuinely unstructured and couldn't be made structured without breaking the use case. Semantic understanding — matching intent and meaning, not keywords — was the actual requirement. No rule-based system handles that well. Claude does.
These two projects are not unusual. They represent a pattern we see constantly:
You probably don't need AI if:
AI genuinely helps when:
The question we ask before any build: "Can I write the rules for this?" If yes — even if the rules are complex — rule-based automation is almost always faster, cheaper, more reliable, and easier to debug. If the answer is genuinely no, because the variation is too wide or the input too unstructured, that's when AI earns its place.
Adding AI where it isn't needed isn't just wasteful — it creates real problems:
None of this means AI is bad. It means it's a tool with specific strengths, and like every tool, it's only right for specific jobs.
Not sure if your process needs AI or not? We'll look at it honestly and tell you — including if the answer is "you don't need us, here's a simpler path."
Talk to us