NIS2 is the EU's broad cybersecurity directive, the successor to NIS1 with a much wider net. Member states were due to transpose it into national law by 17 October 2024, and it covers essential and important entities across sectors from energy, health and transport to digital infrastructure, manufacturing, and public administration. If your organisation is in scope, the security of the systems you run, increasingly including your AI systems, is now a regulated matter with management-level accountability.

The obligations, in one paragraph

In-scope entities must take “appropriate and proportionate” technical and organisational measures across a familiar checklist: risk analysis, incident handling, business continuity, supply-chain security, secure development and configuration, vulnerability handling, cryptography policies, access control and MFA. Add to that a strict incident-reporting clock (early warning within 24 hours of a significant incident, incident notification within 72) and personal responsibility for management bodies, and you have the shape of the regime. Penalties scale to €10M or 2% of global turnover for essential entities.

Why your AI deployment is part of this

Nothing in NIS2 says “artificial intelligence”. It doesn't need to. The directive regulates the network and information systems you rely on, and the moment an assistant is drafting your documents, answering questions over your files, or wired into your workflows via an API, it has become one of those systems. Three consequences follow:

  • It joins your risk analysis. What data can the AI system reach? Who can query it? What happens if it's compromised or unavailable? These now need documented answers.
  • It joins your supply chain review. NIS2 makes you responsible for the security of your suppliers and service providers. Every external AI service is another supplier to assess, contract with, and monitor.
  • It joins your incident scope. A breach involving the AI layer, leaked prompts, exfiltrated documents, a poisoned model, is an incident like any other, with the same 24/72-hour clocks.

The supply-chain angle favours shorter chains

Here is the practical observation: every obligation above gets easier when the chain is shorter. A cloud AI dependency means your NIS2 supply-chain duties extend through the vendor and their sub-processors; your incident response depends on their disclosure speed; your continuity planning inherits their outages. A self-hosted deployment turns that external dependency into an internal system, still in scope, still needing hardening and monitoring, but assessed and evidenced by you, on your timeline.

This is not “on-prem is automatically compliant”, a badly run appliance is worse than a well-run cloud service. The point is narrower: NIS2 rewards architectures whose security you can inspect and evidence directly. Sealed perimeter, immutable audit log, SIEM export and controlled updates exist in Kaldryn precisely because that's what an auditor asks for.

If you're starting now

  1. Confirm whether you're in scope (sector + size, in your member state's transposition, in Sweden, via the new cybersecurity act implementing NIS2).
  2. Add AI systems explicitly to your asset inventory and risk analysis, shadow AI included.
  3. Map your AI supply chain: every external model API, plugin and integration is a supplier.
  4. Rehearse the 24-hour early warning with an AI-flavoured scenario once, you'll find the gaps quickly.