A Frozen Model Is Not a Frozen System
Talk to enough robotics teams and you hear the same line: “We’re using off-the-shelf models, so tracking what trained them isn’t really our problem.”
It sounds reasonable. Someone else pre-trained the backbone. Your team didn’t touch the weights. Why would you need to reproduce training data you never had?
Because almost nothing in that sentence stays true once robots ship. Here are five places the logic breaks.
1. Off-the-shelf doesn’t stay off-the-shelf
You adapt foundation models for physical AI to your own real-world data. The entire value proposition of a vision-language-action model is that you post-train it on your embodiment’s data: your teleop demos, your fleet recordings, your simulation runs.
The moment your team runs a fine-tune, a LoRA, or imitation learning on your own demonstrations, you own training data provenance. You have to answer: which demos went in? Which were filtered out, and by what rule? What did the dataset look like on the day the policy was trained?
But you can’t reconstruct states you never captured. If versioning starts after the first fine-tune, the provenance of that fine-tune is already gone. The infrastructure has to precede the training run, not follow it.
2. The weights are frozen. The world isn’t.
Suppose you really do run the model untouched, forever. Your system’s behavior is still the model plus everything around it: camera calibration, maps, configuration files, prompts, retrieval data, perception thresholds. All of that changes weekly.
As a result, same weights plus a changed input world is a materially different AI system. And your model registry will happily report the same version string the entire time.
When a robot does something unexpected in the field, the forensic question is rarely “which weights were deployed?” Instead, It’s “what did the system consume?” The registry answers which model was deployed. Data version control answers what world it saw.
3. Your validation data is yours, no matter who trained the model
Nobody sends a bought model to a fleet without evaluating it on their own scenarios first. That evaluation set is a dataset your team curates, changes, and reruns, and it’s the evidence behind every deployment decision you make.
Without versioning, “the model passed validation” is a claim about a dataset state that no longer exists. Six months later, when a safety board or a customer asks how you validated the behavior that just made the news, you need the exact test set, not the folder it used to live in.
Standards like ISO 26262 make this explicit for automotive: reproducible, audit-ready evidence linking requirements, data, and tests. The standard does not care where the base model came from. The trace chain is yours to keep intact.
4. Regulators bind the deployer, not just the model vendor
The EU AI Act’s transparency obligations took effect on August 2, 2026, with high-risk obligations following in 2027 and 2028. Two things in it should get a robotics team’s attention.
First, substantially modifying or fine-tuning a model inside a high-risk system can make you the provider, with everything that entails. Second, Article 10’s data governance requirements cover the training, validation, and testing data of the high-risk system, which includes the data you use to validate and operate a model you bought.
Buying the model transfers none of the liability. “Our vendor trained it” is not an answer regulators accept, and it won’t be an answer your enterprise customers accept in procurement either.
5. You are already building tomorrow’s training set
Robotics teams hoard fleet data for a reason: it’s the moat. The events you’re tagging and curating this quarter are next year’s fine-tuning corpus, whether or not there’s a training run on the roadmap today.
In other words, the provenance question is already live. Uncaptured lineage is a debt that compounds silently and comes due on the day you decide to train. Teams that version their data from the start inherit a clean chain of custody. Teams that don’t inherit an archaeology project.
What this looks like when it’s solved
In practice, none of this requires replacing your stack. Your recordings, curated datasets, labels, and simulation outputs already live in object storage. The missing piece is a layer that makes that storage auditable and reproducible: it records every change to a dataset as a permanent snapshot, lets teams work on isolated copies of petabyte-scale data without duplicating it, and links every downstream consumer of that data back to the exact version it used.
That’s what lakeFS does. As the control plane for AI-ready data, it sits between your object storage and the tools, users, and agents that consume it. Every training run, evaluation, and fine-tune ties back to an exact, immutable dataset version. Teams get isolated branches of petabyte-scale data without copying it. Bad changes roll back in seconds, and lakeFS captures the audit trail regulators ask for automatically, so you never reconstruct it by hand.
Volvo runs this pattern on the sensor data and images continuously collected from its cars: teams experiment on massive datasets, reproducibly, without duplicating them.
The gap is common. According to Dun & Bradstreet’s AI Momentum Survey, 97% of organizations have active AI initiatives, but only 5% say their data is ready to support them. In physical AI, where the data is multimodal, massive, and about to be regulated, that gap is the whole game.
Your robot logged everything. The question is whether you can prove what trained the model, what validated it, and what world it saw when it acted. If the honest answer is “not yet,” start before the next fine-tune, because that history only exists if you capture it.
Get the whitepaper: Governance & Compliance for Your AI Data Infrastructure
