Almost every company I walk into has a list of things they want AI to do. Very few have asked whether the problems on that list need AI.
That is not a criticism of the people writing the list. AI is where the budget and the attention are, the demos are genuinely impressive, and asking for a model is a much easier conversation to have with a board than asking for two weeks of data work. But a real proportion of what gets specified as an AI feature is a well-understood problem with a known direct solution, and the direct solution is usually better on every axis anybody actually cares about.
The search product that was not the problem
One company had bought a natural language search tool to find records in its system. The demo was excellent. In production, the people using it could not find what they needed, and the product got the blame.
The product was fine. It was being pointed at tens of thousands of records whose meaningful content sat unstructured in free-text fields, and no search tool can query that usefully. That part is a data problem wearing a search problem's clothes.
The more interesting part came when I sat down with what the users were actually trying to do. They did not want to have a conversation with a search engine. They wanted to narrow a pool of records by a handful of attributes and see the count change as they went. Dropdown filters over well-structured data, results updating in real time as each filter was applied.
We built that. It beat the AI product on every measure the users cared about, and it was faster to use, because typing a sentence and waiting is slower than clicking three things and watching a number move.
The reason nobody had specified it that way is that the existing filters were bad, so users had learned to describe what they wanted in prose instead. The natural language request was a symptom of the filters, not a requirement.
They had AI back in the 1900s
I have been making a version of this argument for a long time.
In college I took an AI class - yes, they had AI back in the 1900s - and the language was LISP. The assignment was a 4x4 tic-tac-toe player. The intended approach was lookahead: search three to five moves deep, evaluate the resulting positions, pick the best branch. The professor pitted everyone's programs against each other and scored on both wins and processing time.
I did not do lookahead. A 3x3 board is solved - follow a fixed strategy and you can guarantee you never lose - and I suspected 4x4 would yield to something similar. So I wrote a function that scored every open square on the board as it currently stood.
A square that blocked an opponent who was about to win scored 100. A square that blocked them two or three moves out scored 50. A square that won the game for me scored 1000, and one that set up a win in two or three moves scored 10. Squares sit in more than one line at a time, so a square in three rows, columns, or diagonals collected the value from each of them. A corner that blocked an opponent and opened a win of my own scored as both. Score the whole board, take the highest square, move.
It won every game it played. It was also, by a wide margin, the fastest, because it ran in linear time against everybody else's exponential.
That is not a story about being clever. Lookahead is the more general technique and it solves problems my scoring function cannot touch. It is a story about fit. The problem was small and completely understood, and a direct solution beat the general-purpose machinery on both of the measures being scored.
What the direct solution buys you
Cost, obviously. A dropdown does not have a per-token price.
But in a regulated environment the bigger wins are the ones that show up two years later. A deterministic function gives the same answer twice, which means you can test it, and a reviewer can reproduce it. It has no vendor behind it, so no agreement to negotiate and no terms to re-read when the vendor changes them. It does not drift when somebody upgrades a model. And it creates no data flow that anybody has to justify to a customer's security team or a regulator.
Every model you put into an architecture is a vendor, a data flow, an accountability question, and an explanation you will eventually owe someone. Those are all manageable - that is what governing AI in a regulated environment is for - but they are not free, and you should only pay for them when the problem actually requires it.
When it genuinely is AI
I am not arguing against the tools. I use them heavily, they have changed what one senior person can produce in a week, and I have written about running them inside a regulated codebase without breaking anything that matters.
The line I would draw is roughly this. If the inputs can be enumerated and a competent person could write down the rules, write down the rules. If the input is genuinely unstructured, or the variety is a long tail nobody can list in advance, that is where a model earns its place and nothing else will do.
The same product usually contains both. On that recruiting system, parsing a resume is a real AI problem - resumes are unstructured documents in a thousand formats, and no rule set survives contact with them. Searching the parsed result is not an AI problem at all, because by then the data is structured and the question is just a filter. Same feature, same users, two completely different answers, and the mistake was applying the resume answer to the search question.
The question to ask
When somebody asks for AI, ask what they are trying to accomplish, and keep asking until you get to the actual job. Not what they want the software to be - what they want to have happen. Most of the time the answer is something like "I need to find the six people in here who can do this job by Thursday," and that sentence contains no requirement about how.
Then build the thing that does that. Sometimes it is a model. A surprising amount of the time it is good data, a sensible interface, and an algorithm somebody understood forty years ago.