EU AI Act for physical security systems — what you need to know

Annex III of the AI Act lists eight areas of high-risk AI systems. The strongest interpretation places Perimetro Platform outside Annex III. The most debatable item is point 2 (critical infrastructure), but its literal reading covers AI used in the delivery of a critical service (AI controlling energy distribution, AI in SCADA, AI controlling road traffic) — not AI used to protect the perimeter of a site delivering a critical service.

An analogous reading applies to CCTV systems, which are not classified as high-risk despite serving the protection of critical infrastructure. The remaining seven Annex III points (biometrics, education, employment, access to services, law enforcement, migration, justice) unambiguously do not cover Perimetro. The detection classifier has three generic classes (person, vehicle, zone breach, drone* on the detection roadmap) without subtypes or individual identification.

A conservative reading might bring Perimetro under Art. 6(2) if the deployer uses the system as a safety component of their infrastructure — in which case Perimetro would be a high-risk AI system for that specific deployment. The final decision belongs to the supervisory authority and to the deployer's legal assessment in their operational context. Perimetro provides documentation for both paths.

A common misunderstanding is the assumption that "high-risk certified" is a stronger position than "outside high-risk". In procurement and compliance practice, the opposite holds. The outside-high-risk deployer client saves four categories of formal obligations under Art. 8-17 and Art. 71 of the AI Act.

First, conformity assessment by a notified body (Art. 43) — cost EUR 50-150k one-time plus renewals after material system changes. Second, CE marking and declaration of conformity (Art. 47-48) — a formal 3-6 month process. Third, registration in the EU database for high-risk AI systems (Art. 71) — public reporting plus update obligations. Fourth, formal post-market monitoring (Art. 72) — incident reporting to the EU AI Office.

Meanwhile Perimetro implements the full set of controls from Art. 9-15 — the client gets a system designed like high-risk without the high-risk obligations on their side. By comparison, alternative cloud-first solutions transferring raw video streams typically require the deployer to perform a conformity assessment for every material change, run full post-market monitoring, and build their own inference logging infrastructure.

Perimetro's position: the client gets an auditable, documented tool with documented risk — regardless of formal classification. Scoping outside Annex III means the client saves 6-12 months of procurement and EUR 50-150k of formal conformity assessment cost, while receiving an architecture that exceeds the minimum high-risk requirements.

Art. 5 of the AI Act lists eight prohibited practices. Perimetro satisfies this article through architectural constraints, not organisational policies. Individual biometric identification (Art. 5(1)(h)): the detection classifier has three generic classes without subtypes or identification. The event payload schema has no fields permitting individual identification.

Biometric categorisation (Art. 5(1)(g)): the classifier does not analyse demographic attributes — no such features in the model architecture, no such categories in the event schema. Emotion recognition (Art. 5(1)(f)): no emotion recognition functionality, no such classes in the detection taxonomy, the ML model has no detection heads for affect, gestures or posture.

Social scoring (Art. 5(1)(c)): the system does not rate people, it rates events (zone breach incidents). The audit log contains no per-person aggregated scores or histories of individual behaviour. Predictive policing for individual offences (Art. 5(1)(d)): the system does not rate people, escalation is event-based, not person-based. Untargeted scraping of facial images (Art. 5(1)(e)): the system does not build face databases, key frames are stored per event with configurable retention and optional face blur enabled by default.

All the above prohibitions are enforced structurally in the Protocol Buffers schema defining the edge ↔ cloud communication format. The absence of fields like face_descriptor, emotion_score, demographic_attribute, behavioral_score is a CI/CD gate — automatic tests verify that a new build hasn't introduced prohibited fields. A pull request modifying the event schema is mandatorily reviewed by the compliance officer and the CTO before merge.

Art. 9 of the AI Act requires a continuous, iterative risk management process covering identification of known and foreseeable risks, estimation of risks from intended use, evaluation of risks from possible misuse, management measures for identified risks, and elimination or reduction of risks through design.

Perimetro's Risk Register is maintained as a versioned document in source control and covers six categories of risk. Operational: classification false positive causing unnecessary escalation, false negative letting an intruder through, connectivity failure during a mission — measures: confidence threshold configurable per class, outbox queue for offline operation, autonomous return-to-home on connectivity loss.

Compliance: unauthorised access to client data, audit trail loss, data residency violation — measures: per-tenant encryption with key destruction (cryptographic erasure), HMAC hash chain for the audit log, EU-only infrastructure. Model security: adversarial examples, model drift from seasonal lighting changes — measures: adversarial testing in CI, model evaluation per release on a test dataset with edge cases, drift monitoring in production.

