Guides

AI Act Guide · 11 min

The EU AI Act: risk tiers, the timeline, and what deployers must do (Article 26)

The EU AI Act is the world's first comprehensive law for artificial intelligence. It classifies AI systems by risk and puts most of the heavy obligations on high-risk systems, but it also places concrete duties on the organisations that use AI, not only those that build it. It is already in force and applies in phases through 2027. This guide explains the risk tiers, the dates that matter, the deployer obligations under Article 26, and what it means when you procure or deploy AI in your supply chain.

Key takeaways

  • The AI Act (Regulation (EU) 2024/1689) classifies AI by risk: prohibited, high-risk, limited (transparency) and minimal.
  • Phased dates: in force 1 August 2024; prohibited practices from 2 February 2025; general-purpose AI from 2 August 2025; high-risk and most obligations from 2 August 2026.
  • If you use a high-risk AI system, you're a “deployer” with your own duties under Article 26 (human oversight, monitoring, logs and more) even though the provider carries the bulk of the build-side obligations.

What the AI Act is

The AI Act (Regulation (EU) 2024/1689) is a risk-based, product-style regulation for AI systems placed on the EU market or whose output is used in the EU. Because it's a regulation, it applies directly across all member states. It assigns duties along the value chain: chiefly to providers (who develop AI) and deployers (who use it under their own authority), with lighter roles for importers and distributors.

Rather than regulating “AI” uniformly, it sorts systems into risk tiers and scales the obligations accordingly: a handful of practices are banned outright, a defined set of high-risk uses carry heavy requirements, some systems need only transparency, and the vast majority (minimal-risk AI) carry essentially none.

Where the duties are

Prohibited practices (banned), high-risk systems (the heavy obligations, e.g. AI used in employment, credit, critical infrastructure or biometrics), and limited-risk systems that require transparency (e.g. telling users they're interacting with AI or that content is AI-generated).

Minimal risk (most AI)

The large majority of AI systems (spam filters, recommendation engines, most productivity tools) fall into minimal risk and carry no specific obligations under the Act, beyond voluntary codes and a general AI-literacy expectation.

The timeline

The Act applies in phases. The dates that drive planning:

1 Aug 2024

Entered into force. The clock starts; obligations phase in from here.

2 Feb 2025

Prohibited practices apply: “unacceptable risk” AI (e.g. social scoring, certain manipulative or biometric-categorisation uses) is banned. AI-literacy duties also begin.

2 Aug 2025

Obligations for general-purpose AI (GPAI) models begin, alongside governance structures and the national competent authorities.

2 Aug 2026

The main event: obligations for high-risk systems (including deployer duties under Article 26) apply.

2 Aug 2027

Extended deadline for high-risk AI that is a safety component of products already regulated under other EU law (Annex I).

What deployers must do (Article 26)

If you use a high-risk AI system under your own authority, Article 26 places operational duties on you. In summary, a deployer must:

  • Use the system in line with the provider's instructions for use.
  • Assign human oversight to competent, trained and adequately resourced people who can intervene in or override its operation.
  • Monitor the system's operation, and suspend use and inform the provider and authorities where it presents a risk or a serious incident occurs.
  • Keep the automatically generated logs for an appropriate period: at least six months, unless other law requires longer.
  • Ensure input data is relevant and sufficiently representative for the intended purpose, to the extent you control it.
  • Inform workers and their representatives before putting a high-risk system into use in the workplace, and inform individuals subject to its decisions.
  • Carry out a fundamental-rights impact assessment where required (Art. 27), and cooperate with the competent authorities.

How it fits with NIS2 and the GDPR

The AI Act doesn't replace your other obligations. It stacks on them. An AI system that processes personal data is still governed by the GDPR (and may need a data-protection impact assessment alongside the AI Act's fundamental-rights one). An AI system that's part of your essential-service operations still falls under NIS2's security and incident-reporting duties. The three overlap rather than supersede.

For procurement, that convergence is the practical point. When you bring an AI system into your supply chain, you inherit deployer duties (Art. 26) and you need to know the provider's compliance posture: conformity, instructions for use, logging, the system's risk class. That's the same vendor-due-diligence muscle NIS2 already asks you to build, pointed at AI.

AI-system classification (especially the high-risk boundary and the GPAI rules) is detailed and fact-specific, and implementing acts and standards are still landing. Confirm a specific system's class and your role with qualified advice and the official text.

What it means for you

Your duties depend on your role with the system:

A provider (you develop or substantially modify an AI system)

