22.01.2024
2 min
1683
ETSI SAI — new AI security standards. Learn how the European Telecommunications Institute is implementing modern requirements for protecting artificial intelligence. In the first part, we look at the main technical documents: from model testing to supply chain protection and explainability requirements. The article is useful for developers, analysts and IT security. Read the guide on implementation in practice.
Artificial intelligence is developing rapidly, but along with the opportunities, the threats are also growing. Prompt injections, agent abuse, vulnerabilities in orchestration – the spectrum of risks for AI is constantly expanding. While the US and China compete in the power of generative models, Europe has focused on developing security standards.
To this end, the Securing Artificial Intelligence Committee (SAI) was created within the European Telecommunications Standards Institute (ETSI). The main goal is to develop practical specifications that cover all stages of the life cycle of AI systems: from training and data supply to implementation and decommissioning. So far, 10 reports have been published – some of them remain relevant, while others have become morally obsolete in recent months.
This material opens a series of publications with a detailed analysis of ETSI SAI documents. The first part is an overview of the basic reports that laid the foundation for approaches to AI cybersecurity in Europe.
ETSI is an independent, non-profit organization officially recognized by the European Union alongside CEN and CENELEC. It develops standards for telecommunications, cybersecurity, and digital technologies that directly impact the requirements for companies operating in the EU. ETSI is behind the CE-type certifications that are often seen on electronics, toys, and telecom equipment.
The SAI Committee works in four areas:
protecting AI components from attacks;
reducing risks in AI systems;
using AI to enhance cyber defense;
considering ethical and social aspects in security.
The following is a brief overview of the published ETSI SAI documents that are already available for review.
Based on the table above, you may notice that the documents were not released together, but with a gap in time, and this will be important when we begin to analyze them in more detail.
First wave (07-2024) – methodology: testing and countermeasure catalog.
Second wave (01-2025) – foundation: problem formulation and data chain security.
Third wave (03-2025) – thematic specifications for threats, transparency and controls.
Fourth wave (04-2025) – a single basic set of requirements for implementation.
Fifth wave (05-2025) – linkage with legislation (AI Act) and a guide to practical implementation.
Thus, the historicality shows a consistent transition from threat description and tests → to process requirements → to regulatory mapping and implementation guidance in agent-based AI systems.
Let’s deal with the documents.
The document focuses on predictive ML models and describes fuzzing, differential testing, and a number of adversarial algorithms. However, it does not address specific threats to generative AI, such as prompt injection, jailbreak, or LLM attacks. Although gradient attacks can theoretically be applied to genAI systems, in practice they are no longer the main attack tactic.
The material does not contain ready-made practical examples or code — only mathematical formulas, pseudocode, and comparative performance tables. This is more of a guide to basic techniques for testing the robustness of neural networks than a practical guide.
For those looking for real-world cases or recipes for red teaming generative models, it is more appropriate to refer to the OWASP Red Team Guide.
There is a taxonomy of attacks on ML models (CV, NLP, audio), there is no explicit mention of LLM, although the document was released in 2024, this is explained by the fact that the first version was prepared in the distant 2021 and, apparently, the authors simply wanted to bring what they had started to the release and not touch on the topic of language models.
Below is an example of an attack taxonomy, presented in an abbreviated form for ease of understanding. Despite the concise format, the structure retains the basic idea and logic of the classification.
The document’s conclusion, the authors admit that the material is again academic, you won’t find any specific recommendations or calls to action here, which is a shame, the title was encouraging.
The first describes threats to machine learning systems along two axes – lifecycle stage and attack/abuse type. Two new classes are added to the problems in the table above:
Incorrect use of artificial intelligence:
ad-blocker bypass
malicious code obfuscation
deepfake content
handwriting or voice forgery
fake correspondence, etc.
And System/Process Risks:
bias,
ethical flaws,
lack of clarity,
software/hardware vulnerabilities
The document is small, more like a memo for corporate email distribution, and does not amount to a full-fledged threat model.
The second document again deals with the topic of datasets and protection against various data poisonings and training system compromises. Below is an illustration of the training pipeline around which the document is built.
At the end of the document, recommendations for protecting the supply chain for models are provided:
Hash sums can be used to effectively protect data integrity. When verifying data integrity.
Retraining models using verified or trusted data
Following standard cybersecurity guidelines, such as the principle of least privilege when accessing data and the supply chain.
Logging at all stages of processing and deployment, including collecting model telemetry.
A document that immerses the reader in the following concepts:
Transparency – the system is “open to inspection”, it has “no hidden parts”; any operation can be subjected to external audit
Explicability – the ability to show exactly how the system reached the result (“show the solution to the problem step by step”)
To ensure transparency of AI systems, the authors suggest the following actions:
Let’s take a quick look at TR 104030 “Critical Security Controls for AI Sector.” Essentially, the document answers a single question: should the testing methods for AI systems listed in the older ETSI TR 103305 checklist be changed? Some security controls from the original source are below:
The report confirms the application of the existing Critical Security Controls methodology and does not introduce new methodologies.
At this stage, the analysis of the documents of the ETSI Securing Artificial Intelligence working group is temporarily stopped. A significant part of the reports focuses on classic ML models and does not cover the specifics of LLM or agent systems. The next part will consider the latest May documents related to the EU AI Act, which has already entered into force and partially covers the current challenges of generative AI and agent architectures.
