When Not to Use AI

AI is a powerful tool. It’s also an expensive, complex, and sometimes fragile one. Knowing when to use it is important. Knowing when not to use it is just as important, and arguably harder, because the industry narrative right now pushes AI as the answer to everything.

It isn’t. Here’s how to tell.

If your rules fit on a whiteboard

Some problems have clean, deterministic logic. If a user’s account is older than 30 days and their balance exceeds a threshold, flag it. If the input contains these fields, route it here; otherwise, route it there. If the value is outside this range, reject it.

These are if-statements. A simple rule engine, a configuration file, or a few well-written validation functions will handle them faster, more predictably, and with zero training data. When the rules change, you just update the code and deploy. There’s no retraining, no pipeline, no drift to monitor.

The temptation is to use ML “in case the rules get more complex later.” That’s speculative engineering. If the rules are simple today, build for today. You can introduce a model when the need for complexity actually arrives, and as a bonus, you’ll now have a working baseline to compare it against.

If your data fits in a spreadsheet

Machine learning needs both data volume and data variance to generalize. If your dataset has a few hundred rows and a handful of columns, a model doesn’t have enough signal to learn from. It’ll just memorize the training set and fail on new data.

For small, structured datasets, the right tools are the ones that have existed for decades: SQL queries, spreadsheet formulas, basic statistics. A pivot table can answer most questions that people try to train classifiers for. A GROUP BY with a HAVING clause can surface the same anomalies that someone wants to build a detection model for.

That’s a property of the problem. Small data with clear structure has already been solved; the solutions just aren’t fashionable. Well-normalized datasets can help enable powerful queries and automations on your data as needed, and are easier to scale.

If your answer needs to be exact

Models produce probabilities. A classifier that’s 98% accurate sounds impressive until you realize it means 2 out of every 100 predictions are wrong. For many applications, that’s fine. For some, it’s not.

Accounting, compliance, inventory management, billing: these are domains where correctness is a requirement. A billing system that’s “usually right” is a billing system that generates support tickets, disputes, and lost trust. Depending on the industry, a compliance check that misses 2% of violations is a regulatory problem or worse.

If the problem demands deterministic, reproducible, auditable answers, you want deterministic, reproducible, auditable code. Models are often the wrong abstraction for this use case.

If you can’t explain what the model should learn

This one is a little more subtle. Sometimes a team knows they have “a lot of data” and they’ve heard ML can “find patterns.” So they want to point a model at a dataset and see what comes out.

Supervised learning needs labeled examples. Unsupervised learning needs a clear definition of what structure you’re looking for. Both need a problem statement: what are you trying to predict, classify, cluster, or detect?

If you can’t articulate the pattern the model is supposed to find, you have a requirements problem. The fix is a conversation with the stakeholders about what question they’re trying to answer. Once the problem set is clear, the right tool often becomes obvious, and it’s frequently not AI.

If the maintenance cost exceeds the value

Models need monitoring for accuracy drift, retraining when the data distribution shifts, infrastructure for inference, and engineers who understand the pipeline well enough to debug it when something breaks.

For a high-value, high-volume problem, that overhead is justified. For a low-volume problem with a stable solution, it isn’t. If you’re building a model to automate something that happens 50 times a month and a human could handle it in 10 minutes, the engineering and maintenance cost of the ML solution will exceed the value it creates for years.

The goal is to choose the right kind of automation. A cron job, a script, or a simple heuristic might solve the problem at 1% of the cost with none of the fragility or overhead.

When AI is the right call

AI is the right tool when the patterns are complex and can’t be captured simply by hand-written rules. When the data is rich enough to learn from. When the problem benefits from generalization rather than exact determinism. When the value of the solution justifies the cost of building and maintaining it.

Image classification, anomaly detection in high-dimensional data, natural language understanding, predictive maintenance on sensor streams: these are real problems where ML delivers real value that no amount of if-statements can replicate. I build these systems every day.

I reach for it deliberately, when the problem calls for it, and not by default.

Picking the tool

The best engineering is knowing which tool to reach for. Sometimes that’s a model. Sometimes it’s a SQL query. Sometimes it’s a conversation with the person who asked for AI in the first place, to figure out what they need.

There’s no shame in solving a problem with boring technology. The goal was always to solve the problem.

If you’re weighing whether your product actually needs machine learning, that’s the conversation I like having. It’s the first step of every AI integration project I take on.