[et_pb_section fb_built=”1″ _builder_version=”4.16″ global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_row _builder_version=”4.16″ background_size=”initial” background_position=”top_left” background_repeat=”repeat” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_column type=”4_4″ _builder_version=”4.16″ custom_padding=”|||” global_colors_info=”{}” custom_padding__hover=”|||” theme_builder_area=”post_content”][et_pb_text _builder_version=”4.27.8″ background_size=”initial” background_position=”top_left” background_repeat=”repeat” hover_enabled=”0″ global_colors_info=”{}” theme_builder_area=”post_content” sticky_enabled=”0″]<\/p>\n
One question consistently arises when an organization structures its AI risk management: Should it use a general-purpose methodology that is already familiar, or a framework specifically designed for artificial intelligence? The most robust answer, observed in most successful approaches, is not to choose one over the other: EBIOS RM provides the organizational framework and risk prioritization, while MITRE ATLAS documents the technical attack scenarios specific to AI. One provides the framework for the approach, the other supplies it with concrete scenarios , and both are part of a broader approach to <\/span>AI security in the enterprise<\/a> that this guide aims to structure.<\/span> <\/p>\n <\/p>\n EBIOS Risk Manager<\/u><\/a>, published by the National Agency for Security and Information Systems (ANSSI) in 2018 and updated in March 2024, organizes the risk analysis into five sequential and iterative workshops.<\/p>\n <\/p>\n EBIOS RM was not designed specifically for AI: it serves as a framework for all of an organization\u2019s digital risks, is de facto<\/em> required for entities subject to NIS2, and is recommended by the CNIL for GDPR<\/a> impact assessments. Although its 2024 update does not add a module dedicated to AI, the method remains fully applicable to AI systems\u2014including generative AI\u2014by treating them as supporting assets and\/or sources of risk within the generic framework of the five workshops. <\/p>\n <\/p>\n While EBIOS RM outlines an organizational approach, MITRE ATLAS documents\u2014with a level of precision that no general-purpose method can match\u2014how AI systems are actually attacked. The framework\u2014a direct extension of MITRE ATT&CK applied to data pipelines, inference APIs, and training processes\u2014lists, in its July 2026 version, 16 tactics, 111 techniques, and 83 sub-techniques, all derived from real-world incidents and documented red team exercises rather than purely theoretical threats. <\/p>\n By the end of 2025, the framework had incorporated fourteen techniques specifically dedicated to agent-based AI: context and memory poisoning, agent configuration tampering, credential harvesting, and exfiltration via an agent\u2019s invocation of a tool. For any team operating internal copilots or MCP<\/a> servers, ATLAS is now the reference framework that precisely identifies the attacks to which it is exposed, whereas EBIOS RM remains more generic in this specific area. <\/p>\n <\/p>\n According to consultants at Wavestone<\/u><\/a>, approximately 70% of the mitigation measures identified by MITRE ATLAS correspond to existing security controls, which makes it easier to integrate them into existing processes rather than imposing an entirely new framework. In practice, combining the two frameworks follows a simple logic: during the third and fourth EBIOS RM workshops\u2014dedicated to strategic and operational scenarios, respectively\u2014ATLAS provides a library of documented and up-to-date attack techniques, either in place of or as a supplement to the generic scenarios that the ANSSI method would otherwise require experts to construct on their own. <\/p>\n OWASP LLM Top 10<\/u><\/a> complements this framework on a third, more application-specific level: while EBIOS RM structures the organizational approach and ATLAS documents attack techniques at the system level, OWASP prioritizes the most critical vulnerabilities in the code and configuration of an LLM application. The three frameworks form complementary layers (governance<\/a>, threats, application vulnerabilities) rather than competing standards from which one must choose. <\/p>\n A concrete example illustrates this relationship: for a RAG system connected to an internal document repository, EBIOS RM Workshop 1 would identify this system as a critical business asset and define the scope of the study. Workshop 2 would identify plausible sources of risk: a malicious employee, a compromised service provider, or an external attacker targeting the document supply chain. Rather than inventing an operational scenario from scratch during Workshops 3 and 4, the team can directly draw on data poisoning techniques already documented and detailed in ATLAS, along with their associated mitigation measures: this approach saves significant time and ensures greater rigor compared to constructing a scenario based solely on expert opinion. <\/p>\n <\/p>\n <\/p>\n [\/et_pb_text][et_pb_accordion _builder_version=”4.27.8″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”][et_pb_accordion_item title=”What scope should be analyzed for an AI system?” open=”on” _builder_version=”4.27.8″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n The analysis must cover the model, data, prompts, RAG components, APIs, connected tools, infrastructure, and user access. The scope must be tailored to the system\u2019s intended uses and criticality. <\/p>\n [\/et_pb_accordion_item][et_pb_accordion_item title=”What deliverables can you expect from an AI risk analysis?” _builder_version=”4.27.8″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content” open=”off”]<\/p>\n The analysis should result in a map of the area, a prioritization of risks, priority threat scenarios, and an action plan specifying the measures to be implemented, the individuals responsible, and the deadlines.<\/p>\n [\/et_pb_accordion_item][et_pb_accordion_item title=”When should the risks of an AI system be reassessed?” _builder_version=”4.27.8″ _module_preset=”default” hover_enabled=”0″ global_colors_info=”{}” theme_builder_area=”post_content” open=”off” sticky_enabled=”0″]<\/p>\n A new assessment is recommended in the event of a change in model, data, or provider; when connecting to a new tool; or when transforming an assistant into an autonomous agent. It should also be considered following an incident or a significant change in usage patterns. <\/p>\n [\/et_pb_accordion_item][\/et_pb_accordion][et_pb_text _builder_version=”4.27.8″ _module_preset=”default” global_colors_info=”{}” theme_builder_area=”post_content”]<\/p>\n <\/p>\n <\/p>\n Our cybersecurity experts will assist you with the customized deployment of the EBIOS RM and MITRE ATLAS frameworks.<\/p>\n <\/p>\n <\/p>\n Would you like to discuss your project or assess your needs? Contact our experts.<\/u><\/a><\/p>\n [\/et_pb_text][et_pb_code _builder_version=”4.27.8″ _module_preset=”default” theme_builder_area=”post_content” hover_enabled=”0″ sticky_enabled=”0″]EBIOS RM Methodology (ANSSI): The French Framework for Digital Risk Management Applied to AI Systems<\/h2>\n
\n
<\/p>\n
MITRE ATLAS Framework: Mapping Threats, Adversarial Attacks, and Vulnerabilities in Large Language Models and Autonomous Agents<\/h2>\n
Integration of EBIOS RM, MITRE ATLAS, and OWASP LLM Top 10: Risk Analysis Methodology and Concrete RAG Scenarios<\/h2>\n
Frequently Asked Questions (FAQ): Implementing an AI Risk Analysis<\/h2>\n
AI Risk Support and Auditing: Structuring Your EBIOS RM and MITRE ATLAS Governance<\/h2>\n