The Risk Register is updated at every ML model release (pre-deployment risk review as a CI/CD gate), quarterly (systematic review by compliance officer plus ML lead plus CTO), ad-hoc on production incidents, and after material regulatory changes. Every update is timestamped, authored and reason-stamped. History is available to auditors under NDA as part of documentation aligned with Art. 11 AI Act (Annex IV).

Art. 14 of the AI Act requires that high-risk AI systems be designed to enable effective human oversight. Perimetro implements the HITL (Human-in-the-Loop) model as an architectural constraint, not a configurable option. HIGH events (intruder in restricted zone, high-confidence thermal anomaly) require explicit operator acknowledgment with one of four action choices: escalate, verify, mark as classification error, normal handling.

The system performs no autonomous kinetic response. The Aero drone may change its patrol route but cannot actively pursue an intruder or take actions other than observation and reporting. Tower and Connect generate alerts only — physical response (gate locking, recording activation, patrol dispatch) requires operator decision or is delivered through integrations with client systems (Genetec, Milestone, access control).

The operator UI is designed in line with WCAG AA accessibility best practices. HIGH alerts are modal blocking — the operator cannot move to another task without taking a decision. Auto-escalation to supervisor happens after 60 seconds (timeout configurable per client) without an operator decision — with an audit log entry stating that the supervisor was notified due to timeout, not active operator escalation.

The absence of autonomous kinetic response is enforced structurally. The event state machine has no "auto-respond" transition — every HIGH event must pass through an operator or supervisor decision. A pull request introducing such a transition would be blocked in code review by the compliance officer.

Art. 15 of the AI Act requires high-risk AI systems to reach an appropriate level of accuracy, robustness and cybersecurity throughout their lifecycle. Perimetro's classifier accuracy is measured on a test dataset representative of European conditions (varied times of day, weather, seasons) with precision, recall, F1 per class metrics.

Robustness covers adversarial testing (imagery crafted to evade detection or generate false positives), model evaluation per release on edge cases (occluded intruders, partial thermal masking, extreme weather), and drift monitoring in production (auto-detection when per-class performance drops below threshold). Concrete metrics are available in Dataset Cards and Model Cards within the client's VRA Pack.

Cybersecurity: TLS 1.3 with a per-device HMAC-SHA256 signature for edge ↔ cloud communication (with replay protection), per-tenant encryption keys with optional Customer-Managed Keys, HMAC hash chain for the audit log (tamper-evident — log entry modification is cryptographically detectable), regular penetration testing by an external firm (annual plus ad-hoc after material system changes).

Drift detection is automatic. The system monitors per-class production performance (precision on confirmed-by-operator events) and emits an alert to the ML team when it drops below a per-client configurable threshold (default 5% drop over 7 days). The trigger initiates a retraining cycle or rollback to the previous model version, with the decision sitting with the ML lead under compliance officer review.

Critical infrastructure operators usually fall under NIS2, AI Act, GDPR and often CER simultaneously. These regimes have overlapping requirements — audit logging (NIS2 Art. 21 plus AI Act Art. 12), risk management (NIS2 Art. 21 plus AI Act Art. 9), incident reporting (NIS2 Art. 23 plus AI Act Art. 73 for high-risk), supply chain (NIS2 Art. 21(2)(d) plus AI Act Art. 25 for providers).

Perimetro Platform is designed for all these regimes at once. The audit log is tamper-evident (HMAC hash chain) — it satisfies the NIS2 audit requirement and AI Act Art. 12 logging simultaneously. The Risk Register covers both operational risks (NIS2 framing) and ML model risks (AI Act framing). The NIS2 Reporter generates 24h/72h reports in the format required by the national CSIRT, regardless of the regulatory path applied to the AI component of the system.

The deployer client gets one integration platform for both regimes. The compliance officer does not need to map separately to NIS2 and separately to the AI Act — Perimetro provides the mapping in the VRA Pack (Vendor Risk Assessment Pack) as a pre-filled template from the client perspective. Pre-filled DPIA template, supply chain analysis, risk register sample, audit log specification — all ready for review by the client's counsel instead of being written from scratch.

Full analysis and mapping of all AI Act articles (Art. 5 and 9-15) plus AI threat model plus FRIA plus post-market monitoring plus AI Regulatory Sandbox plus AI Act assessment case study are available in the whitepaper "Perimetro AI Act Conformity Reference Architecture v2.0" (49 pages, publicly available under NDA for enterprise clients with procurement intent).