Hardik Parikh is Co-Founder, SVP and Business Head of Shaip, now part of Ubiquity, which supplies training data, annotation, data licensing and human evaluation to frontier AI labs and enterprises across speech, healthcare, computer vision and multimodal AI. A tech entrepreneur, he has built, scaled and exited businesses across AI data, healthcare technology and compliance, including emPower Solutions, and was an early leader at ezDI (acquired by AGS Health). In this interview, he explains why Physical AI succeeds or fails on whether its data reflects the real world, and how teams should evaluate, budget for and govern that data as systems move from pilots to production.
Where are the most consequential data-quality bottlenecks in Physical AI today, particularly for robotics and embodied systems?
I believe the biggest challenge in Physical AI today isn't necessarily the volume of data available. It's whether that data accurately represents the complexity and unpredictability of the real world.
Unlike traditional AI systems that primarily process text, images, or audio, Physical AI systems must interpret their surroundings, make decisions, and interact with physical environments. That introduces an entirely different level of complexity.
I see three major bottlenecks.
First is data diversity and representativeness. A robot trained in a controlled environment may perform exceptionally well there but struggle when lighting, objects, surfaces, or human behavior changes.
Second is multimodal data synchronization and annotation consistency. Physical AI often combines video, depth information, spatial data, and sensor readings. If those inputs aren't properly synchronized or annotated consistently, even sophisticated models can learn incorrect relationships.
Third is the long tail of edge cases. Real environments contain unpredictable situations that rarely appear in training datasets but can significantly affect performance and safety.
How do you evaluate whether synthetic or simulated training data will transfer reliably to real-world conditions?
Synthetic data is becoming increasingly important in Physical AI because collecting real-world data for every possible scenario can be expensive, time-consuming, and sometimes unsafe.
However, the fundamental challenge is the simulation-to-reality gap. A model may perform extremely well in a simulated environment but behave very differently when exposed to real-world conditions.
My view is that synthetic data should complement real-world data, not replace it.
The first step is establishing a representative real-world evaluation dataset that reflects the actual operating environment. That includes variations in lighting, object characteristics, background conditions, human interactions, and other factors relevant to the application.
Next, organizations should evaluate model performance across individual scenarios rather than relying exclusively on aggregate accuracy. For example, a robotic vision system might perform well overall but struggle with reflective surfaces, partially obstructed objects, or unusual lighting.
Synthetic data can be particularly valuable for generating rare events and difficult edge cases that would otherwise be expensive to collect.
But ultimately, real-world performance must remain the benchmark.
What failure modes do teams often discover only after deployment, and how can better data preparation reduce them?
One of the biggest lessons from deploying AI systems is that models frequently encounter situations that were underrepresented or completely absent from their training data.
In Physical AI, these failures can have more serious consequences because the system is interacting with the physical world.
For example, a warehouse robot might recognize objects accurately in a controlled setting but struggle when packaging changes, shelves become cluttered, lighting varies, or people unexpectedly enter its operating area.
I would highlight three common failure modes: environmental changes, unexpected edge cases, and inconsistent annotations.
Many organizations focus heavily on achieving high benchmark accuracy during development. But a model that performs well on a narrow dataset may not generalize to real-world conditions.
Better preparation begins with designing datasets around the intended operating environment, not simply collecting whatever data is easiest to obtain.
It also requires clear annotation guidelines, measurable quality standards, and continuous evaluation across different scenarios.
An equally important component is creating a feedback loop between deployment and data operations. When a model fails, that failure should inform future data collection, annotation, and evaluation.
How should teams balance data coverage, annotation quality, and the cost of collecting difficult edge cases?
I don't believe organizations should treat all training data equally. The right investment depends on the consequences of getting a prediction or action wrong.
For example, incorrectly identifying a product on a warehouse shelf is very different from failing to recognize a person entering a robot's operating area.
That distinction should influence how organizations allocate their data budgets.
I recommend a risk-based approach to data collection and annotation.
For common, lower-risk scenarios, organizations can prioritize broad coverage and efficient annotation workflows supported by automation and sampling-based quality checks.
For complex or safety-critical scenarios, the investment should shift toward carefully designed data collection, more detailed annotation, expert review, and stricter acceptance criteria.
Another important consideration is the cost of poor-quality data. Collecting large volumes of inexpensive data may initially appear economical, but inconsistent labels and missing edge cases can lead to expensive model retraining and deployment delays.
My recommendation is to avoid spending the entire budget on a single large collection exercise. Instead, use iterative collection cycles informed by model performance. That allows organizations to invest in the data that creates the greatest improvement.
What changes in data infrastructure or evaluation do you expect as Physical AI moves from pilots to production?
I expect one of the biggest shifts in Physical AI will be moving from project-based data collection to continuous data operations.
During the pilot stage, organizations often work with relatively controlled datasets and environments. Once systems move into production, they encounter new objects, different environments, changing behaviors, and unexpected situations.
That means data infrastructure can no longer be designed around a one-time collection and annotation process.
Organizations will need continuous pipelines that identify model failures, capture relevant examples, prioritize them for annotation, and incorporate them into future training and evaluation cycles.
I also expect evaluation frameworks to become significantly more sophisticated.
Instead of relying primarily on aggregate accuracy metrics, organizations will increasingly measure performance across specific environments, object categories, interaction types, and safety-critical scenarios.
Another major area will be data provenance, traceability, and governance.
As robots and embodied systems collect information in workplaces, public environments, and potentially homes, organizations must understand where their data originated, what permissions exist, and how that data can legally and responsibly be used.
What practical advice would you give organizations beginning to develop or deploy Physical AI systems?
My first recommendation is simple: start with the real-world problem and operating environment, not the model.
Organizations should clearly define where their Physical AI system will operate, what tasks it must perform, which objects and people it will encounter, and what constitutes successful and safe behavior.
Those requirements should drive the data strategy from day one.
Second, invest early in a representative real-world evaluation dataset. Without a reliable benchmark, it's difficult to determine whether improvements in training actually translate into better real-world performance.
Third, prioritize annotation quality and consistency. Even advanced AI architectures can struggle when the underlying training data contains ambiguous labels or inconsistent definitions.
Fourth, deliberately plan for diversity and edge cases. Don't assume that collecting more data will automatically produce a more representative dataset.
Fifth, establish clear data governance practices, including provenance, consent, privacy, and usage rights.
Finally, recognize that building a successful Physical AI system requires more than a strong model. It requires a reliable data supply chain.
Organizations should focus their internal expertise on areas that create competitive differentiation and consider specialized partners for complex data collection, annotation, and quality assurance.
At Shaip, we believe that high-quality, responsibly sourced, and well-structured training data is foundational to building AI systems that can perform reliably beyond controlled environments.
The future of Physical AI won't be determined by model sophistication alone. It will also depend on how effectively organizations translate real-world complexity into reliable training and evaluation data.
