Year: 2026

Generative AI (GenAI) is accelerating how much data organizations generate, straining storage and governance frameworks built for a slower-growth era. Most GenAI-using organizations now expect increases in data volume over the next two years, and infrastructure and governance strategies often struggle to keep pace.

The scale of the challenge

According to IDC’s Global DataSphere, consumers and organizations worldwide will generate more than 274.4 zettabytes (ZB) of data in 2026 alone. That figure is forecast to nearly triple to 718.5 ZB in 2030, a compound annual growth rate (CAGR) of 26.9%. Enterprise data is growing significantly faster than consumer data (31.1% CAGR versus 13.5%), and it matters most here because it’s the data organizations are responsible for governing and protecting, and expect to get value from. It’s also the data most directly implicated in AI workloads.

Storage is expanding in parallel. IDC’s Global StorageSphere shows the installed base of storage capacity roughly doubling, from about 13 ZB in 2026 to more than 26 ZB in 2030. Even before accounting for AI, the enterprise data challenge was already heightened and the governance surface area was already growing faster than most organizations could manage.

The AI inflection point: What IT leaders are telling us

In IDC’s 2026 Worldwide Data Utilization Survey, 81.7% of the 714 GenAI-using respondents said they expect GenAI to increase their organization’s data volume over the next two years. Only 4.8% expect a decrease.

Of those anticipating an increase, 47.7% expect data volumes to grow by 25% or more, and 13.4% expect growth exceeding 50%.

Much of what GenAI produces is ephemeral, and a share of AI-generated content replaces existing workflows. In some cases, GenAI can reduce data volumes, such as by eliminating raw footage through synthetic generation, or by converting unstructured data into structured, actionable formats that can then be selectively retained or deleted.

These dynamics leave the overall growth trajectory intact. For organizations running active GenAI programs, operational telemetry, model logs, RAG corpora, and fine-tuning data sets can add up in ways that initial planning assumptions rarely account for.

Why GenAI drives data growth

There are at least four distinct layers, and the net effect varies by industry, organization, use case, and deployment maturity:

Model training and fine-tuning data: Customizing models on proprietary documents, transaction records, or customer interactions creates derivative data sets that must be stored and governed, including every version.
Retrieval-augmented generation (RAG) corpora: Every document ingested into a RAG pipeline generates an embedding stored in a vector index, and that corpus needs ongoing refresh. RAG can also have a reduction effect by lessening the need to retain full-length source materials indefinitely.
AI-generated output data: Much of it is ephemeral, and only finalized outputs tend to be stored, but where compliance mandates retention, the footprint grows predictably over time.
Operational and observability data: Every inference request generates metadata, including prompts, outputs, latency, and token consumption. This layer tends to be underestimated in early planning, and agentic AI compounds it with richer, more continuous logs and reasoning traces.

The governance and infrastructure gaps

Knowing that data volumes will grow is not the same as being prepared for it. IDC’s research points to three structural gaps:

The governance gap: Most frameworks were built for structured, human-generated data. AI-generated content often falls outside them, creating compliance exposure in regulated industries.
The storage architecture gap: AI inference, training, and RAG pipelines need high-throughput access, low-latency embedding lookups, and cost-efficient tiering for training archives. Organizations that haven’t revisited their architecture may pay a performance or cost penalty.
The retention and life-cycle gap: Retention policies at most organizations predate the GenAI era, and keeping a prompt-response pair, a fine-tuning data set, or an embedding raises questions those policies never anticipated.

None of these gaps is insurmountable, but they widen quietly in the background while organizations focus on deploying AI.

Volume isn’t value: Why runaway data is harder to use

There’s a second cost to letting data volumes outrun your strategy: the value you never get out of the data. Value depends on how effectively data becomes insight or advantage. Vast quantities of poorly structured, unlabeled, or siloed data may hold almost no practical value despite their volume, so every RAG index, fine-tuning corpus, and log stream that no one has cataloged or assigned an owner is data you hold but cannot use.

Beyond the prompt: What to do next

Most GenAI-using organizations expect data volumes to rise. The open question is whether infrastructure and governance strategies are built for that reality. Preparing takes a deliberate, systematic approach, and these five steps are the place to start:

Audit the AI data footprint before it becomes unmanageable. Inventory training sets, fine-tuning corpora, RAG indexes, and telemetry, including where each lives and who owns it.
Extend data governance explicitly to AI data assets, with updated classification, retention, and lineage tracking, and engage legal and compliance early.
Align storage infrastructure planning with the AI road map by developing capacity plans together with AI and data science teams.
Revisit retention policies with AI data types explicitly in scope.
Model the economics of AI data storage across cloud and on-premises options. Cloud is growing nearly four times faster than noncloud, but high-volume, persistent data may be more cost effective on-premises or in colocation over a multiyear horizon.

