5 Common Data Pitfalls.

When an AI project fails, the postmortem usually points at the model. It underperformed. It did not generalise. It gave inconsistent results in production.

But pull the thread a little further back, and the real story is often much earlier in the process — in the data itself, and in decisions (or non-decisions) made before a single model was ever trained.

The Data Understanding phase exists precisely to catch these problems before they become expensive. Here are five of the most common pitfalls, and what to do about each.

1. Data Redundancy or Gaps.

Redundant data can create a false sense of confidence. If your dataset is full of near-duplicate records, it can look like you have more information than you actually do — the model may just be learning the same pattern over and over, rather than a genuinely diverse set of examples.

Gaps are the flip side of the same problem. Blind spots in your data — customer segments, time periods, geographies, or edge cases that simply are not represented — do not announce themselves. They show up later, quietly, as a model that performs unevenly or fails on exactly the cases nobody thought to check.

What to do:

Audit your dataset for both duplication and coverage before you start building. Ask not just "how much data do we have" but "what is missing that we would expect to see?"

2. Poor Quality.

Inconsistent formatting, incomplete fields, and poor labeling are some of the most common — and most damaging — issues in real-world datasets. A field that is sometimes a date, sometimes a string, and sometimes blank will quietly degrade everything downstream of it. Poorly labeled training data teaches a model the wrong lessons, and those errors compound as the model scales.

What to do:

Build data quality checks into your process early, not as a final cleanup step. Spot-check labels. Look for inconsistent formats. Treat data quality as a design requirement, not an afterthought.

3. Unsupported Formats.

Sometimes the data you need exists — but it is trapped in a format your tools and pipeline cannot actually ingest. Legacy file types, proprietary export formats, scanned documents without OCR, or systems that do not easily integrate with your data pipeline can all quietly stall a project.

What to do:

Confirm early whether your data is technically accessible, not just theoretically available. "We have the data" and "we can actually use the data" are two very different statements.

4. Unclear Permissions or Ownership.

This one tends to surface at the worst possible time — often after a model has already been built. Legal, compliance, or access issues around who owns a dataset, what it can be used for, and under what conditions can bring a project to a halt, regardless of how good the underlying model is.

What to do:

Clarify data ownership and usage rights as part of your initial data inventory, not as a legal review that happens right before launch.

5. "More Data Is Always Better" Thinking.

It is tempting to assume that the more data you throw at a model, the better it will perform. In practice, more data that is low-quality, unrepresentative, or biased can make a model worse, not better — and it can do so in ways that are hard to detect until the system is already deployed and producing skewed results.

What to do:

Prioritise representativeness and quality over sheer volume. A smaller, well-understood dataset will usually outperform a massive, messy one.

Measure Twice, Cut Once.

Every one of these pitfalls is avoidable — but only if you catch it during the Data Understanding phase, before you move into cleaning, preparing, and modeling. None of these issues get easier to fix once a model is already built around flawed data. They just get more expensive.

Before your team moves forward, it is worth running through a short checklist:

> Have we checked for redundancy and gapods in our dataset?

> Have we validated the quality and consistency of our data?

> Can our tools and pipeline actually ingest the formats we have?

> Do we have clear answers on data ownership and permissions?

> Are we prioritizing data quality and representativeness over raw volume?

If you can answer yes to all five, you are in good shape to move forward. If not, better to find out now than after the model is already built.