The exciting part of AI is the model. The reason it ships, or doesn't, is almost always the data and the operations around it.
The part of AI that gets attention is the model. The part that determines whether anything reaches production is the data and the operations around it. It is unglamorous, it does not demo well, and it is where the majority of real engineering effort goes — because it is where projects actually succeed or fail.
Most AI projects do not fail because the model was not good enough. They fail because the data was not ready and the operations were never built.
Start with data. A prototype runs on an extract someone pulled into a notebook. A production system runs on live data, which means pipelines that are reliable, monitored, and governed; access that is controlled and auditable; and quality that is measured rather than assumed. The path from extract to live, governed data is often the longest part of the whole project, and skipping it is the most common reason pilots never go live.
Data quality is not a one-time clean-up. The data that feeds a production model changes — sources shift, formats drift, upstream systems are updated without warning. A model that was accurate on last quarter's data can quietly degrade on this quarter's. Treating data quality as continuous, with monitoring and alerts, is the difference between a system that holds up and one that fails silently.
Then there are the operations — the unglamorous discipline of MLOps. Models and prompts need versioning, so you know exactly what is running and can roll back when something breaks. Deployments need to be repeatable, so shipping a change is routine rather than an event. And everything needs observability, so that when behaviour shifts you can see it before your users do.
The part that determines whether anything reaches production is the data and the operations around it.
Evaluation belongs in this pipeline, not beside it. Every change to a model, a prompt, or a data source should be scored automatically against the cases that matter before it reaches production. A system without that gate is one bad change away from a regression no one notices until a customer does.
Cost and performance are operational concerns too. The same task can cost wildly different amounts depending on the model, the caching, and the architecture, and a system that is accurate but uneconomic has not really shipped. Measuring cost per successful outcome — and tuning it — is part of running AI, not an optimisation for later.
None of this is exotic. It is the ordinary engineering discipline that any organisation already applies to the software it depends on, pointed at AI. The mistake is imagining that AI is exempt — that because the model is clever, the boring parts can be skipped. They cannot, and skipping them is precisely why so much AI stays stuck in prototype.
The model is what makes AI interesting. The data and the operations are what make it dependable — and dependable is the only kind worth putting in front of real users.
