GDPR and Event Emotion Analytics: A Compliance Guide

The GDPR Challenge for Event Analytics

GDPR classifies face images as biometric data and biometric data as a special category requiring explicit consent under Article 9. For most event analytics approaches — those that store or transmit face images — this creates a significant operational burden: consent forms, opt-out mechanisms, data subject rights processes, and retention limitation controls that consume staff resource and create visitor friction.

The result is that many event teams have concluded that visitor analytics is too legally complex to deploy at scale. EchoDepth Events was designed to resolve this problem — not by finding a policy workaround, but by ensuring that no biometric data is created in the first place.

Why Architecture Matters More Than Policy

The most common approach to GDPR compliance in technology systems is to deploy the system, collect the data, and then implement a privacy policy, consent mechanism, and data retention limit to manage the compliance obligations created by the collection.

EchoDepth Events inverts this approach. The architecture is designed so that biometric data is never created. Video frames are processed on an edge device at the venue. AU signal data is extracted from the frame. The frame is then discarded — immediately and irrecoverably. Only derived, aggregated, non-biometric scores leave the edge device.

The consequence is that there is no biometric data to consent to, retain, or delete. The compliance overhead does not exist because the data that would create it does not exist.

GDPR Article 25 — Privacy by Design

Article 25 of GDPR requires that data controllers implement appropriate technical measures to ensure data protection principles are integrated into processing from the design stage. Specifically, Article 25(1) requires that controllers implement technical and organisational measures designed to implement data-protection principles — such as data minimisation — effectively.

EchoDepth Events' edge processing architecture is a direct implementation of Article 25. Data minimisation is not a policy constraint applied to a system that collects more data than necessary — it is embedded in the technical design. The system is incapable of retaining more data than its analytics purpose requires, because the mechanism for doing so (frame storage and transmission) is absent from the architecture.

Article 9 — Special Category Data

GDPR Article 9 covers the processing of special categories of personal data — including biometric data processed for the purpose of uniquely identifying a natural person. Article 9 processing requires one of a limited set of legal bases, of which explicit consent is the most commonly used in commercial contexts. EchoDepth Events does not process biometric data for the purpose of uniquely identifying a natural person. It processes facial movement data to extract aggregate emotional signal scores. The output — a Net Confidence score for a defined zone over a defined time window — cannot identify any individual. It is functionally equivalent to aggregate audience sentiment data. Because EchoDepth Events does not process biometric data for identification purposes, Article 9 does not apply. The system operates under Article 6(1)(f) Legitimate Interests — a substantially lighter compliance framework.

The EU AI Act

The EU AI Act, which began applying from August 2026, classifies real-time remote biometric identification systems as prohibited or high-risk AI. EchoDepth Events is not a biometric identification system. It does not identify individuals. It analyses muscle movement patterns to produce aggregate emotional signal data.

This classification distinction is material: prohibited and high-risk AI systems face registration requirements, conformity assessments, and significant operational constraints. Systems that do not fall within these categories face standard transparency and robustness obligations that EchoDepth Events satisfies through its documentation and architecture.

Article 50(3) — The Emotion Recognition Transparency Duty

Article 50(3) of the EU AI Act places a duty directly on the deployer of an emotion recognition system, not on the vendor that supplied it, and it is the provision most likely to apply to an event using this technology in the EU. It requires that people exposed to such a system are informed of its operation, and it applies regardless of whether the system processes biometric data or identifies anybody — so satisfying GDPR is not the same as satisfying the AI Act. Two further points follow. The obligation sits with the organiser or exhibitor who deploys the system at their event. And in workplace and educational settings the AI Act goes further than transparency, prohibiting emotion recognition outright, which is a live consideration for internal conferences, staff events and training environments rather than for commercial exhibitions.

In practice, meeting Article 50(3) at an event means clear signage at the entrance to any measured zone, a line in the event or venue privacy notice describing what is measured, and a record of when and where the system was deployed. These are the same steps that constitute good practice under GDPR, which is why deployments that are already documented for Article 25 purposes rarely need substantial additional work.

Which Rules Apply to Which Kind of System

What the system does	GDPR status	Consent	AI Act
Counts people and measures dwell time; no facial analysis	Not personal data	Not required	Outside emotion recognition scope
Reads facial movement for aggregate emotion; frames discarded, no identification	Not biometric data under Article 4(14); Article 6(1)(f) applies	Not required for the processing; opt-in taken as good practice	Article 50(3) transparency duty applies
Matches faces to identify or re-identify individuals	Special category data, Article 9	Explicit consent required	High-risk or prohibited depending on context
Any of the above in a workplace or educational setting	As above	As above	Emotion recognition prohibited

EchoDepth Events Standard tier sits in the first row and Deep tier in the second. Neither tier performs the processing described in the third row, because the architecture cannot produce the data that row depends on.

Do You Need a DPIA?

A Data Protection Impact Assessment is required under Article 35 where processing is likely to result in a high risk to individuals, which typically means systematic monitoring of a publicly accessible area on a large scale, or processing of special category data. A deployment that produces only aggregate, non-biometric zone scores generally does not meet that threshold. Many organisations nonetheless choose to complete one, either because internal governance requires it for any camera-based system or because it is the quickest way to satisfy a venue, a client or an internal review. EchoDepth Events provides a DPIA template alongside the Legitimate Interests Assessment and Data Processing Agreement as part of the deployment package, so the assessment can be completed from documentation rather than assembled from scratch.

Practical Compliance Steps for Deploying Organisations

For event organisers and exhibitors deploying EchoDepth Events, the practical compliance steps are straightforward:

1. Update venue privacy notice: Add a single sentence referencing the use of anonymised emotional engagement analytics in defined zones. Template language provided by Cavefish.
2. Ensure zone signage is visible: Standard event signage indicating the analytics zones is sufficient. No consent collection mechanism required.
3. Complete Legitimate Interests Assessment: For regulated industries (financial services, healthcare, public sector), a completed LIA documenting the lawful basis for processing is recommended. Cavefish provides a pre-completed LIA template for adaptation.
4. Confirm data processing agreement: A standard DPA is available from Cavefish for clients who require one as part of their vendor due diligence process.

Documentation Available to Deploying Organisations

EchoDepth Events clients have access to the following GDPR compliance documentation as part of the deployment package: Legitimate Interests Assessment template, Data Processing Agreement template, DPIA template (for organisations that require a formal Data Protection Impact Assessment), venue privacy notice amendment text, technical architecture summary for DPO review, and EU AI Act system classification summary.