NIS2 and running AI: the second regulation that applies to you

NIS2 is the revised EU directive on network and information security. Compared with its predecessor it considerably widens the circle of affected organizations and distinguishes two categories:

• “Essential” entities — such as energy, transport, banking, health, digital infrastructure.
• “Important” entities — including parts of manufacturing, postal and courier services, food, chemicals, research, digital providers.

Whether an organization is covered depends on sector and size. The circle reaches well beyond classic critical-infrastructure operators — many mid-sized companies fall under it for the first time. Transposition into national law was scheduled across Europe for autumn 2024; the concrete shape is set by the member states.

NIS2 does not require vague “efforts”, but a concrete catalogue of technical and organizational measures. Particularly relevant for running AI, among them:

• Risk analysis and information-system security policies.
• Handling of security incidents (detection, response, recovery).
• Business continuity — backup, emergency management, crisis response.
• Supply-chain security, including relationships with service providers.
• Access control, policies for the use of cryptography and, where appropriate, multi-factor authentication.
• Measures to assess effectiveness — security must be verifiable, not just asserted.

From a NIS2 perspective, an AI service in someone else’s cloud is two things: an additional dependency in the supply chain and an extension of your attack surface into which you have only limited insight. If the service fails, the provider changes the terms, or it is itself compromised, you carry the risk — without holding the control the directive demands. And because AI requests process sensitive content, the AI service quickly becomes one of the most protection-worthy elements of your architecture.

A central element of NIS2 is staged reporting duties for significant incidents — with tight deadlines:

• An initial early warning must be submitted without undue delay, at the latest within 24 hours of becoming aware.
• A more detailed notification typically follows within 72 hours.
• A final report is usually to be submitted within one month.

These deadlines assume you can detect and reconstruct an incident at all. Without continuous logging across the whole AI stack that is hardly feasible — and at a foreign system boundary your visibility ends.

Perhaps the sharpest lever of NIS2: responsibility lies explicitly with the management level. Management and boards must approve the risk-management measures, oversee their implementation, and can be held personally accountable for breaches. Training duties are also foreseen. Cybersecurity is therefore not something that can be fully delegated to IT — and running an uncontrolled AI service becomes a question the management level has to be able to answer.

Running in your own security zone brings exactly the control NIS2 demands — and maps point by point onto the catalogue of measures:

• Access control via SSO and RBAC, enforced server-side — directly onto the required access and authentication measures.
• A complete audit trail — the basis for incident detection, reconstruction and timely reporting.
• A reduced supply chain: the AI service is yours, not a third party’s — less external dependency, less attack surface.
• Operational control: no dependence on the availability of an external AI service; emergency and recovery plans apply in-house.

NIS2 and the EU AI Act address different goals — cybersecurity here, AI governance there — but they require overlapping capabilities: access control, traceability, audit, operational control. Set up your AI stack sovereignly once, and you feed into both at the same time. A complete audit trail, for instance, is at once evidence for the AI documentation and the basis for an incident report. Double regulation does not necessarily mean double effort — if the architecture is right.