Your Data Is the Bottleneck, Not the Model

There's a conversation we have a lot. A company wants to do something with AI, and the discussion immediately turns to which model to use. It's the wrong first question, and the right one is less fun: what shape is your data in?

Because here's the thing nobody wants to hear. The model is largely a solved problem you can rent by the hour. Your data is the part only you can fix, and it's almost always where the project actually gets stuck.

Why the model is the easy part

Frontier models are extraordinary and widely available. The gap between the best one and the second-best one is, for most business tasks, not the gap that decides whether your project succeeds. You can swap models in an afternoon.

You cannot swap in clean data in an afternoon. If your customer records live in three systems that disagree about someone's address, no model will resolve that for you. It will just confidently pick one of the wrong answers. Garbage in, confident garbage out: the oldest rule in computing, now with a friendlier voice.

What "data readiness" really means

Readiness isn't a binary, and it isn't about having a fashionable data platform. It comes down to a few plain questions.

Can you actually get to the data? A surprising amount of valuable information is trapped: in a vendor's system you can't export from cleanly, in PDFs, in someone's personal spreadsheet, in a database only one person understands. If reaching it is a project in itself, that project comes first.

Is it consistent? Two departments calling the same thing by different names, dates stored five different ways, statuses that meant something three years ago and nothing now. Humans paper over this constantly without noticing. Software doesn't, and AI built on top of inconsistency inherits all of it.

Is it current, and will it stay current? A one-time cleanup that rots in a month is theater. The data feeding an AI system has to keep flowing and keep being trustworthy, which means pipelines and ownership, not a heroic weekend.

Governance, without the scary meeting

"Governance" sounds like a committee that slows everything down, and done badly, it is. Done well, it's just answering a few questions before they become incidents.

Who's allowed to see this data, and does the AI system respect that? An assistant that helpfully surfaces salary figures to someone who shouldn't see them is a problem you want to find in design, not in production.

Where did an answer come from? When a system makes a recommendation, you want to be able to trace it back to the source. That's good engineering anyway, and it's quickly becoming a regulatory expectation rather than a nicety, especially in regulated industries and increasingly under new AI-specific rules.

What happens when it's wrong? Not if, but when. Knowing in advance how a bad output gets caught and corrected is the difference between a small fix and a public mess.

Where to actually start

If you're serious about AI, the most useful early investment usually isn't a model or a tool. It's getting honest about your data: finding it, connecting it, cleaning the parts that matter, and putting in light governance so it stays usable.

It's not the glamorous part of an AI project. But we've never seen a data-ready company struggle to add AI, and we've rarely seen a data-poor company succeed at it, no matter how good the model. The bottleneck has a location, and it's almost never the model.