Cleaning Robots and GDPR: Cameras, Cloud, and What You Need in Writing

Technically, three things happen in every autonomous cleaning run. The machine builds and keeps a map of your floor plan. It logs where it was, when, and how long it took. And where it has cameras, it perceives its surroundings optically in order to avoid obstacles. None of these functions is designed to observe people — they exist so the robot does not drive into a pallet or over a step. But the data protection officer is not asking about intent. They are asking what is technically captured, where it goes, and who can read it afterwards.

The transport path is the part IT departments most often overlook. Some machines run over the customer's Wi-Fi, which means they are visible on your network and subject to your rules. Others bring their own uplink: the Nexaro NR 1700, for example, connects over a built-in 2G/LTE-M mobile link with global roaming, and the mobile costs are included in the HUB licence. That is convenient — no Wi-Fi onboarding, no VLAN discussion — and it means a device inside your building has a data path outward that never touches your network, and therefore cannot be monitored with your tooling.

The second group of questions comes from the works council. The relevant hook in German law is § 87 (1) no. 6 of the Works Constitution Act, which gives the works council a co-determination right on the "introduction and use of technical devices designed to monitor the behaviour or performance of employees". In practice the discussion turns on whether cleaning logs — area, timestamp, position — allow conclusions about individual staff. In a fifty-person cleaning operation that is unlikely; in a three-person team on one floor it is a genuine question. Whether a given machine falls under that provision is a legal assessment, and we do not make it. We only note that it is asked, and that it is far cheaper to answer before the machine arrives than after.

Where this bites hardest is exactly where autonomous cleaning is most attractive: offices with open-plan floors and staffed desks, and hospitals with patient areas, both of which combine a permanent human presence with a low tolerance for unclear data flows. None of this is a reason not to deploy robots. It is a reason to answer the question once, properly, with documents — after which it stops coming back.

At the camera-free end sits the Nexaro NR 1700, a machine we run ourselves. Its official datasheet of February 2025 lists the sensors as: long-range laser distance sensor (LR-LDS), bumper sensor, eight drop sensors, two magnetic field sensors, a wall-following sensor, incremental sensors, an inertial measurement unit — "and more". No camera appears in that list, and none appears in the FAQ, on the product page or in the sales folder either; navigation is described throughout as laser-based with AI-supported mapping. Here is the honest caveat, applied to our own machine: across those four official documents we did not find a sentence in which Nexaro explicitly writes "without camera", and the datasheet list is expressly open-ended. The claim therefore rests on the published sensor architecture — a laser distance sensor doing the navigating, no imaging device anywhere in the list — and on our own fleet documentation, which records zero cameras for this machine. That is as strong as the published evidence gets in this market, and we would still have it confirmed in writing for a tender. How the machine behaves in a working day is in our NR 1700 field report; what laser navigation can and cannot do is covered in our piece on navigation in cleaning robots.

A step further along sits the Adlatus SR1300, an industrial dry sweeper available through our programme and newly onboarded there — everything here comes from documents. Its official datasheet v3.0 of September 2025 is unusually explicit: Adlatus writes that it is "one of few manufacturers" that does without high-resolution cameras in navigation for data-protection reasons, that 2D and 3D lidar sensors are used instead, that these "record no personal data and also recognise no environmental detail during operation", and that environmental data is recorded "only as coordinates". The comparative part of that sentence — one of few manufacturers — is Adlatus's own claim, and we have no survey of the class that would confirm it. The structural part is the more interesting one anyway: the same datasheet states that operation is "completely self-sufficient" and that no Wi-Fi connection and no continuous internet connection are required, which Adlatus frames explicitly as reducing corporate IT-security risk. Note the machine class, though: this is a hall machine for logistics and production — 485 kg in standard equipment per the current datasheet — not an office device.

At the camera-equipped end are the machines whose vision systems are documented as including cameras. Kemaro's official K900 Gen II factsheet describes the vision system as "a vigilant 2D LiDAR 'crown'" calculating distances across 270 degrees, "and 3D camera fills in the lower blind spots". For the Gausium Phantas, the TASKI OEM datasheet lists the navigation system as "LiDAR's, 3D Depth Cameras, RGB Camera, Anti-drop Sensor, Anti-collision sensor", and the operating manual details two RGB cameras alongside the depth camera. A Gausium company post of February 2026 citing CTO Dr. Baoxing Qin describes the company's sensor suite as including "360-degree 3D LiDAR and 360-degree camera arrays". We operate neither manufacturer; both are covered in our market overviews of the Gausium Phantas and the Kemaro K900.

