What’s holding your organization back from tapping the full opportunity of AI? If your firm is like most, chances are the devil is in the data. AI needs data to succeed – but businesses don’t have the at-the-ready data they need to support it. For just one representative statistic, consider Gartner’s prediction that “organizations will abandon 60% of AI projects unsupported by AI-ready data” through 2026.

For a prime culprit of the data disconnect, look to the pipelines. Today’s data architecture is built on a foundation that made sense for the relatively static data needs of a pre-AI era. As new AI demands more, astronomically faster, safer data access, the reigning networked data architectures just can’t keep up. It’s time for something new.

At Dymium, we’ve created that - a new, more agile, and more secure data access approach for interacting with the AI-driven ecosystem. I’ll explain that approach in pieces to follow. But first, I want to lay out the core of the problem. While the reigning data architecture made sense before the recent AI revolution, it’s now failing its users in two crucial areas: security and speed.

To understand the current failure, let’s take a quick trip to the past.

‍

ETL: Architecture for a Slower-Data Era

In the late 1980s and early 1990s, engineers needed a way to corral data from across systems and make them actionable.​ They’d extract the originating information, transform it into workable form, and load the data into central data warehouses like IBM DB2 or Oracle.​ ETL (Extract, Transform, Load) was born.

Over the years, ETL has evolved – and still powers contemporary setups like ELT. Across applications, the central concept is the same: to make data useful for consumption, development or business analytics, you need to move that data from one fixed point to another.​ It's an approach that makes a lot of sense in the relatively static environment of computing as recently as 2020.​

In the AI era, however, this traditional approach is a recipe for problems – as I’ll explain below, starting with the security issues involved.

‍

Threat Alert: Data that’s Spread too Widely

The ETL’s networked data approach has always carried inherent risk. After all, if you need to copy and move the data to make it usable, you’re also dramatically multiplying the chances that that data can be leaked, stolen, or otherwise subject to attack or corruption. For a sense of the scale of the problem, one recent survey found that enterprises held “an average of 10 million duplicate data records” across the org. That’s a lot of disasters waiting to happen.

That surface becomes especially combustible when you interact with AI – because AI tools can use your data as a training foundation for its models. This ingestion means that your leaked or stolen data may go towards helping the AI’s next users – including every one of your competitors, who can now benefit from your sensitive data and IP to solve problems and ship solutions better and faster than ever. Even the most advanced firms aren’t immune to this data hijacking: for instance, OpenAI has alleged that rival AI firm DeepSeek is built in no small part on careful, unauthorized use of ChatGPT prompts.

Keep in mind that all of this risk is happening in the context of widespread “Shadow AI.” Despite (and often because of) various top-down bans on AI applications, workers are going rogue and doing work on unauthorized LLMs tools, without their firms’ knowledge. Studies find that the problem is huge and growing: over 80% of workers use unapproved AI tools for their work, 75% of those who use unapproved AI share potentially sensitive info, and unapproved generative AI violations more than doubled last year.

Major data leaks and breaches to AI can easily follow.  And often, the sensitive data in question isn’t just just internal company information – it’s highly regulated data. Take the example of the Australian government contractor who uploaded private details – including names, contact details and health information – of 3,000 flood victims into ChatGPT last year.

Again, these leakages are happening in the context of data that’s distributed across the organization already. For a sense of the perfect storm this creates, consider IBM’s Cost of a Data Breach Report 2025, which analyzed a close cousin of shadow AI data leaks: shadow AI data breaches. The study found that firms “that suffered a shadow AI security incident reported the breached data was most often stored across multiple environments and a public cloud” (emphasis mine) – and that “customer PII was the most compromised data type.”

Bringing the issues full circle: all of these problems exist, in large part, because of the reigning data arrangement in which users need to move their data to make it fully useful. If users didn’t need to pass along their data and entrust it to the AI tools – if instead, there were a way to work external applications on the data while keeping that data at rest and under internal “lock and key” – firms could far more freely use AI tools safely. Widespread dangers of leakage and breaches would go away, IT teams could give their workers far greater freedom in terms of the AI applications they’re able to work with, and the need for Shadow AI altogether would largely subside.

But since the reigning data arrangements do require the data to move, we are where we are.

Above, I outlined the problem that ensues because networked setups force data to flow too freely. But traditional data setups pose nearly the opposite problem, too: they don’t let data move swiftly enough, as I’ll explain next.  

‍

AI Speed, Meet Data Roadblocks

AI is likely the greatest productivity accelerant of our lifetimes. For just two representative statistics: workers’ productivity increases 33% every hour they use generative AI; and AI agents can work 88.3% faster than human counterparts.

This astronomically faster work requires astronomically fast data. There’s a hitch though: the current frameworks can impose major roadblocks. There are the technical limits on ETL speeds, “brakes” imposed in the name of data governance, and sometimes simply the need to wait on a colleague to hit “send.”

AI agents, in particular, face huge challenges when faced with traditional data approaches. As IBM researchers Ioana Giurgiu and Michael E. Nidd framed the problem:

Traditional databases and data fabrics were designed for static, well-defined workloads, whereas agentic systems exhibit dynamic, context-driven, and collaborative behaviors. Agents continuously decompose tasks, shift attention across modalities, and share intermediate results with peers - producing non-deterministic, multi-modal workloads that strain conventional query optimizers and caching mechanisms.

AI agents and traditional data systems can be vastly out of sync.

Given what I’ve laid out above, AI-hobbling slowdowns are all but inevitable. Indeed, one report finds that over half of IT teams have dealt with “excessive latency” in AI applications or workloads. As one Gartner sums it up, “traditional data management operations are too slow, too structured, and too rigid for AI teams.”

The latency issue poses more than just a threat of too-slow answers to highly pressing questions. Particularly as agentic AI takes over workflow, systems that need to collaborate can also end up operating at variable speeds. Picture shipping centers dropping off packages before warehouses are ready, industrial robots that start assembling before the rest of the line is prepared, or poorly aligned scheduling bots managing patient care at a hospital, and you have an idea of what kind of havoc agentic data latency can cause.

In short: AI workflows happen at a pace that traditional data structures simply can’t support. For the new world, we need a faster path to getting critical data in-the-moment.

There’s good news, though.  We’ve built a better way.

‍

Don’t Move the Data. Go To It.

As I said above, the problems above are all grounded in a single problem: networked data has to move to be fully useful. We’ve turned that approach on its head and forged a new way.

We can reduce the attack surfaces and other risks, dramatically accelerate data access, and better control where and how data ultimately gets shared with AI applications – by moving AI data access and governance to where the data is already.

At Dymium, we’ve made that transformation happen. With a revolutionary platform that moves data access all the way upstream – to the data layer itself – we’re turning data access from AI’s chief impediment to its primary catalyst.

In further posts, I’ll lay out what that better AI data approach means in detail. For now, I’ll just say that, for the reasons above, the reigning data access frameworks of today just aren’t adequate anymore – but the data access of tomorrow is here right now.

‍