For many enterprises, an AI factory starts as the data center they already run, with a retrofit plan. The moves are familiar: add a GPU cluster, stand up a vector database next to the storage you already have, and put an inference service in front. And for the first few projects, it works.
Those choices get you the compute you need, but they don’t address the data layer underneath. An AI factory asks much more of that layer than a conventional data center ever did. It has to feed the models, hold the context they work from, and capture what they produce, continuously, for every team that wants to use them.
VAST describes an AI factory as two connected systems: a token generation engine for training and inference, and a context supply chain that brings enterprise knowledge into the models and captures what comes back out.
You can add the token engine to an existing data center. The harder part is building the context supply chain around infrastructure that was designed mainly to store and serve data.
Here are five places where that retrofit starts to break down.
AI Factory vs. Data Center: What Changed?
In addition to scale, the data layer has a new role. In a conventional data center, applications drive the work: they decide when data gets read, where the indexes live, who has access, and what happens to the results. In an AI factory, the data layer takes on those decisions. The work starts when data changes, and the agents carrying out that work cross systems on behalf of users.
Each row in the table corresponds to one of the following failure modes.
Dimension | Traditional Data Center | AI Factory |
Data behavior | Applications read and write data | Data changes can initiate work |
Derived data | Indexes live in separate systems | Source data, vectors and metadata stay connected |
Access model | Applications access known systems | Agents cross systems on behalf of users |
Outputs | Results and logs are stored | Outcomes become input to future work |
Data platform | Stores and serves data | Participates directly in the AI workflow |
Failure Mode 1: Data Changes, but the AI Doesn’t React
Traditional storage is built to wait. A file can change, a record can be updated, or new data can arrive, and the storage system simply makes the new version available the next time an application asks for it.
That model is awkward for an AI factory. Much of the work starts because something changed in the data. A new document may need to be parsed and embedded. An updated record may need to change what an agent knows or does. If the data platform cannot initiate that work, teams end up adding polling jobs, scanners, message buses, and orchestration just to notice that something happened.
The better model is for changes in the data layer to become events that can trigger processing directly. That removes a lot of plumbing between the data and the AI systems that depend on it.
Retrofit Tell: If your AI only learns that data changed because another system goes looking for changes, the data platform is still operating like conventional storage.
Failure Mode 2: AI-Derived Data Loses Its Connection to the Source
AI turns one piece of business data into many derived pieces: text, chunks, vectors, metadata, classifications and relationships.
In a traditional architecture, those derivatives often end up in separate systems while the source stays in the original file or object store. Keeping them in sync becomes an engineering job: custom pipelines, cleanup scripts, and sync logic someone has to own.
If the source is deleted, its vectors should disappear. If access changes, the same rule should reach the derived data. If an agent retrieves a chunk, you should still know exactly where it came from. When pipeline stages live on separate systems, every handoff becomes another copy with another security model.
The better model is to keep derived data on the same platform as its source, so lineage and permissions carry over instead of being rebuilt at every handoff.
Retrofit Tell: If deleting or restricting a source requires cleanup or synchronization somewhere else, AI has already created a second data estate.
Failure Mode 3: Agents Can’t Safely Reach Across the Enterprise Data Estate
Agents rarely stay inside one application boundary.
A support agent might need case history, product documentation, telemetry, entitlement data and contract terms to solve one problem. A manufacturing agent might need drawings, images, maintenance records and supplier information.
Those sources are separated for good reasons. HR, legal, finance, and customer data all have different access controls.
The shortcut is to copy what the agent needs into a common repository or give it a highly privileged service account. Neither is a good production answer.
The alternative is to preserve user identity and permissions as the agent moves across files, objects, tables, vectors and tools. Without that, teams end up feeding the agent only the subsets security is willing to approve, which limits what it can actually do.
Retrofit Tell: If making an agent useful requires copying protected data or giving it broader access than the person using it, the existing data architecture cannot safely support the agent.
Failure Mode 4: AI Outputs Become Logs Instead of Inputs to the Next Decision
An agent does more than produce an answer. It chooses context, calls tools, takes actions and creates an outcome.
That outcome may contain useful information for what happens next. A correction can improve future retrieval. An evaluation can expose missing context. A successful action can become an example for another run.
Legacy infrastructure usually scatters those outputs across logs, databases and observability tools. Closing the loop becomes another integration project.
The better model treats the context supply chain as a loop. Data becomes context, context shapes an answer, the answer creates an outcome, and the outcome becomes new context.
Retrofit Tell: If useful agent outcomes disappear into log storage until someone builds another pipeline to recover them, the AI factory has an open loop.
Failure Mode 5: The Data Platform Can Store AI Data, but Can’t Participate in the AI Workflow
This is where retrofitting a data center for AI becomes expensive.
The storage system may still be doing its job perfectly well, but the AI work now happens around it. Teams add services to detect changes, process content, generate embeddings, maintain workflow state, run agents, and keep track of what all those systems produced. The data platform becomes the place where information sits while an expanding collection of infrastructure does the useful work somewhere else.
That approach gets expensive because every new AI application tends to recreate the same foundation. The support agent needs its own processing and retrieval path. Legal builds another. Sales builds another. Over time, the organization accumulates a growing set of pipelines and integrations whose main purpose is to make enterprise data usable by AI.
The better model is one foundation that every AI project builds on, where the data platform does that work itself instead of hosting the data while a separate stack does it per team.
Retrofit Tell: If every new AI project begins by rebuilding the machinery required to prepare and expose enterprise data, the data platform is still serving AI from the sidelines.
How Much AI Factory Infrastructure Are You Building Around the Data Platform?
A data center can run AI workloads. The real question is how much additional machinery you need before those workloads become an AI factory.
If the platform cannot react to data changes, preserve the relationship between source data and AI derivatives, enforce identity across agent workflows, capture outcomes as new context, or participate directly in processing, those capabilities still have to come from somewhere. They show up as brokers, polling services, vector databases, synchronization jobs, orchestration layers and custom integration code.
You can bolt all of that onto a data center, and many teams do. But then the AI factory is being built around the data platform instead of on it. The racks may look the same, but the data platform underneath them has a very different job.
The AI Factory Needs Its Own Operating System
At VAST, we believe AI factories need a platform designed for AI from the beginning. We call that platform the AI Operating System.
The idea is simple: the work that turns enterprise data into usable AI context should happen on the same foundation that stores and governs that data. When information changes, the system can process it without handing it off through a chain of disconnected services. The context created from that data remains tied to its source and its permissions, so agents can work against live business information without breaking the security model around it.
That same foundation carries through to agent execution. Identity stays bound to the work the agent performs, and observability can follow the path from ingest through processing and retrieval all the way to the action the agent takes. The result is one integrated system built to run the context supply chain, rather than a collection of products that customers have to assemble themselves.
