The EU AI Act and NIS2: Risk Tiers and Cyber Baselines

The EU Artificial Intelligence Act (Regulation 2024/1689) and the NIS2 Directive (Directive 2022/2555) solve different problems that often land on the same organisation. The AI Act is product law: it governs how AI systems are built, placed on the market, and used, sorting them by the risk they pose to health, safety, and fundamental rights. NIS2 is cybersecurity law: it raises the security baseline for organisations running essential and important services.

They overlap by design. The AI Act demands cybersecurity for high-risk AI as one obligation among many; NIS2 imposes a horizontal security duty on the whole entity. A hospital deploying a diagnostic AI can be a high-risk deployer under the AI Act and an essential entity under NIS2 at the same time.

The AI Act does not regulate technology uniformly. It regulates risk, and slots every system into one of four tiers. The tier decides the obligations, not the algorithm.

Most AI systems (spam filters, game AI, inventory forecasting) fall into minimal risk and carry no obligations under the Act. The regulatory weight concentrates on the top two tiers. Getting classification right is the first compliance task: it is what determines whether you owe nothing, a disclosure, or a full conformity regime.

The AI Act's risk pyramid: each tier attaches a distinct level of obligation.

The top tier is not a compliance regime but a prohibition. Certain uses are judged incompatible with EU values and may not be placed on the market or used at all. The banned categories include:

• Social scoring by or on behalf of public authorities that leads to detrimental treatment.
• Manipulative or deceptive techniques that materially distort behaviour and cause harm.
• Exploiting vulnerabilities of age, disability, or economic situation.
• Certain biometric categorisation inferring sensitive traits, and untargeted scraping of facial images to build recognition databases.
• Real-time remote biometric identification in public spaces for law enforcement, save for narrow, authorised exceptions.

These are absolute limits. No documentation, oversight, or assessment can make a prohibited practice lawful. Screening a use case against this list is the first gate before any other analysis begins.

High-risk is where the heavy machinery of the Act lives, and a system reaches it by two routes.

Route A - Annex III uses. The system operates in a listed sensitive domain: biometrics, critical infrastructure, education, employment and worker management, access to essential private and public services, law enforcement, migration and border control, and administration of justice and democratic processes.

Route B - safety components. The AI is a safety component of a product already covered by EU product-safety law (machinery, medical devices, toys, vehicles), or is itself such a product requiring third-party conformity assessment.

A CV-screening tool for hiring is high-risk via Route A. An AI braking module in a car is high-risk via Route B. Either route triggers the same obligation set, examined next.

For a high-risk system the provider (the entity that develops it and puts it on the market under its name) must build a structured compliance programme before and after launch:

1. A risk-management system running across the lifecycle.
2. Data governance for training, validation, and testing sets (relevance, representativeness, error controls).
3. Technical documentation and automatic record-keeping (logging) for traceability.
4. Transparency and instructions enabling deployers to use the system correctly.
5. Human oversight designed into the system.
6. Appropriate accuracy, robustness, and cybersecurity.

The provider then runs a conformity assessment, affixes the CE marking, draws up an EU declaration of conformity, and registers the system in the EU database before market entry. These are the entry conditions, not optional add-ons.

The Act binds different actors differently. Confusing the two is a common compliance error.

The provider builds and markets the system. The deployer uses it under its own authority in a professional context.

Providers carry the design-time burden: the conformity regime above. Deployers carry use-time duties: follow the provider's instructions, ensure input data is relevant, maintain human oversight, monitor operation, keep logs, and inform the provider and authorities of serious incidents or risks. In some settings deployers must also run a fundamental-rights impact assessment.

Crucially, a deployer can become a provider. Putting your name on a high-risk system, or making a substantial modification to it, transfers the full provider obligations to you. The label follows the conduct, not the contract.

General-purpose AI (GPAI) models get their own track, layered on top of the risk tiers. Every GPAI provider owes baseline transparency and documentation: technical files for downstream integrators, information for the AI Office, a policy to respect EU copyright, and a public summary of training content.

A GPAI model with systemic risk (identified by very high capability, using training-compute thresholds as a signal) owes more: model evaluation including adversarial testing, systemic-risk assessment and mitigation, serious-incident reporting, and adequate cybersecurity for the model and its weights.

Below high-risk sits limited risk: pure transparency. A chatbot must disclose it is AI; providers must mark synthetic audio, image, video, and text as artificially generated; and deployers must label deepfakes. Minimal risk carries no obligations at all.

Enforcement is split. At Union level, the AI Office oversees GPAI models and supports coherent application. In each Member State, national market-surveillance authorities police high-risk systems and prohibited practices on the ground.

The fine ceilings are tiered to the severity of the breach:

• Prohibited practices: up to EUR 35 million or 7% of total worldwide annual turnover, whichever is higher.
• Most other breaches (e.g. high-risk obligations): up to EUR 15 million or 3%.
• Supplying incorrect or misleading information to authorities: up to EUR 7.5 million or 1%.

The percentage-of-turnover mechanic mirrors data-protection law: it scales the deterrent to the size of the operator, so the ceiling bites on large and small entities alike.

NIS2 widens the EU's cybersecurity net far beyond its predecessor. It works through a sectoral scope plus a size filter.

Entities are sorted into two classes. Essential entities sit in high-criticality sectors (energy, transport, banking, financial-market infrastructure, health, drinking and waste water, digital infrastructure, public administration, space). Important entities sit in other critical sectors (postal, waste management, chemicals, food, manufacturing, digital providers, research).

The general rule is a size threshold: the regime applies to medium-sized and larger entities in these sectors. But some entities are in scope regardless of size, for example certain DNS and TLD operators, and providers whose disruption would have significant systemic effect. The class you fall into sets not your core duties, which are shared, but the supervision you face.

Article 21 sets the substantive baseline: an all-hazards, risk-based set of technical and organisational measures, proportionate to the entity's exposure. The named minimum includes risk-analysis and security policies, incident handling, business continuity and backup, supply-chain security, security in acquisition and development, policies to assess effectiveness, cyber hygiene and training, cryptography and encryption, access control and asset management, and multi-factor authentication.

Accountability is pushed upward. The entity's management body must approve the risk-management measures and oversee their implementation, and members can be held liable for failures; they are also required to undergo training. Supervision differs by class: essential entities face proactive, ex-ante scrutiny (audits, inspections), while important entities face lighter, mainly ex-post supervision triggered by evidence of a problem.

NIS2 imposes a staged reporting duty for any incident with a significant impact, running against the moment the entity becomes aware of it. The clock has three checkpoints:

An intermediate status update can be requested in between. This staged model is deliberate: the 24-hour early warning triggers a fast response even on thin information, while detail is filled in as the picture clarifies. Because a serious cyber incident affecting a high-risk AI system can trigger both this NIS2 clock and AI Act serious-incident reporting, in-scope operators should map their obligations once and build a single, unified response process.