The AI blind spot in NIS2 compliance programmes

When the Network and Information Security Directive 2 (NIS2) Directive (EU) 2022/2555 entered into force at EU level on 16 January 2023, with member states required to transpose it into national law by 17 October 2024 and Germany transposing it with the new BSI Act in force since 6 December 2025, most enterprises in Germany, Austria and Switzerland focused their compliance efforts on traditional network perimeter security, endpoint protection, and incident reporting workflows. Yet a critical dimension remains systematically overlooked: the cybersecurity and resilience requirements that NIS2 places on every network and information system of an essential or important entity, AI systems included.

NIS2's broad definition of network and information systems encompasses AI systems when they support essential or important services, requiring the same cybersecurity risk management as other critical components. For the entities now classified as either essential or important under NIS2's expanded scope, this means that machine learning models, automated decision systems, and AI-dependent processes require the same rigorous cybersecurity risk management, supply chain oversight, and incident response capabilities as any other critical system component.

Many enterprises in critical sectors have deployed AI systems in production environments, yet a significant proportion have not explicitly incorporated these systems into their NIS2 compliance frameworks. This gap creates substantial regulatory risk, particularly as national supervisory authorities begin enforcement actions and maximum fines of at least €10 million or 2 per cent of worldwide annual turnover, whichever is higher, for essential entities, and €7 million or 1.4 per cent for important entities; in Germany up to €10 million or 2 per cent (§ 65 BSIG).

Supply chain risk management extends to model provenance

Third-party AI models as critical suppliers represent perhaps the most immediate compliance challenge under NIS2 Article 21(2)(d), which requires supply chain security, including the security aspects of the relationship with direct suppliers and service providers. When enterprises deploy foundation models from providers such as OpenAI, Anthropic, or Cohere, or use pre-trained models from repositories like Hugging Face, they introduce third-party dependencies that must be assessed and monitored according to NIS2's supply chain risk requirements.

The directive explicitly requires entities to identify and document all suppliers of security-relevant services and products, assess their cybersecurity practices, and implement contractual arrangements that ensure adequate security levels throughout the supply chain. For AI systems, this translates into specific obligations around model provenance tracking: the ability to document the origin, training data sources, fine-tuning history, and update lineage of every model deployed in production environments.

A large energy technology company implementing NIS2 compliance might discover that establishing model provenance for their predictive maintenance AI systems requires implementing a model registry with cryptographic signing, version control integration, and automated dependency scanning. Such assessments often reveal that a substantial proportion of deployed models rely on open-source components with unclear training data lineage, necessitating comprehensive audits and, in several cases, model replacement to meet NIS2's supply chain transparency requirements.

Contractual security requirements for AI service providers must address specific technical and organisational measures. NIS2-compliant contracts need provisions covering model security testing, vulnerability disclosure procedures, incident notification timelines (the directive requires an early warning within 24 hours of becoming aware of a significant incident, a notification within 72 hours and a final report within a month), and the right to audit security controls. To meet the supply chain measure in Article 21(2)(d), contracts with AI providers can include commitments on data residency, model isolation between customers, and the ability to retrieve or delete training data upon request.

AI system failures as reportable security incidents

Incident detection and reporting obligations under NIS2 Article 23 create new monitoring requirements for AI systems. The directive defines incidents broadly as events that compromise the availability, authenticity, integrity, or confidentiality of stored, transmitted, or processed data or related services. For AI systems, this definition encompasses not only traditional cybersecurity events like unauthorised access or data exfiltration, but also AI-specific failure modes including model degradation, adversarial attacks, data poisoning, and unexpected behavioural changes that affect service delivery.

An AI failure is reportable under Article 23 when it is a significant incident: when it causes, or can cause, severe operational disruption or financial loss, or considerable damage to others.

Monitoring AI systems as security telemetry demands capabilities beyond traditional application performance monitoring. NIS2 compliance requires detecting anomalous AI behaviour that might indicate security compromise or system degradation. A major European reinsurer implemented continuous model monitoring for their catastrophe modelling AI systems, tracking prediction drift, confidence score distributions, feature importance shifts, and inference latency as security-relevant metrics. Their security operations centre now correlates AI system telemetry with network security events, treating unexpected model behaviour changes as potential indicators of compromise requiring investigation.

