Data Virtualization Platforms Compared for Enterprise AI Teams

Data virtualization platforms should be compared by the answers they let AI agents produce. For enterprise AI teams, the decisive requirements are governed business definitions, permissions enforced at query time, current data, and traceable results. Without them, a platform can deliver valid-looking SQL while an agent gives the wrong answer, exposes restricted data, or acts on yesterday’s state.

Why connector counts and deployment models are the wrong criteria for AI teams evaluating DVPs

A platform meets every requirement on the buying checklist, yet its agents make up metric definitions or show data their users should not see. That is an architectural failure. Connector breadth, cloud versus on-premises deployment, and pricing tiers help establish whether a platform fits an estate. They do not establish whether an agent can use its data correctly.

The conventional buying frame was built around human analysts querying dashboards. Those analysts supply context that the platform may never record. An agent cannot resolve a vague column through institutional memory, and a stale answer can look just as credible as a current one. When that answer feeds a chain of reasoning and action, the error compounds. Buyers therefore need to assess what an agent can safely conclude from a platform’s connections.

What actually goes wrong when AI agents query a standard data virtualization layer

The first break is context fragmentation. A human analyst may know that “rev_adj” means adjusted revenue excluding returns, while an agent sees an unexplained column and guesses. Gartner’s February 2025 prediction stated that through 2026, organizations would abandon 60% of AI projects unsupported by AI-ready data. That forecast concerns the gap between data being available and data being usable.

Once the agent turns an uncertain interpretation into a query, a second weakness can make the result unsafe as well as wrong. A shared service account may let the agent see more data than the person asking the question can see. If permission checks stop at provisioning, the agent inherits that account’s reach.

Even a correctly interpreted, authorized result can still fail the decision it serves. Batch-only pipelines may show yesterday’s state without enough context for the agent to tell how old it is. A dashboard snapshot becomes an input to action. In a multi-step workflow, later steps build on that stale input. These failures begin in the data layer, so changing the model alone does not remove them.

The capabilities that determine whether a DVP is actually AI-ready

An AI-ready platform needs a queryable semantic layer with governed metric definitions. Table descriptions, formulas, dimension relationships, and business rules must be available when the agent queries. Otherwise, the agent still has to invent meaning. This layer must also distinguish structured metric questions from questions suited to vector retrieval, because similarity search is not a substitute for calculating a governed measure.

The second requirement is permission enforcement under the real requester’s identity at query time. Row- and column-level restrictions must resolve against the initiating human or workload. Access also needs a narrow shutoff point. Revoking one workload should not require disabling every workload that shares its connection.

The third requirement is live query access with freshness matched to the decision. Runtime federation can reach source data as it is now, while a pipeline that last ran at 2 a.m. cannot promise an answer that is up to date. An agent taking action faces a different test from a dashboard refreshing hourly.

The fourth requirement is an audit trail linking identity, intent, and lineage at agent-level volume. SQL alone cannot show whose request started a workflow, what it was meant to answer, or which sources shaped the result. Combined data needs scrutiny too. A join linking a name to a salary can create exposure that separate field classifications miss.

How the leading DVPs measure against those four criteria

The named platforms approach these requirements from different architectural starting points. The varying detail of their documented capabilities across all four criteria limits any blanket comparison of AI readiness. A useful comparison separates what each platform already has from what an enterprise still needs to test with its own workloads.

Denodo Platform 9.5, released July 2026, introduced metric views for defining and reusing governed business metrics. Its governance includes identity-aware policies, row- and column-level security, masking, lineage, and auditability. Smart Query Acceleration precomputes summaries for reuse, while a separate optimizer capability pushes partial aggregations to source warehouses, reducing data sent across the network. Freshness remains to be established for those distinct mechanisms. Denodo fits heterogeneous estates needing a governed access layer, with the operational burden of running that layer still part of the decision.

Starburst Galaxy provides an AI-powered semantic layer and an MCP server supporting agentic pipelines. Its Trino engine, Apache Iceberg support, and federated catalog favor cloud-native lake environments built on open standards. That is a clear architectural fit. The descriptions still leave open some details of how requester-scoped enforcement and linked audit records work. Large enterprises have also raised questions about shared-platform limits in the multi-tenant service, making scale a genuine evaluation concern.

IBM watsonx.data has its clearest strength in native lineage, masking, and compliance controls. Those capabilities address important parts of governed AI access, but do not by themselves settle metric consistency, freshness, or session-level audit reconstruction. Governance is the strongest starting point here. The platform is a natural fit for organizations already running IBM infrastructure. Its fit is less natural in heterogeneous multi-cloud estates where that tooling is not already present.

Informatica IDMC shows active investment in agent integration. In May 2026, Informatica made MCP servers and CLAIRE Agent skills available across AWS AI services, brought CLAIRE GPT to IDMC directly on Google Cloud, and extended CLAIRE agent interoperability to Gemini Enterprise through A2A. Integration does not settle enforcement, though. Its governance, quality, and metadata capabilities still need testing against the four requirements. The Salesforce acquisition favors deeper ecosystem integration for some buyers while complicating the vendor relationship for others.

