A robot with cameras, microphones, LiDAR, or facial recognition can collect information about people who never agreed to be recorded. Before deployment, the hard work is deciding what the robot may collect, where it may operate, and who can view the records.
Quick read
- A public place doesn’t remove privacy duties.
- Facial images, voices, and location trails can identify people.
- A written purpose, short retention period, and human review reduce legal risk.
What the robot collects
The first legal question concerns the sensor, not the robot’s shape. A camera may record faces, clothing, license plates, or activity. A microphone may store voices. LiDAR can map rooms and movement, even when it cannot identify a face.
That information can become personal data when it relates to an identifiable person. A location trail may identify someone without a name attached. The same applies to a face image, voice recording, employee badge, or repeated path through a building.
The operator needs a clear purpose before the robot starts work. “Improve security” is too broad for a useful review. A purpose such as checking a restricted doorway during staffed hours gives the team something it can test against each sensor and recording.
Where the robot operates
The setting changes the legal questions. A robot inside a warehouse raises different questions from one in a hospital, school, apartment block, or public street. People may expect cameras near a guarded entrance. They may have a different expectation inside a changing area, patient room, classroom, or private home.
The owner also needs to check who controls the site. A security company may run the robot, while a landlord, hospital, or city controls the building. Contracts should state who decides the purpose, who handles requests from recorded people, and who reports a data loss.
Public access creates another problem. A sign can tell people that recording is taking place, but a sign alone may not answer every legal question. The notice should name the operator, explain the purpose in plain words, and state how a person can ask about their information.
A deployed surveillance robot raises questions about notice, purpose, and access. Robot24.com robotics coverage can place those questions beside named machines and operators before the next issue: who can see the records?
Who can see the records
Access controls matter because surveillance data can travel far beyond the robot. A guard may need a live view. A technician may need system logs. A vendor may need limited access to fix a sensor.
Those jobs don’t require the same information. Separate live video from stored footage where the system allows it. Give each person the smallest access needed for their job, record access events, and remove accounts when a contract ends. Keep a written list of vendors that receive the data.
Facial recognition needs a separate review. It turns an image into a search tool that can link a person to other records. That can raise stricter legal duties, especially in workplaces, schools, housing, and public areas. A system that only detects a person may create fewer problems than one that names them, but the operator still needs to explain the collection and storage.
How long the data stays
Storage time should match the stated purpose. If a robot checks whether a door was opened, the system may need an alert and a short video segment. It may not need a permanent record of everyone who passed the door.
Long storage increases the harm from a stolen account, faulty access rule, or mistaken identification. Automatic deletion helps, but the schedule must cover backups, exported clips, logs, and copies held by vendors. A deletion rule that covers only the robot’s main database leaves the wider system untouched.
People also need a way to challenge an incorrect record. A human should review cases where the system flags a person, blocks entry, changes a work record, or sends a report to security. The operator should keep the reason for the decision and the source footage long enough to check it, then delete it under the stated rule.
A deployment check before purchase
Use this list during a design review or supplier meeting:
- Name the purpose: write the exact task and remove sensors that don’t help with it.
- Map the people: list workers, visitors, residents, patients, students, and passersby who may be recorded.
- Set access levels: match each job to the live feeds, clips, alerts, and logs it needs.
- Set deletion dates: include backups, exports, system logs, and vendor copies.
- Test human review: decide who checks a false alert and how the person can ask for a correction.
- Check the contract: assign responsibility for notices, requests, security incidents, and system changes.
I’d postpone deployment when the operator can’t name the purpose, retention period, and person responsible for review. A robot that records first and asks legal questions later creates a record the company may not be able to defend.
The next decision should happen before the robot reaches the site: approve each sensor, storage rule, access role, and review process in writing. If any one of those remains vague, the system isn’t ready for people.
