Your AI Problem Isn't AI. It's Your Data.

It's a Tuesday morning and someone in the business asks a reasonable question of a reasonable agent: which past vendors in our area are approaching seven years of ownership, and which of them hasn't heard from us in eighteen months?

The model understands the question perfectly. It knows what a vendor is, why seven years matters, what a lapsed relationship costs. Then it goes looking for the answer.

The contact exists three times in the CRM — once under one owner's name, once under the other's, once as a mobile number with no name attached. The sale date lives inside a settlement statement scanned in 2019 and saved as an image, so it isn't text at all. The last conversation is a free-text note that reads "spoke re market, call back spring", written by an agent who left the business two years ago. A chunk of the older history sits in archive boxes that were never digitised because nobody thought they'd need them.

The agent returns a confident list of fourteen names. Four of them sold again last year. Nobody can tell from the output which four.

Nothing in that sequence was a model failure. The reasoning was sound. The data was not.

The model was never the bottleneck

Iron Mountain released research this month that puts numbers to what most operators already feel in their bones. Their study, The Information Supercycle, surveyed organisations globally through Vanson Bourne and found that 86% had AI projects delayed or derailed by data problems in the past twelve months. In the same breath, 95% said using data to improve business outcomes is a top priority.

That gap is the whole story. Leadership teams are funding AI roadmaps on the assumption that capability is the constraint. It isn't. Only 39% of respondents describe their information as digitised and structured — centrally managed, indexed and usable for analytics and AI. The other 61% are working from some mixture of silos, unstructured documents and things nobody has looked at since they were filed.

The friction shows up exactly where you'd expect. More than half cite disconnected systems and departmental silos as the main obstacle. Slightly fewer point at legacy formats and physical archives. And four in ten organisations report spending at least 41% of their AI project timelines on manual data preparation.

Read that last figure again. For a meaningful share of businesses, close to half of every AI project isn't AI. It's someone cleaning spreadsheets.

Why agents make it worse, not better

When AI was a chat window, bad data produced a bad answer, and a human read it, frowned, and moved on. The person was the safety layer, and most of the time it held.

Agents remove that layer by design. The entire point of an agent is that it acts — it writes the record, sends the email, schedules the call, updates the pipeline. A human reading a flawed report applies judgement. An agent acting on a flawed record executes it, at volume, at three in the morning.

Iron Mountain's own framing makes the same point: the foundations become essential precisely as agents move from producing answers to taking actions across workflows. I'd go further. In an agentic system, data quality isn't an input to performance. It's the boundary of what you can safely automate at all.

This connects directly to something I wrote about recently — the knowledge that never made it into words. That piece argued that AI capability tracks documentation density, not task difficulty: agents struggle where the expertise was never written down. The data problem is the uncomfortable sequel. Even the knowledge that was written down is frequently unreadable — trapped in scanned images, duplicated across systems, stripped of the context that made it meaningful.

There's a governance edge to this as well. The research found that 70% of organisations can't effectively track the lifecycle of the data feeding their models — where it came from, how it moved, whether it's still current. I've argued before that an AI workflow isn't in production until it can fail safely, and that ambiguity should fail closed. But you can only fail closed on ambiguity you can detect. If you can't tell where a record came from, you can't tell whether to trust it, and the system will cheerfully proceed as though it does.

Silos are the SaaS hostage problem wearing a different coat

That 56% figure on silos deserves more attention than it's getting, because it isn't really a data problem. It's a procurement history.

For two decades, the default answer to every internal need was to buy. Each purchase came with its own database, its own schema, its own idea of what a customer is. Each one was a reasonable decision in isolation. Together they produced the landscape most organisations now live in: the same person represented six different ways across six different vendors, with the ability to reconcile them sitting at each vendor's discretion and on each vendor's price list.

That's the SaaS hostage problem in its purest form. Your data lives in their system, and your ability to make it useful depends on decisions they made for their roadmap, not yours. "Buy by default" didn't just cost licence fees. It fragmented the very asset AI now depends on.

Which is why the build/buy/partner conversation looks different this year. The question is no longer only who builds the feature? It's who owns the record? — and whether you can get it out, clean, whenever you need it.

What actually works

There's a temptation, when research like this lands, to commission a data transformation program. Eighteen months, a steering committee, a lake of some description. I'd resist it. Most of those programs end with beautifully governed data that nobody has yet put to work.

What has worked for me, across the businesses I run and the ones I advise, is narrower and more impatient.

Start from a decision, not a dataset. Pick one outcome you want an agent to own — the vendor re-engagement list, the lease renewal reminder, the lead that needs a call inside five minutes — and work backwards to the minimum data that decision actually requires. That's usually far less than the full estate, and it gives the clean-up work a deadline and a payoff.

Make one system authoritative for each entity, and say so out loud. Duplicates aren't a hygiene issue; they're a disagreement between systems about what's true. Agents can't resolve that disagreement. People have to decide it once, and the architecture has to enforce it afterwards.

Capture lineage at write time. Every record an agent creates or changes should carry where it came from and why. It's cheap when you build it in and almost impossible to reconstruct later — which is precisely the 70% problem.

Scope agents to data you can vouch for. Let them act autonomously where the record is clean and governed, and route everything else to a human with the ambiguity flagged. The boundary will move as the data improves. That's the point.

And treat data preparation as product, not project. If 41% of the timeline is going to data work regardless, stop treating it as overhead to be minimised and start treating it as the asset being built. The model will be superseded within a year. The clean, owned, well-labelled record of your customers will compound.

On paying for it

The third claim in Iron Mountain's research is that organisations can fund AI by reclaiming spend from outdated physical and digital infrastructure. It's worth noting that this comes from a company whose business is storing and digitising records, so read it with the appropriate raised eyebrow.

The underlying logic is still sound. Most businesses are carrying costs for storage, duplicated systems and licences that exist mainly to keep old information in place — warehoused rather than used. Moving that spend from keeping information to making it usable isn't a vendor's sales line so much as basic capital discipline.

And there's a cost-per-outcome argument underneath it. An agent's output is only as cheap as it is correct. An outcome built on bad data costs you twice: once to produce, and again to discover, unwind and apologise for. Sooner or later, the bill comes due — and with agents, it arrives faster and in larger denominations.

Who owns the wrong answer

Go back to that list of fourteen names. When four of them turn out to be wrong, someone will ask who's accountable. The instinct is to blame the AI. But the agent did exactly what it was asked, with exactly what it was given.

That's the accountability gap in its most practical form. The model can't own the answer, because it never owned the data. The organisation did — and for most organisations, right now, that ownership is theoretical.

The leaders who get the most out of AI over the next two years won't be the ones with the best models. Everyone will have access to the same models. They'll be the ones who quietly did the unglamorous work of knowing what their data is, where it lives, and whether it's true.

Your AI problem isn't AI. It never was.

Figures cited are from Iron Mountain's The Information Supercycle research (conducted by Vanson Bourne, released October 2026) as reported by IT Brief Australia.