Consent by design: GDPR for robot demonstration data
Egocentric robot demonstration data records a real person, so GDPR applies in full: consent, minimization, and erasure become capture-time engineering.
You hand someone a capture rig and ask them to make coffee in their own kitchen. Twenty minutes later you have a clean multimodal recording: head camera, wrist camera, depth, hand pose, force at the fingertips, the hiss of the kettle. You also have a recording of a specific human being. Their face. Their apartment. Their voice. The exact way their hands move.
That second fact is a legal object, not only an engineering one. Under the General Data Protection Regulation, any recording that can identify a person is personal data, and a face or a voice used to single someone out is biometric data, which sits in a stricter category still. The kettle has no rights. The person pouring from it does.
Most robot-data pipelines were built as if they were scraping the web, where the legal work belonged to whoever first published the page. Egocentric human demonstration removes that buffer. You pressed record on a real person, so the duties begin with you, at the sensor. What follows is what GDPR asks of a capture pipeline, and why scraped or offshored data can never be made to comply after the fact.
Classification comes first
Start with classification, because the rest falls out of it. Web text arrives softened by distance: the author is faceless, the moment has passed, the exposure feels like someone else's. A head-camera recording of a person cooking is the opposite, dense and intimate and traceable to one human. GDPR labels anything that can identify a person personal data. It treats a face or a voice used to single someone out as biometric data, which Article 9 places in a special category with tighter conditions and, in practice, a need for explicit consent.
Some teams assume that feeding the footage to a model launders all of this. It does not. The European Data Protection Board has held a steady line: using personal data to build a model is processing like any other, with no special AI exemption, and the obligations attach the instant you record. The EU AI Act sits on top of GDPR rather than replacing it, and its data-governance duties are explicitly without prejudice to data-protection law.
This is not a fringe reading. Ego4D, the large head-mounted video dataset, wrote consent and face and audio de-identification into its capture protocol precisely because first-person footage is personal data by construction. If a research consortium filming everyday chores treated consent as a requirement, a commercial pipeline selling into the EU cannot wave it away as cleanup.
Lawful basis is a field, not a footer
Every recording needs a lawful basis under Article 6, and biometric special-category data needs an explicit one under Article 9, in practice the subject's explicit consent. Consent that holds up has to be specific, informed, freely given, and as easy to withdraw as it was to grant. That is a structured record tied to a named session, not a banner someone clicked once.
Two more principles bite at capture time. Purpose limitation means you collect for a declared purpose, so training robot manipulation policies has to be named up front, not quietly stretched later to cover a use nobody consented to. Data minimization means you keep only what the purpose needs. A manipulation policy needs hand trajectories and contact forces. It does not need a crisp, identifiable face, so the pipeline should be discarding or blurring identity at the earliest moment it can.
A lawful basis is either recorded while the person is still in front of the sensor, or it is not real. You cannot go back and collect consent from a subject you can no longer name, on footage whose faces you have already blurred.
Data-subject rights outlive the recording
Here is where egocentric data turns genuinely hard, and where many pipelines have no answer. GDPR hands the person recorded a set of standing rights: access under Article 15, erasure under Article 17, and objection under Article 21, among others. These are not one-off consent formalities. A participant can return a year later and ask you to remove everything they appear in, and the law expects a working mechanism, not an apology.
Consider what that takes once a clip has flowed into a training set. You have to know which clips contain that subject, which derived files and labels came from them, and which model checkpoints trained on them. That is an index keyed to a pseudonymous subject ID and maintained from capture through delivery, not a directory of loose video. Without it, an erasure request has no mechanical meaning, and the honest reply to the regulator collapses to a shrug.
Pseudonymization is the design that keeps this tractable. Tokenize identity at the source, hold the mapping between subject ID and real person in a separate, access-controlled key, and every downstream artifact can be traced and pulled without exposing anyone in the meantime. Genuine anonymization can even move data outside GDPR's reach, but only if it is irreversible, and irreversible anonymization of rich multimodal capture is harder than a face blur implies. Gait, hand geometry, and a voiceprint can each re-identify a person the blur was meant to protect.
What each duty demands of the rig
None of these obligations stays abstract. Each lands as a concrete requirement on the capture pipeline, with a specific failure mode when it is skipped. The failure modes are not distant fines. They are datasets a European buyer cannot lawfully put into a product.
| GDPR obligation | What it demands of the capture pipeline | Failure mode if ignored |
|---|---|---|
| Lawful basis (Art. 6 and 9) | Explicit, per-session consent bound to each subject and every clip they appear in | No provable basis to process; the data is unlawful and near worthless to a regulated buyer |
| Purpose limitation (Art. 5) | The purpose, robot policy training, declared at capture and stored with the session | Reuse for a new purpose needs a fresh basis; silent scope creep voids the original consent |
| Data minimization (Art. 5) | Identity channels the task does not need dropped or blurred at the earliest point | An identifiable face rides along as pure liability with zero training value |
| Pseudonymization (Art. 4) | Identity tokenized at source, the reversible key held separately under access control | A late blur pass loses the mapping, so deletion requests cannot be honored |
| Data-subject rights (Art. 15, 17, 21) | A subject-indexed store linking each person to every clip, file, and checkpoint | Access and erasure requests are unanswerable once the data is inside a training set |
| Cross-border transfer (Chapter V) | Processing and annotation kept with entities under EU safeguards | An offshore labeling step exports personal data with no lawful transfer path |
Built in at capture, or not at all
Set the two pipelines beside each other. One records a consenting participant, stamps the lawful basis and purpose onto the session, pseudonymizes identity at the sensor, and keeps a subject index that can honor an erasure request years on. The other scrapes video from the open web, or offshores capture to wherever it is cheapest, and hopes the question never lands. Only the first can answer a regulator. The second holds a corpus it cannot make lawful in hindsight, however large it grows.
This is the plain case for capturing under EU jurisdiction instead of importing a corpus of murky origin. GDPR restricts moving personal data outside the EEA without safeguards, under Chapter V, so a European buyer inherits your transfer decisions along with your files. The EU AI Act then stacks documentation and data-governance duties on top for high-risk systems while leaving every GDPR obligation intact. A capture process that logs consent, purpose, and a pseudonymous subject key as structured metadata is most of the way to satisfying both. A process that defers them is booking a debt that comes due the first time a participant, an auditor, or a buyer's counsel asks a question it cannot answer.
None of this is a reason to slow down capture. It is a reason to design the capture rig as if a data-protection authority and a data subject will both eventually knock, because under EU law both can. The teams treating consent, minimization, pseudonymization, and the right to erasure as parameters of the recording session, fixed before anyone presses record, will be the ones whose data a European robot maker can put into a model. A recording of a real person is a responsibility the moment it exists. GDPR just writes that responsibility down and gives the person in the frame a way to enforce it.