EU AI Act vs NIS2: Differences and Dual Compliance

An organisation that runs AI inside an essential service can owe one incident to two regulators, on two clocks, under two different definitions of what went wrong. The EU AI Act (Regulation (EU) 2024/1689) regulates AI systems as products: it puts duties on providers and deployers of specific systems, including a cybersecurity requirement in Article 15 and serious incident reporting in Article 73. NIS2 (Directive (EU) 2022/2555) regulates entities: it requires risk-management measures across all of an organisation's network and information systems and reporting of significant incidents under Article 23. This guide compares Article 15 with Article 21, serious with significant incidents, supply chain duties and dual coverage, then shows one control set for both. It is for CISOs, GRC leads and AI platform owners in critical sectors. Status checked on EUR-Lex on 13 November 2026.

Key takeaways

Different targets, shared ground. The AI Act attaches duties to an AI system and the role you play for it; NIS2 attaches duties to your organisation and every system it relies on, AI included.
Article 15 is narrower and deeper than Article 21. Article 15(5) covers one high-risk system and names AI-specific attacks such as data poisoning and adversarial examples; Article 21(2) covers the whole entity with ten measures from risk analysis to multi-factor authentication.
The incident tests differ. NIS2 asks whether an incident significantly disrupts your services (24 hours, 72 hours, one month). The AI Act asks whether an AI system's incident or malfunction led to harm such as serious and irreversible disruption of critical infrastructure (2, 10 or 15 days). One event can meet both.
Critical infrastructure is the overlap zone. Annex III point 2 makes AI safety components in critical digital infrastructure, road traffic, water, gas, heating and electricity high-risk, and those operators are usually NIS2 entities too.
Build one control set with two evidence views. Asset inventory, supplier assurance, logging, vulnerability handling and incident triage can serve both laws if each record carries the AI system, the service it supports and the role you hold.

The short answer

NIS2 is an organisation-wide cybersecurity law for entities in 18 sectors. It does not mention AI in its articles; recitals 51 and 89 only encourage the use of AI and machine learning to improve detection and capability. The AI Act is a product safety and fundamental rights law for AI systems and general-purpose AI models, with cybersecurity as one of several requirements for high-risk systems. If you are an essential or important entity, NIS2 already covers your AI estate because AI runs on network and information systems. If an AI system you provide or deploy is high-risk, the AI Act adds system-level duties on top. See the EU AI Act Compliance Guide.

Question	EU AI Act	NIS2
Legal form	Regulation, directly applicable	Directive, applied through national transposition laws
What it regulates	AI systems and general-purpose AI models, by risk class	Entities in Annex I and II sectors, by size and type
Who holds the duty	Providers, deployers, importers, distributors (role per system)	The essential or important entity and its management body
Security requirement	Article 15: accuracy, robustness and cybersecurity of a high-risk system, including resilience to AI-specific attacks	Article 21: appropriate and proportionate measures across all network and information systems, minimum list (a) to (j)
Incident trigger	Serious incident, Article 3(49): death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of fundamental rights obligations, serious harm to property or the environment	Significant incident, Article 23(3): severe operational disruption or financial loss, or considerable material or non-material damage to others
Reporting clock	Not later than 15 days; 2 days for widespread infringement or critical infrastructure disruption; 10 days for a death (Article 73)	Early warning 24 hours, notification 72 hours, final report one month after notification (Article 23(4))
Maximum fines	Up to EUR 15 million or 3% for most operator obligations; EUR 35 million or 7% for prohibited practices (Article 99)	At least EUR 10 million or 2% (essential) and EUR 7 million or 1.4% (important) as the maximum national ceiling (Article 34)

Where each law applies today

NIS2 has been the law to plan against since 18 October 2024, subject to each Member State's transposition (track it in the NIS2 Transposition Tracker). The AI Act has a staged timetable in Article 113: prohibitions and general provisions from 2 February 2025, general-purpose AI and governance chapters from 2 August 2025, and general application from 2 August 2026.

High-risk dates moved: Regulation (EU) 2026/1744, the Digital Omnibus on AI, dated 8 July 2026 and in force since 27 July 2026 according to EUR-Lex, defers the Chapter III high-risk obligations. White and Case's summary gives 2 December 2027 for Annex III stand-alone systems and 2 August 2028 for Annex I product components, and notes that the deferral is limited to Chapter III.
NIS2 is unchanged by it: the AI Omnibus does not amend NIS2. Separate proposals to amend NIS2 are still proposals; see the NIS2 Amending Directive Proposal 2026.
Article 73 timing: serious incident reporting sits in Chapter IX but attaches to high-risk systems, so confirm with counsel when it applies to your system class; the EU AI Act Implementation Timeline Tracker follows the dates.

