Home Humanoid Data Policy Checklist

This guide is not another explainer about the gig workers behind robot training. We covered that supply chain in our prior piece on the invisible workforce training home robots. The buyer problem now is narrower and more practical: which data questions should you ask when a humanoid company says its robot learns, improves, or can be guided by a human operator?

The short version: do not treat data policy as legal boilerplate. For a home robot, it is part of the product spec.

Why data policy is a robot capability

A smart speaker mostly hears sound. A security camera mostly sees a fixed field of view. A home humanoid can combine cameras, microphones, depth sensors, tactile sensors, maps, motion history, task labels, app commands, and sometimes remote human assistance. That creates a richer picture of a home than most consumer devices ever see.

The data is also operational. Robot companies need it to debug failed grasps, train manipulation policies, evaluate safety, and decide whether the machine completed a task. Figure's Helix announcement makes the core challenge clear: the home is hard because objects are varied, tasks are long, and conventional robot learning can require either expert programming or many demonstrations. 1X says NEO can use Expert Mode when a chore is beyond current autonomy. Unitree G1 is sold as a research platform with SDK access and over-the-air upgrades. Agility's Digit is tied to Arc, a cloud automation platform for enterprise fleet monitoring.

Those are not identical models, but they all point to the same buyer reality: autonomy is a loop. Sensors observe, software acts, humans may review or guide, updates change behavior, and new data may improve the next attempt. If that loop enters a private home, the loop needs rules.

What data policy should home humanoid buyers demand?

Before comparing individual robots, split the issue into three separate disclosures. A company can be strong on one and vague on another.

A good policy makes those boundaries understandable before checkout. A weak one buries them in broad terms such as "improve our services" without explaining what the robot actually sends, who reviews it, or whether the owner can opt out without losing core functions.

What current humanoids already tell us

The ui44 database shows why one generic privacy checklist is not enough. The robots near the home-humanoid conversation have different prices, statuses, sensors, and support models. Those differences should change the data questions you ask.

The table is not a verdict on any company. It is a reminder that "humanoid" is not one product category. A $13,500 developer platform, a $20,000 home preorder, and an enterprise RaaS robot create different privacy and training-data risks.

1X NEO: remote help needs plain boundaries

1X is one of the few companies talking directly about a home humanoid. Its NEO page says the robot is designed for household chores, safe human interaction, contextual help, and continued learning. It also describes Expert Mode: when a chore is beyond the robot's current autonomy, a 1X Expert can guide it so NEO learns while the job gets done.

That is refreshingly honest. Early home robots will not be fully autonomous at every task, and pretending otherwise would be worse. But Expert Mode also makes data policy central to the product.

A serious NEO buyer should ask:

• Can Expert Mode start only after explicit approval for each session?
• Does the remote expert see live video, audio, maps, task history, or only a restricted robot-control view?
• Are sessions recorded by default?
• Can the owner delete a recording and prevent it from being used for training?
• How are visitors, children, bedrooms, bathrooms, and sensitive documents handled?
• Can the robot finish basic chores if the owner opts out of model-training use?

The goal is not to reject remote help. Remote assistance may make the first wave of home humanoids more useful and safer. The goal is to know whether the remote-help system respects the home as a private place.

Figure, Tesla, and the factory-to-home gap

Figure and Tesla are useful because both show how much humanoid progress is happening before consumer home sales.

Figure's Helix post says the system runs on onboard embedded GPUs and combines language understanding with fast robot control. It also says Helix was trained on a multi-robot, multi-operator dataset of about 500 hours of teleoperated behaviors. That is not a home privacy scandal. It is a concrete example of how robot learning depends on operators, robot cameras, labels, and controlled data collection.

Tesla Optimus Gen 2 is still listed in ui44 as development-stage, with a future target price around $30,000 and internal factory work rather than consumer sales. Factory-first deployment can be sensible: tasks are bounded, sites are controlled, and failures can be reviewed by employees under business policies. But factory learning does not automatically answer home questions. A kitchen, nursery, bedroom, or elder-care apartment needs stricter consent and deletion controls than a factory aisle.

For any factory-to-home humanoid, ask what changes at the boundary:

• Is the consumer robot covered by a dedicated robot privacy policy?
• Does video leave the home by default, or only during support incidents?
• Are factory training logs, consumer logs, and partner datasets kept separate?
• Can users review a history of data exports and remote-access events?
• Are model updates tested for household safety, not only workplace throughput?

A company that can answer those questions clearly is more credible than one that only says its robot uses AI.

Agility Digit: enterprise monitoring is not a home template

Agility Digit is not sold as a home robot, and that distinction matters. Digit's current value is industrial: warehouse workflows, box carrying, fleet coordination, and integration through Agility Arc. Agility describes Arc as a cloud automation platform that can monitor workflows, show live metrics, and manage fleets, with service support and real-time monitoring.

That model can be appropriate in a business facility. The customer is an organization, the task area is known, the legal relationship is negotiated, and workers can be trained around the system. It is a poor default template for a private home.

If an enterprise humanoid architecture later moves toward home care, delivery, or domestic assistance, buyers should watch for copied assumptions. "Real-time monitoring" sounds normal in logistics. In a living room, it requires a tighter permission model: visible indicators, per-session approval, room-level privacy zones, clear audit logs, and a way to run local or offline modes when possible.

