AI Data Preparation Without Migration

What Makes Data Genuinely Difficult for AI to Consume

An AI agent has no institutional memory. It cannot squint at a column named "netrevadj" and decide to ask someone what that means before using it. It cannot compare an answer against what it knew last quarter, or notice that the number looks wrong relative to context it once had. A stale, partial, or semantically wrong answer arrives with exactly the same confidence as a correct one — like a poker player who bluffs and tells the truth with identical expression. That is not a model deficiency to be patched in a future release. It is a structural property of how these systems work, full stop, and the entire burden of supplying context, currency, and trust signals falls on the data environment itself.

Most enterprise data environments are not built to carry that burden. A 2025 study from Precisely and Drexel University found that only 12% of organizations report data of sufficient quality and accessibility for effective AI implementation. In the same research, 67% said they do not completely trust the data they rely on for decisions, up from 55% just two years prior. That distrust exists in organizations staffed with analysts who can apply judgment, catch anomalies, and escalate when something smells off. Agents do none of those things. They process and return.

The failure modes that surface most consistently are not exotic. "Revenue" means one thing in the customer relationship management system (CRM), something different in the warehouse, and something else entirely in the finance system. Data moves across platforms and transformation steps without documentation, so an answer exists with no traceable provenance. Access permissions are scoped to service accounts rather than real users, creating security exposure and audit liability at the same time. Each failure mode is individually addressable. The problem is that they typically coexist, because the governance that would have prevented them was deferred.

That deferral pattern is common enough to be the norm. Teams build prototypes, connect models to whatever data is accessible, and put ownership and lineage tracking on the list of things to handle after the pilot proves out. By the time governance becomes a priority, AI systems are already running against undocumented data, and retroactive remediation is slow, expensive, and organizationally painful. Gartner has projected that 60% of organizations will fail to realize anticipated AI value by 2027, and the primary cause it names is not model quality or compute budget. It is incohesive data governance. That is the structural problem any serious AI readiness effort must address at the foundation.

Why Migration Is the Wrong Answer to a Governance Problem

The instinct when data is fragmented and ungoverned is to consolidate it. Build a single warehouse. Migrate everything. Clean it up, document it, and then let AI operate against something coherent. This logic is intuitive and nearly always wrong, for two reasons that are worth separating.

The first is timing. A migration of meaningful scope takes years. The business does not pause while infrastructure catches up; AI use cases are being piloted, demanded, and funded on a timeline that has no patience for a 36-month consolidation project. By the time the migration completes, the requirements have shifted, new sources exist, and the newly unified warehouse is already partially obsolete.

The second problem cuts deeper. Migration does not resolve the underlying issues. A centralized warehouse without semantic definitions, without enforced access control, without lineage documentation, is still not AI-ready. The data has moved. The governance deficits have not. Agents querying that warehouse will still generate plausible-looking answers that no one can verify, because physical centralization addresses the symptom of fragmentation without touching the cause. I have watched organizations spend two and a half years on a consolidation project, stand up the new warehouse, and then discover that their AI pilots produced the same class of errors they had before, because the data was now in one place but still undefined, still inconsistently permissioned, still undocumented at the metric level. It is a bit like moving all your files into one room but leaving them in unlabeled boxes — the clutter is consolidated, not solved. The frustration in those postmortems is distinctive.

Gartner's current data fabric guidance explicitly positions logical integration architectures as equally valid alternatives to physical centralization for the majority of enterprise use cases. The operative principle is: query data where it lives, federate results at runtime, and layer AI-ready context and governance on top without requiring source systems to move. The legacy warehouse does not become a liability in this model. It becomes one federated node in a broader architecture that AI can access today.

How Federated Query Execution Makes In-Place Access Viable

The performance argument for physical centralization was legitimate for a long time, and it deserves an honest answer rather than a dismissal. Colocation made query execution faster and more predictable. That advantage has largely closed.

Technologies built on Apache Arrow, distributed SQL engines, and pushdown optimization now allow analytical and AI inference workloads to run against distributed sources at performance levels that were not achievable a few years ago. Pushdown is worth understanding concretely: rather than pulling all the data to a central engine and filtering there, the query logic is sent to the source system, which executes the filter locally and returns only the relevant results. The data movement is minimal. The performance impact is substantial.

Several production deployments illustrate the pattern. Databricks' Lakehouse Federation runs queries against external databases and cloud applications without migrating data first. Starburst handles high-performance analytics across lakehouses and other distributed sources. Denodo focuses on data virtualization and integration across heterogeneous environments. BigQuery Omni supports federated SQL execution across cloud providers. These are not experimental approaches. They are running at enterprise scale in production environments with genuine performance requirements.

