When AI Is Overkill: 4 Patterns Where We Say “Don’t Buy It”

Why This Post

The AI market in 2026 is loud. Every vendor has a demo, every industry an "AI-first strategy", every consultant a 30-slide pitch. So do we — but we have committed to saying honestly, in the first conversation, when AI is not the right lever. That is not noble — it is good business. Poorly fitting AI projects die in the beta, burn budget, and poison the relationship with the company's own IT.

Four patterns we see regularly and where we say "don't buy it".

Pattern 1 — Inbound Below ~20 per Day for Classification or Triage

Example: an SME wants a sales/support triage agent. Inbound volume: 15 emails a day, 70 % of them from three known supplier domains.

Our recommendation: classic rule-based routing is enough. A regex on the sender, a whitelist for the regular customers, a few subject patterns, done. Effort: one to two days. Maintenance: an occasional new rule.

Using an LLM to classify 15 emails a day is over-engineering: you pay token costs and carry model risk for a problem an if-then list solves. Only when volume AND variability grow at the same time — that is, when 80+ inbound items a day come from an unpredictable mix of sources — does the agent pay off. Not before.

More on this in Use Case 09, where we name the thresholds explicitly.

Pattern 2 — A One-Off Task or One-Off Migration

Example: a company plans a one-off data migration from an old CRM into a new one. 4,000 records, five fields, clear mapping logic. "Can you do that with an agent?"

We can. But you shouldn't. For a one-off task with no recurring value, AI makes the project unnecessarily expensive: setup, eval, guardrails, audit trail — all effort that is used once and then expires. An experienced migration consultant does this faster and cheaper with Excel, an ETL script, and three hours of review.

It looks different when the migration recurs structurally (e.g. quarterly inventory transfers, or a company that regularly integrates acquisitions). Then building an agent-supported workflow pays off — see Use Case 01 Agentic SAP Migration, where that is exactly the picture.

Pattern 3 — Very Stable, Schema-Conformant Data Sources

Example: a fiduciary firm receives standard payroll statements from ten clients every month — all as structured XML files following the same schema. "Can we bring that into the system via AI?"

We can, but classic ETL is better here. If the data:

• has a stable schema (fields don't change every month),
• arrives in a machine-readable format (XML, JSON, structured CSV),
• and comes in without interpretive ambiguity (no "different each time" per supplier),

then a deterministic ETL pipeline is simpler, faster, cheaper — and you don't have to evaluate it. An LLM here only adds another source of silent errors.

AI gets interesting when the format becomes creative: incoming invoices in ten different layouts, contracts with handwritten amendments, forms with no fixed schema. There, the document extraction pipeline (Use Case 07) is exactly right. For pure structured data, however: ETL.

Pattern 4 — Knowledge Base Below ~50 Documents

Example: a startup with 25 employees wants a RAG system for its internal knowledge base. Available: an HR handbook (12 pages), three IT policies, a collection of onboarding notes.

Our recommendation: write a good wiki. With fewer than ~50 sensibly delineated documents, building a search pipeline does not pay off. Notion, Confluence, or a well-maintained README in SharePoint with a clear structure solve the problem better. Full-text search is enough for collections this small.

RAG becomes worthwhile when:

• the knowledge base is substantial (rule of thumb: 200+ documents),
• the search frequency is noticeable (several requests a week, not a quarter),
• answer quality matters in a measurable way (e.g. because HR otherwise answers the same five questions every week).

For small knowledge bases, RAG produces a nice demo effect but costs maintenance time that the low usage never recovers. Concrete setup details in Use Case 06 RAG over an internal knowledge base, and thresholds in the FAQ.

Why We Work This Way

Three reasons we prefer to run discovery sessions in which we sometimes advise against a project, rather than pushing every lead into a PoC:

When AI Is the Right Lever After All

So that this post doesn't become a "never AI" manifesto: there are many use cases where AI is clearly superior. Three patterns we recommend with conviction:

• Variable inbound with real volume — 100+ emails a day from changing sources → triage agent, no question.
• Creatively structured documents — incoming invoices, contracts with handwritten amendments, forms with no fixed schema → document extraction with a review queue.
• Knowledge bases of 200+ documents with high search frequency — HR, IT, contract templates, Q&A → RAG with citations and escalation for sensitive topics.

In these patterns, AI delivers days-instead-of-weeks improvements with an audit-ready trail. The use-case library shows twelve such patterns in full depth.

Conclusion

AI is powerful — and powerful tools are not appropriate in every situation. Four patterns where we would advise you against it:

• Pattern 1 — Inbound below 20/day → rule-based routing is enough.
• Pattern 2 — One-off tasks → manual processing is cheaper.
• Pattern 3 — Structured, schema-conformant data → classic ETL is better.
• Pattern 4 — Knowledge base below 50 documents → maintain a wiki and a glossary.

If you're unsure whether your use case falls into one of these patterns, or whether AI is the right lever after all: a discovery call clarifies that in an hour — and costs you nothing. Even if the result is that we shouldn't start a project together.

More on strategic consulting: AI Consulting — architecture reviews and strategy.