How do we tell whether a system is a "safety component" under branch one?

A safety component is a component of a product whose failure would endanger the health and safety of persons or property. The classification follows the underlying Union harmonization legislation. For medical devices, the Medical Device Regulation (MDR) provides the safety-component criteria. For machinery, the Machinery Regulation applies. The AI system inherits the classification from the regulated product it sits inside. The provider should consult the notified body for the relevant harmonization legislation and the AI Office for cross-cutting interpretation.

Does using a general-purpose AI model change the classification?

No. The classification turns on the use case, not on the underlying model. A general-purpose AI model used in a high-risk use case under branch one or branch two is part of a high-risk AI system. The model provider has separate obligations under Articles 53 to 56. The system provider and deployer carry the high-risk obligations under Articles 8 to 27. The two regimes operate together when a general-purpose model is integrated into a high-risk system.

What happens if our classification is wrong?

An incorrect classification produces compliance failure under whichever obligations were not satisfied because of the misclassification. If a deployer classifies a system as low-risk when it should have been high-risk, the deployer faces Tier 2 Article 99 exposure for every Articles-8-to-27 obligation that was not met. The defensible posture is to err toward conservative classification and to document the analysis so the regulator can see the reasoning. Underclassification produces structural penalty exposure. Overclassification produces operational cost.

Can we classify the same system differently for different deployments?

The provider classifies the system at the design level. The deployer verifies the classification holds in its deployment. If the deployer uses the system in a way that materially differs from the provider's intended use, the deployer's deployment can carry a different classification. The deployer's verification work and any deviation must be documented under Article 26 and supplied to the provider so the provider's post-market monitoring under Article 72 can take it into account.

How often should classification be reviewed?

Classification should be reviewed at every material change to the system, the use case, the data flows, or the regulatory context. Annual review is the operational baseline. The Commission's authority to amend Annex III means new categories can appear, and existing categories can be revised. A deployer that classified a system as out of scope in 2026 may need to reclassify in 2027 if the Commission expands Annex III.

EU AI Act High-Risk Classification: The Article 6 Two-Branch Test

Article 6 of the EU AI Act establishes the two-branch test that classifies an AI system as high-risk. Branch one covers AI systems that are safety components of products regulated under listed Union harmonization legislation, such as medical devices, machinery, and toys. Branch two covers AI systems that fall within one of the eight use-case categories in Annex III. A system is high-risk if it meets either test. The classification triggers the full operational regime under Articles 8 to 27 from August 2, 2026. I see most enterprise teams running classification work on the Annex III branch and missing the safety-component branch entirely.

I want to walk through both branches of the test, the carve-out in Article 6(3), and the operational consequence of getting classification wrong.

Mandate

Article 6 is the gateway provision. Every other obligation in the high-risk regime applies only to systems that pass through Article 6. The provision sits at the top of Title III of the Act and governs the scope of the entire regulatory weight.

Branch one: safety components of regulated products

The first branch applies if two conditions hold together. The AI system is intended to be used as a safety component of a product covered by Union harmonization legislation listed in Annex I, or the AI system is itself such a product. And the product is required to undergo a third-party conformity assessment under that legislation. Annex I lists machinery, toys, recreational craft, lifts, equipment for explosive atmospheres, radio equipment, pressure equipment, cableway installations, personal protective equipment, gas appliances, medical devices, in vitro diagnostic medical devices, civil aviation, two- and three-wheel vehicles, agricultural vehicles, marine equipment, rail, motor vehicles, and aviation security.

A clinical decision support tool that is integrated into a regulated medical device is high-risk under branch one regardless of whether the AI use case appears in Annex III. The branch one classification often catches enterprise teams that have classified the AI work as software but the regulatory context as device.

Branch two: Annex III use cases

The second branch applies if the AI system falls within one of the eight Annex III categories: biometrics, critical infrastructure, education, employment, access to essential services, law enforcement, migration, and administration of justice. Branch two is the path through which most enterprise AI deployments are classified as high-risk.

Either branch triggers the full regime

