The Data Problem Nobody Is Talking About Yet

Jensen Huang called it “the ChatGPT moment for physical AI.” Yann LeCun left one of the most powerful AI labs on earth to chase it with a $5B valuation target. Fei-Fei Li built a company around it. And yet most enterprise technology conversations about world models still get filed under the same mental category as GPT-4 — just another model, just another vendor, just another API to evaluate. That framing is going to cause real problems.

World models don’t predict the next word. They predict what happens next in physical reality — spatial relationships, cause-and-effect, the behavior of objects in three-dimensional space. That is not a better LLM. It is a different kind of machine, with different infrastructure requirements, different data dependencies, and different failure modes. Treating it as an incremental upgrade is the mistake that gets baked into your three-year roadmap.

The Data Problem Nobody Is Talking About Yet

World models are trained on interaction data, simulations, and video datasets — not text corpora. The companies best positioned to win this space are the ones sitting on proprietary physical-world data: Tesla’s fleet telemetry, Meta’s egocentric video, NVIDIA’s simulation environments via Cosmos. Enterprise IT shops have none of this. Your organization does not have a moat of video data the way Tesla has built one through eight years of Autopilot deployments.

This creates a structural dependency that is categorically different from LLM procurement.

When you buy GPT-4 access, you’re renting reasoning over human-generated text — a commodity that exists everywhere. OpenAI trained on the internet plus some proprietary datasets, and the performance delta from having that specific training data is real but bounded. When you need a world model for your manufacturing floor or logistics operation, the model is only as good as the sensor and spatial data it was trained on. Your vendor’s data moat matters enormously. A world model trained on automotive video will fail differently than one trained on warehouse footage, and both will underperform in environments they’ve never seen.

CB Insights framed it usefully: these models “simulate and predict how environments change over time.” That simulation fidelity is directly proportional to training data quality and domain specificity. A generic world model will underperform in the same way generic LLMs underperform on specialized enterprise tasks — except the gap will be wider and the consequences more physical. An LLM that hallucinates on your specific regulatory language costs you cycles in review. A world model that hallucinates object trajectories in your warehouse costs you a collision.

Compare the due diligence process for the two.

When you evaluate an LLM API vendor, you run benchmark tests on your own data, you check latency and cost, you negotiate contracts. The underlying training data is opaque, but it doesn’t need to be — the model has already been trained on something broad enough that domain-specific gaps are usually addressable through fine-tuning or prompt engineering. When you evaluate a world model vendor for a warehouse robotics deployment, you need to know where their training data came from. How much of it was captured in conditions similar to yours? How was the simulation data generated? What environments has the model failed in, and why? These are not vendor-relations questions. These are architecture questions. You’re not just evaluating a model. You’re evaluating the data pipeline that the vendor has access to and the spatial domains they’ve already mastered.

Infrastructure Assumptions Built for LLMs Will Not Hold

Near-term, high compute requirements for video and spatial model training favor NVIDIA as the primary infrastructure beneficiary. NVIDIA’s CES 2026 announcements — Alpamayo, Cosmos Reason 2, Cosmos Predict 2.5 — signal that the physical AI infrastructure stack is being built out now, not in three years. The vendor is signaling the timeline. Most enterprise infrastructure teams are still negotiating LLM capacity contracts.

The deployment architecture is fundamentally different from what LLM workloads have trained your organization to build.

The investment thesis from the analysts tracking this space describes a three-phase shift: from current LLM-era compute centralization, through embodied AI in structured industrial settings (2027–2029), to world models distributed across edge networks (2029+). Enterprise infrastructure teams planning three-year roadmaps are still designing for phase zero. Your cloud architecture is optimized for sending data to a central model and getting back a token stream. That works for language. It does not work for spatial reasoning that needs to react in milliseconds to real-time sensor input.

Most engineering teams already underinvest in the infrastructure layer for LLM workloads. The standard observation from practitioners is that teams need at minimum a model provider, a data platform, and a deployment platform, and routinely underprepare the last two. With world models, the inference requirements at the edge are orders of magnitude more demanding. Spatial intelligence interacting with physical environments cannot tolerate the latency of a round-trip to a cloud API. If you’re running a robotaxi fleet on NVIDIA Alpamayo, that model is running on-device, on-vehicle. The inference happens locally. The compute is pushed to the edge, not pulled from the center.

This inverts your infrastructure spending pattern.

LLM deployments have pushed enterprises to consolidate compute in data centers and cloud providers — centralized models, distributed access. World model deployments will require distributed compute, which means hardware at the point of action: robots, vehicles, sensors. That hardware needs to be managed, versioned, updated. Your fleet of warehouse robots is a fleet. It needs infrastructure discipline the way a fleet of servers does. Most organizations have no playbook for that yet. They have playbooks for cloud APIs. They do not have playbooks for pushing a new model to a thousand robots and verifying it doesn’t break the collision avoidance logic before it hits the floor.

Uber’s planned 2026 robotaxi deployments via NVIDIA Alpamayo illustrate what real-time world model inference demands look like at the edge. That is not a cloud service. That is not an API call. That is a distributed system where the model is running on hardware you do not own, in environments you cannot fully control, making decisions that interact with the physical world in real time. The infrastructure requirements are closer to automotive embedded systems than to SaaS deployments. Your enterprise IT team’s experience with Kubernetes and load balancers is partially relevant. Your team’s experience with over-the-air updates and safety-critical system versioning is more relevant, and most teams have almost none.

What This Means Right Now

The companies currently leading in world models — AMI Labs, World Labs, NVIDIA’s physical AI division — are notably secretive about their architectures, their training data, and their commercial models. TechCrunch noted earlier this year that the big players “rank pretty low on the trying-to-make-money scale.” That opacity is not a reason to wait. It is a reason to start asking different questions now, before procurement cycles, vendor lock-in, and infrastructure debt make the wrong assumptions permanent.

The enterprises that treated LLMs as a search upgrade are still recovering from that decision — they built for search, they got a reasoning tool, and now they’re retrofitting their entire data and deployment strategy. The ones that treat world models as better LLMs will be next. They will design their infrastructure for cloud APIs when they need edge compute. They will evaluate vendors on model performance when they should be evaluating them on training data domain coverage. They will assume their LLM procurement playbook applies.

Start now with the assumption that it does not.