The practical architecture that follows from this: virtualize first, migrate later if at all. Federate queries to all sources from day one, monitor access frequency, and then selectively migrate only the datasets where physical colocation demonstrably improves performance. Lower-usage data stays virtualized. This inverts the traditional sequence entirely. AI readiness does not wait for migration; migration, where it happens at all, follows observed usage patterns rather than preceding them.

What a Semantic Layer Gives AI Agents That Raw Schemas Cannot

Here is something I have watched happen repeatedly in production environments. A large language model (LLM) generating SQL against a raw schema produces a query that is syntactically valid and semantically wrong. The query runs. The result looks entirely plausible. The number is wrong. And because the model returns it with the same even confidence it always does, no one flags it until a decision has already been made on that bad data. Sometimes a significant decision.

This is not an edge case. It is the default outcome when agents lack governed semantic context. Internal testing across vendor implementations has shown LLM query accuracy improve from roughly 40% without a semantic layer to above 83% when queries are grounded in governed semantic definitions. That is not a marginal improvement in a benchmark. It is the difference between a system that produces unreliable outputs and one that can be trusted to operate.

What a semantic layer provides is the institutional knowledge the model otherwise has no way to acquire: table descriptions, metric definitions, join relationships, the business logic that exists in the heads of the data team and nowhere in any schema. An agent querying "Quarterly Revenue" does not have to infer meaning from a column name or a schema comment that may not exist. It retrieves the approved definition: the same definition governing the Tableau dashboard, the board deck, the finance reconciliation, and the AI copilot, simultaneously, from one governed source. The consistency is not incidental; it is the entire point.

Gartner elevated the semantic layer to essential infrastructure in the 2025 Hype Cycle for Business Intelligence and Analytics, and roughly 40% of enterprise leaders now identify absent semantic context as a primary blocker for operational AI. The Model Context Protocol (MCP), an emerging standard, allows AI agents to discover and query semantic models without custom integration work for each system. Organizations that standardized on MCP across multiple LLMs found that every agent in the environment shared the same semantic foundation, which means outputs from different agents querying the same underlying data are reconcilable and auditable against each other.

A semantic layer does not make AI smarter. It makes AI answers trustworthy and reproducible. Those are genuinely different things, and conflating them is how organizations end up with sophisticated models producing outputs nobody can stand behind.

Enforcing Access Control at Query Time Rather Than at the Pipeline Boundary

Traditional access control was built around a model that AI agents immediately break. A known user, with a known role, authenticates into a known system. The permissions model holds. Agents do not work that way. They issue queries under service accounts with broad permissions, at speeds and volumes no human analyst could replicate, and a single misconfigured or compromised agent can reach data it should never have touched before anyone notices.

The required shift is conceptual before it is technical. Permissions must be evaluated at query time, scoped to the actual end user's identity, not inherited from the service account executing the workload. If a sales representative's AI assistant is running a query, the results should be bounded by what that sales representative is authorized to see. The service account's broader permissions are irrelevant to that determination.

Attribute-based access control (ABAC) is displacing role-based systems for AI use cases because ABAC handles dynamic evaluation. Access depends on attributes that can change: the current project context, the sensitivity classification of the requested data, and the business purpose of the query. A job title alone is an insufficient predicate for governing what an agent can retrieve on a user's behalf.

Retrieval-augmented generation architectures introduce a specific risk that is worth naming directly. Semantic similarity, left ungoverned, does not respect authorization boundaries. A query for compensation benchmarks should not retrieve executive compensation guidelines unless the requesting user is explicitly authorized to access them. Similarity is not authorization. Systems that treat it as such create exposure that is genuinely difficult to audit, because the access does not look like a breach; it looks like a retrieval that happened to surface something sensitive.

Write actions by agents carry a materially different risk profile than reads. An agent that can modify data, trigger workflows, or update records can cause harm that read-only access cannot, and governance frameworks that treat agent reads and writes equivalently are underbuilt for the actual risk surface. Additionally, access permissions must be revocable at the level of a single workload. When permissions are tied to a shared service account, revoking access breaks everything downstream that depends on that account. Workload-level revocability is baseline infrastructure for operating AI systems in regulated environments, not a refinement for later.

Why Lineage and Audit Logging Must Be Redesigned for Agent-Level Query Volume

Manual lineage tracking was never particularly scalable. At agent query volume, it is not even a consideration; the numbers make it impossible. The real question is whether organizations have deployed automated lineage infrastructure before they actually need it, because the need arrives fast and without warning.