The technical challenge lies in distinguishing legitimate model adaptation from malicious manipulation or degradation requiring incident reporting. Research institutions are developing frameworks in collaboration with national critical infrastructure operators that establish baseline behavioural envelopes for AI systems and trigger security reviews when systems operate outside defined parameters. These approaches have identified genuine security incidents including cases of training data manipulation and instances of adversarial input attempts.

Resilience requirements demand degradation paths

Business continuity and disaster recovery obligations under NIS2 Article 21 require entities to ensure the continuity of critical functions during and after incidents. For AI-dependent processes, this creates architectural requirements that many current implementations fail to meet. The directive's emphasis on resilience means that critical services cannot simply fail when AI systems become unavailable: enterprises must design and test degradation paths that maintain essential functionality through alternative means.

A rail operator might redesign its AI-powered route optimisation system to meet NIS2 resilience requirements, implementing a three-tier degradation architecture. Under normal operation, deep learning models provide optimal routing considering real-time traffic, weather, and demand patterns. When AI system availability drops below defined thresholds, the system automatically falls back to simpler heuristic algorithms that provide acceptable routing using cached data. If both AI and heuristic systems fail, manual routing protocols activate with pre-calculated backup routes. Testing that architecture as part of the NIS2 work would show whether operation continues during a complete AI system failure.

Backup and restoration capabilities for AI systems present technical challenges distinct from traditional data backup. Models themselves require versioned backups, but effective restoration demands preserving the entire operational context including training data snapshots, hyperparameter configurations, feature engineering pipelines, and calibration data. Critical infrastructure operators should maintain the ability to restore AI systems to known-good states within recovery time objectives defined by business impact analysis.

Architecting AI systems for NIS2 compliance

Model governance frameworks must address NIS2's risk management requirements through formal processes for AI system approval, deployment, monitoring, and decommissioning. The directive mandates that entities implement policies and procedures for risk analysis and information system security, which for AI systems must encompass unique risks including adversarial attacks, model inversion, membership inference, and training data extraction.

A large insurance group might implement a model risk committee structure that evaluates all AI systems against NIS2 requirements before production deployment. Such an assessment framework would examine supply chain provenance, security testing results, monitoring capabilities, degradation paths, incident response procedures, and business continuity integration. Systems failing to meet defined criteria cannot enter production, and deployed systems undergo quarterly compliance reviews. This governance structure can prevent deployment of AI systems that lack adequate security controls, while identifying compliance gaps in existing systems requiring remediation.

Security testing specific to AI systems must become standard practice under NIS2's requirement to assess the effectiveness of cybersecurity risk-management measures (Article 21(2)(f)). Traditional penetration testing and vulnerability scanning provide insufficient coverage for AI-specific attack vectors. Research institutions are developing AI security testing protocols that include adversarial robustness testing, model extraction attempts, training data reconstruction attacks, and backdoor detection, providing practical frameworks for NIS2-compliant security assessment of AI systems deployed in critical infrastructure.

Your NIS2 AI compliance readiness diagnostic

The intersection of NIS2 requirements and AI system architecture demands immediate attention from enterprises in regulated sectors. Compliance obligations around supply chain risk management, incident detection and reporting, and resilience requirements fundamentally reshape how AI systems must be designed, deployed, and operated. Enterprises that treat AI systems as exempt from NIS2's cybersecurity framework face both regulatory penalties and operational risks as supervisory authorities increase enforcement activities.

Remote Native's NIS2 AI Compliance Diagnostic provides a structured assessment of your AI systems against directive requirements, identifying gaps in model provenance tracking, security monitoring, incident response integration, and resilience architecture. Our practitioners work with your security, compliance, and AI teams to map your current AI landscape to NIS2 obligations, prioritise remediation activities, and develop implementation roadmaps that address regulatory requirements while maintaining AI system performance and business value.

Start your NIS2 AI compliance diagnostic →

Article based on NIS2 Directive (EU) 2022/2555, ENISA NIS2 implementation guidance, BSI AI security frameworks, and documented compliance implementations across Germany, Austria and Switzerland critical infrastructure operators.

Legal status as of 13 October 2026. This article is not legal advice.