One thing that should not get lost in this spectrum: a camera on a cleaning robot is not a surveillance camera. None of the manufacturers discussed here advertises a recording function, and the cameras exist to keep the machine from running into things. The question a data protection officer actually needs answered is narrower and harder: are images stored, are they processed exclusively on the device and discarded, and do they ever leave the machine — including in the error case, for remote diagnostics, or as training data.

Nexaro is the most concrete of the four. The official FAQ states: "Our software is AWS-based and our servers are located in Europe", adds that "we back up your data exclusively on servers located in Europe", and says the solution is "fully GDPR-compliant". The sales folder of March 2025 puts it in German as: all customer data is stored separately and exclusively on European servers, and external partners and service providers are held to the same GDPR-compliant standards. More useful than any of those sentences, though, is the artefact behind them: Nexaro publishes a data processing agreement for the Nexaro HUB — "Agreement on Commissioned Data Processing in the context of the provision of the Nexaro HUB" — which references Art. 28(3) GDPR, names the categories of data processed, and lists six approved sub-processors by company name, including Vorwerk Elektrowerke, intive and LetMeRepair. That is a document a data protection officer can actually work with before a single sales call. Precision matters here too: that agreement itself refers to data centres generically rather than pinning geography, so the European-servers statement lives on the FAQ, the product page and the sales folder, not in the contract text we read.

Kemaro states on its own homepage, verbatim: "Compliant with European and Swiss privacy regulations – servers located in Switzerland", alongside the positioning line "Minimized sensors: Strengthening privacy and security". Read that carefully. It is a manufacturer statement on a marketing page, not an audit report, not a certificate, and not a contract clause — and "minimized sensors" is a positioning claim, not a specification. It is also worth knowing what the cloud carries: the official Gen II factsheet describes the "Web App & Cloud Sphere" as providing remote maintenance, automated remote software updates, "digital cleaning reports with interactive maps" and "status, errors and robot position". So the map of your building and the position of the machine leave the building by design. Whether a Swiss server location is unproblematic for your case is a question for your counsel; we only record what Kemaro says and what it does not.

Gausium is the case where several sources need reading side by side, and they do not all point the same way. The company's privacy policy states that "the personal information we collect will be stored on Amazon Cloud servers in your country or region" and that users can choose the cloud server area based on their location — and that policy does not itself reference the GDPR. Separately, a Gausium company post of February 2026 citing CTO Dr. Baoxing Qin states that "Gausium is fully GDPR-compliant, collecting training data exclusively from the China market, validating models there, and then deploying validated software upgrades to overseas fleets without collecting any customer data from international markets". Pulling the other way is a source that is not Gausium's: the Dutch Clingendael Institute reported in its Spectator publication that data from Gausium robots is stored in Singapore, and questioned whether that data enjoys GDPR protection. We cannot settle that from published material — a think-tank assessment and a manufacturer statement are different kinds of evidence, and none of the three documents is a contract. The important consequence is structural: if the storage region is a configurable setting, then the answer for your fleet is not a product property at all. It is a configuration and a contract clause, and it belongs in the data processing agreement with the region named. In a public-sector tender, that is the clause the decision hangs on. For the machine level, the TASKI OEM datasheet for the Phantas is the clearest description we found anywhere: data storage is "Both, mostly on-device. Key data, such as cleaning performance and map coverage, is sent to the cloud."

Adlatus is the structural outlier, and it is worth stating plainly why: if the machine needs no continuous internet connection, most of the questionnaire collapses, because data that never leaves cannot be stored in the wrong region. The trade-off is equally plain and rarely mentioned in the same breath — a machine that is offline by design is also a machine without remote diagnostics, without over-the-air fixes and without a fleet dashboard. That is a genuine operational cost, not a free win.

Start with the sensors, and insist on a complete list rather than a phrase. "Intelligent sensor technology" is not an answer; "long-range laser distance sensor, bumper, eight drop sensors, two magnetic field sensors" is. Then the three questions about images that follow from it: are camera images stored at all, are they processed exclusively on the device and then discarded, and do images ever leave the machine — including in the error case, for remote diagnostics, or as training data for the manufacturer's models. That last one is the question most often forgotten and the one most likely to matter, because a diagnostic upload triggered by an exception is a data flow that no normal-operation description covers.

