There is a phrase that has been floating around data circles since the earliest days of computing: garbage in, garbage out. It is one of those sayings that is so old and so obvious that most people stopped thinking about it. And that is exactly the problem.
Right now, companies of every size and in every industry are pouring money into AI. They are standing up large language models, building recommendation engines, training forecasting algorithms, and calling it transformation. And some of them are going to get real value out of it. But a whole lot of them are going to spend a year and a significant chunk of their budget and wind up with a very sophisticated machine that is confidently wrong about almost everything.
The reason is almost always the same: the data going into those models is a mess.
AI Did Not Invent This Problem: It Just Made It Impossible to Ignore
Here is the honest truth: bad data has always been expensive. It has just been easy to hide. When a human analyst is working with a dashboard, they bring context to what they see. They know that the sales numbers for Q3 look weird because of that one reporting issue. They remember that the customer count spiked in February because someone ran a test load. They compensate, they ask questions, they use judgment.
An AI model does not do any of that. It takes whatever you feed it and treats it as ground truth. If your training data has duplicates, the model learns from duplicates. If your historical records have fields that got populated differently across three different system migrations, the model learns all three conventions and has no idea they are supposed to mean the same thing. If your labels are inconsistent because two different people were tagging records by hand with slightly different interpretations of the rules, the model learns that inconsistency as if it were signal.
The model is not broken. It did exactly what you asked it to do. You just asked it to learn from data that did not accurately represent reality.
What “Data Quality” Actually Means in Practice
When people say data quality, they sometimes mean a narrow thing, like whether there are null values in a column or whether a date field is formatted correctly. Those things matter, but they are just the beginning. Real data quality is about five properties working together:
Accuracy Does the data reflect what actually happened? A customer record that shows a purchase of $0.00 because of a payment gateway timeout is not accurate. An inventory count that is three weeks stale is not accurate.
Completeness Are the records you need actually there? Missing data is not just a gap in a table. It is a gap in what your model can learn. If 30% of your customer records are missing a key demographic field, your segmentation model is going to be built on incomplete knowledge of who your customers are.
Consistency Does the same concept mean the same thing everywhere? This is where a lot of organizations quietly bleed. “Active customer” means one thing in the CRM, something slightly different in the billing system, and something else entirely in the data warehouse because each team built their own definition at different points in time. When you pull all three into a feature set, you have created a frankenstein variable that no model can interpret cleanly.
Timeliness Is the data current enough to be useful? A fraud detection model that is working off transaction data that is six hours old is not catching much fraud in real time. A churn prediction model trained on behavior data from two years ago, before you changed your entire product, is predicting behavior that no longer exists.
Validity Does the data conform to the rules it is supposed to follow? Phone numbers with letters in them. Ages of 217. Zip codes with four digits. These are not edge cases. In any system that has been around long enough, they are a regular occurrence. And they corrupt everything downstream.
When any of these five break down, your AI is not working with reality. It is working with a distorted version of it.
The Stakes Are Higher Now Than They Have Ever Been
There was a time when a bad report meant a frustrated analyst and a confused meeting. That was bad, but the blast radius was limited. A person read the number, asked some questions, maybe made a suboptimal decision, and life went on.
AI changes the blast radius entirely.
Think about a recommendation engine that is serving product suggestions to a million customers a day. If that engine was trained on data that over-represented a certain type of customer behavior say, because your data collection had a bug for six months that skewed your event logs then every recommendation it makes is built on that skew. Millions of decisions, made automatically, at scale, every single day, all shaped by a flaw that happened before the model was even built.
Or consider a credit scoring model. If the training data reflects historical biases in lending decisions which it almost certainly does, because historical data reflects historical behavior then the model is going to perpetuate those biases. And it is going to do so in a way that feels objective and algorithmic, which makes it harder to challenge and easier to hide behind.
The operational stakes are high. The ethical stakes are also very real. And they both trace back to the same root: what quality of data did you put into this thing?
Most Organizations Are Not Ready, and Most of Them Know It
The uncomfortable reality is that if you walked into the average enterprise today and asked them honestly how confident they are in their data quality, you would get a lot of nervous laughter. They know the data has problems. They know there are fields that nobody fully trusts. They know there are systems that were never properly integrated and source-of-truth debates that have been going on for years without resolution.
What changes in the age of AI is that you can no longer treat those problems as background noise. They move to the foreground, fast.
I have seen teams spend months building a model, do all the right things from a technical standpoint, train it carefully, tune it well, and then watch it underperform because the underlying data had been quietly wrong for years and nobody had made fixing it a priority. You cannot outmodel bad data. You can try. You will not win.
So What Do You Actually Do About It?
The good news is that this is a solvable problem. It is not a sexy problem. It is not the kind of thing that gets people excited in the same way that deploying a new LLM does. But it is foundational, and organizations that treat it seriously are going to have a significant advantage over those that do not.
Here is where I would start:
Profile your data before you build anything. Before a single model gets trained, understand what is actually in your datasets. Run distribution checks. Look for nulls, outliers, and inconsistencies. Get a factual picture of what you are working with. You cannot fix what you have not measured.
Establish ownership. Every critical dataset should have a named human being who is responsible for its quality. Not a team. A person. Someone who gets paged when something breaks and who has the authority to fix it. Data that is everyone’s responsibility is no one’s responsibility.
Write data contracts. A data contract is a formal agreement about what a dataset promises to deliver — its schema, its freshness, its quality assertions. When upstream systems break those promises, you want to know immediately, not three weeks later when your model has already ingested the bad data and started producing bad outputs.
Build quality checks into your pipelines. Validation should not be a one-time thing that happens before a model launch. It should be running continuously. Every time data moves, you should be asserting that it still looks the way it is supposed to look. The cost of catching a problem early is a fraction of the cost of catching it after it has propagated through your entire stack.
Treat data quality as a product concern, not just a technical one. The people who understand what the data is supposed to mean are often not the same people who are building the pipelines. Business stakeholders need to be part of the conversation about what accuracy, completeness, and consistency actually mean for each dataset. This is not a problem you can solve purely in SQL.
The Organizations That Win Are the Ones That Do the Unglamorous Work
Everyone wants to talk about what model they are using. They want to talk about context windows and fine-tuning and retrieval-augmented generation. And all of that matters. But the organizations that are quietly doing the hard, unglamorous work of understanding and improving their data profiling it, governing it, contracting it, monitoring it, those are the organizations whose AI investments are actually going to pay off.
The AI is only as good as what you feed it. In a world where everyone is using broadly similar models and broadly similar infrastructure, the quality of your data is one of the few places where you can build a real, durable, and defensible competitive advantage.
Garbage in, garbage out. It is the oldest saying in the field. It has never been more true than it is right now.
Cheers!
Jason