EU AI Act and Physical Security: The Article 6 Test for Perimeter AI

The EU AI Act is not, as the trade press often suggests, a regulation that bans perimeter analytics. It is a regulation that classifies them, and the classification depends on what the system actually does, not on what the brochure claims.

That distinction matters because the perimeter security market has spent the last three years marketing every camera with a neural network as "AI-powered", without the operators of those cameras understanding which obligations attach to the label. The Act forces a sorting exercise. Some systems land outside the high-risk category and continue under existing data protection and sector law. Some land inside Article 6 and trigger a compliance regime that resembles, in structure and seriousness, what the medical device industry has lived under for years. The third group, biometric identification in publicly accessible spaces, lives under a separate and stricter article and is not the subject of this article.

This text is written for operators of construction sites, industrial perimeters and logistics terminals who already run, or are about to procure, AI-assisted video analytics. It is also written for the security service providers who deliver those systems on their behalf. The objective is not legal advice. The objective is to give the operator a structure for the conversation with legal counsel, the data protection officer and the supplier, so that the decision about what to deploy and how to document it is made on the right basis rather than the marketing one.

What the Act actually regulates

The EU AI Act is a product safety regulation in the lineage of the New Legislative Framework. It does not regulate the use of cameras as such. It regulates the placing on the market and the putting into service of AI systems, with obligations distributed between providers, deployers, importers and distributors. For the operator of an industrial perimeter, the relevant role is usually that of the deployer, the entity that uses an AI system under its authority. The provider role belongs to the company that develops the system and places it on the market under its name, which in the perimeter context is the analytics vendor or, increasingly, the integrated camera manufacturer.

The Act establishes a tiered structure. Prohibited practices are listed in Article 5 and include, among others, certain forms of real-time remote biometric identification in publicly accessible spaces, social scoring, and the inference of emotions in the workplace. High-risk systems are defined in Article 6 by reference to two routes, the product safety route under Annex I and the use-case route under Annex III. Limited-risk systems carry transparency obligations, primarily disclosure that a user is interacting with an AI system. Minimal-risk systems carry no specific obligations under the Act but remain subject to all other applicable law, including the GDPR, the Law Enforcement Directive where relevant, and national security and labour law.

Perimeter analytics in the conventional sense, meaning a system that detects intrusion at a fence line, classifies objects as person or vehicle, and raises an alarm to a control room, is not on the prohibited list. The question is whether it falls inside Article 6, and if so, on which leg. The answer is not uniform across products. A line-crossing detector that classifies objects is not the same system, in regulatory terms, as a behaviour analytics module that infers intent, and neither is the same as a face-matching module bolted onto the same camera. The operator who buys a single appliance and assumes a single classification has already made the first mistake.

The Article 6 test, applied to a perimeter

Article 6 classifies a system as high-risk when one of two conditions is met. The first condition, set out in Article 6(1), captures AI systems that are themselves a safety component of a product, or are a product, covered by Union harmonisation legislation listed in Annex I, and that require a third-party conformity assessment. This route is not the typical entry point for perimeter security. Most perimeter analytics are not safety components of machinery in the sense of the Machinery Regulation, and they are not medical devices, lifts or pressure equipment. There are edge cases in industrial settings where an AI module participates in a safety function, but for fence-line intrusion detection the second route is the one that matters.

The second condition, Article 6(2), captures the use cases listed in Annex III. Annex III includes biometric identification and categorisation, critical infrastructure management, education, employment, access to essential services, law enforcement, migration and border control, and administration of justice. For perimeter security, three Annex III categories matter. Biometric identification, where the system identifies a natural person by comparing their biometric data to a reference database, is high-risk. Biometric categorisation according to sensitive attributes is high-risk. And the management and operation of critical infrastructure, in particular the safety components of digital infrastructure, road traffic, water, gas, heating, electricity, is high-risk where AI systems are intended to be used as safety components.

