How does the Action Plan relate to the EU AI Act?

The AI Act sets obligations on providers and deployers of AI systems, including the Article 12 record-keeping requirement and the August 2, 2026 date for high-risk system obligations. The Action Plan is a cybersecurity strategy that sits alongside it, focused on the security properties of advanced models and on how access to advanced AI capability is controlled. The two converge on traceability. The AI Act requires that AI system activity be recorded so it can be reconstructed. The Action Plan's structured-access pillar requires that access to capability be controlled and conditioned. An identity-bound audit record at the AI request boundary satisfies both readings.

What is structured access in the Action Plan?

Structured access is the plan's term for controlled, conditioned, and recorded access to advanced AI capabilities, in contrast to open availability. At the model-provider layer it describes tiered release and gated capability. At the enterprise layer it translates into an authorization question: which identities inside your organization may call which models, with what data, under which policy, and what is the record of each of those decisions. The enterprise-side implementation is an identity-aware policy enforcement point in front of the model endpoints, producing a per-decision record.

Does NIS2 already cover AI systems?

NIS2 applies to essential and important entities across eighteen sectors and imposes risk-management, incident-reporting, and governance obligations on their network and information systems. An AI system running inside an in-scope entity is a network and information system, so NIS2 already reaches it. The Action Plan's contribution is to make the coupling explicit and to push AI-specific threat scenarios into the NIS2 risk-management expectation. For an enterprise, that means AI traffic belongs in the same incident-reporting and evidence pipeline as the rest of the estate.

What should a CISO do before the Action Plan's initiatives land?

Start recording. The controls the plan points at (identity binding, per-request authorization, independent audit records) take time to deploy and produce evidence only forward in time. A practical order: inventory which identities and services call which model endpoints, put an enforcement point in front of those endpoints so the calls carry identity, define policy per role and per data classification, and commit a signed decision record for every call. That sequence satisfies the EU AI Act's Article 12 traceability requirement today and positions the organization for the structured-access expectation the Action Plan describes.

The EU Action Plan on Cybersecurity and AI: Pre-Market Evaluation, Structured Access, and What Enterprises Must Evidence

On July 7, 2026 the European Commission presented its Action Plan on Cybersecurity and Artificial Intelligence. It is a strategy instrument rather than a binding deadline, which is exactly why most security teams will file it and move on. I want to argue against that. Read the pillars carefully and the plan tells you what the EU expects an organization running advanced AI to be able to show a regulator eighteen months from now, and most of that is evidence an enterprise cannot retroactively manufacture.

The pillars of the Action Plan

The Commission's factsheet sets out the initiatives the plan launches. Five of them matter to a deploying enterprise.

Pre-market evaluation of advanced AI models

The plan proposes that advanced models be evaluated for cybersecurity risk before they reach the market, rather than assessed after an incident forces the question. The evaluation obligation lands on model providers. The consequence for deployers is that the model you buy will arrive with an evaluation dossier, and your own assessment will be measured against it.

An EU third-party evaluation capacity

The Commission wants an independent evaluation capacity supporting the AI Office, so that the assessment of a model's cyber risk is performed by someone other than the party that trained it. This is the same principle that governs financial audit and the same principle behind the self-attestation problem: the system under review does not get to author the record of its own behavior.

An ENISA and JRC secure testing platform

ENISA and the Joint Research Centre are tasked with a secure environment for evaluating models against adversarial cyber scenarios. The infrastructure signal is that testing is being centralized and made repeatable, which means results will be comparable across vendors and across time.

A structured-access blueprint

The plan sketches "structured access" to advanced AI capabilities: controlled, conditioned, recorded access rather than open availability. This is the pillar closest to enterprise operations. Structured access is an authorization architecture, and an authorization architecture that no one can inspect after the fact is an assertion, not a control.

Alignment with NIS2 and the Cyber Resilience Act

The plan explicitly ties AI security to the NIS2 Directive and the Cyber Resilience Act, which already carry incident-reporting and product-security obligations for in-scope entities. AI stops being a separate regulatory track and becomes one more system inside an existing cyber compliance perimeter.