Digit's enterprise posture is not a knock against it. It is a useful contrast. The more a robot depends on fleet software and remote support, the more the home version needs user-facing controls instead of admin-only dashboards.

Unitree G1: affordable does not mean consumer-simple

Unitree G1 is one of the most accessible humanoids in the database: $13,500 starting price, compact 132 cm body, 35 kg weight, depth camera, 3D LiDAR, four-microphone array, Wi-Fi 6, Bluetooth 5.2, SDK support, ROS2 compatibility, and about two hours of battery life. The official G1 page also warns individual users to understand humanoid limitations before buying.

That warning is important. G1 is available, but it is closer to a research and development platform than a polished home appliance. The data policy challenge is therefore different from NEO's. A developer robot may involve custom code, third-party packages, cloud dashboards, local logs, external cameras, app accounts, and experimental OTA updates.

Before bringing a developer humanoid into a home, ask:

• Which data is sent to the manufacturer app or cloud service?
• Can the robot run locally without uploading camera, LiDAR, or microphone data?
• What logs are created by SDK tools, ROS2 nodes, and third-party packages?
• Are OTA updates automatic, optional, or reversible?
• Does the buyer have a way to disable sensors or create no-record zones?
• Who is responsible if experimental code stores private home data badly?

For technically skilled buyers, G1's openness is part of the appeal. For normal households, openness without clear governance can create more risk, not less.

A practical buyer checklist

Use this checklist before paying a deposit, joining a waitlist, or inviting a robot trial into a private home.

Data collection

1. List every sensor that can capture the home. Cameras, depth sensors, LiDAR, microphones, tactile skin, force sensors, maps, and app commands should be described separately.
2. Ask what is stored versus processed temporarily. A robot can use live perception without saving raw footage forever.
3. Ask whether private rooms can be excluded. Room-level privacy zones should be visible and easy to change.
4. Ask how bystanders are handled. Visitors and family members did not necessarily buy the robot or consent to training use.

Human access

5. Ask when a human can connect. Remote help should require explicit owner approval, not a broad always-on permission.
6. Ask what the operator can see and control. Video, audio, map, arm motion, mobility, and stored history should have separate permissions.
7. Ask for an access log. Owners should be able to see when remote sessions happened, who initiated them, and what data was exported.
8. Ask how contractors are governed. Outside annotation or support vendors need the same restrictions as the robot company.

Training and updates

9. Ask if your data trains future models. Product debugging, support, and model training are different uses.
10. Ask whether opt-out breaks the product. A robot that becomes useless without broad data sharing is not offering meaningful consent.
11. Ask whether updates are reversible. A bad model update should have a rollback path or safe mode.
12. Ask how failures are reviewed. Dropped objects, collisions, blocked paths, and failed grasps should trigger safety review, not only performance analytics.

What good answers sound like

Good answers are specific. They sound like: "Remote operation is off by default. You approve each Expert Mode session. The operator cannot enter privacy-marked rooms. Raw video is retained for 30 days unless you delete it sooner. Training use is opt-in. You can export the session log. Critical updates can be paused or rolled back."

Weak answers are vague. They sound like: "We may collect information to improve our products," "service partners may process data," or "AI learning requires continuous improvement" without explaining the actual robot data path. Those phrases are common in software terms, but a mobile robot with cameras and arms needs more precision.

Also watch for missing separation between support and training. If a remote operator helps unload a dishwasher, that may be acceptable as a service session. It should not automatically become permanent training data unless the owner understands and accepts that use. The same goes for worker and contractor data: a company should be able to explain how demonstration data is consented, filtered, retained, and protected.

How to compare robots with ui44 data

When you compare robots on ui44, start with hardware and status, then add the data-policy layer.

• Use the robot pages for concrete specs: 1X NEO, Figure 03, Tesla Optimus Gen 2, Agility Digit, and Unitree G1.
• Use /compare to separate a consumer preorder from an enterprise deployment or developer platform.
• Check sensors and connectivity before accepting a privacy claim. A robot with microphones, depth cameras, LiDAR, tactile sensing, Wi-Fi, and cloud support needs more than a one-line privacy promise.
• Treat missing price and status honestly. A robot that is not for consumer sale yet may not have consumer-grade policy documents yet either.
• Revisit the question after major updates. Data policy can change when a robot gains remote help, subscriptions, new skills, or more autonomous chores.

The strongest home-humanoid companies will make this easy. They will publish clear data-flow diagrams, remote-access rules, retention windows, opt-out paths, safety-review processes, and update controls. They will not ask buyers to infer all of that from a demo video.

Bottom line

Home humanoids will not become useful without data. They need demonstrations, teleoperation, evaluation, failure logs, simulation, fleet learning, and safety review. The right response is not to panic about every data loop. The right response is to make the loop visible.

For buyers, the key question is simple: can the company explain what the robot records, who can access it, how long it is kept, whether it trains future models, and what control the household has? If the answer is no, the robot is not ready for private rooms, no matter how impressive the walking demo looks.

Treat the home humanoid data policy as a core spec. Compare it beside price, battery life, payload, sensors, and support. A robot that can carry a box but cannot clearly protect your household data is not yet a trustworthy home robot.