A standard perimeter system that detects motion, classifies objects as person or vehicle, and tracks them across a defined zone is, in most readings, not biometric identification. It does not match faces against a reference set. It does not identify the individual. It detects presence and class. That places it, for many sites, outside Article 6, with obligations flowing from the GDPR rather than from the AI Act. The picture changes if the same camera platform adds a face-matching module against a watchlist, even an internal one of known trespassers. It changes again if the system infers attributes from gait, clothing or demeanour in a way that constitutes biometric categorisation. And it changes if the perimeter in question is the perimeter of an installation that qualifies as critical infrastructure and the analytics function is treated as a safety component of that infrastructure.

The Article 6 test is therefore not a single answer for a vendor and a category. It is a determination per system, per configuration, per deployment context. An operator who buys the same product for an office back lot and for a water utility intake station may find the two installations on different sides of the line. This is not a flaw in the regulation. It is the regulation working as intended, distributing obligation by function rather than by label.

Where perimeter analytics land, in practice

In the deployments BOSWAU + KNAUER sees across construction, industry and logistics, the majority of perimeter analytics fall outside high-risk under the AI Act, while remaining subject to the GDPR and to national law on workplace monitoring and works councils. This is the case for line-crossing, zone intrusion, loitering detection, abandoned object detection, and object classification limited to person and vehicle categories. These functions process personal data, in the sense that an identifiable person may appear in the frame, but they do not identify by biometric comparison and they do not categorise by sensitive attribute. The compliance burden is real but it is the burden the operator already carries under existing law.

A second group lands clearly inside Article 6 by way of the biometric leg. This includes any perimeter system that matches faces against a watchlist, whether the watchlist is composed of repeat offenders, blacklisted contractors, or former employees. It includes systems that perform one-to-many identification at access points, and it includes systems that infer sensitive categories such as ethnicity, age band below adulthood, or health status. Operators considering such systems should understand that the regulatory regime they are entering is comparable in seriousness to that of a Class IIb medical device, with conformity assessment, technical documentation, registration in the EU database, post-market monitoring and incident reporting obligations attached. The decision to deploy is no longer purely a security or commercial decision. It is a regulated product decision.

A third group sits in the critical infrastructure leg. Where the perimeter system protects an installation that qualifies as critical infrastructure under the relevant national or Union law, and where the AI function is intended to be used as a safety component of the operation of that infrastructure, Article 6(2) bites. The threshold here is the intended use. A camera that observes a substation perimeter and raises a security alarm is not necessarily a safety component of the electricity infrastructure. A system that gates an interlock or initiates a shutdown sequence in response to AI-detected events probably is. The integrator and the operator need to be aligned on this point before the system is commissioned, because once commissioned the obligations attach to the actual function.

The fourth group, often missed in vendor conversations, comprises systems used in the employment context to monitor workers. The Act treats AI for monitoring and evaluation of workers as high-risk under Annex III. A perimeter system that incidentally records workers entering and leaving a site is not, in itself, a worker monitoring system. A system that scores attendance, productivity or behaviour based on AI inference is. The boundary is not always obvious, and operators with mixed-use cameras, security plus operations analytics, need to draw the line in the technical documentation rather than in the marketing.

Documentation, the part nobody wants to read

The obligations of a deployer of a high-risk AI system are lighter than those of a provider, but they are not trivial. Article 26 of the Act imposes duties to use the system in accordance with the instructions for use, to assign human oversight to natural persons with the necessary competence and authority, to ensure that input data is relevant and sufficiently representative for the intended purpose, to monitor operation and report serious incidents, and to keep automatically generated logs for the period appropriate to the intended purpose, with a six-month minimum in many cases. For workplace deployments, the deployer must inform workers' representatives and the affected workers before putting the system into service. For deployments by public authorities or by entities providing public services, a fundamental rights impact assessment under Article 27 is required.

The provider obligations, which the security integrator or analytics vendor will carry, are heavier. They include a risk management system throughout the lifecycle, data governance for training, validation and testing data sets, technical documentation in line with Annex IV, record-keeping, transparency and information to deployers, human oversight by design, accuracy, robustness and cybersecurity, a quality management system, conformity assessment, the CE marking, registration in the EU database, post-market monitoring, and reporting of serious incidents. The integrator who has been selling line-crossing detection for ten years on the basis of a two-page datasheet will find this list uncomfortable.