Article 15 against Article 21: two security requirements

Article 21 asks whether the entity manages risk across everything it runs. Article 15 asks whether one high-risk AI system performs consistently and resists manipulation. The EU AI Act Article 15 Guide covers Article 15 paragraph by paragraph; this section only shows how the two map.

Threat model of each

NIS2 threat model: anything that compromises "the availability, authenticity, integrity or confidentiality" of data or services (Article 6(6)), on an all-hazards basis. AI is one more asset class.
AI Act threat model: unauthorised third parties trying "to alter their use, outputs or performance by exploiting system vulnerabilities" (Article 15(5)), with named AI-specific classes: data poisoning, model poisoning, adversarial examples or model evasion, confidentiality attacks and model flaws. Robustness in Article 15(4) adds accidental errors, faults and feedback loops.

NIS2 Article 21(2) measure	What it means for an AI system	AI Act provision that adds to it
(a) Risk analysis and information system security policies	AI systems appear in the entity risk register with owner, service supported and data handled	Article 9 risk management system per high-risk system; Article 15(1) levels set by it
(b) Incident handling	Playbooks cover model compromise, prompt injection and data poisoning as incident types	Article 73 serious incident investigation; Article 26(5) deployer escalation
(c) Business continuity and crisis management	Fallback when a model or inference endpoint fails or is withdrawn	Article 15(4) redundancy, backup and fail-safe plans
(d) Supply chain security	Model providers, AI APIs and dataset suppliers on the critical supplier list	Article 25 value chain duties; Article 13 instructions for use
(e) Acquisition, development, maintenance, vulnerability handling	Model and dependency vulnerability intake, patching of serving stacks	Article 15(5) AI-specific vulnerability measures; CRA Article 12 where the system is a product with digital elements
(f) Assessing effectiveness	Control testing includes AI red teaming	Article 9 testing against predefined metrics; Article 72 post-market monitoring
(g) Cyber hygiene and training	Staff know how to report AI misbehaviour	Article 4 AI literacy
(h) Cryptography	Encryption of training data and weights	Confidentiality attacks named in Article 15(5)
(i) HR security, access control, asset management	Least privilege on training data stores, model registries and inference keys; AI assets in the inventory	Article 15(5) resistance to unauthorised alteration; Article 12 logging
(j) Multi-factor or continuous authentication	MFA on model registry, MLOps consoles and cloud AI control planes	No direct equivalent; supports Article 15(5)

Where each requirement fails on its own

NIS2 alone misses AI-specific attacks: a conventional penetration test, patch cycle and MFA rollout can satisfy an Article 21 auditor while a poisoned fine-tuning set or an evasion attack goes untested. Article 15(5) is what forces those tests.
Article 15 alone misses the platform: the deployer's hosting, identity, network and supplier controls are not part of the provider's declaration, and they are exactly what Article 21 audits.
Presumptions are partial: Article 42(2) presumes compliance with the Article 15 cybersecurity requirements for systems certified under a scheme adopted under Regulation (EU) 2019/881, "in so far as" the certificate covers them. Cyber Resilience Act Article 12(1) deems products with digital elements that meet the CRA essential requirements compliant with Article 15 cybersecurity requirements, without prejudice to accuracy and robustness. Neither presumption says anything about NIS2 Article 21. See the EU Cyber Resilience Act Guide.

Serious incident versus significant incident

The definitions measure different harms, the clocks start at different moments, and the reports go to different authorities: the national CSIRT or competent authority for NIS2, the market surveillance authority where the incident occurred for the AI Act.

Feature	AI Act Article 73	NIS2 Article 23
Who reports	The provider; a deployer that identifies a serious incident informs the provider first, then the importer or distributor and the market surveillance authority (Article 26(5))	The essential or important entity
Trigger	An incident or malfunction of an AI system that directly or indirectly leads to a harm listed in Article 3(49)	Significant impact on service provision under Article 23(3), plus objective thresholds in Implementing Regulation (EU) 2024/2690 for digital providers
Clock starts	Awareness by the provider or deployer; report immediately once a causal link is established or reasonably likely	When the entity becomes aware of the significant incident
Deadlines	Not later than 15 days; not later than 2 days for a widespread infringement or a critical infrastructure disruption under 3(49)(b); not later than 10 days for a death. An initial incomplete report is allowed (Article 73(5))	Early warning within 24 hours, incident notification within 72 hours, final report not later than one month after the notification; progress report if still ongoing
After reporting	Investigate, assess risk and correct, without altering the system in a way that affects cause analysis before informing authorities (Article 73(6))	Intermediate reports on request; root cause and mitigation in the final report
Carve-out	For Annex III systems placed by providers already subject to equivalent Union reporting obligations, notification is limited to fundamental rights infringements under 3(49)(c) (Article 73(9))	Sector-specific acts with equivalent requirements take precedence (Article 4(1), recital 23)