More than 12 frontier AI developers have published voluntary safety frameworks with widely varying thresholds, inconsistent evaluation cadences, and no independent verification requirement. The EU AI Act’s maximum fine for general-purpose AI providers, 3% of global annual turnover or €15 million, whichever is higher, became enforceable August 2, 2026. An autonomous coding agent operated unsupervised for approximately one week before its own developer identified and attributed it. These describe the current operating environment for every CISO who has approved an AI integration in the past 18 months.

The structural problem is architectural, and vendor assurance alone does not resolve it. System prompts, safety fine-tuning, and content filters live inside the same weights, context window, and inference pipeline the model uses for every other output. They can be argued with, role-played around, encoded past, or overridden by a sufficiently creative prompt. Prompt injection and tool-calling exploits are now a standing category of incident response. A better system prompt is still inside the boundary.

What the enforcement layer is and what it must do

The right mental model is the content delivery network and web application firewall pattern. A CDN and WAF inspect and act on traffic before it reaches the origin server. The origin has no vote and no visibility into the decision. The same logic applies to AI: the model is the origin server, isolated with no network path to your IT estate and no view of the policy engine, logs, or configuration. The enforcement layer sits at the edge, verifying identity, inspecting requests, applying policy, mediating responses, and logging every interaction before anything reaches or returns from the model.

Five control layers are required. Missing any one leaves an exploitable gap:

Identity and access: Every request, human, application, or agent, is authenticated against your enterprise identity provider. The model inherits the calling user’s actual entitlements through on-behalf-of token exchange. A jailbreak or injection attempt is bounded by what the caller was already permitted to do.
Request inspection: Every inbound prompt and tool-call parameter is screened for policy violations, data-classification conflicts, and injection patterns before the model processes them. This runs outside the model, so the model cannot override it.
Policy enforcement as code: Business rules, regulatory constraints, and data-handling requirements run as code in the enforcement layer, not as instructions the model is asked to follow.
Response mediation: Every outbound response and tool-call authorization is screened, redacted, or blocked regardless of what the model produced. The model’s own judgment about its output is not the final word.
Immutable audit with a kill switch: Every interaction is logged outside the model’s environment with no model write access to the audit store. The kill switch operates at three grains, session, user or application, and full deployment, without the model’s cooperation, and is held by a role separate from the administrator who configures policy.

Separation is a technical property that must be demonstrable in an architecture diagram, not asserted in a terms-of-service clause. Three properties define genuine separation: no network path from the model to the policy engine, audit store, or configuration; no write access to its own logs; and no credentials to any of those systems. A gateway the model can reconfigure or disable provides no meaningful separation.

Identity parity: extending the plane you already run

The identity architecture for an enforcement layer extends the conditional access, MFA, and risk-based policy programs already running in your enterprise, applied to every model, agent, and tool in the same way they govern human access. Each model and agent holds its own scoped, least-privilege identity, revoked at session end or policy trip. On-behalf-of token exchange means the model acts within the calling user’s entitlements, with no standing service account for an attacker reaching the model to inherit.

CISOs should note the ServiceNow trajectory. With the Veza acquisition closed March 2026 and Armis closed April 2026, ServiceNow is positioning itself as a competitor to Entra ID for identity at scale, including machine and AI agent identities. This is a meaningful consolidation in the non-human identity governance market. The enforcement layer must be identity-provider neutral to preserve architecture optionality as this market evolves.

The kill switch: specify it before you need it

A kill switch is a first-response instrument and should be specified with the same precision as a network block or credential revocation. Three granularities matter:

Session grain: Suspends or throttles a single conversation or agent run. Targeted, reversible, lowest blast radius.
User or application grain: Cuts off one identity or one integration. Appropriate when anomalous behavior is attributable to a specific caller or integration.
Deployment grain: Halts every model session simultaneously. Reserved for the scenario where the model itself, the provider’s infrastructure, or a systemic policy failure requires immediate full stop.

The kill switch must function without the model provider’s cooperation, because the scenario requiring activation may involve the provider’s infrastructure being unavailable or compromised. It addresses future actions. Rollback addresses what already happened: the sent message and the emptied database. Both are required. Kill-switch triggers should be defined in advance, sustained policy violation rate, a DLP match, an anomalous tool-call sequence, so activation is a policy-driven operational decision. Rehearse it on your incident-response drill cadence.