You carry the build-side obligations: risk management, data governance, technical documentation, conformity assessment and CE marking for high-risk systems. Largely from 2 August 2026.

A deployer (you use AI under your own authority)

Article 26 applies for high-risk systems: human oversight, monitoring, logs, worker information and a fundamental-rights assessment where required. Build this now for the 2 August 2026 date.

An importer or distributor

You may only make compliant high-risk systems available, must verify the provider's conformity and CE marking, and must act when you learn a system is non-compliant.

A buyer procuring AI for your supply chain

You're typically the deployer. Require the provider's instructions, risk class, conformity status and logging capability, and treat AI vendors as part of your NIS2 supplier due diligence.

Sources: Regulation (EU) 2024/1689 (AI Act) and the European Commission's AI Act pages. Dates, tiers and roles reflect the published regulation; confirm a specific system's classification with qualified advice.

How norppa.io helps

norppa.io won't make an AI system AI-Act compliant (that's the provider's and deployer's job) but it gives you visibility into the AI exposure in your supply chain, which is where deployer due diligence starts. Its scanning surfaces AI service endpoints, exposed model and inference APIs, and AI-related interfaces (including Model Context Protocol endpoints) across your suppliers' attack surface.

Self-assessment questionnaires capture what no external scan can see (which AI systems a supplier deploys, their risk class, conformity status and human-oversight arrangements) and each answer is set against the live technical profile, ready for your supplier file. It's the same continuous, evidence-backed approach NIS2 expects, extended to the AI your suppliers run.

See your suppliers' AI exposure

See a sample supplier report (findings, evidence and article mapping) in about two minutes.

View sample report

Related guides

How to comply with NIS2: a step-by-step roadmap

The steps to NIS2 compliance in order: confirm scope, register, management accountability (Art. 20), the Article 21(2) measures, supply-chain security, incident reporting (Art. 23) and continuous, evidenced assurance.

Who is in scope for NIS2? Essential vs important entities, sectors and size thresholds

Determine whether NIS2 applies to you: the two tiers, the Annex I/II sectors, the size thresholds, size-independent exceptions, and how the supply chain pulls you in even if you're not designated.

NIS2 and the supply chain requirement: what it means in practice

NIS2 requires significant and important entities to assess their supply chain cyber risks. Supplier tiering, 4th-party risk, Art. 23 notification, and what auditors look for.

Supplier cyber risk assessment: what automated NIS2 monitoring checks

All check categories explained: ransomware, dark web leaks, TLS/DNSSEC, cookie security, CVE/EPSS, sanctions, MX blacklists and SAQ. Finding lifecycle and NIS2 article mapping.

NIS2 Art. 21(2): supplier security checklist

Checklist for procurement and security teams: what to ask, what evidence to collect, and how to respond when a supplier falls short. Includes suggested evidence documents.

NIS2 supplier questionnaire (SAQ): what to ask, how to score it, and a free template

What to ask suppliers under Art. 21(2)(d), how to score answers and respond to gaps, why self-attestation needs verification, and a free copy-paste questionnaire template.

NIS2 incident reporting: the 24- and 72-hour deadlines explained

What counts as a significant incident, the Article 23 timeline (24-hour early warning, 72-hour notification, one-month final report), and when a supplier's incident becomes your obligation.

NIS2 and management responsibility: what boards and leadership must know

What NIS2 expects of the management body: approval and oversight duties, personal liability (Art. 20), training, board reporting KPIs, and the penalties under Art. 34.

ISO 27001 and NIS2: what your ISMS already covers, and the gaps it doesn't

If you hold ISO 27001, what carries over to NIS2 and what does not: statutory incident reporting, management liability, registration, and continuous supply-chain assurance: plus how to close the gap.

NIS2 vs DORA: how they differ, where they overlap, and which one applies to you

How the two EU regimes differ and overlap, why DORA is lex specialis for financial entities, which applies to you, and what both mean for third-party and supply-chain risk.

GDPR vs NIS2: how they overlap, where they differ, and when one incident triggers both

How GDPR and NIS2 differ and overlap, when one incident triggers both (GDPR Art. 33 72h to the DPA vs NIS2 Art. 23 24h/72h/1-month to the CSIRT), the Art. 35 cooperation and no-double-fine rule, and what both mean for supplier due diligence.

The EU Cyber Resilience Act (CRA): scope, timeline and what it means for your supply chain

What the CRA requires, its phased dates (in force 2024, reporting Sept 2026, full compliance Dec 2027), who is in scope and why pure SaaS often isn't, how it complements NIS2, and what it means for procurement and supplier due diligence.