A system is high-risk if it passes either test. Branch one classification carries the same obligations as branch two. The provider obligations under Articles 16 to 22, the deployer obligations under Article 26, the record-keeping under Article 12 and Article 19, the transparency under Article 13, and the Article 99 penalty exposure apply uniformly.

The Article 6(3) carve-out

Article 6(3) carves a narrow set of systems out of the high-risk regime. The carve-out applies if the AI system performs only one of four specific functions: a narrow procedural task, an improvement of the result of a previously completed human activity, a detection of decision-making patterns without replacement or material influence on the human assessment, or a preparatory task for an assessment relevant to the purposes of the use case.

The carve-out is intentionally narrow. The provider claiming it must document the classification, notify the national authority on request, and produce the evidence supporting the classification. The carve-out does not apply if the system profiles natural persons, regardless of which of the four functions it performs.

Procedural task means what it says

A "narrow procedural task" is a function that does not involve judgment about the substantive content of the underlying decision. A system that converts an audio recording into a transcript before a human reviews it qualifies. A system that ranks the transcripts by likely relevance before a human reviews them does not, because the ranking influences the human's attention allocation.

Profile-of-natural-persons exclusion

The carve-out explicitly does not apply to systems that profile natural persons. Profiling under Article 4(4) of GDPR is any form of automated processing of personal data to evaluate certain personal aspects relating to a natural person. Most AI systems that produce per-person outputs fall under the GDPR profiling definition. The carve-out cannot be used to remove those systems from the high-risk regime.

Compliance gap

Most enterprise classification work I review has three recurring gaps.

The safety-component branch is missed

Teams that classify their AI work as "software" assume Annex III is the only relevant branch. The branch one safety-component test catches AI integrated into medical devices, industrial machinery, and vehicle systems. A clinical AI feature that runs on a class IIa medical device platform falls under branch one even if the AI use case (e.g., decision support for image triage) does not appear in Annex III.

The carve-out is over-claimed

Teams that read Article 6(3) tend to claim the carve-out applies because the system "only assists" a human. The carve-out is narrower than that. Any system that materially influences the human decision falls outside the carve-out. The threshold is whether the human would have reached a different conclusion without the system's output. If the answer is yes, the system materially influences and stays high-risk.

Cross-branch overlap is missed

A system can satisfy both branches simultaneously. An AI that screens medical device alarms is a safety component of a regulated device (branch one) and may fall under Annex III Category 5 (access to essential health services) depending on the use case. The compliance posture must address both classifications, because the technical documentation, conformity assessment, and post-market monitoring requirements stack.

What classification work actually requires

Classification under Article 6 is a documented activity, not a one-time spreadsheet exercise. The provider must produce technical documentation under Article 11 that includes the classification analysis. The deployer must verify the classification holds in its deployment context and document any deviation.

The classification work runs through three artifacts. First, a written analysis covering both branches and the carve-out, with the specific use case identified and the regulatory citation made. Second, evidence supporting the classification, including the use case description, the data flows, the human-in-the-loop boundaries, and the dependencies on other regulated products. Third, a register of all AI systems in the deployer's environment with their classification, the version of the analysis, and the date of the last review.

The register is the operational artifact a regulator inspects first. A deployer that cannot produce a current AI register fails the Article 26 monitoring obligation independently of the substantive classification work.

DeepInspect

The classification work is the entry point. The infrastructure to satisfy the regime applies uniformly across both branches. DeepInspect sits as a stateless proxy between the application and the LLM. The proxy enforces identity-bound policies per request and produces per-decision audit records. The same proxy serves a branch-one medical-device deployment and a branch-two recruiting deployment.

For Article 6 classification, the operational consequence is that the AI register and the per-decision audit records connect. The register identifies which deployments are high-risk. The audit records produce the evidence that satisfies the obligations for those deployments. The deployer can move from classification to evidence to authority response without manual reconstruction.

If you have AI deployments that touch regulated products under Annex I or any of the eight Annex III categories, your Article 6 readiness is a documentation-and-evidence question.

Book a demo today.