Your data architecture was built for predictable consumers

Working with large financial institutions, I’ve watched enterprise data consumption change drastically. The old model might have had 1,000 people using the same carefully designed application. These 1,000 users could reliably and predictably work from this application, and data access would typically occur in the same way.

That change was already underway as dashboards, APIs, notebooks, microservices and specialized applications multiplied the number and variety of consumers reaching the same underlying data. Agentic AI is turning this construction on its head. Those 1,000 people could now be working from 1,000 individualized dashboards, applications or agents. That creates more paths, data combinations and entitlement decisions, and each requires reconstruction.

What gets easier and more individualized at the application layer gets harder underneath it: infrastructure and InfoSec teams must support more dynamic demand, more access patterns and more control decisions. And that challenge is becoming more pressing as agentic AI broadens: 23% of organizations report scaling agentic systems, and an additional 39% are experimenting with agents.

The result has accelerated a broader shift from relatively predictable data consumption to fluid, individualized and difficult-to-govern access patterns across the same underlying data.

In capital markets, tolerance for inconsistencies is nonexistent. This environment has been an early proving ground for architectures designed to coordinate changing consumer patterns. The lesson is not that every workload should be centralized or routed through one platform, but rather that a governed data consumption layer can provide the leverage to reduce repeated integration, protect sensitive source systems and enforce consistent access, audit and runtime controls.

I use “governed data consumption layer” here to describe the consumption-facing role of a broader data fabric. The fabric connects and contextualizes data across enterprise systems, maintains reusable state and controls and distributes that information through governed interfaces. The consumption layer is where those capabilities meet the applications, users and agents requesting the data.

However, CIOs need to evaluate where this approach may prove valuable and where direct access may remain the better choice, if they wish to manage how a growing number of human and machine consumers access, combine and act on data. The architectural question is what changes when the consumer, its query pattern and its data requirements can no longer be known in advance.

Where a data fabric creates leverage

A data fabric can create significant leverage when growing numbers of consumers would otherwise have to independently reconstruct the same context, establish their own access paths and operate their own controls. A consumer may need a current business view that combines live activity with persistent context. A credit-card authorization, for example, may need to be evaluated against available credit, merchant history, fraud scores and card status. If multiple consumers independently reconstruct that same contextualized view, they duplicate processing and create more opportunities to arrive at inconsistent answers.

A data fabric separates the primary workload from data delivery in these cases. It allows the same working set to be reused, reducing pressure on source systems and making latency more predictable. This layer is also helpful when each subsequent application requires different views of the same information, based on their fields, histories, update rates or interfaces. The objective is to deliver data at the level of freshness each workflow requires; not every consumer needs to be real-time.

That separation also preserves optionality. A new application or AI workflow can gain governed access without requiring the underlying system to be replaced, migrated or exposed directly to every new consumer. Reuse solves only one part of the challenge. As consumption becomes less predictable, the layer also must govern what each consumer receives.

One pattern I describe as the “fire-hose approach” is sending consumers a broad stream of information and expecting them to discard what they do not need. That becomes harder to justify as consumers multiply and request different fields, filters and time windows. At the consumption layer, the fabric can instead tailor delivery more precisely to what each consumer requires, reducing unnecessary movement and downstream processing.

That precision also improves governance. If the request itself defines exactly what information a consumer receives, the organization maintains a more granular record of who requested what instead of knowing only that a user subscribed to a much broader stream.

Additionally, entitlements and audit requirements would need to remain consistent across these dashboards, APIs, notebooks, services and agents that request information. As access paths multiply, observability and governance practices must scale with them. As of writing, only one-third of surveyed organizations rate themselves at least moderately mature in AI strategy, governance and agentic governance.

I’m already seeing AI change the practical meaning of entitlement. An operations employee may legitimately hold broad credentials to perform a technical role but historically lack the time or expertise to use that access to derive sensitive business information. With an AI interface, the same employee may be able to ask for something like an entire desk’s P&L in a few keystrokes. The entitlement has not changed, but what the user can accomplish with it has. Once multiple consumers depend on that shared layer, governance is not solely an access-control problem. The layer itself must be operated as critical infrastructure.

High-consequence architecture demands more than a simple check to confirm it’s running, which only confirms the pipeline is alive. CIOs must know whether the state it is distributing is current, correct and reconstructable. As consumption becomes more individualized, visibility into which consumers are driving load, what queries are becoming common and how those patterns are changing over time is also required.

An enterprise needs to be able to explain which data, state, transformation and permissions produced a result. That means making sure the information is current, explainable and traceable. Here, the leverage of the fabric once again proves valuable. It can supply evidence of what was requested, which state was used, what transformation occurred and what was delivered.

With this foundation, organizations are better equipped to enforce governance at the point where access is granted, rather than leaving it until a final review checkpoint. This includes identity, access scope, consumption limits, tool permissions and audit. As consumers become capable of doing more than retrieving information, that governance also has to follow the progression from what they may access, to what operations they may perform with it, to what actions they may execute.

In higher-risk workflows, that final stage may require a human override. I’ve seen banks use kill switches that allow humans monitoring outliers to halt automated trading when something appears wrong. As automated consumers take on more decision-making, preserving that ability for intervention becomes more important.

When governance becomes part of how the organization operates, and not just how it says it should operate, later applications can reuse connectivity, mappings, state, controls and recovery procedures and trust that they align with the overall business view, which prevents every new consumer from requiring another independent integration, entitlement model and operational path.

The fabric becomes most useful when growing numbers of consumers need the same underlying data in different and increasingly difficult-to-predict ways. It helps provide this data while maintaining oversight and protecting source systems. However, that doesn’t mean that it’s the best choice for every organization.

When predictable consumption still makes direct access the better choice

The decision comes down to a practical tradeoff: a data fabric earns its place when the cost and risk of repeatedly integrating, contextualizing, governing and operating access for individual consumers exceeds the cost and risk of introducing shared infrastructure.

This fabric concentrates responsibility. If the layer can’t process requests, update its working state or distribute information quickly enough, it can become a bottleneck. And with multiple consumers relying on it, an outage, stale working state, faulty transformation or policy error can have a larger blast radius. Under these conditions, the layer can shift into a mechanism for propagating stale working state, bad mappings or entitlement errors.

That tradeoff matters because direct access remains sensible when the consumer is bounded, demand is predictable and the source was designed to serve the workload. The case is even stronger when the data requires little transformation or enrichment, entitlements are straightforward and there is limited expectation that later consumers will reuse the connection. Under those conditions, introducing another layer can add latency, complexity and another failure dependency without creating enough shared value to justify it.

This argues for incremental adoption rather than an enterprise-wide mandate. Start with a bounded workflow where shared access, state or governance can create measurable value, establish reusable connectivity and controls, then expand only when later consumers can reuse those assets. The shared layer should earn a broader role through demonstrated reuse rather than architectural preference alone.

Rather than architectural uniformity, the goal is to encourage optionality while creating shared consumption and governance capabilities where reuse genuinely creates leverage. CIOs do not need to predict every future consumer, but their architecture should govern the conditions under which new consumers access, combine and act on enterprise data.