Skip to main content

NIS2 Directive: AI Governance for Critical Infrastructure Cybersecurity

Directive (EU) 2022/2555, the NIS2 Directive, is also not an AI statute. It is a cybersecurity and resilience regime for essential and important entities. But the minute AI tools are used for incident triage, alert summarization, maintenance guidance, operator support, or external communications in critical sectors, they become part of the systems and supplier relationships that NIS2 expects organizations to secure. Keeptrusts is useful here because it places a governed boundary in front of the model call, so risky prompts, weak routing choices, and uncontrolled output delivery are not treated as ordinary application behavior.

Use this page when​

  • You operate in a sector covered by NIS2, such as energy, transport, health, digital infrastructure, or public administration.
  • You are adding AI assistants to security operations, operational technology support, or incident communications.
  • You need an implementation pattern that supports NIS2-style risk management without pretending the gateway alone satisfies the directive.

Primary audience​

  • Primary: Security engineers, SOC leads, platform engineers, compliance officers
  • Secondary: OT security teams, incident managers, resilience leads

The problem​

Critical infrastructure teams rarely start with a formal AI strategy. They start with urgency. A security analyst wants faster alert triage. An operations team wants an assistant to summarize maintenance notes. A crisis lead wants a draft incident update. Those are understandable use cases, but they create a fragile control surface if they bypass the same cybersecurity discipline applied to the rest of the environment.

NIS2 places strong emphasis on cybersecurity risk-management measures. Article 21 covers areas such as incident handling, business continuity, supply chain security, secure acquisition and maintenance of network and information systems, and policies to assess risk. AI changes each of those areas because it introduces a new path for sensitive operational context to leave the organization and a new source of machine-generated advice that people may act on too quickly.

The failure modes are familiar.

An incident responder pastes raw logs, credentials-adjacent text, or customer-linked identifiers into an assistant route that has no redaction guardrails. A user or attacker supplies a crafted prompt that tries to bypass instructions and elicit system details. A provider fallback path silently sends operational context to a target the security team never meant to approve. A generated summary is copied into an external status update without review because the assistant "usually gets it right."

None of those failures are uniquely about AI. They are governance failures at a new boundary. What NIS2 changes is the expectation that organizations should not leave that boundary unmanaged.

The solution​

The most defensible operating model is to split AI routes by operational purpose.

An internal note-cleanup route is not the same as an incident-communications route. A low-risk knowledge search flow is not the same as a workflow that drafts remediation instructions or outage notices. Keeptrusts gives you a way to encode those distinctions in policy instead of relying on training alone.

Start with prompt-injection to protect the request boundary. In operational environments, the risk is not only a classic jailbreak. It is also the accidental inclusion of hostile or misleading text from logs, tickets, or copied incident transcripts. The policy's normalization, boundary checks, and pattern matching help keep those payloads from steering the model in unintended ways.

Then use pii-detector when incident data or case notes may include personal data. NIS2 is about cybersecurity, not privacy alone, but personal data often appears in the same operational records. Redaction at the gateway boundary keeps privacy and resilience from becoming separate, conflicting workflows.

Next, constrain provider selection with data-routing-policy. That turns provider governance from an architecture slide into runtime behavior. If the route requires zero-data-retention or no-training declarations, providers that do not match are removed before normal routing occurs. That is especially useful for NIS2 because supply chain risk is not just about your contracts. It is also about what the system is technically allowed to use when under pressure.

For operationally sensitive output, use quality-scorer and, where needed, human-oversight. The scorer helps reject weak or incomplete drafts. The oversight policy gives you a deliberate stop when a route must never deliver assistant content directly. That is a good fit for incident communications, remediation recommendations, or crisis-management summaries that still need authorized human approval.

Implementation​

The example below shows a route used to draft incident briefings for a NIS2-scoped environment. It protects the request boundary, redacts route-specific identifiers, restricts providers, checks that the output includes a human-review note, and then escalates the result instead of delivering it directly.

pack:
  name: nis2-incident-briefing-route
  version: "1.0.0"
  enabled: true

providers:
  targets:
    - id: reviewed-secure-provider
      provider: openai
      model: gpt-5.4-mini-mini
      secret_key_ref:
        env: OPENAI_API_KEY
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0
        accepts_tokenized_input: true

policies:
  chain:
    - prompt-injection
    - pii-detector
    - data-routing-policy
    - quality-scorer
    - human-oversight
    - audit-logger

policy:
  prompt-injection:
    use_embedding: false
    detection:
      attack_patterns:
        - "ignore.*previous.*instructions"
        - "print.*hidden.*policy"
    encoding:
      decode_base64: true
      normalize_unicode: true
      detect_homoglyphs: true
    boundaries:
      enforce_delimiters: true
      reject_fake_boundaries: true

  pii-detector:
    action: redact
    detect_patterns:
      - 'INC-\\d{7}'
      - 'SITE-\\d{5}'
    redaction:
      marker_format: label
      include_metadata: true
      custom_markers:
        generic_id: "[REDACTED-OPS-ID]"

  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    tokenize_sensitive_fields: true
    on_no_compliant_provider: block
    log_provider_selection: true

  quality-scorer:
    min_output_chars: 100
    min_sentences: 3
    assertions:
      - type: contains
        name: requires-human-approval
        threshold: 1.0
        mode: enforce
        severity: critical
        config:
          value: "Do not execute or publish without authorized human review."

  human-oversight:
    action: escalate

  audit-logger: {}

This example is intentionally strict. It is suitable for a route where the assistant is generating a draft briefing or recommendation, not for a low-risk route that can safely return content directly. If you need a less restrictive path, remove human-oversight and keep the rest of the control chain for internal-only workflows. The point is not to make every route equally burdensome. It is to make the burden match the operational consequence.

From a documentation and control-mapping perspective, the best companion references remain EU AI Act Compliance, Configuration & Policy Overview, Data Routing Policy, Audit Logger, and the Compliance Officer Guide. Even though NIS2 is a different regime, those docs help keep the technical control descriptions accurate.

Results and impact​

The biggest advantage is that AI stops being an untracked exception inside the cybersecurity program. Instead of relying on a separate "AI acceptable use" memo, you can define which routes are allowed, which providers are eligible, whether sensitive content must be redacted, and whether a response can ever be delivered automatically.

That improves incident readiness. During a real event, teams do not have time to remember nuanced usage rules. A governed route is easier to trust because it removes bad choices under stress. It also improves post-incident review. When an auditor or internal review team asks how AI was used during an event, you can point to concrete route behavior rather than vague policy language.

There is also a supply chain benefit. NIS2 makes organizations think harder about dependencies, and AI providers are dependencies. data-routing-policy is valuable because it enforces the dependency decisions you say you have already made.

Key takeaways​

  • NIS2 does not regulate AI directly, but AI-assisted operational workflows still sit inside the cybersecurity risk perimeter.
  • prompt-injection is especially valuable for routes fed by tickets, logs, and copied operational text.
  • data-routing-policy helps turn supplier and data-handling decisions into actual runtime restrictions.
  • Use human-oversight when an AI route must produce a draft for review rather than a directly actionable answer.
  • Keeptrusts improves technical enforcement and evidence quality, but it does not replace incident reporting, network security, or business continuity controls required by NIS2.

Next steps​