When Not to Use AI

I’ve turned down AI projects

The pressure to “do AI” leads to bad decisions. Boards demand it. Competitors announce it. Vendors sell it. And companies build AI projects that were never going to work - not because AI failed, but because AI was the wrong tool for the job.

The most expensive AI project is the one you didn’t need.

Here are seven scenarios where I’ve told clients not to build AI. If you see yourself in any of them, save your money.

Scenario 1: It’s a process problem

Broken workflow + AI = automated brokenness at scale.

A company came to me wanting AI for churn prediction. Their CRM data was a mess - duplicates, missing fields, inconsistent formats. Sales reps entered data differently. Some didn’t enter data at all.

AI wasn’t going to fix this. AI would have predicted churn based on garbage data - confidently telling them which customers would leave, based on records that were wrong.

The real problem: their CRM process was broken. Fix the process, clean the data, train the reps. Then maybe consider AI. Not before.

Rule: If your process is broken, AI automates the breakage. Fix the process first.

Scenario 2: Rules work better

If you can write the rules, write the rules. AI is for decisions too complex or dynamic to encode.

A company wanted AI for invoice approval routing. “We want AI to learn our approval rules.” I asked: “Can you write down your approval rules?” They could. In fact, they already had - in a policy document.

If the rules fit in a document, you don’t need AI. You need a rules engine. It’s cheaper, faster, more transparent, and 100% accurate. AI adds complexity, opacity, and cost for zero benefit.

Rule: If it fits in a spreadsheet or a policy document, don’t build a neural network.

Scenario 3: Your data isn’t ready

Siloed, inconsistent, incomplete data = confident wrong answers.

A company wanted a RAG system for internal knowledge. Their documents were scattered across SharePoint, Google Drive, three different wikis, and individual employees’ laptops. Formats ranged from Word to PDF to Confluence to handwritten notes scanned as images.

Could AI work on this data? Eventually. After months of consolidation, cleaning, and organization. But the AI project wasn’t the right first step - the data infrastructure project was.

Test: Can you describe where your data lives in one sentence? If the answer is “it’s complicated,” you’re not ready for AI. You’re ready for a data audit.

Scenario 4: The ROI doesn’t justify it

Ongoing costs: compute, monitoring, maintenance, talent. AI isn’t a one-time purchase - it’s an ongoing operational expense.

A company wanted AI to automate a process that cost €20K/year in manual labor. The AI system would cost €80K to build plus €15K/year to run. Even if it worked perfectly, payback was 8 years - and AI systems need retraining, updates, and maintenance that would push the real cost higher.

Rule: Do the math before you build. If the problem costs €20K/year and AI costs €80K + €15K/year, it’s a bad investment. Fix the process manually.

Scenario 5: It’s FOMO-driven

“Our competitor launched AI” is anxiety, not a business case.

A CEO called me because their competitor had announced an AI feature. They wanted to match it. I asked: “What does the feature do?” They didn’t know. “How does it help their customers?” They didn’t know that either. “What would it do for your customers?” Silence.

FOMO leads to building features nobody needs. The right question isn’t “what are they doing?” but “what specific outcome can’t we achieve today that AI would enable?”

Rule: If the motivation is “our competitor did it,” don’t build. If the motivation is “we have a specific problem AI can solve,” consider it.

Scenario 6: Your team can’t maintain it

Building is 30% of the work. Running and maintaining is 70%.

A company wanted a custom model for document classification. Their engineering team was two people - both busy maintaining existing systems. Nobody had time to learn MLOps, monitor model drift, or handle retraining.

If your team can’t debug drift, update data pipelines, or maintain the system after the consultant leaves, you’re not building a capability. You’re creating a permanent vendor dependency.

Rule: If nobody on your team can run it after the consultant leaves, don’t build it. Or build something simpler that they can run.

Scenario 7: Compliance risk is too high

EU AI Act risk classification matters. Some use cases carry heavy compliance burdens that may not be worth the value.

A company wanted AI for automated hiring screening - ranking candidates by CV analysis. Under the EU AI Act, this is likely a high-risk system: employment decisions require risk management systems, data governance, technical documentation, conformity assessment, and ongoing monitoring.

The compliance cost (15-25% of project budget) plus the ongoing documentation burden made the project uneconomical for a 50-person company.

Rule: Know your EU AI Act risk category before building. Some use cases are technically possible but economically unwise due to compliance overhead.

What to do instead

Start with an audit. An audit tells you:

• Whether your data is ready
• Whether the ROI justifies the investment
• Whether your team can maintain the system
• What your compliance requirements are
• What to build first (or whether to build at all)

Sometimes the answer is “not yet.” That’s not a failure - it’s a correct diagnosis. Build the foundation first. Data, process, team. Then AI becomes possible.

Or sometimes the answer is “not at all.” Also fine. Not every problem needs AI. Some problems need better processes, cleaner data, or simpler tools.

FAQ

How do I know if our data is ready? Can you describe where it lives in one sentence? Is it in one system or scattered across five? Is it >95% complete? If you can’t answer these confidently, you need a data audit before an AI project.

Can we build the AI and fix the data later? No. Bad data = authoritative wrong answers. AI on bad data doesn’t produce “roughly right” results - it produces confidently wrong results that look credible. Fix the data first.

What if our board demands an AI strategy? Show them this article. Or book an audit and present the findings. A data-driven assessment is more convincing than a consultant’s opinion. “Here’s what we can build, what it costs, and what we need to fix first” is a strategy. “We should do AI” is not.