Many enterprises are hesitant about where to begin with AI, and the hesitation often traces back to data. Leaders have a general sense that AI could help, but the picture stays abstract, in part because the underlying data feels like a problem to solve before any real work can start. The data in question takes many forms. It might be unstructured content scattered across document repositories, institutional knowledge that lives mostly in people's heads, information siloed across multiple sites, or the patchwork of disconnected systems common at the municipal level. For organizations that have already begun, that same messy and disparate data is frequently what keeps a promising pilot from scaling.
The instinct that follows is understandable. Clean the data, normalize the formats, consolidate the sources, and move everything into one place where AI can finally reach it. The work feels like a responsible first step, yet it often becomes the reason the initiative stalls, because enterprise data rarely sits still long enough to be finished. A more useful question is whether the data needs to change at all, or whether the system reading it can simply meet the data in the state it is already in.
The price of treating preparation as a prerequisite is easy to underestimate. Gartner has projected that through 2026, organizations will abandon 60 percent of AI projects that are not supported by AI-ready data, a figure that captures how often initiatives lose momentum before they ever reach production.
That number is usually read as a case for investing more heavily in cleanup. Read another way, it points to a sequencing problem. When readiness is defined as a finished state the data must reach before AI can begin, the finish line keeps moving. New systems come online, priorities change, and formats multiply faster than any consolidation effort can absorb them, so the preparation phase expands while the value stays out of reach. In contrast, modern AI agents can ingest raw, uncleaned data in its native format, bypassing the preparation tax and accelerating time to value.
The habit of cleaning data first and applying intelligence second is inherited from an earlier era of analytics. Business intelligence and traditional machine learning genuinely required curated, structured inputs, so the data warehouse and the long preparation pipeline became standard practice. Agentic AI changes that requirement in a way many programs have not yet absorbed.
Today's models can reason across material that older systems could never touch. McKinsey estimates that roughly 90 percent of enterprise data is unstructured, living in documents, email, chat, images, audio, and video rather than in tidy tables, and generative models are the first technology able to work with that material at scale. Insisting that all of it be converted into structured records before an agent can engage discards much of the value that makes the technology worth deploying in the first place.
Much of an organization's most useful knowledge lives in exactly these formats. The reasoning behind a decision sits in an email thread or a recorded call, the condition of an asset is captured in inspection photos, and the terms that govern a relationship are buried in a scanned contract or a stack of field notes. An approach that can only work with clean, structured records leaves that knowledge on the table, while an approach that reads the original material directly can put it to work without a translation step in between.
A compounding cost follows from the same habit. Each use case that depends on its own custom preparation pipeline repeats the work of the last one instead of building on a shared foundation, which is part of why fewer than ten percent of organizations have managed to scale AI agents within any single business function, according to McKinsey's 2025 State of AI research. Preparation-heavy programs do not only start slowly. They struggle to compound, because every new initiative pays the readiness cost again.
An architecture that avoids the readiness detour has two defining properties, and they work together.
The first is native access across formats. A capable system reads a relational database, a scanned PDF policy, a set of hand-written field notes, an email archive, and audio or video records within the same workflow, without a separate step that forces every source into one schema before reasoning can begin. Format diversity becomes something the architecture absorbs rather than something the organization has to eliminate in advance.
The second is the ability to leave data where it is. Discovering and indexing information wherever it resides, without mass migration into a central repository, removes the largest and riskiest part of most readiness projects. For many organizations, and especially for government and regulated environments, keeping data inside its existing systems is a practical necessity rather than a preference. Bringing the intelligence to the data, instead of moving the data to the intelligence, works with those constraints rather than against them.
What ties the two together is context. Information becomes useful to an agent when the system can also recognize the relationships and meaning that surround it, so that a retrieved document is understood in light of the policies and history that give it significance.
When those properties are in place, the shape of an AI initiative changes. Instead of a multi-quarter data program that has to finish before any value appears, the work becomes an iterative effort where an agent can be pointed at real data early and improved as it runs.
The Town of Vail offers a concrete illustration. The town needed to review deed restrictions tied to its housing program, a process that depended on dense, inconsistent documents rather than clean database fields, and on the context required to interpret them correctly. Rather than rebuilding that information into a structured system first, Kamiwaza worked with the documents as they were and supplied the context needed to read them consistently, reducing deed restriction case review time by roughly 90 percent. The result came from meeting the data in its existing form rather than from a long preparation project. (See the Town of Vail case study.)
The broader pattern holds across settings. Teams reach a working agent in weeks rather than quarters, not because the data turned out to be tidy, but because the architecture no longer required it to change before the intelligence could begin.
For technology leaders weighing where to start, the more useful question is not how clean the data needs to be before AI can help, but whether a given platform can work with the data in the state it is actually in: distributed across systems, varied in format, and carrying years of accumulated context. Framed that way, data readiness becomes less of a budget line to clear and more of a capability to evaluate.
Enterprise data is messier and more scattered than any cleanup project will fully resolve, and that reality is unlikely to change. The more practical path is to choose an architecture that can work with the data as it is, which is often what separates an AI effort that reaches everyday use from one that stays a demonstration.
To learn more about Kamiwaza’s product and capabilities, visit https://www.kamiwaza.ai/product.