When only NIS2 fires: ransomware stops the inference cluster for a day. That is significant, but no Article 3(49) harm follows unless the outage causes one.
When only the AI Act fires: a high-risk recruitment system systematically breaches equal treatment obligations: a 3(49)(c) serious incident with no service disruption.
When both fire: a manipulated AI safety component in an electricity distribution system causes a serious and irreversible disruption. NIS2 needs an early warning within 24 hours and Article 73(3) a report within 2 days.
Read Article 73(9) carefully: whether NIS2 counts as an "equivalent" reporting instrument for your Annex III system is a legal question. The Commission's draft Article 73 guidance, published for consultation on 26 September 2025, addresses interplay with other regimes; Hunton's summary says it names the CER Directive, NIS2 and DORA. Until final guidance is confirmed, plan to report under both.

Supply chain: value chain duties and supplier security

NIS2 Article 21(3) makes the entity consider "the vulnerabilities specific to each direct supplier and service provider". The AI Act allocates duties along the value chain, and Article 25 governs when a deployer or other party becomes a provider, for example by substantially modifying a high-risk system.

Model and API suppliers are NIS2 suppliers: put general-purpose model providers, hosted AI APIs, vector database services and data labelling firms on the critical supplier list with the same assessment as any ICT provider. See the NIS2 Supply Chain Security Guide.
Ask for the AI Act artefacts: for a high-risk system, request the declared accuracy metrics and known limits (Article 13), the EU declaration of conformity, and how the provider handles Article 15(5) attacks.
Write incident flow into contracts: the provider must hear from you immediately under Article 26(5), and you must hear from the provider fast enough to meet a 24-hour NIS2 early warning.
Watch role changes: fine-tuning or changing the intended purpose of a third-party system can make you the provider, with Article 15 and Article 73 duties you did not budget for. See the EU AI Act Provider vs Deployer Obligations Guide.

Who is caught by both

Organisation profile	NIS2 position	AI Act position	Practical consequence
Energy, water or district heating operator using AI as a safety component in grid or network operation	Annex I entity, often essential	Deployer (or provider if built in-house) of an Annex III point 2 high-risk system	Both reporting regimes; Article 15 evidence from the provider
Cloud, data centre or managed service provider hosting customers' AI	Annex I digital infrastructure or ICT service management; Implementing Regulation 2024/2690 applies	Usually not a provider or deployer of customers' systems	NIS2 duties for the platform; AI Act duties only for its own AI services
Hospital or health provider deploying AI triage or diagnostic tools	Annex I health entity	Deployer of high-risk systems (Annex I medical devices or Annex III uses)	Article 73(10) limits reporting for medical device AI to 3(49)(c); NIS2 reporting unchanged
Manufacturer in an Annex II sector embedding AI in products	Annex II important entity	Provider of AI in Annex I regulated products	Article 15 for the product, Article 21 for the factory and development environment, CRA for products with digital elements
Bank or insurer using AI for credit scoring	Annex I banking, with DORA as the sector act	Deployer of an Annex III high-risk system	DORA replaces NIS2 Article 21 and 23 duties; AI Act duties remain

Worked scenario: a poisoned forecasting model at a water utility

A water utility, an essential entity under its national NIS2 law, deploys a third-party AI system as a safety component that adjusts treatment dosing from sensor data. An attacker with a stolen pipeline credential alters retraining data, and the system under-doses in one district for six hours.

Triage (hour 0 to 4): unauthorised access to the training data store is confirmed and the service was disrupted, so the NIS2 significance test is met. The AI system's malfunction led to disruption of critical infrastructure; legal decides whether it is "serious and irreversible" under 3(49)(b).
NIS2 early warning (by hour 24): to the CSIRT, stating suspected malicious action and possible cross-border impact.
Deployer escalation (immediately): under Article 26(5) the utility informs the provider, then the market surveillance authority. It preserves the model version, training data snapshot and logs, and does not retrain before the authorities are informed (Article 73(6)).
AI Act report (within 2 days if 3(49)(b) applies): the provider files with the market surveillance authority; an initial incomplete report is acceptable.
NIS2 notification (by hour 72) and final report (one month later): root cause is a long-lived pipeline credential with write access to training data, an Article 21(2)(i) and Article 15(5) failure at the same time.
Corrective action: short-lived workload credentials, separated read and write identities on the data store, dataset hashing before retraining, and a supplier review of the provider's poisoning tests.

