AI Readiness Starts with Data Governance, Not Data Access

When agentic AI projects fail in production, the failure rarely traces back to the model. The tables exist. The queries run. The pipeline passes every technical check. But when an agent tries to interpret the environment, something breaks that no amount of infrastructure investment anticipated: The agent needs to know which customer table is canonical, what status_code = 3 actually means in business terms, and who owns the data when something goes wrong downstream. In most organizations, no one can answer those questions cleanly. The problem is not data access. It is semantics, and it has been hiding in plain sight for years.

The Semantic Gap

Here is a useful diagnostic: Pick three tables your team uses daily, open your data catalog, and ask whether someone outside your immediate team could understand what those tables contain and how to use them correctly based solely on what is documented there. Not with help from a colleague who built the pipeline, not with a Slack message to the original data engineer. Based on the documentation alone.

In most organizations, the honest answer is no. Table names like user_data_final_v3 are common. Column descriptions that say “status field” are common. Five different definitions of “active user” spread across six tables, each one slightly different, none of them documented as the authoritative one, are extremely common. The infrastructure works. The semantics do not exist.

This gap has always created friction for human analysts, who have learned to navigate it through institutional knowledge, tribal memory, and the Slack channels where the real data documentation lives. For AI agents, it creates a different class of problem. An agent does not pause to ask a colleague which customer ID is authoritative. It makes a choice, based on whatever signals are available to it, and moves forward. It joins on the wrong key, interprets a metric using a definition no one agreed on, or pulls from a table that has been superseded by a newer one that was never labeled as such. The infrastructure gave it access. No one gave it meaning.

Consider a common failure pattern in production RAG deployments: The pipeline runs clean in development, queries return results, and everything looks fine until the agent tries to join tables across domains and selects the wrong keys because three teams have maintained three different customer ID schemas and no one documented which one was authoritative. The system worked in dev. It failed in production. Not because of the model, and not because of the infrastructure. Because the semantics were never defined.

What Catalog and Access Tooling Provides, and What It Does Not

The past two years have brought a wave of tooling aimed at making data more accessible to AI systems: intelligent data catalogs that auto-tag assets on ingest, cross-cloud query layers that eliminate migration friction, governed access protocols that enforce read/write boundaries at the infrastructure level. Major cloud vendors, Google Cloud among them, have shipped meaningful capabilities in this category. The pitch is compelling, and the access problem these tools solve is real.

On the surface, this addresses the AI readiness problem. In practice, it addresses a subset of it, and it is worth being precise about which subset.

These tools make data more queryable. They surface what exists. They reduce the manual overhead of cataloging and metadata management. What they do not do is create a shared taxonomy, resolve conflicting metric definitions, or assign ownership when a schema changes and downstream systems break. Auto-tagging works well on data that already has structure and meaning. Where that structure does not exist, or where it exists in five contradictory versions with no designated authority, automated cataloging does something useful but insufficient: It makes the gap more visible, faster. The problem does not disappear. It becomes easier to see.

The distinction matters because many organizations are investing in access and catalog tooling under the implicit assumption that it closes the AI readiness gap. It closes the access gap. The semantic gap requires a different kind of work, one that tooling can support but cannot do.

What the Foundation Work Actually Looks Like

The work that makes AI projects succeed in production starts before the AI project begins, which is exactly why it tends not to happen.

Taxonomy is the most unglamorous part of this. Tables need to be named for what they contain, not for the project that created them or the iteration that produced them. customers_final_old should never be the authoritative customer table, but in organizations without enforced naming conventions, it frequently is, and everyone just knows not to use the other one. Column descriptions need to explain business meaning: not “status field,” but “order status: pending, confirmed, shipped, or cancelled, set by the fulfillment system at order creation.” The goal is documentation complete enough that someone outside the original team can use it without asking anyone for help. If it requires local knowledge to interpret, it is not documentation. It is institutional memory, and institutional memory does not scale to AI systems.

Governance structure is the other half of this. Someone needs to own data quality for each domain. When a schema changes, there needs to be an approval path. When metric definitions conflict across teams, someone needs to have the authority to designate which one is canonical and why. Without explicit ownership, schema changes propagate silently, downstream systems break unexpectedly, and agents make choices that no one can audit or correct. No one set the rules for what a correct choice looked like.

Lineage and accountability close the loop. Tracing where data came from and how it was transformed is not just a tooling requirement. It requires actual organizational ownership. When a downstream model breaks because an upstream schema changed without notification, someone should be accountable for that break. Lineage tooling supports this kind of traceability, but the accountability structure has to exist first, or the tooling is just documentation of failures no one is responsible for.

The experience at Mattel is an instructive illustration of what happens when governance has not kept pace with AI adoption. Joseph Vinhais, chief safety officer and SVP of global quality at Mattel, described the situation at a session during Google Cloud Next 2026: Across the quality function alone, the team identified 68 different active AI projects. Six separate teams were focused on the same problem (building a packaging and labeling solution) without knowing the others existed. The result was redundant work, compliance exposure, and duplicated effort in a domain where, as Vinhais noted, regulatory precision is non-negotiable. This is not a technology failure. The AI projects worked. The coordination structure to govern them did not exist.

Where to Start

The good news is that the scale of the problem does not require a large program to begin addressing it. The foundation work is genuinely incremental, which means there is no reason to wait for organizational alignment on a multi-year governance initiative before starting.

Pick one domain. Identify the canonical table for a single entity type: customers, orders, products, whichever one causes the most confusion today. Document what the columns mean in business terms, not technical ones. Get explicit agreement on the metric definitions that matter most to that domain. Set up lineage tracking so schema changes have a visible path and a visible owner. Then expand to the next domain. The measure of whether the work is done is simple: Can someone outside your team use these tables correctly based on the documentation alone? If not, that domain is where to start.

Access tooling and catalog automation have genuine value in this work. Auto-tagging reduces manual cataloging overhead. Governed access protocols reduce the risk of agents operating outside defined boundaries. These capabilities belong in a mature AI data architecture, and the vendors building them are solving real problems. They belong, though, on top of a foundation that already has clear taxonomy, defined ownership, and resolved semantic conflicts. Built on top of ambiguity, they make the ambiguity easier to query. They do not make it go away.

The organizations succeeding with production AI are not necessarily the ones that deployed the most tooling the fastest. They are the ones that did the slower, less visible work of deciding what their data means before asking a model to reason about it.