The evidence question the plan implies

Strip the institutional machinery and the Action Plan asks one operational question of every enterprise running AI: can you demonstrate that access to model capability was controlled, and can you show what happened on each access?

That question has a specific shape. A regulator following the structured-access logic will ask which identity made a given model call, what authority that identity held at the moment of the call, which policy evaluated the request, what the policy decided, and where the record of that decision lives. The EU AI Act already codifies part of this: Article 12 requires "automatic recording of events (logs) over the lifetime of the system" to ensure traceability, including timestamps, input data, and identification of the natural persons involved (Practical AI Act). The Action Plan extends the same instinct from the model layer to the access layer.

Most enterprise AI deployments answer none of these questions today. The application authenticates the user, forwards the prompt to the provider, and logs that a call was made. Identity context is discarded at the boundary. Policy state at the moment of decision was never captured because no policy was evaluated. The audit record, where one exists, was written by the same application that made the call.

What structured access requires operationally

Structured access at the enterprise layer decomposes into four properties, and each one is an architecture decision rather than a documentation exercise.

Identity binding. Every model call carries a verified identity and the role that identity holds. A shared service-account key that fifty engineers use produces one identity for fifty humans, and no amount of post-hoc log analysis recovers the difference.

Per-request authorization. The decision to permit, redact, or deny is evaluated on this request, by this identity, against this data classification, under the policy in force at that moment. Authentication answers who is calling. Authorization at the AI call layer answers what this caller may do with this prompt content right now. This is the post-authentication gap, and it is where most deployments stop.

A per-decision audit record. Not a request log. A structured record of who authorized this, under which policy, at what moment, with what outcome. NIST calls this action lineage in its AI agent identity and authorization framework, whose comment window closed April 2, 2026 (NIST NCCoE).

Write-path independence. The component that produces the audit record sits outside the application that made the decision. Application-controlled logs fail under selective logging, suppression, and loss on crash. A tamper-evident record committed by an independent enforcement point survives all three.

The timing argument

The Action Plan launches initiatives rather than deadlines, so the temptation is to wait for the binding instrument. The problem with waiting is that audit evidence is not retroactive. On the day a supervisory authority asks what an identity was permitted to do with a model in March, an enterprise that started recording in September has nothing to say about March. Every month spent without identity-bound records is a month of AI activity that will always be unaccountable.

The EU AI Act's high-risk obligations already carry an August 2, 2026 date (European Commission), with penalties under Article 99 reaching €15 million or 3% of global annual turnover, whichever is higher. The Action Plan does not add a new deadline. It confirms the direction of the one already on the calendar.

DeepInspect

This is the gap DeepInspect closes. DeepInspect is a stateless proxy that sits at the AI request boundary, between authenticated users or agents and the LLM endpoints they call. Every request is evaluated against the identity making it, the role that identity holds, the classification of the data in the prompt, and the policy that applies to the route. The decision happens inline and can fail closed.

Each decision produces a signed, per-decision audit record committed before the response returns to the calling application. That record holds the identity, the policy version, the evaluation outcome, and the timestamp, which is the exact shape of evidence a structured-access regime asks for. Because the proxy is model-agnostic, the same policy and the same record format apply across OpenAI, Anthropic, Bedrock, Azure OpenAI, Vertex, and self-hosted endpoints in one deployment.

If you are mapping the EU AI Act and the Action Plan's structured-access direction onto controls you actually run, let's talk today.

No. The Action Plan presented on July 7, 2026 is a strategy instrument. It commits the Commission and its agencies to launch specific initiatives: pre-market model evaluation, an EU third-party evaluation capacity supporting the AI Office, an ENISA and JRC secure testing platform, a structured-access blueprint, and closer alignment with NIS2 and the Cyber Resilience Act. Binding obligations for enterprises still come from the EU AI Act, NIS2, and the Cyber Resilience Act themselves. The plan matters because it signals how those instruments will be interpreted and enforced, and because the evidence it implies takes months to accumulate. Organizations that treat it as a preview rather than an announcement will be in a better position when the binding text arrives.