EU AI Act Facial Recognition: CCTV Archive Rules [2026]
The EU AI Act became generally applicable on August 2, 2026 — and the rules governing retrospective facial recognition on stored footage are the part almost nobody has read. Because the Digital Omnibus pushed high-risk deployer duties to December 2027, there is now a window in which archived CCTV can be mined biometrically before the AI Act's targeted-search safeguards bite. This guide explains Article 26(10), why unredacted archives are the real exposure, and how redaction-at-rest closes it.
Most of the coverage of the EU AI Act's August 2026 milestone has been about chatbots and deepfake labels. The part almost nobody has written about is the one that touches anybody operating a camera: retrospective facial recognition. It runs on recorded video, not live feeds — which means the compliance risk is not sitting in your lens, it is sitting in your archive.
If your organisation keeps months of unredacted CCTV, event footage, transport recordings, or campus security video, you are holding a searchable index of everyone who walked past. You did not build it deliberately. It exists as a by-product of a retention setting nobody has revisited since the cameras were installed. And under the AI Act's framework for post-remote biometric identification, that archive is exactly the kind of material a targeted biometric search is designed to consume.
This guide covers what actually changed on August 2, 2026 (and what quietly did not), what Article 26(10) requires of anyone running retrospective facial recognition, why the deferral of high-risk obligations to December 2027 creates a window rather than a reprieve, and the practical fix: redaction at rest — blurring faces and plates before footage goes into long-term storage, so the archive you keep cannot be mined for identities you never had a lawful basis to hold.
Did the EU AI Act's Facial Recognition Rules Actually Start on August 2, 2026?
Partly — and the split matters more than the headline. The European Commission's own summary of the regulatory framework for AI states the Act "entered into force on 1 August 2024 and became applicable on 2 August 2026, with some exceptions." Those exceptions are large. The same page confirms that prohibited practices have applied since 2 February 2025, governance and general-purpose AI rules since 2 August 2025, high-risk systems in sensitive areas from 2 December 2027, and high-risk systems in regulated products from 2 August 2028.
Those last two dates moved. The Digital Omnibus on AI entered into force on 27 July 2026, three days after publication in the Official Journal, extending the timelines for high-risk AI obligations while leaving the August 2, 2026 transparency duties on their original schedule. So on the date the Act "became applicable," the obligations that actually switched on were transparency-facing — the Article 50 disclosure duties we cover in our Article 50 deepfake disclosure compliance guide and in the companion deepfake labelling rules for creators and platforms.
Here is the resulting picture for anything biometric:
| Rule | Status as of August 2026 |
|---|---|
| Ban on untargeted scraping of faces from the internet or CCTV (Art. 5(1)(e)) | In force since 2 February 2025 |
| Ban on real-time remote biometric ID in public for law enforcement (Art. 5(1)(h)) | In force since 2 February 2025, narrow exceptions |
| Article 50 transparency and AI-content disclosure | Applies from 2 August 2026 |
| High-risk duties for Annex III systems, incl. remote biometric ID (Art. 26 deployer obligations) | Deferred to 2 December 2027 |
| High-risk AI in regulated products (Annex I) | Deferred to 2 August 2028 |
Read that table again with an archive in mind. The bans on bulk scraping and on live identification are already law. The structured safeguards on retrospective identification of stored footage arrive last.
What Is Retrospective (Post) Remote Biometric Identification?
Retrospective — or "post" — remote biometric identification is facial recognition applied to previously recorded material instead of a live camera feed. An investigator takes video or images that already exist and searches them against a biometric reference set. The output reconstructs a person's presence at a location, their participation in an event, or their movement through public space, assembled after the fact from footage that was recorded for a completely different reason.
The distinction from real-time identification is one of timing, not capability. The Future of Privacy Forum's analysis of the red lines around real-time remote biometric identification notes that the same device is often capable of both real-time and post-identification functions, and that "real-time" under Recital 17 means processing instantaneously, near-instantaneously, or without significant delay — a fact-based test that cannot be dodged by inserting an artificial pause. Push the delay out far enough and you are no longer in the Article 5 prohibition; you are in the high-risk regime.
That is the structural point operators keep missing. Retrospective identification requires no new hardware and no cooperation from you. It requires footage that still exists. A five-year-old camera writing to a NAS in a back office produces exactly the input a modern biometric search needs, and the longer your retention window, the deeper into the past that search can reach.
What Safeguards Does Article 26(10) Put on Retrospective Facial Recognition?
Article 26(10) of the AI Act sets the conditions for deployers of high-risk post-remote biometric identification systems used in criminal investigations. Per the text of Article 26 on deployer obligations, where such a system is used for the targeted search of a person suspected or convicted of a criminal offence, the deployer must request authorisation "ex ante, or without undue delay and no later than 48 hours" from a judicial authority, or an administrative authority whose decision is binding and subject to judicial review.
The rest of the paragraph builds a fairly tight cage:
- Strict necessity. Each use must be limited to what is strictly necessary for the investigation of a specific criminal offence.
- Rejection means stop and delete. If authorisation is refused, use ceases and the associated personal data is deleted.
- No untargeted use, ever. The system may not be used for law enforcement purposes in an untargeted way, without a link to a criminal offence, criminal proceeding, a genuine present or foreseeable threat, or the search for a specific missing person.
- No sole-basis adverse decisions. No decision producing an adverse legal effect on a person may be taken based solely on the system's output.
- Documented use. Each use must be documented in the relevant police file and made available to the market surveillance authority and the national data protection authority on request.
There is one carve-out worth knowing: the authorisation requirement does not apply where the system is used for the initial identification of a potential suspect based on objective and verifiable facts directly linked to the offence.
Compare that with the live case. Article 5(1)(h) flatly prohibits real-time remote biometric identification in publicly accessible spaces for law enforcement, permitting it only for targeted searches for trafficking or abduction victims and missing persons, prevention of a specific imminent threat to life or a terrorist attack, and locating suspects in serious criminal offences. Even then, a fundamental rights impact assessment under Article 27, prior authorisation, and registration in the EU database under Article 49 are required.
✅ Why the deferral is a window, not a reprieve
Article 26 is a deployer obligation for high-risk systems, and remote biometric identification is an Annex III category — so its safeguards ride the deferred December 2, 2027 timetable rather than the August 2026 date. That does not make retrospective searching of your archive impossible in the meantime; national law, the Law Enforcement Directive, and existing procedural rules still govern access. What it does mean is that the AI Act's specific, uniform guardrails on retrospective identification are the last piece to arrive. Footage you retain today will still be there when they do.
Why Does an Unredacted Archive Make My Organisation a Target?
Because retrospective identification is only as powerful as the footage available to feed it, and most organisations are storing far more than they realise. The exposure is not hypothetical or exotic. It comes in three concrete forms.
You become a lawful-access destination. A targeted search for a suspect's movements does not begin with police cameras; it begins with a list of every private camera near the relevant place and time. Retailers, transport operators, stadiums, universities, and property managers are the first call. The more months of identifiable video you hold, the more often you are that call, and the more staff time, legal review, and disclosure risk each request carries.
You are a breach with biometric consequences. An archive of clear faces is not just video — it is a corpus from which face templates can be derived. A stolen CCTV archive is materially worse than a stolen document store, because faces cannot be rotated like passwords. This is the same underlying logic behind the AI Act's outright ban on building recognition databases from scraped internet or CCTV imagery, which we break down in our guide to the EU AI Act facial recognition scraping ban.
You are already the controller. Long before the AI Act's high-risk clock runs out, GDPR governs your retention. Every extra month of identifiable footage is a month you must justify under purpose limitation, necessity, and storage limitation — and a month during which a data subject can exercise access and erasure rights against material you did not need to keep.
What Does GDPR Already Require of the Footage I Am Holding Right Now?
Data minimisation and storage limitation apply today, with no 2027 grace period attached. The EDPB's Guidelines 3/2019 on processing of personal data through video devices tie video surveillance directly to Article 5(1)(c), observing that continuous real-time monitoring can be more intrusive than storing material and automatically deleting it after a limited timeframe, and that the data minimisation principle must be weighed in that context. In practice, supervisory authorities expect retention set to the shortest period that serves your stated purpose, with anything longer documented and justified rather than left at a vendor default.
Note also that faces are not the only identifier in a security recording. Licence plates, visible ID badges, delivery paperwork, and screens caught in frame all carry personal data, and our GDPR video content compliance guide walks through the full inventory. If a frame lets you identify a person or a vehicle, it is in scope.
One more trap: partial obscuring is not anonymisation. A light mosaic or a low-strength pixelation can be attacked, and video makes that easier because dozens of frames of the same face give an adversary far more to work with than a single still. Our deep dive on why weak blur fails under GDPR explains why an archive protected by a cosmetic filter is very likely still personal data — and therefore still fully in scope for both retrospective identification and a regulator's questions.
What Is "Redaction at Rest" and Why Does It Solve the Archive Problem?
Redaction at rest means the copy of footage you retain long-term is already anonymised — faces and plates irreversibly blurred — so the archive itself holds no biometric payload. Live monitoring and short-term incident review still work on identifiable video; only the durable copy is redacted.
The reason this works is that it attacks the input rather than the rules. Every safeguard discussed above governs who may run a search and under what authority. None of them help you if the underlying material is rich in identifiable faces and something goes wrong — an over-broad request, a misconfigured share, a breach. Redaction at rest removes the material. There is nothing to over-disclose, nothing to leak biometrically, and nothing to mine.
| Approach | What it protects against | What it leaves exposed |
|---|---|---|
| Shorter retention only | Old footage requests | Everything inside the retention window |
| Access controls and logging | Casual internal misuse | Lawful access requests, breach, misconfiguration |
| Light pixelation / mosaic | Casual viewing | Reversal attacks; may still be personal data |
| Redaction at rest (strong, tracked blur) | Lawful-access mining, breach, over-disclosure | Nothing biometric — the archive holds no faces |
The operational trade-off is smaller than most teams expect. A blurred archive still preserves timestamps, camera angle, movement paths, headcounts, dwell time, queue length, and scene context — which is what the archive is usually being kept for anyway. What it stops preserving is the one thing you did not need: who each person was.
How Do You Redact a Backlog of CCTV Footage Without Editing Frame by Frame?
Step 1: Inventory what you are actually storing
List every camera system, DVR, NAS, cloud bucket, and export folder holding video. For each, record the retention period, who can access it, and what purpose justifies keeping it. Most organisations find at least one system quietly retaining far longer than policy says — an old recorder, an exported incident folder, a marketing drive full of event footage.
Step 2: Split the retention window from the archive
Define a short unredacted window matched to your genuine incident-response cycle. Beyond that boundary, the retained copy should be the redacted one. Write it down as policy — the documentation is itself a GDPR accountability artefact under Article 5(2).
Step 3: Batch-blur the backlog
Load the archive into BGBlur and run motion-tracked face and licence plate blur. Detection follows each subject across the clip automatically instead of requiring keyframed masks, so a multi-hour recording does not become a manual editing project, and batch processing lets you queue a library rather than opening files one at a time. Because processing runs in the browser, raw footage is not handed off to a separate pipeline, and uploaded source files are deleted within 24 hours. For a wider view of the tooling landscape, see our comparison of tools for security and CCTV footage processing and our roundup of video redaction software for business.
Step 4: Verify strength, then replace the original
Scrub the output at full resolution and check the hard cases: fast motion, partial occlusion, subjects entering or leaving frame, reflections in glass. Confirm the blur holds on every frame, export as MP4, MOV, or WebM, then make the redacted file the retained version and delete the unredacted source. A blurred copy sitting next to the original protects nobody.
Step 5: Fix the pipeline, not just the backlog
Redacting once is a cleanup. Redaction at rest is a habit: build the blur step into whatever moves footage from the live recorder into long-term storage, so the backlog does not rebuild itself over the next eighteen months.
Who Should Act on This Before December 2027?
Retailers and hospitality operators: multi-site camera estates with long default retention are the single most requested source of third-party footage. A redacted archive turns a disclosure headache into a routine, low-risk response.
Transport operators and mobility fleets: station, platform, and vehicle cameras capture the movement patterns retrospective identification is most useful for reconstructing — and they capture plates as well as faces.
Stadiums, venues, and event organisers: crowd footage is the highest-density biometric material most organisations will ever hold, and it is frequently retained for marketing long after the security purpose has expired.
Universities and schools: campus footage combines minors, staff, and visitors under a heightened expectation of privacy and closer supervisory attention.
Property managers and residential operators: shared-space and entrance cameras routinely capture people who never consented to anything, which is the same bystander problem covered in our doorbell and security camera GDPR guide.
Anyone publishing security footage externally: incident clips shared with insurers, on social media, or with the press should be redacted before they leave the building — see why you should blur security footage before posting it online.
Pro Tips for Getting Archive Redaction Right
- Redact plates as well as faces. A vehicle is an identifier. An archive with blurred faces and readable plates is still a movement-tracking dataset.
- Set blur strength for the export resolution, not the preview. What looks unreadable in a scaled-down preview can resolve at native 4K.
- Test on your worst footage first. Night-time, wide-angle, low-frame-rate, heavily compressed clips are where detection struggles — validate there before batching thousands of files.
- Delete, do not archive, the source. Keeping the unredacted original "just in case" reinstates the exact liability you removed.
- Log what you redacted and when. Article 5(2) accountability rewards a paper trail, and it is far cheaper to produce as you go than to reconstruct under a deadline.
- Revisit vendor defaults. Recorder retention is often set once at installation and never audited again.
The Bottom Line
The EU AI Act's August 2, 2026 milestone has been reported as a transparency story, but for anyone operating cameras the more consequential detail is what it revealed about sequencing. Prohibitions on scraping and on live public facial recognition are already in force. The structured safeguards on retrospective identification — judicial authorisation, strict necessity, no untargeted use, no sole-basis adverse decisions, documented logging — arrive with the high-risk regime on December 2, 2027. Between now and then, the footage you keep is the variable you control.
That is the whole argument for redaction at rest. You cannot influence who is authorised to search archived video, but you can decide what your archive contains when they do. Blur faces and licence plates before footage crosses into long-term storage, keep the unredacted window as short as your incident process genuinely requires, and delete the sources. You keep the operational value of your recordings and drop the biometric payload that makes them a liability. Try BGBlur to batch-blur faces and plates across your CCTV archive — in the browser, with source files deleted within 24 hours.