Why this question is the wrong one to ask Ariadne
If you have shopped for a camera-based people counter, you have probably been asked to pick between two privacy postures. In-camera blur, sometimes labelled edge blur in vendor data sheets, runs the face or person detector inside the camera unit and obscures the detected region before any frame is transmitted. Cloud blur sends the raw frame to a server, blurs it there, and discards the original after processing. Both are reasonable engineering choices, both start from a captured video frame, and both exist to answer the same question: when and where do you obscure that frame.
This article assumes you are asking the question because a vendor put it in front of you. We will explain both techniques honestly so you can read a vendor data sheet without being misled, but the headline answer for how Ariadne measures is that the question does not apply. The Ariadne sensor never captures a video frame in the first place, so there is no frame to obscure inside the unit and no frame to obscure in the cloud. The rest of the article describes the two camera-side techniques, then walks the camera-free measurement method Ariadne actually uses.
In-camera blur, briefly
In an in-camera architecture, the privacy step lives inside the camera unit or inside a small compute box wired directly to it. The camera captures a raw frame, a face or person detector runs against that frame, and a blur, pixelation, or silhouette mask is applied to the detected regions. Only the obscured frame, or in stricter implementations only the counts and bounding boxes derived from it, leaves the unit. Vendors usually pick this pattern because network traffic drops, latency drops, and the compliance posture is easier to explain to a board.
The pattern has three assumptions that an evaluator should test:
- The detector has to fire. Modern detectors are good in good light. They drift in low light, with masks, with motion blur, with unusual head angles, and against backlit doorways. When the detector misses, the frame leaves the unit with a recognisable face in it.
- The hardware has to be capable. Running a person detector at thirty frames per second per camera needs real silicon. Cheap installations cut corners, run the detector at a lower frame rate or a lower resolution, and the gap between detection and reality widens.
- The blur has to be irreversible. Research on de-blurring and super-resolution has shown that some blur and pixelation methods leak enough structure that a face can be partially reconstructed. Strong obscuration is achievable, but it is a research-grade design choice, not a checkbox in a camera firmware.
The deeper issue is conceptual. Even when every part of the pipeline works as advertised, a personal data event has still taken place inside the camera. The raw frame existed for a moment in memory, with a recognisable person in it, before the privacy step ran. Supervisory authorities sometimes accept that momentary processing as low risk when the unobscured frame is never written to disk or transmitted. Others are less comfortable with it. In-camera blur is therefore safer than cloud blur, but it is not a clean answer to the question of whether personal data is processed at all.
Cloud blur, briefly
In a cloud-side architecture, the camera transmits the raw frame to a server, and the blurring runs there. The server stores only the obscured version, or the derived counts, and deletes the raw frame after processing. This pattern is common when the camera is a generic IP camera with no compute on board, when several cameras share a single inference server in a back-of-house rack, or when the counting model is bolted onto an existing video management system. Models can be updated centrally, several cameras can share one expensive GPU, and the architecture maps cleanly onto a video stack operations already trusts.
The trade-offs are mostly privacy ones:
- Data in flight is identifiable. Between the camera and the server, the stream contains identifiable images of real people. TLS protects that stream from outside interception, but every node on the route is, in principle, a processor of personal data. Some Data Protection Officers are uncomfortable with that, particularly when the route crosses jurisdictions.
- Storage of the raw frame, even briefly, is a personal data event. The server has to receive the frame, decode it, run inference, write the obscured version, and delete the original. Each step touches a personal data record. The window is short, but it exists, and an audit will ask about it.
- Regulator framing is harsher than the diagram suggests. Supervisory authorities and EDPB guidance treat the transit of identifiable images as processing, not as a non-event. A system that ships raw frames to a cloud, blurs them, and discards the original is processing personal data, even if the storage is measured in seconds.
- Sub-processor chains lengthen the assessment. If the server is hosted on a third-party cloud, the controller has to map sub-processors and (post Schrems II) work through transfer impact assessments for any non-EU hop. The shorter the diagram, the easier the assessment.
What the two camera pipelines have in common
It is tempting to read in-camera blur as the privacy-safe choice and cloud blur as the lazy one. That framing misses the point. Both pipelines exist to fix the same underlying property: a camera captures a video frame of a real person. That frame is, by default, personal data, and from a regulator's point of view it is biometric-adjacent the moment a face is recognisable in it. Where the blur runs is a secondary question. The primary question is whether the frame existed at all.
If a measurement system can be built without capturing the frame in the first place, the entire comparison becomes academic. There is no detector to drift, because there is no detector. The de-blurring research does not apply, because nothing was blurred. The transit of identifiable images does not happen, because no identifiable image existed. The sub-processor chain shortens, because there is no video frame anywhere on the route. That is the category Ariadne sits in, and it is worth describing how the measurement actually works rather than positioning it inside the comparison.
How Ariadne measures, in line with how it works
Ariadne measures this with Hybrid Fusion, its patented camera-free method. Time-of-Flight depth sensing counts every visitor at the entrances, capturing geometry rather than images, while patented phone signal sensing follows movement through the interior, detecting the signals a phone emits even in airplane mode. The sensor streams both feeds to Ariadne, where Hybrid Fusion combines them into one trajectory per visit and computes counts, dwell, and paths. The streams carry no identifier: no MAC address, no device ID, no biometric data, and no camera is involved. Identifiers are stored only when a visitor explicitly opts in, which keeps the method GDPR-friendly and outside biometric territory.
Two parts of that description carry the privacy argument. Time-of-Flight depth sensing fires infrared pulses and measures return distance, which gives the geometry of whatever passes below the sensor to roughly thirty centimetres. There is no image, no pixel grid that could be reassembled into a face, and no face detector that has to fire correctly. Patented phone signal sensing detects the radio signals a phone emits and triangulates position, with no MAC address captured by default. There is no recognised individual at any point in the measurement.
The fusion of those two feeds runs centrally in the Ariadne platform, not in the sensor unit. The sensor streams geometry and signal patterns, the platform reconciles them into one trajectory per visit, and the operator sees counts, dwell, and paths. No video frame ever exists in this architecture. That is the structural point: Ariadne is not running a quieter version of in-camera blur, and it is not running cloud blur with extra steps. The artefact that both camera pipelines are designed to manage is simply not produced.
This matters for how the system is described to a Data Protection Officer or a supervisory authority. It is not accurate to call Ariadne's posture anonymisation, because there is no identifying signal to anonymise. The correct description is that no personal data is captured at the sensor, no personal data is processed in transit, and identifiers are stored only when a visitor explicitly opts in, for example by logging into guest Wi-Fi. The privacy policy sets out the same in the controller's voice.
Where the camera pipelines still make sense
In-camera blur is a reasonable choice when the use case genuinely needs vision. A safety system that has to recognise a fall, or detect a fire by sight, needs an image to work from. The privacy step then lives inside the camera or alongside it, the design choice is whether to ship the obscured frame on or keep only the alert, and the rest of the engineering follows. Treating that pattern as a privacy posture for people counting, though, mixes two different requirements. Counting people does not need vision. Counting people needs a count.
Cloud blur is, in fairness, the right pattern when there is already a video management system that has to receive the frame for other reasons, and the counting workload is being added to an existing pipeline. The architecture is then explainable, and the privacy posture is the best one available within the constraint. The conversation with a DPO becomes about minimising retention and tightening processor agreements, rather than about removing the personal data event entirely.
When the only requirement is to know how many people are inside a space and how long they stay, neither pipeline is the cleanest answer. A method built around Time-of-Flight depth at the entries and patented signal sensing inside returns the same numbers without producing the artefact those pipelines exist to manage.
A short checklist for a vendor conversation
If you are evaluating a people-counting system and the vendor's privacy posture is described as in-camera blur or cloud blur, these are the questions worth asking before a trial.
- Where does the raw frame live, and for how long? The honest answer is: somewhere, even in an in-camera pipeline. Ask whether it is ever written to non-volatile storage, who can read the memory it lives in, and how the system behaves if the privacy step fails.
- What happens when the detector misses? Ask for the failure mode in low light, with masks, with backlit doorways. If the answer is that the unobscured frame is transmitted, that is a meaningful risk.
- Is the blur reversible? Modern de-blurring is good enough that simple pixelation is not a credible privacy method. Ask which method is used and what the published reversal risk is.
- Does the system need vision at all? For counts, occupancy, and dwell, a camera is a means, not an end. A camera-free measurement method returns the same numbers without the privacy event in the first place. Ask the vendor to explain why a camera is necessary for the use case in front of you.
- Where does processing physically happen? For any cloud-side step, ask about EU data residency, sub-processors, and transfer impact assessments. The shorter the diagram, the easier the assessment.
If the answer to question four is that vision is not strictly required, a camera-free method is worth a comparison trial. The same questions about residency and sub-processors still apply to the analytics platform, but the upstream personal data event is gone.
Related reading
The companion post on biometric vs non-biometric counting walks the regulatory line in more detail and lists the seven yes-or-no questions that classify any counter under the EU AI Act and GDPR Article 4(14). For the full architecture diagram and the patents that sit behind it, see how Ariadne works.
FAQ
Does Ariadne sit on the in-camera blur side or the cloud blur side?
Neither. The comparison only applies to systems that start from a captured video frame. Ariadne does not capture a video frame, so there is no frame to obscure inside the unit and no frame to obscure in the cloud. The measurement uses Time-of-Flight depth at the entries (geometry, not images) and patented phone signal sensing in the interior (radio, not images), and the fusion runs centrally in the Ariadne platform.
Is in-camera blur enough to make a deployment GDPR-safe?
It can be made compliant, but it is not the same as having no personal data in the system. The raw frame is processed, briefly, inside the camera unit, before the privacy step runs. Supervisory authorities generally accept that pattern as low risk when the unobscured frame is never written to disk or transmitted, but the assessment still has to cover detector failure modes and reversibility of the blur. A measurement method with no camera in the pipeline avoids the assessment entirely, because there is no personal data event to assess.
Does the system use cameras?
No. Ariadne counts with Hybrid Fusion: Time-of-Flight depth sensing plus patented phone signal sensing, never cameras. Time-of-Flight captures geometry rather than images, and signal sensing captures no MAC address by default, so the measurement involves no video, no faces, and no biometric data.
If there is no camera, how does the count work?
Ariadne combines two camera-free sensing methods in one hardware unit. Time-of-Flight depth sensing at the entries fires infrared pulses and measures return distance, which counts every visitor crossing the threshold and captures geometry rather than images. Patented phone signal sensing inside detects the radio signals a phone emits and triangulates position, with no MAC address captured by default. The sensor streams both feeds to the Ariadne platform, where Hybrid Fusion combines them into one trajectory per visit and computes counts, dwell, and paths. The full architecture diagram lives on how it works.
