Europe’s standards body has published a testable set of safeguards for the systems most likely to produce harmful deepfakes, shifting the emphasis from detecting fakes after they spread to preventing them by design. The specification, ETSI TS 104 275, sets out requirements across the whole life of a generative AI system, from its first design choices to its retirement, and adds test scenarios with pass and fail criteria so organisations can show whether their safeguards actually work.
What ETSI has published
ETSI, the European Telecommunications Standards Institute, developed the specification through its Technical Committee on Securing Artificial Intelligence, known as TC SAI. The document, version 1.1.1 dated September 2026, applies the baseline cyber security principles of ETSI EN 304 223 to generative AI, with a specific focus on preventing harm from deepfakes. The scope is deliberately broad.
The specification covers misinformation and disinformation, loss of confidentiality, copyright and intellectual property questions, and the training and source material used for large language models. It treats deepfakes not as a single kind of content, such as a fake video, but as a risk that runs through text, images, audio and video produced by generative systems.
ETSI publicised the specification on 29 October 2026, and trade coverage followed over the next two days. The timing matters because deepfake harms have moved from isolated incidents to a standing problem for identity fraud, impersonation, abusive images and fraudulent product sites, all of which can be produced with legal and commercially available software.
Five stages, thirteen principles
The specification organises its requirements around five stages of an AI system’s life: secure design, secure development, secure deployment, secure maintenance and secure end of life. Those stages carry the thirteen principles of the underlying EN 304 223 baseline, extended with provisions specific to generative AI and deepfakes.
At the design stage, organisations are expected to identify potential misuse of a generative system before it is released, evaluate the threats against it and manage the risks they find. Human responsibility is built in from the start, rather than added after a system is already in users’ hands,
and the design must serve security as well as functionality and performance. Development brings documentation and testing duties. Organisations should identify, track and protect their assets, secure their infrastructure and supply chain, and document their data, models and prompts. Appropriate testing and evaluation are required before deployment,
which means a system should be checked against the deepfake risks it could create, not simply checked for whether it works. Deployment adds duties toward the people who will meet the system. Organisations must put communication and processes in place for end users and affected entities, including content filtering, labelling of AI-generated content and user warnings.
Those measures are meant to help a person recognise synthetic material and understand what they are dealing with. Filtering, labelling and warnings are treated as deployment duties, not optional extras, and they apply to every system the specification covers. They are the reader’s first line of defence.
Systems must receive regular security updates, patches and mitigations, and their behaviour must be monitored after release. When a system is retired, its models and data must be disposed of properly, so that a discarded system does not keep generating harm after its owner has stopped watching it.
The testable part
The most consequential feature of the specification is not its list of principles but its test regime. A normative annex sets out extension provisions for conformance assessment, with test scenarios for each principle and pass or fail criteria for each scenario.
An organisation can therefore be asked not just whether it has a deepfake policy, but whether its system passed a specific test. That shift, from commitments to evidence, is the point ETSI’s own spokespeople emphasise. Alex Cadzow, rapporteur and secretary of TC SAI, said harmful,
misleading and illegal deepfake material can be created from the misuse of legal and commercially available software. He argued that AI organisations need support in addressing the risks much earlier, starting with how generative systems are designed. The specification also requires organisations to review emerging threats, investigate incidents and update their safeguards over time,
Organisations must also review emerging threats, investigate incidents and update their safeguards over time, and maintain documentation and records throughout. A safeguard that was adequate at launch is not treated as adequate for ever, because the techniques for producing deepfakes change, and so do the ways they are abused.
An informative annex on detection and prevention, including reporting and removal of deepfake material, sits alongside the normative requirements. Detection still matters, in other words, but it is no longer the whole strategy. The specification treats detection as one part of a lifecycle that starts before release and continues until a system is safely retired.
What this changes
The practical effect of a specification like this depends less on ETSI than on the buyers, regulators and courts that choose to reference it. A technical specification is voluntary guidance, not law, and it does not by itself stop a single deepfake.
Its power comes when procurement contracts, insurance terms or regulators point to it and ask a supplier to demonstrate conformance. That is where the pass and fail criteria matter most. A buyer choosing between generative media tools can now ask a concrete question: which test scenarios did this system pass, which did it fail, and what changed after a failure?
That is a harder conversation than asking whether a vendor takes safety seriously, and it gives internal risk teams something they can record and compare. The specification also supports objectives in the EU AI Act, extending security thinking beyond systems formally classified as high-risk.
That link does not make TS 104 275 a harmonised standard, and conformance to it should not be presented as proof of legal compliance. But it does give European organisations a shared vocabulary for the safeguards they are expected to consider, in a market where every vendor currently describes its own safety work differently.
There are clear limits to what the document can promise. A system can pass a test scenario and still be misused by a determined user, and a specification cannot cover every future technique for generating synthetic media. Organisations that treat conformance as a one-time certificate, rather than an ongoing discipline,
Organisations that treat conformance as a one-time certificate would miss the maintenance and monitoring duties that the specification itself insists on. The contrast with the United States is instructive, and it shows two different theories of how to govern fast-moving technology.
American responses to AI harm have largely arrived as state laws, lawsuits and enforcement warnings, with federal preemption still debated. Europe’s standards-led approach works more slowly and more quietly, but it produces documents that engineers and auditors can actually use, rather than rules that are argued about mainly in court.
How a buyer would use it
A procurement team is the most likely first user of this specification, because it gives a buyer a checklist that does not depend on trusting a vendor’s marketing. Instead of asking whether a system is safe, the team can ask which test scenarios it passed, what evidence supports each pass, and how failures were handled after they were found.
That evidence would need to cover the full lifecycle, not just the model at launch. A buyer should expect documentation of the data and prompts used, the security of the infrastructure and supply chain, and the monitoring in place after deployment. Gaps in any one stage would weaken the whole claim, because a deepfake risk can enter at any stage.
For smaller organisations, the specification cuts both ways. It offers a ready-made framework that a small team could adopt without hiring specialist lawyers or security consultants. But it also creates a new expectation: a supplier that cannot produce test evidence may find itself excluded from tenders where a rival can.
Regulators are the other likely audience, even though the specification is voluntary. A regulator drafting guidance or assessing a complaint can point to TS 104 275 as the current statement of good practice, and ask why an organisation departed from it. That soft power is often how European standards shape behaviour before any law catches up.
The open question is adoption. ETSI specifications gain force when industries adopt them, when auditors learn to test against them, and when contracts cite them by number. Until that happens, TS 104 275 is a well-built tool waiting for users, and its impact will be measured in procurement decisions rather than headlines.
Why It Matters
Deepfake risk is no longer a future problem, and the harms are not limited to politics. Identity fraud and impersonation use the same techniques as a fake celebrity endorsement, and abusive images cause harm that detection after the fact cannot undo. A framework that pushes safeguards earlier, into design and development, addresses the moment when harm is cheapest to prevent.
The specification also matters for the companies that build and host generative systems, because it raises the cost of vague safety claims. A vendor that cannot show test results, incident processes and documentation will look thinner against a rival that can, especially when selling to governments, banks and other buyers that must justify their choices.
That competitive pressure may do more than the document itself, because buyers compare evidence rather than promises. Recent serving failures show why lifecycle thinking is not abstract, and why a specification that covers deployment and maintenance matters in practice for every hosted system.
When a hosted model leaked other customers’ data through a cache fault, the failure was not in the model itself but in how it was served, monitored and fixed. A specification that covers deployment, maintenance and incident response speaks directly to that class of failure, as our report on the Cloudflare cache leak shows.
Background
ETSI’s work on securing AI began with the baseline standard EN 304 223, published in January 2026, which set thirteen principles for AI models and systems. TS 104 275 extends those principles to generative AI and deepfakes, and it is accompanied by a technical report on understanding and preventing harm from generative AI.
Source: ETSI TS 104 275 specification
0 Comments