Does NIS2 mention AI or model APIs directly?

The directive is written around cybersecurity risk-management measures rather than specific technologies, so it does not enumerate AI or model APIs by name. Its access-control, logging, and monitoring requirements apply to your systems and the data moving through them, which includes the traffic your staff and applications send to models. The lack of an explicit AI clause does not create an exemption; it means the general measures extend to the AI path in the same way they extend to any other access channel.

Which organizations does NIS2 apply to?

NIS2 applies to entities the directive classifies as essential or important across a set of sectors it defines, with national transposition determining the precise scope in each member state. If your organization falls in scope, the risk-management measures and the supervisory expectations apply to your whole security posture, and AI access is part of that posture. The determination of scope is a legal question for your jurisdiction, but where the directive applies at all, it applies to the model path as well.

How is NIS2 different from the EU AI Act for logging?

They come at logging from different angles. The AI Act sets record-keeping obligations tied to specific AI systems and their risk classification. NIS2 sets general cybersecurity measures, including access control and logging, that apply to your systems broadly. For AI traffic, the two point at the same practical control: an identity-bound, per-decision record of model access. Building that record once tends to serve both, because both are asking, in their own vocabulary, for evidence of who accessed what under which policy.

What does "demonstrate compliance" mean in practice for AI?

It means being able to produce, on request, evidence that your stated measures are actually in force. For AI access, that is a set of records showing that model calls are authenticated to named identities, governed by policy, and logged, plus the policy definitions themselves. A statement that AI use is covered by policy is not evidence; the per-decision records are. Designing the AI path so those records exist by default is what makes the demonstration straightforward rather than a scramble.

Where should AI logging sit relative to our SIEM?

The enforcement point produces the per-decision records at the AI request layer, and those records can then feed your SIEM alongside the rest of your monitoring. The value of generating them at the request layer is that they carry identity, policy, and data classification that a network-level view of the same traffic would lack. Feeding that enriched record into the SIEM gives your monitoring and your NIS2 evidence the same source of truth for AI access.

NIS2 and AI Logging: Where the Directive Meets Your Model Traffic

NIS2 is a directive, so its text lands on organizations through national transposition rather than as a single regulation. What it asks for is consistent across those national laws: essential and important entities have to run a set of cybersecurity risk-management measures, and they have to be able to show a competent authority that those measures are real. Access control policies, logging, and monitoring sit inside that set. AI added a surface those measures were never scoped to cover, where staff and applications send data to model APIs that the security program has not inventoried.

I want to walk through how NIS2's risk-management and logging expectations reach AI traffic, and what a model call has to leave behind to count as evidence when a supervisor asks.

What NIS2 actually asks of you

The directive's risk-management measures cover the ground you would expect from a modern security baseline: policies for access control, incident handling, monitoring and logging, supply-chain security, and an assessment of whether the measures work. Two features of NIS2 raise the stakes on evidence specifically. Supervision is active, so authorities can ask entities to demonstrate compliance rather than wait for an incident. And accountability reaches management, so the question of whether controls are provably in place is not only a technical one.

For AI, the relevant piece is that access control and logging are named measures. If a category of access to your data exists and is neither controlled nor logged, that is a gap in exactly the area the directive enumerates.

The AI access surface most programs missed

A model call is an access event. An employee sending a document to a chat assistant, or a service sending records to a model API, is moving data across a boundary. Three habits keep that surface outside NIS2 coverage.

The traffic authenticates under a shared application key, so logs name a service rather than the person or agent behind the call. Monitoring watches inbound and internal systems, while outbound calls to model domains ride through an allowlist unexamined. And nothing classifies the content of the prompt, so a request carrying sensitive data looks identical to a benign one on the wire.

The result is a class of access to potentially sensitive data that the access-control and logging measures do not touch. Under a directive that expects those measures and lets a supervisor ask you to prove them, that is the gap worth closing first.

What a model call has to leave behind

To pull AI traffic inside your NIS2 evidence, each model call needs a record that a supervisor could inspect and an access decision that a policy governs. The record carries the identity behind the request, the role and authorization in effect, a classification of the data in the prompt, the policy decision applied, and a timestamp. It is produced independently of the application making the call, so it cannot be quietly skipped or edited by the system it documents.

My view is that AI traffic is now a first-class access channel, and treating it as an unlogged exception because it is new is the kind of gap NIS2 supervision exists to surface. The measures you already apply to other access paths are the ones the model path needs.

Logging demonstrates the control, enforcement is the control

NIS2 asks you to both run the measure and show it works. An access log demonstrates that model traffic is monitored. Acting on the prompt, by redacting or blocking a request that carries data it should not, is the access control itself. Because the enforcement point terminates the call and reads the body, both happen at one place: the decision governs the access, and the record proves it was governed. That pairing is what turns "we have a policy" into "here is the evidence the policy was applied."

DeepInspect

DeepInspect brings AI traffic under the same access-control and logging discipline NIS2 expects everywhere else. It runs as a stateless proxy between your applications, staff, agents, and any LLM, binds a named identity to each model call, applies per-route and per-role policy with detection and redaction of sensitive data in the prompt, and writes a tamper-evident per-decision record.

That record is the artifact a competent authority can inspect to see which AI interactions occurred, under which identity, and that a policy governed them. Committed before the model responds and produced independently of the calling application, it stands as evidence rather than as a log the application could rewrite. To map your AI access surface against your NIS2 measures, book a compliance mapping session.