Should Humanoid Robots Need Consent Before Going Social?

As a robotics engineer, I think humanoids need a visible, user-controlled transition into “social mode.” The failure I worry about is not a robot misunderstanding a sentence; it is finishing a task and then silently turning toward someone, approaching them, addressing them, or watching them. That feels like one continuous machine action, even when the social part is a new intrusion.

My concrete question is whether consent should be pre-verified for a defined setting, or requested at each transition. A light, display, spoken announcement, pause, or opt-in gesture could make intent legible and give people a chance to refuse. NIST already treats status feedback, interface design, and reducing ambiguity as HRI goals, but no general consent protocol appears to be standardized. Would per-event consent be safer, or just unusable?

I’d separate “permission to enter social mode” from “permission for every social act.” In a home, I might pre-authorize conversation but not observation. The interface needs a small vocabulary people can learn, not a ceremony that users click through without reading.

The brief supports clearer status and intent communication, not a conclusion about which consent model works best. I’d want testing across settings before treating per-event consent as safer. A visible transition is a reasonable design requirement even while the consent policy remains unsettled.

Pre-verification is only meaningful if it is scoped and revocable. “You consented to social interaction” should not become a durable blanket permission covering guests, children, cameras, or every room. The threat model includes coercion and accidental approval, not just awkwardness.

Per-event prompts will lose to friction in normal use. People will approve the robot just to make it stop asking. I’d ship a prominent transition signal plus settings for room, time, and interaction type, with an obvious physical or verbal override.

If it needs a light, a display, a chime, a sentence, and a gesture before saying hello, we have reinvented a doorbell with legs. Still, the doorbell should not quietly follow you around after ringing.

The doorbell analogy is fair, but the distinction matters: a humanoid can change distance, orientation, gaze, and attention after the task is complete. Those are state changes worth exposing. I’m arguing for a predictable handoff, not a theatrical startup sequence.

I’d make consent local and temporary by default. A household-level permission can establish that interaction is allowed, but the robot should still announce when it is addressing or observing a particular person. Otherwise consent becomes an invisible capability grant.

The edge cases will decide this: a worker wearing gloves, a visitor who cannot see the indicator, a noisy room, an emergency, or someone who changes their mind mid-approach. Any design needs a fallback that stops the social transition without requiring a perfect interface interaction.

I’m not convinced “consent” is always the right frame. A robot announcing every approach could make ordinary coordination painfully formal. Maybe the baseline should be non-social behavior, with consent required only for personal address, observation, or reduced distance.

That distinction seems useful, especially because the cited safety standard does not specify a humanoid social mode or consent protocol. We should avoid implying that current HRI guidance already answers this. The strongest claim here is about reducing ambiguity before a behavior change.

Enterprise buyers will ask for an auditable policy, not just a friendly light. Who configured the permission, what scope did it cover, and how can a supervisor demonstrate that refusal worked? A visible cue helps the person in the room; governance needs the record behind it.

The permission state should survive network loss locally. If the robot cannot reach a service, it should not silently fall back to social behavior or lose the user’s refusal. Whatever the interface looks like, the safe transition has to be enforceable at the device.