Does NIS2 apply to AI vendors or only to entities using AI?

NIS2 applies to the essential and important entities in the 18 covered sectors. AI vendors are not directly captured unless the vendor itself qualifies as an essential or important entity under one of the sector definitions. Digital infrastructure providers and ICT service management providers are covered sectors, which captures cloud providers and some AI vendors directly. The financial entity, hospital, or utility using AI in covered operations has the primary obligation.

How does NIS2 interact with DORA?

DORA applies to financial entities and operates as lex specialis under DORA Article 1(2). Financial entities subject to DORA are exempt from the equivalent NIS2 obligations on the same subject matter. The exemption covers operational resilience and ICT risk management. Other NIS2 obligations not covered by DORA may still apply. The practical effect is that financial entities follow DORA for the operational risk management and follow the rest of NIS2 only where the directive covers ground DORA does not.

What incidents involving AI trigger NIS2 reporting?

NIS2 reporting triggers when an incident has caused or is capable of causing severe operational disruption or financial loss, or has affected other persons by causing considerable damage. For AI-involved incidents, examples include unauthorized disclosure of personal data through AI prompts, AI vendor outages that disrupt covered services, manipulation of AI outputs producing financial harm, and supply chain attacks reaching the AI infrastructure. The classification depends on the actual or potential impact, not on the AI involvement per se.

How do management body liability provisions work in practice?

Article 20 of NIS2 makes the management body responsible for approving cybersecurity risk management measures, overseeing implementation, and undergoing training. Member State law specifies the personal liability scheme. In Germany, the BSI-Gesetz transposing NIS2 makes management body members personally liable for serious infringements. Other Member States have similar provisions. The practical effect is that the management body's review of AI risk management measures should be documented, with the operational evidence supporting the review.

Do small entities fall under NIS2?

Most small entities are excluded. Article 2 size thresholds capture medium and large entities in critical sectors and important sectors. Article 2(2) extends the directive to some small entities operating in specific high-criticality areas, including DNS service providers, top-level domain name registries, qualified trust service providers, and a few other categories. Small entities outside those specific categories sit outside direct NIS2 capture. They often face NIS2-equivalent obligations indirectly through procurement requirements from covered entities.

NIS2 AI Requirements: How the Directive Captures AI-Driven Operations

The NIS2 Directive (EU 2022/2555) had to be transposed into Member State law by October 17, 2024, with the obligations taking effect on October 18, 2024. NIS2 covers essential and important entities across 18 sectors including energy, transport, banking, financial market infrastructures, healthcare, drinking water, wastewater, digital infrastructure, ICT service management, public administration, space, postal and courier services, waste management, manufacture of chemicals, food production, manufacture of medical devices, manufacture of motor vehicles, and digital providers. AI workloads supporting operations in those sectors fall under Article 21 cybersecurity risk management measures and Article 23 incident reporting. The competent authority will expect operational evidence, not just policy alignment.

I want to walk through how NIS2 captures AI usage, what Article 21 and Article 23 require at the request layer, and what records the competent authority asks for during an inspection.

How NIS2 captures AI usage

NIS2 applies to essential entities and important entities. The size thresholds at Article 2 capture most medium and large entities in the 18 sectors. Essential entities are large entities in critical sectors. Important entities are medium-sized entities in critical sectors and entities of any size in important sectors.

AI workloads enter scope when the workload supports an operation that NIS2 covers. A bank using AI for transaction monitoring falls under the directive because banking is an essential sector and transaction monitoring is part of the entity's core operation. A hospital using AI for clinical decision support falls under the directive because healthcare is an essential sector. A water utility using AI for demand forecasting falls under the directive because drinking water is an essential sector.

The directive does not regulate AI specifically. It regulates the entities operating in the covered sectors. AI is one technology category the entities use to deliver the covered services. The Article 21 risk management measures and Article 23 incident reporting obligations apply to the entire ICT estate of the entity, with AI as one component.

Article 21 risk management measures

Article 21 lists 10 minimum measures the essential and important entities have to implement. The list covers policies on risk analysis and information system security, incident handling, business continuity, supply chain security, security in network and information systems acquisition development and maintenance, policies and procedures to assess the effectiveness of cybersecurity risk-management measures, basic cyber hygiene practices and cybersecurity training, policies and procedures regarding the use of cryptography and encryption, human resources security, access control policies and asset management, and the use of multi-factor authentication or continuous authentication solutions where appropriate.

For AI deployments, the measures with operational weight at the request layer are the access control policies under measure (i), the multi-factor authentication requirement under measure (j), the supply chain security under measure (d), and the incident handling under measure (b).

Access control for AI means deciding which workforce members or automated agents can submit which categories of data to which AI vendors. The policy lives in the entity's documentation. The enforcement has to live at the request boundary or the policy fails the operational test.

Supply chain security for AI means treating the AI vendor as part of the entity's ICT supply chain. The vendor's own cybersecurity posture, the vendor's subprocessor relationships, and the vendor's incident reporting commitments all enter the supply chain security assessment.

