AI security has often been treated as an extension of conventional software protection. ETSI EN 304 223 makes a different assumption: models introduce distinct risks, responsibilities, and lifecycle events that need explicit controls.
The European Standard covers systems ranging from basic prediction to deep neural networks and generative AI, excluding only strictly academic research. It addresses threats such as data poisoning, membership inference, model obfuscation, indirect prompt injection, and extraction through exposed interfaces.
Its practical value is not another list of principles. The standard identifies who is responsible, what evidence must exist, and when security work must be repeated.
Responsibility Follows the Technical Role
ETSI defines Developers, System Operators, and Data Custodians. One organisation may hold several roles. A bank that fine-tunes an open model for fraud detection is both a developer responsible for design and data provenance and an operator responsible for infrastructure and monitoring.
Data Custodians control permissions and integrity. Their inclusion makes data leadership part of the security chain rather than a supplier to it. Intended model use must match the sensitivity and permitted purpose of the training or operational data.
Threat modelling begins during design. Organisations should reduce unused functionality because every modality, tool, or interface expands the attack surface. A multimodal foundation model may be unnecessary when a specialised text model performs the task.
The standard also requires an inventory of models, components, interdependencies, and connections. That supports discovery of shadow AI: systems cannot be secured if the organisation does not know they exist.
Supply Chains Need Verifiable Evidence
Enterprises routinely rely on external models, open repositories, datasets, and cloud services. ETSI requires operators to justify poorly documented components and record the associated risk.
Developers should provide cryptographic hashes for model components so authenticity can be checked. Public training data should include its source and acquisition time, creating an audit trail for investigating poisoning or later disputes.
Procurement teams therefore need more than a vendor’s security promise. They need model versions, data documentation, dependencies, update processes, vulnerability handling, and evidence that the delivered component matches what was assessed.
External APIs require controls against AI-specific abuse. Rate limits and behavioural monitoring can reduce attempts to reverse-engineer a model, extract its capabilities, or overwhelm safeguards with coordinated traffic.
The standard’s emphasis on a known good state is equally important. Recovery planning must explain how a compromised model, configuration, or dataset is identified and restored, not merely how servers are restarted.
Every Major Update Reopens the Assessment
Retraining on new data is treated as a new model version that requires renewed testing. This reflects a reality conventional patch processes can miss: the software may be unchanged while behaviour has altered materially.
Operators must monitor logs for more than availability. Data drift or gradual behavioural change may signal a security problem, corrupted input, or a model moving beyond its validated conditions.
Retirement also has security consequences. Data Custodians should participate when a model is decommissioned or transferred so training information, configurations, credentials, and intellectual property do not remain on forgotten infrastructure.
Role-specific training completes the lifecycle. Developers need AI secure-engineering skills, while general employees need awareness of manipulation through AI outputs and social engineering.
ETSI EN 304 223 gives organisations a common baseline alongside regulatory obligations such as the EU AI Act. Compliance will still require interpretation for each system, but teams now have a structured place to begin.
That consistency can also make supplier comparisons and internal assurance reviews more concrete.
The most important change is cultural. AI security no longer starts at deployment and ends when the service is switched off. It follows the model from data selection to disposal, with evidence and responsibility travelling alongside it.