The compliance obligations are concrete and current. The General Data Protection Regulation (GDPR) right to be forgotten requires an organization to trace and remove a specific user's data across all systems where it exists. If that organization cannot determine which vector embeddings contain a particular user's data because those embeddings were created without lineage documentation, it cannot fulfill the request. This is not a hypothetical future risk. It is an operational requirement today for any organization using retrieval-augmented generation in a jurisdiction with data subject rights. When this realization lands mid-deployment, the remediation effort that follows is not small.

An audit log that captures only what query ran is noise at agent volume. Useful audit infrastructure captures three things: who issued the query, meaning the real end-user identity, not the service account; what was accessed, meaning the query and the data returned; and why, meaning the agent workload or business context that triggered the request. Without all three, the log cannot support a meaningful investigation, cannot satisfy a regulator, and cannot tell you what actually happened after something goes wrong.

Gartner projects that 50% of companies will have formal AI risk management programs by 2026, up from 10% in 2023. GDPR, the EU AI Act, India's Digital Personal Data Protection Act, and various US frameworks create overlapping requirements for traceable, governed data. The organizations building lineage infrastructure now are not ahead of the curve in some aspirational sense. Those deferring it are building toward a compliance collision at a pace they may not fully appreciate yet. Treat lineage as a first-class data asset from the beginning, not as an afterthought appended to satisfy an audit after something has already broken.

How Data Freshness Requirements Change When Agents Make Decisions Rather Than Analysts Review Dashboards

A snapshot acceptable for a weekly executive dashboard is already stale for an agent making a pricing decision, a routing calculation, or an eligibility determination in real time. These are not equivalent use cases, and governing them with equivalent freshness standards is a category error.

Static extract-transform-load (ETL) pipelines rest on two assumptions that do not hold in live enterprise environments: that sources are stable, and that schemas are stable. SaaS vendors update schemas. Operational systems change continuously. The business generates new data faster than pipelines can process it. A pipeline built for weekly batch loads is not appropriate infrastructure for real-time agentic operations, regardless of how well it was engineered for its original purpose.

Federated, live query access resolves the freshness problem structurally rather than operationally. When an agent queries a federated source, it receives the state of that source at the moment the query executes. No pipeline lag. No stale cache to manage or invalidate. The answer reflects reality as it exists when the question is asked, which is the only freshness guarantee that actually matters for real-time decision-making.

Freshness requirements must be matched to the specific use case and enforced as a governance property, not left to the discretion of whatever agent or team is making the request. An agent querying inventory data for fulfillment decisions has near-zero tolerance for staleness. An agent generating a monthly operational summary can tolerate considerably more. Those tolerances should be defined, documented, and enforced at the infrastructure level.

The practical implication: AI readiness infrastructure must surface freshness metadata alongside query results. When the data was last updated, what its normal update frequency is, whether the current result falls within the expected refresh window. Agents and the systems governing them need this information to determine whether to act on an answer or escalate for verification. Without it, they act on whatever they have, and the confidence level of the response will not tell you whether that is appropriate.

Putting the Preparation Requirements Together as an In-Place Architecture

Every requirement covered here, semantic context, access control, lineage, and freshness can be satisfied by a governance and virtualization layer that sits on top of existing infrastructure rather than requiring any of it to be replaced.

That layer exposes a single query interface across federated sources. It attaches semantic definitions to every entity and metric so agents are querying governed meaning rather than raw schema. It evaluates permissions at query time under the real user's identity, not under the service account. It logs identity, intent, and lineage with every query, at agent volume, automatically. It surfaces freshness metadata so agents and governing systems can assess whether an answer is current enough to act on before acting on it.

Nothing in this architecture requires rip-and-replace migration. The warehouse stays. The data lake stays. The SaaS tools, on-premise databases, and operational systems stay. The layer makes them behave as a unified, AI-ready estate. Data products become the unit of governed access: curated, semantically defined, permission-enforced datasets that agents and analysts can query through SQL, APIs, or natural language without manual preparation upstream.

Gartner forecasts that more than 40% of agentic AI projects will be abandoned by 2027. The organizations that avoid that outcome are not the ones with the most capable models or the largest infrastructure budgets. They are the ones that grounded their agents in structured, governed, semantically defined data before deploying them against real decisions. The model does not compensate for what the data environment is missing. It produces a confident answer regardless of whether that answer is trustworthy. Building the layer that makes the answer trustworthy is the actual work, and it was always the actual work.