EU AI Act and Edge AI: What Applies Now, What Comes in 2027

If you build or deploy camera-based AI in Europe, the last few months have been a mess to follow. The EU AI Act’s high-risk obligations were supposed to kick in on 2 August 2026. Then the Digital Omnibus pushed that deadline back. A lot of coverage made it sound like the rules were cancelled. They weren’t.

So here’s the state of play, in plain language, and why “it’s delayed” is not the same as “you can relax,” especially if your product points a camera at people.

Where the AI Act actually stands

The AI Act doesn’t all kick in at once. After the Digital Omnibus on AI (provisional deal 7 May 2026; published as Regulation (EU) 2026/1744 on 24 July 2026; in force 27 July 2026) here’s what the timeline actually looks like:

Don’t forget the Cyber Resilience Act

The AI Act is not the only EU rulebook relevant to connected edge-AI products. The Cyber Resilience Act (CRA) sets cybersecurity requirements for products with digital elements made available on the EU market, subject to its scope and exclusions. That can include connected cameras, gateways, edge devices, and their software. The CRA entered into force on 10 December 2024. Its reporting rules are already live: from 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of covered products. The CRA’s main product-security obligations including secure-by-design requirements, vulnerability handling, security updates, and conformity assessment apply from 11 December 2027. For a connected vision product, this creates a separate but overlapping question from AI Act classification: even if an AI use case is not high-risk, the product may still need a CRA compliance assessment. If you manufacture, substantially modify, or place a connected product on the market under your own name, map the CRA role and obligations alongside the AI Act role and obligations.

Why “delayed” does not mean “do nothing”

Four practical reasons:

1. Your camera data is regulated today. The moment footage of an identifiable person leaves the device, you’re doing personal data processing under GDPR: legal basis, retention limits, processor agreements, breach duties. None of that waited for the AI Act.
2. The bans and transparency rules are live. Prohibited practices have applied since February 2025, and the Article 50 transparency duties since August 2026. “High-risk is deferred” doesn’t cover either of those.
3. December 2027 will land inside your product’s lifetime. A vision system you deploy this quarter will still be running when Annex III obligations bite. Deployed high-risk systems get some grandfathering, but only until they undergo significant changes in their designs (Art. 111(2)). In any case, high-risk systems intended for use by public authorities must comply by 2 August 2030. Building compliant-by-design now is cheaper than retrofitting later.
4. Your customers are already asking. Public-sector and enterprise procurement teams read the same headlines. RFPs increasingly ask where video gets processed, where it’s stored, and who can access it regardless of statutory deadlines.

Cloud AI vs. on-device AI: the compliance difference

The single biggest lever you control is architectural: where inference happens. That one decision determines how much personal data exists outside the camera in the first place.

To be precise: processing on the device is still processing under GDPR. Running inference locally doesn’t make anyone compliant on its own. What it does is shrink the surface you have to manage: less data in flight, less data at rest, fewer parties touching it. Data minimization, which regulators keep repeating as the core principle, stops being a policy statement and becomes a property of the architecture.

How on-device vision works

A neural accelerator (NPU) sits next to the Raspberry Pi 5 and runs the vision model locally, at tens of frames per second and a few watts. Your application logic sees detections, not the world’s rawest personal data. What you forward upstream is your call, and that call is exactly what a privacy review wants to see documented.

We wrote up the architecture pattern in more detail in See Everything, Send Nothing.

Who is responsible: provider, integrator or deployer?

The AI Act splits responsibilities between different roles, and the same company can wear more than one hat.

A practical checklist for builders

• Classify your use case first. Run it against the prohibited list (Article 5), then against Annex III. Most retail counting, quality inspection, parking, and generic safety monitoring use cases aren’t high-risk, unless the AI is used as a safety component in critical infrastructure (Annex III, point 2) or embedded in regulated products under Annex I. Emotion inference in workplaces and schools is prohibited outright under Article 5 (except for medical or safety uses). Biometric identification is high-risk under Annex III and needs a proper assessment. Even if your system technically falls under Annex III, it may still be excluded from the high-risk category by Article 6(3), which covers four situations: narrow procedural tasks, improving the result of a previously completed human activity, detecting decision-making patterns without replacing human review, and preparatory work for an Annex III assessment. Profiling of natural persons never qualifies for the exemption. If you rely on this exemption, you must document your assessment before placing the system on the market and register it: the Omnibus streamlined that registration, it didn’t remove it. The system also remains subject to the AI Act’s prohibitions and transparency rules.
• Do the GDPR work you already owe. Lawful basis, DPIA for systematic monitoring of a publicly accessible area on a large scale (GDPR Art. 35(3)(c)), retention schedule, signage. All of it applies today. Edge or Cloud.
• Minimize by architecture. Process on device, export events, keep raw footage only where you have a documented reason.
• Meet Article 50 now (provider duties). If people interact with your AI system, disclose it (no grace period). If you generate synthetic audio, image, video or text content, apply machine-readable marking. The marking obligation has a grace period to 2 December 2026 only for generative AI systems already on the market before 2 August 2026.
• Article 50(3) (deployer duties). If you deploy an emotion recognition or biometric categorisation system, you must inform the natural persons exposed to its operation, regardless of whether the analysis is live or done afterwards. This is a deployer obligation, separate from the provider’s transparency duties, and it applies in addition to GDPR information requirements. Note that many workplace and school uses of emotion recognition are prohibited under Article 5, so the first check is always whether the deployment is allowed at all.
• Write it down. A one-page data-flow diagram of your deployment answers half of any privacy questionnaire.
• Track the standards. Harmonised standards for high-risk systems don’t change the 2 December 2027 / 2 August 2028 deadlines, but they give presumption of conformity and practical guidance on how to comply.

