ETSI EN 304 223 Turns AI Security Principles Into Baseline Requirements

ETSI adopted EN 304 223 on December 8, 2025 as a European Standard for baseline cybersecurity requirements for AI models and systems. The document follows the full AI lifecycle, but its production test comes down to a visible route: an authenticated request leaves an application and reaches a model, producing a decision record. I read the standard as a useful control-allocation document. A committee can approve thirteen principles on paper. A security team still has to prove which component blocks a prohibited request at 11:42 on a Tuesday.

TL;DR

• ETSI EN 304 223 covers secure design and development through deployment, followed by maintenance and end of life for deployed AI systems.
• Runtime evidence should connect the caller and model route to the policy version, decision, and monitoring result for each governed request.
• An HTTP enforcement layer can address routed model traffic. Training data and model weights remain with their control owners. The same applies to infrastructure, supply chains, and disposal.

The standard assigns security across the AI lifecycle

The official ETSI publication follows an AI system from design and development into deployment, then through maintenance and end of life. Thirteen principles cover risk awareness and security design. They also address threat evaluation, human responsibility, asset protection, infrastructure, supply chains, documentation, testing, user communication, updates, behavior monitoring, and disposal.

That breadth is useful because an AI system has several control planes. Provenance belongs with model artifacts, while training and evaluation data need custody controls. Infrastructure teams handle patching and isolation. Production requests need authorization, and their logs require protection and review. End-of-life work closes with deletion evidence.

I would reject any EN 304 223 mapping that assigns all of those jobs to an AI gateway. The neat one-box diagram looks good in a 47-slide deck and fails the first engineering review. A defensible mapping names the component that owns each provision and the test that proves it. It also names the record retained after the test.

The broader AI governance implementation roadmap gives that mapping a sequence. EN 304 223 supplies the security baseline for each stage.

Runtime provisions need route-level evidence

The behavior-monitoring provision requires teams to watch an AI system's inputs and outputs, along with intermediate states where available and performance against expected behavior. It also addresses protected logs and incident reporting. Those requirements become operational only when teams define the events and identifiers that connect one request to one outcome.

For a routed LLM call, I would preserve the authenticated caller or agent and the application route. The record should also preserve the model destination and prompt classification, followed by the active policy version and enforcement result. Response classification and the timestamp complete it. The incident record should reference the same request identifier. That join lets a reviewer move from an alert to the traffic decision without matching four dashboards by eye.

LLM audit log retention owns storage, indexing, access, migration, and retrieval after the record exists. EN 304 223 adds the reason for collecting it: monitored behavior has to support investigation and response, rather than becoming a pile of provider usage totals.

A gateway log alone cannot prove model-weight integrity or training-data provenance. It can prove what crossed the governed HTTP route and which policy decision occurred there.

The authenticated HTTP boundary covers one part of the baseline

DeepInspect's relevant path starts when an authenticated user or agent sends an HTTP request toward an LLM endpoint. An inline policy decision can inspect the supplied identity and role, plus the destination and data classification, before forwarding that request. The same route can inspect the model response before it reaches the caller. Each decision can produce an independent record.

That path maps cleanly to a bounded set of EN 304 223 controls. Route authorization can combine prompt and response classification with destination policy. Fail-closed handling and per-request evidence complete the decision, while behavior monitoring receives a consistent event stream for governed traffic.

Several provisions sit elsewhere. Secure development owns source review and dependency controls. Model teams own training data and weights. They also own evaluation and model cards. Cloud and platform teams own compute isolation and patching, plus secrets and service availability. Endpoint controls own local execution. Records teams own retention and legal holds. Procurement owns supplier commitments.

The existing LLM cybersecurity guide covers that wider allocation. EN 304 223 should tighten the ownership map, rather than blur it.

An EN 304 223 control file should be testable

The standard's companion implementation guide, ETSI TR 104 128, gives teams a second official reference for turning the principles into engineering work. I would build the control file around evidence, with one row per provision and no decorative maturity score.

Each row should name the EN 304 223 clause and accountable owner. It should identify the system component and expected behavior, then record the test fixture and retained evidence. The review cadence belongs in the same row. A route-control row might use a synthetic prompt carrying a marked data class. The expected result would name the allowed model and the policy outcome. Evidence would include the caller identity and request identifier, the policy version and destination, plus the decision and timestamp.

Run positive and negative fixtures. Prove an approved role can reach the approved model with permitted data. Then prove an unapproved role or destination is denied. Repeat the test with an unapproved data class. Trigger the fail-closed path by making the policy service unavailable in a controlled environment, and preserve the resulting denial record.

The same file should identify exclusions. A runtime HTTP test offers no proof for a poisoned training set or a compromised package. It also offers no proof for a local tool that never calls the governed model route.

DeepInspect

DeepInspect sits between authenticated users or agents and LLM endpoints as a stateless HTTP proxy. For traffic deliberately routed through it, the proxy can evaluate identity and role, plus destination and data classification, before the request reaches the model. It can inspect the response on the return path and commit a per-decision audit record with the policy version and outcome. The record also includes the timestamp.

That mechanism supports the route-level portion of an EN 304 223 control file. Model teams retain training-data and weight controls. Software supply chains, cloud infrastructure, endpoints, and disposal each need their own owners and evidence. Book a demo today.