NIS2 does not regulate AI as a technology, but it covers AI in practice. An AI system that an essential or important entity runs is part of its network and information systems, so the Article 21 risk measures, the Article 23 reporting deadlines of 24 hours, 72 hours and one month, and management accountability all apply to it, and AI vendors are assessed as suppliers.
What NIS2 requires of essential and important entities
The NIS2 Directive, Directive (EU) 2022/2555, applies to public and private entities of the types listed in its Annexes I and II that are at least medium-sized and operate in the EU, plus some entities regardless of size. The European Commission describes it as covering 18 critical sectors, including health, energy, transport and the public sector. Annex I entities above the medium-sized ceilings are essential entities; most others in scope are important entities. Member states had to transpose it by 17 October 2024 and apply their measures from 18 October 2024.
| Duty | Article | What it asks of the entity |
|---|---|---|
| Governance | Art. 20 | The management body approves the cybersecurity risk-management measures, oversees them and can be held liable for breaches; its members must follow training |
| Risk measures | Art. 21(1) and (2) | Appropriate and proportionate technical, operational and organisational measures, on an all-hazards basis, covering at least ten areas |
| Supply chain | Art. 21(2)(d) and 21(3) | Security in relationships with direct suppliers and service providers, weighing each supplier’s vulnerabilities, product quality and secure development |
| Reporting | Art. 23 | For significant incidents: early warning within 24 hours, notification within 72 hours, final report no later than one month after the notification |
| Fines | Art. 34 | For breaches of Art. 21 or 23, maximum fines of at least EUR 10 million or 2% of worldwide turnover (essential) and EUR 7 million or 1.4% (important), whichever is higher |
| Personal sanctions | Art. 32(5) | For essential entities, authorities can seek a temporary ban on the chief executive or legal representative exercising managerial functions |
Where AI systems sit inside NIS2
The Directive names artificial intelligence only twice, in recitals 51 and 89, and both times as a tool defenders may use to detect and prevent attacks, subject to data protection law. There is no AI article. What brings AI into scope is Article 21(1): the measures cover the network and information systems an entity uses for its operations or to provide its services. An assistant answering staff questions from internal documents, an agent that updates tickets, a model server on your GPUs, a vector index and the connectors between them all qualify. The table applies each of the ten minimum areas in Article 21(2) to them.
| Article 21(2) area | What it means for an AI system |
|---|---|
| (a) Risk analysis | Add each AI system to the risk analysis, with AI-specific threats: prompt injection, data leaking through answers, poisoned retrieval data, unsafe tool use |
| (b) Incident handling | Define what an AI incident looks like (an agent acting outside its permissions, confidential data in an answer, manipulated output) and route it through the normal process |
| (c) Business continuity | Decide what happens when an AI service or model provider is unavailable, and keep a manual or local fallback for critical workflows |
| (d) Supply chain | Assess AI vendors and model providers as direct suppliers (next section) |
| (e) Acquisition and maintenance | Patch inference runtimes and AI plug-ins, track model versions through change management, handle vulnerabilities in AI components |
| (f) Effectiveness | Include AI systems in security testing and red-team exercises, and keep the results |
| (g) Hygiene and training | Train staff on AI misuse, such as pasting credentials or acting on unchecked output |
| (h) Cryptography | Encrypt prompts, indexes and logs in transit and at rest |
| (i) Access and assets | Keep an AI inventory, give agents least-privilege service accounts and control who may use which agent |
| (j) Authentication | Put multi-factor authentication on AI admin consoles and on AI tools that reach sensitive data |
An AI incident has to be reported only if it is significant under Article 23(3): it has caused or could cause severe operational disruption or financial loss for the entity, or considerable material or non-material damage to others. If it is, the 24-hour, 72-hour and one-month clock applies to the CSIRT or competent authority. When the incident also involves personal data, a separate GDPR notification may be due, and Article 35 of NIS2 requires the competent authority to inform the data protection authority where an infringement may entail a personal data breach. A risk assessment for each AI system is the simplest way to show that point (a) covers AI.
AI vendors as a supply-chain risk
Article 21(3) asks entities to take into account the vulnerabilities specific to each direct supplier, the overall quality of its products and cybersecurity practices, and its secure development procedures. With AI the chain is longer than usual: the application vendor, the model provider behind it, the hosting or inference provider, their sub-processors, and the open-weight model files, plug-ins and MCP servers that arrive as components.
Implementing Regulation (EU) 2024/2690 of 17 October 2024 makes this concrete for DNS, cloud computing, data-centre, managed service and other digital providers. Its supply chain section asks them to select suppliers on their cybersecurity practices, their ability to meet the entity’s specifications, the quality and resilience of what they supply, and the entity’s ability to diversify sources and limit vendor lock-in. Contracts should then specify, where appropriate, security requirements, incident notification without undue delay, a right to audit or to receive audit reports, vulnerability handling, rules for subcontracting and duties at termination. ENISA published technical implementation guidance for these measures in June 2025. Other entities are not bound by that list, but it is a sound template for an AI contract. For AI, add questions on which model providers see your data, whether it trains models, how much notice you get before a model changes, and whether the workload could move to another model or run locally.
Some AI vendors are in scope themselves, for example as cloud computing or managed service providers listed in Annex I, so ask whether yours is registered as an essential or important entity and where. The 20-question vendor questionnaire in our template covers the rest.
NIS2 vs the AI Act
| NIS2, Directive (EU) 2022/2555 | AI Act, Regulation (EU) 2024/1689 | |
|---|---|---|
| Legal form | Directive, applied through national law | Regulation, applies directly |
| What it protects | Security of the network and information systems of essential and important entities | Health, safety and fundamental rights affected by AI systems and general-purpose AI models |
| Who carries duties | Entities in the listed sectors, by type and size | Providers, deployers, importers and distributors of AI systems; providers of general-purpose AI models |
| How risk is set | All-hazards, proportionate to exposure, size, likelihood and severity | Fixed classes: prohibited, high-risk (Annex I and Annex III), transparency duties, minimal |
| Security duty | Ten minimum areas of measures (Art. 21) | Accuracy, robustness and cybersecurity for high-risk AI, including data and model poisoning, adversarial examples and confidentiality attacks (Art. 15) |
| Incident reporting | Significant incidents: 24 hours, 72 hours, final report one month after notification | Serious incidents with high-risk AI: provider reports within 15 days, 10 days after a death, 2 days for a widespread infringement or serious and irreversible disruption of critical infrastructure (Art. 73) |
| Supply chain | Supplier security is part of the entity’s measures (Art. 21(2)(d)) | High-risk providers need written agreements with suppliers of tools, services and components (Art. 25(4)) |
| People | Management body approves, oversees and can be liable; training is mandatory (Art. 20) | Measures to support AI literacy (Art. 4); competent, trained human oversight for high-risk deployers (Art. 26(2)) |
| Maximum fines | At least EUR 10 million or 2% (essential), EUR 7 million or 1.4% (important) | Up to EUR 35 million or 7% for prohibited practices; EUR 15 million or 3% for most other duties; EUR 7.5 million or 1% for misleading information (Art. 99) |
| Dates | Applies since 18 October 2024 through national law | Prohibitions since 2 February 2025; Art. 50 since 2 August 2026; Annex III high-risk from 2 December 2027; Annex I from 2 August 2028 |
Critical infrastructure is where the two meet
Annex III point 2 of the AI Act makes AI high-risk when it is intended as a safety component in the management and operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating or electricity. The AI Act never cites NIS2: it defines critical infrastructure through the Critical Entities Resilience Directive, (EU) 2022/2557. Recital 55 adds that components intended solely for cybersecurity purposes do not count as safety components, so an AI tool that only detects intrusions is not high-risk on that ground. These systems are also exempt from the fundamental rights impact assessment in Article 27. For energy and utility operators, our NIS2 AI brief for critical infrastructure operators covers deployment inside segmented OT networks.
One incident, two or three clocks
An AI failure at an essential entity can be a significant incident under NIS2 and a serious incident under the AI Act at the same time. Under Article 26(5) of the AI Act, a deployer that identifies a serious incident must inform the provider immediately, and the provider reports to the market surveillance authority, while the NIS2 report goes to the CSIRT or competent authority. Add the GDPR’s 72-hour breach notice when personal data is involved, and keep one incident record that feeds all three.
The Cyber Resilience Act as a bridge
The Digital Omnibus on AI, Regulation (EU) 2026/1744, added Article 42(3) to the AI Act: high-risk AI systems within the scope of the Cyber Resilience Act that meet the conditions of its Article 12(1) are deemed to comply with the AI Act’s cybersecurity requirements. The Cyber Resilience Act’s reporting obligations for manufacturers have applied since 11 September 2026, and the rest of it applies from 11 December 2027, so ask vendors of AI products which route they follow.
Banks and insurers follow DORA
Article 4 of NIS2 gives way to sector-specific EU acts with at least equivalent requirements, and the Directive names DORA, Regulation (EU) 2022/2554, as that act for financial entities. For a bank or insurer, the ICT risk and incident rules for AI come from DORA.
NIS2 transposition status in October 2026
Most member states have transposed the Directive, but not all. The Commission sent letters of formal notice on 28 November 2024 and reasoned opinions on 7 May 2025, and on 8 July 2026 it referred Ireland, Spain, France and the Netherlands to the Court of Justice for failing to notify full transposition, asking the Court for a lump sum and daily penalties (verified October 2026). Thresholds, competent authorities, registration deadlines and penalties are set nationally and vary by member state, so check the law in each country where you operate.
On 20 January 2026 the Commission also proposed targeted amendments to NIS2, alongside a proposed new Cybersecurity Act, to increase legal clarity and simplify compliance. Until an amending directive is adopted and transposed, the 2022 text and the national laws based on it are what apply.
NIS2 AI checklist
- Every AI system, model server, vector index and AI connector is in the asset inventory with an owner (Art. 21(2)(i))
- AI-specific threats are in the risk analysis: prompt injection, data leakage, poisoning, unsafe tool use (a)
- The incident process defines AI incidents and maps them to NIS2 significance, AI Act serious incidents and GDPR breaches (b, Art. 23)
- Critical workflows have a fallback if an AI service or model provider is unavailable (c)
- Each AI vendor and model provider is assessed as a direct supplier, with incident notice, audit and exit terms in the contract (d)
- Model versions, inference runtimes and AI plug-ins go through patching and change management (e)
- AI systems are included in security testing and red-team exercises (f)
- Staff training covers AI misuse, and management body training covers AI risk (g, Art. 20(2))
- Prompts, indexes and logs are encrypted in transit and at rest (h)
- Agents run on least-privilege accounts with role-based access, and AI admin consoles require MFA (i, j)
- AI system logs reach the security operations team in time for a 24-hour early warning
- The management body has approved the measures that cover AI (Art. 20(1))
- The national law, competent authority and CSIRT are identified for each member state you operate in
For the reporting work itself, the NIS2 compliance and reporting use case shows how evidence from GRC, SIEM and ticketing systems can be gathered for notifications, and the AI incident response agent keeps an outage timeline current and drafts updates for approval, which is the raw material for the 72-hour notification and the final report.
How VDF AI fits
VDF AI runs assistants and agents inside your own perimeter, on-premises, in a private cloud or fully air-gapped, and network egress can be disabled. For those workloads no external inference provider joins your supplier list, and segmented or OT-adjacent zones keep their boundaries. Updates for air-gapped sites arrive as signed artifacts that your team inspects and installs from an internal registry.
Role-based access control is included on every plan, tools are granted per role through the MCP gateway registry, and consequential agent actions can wait for human approval. Every prompt, retrieval, model route, tool call, response and approval is logged with the actor and time and can stream to your SIEM, which supports detection, incident timelines and post-incident review. The trust center lists the evidence security reviewers usually request. These controls support your Article 21 measures; the measures, and the accountability for them, remain yours.
Sources
- NIS2 Directive, Directive (EU) 2022/2555, on EUR-Lex
- Implementing Regulation (EU) 2024/2690
- ENISA, NIS2 technical implementation guidance
- European Commission, NIS2 Directive policy page
- European Commission, referral of four member states, 8 July 2026
- European Commission, proposed targeted NIS2 amendments
- AI Act, Regulation (EU) 2024/1689, on EUR-Lex
- Digital Omnibus on AI, Regulation (EU) 2026/1744
- Cyber Resilience Act, Regulation (EU) 2024/2847