The operator's protection against this discomfort being transferred upstream is contract. The procurement file for a perimeter AI system should now contain, at minimum, a clear statement from the provider as to whether the system is classified as high-risk under the Act and on which leg, a copy of the EU declaration of conformity where applicable, the instructions for use referenced in Article 13, a description of the human oversight measures, the accuracy and robustness metrics with the conditions under which they were measured, and a commitment to inform the deployer of any modification that would affect the classification. Where the system is not classified as high-risk, the file should contain the provider's reasoned position on why it is not, because that position will need to be defended if a supervisory authority asks. The third path in the Dr. Nagel manuscript BOSWAU + KNAUER. From Building to Security Technology, the ninety-day pilot, is designed to surface exactly these documentation questions before the platform decision is made, not after.

Cyber, NIS2 and the IEC 62443 overlap

The AI Act does not exist in isolation. For most perimeter deployments, three other regimes apply in parallel. The GDPR governs the processing of personal data and, in the security context, typically requires a Data Protection Impact Assessment under Article 35 for systematic monitoring of publicly accessible areas. The NIS2 Directive, transposed across Member States through 2024 and 2025, brings essential and important entities into a cybersecurity governance regime that includes the security of network and information systems supporting their operations, and perimeter analytics platforms sit inside that scope where the operator falls within the directive. IEC 62443, while not law, is the de facto reference for industrial control and automation security and increasingly informs procurement specifications for any networked security system on an operational technology network.

The practical consequence is that the AI Act compliance question cannot be answered in isolation. A perimeter analytics system that is GDPR-compliant but not segmented from the operational network in line with IEC 62443 zones and conduits is a NIS2 problem. An analytics system that is cybersecure in the IEC 62443 sense but processes biometric data without a lawful basis is a GDPR problem. The Act adds a layer on top, not a substitute. NIST CSF 2.0 and ISO 27001 provide the management framework into which all four regimes can be mapped, and CISA guidance on physical security cyber convergence has been consistent on this point for several years. ASIS International publications on enterprise security risk management make the same argument from the practitioner side. The BSI in Germany and equivalent national authorities elsewhere have begun to publish guidance specifically on AI in security contexts, and that guidance should be read alongside the Act rather than instead of it.

For the operator, the synthesis is unglamorous but defensible. Map every AI function in the perimeter platform against Article 6. Document the classification with reasoning. Carry the documentation alongside the DPIA and the IEC 62443 zone diagram. Ensure that the human oversight required by the Act and the access control required by NIS2 are described in the same operating procedure rather than in two unconnected manuals. The auditor who arrives in 2027 will read all of them in one session.

Enforcement, timelines and the procurement window

The Act entered into force on 1 August 2024. Its provisions apply on a staggered schedule. The prohibitions in Article 5 applied from 2 February 2025. The obligations for general-purpose AI models applied from 2 August 2025. The bulk of the high-risk obligations under Article 6(2), covering the Annex III use cases that matter for perimeter security, apply from 2 August 2026. The high-risk obligations under Article 6(1), covering systems that are safety components of Annex I products, apply from 2 August 2027. Member State competent authorities and the AI Office at Union level are being established through this window, and the harmonised standards that will give presumption of conformity are being developed by CEN-CENELEC under a Commission mandate.

The procurement window is therefore short. An operator placing an order for a perimeter system in the second half of 2025 for installation in early 2026 is procuring a system that will be in operation when the Article 6(2) obligations bite. The provider that cannot answer the classification question today is unlikely to be ready in twelve months. The integrator that is willing to commit contractually to delivering a CE-marked, conformity-assessed system on the relevant date, with the technical documentation and instructions for use to match, is a different conversation partner from the one offering a generic analytics SKU. Operators should adjust their tender questions accordingly. The cost difference between the two suppliers is not the cost difference it appears to be on the quotation. It is the cost difference adjusted for the regulatory risk that the cheaper supplier transfers to the operator by silence.