Then the transport path and the storage location. Over which channel does telemetry travel — your Wi-Fi or a SIM card in the machine? Which data types exactly: maps, cleaning logs, position data, error images? In which geographical region are they stored, and is that region fixed by contract or a configuration setting that can be changed later? Is there a data processing agreement under Art. 28 GDPR, and does it come with a complete, named list of sub-processors rather than a general reservation? A vendor who can hand you all of this without a follow-up call has thought about it before you asked, which is itself a useful signal.

Finally, access and deletion. Who can see the maps and the cleaning logs — including at the manufacturer, in the course of remote maintenance — and how is that access logged? What retention periods apply, and what happens to maps and logs when the contract ends? And the question the works council will ask: can performance or behavioural data about individual employees be derived from the cleaning logs, for instance because a given area is assigned to a given person? If you are still deciding which machine class you are even buying, our guide to which cleaning robot fits which operation covers that step, and our service model describes how we handle the operator side of it.

Our working principle is minimal data: we ask for the least data that still lets us run the machine reliably, and we pick the machine to fit the room rather than arguing the room into fitting the machine. That second half is the part most vendors skip, and it is often the shortest path through the whole discussion. On a sensitive office floor, a camera-free vacuum ends the conversation at the sensor list — there is no image question to answer if there is no image. The NR 1700 is the machine we reach for when that is the requirement, which is why it sits in offices and public-sector buildings in our fleet rather than in warehouses. Machine choice can be the compliance answer, and it is usually cheaper than a legal one.

Which brings the honest part. Our fleet is not camera-free, and we would rather say that ourselves than have you find it in a datasheet. The short navigation labels on our own fleet pages — "Visual + Laser SLAM" for the Pudu CC1, "LiDAR + Vision" for the MT1, the MT1 Vac and the CenoBots L50, "3D LiDAR + Vision" for the MT1 Max — are our summary rows, not manufacturer sensor lists, and the manufacturer documents behind them are more specific. The official CC1 brochure lists two RGBD cameras and a top-view camera alongside two lidars; the MT1 component diagram a VSLAM camera plus three RGBD sensors and an RGB sensor; the MT1 Max deck a VSLAM camera, three RGBD and two RGB cameras next to its 3D lidar; the MT1 Vac page names LiDAR SLAM and VSLAM. The CenoBots L3 is documented with a 96-beam 3D lidar and one depth camera, the L4 with a 32-beam 3D lidar and a 3D depth camera, the L50 with a 3D depth camera plus front and side RGB cameras. The SoftBank Whiz belongs on this list too: its official datasheet labels a "2D/3D Camera" and a "LIDAR Sensor" on the machine diagram, and describes safety sensors that "detect and maneuver around people, objects, and cliffs". And the Pudu SH1 does not navigate at all: it is walk-behind, always with an operator. So camera-freedom is a property of one machine we run, not a property of our fleet, and anyone selling it to you as a fleet-wide virtue is overselling.

The same applies to the other machines in this article: the Adlatus SR1300, the Kemaro K900 Gen II and the Gausium machines. Everything we have written about them here comes from their own documentation, read by us at source. If one of them turns out to be the right machine for your building, the answer is not to take our word for it — it is to put the same list of questions from the previous section to that manufacturer.

One distinction runs through this entire article, and it is worth naming explicitly. "GDPR-compliant" on a website is a self-declaration. That is not worthless — it has an identifiable author and it carries legal weight if it turns out to be false. But it is not an audit report, not a certificate, and not a contractual commitment. Think of it as three levels: a marketing statement on a website, a contractual commitment in a data processing agreement, and a verified proof such as a certification or an audit report. Nothing in this article reaches the third level for any of the four manufacturers. Of the four, Nexaro is the only one for which we found a publicly readable Art. 28 data processing agreement. That does not mean the others have none — it means you will have to ask for theirs, and that the asking is on you.

The legal part, plainly: we operate machines, we do not assess law. Whether your deployment requires a data protection impact assessment, whether the works council has to co-determine, whether a specific data transfer is lawful in your configuration — all of that belongs with your data protection officer and your counsel, who know your organisation and the case law. What we owe you is different and narrower: an accurate sensor list, an accurate description of the data flow, and the manufacturer's own words with the source attached so you can check them yourself. Everything above is exactly that, verified at source in August 2026.

And one piece of pushback, because it is the most common mistake in this discussion: camera-free is not automatically privacy-friendly. A camera-free machine that ships maps and timestamps to a cloud in an unspecified region can be harder to justify than a camera-equipped machine that processes everything on the device and sends nothing but an aggregate. The camera is the most visible question, not the only one, and certainly not the decisive one. Decide on the data flow, not on the sensor that is easiest to picture.