Does your AI strategy have a storage security problem?

When it comes to conversations about security and AI, most start in the right place but stop too soon. The conversations address models, compute infrastructure, and application-layer controls, which are real concerns. Yet, the storage layer, where AI data is concentrated, governed and exposed, does not receive enough consideration. As enterprises move from pilot to production, this is becoming harder to ignore.

 

Data that was once distributed across storage, compute and application layers is now being drawn together, processed at higher velocity and exposed through access paths that did not exist a few years ago. That changes the risk profile considerably and shifts where security controls need to be focused.

 

 

AI changes what storage is, not just how much you need

Training AI workloads draw information from across the organisation in ways that were never designed to sit alongside each other. A training dataset for a foundation model might combine intellectual property and regulated customer data in a single, queryable store, which is a risk in itself. Controlling that risk starts before the data is stored. Segmenting training data and anonymising or removing sensitive inputs where possible limits the exposure that aggregation creates.

 

Retrieval-Augmented Generation (RAG) systems emphasise this further. When you connect a large language model to an enterprise knowledge base, storage becomes a live query layer. It is no longer a repository that users access directly. It becomes an active participant in every interaction the AI system makes. A misconfigured access control on a RAG index can surface sensitive information through a completely valid query. That also makes auditability essential; logging what data is accessed and surfaced by RAG systems supports both investigation and compliance to prevent structural exposure.

 

 

Inference workloads introduce different pressures

Production systems like AI assistants and fraud detection engines depend on continuous, low-latency access to data. The persistent connections and pipelines that make this possible operate at a speed that simultaneously makes manual oversight impractical. Those access paths need to be secured with the same rigour as any other part of the environment. What this means in practice is protecting data in motion between storage and inference systems while validating at runtime that services access only what they require.

 

For organisations running AI across large, distributed environments, visibility over data lineage becomes particularly difficult to maintain. Analytics pipelines frequently span hybrid infrastructure and operate across structured and unstructured data simultaneously. Without clear sight of how data moves and transforms, enforcing policy or identifying anomalous behaviour becomes genuinely difficult.

 

The more telling trend, though, is why storage has become a target in the first place. AI is raising the stakes and reshaping defences simultaneously. It increases the value of stored data, accelerates how it moves across systems and introduces new, often under-secured, access paths, making the integrity and recoverability of enterprise storage a core security priority. As the data supporting AI systems becomes more central to operations, storage environments become correspondingly more attractive to attackers. That is the real pressure bearing down on security architectures right now.

 

 

What resilient storage needs to look like

Visibility is the starting point. Continuous insight into data movement and access patterns is the prerequisite for everything else. Dell Technologies’ Innovation Catalyst research found that 82% of IT decision-makers recognise data as the differentiator for AI integration and that it must be used and protected accordingly, yet only one in three say they can turn that data into real-time insights. Much of that gap traces back to the storage layer. Without closing it, governance frameworks and policy controls are operating on incomplete information.

 

As data becomes more valuable, so does the need to ensure it cannot be altered. Immutable storage prevents training datasets, model artefacts and audit logs from being modified or deleted, making it a core defence against ransomware and data tampering. Locking critical datasets at the storage layer reduces the blast radius of a successful attack and preserves the integrity of the systems that depend on them.

 

Segmentation and Zero Trust work alongside this. AI workloads should have access limited to what they actually need when operating. That means separating datasets by sensitivity and function and applying Zero Trust principles consistently. Enforce least-privilege access and continuous verification, with explicit policy controls across all interactions. For organisations operating under NIS2 or DORA, this kind of control architecture is increasingly expected rather than optional.

 

Recovery is where the conversation needs to shift most. The question organisations should be asking is whether their AI systems can resume trusted operations quickly following an incident, not simply whether a restore is technically possible. That means recovering the correct datasets and model versions, rebuilding data pipelines and testing recovery against real workloads, with storage dependencies able to fail over rapidly to avoid operational disruption. Recovery plans that do not account for these dependencies will leave organisations exposed in ways that a successful backup restoration will not fix.

 

 

The practical implication

Storage has become a primary control plane for AI risk. The challenge is applying the right controls with enough specificity to the workloads now running against that storage. Organisations that get that alignment right will reduce their exposure and build justified confidence in their AI systems as adoption continues to scale.

 

---

 

Stewart Hunwick is Field CTO, Storage Platforms and Solutions, Dell Technologies

 

Main image courtesy of iStockPhoto.com and imaginima