For sites that already operate analytics platforms placed on the market before 2 August 2026, the transitional provisions in Article 111 apply, with substantial modifications triggering re-classification. An operator who plans a meaningful firmware upgrade, a new analytics module or a change of intended purpose after that date should treat the upgrade as a re-procurement for compliance purposes. Doing nothing and assuming legacy status is a position that may hold for some installations and not for others, and the determination should be made deliberately rather than by default.

What holds

The EU AI Act does not end perimeter analytics in Europe. It sorts them. The majority of conventional perimeter functions, detection and classification without biometric identification and without safety-component status in critical infrastructure, continue under the existing data protection framework with limited additional burden. A meaningful minority, biometric matching, sensitive categorisation, safety-component functions in critical infrastructure, and worker monitoring, enter a regulated product regime that demands documentation, conformity assessment and operational discipline that the security industry has not historically been asked to deliver.

The operator's task is to know, for each AI function on each camera at each site, which side of the line it sits on, and to hold a documented file that supports the classification. The provider's task is to deliver systems that are honestly classified, conformity-assessed where required, and shipped with instructions for use that a deployer can actually follow. The integrator's task is to bridge the two, technically and contractually, without hiding the regulatory question inside the commercial one.

For operators who are uncertain where their existing platform sits, or who are about to procure a new one, the appropriate first step is the sixty-minute confidential conversation described as Path I in the BOSWAU + KNAUER manuscript. It is not a sales meeting. It is a structured discussion of the perimeter, the analytics functions in operation or under tender, and the classification implications under Article 6. Where the conversation surfaces ambiguity that warrants a deeper look, the three-to-five-day audit of Path II produces the documented classification, the gap analysis against the deployer obligations, and the procurement-ready specification for the next platform decision. The cost of doing this work in 2025 is materially lower than the cost of doing it in response to a supervisory authority enquiry in 2027.

Frequently asked questions

What is the AI Act risk matrix?

The Act establishes four tiers. Prohibited practices under Article 5 cannot be placed on the market or used. High-risk systems under Article 6 must satisfy a substantial set of provider and deployer obligations including conformity assessment, technical documentation, human oversight, accuracy and robustness, and post-market monitoring. Limited-risk systems carry transparency obligations, primarily disclosure to users. Minimal-risk systems carry no specific AI Act obligations but remain subject to all other applicable law. The matrix is applied per system and per intended use, not per vendor or per product category, and a single platform may contain modules in different tiers.

Is perimeter AI high-risk?

It depends on what the system does. Conventional intrusion detection, line-crossing and object classification limited to person and vehicle categories typically fall outside high-risk under the Act, while remaining subject to the GDPR and national workplace monitoring law. Perimeter systems that perform biometric identification against a watchlist, biometric categorisation by sensitive attributes, safety-component functions in critical infrastructure, or systematic monitoring and evaluation of workers, fall inside Article 6 and trigger the full high-risk regime. The classification must be made per deployment, documented in the technical file, and revisited when modules or intended use change.

What documentation is required?

For high-risk systems, providers must produce the technical documentation set out in Annex IV, an EU declaration of conformity, instructions for use under Article 13, and records of the risk management system and post-market monitoring. Deployers must keep automatically generated logs, document the human oversight arrangements, conduct a fundamental rights impact assessment where required under Article 27, and inform workers' representatives where the system monitors workers. For systems classified as not high-risk, the operator should still hold a reasoned classification note, the DPIA where required by the GDPR, and the provider's confirmation of classification.

When does enforcement start?

The prohibitions in Article 5 have applied since 2 February 2025. General-purpose AI model obligations applied from 2 August 2025. The high-risk obligations relevant to most perimeter security use cases, those flowing from Annex III via Article 6(2), apply from 2 August 2026. The Article 6(1) obligations covering safety components of Annex I products apply from 2 August 2027. Procurement decisions taken in 2025 for installations going live in 2026 are therefore already subject to the high-risk regime where the system falls inside Annex III, and provider readiness on the relevant date should be a contractual deliverable rather than an assumption.