NIS2 and AI Systems: Compliance in Germany

The legal frame in Germany

Germany put NIS2 into law through the NIS2 Implementation and Cybersecurity Strengthening Act (NIS2UmsuCG). The revised BSI Act has been in force since December 2025. It applies to "important" and "essential" entities in the sectors the directive lists. Whether a company is in scope depends on its industry, headcount and turnover. As a result, many mid-sized companies now fall under cybersecurity law for the first time. Often they have not yet checked whether they are in scope.

The key point: NIS2 does not ask whether a system is "AI". Once a company is in scope, the duties cover each system it needs to deliver its services. That includes, for example:

• a chatbot for customer service
• a ticket system that uses an LLM
• computer vision in quality control
• an AI agent with access to the ERP

All of these fall under the risk management rules of Section 30 of the revised BSIG (Art. 21 NIS2). This is why NIS2 compliance for AI systems matters.

Where AI systems meet NIS2 duties

The baseline measures in Art. 21 NIS2 apply directly to AI. Pay close attention to these areas:

• Risk analysis and security policies: AI brings its own attack surface. Examples are prompt injection, data leaks through model outputs, poisoned training data or AI agents with too many rights. The OWASP Top 10 for LLM Applications and MITRE ATLAS work well as checklists for threat analysis.
• Supply chain security: Most companies use AI as a cloud service. Or they build on pre-trained models and open-source libraries. So AI API providers, model repositories and integration partners are suppliers in the NIS2 sense. You need to assess them and bind them by contract.
• Security when you buy, build and maintain systems: This covers patching flaws in AI frameworks and checking model files before you deploy them. It also covers a controlled change process when you update models or system prompts.
• Access control and identities: AI apps use service accounts and API keys to reach data. These are privileged identities. Give them only the rights they need, rotate them and monitor them. Admins of AI platforms must use multi-factor authentication.
• Incident handling: Your incident response plans should cover AI cases. One case is an agent that takes unwanted actions because someone fed it tampered input. Another is a hacked model repository.
• Training and cyber hygiene: Staff need to know which data they may enter into AI tools and which they may not. Uncontrolled use of outside AI services ("shadow AI") is a common path for data leaks.

Reporting AI incidents

You must report significant incidents to the BSI in three stages:

1. an early warning within 24 hours
2. an incident notification within 72 hours
3. a final report within one month

This also applies when the cause lies in an AI system. One example: confidential customer data leaks through a prompt injection flaw. Another: an AI agent disrupts production systems. To meet these deadlines, you must log your AI apps and connect them to security monitoring. Without logs of prompts, tool calls and data access, you can neither detect nor assess an incident.

Management duties

Section 38 BSIG says management must approve the risk management measures, oversee how they are put in place and take part in training on a regular basis. Breaches can lead to personal liability. For AI, this means: putting AI systems to work with access to critical data or processes is a decision for management. Write the decision down and base it on risk. Do not leave it to a single department.

Practical steps

1. Confirm scope: Check whether your company falls under the BSIG. Register with the BSI if you have to.
2. Build an AI inventory: List all AI apps, built-in AI services and agents. Note the data they access and the providers behind them.
3. Add AI to the risk assessment: Assess AI threats within your current ISMS. Do not set up a second system next to it.
4. Assess suppliers: Ask AI providers how they process data, which security certifications they hold and how they report incidents.
5. Limit rights: Give AI service accounts and agents only the rights they need, every time.
6. Adapt monitoring and reporting: Feed AI logs into your SIEM. Add AI cases to the reporting process.
7. Keep evidence: Write down decisions, measures and training. Then you can answer BSI requests.

How NIS2 relates to the EU AI Act

The EU AI Act (Regulation (EU) 2024/1689) and NIS2 apply side by side. The AI Act sets rules for AI systems by risk category. NIS2 governs the cybersecurity of the entity as a whole. For high-risk AI, the AI Act requires robustness and cybersecurity, among other things. If you extend your NIS2 measures to AI in the right way, you build a solid base for both laws. A single management system avoids writing the same documents twice. One example is ISO/IEC 27001 combined with ISO/IEC 42001.

Conclusion

NIS2 does not create rules just for AI. But it makes AI systems a firm part of the security duties set by law. Do not treat AI as a side project. Build it into your risk assessment, supplier management and incident response. That is the core of NIS2 compliance for AI systems. SecTepe helps you check whether you are in scope and build AI into your current ISMS.

Frequently asked questions

Does NIS2 regulate the use of AI directly?

No. NIS2 has no rules just for AI. AI systems fall under the general risk management of the entity.

Do you have to report an incident with an AI chatbot?

Yes, if the incident is significant. That is the case, for example, when confidential data leaks or services are disrupted. Then the same reporting deadlines apply as for any other security incident.

Is it enough to pick a certified AI provider?

No. The company stays responsible for risk management. A provider's certification is useful evidence when you assess suppliers. But it does not replace your own review of settings, rights and data flows.