Privacy by design in human-demonstration capture
Egocentric demonstration data records a real face, home, and voice, so it is personal data by construction. Treat privacy as a capture spec, not policy.
A person straps on a capture rig and makes a pot of coffee in their own kitchen. The head camera sees their hands on the grinder, which is the point. It also sees the child at the table, the letter with a home address face-up on the counter, a face half-reflected in the kettle, and it hears a phone call in the next room. Every one of those is a detail the robot policy will never use, and every one of them is personal data about a real human being.
This is the uncomfortable shape of egocentric human-demonstration data. To teach a robot how a hand actually moves, you record a real person doing a real task in a real place. The signal you want, the hands and the object and the forces, arrives welded to a stream of things you have no business keeping: identity, location, bystanders, speech. You cannot capture the first without capturing the second.
So privacy is not a policy document you attach after the shoot. It is a property of the capture rig, the on-site pipeline, and the schema, decided before anyone presses record. Treat it as an engineering spec and it is tractable. Treat it as legal's problem and you will be reconstructing consent for footage you already shipped, which is the expensive way to learn the lesson.
Why this footage is personal data by construction
Under the GDPR, personal data is any information relating to an identified or identifiable person. A first-person recording of someone cooking clears that bar many times over in a single frame. Their face is identifiable. So is their voice, their home interior, the street through a window, sometimes a screen with their name on it. Bystanders who never agreed to anything are identifiable too, and they did not sign up to train a robot.
Biometric traits raise the stakes. A face and a voiceprint fall under special categories of data, which the GDPR guards more tightly than an ordinary name. The EU AI Act leaves all of this in force and adds its own data-governance duties on top. Neither regime cares that the footage was collected to train a gripper. Purpose does not launder personal data back into something anonymous.
Two pipelines: privacy by design against scrape and hope
There are broadly two ways to build a human-demonstration corpus, and they diverge at the very first step.
The scrape-and-hope pipeline optimizes for volume. Pull first-person video from wherever it can be found, or record loosely and sort it out later, then push the raw footage to a central store and worry about faces and consent when a customer's lawyer asks. It is fast, it is cheap on day one, and it accumulates a liability that grows with every clip. The raw store becomes the single most sensitive asset the company owns, and it was never designed to be one.
Privacy by design inverts the order. GDPR Article 25 names this directly, data protection by design and by default, and it means the safeguards live in the system, not in a review meeting. Consent is captured with the recording. Faces and voices are stripped before the footage leaves the device. The corpus that reaches the training cluster was never personal data at rest, because the identifying layer came off at the edge. The two pipelines can produce a similar-looking dataset. Only one of them survives an audit without a retrain.
You cannot anonymize a checkpoint. Whatever identifying detail the capture rig let through is baked into the weights, and no amount of policy after the fact will get it back out.
The five controls, and what breaks without each
Privacy by design is not a slogan. It is a short list of concrete capture-time controls. Each one protects something specific, and each one has a failure mode that shows up later if you skip it.
| Control | What it protects | Failure mode if skipped |
|---|---|---|
| Documented consent at capture time | The subject's legal basis and scope of use | No lawful basis for the whole corpus, and a withdrawal you cannot honor |
| Face and voice anonymization at source | Biometric identity of subject and bystanders | Special-category data shipped and stored, so a breach exposes faces, not tensors |
| Data minimization, keep the task, drop the room | Home interior, documents, third parties | Sensitive context retained forever with no training value |
| Edge or on-device processing | The raw stream itself | Raw footage in transit and at rest becomes the crown-jewel liability |
| Per-session provenance | Traceability for erasure and audit | A deletion request becomes a forensic search with no index |
Read the right-hand column as a list of incidents waiting to happen. None of them is exotic. Each is the direct, predictable cost of moving a control downstream, from the rig to a cleanup script, from capture time to audit time.
Anonymization is a signal-preservation problem
Here the engineering gets interesting, because the naive version destroys the data you came for. Blur everything and you have protected the subject and thrown away the hands. The task is to remove identity while preserving manipulation signal, and those two live in different regions of the frame. Faces, bystanders, and background documents can be masked or blurred hard. Hands, objects, contact points, and the wrist view must stay pixel-sharp, because that is the whole recording.
Voice is its own decision. Speech carries a voiceprint and often names, addresses, and third-party conversation. For most manipulation tasks the audio channel that matters is contact sound, the click of a latch or the scrape of a drawer, not language. Drop speech, keep contact audio, and you remove an identifier while losing nothing the policy regresses to.
There is a legal line worth getting right. The European Data Protection Board draws a sharp distinction between anonymization and pseudonymization. A blur that can be reversed, or a hashed identifier that can be rejoined, is pseudonymization, and pseudonymized data is still personal data under the GDPR. True anonymization, where re-identification is no longer reasonably possible, takes the data out of scope. That difference decides whether your corpus is a governed personal-data asset or an ordinary dataset, so it is a design target, not a checkbox.
Erasure is a schema problem, not a delete query
Consent under the GDPR is revocable, and the right to erasure is real. A subject can come back a year later and ask that their contribution be removed. If your only index is a bucket of ten thousand video files named by timestamp, honoring that is a forensic project. If every session carries a provenance record, subject identifier, consent version, capture date, rig, and processing chain, as a first-class sibling of the tensors, then erasure is a query and a re-export.
This is where the privacy angle and the provenance angle meet. Datasets like Ego4D and Ego-Exo4D built exactly this scaffolding: signed participant agreements, de-identification passes, and per-clip metadata, precisely because raw first-person footage is unusable at scale without it. They are the existence proof that consented, traceable egocentric capture is possible. They are also proof of how much deliberate structure it takes. The scaffolding is not overhead you add to the data. Increasingly it is the line between a dataset you can ship and one you cannot.
Privacy in human-demonstration capture is not a constraint bolted onto the interesting work. It is part of the interesting work. The rig that records a person's hands is also recording their face, their home, and their voice, and the only question is whether you decided what to do about that before the first frame or after the first audit. Teams that decide early get a corpus they can defend. Teams that decide late get a retrain, or a deletion they cannot perform. Design for it at capture, and privacy stops being the thing that slows the data down. It becomes the reason the data is worth having.