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 enforcement beginning thereafter, most DACH enterprises 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 imposes specifically on artificial intelligence systems embedded within essential services and critical infrastructure.

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 approximately 160,000 entities across the EU, with estimates of 20,000-30,000 in Germany alone (exact numbers depend on national transposition), 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 penalties of up to €10 million or 2 per cent of global annual turnover for essential entities, with member states authorized to impose higher maximums (e.g., up to €20 million in Germany).

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, which mandates comprehensive supply chain security measures. 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 mandates initial notification within 24 hours of incident awareness), and the right to audit security controls. Under NIS2 Article 21, contracts with AI providers should include explicit 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 Articles 23 and 24 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.

NIS2's incident reporting framework requires that algorithmic failures in AI systems used for critical functions constitute reportable incidents when they materially impact service availability or integrity. This interpretation means that AI system malfunctions affecting essential services trigger the same incident reporting obligations as conventional system failures, requiring initial notification within 24 hours, detailed reporting within 72 hours, and final reports including root cause analysis.

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 major European rail operator redesigned their AI-powered route optimisation system to comply with 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. This architecture underwent formal testing as part of NIS2 compliance validation, demonstrating continued operation during 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. Cybersecurity authorities recommend that critical infrastructure operators 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 for regular security assessments. 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 DACH 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 throughout 2025.

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 DACH critical infrastructure operators.