Hotel robot GDPR: cameras, microphones and DPIA

A hotel robot GDPR review should happen before a camera, microphone or cloud dashboard starts processing guest or staff information. The procurement decision is whether the proposed configuration can perform the hotel’s task with a justified and controlled data flow. The GDPR requires a lawful basis for personal-data processing and, where the processing is likely to create high risk, an impact assessment before it begins.[11]

Ask the supplier for a configuration-specific data map, not a brochure declaring the product compliant. A delivery robot that detects obstacles locally, a robot that streams images to a support technician, and a robot that identifies returning guests require different assessments. The examples below are procurement scenarios, not claims about any manufacturer’s product. This analysis reflects evidence checked on 9 October 2026 and is not legal advice.

Map the sensors before the route

Start with the actual machine and software version. Request an inventory covering navigation cameras, depth sensors, microphones, delivery identifiers, diagnostic logs and the hotel-system interfaces the proposed installation will use. For each input, ask what the device collects, what it derives, what it retains and who can receive it. Include temporary buffers and support exports. Do not treat a blank recording dashboard as proof that no processing occurs.

Article 4 defines processing broadly, including collection, use and transmission; it is not limited to permanent recording.[11] The EDPB’s video guidance distinguishes information relating to identifiable people from camera outputs that cannot identify anyone directly or indirectly.[1] Consequently, local processing can reduce exposure without automatically taking a system outside the GDPR.

A proposed obstacle detector might process only geometry. Another configuration might retain identifiable images or associate delivery timestamps with a named guest. Require the supplier to demonstrate which description applies. Assess identifiability in the complete deployment, including other records reasonably available to the hotel or recipient. Replacing a name with a room number does not establish anonymity if the records can still identify the guest.

Illustrative data-map questions for procurement

Proposed function	Evidence to request	Acceptance question
Local navigation	Sensor outputs, buffers and export settings	Can the machine navigate without retaining identifiable images?
Voice interaction	Activation mode, audio destination and transcript policy	Can nearby conversations enter the processing?
Remote recovery	Technician access path, country and session log	Can the hotel authorise and terminate each session?
Delivery history	Identifiers, hotel-system links and deletion controls	Is guest identity necessary for the operational record?
Analytics	Derived attributes, recipients and reuse purposes	Does the proposed use exceed the delivery task?

Give every purpose its own justification

Separate navigation, guest interaction, incident investigation and product improvement. A justification for one purpose does not automatically authorise another. Article 5 requires specified purposes and data minimisation, while Article 6 supplies the conditions for lawful processing.[11] Record the purpose and proposed legal basis against each data flow rather than assigning a single compliance label to the robot.

If the hotel proposes legitimate interests, document the interest, necessity and balancing assessment. The EDPB’s video guidance requires a case-specific assessment and consideration of less intrusive alternatives; a generic statement such as “for your safety” is insufficiently specific.[1] A consent checkbox in the booking process is not a practical substitute for evaluating everyone the robot may encounter.

Greek surveillance rules deserve a separate route review. Article 17 of the HDPA’s Directive 1/2011 limits hotel surveillance to specified areas and excludes, among other places, dining areas, corridors leading to guest rooms and recreation spaces.[8] That directive concerns surveillance systems and predates the GDPR. Its old notification provisions must not be treated as a current general requirement to register every robot.

Do not mechanically classify every navigation camera as a fixed security camera, or assume that mobility avoids surveillance restrictions. Have a qualified adviser assess the actual function, route and applicable Greek rules. As a procurement recommendation, exclude unnecessary surveillance and ambient audio collection from the proposed configuration. The EDPB explicitly recommends deactivating unnecessary video-system functions, including audio recording.[1]

Assign roles by what each party does

The hotel will often determine why personal data is processed in its operations, but the allocation must follow the facts. The EDPB describes controller and processor as functional concepts: contract wording helps, but actual decisions about purposes and essential means matter.[12] Owning the robot, holding the CE documentation or hosting the dashboard does not alone settle the privacy role.

A supplier providing instructed troubleshooting may act as a processor for that operation. If it independently uses identifiable footage for its own training or product research, examine its role for that separate activity. Joint controllership requires an assessment of joint participation in determining purposes and means; it is not the default result of using an external platform.[12]

Where a processor relationship exists, Article 28 requires a binding processing agreement and sufficient guarantees. It also regulates subprocessor authorisation, confidentiality, security, assistance and deletion or return at the end of the service.[11] Request a schedule that names the contracted entity, hosting provider and support chain. Identify an accountable hotel owner for approving access and handling requests.

Keep this assessment distinct from machinery conformity. Ergasa’s CE document audit addresses product evidence; the connected-robot contract analysis covers a related procurement layer. Neither document replaces a privacy assessment of the hotel deployment.

Screen for a DPIA before a live pilot

Article 35 requires a DPIA before processing likely to result in high risk. It expressly includes large-scale systematic monitoring of a publicly accessible area. The assessment must describe the processing, examine necessity and proportionality, assess risks and set out the measures addressing them.[11] A supplier’s generic assessment can inform the work, but it does not describe every hotel’s route, users or integrations.

The Greek authority’s Article 35 list adds important local screening criteria. It covers large-scale monitoring, specified IoT-related processing and systematic employee-location or communications monitoring, with conditions and exceptions stated in the list.[2] Do not reduce this to “two cameras require a DPIA” or “one robot is exempt”. Neither is an established threshold in the sources used here.

Record the number and categories of people affected, data volume, processing duration and geographical reach. Consider children, employee dependence, intimate conversations and possible linkage to booking records. The HDPA list identifies these kinds of scale factors; the conclusion must follow the actual processing rather than the hardware count.[2]

