Bring AI to Data, Not Data to AI

• • Enterprise data often carries more durable value than the model used to interpret it.
  • Keeping data in place can help preserve existing security, governance and ownership controls.
  • Bringing AI processing closer to the source can reduce unnecessary data movement and duplication.
  • A distributed AI architecture lets organizations place models where the data, latency and workload require.

---

Models are becoming easier to move, deploy and replace. Enterprise data isn’t. And that changes how we should think about AI infrastructure.

A few months ago, I was talking with a large enterprise customer about one of their AI projects. They had the models. They had the GPUs. They had a strong engineering team, and they had years of valuable enterprise data that could make the AI application incredibly powerful.

There was only one problem: They didn’t want to move the data.

At first, that sounds like an infrastructure problem. It wasn’t.

The data contained years of intellectual property, customer information, engineering knowledge and operational history. It lived inside systems that had been secured, governed and audited for years. The idea that the company would suddenly copy all of that information somewhere else simply because a new AI application needed it wasn’t realistic.

Someone in the meeting said something very simple:

“The data is already where we want it. Why do we need to move it?”

That question stayed with me, because I think it exposes one of the biggest architectural assumptions we are carrying from the previous generation of computing into AI.

We keep trying to move data to AI. Maybe we should be doing the opposite.

Data has gravity. Models don’t.

For years, infrastructure has talked about data gravity. The idea is straightforward.

As data accumulates, it becomes increasingly difficult to move. A few gigabytes are easy. A few terabytes are manageable. Hundreds of terabytes become a project. Petabytes become infrastructure.

And when you start talking about decades of enterprise data distributed across data centers, clouds, storage systems, factories and edge locations, “let’s move the data” stops being a technical detail — it becomes a business decision.

But something interesting is happening on the other side of the equation.

AI models are becoming increasingly portable. There is a growing range of models available today.

Small language models can run locally. Vision models can run close to storage. Large models can run on GPU infrastructure inside the enterprise. Frontier models can be accessed through APIs.

And the model you use today may not even be the model you use six months from now.

So we have two things moving in opposite directions.

Models are becoming easier to move while data is becoming harder to move.

Yet much of enterprise AI architecture is still designed as if the data should move toward the model.

I think that assumption needs to change.

The most valuable thing the enterprise owns isn’t the model.

Imagine two manufacturing companies buy access to exactly the same foundation model.

They can buy similar GPUs. They can use the same open-source frameworks. They can hire people with similar AI skills.

What can’t they buy?

Thirty years of manufacturing history. Millions of quality inspection images. Engineering drawings. Maintenance records. Machine telemetry. Failure reports. Supplier information.

The knowledge of what went wrong, why it went wrong and how engineers fixed it.

That is the company’s real AI asset, and the same is true in almost every industry.

For a bank, it might be decades of financial and customer information.

For a pharmaceutical company, research and scientific data.

For a hospital, clinical knowledge and medical imaging.

For an automotive company, enormous collections of video, sensor and engineering data.

For a media company, decades of proprietary video and audio.

For an enterprise software company, source code, support cases, product documentation and customer interactions.

The model can be replaced. The data is much harder to replace.

And once you look at enterprise AI through that lens, the architecture starts to look very different.

“Upload your data” sounds very different inside an enterprise

Many AI demos begin with a remarkably simple step:

Upload your documents.

For an individual user, that’s easy. For a large enterprise, those three words can trigger months of meetings. I have seen variations of this conversation repeatedly.

An AI team builds a successful proof of concept using a subset of enterprise data.

The demo works. Everyone gets excited. Then they decide to connect the real data:

Security joins the conversation.

Then compliance.

Then legal.

Then the data owners.

Then infrastructure.

Suddenly people start asking different questions: Where exactly is our data going?

Who has access to it? Is another copy being created? How long is that copy retained?

Does the model provider see it? Can we guarantee that it stays within a particular geography? What happens when the original file is deleted? What happens when permissions change? How do we delete the copy? Which version is now authoritative?

And my favorite question:

Why are we copying it in the first place?

That is usually the moment when an AI experiment meets enterprise reality.

Think about an engineering company

Consider a global engineering company with decades of product information.

CAD files.

PDFs.

Technical manuals.

Images.

Test results.

Service reports.

Videos.

Specifications.

Maybe hundreds of millions of files. The company wants to build an engineering AI agent. The traditional approach says: identify the relevant information, move it into an AI environment, process it, create embeddings and build a new knowledge repository.

But now imagine telling the CIO:

