Cloudera published a report on 11 August 2026, based on a survey conducted by Wakefield Research among 1,500 Enterprise Architects, Cloud Infrastructure Leads, and Data Architects worldwide. Among its findings: 77% of organisations are actively using AI, and 95% said they had delayed or cancelled an AI initiative in the past year because of data governance, compliance, or regulatory challenges.
At first this reads like an AI problem — a model that isn't ready, a vendor that overpromised, a governance process too slow for the pace of adoption.
It usually isn't. It is an architecture problem that AI has made harder to ignore.
The same report found that 72% of respondents said their current data architecture needs a significant overhaul to support AI going forward, 73% said AI has made data governance more complex, and 84% reported rising infrastructure costs tied to AI workloads. A separate 2026 State of Infrastructure in the Agentic AI Era survey from Google Cloud found that 83% of organisations believed they needed infrastructure upgrades to support production-grade agentic AI. Different vendors, different survey instruments, similar shape of finding. None of these numbers describe a model falling short of its benchmark. They describe enterprises discovering, one AI initiative at a time, what was already true about their systems.
That discovery is not new. What's changed is who is doing the discovering.
We built enterprise systems for humans to work around
Most enterprise architecture, quietly and reasonably, assumes a person sits between systems. A person interprets an ambiguous field. A person reconciles two reports that don't quite agree. A person remembers that the documented owner of a process left the organisation two years ago and the real owner is someone else entirely. A person knows which of three "final" spreadsheets is actually final.
This isn't a failure of judgement by the people who built these systems. Integration budgets run out. Documentation falls behind reality within months of being written. Ownership changes as teams reorganise, and nobody updates the diagram. Over years, an enterprise accumulates small gaps between what a system says and what is actually true — and humans, without much fanfare, learn to fill them.
A finance analyst knows which report to trust and which one to quietly ignore. An operations engineer knows which field in the CMDB hasn't been accurate since a migration three platforms ago. A support engineer knows exactly who to call when the automated workflow stalls, even though the process document names someone else. A manager understands what a status label like "in review" actually means in practice, which is different from what it means on paper.
This is tribal knowledge, and many mature organisations run on a substantial amount of it. It isn't a scandal. It's how complex systems, built and rebuilt over years by different teams under different pressures, continue to function. The compensating mechanism was always human judgement, applied quietly, at the point where the architecture fell short.
Agents remove the human glue
An AI agent does not automatically inherit that judgement. It inherits the architecture — as documented, as connected, as governed — and works from that. When we ask an agent to discover the right information, understand what it means, decide what to do with it, and act, every gap that a human used to fill in silently becomes a gap the agent has to navigate on its own.
Discover. Most enterprises have more undiscoverable data than they assume — not hidden, just unreachable through anything an agent can query.
Understand. A field called status with no data dictionary behind it means something different to every team that populates it. A human notices this ambiguity and asks someone. Unless it has been designed to recognise ambiguity and seek clarification, an agent may proceed using whatever context is available to it.
Decide. If the actual approval process differs from the documented one — and in most organisations, somewhere, it does — an agent following the documented version can produce an outcome that looks confident and is wrong.
Act. Where the boundary between what an agent may change on its own and what needs a person to approve was implicit — understood by experienced staff, never actually written down — the agent has no structural way to find it.
None of this is a criticism of any particular model. The same gap would show up with any sufficiently capable agent placed into the same environment. The architecture is being tested by something that, for the first time, has no informal workaround available to it.
Five things AI agents keep exposing
A handful of patterns show up repeatedly once agents start touching real enterprise workflows.
Data without meaning. A table full of values is not the same as information an agent can act on safely. Without clear definitions, ownership, and freshness, an agent can treat stale or ambiguous data with the same apparent confidence as good data, because nothing in the data itself signals the difference.
Ownership that exists only on paper. Most organisations can produce a RACI chart for almost anything. Fewer can say, without checking, who is genuinely accountable for a given dataset or process today. An agent cannot walk down the corridor and ask. It needs that answer to already be structurally true.
Integration built for screens, not capabilities. A great deal of enterprise workflow still assumes a person clicking through an interface, reading context on screen, and making a judgement call before the next click. Agents need something different: reliable APIs, defined contracts, and clear permissions.
Governance designed for occasional human access. A governance model built around periodic human review — quarterly access reviews, manual sign-offs — was never designed for something that can query a dozen systems in the time it takes a person to open one. Machine-speed access needs a different kind of control, not the old one applied more sternly.
Processes full of undocumented exceptions. Every organisation has a documented process and a real process, and the two are rarely identical. Humans absorb the difference without thinking about it. Automation, sooner or later, encounters the gap directly.
None of these problems are exotic. Most experienced architects will recognise all five without an example. What has changed is that these gaps used to be invisible, absorbed by people, and now they surface as a failed agent action, a wrong answer, or a governance review that stalls.
AI readiness is not an AI checklist
None of this is fixed by buying a better model, a copilot licence, or an agent platform. Those tools sit on top of the architecture; they do not repair it. A simple way to think about readiness is five questions, in sequence:
Information — is the data an agent depends on accurate, current, and clearly defined? Context — does that information carry enough meaning for an agent to interpret it correctly, not just retrieve it? Authority — is it clear what the agent may decide alone, and what must stay with a person? Integration — can the agent reach the systems it needs through something more durable than a login and a screen? Observability — when the agent acts, can anyone reconstruct what it did, why, and on what basis?
This isn't a maturity model to score against. It's a set of questions worth answering honestly before the next agent goes into production, because a weak answer to any one of them tends to explain most of the incidents that follow. My earlier piece on why AI readiness is an architecture problem, not an AI problem, goes further into the foundations these questions depend on.
Where this leaves the enterprise architect
The temptation, faced with a fast-moving AI market, is for the architect to become the organisation's product catalogue — tracking which platform to buy, which vendor claims to trust, which copilot to standardise on. That's not where the value sits.
The more useful questions are quieter and older than any AI platform. What information will this agent depend on, and who owns it? What context changes its meaning? Which decisions may it make on its own, and which stay with a person? Which systems is it permitted to change? How will anyone reconstruct what it did after the fact, and how quickly can its access be revoked if something goes wrong? I set out a fuller version of this checklist in an earlier piece on enterprise AI agent architecture.
These are architecture questions. They were true before agents existed, and they remain true now — the difference is that an agent will find every place where the answer was never actually settled. It's the same discipline I've written about in the context of what enterprise architects actually do day to day, applied to a faster-moving and less forgiving situation.
Architecture becomes visible when machines join the workflow
An organisation can run for years on architecture with real gaps in it, because people are remarkably good at absorbing those gaps without anyone above them noticing. Introduce an AI agent into that same workflow, and the gaps stop being absorbed. They surface, one action at a time.
Looked at differently, this makes agentic AI one of the more useful architecture diagnostics an enterprise has had in years. Wherever an agent struggles, the honest next step isn't to blame the model. It's to ask what the struggle is revealing — missing ownership, thin information architecture, integration held together by habit, authority that was never written down, data nobody has looked at closely in a while.
The failure usually says more about the enterprise than about the AI sitting on top of it.
For years, people made imperfect architecture work, quietly, without much credit for it. Now machines are being asked to work inside the same architecture, without that same quiet compensation available to them. What they are finding, mostly, is exactly where the cracks always were.
Statistics referenced: Cloudera / Wakefield Research, The Great AI Re-Architecture, 11 August 2026. Google Cloud, 2026 State of Infrastructure in the Agentic AI Era.