Where Sixfab fits

Sixfab supplies hardware components, not finished AI systems. The company that builds, brands, and markets the completed camera-AI solution is generally the provider of that AI system under the AI Act.

Does the AI Act apply if we’re outside the EU?

The AI Act has extraterritorial reach. It can apply even if your company is not based in Europe. It applies to providers (including those outside the EU) that place an AI system on the EU market or put it into service in the EU, regardless of where they are established. It applies to deployers located in the EU. And it applies to providers and deployers outside the EU where the output produced by the AI system is used in the EU, for example, a non-EU vendor running analytics on video feeds from EU stores.

Non-EU providers of high-risk AI systems must also appoint an authorised representative in the EU. If your customers are in Europe, or your system processes data from EU sites, assume the AI Act can apply to you directly.

FAQ

Is edge AI covered by the EU AI Act?

Yes. The Act is technology-neutral; obligations follow the use case and its risk class, not where inference runs. Edge deployment does not exempt a system, but it substantially reduces the personal-data footprint that GDPR and the Act’s data-governance duties attach to.

Was the EU AI Act delayed?

Partially. The Digital Omnibus on AI (provisional deal 7 May 2026; Regulation (EU) 2026/1744, in force 27 July 2026) postponed the high-risk obligations: Stand-alone high-risk systems (Annex III): from 2 August 2026 → 2 December 2027. AI embedded in regulated products (Annex I, e.g. medical devices, toys, lifts): from August 2027 → 2 August 2028. The prohibitions (Article 5), general-purpose AI rules, and Article 50 transparency duties were not deferred and apply on their original dates.

When did the AI Act enter into force?

The EU AI Act entered into force on 1 August 2024 and applies in stages. Prohibited AI practices (e.g. social scoring, certain biometric categorisation, and AI systems that infer emotions in workplaces and schools except for medical or safety uses) and AI literacy duties applied from 2 February 2025. Governance rules for general-purpose AI models applied from 2 August 2025. Transparency obligations under Article 50 applied from 2 August 2026, covering both informing people they are interacting with AI and machine-readable marking of AI-generated content. The marking obligation has a narrow grace period to 2 December 2026 for certain generative systems already on the market. High-risk obligations apply from 2 December 2027 for standalone Annex III systems, and from 2 August 2028 for AI embedded in regulated products (Annex I).

If video is processed on the device, does GDPR still apply?

Yes. Analyzing footage of identifiable people is personal data processing under GDPR wherever it happens, including on-device. The practical difference is that if raw frames are analyzed and discarded locally, you retain far less personal data, which makes it easier to comply with data minimisation, retention limits, breach notification and security obligations, and to document your processing in DPIAs and records of processing activities.

Does using edge hardware make my product compliant?

No single component or architectural choice makes a product “compliant” on its own. Compliance depends on your use case, risk classification, documentation and processes (lawful basis, DPIA where required, transparency, security, etc.). On-device processing is a privacy-by-design architectural choice that removes whole categories of risk (cross-border transfers, large cloud archives, many third-party processors), which is why data protection authorities and privacy frameworks generally favor it, but it does not by itself guarantee compliance with the GDPR or the AI Act.

If I build a solution with edge-AI hardware, who is the AI Act provider?

The provider is generally the organisation that develops, brands, and places the finished AI system on the market, or puts it into service under its own name. A hardware supplier is not automatically the provider of the finished camera-AI system. However, where hardware components are used in a high-risk AI system, Article 25(4) requires the provider and the relevant third-party supplier to agree in writing on the information and assistance needed to support compliance.

Does the Cyber Resilience Act apply to connected edge-AI hardware?

It may. The CRA applies to products with digital elements made available on the EU market, subject to its scope and exclusions. Its incident and vulnerability reporting obligations have applied since 11 September 2026, while the main product-security obligations apply from 11 December 2027. Whether a specific connected camera, gateway, edge device, or software component is covered depends on the product and its regulatory classification.