Single models and agent swarms: one enforcement pattern

The same five control layers and the same five questions apply across the full deployment spectrum, from a single model call to a multi-agent swarm. Who is calling? What are they asking for? Is it allowed? Is the response safe to return? Is it logged? In a single model call, a missed policy violation affects one response. In a multi-agent workflow with no human reviewing each step, that same violation can cascade across dozens of tool calls before anyone sees it.

The hub-and-spoke gateway architecture deploys enforcement at the right layer. A central hub authors policy, stores identity federation, audit records, and session context. Spoke gateways enforce policy locally near each resource. The hub never touches a request directly. The Autonomous Action Runtime Management specification (AARM), now donated to the Cloud Security Alliance with more than 100 adopters, provides the five-outcome decision framework for each action point: allow, deny, modify, step-up to a human, or defer pending more context.

Four gaps in hub-and-spoke require explicit CISO assessment:

Chain-level risk: Individual calls may look harmless while a sequence pushes an agent outside its authorized role. Require your vendor to demonstrate policy evaluation over chains of calls as well as individual requests.
Fail behavior under load: Failing open at peak volume means enforcement stops when it is needed most. Require documented, configurable fail-open or fail-closed behavior per integration.
Coverage depends on inventory: The hub governs only traffic routed through it. Require vendors to demonstrate how AI assets that bypass the hub are detected and reported.
MCP-only visibility: Skills, hooks, plugins, and direct API calls move alongside MCP traffic. Evaluate R20 and R22 together as a combined coverage assessment.

Enforcement is not governance: the full program

An enforcement layer governs every individual interaction in real time. A complete AI risk program requires additional capabilities that must be funded and owned separately:

AI inventory: Every model, agent, and MCP server accounted for, including embedded models in purchased software.
Model lifecycle management: Version changes and capability-tier upgrades governed before they propagate to production workloads. R26 (proposed) addresses the gap where behavioral drift within a tier can silently undermine policies verified against a previous model version.
Third-party provider scoring: Every provider scored across five dimensions on a continuous basis, rescored on safety-framework updates and material incidents, as well as at annual renewal.
Continuous control assurance: The enforcement layer stays configured and working.
Runtime risk monitoring and trust scoring: Behavioral drift detected and translated into a live score per model or agent that feeds back into access decisions at the enforcement hub.
Board-level reporting: Enforcement telemetry translated into risk language a governance committee can act on.

Provider risk scoring drives three governance gates. Below the onboarding threshold, any new frontier AI dependency requires explicit executive risk acceptance. The contract gate embeds score thresholds as triggers for capability-tier change notice and delivery of evaluation summaries. The exit gate means score deterioration triggers a formal alternative-provider review before the next renewal cycle.

The 90-day CISO action plan

Table 1 organizes the most critical actions across architecture, procurement, and governance by 30-day horizon. Architecture and procurement actions run in parallel with governance actions; neither track waits for the other.

TABLE 1: 90-Day CISO Action Plan for AI Enforcement Layer Deployment

Source: IDC, 2026

The 26 enforcement-layer requirements: your RFP foundation

Table 2 consolidates all 25 published requirements (R1-R25) plus IDC’s proposed R26, which addresses a gap in the current set: advance notification of model updates that materially change behavior in policy-sensitive areas. This gap is distinct from C2 (capability-tier change notice), which covers tier-level changes. R26 addresses behavioral drift within a tier, which can silently undermine policies verified against a previous model version.

For each requirement: mark it Must or Should based on your deployment risk profile. Ask for the evidence listed. Verify in a pilot. A failed Must is a no-go. Apply the five contract terms (C1-C5) to every current and prospective AI vendor contract, covering model provenance disclosure, capability-tier change notice, safety-framework documentation access, incident disclosure timelines, and continuity planning.

TABLE 2: AI Enforcement Layer Requirements R1-R26 and Contract Terms C1-C5

Source: IDC, 2026

Three gates every CISO should establish now

The requirements above translate directly into three governance gates that convert procurement policy into enforceable controls:

Procurement gate: Below your provider-score threshold, any new frontier AI dependency requires executive risk acceptance before contracting. This gate applies to embedded models in purchased software as well as direct model API contracts.
Architecture gate: Before any AI integration goes to production, require the vendor to produce an architecture diagram showing the deployment boundary, separation between the model and your policy engine, and the kill-switch role assignment.
Contract gate: Score deterioration triggers a formal alternative-provider review and activates notice clauses in existing contracts. C2 covers capability-tier changes. R26 covers behavioral drift within a tier.