When NOT to build an AI system

The 7 red flags we look for in a feasibility call

Most AI projects fail not because the technology doesn't work, but because the problem wasn't ready for AI. This guide covers the seven signals we've learned to spot in the first two hours with a client, and why we'll tell you to stop before spending a dollar on development.

1. You don't have a baseline to beat

Before anything else: what does the current system do, and how well? If you can't answer that question with a number, you can't evaluate whether an AI system improves on it. "It's slow" or "people complain" are not baselines. "We process 800 invoices per day with a 12% error rate and 3-day turnaround" is a baseline. Without it, you're flying blind.

2. The data doesn't exist yet

This sounds obvious, but we see it constantly. A team wants to build a recommendation engine, but the user behaviour data is a future collection project. Or they want to detect fraud, but historical fraud labels are inconsistent across systems. The model is only as good as the data that trains it.

3. The data exists but it's a mess

Worse than no data is wrong data. Three systems with three schemas. Inconsistent labels. Missing timestamps. Duplicate records with different customer IDs. Cleaning it takes longer than the ML work. We sometimes spend the first three weeks doing nothing but data engineering before a model sees a single row.

4. The problem is actually just automation

Not every problem needs machine learning. If your process has clear, deterministic rules, conditions that a human could write as if/then statements, it's almost certainly better solved by structured automation than by a probabilistic model. AI adds complexity, drift risk, and explainability challenges. Use it only where you need the probabilistic power.

5. The accuracy requirement doesn't match the domain

"We want 99% accuracy" is a common brief. Whether that's achievable depends entirely on the domain, the data, and the definition of accuracy. A model that's 97% accurate but misses 60% of the critical edge cases is a liability. The metric that matters is the one calibrated to your actual risk, sensitivity vs. specificity, precision vs. recall, not a headline accuracy number.

6. No one owns the integration problem

An AI model in isolation is an academic exercise. It has to connect to your systems, respond within your latency budget, and be maintained by your team. If there's no clear owner of the integration work, if the conversation stops at "we'll figure that out later", the project will stall between development and production.

7. The team expects a plug-and-play handoff

AI systems require operational oversight. Models drift. Data distributions shift. Edge cases appear in production that didn't exist in training. If the expectation is that we hand over a black box that runs itself forever, we're going to have a difficult conversation. The handoff should include runbooks, monitoring dashboards, retraining triggers, and a team that understands what they're running.

If any of these sound familiar, the right move is a feasibility call before a project scope. Two hours, no obligation, we'll tell you honestly what we see.