“We’d like to copy your company’s engineering knowledge into another system so our AI can understand it.”

That conversation is going to be difficult.

And it should be.

Those files may represent some of the company’s most valuable intellectual property.

They already live in infrastructure the enterprise trusts.

They already have permissions. They already have owners. They already have governance.

They already have backup and disaster recovery. They already have security policies.

Why should AI require the company to create another copy of its crown jewels?

A different architecture would bring AI processing into that environment.

AI becomes a visitor rather than the new owner of the information.

A factory tells an even better story

Now consider a manufacturer operating dozens of factories. Every factory may generate enormous amounts of data every day. Cameras continuously inspect production lines. Machines produce telemetry. Robots generate sensor information. Quality systems produce reports. Engineers create maintenance records. Most of that information is useful only in context. Imagine a camera generating video 24 hours a day to identify defects. Do we really want to continuously upload every frame from every camera in every factory to a centralized AI platform? Probably not.

Maybe the AI should come to the factory. Run the vision model locally. Analyze the video close to where it is created. Identify the small fraction that matters. A defect. An unusual event. A safety issue. A machine behaving differently from normal. Then move the result. Move the event. Move the metadata. Move a few relevant frames. Move the embedding. Move the insight.

But don’t move thousands of hours of video simply because somewhere else there is a GPU. That is the difference between moving data and moving intelligence.

Move intelligence, not data

I think this is one of the most important concepts for the next generation of enterprise AI.

We don’t always need to move the data. We need to move what we understand about the data.

Take a two-hour industrial video. The raw file might be tens or hundreds of gigabytes.

But perhaps the AI application only needs to know:

At 14:32, machine number 17 showed an abnormal vibration.

Or consider a 200-page engineering manual. An AI agent doesn’t necessarily need another permanent copy of that PDF. It may need:

What product is this document about?

Which version is it?

What components does it reference?

Who can access it?

Where is the original?

What does section 17 say about replacing a particular component?

That information is dramatically lighter than the underlying dataset. Metadata is lighter than data. Embeddings are lighter than data. Events are lighter than data. Knowledge is often lighter than data. And that creates a completely different architectural possibility. Keep the heavy asset where it belongs. Move the intelligence.

Now imagine a bank

The argument becomes even stronger when the data is highly sensitive. Imagine a bank building an AI assistant for employees. The bank has enormous amounts of valuable information across internal documents, customer systems, policies, communications and historical records. The AI team wants the assistant to understand all of it. The obvious approach is to collect the information into an AI knowledge environment. But from the bank’s perspective, the first question isn’t:

“How intelligent is the model?”

It is:

“Where is my data?”

And then:

“Who can see it?”

For regulated industries, these questions aren’t obstacles to innovation. They are requirements. Instead of forcing every dataset into a new AI repository, imagine bringing approved AI processing to the environment containing the sensitive information. The information can be classified and processed under existing enterprise controls. Sensitive content can remain in place. Permissions can remain attached to the source. And only authorized knowledge is exposed to the AI application. That architecture can allow the enterprise to gain intelligence from the data without unnecessarily surrendering control over the data.

AI doesn’t change who owns the data

I think this point gets lost in some of the excitement around AI. Enterprise data isn’t just fuel for a model. It is an asset. Companies spent decades creating it. Customers trusted them with it.

Employees generated it.

Engineers designed it.

Factories produced it.

Researchers discovered it.

Businesses built processes around it.

There is enormous value in that information.

And enterprises don’t suddenly want to upload their most valuable asset everywhere just because AI has arrived. If anything, AI makes controlling that asset more important. Because for the first time, machines can understand enormous portions of previously inaccessible enterprise information. An old engineering archive was once just millions of files. With AI, it becomes searchable institutional knowledge. Years of video were once just storage. With AI, they become a dataset describing how the physical business operates. Millions of support cases become a map of every problem customers have experienced. The data didn’t become valuable because AI arrived. It was always valuable. AI simply made more of that value accessible.

The model should be the movable part

This leads me to a fairly simple conclusion. When one component is easy to move and another is difficult to move, move the easy one. Models are software. Data is gravity. A company can deploy a model near a storage system. It can run inference on an on-prem GPU. It can deploy a small model at the edge. It can call a larger model when necessary. It can replace one model with another. The enterprise should be able to choose the model based on the workload. But the data shouldn’t have to migrate every time the model changes.

That is backwards. Imagine rebuilding your data architecture every time a better LLM appears. We may see many major model changes over the next few years. The enterprise data estate will still be there. So the stable architectural layer should be the data. The models should come and go.

