What is an EU AI Act high-risk system?

The AI Act applies a use-case-based classification. An AI system is high-risk if it is intended to be used as a safety component of a product covered by EU harmonisation legislation listed in Annex I, OR if its intended use falls into one of the categories listed in Annex III: biometrics, critical infrastructure, education and vocational training, employment, access to essential services, law enforcement, migration/asylum/border control, administration of justice.

For cyber security: an AI system that "is intended to be used as a safety component in the management and operation of critical digital infrastructure" falls within Annex III(2) and is therefore high-risk by default. This pulls in autonomous offensive tooling deployed against critical infrastructure operators.

A high-risk system requires:

• Art. 9 risk management system — continuous, documented, covering the full lifecycle.
• Art. 10 data governance — training/validation/test data quality, bias evaluation, traceability.
• Art. 11 technical documentation — capability description, system architecture, training methodology, performance metrics, known limitations.
• Art. 12 logging — automatic logging of events relevant to risk and to post-market monitoring.
• Art. 13 transparency — operating instructions sufficient for the deployer to use the system responsibly.
• Art. 14 human oversight — meaningful human-in-the-loop, kill-switch, capacity to override.
• Art. 15 accuracy, robustness, cybersecurity — declared, measurable, tested.
• Art. 17 quality management system — for the provider.
• Art. 72 post-market monitoring — incident reporting, performance tracking.

In practice, all of these need to exist as written artefacts, not as informal practices.

The Act distinguishes between providers (those who put the system on the market) and deployers (those who use it under their own authority).

• Providers carry the bulk of the technical-documentation, risk-management and conformity-assessment burden.
• Deployers are responsible for using the system in line with the instructions, maintaining meaningful human oversight, monitoring operation, and reporting serious incidents.

If you procure an AI security tool, you become its deployer. Procurement due-diligence should now include reviewing the provider's Article 11 technical documentation, the Article 14 oversight mechanisms, and the Article 15 accuracy/robustness/cybersecurity declarations.

Two practical shifts:

1. Procurement asks for the AI Act technical documentation as a baseline. Vendors that cannot produce it are increasingly disqualified before commercial evaluation.

1. Deployer-side internal controls must demonstrate meaningful human oversight (kill-switch, audit trail of override events) and serious-incident reporting capability. This is documentation-heavy and tends to surface during the first internal audit cycle.

The practical implication: AI security tooling that exposes per-action signed evidence, a kill-switch on every campaign, and post-market telemetry hooks is procurement-friendly. Tooling that is opaque is increasingly hard to deploy in an AI Act-aware org.