AI Needs Better Data, Not Bigger Models

The uncomfortable bottleneck

When an AI project disappoints, the usual reaction is to ask whether we need a larger model. More parameters, more GPUs, more money disappearing into a cloud bill with the quiet efficiency of a Victorian tax collector. It is an understandable instinct. Bigger models are visible, marketable and reassuringly expensive.

But in most real deployments, the model is not the main problem. The data is.

I have spent enough time building temperature-monitoring and IoT systems to be suspicious of anything described as “plug and play”. Sensors drift. Gateways lose connectivity. Someone changes a probe and neglects to record it. A freezer door gets left open during a delivery, and suddenly a perfectly reasonable reading looks like an equipment fault. If you feed that history into an AI system without understanding it, the system will learn patterns all right. Some will merely be nonsense with excellent confidence.

That is not a failure of artificial intelligence. It is a failure to treat data as evidence rather than as a pile of files.

Data has a biography

Every useful data point should come with a story: where it came from, what measured it, when it was collected, what changed around it, and whether anyone had a reason to distrust it.

Take a cold-storage alerting system. A temperature value of 8°C might mean a genuine refrigeration failure. It might mean a defrost cycle, a sensor taped beside an evaporator, a loading bay door open for twenty minutes, or a battery-powered device having a small existential crisis. Without context, the number is just a number. With context, it becomes operational information.

The same applies to AI training data. A customer-support model needs to know whether a ticket was actually resolved, not merely marked closed because someone wanted their dashboard to look less alarming before Friday afternoon. A predictive-maintenance model needs reliable records of faults, repairs and normal operation. A medical model needs labels produced under a defined clinical process, not whatever happened to be typed into a field at 4:57 pm.

Data quality is not just removing duplicates and filling blank cells. It is understanding the process that produced the data. That work is less glamorous than announcing a new foundation model, which is unfortunate because it is also where much of the value lives.

Bigger models can amplify small mistakes

A larger model can extract more subtle signals from data. That is useful when those signals are real. It can also extract subtler forms of bias, leakage and operational confusion. Give it a dataset where the answer has accidentally leaked into an input field, and it will look astonishing in testing. Deploy it, remove that accidental clue, and it will perform like a cat asked to complete your tax return.

I have seen versions of this in sensor systems. A model appears highly accurate because it learns that one device identifier is associated with failures. The identifier is not a physical cause. It is simply a batch of sensors installed at a troublesome site. Move those sensors elsewhere and the clever model becomes rather less clever.

This is why validation must resemble the real world. Split data by time, site, customer, device generation or operating condition where appropriate. Ask what will be different on deployment day. If a model has only ever seen one warehouse, one shift pattern or one way of recording faults, it has not learned the business. It has learned the wallpaper.

Start with the decision, not the dataset

Before collecting more data or choosing a model, define the decision you want to improve. Who will act on it? How quickly? What happens when the system is wrong? What information can that person realistically use?

For a temperature-monitoring application, “predict refrigeration failure” is too vague to be useful. A better question is: can we identify a likely compressor problem early enough for an engineer to intervene, while keeping false alarms low enough that site staff do not start treating alerts as decorative wallpaper?

That framing tells you what data matters. You may need compressor run time, ambient temperature, door activity, defrost events, maintenance logs and alert acknowledgements. You may also discover that the outcome label is weak because nobody consistently records the precise fault. That is an awkward finding, but a valuable one. Better to learn it before training a model the size of a small country’s electricity demand.

Often, improving the underlying workflow produces more benefit than adding AI. If engineers record fault codes consistently, or staff distinguish planned maintenance from emergencies, you have made future automation possible. Good data practices are useful even if the AI programme is postponed. That is a pleasantly rare property in technology projects.

Human judgement remains part of the system

The best AI systems I have worked with do not pretend people are a nuisance to be designed out. They give people clearer information, surface uncertainty and make it easy to correct mistakes.

This matters particularly in environments where the consequences are real: healthcare, accessibility, safety monitoring, finance, and public services. As a disabled technologist, I am especially wary of systems trained on neat assumptions about how people behave, communicate or complete tasks. Disabled people are often treated as edge cases, despite being remarkably common in the inconvenient real world. Data that excludes us produces products that exclude us, then someone calls the result “unexpected user behaviour”.

Invite the people affected by a system into its design and evaluation. Capture feedback. Keep an audit trail. Make it possible to challenge an automated decision without requiring a scavenger hunt through three portals and a PDF form designed by an enemy of wrists.

Better data means more representative data, but it also means data collected with care, consent and a clear purpose. The goal is not to hoover up every possible signal because storage is cheap. The goal is to know enough to make a useful, accountable decision.

Larger models will continue to have their place. Some tasks genuinely need their breadth and capability. But for most organisations, the next meaningful improvement will not come from adding zeros to a parameter count. It will come from asking better questions about the data already sitting in their systems, complete with its quirks, gaps and rather human history.