A company receives ten thousand events a day. Orders, quality-control photos, customer tickets, sensor readings. Somebody has to decide which ones need action, how fast, and what it costs to get it wrong. That is the problem. Not whether a model can describe those events in elegant prose.
Yet many of the offers I see start from the same place: plug a large language model into an interface and call it AI. It demos beautifully. It also answers a question nobody in operations asked.
The temptation of the universal model
I understand why the LLM is the default. The demo takes an afternoon, the input can be messy, the output is easy to show a board. And modern LLMs are no longer just chatty: they can return JSON that follows a strict schema. OpenAI's own documentation on Structured Outputs is honest about the catch, though. The schema can be valid and the values inside it can still be wrong.
A valid format is not a correct decision. It is a well-dressed guess.
Two questions, not one
Most confusion comes from putting every term on the same axis. There are two separate questions. What does the system do: estimate, classify, detect anomalies, generate, optimise? And how does it process data: statistical model, trees, convolutional network, text encoder, state-space model, generative transformer, graph network?
"Machine learning versus AI" is a false fight (ML is the container, LLMs live inside it). The real comparison is between methods chosen for the task and an LLM used as the starting point for everything.
Take tabular data: churn, priority, the risk of an administrative error. Start with logistic regression or a plain rule as a baseline, then trees and boosting, then neural networks if the evidence justifies them. Grinsztajn, Oyallon and Varoquaux found tree-based models highly competitive on medium tabular datasets. A broader NeurIPS 2023 study by McElfresh and colleagues showed there is no universal winner. The lesson is not "trees win". The lesson is: run the comparison.
Images want vision models that read local patterns. Event streams want models that respect order: statistical baselines, recurrent models, state-space models like Mamba, which processes sequences with linear scaling in length. Architectural properties, mind you, not a guaranteed result on your plant's data. A text encoder can route a ticket without writing a paragraph about it.
Where the generative model belongs
None of this is anti-LLM. Explanations, open requests, synthesis across messy material, a human exploring a flagged case: that is home ground for a generative model. Sometimes the LLM is also the best tool for a narrow task. The test decides, not the taxonomy.
What enters a company is rarely one model. It is a chain: data, evaluation, rules and thresholds, review or action, monitoring. Different models at different links. Code that says what happens when a field is missing, a probability is uncertain, or an error is expensive. The market already has a name for this, Decision Intelligence, and I am not claiming to have invented it. The difference is in how you design and verify the concrete decision system.
Why this matters for your business
Before choosing a model, fix a baseline, human or software. Measure by segment: precision, recall, false positives, false negatives, calibration if you use probabilities, cost per case and review load. Agree with the business which error hurts most. Then offline test, pilot inside the real flow, and monitor after. A probability is useful only if it is calibrated on the cases where it will be used, and deep classifiers are known to be confidently wrong outside the data they saw.
The events keep arriving, whatever model is fashionable this quarter. The question worth asking a vendor, any vendor, is simple: which decision improves, against which baseline, with which residual errors, and who owns them? The architecture follows the answer.
Pan