One control set, two evidence views

Run a single programme and tag evidence so it answers both auditors. These steps are NHI Mgmt Group recommendations, not text from either law.

Inventory AI per legal entity: for every AI system record the NIS2 entity and service it supports, the AI Act risk class and your role (provider, deployer or both). Start with Annex III point 2 systems.
Extend the Article 21 risk register: add AI threat classes from Article 15(5), mapped to MITRE ATLAS techniques such as AML.T0020 Training Data Poisoning, AML.T0018 Manipulate AI Model, AML.T0015 Evade AI Model and AML.T0051 LLM Prompt Injection.
Merge incident classification: one triage form that asks both questions: significant impact on services (NIS2) and AI system involvement with an Article 3(49) harm (AI Act). Pre-fill authority contacts for the CSIRT and the market surveillance authority.
Exercise both clocks: a tabletop that runs the 24-hour, 2-day, 72-hour and 15-day deadlines together, including the provider hand-off.
Unify supplier assurance: one questionnaire for AI suppliers covering NIS2 Article 21(3) and the provider's Article 15 and Article 73 commitments.
Pilot, then scale: run the merged process on one high-risk system for a quarter and keep the old playbooks as rollback until it has handled a real or simulated incident cleanly.

Where identity fits

The identity controls in NIS2 Article 21(2)(i) and (j) are the cheapest way to cut Article 15(5) risk. Pipeline accounts, registry tokens and inference API keys are non-human identities: give each an owner, one function, a short life and logging. See the Agentic AI Identity Guide for AI agents that act inside these systems.

Detection, measurement and framework mapping

Log for both: write access to training data and model registries, model promotions, inference anomalies and agent tool calls serve Article 12 record keeping and NIS2 incident handling alike.
Metrics: share of AI systems with an assigned NIS2 service and AI Act role; time from detection to the joint triage decision; share of AI suppliers with incident notification clauses in hours; share of high-risk systems with a current AI red team result; number of long-lived credentials with write access to training data.

Control area	NIST CSF 2.0	NIST SP 800-53 Rev 5	ISO/IEC 27001:2022 Annex A
Legal and regulatory requirements	GV.OC-03	PM-9	5.31
Supplier requirements in contracts	GV.SC-05	SR-6	5.20
Incident analysis and notification	DE.AE-02, RS.CO-02	IR-6	5.24, 5.26
Logging and monitoring of AI assets	DE.CM	AU-2, SI-4	8.15, 8.16
Least privilege on AI pipelines	PR.AA-05	AC-6	8.2, 5.15

Common failure patterns

Treating AI as out of NIS2 scope: NIS2 has no AI carve-out; an inference cluster is a network and information system like any other.
Waiting for Article 73 clarity: the NIS2 24-hour clock does not wait, so design the dual path now.
Retraining before preserving evidence: fixing a poisoned model quickly can destroy what Article 73(6) requires you to keep for cause analysis.
Weak machine credentials in production: in the WorkOS Breach 2026 an AI agent that escaped its test environment reached an internal API that accepted a development credential deployed to production.

Decision checklist

Is the legal entity an essential or important entity, or covered by a sector act such as DORA instead?
Does it provide or deploy any AI system listed in Annex III, especially point 2 critical infrastructure?
For each such system, who is the provider, and have you changed it enough to become one?
Can your triage reach a decision on both incident tests within 24 hours?
Do AI supplier contracts deliver incident notice fast enough for your NIS2 early warning?

Practitioner checklist

Map every AI system to its NIS2 entity, service, AI Act risk class and your role.
Add Article 15(5) attack classes to the Article 21 risk register and test plan.
Build one incident triage form with both the NIS2 significance test and the Article 3(49) harms.
Preserve model versions, training data snapshots and logs before any corrective retraining.
Put AI model, API and data suppliers on the critical supplier list with hour-level notification clauses.
Replace long-lived pipeline and registry credentials with scoped, short-lived workload identities.
Run a tabletop exercise that times the 24-hour, 2-day, 72-hour and 15-day deadlines together.

Standards and references

Related NHI Mgmt Group resources: NIS2 Directive Guide · EU AI Act Article 15 Guide · DORA and NIS2 Overlap Mapping Guide · EU AI Act High-Risk AI Systems Guide. This guide summarises the EU AI Act and the NIS2 Directive as of 13 November 2026 and is not legal advice.

EU AI Act vs NIS2: How They Differ and How to Comply With Both