The map leaves the robot

A robot can keep every camera frame inside its housing and still disclose the room. Consider a domestic service robot returning to its charger after a navigation run. The household sees an idle machine. A remote planner receives free space, obstacle geometry and a reference for tomorrow’s task. Nobody has asked for a photograph, and none has crossed the network.

For the engineer examining that transfer, the reassuring detail is what is absent: faces, video, recorded conversation. The more difficult discovery lies in what remains. A distinctive arrangement of connected spaces may identify a layout. An unnamed volume may suggest a bed. Repeated destinations near the same cabinet could offer clues about a routine. The packets need not contain a sensitive label to support a sensitive conclusion.

The machine has no interest in exposing its owner. It has supplied information useful to another component, exactly as designed. That is what makes the problem uncomfortable. A system can respect its camera policy while defeating the expectation behind it. Privacy depends on what leaves the machine after perception has converted the world into something easier to compute.

Derived data still speaks

In a 2 September 2026 preprint, Yuqiao Xu and Erman Ayday evaluate Task-Functional Perception Distillation (TFPD): keeping rich perception local while tailoring exports to downstream tasks. Across 120 AI2-THOR scenes, navigation exports delivered equal measured utility but different scene-linkability results. Replacing target labels with regions reduced target-category inference while preserving measured task success. Coarsening obstacle geometry reduced category inference at a collision-checking cost.

The operational distinction is between a message’s contents and the conclusions available from them. Direct exposure places information explicitly in the transfer. Residual inference recovers information from relationships that survive filtering. A planner may receive no room names yet retain enough spatial structure to support a guess. An anonymous shape remains a shape, with dimensions and neighbours that may narrow its possible identity.

Figure 1 locates that second route to disclosure beyond the protected perception boundary. The orange clues represent possible deductions, not additional sensor streams. For a product team, the uncomfortable question is whether the authorized recipient can learn more than the task requires. No compromised password is necessary for that failure; legitimate access may be sufficient.

The abstraction paradox

The same study’s ProcTHOR check changed the relative linkability ordering of normalized and topological maps; overlapping confidence intervals caution against universal rankings. Both scene distributions used the same execution engine. Physical robots and accumulated exports over time remain outside the evaluation, and scene matching in simulation does not establish household re-identification.

For an architect, abstraction therefore creates a decision rather than an automatic improvement. Removing distances might leave an unusual sequence of connected spaces. Rounding dimensions might conceal an object’s shape while preserving its position beside another recognizable structure. The size of the packet cannot settle which change matters. Neither can the absence of fields that once looked sensitive.

A manufacturer also has to answer for the information removed. If less precise obstacle data leave a downstream collision checker unable to distinguish a narrow passage from a blocked one, the privacy benefit arrives with an operational liability. Rich local geometry may still be needed even when an external service receives less. The engineering opportunity lies in separating those needs, then measuring the consequences, rather than forcing every consumer to share one compromised view of the world.

Three problems, three controls

At a fault review, three specialists could examine the same robot and reach different conclusions. The security engineer finds authenticated software and encrypted communication. The safety engineer investigates why motion stopped near an obstacle. The privacy specialist asks why the diagnostic service received enough geometry to characterize the surrounding room. Each can be correct without resolving the others’ concern.

Encryption can protect a transfer against interception while leaving its authorized recipient free to analyse the decrypted contents. Secure boot can help establish which software started without judging whether that software discloses excessive detail. A protective stop can limit physical consequences after a fault while an earlier log remains available elsewhere. Privacy, cybersecurity and functional safety intersect, but their evidence must answer different questions.

The regulatory calendar adds urgency without collapsing those distinctions. The European Commission states that Cyber Resilience Act (CRA) reporting requirements apply from 11 September 2026, covering actively exploited vulnerabilities and severe incidents affecting product security. Those obligations do not make every inference concern reportable or mandate TFPD. Product scope and incident circumstances still matter.

A board presented only with a successful penetration test would therefore lack a complete privacy assessment. The uninvited intruder and the approved service provider occupy different positions. A system needs evidence about both, including what its ordinary operation permits.

Design the representation boundary

The decisive interface sits where rich local interpretation becomes an export. A route planner may need traversability. A collision service may need obstacle envelopes. A maintenance record may need a fault class, software version and timestamp. Giving them all the same scene model makes integration convenient while leaving each recipient with information justified by somebody else’s task.

An information contract gives that interface an owner and a limit: declared purpose, recipient, permitted fields, update rate, retention and deletion behaviour. It also records the inference risks tested and the utility that justified the release. Figure 2 brings six review questions around the same gate, so a proposal to add geometry cannot disappear inside a routine schema change.

The National Institute of Standards and Technology (NIST) Privacy Framework supports voluntary organizational privacy-risk management. Applied to a robot programme, that discipline means assigning responsibility for disclosure decisions alongside responsibility for performance. It provides governance context, not certification of a particular export.