Incident handling for AI means producing the operational evidence that supports the Article 23 reporting timeline.

Article 23 incident reporting

Article 23 sets the incident reporting obligations. Significant incidents trigger reporting to the competent CSIRT or the competent authority. A significant incident is one that has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned, or one that has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.

The reporting timeline runs in three stages. The early warning is due within 24 hours of becoming aware of the significant incident. The incident notification is due within 72 hours of becoming aware. The final report is due within one month of submitting the incident notification. The intermediate report is due on request from the competent authority or the CSIRT.

For AI-involved incidents, the 24-hour clock raises a visibility problem. The entity has to become aware of the incident before the clock starts. AI workloads that operate without prompt-level visibility extend the awareness interval beyond 24 hours, which itself can be evidence of inadequate Article 21 risk management.

The information that goes into the early warning includes an initial assessment of the suspected cause of the incident, the geographic spread, and any cross-border impact. The 72-hour notification adds an updated assessment, a description of the impact, and information about the type of threat or root cause. The final report covers a detailed description, the threat type, the mitigation measures applied, and the cross-border impact assessment.

What the competent authority inspection requests

NIS2 Article 32 gives competent authorities power to conduct on-site inspections and off-site supervision. The inspection covers compliance with the Article 21 risk management measures and Article 23 incident reporting obligations. The competent authority can request access to data, documents, and information.

For AI usage, the inspection typically requests the entity's AI inventory aligned to the covered services, the risk management documentation covering each AI workload, the access control policies and the records of access decisions, the supply chain assessments for the AI vendors, the incident handling procedures with the AI-specific runbooks, and the operational logs covering AI activity during the inspection window.

The operational logs are the part most entities struggle with. The logs need to show who submitted which AI request, for what purpose, with what data classification, and what the outcome was. Application logs that record the API call without the upstream context fail the inspection.

Penalties under NIS2

Article 34 sets the penalty regime. Essential entities face administrative fines of up to €10 million or 2% of total worldwide annual turnover, whichever is higher. Important entities face administrative fines of up to €7 million or 1.4% of total worldwide annual turnover, whichever is higher.

Member States have transposed the directive into national law with their own penalty schemes. Germany, France, Italy, Spain, the Netherlands, and the rest of the EU each operate enforcement through national competent authorities. The penalty exposure is material across the EU operating footprint.

NIS2 also creates personal liability for management bodies under Article 20. Members of the management bodies of essential and important entities have to approve the cybersecurity risk-management measures, oversee their implementation, and follow training. Member States can hold the management body personally liable for infringement of the obligations.

Overlap with DORA, EU AI Act, and GDPR

NIS2 sits alongside several other EU regimes that produce overlapping evidence requirements for AI deployments.

DORA applies to financial entities and largely supersedes NIS2 for those entities through the lex specialis principle established in DORA Article 1(2). A bank running AI for transaction monitoring falls under DORA, not NIS2, for the same operational risk management. The evidence requirements are similar.

The EU AI Act applies to high-risk AI systems under Annex III. NIS2 entities running high-risk AI face both regimes. Article 12 record-keeping under the AI Act and Article 21 risk management under NIS2 both require operational records at the AI request layer. The same record format can satisfy both.

GDPR applies when AI workloads process personal data. NIS2 entities processing personal data through AI face GDPR Articles 5, 6, 24, and 30 obligations alongside NIS2 Article 21 risk management. The accounting-of-disclosures obligation under GDPR aligns with the NIS2 audit trail expectation.

The record set that survives a NIS2 inspection

The records that support Article 21 access control measures, Article 23 incident reporting timelines, and Article 32 inspection requests share a common format. Per AI request, the record contains: the workforce member or agent identity, the role and access policy that authorized the request, the data classification of the prompt, the AI vendor and model called, the policy version, the decision outcome, and the timestamp.

The records have to be available within 24 hours of an awareness event to feed the early warning under Article 23. The records have to be queryable by identity, time range, vendor, and data classification to support both incident response and routine inspection requests. The records have to be tamper-evident to satisfy the integrity expectations the competent authority sets.

Application logs do not produce records at this resolution. The architecture that produces them runs at the AI request boundary, independent of the application that made the request.

DeepInspect

This is the architecture DeepInspect was built to provide. DeepInspect sits at the AI request boundary as a stateless proxy between authenticated users and agents and any LLM endpoint. Per-route policies enforce identity, data classification, AI vendor selection, and retention scope for every request. Every decision produces a signed audit record covering identity, role, classification, vendor selected, policy version, decision outcome, and timestamp.

The records support NIS2 Article 21 risk management evidence, Article 23 incident reporting timelines, and Article 32 inspection responses. The same records carry DORA register data for financial entities, EU AI Act Article 12 record-keeping for high-risk systems, and GDPR accounting-of-disclosures requirements for personal data processed through AI.

If you are a NIS2 essential or important entity running AI on operations the directive covers and your evidence depends on application logs, the inspection will surface the gap. Book a demo today.