This changes the economics of enterprise AI too

Moving less data isn’t only about security. It’s also about economics. Moving petabytes costs money. Duplicating petabytes costs money. Synchronizing petabytes costs money. Processing information repeatedly because five different AI projects created five different copies costs money. And then there is the operational cost of governing all of those copies.

Which one is current?

Which one contains sensitive information?

Which one can be deleted?

Which one is being used by which model?

Which one inherited the latest permissions?

The cheapest byte to move is often the byte you never needed to move in the first place. If AI can determine close to the source what information is valuable, the amount of information that needs to travel can decrease significantly. That becomes especially important as enterprises move from millions to billions of files and from terabytes to petabytes of unstructured data.

Enterprise AI won’t live in one place

There is another reason I believe this architecture will become increasingly important. Enterprise AI itself is becoming distributed. Some models will run in the cloud. Some will run in corporate data centers. Some will run next to storage. Some will run inside factories. Some will run on edge devices. Some tasks will use massive foundation models. Others will use small specialized models that can run almost anywhere. So asking, “Where does the AI run?” may eventually become the wrong question. It will run in many places. The better question is:

Where should this particular AI task run given where the data is?

If the data is enormous, bring compute closer. If the data is sensitive, process it within its security boundary. If latency matters, process it locally. If only a small piece of information needs a frontier model, extract that information first and send only what is required. That is a more natural architecture for the enterprise.

The companies that understand this will treat data differently

We are entering a period where almost every company will have access to powerful AI models. That will be incredible. But it also means access to the model itself becomes less differentiating. Two competitors can use the same model. They can’t have the same data. They don’t have the same customers. They don’t have the same history. They don’t have the same engineering knowledge. They don’t have the same factory data. They don’t have the same failures, lessons, processes and experience. That proprietary context is what makes enterprise AI valuable. So perhaps the most important question for enterprise AI isn’t:

How do we get all our data into AI?

It is:

How do we let AI securely use our data without giving up control of our most important asset?

For me, the answer starts with changing the direction of the architecture. Don’t assume the data has to move. Let the data stay where it has gravity. Let it stay where it is secured. Then bring intelligence to it. Models will change. Infrastructure will change. AI frameworks will change. The data will remain.

And that is exactly why I believe the future of enterprise AI will increasingly be about bringing AI to data instead of moving data to AI.

Conclusion

The future of enterprise AI will not be defined by how quickly organizations can copy all their data into a new environment. It will be defined by how intelligently they can bring processing to the data, preserve control and move only what the workload requires. Dell AI Data Platform is designed to help organizations build that kind of open, distributed foundation for AI.

Ready to put your data to work?

If you’re looking to turn enterprise data into a real advantage for agentic AI, this is the next step. Dell AI Data Platform is built to help organizations create AI-ready datasets, automate data pipelines and support modern workloads across the full AI lifecycle.

• • Start by registering for the Dell AI Data Platform event: https://www.thecube.net/events/dell/dell-ai-data-platform-event-from-ambition-to-ai-at-scale
  • Explore Dell AI Data Platform with NVIDIA: https://www.dell.com/en-us/blog/dell-ai-data-platform-with-nvidia-full-throttle-ai/
  • Explore PowerScale for AI at scale: https://www.dell.com/en-us/shop/storage-servers-and-networking-for-business/sf/powerscale
  • Explore the Dell Data Orchestration Engine: https://www.dell.com/en-us/shop/artificial-intelligence/sc/data-orchestration-engine
  • Continue the conversation: https://www.dell.com/en-us/lp/contact-us

---

Frequently Asked Questions

Why bring AI to data instead of moving data to AI?

Because enterprise data may be large, sensitive, distributed and governed by existing controls. Bringing processing closer to the source can reduce unnecessary movement and duplication.

Does this mean data should never move?

No. The point is to move only what the workload requires — such as metadata, events, embeddings, insights or selected content — while keeping authoritative data where it belongs when appropriate.

How does this approach support security and governance?

It can help organizations keep existing permissions, ownership, retention and security controls attached to data while approved AI processing occurs within the relevant environment.

Where can models run in a distributed AI architecture?

Depending on the workload, models can run in the cloud, in enterprise data centers, near storage, in factories or at the edge.

How does Dell AI Data Platform help?

Dell AI Data Platform helps organizations orchestrate data ingestion, preparation, processing, retrieval and inference across distributed environments, supporting AI workloads from pilot to production.