Domo’s 2026 analysis argues that pure-play virtualization leaves the journey from access to business action incomplete, while Domo combines connection, transformation, visualization, and action. The broader comparison still requires demonstration of semantic consistency, identity enforcement, freshness, and auditability. Buyers need to weigh the single-platform workflow against how much federation their use case needs.

What a semantic layer actually does inside a DVP — and why metric views change the AI calculus

A semantic layer governs how a business question becomes a query. For “revenue,” it supplies the formula, permitted dimensions, applicable filters, relationships, and descriptions that determine the answer. It removes the need to reconstruct the definition. When access policies are machine-consumable with that context, the layer controls both what the metric means and how it can be used.

Denodo’s metric views make that reuse concrete. A revenue definition becomes one semantic object that is available through governed data products, the marketplace, BI tools, and AI experiences. The agent and finance dashboard use the same definition. Revenue queries can still give different results because filters and dimensions shape the answers.

The Open Semantic Interchange specification appeared in January 2026 as an initial v0.1 specification for representing semantic constructs in a vendor-neutral format. Snowflake’s announcement describes datasets, metrics, dimensions, relationships, and contexts, leaving access policies outside its core constructs. That boundary is important for governance claims. Sharing business meaning across platforms does not itself prove that permission enforcement travels with it.

A semantic layer still cannot take the place of a vector database or serve as one. Revenue is a structured calculation. Sending that question through retrieval leaves the agent to infer a formula from text. The semantic layer instead gives the query engine a definition it can execute and govern.

Runtime governance for AI agents — what query-time enforcement actually requires

Agents query dynamically and at volume without pausing for a person to approve each access. A permission gap therefore becomes a repeatable path to exposure. Policy documentation cannot block that path by itself. If the running query uses a broad service account without resolving the actual requester’s restrictions, the written policy has no effect on the result.

Runtime enforcement must also allow one workload’s access to be revoked without disabling unrelated work. Shared credentials make that separation difficult. At the same time, controls need to evaluate data where it is combined, because a permitted name field joined to a permitted salary field can create a newly sensitive result. Reviewing fields only at ingestion misses the relationship the query creates.

The audit record must preserve that execution context. Identity, what the user asked, and source lineage need to be linked so a reviewer can reconstruct an agent session from its SQL strings. Writes require stricter controls than reads. Once an agent can initiate a transaction, an access mistake can lead to both an exposed answer and an action.

In March 2026, BigID made its Data Access Governance and Data Activity Monitoring work with AI agents too, with identity controls, least-privilege enforcement, and real-time monitoring for non-human entities. Those changes focus on what happens at runtime, beyond how policies are stored. For DVP evaluation, the distinction is decisive. A restriction that is written down but never applied to the running query leaves the same access gap as having no restriction at all.

Data products and marketplaces — how governed DVPs turn federation into something agents can reliably consume

Federation and enforcement still leave an agent with a discovery problem. It needs to know which dataset is suitable, who owns it, and what quality standards apply before using it. A table alone does not answer those questions. A data product packages data with business definitions, metadata, documentation, quality standards, ownership, accountability, and access mechanisms.

That package makes reuse more dependable. Instead of rediscovering and validating the same dataset for every workflow, consumers get an approved unit with its assurances attached. Alation’s Data Products Marketplace certifies every product against the organization’s quality, ownership, and compliance standards. Only trusted, approved products are published. Users or agents can then request governed access through the marketplace.

Denodo’s marketplace uses this way of packaging data with metric views. An agent consuming a governed product can receive the semantic definition and governance rule in the same call. Certified products also reduce the pattern of different teams recreating the same datasets for separate projects. This is where virtualization moves beyond exposing infrastructure to supplying something an agent can reliably consume.

How to evaluate a DVP for AI readiness before signing a contract

The tests should bring out failures that a clean, single-step proof of concept would miss. Start with a real business metric that has produced inconsistent answers across tools, then query it through different tools and agents under equivalent conditions. The definition should hold across those routes. Ask for a specific column’s meaning in queryable form too, so documentation cannot pass as an executable semantic layer.

Next, compare a broad service-account query with the same request scoped to a restricted end user. For a row-restriction test, the results should reflect the user’s permitted rows. Then attempt to revoke one workload’s access. If the only available switch disables the shared account, the platform has not demonstrated workload-level revocability.

Identify the most time-sensitive decision the agent will make, query its inputs, and inspect when those inputs were last current. An unexplained timestamp is not enough assurance. Run a multi-step agent workflow at the expected query volume as well, then use the audit record to reconstruct who initiated it, what question it answered, and which source systems contributed.

The final test is architectural fit. The layer should work over the infrastructure already in place, with governance available before any warehouse migration. It should deliver business meaning and permission enforcement at every query, under the real requester’s identity. A contract should follow evidence of those conditions.