If the documented screening concludes that a DPIA is unnecessary, keep the reasons and review triggers. If one is required, involve the DPO where designated. Article 36 requires prior consultation with the supervisory authority where the DPIA indicates high risk in the absence of measures taken to mitigate it.[11] A live guest-area pilot is not a way to postpone that assessment.

Make minimisation and deletion testable

The EDPB’s Article 25 guidance treats data protection by design and default as a controller obligation regardless of organisational size. It recommends considering protection from the initial planning stages and involving the DPO in procurement where one exists.[5] Convert this into acceptance evidence rather than an aspiration in the contract.

Request a demonstration of disabled ambient recording, restricted diagnostic exports and permissions that survive a reboot. Test what happens when connectivity fails or a technician starts recovery mode. Check whether updates restore broader defaults. These are suggested tests, not assumptions that every robot exposes these controls. Do not disable a necessary safety function without a competent technical assessment.

Set retention separately for images, transcripts, delivery logs and incident evidence. The EDPB says video should generally be erased after a few days and requires more justification for longer periods, especially beyond 72 hours.[1] This is not a universal GDPR retention deadline or permission to keep every robot dataset for that period. Assess any applicable Greek rules and the necessity of each record.

Require proof that deletion reaches the device, dashboards and relevant service copies, with a documented backup policy. For a specific incident, preserve only the justified material under controlled access and a review date. Test the guest-request process using a staged record rather than collecting real guest footage for convenience.

Provide information where people encounter the processing. The EDPB recommends layered video notices, with essential information before entry into the monitored area and accessible detail afterward.[1] For a moving device, assess signs, route entrances and staff explanations together. A small label or QR code alone may leave people unable to understand what is happening.

Trace remote access through the support chain

An EEA server address is not the whole transfer assessment. The EDPB’s Recommendations 01/2020 include remote access by an entity in a third country and require mapping onward transfers.[10] Request the countries and entities involved in hosting, recovery, escalation and analytics. Ask whether support can view identifiable material or only redacted diagnostic data.

Where international transfers occur, identify the applicable Chapter V mechanism. If relying on standard contractual clauses, select the appropriate arrangement and assess the relevant transfer conditions. The Commission’s SCC guidance says Clause 14 should be used with the EDPB’s detailed guidance.[7] Signing an uncompleted attachment does not establish that the actual support path is covered.

The EDPB adopted the final version of Recommendations 01/2020 on 18 June 2021.[6] Its roadmap requires context-specific assessment and, where necessary, effective supplementary measures; if adequate protection cannot be achieved, the transfer must be avoided, suspended or terminated.[10]

Recommend named technician accounts, hotel-approved sessions and an accessible revocation control. Agree how access records and incident details reach the hotel. Under Article 33, processors must notify controllers of personal-data breaches without undue delay; the controller’s supervisory notification has a separate, risk-qualified 72-hour rule.[11] A commercial support SLA should help the hotel meet its obligations rather than consume the available response time.

Budget for the approved configuration

Compare offers only after defining the allowed functions. Request separate prices for local processing, restricted cloud access, log export, retention controls and exit assistance where applicable. Add the hotel’s internal review, staff training, acceptance testing and periodic checks. These are cost categories to obtain from real quotations, not evidence of a fixed compliance price or guaranteed savings.

A worked procurement scenario can compare a locally processed delivery configuration with an optional cloud voice service. Keep the delivery scope constant, then obtain the incremental subscription, integration, review and exit costs of voice processing. Credit labour savings only when measured for that approved workflow. A cheaper offer that depends on an unapproved data flow is not an equivalent alternative.

1. Document the exact sensor, software and integration configuration.
2. Assign a purpose, proposed lawful basis and owner to each personal-data flow.
3. Review guest-area routes and Greek surveillance constraints with a qualified adviser.
4. Complete DPIA screening and any required assessment before personal-data processing.
5. Agree processor responsibilities, subprocessors and international-access conditions.
6. Test minimisation, deletion, notices, access revocation and request handling.
7. Cost the approved configuration and define which changes require reassessment.

The unresolved issue is often technical evidence: whether images remain identifiable, whether audio leaves the device, and what a support account can see. Until the supplier demonstrates those facts, the hotel robot GDPR decision remains open. Recommend holding the affected function, not filling the gap with a compliance assurance.

Hotel robot GDPR acceptance questions

Does switching off recording remove GDPR duties?

No, if identifiable personal data is still collected, used or transmitted. Article 4 covers those operations.[11] Ask for evidence about local buffers, live viewing and diagnostic exports before treating a configuration as outside scope.

Does every robot camera require a DPIA?

There is no universal camera-count rule in the sources reviewed. Apply Article 35’s high-risk test and the Greek authority’s list to the actual deployment.[2] Document the conclusion before the pilot processes personal data.

Can booking consent cover all microphone use?

Do not assume so. Other guests, visitors and employees may be captured, and consent must meet the GDPR’s conditions. The EDPB notes the difficulty of consent for systematic monitoring and the employer-employee power imbalance.[1]

Are all camera images special-category biometric data?

No. The EDPB distinguishes ordinary footage from specific technical processing used for unique identification.[1] Facial identification needs a separate assessment of the Article 9 conditions as well as a lawful basis under Article 6.

What should stop acceptance?

As a procurement recommendation, hold unresolved sensor flows, unexplained remote access or controls that the supplier cannot demonstrate. Obtain the missing evidence and finish the applicable assessment. A signed purchase order does not answer those operational questions or prove that a proposed processing activity is lawful.