Failure behaviour belongs in that contract too. If the approved export cannot support a request, silently substituting a richer representation changes the bargain. A robot could instead defer the remote task, retain a local function where justified, or request a separately authorized diagnostic path. The appropriate response depends on the function and its safety requirements. The essential property is that reduced connectivity or service failure does not automatically grant a remote consumer broader access to the home.

The difficult case arrives when an exception is useful. A service engineer may need richer evidence to diagnose repeated navigation failures. Refusing all access could prolong a fault; granting permanent access could turn troubleshooting into routine observation. A bounded diagnostic session, with attributable authorization and an expiry, makes the choice visible. It also leaves a record of who accepted the additional disclosure and for what purpose.

Test before trust

A credible acceptance test would hold the robot, planner and routes constant while comparing candidate exports in physical environments. The product team would agree utility tolerances before results arrive, including navigation success, path efficiency and relevant clearance measures. Safety requirements would remain independent constraints. A reduction in inference would have little value if it were purchased by quietly accepting unreliable motion.

Inference tests would cover several outcomes separately: room classification, object clues, scene association and task intent. Development environments would support model training and selection; held-out spaces would provide the final comparison. The test adversary would see the complete export available to the recipient, including schema, timing and metadata. Ground-truth labels could support training and scoring, while protected state from test environments would remain unavailable as attack input.

Recipient knowledge changes the challenge. A planner, manufacturer support team and analytics provider may have different histories, account information and external datasets. Each evaluation needs a declared knowledge model, including plausible auxiliary information. A conservative test should also assume the transformation is understood. An obscure message format offers little reassurance once its structure becomes known.

Time may expose what an isolated packet conceals. Repeated destinations could suggest routines; changing free space could indicate moved furniture or changing access. Those possibilities need sequence tests, with retention periods and task combinations matching intended operation. Expiry must reach caches and derived records covered by the policy. Deleting the original message would provide limited protection if its informative features remained indefinitely.

A pass would establish a bounded result against the tested inference methods, not permanent anonymity. Confidence intervals, unsuccessful attacks and utility losses belong in the decision record. If stronger held-out attacks recover the same information, or performance falls outside the agreed tolerance, the proposed transformation has failed its purpose.

What the electronics must make possible

The software boundary becomes credible only if the electronics can sustain it. Local compute needs enough capacity to transform perception before export, with memory and bandwidth that support the workload. Power and thermal limits matter because an architecture that depends on local processing must remain viable during sustained operation. Otherwise a convenient remote fallback could reopen the very information path the design intended to restrict.

Memory protection and access isolation can help separate rich perception state from less trusted software. Protected keys support authenticated, confidential connections; authenticated software and configuration help bind deployed behaviour to reviewed export logic. None of these functions chooses the right representation. They support enforcement of a decision whose privacy consequences still require measurement.

Maintenance tests that enforcement under pressure. When a robot repeatedly stops at the same doorway, a full scene capture may be the quickest diagnostic route. The engineer has a legitimate problem, and the household has a legitimate expectation. Service access needs a defined scope, an accountable operator and a reliable end. Debug interfaces and temporary logging modes deserve the same scrutiny as production telemetry.

Updates create another pressure point. A new export field, altered coordinate system or longer retention period can change disclosure without replacing a single sensor. Version traceability and controlled recovery help identify which behaviour was active. Recovery must also prevent an old, less restrictive export policy from returning unnoticed. Semiconductor selection should support these functions against explicit workload and assurance requirements; a generic security feature list cannot establish that the complete boundary holds.

The decision belongs at architecture review

Rich representations have real value for planning, learning and fault investigation. A household may welcome a service that notices a dangerous obstruction, yet object to the same evidence supporting conclusions about daily life. Greater capability does not settle who should receive the evidence or how long the authority to use it should last.

Commercial incentives complicate the decision. A fleet-learning team may see long retention as an investment in future capability, while the owner experiences it as a growing record of private space. Neither perspective disappears because the data are useful. A defensible product needs a specific benefit, an accountable recipient and limits that remain meaningful when the next service is proposed. Permission to navigate a home cannot carry every future use of the resulting map.

That choice belongs before an interface becomes a dependency across a deployed fleet. Product leaders need a named owner for each export, a measured utility case and an account of what recipients could infer. Engineering teams need the resources to enforce the boundary and revisit it when software, services or observation histories change. The absence of a camera upload is too narrow a release criterion.

The robot returning to its charger may have done nothing wrong. Its sensors worked, its software followed policy and its connection was secure. Yet the room could already exist elsewhere as a set of useful deductions. Trust depends on deciding which deductions the task justifies, and building the machine so that decision survives ordinary operation.