{
  "generated": "2026-09-11T20:55:56.370Z",
  "count": 9,
  "license": "Content © Santiago Santa María Morales, licensed CC BY 4.0. Attribution required: credit the author and link the canonical URL.",
  "license_spdx": "CC-BY-4.0",
  "license_url": "https://creativecommons.org/licenses/by/4.0/",
  "entries": [
    {
      "id": "GOV-001",
      "slug": "eu-ai-act",
      "category": "regulation",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/governance/eu-ai-act",
      "api": "https://santismm.com/api/governance/eu-ai-act",
      "canonical_url": "https://santismm.com/en/governance/eu-ai-act",
      "api_url": "https://santismm.com/api/governance/eu-ai-act",
      "evidence": {
        "evidenceLevel": "industry_observation",
        "confidenceLevel": "high",
        "sourceType": [
          "paper",
          "industry_observation"
        ]
      },
      "frameworks": [
        "EU AI Act"
      ],
      "patterns": [
        "human-approval-gate"
      ],
      "knowledge": [
        "ai-governance",
        "guardrails",
        "human-in-the-loop",
        "ai-observability"
      ],
      "references": [
        {
          "title": "European Union — Artificial Intelligence Act (Regulation (EU) 2024/1689)",
          "url": "https://artificialintelligenceact.eu/"
        },
        {
          "title": "EU AI Act — Article 14 (Human oversight)",
          "url": "https://artificialintelligenceact.eu/article/14/"
        },
        {
          "title": "European Commission — AI Act overview",
          "url": "https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai"
        }
      ],
      "related": [
        "iso-42001",
        "nist-ai-rmf",
        "agentic-ai-governance-checklist"
      ],
      "locales": {
        "en": {
          "name": "EU AI Act",
          "summary": "The EU AI Act is the European Union's comprehensive, risk-based law for artificial intelligence. It sorts AI systems into risk tiers — unacceptable (banned), high-risk (strict obligations), limited-risk (transparency duties) and minimal-risk — and adds specific obligations for general-purpose AI models. It applies extraterritorially to anyone placing AI on the EU market and phases in over several years, with penalties reaching up to 7% of global annual turnover for the most serious breaches.",
          "definition": "The EU AI Act is a horizontal European regulation that governs AI by risk tier, imposing obligations on providers and deployers proportional to the risk an AI system poses to health, safety and fundamental rights.",
          "scope": "Providers and deployers that place AI systems or general-purpose AI models on the EU market or whose output is used in the EU — regardless of where they are established. Some uses (e.g. purely personal, certain research) are out of scope.",
          "keyPoints": [
            "Risk-based tiers: unacceptable (prohibited), high-risk, limited-risk (transparency), minimal-risk.",
            "Prohibited practices include social scoring and certain biometric and manipulative uses.",
            "High-risk systems require risk management, data governance, technical documentation, logging, human oversight, accuracy/robustness and post-market monitoring.",
            "General-purpose AI (GPAI) models carry their own transparency and, for systemic-risk models, additional obligations.",
            "Transparency duties: users must be told when they interact with AI, and synthetic content must be marked.",
            "Phased application with significant penalties for non-compliance."
          ],
          "controls": [
            {
              "control": "Risk classification",
              "note": "Determine each system's tier first — it decides every other obligation. Misclassifying a high-risk system is the costliest early mistake."
            },
            {
              "control": "Human oversight (Art. 14)",
              "note": "High-risk systems must be overseeable by a person who can intervene or stop them — the regulatory basis for human-approval gates."
            },
            {
              "control": "Technical documentation & logging",
              "note": "Maintain documentation and automatic event logs so the system is traceable and auditable across its lifecycle."
            },
            {
              "control": "Transparency to users",
              "note": "Disclose AI interaction and label AI-generated or manipulated content (deepfakes)."
            },
            {
              "control": "Post-market monitoring",
              "note": "Monitor performance in the field and report serious incidents; governance does not end at deployment."
            }
          ],
          "checklist": [
            "Inventory your AI systems and classify each by risk tier.",
            "Confirm none fall under prohibited practices.",
            "For high-risk systems, stand up risk management, data governance and technical documentation.",
            "Implement human oversight with the ability to intervene or stop the system.",
            "Enable logging/traceability and define post-market monitoring and incident reporting.",
            "Add user-facing transparency and content labelling where required.",
            "Track the phased application dates that apply to your systems."
          ],
          "pitfalls": [
            "Assuming the Act doesn't apply because you're outside the EU — it is extraterritorial.",
            "Treating GPAI obligations as identical to AI-system obligations; they are distinct.",
            "Bolting on human oversight that can't actually intervene in time.",
            "Under-documenting: missing technical documentation and logs is a common gap."
          ],
          "examples": [
            "A hiring screening tool classified as high-risk, requiring documentation, human oversight and monitoring.",
            "A chatbot adding a clear 'you are talking to an AI' disclosure to meet transparency duties.",
            "A GPAI provider publishing model documentation and a training-data summary."
          ],
          "faqs": [
            {
              "q": "Does the EU AI Act apply to companies outside the EU?",
              "a": "Yes. It applies to providers and deployers whose AI systems are placed on the EU market or whose output is used in the EU, regardless of where the company is established."
            },
            {
              "q": "What is a 'high-risk' AI system?",
              "a": "Systems used in sensitive areas (e.g. employment, credit, critical infrastructure, certain biometrics) or as safety components of regulated products. They carry the strictest obligations short of prohibition."
            },
            {
              "q": "How does it relate to human-in-the-loop?",
              "a": "Article 14 requires effective human oversight for high-risk systems — a person able to understand, intervene in or stop the system. The human-approval-gate pattern is one way to implement it."
            }
          ]
        },
        "es": {
          "name": "Reglamento Europeo de IA (EU AI Act)",
          "summary": "El Reglamento Europeo de IA es la ley integral y basada en riesgo de la Unión Europea para la inteligencia artificial. Clasifica los sistemas de IA en niveles de riesgo —inaceptable (prohibido), alto riesgo (obligaciones estrictas), riesgo limitado (deberes de transparencia) y riesgo mínimo— y añade obligaciones específicas para los modelos de IA de propósito general. Se aplica de forma extraterritorial a quien comercialice IA en el mercado de la UE y entra en vigor de forma escalonada, con sanciones de hasta el 7% de la facturación anual mundial en las infracciones más graves.",
          "definition": "El Reglamento Europeo de IA es una norma europea horizontal que gobierna la IA por nivel de riesgo, imponiendo obligaciones a proveedores y responsables del despliegue proporcionales al riesgo que el sistema supone para la salud, la seguridad y los derechos fundamentales.",
          "scope": "Proveedores y responsables del despliegue que comercialicen sistemas de IA o modelos de IA de propósito general en el mercado de la UE o cuya salida se use en la UE, con independencia de dónde estén establecidos. Algunos usos (p. ej. puramente personales, cierta investigación) quedan fuera del ámbito.",
          "keyPoints": [
            "Niveles basados en riesgo: inaceptable (prohibido), alto riesgo, riesgo limitado (transparencia), riesgo mínimo.",
            "Las prácticas prohibidas incluyen la puntuación social y ciertos usos biométricos y manipuladores.",
            "Los sistemas de alto riesgo exigen gestión de riesgos, gobernanza de datos, documentación técnica, registros, supervisión humana, precisión/robustez y vigilancia poscomercialización.",
            "Los modelos de IA de propósito general (GPAI) tienen su propia transparencia y, los de riesgo sistémico, obligaciones adicionales.",
            "Deberes de transparencia: hay que avisar al usuario cuando interactúa con IA y marcar el contenido sintético.",
            "Aplicación escalonada con sanciones significativas por incumplimiento."
          ],
          "controls": [
            {
              "control": "Clasificación de riesgo",
              "note": "Determina primero el nivel de cada sistema: decide todas las demás obligaciones. Clasificar mal un sistema de alto riesgo es el error temprano más costoso."
            },
            {
              "control": "Supervisión humana (Art. 14)",
              "note": "Los sistemas de alto riesgo deben poder ser supervisados por una persona que pueda intervenir o detenerlos: la base regulatoria de las puertas de aprobación humana."
            },
            {
              "control": "Documentación técnica y registros",
              "note": "Mantén documentación y registros automáticos de eventos para que el sistema sea trazable y auditable durante su ciclo de vida."
            },
            {
              "control": "Transparencia hacia el usuario",
              "note": "Revela la interacción con IA y etiqueta el contenido generado o manipulado por IA (deepfakes)."
            },
            {
              "control": "Vigilancia poscomercialización",
              "note": "Monitoriza el rendimiento en el campo y reporta incidentes graves; la gobernanza no termina en el despliegue."
            }
          ],
          "checklist": [
            "Inventaría tus sistemas de IA y clasifica cada uno por nivel de riesgo.",
            "Confirma que ninguno cae en prácticas prohibidas.",
            "Para los de alto riesgo, monta gestión de riesgos, gobernanza de datos y documentación técnica.",
            "Implementa supervisión humana con capacidad de intervenir o detener el sistema.",
            "Habilita registro/trazabilidad y define la vigilancia poscomercialización y el reporte de incidentes.",
            "Añade transparencia hacia el usuario y etiquetado de contenido donde se exija.",
            "Sigue las fechas de aplicación escalonada que afectan a tus sistemas."
          ],
          "pitfalls": [
            "Suponer que el Reglamento no aplica por estar fuera de la UE: es extraterritorial.",
            "Tratar las obligaciones de GPAI como idénticas a las de los sistemas de IA; son distintas.",
            "Añadir una supervisión humana que en realidad no puede intervenir a tiempo.",
            "Documentar de menos: la falta de documentación técnica y registros es una carencia habitual."
          ],
          "examples": [
            "Una herramienta de cribado de candidatos clasificada como alto riesgo, que exige documentación, supervisión humana y monitorización.",
            "Un chatbot que añade un aviso claro de 'estás hablando con una IA' para cumplir los deberes de transparencia.",
            "Un proveedor de GPAI que publica la documentación del modelo y un resumen de los datos de entrenamiento."
          ],
          "faqs": [
            {
              "q": "¿El Reglamento aplica a empresas fuera de la UE?",
              "a": "Sí. Aplica a proveedores y responsables del despliegue cuyos sistemas de IA se comercialicen en el mercado de la UE o cuya salida se use en la UE, con independencia de dónde esté la empresa."
            },
            {
              "q": "¿Qué es un sistema de IA de 'alto riesgo'?",
              "a": "Sistemas usados en ámbitos sensibles (p. ej. empleo, crédito, infraestructuras críticas, ciertos usos biométricos) o como componentes de seguridad de productos regulados. Tienen las obligaciones más estrictas sin llegar a la prohibición."
            },
            {
              "q": "¿Cómo se relaciona con el human-in-the-loop?",
              "a": "El Artículo 14 exige supervisión humana efectiva para los sistemas de alto riesgo: una persona capaz de entender, intervenir o detener el sistema. El patrón de puerta de aprobación humana es una forma de implementarlo."
            }
          ]
        },
        "pt": {
          "name": "Regulamento Europeu de IA (EU AI Act)",
          "summary": "O Regulamento Europeu de IA é a lei abrangente e baseada em risco da União Europeia para a inteligência artificial. Classifica os sistemas de IA em níveis de risco —inaceitável (proibido), alto risco (obrigações estritas), risco limitado (deveres de transparência) e risco mínimo— e adiciona obrigações específicas para os modelos de IA de propósito geral. Aplica-se de forma extraterritorial a quem comercializa IA no mercado da UE e entra em vigor de forma faseada, com sanções de até 7% do faturamento anual mundial nas infrações mais graves.",
          "definition": "O Regulamento Europeu de IA é uma norma europeia horizontal que governa a IA por nível de risco, impondo obrigações a fornecedores e implantadores proporcionais ao risco que o sistema representa para a saúde, a segurança e os direitos fundamentais.",
          "scope": "Fornecedores e implantadores que comercializem sistemas de IA ou modelos de IA de propósito geral no mercado da UE ou cuja saída seja usada na UE, independentemente de onde estejam estabelecidos. Alguns usos (ex.: puramente pessoais, certa pesquisa) ficam fora do escopo.",
          "keyPoints": [
            "Níveis baseados em risco: inaceitável (proibido), alto risco, risco limitado (transparência), risco mínimo.",
            "As práticas proibidas incluem a pontuação social e certos usos biométricos e manipuladores.",
            "Os sistemas de alto risco exigem gestão de risco, governança de dados, documentação técnica, registros, supervisão humana, precisão/robustez e vigilância pós-mercado.",
            "Os modelos de IA de propósito geral (GPAI) têm sua própria transparência e, os de risco sistêmico, obrigações adicionais.",
            "Deveres de transparência: é preciso avisar o usuário quando ele interage com IA e marcar o conteúdo sintético.",
            "Aplicação faseada com sanções significativas por descumprimento."
          ],
          "controls": [
            {
              "control": "Classificação de risco",
              "note": "Determine primeiro o nível de cada sistema: ele decide todas as demais obrigações. Classificar mal um sistema de alto risco é o erro inicial mais custoso."
            },
            {
              "control": "Supervisão humana (Art. 14)",
              "note": "Os sistemas de alto risco devem poder ser supervisionados por uma pessoa que possa intervir ou pará-los: a base regulatória dos portões de aprovação humana."
            },
            {
              "control": "Documentação técnica e registros",
              "note": "Mantenha documentação e registros automáticos de eventos para que o sistema seja rastreável e auditável ao longo do seu ciclo de vida."
            },
            {
              "control": "Transparência ao usuário",
              "note": "Revele a interação com IA e rotule o conteúdo gerado ou manipulado por IA (deepfakes)."
            },
            {
              "control": "Vigilância pós-mercado",
              "note": "Monitore o desempenho em campo e reporte incidentes graves; a governança não termina na implantação."
            }
          ],
          "checklist": [
            "Inventarie seus sistemas de IA e classifique cada um por nível de risco.",
            "Confirme que nenhum cai em práticas proibidas.",
            "Para os de alto risco, monte gestão de risco, governança de dados e documentação técnica.",
            "Implemente supervisão humana com capacidade de intervir ou parar o sistema.",
            "Habilite registro/rastreabilidade e defina a vigilância pós-mercado e o reporte de incidentes.",
            "Adicione transparência ao usuário e rotulagem de conteúdo onde for exigido.",
            "Acompanhe as datas de aplicação faseada que afetam seus sistemas."
          ],
          "pitfalls": [
            "Supor que o Regulamento não se aplica por estar fora da UE: ele é extraterritorial.",
            "Tratar as obrigações de GPAI como idênticas às dos sistemas de IA; são distintas.",
            "Adicionar uma supervisão humana que na verdade não consegue intervir a tempo.",
            "Documentar de menos: a falta de documentação técnica e registros é uma lacuna comum."
          ],
          "examples": [
            "Uma ferramenta de triagem de candidatos classificada como alto risco, que exige documentação, supervisão humana e monitoramento.",
            "Um chatbot que adiciona um aviso claro de 'você está falando com uma IA' para cumprir os deveres de transparência.",
            "Um fornecedor de GPAI que publica a documentação do modelo e um resumo dos dados de treinamento."
          ],
          "faqs": [
            {
              "q": "O Regulamento se aplica a empresas fora da UE?",
              "a": "Sim. Aplica-se a fornecedores e implantadores cujos sistemas de IA sejam comercializados no mercado da UE ou cuja saída seja usada na UE, independentemente de onde a empresa esteja."
            },
            {
              "q": "O que é um sistema de IA de 'alto risco'?",
              "a": "Sistemas usados em áreas sensíveis (ex.: emprego, crédito, infraestrutura crítica, certos usos biométricos) ou como componentes de segurança de produtos regulados. Têm as obrigações mais estritas aquém da proibição."
            },
            {
              "q": "Como se relaciona com o human-in-the-loop?",
              "a": "O Artigo 14 exige supervisão humana efetiva para os sistemas de alto risco: uma pessoa capaz de entender, intervir ou parar o sistema. O padrão de portão de aprovação humana é uma forma de implementá-lo."
            }
          ]
        },
        "fr": {
          "name": "EU AI Act",
          "summary": "L'EU AI Act est la législation complète de l'Union européenne sur l'intelligence artificielle, basée sur le risque. Il classe les systèmes d'IA en différents niveaux de risque — inacceptable (interdit), haut risque (obligations strictes), risque limité (devoirs de transparence) et risque minimal — et ajoute des obligations spécifiques pour les modèles d'IA à usage général. Il s'applique de manière extraterritoriale à quiconque met sur le marché de l'UE des systèmes d'IA et entre en vigueur de manière progressive sur plusieurs années, avec des sanctions pouvant atteindre jusqu'à 7 % du chiffre d'affaires annuel mondial pour les infractions les plus graves.",
          "definition": "L'EU AI Act est un règlement européen horizontal qui encadre l'IA par niveau de risque, imposant aux fournisseurs et aux déployeurs des obligations proportionnelles au risque qu'un système d'IA présente pour la santé, la sécurité et les droits fondamentaux.",
          "scope": "Les fournisseurs et déployeurs qui mettent sur le marché de l'UE des systèmes d'IA ou des modèles d'IA à usage général, ou dont les résultats sont utilisés dans l'UE — quel que soit leur lieu d'établissement. Certains usages (par exemple, purement personnels ou certaines recherches) sont hors du champ d'application.",
          "keyPoints": [
            "Niveaux basés sur le risque : inacceptable (interdit), haut risque, risque limité (transparence), risque minimal.",
            "Les pratiques interdites incluent la notation sociale ainsi que certains usages biométriques et de manipulation.",
            "Les systèmes à haut risque requièrent une gestion des risques, une gouvernance des données, une documentation technique, une journalisation, une surveillance humaine, de la précision/robustesse et un suivi après commercialisation.",
            "Les modèles d'IA à usage général (GPAI) comportent leurs propres obligations de transparence et, pour les modèles à risque systémique, des obligations supplémentaires.",
            "Devoirs de transparence : les utilisateurs doivent être informés lorsqu'ils interagissent avec une IA, et les contenus synthétiques doivent être marqués.",
            "Application progressive avec des sanctions importantes en cas de non-conformité."
          ],
          "controls": [
            {
              "control": "Classification des risques",
              "note": "Déterminez d'abord le niveau de risque de chaque système — il conditionne toutes les autres obligations. Une mauvaise classification d'un système à haut risque est l'erreur initiale la plus coûteuse."
            },
            {
              "control": "Surveillance humaine (Art. 14)",
              "note": "Les systèmes à haut risque doivent pouvoir être surveillés par une personne capable d'intervenir ou de les arrêter — le fondement réglementaire des jalons d'approbation humaine."
            },
            {
              "control": "Documentation technique et journalisation",
              "note": "Maintenez la documentation et les journaux d'événements automatiques afin que le système soit traçable et auditable tout au long de son cycle de vie."
            },
            {
              "control": "Transparence envers les utilisateurs",
              "note": "Divulguez l'interaction avec l'IA et étiquetez les contenus générés ou manipulés par l'IA (deepfakes)."
            },
            {
              "control": "Suivi après commercialisation",
              "note": "Surveillez les performances sur le terrain et signalez les incidents graves ; la gouvernance ne s'arrête pas au déploiement."
            }
          ],
          "checklist": [
            "Inventoriez vos systèmes d'IA et classifiez chacun d'eux par niveau de risque.",
            "Confirmez qu'aucun ne relève de pratiques interdites.",
            "Pour les systèmes à haut risque, mettez en place une gestion des risques, une gouvernance des données et une documentation technique.",
            "Mettez en œuvre une surveillance humaine avec la capacité d'intervenir ou d'arrêter le système.",
            "Activez la journalisation/traçabilité et définissez le suivi après commercialisation ainsi que la notification des incidents.",
            "Ajoutez la transparence envers les utilisateurs et l'étiquetage des contenus là où cela est requis.",
            "Suivez les dates d'application progressive qui s'appliquent à vos systèmes."
          ],
          "pitfalls": [
            "Supposer que le règlement ne s'applique pas parce que vous êtes en dehors de l'UE — il est extraterritorial.",
            "Traiter les obligations relatives aux GPAI comme identiques à celles des systèmes d'IA ; elles sont distinctes.",
            "Greffer à la va-vite une surveillance humaine qui ne peut pas réellement intervenir à temps.",
            "Sous-documenter : l'absence de documentation technique et de journaux est une lacune courante."
          ],
          "examples": [
            "Un outil de présélection des candidatures classé à haut risque, nécessitant une documentation, une surveillance humaine et un suivi.",
            "Un chatbot ajoutant une mention claire « vous parlez à une IA » pour répondre aux devoirs de transparence.",
            "Un fournisseur de GPAI publiant la documentation du modèle et un résumé des données d'entraînement."
          ],
          "faqs": [
            {
              "q": "L'EU AI Act s'applique-t-il aux entreprises situées en dehors de l'UE ?",
              "a": "Oui. Il s'applique aux fournisseurs et déployeurs dont les systèmes d'IA sont mis sur le marché de l'UE ou dont les résultats sont utilisés dans l'UE, quel que soit le lieu d'établissement de l'entreprise."
            },
            {
              "q": "Qu'est-ce qu'un système d'IA « à haut risque » ?",
              "a": "Des systèmes utilisés dans des domaines sensibles (par exemple, l'emploi, le crédit, les infrastructures critiques, certains systèmes biométriques) ou comme composants de sécurité de produits réglementés. Ils comportent les obligations les plus strictes juste avant l'interdiction."
            },
            {
              "q": "Quel est le rapport avec le principe de l'humain dans la boucle (human-in-the-loop) ?",
              "a": "L'article 14 exige une surveillance humaine efficace pour les systèmes à haut risque — une personne capable de comprendre, d'intervenir ou d'arrêter le système. Le modèle du jalon d'approbation humaine est un moyen de le mettre en œuvre."
            }
          ]
        },
        "de": {
          "name": "EU AI Act",
          "summary": "Der EU AI Act ist das umfassende, risikobasierte Gesetz der Europäischen Union für künstliche Intelligenz. Er teilt KI-Systeme in Risikostufen ein – unannehmbar (verboten), hohes Risiko (strenge Auflagen), begrenztes Risiko (Transparenzpflichten) und minimales Risiko – und führt spezifische Verpflichtungen für KI-Modelle mit allgemeinem Verwendungszweck (General-Purpose AI) ein. Er gilt extraterritorial für jeden, der KI auf dem EU-Markt bereitstellt, und wird über mehrere Jahre hinweg schrittweise eingeführt, wobei die Strafen bei schwerwiegenden Verstößen bis zu 7 % des weltweiten Jahresumsatzes betragen können.",
          "definition": "Der EU AI Act ist eine horizontale europäische Verordnung, die KI nach Risikostufen reguliert und Anbietern sowie Betreibern Verpflichtungen auferlegt, die proportional zu dem Risiko sind, das ein KI-System für Gesundheit, Sicherheit und Grundrechte darstellt.",
          "scope": "Anbieter und Betreiber, die KI-Systeme oder KI-Modelle mit allgemeinem Verwendungszweck auf dem EU-Markt bereitstellen oder deren Ergebnisse in der EU genutzt werden – unabhängig von ihrem Niederlassungsort. Einige Verwendungszwecke (z. B. rein persönliche Nutzung, bestimmte Forschungsarbeiten) fallen nicht in den Anwendungsbereich.",
          "keyPoints": [
            "Risikobasierte Stufen: unannehmbar (verboten), hohes Risiko, begrenztes Risiko (Transparenz), minimales Risiko.",
            "Zu den verbotenen Praktiken gehören Social Scoring sowie bestimmte biometrische und manipulative Verwendungszwecke.",
            "Hochrisiko-Systeme erfordern Risikomanagement, Data Governance, technische Dokumentation, Protokollierung, menschliche Aufsicht, Genauigkeit/Robustheit und eine Überwachung nach dem Inverkehrbringen (Post-Market Monitoring).",
            "KI-Modelle mit allgemeinem Verwendungszweck (GPAI) unterliegen eigenen Transparenzpflichten und, bei Modellen mit systemischem Risiko, zusätzlichen Verpflichtungen.",
            "Transparenzpflichten: Nutzer müssen darüber informiert werden, wenn sie mit einer KI interagieren, und synthetische Inhalte müssen gekennzeichnet werden.",
            "Schrittweise Anwendung mit erheblichen Strafen bei Nichteinhaltung."
          ],
          "controls": [
            {
              "control": "Risikoklassifizierung",
              "note": "Bestimmen Sie zuerst die Risikostufe jedes Systems – sie entscheidet über alle weiteren Verpflichtungen. Die Fehlklassifizierung eines Hochrisiko-Systems ist der kostspieligste Fehler zu Beginn."
            },
            {
              "control": "Menschliche Aufsicht (Art. 14)",
              "note": "Hochrisiko-Systeme müssen von einer Person beaufsichtigt werden können, die eingreifen oder sie stoppen kann – die regulatorische Grundlage für Freigabeprozesse durch den Menschen (Human-Approval Gates)."
            },
            {
              "control": "Technische Dokumentation & Protokollierung",
              "note": "Führen Sie Dokumentationen und automatische Ereignisprotokolle, damit das System über seinen gesamten Lebenszyklus hinweg rückverfolgbar und prüfbar bleibt."
            },
            {
              "control": "Transparenz gegenüber Nutzern",
              "note": "Offenlegung der KI-Interaktion und Kennzeichnung von KI-generierten oder manipulierten Inhalten (Deepfakes)."
            },
            {
              "control": "Überwachung nach dem Inverkehrbringen",
              "note": "Überwachen Sie die Leistung im praktischen Einsatz und melden Sie schwerwiegende Vorfälle; Governance endet nicht mit der Bereitstellung."
            }
          ],
          "checklist": [
            "Erfassen Sie Ihre KI-Systeme in einem Inventar und klassifizieren Sie jedes nach seiner Risikostufe.",
            "Stellen Sie sicher, dass keines der Systeme unter die verbotenen Praktiken fällt.",
            "Richten Sie für Hochrisiko-Systeme Risikomanagement, Data Governance und technische Dokumentation ein.",
            "Implementieren Sie eine menschliche Aufsicht mit der Möglichkeit, einzugreifen oder das System zu stoppen.",
            "Ermöglichen Sie die Protokollierung/Rückverfolgbarkeit und definieren Sie die Überwachung nach dem Inverkehrbringen sowie die Meldung von Vorfällen.",
            "Fügen Sie bei Bedarf Transparenzhinweise für Nutzer und Inhaltskennzeichnungen hinzu.",
            "Verfolgen Sie die für Ihre Systeme geltenden Termine der schrittweisen Anwendung."
          ],
          "pitfalls": [
            "Die Annahme, das Gesetz gelte nicht, weil Sie sich außerhalb der EU befinden – es ist extraterritorial wirksam.",
            "Die Behandlung von GPAI-Verpflichtungen als identisch mit den Verpflichtungen für KI-Systeme; diese sind unterschiedlich.",
            "Das nachträgliche Aufpfropfen einer menschlichen Aufsicht, die im Ernstfall nicht rechtzeitig eingreifen kann.",
            "Unzureichende Dokumentation: Fehlende technische Dokumentation und Protokolle sind eine häufige Schwachstelle."
          ],
          "examples": [
            "Ein Tool zur Vorauswahl von Bewerbern, das als hochriskant eingestuft ist und Dokumentation, menschliche Aufsicht sowie Überwachung erfordert.",
            "Ein Chatbot, der einen klaren Hinweis \"Sie sprechen mit einer KI\" anzeigt, um die Transparenzpflichten zu erfüllen.",
            "Ein GPAI-Anbieter, der die Modelldokumentation und eine Zusammenfassung der Trainingsdaten veröffentlicht."
          ],
          "faqs": [
            {
              "q": "Gilt der EU AI Act auch für Unternehmen außerhalb der EU?",
              "a": "Ja. Er gilt für Anbieter und Betreiber, deren KI-Systeme auf dem EU-Markt bereitgestellt werden oder deren Ergebnisse in der EU genutzt werden, unabhängig vom Sitz des Unternehmens."
            },
            {
              "q": "Was ist ein \"Hochrisiko\"-KI-System?",
              "a": "Systeme, die in sensiblen Bereichen (z. B. Beschäftigung, Kreditwürdigkeit, kritische Infrastruktur, bestimmte Biometrie) oder als Sicherheitsbauteile regulierter Produkte eingesetzt werden. Sie unterliegen den strengsten Verpflichtungen direkt unterhalb eines Verbots."
            },
            {
              "q": "Wie verhält es sich zu Human-in-the-Loop?",
              "a": "Artikel 14 fordert eine wirksame menschliche Aufsicht für Hochrisiko-Systeme – eine Person, die in der Lage ist, das System zu verstehen, einzugreifen oder es zu stoppen. Das Muster des \"Human-Approval-Gate\" (Freigabe durch den Menschen) ist eine Möglichkeit, dies umzusetzen."
            }
          ]
        },
        "ja": {
          "name": "EU AI Act",
          "summary": "EU AI Actは、欧州連合（EU）による人工知能に関する包括的かつリスクベースの法律です。AIシステムを、許容できないリスク（禁止）、高リスク（厳格な義務）、限定的なリスク（透明性の義務）、最小限のリスクというリスクティアに分類し、汎用AI（GPAI）モデルに対する特定の義務を追加しています。EU市場にAIを投入するすべての主体に域外適用され、数年かけて段階的に施行されます。最も深刻な違反に対しては、世界年間売上高の最大7%に達する制裁金が科されます。",
          "definition": "EU AI Actは、リスクティアに基づいてAIを規制する横断的な欧州の規則であり、AIシステムが健康、安全、および基本的人権に及ぼすリスクに比例した義務を提供者および展開者に課します。",
          "scope": "設立地に関わらず、EU市場にAIシステムや汎用AIモデルを投入する、またはその出力がEU内で使用される提供者および展開者。一部の用途（純粋に個人的な使用、特定の研究など）は対象外です。",
          "keyPoints": [
            "リスクベースのティア：許容できないリスク（禁止）、高リスク、限定的なリスク（透明性）、最小限のリスク。",
            "禁止される行為には、ソーシャルスコアリング、特定の生体認証、および人を操作するような使用が含まれます。",
            "高リスクシステムには、リスク管理、データガバナンス、技術文書、ログ記録、人間による監視、正確性/堅牢性、および市後監視（ポストマーケットモニタリング）が求められます。",
            "汎用AI（GPAI）モデルには独自の透明性の義務があり、システム的リスクを伴うモデルにはさらなる義務が課されます。",
            "透明性の義務：ユーザーはAIと対話していることを知らされる必要があり、合成コンテンツにはマークを付す必要があります。",
            "段階的な適用と、非準拠に対する重大な制裁金。"
          ],
          "controls": [
            {
              "control": "リスク分類",
              "note": "まず各システムのリスクティアを決定します。これが他のすべての義務を左右します。高リスクシステムを誤って分類することは、初期段階における最もコストのかかる過ちです。"
            },
            {
              "control": "人間による監視（第14条）",
              "note": "高リスクシステムは、介入または停止できる人間によって監視可能でなければなりません。これが「人間による承認ゲート」の規制上の根拠となります。"
            },
            {
              "control": "技術文書とログ記録",
              "note": "ライフサイクル全体でシステムを追跡および監査できるように、文書と自動イベントログを維持します。"
            },
            {
              "control": "ユーザーに対する透明性",
              "note": "AIとの対話を明示し、AIによって生成または操作されたコンテンツ（ディープフェイク）にラベルを付します。"
            },
            {
              "control": "市後監視（ポストマーケットモニタリング）",
              "note": "現場でのパフォーマンスを監視し、重大なインシデントを報告します。ガバナンスはデプロイして終わりではありません。"
            }
          ],
          "checklist": [
            "AIシステムのインベントリ（台帳）を作成し、それぞれをリスクティアごとに分類します。",
            "禁止されている行為に該当するものがないことを確認します。",
            "高リスクシステムについては、リスク管理、データガバナンス、および技術文書を整備します。",
            "システムに介入または停止する権限を持つ、人間による監視を実装します。",
            "ログ記録/追跡可能性を有効にし、市後監視とインシデント報告を定義します。",
            "必要に応じて、ユーザー向けの透明性の確保とコンテンツへのラベル付加を行います。",
            "自社システムに適用される段階的な施行日を追跡します。"
          ],
          "pitfalls": [
            "EU域外にいるため、この法律が適用されないと仮定すること。これは域外適用されます。",
            "GPAIの義務をAIシステムの義務と同一視すること。これらは異なります。",
            "実際には適時に介入できないような、形ばかりの人間による監視を後付けすること。",
            "文書化の不足：技術文書やログの欠落は、よくあるギャップです。"
          ],
          "examples": [
            "高リスクに分類され、文書化、人間による監視、およびモニタリングが要求される採用選考ツール。",
            "透明性の義務を果たすために、「AIと対話しています」という明確な開示を追加したチャットボット。",
            "モデルの文書とトレーニングデータの要約を公開するGPAI提供者。"
          ],
          "faqs": [
            {
              "q": "EU AI ActはEU域外の企業にも適用されますか？",
              "a": "はい。会社の設立地に関わらず、AIシステムがEU市場に投入される、またはその出力がEU内で使用される提供者および展開者に適用されます。"
            },
            {
              "q": "「高リスク」AIシステムとは何ですか？",
              "a": "機微な領域（雇用、与信、重要インフラ、特定の生体認証など）で使用されるシステム、または規制対象製品の安全構成要素として使用されるシステムです。禁止措置を除けば、最も厳格な義務が課されます。"
            },
            {
              "q": "Human-in-the-loop（人間による関与）とはどのような関係がありますか？",
              "a": "第14条は、高リスクシステムに対して効果的な人間による監視（システムを理解し、介入し、または停止できる人物）を求めています。人間による承認ゲートのパターンは、これを実装する1つの方法です。"
            }
          ]
        },
        "zh": {
          "name": "EU AI Act",
          "summary": "EU AI Act 是欧盟针对人工智能制定的全面的、基于风险的法律。它将 AI 系统划分为不同的风险等级——不可接受（禁用）、高风险（严格义务）、有限风险（透明度义务）和极低风险，并对通用 AI 模型增加了特定合规义务。该法案具有域外效力，适用于任何将 AI 引入欧盟市场的主体，并在数年内分阶段实施，对最严重的违规行为处以最高可达全球年营业额 7% 的罚款。",
          "definition": "EU AI Act 是一项横向的欧洲法规，通过风险分级来监管 AI，对提供商和部署商施加与其 AI 系统对健康、安全和基本权利所构成风险相匹配的义务。",
          "scope": "在欧盟市场投放 AI 系统或通用 AI 模型，或者其输出在欧盟境内使用的提供商和部署商——无论其注册地在何处。某些用途（例如纯个人用途、特定研究）不属于适用范围。",
          "keyPoints": [
            "基于风险的分级：不可接受（禁止）、高风险、有限风险（透明度）、极低风险。",
            "禁止的行为包括社会信用评分以及某些生物识别和操纵性用途。",
            "高风险系统需要进行风险管理、数据治理、技术文档记录、日志记录、人工监督、准确性/鲁棒性保障以及上市后监控。",
            "通用 AI（GPAI）模型有其自身的透明度要求，对于具有系统性风险的模型，还需承担额外义务。",
            "透明度义务：当用户与 AI 交互时必须予以告知，且合成内容必须进行标记。",
            "分阶段实施，对不合规行为处以重罚。"
          ],
          "controls": [
            {
              "control": "风险分类",
              "note": "首先确定每个系统的风险等级——它决定了所有其他合规义务。将高风险系统错误分类是前期代价最昂贵的错误。"
            },
            {
              "control": "人工监督（第 14 条）",
              "note": "高风险系统必须可由人员进行监督，且该人员能够进行干预或终止系统——这是设置人工审批关卡的监管依据。"
            },
            {
              "control": "技术文档与日志记录",
              "note": "维护文档和自动事件日志，确保系统在整个生命周期内可追溯、可审计。"
            },
            {
              "control": "对用户的透明度",
              "note": "披露 AI 交互情况，并对 AI 生成或操纵的内容（深度伪造）进行标记。"
            },
            {
              "control": "上市后监控",
              "note": "监控实际运行中的性能并报告严重事件；治理并不会在部署后结束。"
            }
          ],
          "checklist": [
            "盘点您的 AI 系统并按风险等级对每个系统进行分类。",
            "确认没有任何系统属于被禁止的行为。",
            "对于高风险系统，建立风险管理、数据治理和技术文档记录机制。",
            "实施人工监督，并具备干预或终止系统的能力。",
            "启用日志记录/可追溯性，并定义上市后监控和事件报告机制。",
            "在需要时增加面向用户的透明度提示和内容标记。",
            "跟踪适用于您系统的分阶段实施日期。"
          ],
          "pitfalls": [
            "误以为因为自身处于欧盟境外，该法案便不适用——实际上它具有域外效力。",
            "将 GPAI 义务与 AI 系统义务混为一谈；它们是不同的。",
            "强行附加无法真正及时干预的人工监督。",
            "文档记录不足：缺少技术文档 and 日志是常见的漏洞。"
          ],
          "examples": [
            "被归类为高风险的招聘筛选工具，需要文档记录、人工监督和监控。",
            "聊天机器人添加清晰的“您正在与 AI 对话”披露信息，以满足透明度义务。",
            "GPAI 提供商发布模型文档和训练数据摘要。"
          ],
          "faqs": [
            {
              "q": "EU AI Act 是否适用于欧盟境外的公司？",
              "a": "是的。它适用于将其 AI 系统投放到欧盟市场或其输出在欧盟境内使用的提供商和部署商，无论该公司的注册地在何处。"
            },
            {
              "q": "什么是“高风险”AI 系统？",
              "a": "用于敏感领域（例如就业、信贷、关键基础设施、特定生物识别）或作为受监管产品安全组件的系统。除禁用外，它们承担着最严格的合规义务。"
            },
            {
              "q": "它与“人机协同（human-in-the-loop）”有何关系？",
              "a": "第 14 条要求对高风险系统进行有效的人工监督——即由能够理解、干预或终止系统的人员进行监督。人工审批关卡模式是实现这一要求的一种方式。"
            }
          ]
        }
      }
    },
    {
      "id": "GOV-002",
      "slug": "iso-42001",
      "category": "standard",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/governance/iso-42001",
      "api": "https://santismm.com/api/governance/iso-42001",
      "canonical_url": "https://santismm.com/en/governance/iso-42001",
      "api_url": "https://santismm.com/api/governance/iso-42001",
      "evidence": {
        "evidenceLevel": "industry_observation",
        "confidenceLevel": "high",
        "sourceType": [
          "paper",
          "industry_observation"
        ]
      },
      "frameworks": [
        "ISO/IEC 42001"
      ],
      "patterns": [
        "human-approval-gate"
      ],
      "knowledge": [
        "ai-governance",
        "agentic-evaluation",
        "ai-observability",
        "guardrails"
      ],
      "references": [
        {
          "title": "ISO/IEC 42001:2023 — AI management system",
          "url": "https://www.iso.org/standard/81230.html"
        },
        {
          "title": "ISO — What is an AI management system?",
          "url": "https://www.iso.org/artificial-intelligence/ai-management-systems"
        }
      ],
      "related": [
        "eu-ai-act",
        "nist-ai-rmf",
        "agentic-ai-governance-checklist"
      ],
      "locales": {
        "en": {
          "name": "ISO/IEC 42001",
          "summary": "ISO/IEC 42001:2023 is the first international, certifiable standard for an AI management system (AIMS). Like ISO 27001 for information security, it defines how an organization should establish, implement, maintain and continually improve the way it governs AI — through a policy, defined roles, risk and impact assessments, a set of controls, and a Plan-Do-Check-Act improvement cycle. It is voluntary and certifiable, giving organizations a recognized way to demonstrate responsible AI management.",
          "definition": "ISO/IEC 42001 is a management-system standard that specifies requirements for establishing and continually improving an Artificial Intelligence Management System (AIMS) across an organization's AI lifecycle.",
          "scope": "Any organization that provides or uses AI, of any size or sector. It governs the management system around AI — not a specific product — so it complements product- or risk-specific frameworks rather than replacing them.",
          "keyPoints": [
            "A certifiable AI management system, structured like other ISO management standards.",
            "Requires an AI policy, leadership commitment and clearly assigned roles and responsibilities.",
            "Centres on AI risk assessment and AI system impact assessment.",
            "Provides a reference set of controls (Annex A) and implementation guidance (Annex B).",
            "Built on the Plan-Do-Check-Act cycle for continual improvement.",
            "Complements regulation (EU AI Act) and risk frameworks (NIST AI RMF)."
          ],
          "controls": [
            {
              "control": "AI policy & governance roles",
              "note": "Establish an organizational AI policy and assign accountable owners — governance starts with leadership, not tooling."
            },
            {
              "control": "AI risk assessment",
              "note": "Systematically identify, analyse and treat risks across the AI lifecycle, and keep the assessment current."
            },
            {
              "control": "AI system impact assessment",
              "note": "Assess impacts on individuals and society (fairness, safety, rights), not just technical risk."
            },
            {
              "control": "Lifecycle controls (Annex A)",
              "note": "Apply controls for data, design, deployment and operation, selecting those relevant to your context."
            },
            {
              "control": "Continual improvement (PDCA)",
              "note": "Audit, review and improve the management system on a cycle, so governance keeps pace with change."
            }
          ],
          "checklist": [
            "Define the AIMS scope and an organizational AI policy.",
            "Assign governance roles, responsibilities and leadership accountability.",
            "Run AI risk assessments and AI system impact assessments.",
            "Select and implement the relevant Annex A controls.",
            "Document objectives, processes and evidence of operation.",
            "Establish internal audit and management review.",
            "Run the Plan-Do-Check-Act cycle and pursue certification if desired."
          ],
          "pitfalls": [
            "Treating it as a one-off project rather than a continuing management system.",
            "Documenting a policy nobody operates against day to day.",
            "Confusing it with EU AI Act compliance — certification is not legal conformity.",
            "Skipping impact assessment and reducing it to technical risk only."
          ],
          "examples": [
            "A company standing up an AIMS to govern all its AI use under one policy and risk process.",
            "An impact assessment surfacing a fairness risk before a model ships.",
            "An annual internal audit and management review closing governance gaps."
          ],
          "faqs": [
            {
              "q": "Is ISO/IEC 42001 the same as complying with the EU AI Act?",
              "a": "No. The standard is a voluntary, certifiable management system; the EU AI Act is binding law. A well-run AIMS supports legal compliance but does not by itself satisfy it."
            },
            {
              "q": "Can you get certified?",
              "a": "Yes. Like ISO 27001, an accredited body can audit and certify an organization's AI management system against the standard."
            },
            {
              "q": "How does it relate to NIST AI RMF?",
              "a": "They are complementary: NIST AI RMF gives a risk-management framework and trustworthiness characteristics; ISO/IEC 42001 gives the certifiable management-system structure to operate governance continuously."
            }
          ]
        },
        "es": {
          "name": "ISO/IEC 42001",
          "summary": "ISO/IEC 42001:2023 es la primera norma internacional y certificable para un sistema de gestión de IA (AIMS). Igual que ISO 27001 para la seguridad de la información, define cómo una organización debe establecer, implementar, mantener y mejorar de forma continua la manera en que gobierna la IA: mediante una política, roles definidos, evaluaciones de riesgo e impacto, un conjunto de controles y un ciclo de mejora Planificar-Hacer-Verificar-Actuar. Es voluntaria y certificable, y ofrece una forma reconocida de demostrar una gestión responsable de la IA.",
          "definition": "ISO/IEC 42001 es una norma de sistema de gestión que especifica los requisitos para establecer y mejorar de forma continua un Sistema de Gestión de Inteligencia Artificial (AIMS) a lo largo del ciclo de vida de la IA de una organización.",
          "scope": "Cualquier organización que provea o use IA, de cualquier tamaño o sector. Gobierna el sistema de gestión en torno a la IA —no un producto concreto— por lo que complementa marcos específicos de producto o riesgo en vez de reemplazarlos.",
          "keyPoints": [
            "Un sistema de gestión de IA certificable, estructurado como otras normas de gestión ISO.",
            "Exige una política de IA, compromiso de la dirección y roles y responsabilidades claramente asignados.",
            "Se centra en la evaluación de riesgos de IA y la evaluación de impacto del sistema de IA.",
            "Proporciona un conjunto de controles de referencia (Anexo A) y guía de implementación (Anexo B).",
            "Se basa en el ciclo Planificar-Hacer-Verificar-Actuar para la mejora continua.",
            "Complementa la regulación (EU AI Act) y los marcos de riesgo (NIST AI RMF)."
          ],
          "controls": [
            {
              "control": "Política y roles de gobernanza de IA",
              "note": "Establece una política organizativa de IA y asigna responsables: la gobernanza empieza por la dirección, no por las herramientas."
            },
            {
              "control": "Evaluación de riesgos de IA",
              "note": "Identifica, analiza y trata los riesgos de forma sistemática a lo largo del ciclo de vida, y mantén la evaluación actualizada."
            },
            {
              "control": "Evaluación de impacto del sistema de IA",
              "note": "Evalúa los impactos en las personas y la sociedad (equidad, seguridad, derechos), no solo el riesgo técnico."
            },
            {
              "control": "Controles del ciclo de vida (Anexo A)",
              "note": "Aplica controles de datos, diseño, despliegue y operación, seleccionando los relevantes para tu contexto."
            },
            {
              "control": "Mejora continua (PDCA)",
              "note": "Audita, revisa y mejora el sistema de gestión de forma cíclica, para que la gobernanza siga el ritmo del cambio."
            }
          ],
          "checklist": [
            "Define el alcance del AIMS y una política organizativa de IA.",
            "Asigna roles de gobernanza, responsabilidades y rendición de cuentas de la dirección.",
            "Ejecuta evaluaciones de riesgos de IA y de impacto del sistema de IA.",
            "Selecciona e implementa los controles relevantes del Anexo A.",
            "Documenta objetivos, procesos y evidencia de operación.",
            "Establece auditoría interna y revisión por la dirección.",
            "Ejecuta el ciclo Planificar-Hacer-Verificar-Actuar y busca la certificación si lo deseas."
          ],
          "pitfalls": [
            "Tratarlo como un proyecto puntual en vez de un sistema de gestión continuo.",
            "Documentar una política contra la que nadie opera en el día a día.",
            "Confundirlo con el cumplimiento del EU AI Act: la certificación no es conformidad legal.",
            "Saltarse la evaluación de impacto y reducirla solo a riesgo técnico."
          ],
          "examples": [
            "Una empresa que monta un AIMS para gobernar todo su uso de IA bajo una política y un proceso de riesgo.",
            "Una evaluación de impacto que revela un riesgo de equidad antes de desplegar un modelo.",
            "Una auditoría interna y revisión por la dirección anuales que cierran brechas de gobernanza."
          ],
          "faqs": [
            {
              "q": "¿ISO/IEC 42001 es lo mismo que cumplir el EU AI Act?",
              "a": "No. La norma es un sistema de gestión voluntario y certificable; el EU AI Act es ley vinculante. Un AIMS bien llevado apoya el cumplimiento legal, pero no lo satisface por sí solo."
            },
            {
              "q": "¿Se puede certificar?",
              "a": "Sí. Igual que ISO 27001, un organismo acreditado puede auditar y certificar el sistema de gestión de IA de una organización frente a la norma."
            },
            {
              "q": "¿Cómo se relaciona con NIST AI RMF?",
              "a": "Son complementarios: NIST AI RMF da un marco de gestión de riesgos y características de confiabilidad; ISO/IEC 42001 da la estructura certificable de sistema de gestión para operar la gobernanza de forma continua."
            }
          ]
        },
        "pt": {
          "name": "ISO/IEC 42001",
          "summary": "A ISO/IEC 42001:2023 é a primeira norma internacional e certificável para um sistema de gestão de IA (AIMS). Assim como a ISO 27001 para a segurança da informação, ela define como uma organização deve estabelecer, implementar, manter e melhorar continuamente a forma como governa a IA: por meio de uma política, papéis definidos, avaliações de risco e impacto, um conjunto de controles e um ciclo de melhoria Planejar-Fazer-Verificar-Agir. É voluntária e certificável, oferecendo uma forma reconhecida de demonstrar uma gestão responsável da IA.",
          "definition": "A ISO/IEC 42001 é uma norma de sistema de gestão que especifica os requisitos para estabelecer e melhorar continuamente um Sistema de Gestão de Inteligência Artificial (AIMS) ao longo do ciclo de vida da IA de uma organização.",
          "scope": "Qualquer organização que forneça ou use IA, de qualquer tamanho ou setor. Governa o sistema de gestão em torno da IA —não um produto específico— por isso complementa frameworks específicos de produto ou risco em vez de substituí-los.",
          "keyPoints": [
            "Um sistema de gestão de IA certificável, estruturado como outras normas de gestão ISO.",
            "Exige uma política de IA, comprometimento da liderança e papéis e responsabilidades claramente atribuídos.",
            "Centra-se na avaliação de riscos de IA e na avaliação de impacto do sistema de IA.",
            "Fornece um conjunto de controles de referência (Anexo A) e orientação de implementação (Anexo B).",
            "Baseia-se no ciclo Planejar-Fazer-Verificar-Agir para a melhoria contínua.",
            "Complementa a regulação (EU AI Act) e os frameworks de risco (NIST AI RMF)."
          ],
          "controls": [
            {
              "control": "Política e papéis de governança de IA",
              "note": "Estabeleça uma política organizacional de IA e atribua responsáveis: a governança começa pela liderança, não pelas ferramentas."
            },
            {
              "control": "Avaliação de riscos de IA",
              "note": "Identifique, analise e trate os riscos de forma sistemática ao longo do ciclo de vida, e mantenha a avaliação atualizada."
            },
            {
              "control": "Avaliação de impacto do sistema de IA",
              "note": "Avalie os impactos nas pessoas e na sociedade (equidade, segurança, direitos), não só o risco técnico."
            },
            {
              "control": "Controles do ciclo de vida (Anexo A)",
              "note": "Aplique controles de dados, design, implantação e operação, selecionando os relevantes para o seu contexto."
            },
            {
              "control": "Melhoria contínua (PDCA)",
              "note": "Audite, revise e melhore o sistema de gestão de forma cíclica, para que a governança acompanhe a mudança."
            }
          ],
          "checklist": [
            "Defina o escopo do AIMS e uma política organizacional de IA.",
            "Atribua papéis de governança, responsabilidades e prestação de contas da liderança.",
            "Execute avaliações de riscos de IA e de impacto do sistema de IA.",
            "Selecione e implemente os controles relevantes do Anexo A.",
            "Documente objetivos, processos e evidência de operação.",
            "Estabeleça auditoria interna e análise crítica pela direção.",
            "Execute o ciclo Planejar-Fazer-Verificar-Agir e busque a certificação se desejar."
          ],
          "pitfalls": [
            "Tratá-la como um projeto pontual em vez de um sistema de gestão contínuo.",
            "Documentar uma política contra a qual ninguém opera no dia a dia.",
            "Confundi-la com a conformidade ao EU AI Act: a certificação não é conformidade legal.",
            "Pular a avaliação de impacto e reduzi-la apenas a risco técnico."
          ],
          "examples": [
            "Uma empresa que monta um AIMS para governar todo o seu uso de IA sob uma política e um processo de risco.",
            "Uma avaliação de impacto que revela um risco de equidade antes de implantar um modelo.",
            "Uma auditoria interna e análise crítica pela direção anuais que fecham lacunas de governança."
          ],
          "faqs": [
            {
              "q": "ISO/IEC 42001 é o mesmo que cumprir o EU AI Act?",
              "a": "Não. A norma é um sistema de gestão voluntário e certificável; o EU AI Act é lei vinculante. Um AIMS bem conduzido apoia a conformidade legal, mas não a satisfaz por si só."
            },
            {
              "q": "É possível se certificar?",
              "a": "Sim. Assim como a ISO 27001, um organismo acreditado pode auditar e certificar o sistema de gestão de IA de uma organização frente à norma."
            },
            {
              "q": "Como se relaciona com o NIST AI RMF?",
              "a": "São complementares: o NIST AI RMF dá um framework de gestão de riscos e características de confiabilidade; a ISO/IEC 42001 dá a estrutura certificável de sistema de gestão para operar a governança de forma contínua."
            }
          ]
        },
        "fr": {
          "name": "ISO/IEC 42001",
          "summary": "La norme ISO/IEC 42001:2023 est la première norme internationale certifiable pour un système de management de l'IA (SMI). À l'instar de l'ISO 27001 pour la sécurité de l'information, elle définit la manière dont une organisation doit établir, implémenter, maintenir et améliorer continuellement sa gouvernance de l'IA — à travers une politique, des rôles définis, des évaluations des risques et des impacts, un ensemble de mesures de contrôle et un cycle d'amélioration Plan-Do-Check-Act (Planifier-Déployer-Contrôler-Agir). Volontaire et certifiable, elle offre aux organisations un moyen reconnu de démontrer une gestion responsable de l'IA.",
          "definition": "L'ISO/IEC 42001 est une norme de système de management qui spécifie les exigences pour établir et améliorer continuellement un système de management de l'intelligence artificielle (SMI) tout au long du cycle de vie de l'IA au sein d'une organisation.",
          "scope": "Toute organisation qui fournit ou utilise de l'IA, quels que soient sa taille ou son secteur. Elle régit le système de management autour de l'IA — et non un produit spécifique — de sorte qu'elle complète les cadres spécifiques aux produits ou aux risques plutôt que de les remplacer.",
          "keyPoints": [
            "Un système de management de l'IA certifiable, structuré comme les autres normes de management ISO.",
            "Exige une politique d'IA, un engagement de la direction et des rôles et responsabilités clairement attribués.",
            "S'articule autour de l'évaluation des risques liés à l'IA et de l'évaluation d'impact du système d'IA.",
            "Fournit un ensemble de mesures de contrôle de référence (Annexe A) et des directives de mise en œuvre (Annexe B).",
            "Repose sur le cycle Plan-Do-Check-Act pour une amélioration continue.",
            "Complète la réglementation (Règlement européen sur l'IA) et les cadres de gestion des risques (NIST AI RMF)."
          ],
          "controls": [
            {
              "control": "Politique d'IA et rôles de gouvernance",
              "note": "Établir une politique d'IA organisationnelle et attribuer des responsables redevables — la gouvernance commence par le leadership, pas par l'outillage."
            },
            {
              "control": "Évaluation des risques liés à l'IA",
              "note": "Identifier, analyser et traiter systématiquement les risques tout au long du cycle de vie de l'IA, et maintenir l'évaluation à jour."
            },
            {
              "control": "Évaluation d'impact du système d'IA",
              "note": "Évaluer les impacts sur les individus et la société (équité, sécurité, droits), et pas seulement le risque technique."
            },
            {
              "control": "Mesures de contrôle du cycle de vie (Annexe A)",
              "note": "Appliquer des mesures de contrôle pour les données, la conception, le déploiement et l'exploitation, en sélectionnant celles qui sont pertinentes pour votre contexte."
            },
            {
              "control": "Amélioration continue (PDCA)",
              "note": "Auditer, examiner et améliorer périodiquement le système de management, afin que la gouvernance suive le rythme des évolutions."
            }
          ],
          "checklist": [
            "Définir le périmètre du SMI et une politique d'IA organisationnelle.",
            "Attribuer les rôles de gouvernance, les responsabilités et la redevabilité de la direction.",
            "Réaliser des évaluations des risques liés à l'IA et des évaluations d'impact du système d'IA.",
            "Sélectionner et implémenter les mesures de contrôle pertinentes de l'Annexe A.",
            "Documenter les objectifs, les processus et les preuves de fonctionnement.",
            "Établir un audit interne et une revue de direction.",
            "Exécuter le cycle Plan-Do-Check-Act et viser la certification si souhaité."
          ],
          "pitfalls": [
            "Le traiter comme un projet ponctuel plutôt que comme un système de management continu.",
            "Documenter une politique que personne n'applique au quotidien.",
            "Le confondre avec la conformité au Règlement européen sur l'IA — la certification ne constitue pas une conformité légale.",
            "Faire l'impasse sur l'évaluation d'impact et la réduire au seul risque technique."
          ],
          "examples": [
            "Une entreprise mettant en place un SMI pour régir l'ensemble de son utilisation de l'IA sous une politique et un processus de gestion des risques uniques.",
            "Une évaluation d'impact mettant en évidence un risque d'équité avant le déploiement d'un modèle.",
            "Un audit interne annuel et une revue de direction comblant les lacunes de gouvernance."
          ],
          "faqs": [
            {
              "q": "L'ISO/IEC 42001 est-elle équivalente à la conformité au Règlement européen sur l'IA ?",
              "a": "Non. La norme est un système de management volontaire et certifiable ; le Règlement européen sur l'IA est une loi contraignante. Un SMI bien géré facilite la conformité légale, mais ne suffit pas à lui seul à la garantir."
            },
            {
              "q": "Est-il possible de se faire certifier ?",
              "a": "Oui. À l'instar de l'ISO 27001, un organisme accrédité peut auditer et certifier le système de management de l'IA d'une organisation par rapport à la norme."
            },
            {
              "q": "Quel est le lien avec le NIST AI RMF ?",
              "a": "Ils sont complémentaires : le NIST AI RMF fournit un cadre de gestion des risques et des caractéristiques de fiabilité ; l'ISO/IEC 42001 apporte la structure de système de management certifiable pour faire fonctionner la gouvernance en continu."
            }
          ]
        },
        "de": {
          "name": "ISO/IEC 42001",
          "summary": "ISO/IEC 42001:2023 ist der erste internationale, zertifizierbare Standard für ein KI-Managementsystem (KIMS bzw. AIMS). Ähnlich wie ISO 27001 für Informationssicherheit definiert er, wie eine Organisation die Steuerung von KI etablieren, implementieren, aufrechterhalten und kontinuierlich verbessern sollte – durch eine Richtlinie, definierte Rollen, Risiko- und Folgenabschätzungen, eine Reihe von Kontrollmaßnahmen (Controls) und einen Plan-Do-Check-Act-Verbesserungszyklus. Er ist freiwillig und zertifizierbar und bietet Organisationen eine anerkannte Möglichkeit, ein verantwortungsvolles KI-Management nachzuweisen.",
          "definition": "ISO/IEC 42001 ist ein Managementsystem-Standard, der Anforderungen für die Einrichtung und kontinuierliche Verbesserung eines Künstliche-Intelligenz-Managementsystems (AIMS) über den gesamten KI-Lebenszyklus einer Organisation hinweg festlegt.",
          "scope": "Jede Organisation, die KI bereitstellt oder nutzt, unabhängig von Größe oder Branche. Er regelt das Managementsystem rund um KI – nicht ein bestimmtes Produkt – und ergänzt somit produkt- oder risikospezifische Frameworks, anstatt sie zu ersetzen.",
          "keyPoints": [
            "Ein zertifizierbares KI-Managementsystem, strukturiert wie andere ISO-Managementstandards.",
            "Erfordert eine KI-Richtlinie, das Engagement der Führungsebene sowie klar zugewiesene Rollen und Verantwortlichkeiten.",
            "Konzentriert sich auf die KI-Risikobewertung und die Folgenabschätzung für KI-Systeme.",
            "Bietet einen Referenzsatz von Kontrollmaßnahmen (Anhang A) und eine Anleitung zur Implementierung (Anhang B).",
            "Basiert auf dem Plan-Do-Check-Act-Zyklus zur kontinuierlichen Verbesserung.",
            "Ergänzt Regulierungen (EU AI Act) und Risiko-Frameworks (NIST AI RMF)."
          ],
          "controls": [
            {
              "control": "KI-Richtlinie und Governance-Rollen",
              "note": "Etablieren Sie eine organisatorische KI-Richtlinie und weisen Sie verantwortliche Eigentümer zu – Governance beginnt bei der Führung, nicht bei den Tools."
            },
            {
              "control": "KI-Risikobewertung",
              "note": "Identifizieren, analysieren und behandeln Sie Risiken systematisch über den gesamten KI-Lebenszyklus hinweg und halten Sie die Bewertung auf dem neuesten Stand."
            },
            {
              "control": "Folgenabschätzung für KI-Systeme",
              "note": "Bewerten Sie die Auswirkungen auf Einzelpersonen und die Gesellschaft (Fairness, Sicherheit, Rechte), nicht nur technische Risiken."
            },
            {
              "control": "Lebenszyklus-Kontrollen (Anhang A)",
              "note": "Wenden Sie Kontrollmaßnahmen für Daten, Design, Bereitstellung und Betrieb an und wählen Sie diejenigen aus, die für Ihren Kontext relevant sind."
            },
            {
              "control": "Kontinuierliche Verbesserung (PDCA)",
              "note": "Auditieren, überprüfen und verbessern Sie das Managementsystem in einem regelmäßigen Zyklus, damit die Governance mit dem Wandel Schritt hält."
            }
          ],
          "checklist": [
            "Definieren Sie den Anwendungsbereich des AIMS und eine organisatorische KI-Richtlinie.",
            "Weisen Sie Governance-Rollen, Verantwortlichkeiten und die Rechenschaftspflicht der Führungsebene zu.",
            "Führen Sie KI-Risikobewertungen und Folgenabschätzungen für KI-Systeme durch.",
            "Wählen Sie die relevanten Kontrollmaßnahmen aus Anhang A aus und implementieren Sie diese.",
            "Dokumentieren Sie Ziele, Prozesse und Nachweise des Betriebs.",
            "Richten Sie interne Audits und Managementbewertungen ein.",
            "Führen Sie den Plan-Do-Check-Act-Zyklus aus und streben Sie bei Bedarf eine Zertifizierung an."
          ],
          "pitfalls": [
            "Es als einmaliges Projekt zu behandeln, anstatt als kontinuierliches Managementsystem.",
            "Eine Richtlinie zu dokumentieren, nach der im Alltag niemand arbeitet.",
            "Es mit der Einhaltung des EU AI Act zu verwechseln – eine Zertifizierung ist keine rechtliche Konformität.",
            "Die Folgenabschätzung zu überspringen und sie nur auf technische Risiken zu reduzieren."
          ],
          "examples": [
            "Ein Unternehmen, das ein AIMS einrichtet, um seine gesamte KI-Nutzung unter einer einzigen Richtlinie und einem einzigen Risikoprozess zu steuern.",
            "Eine Folgenabschätzung, die ein Fairness-Risiko aufdeckt, bevor ein Modell bereitgestellt wird.",
            "Ein jährliches internes Audit und eine Managementbewertung, die Governance-Lücken schließen."
          ],
          "faqs": [
            {
              "q": "Ist ISO/IEC 42001 dasselbe wie die Einhaltung des EU AI Act?",
              "a": "Nein. Der Standard ist ein freiwilliges, zertifizierbares Managementsystem; der EU AI Act ist bindendes Recht. Ein gut geführtes AIMS unterstützt die Einhaltung gesetzlicher Vorschriften, erfüllt diese jedoch nicht von sich aus."
            },
            {
              "q": "Kann man sich zertifizieren lassen?",
              "a": "Ja. Ähnlich wie bei ISO 27001 kann eine akkreditierte Stelle das KI-Managementsystem einer Organisation auditieren und nach dem Standard zertifizieren."
            },
            {
              "q": "Wie verhält es sich zum NIST AI RMF?",
              "a": "Sie ergänzen sich: Das NIST AI RMF bietet ein Risikomanagement-Framework und Vertrauenswürdigkeitsmerkmale; ISO/IEC 42001 liefert die zertifizierbare Managementsystem-Struktur, um Governance kontinuierlich zu betreiben."
            }
          ]
        },
        "ja": {
          "name": "ISO/IEC 42001",
          "summary": "ISO/IEC 42001:2023は、AIマネジメントシステム（AIMS）に関する初の国際的かつ認証可能な規格です。情報セキュリティにおけるISO 27001と同様に、組織がAIガバナンスを確立、実施、維持、および継続的に改善する方法を、方針、定義された役割、リスクおよび影響評価、管理策のセット、およびPlan-Do-Check-Act（PDCA）改善サイクルを通じて定義します。これは任意かつ認証可能であり、組織が責任あるAI管理を実証するための認められた手段を提供します。",
          "definition": "ISO/IEC 42001は、組織のAIライフサイクル全体にわたってAIマネジメントシステム（AIMS）を確立し、継続的に改善するための要求事項を規定するマネジメントシステム規格です。",
          "scope": "規模やセクターを問わず、AIを提供または利用するすべての組織。これは特定の製品ではなく、AIを取り巻くマネジメントシステムを管理するものであるため、製品固有またはリスク固有のフレームワークを代替するものではなく、それらを補完します。",
          "keyPoints": [
            "他のISOマネジメント規格と同様に構成された、認証可能なAIマネジメントシステム。",
            "AI方針、リーダーシップのコミットメント、および明確に割り当てられた役割と責任を要求します。",
            "AIリスク評価とAIシステム影響評価を中心に据えています。",
            "管理策の参照セット（附属書A）と実施ガイダンス（附属書B）を提供します。",
            "継続的改善のためのPlan-Do-Check-Act（PDCA）サイクルに基づいています。",
            "規制（EU AI法）やリスクフレームワーク（NIST AI RMF）を補完します。"
          ],
          "controls": [
            {
              "control": "AI方針とガバナンスの役割",
              "note": "組織のAI方針を確立し、責任あるオーナーを割り当てます。ガバナンスはツールではなく、リーダーシップから始まります。"
            },
            {
              "control": "AIリスク評価",
              "note": "AIライフサイクル全体にわたるリスクを体系的に特定、分析、および対処し、評価を最新の状態に維持します。"
            },
            {
              "control": "AIシステム影響評価",
              "note": "技術的なリスクだけでなく、個人や社会への影響（公平性、安全性、権利）を評価します。"
            },
            {
              "control": "ライフサイクル管理策（附属書A）",
              "note": "データ、設計、デプロイ、および運用に関する管理策を適用し、コンテキストに関連するものを選択します。"
            },
            {
              "control": "継続的改善（PDCA）",
              "note": "マネジメントシステムを定期的に監査、レビュー、および改善し、ガバナンスが変化に対応できるようにします。"
            }
          ],
          "checklist": [
            "AIMSの適用範囲と組織のAI方針を定義します。",
            "ガバナンスの役割、責任、およびリーダーシップの責任を割り当てます。",
            "AIリスク評価とAIシステム影響評価を実行します。",
            "関連する附属書Aの管理策を選択し、実装します。",
            "目標、プロセス、および運用の証拠を文書化します。",
            "内部監査とマネジメントレビューを確立します。",
            "Plan-Do-Check-Act（PDCA）サイクルを実行し、必要に応じて認証取得を目指します。"
          ],
          "pitfalls": [
            "継続的なマネジメントシステムとしてではなく、単発のプロジェクトとして扱ってしまうこと。",
            "日常業務で誰も従わない方針を文書化してしまうこと。",
            "EU AI法への準拠と混同してしまうこと。認証は法的適合性を意味するものではありません。",
            "影響評価をスキップし、技術的なリスクのみに矮小化してしまうこと。"
          ],
          "examples": [
            "単一の方針とリスクプロセスの下で、すべてのAI利用を管理するためにAIMSを立ち上げる企業。",
            "モデルのリリース前に、影響評価によって公平性のリスクが明らかになるケース。",
            "年に一度の内部監査とマネジメントレビューによって、ガバナンスのギャップを解消するケース。"
          ],
          "faqs": [
            {
              "q": "ISO/IEC 42001は、EU AI法に準拠することと同じですか？",
              "a": "いいえ。この規格は任意で認証可能なマネジメントシステムであり、EU AI法は拘束力のある法律です。適切に運用されているAIMSは法的遵守をサポートしますが、それ自体で法を満たすものではありません。"
            },
            {
              "q": "認証を取得することはできますか？",
              "a": "はい。ISO 27001と同様に、認定された機関が組織のAIマネジメントシステムを監査し、規格に適合していることを認証できます。"
            },
            {
              "q": "NIST AI RMFとはどのような関係がありますか？",
              "a": "これらは補完関係にあります。NIST AI RMFはリスクマネジメントフレームワークと信頼性の特性を提供し、ISO/IEC 42001はガバナンスを継続的に運用するための認証可能なマネジメントシステム構造を提供します。"
            }
          ]
        },
        "zh": {
          "name": "ISO/IEC 42001",
          "summary": "ISO/IEC 42001:2023 是首个针对人工智能管理体系（AIMS）的国际可认证标准。与用于信息安全的 ISO 27001 类似，它定义了组织应如何建立、实施、维护和持续改进其治理 AI 的方式——通过政策、定义的角色、风险和影响评估、一套控制措施以及“策划-实施-检查-处置”（PDCA）改进循环。它是自愿且可认证的，为组织提供了一种公认的方式来证明其负责任的 AI 管理。",
          "definition": "ISO/IEC 42001 是一项管理体系标准，规定了在组织的 AI 生命周期中建立和持续改进人工智能管理体系（AIMS）的要求。",
          "scope": "任何提供或使用 AI 的组织，无论规模或行业。它治理的是围绕 AI 的管理体系，而非特定产品，因此它与特定产品或特定风险的框架相辅相成，而不是取而代之。",
          "keyPoints": [
            "一个可认证的 AI 管理体系，其结构与其他 ISO management 标准类似。",
            "需要 AI 政策、领导层承诺以及明确分配的角色和职责。",
            "以 AI 风险评估和 AI 系统影响评估为中心。",
            "提供了一套参考控制措施（附录 A）和实施指南（附录 B）。",
            "基于“策划-实施-检查-处置”（PDCA）循环以实现持续改进。",
            "与法规（欧盟《AI 法案》）和风险框架（NIST AI RMF）相辅相成。"
          ],
          "controls": [
            {
              "control": "AI 政策与治理角色",
              "note": "建立组织级 AI 政策并分配负责的拥有者——治理始于领导层，而非工具。"
            },
            {
              "control": "AI 风险评估",
              "note": "系统地识别、分析和应对整个 AI 生命周期中的风险，并保持评估的最新状态。"
            },
            {
              "control": "AI 系统影响评估",
              "note": "评估对个人和组织/社会的影响（公平性、安全、权利），而不仅仅是技术风险。"
            },
            {
              "control": "生命周期控制措施（附录 A）",
              "note": "对数据、设计、部署和运行实施控制措施，选择与您的具体背景相关的控制措施。"
            },
            {
              "control": "持续改进（PDCA）",
              "note": "循环进行审计、评审和改进管理体系，使治理与变化保持同步。"
            }
          ],
          "checklist": [
            "定义 AIMS 范围和组织级 AI 政策。",
            "分配治理角色、职责和领导层问责制。",
            "开展 AI 风险评估和 AI 系统影响评估。",
            "选择并实施相关的附录 A 控制措施。",
            "记录目标、流程 and 运行证据。",
            "建立内部审计和管理评审机制。",
            "运行“策划-实施-检查-处置”（PDCA）循环，并根据需要寻求认证。"
          ],
          "pitfalls": [
            "将其视为一次性项目，而不是持续运行的管理体系。",
            "编写了一套在日常工作中无人执行的政策。",
            "将其与欧盟《AI 法案》合规性混淆——获得认证并不等同于法律合规。",
            "跳过影响评估，将其简化为仅针对技术风险的评估。"
          ],
          "examples": [
            "一家公司建立 AIMS，在统一的政策和风险流程下治理其所有的 AI 使用。",
            "在模型发布前，通过影响评估发现公平性风险。",
            "通过年度内部审计和管理评审来弥补治理差距。"
          ],
          "faqs": [
            {
              "q": "ISO/IEC 42001 是否等同于遵守欧盟《AI 法案》？",
              "a": "不等同。该标准是一个自愿性的、可认证的管理体系；而欧盟《AI 法案》是具有约束力的法律。运行良好的 AIMS 有助于法律合规，但其本身并不能直接等同于满足法律要求。"
            },
            {
              "q": "可以获得认证吗？",
              "a": "可以。与 ISO 27001 类似，认可的机构可以根据该标准对组织的 AI 管理体系进行审计和认证。"
            },
            {
              "q": "它与 NIST AI RMF 有何关系？",
              "a": "它们是互补的：NIST AI RMF 提供了风险管理框架和可信赖特征；而 ISO/IEC 42001 则提供了可认证的管理体系结构，以持续运行治理工作。"
            }
          ]
        }
      }
    },
    {
      "id": "GOV-003",
      "slug": "nist-ai-rmf",
      "category": "framework",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/governance/nist-ai-rmf",
      "api": "https://santismm.com/api/governance/nist-ai-rmf",
      "canonical_url": "https://santismm.com/en/governance/nist-ai-rmf",
      "api_url": "https://santismm.com/api/governance/nist-ai-rmf",
      "evidence": {
        "evidenceLevel": "industry_observation",
        "confidenceLevel": "high",
        "sourceType": [
          "paper",
          "industry_observation"
        ]
      },
      "frameworks": [
        "NIST AI RMF"
      ],
      "patterns": [
        "human-approval-gate",
        "evaluator-optimizer"
      ],
      "knowledge": [
        "ai-governance",
        "agentic-evaluation",
        "ai-observability",
        "guardrails"
      ],
      "references": [
        {
          "title": "NIST — AI Risk Management Framework (AI RMF 1.0)",
          "url": "https://www.nist.gov/itl/ai-risk-management-framework"
        },
        {
          "title": "NIST AI 600-1 — Generative AI Profile",
          "url": "https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence"
        }
      ],
      "related": [
        "eu-ai-act",
        "iso-42001",
        "agentic-ai-governance-checklist",
        "owasp-llm-top10",
        "mitre-atlas"
      ],
      "locales": {
        "en": {
          "name": "NIST AI Risk Management Framework",
          "summary": "The NIST AI RMF 1.0 is a voluntary, widely-adopted framework for managing AI risk across the lifecycle. It is organized around four functions — Govern, Map, Measure and Manage — and a set of characteristics of trustworthy AI (valid and reliable, safe, secure and resilient, accountable and transparent, explainable, privacy-enhanced, and fair with harmful bias managed). A companion Generative AI Profile adapts it to GenAI risks. Unlike the EU AI Act it is not law, but it is a common backbone for operational AI governance.",
          "definition": "The NIST AI Risk Management Framework is a voluntary framework that helps organizations govern, map, measure and manage the risks of AI systems while pursuing the characteristics of trustworthy AI.",
          "scope": "Any organization designing, developing, deploying or using AI, in any sector. It is voluntary and outcome-focused, designed to be tailored to context and used alongside standards and regulation.",
          "keyPoints": [
            "Four core functions: Govern (culture & accountability), Map (context & risks), Measure (assess & track), Manage (prioritize & respond).",
            "Govern is cross-cutting — it underpins the other three.",
            "Defines characteristics of trustworthy AI to aim for, not just risks to avoid.",
            "A companion Generative AI Profile (NIST AI 600-1) addresses GenAI-specific risks.",
            "Voluntary and flexible — meant to be tailored, not certified against.",
            "Pairs well with ISO/IEC 42001 (management system) and the EU AI Act (law)."
          ],
          "controls": [
            {
              "control": "Govern",
              "note": "Establish the policies, accountability, culture and roles that make risk management real — the foundation the other functions stand on."
            },
            {
              "control": "Map",
              "note": "Establish context: intended use, stakeholders, and the risks and impacts of the AI system before building."
            },
            {
              "control": "Measure",
              "note": "Use quantitative and qualitative methods to assess, benchmark and monitor risk and trustworthiness — you can't manage what you don't measure."
            },
            {
              "control": "Manage",
              "note": "Prioritize, respond to and track risks over time, including incident response and decommissioning."
            },
            {
              "control": "Trustworthiness characteristics",
              "note": "Steer toward valid, safe, secure, accountable, explainable, privacy-enhanced and fair outcomes as explicit design targets."
            }
          ],
          "checklist": [
            "Stand up the Govern function: policy, accountability and roles.",
            "Map each system's context, intended use, stakeholders and risks.",
            "Define metrics and Measure validity, safety, security, bias and robustness.",
            "Manage: prioritize risks, plan responses and track them over time.",
            "Apply the Generative AI Profile for GenAI systems.",
            "Set incident response and monitoring for deployed systems.",
            "Map the framework to your obligations under ISO 42001 and the EU AI Act."
          ],
          "pitfalls": [
            "Doing Map and Measure but neglecting Govern, so nothing is accountable.",
            "Measuring what's easy instead of what matters for trustworthiness.",
            "Treating it as a checklist rather than a continuous risk practice.",
            "Ignoring the Generative AI Profile for LLM and agentic systems."
          ],
          "examples": [
            "A team using Map to document an agent's intended use and stakeholders before building.",
            "A Measure step benchmarking a model for bias and robustness against an eval set.",
            "A Manage process with incident response for a deployed GenAI assistant."
          ],
          "faqs": [
            {
              "q": "Is the NIST AI RMF mandatory?",
              "a": "No. It is a voluntary framework. But it is widely adopted as a common language and backbone for operational AI risk management, and often referenced in policy and procurement."
            },
            {
              "q": "What are the four functions?",
              "a": "Govern, Map, Measure and Manage. Govern is cross-cutting and supports the other three, which run across the AI lifecycle."
            },
            {
              "q": "How does it handle generative AI?",
              "a": "Through the companion Generative AI Profile (NIST AI 600-1), which identifies GenAI-specific risks and suggested actions mapped to the four functions."
            }
          ]
        },
        "es": {
          "name": "Marco de Gestión de Riesgos de IA del NIST",
          "summary": "El NIST AI RMF 1.0 es un marco voluntario y ampliamente adoptado para gestionar el riesgo de la IA a lo largo de su ciclo de vida. Se organiza en torno a cuatro funciones —Gobernar, Mapear, Medir y Gestionar— y un conjunto de características de IA confiable (válida y fiable, segura, resistente, responsable y transparente, explicable, con privacidad reforzada y justa con el sesgo dañino gestionado). Un Perfil de IA Generativa lo adapta a los riesgos de la GenAI. A diferencia del EU AI Act no es ley, pero es una columna vertebral común para la gobernanza operativa de la IA.",
          "definition": "El Marco de Gestión de Riesgos de IA del NIST es un marco voluntario que ayuda a las organizaciones a gobernar, mapear, medir y gestionar los riesgos de los sistemas de IA mientras persiguen las características de la IA confiable.",
          "scope": "Cualquier organización que diseñe, desarrolle, despliegue o use IA, en cualquier sector. Es voluntario y orientado a resultados, pensado para adaptarse al contexto y usarse junto a normas y regulación.",
          "keyPoints": [
            "Cuatro funciones centrales: Gobernar (cultura y rendición de cuentas), Mapear (contexto y riesgos), Medir (evaluar y seguir), Gestionar (priorizar y responder).",
            "Gobernar es transversal: sustenta a las otras tres.",
            "Define características de IA confiable a perseguir, no solo riesgos a evitar.",
            "Un Perfil de IA Generativa (NIST AI 600-1) aborda los riesgos específicos de la GenAI.",
            "Voluntario y flexible: pensado para adaptarse, no para certificarse.",
            "Encaja bien con ISO/IEC 42001 (sistema de gestión) y el EU AI Act (ley)."
          ],
          "controls": [
            {
              "control": "Gobernar",
              "note": "Establece las políticas, la rendición de cuentas, la cultura y los roles que hacen real la gestión de riesgos: la base sobre la que se apoyan las demás funciones."
            },
            {
              "control": "Mapear",
              "note": "Establece el contexto: uso previsto, partes interesadas, y los riesgos e impactos del sistema de IA antes de construir."
            },
            {
              "control": "Medir",
              "note": "Usa métodos cuantitativos y cualitativos para evaluar, comparar y monitorizar el riesgo y la confiabilidad: no puedes gestionar lo que no mides."
            },
            {
              "control": "Gestionar",
              "note": "Prioriza, responde y haz seguimiento de los riesgos en el tiempo, incluyendo respuesta a incidentes y retirada."
            },
            {
              "control": "Características de confiabilidad",
              "note": "Dirige hacia resultados válidos, seguros, responsables, explicables, con privacidad reforzada y justos como objetivos de diseño explícitos."
            }
          ],
          "checklist": [
            "Pon en marcha la función Gobernar: política, rendición de cuentas y roles.",
            "Mapea el contexto, el uso previsto, las partes interesadas y los riesgos de cada sistema.",
            "Define métricas y Mide validez, seguridad, sesgo y robustez.",
            "Gestiona: prioriza riesgos, planifica respuestas y haz seguimiento en el tiempo.",
            "Aplica el Perfil de IA Generativa para los sistemas de GenAI.",
            "Establece respuesta a incidentes y monitorización para los sistemas desplegados.",
            "Mapea el marco a tus obligaciones bajo ISO 42001 y el EU AI Act."
          ],
          "pitfalls": [
            "Hacer Mapear y Medir pero descuidar Gobernar, de modo que nada es responsable.",
            "Medir lo fácil en vez de lo que importa para la confiabilidad.",
            "Tratarlo como una lista de verificación en vez de una práctica continua de riesgo.",
            "Ignorar el Perfil de IA Generativa para sistemas LLM y agénticos."
          ],
          "examples": [
            "Un equipo que usa Mapear para documentar el uso previsto y las partes interesadas de un agente antes de construir.",
            "Un paso de Medir que compara un modelo en sesgo y robustez frente a un conjunto de evaluación.",
            "Un proceso de Gestionar con respuesta a incidentes para un asistente de GenAI desplegado."
          ],
          "faqs": [
            {
              "q": "¿El NIST AI RMF es obligatorio?",
              "a": "No. Es un marco voluntario. Pero está ampliamente adoptado como lenguaje común y columna vertebral para la gestión operativa del riesgo de IA, y se referencia a menudo en políticas y compras."
            },
            {
              "q": "¿Cuáles son las cuatro funciones?",
              "a": "Gobernar, Mapear, Medir y Gestionar. Gobernar es transversal y sustenta a las otras tres, que recorren el ciclo de vida de la IA."
            },
            {
              "q": "¿Cómo aborda la IA generativa?",
              "a": "Mediante el Perfil de IA Generativa complementario (NIST AI 600-1), que identifica riesgos específicos de la GenAI y acciones sugeridas mapeadas a las cuatro funciones."
            }
          ]
        },
        "pt": {
          "name": "Framework de Gestão de Riscos de IA do NIST",
          "summary": "O NIST AI RMF 1.0 é um framework voluntário e amplamente adotado para gerir o risco da IA ao longo do seu ciclo de vida. Organiza-se em torno de quatro funções —Governar, Mapear, Medir e Gerir— e um conjunto de características de IA confiável (válida e confiável, segura, resiliente, responsável e transparente, explicável, com privacidade reforçada e justa com o viés prejudicial gerido). Um Perfil de IA Generativa o adapta aos riscos da GenAI. Diferente do EU AI Act, não é lei, mas é uma espinha dorsal comum para a governança operacional da IA.",
          "definition": "O Framework de Gestão de Riscos de IA do NIST é um framework voluntário que ajuda as organizações a governar, mapear, medir e gerir os riscos dos sistemas de IA enquanto perseguem as características da IA confiável.",
          "scope": "Qualquer organização que projete, desenvolva, implante ou use IA, em qualquer setor. É voluntário e orientado a resultados, pensado para se adaptar ao contexto e ser usado junto a normas e regulação.",
          "keyPoints": [
            "Quatro funções centrais: Governar (cultura e prestação de contas), Mapear (contexto e riscos), Medir (avaliar e acompanhar), Gerir (priorizar e responder).",
            "Governar é transversal: sustenta as outras três.",
            "Define características de IA confiável a perseguir, não só riscos a evitar.",
            "Um Perfil de IA Generativa (NIST AI 600-1) aborda os riscos específicos da GenAI.",
            "Voluntário e flexível: pensado para se adaptar, não para se certificar.",
            "Combina bem com a ISO/IEC 42001 (sistema de gestão) e o EU AI Act (lei)."
          ],
          "controls": [
            {
              "control": "Governar",
              "note": "Estabeleça as políticas, a prestação de contas, a cultura e os papéis que tornam a gestão de riscos real: a base sobre a qual as demais funções se apoiam."
            },
            {
              "control": "Mapear",
              "note": "Estabeleça o contexto: uso pretendido, partes interessadas, e os riscos e impactos do sistema de IA antes de construir."
            },
            {
              "control": "Medir",
              "note": "Use métodos quantitativos e qualitativos para avaliar, comparar e monitorar o risco e a confiabilidade: você não gere o que não mede."
            },
            {
              "control": "Gerir",
              "note": "Priorize, responda e acompanhe os riscos ao longo do tempo, incluindo resposta a incidentes e descomissionamento."
            },
            {
              "control": "Características de confiabilidade",
              "note": "Direcione para resultados válidos, seguros, responsáveis, explicáveis, com privacidade reforçada e justos como metas de design explícitas."
            }
          ],
          "checklist": [
            "Coloque em marcha a função Governar: política, prestação de contas e papéis.",
            "Mapeie o contexto, o uso pretendido, as partes interessadas e os riscos de cada sistema.",
            "Defina métricas e Meça validade, segurança, viés e robustez.",
            "Gerencie: priorize riscos, planeje respostas e acompanhe ao longo do tempo.",
            "Aplique o Perfil de IA Generativa para os sistemas de GenAI.",
            "Estabeleça resposta a incidentes e monitoramento para os sistemas implantados.",
            "Mapeie o framework para suas obrigações sob a ISO 42001 e o EU AI Act."
          ],
          "pitfalls": [
            "Fazer Mapear e Medir mas negligenciar Governar, de modo que nada é responsável.",
            "Medir o fácil em vez do que importa para a confiabilidade.",
            "Tratá-lo como uma lista de verificação em vez de uma prática contínua de risco.",
            "Ignorar o Perfil de IA Generativa para sistemas LLM e agênticos."
          ],
          "examples": [
            "Uma equipe que usa Mapear para documentar o uso pretendido e as partes interessadas de um agente antes de construir.",
            "Um passo de Medir que compara um modelo em viés e robustez frente a um conjunto de avaliação.",
            "Um processo de Gerir com resposta a incidentes para um assistente de GenAI implantado."
          ],
          "faqs": [
            {
              "q": "O NIST AI RMF é obrigatório?",
              "a": "Não. É um framework voluntário. Mas é amplamente adotado como linguagem comum e espinha dorsal para a gestão operacional do risco de IA, e frequentemente referenciado em políticas e compras."
            },
            {
              "q": "Quais são as quatro funções?",
              "a": "Governar, Mapear, Medir e Gerir. Governar é transversal e sustenta as outras três, que percorrem o ciclo de vida da IA."
            },
            {
              "q": "Como aborda a IA generativa?",
              "a": "Por meio do Perfil de IA Generativa complementar (NIST AI 600-1), que identifica riscos específicos da GenAI e ações sugeridas mapeadas para as quatro funções."
            }
          ]
        },
        "fr": {
          "name": "NIST AI Risk Management Framework",
          "summary": "Le NIST AI RMF 1.0 est un cadre volontaire et largement adopté pour gérer les risques liés à l'IA tout au long de son cycle de vie. Il s'articule autour de quatre fonctions — Gouverner, Cartographier, Mesurer et Gérer (Govern, Map, Measure, Manage) — et d'un ensemble de caractéristiques d'une IA digne de confiance (valide et fiable, sûre, sécurisée et résiliente, responsable et transparente, explicable, respectueuse de la vie privée, et équitable avec gestion des biais préjudiciables). Un profil compagnon pour l'IA générative adapte ce cadre aux risques de la GenAI. Contrairement à l'EU AI Act, il ne s'agit pas d'une loi, mais il constitue un socle commun pour la gouvernance opérationnelle de l'IA.",
          "definition": "Le NIST AI Risk Management Framework est un cadre volontaire qui aide les organisations à gouverner, cartographier, mesurer et gérer les risques des systèmes d'IA tout en tendant vers les caractéristiques d'une IA digne de confiance.",
          "scope": "Toute organisation concevant, développant, déployant ou utilisant l'IA, quel que soit le secteur. Il est volontaire, axé sur les résultats, conçu pour être adapté au contexte et utilisé en parallèle des normes et réglementations.",
          "keyPoints": [
            "Quatre fonctions clés : Gouverner (culture et responsabilité), Cartographier (contexte et risques), Mesurer (évaluer et suivre), Gérer (prioriser et répondre).",
            "La fonction Gouverner est transversale — elle sous-tend les trois autres.",
            "Définit les caractéristiques d'une IA digne de confiance à cibler, et pas seulement les risques à éviter.",
            "Un profil compagnon pour l'IA générative (NIST AI 600-1) traite des risques spécifiques à la GenAI.",
            "Volontaire et flexible — conçu pour être adapté, et non pour faire l'objet d'une certification.",
            "S'associe parfaitement avec la norme ISO/IEC 42001 (système de management) et l'EU AI Act (législation)."
          ],
          "controls": [
            {
              "control": "Gouverner",
              "note": "Établir les politiques, la responsabilité, la culture et les rôles qui concrétisent la gestion des risques — le socle sur lequel reposent les autres fonctions."
            },
            {
              "control": "Cartographier",
              "note": "Définir le contexte : utilisation prévue, parties prenantes, ainsi que les risques et impacts du système d'IA avant sa construction."
            },
            {
              "control": "Mesurer",
              "note": "Utiliser des méthodes quantitatives et qualitatives pour évaluer, comparer et surveiller les risques et la fiabilité — on ne peut gérer ce que l'on ne mesure pas."
            },
            {
              "control": "Gérer",
              "note": "Prioriser, traiter et suivre les risques dans le temps, y compris la réponse aux incidents et le démantèlement."
            },
            {
              "control": "Caractéristiques de confiance",
              "note": "S'orienter vers des résultats valides, sûrs, sécurisés, responsables, explicables, respectueux de la vie privée et équitables en tant qu'objectifs de conception explicites."
            }
          ],
          "checklist": [
            "Mettre en place la fonction Gouverner : politique, responsabilité et rôles.",
            "Cartographier le contexte de chaque système, son utilisation prévue, ses parties prenantes et ses risques.",
            "Définir des métriques et Mesurer la validité, la sécurité, la sûreté, les biais et la robustesse.",
            "Manage : hiérarchiser les risques, planifier les réponses et en assurer le suivi dans le temps.",
            "Appliquer le Generative AI Profile pour les systèmes d'IA générative (GenAI).",
            "Mettre en place la réponse aux incidents et la surveillance pour les systèmes déployés.",
            "Faire correspondre le cadre avec vos obligations au titre d'ISO 42001 et de l'EU AI Act."
          ],
          "pitfalls": [
            "Réaliser les étapes Map et Measure tout en négligeant Govern, ce qui empêche toute responsabilisation.",
            "Mesurer ce qui est facile plutôt que ce qui importe pour la fiabilité.",
            "Le traiter comme une simple liste de contrôle plutôt que comme une pratique continue de gestion des risques.",
            "Ignorer le Generative AI Profile pour les LLM et les systèmes d'agents autonomes."
          ],
          "examples": [
            "Une équipe utilisant Map pour documenter l'utilisation prévue d'un agent et ses parties prenantes avant sa construction.",
            "Une étape Measure évaluant un modèle par rapport à un jeu d'évaluation pour mesurer le biais et la robustesse.",
            "Un processus Manage incluant la réponse aux incidents pour un assistant de GenAI déployé."
          ],
          "faqs": [
            {
              "q": "Le NIST AI RMF est-il obligatoire ?",
              "a": "Non. Il s'agit d'un cadre volontaire. Cependant, il est largement adopté comme langage commun et pilier de la gestion opérationnelle des risques liés à l'IA, et il est souvent référencé dans les politiques et les processus d'achat."
            },
            {
              "q": "Quelles sont les quatre fonctions ?",
              "a": "Govern, Map, Measure et Manage. Govern est transversale et soutient les trois autres, qui s'appliquent tout au long du cycle de vie de l'IA."
            },
            {
              "q": "Comment gère-t-il l'IA générative ?",
              "a": "Grâce au document d'accompagnement Generative AI Profile (NIST AI 600-1), qui identifie les risques spécifiques à la GenAI et suggère des actions associées aux quatre fonctions."
            }
          ]
        },
        "de": {
          "name": "NIST AI Risk Management Framework",
          "summary": "Das NIST AI RMF 1.0 is ein freiwilliges, weit verbreitetes Framework für das Management von KI-Risiken über den gesamten Lebenszyklus hinweg. Es ist um vier Kernfunktionen herum organisiert – Govern (Steuern), Map (Abbilden), Measure (Messen) und Manage (Verwalten) – sowie um eine Reihe von Merkmalen vertrauenswürdiger KI (valide und zuverlässig, sicher, geschützt und widerstandsfähig, rechenschaftspflichtig und transparent, erklärbar, datenschutzfreundlich sowie fair bei kontrollierter schädlicher Verzerrung). Ein begleitendes Generative AI Profile passt es an GenAI-Risiken an. Im Gegensatz zum EU AI Act ist es kein Gesetz, dient aber als gemeinsames Rückgrat für die operative KI-Governance.",
          "definition": "Das NIST AI Risk Management Framework ist ein freiwilliges Framework, das Organisationen dabei unterstützt, die Risiken von KI-Systemen zu steuern, abzubilden, zu messen und zu verwalten, während sie gleichzeitig die Merkmale vertrauenswürdiger KI anstreben.",
          "scope": "Jede Organisation in jedem Sektor, die KI entwirft, entwickelt, bereitstellt oder nutzt. Es ist freiwillig und ergebnisorientiert, so konzipiert, dass es an den jeweiligen Kontext angepasst und zusammen mit Standards und Vorschriften angewendet werden kann.",
          "keyPoints": [
            "Vier Kernfunktionen: Govern (Kultur & Rechenschaftspflicht), Map (Kontext & Risiken), Measure (Bewerten & Verfolgen), Manage (Priorisieren & Reagieren).",
            "Govern ist eine Querschnittsfunktion – sie bildet das Fundament für die anderen drei.",
            "Definiert Merkmale vertrauenswürdiger KI, die angestrebt werden sollen, und nicht nur Risiken, die es zu vermeiden gilt.",
            "Ein begleitendes Generative AI Profile (NIST AI 600-1) befasst sich mit GenAI-spezifischen Risiken.",
            "Freiwillig und flexibel – zur Anpassung gedacht, nicht zur Zertifizierung.",
            "Lässt sich gut mit ISO/IEC 42001 (Managementsystem) und dem EU AI Act (Gesetz) kombinieren."
          ],
          "controls": [
            {
              "control": "Govern",
              "note": "Etablieren Sie die Richtlinien, Rechenschaftspflichten, Kultur und Rollen, die das Risikomanagement mit Leben füllen – das Fundament, auf dem die anderen Funktionen aufbauen."
            },
            {
              "control": "Map",
              "note": "Kontext herstellen: Bestimmen Sie den Verwendungszweck, die Stakeholder sowie die Risiken und Auswirkungen des KI-Systems vor der Entwicklung."
            },
            {
              "control": "Measure",
              "note": "Nutzen Sie quantitative und qualitative Methoden, um Risiken und Vertrauenswürdigkeit zu bewerten, zu vergleichen und zu überwachen – man kann nur verwalten, was man auch misst."
            },
            {
              "control": "Manage",
              "note": "Priorisieren, reagieren Sie auf und verfolgen Sie Risiken im Laufe der Zeit, einschließlich der Reaktion auf Vorfälle und der Außerbetriebnahme."
            },
            {
              "control": "Trustworthiness characteristics",
              "note": "Steuern Sie auf valide, sichere, geschützte, rechenschaftspflichtige, erklärbare, datenschutzfreundliche und faire Ergebnisse als explizite Designziele hin."
            }
          ],
          "checklist": [
            "Etablieren Sie die Govern-Funktion: Richtlinien, Rechenschaftspflicht und Rollen.",
            "Bilden Sie den Kontext, den Verwendungszweck, die Stakeholder und die Risiken jedes Systems ab.",
            "Definieren Sie Metriken und messen Sie Validität, Sicherheit, Schutz, Verzerrung (Bias) und Robustheit.",
            "Manage: Risiken priorisieren, Reaktionen planen und im Zeitverlauf nachverfolgen.",
            "Das Generative AI Profile für GenAI-Systeme anwenden.",
            "Incident Response und Monitoring für bereitgestellte Systeme einrichten.",
            "Das Framework Ihren Verpflichtungen unter ISO 42001 und dem EU AI Act zuordnen."
          ],
          "pitfalls": [
            "„Map“ und „Measure“ durchführen, aber „Govern“ vernachlässigen, sodass keine Rechenschaftspflicht besteht.",
            "Das messen, was einfach ist, anstatt dessen, was für die Vertrauenswürdigkeit wichtig ist.",
            "Es als Checkliste statt als kontinuierliche Risikopraxis behandeln.",
            "Das Generative AI Profile für LLM- und agentenbasierte Systeme ignorieren."
          ],
          "examples": [
            "Ein Team, das „Map“ nutzt, um den beabsichtigten Verwendungszweck eines Agenten und die Stakeholder vor der Entwicklung zu dokumentieren.",
            "Ein „Measure“-Schritt, bei dem ein Modell hinsichtlich Bias und Robustheit anhand eines Evaluierungsdatensatzes gebenchmarkt wird.",
            "Ein „Manage“-Prozess mit Incident Response für einen bereitgestellten GenAI-Assistenten."
          ],
          "faqs": [
            {
              "q": "Ist das NIST AI RMF verpflichtend?",
              "a": "Nein. Es ist ein freiwilliges Framework. Es ist jedoch als gemeinsame Sprache und Rückgrat für das operative KI-Risikomanagement weit verbreitet und wird häufig in Richtlinien und bei der Beschaffung referenziert."
            },
            {
              "q": "Was sind die vier Funktionen?",
              "a": "Govern, Map, Measure und Manage. Govern ist ein übergreifender Bereich und unterstützt die anderen drei Funktionen, die sich über den gesamten KI-Lebenszyklus erstrecken."
            },
            {
              "q": "Wie geht es mit generativer KI um?",
              "a": "Durch das begleitende Generative AI Profile (NIST AI 600-1), das GenAI-spezifische Risiken identifiziert und empfohlene Maßnahmen vorschlägt, die den vier Funktionen zugeordnet sind."
            }
          ]
        },
        "ja": {
          "name": "NIST AIリスクマネジメントフレームワーク",
          "summary": "NIST AI RMF 1.0は、ライフサイクル全体でAIリスクを管理するための、自主的かつ広く採用されているフレームワークです。これは、「Govern（統治）」、「Map（位置づけ）」、「Measure（測定）」、「Manage（管理）」の4つの機能と、信頼できるAIの特徴（妥当性と信頼性、安全性、セキュリティと回復力、説明責任と透明性、説明可能性、プライバシー強化、有害なバイアスが管理された公平性）を中心に構成されています。関連する「Generative AI Profile」は、これをGenAIのリスクに適応させています。EU AI法とは異なり法律ではありませんが、実務的なAIガバナンスの共通の基盤となっています。",
          "definition": "NIST AIリスクマネジメントフレームワークは、組織が信頼できるAIの特徴を追求しながら、AIシステムの管理、位置づけ、測定、およびリスク管理を行うのを支援する自主的なフレームワークです。",
          "scope": "あらゆるセクターにおいて、AIの設計、開発、展開、または利用を行うすべての組織が対象です。これは自主的かつ成果重視のフレームワークであり、文脈に合わせてカスタマイズし、他の標準規格や規制と併用するように設計されています。",
          "keyPoints": [
            "4つのコア機能：Govern（文化と説明責任）、Map（文脈とリスク）、Measure（評価と追跡）、Manage（優先順位付けと対応）。",
            "Govern（統治）は横断的な機能であり、他の3つの機能を支える基盤となります。",
            "回避すべきリスクだけでなく、目指すべき「信頼できるAI」の特徴を定義しています。",
            "関連するGenerative AI Profile（NIST AI 600-1）は、GenAI特有のリスクに対処しています。",
            "自主的かつ柔軟であり、認証を受けるためのものではなく、カスタマイズして使用することを前提としています。",
            "ISO/IEC 42001（マネジメントシステム）やEU AI法（法律）と良好に組み合わせることができます。"
          ],
          "controls": [
            {
              "control": "Govern（統治）",
              "note": "リスク管理を実効性のあるものにするためのポリシー、説明責任、文化、および役割を確立します。これは、他の機能が立脚する基盤となります。"
            },
            {
              "control": "Map（位置づけ）",
              "note": "構築前に、意図された用途、ステークホルダー、AIシステムのリスクと影響などの文脈を確立します。"
            },
            {
              "control": "Measure（測定）",
              "note": "定量的および定性的手法を使用して、リスクと信頼性を評価、ベンチマーク、および監視します。測定できないものは管理できません。"
            },
            {
              "control": "Manage（管理）",
              "note": "インシデント対応や廃止措置を含め、時間の経過に伴うリスクの優先順位付け、対応、および追跡を行います。"
            },
            {
              "control": "信頼性の特徴",
              "note": "明示的な設計目標として、妥当、安全、セキュア、説明責任、説明可能、プライバシー強化、および公平な成果を目指します。"
            }
          ],
          "checklist": [
            "Govern（統治）機能を立ち上げる：ポリシー、説明責任、および役割。",
            "各システムについて、文脈、意図された用途、ステークホルダー、およびリスクを位置づける（Map）。",
            "メトリクスを定義し、妥当性、安全性、セキュリティ、バイアス、および堅牢性を測定（Measure）する。",
            "Manage（管理）：リスクの優先順位付け、対応の計画、および長期的な追跡を行います。",
            "GenAI（生成AI）システムにGenerative AI Profile（生成AIプロファイル）を適用します。",
            "デプロイされたシステムに対してインシデント対応とモニタリングを設定します。",
            "フレームワークを、ISO 42001およびEU AI法に基づく義務にマッピングします。"
          ],
          "pitfalls": [
            "Map（マッピング）とMeasure（測定）は行うものの、Govern（ガバナンス）を怠るため、説明責任が果たされない。",
            "信頼性にとって重要なことではなく、測定しやすいことだけを測定する。",
            "継続的なリスク管理の実践としてではなく、単なるチェックリストとして扱う。",
            "LLMやエージェント型システムにおいて、Generative AI Profileを無視する。"
          ],
          "examples": [
            "構築前に、Map（マッピング）を使用してエージェントの想定される用途とステークホルダーを文書化するチーム。",
            "評価セットに対してモデルのバイアスと堅牢性をベンチマーク測定するMeasure（測定）ステップ。",
            "デプロイされたGenAIアシスタントに対するインシデント対応を含むManage（管理）プロセス。"
          ],
          "faqs": [
            {
              "q": "NIST AI RMFは義務化されていますか？",
              "a": "いいえ。これは自主的なフレームワークです。しかし、実務的なAIリスク管理の共通言語および基盤として広く採用されており、ポリシーや調達において頻繁に参照されています。"
            },
            {
              "q": "4つの機能とは何ですか？",
              "a": "Govern（ガバナンス）、Map（マッピング）、Measure（測定）、Manage（管理）です。Governは横断的な機能であり、AIライフサイクル全体にわたって実行される他の3つの機能をサポートします。"
            },
            {
              "q": "生成AIにはどのように対応していますか？",
              "a": "4つの機能にマッピングされた、GenAI特有のリスクと推奨されるアクションを特定する、コンパニオン文書のGenerative AI Profile（NIST AI 600-1）を通じて対応しています。"
            }
          ]
        },
        "zh": {
          "name": "NIST AI 风险管理框架",
          "summary": "NIST AI RMF 1.0 是一个自愿采用且被广泛接受的框架，用于管理整个生命周期中的 AI 风险。它围绕四个功能展开——治理（Govern）、映射（Map）、测量（Measure）和管理（Manage），以及一套可信 AI 的特征（有效且可靠、安全、安全且有弹性、可问责且透明、可解释、隐私增强以及管理有害偏见的公平性）。配套的生成式 AI 配置文件（Generative AI Profile）使其适用于 GenAI 风险。与《欧盟 AI 法案》不同，它不是法律，但它是运营 AI 治理的通用支柱。",
          "definition": "NIST AI 风险管理框架是一个自愿性框架，旨在帮助组织治理、映射、测量和管理 AI 系统的风险，同时追求可信 AI 的特征。",
          "scope": "任何行业中设计、开发、部署或使用 AI 的组织。它是自愿性的且以结果为导向，旨在根据具体背景进行定制，并与标准和法规配合使用。",
          "keyPoints": [
            "四大核心功能：治理（Govern，文化与问责）、映射（Map，背景与风险）、测量（Measure，评估与跟踪）、管理（Manage，优先级与响应）。",
            "治理（Govern）是横向贯穿的——它是其他三个功能的基础。",
            "定义了要追求的可信 AI 特征，而不仅仅是要避免的风险。",
            "配套的生成式 AI 配置文件（NIST AI 600-1）应对了 GenAI 特有的风险。",
            "自愿且灵活——旨在进行定制，而非用于认证。",
            "能与 ISO/IEC 42001（管理体系）和《欧盟 AI 法案》（法律）良好配合。"
          ],
          "controls": [
            {
              "control": "治理（Govern）",
              "note": "建立使风险管理落地的政策、问责制、文化和角色——这是其他功能赖以建立的基础。"
            },
            {
              "control": "映射（Map）",
              "note": "确立背景：在构建之前，明确 AI 系统的预期用途、利益相关者以及风险和影响。"
            },
            {
              "control": "测量（Measure）",
              "note": "使用定量和定性的方法来评估、基准测试和监控风险与可信度——无法测量就无法管理。"
            },
            {
              "control": "管理（Manage）",
              "note": "随着时间的推移，对风险进行优先级排序、响应和跟踪，包括事件响应和退役。"
            },
            {
              "control": "可信度特征",
              "note": "将有效、安全、可靠、可问责、可解释、隐私增强和公平的结果作为明确的设计目标。"
            }
          ],
          "checklist": [
            "建立治理（Govern）功能：政策、问责制和角色。",
            "映射每个系统的背景、预期用途、利益相关者和风险。",
            "定义指标并测量（Measure）有效性、安全性、可靠性、偏见和鲁棒性。",
            "管理（Manage）：确定风险优先级、规划应对措施并进行长期跟踪。",
            "针对 GenAI 系统应用生成式人工智能配置文件（Generative AI Profile）。",
            "为已部署系统设置事件响应和监控。",
            "将该框架映射到您在 ISO 42001 和《欧盟人工智能法案》（EU AI Act）下的义务。"
          ],
          "pitfalls": [
            "只进行映射（Map）和测量（Measure）却忽略了治理（Govern），导致无人对结果负责。",
            "测量容易测量的指标，而不是对可信度至关重要的指标。",
            "将其视为一份核对清单，而不是一种持续的风险管理实践。",
            "在 LLM 和智能体（agentic）系统中忽略了生成式人工智能配置文件（Generative AI Profile）。"
          ],
          "examples": [
            "团队在构建前使用“映射”（Map）来记录智能体的预期用途和利益相关者。",
            "“测量”（Measure）步骤，根据评估集对模型的偏差和鲁棒性进行基准测试。",
            "“管理”（Manage）流程，包含针对已部署 GenAI 助手的事件响应。"
          ],
          "faqs": [
            {
              "q": "NIST AI RMF 是强制性的吗？",
              "a": "不是。它是一个自愿性框架。但它被广泛采纳为运营 AI 风险管理的通用语言和骨干，并经常在政策和采购中被引用。"
            },
            {
              "q": "这四个功能是什么？",
              "a": "治理（Govern）、映射（Map）、测量（Measure）和管理（Manage）。治理是横向贯穿的，支持其他三个贯穿整个 AI 生命周期的功能。"
            },
            {
              "q": "它是如何处理生成式 AI 的？",
              "a": "通过配套的生成式人工智能配置文件（Generative AI Profile，即 NIST AI 600-1），该文件识别了 GenAI 特有的风险，并提出了映射到这四个功能的建议行动。"
            }
          ]
        }
      }
    },
    {
      "id": "GOV-004",
      "slug": "agentic-ai-governance-checklist",
      "category": "playbook",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/governance/agentic-ai-governance-checklist",
      "api": "https://santismm.com/api/governance/agentic-ai-governance-checklist",
      "canonical_url": "https://santismm.com/en/governance/agentic-ai-governance-checklist",
      "api_url": "https://santismm.com/api/governance/agentic-ai-governance-checklist",
      "evidence": {
        "evidenceLevel": "industry_observation",
        "confidenceLevel": "medium",
        "sourceType": [
          "industry_observation",
          "personal_experience"
        ]
      },
      "frameworks": [
        "EU AI Act",
        "ISO/IEC 42001",
        "NIST AI RMF"
      ],
      "patterns": [
        "human-approval-gate",
        "evaluator-optimizer",
        "reflection",
        "routing"
      ],
      "knowledge": [
        "ai-governance",
        "guardrails",
        "human-in-the-loop",
        "ai-observability",
        "agentic-evaluation",
        "prompt-injection"
      ],
      "references": [
        {
          "title": "NIST — AI Risk Management Framework (AI RMF 1.0)",
          "url": "https://www.nist.gov/itl/ai-risk-management-framework"
        },
        {
          "title": "EU AI Act — Article 14 (Human oversight)",
          "url": "https://artificialintelligenceact.eu/article/14/"
        },
        {
          "title": "OWASP — Top 10 for LLM Applications",
          "url": "https://owasp.org/www-project-top-10-for-large-language-model-applications/"
        }
      ],
      "related": [
        "eu-ai-act",
        "iso-42001",
        "nist-ai-rmf",
        "enterprise-ai-governance-framework",
        "human-oversight-and-accountability-policy"
      ],
      "locales": {
        "en": {
          "name": "Agentic AI Governance Checklist",
          "summary": "A practical, vendor-neutral checklist for governing agentic AI in the enterprise — translating the principles of the EU AI Act, ISO/IEC 42001 and NIST AI RMF into concrete controls you can implement in a harness. It covers human oversight, guardrails, audit logging, evaluation, access control, prompt-injection defence and incident response, and maps each control to the patterns and knowledge units that operationalize it. Use it as a readiness gate before letting an agent act in production.",
          "definition": "The agentic AI governance checklist is an operational control set that turns AI governance frameworks into concrete, implementable requirements for autonomous agents acting in production.",
          "scope": "Teams building or deploying autonomous or semi-autonomous agents that use tools, act on systems, or make consequential decisions. It is a practical companion to the formal frameworks, not a substitute for legal advice.",
          "keyPoints": [
            "Human oversight by risk: gate high-impact, irreversible or regulated actions for human approval.",
            "Guardrails on inputs and outputs, including prompt-injection and PII defence.",
            "Full audit logging and observability so every action is traceable.",
            "Evaluation before and after deployment, against a maintained eval set.",
            "Least-privilege access for tools and data the agent can reach.",
            "A defined incident response and kill-switch for agents in production."
          ],
          "controls": [
            {
              "control": "Human approval gates",
              "note": "Route high-impact actions through a human checkpoint (EU AI Act Art. 14). Implements the human-approval-gate pattern."
            },
            {
              "control": "Guardrails",
              "note": "Validate and constrain inputs and outputs; defend against prompt injection and block out-of-policy actions."
            },
            {
              "control": "Audit logging & observability",
              "note": "Trace every decision, tool call and action so the agent is reviewable and incidents are reconstructable."
            },
            {
              "control": "Evaluation harness",
              "note": "Score behaviour against an eval set before shipping and monitor for regressions after — NIST 'Measure'."
            },
            {
              "control": "Least-privilege access",
              "note": "Scope the tools, data and permissions an agent can reach to the minimum its task requires."
            },
            {
              "control": "Incident response & kill-switch",
              "note": "Define how to detect, stop and remediate a misbehaving agent, including a way to halt it immediately."
            }
          ],
          "checklist": [
            "Classify the agent's risk and identify which actions need human approval.",
            "Implement guardrails for inputs/outputs and prompt-injection defence.",
            "Enable end-to-end audit logging and observability.",
            "Stand up an evaluation set and run it pre-deployment and continuously.",
            "Apply least-privilege scoping to tools, data and credentials.",
            "Define incident response, monitoring thresholds and a kill-switch.",
            "Map each control to your obligations under the EU AI Act, ISO 42001 and NIST AI RMF.",
            "Document ownership and review the agent on a schedule."
          ],
          "pitfalls": [
            "Granting an agent broad tool/data access 'to be safe', creating a large blast radius.",
            "Gating everything (approval fatigue) or nothing (no oversight) instead of gating by risk.",
            "Shipping without an eval set, so quality and safety are unmeasured.",
            "No kill-switch or incident plan when an agent misbehaves in production.",
            "Ignoring prompt injection as an attack surface for tool-using agents."
          ],
          "productionEvidence": {
            "context": "Teams putting an autonomous or semi-autonomous agent into production where it uses tools and takes consequential actions.",
            "scenario": "Before go-live, the team runs the checklist as a readiness gate: classify the agent's risk, gate high-impact actions for human approval, add guardrails and prompt-injection defence, enable audit logging and observability, stand up an evaluation set, scope least-privilege access, and define incident response and a kill-switch.",
            "technology": "A harness combining a human-approval gate, guardrails, audit logging/observability, an evaluation harness and scoped tool/credential access.",
            "load": "Applied per agent before deployment and re-reviewed on a schedule; the heaviest control (human approval) is reserved for the small set of high-impact actions.",
            "results": "Observed pattern: teams that gate by risk, enforce least privilege and instrument from day one contain the blast radius of agent errors; those that grant broad access 'to be safe' or ship without evals discover failures in production. Measure escalation appropriateness, false-action rate and mean time to detect."
          },
          "lessons": [
            "Treat the checklist as a readiness gate, not a one-time audit — re-run it as the agent's tools and autonomy grow.",
            "Least-privilege access and risk-based human approval bound the blast radius more than any single guardrail.",
            "Without an evaluation set and audit logging in place before launch, you cannot tell a safe agent from a lucky one.",
            "Map each control to a concrete owner; governance without accountability is just documentation."
          ],
          "examples": [
            "An agent whose refund action is gated for human approval while read-only lookups run freely.",
            "A guardrail blocking a prompt-injected instruction to exfiltrate data via a tool.",
            "An evaluation run catching a safety regression before an agent update ships."
          ],
          "faqs": [
            {
              "q": "Is this a substitute for the EU AI Act or ISO 42001?",
              "a": "No. It is a practical control set that operationalizes their principles for agents. Use it alongside the formal frameworks and legal advice, not instead of them."
            },
            {
              "q": "Which control matters most for autonomous agents?",
              "a": "Risk-based human oversight plus least-privilege access and audit logging — together they bound what an agent can do and make every action accountable."
            },
            {
              "q": "How does it connect to the patterns library?",
              "a": "Each control maps to patterns that implement it — human-approval-gate for oversight, reflection and evaluator-optimizer for quality — and to knowledge units like guardrails and AI observability."
            }
          ]
        },
        "es": {
          "name": "Checklist de Gobernanza de IA Agéntica",
          "summary": "Un checklist práctico y neutral para gobernar la IA agéntica en la empresa, que traduce los principios del EU AI Act, ISO/IEC 42001 y NIST AI RMF en controles concretos que puedes implementar en un harness. Cubre supervisión humana, guardarraíles, registro de auditoría, evaluación, control de acceso, defensa frente a inyección de prompts y respuesta a incidentes, y mapea cada control a los patrones y unidades de conocimiento que lo operacionalizan. Úsalo como puerta de preparación antes de dejar que un agente actúe en producción.",
          "definition": "El checklist de gobernanza de IA agéntica es un conjunto de controles operativos que convierte los marcos de gobernanza de IA en requisitos concretos e implementables para agentes autónomos que actúan en producción.",
          "scope": "Equipos que construyen o despliegan agentes autónomos o semiautónomos que usan herramientas, actúan sobre sistemas o toman decisiones de consecuencia. Es un compañero práctico de los marcos formales, no un sustituto del asesoramiento legal.",
          "keyPoints": [
            "Supervisión humana por riesgo: pon puertas de aprobación a las acciones de alto impacto, irreversibles o reguladas.",
            "Guardarraíles en entradas y salidas, incluyendo defensa frente a inyección de prompts y PII.",
            "Registro de auditoría y observabilidad completos para que cada acción sea trazable.",
            "Evaluación antes y después del despliegue, contra un conjunto de evaluación mantenido.",
            "Acceso de mínimo privilegio a las herramientas y datos que el agente puede alcanzar.",
            "Una respuesta a incidentes y un interruptor de parada definidos para los agentes en producción."
          ],
          "controls": [
            {
              "control": "Puertas de aprobación humana",
              "note": "Enruta las acciones de alto impacto por un punto de control humano (Art. 14 del EU AI Act). Implementa el patrón de puerta de aprobación humana."
            },
            {
              "control": "Guardarraíles",
              "note": "Valida y restringe entradas y salidas; defiende frente a la inyección de prompts y bloquea acciones fuera de política."
            },
            {
              "control": "Registro de auditoría y observabilidad",
              "note": "Traza cada decisión, llamada a herramienta y acción para que el agente sea revisable y los incidentes reconstruibles."
            },
            {
              "control": "Arnés de evaluación",
              "note": "Puntúa el comportamiento frente a un conjunto de evaluación antes de desplegar y monitoriza regresiones después: el 'Medir' del NIST."
            },
            {
              "control": "Acceso de mínimo privilegio",
              "note": "Acota las herramientas, los datos y los permisos que un agente puede alcanzar al mínimo que su tarea requiere."
            },
            {
              "control": "Respuesta a incidentes e interruptor de parada",
              "note": "Define cómo detectar, detener y remediar un agente que se comporta mal, incluyendo una forma de pararlo de inmediato."
            }
          ],
          "checklist": [
            "Clasifica el riesgo del agente e identifica qué acciones necesitan aprobación humana.",
            "Implementa guardarraíles para entradas/salidas y defensa frente a inyección de prompts.",
            "Habilita registro de auditoría y observabilidad de extremo a extremo.",
            "Monta un conjunto de evaluación y ejecútalo antes del despliegue y de forma continua.",
            "Aplica mínimo privilegio a herramientas, datos y credenciales.",
            "Define respuesta a incidentes, umbrales de monitorización y un interruptor de parada.",
            "Mapea cada control a tus obligaciones bajo el EU AI Act, ISO 42001 y NIST AI RMF.",
            "Documenta la responsabilidad y revisa el agente de forma periódica."
          ],
          "pitfalls": [
            "Dar a un agente amplio acceso a herramientas/datos 'por si acaso', creando un gran radio de impacto.",
            "Poner puertas a todo (fatiga de aprobación) o a nada (sin supervisión) en vez de hacerlo por riesgo.",
            "Desplegar sin un conjunto de evaluación, dejando calidad y seguridad sin medir.",
            "No tener interruptor de parada ni plan de incidentes cuando un agente se comporta mal en producción.",
            "Ignorar la inyección de prompts como superficie de ataque para agentes con herramientas."
          ],
          "productionEvidence": {
            "context": "Equipos que ponen en producción un agente autónomo o semiautónomo que usa herramientas y toma acciones de consecuencia.",
            "scenario": "Antes del lanzamiento, el equipo ejecuta el checklist como puerta de preparación: clasifica el riesgo del agente, pone puertas de aprobación humana a las acciones de alto impacto, añade guardarraíles y defensa frente a inyección de prompts, habilita registro de auditoría y observabilidad, monta un conjunto de evaluación, acota el acceso de mínimo privilegio y define respuesta a incidentes y un interruptor de parada.",
            "technology": "Un harness que combina una puerta de aprobación humana, guardarraíles, registro de auditoría/observabilidad, un arnés de evaluación y acceso acotado a herramientas y credenciales.",
            "load": "Se aplica por agente antes del despliegue y se revisa de forma periódica; el control más pesado (aprobación humana) se reserva para el pequeño conjunto de acciones de alto impacto.",
            "results": "Patrón observado: los equipos que ponen puertas por riesgo, aplican mínimo privilegio e instrumentan desde el día uno contienen el radio de impacto de los errores del agente; los que dan acceso amplio 'por si acaso' o despliegan sin evaluaciones descubren los fallos en producción. Mide la idoneidad del escalado, la tasa de acciones erróneas y el tiempo medio de detección."
          },
          "lessons": [
            "Trata el checklist como una puerta de preparación, no como una auditoría puntual: vuelve a ejecutarlo a medida que crecen las herramientas y la autonomía del agente.",
            "El acceso de mínimo privilegio y la aprobación humana basada en riesgo acotan el radio de impacto más que cualquier guardarraíl aislado.",
            "Sin un conjunto de evaluación y registro de auditoría antes del lanzamiento, no puedes distinguir un agente seguro de uno con suerte.",
            "Asigna cada control a un responsable concreto; la gobernanza sin rendición de cuentas es solo documentación."
          ],
          "examples": [
            "Un agente cuya acción de reembolso tiene puerta de aprobación humana mientras las consultas de solo lectura corren libres.",
            "Un guardarraíl que bloquea una instrucción inyectada para exfiltrar datos mediante una herramienta.",
            "Una ejecución de evaluación que detecta una regresión de seguridad antes de desplegar una actualización del agente."
          ],
          "faqs": [
            {
              "q": "¿Esto sustituye al EU AI Act o a ISO 42001?",
              "a": "No. Es un conjunto de controles práctico que operacionaliza sus principios para agentes. Úsalo junto a los marcos formales y al asesoramiento legal, no en su lugar."
            },
            {
              "q": "¿Qué control importa más para los agentes autónomos?",
              "a": "La supervisión humana basada en riesgo más el acceso de mínimo privilegio y el registro de auditoría: juntos acotan lo que un agente puede hacer y hacen cada acción responsable."
            },
            {
              "q": "¿Cómo conecta con la biblioteca de patrones?",
              "a": "Cada control mapea a patrones que lo implementan —puerta de aprobación humana para la supervisión, reflexión y evaluador-optimizador para la calidad— y a unidades de conocimiento como guardarraíles y observabilidad de IA."
            }
          ]
        },
        "pt": {
          "name": "Checklist de Governança de IA Agêntica",
          "summary": "Um checklist prático e neutro para governar a IA agêntica na empresa, que traduz os princípios do EU AI Act, ISO/IEC 42001 e NIST AI RMF em controles concretos que você pode implementar num harness. Cobre supervisão humana, guard-rails, registro de auditoria, avaliação, controle de acesso, defesa contra injeção de prompts e resposta a incidentes, e mapeia cada controle aos padrões e unidades de conhecimento que o operacionalizam. Use-o como portão de prontidão antes de deixar um agente agir em produção.",
          "definition": "O checklist de governança de IA agêntica é um conjunto de controles operacionais que transforma os frameworks de governança de IA em requisitos concretos e implementáveis para agentes autônomos que agem em produção.",
          "scope": "Equipes que constroem ou implantam agentes autônomos ou semiautônomos que usam ferramentas, agem sobre sistemas ou tomam decisões consequentes. É um companheiro prático dos frameworks formais, não um substituto de aconselhamento jurídico.",
          "keyPoints": [
            "Supervisão humana por risco: coloque portões de aprovação nas ações de alto impacto, irreversíveis ou reguladas.",
            "Guard-rails em entradas e saídas, incluindo defesa contra injeção de prompts e PII.",
            "Registro de auditoria e observabilidade completos para que cada ação seja rastreável.",
            "Avaliação antes e depois da implantação, contra um conjunto de avaliação mantido.",
            "Acesso de menor privilégio às ferramentas e dados que o agente pode alcançar.",
            "Uma resposta a incidentes e um interruptor de parada definidos para os agentes em produção."
          ],
          "controls": [
            {
              "control": "Portões de aprovação humana",
              "note": "Roteie as ações de alto impacto por um ponto de controle humano (Art. 14 do EU AI Act). Implementa o padrão de portão de aprovação humana."
            },
            {
              "control": "Guard-rails",
              "note": "Valide e restrinja entradas e saídas; defenda contra a injeção de prompts e bloqueie ações fora da política."
            },
            {
              "control": "Registro de auditoria e observabilidade",
              "note": "Rastreie cada decisão, chamada de ferramenta e ação para que o agente seja revisável e os incidentes reconstruíveis."
            },
            {
              "control": "Harness de avaliação",
              "note": "Pontue o comportamento contra um conjunto de avaliação antes de implantar e monitore regressões depois: o 'Medir' do NIST."
            },
            {
              "control": "Acesso de menor privilégio",
              "note": "Restrinja as ferramentas, os dados e as permissões que um agente pode alcançar ao mínimo que sua tarefa requer."
            },
            {
              "control": "Resposta a incidentes e interruptor de parada",
              "note": "Defina como detectar, parar e remediar um agente que se comporta mal, incluindo uma forma de pará-lo imediatamente."
            }
          ],
          "checklist": [
            "Classifique o risco do agente e identifique quais ações precisam de aprovação humana.",
            "Implemente guard-rails para entradas/saídas e defesa contra injeção de prompts.",
            "Habilite registro de auditoria e observabilidade ponta a ponta.",
            "Monte um conjunto de avaliação e execute-o antes da implantação e continuamente.",
            "Aplique menor privilégio a ferramentas, dados e credenciais.",
            "Defina resposta a incidentes, limiares de monitoramento e um interruptor de parada.",
            "Mapeie cada controle para suas obrigações sob o EU AI Act, ISO 42001 e NIST AI RMF.",
            "Documente a responsabilidade e revise o agente periodicamente."
          ],
          "pitfalls": [
            "Dar a um agente amplo acesso a ferramentas/dados 'por precaução', criando um grande raio de impacto.",
            "Colocar portões em tudo (fadiga de aprovação) ou em nada (sem supervisão) em vez de fazê-lo por risco.",
            "Implantar sem um conjunto de avaliação, deixando qualidade e segurança sem medição.",
            "Não ter interruptor de parada nem plano de incidentes quando um agente se comporta mal em produção.",
            "Ignorar a injeção de prompts como superfície de ataque para agentes com ferramentas."
          ],
          "productionEvidence": {
            "context": "Equipes que colocam em produção um agente autônomo ou semiautônomo que usa ferramentas e toma ações consequentes.",
            "scenario": "Antes do go-live, a equipe executa o checklist como portão de prontidão: classifica o risco do agente, coloca portões de aprovação humana nas ações de alto impacto, adiciona guard-rails e defesa contra injeção de prompts, habilita registro de auditoria e observabilidade, monta um conjunto de avaliação, restringe o acesso de menor privilégio e define resposta a incidentes e um interruptor de parada.",
            "technology": "Um harness que combina um portão de aprovação humana, guard-rails, registro de auditoria/observabilidade, um harness de avaliação e acesso restrito a ferramentas e credenciais.",
            "load": "Aplicado por agente antes da implantação e revisado periodicamente; o controle mais pesado (aprovação humana) é reservado para o pequeno conjunto de ações de alto impacto.",
            "results": "Padrão observado: equipes que colocam portões por risco, aplicam menor privilégio e instrumentam desde o dia um contêm o raio de impacto dos erros do agente; as que dão acesso amplo 'por precaução' ou implantam sem avaliações descobrem as falhas em produção. Meça a adequação do escalonamento, a taxa de ações erradas e o tempo médio de detecção."
          },
          "lessons": [
            "Trate o checklist como um portão de prontidão, não como uma auditoria pontual: execute-o novamente à medida que as ferramentas e a autonomia do agente crescem.",
            "O acesso de menor privilégio e a aprovação humana baseada em risco limitam o raio de impacto mais do que qualquer guard-rail isolado.",
            "Sem um conjunto de avaliação e registro de auditoria antes do lançamento, você não distingue um agente seguro de um com sorte.",
            "Atribua cada controle a um responsável concreto; governança sem prestação de contas é só documentação."
          ],
          "examples": [
            "Um agente cuja ação de reembolso tem portão de aprovação humana enquanto as consultas somente leitura correm livres.",
            "Um guard-rail que bloqueia uma instrução injetada para exfiltrar dados via uma ferramenta.",
            "Uma execução de avaliação que detecta uma regressão de segurança antes de implantar uma atualização do agente."
          ],
          "faqs": [
            {
              "q": "Isto substitui o EU AI Act ou a ISO 42001?",
              "a": "Não. É um conjunto de controles prático que operacionaliza seus princípios para agentes. Use-o junto aos frameworks formais e ao aconselhamento jurídico, não no lugar deles."
            },
            {
              "q": "Qual controle importa mais para os agentes autônomos?",
              "a": "A supervisão humana baseada em risco mais o acesso de menor privilégio e o registro de auditoria: juntos limitam o que um agente pode fazer e tornam cada ação responsável."
            },
            {
              "q": "Como conecta com a biblioteca de padrões?",
              "a": "Cada controle mapeia para padrões que o implementam —portão de aprovação humana para a supervisão, reflexão e avaliador-otimizador para a qualidade— e para unidades de conhecimento como guard-rails e observabilidade de IA."
            }
          ]
        },
        "fr": {
          "name": "Checklist de gouvernance de l'IA agentique",
          "summary": "Une checklist pratique et neutre vis-à-vis des fournisseurs pour gouverner l'IA agentique en entreprise — traduisant les principes de l'EU AI Act, de l'ISO/IEC 42001 et du NIST AI RMF en contrôles concrets à implémenter dans un harness. Elle couvre la supervision humaine, les guardrails, la journalisation d'audit, l'évaluation, le contrôle d'accès, la défense contre l'injection de prompts et la réponse aux incidents, et associe chaque contrôle aux patterns et unités de connaissance qui l'opérationnalisent. Utilisez-la comme un jalon de validation (readiness gate) avant de laisser un agent agir en production.",
          "definition": "La checklist de gouvernance de l'IA agentique est un ensemble de contrôles opérationnels qui transforme les cadres de gouvernance de l'IA en exigences concrètes et applicables pour les agents autonomes opérant en production.",
          "scope": "Les équipes qui conçoivent ou déploient des agents autonomes ou semi-autonomes qui utilisent des outils, agissent sur des systèmes ou prennent des décisions importantes. C'est un compagnon pratique pour les cadres formels, et non un substitut à un avis juridique.",
          "keyPoints": [
            "Supervision humaine basée sur le risque : soumettre les actions à fort impact, irréversibles ou réglementées à une approbation humaine.",
            "Guardrails sur les entrées et les sorties, y compris la défense contre l'injection de prompts et la protection des données personnelles (PII).",
            "Journalisation d'audit complète et observabilité pour que chaque action soit traçable.",
            "Évaluation avant et après le déploiement, par rapport à un ensemble d'évaluation (eval set) maintenu.",
            "Accès de moindre privilège pour les outils et les données auxquels l'agent peut accéder.",
            "Une réponse aux incidents définie et un bouton d'arrêt d'urgence (kill-switch) pour les agents en production."
          ],
          "controls": [
            {
              "control": "Portes d'approbation humaine",
              "note": "Acheminer les actions à fort impact via un point de contrôle humain (EU AI Act Art. 14). Implémente le pattern human-approval-gate."
            },
            {
              "control": "Guardrails",
              "note": "Valider et contraindre les entrées et les sorties ; se défendre contre l'injection de prompts et bloquer les actions non conformes aux politiques."
            },
            {
              "control": "Journalisation d'audit et observabilité",
              "note": "Tracer chaque décision, appel d'outil et action afin que l'agent soit auditable et que les incidents puissent être reconstitués."
            },
            {
              "control": "Harness d'évaluation",
              "note": "Évaluer le comportement par rapport à un ensemble d'évaluation (eval set) avant le déploiement et surveiller les régressions après — NIST 'Measure'."
            },
            {
              "control": "Accès de moindre privilège",
              "note": "Restreindre les outils, les données et les permissions auxquels un agent peut accéder au strict minimum requis par sa tâche."
            },
            {
              "control": "Réponse aux incidents et bouton d'arrêt d'urgence (kill-switch)",
              "note": "Définir comment détecter, arrêter et corriger un agent au comportement anormal, y compris un moyen de l'interrompre immédiatement."
            }
          ],
          "checklist": [
            "Classifier le risque de l'agent et identifier les actions qui nécessitent une approbation humaine.",
            "Implémenter des guardrails pour les entrées/sorties et une défense contre l'injection de prompts.",
            "Activer la journalisation d'audit et l'observabilité de bout en bout.",
            "Mettre en place un ensemble d'évaluation (eval set) et l'exécuter avant le déploiement ainsi qu'en continu.",
            "Appliquer une restriction de moindre privilège aux outils, données et identifiants.",
            "Définir la réponse aux incidents, les seuils de surveillance et un bouton d'arrêt d'urgence (kill-switch).",
            "Associer chaque contrôle à vos obligations en vertu de l'EU AI Act, de l'ISO 42001 et du NIST AI RMF.",
            "Documenter la responsabilité (ownership) et réévaluer l'agent de manière périodique."
          ],
          "pitfalls": [
            "Accorder à un agent un accès étendu aux outils et aux données « par sécurité », ce qui crée une zone d'impact (blast radius) importante.",
            "Tout filtrer (fatigue de l'approbation) ou ne rien filtrer (absence de supervision) au lieu de filtrer en fonction du risque.",
            "Déployer sans ensemble d'évaluation (eval set), de sorte que la qualité et la sécurité ne sont pas mesurées.",
            "Aucun bouton d'arrêt d'urgence (kill-switch) ni plan d'incident lorsqu'un agent se comporte de manière anormale en production.",
            "Ignorer l'injection de prompts comme surface d'attaque pour les agents utilisant des outils."
          ],
          "productionEvidence": {
            "context": "Équipes mettant en production un agent autonome ou semi-autonome qui utilise des outils et prend des décisions importantes.",
            "scenario": "Avant la mise en service, l'équipe utilise la checklist comme jalon de validation (readiness gate) : classifier le risque de l'agent, soumettre les actions à fort impact à une approbation humaine, ajouter des guardrails et une défense contre l'injection de prompts, activer la journalisation d'audit et l'observabilité, mettre en place un ensemble d'évaluation, restreindre l'accès au moindre privilège, et définir la réponse aux incidents ainsi qu'un bouton d'arrêt d'urgence (kill-switch).",
            "technology": "Un harness combinant une porte d'approbation humaine, des guardrails, une journalisation d'audit/observabilité, un harness d'évaluation et un accès restreint aux outils et identifiants.",
            "load": "Appliqué par agent avant le déploiement et réévalué périodiquement ; le contrôle le plus lourd (approbation humaine) est réservé au groupe restreint d'actions à fort impact.",
            "results": "Pattern observé : les équipes qui filtrent par risque, appliquent le moindre privilège et instrumentent dès le premier jour limitent la zone d'impact (blast radius) des erreurs de l'agent ; celles qui accordent un accès étendu « par sécurité » ou déploient sans évaluations découvrent les défaillances en production. Mesurez la pertinence de l'escalade, le taux de fausses actions et le temps moyen de détection (MTTD)."
          },
          "lessons": [
            "Traitez la checklist comme un jalon de validation (readiness gate), et non comme un audit ponctuel — réexécutez-la à mesure que les outils et l'autonomie de l'agent se développent.",
            "L'accès de moindre privilège et l'approbation humaine basée sur le risque limitent la zone d'impact (blast radius) bien plus que n'importe quel guardrail individuel.",
            "Sans ensemble d'évaluation et journalisation d'audit en place avant le lancement, vous ne pouvez pas distinguer un agent sûr d'un agent chanceux.",
            "Associez chaque contrôle à un responsable concret ; la gouvernance sans responsabilité n'est que de la documentation."
          ],
          "examples": [
            "Un agent dont l'action de remboursement est soumise à une approbation humaine tandis que les consultations en lecture seule s'exécutent librement.",
            "Un guardrail bloquant une instruction issue d'une injection de prompts visant à exfiltrer des données via un outil.",
            "Une exécution d'évaluation détectant une régression de sécurité avant le déploiement d'une mise à jour de l'agent."
          ],
          "faqs": [
            {
              "q": "Est-ce un substitut à l'EU AI Act ou à l'ISO 42001 ?",
              "a": "Non. Il s'agit d'un ensemble de contrôles pratiques qui opérationnalise leurs principes pour les agents. Utilisez-le en complément des cadres formels et des conseils juridiques, et non à leur place."
            },
            {
              "q": "Quel contrôle importe le plus pour les agents autonomes ?",
              "a": "La supervision humaine basée sur le risque, combinée à l'accès de moindre privilège et à la journalisation d'audit — ensemble, ils limitent ce qu'un agent peut faire et rendent chaque action auditable."
            },
            {
              "q": "Comment se connecte-t-elle à la bibliothèque de patterns ?",
              "a": "Chaque contrôle est associé aux patterns qui l'implémentent — human-approval-gate pour la supervision, reflection et evaluator-optimizer pour la qualité — ainsi qu'à des unités de connaissance comme les guardrails et l'observabilité de l'IA."
            }
          ]
        },
        "de": {
          "name": "Governance-Checkliste für agentische KI",
          "summary": "Eine praktische, herstellerneutrale Checkliste für die Governance agentischer KI im Unternehmen – sie übersetzt die Prinzipien des EU AI Act, der ISO/IEC 42001 und des NIST AI RMF in konkrete Kontrollmechanismen, die Sie in einem Harness implementieren können. Sie deckt menschliche Aufsicht, Guardrails, Audit-Protokollierung, Evaluierung, Zugriffskontrolle, Abwehr von Prompt-Injections sowie Incident Response ab und ordnet jeden Kontrollmechanismus den Patterns und Wissenseinheiten zu, die ihn operationalisieren. Nutzen Sie sie als Freigabeprüfung (Readiness Gate), bevor Sie einen Agenten in der Produktionsumgebung agieren lassen.",
          "definition": "Die Governance-Checkliste für agentische KI ist ein operativer Satz von Kontrollmechanismen, der KI-Governance-Frameworks in konkrete, umsetzbare Anforderungen für autonome Agenten in der Produktionsumgebung überführt.",
          "scope": "Teams, die autonome oder teilautonome Agenten entwickeln oder bereitstellen, welche Tools nutzen, auf Systeme einwirken oder folgenschwere Entscheidungen treffen. Sie ist ein praktischer Begleiter zu den formalen Frameworks und kein Ersatz für eine Rechtsberatung.",
          "keyPoints": [
            "Risikobasierte menschliche Aufsicht: Knüpfen Sie folgenschwere, unumkehrbare oder regulierte Aktionen an eine menschliche Freigabe.",
            "Guardrails für Ein- und Ausgaben, einschließlich der Abwehr von Prompt-Injections und dem Schutz personenbezogener Daten (PII).",
            "Vollständige Audit-Protokollierung und Observability, damit jede Aktion nachvollziehbar ist.",
            "Evaluierung vor und nach der Bereitstellung anhand eines gepflegten Evaluierungssets (Eval-Set).",
            "Zugriffsrechte nach dem Prinzip der minimalen Rechtevergabe (Least Privilege) für Tools und Daten, auf die der Agent zugreifen kann.",
            "Eine definierte Incident Response und ein Notausschalter (Kill-Switch) für Agenten in der Produktionsumgebung."
          ],
          "controls": [
            {
              "control": "Menschliche Freigabestufen",
              "note": "Leiten Sie folgenschwere Aktionen über einen menschlichen Kontrollpunkt (EU AI Act Art. 14). Implementiert das Pattern „human-approval-gate“."
            },
            {
              "control": "Guardrails",
              "note": "Validieren und beschränken Sie Ein- und Ausgaben; wehren Sie Prompt-Injections ab und blockieren Sie richtlinienwidrige Aktionen."
            },
            {
              "control": "Audit-Protokollierung & Observability",
              "note": "Verfolgen Sie jede Entscheidung, jeden Tool-Aufruf und jede Aktion, damit der Agent überprüfbar ist und Vorfälle rekonstruiert werden können."
            },
            {
              "control": "Evaluierungs-Harness",
              "note": "Bewerten Sie das Verhalten vor der Auslieferung anhand eines Eval-Sets und überwachen Sie es danach auf Regressionen – NIST „Measure“."
            },
            {
              "control": "Least-Privilege-Zugriff",
              "note": "Beschränken Sie die Tools, Daten und Berechtigungen, auf die ein Agent zugreifen kann, auf das für seine Aufgabe erforderliche Minimum."
            },
            {
              "control": "Incident Response & Notausschalter",
              "note": "Definieren Sie, wie ein Fehlverhalten des Agenten erkannt, gestoppt und behoben werden kann, einschließlich einer Möglichkeit, ihn sofort anzuhalten."
            }
          ],
          "checklist": [
            "Klassifizieren Sie das Risiko des Agenten und identifizieren Sie, welche Aktionen eine menschliche Freigabe erfordern.",
            "Implementieren Sie Guardrails für Ein-/Ausgaben und die Abwehr von Prompt-Injections.",
            "Aktivieren Sie eine durchgängige Audit-Protokollierung und Observability.",
            "Richten Sie ein Evaluierungsset ein und führen Sie es vor der Bereitstellung sowie kontinuierlich aus.",
            "Wenden Sie das Least-Privilege-Prinzip auf Tools, Daten und Anmeldedaten an.",
            "Definieren Sie Incident Response, Überwachungsschwellenwerte und einen Notausschalter.",
            "Ordnen Sie jeden Kontrollmechanismus Ihren Verpflichtungen aus dem EU AI Act, der ISO 42001 und dem NIST AI RMF zu.",
            "Dokumentieren Sie die Zuständigkeiten und überprüfen Sie den Agenten in regelmäßigen Abständen."
          ],
          "pitfalls": [
            "Einem Agenten „sicherheitshalber“ weitreichenden Zugriff auf Tools/Daten zu gewähren, was zu einem großen Schadensradius (Blast Radius) führt.",
            "Alles freigabepflichtig zu machen (Freigabemüdigkeit) oder gar nichts (keine Aufsicht), anstatt risikobasiert zu steuern.",
            "Bereitstellung ohne ein Eval-Set, sodass Qualität und Sicherheit ungemessen bleiben.",
            "Kein Notausschalter oder Incident-Plan für den Fall, dass sich ein Agent in der Produktionsumgebung fehlerhaft verhält.",
            "Ignorieren von Prompt-Injections als Angriffsfläche für Agenten, die Tools nutzen."
          ],
          "productionEvidence": {
            "context": "Teams, die einen autonomen oder teilautonomen Agenten in der Produktionsumgebung einsetzen, wo er Tools nutzt und folgenschwere Aktionen durchführt.",
            "scenario": "Vor dem Go-Live nutzt das Team die Checkliste als Freigabeprüfung (Readiness Gate): Klassifizierung des Risikos des Agenten, Verknüpfung folgenschwerer Aktionen mit menschlicher Freigabe, Hinzufügen von Guardrails und Schutz vor Prompt-Injections, Aktivierung von Audit-Protokollierung und Observability, Einrichtung eines Evaluierungssets, Beschränkung des Zugriffs nach dem Least-Privilege-Prinzip sowie Definition von Incident Response und eines Notausschalters.",
            "technology": "Ein Harness, das eine menschliche Freigabestufe, Guardrails, Audit-Protokollierung/Observability, ein Evaluierungs-Harness und einen beschränkten Zugriff auf Tools/Anmeldedaten kombiniert.",
            "load": "Wird vor der Bereitstellung pro Agent angewendet und regelmäßig überprüft; der aufwendigste Kontrollmechanismus (menschliche Freigabe) ist der kleinen Gruppe folgenschwerer Aktionen vorbehalten.",
            "results": "Beobachtetes Pattern: Teams, die risikobasiert steuern, das Least-Privilege-Prinzip durchsetzen und von Tag eins an Instrumentierung nutzen, begrenzen den Schadensradius von Agentenfehlern; diejenigen, die „sicherheitshalber“ weitreichenden Zugriff gewähren oder ohne Evals ausliefern, entdecken Fehler erst in der Produktion. Messen Sie die Angemessenheit von Eskalationen, die Rate fehlerhafter Aktionen und die mittlere Zeit bis zur Erkennung (Mean Time to Detect)."
          },
          "lessons": [
            "Betrachten Sie die Checkliste als Freigabeprüfung (Readiness Gate), nicht als einmaliges Audit – führen Sie sie erneut aus, wenn die Tools und die Autonomie des Agenten zunehmen.",
            "Der Least-Privilege-Zugriff und die risikobasierte menschliche Freigabe begrenzen den Schadensradius stärker als jede einzelne Guardrail.",
            "Ohne ein Evaluierungsset und eine Audit-Protokollierung vor dem Start können Sie einen sicheren Agenten nicht von einem glücklichen unterscheiden.",
            "Ordnen Sie jeden Kontrollmechanismus einem konkreten Verantwortlichen zu; Governance ohne Rechenschaftspflicht ist lediglich Dokumentation."
          ],
          "examples": [
            "Ein Agent, dessen Rückerstattungsaktion an eine menschliche Freigabe geknüpft ist, während schreibgeschützte Abfragen frei ausgeführt werden.",
            "Eine Guardrail, die eine per Prompt-Injection eingeschleuste Anweisung zur Datenexfiltration über ein Tool blockiert.",
            "Ein Evaluierungslauf, der eine Sicherheitsregression abfängt, bevor ein Agenten-Update ausgeliefert wird."
          ],
          "faqs": [
            {
              "q": "Ist dies ein Ersatz für den EU AI Act oder die ISO 42001?",
              "a": "Nein. Es handelt sich um einen praktischen Satz von Kontrollmechanismen, der deren Prinzipien für Agenten operationalisiert. Nutzen Sie ihn neben den formalen Frameworks und der Rechtsberatung, nicht anstelle dieser."
            },
            {
              "q": "Welcher Kontrollmechanismus ist für autonome Agenten am wichtigsten?",
              "a": "Risikobasierte menschliche Aufsicht plus Least-Privilege-Zugriff und Audit-Protokollierung – zusammen begrenzen sie, was ein Agent tun kann, und machen jede Aktion nachvollziehbar."
            },
            {
              "q": "Wie hängt dies mit der Patterns-Bibliothek zusammen?",
              "a": "Jeder Kontrollmechanismus ist Patterns zugeordnet, die ihn implementieren – „human-approval-gate“ für die Aufsicht, „reflection“ und „evaluator-optimizer“ für die Qualität – sowie Wissenseinheiten wie Guardrails und KI-Observability."
            }
          ]
        },
        "ja": {
          "name": "エージェント型AIガバナンスチェックリスト",
          "summary": "企業におけるエージェント型AIを統制するための、実用的かつベンダーニュートラルなチェックリスト。EU AI法、ISO/IEC 42001、NIST AI RMFの原則を、ハーネスに実装可能な具体的なコントロールに変換します。人間による監視、ガードレール、監査ログ、評価、アクセス制御、プロンプトインジェクション対策、インシデント対応をカバーし、各コントロールをそれを具現化するパターンやナレッジユニットにマッピングします。エージェントを本番環境で動作させる前のレディネスゲートとしてご活用ください。",
          "definition": "エージェント型AIガバナンスチェックリストは、AIガバナンスフレームワークを、本番環境で動作する自律型エージェント向けの具体的かつ実装可能な要件へと変換する、運用コントロールセットです。",
          "scope": "ツールを使用し、システム上で動作し、または重大な意思決定を行う、自律型または半自律型エージェントを構築またはデプロイするチーム。本チェックリストは、公式なフレームワークを補完する実用的なガイドであり、法的助言に代わるものではありません。",
          "keyPoints": [
            "リスクに応じた人間による監視：影響が大きく、不可逆的、または規制対象となるアクションを、人間の承認ゲートに通すこと。",
            "プロンプトインジェクションやPII（個人特定情報）保護を含む、入力および出力に対するガードレール。",
            "すべてのアクションを追跡可能にするための、完全な監査ログとオブザーバビリティ。",
            "メンテナンスされた評価セットを用いた、デプロイ前後での評価。",
            "エージェントがアクセスできるツールおよびデータに対する、最小権限アクセスの適用。",
            "本番環境のエージェントに対する、定義されたインシデント対応とキルスイッチ。"
          ],
          "controls": [
            {
              "control": "人間の承認ゲート",
              "note": "影響の大きいアクションを人間のチェックポイント経由でルーティングする（EU AI法 第14条）。human-approval-gateパターンを実装します。"
            },
            {
              "control": "ガードレール",
              "note": "入出力を検証・制限し、プロンプトインジェクションを防御し、ポリシー違反のアクションをブロックする。"
            },
            {
              "control": "監査ログとオブザーバビリティ",
              "note": "すべての意思決定、ツール呼び出し、アクションを追跡し、エージェントのレビューを可能にし、インシデントを再構成できるようにする。"
            },
            {
              "control": "評価ハーネス",
              "note": "リリース前に評価セットに対して振る舞いをスコアリングし、リリース後にデグレード（退行）を監視する（NISTの「測定（Measure）」に該当）。"
            },
            {
              "control": "最小権限アクセス",
              "note": "エージェントがアクセスできるツール、データ、権限のスコープを、タスクに必要な最小限に制限する。"
            },
            {
              "control": "インシデント対応とキルスイッチ",
              "note": "異常な動作をするエージェントを検知、停止、修復する方法（即時停止する方法を含む）を定義する。"
            }
          ],
          "checklist": [
            "エージェントのリスクを分類し、どのアクションに人間の承認が必要かを特定する。",
            "入出力に対するガードレールとプロンプトインジェクション対策を実装する。",
            "エンドツーエンドの監査ログとオブザーバビリティを有効にする。",
            "評価セットを構築し、デプロイ前および継続的に実行する。",
            "ツール、データ、資格情報に対して最小権限のスコープを適用する。",
            "インシデント対応、監視しきい値、およびキルスイッチを定義する。",
            "各コントロールを、EU AI法、ISO 42001、NIST AI RMFに基づく義務にマッピングする。",
            "所有権を文書化し、定期的なスケジュールでエージェントをレビューする。"
          ],
          "pitfalls": [
            "「念のため」としてエージェントに広範なツールやデータへのアクセス権を付与し、影響範囲（ブラストライジアス）を拡大させてしまうこと。",
            "リスクに応じたゲート設定を行わず、すべてをゲートに通す（承認疲れを招く）、あるいは何も通さない（監視がない）状態にしてしまうこと。",
            "評価セットなしでリリースしてしまい、品質と安全性が測定されないこと。",
            "本番環境でエージェントが異常な動作をした際の、キルスイッチやインシデント計画がないこと。",
            "ツールを使用するエージェントのアタックサーフェス（攻撃対象領域）としてのプロンプトインジェクションを無視すること。"
          ],
          "productionEvidence": {
            "context": "ツールを使用し、重大なアクションを実行する自律型または半自律型エージェントを本番環境に導入するチーム。",
            "scenario": "本番稼働前に、チームはレディネスゲートとしてチェックリストを実行します。エージェントのリスクを分類し、影響の大きいアクションを人間の承認ゲートに通し、ガードレールとプロンプトインジェクション対策を追加し、監査ログとオブザーバビリティを有効にし、評価セットを構築し、最小権限アクセスのスコープを設定し、インシデント対応とキルスイッチを定義します。",
            "technology": "人間の承認ゲート、ガードレール、監査ログ/オブザーバビリティ、評価ハーネス、およびスコープ制限されたツール/資格情報アクセスを組み合わせたハーネス。",
            "load": "デプロイ前にエージェントごとに適用され、定期的なスケジュールで再レビューされます。最も重いコントロール（人間の承認）は、影響の大きい少数のアクションに限定して適用されます。",
            "results": "観察されたパターン：リスクに応じてゲートを設定し、最小権限を強制し、初日から計測（インストルメンテーション）を行うチームは、エージェントのエラーによる影響範囲を抑制できています。一方で、「念のため」として広範なアクセス権を付与したり、評価なしでリリースしたりするチームは、本番環境で障害に直面します。エスカレーションの適切性、誤アクション率、および平均検出時間を測定してください。"
          },
          "lessons": [
            "チェックリストは1回限りの監査ではなく、レディネスゲートとして扱い、エージェントのツールや自律性が向上するたびに再実行してください。",
            "最小権限アクセスとリスクに基づく人間の承認は、単一のガードレールよりも影響範囲を効果的に制限します。",
            "ローンチ前に評価セットと監査ログが整備されていなければ、安全なエージェントと、単に運が良いだけのエージェントを区別することはできません。",
            "各コントロールを具体的な所有者にマッピングしてください。説明責任のないガバナンスは、単なる文書にすぎません。"
          ],
          "examples": [
            "返金アクションは人間の承認ゲートに通される一方で、読み取り専用の照会は自由に実行されるエージェント。",
            "ツールを介してデータを流出させようとする、プロンプトインジェクションによる指示をブロックするガードレール。",
            "エージェントのアップデートがリリースされる前に、安全性のデグレード（退行）を検出する評価の実行。"
          ],
          "faqs": [
            {
              "q": "これはEU AI法やISO 42001の代わりになりますか？",
              "a": "いいえ。これは、それらの原則をエージェント向けに運用可能にする実用的なコントロールセットです。公式なフレームワークや法的助言の代わりとしてではなく、それらと併せて使用してください。"
            },
            {
              "q": "自律型エージェントにとって最も重要なコントロールは何ですか？",
              "a": "リスクに基づく人間による監視に加えて、最小権限アクセスと監査ログです。これらが組み合わさることで、エージェントができることを制限し、すべてのアクションに説明責任を持たせることができます。"
            },
            {
              "q": "これはパターンライブラリとどのように接続していますか？",
              "a": "各コントロールは、それを実装するパターン（監視のためのhuman-approval-gate、品質のためのreflectionやevaluator-optimizerなど）や、ガードレール、AIオブザーバビリティなどのナレッジユニットにマッピングされています。"
            }
          ]
        },
        "zh": {
          "name": "智能体 AI 治理清单",
          "summary": "一份实用且不绑定特定厂商的清单，用于在企业中治理智能体 AI —— 将 EU AI Act、ISO/IEC 42001 和 NIST AI RMF 的原则转化为可在支撑系统中实施的具体控制措施。它涵盖了人工监督、护栏、审计日志、评估、访问控制、提示词注入防御和事件响应，并将每项控制措施映射到使其落地运行的模式和知识单元。在允许智能体在生产环境中运行之前，将其用作就绪性闸口。",
          "definition": "智能体 AI 治理清单是一套操作性控制集，它将 AI 治理框架转化为针对在生产环境中运行的自主智能体的具体、可实施的要求。",
          "scope": "适用于构建或部署使用工具、在系统上执行操作或做出重大决策的自主或半自主智能体的团队。它是正式框架的实用指南，不能替代法律咨询。",
          "keyPoints": [
            "基于风险的人工监督：对高影响、不可逆或受监管的操作设置人工审批闸口。",
            "输入和输出的护栏，包括提示词注入 and PII 防御。",
            "完整的审计日志和可观测性，确保每项操作都可追溯。",
            "部署前后的评估，对照维护的评估集进行。",
            "对智能体可触及的工具和数据实行最小特权访问。",
            "为生产环境中的智能体定义明确的事件响应和紧急停机开关（kill-switch）。"
          ],
          "controls": [
            {
              "control": "人工审批闸口",
              "note": "将高影响操作路由至人工检查点（EU AI Act 第 14 条）。实现 human-approval-gate 模式。"
            },
            {
              "control": "护栏",
              "note": "验证并约束输入和输出；防御提示词注入并阻止违反策略的操作。"
            },
            {
              "control": "审计日志与可观测性",
              "note": "追溯每一次决策、工具调用和操作，使智能体可被审查，且事件可被重现。"
            },
            {
              "control": "评估支撑系统",
              "note": "在发布前对照评估集对行为进行评分，并在发布后监控退化情况 —— NIST 'Measure'。"
            },
            {
              "control": "最小特权访问",
              "note": "将智能体可触及的工具、数据和权限限制在其任务所需的最低限度。"
            },
            {
              "control": "事件响应与紧急停机开关",
              "note": "定义如何检测、停止和纠正行为异常的智能体，包括立即暂停其运行的方法。"
            }
          ],
          "checklist": [
            "对智能体的风险进行分类，并识别哪些操作需要人工审批。",
            "实施输入/输出护栏和提示词注入防御。",
            "启用端到端审计日志和可观测性。",
            "建立评估集，并在部署前及运行中持续运行该评估集。",
            "对工具、数据和凭据应用最小特权范围限制。",
            "定义事件响应、监控阈值 and 紧急停机开关。",
            "将每项控制措施映射到您在 EU AI Act、ISO 42001 和 NIST AI RMF 下的义务。",
            "记录所有权并定期审查智能体。"
          ],
          "pitfalls": [
            "为了“安全起见”授予智能体广泛的工具/数据访问权限，从而造成巨大的爆炸半径。",
            "对所有操作都设置闸口（导致审批疲劳）或完全不设闸口（缺乏监督），而不是基于风险设置闸口。",
            "在没有评估集的情况下发布，导致质量和安全性无法衡量。",
            "当智能体在生产环境中行为异常时，没有紧急停机开关或事件应对计划。",
            "忽视提示词注入作为使用工具的智能体的攻击面。"
          ],
          "productionEvidence": {
            "context": "将自主或半自主智能体投入生产环境，使其使用工具并执行重大操作的团队。",
            "scenario": "在上线前，团队将该清单作为就绪性闸口运行：对智能体的风险进行分类、对高影响操作设置人工审批闸口、添加护栏和提示词注入防御、启用审计日志和可观测性、建立评估集、限制最小特权访问，并定义事件响应和紧急停机开关。",
            "technology": "一个结合了人工审批闸口、护栏、审计日志/可观测性、评估支撑系统以及受限工具/凭据访问的支撑系统。",
            "load": "在部署前应用于每个智能体，并定期重新审查；最重的控制措施（人工审批）仅保留给少数高影响操作。",
            "results": "观察到的模式：从第一天起就基于风险设置闸口、强制执行最小特权并进行插桩的团队，能够控制智能体错误的影响范围；而那些为了“安全起见”授予广泛访问权限或在没有评估的情况下发布的团队，则会在生产环境中发现故障。衡量指标包括升级适当性、错误操作率和平均检测时间。"
          },
          "lessons": [
            "将清单视为就绪性闸口，而不是一次性审计 —— 随着智能体工具和自主性的增加，应重新运行该清单。",
            "与任何单一护栏相比，最小特权访问和基于风险的人工审批更能限制爆炸半径。",
            "如果在发布前没有建立评估集和审计日志，你将无法区分一个安全的智能体和一个仅仅是运气好的智能体。",
            "将每项控制措施映射到具体的责任人；没有问责制的治理仅仅是文档。"
          ],
          "examples": [
            "一个退款操作需要人工审批，而只读查询可以自由运行的智能体。",
            "一个阻止通过工具外泄数据的提示词注入指令的护栏。",
            "在智能体更新发布前捕获安全性退化的评估运行。"
          ],
          "faqs": [
            {
              "q": "这可以替代 EU AI Act 或 ISO 42001 吗？",
              "a": "不能。它是一套实用的控制集，旨在将这些原则落实到智能体的运行中。请将其与正式框架和法律咨询结合使用，而不是取而代之。"
            },
            {
              "q": "对于自主智能体来说，哪项控制措施最重要？",
              "a": "基于风险的人工监督，加上最小特权访问和审计日志 —— 它们共同限制了智能体可以执行的操作，并使每项操作都可问责。"
            },
            {
              "q": "它如何与模式库相联系？",
              "a": "每项控制措施都映射到实现它的模式 —— 用于监督的 human-approval-gate，用于质量的 reflection 和 evaluator-optimizer —— 以及诸如护栏和 AI 可观测性等知识单元。"
            }
          ]
        }
      }
    },
    {
      "id": "GOV-005",
      "slug": "enterprise-ai-governance-framework",
      "category": "framework",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/governance/enterprise-ai-governance-framework",
      "api": "https://santismm.com/api/governance/enterprise-ai-governance-framework",
      "canonical_url": "https://santismm.com/en/governance/enterprise-ai-governance-framework",
      "api_url": "https://santismm.com/api/governance/enterprise-ai-governance-framework",
      "evidence": {
        "evidenceLevel": "industry_observation",
        "confidenceLevel": "high",
        "sourceType": [
          "industry_observation",
          "paper"
        ]
      },
      "frameworks": [
        "EU AI Act",
        "ISO/IEC 42001",
        "NIST AI RMF"
      ],
      "patterns": [
        "human-approval-gate"
      ],
      "knowledge": [
        "ai-governance"
      ],
      "references": [
        {
          "title": "NIST — AI Risk Management Framework (AI RMF 1.0)",
          "url": "https://www.nist.gov/itl/ai-risk-management-framework"
        },
        {
          "title": "ISO/IEC 42001:2023 — Artificial intelligence management system",
          "url": "https://www.iso.org/standard/81230.html"
        },
        {
          "title": "OECD AI Principles",
          "url": "https://oecd.ai/en/ai-principles"
        }
      ],
      "related": [
        "agentic-ai-governance-checklist",
        "eu-ai-act",
        "iso-42001",
        "nist-ai-rmf"
      ],
      "locales": {
        "en": {
          "name": "Enterprise AI Governance Framework",
          "summary": "An umbrella operating model for governing AI across an organization. It defines the principles, accountability (RACI), AI risk taxonomy, lifecycle gates and policy hierarchy that keep AI use lawful, safe and aligned with risk appetite. It harmonizes the EU AI Act, ISO/IEC 42001 and NIST AI RMF into one internal program — comply once, reuse everywhere — and composes the agentic governance checklist as its concrete control set. Use it to give every production AI system a named owner, a risk tier and a gate that can actually block a non-compliant deployment.",
          "definition": "An enterprise AI governance framework is the system of principles, roles, processes and controls by which an organization directs and controls how it builds, procures and operates AI so that AI use stays lawful, safe, effective and aligned with its risk appetite.",
          "scope": "Boards, AI governance committees, risk and compliance officers, and the product and engineering leaders who build and operate AI across the enterprise. It is an internal operating model that maps to named regulations and standards, not legal advice or a substitute for qualified counsel.",
          "keyPoints": [
            "Principles first: lawfulness, accountability, human oversight, transparency, fairness, safety and privacy by design anchor every policy.",
            "RACI accountability: every governance activity has a clear Responsible, Accountable, Consulted and Informed map, and every production system has one named owner.",
            "A risk taxonomy tiers use cases (unacceptable, high, limited, minimal) so control intensity is proportional to risk.",
            "Lifecycle gates attach entry and exit checks to each stage, from propose through retire.",
            "A policy hierarchy traces principles to policies, standards and concrete controls with named owners.",
            "Comply once, reuse everywhere: external obligations map to internal controls a single time and are shared across regimes."
          ],
          "controls": [
            {
              "control": "AI governance committee with a charter",
              "note": "A standing body with published decision rights sets risk appetite and policy, so accountability is structural rather than ad hoc."
            },
            {
              "control": "Named accountable system owner",
              "note": "Every production AI system has one human owner; this is the control most associated with incidents being caught and answered."
            },
            {
              "control": "Risk-tiering procedure and central register",
              "note": "A documented taxonomy classifies each use case before build and records it in an inventory, surfacing shadow AI and calibrating controls."
            },
            {
              "control": "Lifecycle entry and exit gates",
              "note": "Each stage from propose to retire has gates scaled to risk tier; an enforceable gate can block a non-compliant deployment."
            },
            {
              "control": "Policy hierarchy mapped to controls",
              "note": "Principles trace to policies, standards and concrete controls so obligations are operational, not aspirational."
            },
            {
              "control": "Independent audit and assurance",
              "note": "Periodic independent review tests that gates and controls actually hold, closing the loop back to the committee."
            }
          ],
          "checklist": [
            "Stand up an AI governance committee with a published charter and decision rights.",
            "Define the seven governing principles and trace every policy back to them.",
            "Publish a risk taxonomy with tiers and enumerate prohibited use cases blocked at intake.",
            "Build a central register of all AI systems with their tier and named owner.",
            "Attach entry and exit gates to each lifecycle stage, scaled to risk tier.",
            "Map the EU AI Act, ISO/IEC 42001 and NIST AI RMF to internal controls once and reuse them.",
            "Adopt the agentic governance checklist as the concrete control set for high-risk systems.",
            "Schedule re-tiering and independent audit on a recurring cadence."
          ],
          "pitfalls": [
            "Governance as paperwork: policies exist but no gate can actually block a non-compliant deployment.",
            "No accountable owner: systems ship with diffuse ownership and no one is answerable when they fail.",
            "Uniform controls: every system gets the same heavyweight process, so teams route around governance.",
            "Shadow AI: systems are built outside the register and stay invisible to risk.",
            "Static tiering: a use case's risk is set once and never re-evaluated as autonomy or scope grows."
          ],
          "examples": [
            "A regulated enterprise routes every new agent through a tier-based intake gate before any build begins.",
            "A high-risk customer-facing system gets the full control set and independent audit while a minimal-risk internal tool follows baseline hygiene only.",
            "EU AI Act, ISO/IEC 42001 and NIST AI RMF obligations are mapped to one internal control library and reused across the portfolio."
          ],
          "faqs": [
            {
              "q": "Is this framework legal advice?",
              "a": "No. It is a professional operating model that maps to named regulations and standards. Consult qualified counsel for binding compliance decisions."
            },
            {
              "q": "How does it relate to the agentic governance checklist and the specific regimes?",
              "a": "This framework owns the structure — principles, roles, taxonomy and gates — and composes the EU AI Act, ISO/IEC 42001 and NIST AI RMF and the agentic checklist as its concrete controls."
            },
            {
              "q": "What is the single highest-leverage element?",
              "a": "An enforceable gate plus a named accountable owner per system. Un-enforced policy is routed around within a quarter, and diffuse ownership means no one answers when a system fails."
            }
          ]
        },
        "es": {
          "name": "Marco de Gobernanza de IA Empresarial",
          "summary": "Un modelo operativo paraguas para gobernar la IA en toda la organización. Define los principios, la rendición de cuentas (RACI), la taxonomía de riesgo de IA, las puertas de ciclo de vida y la jerarquía de políticas que mantienen el uso de IA legal, seguro y alineado con el apetito de riesgo. Armoniza el EU AI Act, ISO/IEC 42001 y NIST AI RMF en un único programa interno —cumple una vez, reutiliza en todas partes— y compone el checklist de gobernanza agéntica como su conjunto concreto de controles. Úsalo para dar a cada sistema de IA en producción un responsable nombrado, un nivel de riesgo y una puerta que pueda realmente bloquear un despliegue no conforme.",
          "definition": "Un marco de gobernanza de IA empresarial es el sistema de principios, roles, procesos y controles con el que una organización dirige y controla cómo construye, adquiere y opera la IA para que su uso siga siendo legal, seguro, eficaz y alineado con su apetito de riesgo.",
          "scope": "Consejos de administración, comités de gobernanza de IA, responsables de riesgo y cumplimiento, y los líderes de producto e ingeniería que construyen y operan la IA en la empresa. Es un modelo operativo interno que mapea a regulaciones y estándares nombrados, no asesoramiento legal ni un sustituto del asesoramiento de un profesional cualificado.",
          "keyPoints": [
            "Los principios primero: legalidad, rendición de cuentas, supervisión humana, transparencia, equidad, seguridad y privacidad por diseño anclan cada política.",
            "Rendición de cuentas RACI: cada actividad de gobernanza tiene un mapa claro de Responsable, Aprobador, Consultado e Informado, y cada sistema en producción tiene un responsable nombrado.",
            "Una taxonomía de riesgo clasifica los casos de uso (inaceptable, alto, limitado, mínimo) para que la intensidad del control sea proporcional al riesgo.",
            "Las puertas de ciclo de vida añaden controles de entrada y salida a cada etapa, desde proponer hasta retirar.",
            "Una jerarquía de políticas traza los principios a políticas, estándares y controles concretos con responsables nombrados.",
            "Cumple una vez, reutiliza en todas partes: las obligaciones externas se mapean a controles internos una sola vez y se comparten entre regímenes."
          ],
          "controls": [
            {
              "control": "Comité de gobernanza de IA con un estatuto",
              "note": "Un órgano permanente con derechos de decisión publicados fija el apetito de riesgo y la política, de modo que la rendición de cuentas sea estructural y no ad hoc."
            },
            {
              "control": "Responsable nombrado del sistema",
              "note": "Cada sistema de IA en producción tiene un responsable humano; este es el control más asociado con que los incidentes se detecten y respondan."
            },
            {
              "control": "Procedimiento de tiering de riesgo y registro central",
              "note": "Una taxonomía documentada clasifica cada caso de uso antes de construir y lo registra en un inventario, sacando a la luz la IA en la sombra y calibrando los controles."
            },
            {
              "control": "Puertas de entrada y salida del ciclo de vida",
              "note": "Cada etapa, de proponer a retirar, tiene puertas escaladas al nivel de riesgo; una puerta exigible puede bloquear un despliegue no conforme."
            },
            {
              "control": "Jerarquía de políticas mapeada a controles",
              "note": "Los principios se trazan a políticas, estándares y controles concretos para que las obligaciones sean operativas, no aspiracionales."
            },
            {
              "control": "Auditoría y aseguramiento independientes",
              "note": "Una revisión independiente periódica comprueba que las puertas y los controles realmente se sostienen, cerrando el ciclo de vuelta al comité."
            }
          ],
          "checklist": [
            "Pon en marcha un comité de gobernanza de IA con un estatuto publicado y derechos de decisión.",
            "Define los siete principios rectores y traza cada política de vuelta a ellos.",
            "Publica una taxonomía de riesgo con niveles y enumera los casos de uso prohibidos bloqueados en la entrada.",
            "Construye un registro central de todos los sistemas de IA con su nivel y responsable nombrado.",
            "Añade puertas de entrada y salida a cada etapa del ciclo de vida, escaladas al nivel de riesgo.",
            "Mapea el EU AI Act, ISO/IEC 42001 y NIST AI RMF a controles internos una vez y reutilízalos.",
            "Adopta el checklist de gobernanza agéntica como conjunto concreto de controles para los sistemas de alto riesgo.",
            "Programa el re-tiering y la auditoría independiente con una cadencia recurrente."
          ],
          "pitfalls": [
            "Gobernanza como papeleo: las políticas existen pero ninguna puerta puede realmente bloquear un despliegue no conforme.",
            "Sin responsable nombrado: los sistemas se lanzan con propiedad difusa y nadie responde cuando fallan.",
            "Controles uniformes: cada sistema recibe el mismo proceso pesado, así que los equipos esquivan la gobernanza.",
            "IA en la sombra: los sistemas se construyen fuera del registro y permanecen invisibles para el riesgo.",
            "Tiering estático: el riesgo de un caso de uso se fija una vez y nunca se reevalúa a medida que crecen su autonomía o alcance."
          ],
          "examples": [
            "Una empresa regulada enruta cada nuevo agente por una puerta de entrada basada en niveles antes de que comience cualquier construcción.",
            "Un sistema de alto riesgo orientado al cliente recibe el conjunto completo de controles y auditoría independiente, mientras una herramienta interna de riesgo mínimo sigue solo la higiene básica.",
            "Las obligaciones del EU AI Act, ISO/IEC 42001 y NIST AI RMF se mapean a una única biblioteca de controles interna y se reutilizan en todo el portafolio."
          ],
          "faqs": [
            {
              "q": "¿Este marco es asesoramiento legal?",
              "a": "No. Es un modelo operativo profesional que mapea a regulaciones y estándares nombrados. Consulta a un profesional cualificado para decisiones de cumplimiento vinculantes."
            },
            {
              "q": "¿Cómo se relaciona con el checklist de gobernanza agéntica y los regímenes específicos?",
              "a": "Este marco posee la estructura —principios, roles, taxonomía y puertas— y compone el EU AI Act, ISO/IEC 42001 y NIST AI RMF y el checklist agéntico como sus controles concretos."
            },
            {
              "q": "¿Cuál es el elemento de mayor palanca?",
              "a": "Una puerta exigible más un responsable nombrado por sistema. La política no exigida se esquiva en un trimestre, y la propiedad difusa significa que nadie responde cuando un sistema falla."
            }
          ]
        },
        "pt": {
          "name": "Framework de Governança de IA Empresarial",
          "summary": "Um modelo operacional guarda-chuva para governar a IA em toda a organização. Define os princípios, a prestação de contas (RACI), a taxonomia de risco de IA, os portões de ciclo de vida e a hierarquia de políticas que mantêm o uso de IA legal, seguro e alinhado ao apetite de risco. Harmoniza o EU AI Act, ISO/IEC 42001 e NIST AI RMF num único programa interno —cumpra uma vez, reutilize em todo lugar— e compõe o checklist de governança agêntica como seu conjunto concreto de controles. Use-o para dar a cada sistema de IA em produção um responsável nomeado, um nível de risco e um portão que possa de fato bloquear uma implantação não conforme.",
          "definition": "Um framework de governança de IA empresarial é o sistema de princípios, papéis, processos e controles pelo qual uma organização dirige e controla como constrói, adquire e opera a IA para que seu uso permaneça legal, seguro, eficaz e alinhado ao seu apetite de risco.",
          "scope": "Conselhos de administração, comitês de governança de IA, responsáveis por risco e conformidade, e os líderes de produto e engenharia que constroem e operam a IA na empresa. É um modelo operacional interno que mapeia para regulamentos e padrões nomeados, não aconselhamento jurídico nem um substituto de aconselhamento de um profissional qualificado.",
          "keyPoints": [
            "Princípios primeiro: legalidade, prestação de contas, supervisão humana, transparência, equidade, segurança e privacidade desde a concepção ancoram cada política.",
            "Prestação de contas RACI: cada atividade de governança tem um mapa claro de Responsável, Aprovador, Consultado e Informado, e cada sistema em produção tem um responsável nomeado.",
            "Uma taxonomia de risco classifica os casos de uso (inaceitável, alto, limitado, mínimo) para que a intensidade do controle seja proporcional ao risco.",
            "Os portões de ciclo de vida adicionam verificações de entrada e saída a cada etapa, de propor a aposentar.",
            "Uma hierarquia de políticas rastreia os princípios para políticas, padrões e controles concretos com responsáveis nomeados.",
            "Cumpra uma vez, reutilize em todo lugar: as obrigações externas mapeiam para controles internos uma única vez e são compartilhadas entre regimes."
          ],
          "controls": [
            {
              "control": "Comitê de governança de IA com um estatuto",
              "note": "Um órgão permanente com direitos de decisão publicados define o apetite de risco e a política, para que a prestação de contas seja estrutural e não ad hoc."
            },
            {
              "control": "Responsável nomeado pelo sistema",
              "note": "Cada sistema de IA em produção tem um responsável humano; este é o controle mais associado a incidentes serem detectados e respondidos."
            },
            {
              "control": "Procedimento de tiering de risco e registro central",
              "note": "Uma taxonomia documentada classifica cada caso de uso antes de construir e o registra num inventário, revelando a IA na sombra e calibrando os controles."
            },
            {
              "control": "Portões de entrada e saída do ciclo de vida",
              "note": "Cada etapa, de propor a aposentar, tem portões escalados ao nível de risco; um portão exigível pode bloquear uma implantação não conforme."
            },
            {
              "control": "Hierarquia de políticas mapeada para controles",
              "note": "Os princípios são rastreados para políticas, padrões e controles concretos para que as obrigações sejam operacionais, não aspiracionais."
            },
            {
              "control": "Auditoria e garantia independentes",
              "note": "Uma revisão independente periódica verifica que os portões e controles realmente se sustentam, fechando o ciclo de volta ao comitê."
            }
          ],
          "checklist": [
            "Estabeleça um comitê de governança de IA com um estatuto publicado e direitos de decisão.",
            "Defina os sete princípios norteadores e rastreie cada política de volta a eles.",
            "Publique uma taxonomia de risco com níveis e enumere os casos de uso proibidos bloqueados na entrada.",
            "Construa um registro central de todos os sistemas de IA com seu nível e responsável nomeado.",
            "Adicione portões de entrada e saída a cada etapa do ciclo de vida, escalados ao nível de risco.",
            "Mapeie o EU AI Act, ISO/IEC 42001 e NIST AI RMF para controles internos uma vez e reutilize-os.",
            "Adote o checklist de governança agêntica como conjunto concreto de controles para os sistemas de alto risco.",
            "Programe o re-tiering e a auditoria independente numa cadência recorrente."
          ],
          "pitfalls": [
            "Governança como papelada: as políticas existem mas nenhum portão pode de fato bloquear uma implantação não conforme.",
            "Sem responsável nomeado: os sistemas são lançados com propriedade difusa e ninguém responde quando falham.",
            "Controles uniformes: cada sistema recebe o mesmo processo pesado, então as equipes contornam a governança.",
            "IA na sombra: os sistemas são construídos fora do registro e permanecem invisíveis ao risco.",
            "Tiering estático: o risco de um caso de uso é definido uma vez e nunca reavaliado à medida que sua autonomia ou escopo crescem."
          ],
          "examples": [
            "Uma empresa regulada roteia cada novo agente por um portão de entrada baseado em níveis antes de qualquer construção começar.",
            "Um sistema de alto risco voltado ao cliente recebe o conjunto completo de controles e auditoria independente, enquanto uma ferramenta interna de risco mínimo segue apenas a higiene básica.",
            "As obrigações do EU AI Act, ISO/IEC 42001 e NIST AI RMF são mapeadas para uma única biblioteca de controles interna e reutilizadas em todo o portfólio."
          ],
          "faqs": [
            {
              "q": "Este framework é aconselhamento jurídico?",
              "a": "Não. É um modelo operacional profissional que mapeia para regulamentos e padrões nomeados. Consulte um profissional qualificado para decisões de conformidade vinculantes."
            },
            {
              "q": "Como se relaciona com o checklist de governança agêntica e os regimes específicos?",
              "a": "Este framework detém a estrutura —princípios, papéis, taxonomia e portões— e compõe o EU AI Act, ISO/IEC 42001 e NIST AI RMF e o checklist agêntico como seus controles concretos."
            },
            {
              "q": "Qual é o elemento de maior alavancagem?",
              "a": "Um portão exigível mais um responsável nomeado por sistema. A política não exigida é contornada em um trimestre, e a propriedade difusa significa que ninguém responde quando um sistema falha."
            }
          ]
        },
        "fr": {
          "name": "Cadre de gouvernance de l'IA d'entreprise",
          "summary": "Un modèle opérationnel global pour gouverner l'IA au sein d'une organisation. Il définit les principes, la responsabilisation (RACI), la taxonomie des risques liés à l'IA, les jalons de validation du cycle de vie et la hiérarchie des politiques qui garantissent une utilisation de l'IA légale, sûre et alignée sur l'appétence au risque. Il harmonise l'EU AI Act, l'ISO/CEI 42001 et le NIST AI RMF en un seul programme interne — se conformer une fois, réutiliser partout — et intègre la liste de contrôle de gouvernance des agents comme son ensemble de contrôles concrets. Utilisez-le pour attribuer à chaque système d'IA en production un propriétaire désigné, un niveau de risque et un jalon de validation capable de bloquer réellement un déploiement non conforme.",
          "definition": "Un cadre de gouvernance de l'IA d'entreprise est le système de principes, de rôles, de processus et de contrôles par lequel une organisation dirige et contrôle la manière dont elle conçoit, acquiert et exploite l'IA, afin que son utilisation reste légale, sûre, efficace et alignée sur son appétence au risque.",
          "scope": "Conseils d'administration, comités de gouvernance de l'IA, responsables des risques et de la conformité, ainsi que les responsables produits et ingénierie qui conçoivent et exploitent l'IA dans l'ensemble de l'entreprise. Il s'agit d'un modèle opérationnel interne qui correspond à des réglementations et des normes désignées, et non d'un conseil juridique ou d'un substitut à un conseiller qualifié.",
          "keyPoints": [
            "Les principes d'abord : la légalité, la responsabilisation, la surveillance humaine, la transparence, l'équité, la sécurité et la protection de la vie privée dès la conception (privacy by design) ancrent chaque politique.",
            "Responsabilisation RACI : chaque activité de gouvernance dispose d'une matrice RACI claire, et chaque système en production a un propriétaire désigné unique.",
            "Une taxonomie des risques hiérarchise les cas d'usage (inacceptable, élevé, limité, minimal) afin que l'intensité des contrôles soit proportionnelle au risque.",
            "Les jalons de validation du cycle de vie associent des contrôles d'entrée et de sortie à chaque étape, de la proposition au retrait.",
            "Une hiérarchie des politiques relie les principes aux politiques, normes et contrôles concrets dotés de propriétaires désignés.",
            "Se conformer une fois, réutiliser partout : les obligations externes sont associées aux contrôles internes une seule fois et sont partagées entre les différents régimes."
          ],
          "controls": [
            {
              "control": "Comité de gouvernance de l'IA doté d'une charte",
              "note": "Un organe permanent doté de droits de décision publiés définit l'appétence au risque et la politique, de sorte que la responsabilisation soit structurelle plutôt qu'ad hoc."
            },
            {
              "control": "Propriétaire de système responsable désigné",
              "note": "Chaque système d'IA en production a un propriétaire humain unique ; c'est le contrôle le plus souvent associé à la détection et à la résolution des incidents."
            },
            {
              "control": "Procédure de hiérarchisation des risques et registre central",
              "note": "Une taxonomie documentée classifie chaque cas d'usage avant sa conception et l'enregistre dans un inventaire, mettant en lumière le shadow AI et calibrant les contrôles."
            },
            {
              "control": "Jalons de validation d'entrée et de sortie du cycle de vie",
              "note": "Chaque étape, de la proposition au retrait, comporte des jalons de validation adaptés au niveau de risque ; un jalon contraignant peut bloquer un déploiement non conforme."
            },
            {
              "control": "Hiérarchie des politiques associée aux contrôles",
              "note": "Les principes se traduisent en politiques, normes et contrôles concrets afin que les obligations soient opérationnelles et non de simples aspirations."
            },
            {
              "control": "Audit indépendant et assurance",
              "note": "Un examen indépendant périodique permet de tester si les jalons de validation et les contrôles sont réellement efficaces, bouclant ainsi la boucle avec le comité."
            }
          ],
          "checklist": [
            "Mettre en place un comité de gouvernance de l'IA doté d'une charte publiée et de droits de décision.",
            "Définir les sept principes directeurs et y rattacher chaque politique.",
            "Publier une taxonomie des risques avec différents niveaux et énumérer les cas d'usage interdits bloqués dès la phase d'admission.",
            "Créer un registre central de tous les systèmes d'IA avec leur niveau de risque et leur propriétaire désigné.",
            "Associer des jalons de validation d'entrée et de sortie à chaque étape du cycle de vie, adaptés au niveau de risque.",
            "Associer l'EU AI Act, l'ISO/CEI 42001 et le NIST AI RMF aux contrôles internes une seule fois et les réutiliser.",
            "Adopter la liste de contrôle de gouvernance des agents comme ensemble de contrôles concrets pour les systèmes à haut risque.",
            "Planifier une réévaluation des niveaux de risque et un audit indépendant selon une cadence régulière."
          ],
          "pitfalls": [
            "La gouvernance comme simple formalité administrative : les politiques existent, mais aucun jalon de contrôle ne peut réellement bloquer un déploiement non conforme.",
            "Absence de responsable désigné : les systèmes sont mis en production avec une responsabilité diffuse et personne n'est garant en cas de défaillance.",
            "Contrôles uniformes : chaque système est soumis au même processus lourd, ce qui pousse les équipes à contourner la gouvernance.",
            "Shadow AI : des systèmes sont développés en dehors du registre et restent invisibles pour la gestion des risques.",
            "Classification statique : le niveau de risque d'un cas d'usage est défini une fois pour toutes et n'est jamais réévalué à mesure que son autonomie ou sa portée s'étendent."
          ],
          "examples": [
            "Une entreprise réglementée soumet chaque nouvel agent à un jalon d'évaluation basé sur les niveaux de risque avant de commencer tout développement.",
            "Un système à haut risque destiné aux clients bénéficie de l'ensemble complet de contrôles et d'un audit indépendant, tandis qu'un outil interne à risque minimal suit uniquement les règles d'hygiène de base.",
            "Les obligations de l'EU AI Act, de l'ISO/CEI 42001 et du NIST AI RMF sont associées à une bibliothèque de contrôles internes unique et réutilisées dans l'ensemble du portefeuille."
          ],
          "faqs": [
            {
              "q": "Ce cadre constitue-t-il un avis juridique ?",
              "a": "Non. Il s'agit d'un modèle opérationnel professionnel qui s'aligne sur des réglementations et des normes spécifiques. Consultez un conseiller juridique qualifié pour toute décision de conformité contraignante."
            },
            {
              "q": "Quel est le lien avec la checklist de gouvernance des agents et les différents cadres réglementaires ?",
              "a": "Ce cadre définit la structure — principes, rôles, taxonomie et jalons de contrôle — et intègre l'EU AI Act, l'ISO/CEI 42001, le NIST AI RMF ainsi que la checklist pour les agents en tant que contrôles concrets."
            },
            {
              "q": "Quel est l'élément unique ayant le plus fort impact ?",
              "a": "Un jalon de contrôle contraignant associé à un responsable désigné pour chaque système. Une politique non appliquée est contournée en moins d'un trimestre, et une responsabilité diffuse signifie que personne ne répond des défaillances d'un système."
            }
          ]
        },
        "de": {
          "name": "Enterprise AI Governance Framework",
          "summary": "Ein übergeordnetes Betriebsmodell für die KI-Governance im gesamten Unternehmen. Es definiert die Prinzipien, Verantwortlichkeiten (RACI), die KI-Risikotaxonomie, Lifecycle-Gates und die Richtlinienhierarchie, die sicherstellen, dass die KI-Nutzung rechtmäßig, sicher und im Einklang mit der Risikobereitschaft bleibt. Es harmonisiert den EU AI Act, ISO/IEC 42001 und das NIST AI RMF in einem einzigen internen Programm – einmal erfüllen, überall wiederverwenden – und nutzt die Checkliste für agentische Governance als konkretes Kontrollset. Nutzen Sie es, um jedem produktiven KI-System einen namentlich genannten Verantwortlichen, eine Risikostufe und ein Gate zuzuweisen, das eine nicht-konforme Bereitstellung tatsächlich blockieren kann.",
          "definition": "Ein Enterprise AI Governance Framework ist das System aus Prinzipien, Rollen, Prozessen und Kontrollen, mit dem ein Unternehmen die Entwicklung, Beschaffung und den Betrieb von KI steuert und kontrolliert, damit die KI-Nutzung rechtmäßig, sicher, effektiv und im Einklang mit der Risikobereitschaft bleibt.",
          "scope": "Vorstände, KI-Governance-Ausschüsse, Risiko- und Compliance-Beauftragte sowie Produkt- und Engineering-Leiter, die KI im gesamten Unternehmen entwickeln und betreiben. Es handelt sich um ein internes Betriebsmodell, das sich an bestimmten Vorschriften und Standards orientiert, und nicht um eine Rechtsberatung oder einen Ersatz für eine qualifizierte Rechtsberatung.",
          "keyPoints": [
            "Prinzipien zuerst: Rechtmäßigkeit, Rechenschaftspflicht, menschliche Aufsicht, Transparenz, Fairness, Sicherheit und Privacy by Design verankern jede Richtlinie.",
            "RACI-Verantwortlichkeiten: Jede Governance-Aktivität verfügt über eine klare Zuordnung (Responsible, Accountable, Consulted, Informed), und jedes Produktivsystem hat einen namentlich genannten Verantwortlichen.",
            "Eine Risikotaxonomie unterteilt Anwendungsfälle in Stufen (unzulässig, hoch, begrenzt, minimal), sodass die Kontrollintensität proportional zum Risiko ist.",
            "Lifecycle-Gates verknüpfen jede Phase, vom Vorschlag bis zur Außerbetriebnahme, mit Eingangs- und Ausgangsprüfungen.",
            "Eine Richtlinienhierarchie führt Prinzipien auf Richtlinien, Standards und konkrete Kontrollen mit namentlich genannten Verantwortlichen zurück.",
            "Einmal erfüllen, überall wiederverwenden: Externe Verpflichtungen werden ein einziges Mal internen Kontrollen zugeordnet und über verschiedene Regelwerke hinweg geteilt."
          ],
          "controls": [
            {
              "control": "KI-Governance-Ausschuss mit Statut",
              "note": "Ein ständiges Gremium mit veröffentlichten Entscheidungsrechten legt die Risikobereitschaft und Richtlinien fest, sodass die Rechenschaftspflicht strukturell und nicht ad hoc verankert ist."
            },
            {
              "control": "Namentlich genannter Systemverantwortlicher",
              "note": "Jedes produktive KI-System hat einen menschlichen Verantwortlichen; dies ist die Kontrolle, die am ehesten dazu beiträgt, dass Vorfälle erkannt und behoben werden."
            },
            {
              "control": "Verfahren zur Risikoeinstufung und zentrales Register",
              "note": "Eine dokumentierte Taxonomie klassifiziert jeden Anwendungsfall vor der Entwicklung und erfasst ihn in einem Inventar, wodurch Schatten-KI aufgedeckt und Kontrollen kalibriert werden."
            },
            {
              "control": "Lifecycle-Eingangs- und -Ausgangs-Gates",
              "note": "Jede Phase vom Vorschlag bis zur Außerbetriebnahme verfügt über Gates, die auf die Risikostufe abgestimmt sind; ein durchsetzbares Gate kann eine nicht-konforme Bereitstellung blockieren."
            },
            {
              "control": "Auf Kontrollen abgebildete Richtlinienhierarchie",
              "note": "Prinzipien lassen sich auf Richtlinien, Standards und konkrete Kontrollen zurückführen, sodass Verpflichtungen operativ und nicht nur theoretisch sind."
            },
            {
              "control": "Unabhängiges Audit und Assurance",
              "note": "Regelmäßige unabhängige Überprüfungen testen, ob Gates und Kontrollen tatsächlich greifen, und schließen den Kreis zurück zum Ausschuss."
            }
          ],
          "checklist": [
            "Richten Sie einen KI-Governance-Ausschuss mit einem veröffentlichten Statut und Entscheidungsrechten ein.",
            "Definieren Sie die sieben Leitprinzipien und führen Sie jede Richtlinie auf diese zurück.",
            "Veröffentlichen Sie eine Risikotaxonomie mit Stufen und listen Sie verbotene Anwendungsfälle auf, die bereits bei der Aufnahme blockiert werden.",
            "Erstellen Sie ein zentrales Register aller KI-Systeme mit ihrer Risikostufe und dem namentlich genannten Verantwortlichen.",
            "Verknüpfen Sie jede Lifecycle-Phase mit Eingangs- und Ausgangs-Gates, die auf die Risikostufe abgestimmt sind.",
            "Ordnen Sie den EU AI Act, ISO/IEC 42001 und das NIST AI RMF ein einziges Mal internen Kontrollen zu und verwenden Sie diese wieder.",
            "Übernehmen Sie die Checkliste für agentische Governance als konkretes Kontrollset für Hochrisikosysteme.",
            "Planen Sie die Neueinstufung (Re-Tiering) und unabhängige Audits in regelmäßigen Abständen."
          ],
          "pitfalls": [
            "Governance als reine Formsache: Richtlinien existieren, aber kein Kontrollpunkt (Gate) kann eine nicht-konforme Bereitstellung tatsächlich blockieren.",
            "Keine verantwortliche Person: Systeme werden mit unklaren Zuständigkeiten bereitgestellt, und niemand übernimmt die Verantwortung, wenn sie fehlschlagen.",
            "Einheitliche Kontrollen: Jedes System durchläuft denselben schwerfälligen Prozess, sodass Teams die Governance umgehen.",
            "Schatten-KI: Systeme werden außerhalb des Registers entwickelt und bleiben für das Risikomanagement unsichtbar.",
            "Statisches Tiering: Das Risiko eines Anwendungsfalls wird einmalig festgelegt und bei zunehmender Autonomie oder wachsendem Umfang nie neu bewertet."
          ],
          "examples": [
            "Ein reguliertes Unternehmen leitet jeden neuen Agenten vor Beginn der Entwicklung durch einen stufenbasierten Freigabeprozess (Intake Gate).",
            "Ein kundenorientiertes System mit hohem Risiko erhält das vollständige Kontrollset und ein unabhängiges Audit, während ein internes Tool mit minimalem Risiko nur grundlegende Sicherheitsmaßnahmen befolgt.",
            "Die Verpflichtungen aus dem EU AI Act, der ISO/IEC 42001 und dem NIST AI RMF werden in einer einzigen internen Kontrollbibliothek zusammengeführt und portfolioübergreifend wiederverwendet."
          ],
          "faqs": [
            {
              "q": "Stellt dieses Framework eine Rechtsberatung dar?",
              "a": "Nein. Es handelt sich um ein professionelles Betriebsmodell, das auf genannte Vorschriften und Standards abgestimmt ist. Wenden Sie sich für verbindliche Compliance-Entscheidungen an eine qualifizierte Rechtsberatung."
            },
            {
              "q": "Wie verhält es sich zur Checkliste für agentische Governance und den spezifischen Regelwerken?",
              "a": "Dieses Framework liefert die Struktur – Prinzipien, Rollen, Taxonomie und Gates – und integriert den EU AI Act, die ISO/IEC 42001, das NIST AI RMF sowie die agentische Checkliste als konkrete Kontrollmaßnahmen."
            },
            {
              "q": "Was ist das Element mit der absolut größten Hebelwirkung?",
              "a": "Ein durchsetzbares Gate plus eine namentlich benannte verantwortliche Person pro System. Nicht durchgesetzte Richtlinien werden innerhalb eines Quartals umgangen, und unklare Zuständigkeiten führen dazu, dass sich bei einem Systemausfall niemand verantwortlich fühlt."
            }
          ]
        },
        "ja": {
          "name": "エンタープライズAIガバナンスフレームワーク",
          "summary": "組織全体でAIを統治するための包括的な運用モデルです。AIの利用を合法かつ安全に保ち、リスク許容度に合わせるための原則、責任（RACI）、AIリスク分類、ライフサイクルゲート、およびポリシー階層を定義します。EU AI法、ISO/IEC 42001、NIST AI RMFを1つの内部プログラムに調和させ（一度の準拠でどこでも再利用可能）、エージェント型ガバナンスチェックリストを具体的なコントロールセットとして構成します。これを使用して、本番環境のすべてのAIシステムに指名された所有者、リスク層、および非準拠のデプロイを実際にブロックできるゲートを割り当てます。",
          "definition": "エンタープライズAIガバナンスフレームワークとは、組織がAIの構築、調達、運用を指揮・管理し、AIの利用が合法、安全、効果的であり、かつリスク許容度に合致するようにするための原則、役割、プロセス、およびコントロールの体系です。",
          "scope": "取締役会、AIガバナンス委員会、リスク・コンプライアンス担当者、および企業全体でAIを構築・運用するプロダクトおよびエンジニアリングのリーダーを対象としています。これは、特定の規制や標準に対応する内部運用モデルであり、法的助言や資格を持つ専門家によるカウンセルの代わりとなるものではありません。",
          "keyPoints": [
            "原則第一：合法性、説明責任、人間による監視、透明性、公平性、安全性、およびプライバシー・バイ・デザインが、すべてのポリシーの基盤となります。",
            "RACIによる責任の明確化：すべてのガバナンス活動に明確なRACI（実行責任者、説明責任者、協働者、報告先）マップが定義され、本番環境のすべてのシステムに1人の指名された所有者が存在します。",
            "リスク分類によるユースケースの階層化（許容不可、高、制限あり、最小限）により、コントロールの強度がリスクに比例するようにします。",
            "ライフサイクルゲートにより、提案から廃止に至るまでの各段階に開始および終了チェックを適用します。",
            "ポリシー階層により、原則からポリシー、標準、および指名された所有者を持つ具体的なコントロールへと追跡できるようにします。",
            "一度の準拠でどこでも再利用：外部の義務を内部コントロールに一度だけマッピングし、異なる制度間で共有します。"
          ],
          "controls": [
            {
              "control": "憲章を持つAIガバナンス委員会",
              "note": "公表された決定権を持つ常設組織がリスク許容度とポリシーを設定することで、説明責任がその場しのぎではなく構造的なものになります。"
            },
            {
              "control": "指名された説明責任のあるシステム所有者",
              "note": "本番環境のすべてのAIシステムに1人の人間の所有者が存在します。これは、インシデントの検知と対応に最も深く関連するコントロールです。"
            },
            {
              "control": "リスク階層化手順と中央レジストリ",
              "note": "文書化された分類法により、構築前に各ユースケースを分類してインベントリに記録することで、シャドーAIを浮き彫りにし、コントロールを調整します。"
            },
            {
              "control": "ライフサイクルの開始および終了ゲート",
              "note": "提案から廃止までの各段階に、リスク層に応じたゲートが設定されます。強制力のあるゲートにより、非準拠 of デプロイをブロックできます。"
            },
            {
              "control": "コントロールにマッピングされたポリシー階層",
              "note": "原則からポリシー、標準、および具体的なコントロールへと追跡できるようにすることで、義務を単なる願望ではなく、運用可能なものにします。"
            },
            {
              "control": "独立した監査とアシュアランス（保証）",
              "note": "定期的な独立したレビューにより、ゲートとコントロールが実際に機能しているかをテストし、委員会へのフィードバックループを完成させます。"
            }
          ],
          "checklist": [
            "公表された憲章と決定権を持つAIガバナンス委員会を立ち上げる。",
            "7つのガバナンス原則を定義し、すべてのポリシーをそれらに紐付ける。",
            "階層化されたリスク分類を公表し、受付段階でブロックされる禁止されたユースケースを列挙する。",
            "すべてのAIシステムのリスク層と指名された所有者を記載した中央レジストリを構築する。",
            "ライフサイクルの各段階に、リスク層に応じた開始および終了ゲートを適用する。",
            "EU AI法、ISO/IEC 42001、およびNIST AI RMFを内部コントロールに一度だけマッピングし、それらを再利用する。",
            "高リスクシステム向けの具体的なコントロールセットとして、エージェント型ガバナンスチェックリストを採用する。",
            "定期的なサイクルで再ティアリングと独立した監査をスケジュールします。"
          ],
          "pitfalls": [
            "ペーパーワークとしてのガバナンス：ポリシーは存在するものの、コンプライアンスに準拠していないデプロイを実際にブロックできるゲートが存在しない。",
            "責任ある所有者の不在：所有権が曖昧なままシステムがリリースされ、障害発生時に誰も責任を負わない。",
            "画一的なコントロール：すべてのシステムに同じ重いプロセスが適用されるため、チームがガバナンスを回避してしまう。",
            "シャドーAI：台帳の外でシステムが構築され、リスク管理の対象外（不可視）のままになる。",
            "静的なティアリング：ユースケースのリスクが一度設定されたきり、自律性やスコープが拡大しても再評価されない。"
          ],
          "examples": [
            "規制対象の企業が、構築を開始する前に、すべての新しいエージェントをティアベースのインテークゲートに通す。",
            "高リスクの顧客向けシステムには完全なコントロールセットと独立した監査が適用される一方、最小リスクの社内ツールにはベースラインの衛生管理のみが適用される。",
            "EU AI Act、ISO/IEC 42001、およびNIST AI RMFの義務が1つの内部コントロールライブラリにマッピングされ、ポートフォリオ全体で再利用される。"
          ],
          "faqs": [
            {
              "q": "このフレームワークは法的助言ですか？",
              "a": "いいえ。これは、特定の規制や標準にマッピングされた専門的な運用モデルです。法的拘束力のあるコンプライアンスの決定については、資格を持つ顧問弁護士にご相談ください。"
            },
            {
              "q": "エージェント型ガバナンスのチェックリストや特定の規制制度とはどのような関係がありますか？",
              "a": "このフレームワークは、原則、役割、タクソノミー、ゲートなどの構造を定義し、EU AI Act、ISO/IEC 42001、NIST AI RMF、およびエージェント型チェックリストを具体的なコントロールとして構成します。"
            },
            {
              "q": "最も効果の高い（レバレッジの効く）単一の要素は何ですか？",
              "a": "強制力のあるゲートと、システムごとの明確な責任ある所有者（Accountable Owner）の割り当てです。強制力のないポリシーは1四半期以内に形骸化し、所有権が曖昧であればシステム障害時に誰も責任を負いません。"
            }
          ]
        },
        "zh": {
          "name": "企业级 AI 治理框架",
          "summary": "一个用于在整个组织内治理 AI 的综合运行模型。它定义了原则、问责制（RACI）、AI 风险分类法、生命周期关卡和策略层级，以确保 AI 的使用合法、安全并符合风险偏好。它将《欧盟 AI 法案》（EU AI Act）、ISO/IEC 42001 和 NIST AI RMF 整合为一个内部项目——一次合规，到处复用——并将智能体治理清单作为其具体的控制集。使用它为每个生产环境中的 AI 系统指定明确的所有者、风险层级以及一个能够真正阻止非合规部署的关卡。",
          "definition": "企业级 AI 治理框架是指组织借以指导和控制其如何构建、采购和运行 AI 的原则、角色、流程和控制体系，以确保 AI 的使用保持合法、安全、有效并符合其风险偏好。",
          "scope": "董事会、AI 治理委员会、风险与合规官，以及在整个企业中构建和运行 AI 的产品与工程领导者。这是一个映射到指定法规和标准的内部运行模型，并非法律建议，也不能替代合格的法律顾问。",
          "keyPoints": [
            "原则至上：合法性、问责制、人类监督、透明度、公平性、安全性和源自设计的隐私保护（privacy by design）是每项策略的基石。",
            "RACI 问责制：每项治理活动都有明确的负责人（Responsible）、问责人（Accountable）、咨询人（Consulted）和知情人（Informed）映射，且每个生产系统都有一个明确指定的所有者。",
            "风险分类法将使用场景分层（不可接受、高、有限、极小），使控制强度与风险成正比。",
            "生命周期关卡为从提议到退役的每个阶段都附加了准入和准出检查。",
            "策略层级将原则追溯到策略、标准以及具有明确指定所有者的具体控制项。",
            "一次合规，到处复用：外部义务仅一次性映射到内部控制，并在不同的合规体系间共享。"
          ],
          "controls": [
            {
              "control": "拥有章程的 AI 治理委员会",
              "note": "一个拥有已公布决策权的常设机构，负责设定风险偏好和策略，使问责制成为结构性的，而非临时的。"
            },
            {
              "control": "明确指定的问责系统所有者",
              "note": "每个生产环境中的 AI 系统都有一个人类所有者；这是与发现并应对事件最密切相关的控制项。"
            },
            {
              "control": "风险分层程序与中央登记簿",
              "note": "在构建前，通过文件化的分类法对每个使用场景进行分类并记录在清单中，从而使影子 AI 显现并调整控制力度。"
            },
            {
              "control": "生命周期准入和准出关卡",
              "note": "从提议到退役的每个阶段都设有根据风险层级调整的关卡；可强制执行的关卡能够阻止非合规的部署。"
            },
            {
              "control": "映射到控制项的策略层级",
              "note": "原则追溯到策略、标准和具体的控制项，使合规义务具有可操作性，而非仅仅是愿景。"
            },
            {
              "control": "独立审计与保证",
              "note": "定期的独立审查测试关卡和控制项是否切实有效，从而向委员会形成闭环反馈。"
            }
          ],
          "checklist": [
            "组建一个拥有已公布章程和决策权的 AI 治理委员会。",
            "定义七项治理原则，并将每项策略追溯到这些原则。",
            "发布包含层级的风险分类法，并列出在准入阶段即被阻止的禁止使用场景。",
            "建立所有 AI 系统的中央登记簿，记录其风险层级和明确指定的所有者。",
            "为每个生命周期阶段附加准入和准出关卡，并根据风险层级进行调整。",
            "将《欧盟 AI 法案》（EU AI Act）、ISO/IEC 42001 和 NIST AI RMF 一次性映射到内部控制，并进行复用。",
            "采用智能体治理清单作为高风险系统的具体控制集。",
            "定期安排重新分级和独立审计。"
          ],
          "pitfalls": [
            "治理流于形式：政策确实存在，但没有任何关卡能真正阻止不合规的部署。",
            "缺乏明确的责任人：系统发布时权责不清，出现故障时无人负责。",
            "一刀切的控制：每个系统都采用同样繁重的流程，导致团队设法绕过治理。",
            "影子 AI：系统在登记册之外构建，脱离了风险监管视线。",
            "静态分级：用例的风险级别一经设定便不再重新评估，即使其自主性或范围有所扩大。"
          ],
          "examples": [
            "受监管的企业在开始任何构建之前，都会让每个新智能体通过基于分级的准入关卡。",
            "高风险的面向客户系统接受全套控制和独立审计，而极低风险的内部工具仅遵循基线规范。",
            "将 EU AI Act、ISO/IEC 42001 和 NIST AI RMF 的合规义务映射到统一的内部控制库中，并在整个产品组合中复用。"
          ],
          "faqs": [
            {
              "q": "该框架是否构成法律建议？",
              "a": "否。它是一个与特定法规和标准相映射的专业运营模型。如需做出具有约束力的合规决策，请咨询合格的法律顾问。"
            },
            {
              "q": "它与智能体治理清单及具体监管机制有何关系？",
              "a": "该框架负责定义结构（原则、角色、分类和关卡），并将 EU AI Act、ISO/IEC 42001、NIST AI RMF 以及智能体清单整合为其具体的控制措施。"
            },
            {
              "q": "哪一个是杠杆效应最高的单一要素？",
              "a": "强制执行的关卡加上每个系统指定的明确责任人。未强制执行的政策在一个季度内就会被绕过，而权责不清则意味着系统出现故障时无人负责。"
            }
          ]
        }
      }
    },
    {
      "id": "GOV-006",
      "slug": "audit-framework-for-agentic-systems",
      "category": "framework",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/governance/audit-framework-for-agentic-systems",
      "api": "https://santismm.com/api/governance/audit-framework-for-agentic-systems",
      "canonical_url": "https://santismm.com/en/governance/audit-framework-for-agentic-systems",
      "api_url": "https://santismm.com/api/governance/audit-framework-for-agentic-systems",
      "evidence": {
        "evidenceLevel": "industry_observation",
        "confidenceLevel": "medium",
        "sourceType": [
          "industry_observation",
          "paper"
        ]
      },
      "frameworks": [
        "ISO/IEC 42001",
        "NIST AI RMF"
      ],
      "patterns": [
        "human-approval-gate",
        "evaluator-optimizer"
      ],
      "knowledge": [
        "ai-observability",
        "agentic-evaluation",
        "ai-governance"
      ],
      "references": [
        {
          "title": "NIST — AI Risk Management Framework (AI RMF 1.0)",
          "url": "https://www.nist.gov/itl/ai-risk-management-framework"
        },
        {
          "title": "ISO/IEC 42001:2023 — AI management systems",
          "url": "https://www.iso.org/standard/81230.html"
        },
        {
          "title": "ISACA — Auditing Artificial Intelligence",
          "url": "https://www.isaca.org/resources/white-papers/2024/auditing-artificial-intelligence"
        }
      ],
      "related": [
        "agentic-ai-governance-checklist",
        "nist-ai-rmf",
        "iso-42001",
        "owasp-llm-top10",
        "mitre-atlas"
      ],
      "locales": {
        "en": {
          "name": "Audit Framework for Agentic Systems",
          "summary": "A practical, vendor-neutral framework for making an agent auditable and for auditing it. It defines the evidence an independent reviewer needs — immutable, correlated traces of every decision and tool call, model and version provenance, evaluation reports, approval and incident records — and how to test controls and sample high-volume runs. Each evidence type maps to ISO/IEC 42001 and NIST AI RMF so an auditor can verify the agent stayed within its governed bounds. Use it to design auditability in from the start, not as an afterthought.",
          "definition": "An agent audit is an independent, evidence-based examination that determines whether an agentic system operated within its authorized scope, controls and policies over a defined period, and whether the governance claims made about it are supported by reliable evidence.",
          "scope": "Auditors, assurance and risk teams, and the system owners who must make their agents auditable by design. It applies to autonomous or semi-autonomous agents that use tools and act over time, and supports both internal assurance and external or regulatory audit. It is a practical companion to the formal frameworks, not a substitute for legal advice.",
          "keyPoints": [
            "Auditability by design: the agent must emit enough structured evidence at runtime to reconstruct any run later.",
            "Every run produces an immutable, correlated trace: goal, each step and tool call with parameters and results, approvals, overrides and outcome.",
            "Evidence must be complete, attributable, time-stamped and tamper-evident to hold evidentiary value.",
            "Model and version provenance (prompt, tools, model) is captured per run so behaviour is tied to a known configuration.",
            "Sampling is layered: risk-stratified, statistical, and 100% review of all exceptions, overrides, denials and incidents.",
            "Audit evidence maps to ISO/IEC 42001 internal audit (Clause 9) and NIST AI RMF Measure and Manage functions."
          ],
          "controls": [
            {
              "control": "Immutable audit logs and traceability",
              "note": "Capture a correlated trace per run — agent identity and version, goal, each step, tool call, result, approvals and outcome — and protect it against alteration. Implements AI observability."
            },
            {
              "control": "Model and version provenance",
              "note": "Record the exact prompt, tool set and model version behind each run so behaviour is attributable to a known, reproducible-by-config baseline."
            },
            {
              "control": "Evaluation evidence",
              "note": "Retain pre-deployment and ongoing evaluation reports and gate results so the auditor can verify safety and quality were measured — NIST 'Measure'."
            },
            {
              "control": "Control testing and sampling",
              "note": "Test each control against evidence using a documented sampling methodology: risk-stratified, statistical, and full exception review."
            },
            {
              "control": "Approval and incident records",
              "note": "Capture human approvals, overrides and incidents with actor identity and timestamps. Implements the human-approval-gate pattern."
            },
            {
              "control": "Attestations and findings management",
              "note": "System and control owners sign attestations backed by evidence; findings are tracked to closure with severity and deadlines."
            }
          ],
          "checklist": [
            "Confirm every agent run produces a complete, correlated trace tied by a stable trace ID.",
            "Verify logs are tamper-evident, time-stamped and retained for the full audit and regulatory window.",
            "Check that each run records model and version provenance (prompt, tools, model version).",
            "Retrieve a control mapping / Statement of Applicability linking each control to its evidence.",
            "Retain and review pre-deployment and ongoing evaluation reports and gate outcomes.",
            "Confirm approval, override and incident records exist with actor identity and timestamps.",
            "Apply a documented sampling methodology — risk-stratified, statistical, and 100% exception coverage.",
            "Track findings to closure with severity and deadlines, and collect signed owner attestations."
          ],
          "pitfalls": [
            "Non-auditable agents: logging added as an afterthought, leaving gaps no audit can fill.",
            "Mutable logs: records that could be altered, destroying their evidentiary value.",
            "Sampling blind spots: random-only sampling that misses rare but catastrophic actions.",
            "Attestation without evidence: owners signing off on controls they cannot demonstrate.",
            "Findings graveyard: issues raised but never remediated or re-tested."
          ],
          "examples": [
            "An auditor reconstructs a disputed refund by following its correlated trace from goal to tool call to human approval.",
            "A continuous-audit check alerts on a tool call outside the allow-list against the live log stream.",
            "Retained evaluation reports map to NIST AI RMF Measure, evidencing that safety gates passed before deployment."
          ],
          "faqs": [
            {
              "q": "Can you audit a non-deterministic agent at all?",
              "a": "Yes — you audit the controls and the recorded behaviour, not the determinism. Complete, immutable traces make any specific run reconstructable even if it cannot be reproduced exactly."
            },
            {
              "q": "How big should the audit sample be?",
              "a": "Large enough for your target assurance level statistically, plus 100% of exceptions and high-impact actions. Sampling never replaces full exception review."
            },
            {
              "q": "How does audit evidence map to the frameworks?",
              "a": "Traces and logs support NIST AI RMF Measure and Manage and ISO/IEC 42001 Clause 9 internal audit; a control mapping or Statement of Applicability links each control to the evidence that proves it operated."
            }
          ]
        },
        "es": {
          "name": "Marco de Auditoría para Sistemas Agénticos",
          "summary": "Un marco práctico y neutral para hacer un agente auditable y para auditarlo. Define la evidencia que necesita un revisor independiente —trazas inmutables y correlacionadas de cada decisión y llamada a herramienta, procedencia de modelo y versión, informes de evaluación, registros de aprobación e incidentes— y cómo probar controles y muestrear ejecuciones de alto volumen. Cada tipo de evidencia se mapea a ISO/IEC 42001 y NIST AI RMF para que un auditor pueda verificar que el agente se mantuvo dentro de sus límites gobernados. Úsalo para diseñar la auditabilidad desde el inicio, no como algo añadido después.",
          "definition": "Una auditoría de agente es un examen independiente y basado en evidencia que determina si un sistema agéntico operó dentro de su alcance, controles y políticas autorizados durante un periodo definido, y si las afirmaciones de gobernanza hechas sobre él se sustentan en evidencia fiable.",
          "scope": "Auditores, equipos de aseguramiento y de riesgo, y los responsables del sistema que deben hacer sus agentes auditables por diseño. Aplica a agentes autónomos o semiautónomos que usan herramientas y actúan a lo largo del tiempo, y da soporte tanto al aseguramiento interno como a la auditoría externa o regulatoria. Es un compañero práctico de los marcos formales, no un sustituto del asesoramiento legal.",
          "keyPoints": [
            "Auditabilidad por diseño: el agente debe emitir suficiente evidencia estructurada en tiempo de ejecución para reconstruir cualquier ejecución después.",
            "Cada ejecución produce una traza inmutable y correlacionada: objetivo, cada paso y llamada a herramienta con parámetros y resultados, aprobaciones, anulaciones y resultado.",
            "La evidencia debe ser completa, atribuible, con marca de tiempo y a prueba de manipulación para tener valor probatorio.",
            "La procedencia de modelo y versión (prompt, herramientas, modelo) se captura por ejecución para que el comportamiento quede ligado a una configuración conocida.",
            "El muestreo es por capas: estratificado por riesgo, estadístico, y revisión al 100% de todas las excepciones, anulaciones, denegaciones e incidentes.",
            "La evidencia de auditoría se mapea a la auditoría interna de ISO/IEC 42001 (Cláusula 9) y a las funciones Medir y Gestionar de NIST AI RMF."
          ],
          "controls": [
            {
              "control": "Registros de auditoría inmutables y trazabilidad",
              "note": "Captura una traza correlacionada por ejecución —identidad y versión del agente, objetivo, cada paso, llamada a herramienta, resultado, aprobaciones y resultado— y protégela contra alteración. Implementa la observabilidad de IA."
            },
            {
              "control": "Procedencia de modelo y versión",
              "note": "Registra el prompt exacto, el conjunto de herramientas y la versión del modelo detrás de cada ejecución para que el comportamiento sea atribuible a una base conocida y reproducible por configuración."
            },
            {
              "control": "Evidencia de evaluación",
              "note": "Conserva los informes de evaluación previos al despliegue y continuos y los resultados de las puertas para que el auditor pueda verificar que se midieron la seguridad y la calidad: el 'Medir' del NIST."
            },
            {
              "control": "Prueba de controles y muestreo",
              "note": "Prueba cada control frente a la evidencia usando una metodología de muestreo documentada: estratificada por riesgo, estadística y revisión completa de excepciones."
            },
            {
              "control": "Registros de aprobación e incidentes",
              "note": "Captura aprobaciones humanas, anulaciones e incidentes con la identidad del actor y marcas de tiempo. Implementa el patrón de puerta de aprobación humana."
            },
            {
              "control": "Atestaciones y gestión de hallazgos",
              "note": "Los responsables del sistema y de los controles firman atestaciones respaldadas por evidencia; los hallazgos se siguen hasta su cierre con severidad y plazos."
            }
          ],
          "checklist": [
            "Confirma que cada ejecución del agente produce una traza completa y correlacionada ligada por un ID de traza estable.",
            "Verifica que los registros son a prueba de manipulación, con marca de tiempo y conservados durante toda la ventana de auditoría y regulatoria.",
            "Comprueba que cada ejecución registra la procedencia de modelo y versión (prompt, herramientas, versión del modelo).",
            "Obtén un mapeo de controles / Declaración de Aplicabilidad que vincule cada control con su evidencia.",
            "Conserva y revisa los informes de evaluación previos al despliegue y continuos y los resultados de las puertas.",
            "Confirma que existen registros de aprobación, anulación e incidentes con identidad del actor y marcas de tiempo.",
            "Aplica una metodología de muestreo documentada: estratificada por riesgo, estadística y cobertura del 100% de excepciones.",
            "Sigue los hallazgos hasta su cierre con severidad y plazos, y recoge atestaciones firmadas de los responsables."
          ],
          "pitfalls": [
            "Agentes no auditables: registro añadido como algo tardío, dejando huecos que ninguna auditoría puede llenar.",
            "Registros mutables: registros que podrían alterarse, destruyendo su valor probatorio.",
            "Puntos ciegos del muestreo: muestreo solo aleatorio que pasa por alto acciones raras pero catastróficas.",
            "Atestación sin evidencia: responsables que firman controles que no pueden demostrar.",
            "Cementerio de hallazgos: problemas planteados pero nunca remediados ni vueltos a probar."
          ],
          "examples": [
            "Un auditor reconstruye un reembolso en disputa siguiendo su traza correlacionada desde el objetivo a la llamada a herramienta y a la aprobación humana.",
            "Un control de auditoría continua alerta sobre una llamada a herramienta fuera de la lista permitida contra el flujo de registros en vivo.",
            "Los informes de evaluación conservados se mapean al Medir de NIST AI RMF, evidenciando que las puertas de seguridad pasaron antes del despliegue."
          ],
          "faqs": [
            {
              "q": "¿Se puede auditar un agente no determinista?",
              "a": "Sí: auditas los controles y el comportamiento registrado, no el determinismo. Las trazas completas e inmutables hacen reconstruible cualquier ejecución concreta aunque no se pueda reproducir exactamente."
            },
            {
              "q": "¿Qué tamaño debe tener la muestra de auditoría?",
              "a": "Suficiente para tu nivel de aseguramiento objetivo de forma estadística, más el 100% de las excepciones y las acciones de alto impacto. El muestreo nunca reemplaza la revisión completa de excepciones."
            },
            {
              "q": "¿Cómo se mapea la evidencia de auditoría a los marcos?",
              "a": "Las trazas y registros dan soporte a Medir y Gestionar de NIST AI RMF y a la auditoría interna de la Cláusula 9 de ISO/IEC 42001; un mapeo de controles o Declaración de Aplicabilidad vincula cada control con la evidencia que prueba que operó."
            }
          ]
        },
        "pt": {
          "name": "Framework de Auditoria para Sistemas Agênticos",
          "summary": "Um framework prático e neutro para tornar um agente auditável e para auditá-lo. Define a evidência que um revisor independente precisa — traços imutáveis e correlacionados de cada decisão e chamada de ferramenta, proveniência de modelo e versão, relatórios de avaliação, registros de aprovação e incidentes — e como testar controles e amostrar execuções de alto volume. Cada tipo de evidência é mapeado para ISO/IEC 42001 e NIST AI RMF, para que um auditor possa verificar se o agente se manteve dentro de seus limites governados. Use-o para projetar a auditabilidade desde o início, não como algo adicionado depois.",
          "definition": "Uma auditoria de agente é um exame independente e baseado em evidência que determina se um sistema agêntico operou dentro de seu escopo, controles e políticas autorizados durante um período definido, e se as alegações de governança feitas sobre ele são sustentadas por evidência confiável.",
          "scope": "Auditores, equipes de garantia e de risco, e os responsáveis pelo sistema que devem tornar seus agentes auditáveis por design. Aplica-se a agentes autônomos ou semiautônomos que usam ferramentas e agem ao longo do tempo, e dá suporte tanto à garantia interna quanto à auditoria externa ou regulatória. É um companheiro prático dos frameworks formais, não um substituto de aconselhamento jurídico.",
          "keyPoints": [
            "Auditabilidade por design: o agente deve emitir evidência estruturada suficiente em tempo de execução para reconstruir qualquer execução depois.",
            "Cada execução produz um traço imutável e correlacionado: objetivo, cada passo e chamada de ferramenta com parâmetros e resultados, aprovações, anulações e resultado.",
            "A evidência deve ser completa, atribuível, com carimbo de tempo e à prova de adulteração para ter valor probatório.",
            "A proveniência de modelo e versão (prompt, ferramentas, modelo) é capturada por execução para que o comportamento fique ligado a uma configuração conhecida.",
            "A amostragem é em camadas: estratificada por risco, estatística, e revisão de 100% de todas as exceções, anulações, negações e incidentes.",
            "A evidência de auditoria mapeia para a auditoria interna da ISO/IEC 42001 (Cláusula 9) e para as funções Medir e Gerenciar do NIST AI RMF."
          ],
          "controls": [
            {
              "control": "Registros de auditoria imutáveis e rastreabilidade",
              "note": "Capture um traço correlacionado por execução — identidade e versão do agente, objetivo, cada passo, chamada de ferramenta, resultado, aprovações e resultado — e proteja-o contra alteração. Implementa a observabilidade de IA."
            },
            {
              "control": "Proveniência de modelo e versão",
              "note": "Registre o prompt exato, o conjunto de ferramentas e a versão do modelo por trás de cada execução para que o comportamento seja atribuível a uma base conhecida e reproduzível por configuração."
            },
            {
              "control": "Evidência de avaliação",
              "note": "Retenha os relatórios de avaliação prévios à implantação e contínuos e os resultados dos portões para que o auditor possa verificar que a segurança e a qualidade foram medidas: o 'Medir' do NIST."
            },
            {
              "control": "Teste de controles e amostragem",
              "note": "Teste cada controle contra a evidência usando uma metodologia de amostragem documentada: estratificada por risco, estatística e revisão completa de exceções."
            },
            {
              "control": "Registros de aprovação e incidentes",
              "note": "Capture aprovações humanas, anulações e incidentes com a identidade do ator e carimbos de tempo. Implementa o padrão de portão de aprovação humana."
            },
            {
              "control": "Atestações e gestão de achados",
              "note": "Os responsáveis pelo sistema e pelos controles assinam atestações respaldadas por evidência; os achados são acompanhados até o fechamento com severidade e prazos."
            }
          ],
          "checklist": [
            "Confirme que cada execução do agente produz um traço completo e correlacionado ligado por um ID de traço estável.",
            "Verifique que os registros são à prova de adulteração, com carimbo de tempo e retidos durante toda a janela de auditoria e regulatória.",
            "Verifique que cada execução registra a proveniência de modelo e versão (prompt, ferramentas, versão do modelo).",
            "Obtenha um mapeamento de controles / Declaração de Aplicabilidade que vincule cada controle à sua evidência.",
            "Retenha e revise os relatórios de avaliação prévios à implantação e contínuos e os resultados dos portões.",
            "Confirme que existem registros de aprovação, anulação e incidentes com identidade do ator e carimbos de tempo.",
            "Aplique uma metodologia de amostragem documentada: estratificada por risco, estatística e cobertura de 100% das exceções.",
            "Acompanhe os achados até o fechamento com severidade e prazos, e colete atestações assinadas dos responsáveis."
          ],
          "pitfalls": [
            "Agentes não auditáveis: registro adicionado tardiamente, deixando lacunas que nenhuma auditoria pode preencher.",
            "Registros mutáveis: registros que poderiam ser alterados, destruindo seu valor probatório.",
            "Pontos cegos da amostragem: amostragem apenas aleatória que ignora ações raras mas catastróficas.",
            "Atestação sem evidência: responsáveis que assinam controles que não conseguem demonstrar.",
            "Cemitério de achados: problemas levantados mas nunca remediados ou retestados."
          ],
          "examples": [
            "Um auditor reconstrói um reembolso em disputa seguindo seu traço correlacionado do objetivo à chamada de ferramenta e à aprovação humana.",
            "Um controle de auditoria contínua alerta sobre uma chamada de ferramenta fora da lista permitida contra o fluxo de registros ao vivo.",
            "Os relatórios de avaliação retidos mapeiam para o Medir do NIST AI RMF, evidenciando que os portões de segurança passaram antes da implantação."
          ],
          "faqs": [
            {
              "q": "É possível auditar um agente não determinístico?",
              "a": "Sim: você audita os controles e o comportamento registrado, não o determinismo. Traços completos e imutáveis tornam qualquer execução específica reconstruível, mesmo que não possa ser reproduzida exatamente."
            },
            {
              "q": "Qual deve ser o tamanho da amostra de auditoria?",
              "a": "Grande o suficiente para seu nível de garantia alvo de forma estatística, mais 100% das exceções e das ações de alto impacto. A amostragem nunca substitui a revisão completa de exceções."
            },
            {
              "q": "Como a evidência de auditoria mapeia para os frameworks?",
              "a": "Traços e registros dão suporte a Medir e Gerenciar do NIST AI RMF e à auditoria interna da Cláusula 9 da ISO/IEC 42001; um mapeamento de controles ou Declaração de Aplicabilidade vincula cada controle à evidência que prova que ele operou."
            }
          ]
        },
        "fr": {
          "name": "Cadre d'audit pour les systèmes agentiques",
          "summary": "Un cadre pratique et neutre vis-à-vis des fournisseurs pour rendre un agent auditable et pour l'auditer. Il définit les preuves dont un réviseur indépendant a besoin — des traces immuables et corrélées de chaque décision et appel d'outil, la provenance du modèle et de sa version, les rapports d'évaluation, les enregistrements d'approbations et d'incidents — ainsi que la manière de tester les contrôles et d'échantillonner les exécutions à grand volume. Chaque type de preuve est associé à l'ISO/IEC 42001 et au NIST AI RMF afin qu'un auditeur puisse vérifier que l'agent est resté dans ses limites gouvernées. Utilisez-le pour concevoir l'auditabilité dès le départ, et non après coup.",
          "definition": "Un audit d'agent est un examen indépendant et basé sur des preuves qui détermine si un système agentique a fonctionné dans le cadre de son périmètre, de ses contrôles et de ses politiques autorisés sur une période définie, et si les affirmations de gouvernance formulées à son sujet sont étayées par des preuves fiables.",
          "scope": "Les auditeurs, les équipes d'assurance et de gestion des risques, ainsi que les propriétaires de systèmes qui doivent rendre leurs agents auditables dès la conception (auditable by design). Il s'applique aux agents autonomes ou semi-autonomes qui utilisent des outils et agissent dans le temps, et prend en charge à la fois l'assurance interne et l'audit externe ou réglementaire. C'est un compagnon pratique pour les cadres formels, et non un substitut à un avis juridique.",
          "keyPoints": [
            "Auditabilité dès la conception (auditability by design) : l'agent doit émettre suffisamment de preuves structurées au moment de l'exécution pour pouvoir reconstituer n'importe quelle exécution ultérieurement.",
            "Chaque exécution produit une trace immuable et corrélée : l'objectif, chaque étape et appel d'outil avec paramètres et résultats, les approbations, les contournements (overrides) et le résultat final.",
            "Les preuves doivent être complètes, attribuables, horodatées et inviolables (tamper-evident) pour avoir une valeur probante.",
            "La provenance du modèle et de sa version (prompt, outils, modèle) est capturée à chaque exécution afin que le comportement soit lié à une configuration connue.",
            "L'échantillonnage est structuré en couches : stratifié par risque, statistique, et examen à 100 % de l'ensemble des exceptions, contournements, refus et incidents.",
            "Les preuves d'audit correspondent à l'audit interne de la norme ISO/CEI 42001 (Clause 9) et aux fonctions Measure et Manage du NIST AI RMF."
          ],
          "controls": [
            {
              "control": "Journaux d'audit immuables et traçabilité",
              "note": "Capturer une trace corrélée par exécution — identité et version de l'agent, objectif, chaque étape, appel d'outil, résultat, approbations et issue — et la protéger contre toute altération. Implémente l'observabilité de l'IA."
            },
            {
              "control": "Provenance du modèle et de la version",
              "note": "Enregistrer le prompt exact, le jeu d'outils et la version du modèle derrière chaque exécution afin que le comportement soit attribuable à une référence connue et reproductible par configuration."
            },
            {
              "control": "Preuves d'évaluation",
              "note": "Conserver les rapports d'évaluation pré-déploiement et continus ainsi que les résultats des jalons de validation afin que l'auditeur puisse vérifier que la sécurité et la qualité ont été mesurées — fonction « Measure » du NIST."
            },
            {
              "control": "Test des contrôles et échantillonnage",
              "note": "Tester chaque contrôle par rapport aux preuves en utilisant une méthodologie d'échantillonnage documentée : stratifiée par risque, statistique, et examen complet des exceptions."
            },
            {
              "control": "Registres d'approbation et d'incident",
              "note": "Capturer les approbations humaines, les contournements et les incidents avec l'identité de l'acteur et l'horodatage. Implémente le modèle de jalon de validation par approbation humaine."
            },
            {
              "control": "Attestations et gestion des constats",
              "note": "Les propriétaires de systèmes et de contrôles signent des attestations appuyées par des preuves ; les constats sont suivis jusqu'à leur résolution avec un niveau de gravité et des échéances."
            }
          ],
          "checklist": [
            "Confirmer que chaque exécution d'agent produit une trace complète et corrélée, liée par un identifiant de trace stable.",
            "Vérifier que les journaux sont infalsifiables, horodatés et conservés pendant toute la période d'audit et de conformité réglementaire.",
            "Vérifier que chaque exécution enregistre la provenance du modèle et de la version (prompt, outils, version du modèle).",
            "Récupérer une cartographie des contrôles / Déclaration d'applicabilité liant chaque contrôle à ses preuves.",
            "Conserver et examiner les rapports d'évaluation pré-déploiement et continus ainsi que les résultats des jalons de validation.",
            "Confirmer l'existence de registres d'approbation, de contournement et d'incident comportant l'identité de l'acteur et l'horodatage.",
            "Appliquer une méthodologie d'échantillonnage documentée — stratifiée par risque, statistique, et couverture à 100 % des exceptions.",
            "Suivre les constats jusqu'à leur résolution avec un niveau de gravité et des échéances, et recueillir les attestations signées des propriétaires."
          ],
          "pitfalls": [
            "Agents non auditables : journalisation ajoutée après coup, laissant des lacunes qu'aucun audit ne peut combler.",
            "Journaux modifiables : enregistrements susceptibles d'être altérés, détruisant leur valeur probante.",
            "Angles morts de l'échantillonnage : échantillonnage uniquement aléatoire qui passe à côté d'actions rares mais catastrophiques.",
            "Attestation sans preuve : propriétaires validant des contrôles qu'ils ne peuvent pas démontrer.",
            "Cimetière de constats : problèmes soulevés mais jamais corrigés ni re-testés."
          ],
          "examples": [
            "Un auditeur reconstitue un remboursement contesté en suivant sa trace corrélée, de l'objectif à l'appel d'outil, puis à l'approbation humaine.",
            "Un contrôle d'audit continu signale un appel d'outil en dehors de la liste d'autorisation par rapport au flux de journaux en direct.",
            "Les rapports d'évaluation conservés correspondent à la fonction Measure du NIST AI RMF, prouvant que les jalons de sécurité ont été franchis avec succès avant le déploiement."
          ],
          "faqs": [
            {
              "q": "Peut-on vraiment auditer un agent non déterministe ?",
              "a": "Oui — vous auditez les contrôles et le comportement enregistré, pas le déterminisme. Des traces complètes et immuables permettent de reconstituer n'importe quelle exécution spécifique, même si elle ne peut pas être reproduite à l'identique."
            },
            {
              "q": "Quelle doit être la taille de l'échantillon d'audit ?",
              "a": "Assez grande pour atteindre statistiquement votre niveau d'assurance cible, plus 100 % des exceptions et des actions à fort impact. L'échantillonnage ne remplace jamais un examen complet des exceptions."
            },
            {
              "q": "Comment les preuves d'audit correspondent-elles aux référentiels ?",
              "a": "Les traces et les journaux soutiennent les fonctions Measure et Manage du NIST AI RMF ainsi que l'audit interne de la clause 9 de l'ISO/CEI 42001 ; une cartographie des contrôles ou une Déclaration d'applicabilité lie chaque contrôle aux preuves qui démontrent son fonctionnement."
            }
          ]
        },
        "de": {
          "name": "Audit-Framework für agentische Systeme",
          "summary": "Ein praktisches, herstellerneutrales Framework, um einen Agenten auditierbar zu machen und ihn zu prüfen. Es definiert die Nachweise, die ein unabhängiger Prüfer benötigt – unveränderliche, korrelierte Traces jeder Entscheidung und jedes Tool-Aufrufs, Modell- und Versionsherkunft (Provenance), Evaluierungsberichte, Freigabe- und Incident-Protokolle – sowie Methoden zum Testen von Kontrollmechanismen und zur Stichprobenprüfung von Läufen mit hohem Volumen. Jede Nachweisart ist der ISO/IEC 42001 und dem NIST AI RMF zugeordnet, sodass ein Auditor überprüfen kann, ob der Agent innerhalb seiner vorgegebenen Grenzen geblieben ist. Nutzen Sie es, um Auditierbarkeit von Anfang an einzuplanen, statt sie nachträglich hinzuzufügen.",
          "definition": "Ein Agenten-Audit ist eine unabhängige, evidenzbasierte Prüfung, die feststellt, ob ein agentisches System über einen definierten Zeitraum innerhalb seines autorisierten Rahmens, seiner Kontrollmechanismen und Richtlinien agiert hat und ob die darüber aufgestellten Governance-Behauptungen durch verlässliche Nachweise gestützt werden.",
          "scope": "Auditoren, Assurance- und Risikoteams sowie Systemverantwortliche, die ihre Agenten von Grund auf auditierbar gestalten müssen (Auditability by Design). Es gilt für autonome oder teilautonome Agenten, die Tools nutzen und über längere Zeit agieren, und unterstützt sowohl die interne Qualitätssicherung als auch externe oder regulatorische Audits. Es ist ein praktischer Begleiter zu den formalen Frameworks und kein Ersatz für eine Rechtsberatung.",
          "keyPoints": [
            "Auditability by Design: Der Agent muss zur Laufzeit genügend strukturierte Nachweise liefern, um jeden Durchlauf später rekonstruieren zu können.",
            "Jeder Durchlauf erzeugt einen unveränderlichen, korrelierten Trace: Ziel, jeder Schritt und Tool-Aufruf mit Parametern und Ergebnissen, Freigaben, Overrides und das Endergebnis.",
            "Nachweise müssen vollständig, zuordenbar, mit Zeitstempeln versehen und manipulationssicher sein, um Beweiskraft zu besitzen.",
            "Modell- und Versionsherkunft (Prompt, Tools, Modell) werden pro Durchlauf erfasst, sodass das Verhalten an eine bekannte Konfiguration gebunden ist.",
            "Die Stichprobenentnahme ist gestuft: risikostratifiziert, statistisch und eine 100-prozentige Überprüfung aller Ausnahmen, Overrides, Ablehnungen und Vorfälle.",
            "Audit-Nachweise lassen sich dem internen Audit nach ISO/IEC 42001 (Klausel 9) und den Measure- und Manage-Funktionen des NIST AI RMF zuordnen."
          ],
          "controls": [
            {
              "control": "Unveränderliche Audit-Logs und Rückverfolgbarkeit",
              "note": "Erfassen Sie pro Durchlauf einen korrelierten Trace – Agenten-Identität und -Version, Ziel, jeden Schritt, Tool-Aufruf, Ergebnis, Genehmigungen und Resultat – und schützen Sie diesen vor Änderungen. Implementiert KI-Observability."
            },
            {
              "control": "Modell- und Versionsherkunft",
              "note": "Erfassen Sie den genauen Prompt, das Tool-Set und die Modellversion hinter jedem Durchlauf, sodass das Verhalten einer bekannten, per Konfiguration reproduzierbaren Baseline zugeordnet werden kann."
            },
            {
              "control": "Evaluierungsnachweise",
              "note": "Bewahren Sie Berichte zur Vorab- und laufenden Evaluierung sowie Gate-Ergebnisse auf, damit Auditoren überprüfen können, ob Sicherheit und Qualität gemessen wurden – NIST „Measure“."
            },
            {
              "control": "Kontrollprüfungen und Stichprobenentnahme",
              "note": "Prüfen Sie jede Kontrolle anhand von Nachweisen unter Verwendung einer dokumentierten Stichprobenmethodik: risikostratifiziert, statistisch und vollständige Überprüfung von Ausnahmen."
            },
            {
              "control": "Genehmigungs- und Vorfallprotokolle",
              "note": "Erfassen Sie menschliche Genehmigungen, Overrides und Vorfälle mit der Identität des Akteurs und Zeitstempeln. Implementiert das Human-Approval-Gate-Muster."
            },
            {
              "control": "Attestierungen und Feststellungsmanagement",
              "note": "System- und Kontrollverantwortliche unterzeichnen durch Nachweise gestützte Attestierungen; Feststellungen werden mit Schweregrad und Fristen bis zur Behebung nachverfolgt."
            }
          ],
          "checklist": [
            "Bestätigen Sie, dass jeder Agenten-Durchlauf einen vollständigen, korrelierten Trace erzeugt, der an eine stabile Trace-ID gebunden ist.",
            "Überprüfen Sie, ob Logs manipulationssicher und zeitgestempelt sind sowie für den gesamten Audit- und regulatorischen Aufbewahrungszeitraum vorgehalten werden.",
            "Prüfen Sie, ob jeder Durchlauf die Modell- und Versionsherkunft aufzeichnet (Prompt, Tools, Modellversion).",
            "Rufen Sie ein Control-Mapping / eine Anwendbarkeitserklärung (Statement of Applicability) ab, die jede Kontrolle mit ihren Nachweisen verknüpft.",
            "Bewahren und überprüfen Sie Berichte zur Vorab- und laufenden Evaluierung sowie Gate-Ergebnisse.",
            "Bestätigen Sie, dass Protokolle für Genehmigungen, Overrides und Vorfälle mit der Identität des Akteurs und Zeitstempeln vorhanden sind.",
            "Wenden Sie eine dokumentierte Stichprobenmethodik an – risikostratifiziert, statistisch und mit 100-prozentiger Abdeckung von Ausnahmen.",
            "Verfolgen Sie Feststellungen mit Schweregrad und Fristen bis zur Behebung und holen Sie unterzeichnete Attestierungen der Verantwortlichen ein."
          ],
          "pitfalls": [
            "Nicht auditierbare Agenten: Die Protokollierung wird erst nachträglich hinzugefügt, was Lücken hinterlässt, die kein Audit schließen kann.",
            "Veränderbare Logs: Datensätze, die geändert werden könnten, was ihren Beweiswert zerstört.",
            "Blinde Flecken bei Stichproben: Rein zufällige Stichproben, bei denen seltene, aber katastrophale Aktionen übersehen werden.",
            "Attestierung ohne Nachweise: Verantwortliche zeichnen Kontrollen ab, die sie nicht nachweisen können.",
            "Friedhof der Feststellungen: Aufgeworfene Probleme, die nie behoben oder erneut geprüft werden."
          ],
          "examples": [
            "Ein Auditor rekonstruiert eine umstrittene Rückerstattung, indem er deren korrelierten Trace vom Ziel über den Tool-Aufruf bis zur menschlichen Genehmigung verfolgt.",
            "Eine kontinuierliche Audit-Prüfung schlägt bei einem Tool-Aufruf außerhalb der Allow-List im Live-Log-Stream Alarm.",
            "Aufbewahrte Evaluierungsberichte lassen sich dem Bereich „Measure“ des NIST AI RMF zuordnen und belegen, dass Sicherheits-Gates vor der Bereitstellung erfolgreich durchlaufen wurden."
          ],
          "faqs": [
            {
              "q": "Kann man einen nicht-deterministischen Agenten überhaupt auditieren?",
              "a": "Ja – Sie auditieren die Kontrollen und das aufgezeichnete Verhalten, nicht den Determinismus. Vollständige, unveränderliche Traces machen jeden spezifischen Durchlauf rekonstruierbar, selbst wenn er nicht exakt reproduziert werden kann."
            },
            {
              "q": "Wie groß sollte die Audit-Stichprobe sein?",
              "a": "Statistisch gesehen groß genug für Ihr angestrebtes Sicherheitsniveau, plus 100 % der Ausnahmen und folgenschweren Aktionen. Stichproben ersetzen niemals eine vollständige Überprüfung von Ausnahmen."
            },
            {
              "q": "Wie lassen sich Audit-Nachweise den Frameworks zuordnen?",
              "a": "Traces und Logs unterstützen die Bereiche „Measure“ und „Manage“ des NIST AI RMF sowie das interne Audit nach ISO/IEC 42001 Klausel 9; ein Control-Mapping oder eine Anwendbarkeitserklärung (Statement of Applicability) verknüpft jede Kontrolle mit dem Nachweis, dass sie wirksam war."
            }
          ]
        },
        "ja": {
          "name": "エージェント型システム向け監査フレームワーク",
          "summary": "エージェントを監査可能にし、実際に監査を行うための、実用的かつベンダーニュートラルなフレームワーク。独立したレビュー担当者が必要とする証拠（すべての意思決定とツール呼び出しの不変かつ関連付けられたトレース、モデルとバージョンのプロベナンス、評価レポート、承認およびインシデントの記録など）を定義し、コントロールのテスト方法や大量の実行データのサンプリング方法を示します。各証拠タイプはISO/IEC 42001およびNIST AI RMFにマッピングされており、監査人はエージェントが管理された境界内に留まっているかを検証できます。後付けではなく、最初から監査可能性を考慮して設計するためにご活用ください。",
          "definition": "エージェント監査とは、エージェント型システムが定義された期間において、承認されたスコープ、コントロール、およびポリシーの範囲内で動作したか、また、そのシステムに関して行われたガバナンスの主張が信頼できる証拠によって裏付けられているかを判断する、独立した証拠に基づく検査です。",
          "scope": "監査人、アシュアランスおよびリスク管理チーム、そして設計段階からエージェントを監査可能にする必要があるシステム所有者。ツールを使用し、長期にわたって動作する自律型または半自律型エージェントに適用され、内部アシュアランスと外部または規制監査の両方をサポートします。本フレームワークは、公式なフレームワークを補完する実用的なガイドであり、法的助言に代わるものではありません。",
          "keyPoints": [
            "設計段階からの監査可能性（Auditability by design）：エージェントは、後から任意の実行を再構成できるように、実行時に十分な構造化された証拠を出力しなければなりません。",
            "すべての実行において、不変かつ関連付けられたトレース（目標、パラメータと結果を伴う各ステップおよびツール呼び出し、承認、オーバーライド、および最終結果）が生成されます。",
            "証拠価値を持つためには、証拠が完全であり、帰属性があり、タイムスタンプが付与され、改ざん検知可能（tamper-evident）でなければなりません。",
            "モデルとバージョンのプロベナンス（プロンプト、ツール、モデル）が実行ごとに記録され、振る舞いが既知の構成に関連付けられます。",
            "サンプリングは階層化されています。リスク層別化、統計的サンプリング、およびすべての例外、オーバーライド、拒否、インシデントに対する100%のレビューで構成されます。",
            "監査証跡は、ISO/IEC 42001の内部監査（箇条9）およびNIST AI RMFのMeasure（測定）およびManage（管理）機能に対応しています。"
          ],
          "controls": [
            {
              "control": "不変の監査ログとトレーサビリティ",
              "note": "実行ごとに、エージェントの識別情報とバージョン、目標、各ステップ、ツール呼び出し、結果、承認、最終結果を紐付けたトレースを記録し、改ざんから保護します。これによりAIオブザーバビリティを実装します。"
            },
            {
              "control": "モデルとバージョンのプロバナンス（来歴）",
              "note": "各実行の背景にある正確なプロンプト、ツールセット、モデルバージョンを記録し、動作が構成によって再現可能な既知のベースラインに起因するようにします。"
            },
            {
              "control": "評価の証跡",
              "note": "監査人が安全性と品質が測定されたことを検証できるように、デプロイ前および継続的な評価レポートとゲート結果を保持します（NISTの「Measure」に対応）。"
            },
            {
              "control": "コントロールのテストとサンプリング",
              "note": "文書化されたサンプリング手法（リスク層別化、統計的サンプリング、および完全な例外レビュー）を使用して、証跡に照らし合わせて各コントロールをテストします。"
            },
            {
              "control": "承認およびインシデントの記録",
              "note": "実行者の識別情報とタイムスタンプとともに、人の承認、オーバーライド、インシデントを記録します。これにより、人の承認ゲート（human-approval-gate）パターンを実装します。"
            },
            {
              "control": "アテステーション（証明）と指摘事項の管理",
              "note": "システムおよびコントロールの所有者は、証跡に裏付けられたアテステーションに署名します。指摘事項は、深刻度と期限を設定して解決まで追跡されます。"
            }
          ],
          "checklist": [
            "すべてのエージェントの実行が、一貫したトレースIDによって紐付けられた、完全で関連性のあるトレースを生成することを確認する。",
            "ログが改ざん検知可能であり、タイムスタンプが付与され、監査および規制で定められた全期間にわたって保持されていることを検証する。",
            "各実行において、モデルとバージョンのプロバナンス（プロンプト、ツール、モデルバージョン）が記録されていることを確認する。",
            "各コントロールをその証跡に関連付けるコントロールマッピングまたは適用宣言書（Statement of Applicability）を取得する。",
            "デプロイ前および継続的な評価レポートとゲート結果を保持し、レビューする。",
            "実行者の識別情報とタイムスタンプを含む、承認、オーバーライド、インシデントの記録が存在することを確認する。",
            "文書化されたサンプリング手法（リスク層別化、統計的サンプリング、および100%の例外カバー）を適用する。",
            "深刻度と期限を設定して指摘事項を解決まで追跡し、所有者による署名済みのアテステーションを回収する。"
          ],
          "pitfalls": [
            "監査不可能なエージェント：ロギングが後回しにされ、監査では埋められないギャップが残ること。",
            "変更可能なログ：記録が改ざんされる可能性があり、証拠としての価値が損なわれること。",
            "サンプリングの盲点：ランダムサンプリングのみに頼ることで、まれではあるが壊滅的なアクションを見落とすこと。",
            "証跡のないアテステーション：実証できないコントロールに対して、所有者が承認の署名をしてしまうこと。",
            "指摘事項の放置：問題が提起されたものの、是正や再テストが一切行われないこと。"
          ],
          "examples": [
            "監査人が、目標からツール呼び出し、人の承認に至るまでの関連付けられたトレースを追跡することで、紛争のある返金処理を再構成する。",
            "継続的監査チェックにより、ライブログストリームに対して許可リスト外のツール呼び出しを検知し、アラートを発信する。",
            "保持された評価レポートがNIST AI RMFのMeasureに対応し、デプロイ前に安全ゲートを通過したことを証明する。"
          ],
          "faqs": [
            {
              "q": "非決定的なエージェントを監査することはそもそも可能ですか？",
              "a": "はい。決定性ではなく、コントロールと記録された動作を監査します。完全で不変のトレースがあれば、特定の実行を正確に再現できなくても、再構成することが可能です。"
            },
            {
              "q": "監査サンプルの規模はどの程度にするべきですか？",
              "a": "統計的に目標とする保証レベルに達するのに十分な大きさに加え、例外および影響の大きいアクションの100%を含める必要があります。サンプリングが完全な例外レビューの代わりになることはありません。"
            },
            {
              "q": "監査証跡はフレームワークにどのように対応しますか？",
              "a": "トレースとログは、NIST AI RMFのMeasureおよびManage、ならびにISO/IEC 42001の箇条9（内部監査）をサポートします。コントロールマッピングまたは適用宣言書（Statement of Applicability）により、各コントロールがその運用を証明する証跡に関連付けられます。"
            }
          ]
        },
        "zh": {
          "name": "智能体系统审计框架",
          "summary": "一个实用且不绑定特定厂商的框架，用于使智能体具备可审计性并对其进行审计。它定义了独立审查员所需的证据 —— 每次决策和工具调用的不可变且关联的追踪记录、模型 and 版本溯源、评估报告、审批和事件记录 —— 以及如何测试控制措施和对高吞吐量运行进行抽样。每种证据类型都映射到 ISO/IEC 42001 和 NIST AI RMF，以便审计员能够验证智能体是否保持在其治理边界内。使用它从一开始就设计可审计性，而不是事后弥补。",
          "definition": "智能体审计是一项独立的、基于证据的检查，旨在确定智能体系统在特定时期内是否在其授权范围、控制措施和策略内运行，以及针对其提出的治理声明是否有可靠证据支持。",
          "scope": "适用于审计员、合规与风险团队，以及必须使智能体具备“源自设计”的可审计性的系统所有者。它适用于在一段时间内使用工具并执行操作的自主或半自主智能体，并支持内部合规和外部或监管审计。它是正式框架的实用指南，不能替代法律咨询。",
          "keyPoints": [
            "源自设计的可审计性：智能体必须在运行时输出足够的结构化证据，以便日后重构任何运行过程。",
            "每次运行都会产生不可变且关联的追踪记录：目标、包含参数和结果的每个步骤及工具调用、审批、覆盖和最终结果。",
            "证据必须完整、可归属、带有时间戳且防篡改，才具有证据价值。",
            "每次运行都会捕获模型和版本溯源（提示词、工具、模型），从而将行为与已知配置绑定。",
            "抽样是分层的：包括风险分层抽样、统计抽样，以及对所有异常、覆盖、拒绝和事件进行 100% 的审查。",
            "审计证据映射到 ISO/IEC 42001 内部审计（第 9 条）以及 NIST AI RMF 的 Measure（测量）和 Manage（管理）功能。"
          ],
          "controls": [
            {
              "control": "不可变审计日志与可追溯性",
              "note": "捕获每次运行的相关联 trace——智能体身份和版本、目标、每个步骤、工具调用、结果、审批和最终产出——并防止其被篡改。这实现了 AI 可观测性。"
            },
            {
              "control": "模型与版本溯源",
              "note": "记录每次运行背后的确切提示词、工具集和模型版本，以便将行为归因于已知的、可通过配置复现的基线。"
            },
            {
              "control": "评估证据",
              "note": "保留部署前和持续的评估报告及关卡结果，以便审计员能够验证安全性和质量已得到测量——即 NIST 的 'Measure'。"
            },
            {
              "control": "控制测试与抽样",
              "note": "使用文件化的抽样方法对照证据测试每个控制项：风险分层抽样、统计抽样以及全面的异常审查。"
            },
            {
              "control": "审批与事件记录",
              "note": "捕获人工审批、覆盖和事件，并附带操作者身份和时间戳。这实现了人工审批关卡模式。"
            },
            {
              "control": "证明与发现项管理",
              "note": "系统和控制所有者签署以证据为支撑的证明；对发现项进行跟踪直至关闭，并明确严重程度和截止日期。"
            }
          ],
          "checklist": [
            "确认每次智能体运行都生成一个完整的、通过稳定 trace ID 绑定的关联 trace。",
            "验证日志具有防篡改特征、带有时间戳，并在整个审计和监管窗口期内予以保留。",
            "检查每次运行是否记录了模型和版本溯源信息（提示词、工具、模型版本）。",
            "获取将每个控制项与其证据相关联的控制映射表 / 适用性声明（Statement of Applicability）。",
            "保留并审查部署前和持续的评估报告及关卡结果。",
            "确认存在审批、覆盖和事件记录，并附带操作者身份和时间戳。",
            "应用文件化的抽样方法——风险分层抽样、统计抽样以及 100% 的异常覆盖。",
            "跟踪发现项直至关闭，明确严重程度和截止日期，并收集所有者签署的证明。"
          ],
          "pitfalls": [
            "不可审计的智能体：日志记录是事后才补上的，留下了任何审计都无法填补的空白。",
            "可变日志：记录可能会被篡改，从而破坏其证据价值。",
            "抽样盲区：仅进行随机抽样，从而遗漏了罕见但灾难性的行为。",
            "无证据的证明：所有者对他们无法证明的控制项进行签字确认。",
            "发现项坟墓：提出了问题，但从未进行整改或重新测试。"
          ],
          "examples": [
            "审计员通过跟踪一笔争议退款的相关联 trace（从目标到工具调用再到人工审批），来重构该退款过程。",
            "持续审计检查针对实时日志流中超出准允列表的工具调用发出告警。",
            "保留的评估报告映射到 NIST AI RMF Measure，证明在部署前已通过安全关卡。"
          ],
          "faqs": [
            {
              "q": "非确定性智能体真的可以被审计吗？",
              "a": "可以。您审计的是控制项和记录的行为，而不是其确定性。完整、不可变的 trace 使得任何特定的运行都是可重构的，即使它无法被完全精确地复现。"
            },
            {
              "q": "审计抽样规模应该有多大？",
              "a": "在统计学上足够大以达到您的目标保证水平，外加 100% 的异常和高影响行为。抽样永远不能取代全面的异常审查。"
            },
            {
              "q": "审计证据如何映射到各个框架？",
              "a": "trace 和日志支持 NIST AI RMF Measure 和 Manage 以及 ISO/IEC 42001 第 9 条内部审计；控制映射表或适用性声明将每个控制项与证明其已运行的证据相关联。"
            }
          ]
        }
      }
    },
    {
      "id": "GOV-007",
      "slug": "human-oversight-and-accountability-policy",
      "category": "playbook",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/governance/human-oversight-and-accountability-policy",
      "api": "https://santismm.com/api/governance/human-oversight-and-accountability-policy",
      "canonical_url": "https://santismm.com/en/governance/human-oversight-and-accountability-policy",
      "api_url": "https://santismm.com/api/governance/human-oversight-and-accountability-policy",
      "evidence": {
        "evidenceLevel": "industry_observation",
        "confidenceLevel": "high",
        "sourceType": [
          "industry_observation",
          "paper"
        ]
      },
      "frameworks": [
        "EU AI Act"
      ],
      "patterns": [
        "human-approval-gate",
        "human-escalation"
      ],
      "knowledge": [
        "human-in-the-loop",
        "ai-governance"
      ],
      "references": [
        {
          "title": "EU AI Act — Article 14 (Human oversight)",
          "url": "https://artificialintelligenceact.eu/article/14/"
        },
        {
          "title": "NIST — AI Risk Management Framework (AI RMF 1.0)",
          "url": "https://www.nist.gov/itl/ai-risk-management-framework"
        },
        {
          "title": "OECD — AI Principles",
          "url": "https://oecd.ai/en/ai-principles"
        }
      ],
      "related": [
        "eu-ai-act",
        "agentic-ai-governance-checklist"
      ],
      "locales": {
        "en": {
          "name": "Human Oversight and Accountability Policy",
          "summary": "An operational policy that turns EU AI Act Article 14 human oversight into practice for agentic AI. It assigns a named accountable owner per agent, sets the oversight level (in-the-loop, on-the-loop, out-of-the-loop) by risk, and defines intervention, override and stop authority plus escalation paths. It requires overseers to be competent and have time to act, and it guards against rubber-stamping and automation bias. It exists to prevent two failures: the absent human and the token human who cannot actually understand, override, or answer for what the agent does.",
          "definition": "A human oversight and accountability policy is a binding rule set that assigns a named human to be answerable for each agent and guarantees a competent person can understand, intervene in, and stop its actions.",
          "scope": "Every production or pilot agent that uses tools, acts on systems, or makes consequential decisions, and the system owners, approvers and operators who oversee them. It operationalizes Article 14; it is not a substitute for legal advice.",
          "keyPoints": [
            "Each agent has one named, accountable owner — accountability is never transferred to the model.",
            "Oversight level is matched to risk: in-the-loop for high-impact or irreversible actions, on-the-loop for reversible high-volume actions, out-of-the-loop only for low-risk reversible tasks.",
            "Every agent exposes tested reject, modify and stop (kill-switch) controls with the context needed for an informed decision.",
            "Escalation thresholds route consequential decisions to humans by impact, irreversibility, rights or safety, confidence and novelty.",
            "Overseers must be competent, intelligibly informed, and have genuine authority and time to act.",
            "Automation bias and rubber-stamping are actively countered, not assumed away."
          ],
          "controls": [
            {
              "control": "Named accountable owner",
              "note": "Assign one human answerable for each agent's outcomes. 'The model decided' is not an acceptable account."
            },
            {
              "control": "Risk-matched oversight level",
              "note": "Define in-the-loop, on-the-loop or out-of-the-loop per agent based on action impact and reversibility. Implements the human-approval-gate pattern for high-impact actions."
            },
            {
              "control": "Override and stop authority",
              "note": "Expose tested reject, modify and stop controls; surface enough context for an informed override. The stop must be fast and reachable."
            },
            {
              "control": "Escalation thresholds",
              "note": "Route decisions to humans when impact, irreversibility, rights/safety, low confidence or novelty thresholds are crossed. Implements the human-escalation pattern."
            },
            {
              "control": "Overseer competence",
              "note": "Train and certify overseers on the agent's domain and limits so oversight is meaningful, not nominal."
            },
            {
              "control": "Anti-rubber-stamping safeguards",
              "note": "Throttle and require justification for approvals; monitor approval time and override rates to detect automation bias."
            }
          ],
          "checklist": [
            "Name one accountable owner for each production agent and record it.",
            "Classify each agent's actions by impact and reversibility and assign an oversight level.",
            "Implement and test reject, modify and stop (kill-switch) controls for every agent.",
            "Ensure the agent surfaces intelligible context for any decision that needs oversight.",
            "Define and configure escalation thresholds for impact, rights/safety, confidence and novelty.",
            "Train overseers on the agent's domain and limits and keep their certification current.",
            "Add anti-rubber-stamping safeguards and monitor approval time and override rates.",
            "Log every approval and override with actor, reason and timestamp, and review thresholds on a schedule."
          ],
          "pitfalls": [
            "Token oversight: a human clicks approve without the context, authority or time to actually evaluate the action.",
            "Automation bias: approvers trust the agent so much they stop scrutinizing its output.",
            "Diffuse accountability: no single named owner, so a failure has no answerable human.",
            "Unreachable override: a stop control that is slow, hidden or never tested.",
            "Threshold drift: escalation limits set once and never updated as the agent's scope grows."
          ],
          "examples": [
            "A finance agent whose payments above a spend cap require in-the-loop human approval, while reconciliations run on-the-loop.",
            "A support agent that escalates to a human when its confidence is low or a request affects a customer's rights.",
            "An incident where the named owner is held accountable and the override log shows who approved the action and why."
          ],
          "faqs": [
            {
              "q": "Does human oversight mean a human approves everything?",
              "a": "No. Oversight is tiered: in-the-loop for high-impact or irreversible actions, on-the-loop monitoring for reversible high-volume actions, and a human-in-command posture overall. The model scales to risk so oversight stays meaningful instead of becoming approval fatigue."
            },
            {
              "q": "Can accountability sit with the AI vendor?",
              "a": "No. Vendor relationships are governed separately, but your named system owner remains accountable for how the agent is deployed and used. Automation is a tool, not a defense."
            },
            {
              "q": "How do we prevent rubber-stamping and automation bias?",
              "a": "Surface intelligible context for each decision, throttle and require justification for approvals, monitor approval time and override rates, and keep overseers competent through training and rotation."
            }
          ]
        },
        "es": {
          "name": "Política de Supervisión Humana y Rendición de Cuentas",
          "summary": "Una política operativa que lleva la supervisión humana del Artículo 14 del EU AI Act a la práctica para la IA agéntica. Asigna un responsable nombrado por agente, fija el nivel de supervisión (en el bucle, sobre el bucle, fuera del bucle) según el riesgo y define la autoridad de intervención, anulación y parada más las vías de escalado. Exige que los supervisores sean competentes y tengan tiempo para actuar, y protege frente al sello automático y el sesgo de automatización. Existe para evitar dos fallos: el humano ausente y el humano simbólico que no puede entender, anular ni responder por lo que hace el agente.",
          "definition": "Una política de supervisión humana y rendición de cuentas es un conjunto de reglas vinculantes que asigna un humano nombrado como responsable de cada agente y garantiza que una persona competente pueda entender, intervenir y detener sus acciones.",
          "scope": "Todo agente en producción o piloto que use herramientas, actúe sobre sistemas o tome decisiones de consecuencia, y los propietarios de sistema, aprobadores y operadores que los supervisan. Operacionaliza el Artículo 14; no sustituye al asesoramiento legal.",
          "keyPoints": [
            "Cada agente tiene un único responsable nombrado: la rendición de cuentas nunca se transfiere al modelo.",
            "El nivel de supervisión se ajusta al riesgo: en el bucle para acciones de alto impacto o irreversibles, sobre el bucle para acciones reversibles de alto volumen, fuera del bucle solo para tareas reversibles de bajo riesgo.",
            "Cada agente expone controles probados de rechazar, modificar y detener (interruptor de parada) con el contexto necesario para una decisión informada.",
            "Los umbrales de escalado enrutan las decisiones de consecuencia a humanos por impacto, irreversibilidad, derechos o seguridad, confianza y novedad.",
            "Los supervisores deben ser competentes, estar informados de forma inteligible y tener autoridad y tiempo reales para actuar.",
            "El sesgo de automatización y el sello automático se contrarrestan activamente, no se dan por descartados."
          ],
          "controls": [
            {
              "control": "Responsable nombrado",
              "note": "Asigna un humano que responda por los resultados de cada agente. 'El modelo decidió' no es una explicación aceptable."
            },
            {
              "control": "Nivel de supervisión según riesgo",
              "note": "Define en el bucle, sobre el bucle o fuera del bucle por agente según el impacto y la reversibilidad de la acción. Implementa el patrón de puerta de aprobación humana para acciones de alto impacto."
            },
            {
              "control": "Autoridad de anulación y parada",
              "note": "Expón controles probados de rechazar, modificar y detener; muestra suficiente contexto para una anulación informada. La parada debe ser rápida y accesible."
            },
            {
              "control": "Umbrales de escalado",
              "note": "Enruta las decisiones a humanos cuando se cruzan umbrales de impacto, irreversibilidad, derechos/seguridad, baja confianza o novedad. Implementa el patrón de escalado humano."
            },
            {
              "control": "Competencia del supervisor",
              "note": "Forma y certifica a los supervisores en el dominio y los límites del agente para que la supervisión sea significativa, no nominal."
            },
            {
              "control": "Salvaguardas contra el sello automático",
              "note": "Limita y exige justificación para las aprobaciones; monitoriza el tiempo de aprobación y la tasa de anulaciones para detectar el sesgo de automatización."
            }
          ],
          "checklist": [
            "Nombra un único responsable para cada agente en producción y regístralo.",
            "Clasifica las acciones de cada agente por impacto y reversibilidad y asigna un nivel de supervisión.",
            "Implementa y prueba los controles de rechazar, modificar y detener (interruptor de parada) para cada agente.",
            "Asegura que el agente muestre contexto inteligible para cualquier decisión que necesite supervisión.",
            "Define y configura umbrales de escalado para impacto, derechos/seguridad, confianza y novedad.",
            "Forma a los supervisores en el dominio y los límites del agente y mantén su certificación al día.",
            "Añade salvaguardas contra el sello automático y monitoriza el tiempo de aprobación y la tasa de anulaciones.",
            "Registra cada aprobación y anulación con actor, motivo y marca de tiempo, y revisa los umbrales de forma periódica."
          ],
          "pitfalls": [
            "Supervisión simbólica: un humano pulsa aprobar sin el contexto, la autoridad o el tiempo para evaluar realmente la acción.",
            "Sesgo de automatización: los aprobadores confían tanto en el agente que dejan de escrutar su salida.",
            "Rendición de cuentas difusa: ningún responsable nombrado, así que un fallo no tiene humano que responda.",
            "Anulación inalcanzable: un control de parada lento, oculto o nunca probado.",
            "Deriva de umbrales: límites de escalado fijados una vez y nunca actualizados a medida que crece el alcance del agente."
          ],
          "examples": [
            "Un agente financiero cuyos pagos por encima de un tope de gasto requieren aprobación humana en el bucle, mientras las conciliaciones corren sobre el bucle.",
            "Un agente de soporte que escala a un humano cuando su confianza es baja o una solicitud afecta los derechos de un cliente.",
            "Un incidente en el que el responsable nombrado rinde cuentas y el registro de anulaciones muestra quién aprobó la acción y por qué."
          ],
          "faqs": [
            {
              "q": "¿Supervisión humana significa que un humano aprueba todo?",
              "a": "No. La supervisión es por niveles: en el bucle para acciones de alto impacto o irreversibles, monitorización sobre el bucle para acciones reversibles de alto volumen y una postura de humano al mando en general. El modelo se ajusta al riesgo para que la supervisión siga siendo significativa en vez de convertirse en fatiga de aprobación."
            },
            {
              "q": "¿Puede la rendición de cuentas recaer en el proveedor de IA?",
              "a": "No. Las relaciones con proveedores se gobiernan aparte, pero tu propietario de sistema nombrado sigue siendo responsable de cómo se despliega y usa el agente. La automatización es una herramienta, no una defensa."
            },
            {
              "q": "¿Cómo evitamos el sello automático y el sesgo de automatización?",
              "a": "Muestra contexto inteligible para cada decisión, limita y exige justificación para las aprobaciones, monitoriza el tiempo de aprobación y la tasa de anulaciones, y mantén a los supervisores competentes mediante formación y rotación."
            }
          ]
        },
        "pt": {
          "name": "Política de Supervisão Humana e Responsabilização",
          "summary": "Uma política operacional que leva a supervisão humana do Artigo 14 do EU AI Act à prática para a IA agêntica. Atribui um responsável nomeado por agente, define o nível de supervisão (no laço, sobre o laço, fora do laço) conforme o risco e estabelece a autoridade de intervenção, anulação e parada, além das vias de escalonamento. Exige que os supervisores sejam competentes e tenham tempo para agir, e protege contra o carimbo automático e o viés de automação. Existe para evitar duas falhas: o humano ausente e o humano simbólico que não consegue entender, anular nem responder pelo que o agente faz.",
          "definition": "Uma política de supervisão humana e responsabilização é um conjunto de regras vinculantes que atribui um humano nomeado como responsável por cada agente e garante que uma pessoa competente possa entender, intervir e parar suas ações.",
          "scope": "Todo agente em produção ou piloto que use ferramentas, aja sobre sistemas ou tome decisões consequentes, e os proprietários de sistema, aprovadores e operadores que os supervisionam. Operacionaliza o Artigo 14; não substitui aconselhamento jurídico.",
          "keyPoints": [
            "Cada agente tem um único responsável nomeado: a responsabilização nunca é transferida para o modelo.",
            "O nível de supervisão é ajustado ao risco: no laço para ações de alto impacto ou irreversíveis, sobre o laço para ações reversíveis de alto volume, fora do laço apenas para tarefas reversíveis de baixo risco.",
            "Cada agente expõe controles testados de rejeitar, modificar e parar (interruptor de parada) com o contexto necessário para uma decisão informada.",
            "Os limiares de escalonamento roteiam as decisões consequentes para humanos por impacto, irreversibilidade, direitos ou segurança, confiança e novidade.",
            "Os supervisores devem ser competentes, informados de forma inteligível e ter autoridade e tempo reais para agir.",
            "O viés de automação e o carimbo automático são contrariados ativamente, não presumidos como ausentes."
          ],
          "controls": [
            {
              "control": "Responsável nomeado",
              "note": "Atribua um humano que responda pelos resultados de cada agente. 'O modelo decidiu' não é uma explicação aceitável."
            },
            {
              "control": "Nível de supervisão conforme o risco",
              "note": "Defina no laço, sobre o laço ou fora do laço por agente conforme o impacto e a reversibilidade da ação. Implementa o padrão de portão de aprovação humana para ações de alto impacto."
            },
            {
              "control": "Autoridade de anulação e parada",
              "note": "Exponha controles testados de rejeitar, modificar e parar; mostre contexto suficiente para uma anulação informada. A parada deve ser rápida e acessível."
            },
            {
              "control": "Limiares de escalonamento",
              "note": "Roteie as decisões para humanos quando limiares de impacto, irreversibilidade, direitos/segurança, baixa confiança ou novidade forem cruzados. Implementa o padrão de escalonamento humano."
            },
            {
              "control": "Competência do supervisor",
              "note": "Treine e certifique os supervisores no domínio e nos limites do agente para que a supervisão seja significativa, não nominal."
            },
            {
              "control": "Salvaguardas contra o carimbo automático",
              "note": "Limite e exija justificativa para as aprovações; monitore o tempo de aprovação e a taxa de anulações para detectar o viés de automação."
            }
          ],
          "checklist": [
            "Nomeie um único responsável para cada agente em produção e registre-o.",
            "Classifique as ações de cada agente por impacto e reversibilidade e atribua um nível de supervisão.",
            "Implemente e teste os controles de rejeitar, modificar e parar (interruptor de parada) para cada agente.",
            "Garanta que o agente mostre contexto inteligível para qualquer decisão que precise de supervisão.",
            "Defina e configure limiares de escalonamento para impacto, direitos/segurança, confiança e novidade.",
            "Treine os supervisores no domínio e nos limites do agente e mantenha a certificação deles em dia.",
            "Adicione salvaguardas contra o carimbo automático e monitore o tempo de aprovação e a taxa de anulações.",
            "Registre cada aprovação e anulação com ator, motivo e marca de tempo, e revise os limiares periodicamente."
          ],
          "pitfalls": [
            "Supervisão simbólica: um humano clica em aprovar sem o contexto, a autoridade ou o tempo para avaliar de fato a ação.",
            "Viés de automação: os aprovadores confiam tanto no agente que param de escrutinar sua saída.",
            "Responsabilização difusa: nenhum responsável nomeado, então uma falha não tem humano que responda.",
            "Anulação inalcançável: um controle de parada lento, oculto ou nunca testado.",
            "Deriva de limiares: limites de escalonamento definidos uma vez e nunca atualizados à medida que o escopo do agente cresce."
          ],
          "examples": [
            "Um agente financeiro cujos pagamentos acima de um teto de gasto exigem aprovação humana no laço, enquanto as conciliações correm sobre o laço.",
            "Um agente de suporte que escala para um humano quando sua confiança é baixa ou uma solicitação afeta os direitos de um cliente.",
            "Um incidente em que o responsável nomeado presta contas e o registro de anulações mostra quem aprovou a ação e por quê."
          ],
          "faqs": [
            {
              "q": "Supervisão humana significa que um humano aprova tudo?",
              "a": "Não. A supervisão é em níveis: no laço para ações de alto impacto ou irreversíveis, monitoramento sobre o laço para ações reversíveis de alto volume e uma postura de humano no comando em geral. O modelo se ajusta ao risco para que a supervisão continue significativa em vez de virar fadiga de aprovação."
            },
            {
              "q": "A responsabilização pode ficar com o fornecedor de IA?",
              "a": "Não. As relações com fornecedores são governadas à parte, mas o seu proprietário de sistema nomeado continua responsável por como o agente é implantado e usado. A automação é uma ferramenta, não uma defesa."
            },
            {
              "q": "Como evitamos o carimbo automático e o viés de automação?",
              "a": "Mostre contexto inteligível para cada decisão, limite e exija justificativa para as aprovações, monitore o tempo de aprovação e a taxa de anulações, e mantenha os supervisores competentes por meio de treinamento e rotação."
            }
          ]
        },
        "fr": {
          "name": "Politique de surveillance humaine et de responsabilité",
          "summary": "Une politique opérationnelle qui concrétise la surveillance humaine de l'article 14 de l'EU AI Act pour l'IA agentique. Elle attribue un responsable désigné par agent, définit le niveau de surveillance (dans la boucle, sur la boucle, hors de la boucle) selon le risque, et détermine l'autorité d'intervention, de contournement et d'arrêt, ainsi que les parcours d'escalade. Elle exige que les surveillants soient compétents et disposent du temps nécessaire pour agir, et elle prémunit contre la validation automatique et le biais d'automatisation. Elle vise à éviter deux défaillances : l'humain absent et l'humain de façade qui ne peut ni comprendre, ni contourner, ni répondre des actions de l'agent.",
          "definition": "Une politique de surveillance humaine et de responsabilité est un ensemble de règles contraignantes qui attribue un responsable humain désigné pour chaque agent et garantit qu'une personne compétente puisse comprendre, intervenir et arrêter ses actions.",
          "scope": "Chaque agent en production ou en phase pilote qui utilise des outils, agit sur des systèmes ou prend des décisions importantes, ainsi que les propriétaires de systèmes, approbateurs et opérateurs qui les surveillent. Elle opérationnalise l'article 14 ; elle ne remplace pas un avis juridique.",
          "keyPoints": [
            "Chaque agent a un unique responsable désigné — la responsabilité n'est jamais transférée au modèle.",
            "Le niveau de surveillance est adapté au risque : dans la boucle pour les actions à fort impact ou irréversibles, sur la boucle pour les actions réversibles à grand volume, hors de la boucle uniquement pour les tâches réversibles à faible risque.",
            "Chaque agent expose des commandes testées de rejet, de modification et d'arrêt d'urgence (kill-switch) avec le contexte nécessaire pour une décision éclairée.",
            "Des seuils d'escalade orientent les décisions importantes vers des humains en fonction de l'impact, de l'irréversibilité, des droits ou de la sécurité, de la confiance et de la nouveauté.",
            "Les surveillants doivent être compétents, informés de manière intelligible, et disposer d'une autorité réelle ainsi que du temps nécessaire pour agir.",
            "Le biais d'automatisation et la validation automatique systématique sont activement combattus, et non ignorés."
          ],
          "controls": [
            {
              "control": "Responsable désigné",
              "note": "Attribuez un responsable humain unique pour les résultats de chaque agent. « Le modèle a décidé » n'est pas une explication acceptable."
            },
            {
              "control": "Niveau de surveillance adapté au risque",
              "note": "Définir le niveau d'intervention humaine (in-the-loop, on-the-loop ou out-of-the-loop) par agent en fonction de l'impact et de la réversibilité de l'action. Implémente le modèle de barrière d'approbation humaine (human-approval-gate) pour les actions à fort impact."
            },
            {
              "control": "Autorité de contournement et d'arrêt",
              "note": "Exposer des commandes testées de rejet, de modification et d'arrêt ; présenter suffisamment de contexte pour permettre un contournement éclairé. L'arrêt doit être rapide et accessible."
            },
            {
              "control": "Seuils d'escalade",
              "note": "Aiguiller les décisions vers des humains lorsque les seuils d'impact, d'irréversibilité, de droits/sécurité, de faible confiance ou de nouveauté sont franchis. Implémente le modèle d'escalade humaine (human-escalation)."
            },
            {
              "control": "Compétence des superviseurs",
              "note": "Former et certifier les superviseurs sur le domaine et les limites de l'agent afin que la supervision soit réelle et non purement nominale."
            },
            {
              "control": "Garanties contre la validation automatique",
              "note": "Réguler et exiger une justification pour les approbations ; surveiller le temps d'approbation et les taux de contournement pour détecter le biais d'automatisation."
            }
          ],
          "checklist": [
            "Désigner un responsable unique pour chaque agent en production et l'enregistrer.",
            "Classifier les actions de chaque agent par impact et réversibilité, et attribuer un niveau de supervision.",
            "Implémenter et tester des commandes de rejet, de modification et d'arrêt d'urgence (kill-switch) pour chaque agent.",
            "S'assurer que l'agent présente un contexte intelligible pour toute décision nécessitant une supervision.",
            "Définir et configurer des seuils d'escalade pour l'impact, les droits/sécurité, la confiance et la nouveauté.",
            "Former les superviseurs sur le domaine et les limites de l'agent et maintenir leur certification à jour.",
            "Ajouter des garanties contre la validation automatique et surveiller le temps d'approbation ainsi que les taux de contournement.",
            "Consigner chaque approbation et contournement avec l'auteur, le motif et l'horodatage, et réviser périodiquement les seuils."
          ],
          "pitfalls": [
            "Supervision de façade : un humain clique sur approuver sans disposer du contexte, de l'autorité ou du temps nécessaire pour évaluer réellement l'action.",
            "Biais d'automatisation : les approbateurs font tellement confiance à l'agent qu'ils cessent d'examiner ses résultats.",
            "Responsabilité diffuse : aucun responsable unique n'est désigné, de sorte qu'une défaillance ne peut être imputée à aucun humain.",
            "Contournement inaccessible : une commande d'arrêt lente, masquée ou jamais testée.",
            "Dérive des seuils : des limites d'escalade définies une fois pour toutes et jamais mises à jour à mesure que le périmètre de l'agent s'étend."
          ],
          "examples": [
            "Un agent financier dont les paiements supérieurs à un plafond de dépenses nécessitent une approbation humaine directe (in-the-loop), tandis que les rapprochements s'effectuent sous supervision indirecte (on-the-loop).",
            "Un agent de support qui escalade vers un humain lorsque son niveau de confiance est faible ou qu'une demande affecte les droits d'un client.",
            "Un incident pour lequel le responsable désigné est tenu pour responsable et où le journal des contournements indique qui a approuvé l'action et pourquoi."
          ],
          "faqs": [
            {
              "q": "La supervision humaine signifie-t-elle qu'un humain doit tout approuver ?",
              "a": "Non. La supervision est hiérarchisée : intervention directe (in-the-loop) pour les actions à fort impact ou irréversibles, surveillance indirecte (on-the-loop) pour les actions réversibles à grand volume, et une posture globale de contrôle humain (human-in-command). Le modèle s'adapte au risque afin que la supervision reste pertinente au lieu de générer une lassitude face aux approbations."
            },
            {
              "q": "La responsabilité peut-elle incomber au fournisseur d'IA ?",
              "a": "Non. Les relations avec les fournisseurs sont régies séparément, mais le responsable désigné de votre système reste redevable de la manière dont l'agent est déployé et utilisé. L'automatisation est un outil, pas une défense."
            },
            {
              "q": "Comment éviter la validation automatique et le biais d'automatisation ?",
              "a": "Présenter un contexte intelligible pour chaque décision, réguler et exiger une justification pour les approbations, surveiller le temps d'approbation et les taux de contournement, et maintenir la compétence des superviseurs par la formation et la rotation."
            }
          ]
        },
        "de": {
          "name": "Richtlinie für menschliche Aufsicht und Rechenschaftspflicht",
          "summary": "Eine operative Richtlinie, die die menschliche Aufsicht gemäß Artikel 14 des EU AI Act für agentische KI in die Praxis umsetzt. Sie weist jedem Agenten eine namentlich benannte verantwortliche Person zu, legt die Aufsichtsstufe (In-the-Loop, On-the-Loop, Out-of-the-Loop) je nach Risiko fest und definiert Eingriffs-, Override- und Stopp-Befugnisse sowie Eskalationspfade. Sie setzt voraus, dass die Aufsichtspersonen kompetent sind und Zeit zum Handeln haben, und schützt vor blindem Abnicken (Rubber-Stamping) und Automatisierungsbias. Sie dient dazu, zwei Fehler zu vermeiden: den abwesenden Menschen und den Alibi-Menschen, der das Handeln des Agenten weder verstehen noch überschreiben oder dafür geradestehen kann.",
          "definition": "Eine Richtlinie für menschliche Aufsicht und Rechenschaftspflicht ist ein verbindliches Regelwerk, das jedem Agenten eine namentlich benannte Person zuweist, die für ihn verantwortlich ist, und garantiert, dass eine kompetente Person seine Aktionen verstehen, in diese eingreifen und sie stoppen kann.",
          "scope": "Jeder produktive oder Pilot-Agent, der Tools nutzt, auf Systemen agiert oder folgenschwere Entscheidungen trifft, sowie die Systemverantwortlichen, Genehmiger und Bediener, die sie beaufsichtigen. Sie operationalisiert Artikel 14; sie ist kein Ersatz für eine Rechtsberatung.",
          "keyPoints": [
            "Jeder Agent hat eine namentlich benannte, verantwortliche Person – die Verantwortung wird niemals auf das Modell übertragen.",
            "Die Aufsichtsstufe ist auf das Risiko abgestimmt: In-the-Loop bei folgenschweren oder unumkehrbaren Aktionen, On-the-Loop bei umkehrbaren Aktionen mit hohem Volumen, Out-of-the-Loop nur bei risikoarmen, umkehrbaren Aufgaben.",
            "Jeder Agent bietet getestete Kontrollmöglichkeiten zum Ablehnen, Ändern und Stoppen (Notaus/Kill-Switch) mit dem für eine fundierte Entscheidung erforderlichen Kontext.",
            "Eskalationsschwellen leiten folgenschwere Entscheidungen basierend auf Auswirkungen, Unumkehrbarkeit, Rechten oder Sicherheit, Konfidenz und Neuartigkeit an Menschen weiter.",
            "Aufsichtspersonen müssen kompetent und verständlich informiert sein sowie über echte Befugnisse und ausreichend Zeit zum Handeln verfügen.",
            "Automatisierungsbias und blindes Abnicken (Rubber-Stamping) werden aktiv bekämpft und nicht einfach als nicht existent vorausgesetzt."
          ],
          "controls": [
            {
              "control": "Namentlich benannte verantwortliche Person",
              "note": "Weisen Sie jedem Agenten eine Person zu, die für dessen Ergebnisse verantwortlich ist. \"Das Modell hat entschieden\" ist keine akzeptable Erklärung."
            },
            {
              "control": "Risikoangepasste Aufsichtsstufe",
              "note": "Definieren Sie In-the-Loop, On-the-Loop oder Out-of-the-Loop pro Agent basierend auf den Auswirkungen und der Reversibilität von Aktionen. Implementiert das Human-Approval-Gate-Muster für folgenschwere Aktionen."
            },
            {
              "control": "Befugnis zum Überschreiben und Stoppen",
              "note": "Stellen Sie getestete Steuerelemente zum Ablehnen, Ändern und Stoppen bereit; stellen Sie ausreichend Kontext für ein fundiertes Überschreiben zur Verfügung. Der Stopp muss schnell und erreichbar sein."
            },
            {
              "control": "Eskalationsschwellenwerte",
              "note": "Leiten Sie Entscheidungen an Menschen weiter, wenn Schwellenwerte für Auswirkungen, Irreversibilität, Rechte/Sicherheit, geringes Vertrauen oder Neuartigkeit überschritten werden. Implementiert das Human-Escalation-Muster."
            },
            {
              "control": "Kompetenz der Aufsichtspersonen",
              "note": "Schulen und zertifizieren Sie Aufsichtspersonen für den Bereich und die Grenzen des Agenten, damit die Aufsicht effektiv und nicht nur nominell ist."
            },
            {
              "control": "Schutzmaßnahmen gegen blindes Abnicken",
              "note": "Drosseln Sie Genehmigungen und fordern Sie Begründungen dafür ein; überwachen Sie die Genehmigungszeit und die Überschreibungsraten, um Automation Bias (Automatisierungsgläubigkeit) zu erkennen."
            }
          ],
          "checklist": [
            "Benennen Sie einen verantwortlichen Eigentümer für jeden produktiven Agenten und dokumentieren Sie dies.",
            "Klassifizieren Sie die Aktionen jedes Agenten nach Auswirkung und Reversibilität und weisen Sie eine Aufsichtsstufe zu.",
            "Implementieren und testen Sie Steuerelemente zum Ablehnen, Ändern und Stoppen (Kill-Switch) für jeden Agenten.",
            "Stellen Sie sicher, dass der Agent verständlichen Kontext für jede Entscheidung liefert, die einer Aufsicht bedarf.",
            "Definieren und konfigurieren Sie Eskalationsschwellenwerte für Auswirkungen, Rechte/Sicherheit, Vertrauen und Neuartigkeit.",
            "Schulen Sie Aufsichtspersonen für den Bereich und die Grenzen des Agenten und halten Sie deren Zertifizierung auf dem neuesten Stand.",
            "Fügen Sie Schutzmaßnahmen gegen blindes Abnicken hinzu und überwachen Sie die Genehmigungszeit sowie die Überschreibungsraten.",
            "Protokollieren Sie jede Genehmigung und Überschreibung mit Akteur, Grund und Zeitstempel, und überprüfen Sie die Schwellenwerte regelmäßig."
          ],
          "pitfalls": [
            "Alibi-Aufsicht: Ein Mensch klickt auf Genehmigen, ohne den Kontext, die Befugnis oder die Zeit zu haben, die Aktion tatsächlich zu bewerten.",
            "Automation Bias (Automatisierungsgläubigkeit): Genehmigende vertrauen dem Agenten so sehr, dass sie aufhören, dessen Ergebnisse kritisch zu prüfen.",
            "Diffuse Verantwortlichkeit: Es gibt keinen namentlich genannten Eigentümer, sodass bei einem Fehler kein Mensch zur Rechenschaft gezogen werden kann.",
            "Unerreichbares Überschreiben: Ein Stopp-Steuerelement, das langsam, versteckt oder nie getestet ist.",
            "Schwellenwert-Drift: Eskalationsgrenzen werden einmal festgelegt und nie aktualisiert, wenn der Aufgabenbereich des Agenten wächst."
          ],
          "examples": [
            "Ein Finanz-Agent, dessen Zahlungen über einer Ausgabengrenze eine menschliche Genehmigung (In-the-Loop) erfordern, während Abstimmungen On-the-Loop laufen.",
            "Ein Support-Agent, der an einen Menschen eskaliert, wenn sein Vertrauen gering ist oder eine Anfrage die Rechte eines Kunden betrifft.",
            "Ein Vorfall, bei dem der namentlich genannte Eigentümer zur Rechenschaft gezogen wird und das Überschreibungsprotokoll zeigt, wer die Aktion genehmigt hat und warum."
          ],
          "faqs": [
            {
              "q": "Bedeutet menschliche Aufsicht, dass ein Mensch alles genehmigen muss?",
              "a": "Nein. Die Aufsicht ist gestuft: In-the-Loop für folgenschwere oder irreversible Aktionen, On-the-Loop-Überwachung für reversible Aktionen mit hohem Volumen und eine übergeordnete Human-in-Command-Haltung. Das Modell skaliert mit dem Risiko, sodass die Aufsicht sinnvoll bleibt, anstatt zu einer Genehmigungsmüdigkeit zu führen."
            },
            {
              "q": "Kann die Verantwortung beim KI-Anbieter liegen?",
              "a": "Nein. Beziehungen zu Anbietern werden separat geregelt, aber Ihr namentlich genannter Systemverantwortlicher bleibt dafür verantwortlich, wie der Agent bereitgestellt und verwendet wird. Automatisierung ist ein Werkzeug, keine Rechtfertigung."
            },
            {
              "q": "Wie verhindern wir blindes Abnicken und Automation Bias?",
              "a": "Stellen Sie verständlichen Kontext für jede Entscheidung bereit, drosseln Sie Genehmigungen und fordern Sie Begründungen dafür ein, überwachen Sie die Genehmigungszeit sowie die Überschreibungsraten und halten Sie die Aufsichtspersonen durch Schulungen und Rotation kompetent."
            }
          ]
        },
        "ja": {
          "name": "人間による監視と説明責任に関するポリシー",
          "summary": "EU AI Act第14条の人間による監視を、エージェント型AI向けに実践へと落とし込む運用ポリシーです。エージェントごとに明確な責任ある所有者を割り当て、リスクに応じて監視レベル（in-the-loop、on-the-loop、out-of-the-loop）を設定し、介入、オーバーライド、停止権限、およびエスカレーションパスを定義します。監視者が有能であり、行動を起こす時間があることを要求し、形骸化（ラバースタンプ）や自動化バイアスを防ぎます。このポリシーは、2つの失敗、すなわち「人間が不在であること」と、エージェントの行動を実際に理解、オーバーライド、または説明できない「名ばかりの人間」を防ぐために存在します。",
          "definition": "人間による監視と説明責任に関するポリシーとは、各エージェントに対して責任を負う特定の人間を割り当て、有能な人物がその行動を理解、介入、および停止できることを保証する、拘束力のあるルールセットです。",
          "scope": "ツールを使用する、システム上で動作する、または重大な意思決定を行うすべての本番環境またはパイロット版のエージェント、およびそれらを監視するシステム所有者、承認者、オペレーター。これは第14条を運用可能にするものであり、法的助言に代わるものではありません。",
          "keyPoints": [
            "各エージェントには、特定の責任ある所有者が1名割り当てられます。説明責任がモデルに移転されることは決してありません。",
            "監視レベルはリスクに適合させます。影響が大きい、または不可逆的なアクションにはin-the-loop、可逆的で大量のアクションにはon-the-loop、低リスクで可逆的なタスクにのみout-of-the-loopを適用します。",
            "すべてのエージェントは、十分な情報に基づいた意思決定に必要なコンテキストとともに、テスト済みの拒否、修正、および停止（キルスイッチ）コントロールを公開します。",
            "エスカレーションのしきい値により、影響、不可逆性、権利または安全性、確信度、および新規性に基づいて、重大な意思決定が人間にルーティングされます。",
            "監視者は、有能であり、分かりやすく情報を与えられ、行動するための真の権限と時間を持っていなければなりません。",
            "自動化バイアスや形骸化（ラバースタンプ）は、想定から排除するのではなく、積極的に対策を講じます。"
          ],
          "controls": [
            {
              "control": "特定の責任ある所有者",
              "note": "各エージェントの成果に対して責任を負う人間を1名割り当てます。「モデルが決定した」という説明は受け入れられません。"
            },
            {
              "control": "リスクに適合した監視レベル",
              "note": "アクションの影響度と可逆性に基づいて、エージェントごとに in-the-loop、on-the-loop、または out-of-the-loop を定義します。影響度の高いアクションに対して human-approval-gate パターンを実装します。"
            },
            {
              "control": "オーバーライドおよび停止の権限",
              "note": "テスト済みの拒否、変更、および停止のコントロールを公開し、十分な情報に基づいたオーバーライドを行うための十分なコンテキストを提示します。停止は迅速かつ到達可能でなければなりません。"
            },
            {
              "control": "エスカレーションのしきい値",
              "note": "影響度、不可逆性、権利/安全性、信頼度の低さ、または新規性のしきい値を超えた場合、意思決定を人間にルーティングします。human-escalation パターンを実装します。"
            },
            {
              "control": "監視者の適格性",
              "note": "監視が名目上のものではなく有意義なものとなるよう、エージェントのドメインと限界について監視者をトレーニングし、認定します。"
            },
            {
              "control": "形骸化防止のセーフガード",
              "note": "承認を制限し、理由の提示を義務付けます。自動化バイアスを検出するために、承認時間とオーバーライド率を監視します。"
            }
          ],
          "checklist": [
            "本番環境の各エージェントに対して責任あるオーナーを1名指名し、記録します。",
            "各エージェントのアクションを影響度と可逆性によって分類し、監視レベルを割り当てます。",
            "すべてのエージェントに対して、拒否、変更、および停止（キルスイッチ）のコントロールを実装し、テストします。",
            "監視が必要な意思決定について、エージェントが理解可能なコンテキストを提示するようにします。",
            "影響度、権利/安全性、信頼度、および新規性のエスカレーションしきい値を定義し、設定します。",
            "エージェントのドメインと限界について監視者をトレーニングし、その認定を最新の状態に維持します。",
            "形骸化防止のセーフガードを追加し、承認時間とオーバーライド率を監視します。",
            "すべての承認とオーバーライドを実行者、理由、タイムスタンプとともにログに記録し、定期的にしきい値を見直します。"
          ],
          "pitfalls": [
            "形ばかりの監視：人間が、アクションを実際に評価するためのコンテキスト、権限、または時間がないまま「承認」をクリックしてしまうこと。",
            "自動化バイアス：承認者がエージェントを過度に信頼し、その出力を精査しなくなること。",
            "責任の分散：指名された単一のオーナーが存在しないため、障害が発生した際に対応すべき責任者が曖昧になること。",
            "到達不可能なオーバーライド：停止コントロールの動作が遅い、隠されている、または一度もテストされていないこと。",
            "しきい値のドリフト：エスカレーションの制限が一度設定されたきり、エージェントの適用範囲が拡大しても更新されないこと。"
          ],
          "examples": [
            "支出上限を超える支払いには人間による in-the-loop の承認が必要である一方、照合業務は on-the-loop で実行される財務エージェント。",
            "信頼度が低い場合や、リクエストが顧客の権利に影響を与える場合に、人間にエスカレーションするサポートエージェント。",
            "指名されたオーナーが責任を問われ、オーバーライドログによって誰がなぜそのアクションを承認したかが示されるインシデント。"
          ],
          "faqs": [
            {
              "q": "人間による監視とは、人間がすべてを承認することを意味しますか？",
              "a": "いいえ。監視は階層化されています。影響度が高いアクションや不可逆的なアクションには in-the-loop、可逆的で大量のアクションには on-the-loop のモニタリング、そして全体として human-in-command の姿勢をとります。このモデルはリスクに応じて拡張されるため、監視が承認疲れに陥ることなく、有意義な状態を維持できます。"
            },
            {
              "q": "責任をAIベンダーに負わせることはできますか？",
              "a": "いいえ。ベンダーとの関係は別途管理されますが、エージェントがどのようにデプロイされ使用されるかについては、指名されたシステムオーナーが引き続き責任を負います。自動化はツールであり、言い訳にはなりません。"
            },
            {
              "q": "形骸化や自動化バイアスを防ぐにはどうすればよいですか？",
              "a": "各意思決定について理解可能なコンテキストを提示し、承認を制限して理由の提示を義務付け、承認時間とオーバーライド率を監視し、トレーニングやローテーションを通じて監視者の適格性を維持します。"
            }
          ]
        },
        "zh": {
          "name": "人工监督与问责政策",
          "summary": "一项将 EU AI Act 第 14 条的人工监督要求转化为智能体 AI（agentic AI）实践的运营政策。它为每个智能体分配一名指定的明确责任人，根据风险设定监督级别（人机协同 in-the-loop、人机监视 on-the-loop、人机脱离 out-of-the-loop），并定义干预、覆盖和终止权限以及升级路径。它要求监督人员具备相应能力并有充足的时间采取行动，同时防范流于形式的审批和自动化偏见。该政策旨在防止两种失败情况：人员缺位，以及无法真正理解、覆盖智能体行为或为其负责的“工具人”式监督。",
          "definition": "人工监督与问责政策是一套具有约束力的规则集，它为每个智能体分配一名指定的负责人，并确保有能力的人员能够理解、干预和终止其行为。",
          "scope": "每一个在生产或试点环境中运行、使用工具、对系统执行操作或做出重大决策的智能体，以及负责监督它们的系统所有者、审批者和操作员。它使第 14 条具有可操作性；它不能替代法律建议。",
          "keyPoints": [
            "每个智能体都有一名指定的明确责任人——问责权绝不能转移给模型。",
            "监督级别与风险相匹配：对于高影响或不可逆的行为采用人机协同（in-the-loop），对于可逆的高频行为采用人机监视（on-the-loop），仅对于低风险且可逆的任务采用人机脱离（out-of-the-loop）。",
            "每个智能体都提供经过测试的拒绝、修改和终止（紧急停止开关）控制，并附带做出明智决策所需的上下文信息。",
            "升级阈值根据影响、不可逆性、权利或安全、置信度以及新颖性，将重大决策路由给人工处理。",
            "监督人员必须具备相应能力、获取清晰的信息，并拥有真正的授权和充足的行动时间。",
            "积极应对自动化偏见和流于形式的审批，而不是假定这些问题不存在。"
          ],
          "controls": [
            {
              "control": "指定的明确责任人",
              "note": "为每个智能体的结果分配一名负责人。“模型做出的决定”不是可接受的解释。"
            },
            {
              "control": "与风险相匹配的监督级别",
              "note": "根据操作影响和可逆性，为每个智能体定义“人在环路中”（in-the-loop）、“人在环路上”（on-the-loop）或“人在环路外”（out-of-the-loop）。针对高影响操作实现“人工审批关卡”（human-approval-gate）模式。"
            },
            {
              "control": "覆盖与终止权限",
              "note": "提供经过测试的拒绝、修改和终止控制；呈现足够的上下文以实现知情覆盖。终止操作必须快速且触手可及。"
            },
            {
              "control": "升级上报阈值",
              "note": "当跨越影响、不可逆性、权利/安全、低置信度或新颖性阈值时，将决策路由给人工。实现“人工升级上报”（human-escalation）模式。"
            },
            {
              "control": "监督人员能力",
              "note": "针对智能体的领域和局限性对监督人员进行培训和认证，使监督具有实质意义，而非流于形式。"
            },
            {
              "control": "防走过场保护机制",
              "note": "对审批进行限流并要求提供理由；监控审批时间和覆盖率，以检测自动化偏差。"
            }
          ],
          "checklist": [
            "为每个生产环境中的智能体指定一名负责的拥有者并予以记录。",
            "根据影响和可逆性对每个智能体的操作进行分类，并分配监督级别。",
            "为每个智能体实现并测试拒绝、修改和终止（紧急停止开关）控制。",
            "确保智能体为任何需要监督的决策呈现易于理解的上下文。",
            "针对影响、权利/安全、置信度和新颖性定义并配置升级上报阈值。",
            "针对智能体的领域和局限性对监督人员进行培训，并保持其认证的有效性。",
            "增加防走过场保护机制，并监控审批时间和覆盖率。",
            "记录每次审批和覆盖的操作人员、原因及时间戳，并定期审查阈值。"
          ],
          "pitfalls": [
            "象征性监督：人员在缺乏上下文、权限或时间来实际评估操作的情况下直接点击批准。",
            "自动化偏差：审批者过度信任智能体，以至于不再仔细审查其输出。",
            "责任分散：没有指定单一的拥有者，导致发生故障时没有可追责的人员。",
            "无法触及的覆盖：终止控制响应缓慢、隐藏过深或从未经过测试。",
            "阈值漂移：升级上报限制仅在设置时确定一次，随着智能体业务范围的扩大而从未更新。"
          ],
          "examples": [
            "一个财务智能体，其超过支出上限的付款需要“人在环路中”的人工审批，而对账工作则在“人在环路上”运行。",
            "一个支持智能体，当其置信度较低或请求影响到客户权益时，会升级上报给人工处理。",
            "在发生事件时，由指定的拥有者承担责任，且覆盖日志能够显示是谁批准了该操作以及原因。"
          ],
          "faqs": [
            {
              "q": "人工监督是否意味着每件事都需要人工批准？",
              "a": "不。监督是分层的：针对高影响或不可逆的操作采用“人在环路中”（in-the-loop），针对可逆的高频操作采用“人在环路上”（on-the-loop）监控，并在整体上保持“人为主导”（human-in-command）的态势。该模式根据风险进行扩展，使监督保持实质意义，而不是演变成审批疲劳。"
            },
            {
              "q": "责任可以由 AI 厂商承担吗？",
              "a": "不能。与厂商的关系是单独管理的，但您指定的系统拥有者仍需对智能体的部署和使用方式负责。自动化是一种工具，而不是免责辩护。"
            },
            {
              "q": "我们如何防止走过场和自动化偏差？",
              "a": "为每个决策呈现易于理解的上下文，对审批进行限流并要求提供理由，监控审批时间和覆盖率，并通过培训和轮岗保持监督人员的能力。"
            }
          ]
        }
      }
    },
    {
      "id": "GOV-008",
      "slug": "owasp-llm-top10",
      "category": "framework",
      "updated": "2026-08-22",
      "version": "1.0",
      "url": "https://santismm.com/en/governance/owasp-llm-top10",
      "api": "https://santismm.com/api/governance/owasp-llm-top10",
      "canonical_url": "https://santismm.com/en/governance/owasp-llm-top10",
      "api_url": "https://santismm.com/api/governance/owasp-llm-top10",
      "evidence": {
        "evidenceLevel": "industry_observation",
        "confidenceLevel": "high",
        "sourceType": [
          "paper",
          "industry_observation",
          "personal_experience"
        ]
      },
      "frameworks": [
        "OWASP GenAI Security Project",
        "NIST AI RMF",
        "MITRE ATLAS"
      ],
      "patterns": [
        "least-privilege-tooling",
        "egress-allowlist",
        "sandboxed-execution",
        "human-approval-gate"
      ],
      "knowledge": [
        "prompt-injection",
        "ai-cyberdefense",
        "agentic-threat-model",
        "mcp-security",
        "guardrails"
      ],
      "references": [
        {
          "title": "OWASP — Top 10 for LLM Applications",
          "url": "https://genai.owasp.org/llm-top-10/"
        },
        {
          "title": "OWASP — LLM01: Prompt Injection",
          "url": "https://genai.owasp.org/llmrisk/llm01-prompt-injection/"
        },
        {
          "title": "MITRE ATLAS — Adversarial Threat Landscape for AI Systems",
          "url": "https://atlas.mitre.org/"
        },
        {
          "title": "NIST — AI Risk Management Framework (AI RMF 1.0)",
          "url": "https://www.nist.gov/itl/ai-risk-management-framework"
        }
      ],
      "related": [
        "mitre-atlas",
        "nist-ai-rmf",
        "iso-42001",
        "agentic-ai-governance-checklist",
        "audit-framework-for-agentic-systems"
      ],
      "locales": {
        "en": {
          "name": "OWASP Top 10 for LLM Applications",
          "summary": "The OWASP Top 10 for LLM Applications is the shared vocabulary for what goes wrong in systems built on language models. It is not a control framework and does not tell you what to implement — it names the vulnerability classes, from prompt injection through excessive agency to unbounded consumption, so that teams, auditors and vendors can argue about the same things. Its practical value is as a checklist over your own architecture and as the common language in which findings get reported.",
          "definition": "The OWASP Top 10 for LLM Applications is a community-maintained list of the most critical vulnerability classes in applications built on large language models, published by the OWASP GenAI Security Project and revised periodically as the ecosystem changes.",
          "scope": "Any application built on a large language model — chat interfaces, retrieval systems, agents and the tools they call. It is voluntary, non-certifiable and deliberately descriptive: it classifies risks, it does not prescribe controls or grant compliance.",
          "keyPoints": [
            "Prompt injection has led the list since the first edition, and remains the class with no clean fix — only layered containment.",
            "The 2025 edition covers prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption. The list is revised periodically, so check the current edition rather than trusting a cached one.",
            "Several entries are agent-specific in effect: excessive agency and improper output handling only become severe once the model can act.",
            "It is a taxonomy, not a control set. Mapping a finding to LLM06 tells you what kind of problem it is, not what to build.",
            "It is the lingua franca of the field: security reviews, vendor questionnaires and bug reports all reference it, which is most of why it is worth knowing by number.",
            "Coverage of the list is not a security posture. Every entry needs a control in your architecture, and an entry with no control is an accepted risk whether or not anyone wrote that down."
          ],
          "controls": [
            {
              "control": "Map the list onto your own architecture",
              "note": "Walk each entry against your actual inputs, tools, data stores and outputs. The exercise is worth more than the list, because it surfaces the entries that do not apply and the surfaces the list does not name."
            },
            {
              "control": "Assign an owner and a control per entry",
              "note": "Each applicable class needs a named component that bounds it and a person who maintains that component. An entry mapped to nothing is a gap with a reference number."
            },
            {
              "control": "Treat prompt injection as containment, not prevention",
              "note": "LLM01 has no reliable fix at the model layer. The controls that matter are least-privilege tooling, egress restriction, output handling and approval gates for high-impact actions."
            },
            {
              "control": "Constrain agency explicitly",
              "note": "For LLM06, write down what the agent may do, with which credentials, against which targets — and enforce it below the model rather than in the prompt."
            },
            {
              "control": "Handle model output as untrusted input",
              "note": "For LLM05, anything the model emits that reaches a renderer, a shell, a query or another system needs the same encoding and validation you would apply to input from a stranger."
            },
            {
              "control": "Bound consumption",
              "note": "For LLM10, rate limits, quotas and timeouts turn an availability and cost attack into a logged refusal. This is the entry teams most often skip because it does not look like security until the invoice arrives."
            },
            {
              "control": "Re-run the mapping when the list or the system changes",
              "note": "The list is revised and your tool catalogue grows. A mapping done once is a document about a system that no longer exists."
            }
          ],
          "checklist": [
            "Read the current edition rather than a summary — including this one.",
            "Produce a mapping table: entry → applies? → control → owner.",
            "For every applicable entry with no control, record it as an accepted risk with a reason and a compensating detection.",
            "Write a test for each control, and see the test fail before trusting it.",
            "Check the entries that only bite with tools: excessive agency, improper output handling, supply chain.",
            "Confirm rate limits and quotas exist and return correct signals to well-behaved clients.",
            "Re-run the mapping whenever a tool, a data source or an autonomy level changes.",
            "Use the list's numbering in findings so reviewers and vendors are discussing the same class."
          ],
          "pitfalls": [
            "Treating the list as a compliance target: covering ten headings while the actual architecture stays unexamined.",
            "Assuming a model vendor's safety work covers LLM01. It reduces attempts; the consequences remain entirely yours.",
            "Mapping to a cached edition. The list is revised, and an old mapping quietly stops covering current classes.",
            "Skipping LLM10 because unbounded consumption looks like an operations problem rather than a security one.",
            "Confusing naming a class with controlling it. A tidy mapping table with no enforcement is documentation of risk, not reduction of it."
          ],
          "examples": [
            "An agent that summarises customer emails maps to LLM01 (the email body is untrusted instruction input), LLM02 (the summary can repeat data the requester should not see) and LLM06 (the CRM tool turns a hijack into an action) — three entries from one feature, each needing a different control.",
            "A RAG system over an internal wiki maps to LLM01 via indirect injection from any page editor, LLM04 if the index can be poisoned, and LLM08 for retrieval that returns documents outside the requester's permissions.",
            "A public MCP endpoint maps most sharply to LLM10: read-only, public data, so the consumption bound — rate limits with correct headers — is the entry doing the real work."
          ],
          "faqs": [
            {
              "q": "Is the OWASP LLM Top 10 something you can be compliant with?",
              "a": "No. It is an awareness and classification document, not a certifiable standard. It pairs naturally with a management system such as ISO 42001 or a framework such as the NIST AI RMF, which is where governance obligations actually live."
            },
            {
              "q": "Which entries change most when you add tools to a model?",
              "a": "Excessive agency and improper output handling. Without tools they produce a wrong answer; with tools they produce an action, and severity moves from embarrassment to incident."
            },
            {
              "q": "How does it relate to MITRE ATLAS?",
              "a": "They answer different questions. OWASP names the vulnerability classes in your application; ATLAS catalogues the tactics and techniques an adversary uses against AI systems. One is a checklist over your design, the other is a map of the attacker's playbook."
            }
          ]
        },
        "es": {
          "name": "OWASP Top 10 para Aplicaciones LLM",
          "summary": "El OWASP Top 10 para aplicaciones LLM es el vocabulario común de lo que sale mal en sistemas construidos sobre modelos de lenguaje. No es un marco de controles y no dice qué implementar: nombra las clases de vulnerabilidad, de la inyección de prompts al exceso de agencia y al consumo sin límite, para que equipos, auditores y proveedores discutan sobre las mismas cosas. Su valor práctico es servir de lista de comprobación sobre tu propia arquitectura y de idioma común en el que se reportan los hallazgos.",
          "definition": "El OWASP Top 10 para aplicaciones LLM es una lista mantenida por la comunidad con las clases de vulnerabilidad más críticas en aplicaciones construidas sobre grandes modelos de lenguaje, publicada por el OWASP GenAI Security Project y revisada periódicamente conforme cambia el ecosistema.",
          "scope": "Cualquier aplicación construida sobre un gran modelo de lenguaje: interfaces de chat, sistemas de recuperación, agentes y las herramientas que invocan. Es voluntaria, no certificable y deliberadamente descriptiva: clasifica riesgos, no prescribe controles ni otorga conformidad.",
          "keyPoints": [
            "La inyección de prompts encabeza la lista desde la primera edición y sigue siendo la clase sin solución limpia: solo contención por capas.",
            "La edición de 2025 cubre inyección de prompts, divulgación de información sensible, cadena de suministro, envenenamiento de datos y modelo, tratamiento indebido de la salida, exceso de agencia, filtración del system prompt, debilidades de vectores y embeddings, desinformación y consumo sin límite. La lista se revisa periódicamente, así que consulta la edición vigente y no una copia en caché.",
            "Varias entradas son en la práctica específicas de agentes: el exceso de agencia y el tratamiento indebido de la salida solo se vuelven graves cuando el modelo puede actuar.",
            "Es una taxonomía, no un conjunto de controles. Mapear un hallazgo a LLM06 te dice de qué tipo de problema se trata, no qué construir.",
            "Es la lengua franca del campo: revisiones de seguridad, cuestionarios de proveedores y reportes de fallos la citan, y esa es buena parte del motivo para conocerla por número.",
            "Cubrir la lista no es una postura de seguridad. Cada entrada necesita un control en tu arquitectura, y una entrada sin control es un riesgo aceptado lo haya escrito alguien o no."
          ],
          "controls": [
            {
              "control": "Mapea la lista sobre tu propia arquitectura",
              "note": "Recorre cada entrada frente a tus entradas reales, herramientas, almacenes de datos y salidas. El ejercicio vale más que la lista, porque saca a la luz las entradas que no aplican y las superficies que la lista no nombra."
            },
            {
              "control": "Asigna responsable y control por entrada",
              "note": "Cada clase aplicable necesita un componente concreto que la acote y una persona que lo mantenga. Una entrada mapeada a nada es una brecha con número de referencia."
            },
            {
              "control": "Trata la inyección de prompts como contención, no como prevención",
              "note": "LLM01 no tiene solución fiable en la capa del modelo. Los controles que importan son herramientas con mínimo privilegio, restricción de salida, tratamiento de la salida y puertas de aprobación para acciones de alto impacto."
            },
            {
              "control": "Acota la agencia de forma explícita",
              "note": "Para LLM06, escribe qué puede hacer el agente, con qué credenciales y contra qué objetivos, y aplícalo por debajo del modelo en lugar de en el prompt."
            },
            {
              "control": "Trata la salida del modelo como entrada no confiable",
              "note": "Para LLM05, todo lo que el modelo emita y llegue a un renderizador, un shell, una consulta u otro sistema necesita la misma codificación y validación que aplicarías a la entrada de un desconocido."
            },
            {
              "control": "Acota el consumo",
              "note": "Para LLM10, los límites de tasa, las cuotas y los timeouts convierten un ataque de disponibilidad y coste en un rechazo registrado. Es la entrada que más se salta la gente porque no parece seguridad hasta que llega la factura."
            },
            {
              "control": "Rehaz el mapeo cuando cambie la lista o el sistema",
              "note": "La lista se revisa y tu catálogo de herramientas crece. Un mapeo hecho una vez es un documento sobre un sistema que ya no existe."
            }
          ],
          "checklist": [
            "Lee la edición vigente en lugar de un resumen, incluido este.",
            "Produce una tabla de mapeo: entrada → ¿aplica? → control → responsable.",
            "Para cada entrada aplicable sin control, regístrala como riesgo aceptado con motivo y detección compensatoria.",
            "Escribe una prueba por control y ve fallar la prueba antes de confiar en ella.",
            "Revisa las entradas que solo muerden con herramientas: exceso de agencia, tratamiento indebido de la salida, cadena de suministro.",
            "Confirma que existen límites de tasa y cuotas y que devuelven señales correctas a los clientes bien educados.",
            "Rehaz el mapeo siempre que cambie una herramienta, una fuente de datos o un nivel de autonomía.",
            "Usa la numeración de la lista en los hallazgos para que revisores y proveedores hablen de la misma clase."
          ],
          "pitfalls": [
            "Tratar la lista como objetivo de cumplimiento: cubrir diez titulares mientras la arquitectura real sigue sin examinarse.",
            "Suponer que el trabajo de seguridad del proveedor del modelo cubre LLM01. Reduce los intentos; las consecuencias siguen siendo enteramente tuyas.",
            "Mapear contra una edición en caché. La lista se revisa, y un mapeo antiguo deja de cubrir en silencio las clases actuales.",
            "Saltarse LLM10 porque el consumo sin límite parece un problema de operaciones y no de seguridad.",
            "Confundir nombrar una clase con controlarla. Una tabla de mapeo impecable sin aplicación es documentación del riesgo, no reducción."
          ],
          "examples": [
            "Un agente que resume correos de clientes mapea a LLM01 (el cuerpo del correo es entrada de instrucciones no confiable), LLM02 (el resumen puede repetir datos que quien pregunta no debería ver) y LLM06 (la herramienta de CRM convierte el secuestro en acción): tres entradas de una sola funcionalidad, cada una con un control distinto.",
            "Un sistema RAG sobre una wiki interna mapea a LLM01 por inyección indirecta desde cualquier editor de páginas, a LLM04 si el índice puede envenenarse y a LLM08 por recuperación que devuelve documentos fuera de los permisos de quien pregunta.",
            "Un endpoint MCP público mapea sobre todo a LLM10: solo lectura y datos públicos, así que el límite de consumo —límites de tasa con cabeceras correctas— es la entrada que hace el trabajo de verdad."
          ],
          "faqs": [
            {
              "q": "¿Se puede ser conforme con el OWASP LLM Top 10?",
              "a": "No. Es un documento de concienciación y clasificación, no una norma certificable. Encaja de forma natural con un sistema de gestión como ISO 42001 o un marco como el NIST AI RMF, que es donde viven de verdad las obligaciones de gobierno."
            },
            {
              "q": "¿Qué entradas cambian más al dar herramientas al modelo?",
              "a": "El exceso de agencia y el tratamiento indebido de la salida. Sin herramientas producen una respuesta equivocada; con herramientas producen una acción, y la gravedad pasa de bochorno a incidente."
            },
            {
              "q": "¿Qué relación tiene con MITRE ATLAS?",
              "a": "Responden preguntas distintas. OWASP nombra las clases de vulnerabilidad de tu aplicación; ATLAS cataloga las tácticas y técnicas que un adversario usa contra sistemas de IA. Una es una lista de comprobación sobre tu diseño, la otra un mapa del manual del atacante."
            }
          ]
        },
        "pt": {
          "name": "OWASP Top 10 para Aplicações LLM",
          "summary": "O OWASP Top 10 para aplicações LLM é o vocabulário comum do que dá errado em sistemas construídos sobre modelos de linguagem. Não é um framework de controles e não diz o que implementar: nomeia as classes de vulnerabilidade, da injeção de prompts ao excesso de agência e ao consumo sem limite, para que times, auditores e fornecedores discutam as mesmas coisas. Seu valor prático é servir de lista de verificação sobre a sua própria arquitetura e de idioma comum em que os achados são relatados.",
          "definition": "O OWASP Top 10 para aplicações LLM é uma lista mantida pela comunidade com as classes de vulnerabilidade mais críticas em aplicações construídas sobre grandes modelos de linguagem, publicada pelo OWASP GenAI Security Project e revisada periodicamente conforme o ecossistema muda.",
          "scope": "Qualquer aplicação construída sobre um grande modelo de linguagem: interfaces de chat, sistemas de recuperação, agentes e as ferramentas que eles invocam. É voluntária, não certificável e deliberadamente descritiva: classifica riscos, não prescreve controles nem concede conformidade.",
          "keyPoints": [
            "A injeção de prompts lidera a lista desde a primeira edição e continua sendo a classe sem solução limpa: apenas contenção em camadas.",
            "A edição de 2025 cobre injeção de prompts, divulgação de informação sensível, cadeia de suprimentos, envenenamento de dados e modelo, tratamento indevido da saída, excesso de agência, vazamento do system prompt, fragilidades de vetores e embeddings, desinformação e consumo sem limite. A lista é revisada periodicamente, então consulte a edição vigente e não uma cópia em cache.",
            "Várias entradas são na prática específicas de agentes: excesso de agência e tratamento indevido da saída só ficam graves quando o modelo pode agir.",
            "É uma taxonomia, não um conjunto de controles. Mapear um achado para LLM06 diz que tipo de problema é, não o que construir.",
            "É a língua franca da área: revisões de segurança, questionários de fornecedores e relatos de falha a citam, e essa é boa parte do motivo para conhecê-la por número.",
            "Cobrir a lista não é uma postura de segurança. Cada entrada precisa de um controle na sua arquitetura, e uma entrada sem controle é um risco aceito, tenha alguém escrito isso ou não."
          ],
          "controls": [
            {
              "control": "Mapeie a lista sobre a sua própria arquitetura",
              "note": "Percorra cada entrada diante das suas entradas reais, ferramentas, armazenamentos de dados e saídas. O exercício vale mais do que a lista, porque revela as entradas que não se aplicam e as superfícies que a lista não nomeia."
            },
            {
              "control": "Atribua responsável e controle por entrada",
              "note": "Cada classe aplicável precisa de um componente concreto que a limite e de uma pessoa que o mantenha. Uma entrada mapeada para nada é uma lacuna com número de referência."
            },
            {
              "control": "Trate a injeção de prompts como contenção, não como prevenção",
              "note": "LLM01 não tem solução confiável na camada do modelo. Os controles que importam são ferramentas com privilégio mínimo, restrição de saída, tratamento da saída e portões de aprovação para ações de alto impacto."
            },
            {
              "control": "Limite a agência explicitamente",
              "note": "Para LLM06, escreva o que o agente pode fazer, com quais credenciais e contra quais alvos — e aplique isso abaixo do modelo, não no prompt."
            },
            {
              "control": "Trate a saída do modelo como entrada não confiável",
              "note": "Para LLM05, tudo o que o modelo emite e chega a um renderizador, a um shell, a uma consulta ou a outro sistema precisa da mesma codificação e validação que você aplicaria à entrada de um desconhecido."
            },
            {
              "control": "Limite o consumo",
              "note": "Para LLM10, limites de taxa, cotas e timeouts transformam um ataque de disponibilidade e custo em uma recusa registrada. É a entrada que mais se pula porque não parece segurança até a fatura chegar."
            },
            {
              "control": "Refaça o mapeamento quando a lista ou o sistema mudar",
              "note": "A lista é revisada e o seu catálogo de ferramentas cresce. Um mapeamento feito uma vez é um documento sobre um sistema que já não existe."
            }
          ],
          "checklist": [
            "Leia a edição vigente em vez de um resumo, este incluído.",
            "Produza uma tabela de mapeamento: entrada → aplica? → controle → responsável.",
            "Para cada entrada aplicável sem controle, registre-a como risco aceito, com motivo e detecção compensatória.",
            "Escreva um teste por controle e veja o teste falhar antes de confiar nele.",
            "Revise as entradas que só mordem com ferramentas: excesso de agência, tratamento indevido da saída, cadeia de suprimentos.",
            "Confirme que limites de taxa e cotas existem e devolvem sinais corretos a clientes bem-educados.",
            "Refaça o mapeamento sempre que uma ferramenta, uma fonte de dados ou um nível de autonomia mudar.",
            "Use a numeração da lista nos achados para que revisores e fornecedores falem da mesma classe."
          ],
          "pitfalls": [
            "Tratar a lista como meta de conformidade: cobrir dez títulos enquanto a arquitetura real segue sem exame.",
            "Supor que o trabalho de segurança do fornecedor do modelo cobre LLM01. Ele reduz as tentativas; as consequências continuam inteiramente suas.",
            "Mapear contra uma edição em cache. A lista é revisada, e um mapeamento antigo deixa de cobrir em silêncio as classes atuais.",
            "Pular LLM10 porque consumo sem limite parece problema de operações e não de segurança.",
            "Confundir nomear uma classe com controlá-la. Uma tabela de mapeamento impecável sem aplicação é documentação do risco, não redução dele."
          ],
          "examples": [
            "Um agente que resume e-mails de clientes mapeia para LLM01 (o corpo do e-mail é entrada de instruções não confiável), LLM02 (o resumo pode repetir dados que quem pergunta não deveria ver) e LLM06 (a ferramenta de CRM transforma o sequestro em ação): três entradas de uma única funcionalidade, cada uma com um controle diferente.",
            "Um sistema RAG sobre uma wiki interna mapeia para LLM01 por injeção indireta a partir de qualquer editor de páginas, para LLM04 se o índice puder ser envenenado e para LLM08 por recuperação que devolve documentos fora das permissões de quem pergunta.",
            "Um endpoint MCP público mapeia sobretudo para LLM10: somente leitura e dados públicos, então o limite de consumo — limites de taxa com cabeçalhos corretos — é a entrada que faz o trabalho de verdade."
          ],
          "faqs": [
            {
              "q": "É possível estar em conformidade com o OWASP LLM Top 10?",
              "a": "Não. É um documento de conscientização e classificação, não uma norma certificável. Ele combina naturalmente com um sistema de gestão como a ISO 42001 ou um framework como o NIST AI RMF, que é onde as obrigações de governança de fato vivem."
            },
            {
              "q": "Quais entradas mudam mais ao dar ferramentas ao modelo?",
              "a": "Excesso de agência e tratamento indevido da saída. Sem ferramentas produzem uma resposta errada; com ferramentas produzem uma ação, e a gravidade passa de constrangimento a incidente."
            },
            {
              "q": "Qual a relação com o MITRE ATLAS?",
              "a": "Respondem perguntas diferentes. O OWASP nomeia as classes de vulnerabilidade da sua aplicação; o ATLAS cataloga as táticas e técnicas que um adversário usa contra sistemas de IA. Uma é uma lista de verificação sobre o seu design, a outra é um mapa do manual do atacante."
            }
          ]
        },
        "fr": {
          "name": "OWASP Top 10 pour les applications LLM",
          "summary": "L'OWASP Top 10 pour les applications LLM constitue le vocabulaire partagé pour identifier les défaillances des systèmes basés sur des modèles de langage. Il ne s'agit pas d'un cadre de contrôle et il ne prescrit pas ce qu'il faut mettre en œuvre — il nomme les classes de vulnérabilités, de l'injection de requêtes (prompt injection) à la consommation illimitée (unbounded consumption) en passant par l'excès d'autonomie (excessive agency), afin que les équipes, les auditeurs et les fournisseurs parlent de la même chose. Sa valeur pratique réside dans son utilisation comme liste de contrôle pour votre propre architecture et comme langage commun pour signaler les anomalies.",
          "definition": "L'OWASP Top 10 pour les applications LLM est une liste gérée par la communauté répertoriant les classes de vulnérabilités les plus critiques dans les applications basées sur de grands modèles de langage. Elle est publiée par l'OWASP GenAI Security Project et révisée périodiquement au fil de l'évolution de l'écosystème.",
          "scope": "Toute application basée sur un grand modèle de langage — interfaces de chat, systèmes de recherche d'informations (retrieval), agents et outils qu'ils appellent. Elle est volontaire, non certifiable et délibérément descriptive : elle classifie les risques, mais ne prescrit pas de contrôles et ne confère pas de conformité.",
          "keyPoints": [
            "L'injection de requêtes (prompt injection) figure en tête de liste depuis la première édition et reste la classe pour laquelle il n'existe pas de solution miracle — seul un confinement de sécurité multicouche est possible.",
            "L'édition 2025 couvre l'injection de requêtes, la divulgation d'informations sensibles, la chaîne d'approvisionnement, l'empoisonnement des données et des modèles, la mauvaise gestion des sorties, l'excès d'autonomie, la fuite de requêtes système, les faiblesses des vecteurs et des plongements (embeddings), la désinformation et la consommation illimitée. La liste étant révisée périodiquement, veuillez consulter l'édition en vigueur plutôt que de vous fier à une version en cache.",
            "Plusieurs entrées ont un effet spécifique aux agents : l'excès d'autonomie et la mauvaise gestion des sorties ne deviennent critiques que lorsque le modèle est en mesure d'agir.",
            "Il s'agit d'une taxonomie, pas d'un ensemble de contrôles. Associer une anomalie à LLM06 indique la nature du problème, mais pas ce qu'il faut construire.",
            "C'est la lingua franca du domaine : les revues de sécurité, les questionnaires des fournisseurs et les rapports de bogues y font tous référence, ce qui explique en grande partie pourquoi il est utile de la connaître par numéro.",
            "Couvrir la liste ne constitue pas une posture de sécurité. Chaque entrée nécessite un contrôle dans votre architecture, et une entrée sans contrôle représente un risque accepté, que cela ait été formalisé par écrit ou non."
          ],
          "controls": [
            {
              "control": "Projeter la liste sur votre propre architecture",
              "note": "Confrontez chaque entrée à vos entrées, outils, bases de données et sorties réels. L'exercice a plus de valeur que la liste elle-même, car il met en évidence les entrées non applicables ainsi que les surfaces d'attaque non mentionnées par la liste."
            },
            {
              "control": "Attribuer un responsable et un contrôle par entrée",
              "note": "Chaque classe applicable nécessite un composant désigné pour la limiter et une personne pour maintenir ce composant. Une entrée non associée à un contrôle est une faille dotée d'un numéro de référence."
            },
            {
              "control": "Traiter l'injection de requêtes comme du confinement, pas de la prévention",
              "note": "LLM01 ne dispose d'aucun correctif fiable au niveau du modèle. Les contrôles essentiels sont l'outillage de moindre privilège, la restriction des flux de sortie, la gestion des sorties et les barrières d'approbation pour les actions à fort impact."
            },
            {
              "control": "Contraindre explicitement l'autonomie",
              "note": "Pour LLM06, définissez par écrit ce que l'agent est autorisé à faire, avec quels identifiants et sur quelles cibles — et appliquez ces règles en aval du modèle plutôt que dans la requête (prompt)."
            },
            {
              "control": "Traiter les sorties du modèle comme des entrées non approuvées",
              "note": "Pour LLM05, tout ce que le modèle génère et qui atteint un moteur de rendu, un interpréteur de commandes (shell), une requête ou un autre système nécessite le même encodage et la même validation que vous appliqueriez à une entrée provenant d'un tiers inconnu."
            },
            {
              "control": "Limiter la consommation",
              "note": "Pour LLM10, les limites de débit, les quotas et les délais d'expiration transforment une attaque sur la disponibilité et les coûts en un refus consigné dans les journaux. C'est l'entrée que les équipes ignorent le plus souvent, car elle ne ressemble pas à un problème de sécurité avant la réception de la facture."
            },
            {
              "control": "Relancer la projection lorsque la liste ou le système change",
              "note": "La liste est révisée et votre catalogue d'outils s'enrichit. Une projection réalisée une seule fois devient un document décrivant un système qui n'existe plus."
            }
          ],
          "checklist": [
            "Lisez l'édition en vigueur plutôt qu'un résumé — y compris celui-ci.",
            "Produisez un tableau de correspondance : entrée → s'applique ? → contrôle → responsable.",
            "Pour chaque entrée applicable sans contrôle, enregistrez-la comme un risque accepté avec un motif et une détection compensatoire.",
            "Écrivez un test pour chaque contrôle et assurez-vous que le test échoue avant de lui faire confiance.",
            "Vérifiez les entrées qui ne posent problème qu'avec des outils : excès d'autonomie, mauvaise gestion des sorties, chaîne d'approvisionnement.",
            "Confirmez que les limites de débit et les quotas existent et renvoient les signaux appropriés aux clients bien intentionnés.",
            "Relancez la projection chaque fois qu'un outil, une source de données ou un niveau d'autonomie change.",
            "Utilisez la numérotation de la liste dans les rapports d'anomalies afin que les réviseurs et les fournisseurs discutent de la même classe."
          ],
          "pitfalls": [
            "Traiter la liste comme un objectif de conformité : couvrir dix rubriques alors que l'architecture réelle reste non examinée.",
            "Supposer que le travail de sécurité d'un fournisseur de modèles couvre LLM01. Cela réduit les tentatives, mais les conséquences restent entièrement de votre responsabilité.",
            "Effectuer la projection sur une édition en cache. La liste étant révisée, une ancienne projection cesse discrètement de couvrir les classes actuelles.",
            "Ignorer LLM10 parce que la consommation illimitée ressemble à un problème d'exploitation plutôt qu'à un problème de sécurité.",
            "Confondre le fait de nommer une classe avec le fait de la contrôler. Un tableau de correspondance bien ordonné sans mise en application constitue une documentation du risque, non sa réduction."
          ],
          "examples": [
            "Un agent qui résume les e-mails des clients correspond à LLM01 (le corps de l'e-mail est une entrée d'instruction non approuvée), LLM02 (le résumé peut répéter des données que le demandeur ne devrait pas voir) et LLM06 (l'outil CRM transforme un détournement en action) — trois entrées pour une seule fonctionnalité, chacune nécessitant un contrôle différent.",
            "Un système RAG sur un wiki interne correspond à LLM01 via une injection indirecte provenant de n'importe quel éditeur de page, à LLM04 si l'index peut être empoisonné, et à LLM08 pour une recherche qui renvoie des documents en dehors des autorisations du demandeur.",
            "Un point de terminaison MCP public correspond le plus nettement à LLM10 : données publiques en lecture seule, de sorte que la limite de consommation — des limites de débit avec des en-têtes corrects — est l'entrée qui effectue le véritable travail."
          ],
          "faqs": [
            {
              "q": "Peut-on être conforme à l'OWASP LLM Top 10 ?",
              "a": "Non. Il s'agit d'un document de sensibilisation et de classification, pas d'une norme certifiable. Il s'associe naturellement à un système de gestion tel qu'ISO 42001 ou à un cadre tel que le NIST AI RMF, où résident réellement les obligations de gouvernance."
            },
            {
              "q": "Quelles entrées changent le plus lorsque vous ajoutez des outils à un modèle ?",
              "a": "L'excès d'autonomie et la mauvaise gestion des sorties. Sans outils, ils produisent une réponse erronée ; avec des outils, ils produisent une action, et la gravité passe d'une simple gêne à un incident."
            },
            {
              "q": "Quel est son lien avec MITRE ATLAS ?",
              "a": "Ils répondent à des questions différentes. L'OWASP nomme les classes de vulnérabilités de votre application ; ATLAS catalogue les tactiques et techniques qu'un adversaire utilise contre les systèmes d'IA. L'un est une liste de contrôle pour votre conception, l'autre est une carte des techniques de l'attaquant."
            }
          ]
        },
        "de": {
          "name": "OWASP Top 10 für LLM-Anwendungen",
          "summary": "Die OWASP Top 10 für LLM-Anwendungen sind das gemeinsame Vokabular für Probleme in Systemen, die auf Sprachmodellen basieren. Es handelt sich nicht um ein Kontroll-Framework und es schreibt nicht vor, was implementiert werden muss – es benennt die Schwachstellenklassen, von Prompt Injection über übermäßige Handlungsbefugnis (Excessive Agency) bis hin zu unbegrenztem Ressourcenverbrauch (Unbounded Consumption), damit Teams, Auditoren und Anbieter über dieselben Dinge sprechen können. Ihr praktischer Wert liegt in der Funktion als Checkliste für die eigene Architektur und als gemeinsame Sprache, in der Ergebnisse gemeldet werden.",
          "definition": "Die OWASP Top 10 für LLM-Anwendungen ist eine von der Community gepflegte Liste der kritischsten Schwachstellenklassen in Anwendungen, die auf großen Sprachmodellen basieren. Sie wird vom OWASP GenAI Security Project veröffentlicht und regelmäßig an Veränderungen im Ökosystem angepasst.",
          "scope": "Jede Anwendung, die auf einem großen Sprachmodell basiert – Chat-Schnittstellen, Retrieval-Systeme, Agenten und die von ihnen aufgerufenen Tools. Sie ist freiwillig, nicht zertifizierbar und bewusst deskriptiv: Sie klassifiziert Risiken, schreibt jedoch keine Kontrollen vor und gewährt keine Compliance.",
          "keyPoints": [
            "Prompt Injection führt die Liste seit der ersten Ausgabe an und bleibt die Klasse, für die es keine saubere Lösung gibt – sondern nur eine mehrschichtige Eindämmung.",
            "Die Ausgabe 2025 umfasst Prompt Injection, Offenlegung sensibler Informationen, Lieferkette, Daten- und Modell-Poisoning, unsachgemäße Ausgabebehandlung, übermäßige Handlungsbefugnis, System-Prompt-Leakage, Vektor- und Embedding-Schwächen, Fehlinformationen und unbegrenzten Ressourcenverbrauch. Die Liste wird regelmäßig überarbeitet. Prüfen Sie daher die aktuelle Ausgabe, anstatt sich auf eine veraltete Version zu verlassen.",
            "Einige Einträge wirken sich speziell auf Agenten aus: Übermäßige Handlungsbefugnis und unsachgemäße Ausgabebehandlung werden erst dann kritisch, wenn das Modell selbstständig agieren kann.",
            "Es handelt sich um eine Taxonomie, nicht um ein Kontrollset. Die Zuordnung eines Befunds zu LLM06 zeigt Ihnen, um welche Art von Problem es sich handelt, nicht aber, was Sie entwickeln müssen.",
            "Es ist die Lingua Franca des Fachbereichs: Sicherheitsüberprüfungen, Anbieterfragebögen und Bug-Reports beziehen sich alle darauf, weshalb es sich vor allem lohnt, sie namentlich und nach Nummern zu kennen.",
            "Das Abdecken der Liste stellt noch kein Sicherheitskonzept dar. Jeder Eintrag erfordert eine Sicherheitsmaßnahme (Control) in Ihrer Architektur, und ein Eintrag ohne Maßnahme ist ein akzeptiertes Risiko, unabhängig davon, ob dies schriftlich festgehalten wurde."
          ],
          "controls": [
            {
              "control": "Die Liste auf die eigene Architektur übertragen",
              "note": "Gleichen Sie jeden Eintrag mit Ihren tatsächlichen Eingaben, Tools, Datenspeichern und Ausgaben ab. Diese Übung ist wertvoller als die Liste selbst, da sie aufzeigt, welche Einträge nicht zutreffen und welche Angriffsflächen die Liste nicht nennt."
            },
            {
              "control": "Einen Verantwortlichen und eine Sicherheitsmaßnahme pro Eintrag zuweisen",
              "note": "Jede anwendbare Klasse benötigt eine definierte Komponente, die sie eingrenzt, und eine Person, die diese Komponente pflegt. Ein Eintrag ohne Zuordnung ist eine Sicherheitslücke mit einer Referenznummer."
            },
            {
              "control": "Prompt Injection als Schadensbegrenzung statt als Prävention behandeln",
              "note": "Für LLM01 gibt es keine zuverlässige Lösung auf der Modellebene. Die entscheidenden Maßnahmen sind Tools mit minimalen Rechten (Least Privilege), ausgehende Beschränkungen (Egress Restriction), Ausgabebehandlung und Freigabeprozesse für folgenschwere Aktionen."
            },
            {
              "control": "Handlungsbefugnisse explizit einschränken",
              "note": "Schreiben Sie für LLM06 auf, was der Agent mit welchen Anmeldedaten und für welche Ziele tun darf – und setzen Sie dies unterhalb der Modellebene durch, anstatt im Prompt."
            },
            {
              "control": "Modellausgaben als nicht vertrauenswürdige Eingaben behandeln",
              "note": "Für LLM05 gilt: Alles, was das Modell ausgibt und was einen Renderer, eine Shell, eine Abfrage oder ein anderes System erreicht, erfordert dieselbe Codierung und Validierung, die Sie bei Eingaben von Fremden anwenden würden."
            },
            {
              "control": "Ressourcenverbrauch begrenzen",
              "note": "Für LLM10 verwandeln Ratenbegrenzungen (Rate Limits), Quoten und Timeouts einen Angriff auf Verfügbarkeit und Kosten in eine protokollierte Verweigerung. Dies ist der Eintrag, den Teams am häufigsten überspringen, weil er erst dann wie ein Sicherheitsproblem aussieht, wenn die Rechnung eintrifft."
            },
            {
              "control": "Die Zuordnung erneut durchführen, wenn sich die Liste oder das Systemändert",
              "note": "Die Liste wird überarbeitet und Ihr Tool-Katalog wächst. Eine einmalig durchgeführte Zuordnung ist lediglich ein Dokument über ein System, das so nicht mehr existiert."
            }
          ],
          "checklist": [
            "Lesen Sie die aktuelle Ausgabe anstelle einer Zusammenfassung – einschließlich dieser hier.",
            "Erstellen Sie eine Zuordnungstabelle: Eintrag → Anwendbar? → Maßnahme → Verantwortlicher.",
            "Erfassen Sie jeden anwendbaren Eintrag ohne Maßnahme als akzeptiertes Risiko mit einer Begründung und einer kompensierenden Erkennungsmaßnahme.",
            "Schreiben Sie einen Test für jede Maßnahme und stellen Sie sicher, dass der Test fehlschlägt, bevor Sie ihm vertrauen.",
            "Prüfen Sie die Einträge, die erst im Zusammenspiel mit Tools gefährlich werden: übermäßige Handlungsbefugnis, unsachgemäße Ausgabebehandlung, Lieferkette.",
            "Stellen Sie sicher, dass Ratenbegrenzungen und Quoten existieren und korrekte Signale an ordnungsgemäß agierende Clients zurückgeben.",
            "Führen Sie die Zuordnung jedes Mal neu durch, wenn sich ein Tool, eine Datenquelle oder ein Autonomiegrad ändert.",
            "Verwenden Sie die Nummerierung der Liste in Ihren Befunden, damit Prüfer und Anbieter über dieselbe Klasse diskutieren."
          ],
          "pitfalls": [
            "Die Liste als Compliance-Ziel behandeln: Zehn Überschriften abhaken, während die tatsächliche Architektur ungeprüft bleibt.",
            "Anzunehmen, dass die Sicherheitsvorkehrungen des Modellherstellers LLM01 abdecken. Sie reduzieren zwar die Versuche, aber die Konsequenzen tragen Sie weiterhin allein.",
            "Die Zuordnung auf Basis einer veralteten Ausgabe vornehmen. Die Liste wird überarbeitet, und eine alte Zuordnung deckt aktuelle Klassen unbemerkt nicht mehr ab.",
            "LLM10 überspringen, weil unbegrenzter Ressourcenverbrauch eher wie ein Betriebsproblem als ein Sicherheitsproblem aussieht.",
            "Das Benennen einer Klasse mit deren Beherrschung verwechseln. Eine ordentliche Zuordnungstabelle ohne Durchsetzung dokumentiert das Risiko lediglich, anstatt es zu verringern."
          ],
          "examples": [
            "Ein Agent, der Kunden-E-Mails zusammenfasst, lässt sich LLM01 (der E-Mail-Text ist eine nicht vertrauenswürdige Anweisungseingabe), LLM02 (die Zusammenfassung kann Daten enthalten, die der Anforderer nicht sehen darf) und LLM06 (das CRM-Tool macht aus einer Übernahme eine Aktion) zuordnen – drei Einträge aus einer einzigen Funktion, die jeweils eine andere Sicherheitsmaßnahme erfordern.",
            "Ein RAG-System über ein internes Wiki lässt sich LLM01 über indirekte Injection durch jeden Seiteneditor, LLM04, falls der Index manipuliert (poisoned) werden kann, und LLM08 für Abfragen, die Dokumente außerhalb der Berechtigungen des Anforderers zurückgeben, zuordnen.",
            "Ein öffentlicher MCP-Endpunkt lässt sich am ehesten LLM10 zuordnen: Nur-Lese-Zugriff, öffentliche Daten, sodass die Begrenzung des Ressourcenverbrauchs – Ratenbegrenzungen mit korrekten Headern – die eigentliche Arbeit leistet."
          ],
          "faqs": [
            {
              "q": "Kann man mit den OWASP LLM Top 10 konform (compliant) sein?",
              "a": "Nein. Es ist ein Dokument zur Sensibilisierung und Klassifizierung, kein zertifizierbarer Standard. Es lässt sich ideal mit einem Managementsystem wie ISO 42001 oder einem Framework wie dem NIST AI RMF kombinieren, in denen die eigentlichen Governance-Verpflichtungen verankert sind."
            },
            {
              "q": "Welche Einträge ändern sich am meisten, wenn man einem Modell Tools hinzufügt?",
              "a": "Übermäßige Handlungsbefugnis (Excessive Agency) und unsachgemäße Ausgabebehandlung (Improper Output Handling). Ohne Tools führen sie zu einer falschen Antwort; mit Tools führen sie zu einer Aktion, und der Schweregrad verschiebt sich von einer Peinlichkeit zu einem Sicherheitsvorfall."
            },
            {
              "q": "Wie verhält es sich im Vergleich zu MITRE ATLAS?",
              "a": "Sie beantworten unterschiedliche Fragen. OWASP benennt die Schwachstellenklassen in Ihrer Anwendung; ATLAS katalogisiert die Taktiken und Techniken, die ein Angreifer gegen KI-Systeme einsetzt. Das eine ist eine Checkliste für Ihr Design, das andere eine Übersicht über das Playbook des Angreifers."
            }
          ]
        },
        "ja": {
          "name": "OWASP LLMアプリケーションのトップ10",
          "summary": "「OWASP LLMアプリケーションのトップ10」は、言語モデル上に構築されたシステムで発生する不具合に関する共通の語彙です。これは管理策フレームワークではなく、何を実装すべきかを指示するものでもありません。プロンプトインジェクションから過剰なエージェンシー、無制限の消費に至るまでの脆弱性クラスを定義することで、チーム、監査人、ベンダーが同じ前提で議論できるようにします。その実用的な価値は、自社のアーキテクチャに対するチェックリストとして、また検出事項を報告する際の共通言語として機能することにあります。",
          "definition": "「OWASP LLMアプリケーションのトップ10」は、大規模言語モデル（LLM）上に構築されたアプリケーションにおける最も重大な脆弱性クラスをコミュニティが維持管理しているリストです。OWASP GenAI Security Projectによって公開され、エコシステムの変化に応じて定期的に改訂されます。",
          "scope": "チャットインターフェース、検索システム、エージェント、およびそれらが呼び出すツールなど、大規模言語モデル上に構築されたあらゆるアプリケーションが対象です。これは自主的なものであり、認証可能な規格ではなく、意図的に記述的な性質を持っています。リスクを分類するものであり、管理策を規定したりコンプライアンスを付与したりするものではありません。",
          "keyPoints": [
            "プロンプトインジェクションは初版からリストのトップに位置しており、根本的な解決策がなく、多層的な封じ込めのみが有効なクラスであり続けています。",
            "2025年版では、プロンプトインジェクション、機密情報の漏洩、サプライチェーン、データおよびモデルのポイズニング、不適切な出力処理、過剰なエージェンシー、システムプロンプトの漏洩、ベクトルと埋め込みの脆弱性、誤情報、および無制限の消費をカバーしています。リストは定期的に改訂されるため、キャッシュされた情報を信頼するのではなく、最新版を確認してください。",
            "いくつかの項目は、実質的にエージェント特有のものです。過剰なエージェンシーや不適切な出力処理は、モデルがアクションを実行できるようになって初めて深刻化します。",
            "これは分類法（タクソノミー）であり、管理策のセットではありません。検出事項をLLM06にマッピングすることは、それがどのような問題であるかを示すものであり、何を構築すべきかを教えるものではありません。",
            "これはこの分野の共通言語です。セキュリティレビュー、ベンダーのアンケート、バグレポートのすべてがこれを参照しており、番号で把握しておく価値がある主な理由はここにあります。",
            "リストを網羅していること自体は、セキュリティポスチャ（セキュリティ態勢）ではありません。すべての項目についてアーキテクチャ内での管理策が必要であり、管理策のない項目は、文書化されているかどうかにかかわらず、受容されたリスクとなります。"
          ],
          "controls": [
            {
              "control": "リストを自社のアーキテクチャにマッピングする",
              "note": "実際の入力、ツール、データストア、出力に対して、各項目を検証します。この演習はリストそのものよりも価値があります。なぜなら、適用されない項目や、リストに記載されていない領域が明らかになるからです。"
            },
            {
              "control": "項目ごとに所有者と管理策を割り当てる",
              "note": "適用可能な各クラスには、それを制限する特定のコンポーネントと、そのコンポーネントを維持管理する担当者が必要です。何にもマッピングされていない項目は、参照番号が付いた単なるギャップにすぎません。"
            },
            {
              "control": "プロンプトインジェクションは予防ではなく封じ込めとして扱う",
              "note": "LLM01には、モデルレイヤーでの信頼できる解決策がありません。重要な管理策は、最小権限のツール設定、送信制限、出力処理、および影響の大きいアクションに対する承認ゲートです。"
            },
            {
              "control": "エージェンシーを明示的に制限する",
              "note": "LLM06については、エージェントがどの認証情報を使用して、どのターゲットに対して何を実行できるかを文書化し、プロンプト内ではなくモデルの下位レイヤーでそれを強制します。"
            },
            {
              "control": "モデルの出力を信頼できない入力として処理する",
              "note": "LLM05については、モデルが出力し、レンダラー、シェル、クエリ、または他のシステムに到達するすべてのものに対して、見知らぬ人からの入力に適用するのと同様のエンコーディングと検証を行う必要があります。"
            },
            {
              "control": "消費を制限する",
              "note": "LLM10については、レート制限、クォータ、およびタイムアウトを設定することで、可用性とコストに対する攻撃を、ログに記録された拒否応答へと変換します。これは、請求書が届くまでセキュリティ問題のように見えないため、チームが最も見落としがちな項目です。"
            },
            {
              "control": "リストまたはシステムが変更されたときにマッピングを再実行する",
              "note": "リストは改訂され、ツールのカタログは増加します。一度だけ行われたマッピングは、もはや存在しないシステムに関する文書になってしまいます。"
            }
          ],
          "checklist": [
            "要約（これを含む）ではなく、最新版を読んでください。",
            "マッピングテーブル（項目 → 適用されるか？ → 管理策 → 所有者）を作成します。",
            "管理策のないすべての適用可能な項目について、理由と代替となる検知手段を添えて、受容されたリスクとして記録します。",
            "各管理策のテストを作成し、そのテストが失敗することを確認してから信頼します。",
            "ツールを使用する場合にのみ問題となる項目（過剰なエージェンシー、不適切な出力処理、サプライチェーン）を確認します。",
            "レート制限とクォータが存在し、正常なクライアントに対して正しいシグナルを返すことを確認します。",
            "ツール、データソース、または自律性のレベルが変更されるたびに、マッピングを再実行します。",
            "レビュー担当者やベンダーが同じクラスについて議論できるように、検出事項にはリストの番号を使用します。"
          ],
          "pitfalls": [
            "リストをコンプライアンスの目標として扱うこと。実際のアーキテクチャが検証されないまま、10個の見出しを網羅するだけに終わってしまう。",
            "モデルベンダーの安全性への取り組みがLLM01をカバーしていると仮定すること。それは試行を減らすだけであり、結果に対する責任は完全に自社にあります。",
            "キャッシュされた版にマッピングすること。リストは改訂されるため、古いマッピングでは現在のクラスをいつの間にかカバーできなくなります。",
            "無制限の消費がセキュリティ問題ではなく運用の問題に見えるため、LLM10をスキップすること。",
            "クラスを命名することと、それを管理することを混同すること。強制力のない整然としたマッピングテーブルは、リスクの文書化にすぎず、リスクの軽減にはなりません。"
          ],
          "examples": [
            "顧客のメールを要約するエージェントは、LLM01（メール本文は信頼できない指示入力）、LLM02（要約に要求者が閲覧すべきでないデータが含まれる可能性がある）、およびLLM06（CRMツールが乗っ取りをアクションに変換する）にマッピングされます。これは1つの機能から生じる3つの項目であり、それぞれに異なる管理策が必要です。",
            "社内Wikiを対象とするRAGシステムは、任意のページ編集者からの間接的なインジェクションを介してLLM01に、インデックスがポイズニングされる可能性がある場合はLLM04に、要求者の権限外のドキュメントを返す検索についてはLLM08にマッピングされます。",
            "公開されているMCPエンドポイントは、LLM10に最も明確にマッピングされます。読み取り専用の公開データであるため、消費制限（正しいヘッダーを伴うレート制限）が実際に機能する項目となります。"
          ],
          "faqs": [
            {
              "q": "OWASP LLM Top 10に準拠することは可能ですか？",
              "a": "いいえ。これは啓発および分類のための文書であり、認証可能な規格ではありません。ISO 42001などの管理システムや、NIST AI RMFなどのフレームワークと組み合わせるのが自然であり、ガバナンスの義務は実際にそこに存在します。"
            },
            {
              "q": "モデルにツールを追加したときに、最も変化する項目はどれですか？",
              "a": "過剰なエージェンシーと不適切な出力処理です。ツールがない場合、これらは誤った回答を生成するだけですが、ツールがある場合はアクションを実行するため、深刻度は単なる当惑からインシデントへと移行します。"
            },
            {
              "q": "MITRE ATLASとはどのような関係がありますか？",
              "a": "これらは異なる疑問に答えるものです。OWASPはアプリケーションにおける脆弱性クラスを定義し、ATLASは攻撃者がAIシステムに対して使用する戦術と技術をカタログ化しています。一方は設計に対するチェックリストであり、他方は攻撃者のプレイブックのマップです。"
            }
          ]
        },
        "zh": {
          "name": "OWASP LLM 应用十大安全漏洞",
          "summary": "OWASP LLM 应用十大安全漏洞是针对基于语言模型构建的系统中可能出现的问题的通用词汇表。它不是一个控制框架，也不会告诉你应该实现什么——它命名了漏洞类别，从提示词注入、过度授权到无限制消耗，以便团队、审计人员和供应商能够基于相同的概念进行讨论。它的实用价值在于作为您自身架构的核对清单，以及作为报告发现问题时的通用语言。",
          "definition": "OWASP LLM 应用十大安全漏洞是由社区维护的、基于大语言模型构建的应用中最关键的漏洞类别清单，由 OWASP GenAI 安全项目发布，并随着生态系统的变化定期修订。",
          "scope": "任何基于大语言模型构建的应用——聊天界面、检索系统、智能体及其调用的工具。它是自愿性的、不可认证的，且刻意采用描述性方式：它对风险进行分类，而不规定控制措施或授予合规性。",
          "keyPoints": [
            "自第一版以来，提示词注入一直位居榜首，并且仍然是唯一没有彻底解决方案的类别——只能进行分层遏制。",
            "2025 版涵盖了提示词注入、敏感信息泄露、供应链、数据和模型投毒、不当输出处理、过度授权、系统提示词泄露、向量和嵌入缺陷、虚假信息以及无限制消耗。该清单会定期修订，因此请查看当前版本，而不要信任缓存的版本。",
            "有几项在效果上是针对智能体特有的：只有当模型能够执行操作时，过度授权和不当输出处理才会变得严重。",
            "它是一个分类法，而不是控制集。将发现的问题映射到 LLM06 只能告诉你这是哪类问题，而不能告诉你该构建什么。",
            "它是该领域的通用语言：安全审查、供应商问卷和漏洞报告都会引用它，这也是为什么按编号了解它非常有价值的主要原因。",
            "覆盖该清单并不等同于具备安全态势。您架构中的每一项都需要一个控制措施，而没有任何控制措施的项目就是已接受的风险，无论是否有人将其记录下来。"
          ],
          "controls": [
            {
              "control": "将清单映射到您自己的架构中",
              "note": "对照您实际的输入、工具、数据存储和输出逐一检查每一项。这种练习的价值远超清单本身，因为它能显现出不适用的项目以及清单中未提及的暴露面。"
            },
            {
              "control": "为每项分配一个所有者和控制措施",
              "note": "每个适用的类别都需要一个命名的组件来对其进行限制，并需要一个人来维护该组件。未映射到任何内容的项就是一个带有参考编号的空白漏洞。"
            },
            {
              "control": "将提示词注入视为遏制，而非预防",
              "note": "LLM01 在模型层没有可靠的修复方法。真正起作用的控制措施是最小权限工具、出口限制、输出处理以及高影响操作的审批关卡。"
            },
            {
              "control": "显式约束代理权限",
              "note": "对于 LLM06，写下智能体可以做什么、使用哪些凭据、针对哪些目标——并在模型之下（而非提示词中）强制执行。"
            },
            {
              "control": "将模型输出视为不可信的输入",
              "note": "对于 LLM05，模型输出的任何到达渲染器、Shell、查询或其他系统的内容，都需要进行与对待陌生人输入相同的编码和验证。"
            },
            {
              "control": "限制消耗",
              "note": "对于 LLM10，速率限制、配额和超时可以将可用性和成本攻击转变为已记录的拒绝服务。这是团队最常跳过的项目，因为在账单寄到之前，它看起来不像是安全问题。"
            },
            {
              "control": "当清单或系统发生变化时，重新运行映射",
              "note": "清单会修订，您的工具目录也会增加。只做一次的映射只是一份关于已不存在的系统的文档。"
            }
          ],
          "checklist": [
            "阅读当前版本，而不是摘要——包括本摘要。",
            "制作一个映射表：项目 → 是否适用？ → 控制措施 → 所有者。",
            "对于每个适用但没有控制措施的项目，将其记录为已接受的风险，并注明原因和补偿性检测措施。",
            "为每个控制措施编写测试，并在信任它之前先看到测试失败。",
            "检查只有在使用工具时才会产生危害的项目：过度授权、不当输出处理、供应链。",
            "确认存在速率限制 and 配额，并向行为良好的客户端返回正确的信号。",
            "每当工具、数据源或自主性级别发生变化时，重新运行映射。",
            "在发现的问题中使用清单的编号，以便评审人员和供应商讨论的是同一个类别。"
          ],
          "pitfalls": [
            "将清单视为合规目标：涵盖了十个标题，而实际架构却未经过审查。",
            "假设模型供应商的安全工作涵盖了 LLM01。它只是减少了尝试；后果仍然完全由您承担。",
            "映射到缓存的版本。清单会修订，旧的映射会悄然停止覆盖当前的类别。",
            "跳过 LLM10，因为无限制消耗看起来像是一个运维问题，而不是安全问题。",
            "混淆了命名类别与控制类别。一个没有执行力的整洁映射表只是对风险的记录，而不是对风险的降低。"
          ],
          "examples": [
            "一个总结客户电子邮件的智能体映射到 LLM01（邮件正文是不可信的指令输入）、LLM02（摘要可能会重复请求者不应看到的数据）和 LLM06（CRM 工具将劫持转化为操作）——一个功能中的三个项目，每个都需要不同的控制措施。",
            "一个针对内部 Wiki 的 RAG 系统通过任何页面编辑器的间接注入映射到 LLM01，如果索引可能被投毒则映射到 LLM04，以及因检索返回超出请求者权限的文档而映射到 LLM08。",
            "一个公开的 MCP 端点最明显地映射到 LLM10：只读、公开数据，因此消耗限制（带有正确标头的速率限制）是真正起作用的项目。"
          ],
          "faqs": [
            {
              "q": "OWASP LLM Top 10 是可以实现合规的东西吗？",
              "a": "不是。它是一个认知和分类文档，而不是一个可认证的标准。它自然地与诸如 ISO 42001 之类的管理系统或诸如 NIST AI RMF 之类的框架相配合，而这才是治理义务真正存在的地方。"
            },
            {
              "q": "当您向模型添加工具时，哪些项目变化最大？",
              "a": "过度授权和不当输出处理。在没有工具的情况下，它们会产生错误答案；在使用工具的情况下，它们会产生操作，严重程度也从尴尬转变为安全事件。"
            },
            {
              "q": "它与 MITRE ATLAS 有何关系？",
              "a": "它们回答了不同的问题。OWASP 命名了您应用中的漏洞类别；ATLAS 则对对手针对 AI 系统使用的战术和技术进行了分类。一个是针对您设计的核对清单，另一个是攻击者战术手册的映射。"
            }
          ]
        }
      }
    },
    {
      "id": "GOV-009",
      "slug": "mitre-atlas",
      "category": "framework",
      "updated": "2026-08-22",
      "version": "1.0",
      "url": "https://santismm.com/en/governance/mitre-atlas",
      "api": "https://santismm.com/api/governance/mitre-atlas",
      "canonical_url": "https://santismm.com/en/governance/mitre-atlas",
      "api_url": "https://santismm.com/api/governance/mitre-atlas",
      "evidence": {
        "evidenceLevel": "industry_observation",
        "confidenceLevel": "high",
        "sourceType": [
          "paper",
          "industry_observation"
        ]
      },
      "frameworks": [
        "MITRE ATLAS",
        "MITRE ATT&CK",
        "OWASP GenAI Security Project",
        "NIST AI RMF"
      ],
      "patterns": [
        "least-privilege-tooling",
        "egress-allowlist",
        "sandboxed-execution"
      ],
      "knowledge": [
        "agentic-threat-model",
        "ai-cyberdefense",
        "prompt-injection",
        "mcp-security",
        "ai-observability"
      ],
      "references": [
        {
          "title": "MITRE ATLAS — Adversarial Threat Landscape for AI Systems",
          "url": "https://atlas.mitre.org/"
        },
        {
          "title": "OWASP — Top 10 for LLM Applications",
          "url": "https://genai.owasp.org/llm-top-10/"
        },
        {
          "title": "NIST — AI Risk Management Framework (AI RMF 1.0)",
          "url": "https://www.nist.gov/itl/ai-risk-management-framework"
        }
      ],
      "related": [
        "owasp-llm-top10",
        "nist-ai-rmf",
        "audit-framework-for-agentic-systems",
        "agentic-ai-governance-checklist"
      ],
      "locales": {
        "en": {
          "name": "MITRE ATLAS",
          "summary": "MITRE ATLAS is the adversary's side of the map. Where OWASP names the vulnerability classes in your application, ATLAS catalogues the tactics and techniques attackers actually use against AI-enabled systems — reconnaissance of a model, gaining access to it, staging an attack, evading defences, exfiltrating data — organised the way MITRE ATT&CK organises conventional intrusions, and grounded in documented case studies rather than hypotheses.",
          "definition": "MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is a publicly available knowledge base of adversary tactics, techniques and case studies observed against AI-enabled systems, structured after MITRE ATT&CK so that AI-specific attacks can be described in the same terms as the rest of an organisation's threat intelligence.",
          "scope": "Any organisation that builds, deploys or defends AI-enabled systems, and any security team that already speaks ATT&CK. It is a knowledge base, not a standard: nothing certifies against it, and it prescribes no controls — it describes what adversaries do so defenders can decide what to detect and prevent.",
          "keyPoints": [
            "Structured as tactics (the adversary's goal) and techniques (how it is achieved), deliberately mirroring MITRE ATT&CK so AI attacks slot into existing threat models rather than sitting beside them.",
            "It spans the whole intrusion arc — reconnaissance, access to the model, execution, persistence, defence evasion, discovery, collection, exfiltration, impact — with AI-specific stages such as staging an attack against a model.",
            "It is evidence-led: entries are grounded in documented incidents and red-team exercises, which is what separates it from a list of things that could theoretically go wrong.",
            "It complements OWASP rather than competing with it. OWASP classifies weaknesses in your design; ATLAS describes the adversary behaviour that exploits them.",
            "Its practical value is detection and red-teaming: a technique is a thing you can attempt against your own system and a thing you can look for in your logs.",
            "The matrix is maintained and extended as new attacks are documented, so it is a living reference and not a fixed checklist."
          ],
          "controls": [
            {
              "control": "Map your agent stack onto the matrix",
              "note": "Walk the tactics against your own architecture and mark which techniques are reachable. Reachability, not plausibility, is what makes a technique worth defending against."
            },
            {
              "control": "Turn reachable techniques into detections",
              "note": "For each one, name the signal that would show it in your telemetry. A technique with no corresponding signal is one you have decided not to notice."
            },
            {
              "control": "Use it as the red-team backlog",
              "note": "Techniques are testable by construction. Run them against your own system and treat 'we could not reproduce it' as a result worth recording, not as an absence of work."
            },
            {
              "control": "Speak ATT&CK where the organisation already does",
              "note": "Report AI findings in ATLAS terms so they enter the same intelligence, triage and response processes as everything else. Novel vocabulary is how AI risk ends up owned by nobody."
            },
            {
              "control": "Read the case studies, not only the matrix",
              "note": "The case studies carry the operational detail — how access was obtained, what the adversary did next — which is the part that transfers to your own environment."
            },
            {
              "control": "Feed it back into the threat model",
              "note": "ATLAS is the external input to an agentic threat model; the threat model is where its techniques become surfaces you own, with controls and owners attached."
            }
          ],
          "checklist": [
            "Identify which ATLAS tactics are reachable in your architecture at all.",
            "For each reachable technique, record the control that bounds it and the signal that detects it.",
            "Where there is no detection, say so explicitly rather than leaving the row blank.",
            "Schedule red-team exercises drawn from the matrix, and see each attempt fail or succeed before claiming coverage.",
            "Report findings using ATLAS identifiers so they join the organisation's existing intelligence flow.",
            "Review the matrix periodically, since new techniques are documented as they are observed.",
            "Cross-reference with the OWASP LLM Top 10 so weaknesses and adversary behaviour are mapped to each other, not tracked separately."
          ],
          "pitfalls": [
            "Treating it as a compliance checklist. Nothing certifies against ATLAS, and 'we reviewed the matrix' is not a control.",
            "Mapping every technique regardless of reachability, which produces a large document and no priorities.",
            "Keeping AI threat intelligence in a separate process from the organisation's existing one — the exact outcome ATT&CK alignment exists to prevent.",
            "Reading the matrix and skipping the case studies, which is where the transferable operational detail lives.",
            "Assuming coverage without testing. A technique you have never attempted against your own system is a technique you have an opinion about."
          ],
          "examples": [
            "A team maps its retrieval agent onto ATLAS and finds that model access is trivial (the endpoint is public), staging is cheap (any wiki editor can plant content) and exfiltration has no control (egress is unrestricted). Three techniques, one of which they were already worrying about.",
            "A security organisation that already runs ATT&CK-based detection engineering adds ATLAS techniques to the same backlog, so AI-specific detections are built, reviewed and on-call'd by the team that does that work.",
            "A red team uses the matrix as its target list for an agent assessment, and reports back in ATLAS identifiers — which lets the finding be triaged by people who have never worked on an agent."
          ],
          "faqs": [
            {
              "q": "Is ATLAS a replacement for ATT&CK?",
              "a": "No, it is a companion. ATT&CK covers conventional adversary behaviour; ATLAS covers the AI-specific stages, deliberately structured the same way so an attack that starts with a phishing email and ends at a model is describable end to end."
            },
            {
              "q": "Do I need ATLAS if I already follow the OWASP LLM Top 10?",
              "a": "They serve different purposes and the pairing is the point. OWASP tells you what class of weakness you have; ATLAS tells you what an adversary does with it, which is what detection and red-teaming actually need."
            },
            {
              "q": "Where does it fit for a small team?",
              "a": "As a red-team backlog first. Even without a detection programme, the matrix gives a prioritised list of attacks to attempt against your own system — and attempting them is the cheapest way to find out which of your controls exist only on paper."
            }
          ]
        },
        "es": {
          "name": "MITRE ATLAS",
          "summary": "MITRE ATLAS es el mapa visto desde el lado del adversario. Donde OWASP nombra las clases de vulnerabilidad de tu aplicación, ATLAS cataloga las tácticas y técnicas que los atacantes usan de verdad contra sistemas con IA —reconocer un modelo, ganar acceso a él, preparar el ataque, evadir defensas, exfiltrar datos—, organizadas como MITRE ATT&CK organiza las intrusiones convencionales y ancladas en casos documentados, no en hipótesis.",
          "definition": "MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) es una base de conocimiento pública de tácticas, técnicas y casos de estudio de adversarios observados contra sistemas con IA, estructurada siguiendo a MITRE ATT&CK para que los ataques específicos de IA se puedan describir en los mismos términos que el resto de la inteligencia de amenazas de una organización.",
          "scope": "Cualquier organización que construya, despliegue o defienda sistemas con IA, y cualquier equipo de seguridad que ya hable ATT&CK. Es una base de conocimiento, no una norma: nada certifica contra ella y no prescribe controles; describe lo que hacen los adversarios para que quien defiende decida qué detectar y qué prevenir.",
          "keyPoints": [
            "Estructurada en tácticas (el objetivo del adversario) y técnicas (cómo se logra), reflejando deliberadamente a MITRE ATT&CK para que los ataques de IA encajen en los modelos de amenaza existentes en lugar de vivir al lado.",
            "Cubre todo el arco de la intrusión —reconocimiento, acceso al modelo, ejecución, persistencia, evasión de defensas, descubrimiento, recolección, exfiltración, impacto— con etapas específicas de IA como la preparación de un ataque contra un modelo.",
            "Está guiada por evidencia: las entradas se apoyan en incidentes documentados y ejercicios de red team, que es lo que la separa de una lista de cosas que teóricamente podrían salir mal.",
            "Complementa a OWASP en lugar de competir con ella. OWASP clasifica debilidades de tu diseño; ATLAS describe el comportamiento adversario que las explota.",
            "Su valor práctico está en la detección y el red team: una técnica es algo que puedes intentar contra tu propio sistema y algo que puedes buscar en tus logs.",
            "La matriz se mantiene y amplía conforme se documentan ataques nuevos, así que es una referencia viva y no una lista de comprobación fija."
          ],
          "controls": [
            {
              "control": "Mapea tu pila agéntica sobre la matriz",
              "note": "Recorre las tácticas frente a tu arquitectura y marca qué técnicas son alcanzables. Lo que hace que merezca la pena defender una técnica es su alcanzabilidad, no su plausibilidad."
            },
            {
              "control": "Convierte las técnicas alcanzables en detecciones",
              "note": "Para cada una, nombra la señal que la mostraría en tu telemetría. Una técnica sin señal correspondiente es una que has decidido no ver."
            },
            {
              "control": "Úsala como backlog del red team",
              "note": "Las técnicas son comprobables por construcción. Ejecútalas contra tu propio sistema y trata «no pudimos reproducirlo» como un resultado que merece registrarse, no como ausencia de trabajo."
            },
            {
              "control": "Habla ATT&CK donde la organización ya lo habla",
              "note": "Reporta hallazgos de IA en términos de ATLAS para que entren en los mismos procesos de inteligencia, triaje y respuesta que todo lo demás. El vocabulario nuevo es la vía por la que el riesgo de IA acaba sin dueño."
            },
            {
              "control": "Lee los casos de estudio, no solo la matriz",
              "note": "Los casos llevan el detalle operativo —cómo se obtuvo el acceso, qué hizo el adversario después—, que es la parte que se traslada a tu propio entorno."
            },
            {
              "control": "Devuélvela al modelo de amenazas",
              "note": "ATLAS es la entrada externa a un modelo de amenazas agéntico; el modelo es donde sus técnicas se convierten en superficies tuyas, con controles y responsables asociados."
            }
          ],
          "checklist": [
            "Identifica qué tácticas de ATLAS son siquiera alcanzables en tu arquitectura.",
            "Para cada técnica alcanzable, registra el control que la acota y la señal que la detecta.",
            "Donde no haya detección, dilo explícitamente en lugar de dejar la fila en blanco.",
            "Programa ejercicios de red team sacados de la matriz y ve fallar o triunfar cada intento antes de afirmar cobertura.",
            "Reporta los hallazgos con identificadores de ATLAS para que entren en el flujo de inteligencia existente de la organización.",
            "Revisa la matriz periódicamente, porque se documentan técnicas nuevas conforme se observan.",
            "Cruza con el OWASP LLM Top 10 para que debilidades y comportamiento adversario queden mapeados entre sí y no en registros separados."
          ],
          "pitfalls": [
            "Tratarla como lista de cumplimiento. Nada certifica contra ATLAS, y «revisamos la matriz» no es un control.",
            "Mapear todas las técnicas sin importar su alcanzabilidad, lo que produce un documento grande y ninguna prioridad.",
            "Mantener la inteligencia de amenazas de IA en un proceso aparte del que ya tiene la organización: justo el resultado que la alineación con ATT&CK existe para evitar.",
            "Leer la matriz y saltarse los casos de estudio, que es donde vive el detalle operativo trasladable.",
            "Suponer cobertura sin probar. Una técnica que nunca has intentado contra tu propio sistema es una técnica sobre la que tienes una opinión."
          ],
          "examples": [
            "Un equipo mapea su agente de recuperación sobre ATLAS y descubre que el acceso al modelo es trivial (el endpoint es público), la preparación es barata (cualquier editor de la wiki puede plantar contenido) y la exfiltración no tiene control (la salida no está restringida). Tres técnicas, y solo una les preocupaba ya.",
            "Una organización de seguridad que ya hace ingeniería de detección basada en ATT&CK añade técnicas de ATLAS al mismo backlog, de modo que las detecciones específicas de IA las construye, revisa y guardia el equipo que hace ese trabajo.",
            "Un red team usa la matriz como lista de objetivos para evaluar un agente y reporta con identificadores de ATLAS, lo que permite triar el hallazgo a gente que nunca ha trabajado con agentes."
          ],
          "faqs": [
            {
              "q": "¿ATLAS sustituye a ATT&CK?",
              "a": "No, es su compañera. ATT&CK cubre el comportamiento adversario convencional; ATLAS cubre las etapas específicas de IA, estructuradas igual a propósito para que un ataque que empieza con un correo de phishing y termina en un modelo se pueda describir de punta a punta."
            },
            {
              "q": "¿Necesito ATLAS si ya sigo el OWASP LLM Top 10?",
              "a": "Sirven a propósitos distintos y la combinación es justo el punto. OWASP te dice qué clase de debilidad tienes; ATLAS te dice qué hace un adversario con ella, que es lo que de verdad necesitan la detección y el red team."
            },
            {
              "q": "¿Por dónde encaja para un equipo pequeño?",
              "a": "Primero como backlog de red team. Incluso sin un programa de detección, la matriz da una lista priorizada de ataques que intentar contra tu propio sistema, e intentarlos es la forma más barata de descubrir cuáles de tus controles solo existen sobre el papel."
            }
          ]
        },
        "pt": {
          "name": "MITRE ATLAS",
          "summary": "O MITRE ATLAS é o mapa visto do lado do adversário. Onde o OWASP nomeia as classes de vulnerabilidade da sua aplicação, o ATLAS cataloga as táticas e técnicas que atacantes de fato usam contra sistemas com IA — reconhecer um modelo, obter acesso a ele, preparar o ataque, evadir defesas, exfiltrar dados —, organizadas como o MITRE ATT&CK organiza as intrusões convencionais e ancoradas em casos documentados, não em hipóteses.",
          "definition": "O MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) é uma base de conhecimento pública de táticas, técnicas e estudos de caso de adversários observados contra sistemas com IA, estruturada segundo o MITRE ATT&CK para que ataques específicos de IA possam ser descritos nos mesmos termos que o restante da inteligência de ameaças de uma organização.",
          "scope": "Qualquer organização que construa, implante ou defenda sistemas com IA, e qualquer time de segurança que já fale ATT&CK. É uma base de conhecimento, não uma norma: nada certifica contra ela e ela não prescreve controles; descreve o que os adversários fazem para que quem defende decida o que detectar e o que prevenir.",
          "keyPoints": [
            "Estruturado em táticas (o objetivo do adversário) e técnicas (como se alcança), espelhando deliberadamente o MITRE ATT&CK para que os ataques de IA encaixem nos modelos de ameaça existentes em vez de ficarem ao lado deles.",
            "Cobre todo o arco da intrusão — reconhecimento, acesso ao modelo, execução, persistência, evasão de defesas, descoberta, coleta, exfiltração, impacto — com estágios específicos de IA, como a preparação de um ataque contra um modelo.",
            "É guiado por evidência: as entradas se apoiam em incidentes documentados e exercícios de red team, o que o separa de uma lista de coisas que teoricamente poderiam dar errado.",
            "Complementa o OWASP em vez de competir com ele. O OWASP classifica fragilidades do seu design; o ATLAS descreve o comportamento adversário que as explora.",
            "Seu valor prático está na detecção e no red team: uma técnica é algo que você pode tentar contra o próprio sistema e algo que pode procurar nos seus logs.",
            "A matriz é mantida e ampliada conforme novos ataques são documentados, então é uma referência viva e não uma lista de verificação fixa."
          ],
          "controls": [
            {
              "control": "Mapeie a sua pilha agêntica sobre a matriz",
              "note": "Percorra as táticas diante da sua arquitetura e marque quais técnicas são alcançáveis. O que torna uma técnica digna de defesa é a alcançabilidade, não a plausibilidade."
            },
            {
              "control": "Transforme técnicas alcançáveis em detecções",
              "note": "Para cada uma, nomeie o sinal que a mostraria na sua telemetria. Uma técnica sem sinal correspondente é uma que você decidiu não enxergar."
            },
            {
              "control": "Use-a como backlog do red team",
              "note": "As técnicas são testáveis por construção. Execute-as contra o seu próprio sistema e trate “não conseguimos reproduzir” como um resultado que vale registrar, não como ausência de trabalho."
            },
            {
              "control": "Fale ATT&CK onde a organização já fala",
              "note": "Relate achados de IA em termos de ATLAS para que entrem nos mesmos processos de inteligência, triagem e resposta que todo o resto. Vocabulário novo é como o risco de IA acaba sem dono."
            },
            {
              "control": "Leia os estudos de caso, não só a matriz",
              "note": "Os casos carregam o detalhe operacional — como o acesso foi obtido, o que o adversário fez em seguida —, que é a parte que se transfere para o seu ambiente."
            },
            {
              "control": "Devolva ao modelo de ameaças",
              "note": "O ATLAS é a entrada externa de um modelo de ameaças agêntico; o modelo é onde as técnicas dele viram superfícies suas, com controles e responsáveis associados."
            }
          ],
          "checklist": [
            "Identifique quais táticas do ATLAS são sequer alcançáveis na sua arquitetura.",
            "Para cada técnica alcançável, registre o controle que a limita e o sinal que a detecta.",
            "Onde não houver detecção, diga isso explicitamente em vez de deixar a linha em branco.",
            "Agende exercícios de red team tirados da matriz e veja cada tentativa falhar ou ter êxito antes de alegar cobertura.",
            "Relate os achados com identificadores do ATLAS para que entrem no fluxo de inteligência já existente.",
            "Revise a matriz periodicamente, pois novas técnicas são documentadas conforme observadas.",
            "Cruze com o OWASP Top 10 para LLM para que fragilidades e comportamento adversário fiquem mapeados entre si, e não em registros separados."
          ],
          "pitfalls": [
            "Tratá-lo como lista de conformidade. Nada certifica contra o ATLAS, e “revisamos a matriz” não é um controle.",
            "Mapear todas as técnicas independentemente da alcançabilidade, o que produz um documento grande e nenhuma prioridade.",
            "Manter a inteligência de ameaças de IA num processo separado do que a organização já tem — exatamente o resultado que o alinhamento com ATT&CK existe para evitar.",
            "Ler a matriz e pular os estudos de caso, que é onde mora o detalhe operacional transferível.",
            "Supor cobertura sem testar. Uma técnica que você nunca tentou contra o próprio sistema é uma técnica sobre a qual você tem uma opinião."
          ],
          "examples": [
            "Um time mapeia seu agente de recuperação no ATLAS e descobre que o acesso ao modelo é trivial (o endpoint é público), a preparação é barata (qualquer editor da wiki pode plantar conteúdo) e a exfiltração não tem controle (a saída é irrestrita). Três técnicas, e apenas uma já preocupava.",
            "Uma organização de segurança que já faz engenharia de detecção baseada em ATT&CK acrescenta técnicas do ATLAS ao mesmo backlog, de modo que as detecções específicas de IA são construídas, revisadas e plantonadas pelo time que faz esse trabalho.",
            "Um red team usa a matriz como lista de alvos para avaliar um agente e relata com identificadores do ATLAS, o que permite triar o achado por pessoas que nunca trabalharam com agentes."
          ],
          "faqs": [
            {
              "q": "O ATLAS substitui o ATT&CK?",
              "a": "Não, é um companheiro. O ATT&CK cobre o comportamento adversário convencional; o ATLAS cobre os estágios específicos de IA, estruturados da mesma forma de propósito para que um ataque que começa com um e-mail de phishing e termina em um modelo seja descritível de ponta a ponta."
            },
            {
              "q": "Preciso do ATLAS se já sigo o OWASP Top 10 para LLM?",
              "a": "Eles servem a propósitos diferentes, e a combinação é justamente o ponto. O OWASP diz que classe de fragilidade você tem; o ATLAS diz o que um adversário faz com ela, que é o que detecção e red team de fato precisam."
            },
            {
              "q": "Onde ele encaixa para um time pequeno?",
              "a": "Primeiro como backlog de red team. Mesmo sem um programa de detecção, a matriz dá uma lista priorizada de ataques a tentar contra o próprio sistema — e tentá-los é a forma mais barata de descobrir quais dos seus controles só existem no papel."
            }
          ]
        },
        "fr": {
          "name": "MITRE ATLAS",
          "summary": "MITRE ATLAS représente le côté adverse de la carte. Là où OWASP nomme les classes de vulnérabilités de votre application, ATLAS répertorie les tactiques et techniques que les attaquants utilisent réellement contre les systèmes basés sur l'IA — reconnaissance d'un modèle, obtention d'accès, préparation d'une attaque, contournement des défenses, exfiltration de données — organisées de la même manière que MITRE ATT&CK structure les intrusions conventionnelles, et fondées sur des études de cas documentées plutôt que sur des hypothèses.",
          "definition": "MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) est une base de connaissances publique répertoriant les tactiques, techniques et études de cas d'adversaires observées contre les systèmes basés sur l'IA. Elle est structurée selon le modèle MITRE ATT&CK afin que les attaques spécifiques à l'IA puissent être décrites dans les mêmes termes que le reste du renseignement sur les menaces de l'organisation.",
          "scope": "Toute organisation qui conçoit, déploie ou défend des systèmes basés sur l'IA, et toute équipe de sécurité qui maîtrise déjà ATT&CK. Il s'agit d'une base de connaissances et non d'une norme : elle ne donne lieu à aucune certification et ne prescrit aucun contrôle — elle décrit les actions des adversaires afin que les défenseurs puissent décider quoi détecter et prévenir.",
          "keyPoints": [
            "Structuré sous forme de tactiques (l'objectif de l'adversaire) et de techniques (la manière d'y parvenir), reflétant délibérément MITRE ATT&CK pour que les attaques d'IA s'intègrent dans les modèles de menaces existants plutôt que de s'ajouter à côté.",
            "Il couvre l'ensemble du cycle d'intrusion — reconnaissance, accès au modèle, exécution, persistance, contournement des défenses, découverte, collecte, exfiltration, impact — avec des étapes spécifiques à l'IA comme la préparation d'une attaque contre un modèle.",
            "Il est basé sur des preuves : les entrées s'appuient sur des incidents documentés et des exercices de red-teaming, ce qui le distingue d'une simple liste de problèmes théoriques.",
            "Il complète OWASP plutôt que de le concurrencer. OWASP classifie les faiblesses de votre conception ; ATLAS décrit le comportement de l'adversaire qui les exploite.",
            "Sa valeur pratique réside dans la détection et le red-teaming : une technique est à la fois une action que vous pouvez tester contre votre propre système et un signal que vous pouvez rechercher dans vos journaux.",
            "La matrice est mise à jour et enrichie à mesure que de nouvelles attaques sont documentées, ce qui en fait une référence vivante et non une liste de contrôle figée."
          ],
          "controls": [
            {
              "control": "Cartographier votre pile d'agents sur la matrice",
              "note": "Parcourez les tactiques au regard de votre propre architecture et identifiez les techniques accessibles. C'est l'accessibilité, et non la plausibilité, qui détermine si une technique mérite d'être contrée."
            },
            {
              "control": "Transformer les techniques accessibles en détections",
              "note": "Pour chacune d'elles, identifiez le signal qui la révélerait dans votre télémétrie. Une technique sans signal correspondant est une technique que vous avez choisi d'ignorer."
            },
            {
              "control": "L'utiliser comme backlog de red-team",
              "note": "Les techniques sont testables par définition. Exécutez-les contre votre propre système et considérez le résultat « impossible à reproduire » comme une information digne d'être enregistrée, et non comme une absence de travail."
            },
            {
              "control": "Utiliser le langage ATT&CK là où l'organisation l'emploie déjà",
              "note": "Rapportez les vulnérabilités d'IA selon la terminologie ATLAS afin qu'elles intègrent les mêmes processus de renseignement, de tri et de réponse que le reste. L'introduction d'un nouveau vocabulaire est le meilleur moyen pour que le risque lié à l'IA ne soit géré par personne."
            },
            {
              "control": "Lire les études de cas, pas seulement la matrice",
              "note": "Les études de cas contiennent les détails opérationnels — comment l'accès a été obtenu, ce que l'adversaire a fait ensuite — qui sont transposables à votre propre environnement."
            },
            {
              "control": "Réintégrer les données dans le modèle de menaces",
              "note": "ATLAS constitue l'apport externe d'un modèle de menaces basé sur des agents ; c'est au sein de ce modèle que ses techniques se traduisent en surfaces d'attaque sous votre responsabilité, associées à des contrôles et des responsables."
            }
          ],
          "checklist": [
            "Identifier quelles tactiques ATLAS sont effectivement accessibles au sein de votre architecture.",
            "Pour chaque technique accessible, enregistrer le contrôle qui la limite et le signal qui la détecte.",
            "En l'absence de détection, mentionnez-le explicitement plutôt que de laisser la ligne vide.",
            "Planifier des exercices de red-teaming basés sur la matrice, et constater l'échec ou la réussite de chaque tentative avant de revendiquer une couverture.",
            "Rapporter les résultats en utilisant les identifiants ATLAS afin qu'ils s'intègrent au flux de renseignement existant de l'organisation.",
            "Examiner périodiquement la matrice, car de nouvelles techniques sont documentées au fur et à mesure de leur observation.",
            "Établir des correspondances avec le Top 10 OWASP pour les LLM afin de lier les faiblesses aux comportements des adversaires, plutôt que de les suivre séparément."
          ],
          "pitfalls": [
            "Le traiter comme une liste de contrôle de conformité. Rien ne certifie la conformité à ATLAS, et « nous avons examiné la matrice » ne constitue pas un contrôle.",
            "Cartographier chaque technique sans tenir compte de son accessibilité, ce qui produit un document volumineux sans priorités.",
            "Maintenir le renseignement sur les menaces d'IA dans un processus distinct de celui existant dans l'organisation — précisément ce que l'alignement avec ATT&CK cherche à éviter.",
            "Lire la matrice en ignorant les études de cas, alors que c'est là que résident les détails opérationnels transposables.",
            "Présumer d'une couverture sans test préalable. Une technique que vous n'avez jamais tentée contre votre propre système reste une simple hypothèse."
          ],
          "examples": [
            "Une équipe cartographie son agent de retrieval sur ATLAS et constate que l'accès au modèle est trivial (le point de terminaison est public), la préparation est peu coûteuse (n'importe quel éditeur de wiki peut injecter du contenu) et l'exfiltration ne fait l'objet d'aucun contrôle (les flux sortants sont illimités). Trois techniques, dont une seule les préoccupait déjà.",
            "Une organisation de sécurité qui pratique déjà l'ingénierie de détection basée sur ATT&CK ajoute les techniques ATLAS au même backlog, de sorte que les détections spécifiques à l'IA soient conçues, révisées et gérées en astreinte par l'équipe dédiée à cette tâche.",
            "Une équipe de red-teaming utilise la matrice comme liste de cibles pour l'évaluation d'un agent, et transmet ses résultats avec les identifiants ATLAS — ce qui permet aux personnes n'ayant jamais travaillé sur un agent de trier les vulnérabilités."
          ],
          "faqs": [
            {
              "q": "ATLAS remplace-t-il ATT&CK ?",
              "a": "Non, c'est un complément. ATT&CK couvre les comportements conventionnels des adversaires ; ATLAS couvre les étapes spécifiques à l'IA, délibérément structurées de la même manière afin qu'une attaque commençant par un e-mail de phishing et se terminant sur un modèle puisse être décrite de bout en bout."
            },
            {
              "q": "Ai-je besoin d'ATLAS si je suis déjà le Top 10 OWASP pour les LLM ?",
              "a": "Ils répondent à des objectifs différents et leur association est essentielle. OWASP vous indique la classe de faiblesse présente ; ATLAS vous décrit ce qu'un adversaire en fait, ce qui est indispensable pour la détection et le red-teaming."
            },
            {
              "q": "Quelle est sa place au sein d'une petite équipe ?",
              "a": "D'abord comme backlog de red-team. Même sans programme de détection, la matrice fournit une liste prioritaire d'attaques à tester contre votre propre système — et ces tests constituent le moyen le plus économique de découvrir quels contrôles n'existent que sur le papier."
            }
          ]
        },
        "de": {
          "name": "MITRE ATLAS",
          "summary": "MITRE ATLAS ist die gegnerische Seite der Landkarte. Während OWASP die Schwachstellenklassen in Ihrer Anwendung benennt, katalogisiert ATLAS die Taktiken und Techniken, die Angreifer tatsächlich gegen KI-gestützte Systeme einsetzen – Aufklärung eines Modells, Erlangung von Zugriff, Vorbereitung eines Angriffs, Umgehen von Abwehrmechanismen, Exfiltration von Daten – organisiert auf dieselbe Weise, wie MITRE ATT&CK konventionelle Einbrüche strukturiert, und gestützt auf dokumentierte Fallstudien statt auf Hypothesen.",
          "definition": "MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) ist eine öffentlich zugängliche Wissensdatenbank für Taktiken, Techniken und Fallstudien von Angreifern, die bei KI-gestützten Systemen beobachtet wurden. Sie ist nach dem Vorbild von MITRE ATT&CK strukturiert, sodass KI-spezifische Angriffe mit denselben Begriffen beschrieben werden können wie die übrige Threat Intelligence einer Organisation.",
          "scope": "Jede Organisation, die KI-gestützte Systeme entwickelt, bereitstellt oder verteidigt, und jedes Sicherheitsteam, das bereits mit ATT&CK arbeitet. Es handelt sich um eine Wissensdatenbank, nicht um einen Standard: Es gibt keine Zertifizierung danach und es werden keine Kontrollen vorgeschrieben – es beschreibt, was Angreifer tun, damit Verteidiger entscheiden können, was sie erkennen und verhindern wollen.",
          "keyPoints": [
            "Strukturiert in Taktiken (das Ziel des Angreifers) und Techniken (wie es erreicht wird), wobei MITRE ATT&CK bewusst gespiegelt wird, damit sich KI-Angriffe in bestehende Bedrohungsmodelle einfügen, anstatt isoliert daneben zu stehen.",
            "Es deckt den gesamten Verlauf eines Einbruchs ab – Aufklärung, Zugriff auf das Modell, Ausführung, Persistenz, Umgehung der Verteidigung, Entdeckung, Erfassung, Exfiltration, Auswirkungen – einschließlich KI-spezifischer Phasen wie der Vorbereitung eines Angriffs auf ein Modell.",
            "Es ist evidenzbasiert: Die Einträge stützen sich auf dokumentierte Vorfälle und Red-Teaming-Übungen, was es von einer bloßen Liste theoretisch möglicher Probleme unterscheidet.",
            "Es ergänzt OWASP, anstatt damit zu konkurrieren. OWASP klassifiziert Schwachstellen in Ihrem Design; ATLAS beschreibt das Verhalten von Angreifern, die diese ausnutzen.",
            "Sein praktischer Nutzen liegt in der Erkennung und im Red-Teaming: Eine Technik ist etwas, das Sie an Ihrem eigenen System ausprobieren und in Ihren Protokollen suchen können.",
            "Die Matrix wird gepflegt und erweitert, sobald neue Angriffe dokumentiert werden. Sie ist somit eine lebendige Referenz und keine starre Checkliste."
          ],
          "controls": [
            {
              "control": "Ordnen Sie Ihren Agenten-Stack der Matrix zu",
              "note": "Gehen Sie die Taktiken anhand Ihrer eigenen Architektur durch und markieren Sie, welche Techniken erreichbar sind. Die Erreichbarkeit, nicht die Plausibilität, macht eine Technik verteidigungswürdig."
            },
            {
              "control": "Erreichbare Techniken in Erkennungsmechanismen umwandeln",
              "note": "Benennen Sie für jede Technik das Signal, das sie in Ihrer Telemetrie anzeigen würde. Eine Technik ohne entsprechendes Signal ist eine, die Sie bewusst ignorieren."
            },
            {
              "control": "Nutzen Sie es als Red-Team-Backlog",
              "note": "Techniken sind von Natur aus testbar. Führen Sie sie gegen Ihr eigenes System aus und betrachten Sie 'konnten wir nicht reproduzieren' als ein aufzeichnungswürdiges Ergebnis, nicht als mangelnde Arbeit."
            },
            {
              "control": "Sprechen Sie ATT&CK, wo die Organisation es bereits tut",
              "note": "Melden Sie KI-Ergebnisse in ATLAS-Begriffen, damit sie in dieselben Analyse-, Triage- und Reaktionsprozesse einfließen wie alles andere. Ein neuartiges Vokabular führt nur dazu, dass sich am Ende niemand für das KI-Risiko verantwortlich fühlt."
            },
            {
              "control": "Lesen Sie die Fallstudien, nicht nur die Matrix",
              "note": "Die Fallstudien enthalten die operativen Details – wie der Zugriff erlangt wurde, was der Angreifer als Nächstes tat –, also genau den Teil, der sich auf Ihre eigene Umgebung übertragen lässt."
            },
            {
              "control": "Führen Sie es in das Bedrohungsmodell zurück",
              "note": "ATLAS ist der externe Input für ein agentenbasiertes Bedrohungsmodell; im Bedrohungsmodell werden seine Techniken zu Angriffsflächen in Ihrem Besitz, denen Kontrollen und Verantwortliche zugeordnet sind."
            }
          ],
          "checklist": [
            "Identifizieren Sie, welche ATLAS-Taktiken in Ihrer Architektur überhaupt erreichbar sind.",
            "Erfassen Sie für jede erreichbare Technik die Kontrollmaßnahme, die sie eingrenzt, und das Signal, das sie erkennt.",
            "Wenn keine Erkennung vorhanden ist, geben Sie dies explizit an, anstatt die Zeile leer zu lassen.",
            "Planen Sie Red-Teaming-Übungen auf Basis der Matrix und prüfen Sie, ob jeder Versuch fehlschlägt oder erfolgreich ist, bevor Sie eine Abdeckung beanspruchen.",
            "Melden Sie Ergebnisse unter Verwendung von ATLAS-Identifikatoren, damit sie in den bestehenden Informationsfluss der Organisation einfließen.",
            "Überprüfen Sie die Matrix regelmäßig, da neue Techniken dokumentiert werden, sobald sie beobachtet werden.",
            "Verknüpfen Sie die Ergebnisse mit den OWASP LLM Top 10, damit Schwachstellen und Angreiferverhalten einander zugeordnet und nicht separat nachverfolgt werden."
          ],
          "pitfalls": [
            "Es als Compliance-Checkliste zu behandeln. Es gibt keine Zertifizierung nach ATLAS, und 'Wir haben die Matrix überprüft' ist keine Kontrollmaßnahme.",
            "Jede Technik unabhängig von ihrer Erreichbarkeit zuzuordnen, was zu einem umfangreichen Dokument ohne Prioritäten führt.",
            "Die KI-Bedrohungsanalyse in einem separaten Prozess von den bestehenden Prozessen der Organisation zu halten – genau das Ergebnis, das durch die Ausrichtung an ATT&CK verhindert werden soll.",
            "Die Matrix zu lesen und die Fallstudien zu überspringen, in denen die übertragbaren operativen Details enthalten sind.",
            "Eine Abdeckung ohne Tests anzunehmen. Eine Technik, die Sie noch nie an Ihrem eigenen System ausprobiert haben, ist eine Technik, zu der Sie lediglich eine Meinung haben."
          ],
          "examples": [
            "Ein Team ordnet seinen Retrieval-Agenten ATLAS zu und stellt fest, dass der Modellzugriff trivial ist (der Endpunkt ist öffentlich), die Vorbereitung kostengünstig ist (jeder Wiki-Editor kann Inhalte einschleusen) und die Exfiltration unkontrolliert erfolgt (der ausgehende Datenverkehr ist unbeschränkt). Drei Techniken, von denen sie sich um eine bereits Sorgen gemacht haben.",
            "Eine Sicherheitsorganisation, die bereits ATT&CK-basiertes Detection Engineering betreibt, fügt ATLAS-Techniken demselben Backlog hinzu, sodass KI-spezifische Erkennungen von dem Team erstellt, überprüft und im Bereitschaftsdienst betreut werden, das diese Arbeit ohnehin erledigt.",
            "Ein Red Team nutzt die Matrix als Zielliste für eine Agenten-Bewertung und meldet die Ergebnisse unter Verwendung von ATLAS-Identifikatoren zurück – was es Personen, die noch nie an einem Agenten gearbeitet haben, ermöglicht, die Ergebnisse zu triagieren."
          ],
          "faqs": [
            {
              "q": "Ist ATLAS ein Ersatz für ATT&CK?",
              "a": "Nein, es ist eine Ergänzung. ATT&CK deckt konventionelles Angreiferverhalten ab; ATLAS deckt die KI-spezifischen Phasen ab, bewusst auf dieselbe Weise strukturiert, sodass ein Angriff, der mit einer Phishing-E-Mail beginnt und bei einem Modell endet, durchgängig beschrieben werden kann."
            },
            {
              "q": "Benötige ich ATLAS, wenn ich bereits die OWASP LLM Top 10 befolge?",
              "a": "Sie dienen unterschiedlichen Zwecken, und die Kombination ist der entscheidende Punkt. OWASP sagt Ihnen, welche Klasse von Schwachstelle Sie haben; ATLAS sagt Ihnen, was ein Angreifer damit macht – und genau das ist es, was für Erkennung und Red-Teaming benötigt wird."
            },
            {
              "q": "Wo lässt es sich in einem kleinen Team einsetzen?",
              "a": "In erster Linie als Red-Team-Backlog. Selbst ohne ein Erkennungsprogramm bietet die Matrix eine priorisierte Liste von Angriffen, die Sie an Ihrem eigenen System ausprobieren können – und diese Versuche sind der günstigste Weg, um herauszufinden, welche Ihrer Kontrollmaßnahmen nur auf dem Papier existieren."
            }
          ]
        },
        "ja": {
          "name": "MITRE ATLAS",
          "summary": "MITRE ATLASは、攻撃者側のマップです。OWASPがアプリケーション内の脆弱性クラスを定義するのに対し、ATLASは攻撃者がAI搭載システムに対して実際に使用する戦術（タクティクス）と手法（テクニック）をカタログ化しています。これには、モデルの偵察、アクセス権の獲得、攻撃の準備、防御の回避、データの持ち出しなどが含まれ、MITRE ATT&CKが従来の侵入を整理するのと同じ方法で整理されており、仮説ではなく文書化されたケーススタディに基づいています。",
          "definition": "MITRE ATLAS（Adversarial Threat Landscape for Artificial-Intelligence Systems）は、AI搭載システムに対して観測された攻撃者の戦術、手法、およびケーススタディをまとめた、一般に公開されているナレッジベースです。MITRE ATT&CKの構成を踏襲しているため、AI特有の攻撃を、組織の他の脅威インテリジェンスと同じ用語で記述することができます。",
          "scope": "AI搭載システムを構築、展開、または防御するすべての組織、およびすでにATT&CKを共通言語としているすべてのセキュリティチームが対象です。これはナレッジベースであり、標準規格ではありません。これに対する認証制度はなく、管理策を規定するものでもありません。防御側が何を検知し防止すべきかを決定できるように、攻撃者の行動を記述したものです。",
          "keyPoints": [
            "戦術（攻撃者の目標）と手法（それがどのように達成されるか）として構成されており、意図的にMITRE ATT&CKを反映させているため、AIへの攻撃を既存の脅威モデルから切り離すことなく、その中に組み込むことができます。",
            "偵察、モデルへのアクセス、実行、永続化、防御回避、検出、収集、持ち出し、影響といった侵入プロセス全体をカバーしており、モデルに対する攻撃の準備など、AI特有のステージも含まれています。",
            "エビデンス主導です。各項目は文書化されたインシデントやレッドチームの演習に基づいているため、理論上起こり得る問題の単なるリストとは一線を画しています。",
            "OWASPと競合するのではなく、補完し合う関係にあります。OWASPが設計上の弱点を分類するのに対し、ATLASはそれらを悪用する攻撃者の行動を記述します。",
            "その実用的な価値は、検知とレッドチーム演習にあります。手法（テクニック）とは、自社システムに対して試行できるものであり、ログから探し出すことができるものです。",
            "マトリクスは新しい攻撃が文書化されるたびに維持・拡張されるため、固定されたチェックリストではなく、生きたリファレンスとして機能します。"
          ],
          "controls": [
            {
              "control": "エージェントスタックをマトリクスにマッピングする",
              "note": "自社のアーキテクチャに照らし合わせて戦術を検証し、どの手法が到達可能（reachable）であるかをマークします。防御する価値がある手法かどうかを決めるのは、もっともらしさ（plausibility）ではなく、到達可能性（reachability）です。"
            },
            {
              "control": "到達可能な手法を検知ルールに変換する",
              "note": "それぞれの手法について、テレメトリ上でそれを特定できるシグナルを定義します。対応するシグナルがない手法は、「気づかないことに決めた」手法と同義です。"
            },
            {
              "control": "レッドチームのバックログとして活用する",
              "note": "手法はその構造上、テスト可能です。自社システムに対して実行し、「再現できなかった」という結果も、成果なしとするのではなく、記録に値する結果として扱ってください。"
            },
            {
              "control": "組織がすでにATT&CKを使用している場合は、それに合わせる",
              "note": "AIに関する検出事項をATLASの用語で報告することで、他のすべての脅威と同じインテリジェンス、トリアージ、対応プロセスに組み込むことができます。独自の新しい語彙を使ってしまうと、AIリスクの責任の所在が曖昧になる原因になります。"
            },
            {
              "control": "マトリクスだけでなく、ケーススタディも読む",
              "note": "ケーススタディには、どのようにアクセスが取得されたか、攻撃者が次に何を行ったかといった運用の詳細が含まれており、これこそが自社の環境に応用できる部分です。"
            },
            {
              "control": "脅威モデルにフィードバックする",
              "note": "ATLAS is the external input to an agentic threat model; the threat model is where its techniques become surfaces you own, with controls and owners attached."
            }
          ],
          "checklist": [
            "自社のアーキテクチャにおいて、どのATLAS戦術がそもそも到達可能であるかを特定する。",
            "到達可能な各手法について、それを制限する管理策と、それを検知するシグナルを記録する。",
            "検知手段がない場合は、行を空白にするのではなく、明示的にその旨を記載する。",
            "マトリクスから抽出したレッドチーム演習を計画し、カバレッジを主張する前に、各試行が成功したか失敗したかを確認する。",
            "検出事項をATLASの識別子（ID）を使用して報告し、組織の既存のインテリジェンスフローに統合する。",
            "新しい手法は観測され次第文書化されるため、マトリクスを定期的に見直す。",
            "OWASP LLM Top 10と相互参照し、弱点と攻撃者の行動を別々に追跡するのではなく、相互にマッピングする。"
          ],
          "pitfalls": [
            "コンプライアンスのチェックリストとして扱うこと。ATLASに対する認証制度はなく、「マトリクスを確認した」ことは管理策にはなりません。",
            "到達可能性を考慮せずにすべての手法をマッピングすること。これは膨大な文書を生み出すだけで、優先順位が定まらなくなります。",
            "AI脅威インテリジェンスを組織の既存のプロセスから切り離して管理すること。これこそが、ATT&CKとの整合性を図ることで防ごうとしている事態です。",
            "マトリクスだけを読み、応用可能な運用の詳細が記載されているケーススタディをスキップすること。",
            "テストをせずにカバレッジを想定すること。自社システムに対して一度も試したことがない手法は、単なる主観的な意見にすぎません。"
          ],
          "examples": [
            "あるチームが自社の検索エージェントをATLASにマッピングしたところ、モデルへのアクセスが容易（エンドポイントが公開されている）、準備が容易（Wikiの編集者なら誰でもコンテンツを仕込める）、持ち出しに対する管理策がない（送信制限がない）ことが判明しました。これら3つの手法のうち、1つはすでに懸念していたものでした。",
            "すでにATT&CKベースの検知エンジニアリングを運用しているセキュリティ組織が、ATLASの手法を同じバックログに追加します。これにより、AI特有の検知ルールが、その業務を担当するチームによって構築、レビュー、およびオンコール対応されるようになります。",
            "レッドチームがマトリクスをエージェント評価のターゲットリストとして使用し、ATLASの識別子で報告します。これにより、エージェントを扱ったことがない担当者でも、その検出事項をトリアージできるようになります。"
          ],
          "faqs": [
            {
              "q": "ATLASはATT&CKの代わりになるものですか？",
              "a": "いいえ、補完し合う関係です。ATT&CKは従来の攻撃者の行動をカバーし、ATLASはAI特有のステージをカバーします。意図的に同じ構造に設計されているため、フィッシングメールから始まりモデルで終わるような攻撃を、終始一貫して記述することができます。"
            },
            {
              "q": "すでにOWASP LLM Top 10に従っている場合でも、ATLASは必要ですか？",
              "a": "これらは異なる目的を持っており、組み合わせて使用することに意味があります。OWASPはどのような脆弱性のクラスが存在するかを示し、ATLASは攻撃者がそれをどのように悪用するかを示します。これこそが、検知やレッドチーム演習で実際に必要とされる情報です。"
            },
            {
              "q": "小規模なチームでは、どのように活用できますか？",
              "a": "まずはレッドチームのバックログとして活用するのが最適です。検知プログラムがなくても、マトリクスは自社システムに対して試行すべき攻撃の優先順位付きリストを提供します。実際に試行することは、どの管理策が机上の空論にすぎないかを明らかにする最も低コストな方法です。"
            }
          ]
        },
        "zh": {
          "name": "MITRE ATLAS",
          "summary": "MITRE ATLAS 是对抗视角的防御地图。如果说 OWASP 命名了应用程序中的漏洞类别，那么 ATLAS 则编目了攻击者实际针对 AI 系统所使用的战术和技术——包括模型侦察、获取访问权限、策划攻击、规避防御、外发数据等。它按照 MITRE ATT&CK 组织传统入侵的方式进行组织，并基于已记录的案例研究而非假设。",
          "definition": "MITRE ATLAS（人工智能系统对抗性威胁格局）是一个公开可用的知识库，收录了针对 AI 系统观察到的对手战术、技术和案例研究。它基于 MITRE ATT&CK 构建，以便能够使用与组织其他威胁情报相同的术语来描述 AI 特有的攻击。",
          "scope": "任何构建、部署或防御 AI 系统的组织，以及任何已经熟悉 ATT&CK 的安全团队。它是一个知识库，而不是标准：没有任何机构对其进行认证，它也不规定任何控制措施——它描述了对手的行为，以便防御者能够决定检测和预防什么。",
          "keyPoints": [
            "结构分为战术（对手的目标）和技术（如何实现目标），刻意镜像了 MITRE ATT&CK，以便将 AI 攻击纳入现有的威胁模型中，而不是将其孤立在外。",
            "它涵盖了整个入侵弧——侦察、获取模型访问权限、执行、持久化、防御规避、发现、收集、数据外发、影响——并包含针对模型的策划攻击等 AI 特有阶段。",
            "它是以证据为导向的：所有条目都基于已记录的事件和红队演练，这使它区别于一份仅在理论上可能出错的清单。",
            "它与 OWASP 互为补充，而非竞争关系。OWASP 对设计中的缺陷进行分类；ATLAS 则描述了利用这些缺陷的对手行为。",
            "它的实际价值在于检测和红队演练：一项技术既是你可以针对自己的系统尝试的操作，也是你可以在日志中寻找的线索。",
            "随着新攻击被记录，该矩阵会持续维护和扩展，因此它是一个动态的参考，而非固定的清单。"
          ],
          "controls": [
            {
              "control": "将您的智能体技术栈映射到矩阵上",
              "note": "对照您自己的架构梳理这些战术，并标记哪些技术是可触达的。决定一项技术是否值得防御的是可触达性，而非合理性。"
            },
            {
              "control": "将可触达的技术转化为检测规则",
              "note": "针对每一项技术，指明在遥测数据中能够显示它的信号。没有对应信号的技术，意味着你已决定对其视而不见。"
            },
            {
              "control": "将其用作红队待办任务",
              "note": "这些技术在设计上就是可测试的。在您自己的系统上运行它们，并将“我们无法复现”视为一个值得记录的结果，而不是工作的缺失。"
            },
            {
              "control": "在组织已使用 ATT&CK 的地方使用相同的语言",
              "note": "用 ATLAS 术语报告 AI 发现，以便它们能与所有其他事件一样进入相同的威胁情报、分流和响应流程。新奇的词汇往往会导致 AI 风险最终无人负责。"
            },
            {
              "control": "阅读案例研究，而不仅仅是矩阵",
              "note": "案例研究承载了操作细节——如何获取访问权限、对手接下来做了什么——这些正是可以应用到您自己环境中的部分。"
            },
            {
              "control": "将其反馈到威胁模型中",
              "note": "ATLAS 是智能体威胁模型的外部输入；而威胁模型则是将其技术转化为您所拥有的攻击面，并为其分配控制措施和负责人的地方。"
            }
          ],
          "checklist": [
            "识别在您的架构中究竟有哪些 ATLAS 战术是可触达的。",
            "针对每个可触达的技术，记录限制它的控制措施以及检测它的信号。",
            "在没有检测手段的地方，应明确说明，而不是将该行留空。",
            "安排从矩阵中提取的红队演练，并在声称覆盖之前，确认每次尝试的失败或成功。",
            "使用 ATLAS 标识符报告发现，以便它们融入组织现有的情报流中。",
            "定期审查矩阵，因为随着新技术的发现，它们会被记录下来。",
            "与 OWASP LLM Top 10 进行交叉引用，以便将缺陷和对手行为相互映射，而不是分开跟踪。"
          ],
          "pitfalls": [
            "将其视为合规清单。没有任何机构对 ATLAS 进行认证，且“我们审查了矩阵”并不是一种控制措施。",
            "不考虑可触达性而映射每项技术，这会导致文档庞大且毫无优先级可言。",
            "将 AI 威胁情报与组织现有的流程分开——这恰恰是与 ATT&CK 保持一致所要防止的结果。",
            "只阅读矩阵而跳过案例研究，而案例研究正是可借鉴的操作细节所在。",
            "在没有测试的情况下假设已覆盖。一项你从未针对自己的系统尝试过的技术，只能算作你对其持有某种看法。"
          ],
          "examples": [
            "一个团队将其检索智能体映射到 ATLAS 上，发现模型访问非常简单（端点是公开的）、策划成本极低（任何维基编辑者都可以植入内容），且数据外发没有任何控制（出口不受限制）。这涉及三项技术，其中一项是他们之前就已经在担心的。",
            "一个已经运行基于 ATT&CK 的检测工程的安全组织将 ATLAS 技术添加到同一个待办任务中，从而使 AI 特有的检测规则由负责该工作的团队进行构建、审查和值班响应。",
            "红队将该矩阵用作智能体评估的目标列表，并使用 ATLAS 标识符报告结果——这使得从未接触过智能体的人员也能对发现的问题进行分流。"
          ],
          "faqs": [
            {
              "q": "ATLAS 是 ATT&CK 的替代品吗？",
              "a": "不，它是伴侣。ATT&CK 涵盖传统的对手行为；ATLAS 涵盖 AI 特有的阶段，其结构刻意保持一致，以便能够端到端地描述从钓鱼邮件开始并以模型结束的攻击。"
            },
            {
              "q": "如果已经遵循 OWASP LLM Top 10，我还需要 ATLAS 吗？",
              "a": "它们服务于不同的目的，两者的结合才是关键。OWASP 告诉您存在哪类缺陷；ATLAS 告诉您对手会如何利用它，而这正是检测和红队演练实际需要的。"
            },
            {
              "q": "它适合小团队的什么环节？",
              "a": "首先作为红队的待办任务。即使没有检测计划，该矩阵也提供了一个针对您自己系统尝试攻击的优先级列表——而尝试这些攻击是发现哪些控制措施仅存在于纸面上的最廉价方式。"
            }
          ]
        }
      }
    }
  ]
}