{
 "version": "1.0",
 "datum": "2026-09-24",
 "quellen": {
  "iso": "ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system",
  "nist": "NIST AI 100-1 (AI RMF 1.0, Januar 2023) + NIST AI RMF Playbook"
 },
 "skala": {
  "stark": "inhaltlich weitgehend deckungsgleich",
  "mittel": "erhebliche Überschneidung, abweichender Fokus",
  "schwach": "thematische Berührung / Teilaspekt"
 },
 "nist_zu_iso": {
  "GOVERN 1.1": {
   "iso": [
    {
     "ref": "4.1",
     "titel": "Understanding the organization and its context",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "4.1 verlangt die Bestimmung externer und interner Themen, die die Zielerreichung des AIMS beeinflussen; das Rechts- und Regulierungsumfeld ist das klassische externe Thema. Zusätzlich ist der intended purpose der AI-Systeme und die eigene Rolle zu bestimmen, was die Anwendbarkeit von Rechtspflichten erst bestimmbar macht."
    },
    {
     "ref": "4.2",
     "titel": "Understanding the needs and expectations of interested parties",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "4.2 fordert die Ermittlung der interested parties (u.a. Aufsichtsbehörden, Gesetzgeber), deren relevanter Anforderungen und der Entscheidung, welche davon über das AIMS adressiert werden. Damit ist das Verstehen und Zuordnen rechtlicher Anforderungen normiert, nicht aber deren laufende Pflege."
    },
    {
     "ref": "A.2.2",
     "titel": "AI policy",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "Die AI policy ist laut B.2.2 ausdrücklich durch legal requirements, including contracts zu informieren und muss Prozesse für Abweichungen und Ausnahmen enthalten. Damit werden Rechtsanforderungen dokumentiert verankert, aber nicht systematisch als Pflichtenregister geführt."
    },
    {
     "ref": "A.2.4",
     "titel": "Review of the AI policy",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.2.4 verlangt die Review der AI policy in geplanten Abständen; B.2.4 nennt als Anlass ausdrücklich Änderungen der legal conditions. Das deckt das managed-Element für sich ändernde Rechtslagen ab."
    },
    {
     "ref": "A.8.5",
     "titel": "Information for interested parties",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.8.5 verlangt, die Berichtspflichten gegenüber interested parties zu bestimmen und zu dokumentieren; B.8.5 stellt klar, dass Jurisdiktionen die Weitergabe von Systeminformationen an Regulatoren verlangen können. Das deckt den dokumentierten Teil regulatorischer Pflichten ab."
    },
    {
     "ref": "6.2",
     "titel": "AI objectives and planning to achieve them",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "6.2 verlangt, dass AI-Ziele applicable requirements berücksichtigen; der Rechtsbezug ist damit nur mittelbar über die Zielplanung hergestellt. Eine eigenständige Verwaltung oder Dokumentation von Rechtspflichten leistet die Klausel nicht."
    }
   ],
   "luecke": "ISO/IEC 42001 kennt kein eigenständiges Rechtspflichten- bzw. Compliance-Register und keine Pflicht zur systematischen Beobachtung regulatorischer Entwicklungen (AI-Act-Konformität, sektorspezifische Auflagen). Die Anforderung ist auf 4.1/4.2, 6.2 und A.2.2/A.2.4 verteilt und muss organisatorisch zu einem nachvollziehbaren Nachweis verdichtet werden."
  },
  "GOVERN 1.2": {
   "iso": [
    {
     "ref": "A.2.2",
     "titel": "AI policy",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.2.2 verlangt eine dokumentierte Policy für Entwicklung oder Nutzung von AI-Systemen; B.2.2 fordert darin „principles that guide all activities of the organization related to AI“. Damit ist die Verankerung von Trustworthiness-Prinzipien in der Leitlinie normativ gefordert."
    },
    {
     "ref": "A.2.3",
     "titel": "Alignment with other organizational policies",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.2.3 verlangt zu bestimmen, wo andere Policies von den AI-Zielen betroffen sind; B.2.3 nennt quality, security, safety und privacy und verlangt, bestehende Policies zu aktualisieren oder Regelungen in die AI policy aufzunehmen. Das ist genau die Integration in organizational policies."
    },
    {
     "ref": "A.6.1.2",
     "titel": "Objectives for responsible development of AI system",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.1.2 verlangt, Ziele für verantwortungsvolle Entwicklung zu dokumentieren und Maßnahmen zu ihrer Erreichung in den Entwicklungslebenszyklus zu integrieren. B.6.1.2 illustriert dies am Beispiel fairness, das in Requirements, Datenakquise, Training und V&V einzuarbeiten ist."
    },
    {
     "ref": "A.6.1.3",
     "titel": "Processes for responsible AI system design and development",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.1.3 verlangt definierte und dokumentierte Prozesse für verantwortungsvolle Gestaltung und Entwicklung; B.6.1.3 listet u.a. Testanforderungen, human oversight, Release-Kriterien und change control. Das deckt die Verankerung in processes and procedures ab."
    },
    {
     "ref": "A.9.3",
     "titel": "Objectives for responsible use of AI system",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.9.3 verlangt, Ziele für die verantwortungsvolle Nutzung von KI-Systemen festzulegen und zu dokumentieren; B.9.3 zählt dafür fairness, accountability, transparency, explainability, reliability, safety, robustness, privacy, security und accessibility auf. Diese Aufzählung deckt sich weitgehend mit den characteristics of trustworthy AI, deren Verankerung in Richtlinien und Prozessen GOVERN 1.2 fordert."
    },
    {
     "ref": "5.2",
     "titel": "AI policy",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "5.2 verpflichtet das Top-Management auf eine AI policy, die einen Rahmen für AI-Ziele setzt, ein Bekenntnis zur Erfüllung anwendbarer Anforderungen enthält und auf andere Policies der Organisation verweist. Die Klausel liefert den formalen Rahmen, benennt die Trustworthiness-Merkmale aber nicht."
    },
    {
     "ref": "A.9.2",
     "titel": "Processes for responsible use of AI systems",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.9.2 verlangt dokumentierte Prozesse für die verantwortungsvolle Nutzung von AI-Systemen, laut B.9.2 einschließlich erforderlicher Genehmigungen und Sourcing-Anforderungen. Damit reicht die Integration bis in die Nutzungsseite, bleibt inhaltlich aber offen."
    }
   ],
   "luecke": "Die NIST-Merkmalsliste (valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, fair with harmful bias managed) ist in ISO/IEC 42001 nicht normativ abschließend festgelegt: A.6.1.2 und A.9.3 lassen die Wahl der Ziele der Organisation, die Beispiellisten stehen nur in Annex B bzw. im informativen Annex C."
  },
  "GOVERN 1.3": {
   "iso": [
    {
     "ref": "6.1.1",
     "titel": "Actions to address risks and opportunities — General",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "6.1.1 verlangt, AI risk criteria zu etablieren und zu pflegen, die acceptable von non-acceptable risks unterscheiden, und Risiken nach domain, application context und intended use zu bestimmen. Genau daraus ergibt sich das erforderliche Maß an Risikomanagement-Aktivitäten."
    },
    {
     "ref": "6.1.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "6.1.2 fordert einen Risikobewertungsprozess, der Risikoniveaus bestimmt, die Analyseergebnisse mit den Risikokriterien aus 6.1.1 vergleicht und die Risiken für die Behandlung priorisiert. Das ist der normative Mechanismus zur Ableitung des Aktivitätsniveaus aus der Risikotoleranz."
    },
    {
     "ref": "A.5.2",
     "titel": "AI system impact assessment process",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.5.2 a) verlangt festzulegen, unter welchen Umständen eine AI system impact assessment durchzuführen ist, u.a. nach criticality of the intended purpose, complexity of AI technology und level of automation sowie sensitivity of data. Das ist eine unmittelbare Entsprechung zur risikobasierten Staffelung der Aktivitäten."
    },
    {
     "ref": "6.1.3",
     "titel": "AI risk treatment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.1.3 verlangt die Genehmigung des Risikobehandlungsplans und die Akzeptanz der Restrisiken durch das designierte Management. Damit wird Risikotoleranz entscheidungsfähig operationalisiert, das Skalieren der Aktivitäten selbst regelt die Klausel jedoch nicht."
    },
    {
     "ref": "8.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "8.2 verlangt Risikobewertungen „at planned intervals or when significant changes are proposed or occur“ und damit die Festlegung von Takt und Auslösern. Die Tiefe der Aktivitäten wird nicht geregelt."
    },
    {
     "ref": "A.2.2",
     "titel": "AI policy",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "Nach B.2.2 ist die AI policy durch „the amount of risk the organization is willing to pursue or retain“ und „the level of risk posed by the AI systems“ zu informieren. Damit ist die Risikotoleranz auf Policy-Ebene dokumentiert zu verankern."
    }
   ],
   "luecke": null
  },
  "GOVERN 1.4": {
   "iso": [
    {
     "ref": "6.1.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "6.1.2 verlangt einen definierten, so ausgestalteten Risikobewertungsprozess, dass wiederholte Bewertungen consistent, valid and comparable results liefern, und das Aufbewahren dokumentierter Information darüber. Das entspricht dem etablierten, nachvollziehbaren Prozess."
    },
    {
     "ref": "6.1.3",
     "titel": "AI risk treatment",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "6.1.3 verlangt eine statement of applicability mit Begründung für Ein- und Ausschluss von Controls; die notwendigen Controls müssen dokumentiert, intern kommuniziert und interested parties as appropriate verfügbar sein. Das ist die Transparenzanforderung an Prozess und Controls."
    },
    {
     "ref": "6.1.1",
     "titel": "Actions to address risks and opportunities — General",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.1.1 verlangt dokumentierte Risikokriterien und das Aufbewahren dokumentierter Information über Maßnahmen zur Identifikation und Behandlung von AI-Risiken. Das liefert die Grundlage der organizational risk priorities."
    },
    {
     "ref": "8.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "8.2 verlangt das Aufbewahren dokumentierter Information über die Ergebnisse aller Risikobewertungen. Damit sind die outcomes des Prozesses belegbar."
    },
    {
     "ref": "8.3",
     "titel": "AI risk treatment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "8.3 verlangt die Umsetzung des Risikobehandlungsplans, die Verifikation seiner Wirksamkeit und das Aufbewahren dokumentierter Information über alle Behandlungsergebnisse. Das deckt die Ergebnisseite ab, nicht die Policy-Ebene."
    },
    {
     "ref": "A.2.2",
     "titel": "AI policy",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.2.2 verlangt eine dokumentierte AI policy; B.2.2 fordert darin „processes for handling deviations and exceptions to policy“ und als mögliches Themenfeld AI system impact assessments. Damit wird der Risikomanagement-Ansatz auf Policy-Ebene transparent gemacht."
    }
   ],
   "luecke": "ISO/IEC 42001 verlangt Dokumentation und interne Kommunikation, aber keine externe bzw. öffentliche Transparenz des Risikomanagementprozesses: Verfügbarkeit für interested parties ist in 6.1.3 nur as appropriate gefordert."
  },
  "GOVERN 1.5": {
   "iso": [
    {
     "ref": "8.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "8.2 verlangt AI-Risikobewertungen „at planned intervals or when significant changes are proposed or occur“. Damit ist die geplante Wiederholung einschließlich Frequenzfestlegung normiert."
    },
    {
     "ref": "9.1",
     "titel": "Monitoring, measurement, analysis and evaluation",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "9.1 verlangt festzulegen, was überwacht und gemessen wird, mit welchen Methoden, wann gemessen und wann die Ergebnisse analysiert und bewertet werden, und die Leistung sowie Wirksamkeit des AIMS zu bewerten. Das ist die zentrale Entsprechung für ongoing monitoring und Frequenzbestimmung."
    },
    {
     "ref": "A.3.2",
     "titel": "AI roles and responsibilities",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.3.2 verlangt definierte und zugewiesene AI-Rollen und -Verantwortlichkeiten; B.3.2 nennt als Bereiche ausdrücklich risk management, AI system impact assessments und performance. Das schließt die im Baseline-Mapping fehlende Rollenkomponente."
    },
    {
     "ref": "5.3",
     "titel": "Roles, responsibilities and authorities",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "5.3 verlangt, dass Verantwortlichkeiten und Befugnisse zugewiesen und in der Organisation kommuniziert werden, einschließlich der Berichterstattung über die AIMS-Leistung an das Top-Management. Das ist die klauselseitige Verankerung der Rollenklarheit."
    },
    {
     "ref": "8.3",
     "titel": "AI risk treatment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "8.3 verlangt die Verifikation der Wirksamkeit der Risikobehandlung sowie Review und Revalidierung nicht wirksamer Behandlungsoptionen. Das ist die Ergebnis-Überwachung der Risikobehandlung."
    },
    {
     "ref": "8.4",
     "titel": "AI system impact assessment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "8.4 verlangt AI system impact assessments in geplanten Abständen bzw. bei erheblichen Änderungen und das Aufbewahren der Ergebnisse. Ergänzt die periodische Review um die Wirkungsdimension."
    },
    {
     "ref": "9.3.1",
     "titel": "Management review — General",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "9.3.1 verpflichtet das Top-Management zur Review des AIMS at planned intervals auf continuing suitability, adequacy and effectiveness. Das deckt die periodische Review des Managementsystems einschließlich seiner Risikoprozesse ab."
    }
   ],
   "luecke": null
  },
  "GOVERN 1.6": {
   "iso": [
    {
     "ref": "4.1",
     "titel": "Understanding the organization and its context",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "4.1 verlangt, den intended purpose der entwickelten, bereitgestellten oder genutzten AI-Systeme zu berücksichtigen und die eigenen Rollen dazu zu bestimmen. Das setzt faktisch eine Übersicht der AI-Systeme im Geltungsbereich voraus."
    },
    {
     "ref": "7.1",
     "titel": "Resources",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "7.1 verlangt, die für Einrichtung, Umsetzung, Aufrechterhaltung und kontinuierliche Verbesserung des AIMS erforderlichen Ressourcen zu bestimmen und bereitzustellen. Das deckt das are resourced-Element ab, ohne Risikopriorisierung vorzugeben."
    },
    {
     "ref": "A.4.2",
     "titel": "Resource documentation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.4.2 verlangt, relevante Ressourcen der einzelnen Lebenszyklusphasen zu identifizieren und zu dokumentieren; B.4.2 nennt AI system components und stellt den Bezug zu Risiken und Auswirkungen her. Ein organisationsweites Register aller KI-Systeme mit Risikoklassifizierung fordert die Norm jedoch nicht — die Dokumentation ist systembezogen, nicht bestandsführend."
    },
    {
     "ref": "A.4.3",
     "titel": "Data resources",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.4.3 verlangt die Dokumentation der genutzten Datenressourcen; B.4.3 nennt u.a. provenance, Datenkategorien, intended use und Aufbewahrungsrichtlinien. Das inventarisiert die Datenseite des AI-Systems."
    },
    {
     "ref": "A.4.4",
     "titel": "Tooling resources",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.4.4 verlangt die Dokumentation der Tooling-Ressourcen, laut B.4.4 einschließlich Algorithmentypen, ML-Modellen und Software/Hardware für Design, Entwicklung und Deployment. Damit werden Modelle und Werkzeuge erfassbar."
    },
    {
     "ref": "A.4.5",
     "titel": "System and computing resources",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.4.5 verlangt die Dokumentation der System- und Rechenressourcen, laut B.4.5 einschließlich Lokation (on-premises, cloud, edge) und Verarbeitungsressourcen. Das ergänzt das Inventar um die technische Betriebsumgebung."
    },
    {
     "ref": "A.4.6",
     "titel": "Human resources",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.4.6 verlangt die Dokumentation der eingesetzten Human Resources und ihrer Kompetenzen über alle Lebenszyklusphasen. Für ein Inventar der AI-Systeme selbst ist das nur eine Randdimension, betrifft aber die Ressourcierung."
    }
   ],
   "luecke": "ISO/IEC 42001 verlangt Ressourcendokumentation je AI-System bzw. Lebenszyklusphase, aber kein zentrales, organisationsweites AI-System-Register mit Risikoklassifikation und Aktualisierungspflicht; die Kopplung der Ressourcenzuteilung an Risikoprioritäten ist nicht normiert."
  },
  "GOVERN 1.7": {
   "iso": [
    {
     "ref": "8.1",
     "titel": "Operational planning and control",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "8.1 verlangt, geplante Änderungen zu steuern, die Folgen unbeabsichtigter Änderungen zu bewerten und nachteilige Auswirkungen zu mindern. Das ist die normative Basis dafür, dass ein Phase-out keine Risiken erhöht."
    },
    {
     "ref": "A.4.6",
     "titel": "Human resources",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.4.6 nennt als einzige Stelle in Annex A das decommissioning ausdrücklich: Human Resources und Kompetenzen sind auch für change management, maintenance, transfer and decommissioning zu dokumentieren. Gefordert ist damit die Ressourcenseite, nicht der Außerbetriebnahmeprozess selbst."
    },
    {
     "ref": "A.6.1.3",
     "titel": "Processes for responsible AI system design and development",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.1.3 verlangt dokumentierte Prozesse für den verantwortungsvollen Lebenszyklus; B.6.1.3 nennt life cycle stages (nach ISO/IEC 22989 einschließlich Retirement) sowie change control und approvals and sign-offs. Daraus ist der Phase-out-Prozess ableitbar, aber nicht explizit gefordert."
    },
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.6 verlangt die Festlegung der Elemente des laufenden Betriebs; B.6.2.6 fordert Prozesse für Updates und Änderungen der Systemoperationen einschließlich communication to users. Das deckt geordnete Änderungen einschließlich Abschaltung von Funktionen teilweise ab."
    },
    {
     "ref": "A.6.2.7",
     "titel": "AI system technical documentation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.2.7 verlangt die Dokumentation eines Plans zum Umgang mit Fehlern und nennt dabei ausdrücklich rollback plan, „turning off features of the AI system“ und plan for notifying customers, users of changes. Das sind die textlich nächsten Elemente einer sicheren Außerbetriebnahme."
    },
    {
     "ref": "6.3",
     "titel": "Planning of changes",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "6.3 verlangt, Änderungen am AI-Managementsystem geplant durchzuführen; die Außerbetriebnahme eines Systems im Geltungsbereich ist eine solche Änderung. Die Klausel adressiert jedoch das Managementsystem, nicht das AI-System selbst."
    }
   ],
   "luecke": "ISO/IEC 42001 enthält kein eigenes Control zur Außerbetriebnahme bzw. Stilllegung (Annex A endet bei A.6.2.8, ein A.6.2.9 existiert nicht). Anforderungen an sicheres Abschalten, Löschung bzw. Archivierung von Modellen, Trainingsdaten, Event-Logs und Dokumentation, Migration der Nutzer und Nachweispflichten nach Ende des Lebenszyklus müssen vollständig hergeleitet werden. A.6.2.5 (Deployment) wurde geprüft und als nicht einschlägig verworfen, da es ausschließlich Release-Kriterien vor Inbetriebnahme regelt."
  },
  "GOVERN 2.1": {
   "iso": [
    {
     "ref": "5.3",
     "titel": "Roles, responsibilities and authorities",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "5.3 verlangt, dass das Top-Management Verantwortlichkeiten und Befugnisse für relevante Rollen zuweist und innerhalb der Organisation kommuniziert. Das entspricht unmittelbar der Forderung nach dokumentierten und organisationsweit klaren Rollen."
    },
    {
     "ref": "7.4",
     "titel": "Communication",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "7.4 verlangt, die internen und externen Kommunikationen zum AIMS zu bestimmen, einschließlich what, when, with whom und how to communicate. Das ist die normative Entsprechung für die Kommunikationswege."
    },
    {
     "ref": "A.3.2",
     "titel": "AI roles and responsibilities",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.3.2 verlangt definierte und zugewiesene AI-Rollen; B.3.2 nennt als Bereiche risk management, AI system impact assessments, performance und human oversight und fordert, Verantwortlichkeiten „to the level appropriate for the individuals to perform their duties“ zu definieren. Das korrigiert die Fehlbezeichnung B.3.2 = Management review inputs der Baseline."
    },
    {
     "ref": "7.2",
     "titel": "Competence",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "7.2 verlangt die Bestimmung der notwendigen Kompetenz der Personen, deren Tätigkeit die AI-Leistung beeinflusst, samt dokumentiertem Kompetenznachweis. Damit werden Rollen kompetenzseitig konkretisiert; die Baseline-Angabe 7..2 war ein Tippfehler."
    },
    {
     "ref": "7.3",
     "titel": "Awareness",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "7.3 verlangt, dass Personen unter der Kontrolle der Organisation die AI policy, ihren Beitrag zur Wirksamkeit des AIMS und die Folgen von Nichtkonformität kennen. Das adressiert das clear to individuals and teams, nicht jedoch die Dokumentation der Rollen."
    },
    {
     "ref": "A.3.3",
     "titel": "Reporting of concerns",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.3.3 verlangt einen Prozess zur Meldung von Concerns; B.3.3 fordert Eskalationswege zum Management in angemessener Zeit sowie Bekanntheit und Verfügbarkeit für Beschäftigte und Beauftragte. Das deckt die lines of communication auf der Meldeseite ab."
    }
   ],
   "luecke": null
  },
  "GOVERN 2.2": {
   "iso": [
    {
     "ref": "7.2",
     "titel": "Competence",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "7.2 verlangt, die notwendige Kompetenz zu bestimmen, sie durch Ausbildung, Schulung oder Erfahrung sicherzustellen, Maßnahmen zum Kompetenzaufbau zu ergreifen und deren Wirksamkeit zu bewerten, mit dokumentiertem Nachweis. Das ist die direkte Entsprechung zur Trainingsforderung."
    },
    {
     "ref": "7.3",
     "titel": "Awareness",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "7.3 verlangt Awareness über die AI policy, den eigenen Beitrag zur Wirksamkeit des AIMS und die Folgen von Nichtkonformität für alle „persons doing work under the organization's control“. Das sichert die Ausrichtung an related policies and procedures."
    },
    {
     "ref": "A.4.6",
     "titel": "Human resources",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.4.6 verlangt die Dokumentation der Human Resources und ihrer Kompetenzen über alle Lebenszyklusphasen; B.4.6 nennt Rollen für human oversight sowie Experten für safety, security und privacy. Das definiert den Kompetenzbedarf, nicht die Schulung selbst."
    },
    {
     "ref": "A.6.1.3",
     "titel": "Processes for responsible AI system design and development",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.1.3 nennt als Element verantwortungsvoller Entwicklungsprozesse ausdrücklich „expertise (subject matter domain or other) required or training for developers of AI systems or both“. Das verankert Schulung im Entwicklungsprozess."
    },
    {
     "ref": "A.9.3",
     "titel": "Objectives for responsible use of AI system",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.9.3 verlangt, dass das in human oversight eingebundene Personal informiert, geschult und mit den Instruktionen und Dokumentationen des AI-Systems sowie den eigenen Pflichten vertraut ist. Das ist eine explizite Schulungsanforderung für eine Schlüsselrolle."
    },
    {
     "ref": "A.10.2",
     "titel": "Allocating responsibilities",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.10.2 verlangt die Zuordnung der Verantwortlichkeiten im Lebenszyklus zwischen Organisation, Partnern, Lieferanten, Kunden und Dritten. Das adressiert die Partnerseite nur zuständigkeits-, nicht qualifizierungsbezogen."
    }
   ],
   "luecke": "Kompetenz- und Awareness-Pflichten gelten nach 7.2 und 7.3 nur für „persons doing work under the organization's control“; ein durchsetzbarer Schulungsanspruch gegenüber externen Partnern und Lieferanten sowie ein spezifisches Curriculum für AI-Risikomanagement (Umfang, Turnus, Wirksamkeitsnachweis pro Rolle) sind nicht normiert."
  },
  "GOVERN 2.3": {
   "iso": [
    {
     "ref": "5.1",
     "titel": "Leadership and commitment",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "5.1 verlangt vom Top-Management den Nachweis von Leadership und Commitment, u.a. die Integration der AIMS-Anforderungen in die Geschäftsprozesse, die Bereitstellung der Ressourcen und die Sicherstellung der beabsichtigten Ergebnisse. Das ist die zentrale Verantwortungsklausel."
    },
    {
     "ref": "6.1.3",
     "titel": "AI risk treatment",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "6.1.3 verlangt ausdrücklich die Genehmigung des AI-Risikobehandlungsplans und die Akzeptanz der Restrisiken durch das designierte Management. Das ist die präziseste Entsprechung zur Verantwortungsübernahme für Risikoentscheidungen und fehlte in der Baseline."
    },
    {
     "ref": "5.2",
     "titel": "AI policy",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "5.2 verpflichtet das Top-Management, die AI policy einschließlich des Bekenntnisses zur Erfüllung anwendbarer Anforderungen und zur kontinuierlichen Verbesserung zu etablieren. Damit ist die Leitungsverantwortung auf Policy-Ebene verankert."
    },
    {
     "ref": "5.3",
     "titel": "Roles, responsibilities and authorities",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "5.3 verlangt, dass das Top-Management die Verantwortung für die Konformität des AIMS und für die Berichterstattung über dessen Leistung an das Top-Management zuweist. Das sichert die Rückkopplung von Risikoinformationen an die Leitung."
    },
    {
     "ref": "9.3.1",
     "titel": "Management review — General",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "9.3.1 verlangt die Review des AIMS durch das Top-Management in geplanten Abständen auf fortdauernde Eignung, Angemessenheit und Wirksamkeit. Das institutionalisiert die Leitungsbefassung."
    },
    {
     "ref": "9.3.3",
     "titel": "Management review results",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "9.3.3 verlangt, dass die Ergebnisse der Managementbewertung Entscheidungen zu Verbesserungsmöglichkeiten und erforderlichen Änderungen des AIMS umfassen und dokumentiert werden. Damit sind Leitungsentscheidungen nachweisbar."
    },
    {
     "ref": "A.6.2.5",
     "titel": "AI system deployment",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.5 verlangt einen Deployment-Plan und die Erfüllung der Anforderungen vor dem Deployment; B.6.2.5 nennt dabei ausdrücklich „management approvals and sign-offs to be obtained“. Das ist die Entsprechung für Leitungsentscheidungen über das Deployment."
    }
   ],
   "luecke": null
  },
  "GOVERN 3.1": {
   "iso": [
    {
     "ref": "7.2",
     "titel": "Competence",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "7.2 verlangt die Bestimmung der notwendigen Kompetenz und Maßnahmen, um fehlende Kompetenz zu beschaffen. Das ist der klauselseitige Hebel für die Zusammenstellung des erforderlichen Expertisespektrums."
    },
    {
     "ref": "A.3.2",
     "titel": "AI roles and responsibilities",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.3.2 verlangt Rollen und Verantwortlichkeiten für risk management, impact assessments, security, safety, privacy, development, performance, human oversight und data quality management. Die Breite dieser Felder erzwingt faktisch eine fachlich gemischte Besetzung."
    },
    {
     "ref": "A.4.6",
     "titel": "Human resources",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.4.6 verlangt, den Bedarf an diverse expertise zu berücksichtigen, und nennt Data Scientists, Rollen für human oversight, Experten für safety, security und privacy sowie Domänenexperten; die Einbeziehung specific demographic groups wird nur bezogen auf Trainingsdaten genannt. Fachliche Vielfalt ist damit abgedeckt, demografische Vielfalt des Entscheidungsgremiums jedoch nur als Annex-B-Guidance und nicht normativ."
    },
    {
     "ref": "A.5.2",
     "titel": "AI system impact assessment process",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.5.2 c) verlangt festzulegen, wer die AI system impact assessment durchführt, und e) die potenziell betroffenen Individuen und Gesellschaften zu bestimmen. Damit ist die personelle Zusammensetzung zu regeln, ohne Diversitätskriterien vorzugeben."
    },
    {
     "ref": "A.5.4",
     "titel": "Assessing AI system impact on individuals or groups of individuals",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.5.4 verlangt, die besonderen Schutzbedarfe von Gruppen wie Kindern, beeinträchtigten und älteren Personen sowie Beschäftigten zu berücksichtigen, und empfiehlt, Experten wie Forschende, Fachexperten und Nutzer zu konsultieren. Das bringt externe Perspektivenvielfalt in die Bewertung."
    },
    {
     "ref": "A.6.1.3",
     "titel": "Processes for responsible AI system design and development",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.1.3 nennt als Elemente verantwortungsvoller Entwicklungsprozesse die erforderliche expertise (subject matter domain or other) und die engagement of interested parties. Das verankert multidisziplinäre Beteiligung im Entwicklungsprozess."
    }
   ],
   "luecke": "Diversität ist in ISO/IEC 42001 nur als Annex-B-Guidance (B.4.6: diverse expertise) formuliert und damit nicht normativ verbindlich. Anforderungen an demografische Diversität des Entscheidungsgremiums, an deren Dokumentation und an eine Wirksamkeitsprüfung fehlen."
  },
  "GOVERN 3.2": {
   "iso": [
    {
     "ref": "A.3.2",
     "titel": "AI roles and responsibilities",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.3.2 verlangt definierte und zugewiesene AI-Rollen und -Verantwortlichkeiten; B.3.2 nennt human oversight ausdrücklich als Bereich, der definierte Rollen erfordert. Die Baseline-Angabe B.3.2 Management review inputs ist eine Fehlbezeichnung: inhaltlich passt A.3.2, nicht 9.3.2, da Management review inputs keinen Bezug zur Rollendifferenzierung für human-AI configurations hat."
    },
    {
     "ref": "A.6.1.3",
     "titel": "Processes for responsible AI system design and development",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.6.1.3 nennt als zwingend zu berücksichtigendes Prozesselement „human oversight requirements, including processes and tools, especially when the AI system can impact natural persons“. Damit ist die Verankerung in Prozessen und Verfahren gefordert."
    },
    {
     "ref": "A.9.3",
     "titel": "Objectives for responsible use of AI system",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.9.3 verlangt festzulegen, in welchen Lebenszyklusphasen meaningful human oversight einzubauen ist, einschließlich human reviewers mit authority to override decisions und der Frage, ob automated decision-making überhaupt angemessen ist. Das ist die präziseste Entsprechung zu human-AI configurations."
    },
    {
     "ref": "5.3",
     "titel": "Roles, responsibilities and authorities",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "5.3 verlangt die Zuweisung und Kommunikation von Verantwortlichkeiten und Befugnissen für relevante Rollen. Das ist der klauselseitige Anker für die Differenzierung von Aufsichtsrollen."
    },
    {
     "ref": "7.2",
     "titel": "Competence",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "7.2 verlangt Kompetenznachweise für Personen, deren Tätigkeit die AI-Leistung beeinflusst; B.9.3 konkretisiert dies für das Oversight-Personal. Ohne Kompetenz bleibt eine definierte Aufsichtsrolle wirkungslos."
    },
    {
     "ref": "A.4.6",
     "titel": "Human resources",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.4.6 verlangt die Dokumentation der Human Resources und Kompetenzen; B.4.6 nennt ausdrücklich „roles related to human oversight of AI systems“. Das ordnet die Aufsichtsrollen ressourcenseitig zu."
    },
    {
     "ref": "A.5.3",
     "titel": "Documentation of AI system impact assessments",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.5.3 verlangt, unter anderem „the role of humans in relationships with system, including human oversight capabilities, processes and tools, available to avoid negative impacts“ zu dokumentieren. Das erzwingt die dokumentierte Differenzierung der Mensch-Maschine-Konfiguration."
    },
    {
     "ref": "A.8.2",
     "titel": "System documentation and information for users",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.8.2 verlangt, Nutzer u.a. darüber zu informieren, „how and when to override the system“ und needs for human oversight. Das adressiert die Rollenklarheit auf der Nutzungsseite."
    }
   ],
   "luecke": "ISO/IEC 42001 verlangt keine Taxonomie oder Abstufung der human-AI configurations (etwa human-in-the-loop, on-the-loop, out-of-the-loop) und keine Kriterien, wann welche Konfiguration risikoadäquat ist; B.9.3 stellt dies vollständig in das Ermessen der Organisation."
  },
  "GOVERN 4.1": {
   "iso": [
    {
     "ref": "A.2.2",
     "titel": "AI policy",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.2.2 verlangt eine dokumentierte AI policy; B.2.2 fordert darin principles that guide all activities sowie eine Herleitung aus organizational values and culture und dem Risikoappetit. Das ist die Policy-Ebene, die GOVERN 4.1 fordert."
    },
    {
     "ref": "A.6.1.2",
     "titel": "Objectives for responsible development of AI system",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.1.2 verlangt dokumentierte Ziele für verantwortungsvolle Entwicklung und die Integration von Maßnahmen zu ihrer Erreichung in den Entwicklungslebenszyklus. B.6.1.2 verlangt dazu Anforderungen und Leitlinien, etwa die Vorgabe bestimmter Testwerkzeuge gegen unwanted bias."
    },
    {
     "ref": "A.6.1.3",
     "titel": "Processes for responsible AI system design and development",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.1.3 verlangt dokumentierte Prozesse für verantwortungsvolles Design und Entwicklung; B.6.1.3 nennt Testanforderungen, human oversight, release criteria sowie „approvals and sign-offs necessary at various stages“. Das etabliert die geforderten Praktiken."
    },
    {
     "ref": "A.9.3",
     "titel": "Objectives for responsible use of AI system",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.9.3 nennt als Ziele verantwortungsvoller Nutzung ausdrücklich safety, reliability, robustness and redundancy neben fairness, transparency und privacy und verlangt Mechanismen zu deren Erreichung. Das entspricht der safety-first-Ausrichtung."
    },
    {
     "ref": "7.3",
     "titel": "Awareness",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "7.3 verlangt, dass Personen unter Kontrolle der Organisation die AI policy, ihren Beitrag zur Wirksamkeit des AIMS und die Folgen von Nichtkonformität kennen. Das ist der klauselseitige Anker für die geforderte Haltung, bleibt aber Awareness statt Kultur."
    },
    {
     "ref": "A.3.3",
     "titel": "Reporting of concerns",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.3.3 verlangt einen Prozess zur Meldung von Concerns; B.3.3 fordert Anonymitäts- bzw. Vertraulichkeitsoptionen, qualifizierte Bearbeitung, Eskalation und effective protection from reprisals. Das ist die normative Grundlage einer Speak-up-Kultur."
    },
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.2.4 verlangt Bewertungskriterien einschließlich reliability and safety requirements sowie acceptable error rates und fordert, bei Nichterreichen die intended use zu überdenken oder die Defizite zu managen. Das ist die kritische Prüfinstanz vor Freigabe."
    },
    {
     "ref": "A.9.2",
     "titel": "Processes for responsible use of AI systems",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.9.2 verlangt dokumentierte Prozesse für die verantwortungsvolle Nutzung; B.9.2 nennt erforderliche Genehmigungen, Kosten für laufendes Monitoring, zugelassene Beschaffungswege und rechtliche Anforderungen. Das adressiert die Nutzungsseite von GOVERN 4.1."
    }
   ],
   "luecke": "ISO/IEC 42001 enthält keine Anforderung an Organisationskultur bzw. psychologische Sicherheit als solche: ein critical thinking and safety-first mindset, Pre-mortem- oder Red-Teaming-Praktiken und die Messung der Sicherheitskultur sind nicht normiert; A.3.3 und 7.3 decken nur Meldewege und Bewusstsein ab."
  },
  "GOVERN 4.2": {
   "iso": [
    {
     "ref": "6.1.4",
     "titel": "AI system impact assessment",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "6.1.4 verlangt einen Prozess zur Bewertung der Folgen für Individuen, Gruppen und Gesellschaften unter Berücksichtigung von deployment, intended use und foreseeable misuse; das Ergebnis ist zu dokumentieren und kann relevanten interested parties zur Verfügung gestellt werden. Das deckt Dokumentation und Kommunikation der Auswirkungen ab."
    },
    {
     "ref": "7.4",
     "titel": "Communication",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "7.4 verlangt die Bestimmung der internen und externen Kommunikation zum AIMS einschließlich what, when, with whom und how. Das ist die normative Entsprechung zu communicate about the impacts more broadly."
    },
    {
     "ref": "A.5.3",
     "titel": "Documentation of AI system impact assessments",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.5.3 verlangt, die Ergebnisse der AI system impact assessments zu dokumentieren und für einen definierten Zeitraum aufzubewahren; B.5.3 listet u.a. intended use und foreseeable misuse, positive und negative Auswirkungen sowie predictable failures. Diese Kernzuordnung fehlte in der Baseline."
    },
    {
     "ref": "A.5.4",
     "titel": "Assessing AI system impact on individuals or groups of individuals",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.5.4 verlangt, die potenziellen Auswirkungen auf Individuen und Gruppen über den gesamten Lebenszyklus zu bewerten und zu dokumentieren; B.5.4 nennt fairness, accountability, transparency, security, safety, financial consequences, accessibility und human rights. Das ist die individuelle Impact-Dimension."
    },
    {
     "ref": "8.4",
     "titel": "AI system impact assessment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "8.4 verlangt, Impact Assessments in geplanten Abständen bzw. bei erheblichen Änderungen durchzuführen und die Ergebnisse dokumentiert aufzubewahren. Das macht die Dokumentation zur laufenden Pflicht der umsetzenden Teams."
    },
    {
     "ref": "A.5.5",
     "titel": "Assessing societal impacts of AI systems",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.5.5 verlangt, die potenziellen gesellschaftlichen Auswirkungen zu bewerten und zu dokumentieren; B.5.5 nennt Umwelt, Wirtschaft, Regierungshandeln, Gesundheit und kulturelle Normen. Das deckt die gesellschaftliche Dimension der Risiken ab."
    },
    {
     "ref": "A.6.2.7",
     "titel": "AI system technical documentation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.7 verlangt die je Interessengruppe erforderliche technische Dokumentation; B.6.2.7 nennt als Elemente management activities (e.g. risk management) und „impact assessment documentation as described in B.5“. Damit werden Risiken und Auswirkungen adressatengerecht dokumentiert."
    },
    {
     "ref": "A.8.5",
     "titel": "Information for interested parties",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.8.5 verlangt, die Berichtspflichten gegenüber interested parties zu bestimmen und zu dokumentieren; B.8.5 nennt als teilbare Inhalte ausdrücklich risks related to the system und results of impact assessments. Das ist die externe Kommunikationsseite."
    }
   ],
   "luecke": "ISO/IEC 42001 verlangt keine proaktive öffentliche Offenlegung von Risiken und Auswirkungen: 6.1.4 stellt die Weitergabe an interested parties unter where appropriate, A.8.5 knüpft sie an bestehende Berichtspflichten. Eine breite Kommunikation im Sinne von NIST (etwa Transparenzberichte, Modell- oder Systemkarten für die Öffentlichkeit) ist nicht gefordert."
  },
  "GOVERN 4.3": {
   "iso": [
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.4 verlangt definierte und dokumentierte Verifikations- und Validierungsmaßnahmen mit Kriterien für ihre Anwendung; B.6.2.4 nennt Testmethodiken und -werkzeuge, die Auswahl von Testdaten und deren Repräsentativität für die intended domain of use. Das ist die direkte Entsprechung zu enable AI testing."
    },
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.6 verlangt die Festlegung der Betriebselemente einschließlich „system and performance monitoring, repairs, updates and support“; B.6.2.6 fordert Monitoring auf general errors and failures und Support-Prozesse, die regeln, how issues and incidents are reported. Das deckt die Erkennung von Vorfällen im Betrieb ab."
    },
    {
     "ref": "A.8.3",
     "titel": "External reporting",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.8.3 verlangt, interested parties Möglichkeiten zur Meldung nachteiliger Auswirkungen bereitzustellen; B.8.3 nennt ausdrücklich externe Parteien und Beispiele wie unfairness. Das erschließt Vorfälle, die internes Monitoring nicht erfasst."
    },
    {
     "ref": "A.8.4",
     "titel": "Communication of incidents",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.8.4 verlangt einen dokumentierten Plan zur Kommunikation von Incidents an die Nutzer; B.8.4 nennt zu regelnde Punkte wie Incident-Typen, Meldefristen, zu informierende Behörden und erforderliche Details. Das ist die Entsprechung zu identification of incidents und information sharing."
    },
    {
     "ref": "10.2",
     "titel": "Nonconformity and corrective action",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "10.2 verlangt bei Nichtkonformitäten Reaktion, Ursachenanalyse, Prüfung auf gleichartige Fälle, Wirksamkeitsprüfung der Korrekturmaßnahmen und dokumentierte Nachweise. Das ist die normative Verarbeitungskette für erkannte Vorfälle."
    },
    {
     "ref": "A.6.1.3",
     "titel": "Processes for responsible AI system design and development",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.1.3 nennt als Element verantwortungsvoller Entwicklungsprozesse ausdrücklich „testing requirements and planned means for testing“ sowie release criteria. Das schafft die organisatorische Voraussetzung für AI-Tests."
    },
    {
     "ref": "A.6.2.8",
     "titel": "AI system recording of event logs",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.8 verlangt Event-Logging mindestens im Nutzungsbetrieb; B.6.2.8 nennt als Zweck ausdrücklich die „detection of the AI system's performance outside of the“ intended operating conditions. Das ist die technische Grundlage der Vorfallerkennung und fehlte in der Baseline."
    },
    {
     "ref": "A.8.5",
     "titel": "Information for interested parties",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.8.5 verlangt dokumentierte Berichtspflichten gegenüber interested parties; B.8.5 nennt als teilbare Inhalte technische Dokumentation, Verifikations- und Validierungsaufzeichnungen sowie logs and other system records. Das deckt den Informationsaustausch mit Behörden und Kunden ab."
    },
    {
     "ref": "A.8.2",
     "titel": "System documentation and information for users",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.8.2 verlangt, Nutzern die notwendigen Systeminformationen bereitzustellen. Das berührt den Teilaspekt „information sharing“ nur gegenüber einer Adressatengruppe und deckt weder Testpraktiken noch Vorfallerkennung ab; die tragenden Entsprechungen sind A.8.3 und A.8.4."
    }
   ],
   "luecke": "ISO/IEC 42001 verlangt keinen sektor- oder branchenweiten Informationsaustausch zu AI-Vorfällen (etwa Meldung an Incident-Datenbanken oder Peer-Austausch) und keine unabhängige Prüfung bzw. Red-Teaming durch Dritte; A.8.3 bis A.8.5 begrenzen den Austausch auf Nutzer, Kunden und Behörden."
  },
  "GOVERN 5.1": {
   "iso": [
    {
     "ref": "A.8.3",
     "titel": "External reporting",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.8.3 verlangt, Fähigkeiten bereitzustellen, mit denen interested parties nachteilige Auswirkungen des AI-Systems melden können; B.8.3 adressiert ausdrücklich Nutzer und andere externe Parteien. Das ist der zentrale Rückkanal von außen."
    },
    {
     "ref": "4.2",
     "titel": "Understanding the needs and expectations of interested parties",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "4.2 verlangt, die relevanten interested parties, deren relevante Anforderungen und die Entscheidung zu bestimmen, welche dieser Anforderungen über das AIMS adressiert werden. Das deckt die Ermittlung der Erwartungen ab, nicht aber das laufende Einsammeln, Priorisieren und Einarbeiten externer Rückmeldungen, das GOVERN 5.1 verlangt."
    },
    {
     "ref": "7.4",
     "titel": "Communication",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "7.4 verlangt, die externen Kommunikationen zum AIMS zu bestimmen, einschließlich mit wem und wie kommuniziert wird. Das ist die formale Grundlage der Feedback-Kanäle."
    },
    {
     "ref": "A.10.4",
     "titel": "Customers",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.10.4 verlangt, dass der verantwortungsvolle Ansatz die Erwartungen und Bedarfe der Kunden berücksichtigt; B.10.4 nennt Anforderungen aus Design-, Engineering- und Vertragsphasen. Das ist Feedback von der Kundenseite, nicht von betroffenen Dritten."
    },
    {
     "ref": "A.3.3",
     "titel": "Reporting of concerns",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.3.3 verlangt einen Prozess zur Meldung von Concerns zur Rolle der Organisation über den gesamten Lebenszyklus; B.3.3 verlangt Verfügbarkeit für Beschäftigte und Beauftragte sowie Antwortmechanismen innerhalb angemessener Fristen. Das deckt Feedback von Personen außerhalb des Entwicklungsteams ab."
    },
    {
     "ref": "A.5.4",
     "titel": "Assessing AI system impact on individuals or groups of individuals",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.5.4 verlangt, die Erwartungen betroffener Individuen an die Trustworthiness zu bewerten und Mittel zu ihrer Berücksichtigung im Impact Assessment zu erwägen, und empfiehlt die Konsultation von Forschenden, Fachexperten und Nutzern. Das ist die inhaltliche Verarbeitung externer Perspektiven."
    },
    {
     "ref": "A.5.5",
     "titel": "Assessing societal impacts of AI systems",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.5.5 verlangt die Bewertung und Dokumentation gesellschaftlicher Auswirkungen über den Lebenszyklus. Das entspricht dem societal impacts-Teil der Subkategorie, regelt aber keine Feedback-Erhebung."
    }
   ],
   "luecke": "ISO/IEC 42001 verlangt keine strukturierte Beteiligung betroffener Gruppen bzw. Gemeinschaften (participatory design, Stakeholder-Panels, Konsultation vulnerabler Gruppen); die Konsultation von Experten und Nutzern steht in B.5.4 nur als where necessary-Guidance. Ebenso fehlt ein Verfahren zur Priorisierung eingehenden Feedbacks."
  },
  "GOVERN 5.2": {
   "iso": [
    {
     "ref": "A.6.1.3",
     "titel": "Processes for responsible AI system design and development",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.6.1.3 nennt als Prozesselemente ausdrücklich change control, „approvals and sign-offs necessary at various stages“ und engagement of interested parties. Das ist der Mechanismus, über den bewertetes Feedback in Design und Entwicklung einfließt."
    },
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.6.2.6 verlangt Prozesse für Reparaturen und Updates auch als Reaktion auf „externally identified issues (e.g. non-compliance with customer expectations or legal requirement)“ sowie Support-Prozesse, die regeln, wie Issues und Incidents gemeldet werden. Das ist die Einarbeitung von Feedback in die laufende Implementierung."
    },
    {
     "ref": "10.1",
     "titel": "Continual improvement",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "10.1 verlangt die fortlaufende Verbesserung der Eignung, Angemessenheit und Wirksamkeit des AIMS. Das ist die klauselseitige Grundlage für die regelmäßige, nicht einmalige Einarbeitung von Feedback."
    },
    {
     "ref": "9.3.2",
     "titel": "Management review inputs",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "9.3.2 nennt als Eingangsgröße der Managementbewertung ausdrücklich „changes in needs and expectations of interested parties“; 9.3.3 verlangt daraus Entscheidungen zu erforderlichen Änderungen. Das ist der normierte Adjudikationsmechanismus auf Leitungsebene."
    },
    {
     "ref": "A.10.4",
     "titel": "Customers",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.10.4 verlangt, Kundenerwartungen und -bedarfe zu verstehen und Risiken aus der Kundennutzung zu behandeln, etwa durch geeignete Information des Kunden. Das ist ein geregelter, wiederkehrender Feedbackkanal."
    },
    {
     "ref": "A.5.4",
     "titel": "Assessing AI system impact on individuals or groups of individuals",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.5.4 verlangt, die Erwartungen betroffener Individuen zu bewerten und die Mittel zu ihrer Berücksichtigung als Teil des Impact Assessments zu erwägen. Das ist der normierte Bewertungsschritt zwischen Feedback und Systemänderung."
    },
    {
     "ref": "A.6.2.2",
     "titel": "AI system requirements and specification",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.2.2 verlangt, Systemanforderungen zu revidieren, wenn das System nicht wie beabsichtigt arbeitet oder „new information arises that can be used to change and to improve the requirements“. Das ist die Rückkopplung in die Spezifikation."
    },
    {
     "ref": "A.8.3",
     "titel": "External reporting",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.8.3 verlangt Meldemöglichkeiten für nachteilige Auswirkungen durch interested parties. Damit ist die Erfassungsseite des Feedbacks normiert, nicht dessen Einarbeitung in Design und Implementierung."
    }
   ],
   "luecke": "Der doppelte Baseline-Eintrag wurde zu einem Eintrag konsolidiert. ISO/IEC 42001 regelt keinen formalen Adjudikationsprozess für eingehendes Feedback (Zuständigkeit, Bewertungskriterien, Reaktionsfristen, Rückmeldung an die meldende Partei); A.8.3 fordert nur die Meldemöglichkeit selbst."
  },
  "GOVERN 6.1": {
   "iso": [
    {
     "ref": "A.10.2",
     "titel": "Allocating responsibilities",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.10.2 verlangt, die Verantwortlichkeiten im Lebenszyklus zwischen Organisation, Partnern, Lieferanten, Kunden und Dritten zuzuordnen; B.10.2 verlangt, alle beteiligten Parteien samt Rollen zu dokumentieren und ihre Verantwortlichkeiten zu bestimmen. Das adressiert die Risiken aus Drittbeteiligung unmittelbar."
    },
    {
     "ref": "A.10.3",
     "titel": "Suppliers",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.10.3 verlangt einen Prozess, der sicherstellt, dass bezogene Dienste, Produkte und Materialien zum verantwortungsvollen Ansatz der Organisation passen; B.10.3 verlangt, Lieferantentypen und deren Risikoniveau bei Auswahl, Anforderungen und laufender Überwachung zu berücksichtigen. Das ist die Kern-Policy für Drittparteirisiken."
    },
    {
     "ref": "8.1",
     "titel": "Operational planning and control",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "8.1 verlangt ausdrücklich, dass externally provided processes, products or services, die für das AIMS relevant sind, gesteuert werden. Die Klausel ist damit einschlägig, bleibt aber generisch und ohne AI-spezifische Drittparteianforderungen."
    },
    {
     "ref": "A.7.3",
     "titel": "Acquisition of data",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.7.3 verlangt, Details zu Beschaffung und Auswahl der genutzten Daten zu bestimmen und zu dokumentieren; B.7.3 nennt dabei ausdrücklich data rights (e.g. PII, copyright), prior handling of the data und provenance of the data. Das ist der einzige textliche Anknüpfungspunkt für Rechte Dritter."
    },
    {
     "ref": "A.7.5",
     "titel": "Data provenance",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.7.5 verlangt einen dokumentierten Prozess zur Erfassung der Datenprovenienz über den Lebenszyklus; B.7.5 verlangt zu erwägen, ob Maßnahmen zur Verifikation der Provenienz erforderlich sind. Das stützt die Prüfung fremder Rechtspositionen an Daten."
    },
    {
     "ref": "A.9.2",
     "titel": "Processes for responsible use of AI systems",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.9.2 verlangt dokumentierte Prozesse für die verantwortungsvolle Nutzung; B.9.2 nennt approved sourcing requirements und legal requirements applicable to the organization, ausdrücklich unabhängig davon, ob das System selbst entwickelt oder von Dritten bezogen wurde. Das ist der Policy-Anker für Drittbezug."
    },
    {
     "ref": "A.4.2",
     "titel": "Resource documentation",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "B.4.2 stellt klar, dass Ressourcen durch die Organisation selbst, durch Kunden oder durch Dritte bereitgestellt werden können, und verlangt deren Dokumentation. Das macht Drittkomponenten sichtbar, regelt aber keine Risikobehandlung."
    }
   ],
   "luecke": "ISO/IEC 42001 enthält kein Control zu geistigem Eigentum oder Lizenzkonformität; Annex A kennt keine IP-Anforderung, und nur B.7.3 nennt data rights (e.g. PII, copyright) als Guidance zur Datenbeschaffung. IP-Risiken bei Modellen, vortrainierten Gewichten, Code und generierten Outputs sowie Freistellungs- und Vertragsanforderungen bleiben ungeregelt."
  },
  "GOVERN 6.2": {
   "iso": [
    {
     "ref": "A.10.3",
     "titel": "Suppliers",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.10.3 verlangt, dass die Organisation vom Lieferanten Korrekturmaßnahmen verlangt, wenn dessen AI-System oder Komponenten nicht wie beabsichtigt arbeiten oder zu nicht ansatzkonformen Auswirkungen führen können, und dass Umfang der laufenden Überwachung risikoabhängig festgelegt wird. Das ist die Kernentsprechung zum Umgang mit Drittparteifehlern."
    },
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.6 verlangt die Festlegung der Betriebselemente einschließlich repairs, updates and support; B.6.2.6 stellt klar, dass Support je nach Bezugsweg intern, extern oder beides sein kann und Support-Prozesse Meldewege, SLAs und Metriken berücksichtigen müssen. Das deckt die Reaktion auf Ausfälle bezogener Systeme ab."
    },
    {
     "ref": "10.2",
     "titel": "Nonconformity and corrective action",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "10.2 verlangt Reaktion auf Nichtkonformitäten, Ursachenbeseitigung, Prüfung auf gleichartige Fälle und dokumentierte Nachweise der Wirksamkeit. Das ist die formale Aufarbeitung eines Ausfalls, nicht die Notfallvorsorge."
    },
    {
     "ref": "8.1",
     "titel": "Operational planning and control",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "8.1 verlangt, die Wirksamkeit der Controls zu überwachen, bei Nichterreichen Korrekturmaßnahmen zu erwägen, die Folgen unbeabsichtigter Änderungen zu bewerten und extern bereitgestellte Prozesse, Produkte und Dienste zu steuern. Das ist der klauselseitige Anker für die Beherrschung von Drittparteistörungen."
    },
    {
     "ref": "A.10.2",
     "titel": "Allocating responsibilities",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.10.2 verlangt die Zuordnung der Verantwortlichkeiten zwischen Organisation, Partnern, Lieferanten, Kunden und Dritten. Damit ist im Störfall geklärt, wer welche Maßnahme schuldet, nicht aber welche Notfallmaßnahme greift."
    },
    {
     "ref": "A.6.2.7",
     "titel": "AI system technical documentation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.2.7 verlangt die Dokumentation eines „plan for managing failures“ und nennt rollback plan, „turning off features of the AI system“ und die Benachrichtigung von Kunden und Nutzern. Das adressiert eigene Systemausfälle; Ausfälle in Daten oder Systemen Dritter, auf die GOVERN 6.2 abstellt, sind nicht gesondert geregelt."
    },
    {
     "ref": "A.8.4",
     "titel": "Communication of incidents",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.8.4 verlangt einen dokumentierten Plan zur Kommunikation von Incidents an die Nutzer; B.8.4 erlaubt die Integration in das allgemeine Incident-Management, mahnt aber AI-spezifische Besonderheiten an. Das deckt die Kommunikationsseite eines Drittparteivorfalls ab."
    }
   ],
   "luecke": "ISO/IEC 42001 verlangt keine Notfall- bzw. Kontinuitätsplanung im engeren Sinne für hochriskante Drittparteisysteme: Fallback- bzw. Degraded-Mode-Betrieb, Exit-Strategie und Lieferantensubstitution, Eskalations- und Wiederanlaufzeiten sowie vertragliche Kontinuitätszusagen sind nicht normiert. Auch eine Risikoklassifikation von Lieferanten als high-risk fehlt; B.10.3 verlangt lediglich, das Risikoniveau zu berücksichtigen."
  },
  "MANAGE 1.1": {
   "iso": [
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.4 verlangt dokumentierte Verifizierungs- und Validierungsmaßnahmen samt Bewertungskriterien; das KI-System ist gegen diese Kriterien zu bewerten und bei Nichterfüllung sind Zweckbestimmung, Leistungsanforderungen und Defizite neu zu erwägen. Das entspricht der NIST-Feststellung, ob das System seinen Zweck und seine Ziele erreicht."
    },
    {
     "ref": "A.6.2.5",
     "titel": "AI system deployment",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.5 fordert einen Deployment-Plan und die Erfüllung festgelegter Anforderungen vor dem Einsatz; die Guidance nennt ausdrücklich Release-Kriterien, zu erreichende Leistungsmetriken sowie Management-Freigaben und Sign-offs. Damit ist die Entscheidung, ob das Deployment fortgesetzt wird, normativ verankert."
    },
    {
     "ref": "A.6.1.3",
     "titel": "Processes for responsible AI system design and development",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.1.3 verlangt dokumentierte Prozesse für verantwortungsvolle Entwicklung; die Guidance listet Release-Kriterien sowie „approvals and sign-offs necessary at various stages“. Der Fokus liegt auf der Prozessdefinition, nicht auf der konkreten Einzelfallentscheidung."
    },
    {
     "ref": "A.9.2",
     "titel": "Processes for responsible use of AI systems",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.9.2 fordert dokumentierte Prozesse für die verantwortungsvolle Nutzung; die Guidance nennt als Erwägungen zur Entscheidung über die Nutzung eines KI-Systems erforderliche Genehmigungen, Kosten, Beschaffungsanforderungen und rechtliche Anforderungen. Deckt die Nutzungsseite der Go/No-Go-Entscheidung ab."
    },
    {
     "ref": "A.9.3",
     "titel": "Objectives for responsible use of AI system",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.9.3 verlangt dokumentierte Ziele für die verantwortungsvolle Nutzung (u. a. Fairness, Zuverlässigkeit, Sicherheit), die nach B.6.2.4 ausdrücklich als Bewertungsmaßstab in die Evaluierung einfließen. Liefert die „stated objectives“, gegen die gemessen wird."
    },
    {
     "ref": "A.9.4",
     "titel": "Intended use of the AI system",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.9.4 verlangt, dass das KI-System gemäß seiner Zweckbestimmung und Begleitdokumentation genutzt wird; bei Bedenken hinsichtlich Auswirkungen sind diese intern und an Lieferanten zu kommunizieren. Adressiert die Zweckkonformität, nicht aber die formale Fortsetzungsentscheidung."
    },
    {
     "ref": "A.5.2",
     "titel": "AI system impact assessment process",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.5.2 fordert einen Impact-Assessment-Prozess; die Guidance nennt als Verwendungszweck ausdrücklich, dass das Ergebnis Reviews und Genehmigungen auslösen kann. Nur mittelbarer Beitrag zur Fortsetzungsentscheidung."
    }
   ],
   "luecke": "ISO 42001 fordert Release-Kriterien und Freigaben, aber keine ausdrücklich dokumentierte Go/No-Go-Entscheidung mit benannter Entscheidungsinstanz und definierten Abbruchkriterien; die Entscheidung, Entwicklung oder Deployment einzustellen, ist nicht als eigenes Nachweisdokument gefordert."
  },
  "MANAGE 1.2": {
   "iso": [
    {
     "ref": "6.1.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "6.1.2 d)/e) verlangt die Analyse von Konsequenzen und realistischer Eintrittswahrscheinlichkeit, die Bestimmung von Risikoniveaus und ausdrücklich „prioritize the assessed risks for risk treatment“. Das ist inhaltlich deckungsgleich mit der NIST-Forderung nach Priorisierung anhand Impact und Likelihood."
    },
    {
     "ref": "6.1.3",
     "titel": "AI risk treatment",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "6.1.3 fordert, die Ergebnisse der Risikobewertung zu berücksichtigen, geeignete Behandlungsoptionen auszuwählen und einen Risikobehandlungsplan zu formulieren. Damit wird die priorisierte Behandlung dokumentierter Risiken normativ abgedeckt."
    },
    {
     "ref": "6.1.1",
     "titel": "Actions to address risks and opportunities — General",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.1.1 verlangt etablierte KI-Risikokriterien, die akzeptable von nicht akzeptablen Risiken unterscheiden und Risikobewertung, -behandlung und Wirkungsbeurteilung stützen. Diese Kriterien sind die Grundlage jeder Priorisierung, legen aber selbst keine Rangfolge fest."
    },
    {
     "ref": "6.1.4",
     "titel": "AI system impact assessment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.1.4 verlangt die Ermittlung potenzieller Konsequenzen für Individuen, Gruppen und Gesellschaften und schreibt vor, deren Ergebnis in der Risikobewertung nach 6.1.2 zu berücksichtigen. Liefert damit die Impact-Dimension der Priorisierung."
    },
    {
     "ref": "8.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "8.2 verpflichtet zur Durchführung der Risikobewertungen nach 6.1.2 in geplanten Intervallen bzw. bei wesentlichen Änderungen und zur Aufbewahrung der Ergebnisse. Stellt sicher, dass die Priorisierung tatsächlich und wiederholt operativ erfolgt."
    },
    {
     "ref": "8.3",
     "titel": "AI risk treatment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "8.3 verlangt die Umsetzung des Risikobehandlungsplans und die Verifizierung seiner Wirksamkeit sowie die Revalidierung unwirksamer Behandlungsoptionen. Betrifft die Umsetzung der priorisierten Behandlung, nicht die Priorisierung selbst."
    }
   ],
   "luecke": "ISO 42001 verankert die Priorisierung über Risikokriterien (6.1.1) sowie Konsequenz- und Wahrscheinlichkeitsanalyse (6.1.2), nennt jedoch verfügbare Ressourcen oder verfügbare Methoden nicht ausdrücklich als zulässiges Priorisierungskriterium."
  },
  "MANAGE 1.3": {
   "iso": [
    {
     "ref": "6.1.3",
     "titel": "AI risk treatment",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "6.1.3 verlangt Auswahl der Behandlungsoptionen, Bestimmung notwendiger Controls im Abgleich mit Annex A, Statement of Applicability, Formulierung des Risikobehandlungsplans sowie dokumentierte Information darüber. Deckt Entwicklung, Planung und Dokumentation der Risikoantworten vollständig ab."
    },
    {
     "ref": "8.3",
     "titel": "AI risk treatment",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "8.3 schreibt vor: „When risk assessments identify new risks that require treatment, a risk treatment process in accordance with 6.1.3 shall be performed for these risks“, und verlangt dokumentierte Ergebnisse aller Risikobehandlungen. Das ist die operative Entsprechung der NIST-Forderung."
    },
    {
     "ref": "6.1.1",
     "titel": "Actions to address risks and opportunities — General",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.1.1 verlangt die Planung von Maßnahmen zur Adressierung von Risiken, deren Integration in AIMS-Prozesse und die Bewertung ihrer Wirksamkeit sowie dokumentierte Information hierzu. Bleibt auf Managementsystemebene und benennt keine Antwortoptionen."
    },
    {
     "ref": "6.1.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.1.2 e) 5) verlangt die Priorisierung der bewerteten Risiken für die Behandlung und stellt damit die von NIST vorausgesetzte Menge der hochprioren Risiken aus der Map-Funktion bereit. Selbst jedoch kein Behandlungsschritt."
    },
    {
     "ref": "6.1.4",
     "titel": "AI system impact assessment",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "6.1.4 liefert über die Impact-Assessment-Ergebnisse, die in der Risikobewertung zu berücksichtigen sind, nur einen Input für die Priorisierung. Zur Entwicklung und Planung der Risikoantworten selbst trifft die Klausel keine Aussage."
    }
   ],
   "luecke": "ISO 42001 spricht generisch von „AI risk treatment options“ und benennt die von NIST genannten Optionen nicht abschließend; ausdrücklich geregelt ist nur die Akzeptanz (Genehmigung der Restrisiken nach 6.1.3), während Risikotransfer (z. B. Versicherung, vertragliche Weitergabe) und Vermeidung nicht als eigene Optionen benannt sind."
  },
  "MANAGE 1.4": {
   "iso": [
    {
     "ref": "6.1.3",
     "titel": "AI risk treatment",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "6.1.3 verlangt ausdrücklich die Genehmigung des Risikobehandlungsplans und die Akzeptanz der Restrisiken durch das benannte Management sowie dokumentierte Information hierzu; die notwendigen Controls sind zudem „available to interested parties, as appropriate“. Das ist die Dokumentation negativer Restrisiken mit Akzeptanz durch den Risikoeigner."
    },
    {
     "ref": "A.10.4",
     "titel": "Customers",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.10.4 fordert die Berücksichtigung von Kundenerwartungen; die Guidance nennt als Beispiel, identifizierte Risiken der Kundennutzung dadurch zu behandeln, dass dem Kunden angemessene Informationen gegeben werden, damit dieser die Risiken selbst behandeln kann, und die Grenzen der Einsatzdomäne zu kommunizieren. Genau die NIST-Forderung gegenüber Downstream-Abnehmern."
    },
    {
     "ref": "A.8.2",
     "titel": "System documentation and information for users",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.8.2 verlangt die Bereitstellung der notwendigen Informationen an Nutzer; die Guidance nennt ausdrücklich technische Grenzen, Angaben zu Genauigkeit und Leistung sowie „relevant information from the impact assessment, including potential benefits and harms“. Damit sind Restrisiken gegenüber Endnutzern offenzulegen."
    },
    {
     "ref": "A.5.3",
     "titel": "Documentation of AI system impact assessments",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.5.3 verlangt die Dokumentation und Aufbewahrung der Impact-Assessment-Ergebnisse; die Guidance nennt vorhersehbaren Fehlgebrauch, negative Auswirkungen sowie „predictable failures, their potential impacts and measures taken to mitigate them“. Liefert die inhaltliche Basis, adressiert aber nicht die Weitergabe an Abnehmer."
    },
    {
     "ref": "A.6.2.7",
     "titel": "AI system technical documentation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.7 verlangt technische Dokumentation je Kategorie interessierter Parteien einschließlich technischer Grenzen (akzeptable Fehlerraten, Robustheit), Risikomanagement-Aktivitäten und Impact-Assessment-Dokumentation. Adressiert Restrisiken aber als Teil der Technikdokumentation, nicht als konsolidierte Restrisikoaussage."
    },
    {
     "ref": "A.8.5",
     "titel": "Information for interested parties",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.8.5 verlangt die Ermittlung und Dokumentation der Berichtspflichten gegenüber interessierten Parteien; die Guidance nennt als zu teilende Inhalte ausdrücklich „risks related to the system“ und „results of impact assessments“. Bleibt jedoch an bestehende rechtliche Pflichten gebunden."
    }
   ],
   "luecke": "ISO 42001 kennt keine aggregierte Restrisikoaussage im Sinne der „sum of all unmitigated risks“: Restrisiken werden intern akzeptiert (6.1.3) und einzelne Grenzen an Nutzer und Kunden kommuniziert, eine geschlossene Auflistung nicht mitigierter negativer Risiken zur Weitergabe an Downstream-Abnehmer ist nicht gefordert."
  },
  "MANAGE 2.1": {
   "iso": [
    {
     "ref": "A.4.2",
     "titel": "Resource documentation",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.4.2 verlangt Identifikation und Dokumentation der für die einzelnen Lebenszyklusphasen erforderlichen Ressourcen; die Guidance begründet dies ausdrücklich damit, dass Ressourcendokumentation „critical for understanding risks, as well as potential AI system impacts“ ist, und verlangt bei fehlender Verfügbarkeit eine Revision von Design- oder Deployment-Anforderungen."
    },
    {
     "ref": "7.1",
     "titel": "Resources",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "7.1 verpflichtet zur Bestimmung und Bereitstellung der für Einrichtung, Umsetzung, Aufrechterhaltung und fortlaufende Verbesserung des AIMS erforderlichen Ressourcen. Erfasst damit auch Ressourcen für das Risikomanagement, stellt aber keinen Bezug zur Reduktion von Ausmaß oder Wahrscheinlichkeit her."
    },
    {
     "ref": "A.4.6",
     "titel": "Human resources",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.4.6 verlangt die Dokumentation der Personalressourcen und Kompetenzen für Entwicklung, Deployment, Betrieb, Change Management, Wartung, Transfer und Decommissioning; die Guidance nennt ausdrücklich Rollen für menschliche Aufsicht und Fachleute für Sicherheit, Safety und Privacy. Deckt die personelle Seite der Risikomanagement-Ressourcen."
    },
    {
     "ref": "A.9.2",
     "titel": "Processes for responsible use of AI systems",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.9.2 verlangt dokumentierte Prozesse für die verantwortungsvolle Nutzung; die Guidance nennt als Erwägung, ob ein bestimmtes KI-System überhaupt genutzt wird, einschließlich „cost (including for ongoing monitoring and maintenance)“. Erfasst Ressourcenerwägung und Nutzungsentscheidung, nicht aber den Vergleich mit Nicht-KI-Alternativen."
    },
    {
     "ref": "A.6.2.2",
     "titel": "AI system requirements and specification",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.6.2.2 verlangt die Dokumentation von Anforderungen und der Begründung, warum ein KI-System entwickelt wird (Business Case, Kundenwunsch, Politik), und die Revision der Anforderungen, wenn das System nicht wie beabsichtigt arbeiten kann. Berührt die Alternativenprüfung nur am Rand."
    }
   ],
   "luecke": "ISO 42001 verlangt an keiner Stelle die Prüfung und Dokumentation tragfähiger Nicht-KI-Alternativen (Systeme, Ansätze, Methoden) als Mittel zur Reduktion von Ausmaß oder Eintrittswahrscheinlichkeit potenzieller Auswirkungen; A.9.2 nennt lediglich allgemeine Erwägungen zur Nutzungsentscheidung."
  },
  "MANAGE 2.2": {
   "iso": [
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.6 verlangt die Festlegung und Dokumentation der Elemente des laufenden Betriebs, mindestens System- und Leistungsüberwachung, Reparaturen, Updates und Support; die Guidance adressiert ausdrücklich Concept und Data Drift sowie das Nachtrainieren, damit das System weiterhin seine Designziele erfüllt. Das erhält den Nutzen des eingesetzten Systems."
    },
    {
     "ref": "10.1",
     "titel": "Continual improvement",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "10.1 verpflichtet zur fortlaufenden Verbesserung von Eignung, Angemessenheit und Wirksamkeit des AIMS. Stützt den Werterhalt, adressiert aber die Managementsystem- und nicht die Systemebene."
    },
    {
     "ref": "7.1",
     "titel": "Resources",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "7.1 verlangt die Bereitstellung der Ressourcen für Aufrechterhaltung und fortlaufende Verbesserung des AIMS; B.4.5 ergänzt, dass für die fortlaufende Verbesserung von KI-Systemen andere Ressourcen erforderlich sein können. Notwendige Voraussetzung, kein Mechanismus des Werterhalts."
    },
    {
     "ref": "9.1",
     "titel": "Monitoring, measurement, analysis and evaluation",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "9.1 verlangt die Festlegung, was zu überwachen und zu messen ist, mit welchen Methoden und wann, sowie die Bewertung von Leistung und Wirksamkeit des AIMS mit dokumentierten Nachweisen. Bezieht sich auf das Managementsystem, nicht unmittelbar auf den Nutzen des Einzelsystems."
    },
    {
     "ref": "A.6.1.3",
     "titel": "Processes for responsible AI system design and development",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.1.3 verlangt dokumentierte Prozesse für verantwortungsvolles Design und Entwicklung; die Guidance nennt Change Control, „usability and controllability“ sowie „engagement of interested parties“. Wirkt auf die Entwicklungsseite, nicht auf den Werterhalt im Betrieb."
    },
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.4 verlangt Bewertungskriterien einschließlich akzeptabler Fehlerraten und die Festlegung der Evaluierungsfrequenz sowie Mechanismen für den Umgang mit schlechter Systemleistung. Sichert die fortlaufende Zielerfüllung, ist aber primär auf Verifizierung und Validierung bezogen."
    },
    {
     "ref": "A.7.2",
     "titel": "Data for development and enhancement of AI system",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.7.2 verlangt definierte Datenmanagementprozesse für Entwicklung und Verbesserung („enhancement“) des KI-Systems; die Guidance nennt ausdrücklich die Repräsentativität der Trainingsdaten gegenüber der operativen Einsatzdomäne. Erhält die Leistungsfähigkeit datenseitig."
    }
   ],
   "luecke": "„Sustain the value“ im Sinne des fortdauernden geschäftlichen Nutzens (z. B. Wertbeitrag, ROI, Nutzenmessung gegenüber der Nicht-KI-Alternative) ist in ISO 42001 nicht adressiert; die Norm zielt auf Konformität, Leistungsfähigkeit und verantwortungsvolle Nutzung."
  },
  "MANAGE 2.3": {
   "iso": [
    {
     "ref": "10.2",
     "titel": "Nonconformity and corrective action",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "10.2 verlangt bei Auftreten einer Nichtkonformität die Reaktion, Korrektur, den Umgang mit den Konsequenzen, Ursachenanalyse, Prüfung auf ähnliche Fälle, Wirksamkeitsbewertung und ggf. Änderungen am AIMS sowie dokumentierte Nachweise. Das ist das Verfahren zur Reaktion auf ein neu erkanntes Problem."
    },
    {
     "ref": "8.3",
     "titel": "AI risk treatment",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "8.3 schreibt ausdrücklich vor, dass bei neu identifizierten behandlungsbeduerftigen Risiken ein Risikobehandlungsprozess nach 6.1.3 durchzuführen ist und unwirksame Behandlungsoptionen zu überprüfen und zu revalidieren sind. Das adressiert das zuvor unbekannte Risiko unmittelbar."
    },
    {
     "ref": "6.1.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.1.2 fordert einen reproduzierbaren Risikobewertungsprozess, der Risiken identifiziert, analysiert und gegen die Risikokriterien bewertet. Liefert das Verfahren, mit dem ein neu aufgetauchtes Risiko eingeordnet wird."
    },
    {
     "ref": "6.1.3",
     "titel": "AI risk treatment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.1.3 definiert den Behandlungsprozess, der nach 8.3 auch auf neu identifizierte Risiken anzuwenden ist, einschließlich Managementgenehmigung und Restrisikoakzeptanz. Prozessgrundlage, aber ohne Vorfall- oder Wiederherstellungsbezug."
    },
    {
     "ref": "8.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "8.2 verlangt Risikobewertungen in geplanten Intervallen und bei wesentlichen vorgeschlagenen oder eingetretenen Änderungen. Das ist der Mechanismus, durch den bislang unbekannte Risiken überhaupt erkannt werden, jedoch keine Reaktions- oder Wiederherstellungsprozedur."
    },
    {
     "ref": "A.3.3",
     "titel": "Reporting of concerns",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.3.3 verlangt einen Prozess zur Meldung von Bedenken über die Rolle der Organisation im KI-Lebenszyklus; die Guidance fordert zeitnahe Eskalation an das Management, Untersuchungs- und Lösungsbefugnisse sowie Reaktionsmechanismen innerhalb angemessener Fristen. Interner Kanal, über den unbekannte Risiken sichtbar werden."
    },
    {
     "ref": "A.6.2.7",
     "titel": "AI system technical documentation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.7 verlangt Dokumentation zum verantwortungsvollen Betrieb; die Guidance nennt ausdrücklich einen Plan zum Umgang mit Ausfällen einschließlich Rollback-Plan, Abschalten von Funktionen und Verfahren zur Untersuchung und Vermeidung von Fehlern. Nächstliegender Anker für Reaktion und Wiederherstellung, aber nur als Dokumentationsanforderung."
    }
   ],
   "luecke": "ISO 42001 enthält keine eigenständige normative Anforderung an Incident-Response- und Recovery-Verfahren (Wiederherstellung des Betriebs, Rollback, Ersatzbetrieb); Reaktion wird über Nichtkonformität (10.2) und Risikobehandlung (8.3) abgebildet, Rollback und Abschalten nur als Annex-B-Guidance zu A.6.2.7."
  },
  "MANAGE 2.4": {
   "iso": [
    {
     "ref": "A.6.2.7",
     "titel": "AI system technical documentation",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.7 verlangt Dokumentation zum verantwortungsvollen Betrieb; die Guidance nennt ausdrücklich Rollback-Plan, „turning off features of the AI system“ sowie die Dokumentation der Rollen des Betriebs- und Verantwortungspersonals speziell für den Umgang mit Systemausfällen. Deckt Mechanismus und Verantwortungszuweisung gemeinsam ab."
    },
    {
     "ref": "A.9.4",
     "titel": "Intended use of the AI system",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.9.4 verlangt, dass das KI-System entsprechend seiner Zweckbestimmung und Begleitdokumentation genutzt wird; die Guidance fordert Überwachung des Betriebs und, wo der Einsatz Bedenken hinsichtlich Auswirkungen oder rechtlicher Anforderungen auslöst, die Kommunikation an das zuständige Personal und an Drittlieferanten sowie Nachweisführung über Event-Logs. Kern der Reaktion auf zweckwidrige Ergebnisse."
    },
    {
     "ref": "A.3.2",
     "titel": "AI roles and responsibilities",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.3.2 verlangt definierte und zugewiesene KI-Rollen und Verantwortlichkeiten; die Guidance nennt als abzudeckende Bereiche u. a. Safety, Performance und Human Oversight. Erfüllt die NIST-Forderung nach zugewiesenen und verstandenen Verantwortlichkeiten."
    },
    {
     "ref": "A.4.6",
     "titel": "Human resources",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.4.6 verlangt die Dokumentation der Personalressourcen und Kompetenzen ausdrücklich auch für Change Management, Transfer und Decommissioning des KI-Systems. Einzige Stelle, an der die Außerbetriebnahme namentlich adressiert ist, allerdings nur ressourcenseitig."
    },
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.6 verlangt definierte Betriebselemente einschließlich Reparaturen und Updates; die Guidance fordert, dass bei Nutzung für nicht vorgesehene oder unerwartete Zwecke die Angemessenheit solcher Nutzungen zu erwägen ist. Führt zu Anpassung oder Außerbetriebnahme, nennt sie aber nicht explizit."
    },
    {
     "ref": "A.8.2",
     "titel": "System documentation and information for users",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.8.2 verlangt die notwendigen Informationen an Nutzer; die Guidance nennt ausdrücklich „how and when to override the system“ sowie den Bedarf menschlicher Aufsicht. Stellt die Übersteuerungsfähigkeit auf Nutzerseite sicher."
    },
    {
     "ref": "A.9.3",
     "titel": "Objectives for responsible use of AI system",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.9.3 verlangt Ziele für verantwortungsvolle Nutzung; die Guidance fordert menschliche Aufsicht einschließlich Prüfern mit „authority to override decisions made by the AI system“ sowie die Meldung von Bedenken bei veränderter Leistungsfähigkeit. Deckt Übersteuerung, nicht aber Deaktivierung."
    },
    {
     "ref": "6.3",
     "titel": "Planning of changes",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "6.3 verlangt lediglich, dass erforderliche Änderungen am AIMS geplant durchgeführt werden; 8.1 ergänzt die Steuerung geplanter und die Überprüfung unbeabsichtigter Änderungen. Trifft die Außerbetriebnahme eines KI-Systems nur mittelbar."
    }
   ],
   "luecke": "ISO 42001 fordert keinen normativen Not-Aus- bzw. Deaktivierungsmechanismus mit definierten Auslöseschwellen und benannter Entscheidungsbefugnis: Decommissioning erscheint nur in A.4.6 als zu dokumentierende Personalressource, Rollback und Abschalten von Funktionen nur als Annex-B-Guidance zu A.6.2.7."
  },
  "MANAGE 3.1": {
   "iso": [
    {
     "ref": "8.1",
     "titel": "Operational planning and control",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "8.1 verlangt ausdrücklich: „The organization shall ensure that externally provided processes, products or services that are relevant to the AI management system are controlled“, und fordert Wirksamkeitsüberwachung der Controls sowie Korrekturmaßnahmen bei Zielverfehlung. Normativer Anker für die Anwendung von Risikocontrols auf Drittressourcen."
    },
    {
     "ref": "A.10.3",
     "titel": "Suppliers",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.10.3 verlangt einen Prozess, der sicherstellt, dass die Nutzung von Lieferantenleistungen dem verantwortungsvollen Ansatz der Organisation entspricht; die Guidance fordert risikoabhängige Lieferantenauswahl, Anforderungen an Lieferanten, „levels of ongoing monitoring and evaluation needed for the suppliers“ sowie Korrekturmaßnahmen des Lieferanten bei Abweichungen."
    },
    {
     "ref": "8.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "8.2 verlangt Risikobewertungen in geplanten Intervallen und bei wesentlichen Änderungen mit Aufbewahrung der Ergebnisse. Liefert die Regelmäßigkeit der Risikobetrachtung, ohne Drittressourcen ausdrücklich zu benennen."
    },
    {
     "ref": "A.10.2",
     "titel": "Allocating responsibilities",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.10.2 verlangt die Aufteilung der Verantwortlichkeiten im KI-Lebenszyklus zwischen Organisation, Partnern, Lieferanten, Kunden und Dritten; die Guidance fordert, alle beteiligten Parteien, ihre Rollen und Verantwortlichkeiten zu dokumentieren. Regelt Zurechnung, nicht die laufende Überwachung."
    },
    {
     "ref": "A.4.2",
     "titel": "Resource documentation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.4.2 verlangt Identifikation und Dokumentation der relevanten Ressourcen je Lebenszyklusphase; die Guidance stellt ausdrücklich fest, dass Ressourcen von der Organisation selbst, von Kunden oder von Dritten bereitgestellt werden können. Schafft die Dokumentationsgrundlage für Drittressourcen."
    },
    {
     "ref": "A.7.3",
     "titel": "Acquisition of data",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.7.3 verlangt die Dokumentation von Details zu Beschaffung und Auswahl der Daten; die Guidance nennt ausdrücklich Datenquellen (gekauft, geteilt, offen, synthetisch), vorherige Handhabung, Datenrechte und Provenienz. Deckt die Datenkomponente von Drittressourcen ab."
    }
   ],
   "luecke": "ISO 42001 regelt die laufende Lieferantenüberwachung nur als Annex-B-Guidance ohne festgelegte Frequenz oder Kennzahlen; die von NIST ebenfalls geforderte Überwachung des Nutzens (benefits) von Drittressourcen ist nicht adressiert."
  },
  "MANAGE 3.2": {
   "iso": [
    {
     "ref": "A.10.3",
     "titel": "Suppliers",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.10.3-Guidance nennt als Lieferantenleistungen ausdrücklich „sourcing datasets, machine learning algorithms or models“ und verlangt, zu dokumentieren, wie KI-Systemkomponenten in die eigenen Systeme integriert werden, sowie Korrekturmaßnahmen des Lieferanten bei nicht erwartungsgemäßer Leistung."
    },
    {
     "ref": "A.4.4",
     "titel": "Tooling resources",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.4.4 verlangt die Dokumentation der Tooling-Ressourcen des KI-Systems; die Guidance nennt ausdrücklich „algorithm types and machine learning models“, Evaluierungsmethoden und Werkzeuge zur Modellentwicklung. Damit sind auch vortrainierte Modelle als zu erfassende und zu bewertende Ressource abgedeckt."
    },
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.6 verlangt System- und Leistungsüberwachung, Reparaturen, Updates und Support im laufenden Betrieb; die Guidance adressiert ausdrücklich Leistungsveränderungen durch Concept oder Data Drift und den daraus folgenden Bedarf an Retraining. Genau die von NIST geforderte Einbindung in die reguläre Überwachung und Wartung."
    },
    {
     "ref": "A.6.2.3",
     "titel": "Documentation of AI system design and development",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.3 verlangt die Dokumentation von Design und Entwicklung; die Guidance nennt den verwendeten Lernalgorithmus und Modelltyp, Hardware- und Softwarekomponenten sowie KI-spezifische Sicherheitsbedrohungen wie Data Poisoning, Model Stealing und Model Inversion. Relevant für die Bewertung vortrainierter Modelle, aber entwicklungsbezogen."
    },
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.4 verlangt Verifizierungs- und Validierungsmaßnahmen und einen Plan zur Bewertung „the AI system components and the whole AI system“ hinsichtlich Auswirkungsrisiken. Erfasst zugekaufte Modellkomponenten, allerdings primär vor dem Release."
    },
    {
     "ref": "A.7.5",
     "titel": "Data provenance",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.7.5 verlangt einen dokumentierten Prozess zur Aufzeichnung der Provenienz der verwendeten Daten über deren Lebenszyklus und den des KI-Systems, inklusive Prüfung, ob Verifizierungsmaßnahmen zur Herkunft erforderlich sind. Erfasst die Datenherkunft, nicht die Modellherkunft."
    }
   ],
   "luecke": "ISO 42001 kennt keinen eigenen Begriff für vortrainierte Basis- bzw. Foundation-Modelle; eine Modell-Provenienz (im Unterschied zur Datenprovenienz nach A.7.5) und die laufende Überwachung von Modellversionen und -updates des Drittanbieters sind nicht ausdrücklich gefordert."
  },
  "MANAGE 4.1": {
   "iso": [
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.6 verlangt die dokumentierten Elemente des laufenden Betriebs mit mindestens System- und Leistungsüberwachung, Reparaturen, Updates und Support; die Guidance fordert Prozesse für Fehlerbehebung, Update-Verfahren mit Zeitplan und Nutzerinformation, Verfahren für Betriebsänderungen sowie Supportwege für die Meldung von Problemen und Vorfällen."
    },
    {
     "ref": "A.8.3",
     "titel": "External reporting",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.8.3 verlangt, Fähigkeiten bereitzustellen, mit denen interessierte Parteien nachteilige Auswirkungen des Systems melden können; die Guidance stellt dies ausdrücklich neben die Betriebsüberwachung. Das ist der Mechanismus zur Erfassung von Rückmeldungen von Nutzern und anderen KI-Akteuren."
    },
    {
     "ref": "10.2",
     "titel": "Nonconformity and corrective action",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "10.2 verlangt Reaktion und Korrektur bei Nichtkonformitäten, Umgang mit den Konsequenzen, Ursachenbeseitigung und Wirksamkeitsbewertung mit dokumentierten Nachweisen. Deckt die Vorfallreaktion, nicht die Wiederherstellung."
    },
    {
     "ref": "8.1",
     "titel": "Operational planning and control",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "8.1 verlangt die Steuerung geplanter Änderungen und die Überprüfung der Folgen unbeabsichtigter Änderungen mit Maßnahmen zur Minderung nachteiliger Effekte. Entspricht dem von NIST geforderten Change Management im Betrieb."
    },
    {
     "ref": "9.1",
     "titel": "Monitoring, measurement, analysis and evaluation",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "9.1 verlangt die Festlegung von Überwachungs- und Messgegenständen, Methoden und Zeitpunkten sowie dokumentierte Nachweise der Ergebnisse. Gibt dem Monitoring-Plan die normative Struktur, bezieht sich aber auf das AIMS."
    },
    {
     "ref": "A.10.4",
     "titel": "Customers",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.10.4 verlangt, dass der verantwortungsvolle Ansatz die Erwartungen und Bedarfe der Kunden berücksichtigt, die auch als vertragliche oder Nutzungsanforderungen auftreten können. Deckt die Erfassung von Rückmeldungen der Kundenseite ab."
    },
    {
     "ref": "A.6.2.8",
     "titel": "AI system recording of event logs",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.8 verlangt Event-Logging mindestens während der Nutzung; die Guidance nennt Nachvollziehbarkeit des bestimmungsgemäßen Betriebs und die Erkennung von Leistung außerhalb der vorgesehenen Betriebsbedingungen. Technische Grundlage des Post-Deployment-Monitorings."
    },
    {
     "ref": "A.9.3",
     "titel": "Objectives for responsible use of AI system",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.9.3-Guidance verlangt menschliche Aufsicht mit Befugnis zur Übersteuerung von Systementscheidungen, Überwachung der Ausgabegenauigkeit und Meldung von Bedenken zu Ausgaben und Leistungsänderungen. Deckt Override, nicht aber ein Widerspruchsverfahren."
    }
   ],
   "luecke": "ISO 42001 fordert weder ein Widerspruchs- bzw. Rechtsbehelfsverfahren (appeal) für von Systementscheidungen Betroffene noch ein normatives Decommissioning-Verfahren oder eigenständige Recovery-Anforderungen; Decommissioning erscheint nur in A.4.6 als Personalressource."
  },
  "MANAGE 4.2": {
   "iso": [
    {
     "ref": "10.1",
     "titel": "Continual improvement",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "10.1 verpflichtet zur fortlaufenden Verbesserung von Eignung, Angemessenheit und Wirksamkeit des AIMS und ist damit die normative Basis der von NIST geforderten kontinuierlichen Verbesserungsaktivitäten."
    },
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.6-Guidance verlangt Prozesse für Systemupdates einschließlich betroffener Komponenten, Update-Zeitplan und Nutzerinformation zum Update-Inhalt sowie Leistungskriterien mit Metriken und akzeptablen Werten. Damit sind Verbesserungsaktivitäten messbar in die Systemupdates integriert."
    },
    {
     "ref": "4.2",
     "titel": "Understanding the needs and expectations of interested parties",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "4.2 verlangt die Bestimmung der relevanten interessierten Parteien und ihrer Bedarfe und Erwartungen; 9.3.2 c) fordert deren Veränderungen als Input der Managementbewertung. Verankert die Einbeziehung interessierter Parteien, aber nicht als regelmäßige Beteiligung am Systemupdate."
    },
    {
     "ref": "6.2",
     "titel": "AI objectives and planning to achieve them",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.2 verlangt KI-Ziele, die messbar (soweit praktikabel), überwacht, kommuniziert und aktualisiert sind, samt Festlegung von Maßnahmen, Ressourcen, Verantwortlichkeiten, Terminen und Ergebnisbewertung. Liefert die Messbarkeit, ohne Systemupdates zu adressieren."
    },
    {
     "ref": "7.4",
     "titel": "Communication",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "7.4 verlangt die Festlegung der internen und externen Kommunikation mit Inhalt, Zeitpunkt, Adressaten und Methode. Bildet den formalen Rahmen für den Austausch mit interessierten Parteien und KI-Akteuren."
    },
    {
     "ref": "9.1",
     "titel": "Monitoring, measurement, analysis and evaluation",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "9.1 verlangt die Festlegung, was gemessen wird und mit welchen Methoden, um valide Ergebnisse sicherzustellen, sowie die Bewertung von Leistung und Wirksamkeit. Stellt die Messgrundlage der Verbesserungsaktivitäten."
    },
    {
     "ref": "9.3.3",
     "titel": "Management review results",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "9.3.3 verlangt, dass die Ergebnisse der Managementbewertung Entscheidungen zu Verbesserungsmöglichkeiten und erforderlichen AIMS-Änderungen umfassen, mit dokumentierten Nachweisen. Steuert Verbesserung auf Managementebene."
    },
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.4 verlangt dokumentierte Bewertungskriterien einschließlich akzeptabler Fehlerraten und die Festlegung der Evaluierungsfrequenz, die sich aus dem Impact Assessment ergeben kann. Liefert die messbaren Kriterien für Verbesserungen an Systemupdates."
    }
   ],
   "luecke": "ISO 42001 verankert die Einbeziehung interessierter Parteien auf Managementsystemebene (4.2, 7.4, 9.3.2), fordert jedoch keine regelmäßige, dokumentierte Beteiligung interessierter Parteien und KI-Akteure an der Verbesserung des einzelnen KI-Systems; „engagement of interested parties“ erscheint nur als Annex-B-Guidance zu A.6.1.3."
  },
  "MANAGE 4.3": {
   "iso": [
    {
     "ref": "10.2",
     "titel": "Nonconformity and corrective action",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "10.2 verlangt Reaktion und Korrektur, Umgang mit den Konsequenzen, Ursachenermittlung, Prüfung auf ähnliche Fälle, Wirksamkeitsbewertung sowie dokumentierte Nachweise zu Art der Nichtkonformitäten und ergriffenen Maßnahmen. Deckt Verfolgung, Reaktion und Dokumentation von Vorfällen und Fehlern."
    },
    {
     "ref": "A.8.4",
     "titel": "Communication of incidents",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.8.4 verlangt einen dokumentierten Plan zur Kommunikation von Vorfällen an die Nutzer des KI-Systems; die Guidance fordert die Kenntnis der Meldepflichten nach Art des Vorfalls, Zeitrahmen, zu unterrichtende Behörden und erforderliche Detailtiefe. Kern der NIST-Forderung nach Vorfallkommunikation."
    },
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.6-Guidance verlangt Prozesse für Reaktion und Reparatur bei Fehlern und Ausfällen, Kommunikation von Betriebsänderungen an Nutzer sowie Supportprozesse dazu, wie Probleme und Vorfälle gemeldet werden. Operative Grundlage der Vorfallbearbeitung."
    },
    {
     "ref": "A.6.2.7",
     "titel": "AI system technical documentation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.7-Guidance verlangt einen dokumentierten Plan zum Umgang mit Ausfällen einschließlich Benachrichtigung von Kunden und Nutzern, Angaben zu Systemausfällen und ihrer Minderung sowie Verfahren zur Untersuchung von Fehlern. Verbindet Vorfalldokumentation und Wiederherstellungsplanung."
    },
    {
     "ref": "A.6.2.8",
     "titel": "AI system recording of event logs",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.8 verlangt Event-Logging mindestens während der Nutzung zur Nachvollziehbarkeit und zur Erkennung von Leistung außerhalb der vorgesehenen Betriebsbedingungen, mit definierten Aufbewahrungsfristen. Stützt die Nachverfolgung und Dokumentation von Vorfällen und Fehlern."
    },
    {
     "ref": "A.8.3",
     "titel": "External reporting",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.8.3 verlangt Fähigkeiten für interessierte Parteien, nachteilige Auswirkungen (z. B. Unfairness) zu melden. Bildet den eingehenden Kanal, über den Vorfälle und Fehler betroffener Gruppen erfasst werden."
    },
    {
     "ref": "A.8.5",
     "titel": "Information for interested parties",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.8.5 verlangt die Ermittlung und Dokumentation der Pflichten zur Berichterstattung an interessierte Parteien; die Guidance nennt Kunden und Regulierer sowie als Inhalte Risiken, Impact-Assessment-Ergebnisse und Systemprotokolle innerhalb angemessener Fristen. Reicht über Nutzer hinaus, bleibt aber pflichtengebunden."
    },
    {
     "ref": "9.3.2",
     "titel": "Management review inputs",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "9.3.2 d) 1) verlangt, Trends bei Nichtkonformitäten und Korrekturmaßnahmen als Input der Managementbewertung zu berücksichtigen. Nur aggregierte Nachbetrachtung, keine Vorfallkommunikation."
    }
   ],
   "luecke": "Die Kommunikation von Vorfällen an betroffene Gemeinschaften bzw. die betroffene Öffentlichkeit ist nicht gefordert: A.8.4 adressiert ausdrücklich nur Nutzer, A.8.5 nur bestehende Berichtspflichten. Ein Wiederherstellungsverfahren (recovery) nach Vorfällen ist normativ nicht verankert."
  },
  "MAP 1.1": {
   "iso": [
    {
     "ref": "4.1",
     "titel": "Understanding the organization and its context",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "4.1 verlangt die Bestimmung externer und interner Themen und ausdrücklich die Berücksichtigung des „intended purpose of the AI systems“ sowie der eigenen Rolle. Damit ist die Kernforderung von MAP 1.1 (Zweck und Kontext verstehen) normativ abgedeckt."
    },
    {
     "ref": "6.1.4",
     "titel": "AI system impact assessment",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "6.1.4 fordert die Bewertung der Folgen von „deployment, intended use and foreseeable misuse“ unter Berücksichtigung des „specific technical and societal context where the AI system is deployed and applicable jurisdictions“. Das deckt Einsatzumfeld, Rechtsrahmen und positive wie negative Auswirkungen ab; das Ergebnis ist zu dokumentieren."
    },
    {
     "ref": "4.2",
     "titel": "Understanding the needs and expectations of interested parties",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "4.2 verlangt die Bestimmung relevanter interessierter Parteien und ihrer Anforderungen und trifft damit die NIST-Forderung nach Nutzertypen und deren Erwartungen. Normen und gesellschaftliche Erwartungen werden jedoch nur mittelbar über die interessierten Parteien erfasst."
    },
    {
     "ref": "A.5.2",
     "titel": "AI system impact assessment process",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.5.2 verlangt einen Prozess zur Bewertung der Folgen über den gesamten Lebenszyklus; B.5.2 nennt als Auslöser Kritikalität des Zwecks, Komplexität der Technologie und Sensitivität der Daten. Die Lebenszyklusperspektive von MAP 1.1 wird so erfasst, nicht aber die vollständige Kontextdokumentation."
    },
    {
     "ref": "A.5.4",
     "titel": "Assessing AI system impact on individuals or groups of individuals",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.5.4 verlangt Bewertung und Dokumentation der Auswirkungen auf Individuen und Gruppen; B.5.4 nennt Fairness, Transparenz, Sicherheit, Privatheit und Menschenrechte als Bewertungsfelder. Das entspricht dem NIST-Punkt „potential positive and negative impacts ... to individuals, communities“."
    },
    {
     "ref": "A.5.5",
     "titel": "Assessing societal impacts of AI systems",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.5.5 verlangt die Bewertung gesellschaftlicher Auswirkungen; B.5.5 nennt ausdrücklich Umweltnachhaltigkeit, Wirtschaft, Gesundheit und Werte. Damit sind die NIST-Adressaten „society, and the planet“ abgedeckt."
    },
    {
     "ref": "A.6.2.2",
     "titel": "AI system requirements and specification",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.2.2 verlangt die Dokumentation der Begründung und Ziele eines KI-Systems sowie Anforderungen, die den gesamten Lebenszyklus umfassen. Das trifft die NIST-Forderung nach dokumentierten Annahmen zum Systemzweck und Risiken über den Lebenszyklus."
    },
    {
     "ref": "A.6.2.7",
     "titel": "AI system technical documentation",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "B.6.2.7 nennt als Dokumentationselemente „technical assumptions about its deployment and operation“ und „technical limitations (e.g. acceptable error rates, accuracy, reliability, robustness)“. Das betrifft nur den technischen Teilaspekt von Annahmen und Grenzen, nicht das Kontext-Mapping insgesamt."
    }
   ],
   "luecke": "ISO 42001 verlangt nicht, TEVV-Ansätze und Systemmetriken bereits in der Kontext-/Mapping-Phase festzulegen; Mess- und Prüfkriterien entstehen erst nachgelagert in A.6.2.4 und A.6.2.6. Ebenso fehlt eine ausdrückliche Pflicht, kontextspezifische Normen und gesellschaftliche Erwartungen jenseits der interessierten Parteien zu erheben."
  },
  "MAP 1.2": {
   "iso": [
    {
     "ref": "7.2",
     "titel": "Competence",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "7.2 verlangt, die notwendige Kompetenz zu bestimmen, sicherzustellen und als dokumentierte Information nachzuweisen. Das deckt Kompetenzen, Fähigkeiten und deren Dokumentation nach MAP 1.2 ab."
    },
    {
     "ref": "A.4.6",
     "titel": "Human resources",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.4.6 verlangt die Dokumentation der eingesetzten Humanressourcen und ihrer Kompetenzen über alle Lebenszyklusphasen. B.4.6 fordert ausdrücklich „the need for diverse expertise“ und nennt Data Scientists, Human-Oversight-Rollen, Trustworthiness-Experten und Domänenexperten."
    },
    {
     "ref": "A.3.2",
     "titel": "AI roles and responsibilities",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.3.2 verlangt die Definition und Zuweisung von KI-Rollen; B.3.2 listet Risikomanagement, Impact Assessment, Sicherheit, Safety, Privacy, Entwicklung und Human Oversight als abzudeckende Bereiche. Die interdisziplinäre Besetzung wird damit strukturell verlangt, aber nicht als Beteiligungsnachweis dokumentiert."
    },
    {
     "ref": "A.6.1.3",
     "titel": "Processes for responsible AI system design and development",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.1.3 fordert als Bestandteil verantwortlicher Entwicklungsprozesse die Festlegung erforderlicher „expertise (subject matter domain or other)“ sowie die „engagement of interested parties“. Das entspricht dem NIST-Ziel interdisziplinärer Zusammenarbeit, ohne sie zu priorisieren."
    },
    {
     "ref": "7.1",
     "titel": "Resources",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "7.1 verpflichtet zur Bereitstellung der für das AIMS erforderlichen Ressourcen, worunter auch personelle Kapazitäten fallen. Die Klausel bleibt generisch und adressiert weder Interdisziplinarität noch Diversität."
    },
    {
     "ref": "A.5.4",
     "titel": "Assessing AI system impact on individuals or groups of individuals",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "B.5.4 empfiehlt, bei Bedarf Experten wie Forschende, Fachleute und Nutzende zu konsultieren, um Auswirkungen vollständig zu verstehen. Das ist nur ein punktueller Beteiligungsaspekt und keine durchgängige Kapazitätsanforderung."
    }
   ],
   "luecke": "Demografische Diversität des Teams selbst wird von ISO 42001 nicht gefordert; B.4.6 verknüpft demografische Gruppen nur mit Trainingsdatensätzen. Es fehlt zudem die NIST-Forderung, interdisziplinäre Zusammenarbeit zu priorisieren und die Beteiligung der AI-Akteure nachvollziehbar zu dokumentieren."
  },
  "MAP 1.3": {
   "iso": [
    {
     "ref": "4.1",
     "titel": "Understanding the organization and its context",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "4.1 verlangt, die für den Zweck der Organisation relevanten Themen zu bestimmen, die das Erreichen der beabsichtigten Ergebnisse des AIMS beeinflussen. Damit ist der Bezug zwischen Organisationsauftrag und KI-Einsatz normativ verankert."
    },
    {
     "ref": "5.2",
     "titel": "AI policy",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "5.2 fordert eine KI-Politik, die „appropriate to the purpose of the organization“ ist, einen Rahmen für KI-Ziele bietet und als dokumentierte Information vorliegt. Mission und Zielrahmen sind damit dokumentiert."
    },
    {
     "ref": "6.2",
     "titel": "AI objectives and planning to achieve them",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "6.2 verlangt KI-Ziele auf relevanten Funktionen und Ebenen, die konsistent zur KI-Politik, messbar, überwacht, kommuniziert und als dokumentierte Information verfügbar sind. Das deckt „relevant goals for the AI technology ... documented“ vollständig ab."
    },
    {
     "ref": "5.1",
     "titel": "Leadership and commitment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "5.1 verpflichtet die oberste Leitung sicherzustellen, dass KI-Politik und KI-Ziele mit der strategischen Ausrichtung der Organisation vereinbar sind. Das stellt die Verbindung zur Mission her, ohne sie eigenständig zu dokumentieren."
    },
    {
     "ref": "A.2.2",
     "titel": "AI policy",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.2.2 verlangt, dass die KI-Politik von Geschäftsstrategie sowie organisationalen Werten und Kultur informiert wird. Die Mission wird so in die dokumentierte KI-Politik überführt."
    },
    {
     "ref": "A.6.1.2",
     "titel": "Objectives for responsible development of AI system",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.1.2 verlangt die Identifikation und Dokumentation von Zielen für die verantwortliche Entwicklung und deren Integration in den Entwicklungslebenszyklus. Das konkretisiert die Organisationsziele für die KI-Technologie."
    },
    {
     "ref": "A.9.3",
     "titel": "Objectives for responsible use of AI system",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.9.3 fordert dokumentierte Ziele für die verantwortliche Nutzung von KI-Systemen (z. B. Fairness, Transparenz, Sicherheit). Der Bezug zur übergeordneten Mission der Organisation bleibt dabei indirekt."
    }
   ],
   "luecke": null
  },
  "MAP 1.4": {
   "iso": [
    {
     "ref": "A.6.2.2",
     "titel": "AI system requirements and specification",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.6.2.2 verlangt ausdrücklich die Dokumentation, „why the AI system is to be developed, for example, is this driven by a business case, customer request or by government policy“, und fordert die erneute Prüfung der Anforderungen, wenn das System nicht wie beabsichtigt arbeitet. Damit sind sowohl die Erstdefinition des Geschäftsnutzens als auch die Neubewertung bestehender Systeme abgedeckt."
    },
    {
     "ref": "4.1",
     "titel": "Understanding the organization and its context",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "4.1 verlangt die Berücksichtigung des beabsichtigten Zwecks der entwickelten, bereitgestellten oder genutzten KI-Systeme und die Bestimmung der eigenen Rolle. Der geschäftliche Nutzungskontext wird so erfasst, nicht aber dessen Wertbeitrag."
    },
    {
     "ref": "5.1",
     "titel": "Leadership and commitment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "5.1 verlangt die Integration der AIMS-Anforderungen in die Geschäftsprozesse der Organisation und die Vereinbarkeit mit der strategischen Ausrichtung. Das verankert den geschäftlichen Nutzungskontext auf Leitungsebene."
    },
    {
     "ref": "A.10.4",
     "titel": "Customers",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "Der in der Baseline genannte Titel „Customers“ gehört zu A.10.4: Die Organisation muss Kundenerwartungen und -beduerfnisse in ihrem verantwortlichen Ansatz berücksichtigen, auch in Form vertraglicher Anforderungen. Das prägt den Geschäftsnutzungskontext bei Anbieterrollen unmittelbar."
    },
    {
     "ref": "A.2.2",
     "titel": "AI policy",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "Die Baseline führt „B.2.2 Customers“; inhaltlich ist A.2.2 AI policy gemeint, denn B.2.2 verlangt, dass die KI-Politik von der „business strategy“ informiert wird. Damit wird der geschäftliche Rahmen des KI-Einsatzes dokumentiert festgelegt."
    },
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "B.6.2.6 verlangt, die Angemessenheit zu prüfen, wenn KI-Systeme für andere als die vorgesehenen Zwecke genutzt werden. Das stützt die Neubewertung bestehender Systeme, ohne den Geschäftswert zu adressieren."
    },
    {
     "ref": "A.9.2",
     "titel": "Processes for responsible use of AI systems",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "B.9.2 nennt als Erwägungen für den Einsatz eines KI-Systems erforderliche Genehmigungen, Kosten einschließlich Monitoring und Wartung sowie genehmigte Bezugsanforderungen. Das berührt die Nutzenentscheidung nur am Rand."
    }
   ],
   "luecke": "Eine explizite Bewertung oder Quantifizierung des Geschäftswerts als Entscheidungsgrundlage fordert ISO 42001 nicht; Kosten- und Nutzenerwägungen erscheinen nur als Beispiele in B.9.2 und B.6.2.2. Auch eine periodische Wert-Neubewertung im Bestand ist nicht als eigene Anforderung verankert."
  },
  "MAP 1.5": {
   "iso": [
    {
     "ref": "6.1.1",
     "titel": "Actions to address risks and opportunities — General",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "6.1.1 (korrekter Titel: General, nicht „Objective“) verlangt, KI-Risikokriterien zu etablieren und aufrechtzuerhalten, die „distinguishing acceptable from non-acceptable risks“ unterstützen. Das ist die normative Entsprechung der organisationalen Risikotoleranz, mit Pflicht zur Aufbewahrung dokumentierter Information."
    },
    {
     "ref": "6.1.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.1.2 verlangt, die Ergebnisse der Risikoanalyse mit den Risikokriterien nach 6.1.1 zu vergleichen und Risiken zu priorisieren, sowie Risikostufen zu bestimmen. Die Toleranz wird hier angewendet und operationalisiert, nicht erstmals festgelegt."
    },
    {
     "ref": "6.1.3",
     "titel": "AI risk treatment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.1.3 verlangt die Genehmigung des Risikobehandlungsplans und die „acceptance of the residual AI risks“ durch das benannte Management. Die akzeptierten Restrisiken sind die praktisch wirksame und dokumentierte Ausprägung der Risikotoleranz."
    },
    {
     "ref": "A.2.2",
     "titel": "AI policy",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.2.2 verlangt, dass die KI-Politik von „the amount of risk the organization is willing to pursue or retain“ informiert wird. Damit wird die Risikobereitschaft in einem dokumentierten Leitungsdokument verankert."
    },
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "B.6.2.4 verlangt die Festlegung akzeptabler Fehlerraten und akzeptabler Bandbreiten operativer Faktoren sowie den Umgang mit Unterschreitungen. Das ist Toleranz auf Systemebene und ersetzt keine organisationsweite Risikotoleranz."
    }
   ],
   "luecke": "ISO 42001 verlangt keine eigenständig ausformulierte und veröffentlichte Risikotoleranz-Erklärung; die Toleranz bleibt implizit in Risikokriterien, Restrisikoakzeptanz und KI-Politik verteilt. Eine Herleitung der Toleranzschwellen aus rechtlichen oder gesellschaftlichen Vorgaben wird nicht gefordert."
  },
  "MAP 1.6": {
   "iso": [
    {
     "ref": "A.6.2.2",
     "titel": "AI system requirements and specification",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.2 verlangt, Anforderungen für neue KI-Systeme oder wesentliche Erweiterungen zu spezifizieren und zu dokumentieren; B.6.2.2 fordert, dass diese Anforderungen den gesamten Lebenszyklus umfassen und bei neuen Erkenntnissen revidiert werden. Das ist die direkte Entsprechung zu „system requirements ... are elicited“."
    },
    {
     "ref": "4.2",
     "titel": "Understanding the needs and expectations of interested parties",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "4.2 verlangt die Bestimmung der relevanten Anforderungen interessierter Parteien und die Entscheidung, welche davon über das AIMS adressiert werden. Das ist der normative Anker für die Erhebung von Anforderungen bei relevanten Akteuren."
    },
    {
     "ref": "A.5.4",
     "titel": "Assessing AI system impact on individuals or groups of individuals",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.5.4 verlangt die Berücksichtigung von Erwartungen an die Vertrauenswürdigkeit sowie von Fairness, Transparenz, Sicherheit, Privatheit und Menschenrechten. Diese Felder sind die inhaltliche Basis für Anforderungen wie „the system shall respect the privacy of its users“."
    },
    {
     "ref": "A.6.1.2",
     "titel": "Objectives for responsible development of AI system",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.1.2 verlangt, Ziele wie Fairness in die Anforderungsspezifikation, Datenbeschaffung, Modelltraining und Validierung zu integrieren. Damit fließen sozio-technische Erwägungen in Entwurfsentscheidungen ein."
    },
    {
     "ref": "A.6.1.3",
     "titel": "Processes for responsible AI system design and development",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.1.3 nennt als Prozessbestandteile Human-Oversight-Anforderungen, Usability und Controllability sowie „engagement of interested parties“. Das adressiert die sozio-technische Dimension von Entwurfsentscheidungen."
    },
    {
     "ref": "A.6.2.3",
     "titel": "Documentation of AI system design and development",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.2.3 verlangt die Dokumentation von Entwurfsentscheidungen einschließlich Schnittstelle und Darstellung der Ausgaben sowie „how humans can interact with the system“. Entwurfsentscheidungen werden so nachvollziehbar festgehalten."
    },
    {
     "ref": "A.5.5",
     "titel": "Assessing societal impacts of AI systems",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.5.5 verlangt die Bewertung gesellschaftlicher Auswirkungen über den Lebenszyklus. Der Rückfluss dieser Bewertung in konkrete Systemanforderungen wird jedoch nicht ausdrücklich gefordert."
    }
   ],
   "luecke": "ISO 42001 kennt keine Pflicht, Anforderungen aktiv bei den relevanten AI-Akteuren zu erheben und deren Verständnis nachzuweisen („elicited from and understood by“). Die Norm verlangt Spezifikation und Dokumentation, nicht aber einen belegten Verständnisabgleich mit Betroffenen und Betreibern."
  },
  "MAP 2.1": {
   "iso": [
    {
     "ref": "A.4.4",
     "titel": "Tooling resources",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.4.4 verlangt die Dokumentation der Tooling-Ressourcen und nennt „algorithm types and machine learning models“, Optimierungs- und Evaluationsmethoden. Die eingesetzten Methoden werden damit vollständig erfasst."
    },
    {
     "ref": "A.6.2.3",
     "titel": "Documentation of AI system design and development",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.6.2.3 verlangt die Dokumentation der Entwurfsentscheidungen einschließlich „machine learning approach (e.g. supervised vs. unsupervised)“ sowie „learning algorithm and type of machine learning model utilized“. Das entspricht exakt der NIST-Forderung nach definierter Aufgabe und Methode."
    },
    {
     "ref": "A.4.2",
     "titel": "Resource documentation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.4.2 verlangt die Identifikation und Dokumentation der für die jeweiligen Lebenszyklusphasen relevanten Ressourcen; B.4.2 zählt dazu ausdrücklich die AI-Systemkomponenten. Das liefert den strukturellen Rahmen der Methoden- und Komponentenerfassung."
    },
    {
     "ref": "A.6.2.2",
     "titel": "AI system requirements and specification",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.2.2 verlangt die Dokumentation von Begründung, Zielen und Anforderungen des KI-Systems einschließlich der Frage, wie das Modell trainiert werden kann. Die Aufgabe wird damit spezifiziert, die Methodenwahl nur mittelbar."
    },
    {
     "ref": "A.4.3",
     "titel": "Data resources",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "B.4.3 verlangt die Dokumentation der Datenressourcen einschließlich Datenkategorien (Training, Validierung, Test, Produktion) und des beabsichtigten Datengebrauchs. Das stützt die Aufgabendefinition nur mittelbar."
    },
    {
     "ref": "A.4.5",
     "titel": "System and computing resources",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "B.4.5 verlangt die Dokumentation von System- und Rechenressourcen einschließlich Ressourcenbedarf und Betriebsort. Für die Definition der Aufgabe selbst ist dies nur begleitend relevant."
    }
   ],
   "luecke": null
  },
  "MAP 2.2": {
   "iso": [
    {
     "ref": "A.6.2.7",
     "titel": "AI system technical documentation",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.6.2.7 verlangt in der technischen Dokumentation „technical limitations (e.g. acceptable error rates, accuracy, reliability, robustness)“ sowie „monitoring capabilities and functions that allow users or operators to influence the system operation“. Das deckt Systemgrenzen und Eingriffsmöglichkeiten dokumentiert ab."
    },
    {
     "ref": "A.8.2",
     "titel": "System documentation and information for users",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.8.2 verlangt Informationen an Nutzende zu „how and when to override the system“, „needs for human oversight“, Genauigkeit und Leistung sowie Grenzen des Systems. Genau das fordert MAP 2.2 für die Nutzung und Beaufsichtigung der Systemausgaben."
    },
    {
     "ref": "A.10.4",
     "titel": "Customers",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.10.4 verlangt, dass bei Gültigkeit eines KI-Systems für eine bestimmte Domäne „the limits of the domain should be communicated to the customer“. Das entspricht der Offenlegung der Wissensgrenzen gegenüber abnehmenden Stellen."
    },
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.2.4 verlangt Methoden und Metriken zur Bewertung, ob Entscheidende und Betroffene „can adequately interpret the AI system outputs“. Das trifft die NIST-Forderung nach ausreichender Information für informierte Entscheidungen."
    },
    {
     "ref": "A.9.3",
     "titel": "Objectives for responsible use of AI system",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.9.3 verlangt die Festlegung, an welchen Lebenszyklusstellen wirksame menschliche Aufsicht erfolgt, einschließlich Prüfung und Übersteuerung von Ausgaben. Der Dokumentationsfokus liegt jedoch auf Zielen, nicht auf der Nutzerinformation."
    },
    {
     "ref": "A.8.5",
     "titel": "Information for interested parties",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.8.5 verlangt die Bestimmung und Dokumentation der Berichtspflichten gegenüber interessierten Parteien, etwa Aufsichtsbehörden. Das betrifft externe Berichtspflichten, nicht die Entscheidungsunterstützung der operativen Akteure."
    }
   ],
   "luecke": "Wissensgrenzen im epistemischen Sinn (Unsicherheitsangaben, Out-of-Distribution-Erkennung, Konfidenzaussagen zur einzelnen Ausgabe) werden von ISO 42001 nicht gefordert; die Norm bleibt bei technischen Grenzen, Fehlerraten und Nutzungshinweisen."
  },
  "MAP 2.3": {
   "iso": [
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.4 verlangt definierte und dokumentierte Verifikations- und Validierungsmaßnahmen samt Kriterien; B.6.2.4 nennt Testmethoden und -werkzeuge, „selection of test data and their representation of the intended domain of use“ sowie Freigabekriterien. Das ist die zentrale TEVV-Entsprechung."
    },
    {
     "ref": "A.7.3",
     "titel": "Acquisition of data",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.7.3 verlangt die Dokumentation von Datenkategorien, Datenmenge, Datenquellen, Quellencharakteristik sowie „data subject demographics and characteristics (e.g. known or potential biases or other systematic errors)“. Das deckt Datenerhebung und -auswahl einschließlich Verfügbarkeit und Repräsentativität ab."
    },
    {
     "ref": "A.7.4",
     "titel": "Quality of data for AI systems",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.7.4 verlangt, die Qualität von Trainings-, Validierungs-, Test- und Produktionsdaten zu definieren, zu messen und zu verbessern und die Eignung für den beabsichtigten Zweck sicherzustellen. Damit sind Eignung, Repräsentativität und Bias-Wirkung auf Leistung und Fairness erfasst."
    },
    {
     "ref": "A.6.1.3",
     "titel": "Processes for responsible AI system design and development",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.1.3 verlangt als Bestandteil verantwortlicher Entwicklungsprozesse „testing requirements and planned means for testing“, Erwartungen an Trainingsdaten sowie Freigabekriterien. Die TEVV-Erwägungen werden damit prozessual verankert."
    },
    {
     "ref": "A.6.2.7",
     "titel": "AI system technical documentation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.2.7 nennt als Dokumentationselemente „verification and validation records“, Informationen über die Entwicklungsdaten und „assumptions made and quality measures taken on data quality (e.g. assumed statistical distributions)“. Das sichert die Dokumentationsforderung von MAP 2.3."
    },
    {
     "ref": "A.7.2",
     "titel": "Data for development and enhancement of AI system",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.7.2 verlangt Datenmanagementprozesse und nennt „representativeness of training data compared to operational domain of use“ sowie „accuracy and integrity of the data“. Das liefert den Prozessrahmen, nicht die Prüfmethodik."
    },
    {
     "ref": "A.7.5",
     "titel": "Data provenance",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.7.5 verlangt einen dokumentierten Prozess zur Aufzeichnung der Datenprovenienz über die Lebenszyklen von Daten und System. Nachvollziehbare Datenherkunft ist Voraussetzung wissenschaftlicher Integrität, deckt sie aber nicht vollständig ab."
    },
    {
     "ref": "A.7.6",
     "titel": "Data preparation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.7.6 verlangt dokumentierte Kriterien für die Auswahl der Datenaufbereitungsmethoden und nennt statistische Exploration, Bereinigung, Imputation, Normalisierung und Kodierung. Das entspricht dem methodischen Teil des „experimental design“."
    }
   ],
   "luecke": "Konstruktvalidität („construct validation“ - misst das System tatsächlich das behauptete Konstrukt?) und wissenschaftliche Integrität im engeren Sinn (Reproduzierbarkeit, unabhängige Nachprüfung, Peer Review) sind in ISO 42001 nicht gefordert; A.6.2.4 bleibt bei Verifikation und Validierung gegen selbst definierte Kriterien."
  },
  "MAP 3.1": {
   "iso": [
    {
     "ref": "6.1.1",
     "titel": "Actions to address risks and opportunities — General",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "6.1.1 verlangt, Risiken UND Chancen zu bestimmen, die adressiert werden müssen, und dazu dokumentierte Information aufzubewahren („actions taken to identify and address AI risks and AI opportunities“). Die Chancenseite ist die normative Entsprechung zu „potential benefits ... examined and documented“."
    },
    {
     "ref": "A.5.3",
     "titel": "Documentation of AI system impact assessments",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.5.3 verlangt, unter anderem „positive and negative impacts of the AI system to the relevant individuals or groups of individuals, or both, and societies“ zu dokumentieren und die Ergebnisse aufzubewahren. Nutzenpotenziale werden damit ausdrücklich dokumentationspflichtig."
    },
    {
     "ref": "6.1.4",
     "titel": "AI system impact assessment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.1.4 verlangt die Bestimmung der potenziellen Konsequenzen aus Bereitstellung und Nutzung; der Begriff „consequences“ ist richtungsoffen und schließt Nutzen ein. Der Fokus der Klausel liegt jedoch erkennbar auf negativen Folgen."
    },
    {
     "ref": "A.5.2",
     "titel": "AI system impact assessment process",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.5.2 strukturiert den Impact-Assessment-Prozess in Identifikation, Analyse, Bewertung, Behandlung und Dokumentation und knüpft ihn an „intended purpose and use“. Der Prozess trägt die Nutzenanalyse, adressiert sie aber nicht eigens."
    },
    {
     "ref": "A.5.4",
     "titel": "Assessing AI system impact on individuals or groups of individuals",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.5.4 verlangt die Bewertung und Dokumentation der potenziellen Auswirkungen auf Individuen und Gruppen über den Lebenszyklus, inhaltlich entlang Fairness, Zugänglichkeit und Gesundheit. Positive Auswirkungen sind dabei mitgemeint."
    },
    {
     "ref": "A.5.5",
     "titel": "Assessing societal impacts of AI systems",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.5.5 stellt ausdrücklich fest: „The societal impacts of AI systems can be both beneficial and detrimental“, und fragt etwa nach verbessertem Zugang zu Finanzdienstleistungen. Der gesellschaftliche Nutzen ist damit explizit Bewertungsgegenstand."
    },
    {
     "ref": "A.8.2",
     "titel": "System documentation and information for users",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "B.8.2 verlangt die Weitergabe „relevant information from the impact assessment, including potential benefits and harms“ an Nutzende. Das betrifft die Kommunikation des Nutzens, nicht dessen Ermittlung."
    }
   ],
   "luecke": "Ein Nutzennachweis bezogen auf Funktionalität und Leistung des Systems (erwarteter Leistungsgewinn gegenüber dem Status quo) wird von ISO 42001 nicht verlangt; der Nutzen wird nur als Auswirkung auf Individuen und Gesellschaft betrachtet."
  },
  "MAP 3.2": {
   "iso": [
    {
     "ref": "6.1.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "6.1.2 verlangt, „the potential consequences to the organization, individuals and societies that would result if the identified risks were to materialize“ zu bewerten, Risikostufen zu bestimmen und die Ergebnisse mit den Risikokriterien zu vergleichen. Damit ist die von NIST geforderte Verknüpfung von Schadensfolgen mit der Risikotoleranz normativ abgebildet."
    },
    {
     "ref": "A.5.3",
     "titel": "Documentation of AI system impact assessments",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.5.3 verlangt die Dokumentation von „predictable failures, their potential impacts and measures taken to mitigate them“ sowie der negativen Auswirkungen. Das entspricht den Folgen erwarteter oder eingetretener KI-Fehler."
    },
    {
     "ref": "6.1.1",
     "titel": "Actions to address risks and opportunities — General",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.1.1 verlangt KI-Risikokriterien zur Unterscheidung akzeptabler von nicht akzeptablen Risiken. Das ist der Bezugsrahmen für die von NIST geforderte Anbindung der Kosten an die Risikotoleranz."
    },
    {
     "ref": "A.5.2",
     "titel": "AI system impact assessment process",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.5.2 definiert als Prozesselemente Identifikation, Analyse (Konsequenzen und Eintrittswahrscheinlichkeit), Bewertung und Behandlung. Der Prozess erfasst Schadensfolgen, kennt aber keine Kostenkategorie."
    },
    {
     "ref": "A.5.4",
     "titel": "Assessing AI system impact on individuals or groups of individuals",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.5.4 nennt als Auswirkungsfelder ausdrücklich „financial consequences“ neben Fairness, Sicherheit, Gesundheit, Zugänglichkeit und Menschenrechten. Damit sind monetäre und nicht-monetäre Folgen für Betroffene abgedeckt."
    },
    {
     "ref": "A.5.5",
     "titel": "Assessing societal impacts of AI systems",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.5.5 nennt ökonomische, gesundheitliche, umweltbezogene und gesellschaftliche Schadenspotenziale einschließlich Desinformation. Das erfasst die nicht-monetären Kosten auf gesellschaftlicher Ebene."
    },
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.2.4 verlangt akzeptable Fehlerraten, Bewertungskriterien für Zuverlässigkeit und Sicherheit sowie dokumentierte Mechanismen zum Umgang mit schlechter Systemleistung. Das verknüpft Fehlverhalten und Vertrauenswürdigkeit mit definierten Schwellen."
    },
    {
     "ref": "8.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "8.2 verlangt die Durchführung von Risikobewertungen in geplanten Abständen oder bei wesentlichen Änderungen sowie die Aufbewahrung aller Ergebnisse. Das sichert die Aktualität, liefert aber keine eigene Kostenbetrachtung."
    }
   ],
   "luecke": "Eine ausdrückliche Kostenbetrachtung - insbesondere nicht-monetärer Kosten wie Reputations-, Vertrauens- oder Opportunitätsverluste - als eigenständige Analyse fehlt in ISO 42001; die Norm bewertet Folgen ausschließlich als Risiko bzw. Impact und verlangt keine Bezifferung realisierter Fehlerfolgen."
  },
  "MAP 3.3": {
   "iso": [
    {
     "ref": "A.6.2.2",
     "titel": "AI system requirements and specification",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.2 verlangt die Spezifikation und Dokumentation der Anforderungen für das KI-System; B.6.2.2 fordert zusätzlich die Dokumentation von Begründung und Zielen sowie die Revision, wenn das System nicht wie beabsichtigt arbeitet. Der angestrebte Anwendungsbereich wird damit festgelegt und dokumentiert."
    },
    {
     "ref": "A.9.4",
     "titel": "Intended use of the AI system",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.9.4 verlangt sicherzustellen, dass das KI-System entsprechend seiner beabsichtigten Verwendung und der Begleitdokumentation genutzt wird; B.9.4 fordert zusätzlich, dass die verarbeiteten Daten zur Dokumentation passen. Das ist die unmittelbare Entsprechung des „targeted application scope“."
    },
    {
     "ref": "4.1",
     "titel": "Understanding the organization and its context",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "4.1 verlangt die Berücksichtigung des beabsichtigten Zwecks der KI-Systeme und die Bestimmung der Rollen der Organisation. Das bildet den „established context“ als Grundlage der Scope-Festlegung."
    },
    {
     "ref": "A.10.4",
     "titel": "Customers",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.10.4 verlangt, die Grenzen der Gültigkeitsdomäne eines KI-Systems an die Kundenseite zu kommunizieren. Das setzt eine festgelegte und dokumentierte Einsatzdomäne voraus."
    },
    {
     "ref": "A.5.2",
     "titel": "AI system impact assessment process",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.5.2 nennt als Einstufungskriterien Kritikalität des Zwecks und Einsatzkontexts, Komplexität der Technologie und Automatisierungsgrad sowie Sensitivität der Datentypen. Das kommt einer Kategorisierung von KI-Systemen am nächsten."
    },
    {
     "ref": "A.6.2.7",
     "titel": "AI system technical documentation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.2.7 verlangt eine allgemeine Systembeschreibung einschließlich beabsichtigtem Zweck sowie technische Annahmen zu Deployment und Betrieb und technische Grenzen. Der Anwendungsbereich wird damit technisch dokumentiert."
    },
    {
     "ref": "4.3",
     "titel": "Determining the scope of the AI management system",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "4.3 betrifft die Festlegung des Geltungsbereichs des AI-Managementsystems, nicht den Anwendungsbereich des einzelnen KI-Systems; die Baseline setzt beides fälschlich gleich. Ein Bezug besteht nur insoweit, als der AIMS-Scope die einbezogenen Systeme und Tätigkeiten abgrenzt und dokumentiert vorliegen muss."
    }
   ],
   "luecke": "Eine formale Kategorisierung bzw. Risikoklassifizierung von KI-Systemen (AI system categorization im Sinne von NIST) kennt ISO 42001 nicht; B.5.2 nennt Kritikalitäts- und Komplexitätskriterien lediglich als Auslöser für Impact Assessments, nicht als Klassifikationsschema."
  },
  "MAP 3.4": {
   "iso": [
    {
     "ref": "7.2",
     "titel": "Competence",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "7.2 verlangt, die notwendige Kompetenz der unter Kontrolle der Organisation tätigen Personen zu bestimmen, sie durch Ausbildung, Schulung oder Erfahrung sicherzustellen und die Wirksamkeit der Maßnahmen zu bewerten. Damit sind „defined, assessed and documented“ für Bedienpersonal und Praktiker abgedeckt."
    },
    {
     "ref": "A.4.6",
     "titel": "Human resources",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.4.6 verlangt die Dokumentation der Humanressourcen und ihrer Kompetenzen für Entwicklung, Deployment, Betrieb, Änderungsmanagement, Wartung sowie Verifikation und Integration des KI-Systems. Das trifft die Betreiber- und Praktikerkompetenz unmittelbar."
    },
    {
     "ref": "7.3",
     "titel": "Awareness",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "7.3 verlangt Bewusstsein über die KI-Politik, den eigenen Beitrag zur Wirksamkeit des AIMS und die Folgen von Nichtkonformität. Das ergänzt die formale Kompetenz um die Verhaltensdimension."
    },
    {
     "ref": "A.6.1.3",
     "titel": "Processes for responsible AI system design and development",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.1.3 verlangt die Festlegung der erforderlichen Expertise bzw. Schulung für Entwickelnde von KI-Systemen als Bestandteil der Entwicklungsprozesse. Der Betriebsbereich wird dabei nur teilweise erfasst."
    },
    {
     "ref": "A.9.3",
     "titel": "Objectives for responsible use of AI system",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.9.3 verlangt, dass das in der menschlichen Aufsicht tätige Personal „informed of, trained and understand the instructions and other documentation“ ist. Das verbindet Kompetenz mit Systemleistung und Aufsichtspflichten."
    },
    {
     "ref": "A.8.2",
     "titel": "System documentation and information for users",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "B.8.2 nennt „educational materials for system use“ als eine den Nutzenden bereitzustellende Information. Das ist ein Hilfsmittel, aber kein Qualifizierungsprozess."
    }
   ],
   "luecke": "Der Bezug auf einschlägige technische Normen und Zertifizierungen für Bedien- und Fachpersonal fehlt in ISO 42001 vollständig; Kompetenz wird ausschließlich organisationsintern definiert und nachgewiesen, ohne externe Zertifizierungsanforderung."
  },
  "MAP 3.5": {
   "iso": [
    {
     "ref": "A.6.1.3",
     "titel": "Processes for responsible AI system design and development",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.6.1.3 verlangt ausdrücklich „human oversight requirements, including processes and tools, especially when the AI system can impact natural persons“ als dokumentierten Bestandteil der Entwicklungsprozesse. Damit sind Definition und Dokumentation der Aufsichtsprozesse normativ verankert."
    },
    {
     "ref": "A.9.3",
     "titel": "Objectives for responsible use of AI system",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.9.3 verlangt festzulegen, an welchen Lebenszyklusstellen „meaningful human oversight objectives“ zu verankern sind, einschließlich Prüfung und Übersteuerung von Ausgaben, Leistungsüberwachung, Meldung von Bedenken und der Frage, ob automatisierte Entscheidungen überhaupt angemessen sind. Das ist die zentrale Entsprechung zu „processes for human oversight“."
    },
    {
     "ref": "A.2.2",
     "titel": "AI policy",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.2.2 verlangt eine dokumentierte Politik für Entwicklung oder Nutzung von KI-Systemen, die nach B.2.2 leitende Prinzipien und den Umgang mit Abweichungen enthält. Das liefert die von NIST geforderte Rückbindung an die Governance-Vorgaben."
    },
    {
     "ref": "A.3.2",
     "titel": "AI roles and responsibilities",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.3.2 nennt „human oversight“ ausdrücklich als Bereich, für den Rollen und Verantwortlichkeiten definiert und zugewiesen werden müssen. Die organisatorische Verankerung der Aufsicht ist damit gefordert."
    },
    {
     "ref": "A.5.3",
     "titel": "Documentation of AI system impact assessments",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.5.3 verlangt die Dokumentation von „the role of humans in relationships with system, including human oversight capabilities, processes and tools, available to avoid negative impacts“. Die Aufsichtsprozesse werden damit im Impact Assessment dokumentiert."
    },
    {
     "ref": "A.6.2.7",
     "titel": "AI system technical documentation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.2.7 verlangt die Dokumentation der Rollen des Betriebspersonals und der für die Nutzung verantwortlichen Stellen, insbesondere im Umgang mit Systemausfällen. Das dokumentiert die Aufsichtsverantwortung technisch-operativ."
    },
    {
     "ref": "A.8.2",
     "titel": "System documentation and information for users",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.8.2 verlangt Angaben zu „how and when to override the system“ und „needs for human oversight“ gegenüber den Nutzenden. Das macht die Aufsichtsprozesse für die ausführende Ebene wirksam."
    },
    {
     "ref": "9.1",
     "titel": "Monitoring, measurement, analysis and evaluation",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "9.1 verlangt, festzulegen, was zu überwachen und zu messen ist, und die Wirksamkeit des AIMS zu bewerten. Eine Bewertung speziell der Aufsichtsprozesse ist damit möglich, aber nicht ausdrücklich gefordert."
    }
   ],
   "luecke": "ISO 42001 verlangt keine eigenständige Wirksamkeitsbewertung der Human-Oversight-Prozesse mit definierten Kriterien (z. B. Übersteuerungsquoten, Automation Bias); „assessed“ im NIST-Sinn wird nur über die allgemeine Wirksamkeitsbewertung nach 9.1 abgedeckt."
  },
  "MAP 4.1": {
   "iso": [
    {
     "ref": "A.10.2",
     "titel": "Allocating responsibilities",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.10.2 verlangt, alle am Lebenszyklus beteiligten Parteien - Daten-, Algorithmen- und Modelllieferanten - zu dokumentieren und ihre Verantwortlichkeiten zu bestimmen, einschließlich der Rollenverteilung bei PII. Damit wird die rechtliche Zurechnung von Komponentenrisiken systematisch erfasst."
    },
    {
     "ref": "A.10.3",
     "titel": "Suppliers",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.10.3 verlangt einen Prozess, der sicherstellt, dass die Nutzung von Leistungen, Produkten oder Materialien von Lieferanten dem verantwortlichen Ansatz der Organisation entspricht; B.10.3 nennt ausdrücklich bezogene Datensätze, Algorithmen, Modelle und Softwarebibliotheken sowie deren Risikobewertung. Das ist die direkte Entsprechung zu „use of third-party data or software“."
    },
    {
     "ref": "A.7.3",
     "titel": "Acquisition of data",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.7.3 verlangt die Dokumentation von „data rights (e.g. PII, copyright)“ sowie „prior handling of the data (e.g. previous uses, conformity with privacy and security requirements)“ und der Datenherkunft. Das ist der einzige Ort, an dem ISO 42001 Schutzrechte Dritter an Daten ausdrücklich adressiert."
    },
    {
     "ref": "4.1",
     "titel": "Understanding the organization and its context",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "4.1 verlangt die Bestimmung externer und interner Themen, die die Zielerreichung des AIMS beeinflussen; dazu zählen rechtliche Rahmenbedingungen. Ein strukturiertes Verfahren zur Rechtsrisikoanalyse folgt daraus jedoch nicht."
    },
    {
     "ref": "A.2.2",
     "titel": "AI policy",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.2.2 verlangt, dass die KI-Politik von „legal requirements, including contracts“ und dem Risikoumfeld der Organisation informiert wird. Rechtsrisiken werden so auf Politikebene verankert."
    },
    {
     "ref": "A.2.3",
     "titel": "Alignment with other organizational policies",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.2.3 verlangt zu bestimmen, welche anderen Richtlinien von den KI-Zielen betroffen sind; B.2.3 nennt Qualität, Sicherheit, Safety und Privatheit als Schnittmengen. Damit werden bestehende Rechts- und Compliance-Regelwerke mit dem KI-Einsatz verknüpft."
    },
    {
     "ref": "A.7.5",
     "titel": "Data provenance",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.7.5 verlangt einen dokumentierten Prozess zur Aufzeichnung der Datenprovenienz; B.7.5 empfiehlt zu prüfen, ob Maßnahmen zur Verifikation der Herkunft erforderlich sind. Ohne belastbare Provenienz lassen sich IP-Ansprüchen Dritter nicht begegnen."
    },
    {
     "ref": "A.9.2",
     "titel": "Processes for responsible use of AI systems",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.9.2 nennt als Erwägungen für den Einsatz eines KI-Systems „approved sourcing requirements“ und „legal requirements applicable to the organization“, unabhängig davon, ob das System selbst entwickelt oder bezogen wurde. Das adressiert Rechtsrisiken bei Drittkomponenten prozessual."
    }
   ],
   "luecke": "ISO 42001 kennt kein eigenständiges Verfahren zur Kartierung technologischer und rechtlicher Risiken und insbesondere keine Lizenz-, Urheber- oder Patentprüfung für Trainingsdaten, Modelle und Softwarekomponenten. Schutzrechte Dritter erscheinen ausschließlich als Dokumentationsmerkmal in B.7.3 („data rights“), nicht als zu befolgender und nachzuweisender Prüfprozess."
  },
  "MAP 4.2": {
   "iso": [
    {
     "ref": "6.1.3",
     "titel": "AI risk treatment",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "6.1.3 verlangt, alle notwendigen Controls zu bestimmen, mit Annex A abzugleichen, zusätzliche Controls zu identifizieren und eine Statement of Applicability mit Begründung von Ein- und Ausschluss zu erstellen. Das ist die unmittelbare Entsprechung zu „internal risk controls ... are identified and documented“."
    },
    {
     "ref": "A.10.3",
     "titel": "Suppliers",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.10.3 verlangt, Lieferantentypen, das jeweilige Risiko, die an sie gestellten Anforderungen sowie das laufende Monitoring zu bestimmen und zu dokumentieren, „how the AI system and AI system components are integrated“. Das deckt Kontrollen für Drittanbieter-KI-Technologien ab."
    },
    {
     "ref": "8.1",
     "titel": "Operational planning and control",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "8.1 verlangt die Umsetzung der nach 6.1.3 bestimmten Controls, die Überwachung ihrer Wirksamkeit und ausdrücklich, dass „externally provided processes, products or services that are relevant to the AI management system are controlled“. Das sichert die Anwendung der Kontrollen auf Drittkomponenten."
    },
    {
     "ref": "A.10.2",
     "titel": "Allocating responsibilities",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.10.2 verlangt die Zuweisung der Verantwortlichkeiten im Lebenszyklus zwischen Organisation, Partnern, Lieferanten, Kunden und Dritten. Ohne diese Zuordnung lassen sich Kontrollen für fremdbezogene Komponenten nicht wirksam verorten."
    },
    {
     "ref": "A.4.2",
     "titel": "Resource documentation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.4.2 verlangt die Identifikation und Dokumentation der relevanten Ressourcen je Lebenszyklusphase; B.4.2 hält fest, dass Ressourcen auch von Kunden oder Dritten stammen können. Das liefert das Komponenteninventar als Grundlage der Kontrollzuordnung."
    },
    {
     "ref": "A.6.2.7",
     "titel": "AI system technical documentation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.2.7 verlangt die Dokumentation der während Entwicklung oder Betrieb ergriffenen Managementaktivitäten einschließlich Risikomanagement sowie der Verifikations- und Validierungsnachweise. Damit werden wirkende Kontrollen technisch dokumentiert."
    },
    {
     "ref": "A.4.4",
     "titel": "Tooling resources",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "B.4.4 verlangt die Dokumentation der Tooling-Ressourcen einschließlich Algorithmen, Modelle und eingesetzter Software. Das erfasst Drittkomponenten, sagt aber nichts über die zugehörigen Kontrollen aus."
    }
   ],
   "luecke": "Eine komponentenscharfe Zuordnung von Kontrollen zu einzelnen KI-Systemkomponenten (Control-Inventar je Komponente einschließlich zugekaufter Modelle und Bibliotheken) verlangt ISO 42001 nicht; die Statement of Applicability nach 6.1.3 bleibt auf Ebene des Managementsystems."
  },
  "MAP 5.1": {
   "iso": [
    {
     "ref": "6.1.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "6.1.2 verlangt, die potenziellen Konsequenzen bei Risikoeintritt zu bewerten, „the realistic likelihood of the identified risks“ zu beurteilen und Risikostufen zu bestimmen. Das entspricht exakt der NIST-Forderung nach Eintrittswahrscheinlichkeit und Ausmaß jeder identifizierten Auswirkung."
    },
    {
     "ref": "A.5.2",
     "titel": "AI system impact assessment process",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.5.2 nennt als Prozesselemente „identification (e.g. sources, events and outcomes)“, „analysis (e.g. consequences and likelihood)“ und „evaluation (e.g. acceptance decisions and prioritization)“. Damit ist die Wahrscheinlichkeits- und Ausmaßbetrachtung je Auswirkung prozessual verankert."
    },
    {
     "ref": "6.1.4",
     "titel": "AI system impact assessment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.1.4 verlangt die Bestimmung der Folgen aus Deployment, beabsichtigter Nutzung und vorhersehbarem Missbrauch sowie die Dokumentation der Ergebnisse und deren Berücksichtigung in der Risikobewertung. Der Bezug auf „expected use“ ist damit abgedeckt."
    },
    {
     "ref": "A.5.3",
     "titel": "Documentation of AI system impact assessments",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.5.3 verlangt die Dokumentation positiver und negativer Auswirkungen sowie „predictable failures, their potential impacts“. Das sichert die Dokumentationspflicht von MAP 5.1, ohne Wahrscheinlichkeiten eigens zu verlangen."
    },
    {
     "ref": "A.5.4",
     "titel": "Assessing AI system impact on individuals or groups of individuals",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.5.4 verlangt die Bewertung und Dokumentation der potenziellen Auswirkungen auf Individuen und Gruppen über den gesamten Lebenszyklus. Das liefert die inhaltliche Grundlage der je Auswirkung zu bestimmenden Größe."
    },
    {
     "ref": "A.8.3",
     "titel": "External reporting",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.8.3 verlangt Meldemöglichkeiten für interessierte Parteien, um nachteilige Auswirkungen des KI-Systems zu melden; B.8.3 nennt ausdrücklich externe Parteien. Das ist die ISO-Entsprechung zu „feedback from those external to the team“."
    },
    {
     "ref": "A.5.5",
     "titel": "Assessing societal impacts of AI systems",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.5.5 verlangt die Bewertung gesellschaftlicher Auswirkungen über den Lebenszyklus. Eine Quantifizierung nach Wahrscheinlichkeit und Ausmaß wird dort nicht gefordert."
    }
   ],
   "luecke": "Die systematische Auswertung externer Erfahrungsquellen - früherer Einsätze vergleichbarer KI-Systeme und öffentlicher Incident-Reports - als Eingangsgröße der Wahrscheinlichkeitsschätzung fordert ISO 42001 nicht; B.5.4 nennt lediglich die Konsultation von Experten."
  },
  "MAP 5.2": {
   "iso": [
    {
     "ref": "A.3.3",
     "titel": "Reporting of concerns",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "B.3.3 verlangt einen Meldeprozess, der „staffed with qualified persons“ ist, Untersuchungs- und Lösungsbefugnisse festlegt, Eskalation an das Management sowie Antwortmechanismen in angemessener Frist vorsieht. Damit sind die von NIST geforderten Praktiken UND das zuständige Personal normativ verankert."
    },
    {
     "ref": "A.8.3",
     "titel": "External reporting",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.8.3 verlangt, Fähigkeiten bereitzustellen, mit denen interessierte Parteien nachteilige Auswirkungen des KI-Systems melden können; B.8.3 stellt klar, dass dies zusätzlich zum internen Monitoring gilt und auch Unfairness umfasst. Das ist die zentrale Entsprechung für die Aufnahme externen Feedbacks."
    },
    {
     "ref": "4.2",
     "titel": "Understanding the needs and expectations of interested parties",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "4.2 verlangt die Bestimmung der relevanten interessierten Parteien, ihrer Anforderungen und der Entscheidung, welche davon adressiert werden. Das definiert den Kreis der einzubindenden AI-Akteure."
    },
    {
     "ref": "7.4",
     "titel": "Communication",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "7.4 verlangt die Festlegung interner und externer Kommunikation nach Inhalt, Zeitpunkt, Adressat und Methode. Das ist der normative Rahmen für regelmäßigen Austausch, ohne dessen Frequenz oder Format vorzugeben."
    },
    {
     "ref": "A.6.1.3",
     "titel": "Processes for responsible AI system design and development",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.1.3 nennt „engagement of interested parties“ als zu berücksichtigenden Bestandteil der verantwortlichen Entwicklungsprozesse. Die Einbindung wird gefordert, aber nicht als wiederkehrende Praxis ausgestaltet."
    },
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.2.6 verlangt Supportprozesse dazu, „how issues and incidents are reported“, und die Prüfung der Angemessenheit, wenn Systeme auf unvorhergesehene Weise genutzt werden. Damit werden unerwartete Auswirkungen aufgegriffen und in den Betrieb zurückgeführt."
    },
    {
     "ref": "9.3.2",
     "titel": "Management review inputs",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "9.3.2 verlangt, „changes in needs and expectations of interested parties“ als Eingabe in die Managementbewertung aufzunehmen. Damit wird Feedback zumindest periodisch in Entscheidungen integriert."
    },
    {
     "ref": "A.10.4",
     "titel": "Customers",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "B.10.4 verlangt, Kundenerwartungen und -beduerfnisse zu verstehen, auch aus Design-, Engineering- oder Vertragsanforderungen. Das erfasst nur eine Gruppe von AI-Akteuren."
    }
   ],
   "luecke": "Eine proaktive, regelmäßige und strukturierte Einbindung externer Betroffener (z. B. Konsultationen, Nutzerpanels, Community-Beteiligung) fordert ISO 42001 nicht; die Norm beschränkt sich auf Melde- und Beschwerdewege (A.3.3, A.8.3) und generische Kommunikationsplanung (7.4)."
  },
  "MEASURE 1.1": {
   "iso": [
    {
     "ref": "6.1.1",
     "titel": "Actions to address risks and opportunities — General",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.1.1 verlangt die Festlegung von AI-Risikokriterien, die akzeptable von nicht akzeptablen Risiken unterscheiden und Risikobewertungen stützen. Damit ist die Grundlage für eine Priorisierung gelegt, nicht aber die Auswahl konkreter Messansätze und Metriken."
    },
    {
     "ref": "6.1.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.1.2 e) 5) fordert ausdrücklich, die bewerteten Risiken für die Risikobehandlung zu priorisieren, was dem NIST-Gedanken \"starting with the most significant AI risks\" entspricht. Der Prozess zielt jedoch auf Risikobehandlung, nicht auf die Auswahl von Messverfahren."
    },
    {
     "ref": "9.1",
     "titel": "Monitoring, measurement, analysis and evaluation",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "9.1 verlangt festzulegen, was überwacht und gemessen wird sowie welche Methoden valide Ergebnisse sicherstellen. Der Bezugspunkt ist jedoch die Leistung des AIMS, nicht die Messbarkeit einzelner AI-Risiken oder Trustworthiness-Merkmale."
    },
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.4 fordert dokumentierte Evaluationskriterien einschließlich akzeptabler Fehlerraten sowie die Dokumentation von Faktoren, die ein Verfehlen eines Mindestleistungsniveaus erklären können. Das deckt den Dokumentationsgedanken teilweise ab, adressiert aber nicht grundsätzlich nicht messbare Risiken."
    },
    {
     "ref": "A.6.1.2",
     "titel": "Objectives for responsible development of AI system",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.6.1.2 verlangt, Ziele verantwortlicher Entwicklung zu dokumentieren und Maßnahmen zu ihrer Erreichung in den Lebenszyklus zu integrieren (z. B. ein bestimmtes Testwerkzeug gegen unerwünschten Bias). Das berührt die Metrikauswahl nur mittelbar über Zielvorgaben."
    }
   ],
   "luecke": "ISO/IEC 42001 kennt keine Anforderung, Messansätze und Metriken je Risiko explizit auszuwählen und nach Signifikanz zu priorisieren. Vor allem fehlt die NIST-Kernforderung, diejenigen Risiken und Trustworthiness-Merkmale, die nicht oder nicht sinnvoll gemessen werden können, ausdrücklich als solche zu dokumentieren."
  },
  "MEASURE 1.2": {
   "iso": [
    {
     "ref": "8.1",
     "titel": "Operational planning and control",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "8.1 verlangt, die Wirksamkeit der nach 6.1.3 bestimmten Controls zu überwachen und Korrekturmaßnahmen zu erwägen, wenn die beabsichtigten Ergebnisse nicht erreicht werden. Das deckt die regelmäßige Wirksamkeitsprüfung bestehender Controls weitgehend ab."
    },
    {
     "ref": "8.3",
     "titel": "AI risk treatment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "8.3 fordert, die Umsetzung des Risikobehandlungsplans zu verifizieren und unwirksame Behandlungsoptionen zu überprüfen, zu revalidieren und den Plan zu aktualisieren. Der Aktualisierungszyklus ist damit normiert, allerdings für Risikobehandlungen und nicht für Metriken."
    },
    {
     "ref": "9.1",
     "titel": "Monitoring, measurement, analysis and evaluation",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "9.1 verlangt festzulegen, wann Ergebnisse aus Überwachung und Messung analysiert und bewertet werden, und die Wirksamkeit des AIMS zu bewerten. Die Angemessenheit der eingesetzten Metriken selbst wird jedoch nicht zum Prüfgegenstand gemacht."
    },
    {
     "ref": "A.5.4",
     "titel": "Assessing AI system impact on individuals or groups of individuals",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.5.4 fordert die Bewertung und Dokumentation der Auswirkungen auf Einzelpersonen und Gruppen über den gesamten Lebenszyklus, einschließlich Fairness, Sicherheit und Menschenrechten. Damit sind Auswirkungen auf betroffene Gruppen erfasst, nicht aber deren strukturierte Rückmeldung an das Metrikdesign."
    },
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.4 verlangt, die Häufigkeit der Evaluation festzulegen, wobei sie sich auf Ergebnisse der AI-System-Folgenabschätzung stützen kann, und bei Nichterfüllung der Kriterien Zweckbestimmung und Leistungsanforderungen zu überdenken. Das entspricht der geforderten regelmäßigen Nachjustierung."
    },
    {
     "ref": "10.2",
     "titel": "Nonconformity and corrective action",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "10.2 verlangt, auf Nichtkonformitäten zu reagieren, ihre Ursachen zu bewerten und Korrekturmaßnahmen umzusetzen. Das greift erst bei festgestellten Abweichungen und ist kein Verfahren zur laufenden Fehlerberichterstattung aus betroffenen Gemeinschaften."
    },
    {
     "ref": "A.5.5",
     "titel": "Assessing societal impacts of AI systems",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.5.5 verlangt die laufende Bewertung gesellschaftlicher Auswirkungen über den Lebenszyklus. Der Bezug zur Angemessenheit von Metriken und zur Fehlerberichterstattung ist nur thematisch."
    }
   ],
   "luecke": "ISO fordert die Wirksamkeitsprüfung von Controls, nicht aber die Prüfung der Angemessenheit der Metriken selbst (Konstruktvalidität, Metrikdrift, Proxy-Eignung). Ebenso fehlt ein definierter Kanal, über den Fehlermeldungen und Auswirkungsberichte betroffener Gemeinschaften systematisch erfasst und in die Metrik- und Control-Revision zurückgespielt werden."
  },
  "MEASURE 1.3": {
   "iso": [
    {
     "ref": "9.2.2",
     "titel": "Internal audit programme",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "9.2.2 b) verlangt, Auditoren so auszuwählen und Audits so durchzuführen, dass Objektivität und Unparteilichkeit des Auditprozesses sichergestellt sind. Das Unabhängigkeitsprinzip passt, der Prüfgegenstand ist jedoch das AIMS und nicht die technische Bewertung des AI-Systems."
    },
    {
     "ref": "A.5.2",
     "titel": "AI system impact assessment process",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.5.2 c) verlangt festzulegen, wer die AI-System-Folgenabschätzung durchführt, und A.5.2 e) die Identifikation potenziell betroffener Einzelpersonen und Gesellschaften. Eine Unabhängigkeit der durchführenden Personen von der Entwicklung wird jedoch nicht gefordert."
    },
    {
     "ref": "A.5.4",
     "titel": "Assessing AI system impact on individuals or groups of individuals",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.5.4 empfiehlt in den weiteren Hinweisen ausdrücklich, bei Bedarf Experten wie Forschende, Fachexperten und Nutzende zu konsultieren, um Auswirkungen vollständig zu verstehen. Das entspricht der Konsultation von Domänenexperten, ist aber nur eine Empfehlung ohne Unabhängigkeitskriterium."
    },
    {
     "ref": "9.2.1",
     "titel": "Internal audit — General",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "9.2.1 fordert interne Audits in geplanten Abständen zur Konformität und wirksamen Umsetzung des AIMS. Eine regelmäßige unabhängige Neubewertung des AI-Systems selbst wird damit nicht verlangt."
    },
    {
     "ref": "A.5.5",
     "titel": "Assessing societal impacts of AI systems",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.5.5 verlangt die Bewertung gesellschaftlicher Auswirkungen und die Analyse, wie Akteure das System missbrauchen können. Betroffene Gemeinschaften sind damit Bewertungsgegenstand, nicht Konsultationspartner."
    },
    {
     "ref": "A.6.1.3",
     "titel": "Processes for responsible AI system design and development",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.6.1.3 nennt als Bestandteile verantwortlicher Entwicklungsprozesse unter anderem die erforderliche Fachexpertise, Freigaben und Sign-offs sowie die Einbindung interessierter Parteien. Eine personelle Trennung von Entwicklung und Bewertung ist darin nicht angelegt."
    }
   ],
   "luecke": "ISO/IEC 42001 kennt Unabhängigkeit und Unparteilichkeit ausschließlich für interne Audits des Managementsystems (9.2.2 b). Für die wiederkehrende technische Bewertung des AI-Systems fehlt jede Anforderung an eine Trennung von Entwicklerteam und Assessor, an unabhängige externe Assessoren sowie an die strukturierte Konsultation von Nutzenden, systemexternen AI-Akteuren und betroffenen Gemeinschaften entlang der Risikotoleranz."
  },
  "MEASURE 2.1": {
   "iso": [
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.4 verlangt, Verifizierungs- und Validierungsmaßnahmen zu definieren und zu dokumentieren, ausdrücklich einschließlich Testmethodik und -werkzeugen, der Auswahl der Testdaten und ihrer Repräsentativität für die beabsichtigte Anwendungsdomäne sowie der Freigabekriterien. Das deckt Test-Sets, Metriken und Werkzeuge im Kern ab."
    },
    {
     "ref": "A.4.4",
     "titel": "Tooling resources",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.4.4 verlangt die Dokumentation der Tooling-Ressourcen und führt dabei ausdrücklich Evaluationsmethoden sowie Werkzeuge für Entwicklung und Deployment auf. Damit sind die TEVV-Werkzeuge erfasst, nicht aber Test-Sets und Metrikdefinitionen."
    },
    {
     "ref": "A.6.2.3",
     "titel": "Documentation of AI system design and development",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.3 verlangt die Dokumentation von Design und Entwicklung einschließlich der Evaluation und Verfeinerung der Modelle sowie der Hardware- und Softwarekomponenten. Der Detailgrad bleibt hinter einer TEVV-spezifischen Dokumentation zurück."
    },
    {
     "ref": "A.6.2.7",
     "titel": "AI system technical documentation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.7 nennt Verifizierungs- und Validierungsaufzeichnungen sowie Angaben zu den bei der Entwicklung verwendeten Daten und getroffenen Qualitätsmaßnahmen als Bestandteile der technischen Dokumentation. Der Fokus liegt jedoch auf der Bereitstellung an interessierte Parteien, nicht auf der TEVV-internen Nachvollziehbarkeit."
    },
    {
     "ref": "A.4.2",
     "titel": "Resource documentation",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.4.2 verlangt die Identifikation und Dokumentation der für die jeweiligen Lebenszyklusphasen benötigten Ressourcen als Grundlage für Risiko- und Folgenverständnis. Der Bezug zu TEVV ist nur allgemeiner Natur."
    },
    {
     "ref": "A.4.3",
     "titel": "Data resources",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.4.3 fordert die Dokumentation der Datenressourcen, die in irgendeiner Lebenszyklusphase verwendet werden, was auch Testdaten einschließt. Test-Sets werden jedoch nicht als eigene, versionierte Kategorie adressiert."
    }
   ],
   "luecke": "Die Baseline-Zuordnung zu B.8.4 (Communication of incidents) ist eine Fehlzuordnung und wurde entfernt: Vorfallkommunikation hat keinen Bezug zur TEVV-Dokumentation. Inhaltlich fehlt ISO eine verbindliche Nachweisführung über versionierte Test-Sets, präzise Metrikdefinitionen und Werkzeugversionen, die eine unabhängige Reproduktion der TEVV-Ergebnisse erlauben würde; A.6.2.4 formuliert dies nur beispielhaft (\"can include\")."
  },
  "MEASURE 2.2": {
   "iso": [
    {
     "ref": "A.2.3",
     "titel": "Alignment with other organizational policies",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.2.3 verlangt zu bestimmen, welche anderen Richtlinien der Organisation berührt werden, und nennt ausdrücklich Qualität, Sicherheit, Safety und Datenschutz. Forschungsethik oder Probandenschutz werden darunter nicht genannt, wären aber über diesen Mechanismus anzubinden."
    },
    {
     "ref": "A.5.4",
     "titel": "Assessing AI system impact on individuals or groups of individuals",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.5.4 verlangt, besondere Schutzbeduerfnisse von Gruppen wie Kindern, beeinträchtigten und älteren Personen sowie Beschäftigten zu berücksichtigen. Gemeint sind jedoch die von einem AI-System Betroffenen, nicht Teilnehmende an Evaluationsstudien."
    },
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.6.2.4 verlangt die Auswahl von Testdaten und deren Repräsentativität für die beabsichtigte Anwendungsdomäne. Das betrifft Datenrepräsentativität, nicht die Repräsentativität einer Stichprobe menschlicher Versuchspersonen, und enthält keinerlei Probandenschutz."
    },
    {
     "ref": "A.7.2",
     "titel": "Data for development and enhancement of AI system",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.7.2 nennt als Bestandteil des Datenmanagements Datenschutz- und Sicherheitsimplikationen sowie die Repräsentativität von Trainingsdaten gegenüber der operativen Anwendungsdomäne. Ein Bezug zu Evaluationen mit menschlichen Versuchspersonen fehlt."
    },
    {
     "ref": "A.7.3",
     "titel": "Acquisition of data",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.7.3 verlangt die Dokumentation von Demografie und Merkmalen der Datensubjekte, von Datenrechten (z. B. PII) sowie der bisherigen Handhabung der Daten einschließlich Konformität mit Datenschutzanforderungen. Das berührt Probandenrechte nur über den Umweg der Datenbeschaffung."
    }
   ],
   "luecke": "Klare und vollständige Lücke: ISO/IEC 42001 enthält keine einzige Anforderung zu Evaluationen mit menschlichen Versuchspersonen. Es fehlen Ethikkommission/IRB-Votum, informierte Einwilligung und Widerrufsrecht, Aufklärung und Debriefing, Vergütung, Schutz vulnerabler Probandengruppen sowie die statistische Repräsentativität der Probandenstichprobe für die Zielpopulation; diese Anforderungen sind ausschließlich über externe Regelwerke (z. B. Deklaration von Helsinki, DSGVO Art. 6/9, institutionelle Forschungsethikrichtlinien) abzudecken und wären über A.2.3 in das AIMS einzubinden."
  },
  "MEASURE 2.3": {
   "iso": [
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.4 verlangt dokumentierte Evaluationskriterien einschließlich Zuverlässigkeits- und Safety-Anforderungen mit akzeptablen Fehlerraten sowie operativer Faktoren wie Datenqualität und beabsichtigter Nutzung mit akzeptablen Wertebereichen. Das AI-System ist ausdrücklich gegen diese dokumentierten Kriterien zu evaluieren."
    },
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.6 verlangt Leistungskriterien und Metriken für den Betrieb (z. B. F1-Wert nach ISO/IEC TS 4213) und fordert, dass Bewertungsmethodiken die Eigenschaften von Betrieb und Nutzung möglichst genau abbilden. Das entspricht der Forderung nach Nachweis unter deploymentnahen Bedingungen."
    },
    {
     "ref": "A.6.2.5",
     "titel": "AI system deployment",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.5 verlangt Freigabekriterien vor Deployment, die zu bestehende V&V-Maßnahmen, zu erreichende Leistungsmetriken und abzuschließende Nutzertests umfassen können. Zudem sind Unterschiede zwischen Entwicklungs- und Deployment-Umgebung im Deployment-Plan zu berücksichtigen."
    },
    {
     "ref": "A.6.2.7",
     "titel": "AI system technical documentation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.7 verlangt die Dokumentation technischer Annahmen zu Deployment und Betrieb sowie technischer Grenzen wie akzeptabler Fehlerraten, Genauigkeit, Zuverlässigkeit und Robustheit. Damit ist die Dokumentationspflicht für die Messergebnisse teilweise abgedeckt."
    },
    {
     "ref": "9.1",
     "titel": "Monitoring, measurement, analysis and evaluation",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "9.1 verlangt festzulegen, was mit welchen Methoden gemessen wird, um valide Ergebnisse sicherzustellen, und die Ergebnisse als dokumentierte Information vorzuhalten. Der Bezugspunkt ist die AIMS-Leistung, nicht die Systemleistung unter Einsatzbedingungen."
    },
    {
     "ref": "A.7.4",
     "titel": "Quality of data for AI systems",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.7.4 verlangt definierte Datenqualitätsanforderungen, da die Datenqualität die Validität der Systemausgaben erheblich beeinflusst. Das ist eine Voraussetzung belastbarer Leistungsmessung, aber kein Messverfahren."
    }
   ],
   "luecke": "Die Forderung, Bewertungsmethodiken möglichst realitätsnah an Betrieb und Nutzung auszurichten, steht in ISO nur in den nicht-normativen \"Other information\" zu B.6.2.6. Eine verbindliche Demonstration der Leistung unter deploymentähnlichen Bedingungen vor Inbetriebnahme, inklusive quantitativer oder qualitativer Assurance-Schwellen, wird nicht gefordert."
  },
  "MEASURE 2.4": {
   "iso": [
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.6 verlangt als Mindestumfang System- und Leistungsüberwachung im laufenden Betrieb, einschließlich der Überwachung auf allgemeine Fehler und Ausfälle sowie darauf, ob das System mit Produktionsdaten erwartungsgemäß arbeitet. Konzept- und Datendrift sowie kontinuierliches Lernen sind ausdrücklich zu überwachen."
    },
    {
     "ref": "A.6.2.8",
     "titel": "AI system recording of event logs",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.8 verlangt Event-Logging mindestens während der Nutzung, um die Funktionalität rückverfolgbar zu machen und Leistung außerhalb der beabsichtigten Betriebsbedingungen zu erkennen. Das deckt die Beobachtung des tatsächlichen Systemverhaltens in Produktion ab."
    },
    {
     "ref": "8.1",
     "titel": "Operational planning and control",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "8.1 verlangt, die Wirksamkeit der operativen Controls zu überwachen und die Folgen unbeabsichtigter Änderungen zu überprüfen. Das stützt die laufende Betriebsüberwachung, bleibt aber auf Control-Ebene."
    },
    {
     "ref": "9.1",
     "titel": "Monitoring, measurement, analysis and evaluation",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "9.1 verlangt festzulegen, was überwacht und gemessen wird, mit welchen Methoden und zu welchen Zeitpunkten Ergebnisse analysiert und bewertet werden. Die Klausel liefert den Rahmen, adressiert aber das AIMS und nicht einzelne Systemkomponenten."
    },
    {
     "ref": "A.6.2.7",
     "titel": "AI system technical documentation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.7 verlangt, Prozesse zur Überwachung der Systemgesundheit (Observability) zu dokumentieren sowie festzulegen, welche Ereignisse überwacht und wie Event-Logs priorisiert und ausgewertet werden. Das ergänzt die Überwachung um die Dokumentations- und Auswerteseite."
    },
    {
     "ref": "A.8.4",
     "titel": "Communication of incidents",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.8.4 verlangt einen dokumentierten Plan zur Kommunikation von Vorfällen an Nutzende. Das setzt nach einem erkannten Ereignis an und ist kein Monitoring im Sinne der Subkategorie."
    }
   ],
   "luecke": "ISO fordert kein Nachverfolgen der Überwachung auf die zuvor identifizierten Systemkomponenten und Verhaltensweisen; ein MAP-äquivalentes Komponenteninventar als Monitoring-Bezugsrahmen existiert nicht. Überwachungstiefe, Frequenz und Alarmschwellen bleiben durchgängig unbestimmt (\"can include\")."
  },
  "MEASURE 2.5": {
   "iso": [
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.4 verlangt definierte V&V-Maßnahmen mit Evaluationskriterien zu Zuverlässigkeit und Safety und schreibt vor, das AI-System gegen diese dokumentierten Kriterien zu evaluieren. Erfüllt es sie nicht, sind Zweckbestimmung, Leistungsanforderungen und Mängelbehandlung neu zu bewerten."
    },
    {
     "ref": "A.6.2.5",
     "titel": "AI system deployment",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.5 verlangt einen Deployment-Plan und Freigabekriterien, die vor Release zu erfüllen sind, einschließlich bestandener V&V-Maßnahmen, erreichter Leistungsmetriken sowie Management-Freigaben. Das entspricht dem Nachweis der Einsatzreife vor Deployment."
    },
    {
     "ref": "A.6.2.7",
     "titel": "AI system technical documentation",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.7 verlangt die Dokumentation technischer Annahmen zur Deployment- und Betriebsumgebung sowie technischer Grenzen (akzeptable Fehlerraten, Genauigkeit, Zuverlässigkeit, Robustheit) und der V&V-Aufzeichnungen. Das deckt die Dokumentation der Einsatzgrenzen weitgehend ab."
    },
    {
     "ref": "A.8.2",
     "titel": "System documentation and information for users",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.8.2 verlangt, Nutzenden Informationen zu Zweck, technischen Voraussetzungen und Grenzen des Systems bereitzustellen. Die Grenzen werden adressiert, jedoch aus Nutzersicht und nicht als Nachweis der Generalisierbarkeit."
    },
    {
     "ref": "A.7.2",
     "titel": "Data for development and enhancement of AI system",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.7.2 nennt die Repräsentativität der Trainingsdaten gegenüber der operativen Anwendungsdomäne als Gegenstand des Datenmanagements. Das ist eine Vorbedingung für Generalisierbarkeit, aber kein Nachweisverfahren."
    },
    {
     "ref": "A.9.4",
     "titel": "Intended use of the AI system",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.9.4 verlangt, das AI-System entsprechend seiner beabsichtigten Zweckbestimmung zu verwenden, und markiert damit die Grenze zulässiger Anwendung. Ein Nachweis der Validität außerhalb dieser Grenzen wird nicht gefordert."
    }
   ],
   "luecke": "ISO verlangt die Dokumentation technischer Grenzen, aber keinen aktiven Nachweis der Generalisierbarkeitsgrenzen: Out-of-Distribution-Tests, Prüfung auf Domänen- und Populationsverschiebung sowie Stresstests jenseits der Entwicklungsbedingungen sind nicht gefordert. \"Valid and reliable\" bleibt an organisationsintern selbst gesetzte Kriterien gebunden, ohne externe Referenz oder Mindestniveau."
  },
  "MEASURE 2.6": {
   "iso": [
    {
     "ref": "8.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "8.2 verlangt AI-Risikobewertungen nach 6.1.2 in geplanten Abständen sowie bei geplanten oder eingetretenen wesentlichen Änderungen und die Aufbewahrung der Ergebnisse. Das deckt die geforderte regelmäßige Neubewertung der Safety-Risiken strukturell ab."
    },
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.4 nennt ausdrücklich Zuverlässigkeits- und Safety-Anforderungen einschließlich akzeptabler Fehlerraten als Grundlage des Evaluationsplans und verlangt die Evaluation gegen diese dokumentierten Kriterien. Damit sind Safety-Kriterien normativ im V&V verankert."
    },
    {
     "ref": "6.1.1",
     "titel": "Actions to address risks and opportunities — General",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.1.1 verlangt AI-Risikokriterien, die akzeptable von nicht akzeptablen Risiken unterscheiden, also eine dokumentierte Risikotoleranz. Ein expliziter Abgleich des Restrisikos gegen diese Toleranz als Freigabebedingung wird jedoch nicht gefordert."
    },
    {
     "ref": "8.3",
     "titel": "AI risk treatment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "8.3 verlangt die Umsetzung des Risikobehandlungsplans, die Verifikation seiner Wirksamkeit und die Revalidierung unwirksamer Behandlungsoptionen. Das adressiert den Umgang mit verbleibenden Risiken, ohne den Begriff des Restrisikos gegen eine Toleranzschwelle zu operationalisieren."
    },
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.6 verlangt Prozesse für Reaktion und Behebung von Fehlern und Ausfällen sowie Supportprozesse mit Service-Level-Agreements und Metriken. Das kommt Reaktionszeiten bei Systemausfällen am nächsten, bleibt aber unverbindlich formuliert."
    },
    {
     "ref": "A.6.2.7",
     "titel": "AI system technical documentation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.7 verlangt die Dokumentation eines Plans zum Umgang mit Ausfällen, ausdrücklich einschließlich Rollback-Plan und Abschalten von Systemfunktionen. Das ist der einzige konkrete Anknüpfungspunkt für sicheres Ausfallverhalten."
    },
    {
     "ref": "A.6.2.8",
     "titel": "AI system recording of event logs",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.8 verlangt Event-Logs, die ein Arbeiten außerhalb der beabsichtigten Betriebsbedingungen erkennbar machen, einschließlich Ausgaben außerhalb des vorgesehenen Bereichs. Das adressiert das Erkennen des Überschreitens der Wissensgrenzen, nicht die Reaktion darauf."
    }
   ],
   "luecke": "Safety ist in ISO/IEC 42001 lediglich ein Beispielziel (B.6.1.2, B.9.3) ohne eigenes Control. Es fehlen konkrete Safety-Metriken, Anforderungen an Fail-Safe-Verhalten und graceful degradation beim Überschreiten der Wissensgrenzen, Echtzeitüberwachung, definierte Reaktionszeiten bei Systemausfällen sowie ein formaler Nachweis, dass das negative Restrisiko die festgelegte Risikotoleranz nicht überschreitet."
  },
  "MEASURE 2.7": {
   "iso": [
    {
     "ref": "A.6.2.3",
     "titel": "Documentation of AI system design and development",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.3 verlangt, die im gesamten AI-Lebenszyklus betrachteten Sicherheitsbedrohungen zu dokumentieren, und nennt ausdrücklich AI-spezifische Bedrohungen wie Data Poisoning, Model Stealing und Model-Inversion-Angriffe. Das ist der konkreteste Anknüpfungspunkt für Sicherheitsbewertung und deren Dokumentation."
    },
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.6 verlangt, AI-spezifische Informationssicherheitsbedrohungen für die eingesetzten und entwickelten AI-Systeme zu identifizieren, wiederum mit Data Poisoning, Model Stealing und Model Inversion als Beispielen. Damit ist die Sicherheitsbetrachtung auch im Betrieb verankert."
    },
    {
     "ref": "8.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "8.2 verlangt AI-Risikobewertungen in geplanten Abständen und bei wesentlichen Änderungen mit dokumentierten Ergebnissen. Sicherheitsrisiken fallen darunter, werden aber nicht als eigener Bewertungsgegenstand ausgewiesen."
    },
    {
     "ref": "A.2.3",
     "titel": "Alignment with other organizational policies",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.2.3 verlangt zu bestimmen, welche anderen Organisationsrichtlinien betroffen sind, und nennt ausdrücklich den Schnittbereich zu Security und Safety; bestehende Richtlinien sind zu aktualisieren oder in die AI-Policy zu überführen. Die eigentliche Sicherheitsbewertung wird damit an das ISMS (ISO/IEC 27001) delegiert."
    },
    {
     "ref": "A.7.2",
     "titel": "Data for development and enhancement of AI system",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.7.2 verlangt Datenmanagementprozesse, die Datenschutz- und Sicherheitsimplikationen sowie Sicherheits- und Safety-Bedrohungen aus datenabhängiger AI-Entwicklung einbeziehen. Das deckt den datenseitigen Teil der Angriffsfläche ab."
    },
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.6.2.4 lässt Testmethoden und Evaluationskriterien offen, sodass Sicherheitstests darunter gefasst werden können. Sicherheits- oder Robustheitstests werden jedoch nirgends ausdrücklich verlangt."
    },
    {
     "ref": "A.9.3",
     "titel": "Objectives for responsible use of AI system",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.9.3 nennt als Ziele verantwortlicher Nutzung unter anderem Zuverlässigkeit, Robustheit und Redundanz sowie Datenschutz und Sicherheit. Es handelt sich um Zielbegriffe ohne Bewertungs- oder Nachweisanforderung."
    }
   ],
   "luecke": "ISO/IEC 42001 fordert keine eigenständige Sicherheits- und Resilienzbewertung des AI-Systems: Red Teaming, Adversarial Testing, Penetrationstests, Modell-Extraktions- und Evasionsprüfungen sowie Nachweise zu Failover, Wiederherstellungszeiten und Degradationsverhalten fehlen vollständig. Resilienz erscheint nur als Zielbegriff (\"robustness and redundancy\", A.9.3), die operative Sicherheitsarbeit wird über A.2.3 an ISO/IEC 27001 ausgelagert."
  },
  "MEASURE 2.8": {
   "iso": [
    {
     "ref": "A.5.4",
     "titel": "Assessing AI system impact on individuals or groups of individuals",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.5.4 verlangt, potenzielle Auswirkungen auf Individuen und Gruppen zu bewerten und zu dokumentieren; B.5.4 nennt „accountability“ sowie „transparency and explainability“ ausdrücklich als zu prüfende Wirkungsbereiche."
    },
    {
     "ref": "6.1.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.1.2 verlangt einen dokumentierten KI-Risikobewertungsprozess mit Identifikation, Analyse und Bewertung; Transparenz- und Accountability-Risiken sind darin einzuschließen, werden aber nicht eigens benannt."
    },
    {
     "ref": "A.5.3",
     "titel": "Documentation of AI system impact assessments",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.5.3 fordert die Dokumentation und befristete Aufbewahrung der Ergebnisse der Impact Assessments und deckt damit die von NIST geforderte Dokumentation der Transparenz- und Verantwortlichkeitsrisiken ab."
    },
    {
     "ref": "A.5.5",
     "titel": "Assessing societal impacts of AI systems",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.5.5 adressiert gesellschaftliche Auswirkungen und berührt Transparenzrisiken nur mittelbar über Fehlinformation und Vertrauensverlust (B.5.5), nicht als eigene Prüfdimension."
    },
    {
     "ref": "A.6.1.2",
     "titel": "Objectives for responsible development of AI system",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.6.1.2 verlangt Ziele für verantwortliche Entwicklung und deren Integration in den Lebenszyklus; Transparenz kann ein solches Ziel sein, eine Risikoprüfung schreibt das Control aber nicht vor."
    },
    {
     "ref": "A.7.2",
     "titel": "Data for development and enhancement of AI system",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "B.7.2 nennt „transparency and explainability aspects including data provenance“ als Gegenstand des Datenmanagements; das erfasst jedoch nur die datenseitige Teilmenge der Transparenzrisiken."
    }
   ],
   "luecke": "ISO/IEC 42001 verlangt keine eigenständige Messung von Transparenz und Rechenschaftsfähigkeit; beides erscheint nur als Prüfdimension der Impact Assessments, ohne Indikatoren, Schwellenwerte oder Prüfverfahren."
  },
  "MEASURE 2.9": {
   "iso": [
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.4 fordert dokumentierte Verifizierungs- und Validierungsmaßnahmen samt Kriterien; B.6.2.4 verlangt ausdrücklich Methoden oder Metriken zur Bewertung, ob Beteiligte die Systemausgaben angemessen interpretieren können."
    },
    {
     "ref": "A.6.2.7",
     "titel": "AI system technical documentation",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.7 verlangt technische Dokumentation je Adressatenkreis; B.6.2.7 listet Zweck, technische Grenzen, Designentscheidungen sowie Verifizierungs- und Validierungsnachweise als Inhalte auf."
    },
    {
     "ref": "A.8.2",
     "titel": "System documentation and information for users",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.8.2 fordert die notwendigen Informationen für Nutzer; B.8.2 nennt Zweck, Funktionsweise, Genauigkeits- und Leistungsangaben sowie Übersteuerungsmöglichkeiten und deckt damit die kontextbezogene Interpretation der Ausgaben ab."
    },
    {
     "ref": "A.6.2.3",
     "titel": "Documentation of AI system design and development",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.3 verlangt die Dokumentation von Design und Entwicklung; B.6.2.3 nennt Lernverfahren, Modelltyp, Modellevaluation sowie die Darstellung der Ausgaben als zu dokumentierende Entwurfsentscheidungen."
    },
    {
     "ref": "A.9.4",
     "titel": "Intended use of the AI system",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.9.4 verpflichtet zur Nutzung des Systems entsprechend dem beabsichtigten Zweck und der Begleitdokumentation und stellt damit den von NIST geforderten Bezug zur verantwortlichen Verwendung her."
    },
    {
     "ref": "A.6.2.5",
     "titel": "AI system deployment",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.6.2.5 verlangt einen Deployment-Plan mit vorab zu erfüllenden Freigabekriterien; B.6.2.5 fordert bestandene V&V-Maßnahmen, adressiert die Modellerklärung selbst aber nicht."
    },
    {
     "ref": "A.7.5",
     "titel": "Data provenance",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.7.5 fordert einen Prozess zur Aufzeichnung der Datenherkunft und liefert damit nur einen Baustein der Nachvollziehbarkeit, keine Modellerklärung oder Ausgabeinterpretation."
    }
   ],
   "luecke": "Konkrete Erklärbarkeitsverfahren (z. B. Feature-Attribution, Surrogatmodelle, Counterfactuals) werden normativ nicht gefordert; ISO verlangt Dokumentation und eine Bewertung der Interpretierbarkeit, ohne Methoden oder ein Mindestniveau festzulegen."
  },
  "MEASURE 2.10": {
   "iso": [
    {
     "ref": "A.5.4",
     "titel": "Assessing AI system impact on individuals or groups of individuals",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.5.4 verlangt Bewertung und Dokumentation der Auswirkungen auf Individuen; B.5.4 nennt „security and privacy“ ausdrücklich als Wirkungsbereich und verweist auf Erwartungen von Personen, deren PII verarbeitet werden."
    },
    {
     "ref": "6.1.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.1.2 verpflichtet zu einem wiederholbaren KI-Risikobewertungsprozess, unter den Datenschutzrisiken als Risikokategorie fallen, ohne dass die Norm sie eigens ausweist."
    },
    {
     "ref": "A.5.2",
     "titel": "AI system impact assessment process",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.5.2 fordert einen Impact-Assessment-Prozess; B.5.2 nennt die Sensitivität der verarbeiteten Datenarten als Auslöser und Privacy ausdrücklich als eine der abzudeckenden Disziplinen."
    },
    {
     "ref": "A.7.2",
     "titel": "Data for development and enhancement of AI system",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.7.2 verlangt dokumentierte Datenmanagementprozesse; B.7.2 führt „privacy and security implications due to the use of data, some of which can be sensitive in nature“ als Pflichtthema."
    },
    {
     "ref": "A.7.3",
     "titel": "Acquisition of data",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.7.3 verlangt Dokumentation von Datenbeschaffung und -auswahl; B.7.3 nennt Datenrechte (PII, Urheberrecht) und die Konformität der Vorverwendung mit Datenschutzanforderungen als Prüfpunkte."
    },
    {
     "ref": "A.2.3",
     "titel": "Alignment with other organizational policies",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.2.3 verlangt die Abstimmung mit anderen Unternehmensrichtlinien und bindet damit bestehende Datenschutzvorgaben an das KI-Managementsystem an, ohne eigene Prüfpflichten zu begründen."
    },
    {
     "ref": "A.5.3",
     "titel": "Documentation of AI system impact assessments",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.5.3 regelt nur Form und Aufbewahrung der Ergebnisdokumentation der Impact Assessments, nicht die inhaltliche Untersuchung des Datenschutzrisikos."
    }
   ],
   "luecke": "ISO/IEC 42001 kennt keine eigenständige Datenschutz-Folgenabschätzung und keine Privacy-Metriken (z. B. Re-Identifikations-, Memorisierungs- oder Inferenzrisiko); B.5.2 verweist für die disziplinspezifische Tiefe auf getrennte Regelwerke wie ISO/IEC 27701."
  },
  "MEASURE 2.11": {
   "iso": [
    {
     "ref": "A.5.4",
     "titel": "Assessing AI system impact on individuals or groups of individuals",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.5.4 fordert Bewertung und Dokumentation der Auswirkungen auf Individuen und Gruppen; B.5.4 nennt „fairness“ als ersten der zu betrachtenden Wirkungsbereiche und verlangt die Berücksichtigung besonders schutzbeduerftiger Gruppen."
    },
    {
     "ref": "A.7.4",
     "titel": "Quality of data for AI systems",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.7.4 verlangt definierte Datenqualitätsanforderungen; B.7.4 fordert ausdrücklich, die Wirkung von Bias auf Systemleistung und Fairness zu berücksichtigen und Modell oder Daten entsprechend anzupassen."
    },
    {
     "ref": "A.5.5",
     "titel": "Assessing societal impacts of AI systems",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "B.5.5 verlangt die Analyse, wie KI-Systeme unerwünschte historische soziale Verzerrungen verstärken können; das ist eine gesellschaftliche Betrachtung, keine Evaluation der Systemergebnisse."
    },
    {
     "ref": "A.6.1.2",
     "titel": "Objectives for responsible development of AI system",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "B.6.1.2 führt Fairness nur als Beispiel für ein Entwicklungsziel an, das bis in Verifizierung und Validierung zu tragen ist; eine Fairness-Bewertung ist damit nicht normativ gefordert."
    },
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.6.2.4 verlangt Evaluationskriterien, die sich an den Zielen verantwortlicher Entwicklung (B.6.1.2) orientieren; Fairness wird dadurch nur mittelbar und nur bei entsprechender Zielsetzung geprüft."
    },
    {
     "ref": "A.7.3",
     "titel": "Acquisition of data",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "B.7.3 nennt Demografie und Merkmale der Datensubjekte einschließlich bekannter oder potenzieller Verzerrungen als zu dokumentierendes Beschaffungsdetail, ohne eine Bias-Messung vorzuschreiben."
    }
   ],
   "luecke": "ISO/IEC 42001 nennt weder Fairness-Metriken noch Definitionen geschützter Gruppen, Disparitätsschwellen oder Bias-Testverfahren; Fairness erscheint ausschließlich als Wirkungsdimension (A.5.4) und als Beispielziel (A.6.1.2) ohne Evaluationsmethodik und ohne Anforderung, Ergebnisse als Messgrößen auszuweisen."
  },
  "MEASURE 2.12": {
   "iso": [
    {
     "ref": "A.5.5",
     "titel": "Assessing societal impacts of AI systems",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.5.5 verlangt Bewertung und Dokumentation gesellschaftlicher Auswirkungen; B.5.5 nennt Umweltverträglichkeit einschließlich Treibhausgasemissionen und fordert, die Wirkung rechenintensiver Entwicklung im Kontext der Nachhaltigkeitsziele zu betrachten."
    },
    {
     "ref": "6.1.4",
     "titel": "AI system impact assessment",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "6.1.4 verpflichtet zur Folgenabschätzung für Individuen, Gruppen und Gesellschaften; Umweltwirkungen sind nur über die gesellschaftliche Dimension und ohne eigene Anforderung erfasst."
    },
    {
     "ref": "A.4.2",
     "titel": "Resource documentation",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.4.2 fordert die Identifikation und Dokumentation aller je Lebenszyklusphase benötigten Ressourcen; ein Bezug zu Umweltwirkung oder Verbrauchsbilanzierung fehlt."
    },
    {
     "ref": "A.4.5",
     "titel": "System and computing resources",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.4.5 verlangt die Dokumentation der genutzten System- und Rechenressourcen und liefert damit allenfalls die Datenbasis für eine Energiebetrachtung, nicht deren Bewertung."
    },
    {
     "ref": "A.5.2",
     "titel": "AI system impact assessment process",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.5.2 etabliert nur den generischen Prozess zur Folgenabschätzung über den Lebenszyklus; Umweltauswirkungen sind darin ein möglicher, nicht benannter Prüfgegenstand."
    },
    {
     "ref": "A.5.3",
     "titel": "Documentation of AI system impact assessments",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.5.3 sichert die Dokumentation und Aufbewahrung der Assessment-Ergebnisse, trifft aber keine Aussage zu Umwelt- oder Nachhaltigkeitsinhalten."
    }
   ],
   "luecke": "Es gibt keine normative Anforderung zur Quantifizierung von Energieverbrauch, CO₂-Bilanz, Wasser- oder Flächenverbrauch des Modelltrainings und -betriebs; Umweltwirkung erscheint allein als Beispielkategorie gesellschaftlicher Auswirkungen in B.5.5, Messmethodik, Kennzahlen und Berichtspflicht fehlen vollständig."
  },
  "MEASURE 2.13": {
   "iso": [
    {
     "ref": "9.1",
     "titel": "Monitoring, measurement, analysis and evaluation",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "9.1 verlangt, die Methoden für Überwachung, Messung, Analyse und Bewertung so festzulegen, dass valide Ergebnisse sichergestellt sind, und dies durch dokumentierte Information zu belegen."
    },
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.4 fordert dokumentierte V&V-Maßnahmen mit Kriterien für ihre Anwendung; B.6.2.4 verlangt zudem, bei Nichterreichen der Kriterien Zweck, Leistungsanforderungen und Maßnahmen neu zu bewerten."
    },
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.2.6 verlangt sicherzustellen, dass die zur Evaluation eingesetzten Mittel und Prozesse einschließlich der Auswahl der Evaluationsdaten Vollständigkeit und Zuverlässigkeit der Leistungsbeurteilung verbessern."
    },
    {
     "ref": "10.1",
     "titel": "Continual improvement",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "10.1 verpflichtet zur fortlaufenden Verbesserung von Eignung, Angemessenheit und Wirksamkeit des Managementsystems und erfasst TEVV-Prozesse nur als unbenannten Teil davon."
    },
    {
     "ref": "10.2",
     "titel": "Nonconformity and corrective action",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "10.2 verlangt bei Nichtkonformitäten eine Ursachenanalyse und die Überprüfung der Wirksamkeit der Korrekturmaßnahme; das greift erst reaktiv und nicht bei der Bewertung der Metriken selbst."
    },
    {
     "ref": "9.2.1",
     "titel": "Internal audit — General",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "9.2.1 prüft, ob das KI-Managementsystem die eigenen und die Normanforderungen erfüllt und wirksam umgesetzt ist; die fachliche Güte einzelner Testmetriken ist nicht Auditgegenstand."
    }
   ],
   "luecke": "Eine eigenständige Meta-Evaluation der TEVV-Metriken selbst (Validität, Sensitivität, Verzerrung und Aussagekraft der Messverfahren) fordert ISO/IEC 42001 nicht; 9.1 zielt auf die Wirksamkeit des Managementsystems, nicht auf die Güte der eingesetzten Testmetriken."
  },
  "MEASURE 3.1": {
   "iso": [
    {
     "ref": "8.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "8.2 verlangt die Durchführung der KI-Risikobewertung in geplanten Abständen sowie bei wesentlichen Änderungen und deckt damit die von NIST geforderte regelmäßige Identifikation und Verfolgung bestehender Risiken ab."
    },
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.6 fordert System- und Leistungsüberwachung im Betrieb; B.6.2.6 adressiert ausdrücklich Abweichungen gegenüber Produktionsdaten, Konzept- und Datendrift sowie nicht antizipierte Nutzungsarten."
    },
    {
     "ref": "6.1.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.1.2 verlangt einen dokumentierten Prozess mit Risikokriterien, Identifikation, Analyse und Bewertung und liefert damit den von NIST geforderten methodischen Ansatz, ohne den Einsatzkontext eigens zu adressieren."
    },
    {
     "ref": "A.4.6",
     "titel": "Human resources",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.4.6 fordert die Dokumentation der eingesetzten Humanressourcen und ihrer Kompetenzen über alle Lebenszyklusphasen und deckt damit den Aspekt „personnel“ der Subkategorie ab."
    },
    {
     "ref": "A.6.2.8",
     "titel": "AI system recording of event logs",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.8 verlangt Ereignisprotokollierung mindestens im Nutzungsbetrieb; B.6.2.8 nennt die Erkennung von Leistung außerhalb der vorgesehenen Betriebsbedingungen als ausdrücklichen Zweck."
    },
    {
     "ref": "10.1",
     "titel": "Continual improvement",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "10.1 fordert fortlaufende Verbesserung des Managementsystems und stützt die Weiterentwicklung der Risikoverfolgung nur allgemein, ohne Verfahren zu benennen."
    },
    {
     "ref": "8.4",
     "titel": "AI system impact assessment",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "8.4 verlangt die Folgenabschätzung in geplanten Abständen und bei Änderungen; sie erfasst Auswirkungen auf Betroffene, nicht die laufende Verfolgung technischer Leistungsrisiken."
    }
   ],
   "luecke": "Verfahren zur aktiven Entdeckung unvorhergesehener und emergenter Risiken (z. B. Red Teaming, adversariales Testen, Horizon Scanning, Incident-Auswertung als Risikoquelle) benennt ISO/IEC 42001 nicht; die Norm bleibt beim turnusmäßigen Wiederholen der bekannten Risikobewertung."
  },
  "MEASURE 3.2": {
   "iso": [
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.2.4 verlangt, akzeptable Faktoren für das Nichterreichen eines Mindestleistungsniveaus zu benennen und Mechanismen zum Umgang mit dadurch bedingter schlechter Leistung zu dokumentieren."
    },
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.2.6 fordert zu prüfen, ob erkannte Probleme mit bestehenden Maßnahmen beherrschbar sind, und andernfalls bestehende Maßnahmen zu ändern oder zusätzliche zu definieren."
    },
    {
     "ref": "10.1",
     "titel": "Continual improvement",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "10.1 verpflichtet zur fortlaufenden Verbesserung und erlaubt so das Nachrüsten von Messverfahren, benennt aber kein Vorgehen für den Zeitraum ohne verfügbare Metriken."
    },
    {
     "ref": "6.1.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "6.1.2 verlangt Risikokriterien sowie Analyse von Konsequenzen und Eintrittswahrscheinlichkeit, setzt dabei aber bewertbare Risiken voraus und regelt den Fall fehlender Messbarkeit nicht."
    },
    {
     "ref": "8.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "8.2 sichert die wiederkehrende Durchführung der Risikobewertung; für schwer bewertbare Risiken stellt die Wiederholung allein kein Verfolgungsverfahren dar."
    },
    {
     "ref": "A.6.2.8",
     "titel": "AI system recording of event logs",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.6.2.8 verlangt Ereignisprotokolle einschließlich Ausgaben außerhalb des vorgesehenen Betriebsbereichs und liefert damit qualitative Beobachtungsdaten, wo Metriken fehlen, ohne dies als Ersatzverfahren auszuweisen."
    }
   ],
   "luecke": "Den Fall nicht messbarer oder noch nicht metrifizierbarer Risiken adressiert ISO/IEC 42001 nicht: qualitative Ersatzverfahren wie strukturiertes Expertenurteil, dokumentierte Unsicherheitsangaben, Beobachtungsregister oder eine explizite Kennzeichnung ungemessener Risiken sind normativ nicht vorgesehen."
  },
  "MEASURE 3.3": {
   "iso": [
    {
     "ref": "A.8.3",
     "titel": "External reporting",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.8.3 verpflichtet die Organisation, interessierten Parteien Möglichkeiten zur Meldung nachteiliger Auswirkungen bereitzustellen; B.8.3 nennt ausdrücklich Nutzer und externe Dritte sowie Unfairness als Meldegegenstand."
    },
    {
     "ref": "A.3.3",
     "titel": "Reporting of concerns",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.3.3 verlangt einen Prozess zur Meldung von Bedenken zur Rolle der Organisation beim KI-System über dessen Lebenszyklus, adressiert dabei aber vorrangig interne Meldewege."
    },
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.2.6 verlangt Supportprozesse, die regeln, wie Nutzer Hilfe erreichen, wie Probleme und Vorfälle gemeldet werden sowie welche Service-Level und Metriken dafür gelten."
    },
    {
     "ref": "A.8.2",
     "titel": "System documentation and information for users",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.8.2 fordert die notwendigen Nutzerinformationen; B.8.2 nennt Kontaktinformationen sowie Angaben dazu, wie und wann das System übersteuert werden kann, als bereitzustellende Inhalte."
    },
    {
     "ref": "9.1",
     "titel": "Monitoring, measurement, analysis and evaluation",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "9.1 verlangt festzulegen, was zu überwachen und zu messen ist, verpflichtet aber nicht dazu, Rückmeldungen von Nutzern und Betroffenen in die Evaluationsgrößen zu überführen."
    },
    {
     "ref": "A.10.4",
     "titel": "Customers",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.10.4 verlangt, Erwartungen und Beduerfnisse von Kunden im verantwortlichen Umgang mit KI zu berücksichtigen; betroffene Gemeinschaften ohne Kundenbeziehung sind davon nicht erfasst."
    },
    {
     "ref": "A.8.4",
     "titel": "Communication of incidents",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.8.4 regelt die Kommunikation von Vorfällen an Nutzer und damit die ausgehende Richtung; ein Rückkanal für Betroffene wird dadurch nicht geschaffen."
    }
   ],
   "luecke": "Ein Rechtsbehelf gegen Einzelergebnisse („appeal system outcomes“) fehlt in ISO/IEC 42001 vollständig: A.8.3 sieht nur einen Meldekanal für nachteilige Auswirkungen vor, ohne Anspruch auf Überprüfung, Korrektur oder menschliche Nachentscheidung. Ebenso fehlt die Anforderung, Feedback systematisch in die Evaluationsmetriken des Systems zu integrieren."
  },
  "MEASURE 4.1": {
   "iso": [
    {
     "ref": "9.1",
     "titel": "Monitoring, measurement, analysis and evaluation",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "9.1 verlangt festzulegen, was überwacht und gemessen wird, mit welchen Methoden, zu welchem Zeitpunkt und wann ausgewertet wird, und dies durch dokumentierte Information zu belegen."
    },
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.4 fordert dokumentierte V&V-Maßnahmen und Kriterien; B.6.2.4 verlangt ausdrücklich die Auswahl von Testdaten und deren Repräsentativität für den vorgesehenen Anwendungsbereich."
    },
    {
     "ref": "6.1.2",
     "titel": "AI risk assessment",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "6.1.2 verlangt einen dokumentierten Risikobewertungsprozess mit festgelegten Kriterien und liefert damit den dokumentierten Ansatz zur Risikoidentifikation, ohne den Einsatzkontext eigens zu verankern."
    },
    {
     "ref": "A.5.4",
     "titel": "Assessing AI system impact on individuals or groups of individuals",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.5.4 empfiehlt die Konsultation von Experten wie Forschenden, Fachleuten und Nutzern, um die potenziellen Auswirkungen des Systems vollständig zu erfassen."
    },
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.6.2.6 verlangt, akzeptable Werte je Metrik unter anderem auf Basis von Empfehlungen von Domänenexperten und der Analyse von Erwartungen interessierter Parteien festzulegen."
    },
    {
     "ref": "4.2",
     "titel": "Understanding the needs and expectations of interested parties",
     "typ": "klausel",
     "staerke": "schwach",
     "begruendung": "4.2 verlangt, Beduerfnisse und Erwartungen interessierter Parteien zu bestimmen; das begründet eine Kenntnisnahme, nicht die Einbindung von Experten in die Gestaltung der Messansätze."
    },
    {
     "ref": "A.5.5",
     "titel": "Assessing societal impacts of AI systems",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.5.5 verpflichtet zur Bewertung gesellschaftlicher Auswirkungen und liefert damit Kontextwissen zum Einsatzumfeld, aber keine Messansätze zur Risikoidentifikation."
    }
   ],
   "luecke": "Die Konsultation von Domänenexperten und Endnutzern ist in ISO/IEC 42001 nur als Guidance-Empfehlung („where necessary“, B.5.4) formuliert und nicht als normative Anforderung; ein dokumentierter Konsultationsprozess speziell für die Herleitung der Messansätze wird nicht verlangt."
  },
  "MEASURE 4.2": {
   "iso": [
    {
     "ref": "9.1",
     "titel": "Monitoring, measurement, analysis and evaluation",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "9.1 verlangt die Analyse und Bewertung der Überwachungs- und Messergebnisse sowie dokumentierte Information als Nachweis der Ergebnisse und deckt damit die Dokumentationspflicht der Subkategorie ab."
    },
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.6 fordert System- und Leistungsüberwachung im laufenden Betrieb; B.6.2.6 verlangt zu überwachen, ob das System mit Produktionsdaten wie erwartet arbeitet und seine Entwurfsziele weiterhin erfüllt."
    },
    {
     "ref": "9.2.1",
     "titel": "Internal audit — General",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "9.2.1 verlangt interne Audits in geplanten Abständen zur Frage, ob das KI-Managementsystem konform und wirksam umgesetzt ist, und liefert so eine unabhängige Validierungsschleife."
    },
    {
     "ref": "A.5.4",
     "titel": "Assessing AI system impact on individuals or groups of individuals",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "B.5.4 empfiehlt, Fachleute und Nutzer heranzuziehen, um die Auswirkungen des Systems vollständig zu verstehen, und stützt damit die geforderte Expertenrückkopplung der Messergebnisse."
    },
    {
     "ref": "A.6.2.4",
     "titel": "AI system verification and validation",
     "typ": "control",
     "staerke": "mittel",
     "begruendung": "A.6.2.4 verlangt die Bewertung des Systems gegen die dokumentierten Evaluationskriterien einschließlich Zuverlässigkeits-, Sicherheits- und Fehlerratenanforderungen über den Lebenszyklus."
    },
    {
     "ref": "A.8.2",
     "titel": "System documentation and information for users",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "B.8.2 nennt Angaben zu Genauigkeit und Leistung als Nutzerinformation; das betrifft die Weitergabe der Ergebnisse, nicht deren Validierung."
    },
    {
     "ref": "A.8.3",
     "titel": "External reporting",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.8.3 eröffnet Meldewege für nachteilige Auswirkungen und liefert damit Feldrückmeldungen, ohne diese als Eingangsgröße der Ergebnisvalidierung vorzuschreiben."
    }
   ],
   "luecke": "„Trustworthiness“ als zusammengesetztes, aus mehreren Dimensionen (Robustheit, Sicherheit, Erklärbarkeit, Fairness, Datenschutz) bestehendes Messobjekt definiert ISO/IEC 42001 nicht; die Norm verlangt Leistungsüberwachung gegen selbst gesetzte Kriterien, ohne Vertrauenswürdigkeitsdimensionen oder eine lebenszyklusübergreifende Zusammenschau vorzugeben."
  },
  "MEASURE 4.3": {
   "iso": [
    {
     "ref": "9.3.2",
     "titel": "Management review inputs",
     "typ": "klausel",
     "staerke": "stark",
     "begruendung": "9.3.2 verlangt als Eingaben der Managementbewertung ausdrücklich Trends bei Überwachungs- und Messergebnissen, Nichtkonformitäten und Auditergebnissen sowie Änderungen der Erwartungen interessierter Parteien."
    },
    {
     "ref": "A.6.2.6",
     "titel": "AI system operation and monitoring",
     "typ": "control",
     "staerke": "stark",
     "begruendung": "A.6.2.6 fordert fortlaufende Leistungsüberwachung; B.6.2.6 adressiert Leistungsveränderungen durch Konzept- und Datendrift sowie den daraus abgeleiteten Nachtrainingsbedarf."
    },
    {
     "ref": "10.1",
     "titel": "Continual improvement",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "10.1 verpflichtet zur fortlaufenden Verbesserung von Eignung, Angemessenheit und Wirksamkeit und setzt damit die Identifikation von Leistungsveränderungen voraus."
    },
    {
     "ref": "9.1",
     "titel": "Monitoring, measurement, analysis and evaluation",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "9.1 verlangt festzulegen, wann Messergebnisse analysiert und bewertet werden, und diese Ergebnisse dokumentiert nachzuweisen; damit sind Verbesserungen und Verschlechterungen belegbar."
    },
    {
     "ref": "9.3.3",
     "titel": "Management review results",
     "typ": "klausel",
     "staerke": "mittel",
     "begruendung": "9.3.3 verlangt, dass die Ergebnisse der Managementbewertung Entscheidungen zu Verbesserungsmöglichkeiten und Änderungsbedarf enthalten und dokumentiert vorliegen."
    },
    {
     "ref": "A.6.2.7",
     "titel": "AI system technical documentation",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "B.6.2.7 nennt im Betrieb vorgenommene Systemänderungen und Verifizierungsnachweise als Dokumentationsinhalte und sichert damit nur die Nachvollziehbarkeit der Veränderungen."
    },
    {
     "ref": "A.8.3",
     "titel": "External reporting",
     "typ": "control",
     "staerke": "schwach",
     "begruendung": "A.8.3 stellt Meldewege für nachteilige Auswirkungen bereit und liefert so Felddaten von Betroffenen, ohne deren Auswertung als Leistungsindikator zu verankern."
    }
   ],
   "luecke": "Die systematische Einbeziehung betroffener Gemeinschaften („affected communities“) in die Bewertung von Leistungsveränderungen fordert ISO/IEC 42001 nicht; A.8.3 eröffnet lediglich einen Meldekanal, ohne dessen Auswertung als verpflichtende Eingangsgröße der Leistungs- und Managementbewertung zu verankern."
  }
 },
 "iso_zu_nist": {
  "4.1": [
   {
    "ref": "GOVERN 1.1",
    "text": "Rechtliche und regulatorische Anforderungen an KI sind verstanden, werden gesteuert und dokumentiert.",
    "staerke": "stark",
    "begruendung": "4.1 verlangt die Bestimmung externer und interner Themen, die die Zielerreichung des AIMS beeinflussen; das Rechts- und Regulierungsumfeld ist das klassische externe Thema. Zusätzlich ist der intended purpose der AI-Systeme und die eigene Rolle zu bestimmen, was die Anwendbarkeit von Rechtspflichten erst bestimmbar macht."
   },
   {
    "ref": "MAP 1.1",
    "text": "Zweckbestimmung, nutzbringende Anwendungen, kontextspezifische Rechtsvorschriften und Erwartungen sowie die vorgesehene Einsatzumgebung des KI-Systems sind verstanden und dokumentiert. Zu berücksichtigen sind dabei Nutzergruppen, positive wie negative Auswirkungen, Annahmen und Grenzen, Risiken über den KI-Lebenszyklus sowie TEVV (Test, Evaluation, Verification, Validation) und Systemkennzahlen.",
    "staerke": "stark",
    "begruendung": "4.1 verlangt die Bestimmung externer und interner Themen und ausdrücklich die Berücksichtigung des „intended purpose of the AI systems“ sowie der eigenen Rolle. Damit ist die Kernforderung von MAP 1.1 (Zweck und Kontext verstehen) normativ abgedeckt."
   },
   {
    "ref": "MAP 1.3",
    "text": "Auftrag und einschlägige Ziele der Organisation für die KI-Technologie sind verstanden und dokumentiert.",
    "staerke": "stark",
    "begruendung": "4.1 verlangt, die für den Zweck der Organisation relevanten Themen zu bestimmen, die das Erreichen der beabsichtigten Ergebnisse des AIMS beeinflussen. Damit ist der Bezug zwischen Organisationsauftrag und KI-Einsatz normativ verankert."
   },
   {
    "ref": "GOVERN 1.6",
    "text": "Mechanismen zur Inventarisierung der KI-Systeme bestehen und sind entsprechend den Risikoprioritäten der Organisation mit Ressourcen ausgestattet.",
    "staerke": "mittel",
    "begruendung": "4.1 verlangt, den intended purpose der entwickelten, bereitgestellten oder genutzten AI-Systeme zu berücksichtigen und die eigenen Rollen dazu zu bestimmen. Das setzt faktisch eine Übersicht der AI-Systeme im Geltungsbereich voraus."
   },
   {
    "ref": "MAP 1.4",
    "text": "Der geschäftliche Nutzen bzw. der betriebliche Einsatzkontext ist klar definiert oder – bei der Bewertung bestehender KI-Systeme – erneut bewertet.",
    "staerke": "mittel",
    "begruendung": "4.1 verlangt die Berücksichtigung des beabsichtigten Zwecks der entwickelten, bereitgestellten oder genutzten KI-Systeme und die Bestimmung der eigenen Rolle. Der geschäftliche Nutzungskontext wird so erfasst, nicht aber dessen Wertbeitrag."
   },
   {
    "ref": "MAP 3.3",
    "text": "Der angestrebte Anwendungsbereich ist auf Basis der Systemfähigkeiten, des bestimmten Kontexts und der Kategorisierung des KI-Systems festgelegt und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "4.1 verlangt die Berücksichtigung des beabsichtigten Zwecks der KI-Systeme und die Bestimmung der Rollen der Organisation. Das bildet den „established context“ als Grundlage der Scope-Festlegung."
   },
   {
    "ref": "MAP 4.1",
    "text": "Vorgehensweisen zur Erfassung technischer und rechtlicher Risiken der Systemkomponenten – einschließlich der Nutzung von Daten oder Software Dritter sowie möglicher Verletzungen von Rechten des geistigen Eigentums oder sonstiger Rechte Dritter – bestehen, werden angewendet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "4.1 verlangt die Bestimmung externer und interner Themen, die die Zielerreichung des AIMS beeinflussen; dazu zählen rechtliche Rahmenbedingungen. Ein strukturiertes Verfahren zur Rechtsrisikoanalyse folgt daraus jedoch nicht."
   }
  ],
  "4.2": [
   {
    "ref": "GOVERN 1.1",
    "text": "Rechtliche und regulatorische Anforderungen an KI sind verstanden, werden gesteuert und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "4.2 fordert die Ermittlung der interested parties (u.a. Aufsichtsbehörden, Gesetzgeber), deren relevanter Anforderungen und der Entscheidung, welche davon über das AIMS adressiert werden. Damit ist das Verstehen und Zuordnen rechtlicher Anforderungen normiert, nicht aber deren laufende Pflege."
   },
   {
    "ref": "GOVERN 5.1",
    "text": "Richtlinien und Praktiken stellen sicher, dass Rückmeldungen von Beteiligten außerhalb des entwickelnden oder bereitstellenden Teams zu möglichen individuellen und gesellschaftlichen Auswirkungen erhoben, bewertet, priorisiert und eingebunden werden.",
    "staerke": "mittel",
    "begruendung": "4.2 verlangt, die relevanten interested parties, deren relevante Anforderungen und die Entscheidung zu bestimmen, welche dieser Anforderungen über das AIMS adressiert werden. Das deckt die Ermittlung der Erwartungen ab, nicht aber das laufende Einsammeln, Priorisieren und Einarbeiten externer Rückmeldungen, das GOVERN 5.1 verlangt."
   },
   {
    "ref": "MAP 1.1",
    "text": "Zweckbestimmung, nutzbringende Anwendungen, kontextspezifische Rechtsvorschriften und Erwartungen sowie die vorgesehene Einsatzumgebung des KI-Systems sind verstanden und dokumentiert. Zu berücksichtigen sind dabei Nutzergruppen, positive wie negative Auswirkungen, Annahmen und Grenzen, Risiken über den KI-Lebenszyklus sowie TEVV (Test, Evaluation, Verification, Validation) und Systemkennzahlen.",
    "staerke": "mittel",
    "begruendung": "4.2 verlangt die Bestimmung relevanter interessierter Parteien und ihrer Anforderungen und trifft damit die NIST-Forderung nach Nutzertypen und deren Erwartungen. Normen und gesellschaftliche Erwartungen werden jedoch nur mittelbar über die interessierten Parteien erfasst."
   },
   {
    "ref": "MAP 1.6",
    "text": "Systemanforderungen (z. B. Wahrung der Privatsphäre der Nutzer) werden bei den relevanten KI-Akteuren erhoben und von ihnen verstanden; Designentscheidungen berücksichtigen soziotechnische Wirkungen, um KI-Risiken zu adressieren.",
    "staerke": "mittel",
    "begruendung": "4.2 verlangt die Bestimmung der relevanten Anforderungen interessierter Parteien und die Entscheidung, welche davon über das AIMS adressiert werden. Das ist der normative Anker für die Erhebung von Anforderungen bei relevanten Akteuren."
   },
   {
    "ref": "MAP 5.2",
    "text": "Praktiken und Personal für den regelmäßigen Austausch mit relevanten KI-Akteuren sowie für die Einbindung von Rückmeldungen zu positiven, negativen und unerwarteten Auswirkungen bestehen und sind dokumentiert.",
    "staerke": "mittel",
    "begruendung": "4.2 verlangt die Bestimmung der relevanten interessierten Parteien, ihrer Anforderungen und der Entscheidung, welche davon adressiert werden. Das definiert den Kreis der einzubindenden AI-Akteure."
   },
   {
    "ref": "MANAGE 4.2",
    "text": "Messbare Aktivitäten zur kontinuierlichen Verbesserung sind in die Aktualisierung der KI-Systeme eingebunden und umfassen den regelmäßigen Austausch mit interessierten Parteien einschließlich relevanter KI-Akteure.",
    "staerke": "mittel",
    "begruendung": "4.2 verlangt die Bestimmung der relevanten interessierten Parteien und ihrer Bedarfe und Erwartungen; 9.3.2 c) fordert deren Veränderungen als Input der Managementbewertung. Verankert die Einbeziehung interessierter Parteien, aber nicht als regelmäßige Beteiligung am Systemupdate."
   },
   {
    "ref": "MEASURE 4.1",
    "text": "Messansätze zur Identifikation von KI-Risiken sind auf den jeweiligen Einsatzkontext bezogen und werden unter Einbeziehung von Fachexperten und Endnutzern abgestimmt; die Ansätze sind dokumentiert.",
    "staerke": "schwach",
    "begruendung": "4.2 verlangt, Beduerfnisse und Erwartungen interessierter Parteien zu bestimmen; das begründet eine Kenntnisnahme, nicht die Einbindung von Experten in die Gestaltung der Messansätze."
   }
  ],
  "4.3": [
   {
    "ref": "MAP 3.3",
    "text": "Der angestrebte Anwendungsbereich ist auf Basis der Systemfähigkeiten, des bestimmten Kontexts und der Kategorisierung des KI-Systems festgelegt und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "4.3 betrifft die Festlegung des Geltungsbereichs des AI-Managementsystems, nicht den Anwendungsbereich des einzelnen KI-Systems; die Baseline setzt beides fälschlich gleich. Ein Bezug besteht nur insoweit, als der AIMS-Scope die einbezogenen Systeme und Tätigkeiten abgrenzt und dokumentiert vorliegen muss."
   }
  ],
  "4.4": [],
  "5.1": [
   {
    "ref": "GOVERN 2.3",
    "text": "Die oberste Leitung übernimmt die Verantwortung für Entscheidungen über Risiken bei Entwicklung und Bereitstellung von KI-Systemen.",
    "staerke": "stark",
    "begruendung": "5.1 verlangt vom Top-Management den Nachweis von Leadership und Commitment, u.a. die Integration der AIMS-Anforderungen in die Geschäftsprozesse, die Bereitstellung der Ressourcen und die Sicherstellung der beabsichtigten Ergebnisse. Das ist die zentrale Verantwortungsklausel."
   },
   {
    "ref": "MAP 1.3",
    "text": "Auftrag und einschlägige Ziele der Organisation für die KI-Technologie sind verstanden und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "5.1 verpflichtet die oberste Leitung sicherzustellen, dass KI-Politik und KI-Ziele mit der strategischen Ausrichtung der Organisation vereinbar sind. Das stellt die Verbindung zur Mission her, ohne sie eigenständig zu dokumentieren."
   },
   {
    "ref": "MAP 1.4",
    "text": "Der geschäftliche Nutzen bzw. der betriebliche Einsatzkontext ist klar definiert oder – bei der Bewertung bestehender KI-Systeme – erneut bewertet.",
    "staerke": "mittel",
    "begruendung": "5.1 verlangt die Integration der AIMS-Anforderungen in die Geschäftsprozesse der Organisation und die Vereinbarkeit mit der strategischen Ausrichtung. Das verankert den geschäftlichen Nutzungskontext auf Leitungsebene."
   }
  ],
  "5.2": [
   {
    "ref": "MAP 1.3",
    "text": "Auftrag und einschlägige Ziele der Organisation für die KI-Technologie sind verstanden und dokumentiert.",
    "staerke": "stark",
    "begruendung": "5.2 fordert eine KI-Politik, die „appropriate to the purpose of the organization“ ist, einen Rahmen für KI-Ziele bietet und als dokumentierte Information vorliegt. Mission und Zielrahmen sind damit dokumentiert."
   },
   {
    "ref": "GOVERN 1.2",
    "text": "Die Merkmale vertrauenswürdiger KI sind in die Richtlinien, Prozesse und Verfahren der Organisation integriert.",
    "staerke": "mittel",
    "begruendung": "5.2 verpflichtet das Top-Management auf eine AI policy, die einen Rahmen für AI-Ziele setzt, ein Bekenntnis zur Erfüllung anwendbarer Anforderungen enthält und auf andere Policies der Organisation verweist. Die Klausel liefert den formalen Rahmen, benennt die Trustworthiness-Merkmale aber nicht."
   },
   {
    "ref": "GOVERN 2.3",
    "text": "Die oberste Leitung übernimmt die Verantwortung für Entscheidungen über Risiken bei Entwicklung und Bereitstellung von KI-Systemen.",
    "staerke": "mittel",
    "begruendung": "5.2 verpflichtet das Top-Management, die AI policy einschließlich des Bekenntnisses zur Erfüllung anwendbarer Anforderungen und zur kontinuierlichen Verbesserung zu etablieren. Damit ist die Leitungsverantwortung auf Policy-Ebene verankert."
   }
  ],
  "5.3": [
   {
    "ref": "GOVERN 2.1",
    "text": "Rollen, Verantwortlichkeiten und Kommunikationswege für das Erfassen, Messen und Behandeln von KI-Risiken sind dokumentiert und organisationsweit bekannt.",
    "staerke": "stark",
    "begruendung": "5.3 verlangt, dass das Top-Management Verantwortlichkeiten und Befugnisse für relevante Rollen zuweist und innerhalb der Organisation kommuniziert. Das entspricht unmittelbar der Forderung nach dokumentierten und organisationsweit klaren Rollen."
   },
   {
    "ref": "GOVERN 1.5",
    "text": "Fortlaufende Überwachung und regelmäßige Überprüfung des Risikomanagementprozesses und seiner Ergebnisse sind geplant; Rollen, Verantwortlichkeiten und Prüfintervalle sind klar festgelegt.",
    "staerke": "mittel",
    "begruendung": "5.3 verlangt, dass Verantwortlichkeiten und Befugnisse zugewiesen und in der Organisation kommuniziert werden, einschließlich der Berichterstattung über die AIMS-Leistung an das Top-Management. Das ist die klauselseitige Verankerung der Rollenklarheit."
   },
   {
    "ref": "GOVERN 2.3",
    "text": "Die oberste Leitung übernimmt die Verantwortung für Entscheidungen über Risiken bei Entwicklung und Bereitstellung von KI-Systemen.",
    "staerke": "mittel",
    "begruendung": "5.3 verlangt, dass das Top-Management die Verantwortung für die Konformität des AIMS und für die Berichterstattung über dessen Leistung an das Top-Management zuweist. Das sichert die Rückkopplung von Risikoinformationen an die Leitung."
   },
   {
    "ref": "GOVERN 3.2",
    "text": "Richtlinien und Verfahren definieren und unterscheiden Rollen und Verantwortlichkeiten für das Zusammenwirken von Mensch und KI sowie für die Aufsicht über KI-Systeme.",
    "staerke": "mittel",
    "begruendung": "5.3 verlangt die Zuweisung und Kommunikation von Verantwortlichkeiten und Befugnissen für relevante Rollen. Das ist der klauselseitige Anker für die Differenzierung von Aufsichtsrollen."
   }
  ],
  "6.1.1": [
   {
    "ref": "GOVERN 1.3",
    "text": "Prozesse und Verfahren legen fest, welcher Umfang an Risikomanagement-Aktivitäten erforderlich ist; Maßstab ist die Risikotoleranz der Organisation.",
    "staerke": "stark",
    "begruendung": "6.1.1 verlangt, AI risk criteria zu etablieren und zu pflegen, die acceptable von non-acceptable risks unterscheiden, und Risiken nach domain, application context und intended use zu bestimmen. Genau daraus ergibt sich das erforderliche Maß an Risikomanagement-Aktivitäten."
   },
   {
    "ref": "MAP 1.5",
    "text": "Die Risikotoleranzen der Organisation sind bestimmt und dokumentiert.",
    "staerke": "stark",
    "begruendung": "6.1.1 (korrekter Titel: General, nicht „Objective“) verlangt, KI-Risikokriterien zu etablieren und aufrechtzuerhalten, die „distinguishing acceptable from non-acceptable risks“ unterstützen. Das ist die normative Entsprechung der organisationalen Risikotoleranz, mit Pflicht zur Aufbewahrung dokumentierter Information."
   },
   {
    "ref": "MAP 3.1",
    "text": "Der potenzielle Nutzen der vorgesehenen Funktionalität und Leistung des KI-Systems ist geprüft und dokumentiert.",
    "staerke": "stark",
    "begruendung": "6.1.1 verlangt, Risiken UND Chancen zu bestimmen, die adressiert werden müssen, und dazu dokumentierte Information aufzubewahren („actions taken to identify and address AI risks and AI opportunities“). Die Chancenseite ist die normative Entsprechung zu „potential benefits ... examined and documented“."
   },
   {
    "ref": "GOVERN 1.4",
    "text": "Der Risikomanagementprozess und seine Ergebnisse sind über transparente Richtlinien, Verfahren und weitere Maßnahmen festgelegt, ausgerichtet an den Risikoprioritäten der Organisation.",
    "staerke": "mittel",
    "begruendung": "6.1.1 verlangt dokumentierte Risikokriterien und das Aufbewahren dokumentierter Information über Maßnahmen zur Identifikation und Behandlung von AI-Risiken. Das liefert die Grundlage der organizational risk priorities."
   },
   {
    "ref": "MAP 3.2",
    "text": "Potenzielle Kosten einschließlich nichtmonetärer Kosten aus erwarteten oder eingetretenen Fehlern sowie aus Funktionalität und Vertrauenswürdigkeit des Systems sind – bezogen auf die Risikotoleranz der Organisation – geprüft und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "6.1.1 verlangt KI-Risikokriterien zur Unterscheidung akzeptabler von nicht akzeptablen Risiken. Das ist der Bezugsrahmen für die von NIST geforderte Anbindung der Kosten an die Risikotoleranz."
   },
   {
    "ref": "MEASURE 1.1",
    "text": "Messansätze und Kennzahlen für die in MAP erfassten KI-Risiken werden ausgewählt und zuerst auf die wesentlichen Risiken angewendet. Risiken oder Merkmale der Vertrauenswürdigkeit, die nicht gemessen werden oder nicht messbar sind, werden dokumentiert.",
    "staerke": "mittel",
    "begruendung": "6.1.1 verlangt die Festlegung von AI-Risikokriterien, die akzeptable von nicht akzeptablen Risiken unterscheiden und Risikobewertungen stützen. Damit ist die Grundlage für eine Priorisierung gelegt, nicht aber die Auswahl konkreter Messansätze und Metriken."
   },
   {
    "ref": "MEASURE 2.6",
    "text": "Das KI-System wird regelmäßig auf die in MAP erfassten Sicherheitsrisiken geprüft; vor Bereitstellung ist nachzuweisen, dass das Restrisiko die Risikotoleranz nicht überschreitet und ein Ausfall sicher erfolgt, auch jenseits der Wissensgrenzen. Sicherheitskennzahlen betreffen Zuverlässigkeit, Robustheit, Echtzeitüberwachung und Reaktionszeiten bei Ausfällen.",
    "staerke": "mittel",
    "begruendung": "6.1.1 verlangt AI-Risikokriterien, die akzeptable von nicht akzeptablen Risiken unterscheiden, also eine dokumentierte Risikotoleranz. Ein expliziter Abgleich des Restrisikos gegen diese Toleranz als Freigabebedingung wird jedoch nicht gefordert."
   },
   {
    "ref": "MANAGE 1.2",
    "text": "Die Behandlung dokumentierter KI-Risiken wird nach Auswirkung, Eintrittswahrscheinlichkeit sowie verfügbaren Ressourcen und Methoden priorisiert.",
    "staerke": "mittel",
    "begruendung": "6.1.1 verlangt etablierte KI-Risikokriterien, die akzeptable von nicht akzeptablen Risiken unterscheiden und Risikobewertung, -behandlung und Wirkungsbeurteilung stützen. Diese Kriterien sind die Grundlage jeder Priorisierung, legen aber selbst keine Rangfolge fest."
   },
   {
    "ref": "MANAGE 1.3",
    "text": "Für die in MAP als hoch priorisiert erkannten KI-Risiken werden Maßnahmen entwickelt, geplant und dokumentiert; als Optionen kommen Minderung, Übertragung, Vermeidung oder Akzeptanz in Betracht.",
    "staerke": "mittel",
    "begruendung": "6.1.1 verlangt die Planung von Maßnahmen zur Adressierung von Risiken, deren Integration in AIMS-Prozesse und die Bewertung ihrer Wirksamkeit sowie dokumentierte Information hierzu. Bleibt auf Managementsystemebene und benennt keine Antwortoptionen."
   }
  ],
  "6.1.2": [
   {
    "ref": "GOVERN 1.3",
    "text": "Prozesse und Verfahren legen fest, welcher Umfang an Risikomanagement-Aktivitäten erforderlich ist; Maßstab ist die Risikotoleranz der Organisation.",
    "staerke": "stark",
    "begruendung": "6.1.2 fordert einen Risikobewertungsprozess, der Risikoniveaus bestimmt, die Analyseergebnisse mit den Risikokriterien aus 6.1.1 vergleicht und die Risiken für die Behandlung priorisiert. Das ist der normative Mechanismus zur Ableitung des Aktivitätsniveaus aus der Risikotoleranz."
   },
   {
    "ref": "GOVERN 1.4",
    "text": "Der Risikomanagementprozess und seine Ergebnisse sind über transparente Richtlinien, Verfahren und weitere Maßnahmen festgelegt, ausgerichtet an den Risikoprioritäten der Organisation.",
    "staerke": "stark",
    "begruendung": "6.1.2 verlangt einen definierten, so ausgestalteten Risikobewertungsprozess, dass wiederholte Bewertungen consistent, valid and comparable results liefern, und das Aufbewahren dokumentierter Information darüber. Das entspricht dem etablierten, nachvollziehbaren Prozess."
   },
   {
    "ref": "MAP 3.2",
    "text": "Potenzielle Kosten einschließlich nichtmonetärer Kosten aus erwarteten oder eingetretenen Fehlern sowie aus Funktionalität und Vertrauenswürdigkeit des Systems sind – bezogen auf die Risikotoleranz der Organisation – geprüft und dokumentiert.",
    "staerke": "stark",
    "begruendung": "6.1.2 verlangt, „the potential consequences to the organization, individuals and societies that would result if the identified risks were to materialize“ zu bewerten, Risikostufen zu bestimmen und die Ergebnisse mit den Risikokriterien zu vergleichen. Damit ist die von NIST geforderte Verknüpfung von Schadensfolgen mit der Risikotoleranz normativ abgebildet."
   },
   {
    "ref": "MAP 5.1",
    "text": "Eintrittswahrscheinlichkeit und Ausmaß jeder erkannten Auswirkung – sowohl nützlich als auch schädlich – sind identifiziert und dokumentiert, gestützt auf die vorgesehene Nutzung, Erfahrungen mit KI-Systemen in vergleichbaren Kontexten, öffentliche Vorfallmeldungen, Rückmeldungen von Beteiligten außerhalb des entwickelnden oder bereitstellenden Teams sowie weitere Daten.",
    "staerke": "stark",
    "begruendung": "6.1.2 verlangt, die potenziellen Konsequenzen bei Risikoeintritt zu bewerten, „the realistic likelihood of the identified risks“ zu beurteilen und Risikostufen zu bestimmen. Das entspricht exakt der NIST-Forderung nach Eintrittswahrscheinlichkeit und Ausmaß jeder identifizierten Auswirkung."
   },
   {
    "ref": "MANAGE 1.2",
    "text": "Die Behandlung dokumentierter KI-Risiken wird nach Auswirkung, Eintrittswahrscheinlichkeit sowie verfügbaren Ressourcen und Methoden priorisiert.",
    "staerke": "stark",
    "begruendung": "6.1.2 d)/e) verlangt die Analyse von Konsequenzen und realistischer Eintrittswahrscheinlichkeit, die Bestimmung von Risikoniveaus und ausdrücklich „prioritize the assessed risks for risk treatment“. Das ist inhaltlich deckungsgleich mit der NIST-Forderung nach Priorisierung anhand Impact und Likelihood."
   },
   {
    "ref": "MAP 1.5",
    "text": "Die Risikotoleranzen der Organisation sind bestimmt und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "6.1.2 verlangt, die Ergebnisse der Risikoanalyse mit den Risikokriterien nach 6.1.1 zu vergleichen und Risiken zu priorisieren, sowie Risikostufen zu bestimmen. Die Toleranz wird hier angewendet und operationalisiert, nicht erstmals festgelegt."
   },
   {
    "ref": "MEASURE 1.1",
    "text": "Messansätze und Kennzahlen für die in MAP erfassten KI-Risiken werden ausgewählt und zuerst auf die wesentlichen Risiken angewendet. Risiken oder Merkmale der Vertrauenswürdigkeit, die nicht gemessen werden oder nicht messbar sind, werden dokumentiert.",
    "staerke": "mittel",
    "begruendung": "6.1.2 e) 5) fordert ausdrücklich, die bewerteten Risiken für die Risikobehandlung zu priorisieren, was dem NIST-Gedanken \"starting with the most significant AI risks\" entspricht. Der Prozess zielt jedoch auf Risikobehandlung, nicht auf die Auswahl von Messverfahren."
   },
   {
    "ref": "MEASURE 2.8",
    "text": "Risiken in Bezug auf Transparenz und Rechenschaftspflicht – wie in MAP erfasst – werden geprüft und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "6.1.2 verlangt einen dokumentierten KI-Risikobewertungsprozess mit Identifikation, Analyse und Bewertung; Transparenz- und Accountability-Risiken sind darin einzuschließen, werden aber nicht eigens benannt."
   },
   {
    "ref": "MEASURE 2.10",
    "text": "Das Datenschutzrisiko des KI-Systems – wie in MAP erfasst – wird geprüft und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "6.1.2 verpflichtet zu einem wiederholbaren KI-Risikobewertungsprozess, unter den Datenschutzrisiken als Risikokategorie fallen, ohne dass die Norm sie eigens ausweist."
   },
   {
    "ref": "MEASURE 3.1",
    "text": "Vorgehensweisen, Personal und Dokumentation sind vorhanden, um bestehende, unerwartete und neu auftretende KI-Risiken regelmäßig zu erkennen und zu verfolgen, etwa anhand der vorgesehenen und der tatsächlichen Leistung im Einsatz.",
    "staerke": "mittel",
    "begruendung": "6.1.2 verlangt einen dokumentierten Prozess mit Risikokriterien, Identifikation, Analyse und Bewertung und liefert damit den von NIST geforderten methodischen Ansatz, ohne den Einsatzkontext eigens zu adressieren."
   },
   {
    "ref": "MEASURE 4.1",
    "text": "Messansätze zur Identifikation von KI-Risiken sind auf den jeweiligen Einsatzkontext bezogen und werden unter Einbeziehung von Fachexperten und Endnutzern abgestimmt; die Ansätze sind dokumentiert.",
    "staerke": "mittel",
    "begruendung": "6.1.2 verlangt einen dokumentierten Risikobewertungsprozess mit festgelegten Kriterien und liefert damit den dokumentierten Ansatz zur Risikoidentifikation, ohne den Einsatzkontext eigens zu verankern."
   },
   {
    "ref": "MANAGE 1.3",
    "text": "Für die in MAP als hoch priorisiert erkannten KI-Risiken werden Maßnahmen entwickelt, geplant und dokumentiert; als Optionen kommen Minderung, Übertragung, Vermeidung oder Akzeptanz in Betracht.",
    "staerke": "mittel",
    "begruendung": "6.1.2 e) 5) verlangt die Priorisierung der bewerteten Risiken für die Behandlung und stellt damit die von NIST vorausgesetzte Menge der hochprioren Risiken aus der Map-Funktion bereit. Selbst jedoch kein Behandlungsschritt."
   },
   {
    "ref": "MANAGE 2.3",
    "text": "Für zuvor unbekannte Risiken wird nach deren Erkennung ein festgelegtes Verfahren zur Reaktion und Wiederherstellung befolgt.",
    "staerke": "mittel",
    "begruendung": "6.1.2 fordert einen reproduzierbaren Risikobewertungsprozess, der Risiken identifiziert, analysiert und gegen die Risikokriterien bewertet. Liefert das Verfahren, mit dem ein neu aufgetauchtes Risiko eingeordnet wird."
   },
   {
    "ref": "MEASURE 3.2",
    "text": "Für Konstellationen, in denen KI-Risiken mit verfügbaren Messverfahren schwer zu bewerten sind oder noch keine Kennzahlen vorliegen, werden alternative Ansätze zur Risikoverfolgung erwogen.",
    "staerke": "schwach",
    "begruendung": "6.1.2 verlangt Risikokriterien sowie Analyse von Konsequenzen und Eintrittswahrscheinlichkeit, setzt dabei aber bewertbare Risiken voraus und regelt den Fall fehlender Messbarkeit nicht."
   }
  ],
  "6.1.3": [
   {
    "ref": "GOVERN 1.4",
    "text": "Der Risikomanagementprozess und seine Ergebnisse sind über transparente Richtlinien, Verfahren und weitere Maßnahmen festgelegt, ausgerichtet an den Risikoprioritäten der Organisation.",
    "staerke": "stark",
    "begruendung": "6.1.3 verlangt eine statement of applicability mit Begründung für Ein- und Ausschluss von Controls; die notwendigen Controls müssen dokumentiert, intern kommuniziert und interested parties as appropriate verfügbar sein. Das ist die Transparenzanforderung an Prozess und Controls."
   },
   {
    "ref": "GOVERN 2.3",
    "text": "Die oberste Leitung übernimmt die Verantwortung für Entscheidungen über Risiken bei Entwicklung und Bereitstellung von KI-Systemen.",
    "staerke": "stark",
    "begruendung": "6.1.3 verlangt ausdrücklich die Genehmigung des AI-Risikobehandlungsplans und die Akzeptanz der Restrisiken durch das designierte Management. Das ist die präziseste Entsprechung zur Verantwortungsübernahme für Risikoentscheidungen und fehlte in der Baseline."
   },
   {
    "ref": "MAP 4.2",
    "text": "Interne Risikosteuerungsmaßnahmen für die Komponenten des KI-Systems einschließlich der KI-Technologien Dritter sind identifiziert und dokumentiert.",
    "staerke": "stark",
    "begruendung": "6.1.3 verlangt, alle notwendigen Controls zu bestimmen, mit Annex A abzugleichen, zusätzliche Controls zu identifizieren und eine Statement of Applicability mit Begründung von Ein- und Ausschluss zu erstellen. Das ist die unmittelbare Entsprechung zu „internal risk controls ... are identified and documented“."
   },
   {
    "ref": "MANAGE 1.2",
    "text": "Die Behandlung dokumentierter KI-Risiken wird nach Auswirkung, Eintrittswahrscheinlichkeit sowie verfügbaren Ressourcen und Methoden priorisiert.",
    "staerke": "stark",
    "begruendung": "6.1.3 fordert, die Ergebnisse der Risikobewertung zu berücksichtigen, geeignete Behandlungsoptionen auszuwählen und einen Risikobehandlungsplan zu formulieren. Damit wird die priorisierte Behandlung dokumentierter Risiken normativ abgedeckt."
   },
   {
    "ref": "MANAGE 1.3",
    "text": "Für die in MAP als hoch priorisiert erkannten KI-Risiken werden Maßnahmen entwickelt, geplant und dokumentiert; als Optionen kommen Minderung, Übertragung, Vermeidung oder Akzeptanz in Betracht.",
    "staerke": "stark",
    "begruendung": "6.1.3 verlangt Auswahl der Behandlungsoptionen, Bestimmung notwendiger Controls im Abgleich mit Annex A, Statement of Applicability, Formulierung des Risikobehandlungsplans sowie dokumentierte Information darüber. Deckt Entwicklung, Planung und Dokumentation der Risikoantworten vollständig ab."
   },
   {
    "ref": "MANAGE 1.4",
    "text": "Negative Restrisiken – die Summe aller nicht geminderten Risiken – gegenüber nachgelagerten Abnehmern des KI-Systems und gegenüber Endnutzern sind dokumentiert.",
    "staerke": "stark",
    "begruendung": "6.1.3 verlangt ausdrücklich die Genehmigung des Risikobehandlungsplans und die Akzeptanz der Restrisiken durch das benannte Management sowie dokumentierte Information hierzu; die notwendigen Controls sind zudem „available to interested parties, as appropriate“. Das ist die Dokumentation negativer Restrisiken mit Akzeptanz durch den Risikoeigner."
   },
   {
    "ref": "GOVERN 1.3",
    "text": "Prozesse und Verfahren legen fest, welcher Umfang an Risikomanagement-Aktivitäten erforderlich ist; Maßstab ist die Risikotoleranz der Organisation.",
    "staerke": "mittel",
    "begruendung": "6.1.3 verlangt die Genehmigung des Risikobehandlungsplans und die Akzeptanz der Restrisiken durch das designierte Management. Damit wird Risikotoleranz entscheidungsfähig operationalisiert, das Skalieren der Aktivitäten selbst regelt die Klausel jedoch nicht."
   },
   {
    "ref": "MAP 1.5",
    "text": "Die Risikotoleranzen der Organisation sind bestimmt und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "6.1.3 verlangt die Genehmigung des Risikobehandlungsplans und die „acceptance of the residual AI risks“ durch das benannte Management. Die akzeptierten Restrisiken sind die praktisch wirksame und dokumentierte Ausprägung der Risikotoleranz."
   },
   {
    "ref": "MANAGE 2.3",
    "text": "Für zuvor unbekannte Risiken wird nach deren Erkennung ein festgelegtes Verfahren zur Reaktion und Wiederherstellung befolgt.",
    "staerke": "mittel",
    "begruendung": "6.1.3 definiert den Behandlungsprozess, der nach 8.3 auch auf neu identifizierte Risiken anzuwenden ist, einschließlich Managementgenehmigung und Restrisikoakzeptanz. Prozessgrundlage, aber ohne Vorfall- oder Wiederherstellungsbezug."
   }
  ],
  "6.1.4": [
   {
    "ref": "GOVERN 4.2",
    "text": "Die Teams dokumentieren Risiken und mögliche Auswirkungen der von ihnen konzipierten, entwickelten, bereitgestellten, bewerteten und genutzten KI-Technologie und kommunizieren diese Auswirkungen auch über das Team hinaus.",
    "staerke": "stark",
    "begruendung": "6.1.4 verlangt einen Prozess zur Bewertung der Folgen für Individuen, Gruppen und Gesellschaften unter Berücksichtigung von deployment, intended use und foreseeable misuse; das Ergebnis ist zu dokumentieren und kann relevanten interested parties zur Verfügung gestellt werden. Das deckt Dokumentation und Kommunikation der Auswirkungen ab."
   },
   {
    "ref": "MAP 1.1",
    "text": "Zweckbestimmung, nutzbringende Anwendungen, kontextspezifische Rechtsvorschriften und Erwartungen sowie die vorgesehene Einsatzumgebung des KI-Systems sind verstanden und dokumentiert. Zu berücksichtigen sind dabei Nutzergruppen, positive wie negative Auswirkungen, Annahmen und Grenzen, Risiken über den KI-Lebenszyklus sowie TEVV (Test, Evaluation, Verification, Validation) und Systemkennzahlen.",
    "staerke": "stark",
    "begruendung": "6.1.4 fordert die Bewertung der Folgen von „deployment, intended use and foreseeable misuse“ unter Berücksichtigung des „specific technical and societal context where the AI system is deployed and applicable jurisdictions“. Das deckt Einsatzumfeld, Rechtsrahmen und positive wie negative Auswirkungen ab; das Ergebnis ist zu dokumentieren."
   },
   {
    "ref": "MAP 3.1",
    "text": "Der potenzielle Nutzen der vorgesehenen Funktionalität und Leistung des KI-Systems ist geprüft und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "6.1.4 verlangt die Bestimmung der potenziellen Konsequenzen aus Bereitstellung und Nutzung; der Begriff „consequences“ ist richtungsoffen und schließt Nutzen ein. Der Fokus der Klausel liegt jedoch erkennbar auf negativen Folgen."
   },
   {
    "ref": "MAP 5.1",
    "text": "Eintrittswahrscheinlichkeit und Ausmaß jeder erkannten Auswirkung – sowohl nützlich als auch schädlich – sind identifiziert und dokumentiert, gestützt auf die vorgesehene Nutzung, Erfahrungen mit KI-Systemen in vergleichbaren Kontexten, öffentliche Vorfallmeldungen, Rückmeldungen von Beteiligten außerhalb des entwickelnden oder bereitstellenden Teams sowie weitere Daten.",
    "staerke": "mittel",
    "begruendung": "6.1.4 verlangt die Bestimmung der Folgen aus Deployment, beabsichtigter Nutzung und vorhersehbarem Missbrauch sowie die Dokumentation der Ergebnisse und deren Berücksichtigung in der Risikobewertung. Der Bezug auf „expected use“ ist damit abgedeckt."
   },
   {
    "ref": "MANAGE 1.2",
    "text": "Die Behandlung dokumentierter KI-Risiken wird nach Auswirkung, Eintrittswahrscheinlichkeit sowie verfügbaren Ressourcen und Methoden priorisiert.",
    "staerke": "mittel",
    "begruendung": "6.1.4 verlangt die Ermittlung potenzieller Konsequenzen für Individuen, Gruppen und Gesellschaften und schreibt vor, deren Ergebnis in der Risikobewertung nach 6.1.2 zu berücksichtigen. Liefert damit die Impact-Dimension der Priorisierung."
   },
   {
    "ref": "MEASURE 2.12",
    "text": "Umweltauswirkungen und Nachhaltigkeit von Training und Betrieb des KI-Modells – wie in MAP erfasst – werden bewertet und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "6.1.4 verpflichtet zur Folgenabschätzung für Individuen, Gruppen und Gesellschaften; Umweltwirkungen sind nur über die gesellschaftliche Dimension und ohne eigene Anforderung erfasst."
   },
   {
    "ref": "MANAGE 1.3",
    "text": "Für die in MAP als hoch priorisiert erkannten KI-Risiken werden Maßnahmen entwickelt, geplant und dokumentiert; als Optionen kommen Minderung, Übertragung, Vermeidung oder Akzeptanz in Betracht.",
    "staerke": "schwach",
    "begruendung": "6.1.4 liefert über die Impact-Assessment-Ergebnisse, die in der Risikobewertung zu berücksichtigen sind, nur einen Input für die Priorisierung. Zur Entwicklung und Planung der Risikoantworten selbst trifft die Klausel keine Aussage."
   }
  ],
  "6.2": [
   {
    "ref": "MAP 1.3",
    "text": "Auftrag und einschlägige Ziele der Organisation für die KI-Technologie sind verstanden und dokumentiert.",
    "staerke": "stark",
    "begruendung": "6.2 verlangt KI-Ziele auf relevanten Funktionen und Ebenen, die konsistent zur KI-Politik, messbar, überwacht, kommuniziert und als dokumentierte Information verfügbar sind. Das deckt „relevant goals for the AI technology ... documented“ vollständig ab."
   },
   {
    "ref": "MANAGE 4.2",
    "text": "Messbare Aktivitäten zur kontinuierlichen Verbesserung sind in die Aktualisierung der KI-Systeme eingebunden und umfassen den regelmäßigen Austausch mit interessierten Parteien einschließlich relevanter KI-Akteure.",
    "staerke": "mittel",
    "begruendung": "6.2 verlangt KI-Ziele, die messbar (soweit praktikabel), überwacht, kommuniziert und aktualisiert sind, samt Festlegung von Maßnahmen, Ressourcen, Verantwortlichkeiten, Terminen und Ergebnisbewertung. Liefert die Messbarkeit, ohne Systemupdates zu adressieren."
   },
   {
    "ref": "GOVERN 1.1",
    "text": "Rechtliche und regulatorische Anforderungen an KI sind verstanden, werden gesteuert und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "6.2 verlangt, dass AI-Ziele applicable requirements berücksichtigen; der Rechtsbezug ist damit nur mittelbar über die Zielplanung hergestellt. Eine eigenständige Verwaltung oder Dokumentation von Rechtspflichten leistet die Klausel nicht."
   }
  ],
  "6.3": [
   {
    "ref": "GOVERN 1.7",
    "text": "Prozesse und Verfahren regeln die sichere Außerbetriebnahme und Ablösung von KI-Systemen, ohne dabei Risiken zu erhöhen oder die Vertrauenswürdigkeit der Organisation zu mindern.",
    "staerke": "schwach",
    "begruendung": "6.3 verlangt, Änderungen am AI-Managementsystem geplant durchzuführen; die Außerbetriebnahme eines Systems im Geltungsbereich ist eine solche Änderung. Die Klausel adressiert jedoch das Managementsystem, nicht das AI-System selbst."
   },
   {
    "ref": "MANAGE 2.4",
    "text": "Mechanismen zum Übersteuern, Abschalten oder Deaktivieren von KI-Systemen mit bestimmungswidriger Leistung oder Wirkung bestehen und werden angewendet; die Verantwortlichkeiten dafür sind zugewiesen und bekannt.",
    "staerke": "schwach",
    "begruendung": "6.3 verlangt lediglich, dass erforderliche Änderungen am AIMS geplant durchgeführt werden; 8.1 ergänzt die Steuerung geplanter und die Überprüfung unbeabsichtigter Änderungen. Trifft die Außerbetriebnahme eines KI-Systems nur mittelbar."
   }
  ],
  "7.1": [
   {
    "ref": "GOVERN 1.6",
    "text": "Mechanismen zur Inventarisierung der KI-Systeme bestehen und sind entsprechend den Risikoprioritäten der Organisation mit Ressourcen ausgestattet.",
    "staerke": "mittel",
    "begruendung": "7.1 verlangt, die für Einrichtung, Umsetzung, Aufrechterhaltung und kontinuierliche Verbesserung des AIMS erforderlichen Ressourcen zu bestimmen und bereitzustellen. Das deckt das are resourced-Element ab, ohne Risikopriorisierung vorzugeben."
   },
   {
    "ref": "MANAGE 2.1",
    "text": "Die für die Behandlung von KI-Risiken erforderlichen Ressourcen werden berücksichtigt, ebenso tragfähige Alternativen ohne KI, um Ausmaß oder Eintrittswahrscheinlichkeit möglicher Auswirkungen zu verringern.",
    "staerke": "mittel",
    "begruendung": "7.1 verpflichtet zur Bestimmung und Bereitstellung der für Einrichtung, Umsetzung, Aufrechterhaltung und fortlaufende Verbesserung des AIMS erforderlichen Ressourcen. Erfasst damit auch Ressourcen für das Risikomanagement, stellt aber keinen Bezug zur Reduktion von Ausmaß oder Wahrscheinlichkeit her."
   },
   {
    "ref": "MANAGE 2.2",
    "text": "Mechanismen zur dauerhaften Werterhaltung bereitgestellter KI-Systeme bestehen und werden angewendet.",
    "staerke": "mittel",
    "begruendung": "7.1 verlangt die Bereitstellung der Ressourcen für Aufrechterhaltung und fortlaufende Verbesserung des AIMS; B.4.5 ergänzt, dass für die fortlaufende Verbesserung von KI-Systemen andere Ressourcen erforderlich sein können. Notwendige Voraussetzung, kein Mechanismus des Werterhalts."
   },
   {
    "ref": "MAP 1.2",
    "text": "Interdisziplinäre KI-Akteure mit vielfältigem demografischem Hintergrund sowie breiter Fach- und Anwendungserfahrung wirken an der Kontextbestimmung mit; ihre Beteiligung wird dokumentiert und interdisziplinäre Zusammenarbeit vorrangig ermöglicht.",
    "staerke": "schwach",
    "begruendung": "7.1 verpflichtet zur Bereitstellung der für das AIMS erforderlichen Ressourcen, worunter auch personelle Kapazitäten fallen. Die Klausel bleibt generisch und adressiert weder Interdisziplinarität noch Diversität."
   }
  ],
  "7.2": [
   {
    "ref": "GOVERN 2.2",
    "text": "Beschäftigte und Partner erhalten Schulungen zum KI-Risikomanagement, damit sie ihre Aufgaben im Einklang mit den einschlägigen Richtlinien, Verfahren und Vereinbarungen wahrnehmen können.",
    "staerke": "stark",
    "begruendung": "7.2 verlangt, die notwendige Kompetenz zu bestimmen, sie durch Ausbildung, Schulung oder Erfahrung sicherzustellen, Maßnahmen zum Kompetenzaufbau zu ergreifen und deren Wirksamkeit zu bewerten, mit dokumentiertem Nachweis. Das ist die direkte Entsprechung zur Trainingsforderung."
   },
   {
    "ref": "MAP 1.2",
    "text": "Interdisziplinäre KI-Akteure mit vielfältigem demografischem Hintergrund sowie breiter Fach- und Anwendungserfahrung wirken an der Kontextbestimmung mit; ihre Beteiligung wird dokumentiert und interdisziplinäre Zusammenarbeit vorrangig ermöglicht.",
    "staerke": "stark",
    "begruendung": "7.2 verlangt, die notwendige Kompetenz zu bestimmen, sicherzustellen und als dokumentierte Information nachzuweisen. Das deckt Kompetenzen, Fähigkeiten und deren Dokumentation nach MAP 1.2 ab."
   },
   {
    "ref": "MAP 3.4",
    "text": "Prozesse zur Fachkunde von Bedienern und Fachanwendern hinsichtlich Leistung und Vertrauenswürdigkeit des KI-Systems sowie einschlägige technische Normen und Zertifizierungen sind definiert, bewertet und dokumentiert.",
    "staerke": "stark",
    "begruendung": "7.2 verlangt, die notwendige Kompetenz der unter Kontrolle der Organisation tätigen Personen zu bestimmen, sie durch Ausbildung, Schulung oder Erfahrung sicherzustellen und die Wirksamkeit der Maßnahmen zu bewerten. Damit sind „defined, assessed and documented“ für Bedienpersonal und Praktiker abgedeckt."
   },
   {
    "ref": "GOVERN 2.1",
    "text": "Rollen, Verantwortlichkeiten und Kommunikationswege für das Erfassen, Messen und Behandeln von KI-Risiken sind dokumentiert und organisationsweit bekannt.",
    "staerke": "mittel",
    "begruendung": "7.2 verlangt die Bestimmung der notwendigen Kompetenz der Personen, deren Tätigkeit die AI-Leistung beeinflusst, samt dokumentiertem Kompetenznachweis. Damit werden Rollen kompetenzseitig konkretisiert; die Baseline-Angabe 7..2 war ein Tippfehler."
   },
   {
    "ref": "GOVERN 3.1",
    "text": "Entscheidungen zum Erfassen, Messen und Behandeln von KI-Risiken über den gesamten Lebenszyklus stützen sich auf ein vielfältig zusammengesetztes Team (Demografie, Fachdisziplinen, Erfahrung, Expertise, Hintergründe).",
    "staerke": "mittel",
    "begruendung": "7.2 verlangt die Bestimmung der notwendigen Kompetenz und Maßnahmen, um fehlende Kompetenz zu beschaffen. Das ist der klauselseitige Hebel für die Zusammenstellung des erforderlichen Expertisespektrums."
   },
   {
    "ref": "GOVERN 3.2",
    "text": "Richtlinien und Verfahren definieren und unterscheiden Rollen und Verantwortlichkeiten für das Zusammenwirken von Mensch und KI sowie für die Aufsicht über KI-Systeme.",
    "staerke": "mittel",
    "begruendung": "7.2 verlangt Kompetenznachweise für Personen, deren Tätigkeit die AI-Leistung beeinflusst; B.9.3 konkretisiert dies für das Oversight-Personal. Ohne Kompetenz bleibt eine definierte Aufsichtsrolle wirkungslos."
   }
  ],
  "7.3": [
   {
    "ref": "GOVERN 2.2",
    "text": "Beschäftigte und Partner erhalten Schulungen zum KI-Risikomanagement, damit sie ihre Aufgaben im Einklang mit den einschlägigen Richtlinien, Verfahren und Vereinbarungen wahrnehmen können.",
    "staerke": "stark",
    "begruendung": "7.3 verlangt Awareness über die AI policy, den eigenen Beitrag zur Wirksamkeit des AIMS und die Folgen von Nichtkonformität für alle „persons doing work under the organization's control“. Das sichert die Ausrichtung an related policies and procedures."
   },
   {
    "ref": "GOVERN 2.1",
    "text": "Rollen, Verantwortlichkeiten und Kommunikationswege für das Erfassen, Messen und Behandeln von KI-Risiken sind dokumentiert und organisationsweit bekannt.",
    "staerke": "mittel",
    "begruendung": "7.3 verlangt, dass Personen unter der Kontrolle der Organisation die AI policy, ihren Beitrag zur Wirksamkeit des AIMS und die Folgen von Nichtkonformität kennen. Das adressiert das clear to individuals and teams, nicht jedoch die Dokumentation der Rollen."
   },
   {
    "ref": "GOVERN 4.1",
    "text": "Richtlinien und Praktiken fördern kritisches Denken und einen Sicherheitsvorrang bei Konzeption, Entwicklung, Bereitstellung und Nutzung von KI-Systemen, um negative Auswirkungen zu minimieren.",
    "staerke": "mittel",
    "begruendung": "7.3 verlangt, dass Personen unter Kontrolle der Organisation die AI policy, ihren Beitrag zur Wirksamkeit des AIMS und die Folgen von Nichtkonformität kennen. Das ist der klauselseitige Anker für die geforderte Haltung, bleibt aber Awareness statt Kultur."
   },
   {
    "ref": "MAP 3.4",
    "text": "Prozesse zur Fachkunde von Bedienern und Fachanwendern hinsichtlich Leistung und Vertrauenswürdigkeit des KI-Systems sowie einschlägige technische Normen und Zertifizierungen sind definiert, bewertet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "7.3 verlangt Bewusstsein über die KI-Politik, den eigenen Beitrag zur Wirksamkeit des AIMS und die Folgen von Nichtkonformität. Das ergänzt die formale Kompetenz um die Verhaltensdimension."
   }
  ],
  "7.4": [
   {
    "ref": "GOVERN 2.1",
    "text": "Rollen, Verantwortlichkeiten und Kommunikationswege für das Erfassen, Messen und Behandeln von KI-Risiken sind dokumentiert und organisationsweit bekannt.",
    "staerke": "stark",
    "begruendung": "7.4 verlangt, die internen und externen Kommunikationen zum AIMS zu bestimmen, einschließlich what, when, with whom und how to communicate. Das ist die normative Entsprechung für die Kommunikationswege."
   },
   {
    "ref": "GOVERN 4.2",
    "text": "Die Teams dokumentieren Risiken und mögliche Auswirkungen der von ihnen konzipierten, entwickelten, bereitgestellten, bewerteten und genutzten KI-Technologie und kommunizieren diese Auswirkungen auch über das Team hinaus.",
    "staerke": "stark",
    "begruendung": "7.4 verlangt die Bestimmung der internen und externen Kommunikation zum AIMS einschließlich what, when, with whom und how. Das ist die normative Entsprechung zu communicate about the impacts more broadly."
   },
   {
    "ref": "GOVERN 5.1",
    "text": "Richtlinien und Praktiken stellen sicher, dass Rückmeldungen von Beteiligten außerhalb des entwickelnden oder bereitstellenden Teams zu möglichen individuellen und gesellschaftlichen Auswirkungen erhoben, bewertet, priorisiert und eingebunden werden.",
    "staerke": "mittel",
    "begruendung": "7.4 verlangt, die externen Kommunikationen zum AIMS zu bestimmen, einschließlich mit wem und wie kommuniziert wird. Das ist die formale Grundlage der Feedback-Kanäle."
   },
   {
    "ref": "MAP 5.2",
    "text": "Praktiken und Personal für den regelmäßigen Austausch mit relevanten KI-Akteuren sowie für die Einbindung von Rückmeldungen zu positiven, negativen und unerwarteten Auswirkungen bestehen und sind dokumentiert.",
    "staerke": "mittel",
    "begruendung": "7.4 verlangt die Festlegung interner und externer Kommunikation nach Inhalt, Zeitpunkt, Adressat und Methode. Das ist der normative Rahmen für regelmäßigen Austausch, ohne dessen Frequenz oder Format vorzugeben."
   },
   {
    "ref": "MANAGE 4.2",
    "text": "Messbare Aktivitäten zur kontinuierlichen Verbesserung sind in die Aktualisierung der KI-Systeme eingebunden und umfassen den regelmäßigen Austausch mit interessierten Parteien einschließlich relevanter KI-Akteure.",
    "staerke": "mittel",
    "begruendung": "7.4 verlangt die Festlegung der internen und externen Kommunikation mit Inhalt, Zeitpunkt, Adressaten und Methode. Bildet den formalen Rahmen für den Austausch mit interessierten Parteien und KI-Akteuren."
   }
  ],
  "7.5.1": [],
  "7.5.2": [],
  "7.5.3": [],
  "8.1": [
   {
    "ref": "MEASURE 1.2",
    "text": "Die Eignung der KI-Kennzahlen und die Wirksamkeit bestehender Maßnahmen werden regelmäßig bewertet und fortgeschrieben, einschließlich der Auswertung von Fehlermeldungen und von Auswirkungen auf betroffene Gruppen.",
    "staerke": "stark",
    "begruendung": "8.1 verlangt, die Wirksamkeit der nach 6.1.3 bestimmten Controls zu überwachen und Korrekturmaßnahmen zu erwägen, wenn die beabsichtigten Ergebnisse nicht erreicht werden. Das deckt die regelmäßige Wirksamkeitsprüfung bestehender Controls weitgehend ab."
   },
   {
    "ref": "MANAGE 3.1",
    "text": "KI-Risiken und -Nutzen aus Ressourcen Dritter werden regelmäßig überwacht; Risikosteuerungsmaßnahmen werden angewendet und dokumentiert.",
    "staerke": "stark",
    "begruendung": "8.1 verlangt ausdrücklich: „The organization shall ensure that externally provided processes, products or services that are relevant to the AI management system are controlled“, und fordert Wirksamkeitsüberwachung der Controls sowie Korrekturmaßnahmen bei Zielverfehlung. Normativer Anker für die Anwendung von Risikocontrols auf Drittressourcen."
   },
   {
    "ref": "GOVERN 1.7",
    "text": "Prozesse und Verfahren regeln die sichere Außerbetriebnahme und Ablösung von KI-Systemen, ohne dabei Risiken zu erhöhen oder die Vertrauenswürdigkeit der Organisation zu mindern.",
    "staerke": "mittel",
    "begruendung": "8.1 verlangt, geplante Änderungen zu steuern, die Folgen unbeabsichtigter Änderungen zu bewerten und nachteilige Auswirkungen zu mindern. Das ist die normative Basis dafür, dass ein Phase-out keine Risiken erhöht."
   },
   {
    "ref": "GOVERN 6.1",
    "text": "Richtlinien und Verfahren adressieren KI-Risiken im Zusammenhang mit Dritten, einschließlich der Verletzung von Rechten des geistigen Eigentums oder sonstiger Rechte Dritter.",
    "staerke": "mittel",
    "begruendung": "8.1 verlangt ausdrücklich, dass externally provided processes, products or services, die für das AIMS relevant sind, gesteuert werden. Die Klausel ist damit einschlägig, bleibt aber generisch und ohne AI-spezifische Drittparteianforderungen."
   },
   {
    "ref": "GOVERN 6.2",
    "text": "Notfallprozesse regeln den Umgang mit Ausfällen oder Vorfällen bei Daten oder KI-Systemen Dritter, die als hochriskant eingestuft sind.",
    "staerke": "mittel",
    "begruendung": "8.1 verlangt, die Wirksamkeit der Controls zu überwachen, bei Nichterreichen Korrekturmaßnahmen zu erwägen, die Folgen unbeabsichtigter Änderungen zu bewerten und extern bereitgestellte Prozesse, Produkte und Dienste zu steuern. Das ist der klauselseitige Anker für die Beherrschung von Drittparteistörungen."
   },
   {
    "ref": "MAP 4.2",
    "text": "Interne Risikosteuerungsmaßnahmen für die Komponenten des KI-Systems einschließlich der KI-Technologien Dritter sind identifiziert und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "8.1 verlangt die Umsetzung der nach 6.1.3 bestimmten Controls, die Überwachung ihrer Wirksamkeit und ausdrücklich, dass „externally provided processes, products or services that are relevant to the AI management system are controlled“. Das sichert die Anwendung der Kontrollen auf Drittkomponenten."
   },
   {
    "ref": "MEASURE 2.4",
    "text": "Funktionalität und Verhalten des KI-Systems und seiner Komponenten – wie in MAP bestimmt – werden im Produktivbetrieb überwacht.",
    "staerke": "mittel",
    "begruendung": "8.1 verlangt, die Wirksamkeit der operativen Controls zu überwachen und die Folgen unbeabsichtigter Änderungen zu überprüfen. Das stützt die laufende Betriebsüberwachung, bleibt aber auf Control-Ebene."
   },
   {
    "ref": "MANAGE 4.1",
    "text": "Pläne zur Überwachung des KI-Systems nach der Inbetriebnahme sind umgesetzt, einschließlich Erfassung und Auswertung von Rückmeldungen der Nutzer und weiterer relevanter KI-Akteure, Beschwerde- und Übersteuerungsmöglichkeiten, Außerbetriebnahme, Vorfallreaktion, Wiederherstellung und Änderungsmanagement.",
    "staerke": "mittel",
    "begruendung": "8.1 verlangt die Steuerung geplanter Änderungen und die Überprüfung der Folgen unbeabsichtigter Änderungen mit Maßnahmen zur Minderung nachteiliger Effekte. Entspricht dem von NIST geforderten Change Management im Betrieb."
   }
  ],
  "8.2": [
   {
    "ref": "GOVERN 1.5",
    "text": "Fortlaufende Überwachung und regelmäßige Überprüfung des Risikomanagementprozesses und seiner Ergebnisse sind geplant; Rollen, Verantwortlichkeiten und Prüfintervalle sind klar festgelegt.",
    "staerke": "stark",
    "begruendung": "8.2 verlangt AI-Risikobewertungen „at planned intervals or when significant changes are proposed or occur“. Damit ist die geplante Wiederholung einschließlich Frequenzfestlegung normiert."
   },
   {
    "ref": "MEASURE 2.6",
    "text": "Das KI-System wird regelmäßig auf die in MAP erfassten Sicherheitsrisiken geprüft; vor Bereitstellung ist nachzuweisen, dass das Restrisiko die Risikotoleranz nicht überschreitet und ein Ausfall sicher erfolgt, auch jenseits der Wissensgrenzen. Sicherheitskennzahlen betreffen Zuverlässigkeit, Robustheit, Echtzeitüberwachung und Reaktionszeiten bei Ausfällen.",
    "staerke": "stark",
    "begruendung": "8.2 verlangt AI-Risikobewertungen nach 6.1.2 in geplanten Abständen sowie bei geplanten oder eingetretenen wesentlichen Änderungen und die Aufbewahrung der Ergebnisse. Das deckt die geforderte regelmäßige Neubewertung der Safety-Risiken strukturell ab."
   },
   {
    "ref": "MEASURE 3.1",
    "text": "Vorgehensweisen, Personal und Dokumentation sind vorhanden, um bestehende, unerwartete und neu auftretende KI-Risiken regelmäßig zu erkennen und zu verfolgen, etwa anhand der vorgesehenen und der tatsächlichen Leistung im Einsatz.",
    "staerke": "stark",
    "begruendung": "8.2 verlangt die Durchführung der KI-Risikobewertung in geplanten Abständen sowie bei wesentlichen Änderungen und deckt damit die von NIST geforderte regelmäßige Identifikation und Verfolgung bestehender Risiken ab."
   },
   {
    "ref": "GOVERN 1.3",
    "text": "Prozesse und Verfahren legen fest, welcher Umfang an Risikomanagement-Aktivitäten erforderlich ist; Maßstab ist die Risikotoleranz der Organisation.",
    "staerke": "mittel",
    "begruendung": "8.2 verlangt Risikobewertungen „at planned intervals or when significant changes are proposed or occur“ und damit die Festlegung von Takt und Auslösern. Die Tiefe der Aktivitäten wird nicht geregelt."
   },
   {
    "ref": "GOVERN 1.4",
    "text": "Der Risikomanagementprozess und seine Ergebnisse sind über transparente Richtlinien, Verfahren und weitere Maßnahmen festgelegt, ausgerichtet an den Risikoprioritäten der Organisation.",
    "staerke": "mittel",
    "begruendung": "8.2 verlangt das Aufbewahren dokumentierter Information über die Ergebnisse aller Risikobewertungen. Damit sind die outcomes des Prozesses belegbar."
   },
   {
    "ref": "MEASURE 2.7",
    "text": "Security und Resilienz des KI-Systems – wie in MAP erfasst – werden bewertet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "8.2 verlangt AI-Risikobewertungen in geplanten Abständen und bei wesentlichen Änderungen mit dokumentierten Ergebnissen. Sicherheitsrisiken fallen darunter, werden aber nicht als eigener Bewertungsgegenstand ausgewiesen."
   },
   {
    "ref": "MANAGE 1.2",
    "text": "Die Behandlung dokumentierter KI-Risiken wird nach Auswirkung, Eintrittswahrscheinlichkeit sowie verfügbaren Ressourcen und Methoden priorisiert.",
    "staerke": "mittel",
    "begruendung": "8.2 verpflichtet zur Durchführung der Risikobewertungen nach 6.1.2 in geplanten Intervallen bzw. bei wesentlichen Änderungen und zur Aufbewahrung der Ergebnisse. Stellt sicher, dass die Priorisierung tatsächlich und wiederholt operativ erfolgt."
   },
   {
    "ref": "MANAGE 2.3",
    "text": "Für zuvor unbekannte Risiken wird nach deren Erkennung ein festgelegtes Verfahren zur Reaktion und Wiederherstellung befolgt.",
    "staerke": "mittel",
    "begruendung": "8.2 verlangt Risikobewertungen in geplanten Intervallen und bei wesentlichen vorgeschlagenen oder eingetretenen Änderungen. Das ist der Mechanismus, durch den bislang unbekannte Risiken überhaupt erkannt werden, jedoch keine Reaktions- oder Wiederherstellungsprozedur."
   },
   {
    "ref": "MANAGE 3.1",
    "text": "KI-Risiken und -Nutzen aus Ressourcen Dritter werden regelmäßig überwacht; Risikosteuerungsmaßnahmen werden angewendet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "8.2 verlangt Risikobewertungen in geplanten Intervallen und bei wesentlichen Änderungen mit Aufbewahrung der Ergebnisse. Liefert die Regelmäßigkeit der Risikobetrachtung, ohne Drittressourcen ausdrücklich zu benennen."
   },
   {
    "ref": "MAP 3.2",
    "text": "Potenzielle Kosten einschließlich nichtmonetärer Kosten aus erwarteten oder eingetretenen Fehlern sowie aus Funktionalität und Vertrauenswürdigkeit des Systems sind – bezogen auf die Risikotoleranz der Organisation – geprüft und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "8.2 verlangt die Durchführung von Risikobewertungen in geplanten Abständen oder bei wesentlichen Änderungen sowie die Aufbewahrung aller Ergebnisse. Das sichert die Aktualität, liefert aber keine eigene Kostenbetrachtung."
   },
   {
    "ref": "MEASURE 3.2",
    "text": "Für Konstellationen, in denen KI-Risiken mit verfügbaren Messverfahren schwer zu bewerten sind oder noch keine Kennzahlen vorliegen, werden alternative Ansätze zur Risikoverfolgung erwogen.",
    "staerke": "schwach",
    "begruendung": "8.2 sichert die wiederkehrende Durchführung der Risikobewertung; für schwer bewertbare Risiken stellt die Wiederholung allein kein Verfolgungsverfahren dar."
   }
  ],
  "8.3": [
   {
    "ref": "MANAGE 1.3",
    "text": "Für die in MAP als hoch priorisiert erkannten KI-Risiken werden Maßnahmen entwickelt, geplant und dokumentiert; als Optionen kommen Minderung, Übertragung, Vermeidung oder Akzeptanz in Betracht.",
    "staerke": "stark",
    "begruendung": "8.3 schreibt vor: „When risk assessments identify new risks that require treatment, a risk treatment process in accordance with 6.1.3 shall be performed for these risks“, und verlangt dokumentierte Ergebnisse aller Risikobehandlungen. Das ist die operative Entsprechung der NIST-Forderung."
   },
   {
    "ref": "MANAGE 2.3",
    "text": "Für zuvor unbekannte Risiken wird nach deren Erkennung ein festgelegtes Verfahren zur Reaktion und Wiederherstellung befolgt.",
    "staerke": "stark",
    "begruendung": "8.3 schreibt ausdrücklich vor, dass bei neu identifizierten behandlungsbeduerftigen Risiken ein Risikobehandlungsprozess nach 6.1.3 durchzuführen ist und unwirksame Behandlungsoptionen zu überprüfen und zu revalidieren sind. Das adressiert das zuvor unbekannte Risiko unmittelbar."
   },
   {
    "ref": "GOVERN 1.4",
    "text": "Der Risikomanagementprozess und seine Ergebnisse sind über transparente Richtlinien, Verfahren und weitere Maßnahmen festgelegt, ausgerichtet an den Risikoprioritäten der Organisation.",
    "staerke": "mittel",
    "begruendung": "8.3 verlangt die Umsetzung des Risikobehandlungsplans, die Verifikation seiner Wirksamkeit und das Aufbewahren dokumentierter Information über alle Behandlungsergebnisse. Das deckt die Ergebnisseite ab, nicht die Policy-Ebene."
   },
   {
    "ref": "GOVERN 1.5",
    "text": "Fortlaufende Überwachung und regelmäßige Überprüfung des Risikomanagementprozesses und seiner Ergebnisse sind geplant; Rollen, Verantwortlichkeiten und Prüfintervalle sind klar festgelegt.",
    "staerke": "mittel",
    "begruendung": "8.3 verlangt die Verifikation der Wirksamkeit der Risikobehandlung sowie Review und Revalidierung nicht wirksamer Behandlungsoptionen. Das ist die Ergebnis-Überwachung der Risikobehandlung."
   },
   {
    "ref": "MEASURE 1.2",
    "text": "Die Eignung der KI-Kennzahlen und die Wirksamkeit bestehender Maßnahmen werden regelmäßig bewertet und fortgeschrieben, einschließlich der Auswertung von Fehlermeldungen und von Auswirkungen auf betroffene Gruppen.",
    "staerke": "mittel",
    "begruendung": "8.3 fordert, die Umsetzung des Risikobehandlungsplans zu verifizieren und unwirksame Behandlungsoptionen zu überprüfen, zu revalidieren und den Plan zu aktualisieren. Der Aktualisierungszyklus ist damit normiert, allerdings für Risikobehandlungen und nicht für Metriken."
   },
   {
    "ref": "MEASURE 2.6",
    "text": "Das KI-System wird regelmäßig auf die in MAP erfassten Sicherheitsrisiken geprüft; vor Bereitstellung ist nachzuweisen, dass das Restrisiko die Risikotoleranz nicht überschreitet und ein Ausfall sicher erfolgt, auch jenseits der Wissensgrenzen. Sicherheitskennzahlen betreffen Zuverlässigkeit, Robustheit, Echtzeitüberwachung und Reaktionszeiten bei Ausfällen.",
    "staerke": "mittel",
    "begruendung": "8.3 verlangt die Umsetzung des Risikobehandlungsplans, die Verifikation seiner Wirksamkeit und die Revalidierung unwirksamer Behandlungsoptionen. Das adressiert den Umgang mit verbleibenden Risiken, ohne den Begriff des Restrisikos gegen eine Toleranzschwelle zu operationalisieren."
   },
   {
    "ref": "MANAGE 1.2",
    "text": "Die Behandlung dokumentierter KI-Risiken wird nach Auswirkung, Eintrittswahrscheinlichkeit sowie verfügbaren Ressourcen und Methoden priorisiert.",
    "staerke": "mittel",
    "begruendung": "8.3 verlangt die Umsetzung des Risikobehandlungsplans und die Verifizierung seiner Wirksamkeit sowie die Revalidierung unwirksamer Behandlungsoptionen. Betrifft die Umsetzung der priorisierten Behandlung, nicht die Priorisierung selbst."
   }
  ],
  "8.4": [
   {
    "ref": "GOVERN 1.5",
    "text": "Fortlaufende Überwachung und regelmäßige Überprüfung des Risikomanagementprozesses und seiner Ergebnisse sind geplant; Rollen, Verantwortlichkeiten und Prüfintervalle sind klar festgelegt.",
    "staerke": "mittel",
    "begruendung": "8.4 verlangt AI system impact assessments in geplanten Abständen bzw. bei erheblichen Änderungen und das Aufbewahren der Ergebnisse. Ergänzt die periodische Review um die Wirkungsdimension."
   },
   {
    "ref": "GOVERN 4.2",
    "text": "Die Teams dokumentieren Risiken und mögliche Auswirkungen der von ihnen konzipierten, entwickelten, bereitgestellten, bewerteten und genutzten KI-Technologie und kommunizieren diese Auswirkungen auch über das Team hinaus.",
    "staerke": "mittel",
    "begruendung": "8.4 verlangt, Impact Assessments in geplanten Abständen bzw. bei erheblichen Änderungen durchzuführen und die Ergebnisse dokumentiert aufzubewahren. Das macht die Dokumentation zur laufenden Pflicht der umsetzenden Teams."
   },
   {
    "ref": "MEASURE 3.1",
    "text": "Vorgehensweisen, Personal und Dokumentation sind vorhanden, um bestehende, unerwartete und neu auftretende KI-Risiken regelmäßig zu erkennen und zu verfolgen, etwa anhand der vorgesehenen und der tatsächlichen Leistung im Einsatz.",
    "staerke": "schwach",
    "begruendung": "8.4 verlangt die Folgenabschätzung in geplanten Abständen und bei Änderungen; sie erfasst Auswirkungen auf Betroffene, nicht die laufende Verfolgung technischer Leistungsrisiken."
   }
  ],
  "9.1": [
   {
    "ref": "GOVERN 1.5",
    "text": "Fortlaufende Überwachung und regelmäßige Überprüfung des Risikomanagementprozesses und seiner Ergebnisse sind geplant; Rollen, Verantwortlichkeiten und Prüfintervalle sind klar festgelegt.",
    "staerke": "stark",
    "begruendung": "9.1 verlangt festzulegen, was überwacht und gemessen wird, mit welchen Methoden, wann gemessen und wann die Ergebnisse analysiert und bewertet werden, und die Leistung sowie Wirksamkeit des AIMS zu bewerten. Das ist die zentrale Entsprechung für ongoing monitoring und Frequenzbestimmung."
   },
   {
    "ref": "MEASURE 4.1",
    "text": "Messansätze zur Identifikation von KI-Risiken sind auf den jeweiligen Einsatzkontext bezogen und werden unter Einbeziehung von Fachexperten und Endnutzern abgestimmt; die Ansätze sind dokumentiert.",
    "staerke": "stark",
    "begruendung": "9.1 verlangt festzulegen, was überwacht und gemessen wird, mit welchen Methoden, zu welchem Zeitpunkt und wann ausgewertet wird, und dies durch dokumentierte Information zu belegen."
   },
   {
    "ref": "MEASURE 4.2",
    "text": "Messergebnisse zur Vertrauenswürdigkeit im Einsatzkontext und über den KI-Lebenszyklus werden unter Mitwirkung von Fachexperten und weiteren relevanten KI-Akteuren daraufhin beurteilt, ob das System bestimmungsgemäß und gleichbleibend arbeitet; die Ergebnisse sind dokumentiert.",
    "staerke": "stark",
    "begruendung": "9.1 verlangt die Analyse und Bewertung der Überwachungs- und Messergebnisse sowie dokumentierte Information als Nachweis der Ergebnisse und deckt damit die Dokumentationspflicht der Subkategorie ab."
   },
   {
    "ref": "MEASURE 1.1",
    "text": "Messansätze und Kennzahlen für die in MAP erfassten KI-Risiken werden ausgewählt und zuerst auf die wesentlichen Risiken angewendet. Risiken oder Merkmale der Vertrauenswürdigkeit, die nicht gemessen werden oder nicht messbar sind, werden dokumentiert.",
    "staerke": "mittel",
    "begruendung": "9.1 verlangt festzulegen, was überwacht und gemessen wird sowie welche Methoden valide Ergebnisse sicherstellen. Der Bezugspunkt ist jedoch die Leistung des AIMS, nicht die Messbarkeit einzelner AI-Risiken oder Trustworthiness-Merkmale."
   },
   {
    "ref": "MEASURE 1.2",
    "text": "Die Eignung der KI-Kennzahlen und die Wirksamkeit bestehender Maßnahmen werden regelmäßig bewertet und fortgeschrieben, einschließlich der Auswertung von Fehlermeldungen und von Auswirkungen auf betroffene Gruppen.",
    "staerke": "mittel",
    "begruendung": "9.1 verlangt festzulegen, wann Ergebnisse aus Überwachung und Messung analysiert und bewertet werden, und die Wirksamkeit des AIMS zu bewerten. Die Angemessenheit der eingesetzten Metriken selbst wird jedoch nicht zum Prüfgegenstand gemacht."
   },
   {
    "ref": "MEASURE 2.4",
    "text": "Funktionalität und Verhalten des KI-Systems und seiner Komponenten – wie in MAP bestimmt – werden im Produktivbetrieb überwacht.",
    "staerke": "mittel",
    "begruendung": "9.1 verlangt festzulegen, was überwacht und gemessen wird, mit welchen Methoden und zu welchen Zeitpunkten Ergebnisse analysiert und bewertet werden. Die Klausel liefert den Rahmen, adressiert aber das AIMS und nicht einzelne Systemkomponenten."
   },
   {
    "ref": "MEASURE 2.13",
    "text": "Die Wirksamkeit der in der Funktion MEASURE eingesetzten TEVV-Kennzahlen und -Prozesse wird bewertet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "9.1 verlangt, die Methoden für Überwachung, Messung, Analyse und Bewertung so festzulegen, dass valide Ergebnisse sichergestellt sind, und dies durch dokumentierte Information zu belegen."
   },
   {
    "ref": "MEASURE 4.3",
    "text": "Messbare Verbesserungen oder Verschlechterungen der Leistung werden anhand von Rückmeldungen relevanter KI-Akteure einschließlich betroffener Gruppen sowie anhand von Felddaten zu kontextrelevanten Risiken und Merkmalen der Vertrauenswürdigkeit ermittelt und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "9.1 verlangt festzulegen, wann Messergebnisse analysiert und bewertet werden, und diese Ergebnisse dokumentiert nachzuweisen; damit sind Verbesserungen und Verschlechterungen belegbar."
   },
   {
    "ref": "MANAGE 2.2",
    "text": "Mechanismen zur dauerhaften Werterhaltung bereitgestellter KI-Systeme bestehen und werden angewendet.",
    "staerke": "mittel",
    "begruendung": "9.1 verlangt die Festlegung, was zu überwachen und zu messen ist, mit welchen Methoden und wann, sowie die Bewertung von Leistung und Wirksamkeit des AIMS mit dokumentierten Nachweisen. Bezieht sich auf das Managementsystem, nicht unmittelbar auf den Nutzen des Einzelsystems."
   },
   {
    "ref": "MANAGE 4.1",
    "text": "Pläne zur Überwachung des KI-Systems nach der Inbetriebnahme sind umgesetzt, einschließlich Erfassung und Auswertung von Rückmeldungen der Nutzer und weiterer relevanter KI-Akteure, Beschwerde- und Übersteuerungsmöglichkeiten, Außerbetriebnahme, Vorfallreaktion, Wiederherstellung und Änderungsmanagement.",
    "staerke": "mittel",
    "begruendung": "9.1 verlangt die Festlegung von Überwachungs- und Messgegenständen, Methoden und Zeitpunkten sowie dokumentierte Nachweise der Ergebnisse. Gibt dem Monitoring-Plan die normative Struktur, bezieht sich aber auf das AIMS."
   },
   {
    "ref": "MANAGE 4.2",
    "text": "Messbare Aktivitäten zur kontinuierlichen Verbesserung sind in die Aktualisierung der KI-Systeme eingebunden und umfassen den regelmäßigen Austausch mit interessierten Parteien einschließlich relevanter KI-Akteure.",
    "staerke": "mittel",
    "begruendung": "9.1 verlangt die Festlegung, was gemessen wird und mit welchen Methoden, um valide Ergebnisse sicherzustellen, sowie die Bewertung von Leistung und Wirksamkeit. Stellt die Messgrundlage der Verbesserungsaktivitäten."
   },
   {
    "ref": "MAP 3.5",
    "text": "Prozesse für Human Oversight (menschliche Aufsicht) sind entsprechend den Richtlinien aus der Funktion GOVERN definiert, bewertet und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "9.1 verlangt, festzulegen, was zu überwachen und zu messen ist, und die Wirksamkeit des AIMS zu bewerten. Eine Bewertung speziell der Aufsichtsprozesse ist damit möglich, aber nicht ausdrücklich gefordert."
   },
   {
    "ref": "MEASURE 2.3",
    "text": "Leistungs- bzw. Zusicherungskriterien des KI-Systems werden qualitativ oder quantitativ gemessen und unter einsatznahen Bedingungen nachgewiesen; die Messungen sind dokumentiert.",
    "staerke": "schwach",
    "begruendung": "9.1 verlangt festzulegen, was mit welchen Methoden gemessen wird, um valide Ergebnisse sicherzustellen, und die Ergebnisse als dokumentierte Information vorzuhalten. Der Bezugspunkt ist die AIMS-Leistung, nicht die Systemleistung unter Einsatzbedingungen."
   },
   {
    "ref": "MEASURE 3.3",
    "text": "Rückmeldeverfahren, über die Endnutzer und betroffene Gruppen Probleme melden und Systemergebnisse beanstanden können, sind eingerichtet und in die Bewertungskennzahlen des KI-Systems eingebunden.",
    "staerke": "schwach",
    "begruendung": "9.1 verlangt festzulegen, was zu überwachen und zu messen ist, verpflichtet aber nicht dazu, Rückmeldungen von Nutzern und Betroffenen in die Evaluationsgrößen zu überführen."
   }
  ],
  "9.2.1": [
   {
    "ref": "MEASURE 4.2",
    "text": "Messergebnisse zur Vertrauenswürdigkeit im Einsatzkontext und über den KI-Lebenszyklus werden unter Mitwirkung von Fachexperten und weiteren relevanten KI-Akteuren daraufhin beurteilt, ob das System bestimmungsgemäß und gleichbleibend arbeitet; die Ergebnisse sind dokumentiert.",
    "staerke": "mittel",
    "begruendung": "9.2.1 verlangt interne Audits in geplanten Abständen zur Frage, ob das KI-Managementsystem konform und wirksam umgesetzt ist, und liefert so eine unabhängige Validierungsschleife."
   },
   {
    "ref": "MEASURE 1.3",
    "text": "An den regelmäßigen Bewertungen und Aktualisierungen wirken interne Fachleute außerhalb des Entwicklungsteams und/oder unabhängige Prüfer mit. Entsprechend der Risikotoleranz werden zusätzlich Fachexperten, Nutzer, teamexterne KI-Akteure und betroffene Gruppen hinzugezogen.",
    "staerke": "schwach",
    "begruendung": "9.2.1 fordert interne Audits in geplanten Abständen zur Konformität und wirksamen Umsetzung des AIMS. Eine regelmäßige unabhängige Neubewertung des AI-Systems selbst wird damit nicht verlangt."
   },
   {
    "ref": "MEASURE 2.13",
    "text": "Die Wirksamkeit der in der Funktion MEASURE eingesetzten TEVV-Kennzahlen und -Prozesse wird bewertet und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "9.2.1 prüft, ob das KI-Managementsystem die eigenen und die Normanforderungen erfüllt und wirksam umgesetzt ist; die fachliche Güte einzelner Testmetriken ist nicht Auditgegenstand."
   }
  ],
  "9.2.2": [
   {
    "ref": "MEASURE 1.3",
    "text": "An den regelmäßigen Bewertungen und Aktualisierungen wirken interne Fachleute außerhalb des Entwicklungsteams und/oder unabhängige Prüfer mit. Entsprechend der Risikotoleranz werden zusätzlich Fachexperten, Nutzer, teamexterne KI-Akteure und betroffene Gruppen hinzugezogen.",
    "staerke": "mittel",
    "begruendung": "9.2.2 b) verlangt, Auditoren so auszuwählen und Audits so durchzuführen, dass Objektivität und Unparteilichkeit des Auditprozesses sichergestellt sind. Das Unabhängigkeitsprinzip passt, der Prüfgegenstand ist jedoch das AIMS und nicht die technische Bewertung des AI-Systems."
   }
  ],
  "9.3.1": [
   {
    "ref": "GOVERN 1.5",
    "text": "Fortlaufende Überwachung und regelmäßige Überprüfung des Risikomanagementprozesses und seiner Ergebnisse sind geplant; Rollen, Verantwortlichkeiten und Prüfintervalle sind klar festgelegt.",
    "staerke": "mittel",
    "begruendung": "9.3.1 verpflichtet das Top-Management zur Review des AIMS at planned intervals auf continuing suitability, adequacy and effectiveness. Das deckt die periodische Review des Managementsystems einschließlich seiner Risikoprozesse ab."
   },
   {
    "ref": "GOVERN 2.3",
    "text": "Die oberste Leitung übernimmt die Verantwortung für Entscheidungen über Risiken bei Entwicklung und Bereitstellung von KI-Systemen.",
    "staerke": "mittel",
    "begruendung": "9.3.1 verlangt die Review des AIMS durch das Top-Management in geplanten Abständen auf fortdauernde Eignung, Angemessenheit und Wirksamkeit. Das institutionalisiert die Leitungsbefassung."
   }
  ],
  "9.3.2": [
   {
    "ref": "MEASURE 4.3",
    "text": "Messbare Verbesserungen oder Verschlechterungen der Leistung werden anhand von Rückmeldungen relevanter KI-Akteure einschließlich betroffener Gruppen sowie anhand von Felddaten zu kontextrelevanten Risiken und Merkmalen der Vertrauenswürdigkeit ermittelt und dokumentiert.",
    "staerke": "stark",
    "begruendung": "9.3.2 verlangt als Eingaben der Managementbewertung ausdrücklich Trends bei Überwachungs- und Messergebnissen, Nichtkonformitäten und Auditergebnissen sowie Änderungen der Erwartungen interessierter Parteien."
   },
   {
    "ref": "GOVERN 5.2",
    "text": "Mechanismen stellen sicher, dass geprüfte Rückmeldungen relevanter KI-Akteure regelmäßig in Systemdesign und Umsetzung einfließen.",
    "staerke": "mittel",
    "begruendung": "9.3.2 nennt als Eingangsgröße der Managementbewertung ausdrücklich „changes in needs and expectations of interested parties“; 9.3.3 verlangt daraus Entscheidungen zu erforderlichen Änderungen. Das ist der normierte Adjudikationsmechanismus auf Leitungsebene."
   },
   {
    "ref": "MAP 5.2",
    "text": "Praktiken und Personal für den regelmäßigen Austausch mit relevanten KI-Akteuren sowie für die Einbindung von Rückmeldungen zu positiven, negativen und unerwarteten Auswirkungen bestehen und sind dokumentiert.",
    "staerke": "schwach",
    "begruendung": "9.3.2 verlangt, „changes in needs and expectations of interested parties“ als Eingabe in die Managementbewertung aufzunehmen. Damit wird Feedback zumindest periodisch in Entscheidungen integriert."
   },
   {
    "ref": "MANAGE 4.3",
    "text": "Vorfälle und Fehler werden relevanten KI-Akteuren einschließlich betroffener Gruppen mitgeteilt. Prozesse zur Verfolgung von Vorfällen und Fehlern, zur Reaktion darauf und zur Wiederherstellung werden befolgt und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "9.3.2 d) 1) verlangt, Trends bei Nichtkonformitäten und Korrekturmaßnahmen als Input der Managementbewertung zu berücksichtigen. Nur aggregierte Nachbetrachtung, keine Vorfallkommunikation."
   }
  ],
  "9.3.3": [
   {
    "ref": "GOVERN 2.3",
    "text": "Die oberste Leitung übernimmt die Verantwortung für Entscheidungen über Risiken bei Entwicklung und Bereitstellung von KI-Systemen.",
    "staerke": "mittel",
    "begruendung": "9.3.3 verlangt, dass die Ergebnisse der Managementbewertung Entscheidungen zu Verbesserungsmöglichkeiten und erforderlichen Änderungen des AIMS umfassen und dokumentiert werden. Damit sind Leitungsentscheidungen nachweisbar."
   },
   {
    "ref": "MEASURE 4.3",
    "text": "Messbare Verbesserungen oder Verschlechterungen der Leistung werden anhand von Rückmeldungen relevanter KI-Akteure einschließlich betroffener Gruppen sowie anhand von Felddaten zu kontextrelevanten Risiken und Merkmalen der Vertrauenswürdigkeit ermittelt und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "9.3.3 verlangt, dass die Ergebnisse der Managementbewertung Entscheidungen zu Verbesserungsmöglichkeiten und Änderungsbedarf enthalten und dokumentiert vorliegen."
   },
   {
    "ref": "MANAGE 4.2",
    "text": "Messbare Aktivitäten zur kontinuierlichen Verbesserung sind in die Aktualisierung der KI-Systeme eingebunden und umfassen den regelmäßigen Austausch mit interessierten Parteien einschließlich relevanter KI-Akteure.",
    "staerke": "mittel",
    "begruendung": "9.3.3 verlangt, dass die Ergebnisse der Managementbewertung Entscheidungen zu Verbesserungsmöglichkeiten und erforderlichen AIMS-Änderungen umfassen, mit dokumentierten Nachweisen. Steuert Verbesserung auf Managementebene."
   }
  ],
  "10.1": [
   {
    "ref": "MANAGE 4.2",
    "text": "Messbare Aktivitäten zur kontinuierlichen Verbesserung sind in die Aktualisierung der KI-Systeme eingebunden und umfassen den regelmäßigen Austausch mit interessierten Parteien einschließlich relevanter KI-Akteure.",
    "staerke": "stark",
    "begruendung": "10.1 verpflichtet zur fortlaufenden Verbesserung von Eignung, Angemessenheit und Wirksamkeit des AIMS und ist damit die normative Basis der von NIST geforderten kontinuierlichen Verbesserungsaktivitäten."
   },
   {
    "ref": "GOVERN 5.2",
    "text": "Mechanismen stellen sicher, dass geprüfte Rückmeldungen relevanter KI-Akteure regelmäßig in Systemdesign und Umsetzung einfließen.",
    "staerke": "mittel",
    "begruendung": "10.1 verlangt die fortlaufende Verbesserung der Eignung, Angemessenheit und Wirksamkeit des AIMS. Das ist die klauselseitige Grundlage für die regelmäßige, nicht einmalige Einarbeitung von Feedback."
   },
   {
    "ref": "MEASURE 4.3",
    "text": "Messbare Verbesserungen oder Verschlechterungen der Leistung werden anhand von Rückmeldungen relevanter KI-Akteure einschließlich betroffener Gruppen sowie anhand von Felddaten zu kontextrelevanten Risiken und Merkmalen der Vertrauenswürdigkeit ermittelt und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "10.1 verpflichtet zur fortlaufenden Verbesserung von Eignung, Angemessenheit und Wirksamkeit und setzt damit die Identifikation von Leistungsveränderungen voraus."
   },
   {
    "ref": "MANAGE 2.2",
    "text": "Mechanismen zur dauerhaften Werterhaltung bereitgestellter KI-Systeme bestehen und werden angewendet.",
    "staerke": "mittel",
    "begruendung": "10.1 verpflichtet zur fortlaufenden Verbesserung von Eignung, Angemessenheit und Wirksamkeit des AIMS. Stützt den Werterhalt, adressiert aber die Managementsystem- und nicht die Systemebene."
   },
   {
    "ref": "MEASURE 2.13",
    "text": "Die Wirksamkeit der in der Funktion MEASURE eingesetzten TEVV-Kennzahlen und -Prozesse wird bewertet und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "10.1 verpflichtet zur fortlaufenden Verbesserung von Eignung, Angemessenheit und Wirksamkeit des Managementsystems und erfasst TEVV-Prozesse nur als unbenannten Teil davon."
   },
   {
    "ref": "MEASURE 3.1",
    "text": "Vorgehensweisen, Personal und Dokumentation sind vorhanden, um bestehende, unerwartete und neu auftretende KI-Risiken regelmäßig zu erkennen und zu verfolgen, etwa anhand der vorgesehenen und der tatsächlichen Leistung im Einsatz.",
    "staerke": "schwach",
    "begruendung": "10.1 fordert fortlaufende Verbesserung des Managementsystems und stützt die Weiterentwicklung der Risikoverfolgung nur allgemein, ohne Verfahren zu benennen."
   },
   {
    "ref": "MEASURE 3.2",
    "text": "Für Konstellationen, in denen KI-Risiken mit verfügbaren Messverfahren schwer zu bewerten sind oder noch keine Kennzahlen vorliegen, werden alternative Ansätze zur Risikoverfolgung erwogen.",
    "staerke": "schwach",
    "begruendung": "10.1 verpflichtet zur fortlaufenden Verbesserung und erlaubt so das Nachrüsten von Messverfahren, benennt aber kein Vorgehen für den Zeitraum ohne verfügbare Metriken."
   }
  ],
  "10.2": [
   {
    "ref": "MANAGE 2.3",
    "text": "Für zuvor unbekannte Risiken wird nach deren Erkennung ein festgelegtes Verfahren zur Reaktion und Wiederherstellung befolgt.",
    "staerke": "stark",
    "begruendung": "10.2 verlangt bei Auftreten einer Nichtkonformität die Reaktion, Korrektur, den Umgang mit den Konsequenzen, Ursachenanalyse, Prüfung auf ähnliche Fälle, Wirksamkeitsbewertung und ggf. Änderungen am AIMS sowie dokumentierte Nachweise. Das ist das Verfahren zur Reaktion auf ein neu erkanntes Problem."
   },
   {
    "ref": "MANAGE 4.3",
    "text": "Vorfälle und Fehler werden relevanten KI-Akteuren einschließlich betroffener Gruppen mitgeteilt. Prozesse zur Verfolgung von Vorfällen und Fehlern, zur Reaktion darauf und zur Wiederherstellung werden befolgt und dokumentiert.",
    "staerke": "stark",
    "begruendung": "10.2 verlangt Reaktion und Korrektur, Umgang mit den Konsequenzen, Ursachenermittlung, Prüfung auf ähnliche Fälle, Wirksamkeitsbewertung sowie dokumentierte Nachweise zu Art der Nichtkonformitäten und ergriffenen Maßnahmen. Deckt Verfolgung, Reaktion und Dokumentation von Vorfällen und Fehlern."
   },
   {
    "ref": "GOVERN 4.3",
    "text": "Organisatorische Praktiken ermöglichen das Testen von KI, die Erkennung von Vorfällen und den Informationsaustausch.",
    "staerke": "mittel",
    "begruendung": "10.2 verlangt bei Nichtkonformitäten Reaktion, Ursachenanalyse, Prüfung auf gleichartige Fälle, Wirksamkeitsprüfung der Korrekturmaßnahmen und dokumentierte Nachweise. Das ist die normative Verarbeitungskette für erkannte Vorfälle."
   },
   {
    "ref": "GOVERN 6.2",
    "text": "Notfallprozesse regeln den Umgang mit Ausfällen oder Vorfällen bei Daten oder KI-Systemen Dritter, die als hochriskant eingestuft sind.",
    "staerke": "mittel",
    "begruendung": "10.2 verlangt Reaktion auf Nichtkonformitäten, Ursachenbeseitigung, Prüfung auf gleichartige Fälle und dokumentierte Nachweise der Wirksamkeit. Das ist die formale Aufarbeitung eines Ausfalls, nicht die Notfallvorsorge."
   },
   {
    "ref": "MANAGE 4.1",
    "text": "Pläne zur Überwachung des KI-Systems nach der Inbetriebnahme sind umgesetzt, einschließlich Erfassung und Auswertung von Rückmeldungen der Nutzer und weiterer relevanter KI-Akteure, Beschwerde- und Übersteuerungsmöglichkeiten, Außerbetriebnahme, Vorfallreaktion, Wiederherstellung und Änderungsmanagement.",
    "staerke": "mittel",
    "begruendung": "10.2 verlangt Reaktion und Korrektur bei Nichtkonformitäten, Umgang mit den Konsequenzen, Ursachenbeseitigung und Wirksamkeitsbewertung mit dokumentierten Nachweisen. Deckt die Vorfallreaktion, nicht die Wiederherstellung."
   },
   {
    "ref": "MEASURE 1.2",
    "text": "Die Eignung der KI-Kennzahlen und die Wirksamkeit bestehender Maßnahmen werden regelmäßig bewertet und fortgeschrieben, einschließlich der Auswertung von Fehlermeldungen und von Auswirkungen auf betroffene Gruppen.",
    "staerke": "schwach",
    "begruendung": "10.2 verlangt, auf Nichtkonformitäten zu reagieren, ihre Ursachen zu bewerten und Korrekturmaßnahmen umzusetzen. Das greift erst bei festgestellten Abweichungen und ist kein Verfahren zur laufenden Fehlerberichterstattung aus betroffenen Gemeinschaften."
   },
   {
    "ref": "MEASURE 2.13",
    "text": "Die Wirksamkeit der in der Funktion MEASURE eingesetzten TEVV-Kennzahlen und -Prozesse wird bewertet und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "10.2 verlangt bei Nichtkonformitäten eine Ursachenanalyse und die Überprüfung der Wirksamkeit der Korrekturmaßnahme; das greift erst reaktiv und nicht bei der Bewertung der Metriken selbst."
   }
  ],
  "A.2.2": [
   {
    "ref": "GOVERN 1.2",
    "text": "Die Merkmale vertrauenswürdiger KI sind in die Richtlinien, Prozesse und Verfahren der Organisation integriert.",
    "staerke": "stark",
    "begruendung": "A.2.2 verlangt eine dokumentierte Policy für Entwicklung oder Nutzung von AI-Systemen; B.2.2 fordert darin „principles that guide all activities of the organization related to AI“. Damit ist die Verankerung von Trustworthiness-Prinzipien in der Leitlinie normativ gefordert."
   },
   {
    "ref": "GOVERN 4.1",
    "text": "Richtlinien und Praktiken fördern kritisches Denken und einen Sicherheitsvorrang bei Konzeption, Entwicklung, Bereitstellung und Nutzung von KI-Systemen, um negative Auswirkungen zu minimieren.",
    "staerke": "stark",
    "begruendung": "A.2.2 verlangt eine dokumentierte AI policy; B.2.2 fordert darin principles that guide all activities sowie eine Herleitung aus organizational values and culture und dem Risikoappetit. Das ist die Policy-Ebene, die GOVERN 4.1 fordert."
   },
   {
    "ref": "GOVERN 1.1",
    "text": "Rechtliche und regulatorische Anforderungen an KI sind verstanden, werden gesteuert und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "Die AI policy ist laut B.2.2 ausdrücklich durch legal requirements, including contracts zu informieren und muss Prozesse für Abweichungen und Ausnahmen enthalten. Damit werden Rechtsanforderungen dokumentiert verankert, aber nicht systematisch als Pflichtenregister geführt."
   },
   {
    "ref": "GOVERN 1.3",
    "text": "Prozesse und Verfahren legen fest, welcher Umfang an Risikomanagement-Aktivitäten erforderlich ist; Maßstab ist die Risikotoleranz der Organisation.",
    "staerke": "mittel",
    "begruendung": "Nach B.2.2 ist die AI policy durch „the amount of risk the organization is willing to pursue or retain“ und „the level of risk posed by the AI systems“ zu informieren. Damit ist die Risikotoleranz auf Policy-Ebene dokumentiert zu verankern."
   },
   {
    "ref": "GOVERN 1.4",
    "text": "Der Risikomanagementprozess und seine Ergebnisse sind über transparente Richtlinien, Verfahren und weitere Maßnahmen festgelegt, ausgerichtet an den Risikoprioritäten der Organisation.",
    "staerke": "mittel",
    "begruendung": "A.2.2 verlangt eine dokumentierte AI policy; B.2.2 fordert darin „processes for handling deviations and exceptions to policy“ und als mögliches Themenfeld AI system impact assessments. Damit wird der Risikomanagement-Ansatz auf Policy-Ebene transparent gemacht."
   },
   {
    "ref": "MAP 1.3",
    "text": "Auftrag und einschlägige Ziele der Organisation für die KI-Technologie sind verstanden und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.2.2 verlangt, dass die KI-Politik von Geschäftsstrategie sowie organisationalen Werten und Kultur informiert wird. Die Mission wird so in die dokumentierte KI-Politik überführt."
   },
   {
    "ref": "MAP 1.4",
    "text": "Der geschäftliche Nutzen bzw. der betriebliche Einsatzkontext ist klar definiert oder – bei der Bewertung bestehender KI-Systeme – erneut bewertet.",
    "staerke": "mittel",
    "begruendung": "Die Baseline führt „B.2.2 Customers“; inhaltlich ist A.2.2 AI policy gemeint, denn B.2.2 verlangt, dass die KI-Politik von der „business strategy“ informiert wird. Damit wird der geschäftliche Rahmen des KI-Einsatzes dokumentiert festgelegt."
   },
   {
    "ref": "MAP 1.5",
    "text": "Die Risikotoleranzen der Organisation sind bestimmt und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.2.2 verlangt, dass die KI-Politik von „the amount of risk the organization is willing to pursue or retain“ informiert wird. Damit wird die Risikobereitschaft in einem dokumentierten Leitungsdokument verankert."
   },
   {
    "ref": "MAP 3.5",
    "text": "Prozesse für Human Oversight (menschliche Aufsicht) sind entsprechend den Richtlinien aus der Funktion GOVERN definiert, bewertet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.2.2 verlangt eine dokumentierte Politik für Entwicklung oder Nutzung von KI-Systemen, die nach B.2.2 leitende Prinzipien und den Umgang mit Abweichungen enthält. Das liefert die von NIST geforderte Rückbindung an die Governance-Vorgaben."
   },
   {
    "ref": "MAP 4.1",
    "text": "Vorgehensweisen zur Erfassung technischer und rechtlicher Risiken der Systemkomponenten – einschließlich der Nutzung von Daten oder Software Dritter sowie möglicher Verletzungen von Rechten des geistigen Eigentums oder sonstiger Rechte Dritter – bestehen, werden angewendet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.2.2 verlangt, dass die KI-Politik von „legal requirements, including contracts“ und dem Risikoumfeld der Organisation informiert wird. Rechtsrisiken werden so auf Politikebene verankert."
   }
  ],
  "A.2.3": [
   {
    "ref": "GOVERN 1.2",
    "text": "Die Merkmale vertrauenswürdiger KI sind in die Richtlinien, Prozesse und Verfahren der Organisation integriert.",
    "staerke": "stark",
    "begruendung": "A.2.3 verlangt zu bestimmen, wo andere Policies von den AI-Zielen betroffen sind; B.2.3 nennt quality, security, safety und privacy und verlangt, bestehende Policies zu aktualisieren oder Regelungen in die AI policy aufzunehmen. Das ist genau die Integration in organizational policies."
   },
   {
    "ref": "MAP 4.1",
    "text": "Vorgehensweisen zur Erfassung technischer und rechtlicher Risiken der Systemkomponenten – einschließlich der Nutzung von Daten oder Software Dritter sowie möglicher Verletzungen von Rechten des geistigen Eigentums oder sonstiger Rechte Dritter – bestehen, werden angewendet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.2.3 verlangt zu bestimmen, welche anderen Richtlinien von den KI-Zielen betroffen sind; B.2.3 nennt Qualität, Sicherheit, Safety und Privatheit als Schnittmengen. Damit werden bestehende Rechts- und Compliance-Regelwerke mit dem KI-Einsatz verknüpft."
   },
   {
    "ref": "MEASURE 2.7",
    "text": "Security und Resilienz des KI-Systems – wie in MAP erfasst – werden bewertet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.2.3 verlangt zu bestimmen, welche anderen Organisationsrichtlinien betroffen sind, und nennt ausdrücklich den Schnittbereich zu Security und Safety; bestehende Richtlinien sind zu aktualisieren oder in die AI-Policy zu überführen. Die eigentliche Sicherheitsbewertung wird damit an das ISMS (ISO/IEC 27001) delegiert."
   },
   {
    "ref": "MEASURE 2.2",
    "text": "Bewertungen unter Beteiligung von Menschen erfüllen die einschlägigen Anforderungen einschließlich des Probandenschutzes und bilden die relevante Population repräsentativ ab.",
    "staerke": "schwach",
    "begruendung": "A.2.3 verlangt zu bestimmen, welche anderen Richtlinien der Organisation berührt werden, und nennt ausdrücklich Qualität, Sicherheit, Safety und Datenschutz. Forschungsethik oder Probandenschutz werden darunter nicht genannt, wären aber über diesen Mechanismus anzubinden."
   },
   {
    "ref": "MEASURE 2.10",
    "text": "Das Datenschutzrisiko des KI-Systems – wie in MAP erfasst – wird geprüft und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.2.3 verlangt die Abstimmung mit anderen Unternehmensrichtlinien und bindet damit bestehende Datenschutzvorgaben an das KI-Managementsystem an, ohne eigene Prüfpflichten zu begründen."
   }
  ],
  "A.2.4": [
   {
    "ref": "GOVERN 1.1",
    "text": "Rechtliche und regulatorische Anforderungen an KI sind verstanden, werden gesteuert und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.2.4 verlangt die Review der AI policy in geplanten Abständen; B.2.4 nennt als Anlass ausdrücklich Änderungen der legal conditions. Das deckt das managed-Element für sich ändernde Rechtslagen ab."
   }
  ],
  "A.3.2": [
   {
    "ref": "GOVERN 1.5",
    "text": "Fortlaufende Überwachung und regelmäßige Überprüfung des Risikomanagementprozesses und seiner Ergebnisse sind geplant; Rollen, Verantwortlichkeiten und Prüfintervalle sind klar festgelegt.",
    "staerke": "stark",
    "begruendung": "A.3.2 verlangt definierte und zugewiesene AI-Rollen und -Verantwortlichkeiten; B.3.2 nennt als Bereiche ausdrücklich risk management, AI system impact assessments und performance. Das schließt die im Baseline-Mapping fehlende Rollenkomponente."
   },
   {
    "ref": "GOVERN 2.1",
    "text": "Rollen, Verantwortlichkeiten und Kommunikationswege für das Erfassen, Messen und Behandeln von KI-Risiken sind dokumentiert und organisationsweit bekannt.",
    "staerke": "stark",
    "begruendung": "A.3.2 verlangt definierte und zugewiesene AI-Rollen; B.3.2 nennt als Bereiche risk management, AI system impact assessments, performance und human oversight und fordert, Verantwortlichkeiten „to the level appropriate for the individuals to perform their duties“ zu definieren. Das korrigiert die Fehlbezeichnung B.3.2 = Management review inputs der Baseline."
   },
   {
    "ref": "GOVERN 3.2",
    "text": "Richtlinien und Verfahren definieren und unterscheiden Rollen und Verantwortlichkeiten für das Zusammenwirken von Mensch und KI sowie für die Aufsicht über KI-Systeme.",
    "staerke": "stark",
    "begruendung": "A.3.2 verlangt definierte und zugewiesene AI-Rollen und -Verantwortlichkeiten; B.3.2 nennt human oversight ausdrücklich als Bereich, der definierte Rollen erfordert. Die Baseline-Angabe B.3.2 Management review inputs ist eine Fehlbezeichnung: inhaltlich passt A.3.2, nicht 9.3.2, da Management review inputs keinen Bezug zur Rollendifferenzierung für human-AI configurations hat."
   },
   {
    "ref": "GOVERN 3.1",
    "text": "Entscheidungen zum Erfassen, Messen und Behandeln von KI-Risiken über den gesamten Lebenszyklus stützen sich auf ein vielfältig zusammengesetztes Team (Demografie, Fachdisziplinen, Erfahrung, Expertise, Hintergründe).",
    "staerke": "mittel",
    "begruendung": "B.3.2 verlangt Rollen und Verantwortlichkeiten für risk management, impact assessments, security, safety, privacy, development, performance, human oversight und data quality management. Die Breite dieser Felder erzwingt faktisch eine fachlich gemischte Besetzung."
   },
   {
    "ref": "MAP 1.2",
    "text": "Interdisziplinäre KI-Akteure mit vielfältigem demografischem Hintergrund sowie breiter Fach- und Anwendungserfahrung wirken an der Kontextbestimmung mit; ihre Beteiligung wird dokumentiert und interdisziplinäre Zusammenarbeit vorrangig ermöglicht.",
    "staerke": "mittel",
    "begruendung": "A.3.2 verlangt die Definition und Zuweisung von KI-Rollen; B.3.2 listet Risikomanagement, Impact Assessment, Sicherheit, Safety, Privacy, Entwicklung und Human Oversight als abzudeckende Bereiche. Die interdisziplinäre Besetzung wird damit strukturell verlangt, aber nicht als Beteiligungsnachweis dokumentiert."
   },
   {
    "ref": "MAP 3.5",
    "text": "Prozesse für Human Oversight (menschliche Aufsicht) sind entsprechend den Richtlinien aus der Funktion GOVERN definiert, bewertet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.3.2 nennt „human oversight“ ausdrücklich als Bereich, für den Rollen und Verantwortlichkeiten definiert und zugewiesen werden müssen. Die organisatorische Verankerung der Aufsicht ist damit gefordert."
   },
   {
    "ref": "MANAGE 2.4",
    "text": "Mechanismen zum Übersteuern, Abschalten oder Deaktivieren von KI-Systemen mit bestimmungswidriger Leistung oder Wirkung bestehen und werden angewendet; die Verantwortlichkeiten dafür sind zugewiesen und bekannt.",
    "staerke": "mittel",
    "begruendung": "A.3.2 verlangt definierte und zugewiesene KI-Rollen und Verantwortlichkeiten; die Guidance nennt als abzudeckende Bereiche u. a. Safety, Performance und Human Oversight. Erfüllt die NIST-Forderung nach zugewiesenen und verstandenen Verantwortlichkeiten."
   }
  ],
  "A.3.3": [
   {
    "ref": "MAP 5.2",
    "text": "Praktiken und Personal für den regelmäßigen Austausch mit relevanten KI-Akteuren sowie für die Einbindung von Rückmeldungen zu positiven, negativen und unerwarteten Auswirkungen bestehen und sind dokumentiert.",
    "staerke": "stark",
    "begruendung": "B.3.3 verlangt einen Meldeprozess, der „staffed with qualified persons“ ist, Untersuchungs- und Lösungsbefugnisse festlegt, Eskalation an das Management sowie Antwortmechanismen in angemessener Frist vorsieht. Damit sind die von NIST geforderten Praktiken UND das zuständige Personal normativ verankert."
   },
   {
    "ref": "GOVERN 2.1",
    "text": "Rollen, Verantwortlichkeiten und Kommunikationswege für das Erfassen, Messen und Behandeln von KI-Risiken sind dokumentiert und organisationsweit bekannt.",
    "staerke": "mittel",
    "begruendung": "A.3.3 verlangt einen Prozess zur Meldung von Concerns; B.3.3 fordert Eskalationswege zum Management in angemessener Zeit sowie Bekanntheit und Verfügbarkeit für Beschäftigte und Beauftragte. Das deckt die lines of communication auf der Meldeseite ab."
   },
   {
    "ref": "GOVERN 4.1",
    "text": "Richtlinien und Praktiken fördern kritisches Denken und einen Sicherheitsvorrang bei Konzeption, Entwicklung, Bereitstellung und Nutzung von KI-Systemen, um negative Auswirkungen zu minimieren.",
    "staerke": "mittel",
    "begruendung": "A.3.3 verlangt einen Prozess zur Meldung von Concerns; B.3.3 fordert Anonymitäts- bzw. Vertraulichkeitsoptionen, qualifizierte Bearbeitung, Eskalation und effective protection from reprisals. Das ist die normative Grundlage einer Speak-up-Kultur."
   },
   {
    "ref": "GOVERN 5.1",
    "text": "Richtlinien und Praktiken stellen sicher, dass Rückmeldungen von Beteiligten außerhalb des entwickelnden oder bereitstellenden Teams zu möglichen individuellen und gesellschaftlichen Auswirkungen erhoben, bewertet, priorisiert und eingebunden werden.",
    "staerke": "mittel",
    "begruendung": "A.3.3 verlangt einen Prozess zur Meldung von Concerns zur Rolle der Organisation über den gesamten Lebenszyklus; B.3.3 verlangt Verfügbarkeit für Beschäftigte und Beauftragte sowie Antwortmechanismen innerhalb angemessener Fristen. Das deckt Feedback von Personen außerhalb des Entwicklungsteams ab."
   },
   {
    "ref": "MEASURE 3.3",
    "text": "Rückmeldeverfahren, über die Endnutzer und betroffene Gruppen Probleme melden und Systemergebnisse beanstanden können, sind eingerichtet und in die Bewertungskennzahlen des KI-Systems eingebunden.",
    "staerke": "mittel",
    "begruendung": "A.3.3 verlangt einen Prozess zur Meldung von Bedenken zur Rolle der Organisation beim KI-System über dessen Lebenszyklus, adressiert dabei aber vorrangig interne Meldewege."
   },
   {
    "ref": "MANAGE 2.3",
    "text": "Für zuvor unbekannte Risiken wird nach deren Erkennung ein festgelegtes Verfahren zur Reaktion und Wiederherstellung befolgt.",
    "staerke": "mittel",
    "begruendung": "A.3.3 verlangt einen Prozess zur Meldung von Bedenken über die Rolle der Organisation im KI-Lebenszyklus; die Guidance fordert zeitnahe Eskalation an das Management, Untersuchungs- und Lösungsbefugnisse sowie Reaktionsmechanismen innerhalb angemessener Fristen. Interner Kanal, über den unbekannte Risiken sichtbar werden."
   }
  ],
  "A.4.2": [
   {
    "ref": "MANAGE 2.1",
    "text": "Die für die Behandlung von KI-Risiken erforderlichen Ressourcen werden berücksichtigt, ebenso tragfähige Alternativen ohne KI, um Ausmaß oder Eintrittswahrscheinlichkeit möglicher Auswirkungen zu verringern.",
    "staerke": "stark",
    "begruendung": "A.4.2 verlangt Identifikation und Dokumentation der für die einzelnen Lebenszyklusphasen erforderlichen Ressourcen; die Guidance begründet dies ausdrücklich damit, dass Ressourcendokumentation „critical for understanding risks, as well as potential AI system impacts“ ist, und verlangt bei fehlender Verfügbarkeit eine Revision von Design- oder Deployment-Anforderungen."
   },
   {
    "ref": "GOVERN 1.6",
    "text": "Mechanismen zur Inventarisierung der KI-Systeme bestehen und sind entsprechend den Risikoprioritäten der Organisation mit Ressourcen ausgestattet.",
    "staerke": "mittel",
    "begruendung": "A.4.2 verlangt, relevante Ressourcen der einzelnen Lebenszyklusphasen zu identifizieren und zu dokumentieren; B.4.2 nennt AI system components und stellt den Bezug zu Risiken und Auswirkungen her. Ein organisationsweites Register aller KI-Systeme mit Risikoklassifizierung fordert die Norm jedoch nicht — die Dokumentation ist systembezogen, nicht bestandsführend."
   },
   {
    "ref": "MAP 2.1",
    "text": "Die konkrete Aufgabe des KI-Systems und die zu ihrer Umsetzung eingesetzten Methoden sind definiert (z. B. Klassifikatoren, generative Modelle, Empfehlungssysteme).",
    "staerke": "mittel",
    "begruendung": "A.4.2 verlangt die Identifikation und Dokumentation der für die jeweiligen Lebenszyklusphasen relevanten Ressourcen; B.4.2 zählt dazu ausdrücklich die AI-Systemkomponenten. Das liefert den strukturellen Rahmen der Methoden- und Komponentenerfassung."
   },
   {
    "ref": "MAP 4.2",
    "text": "Interne Risikosteuerungsmaßnahmen für die Komponenten des KI-Systems einschließlich der KI-Technologien Dritter sind identifiziert und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.4.2 verlangt die Identifikation und Dokumentation der relevanten Ressourcen je Lebenszyklusphase; B.4.2 hält fest, dass Ressourcen auch von Kunden oder Dritten stammen können. Das liefert das Komponenteninventar als Grundlage der Kontrollzuordnung."
   },
   {
    "ref": "MANAGE 3.1",
    "text": "KI-Risiken und -Nutzen aus Ressourcen Dritter werden regelmäßig überwacht; Risikosteuerungsmaßnahmen werden angewendet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.4.2 verlangt Identifikation und Dokumentation der relevanten Ressourcen je Lebenszyklusphase; die Guidance stellt ausdrücklich fest, dass Ressourcen von der Organisation selbst, von Kunden oder von Dritten bereitgestellt werden können. Schafft die Dokumentationsgrundlage für Drittressourcen."
   },
   {
    "ref": "GOVERN 6.1",
    "text": "Richtlinien und Verfahren adressieren KI-Risiken im Zusammenhang mit Dritten, einschließlich der Verletzung von Rechten des geistigen Eigentums oder sonstiger Rechte Dritter.",
    "staerke": "schwach",
    "begruendung": "B.4.2 stellt klar, dass Ressourcen durch die Organisation selbst, durch Kunden oder durch Dritte bereitgestellt werden können, und verlangt deren Dokumentation. Das macht Drittkomponenten sichtbar, regelt aber keine Risikobehandlung."
   },
   {
    "ref": "MEASURE 2.1",
    "text": "Testdatensätze, Kennzahlen und die eingesetzten Werkzeuge für TEVV (Test, Evaluation, Verification, Validation) sind dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.4.2 verlangt die Identifikation und Dokumentation der für die jeweiligen Lebenszyklusphasen benötigten Ressourcen als Grundlage für Risiko- und Folgenverständnis. Der Bezug zu TEVV ist nur allgemeiner Natur."
   },
   {
    "ref": "MEASURE 2.12",
    "text": "Umweltauswirkungen und Nachhaltigkeit von Training und Betrieb des KI-Modells – wie in MAP erfasst – werden bewertet und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.4.2 fordert die Identifikation und Dokumentation aller je Lebenszyklusphase benötigten Ressourcen; ein Bezug zu Umweltwirkung oder Verbrauchsbilanzierung fehlt."
   }
  ],
  "A.4.3": [
   {
    "ref": "GOVERN 1.6",
    "text": "Mechanismen zur Inventarisierung der KI-Systeme bestehen und sind entsprechend den Risikoprioritäten der Organisation mit Ressourcen ausgestattet.",
    "staerke": "mittel",
    "begruendung": "A.4.3 verlangt die Dokumentation der genutzten Datenressourcen; B.4.3 nennt u.a. provenance, Datenkategorien, intended use und Aufbewahrungsrichtlinien. Das inventarisiert die Datenseite des AI-Systems."
   },
   {
    "ref": "MAP 2.1",
    "text": "Die konkrete Aufgabe des KI-Systems und die zu ihrer Umsetzung eingesetzten Methoden sind definiert (z. B. Klassifikatoren, generative Modelle, Empfehlungssysteme).",
    "staerke": "schwach",
    "begruendung": "B.4.3 verlangt die Dokumentation der Datenressourcen einschließlich Datenkategorien (Training, Validierung, Test, Produktion) und des beabsichtigten Datengebrauchs. Das stützt die Aufgabendefinition nur mittelbar."
   },
   {
    "ref": "MEASURE 2.1",
    "text": "Testdatensätze, Kennzahlen und die eingesetzten Werkzeuge für TEVV (Test, Evaluation, Verification, Validation) sind dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.4.3 fordert die Dokumentation der Datenressourcen, die in irgendeiner Lebenszyklusphase verwendet werden, was auch Testdaten einschließt. Test-Sets werden jedoch nicht als eigene, versionierte Kategorie adressiert."
   }
  ],
  "A.4.4": [
   {
    "ref": "MAP 2.1",
    "text": "Die konkrete Aufgabe des KI-Systems und die zu ihrer Umsetzung eingesetzten Methoden sind definiert (z. B. Klassifikatoren, generative Modelle, Empfehlungssysteme).",
    "staerke": "stark",
    "begruendung": "B.4.4 verlangt die Dokumentation der Tooling-Ressourcen und nennt „algorithm types and machine learning models“, Optimierungs- und Evaluationsmethoden. Die eingesetzten Methoden werden damit vollständig erfasst."
   },
   {
    "ref": "MANAGE 3.2",
    "text": "Für die Entwicklung genutzte Pre-trained Models (vortrainierte Modelle) werden in die regelmäßige Überwachung und Wartung des KI-Systems einbezogen.",
    "staerke": "stark",
    "begruendung": "A.4.4 verlangt die Dokumentation der Tooling-Ressourcen des KI-Systems; die Guidance nennt ausdrücklich „algorithm types and machine learning models“, Evaluierungsmethoden und Werkzeuge zur Modellentwicklung. Damit sind auch vortrainierte Modelle als zu erfassende und zu bewertende Ressource abgedeckt."
   },
   {
    "ref": "GOVERN 1.6",
    "text": "Mechanismen zur Inventarisierung der KI-Systeme bestehen und sind entsprechend den Risikoprioritäten der Organisation mit Ressourcen ausgestattet.",
    "staerke": "mittel",
    "begruendung": "A.4.4 verlangt die Dokumentation der Tooling-Ressourcen, laut B.4.4 einschließlich Algorithmentypen, ML-Modellen und Software/Hardware für Design, Entwicklung und Deployment. Damit werden Modelle und Werkzeuge erfassbar."
   },
   {
    "ref": "MEASURE 2.1",
    "text": "Testdatensätze, Kennzahlen und die eingesetzten Werkzeuge für TEVV (Test, Evaluation, Verification, Validation) sind dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.4.4 verlangt die Dokumentation der Tooling-Ressourcen und führt dabei ausdrücklich Evaluationsmethoden sowie Werkzeuge für Entwicklung und Deployment auf. Damit sind die TEVV-Werkzeuge erfasst, nicht aber Test-Sets und Metrikdefinitionen."
   },
   {
    "ref": "MAP 4.2",
    "text": "Interne Risikosteuerungsmaßnahmen für die Komponenten des KI-Systems einschließlich der KI-Technologien Dritter sind identifiziert und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "B.4.4 verlangt die Dokumentation der Tooling-Ressourcen einschließlich Algorithmen, Modelle und eingesetzter Software. Das erfasst Drittkomponenten, sagt aber nichts über die zugehörigen Kontrollen aus."
   }
  ],
  "A.4.5": [
   {
    "ref": "GOVERN 1.6",
    "text": "Mechanismen zur Inventarisierung der KI-Systeme bestehen und sind entsprechend den Risikoprioritäten der Organisation mit Ressourcen ausgestattet.",
    "staerke": "mittel",
    "begruendung": "A.4.5 verlangt die Dokumentation der System- und Rechenressourcen, laut B.4.5 einschließlich Lokation (on-premises, cloud, edge) und Verarbeitungsressourcen. Das ergänzt das Inventar um die technische Betriebsumgebung."
   },
   {
    "ref": "MAP 2.1",
    "text": "Die konkrete Aufgabe des KI-Systems und die zu ihrer Umsetzung eingesetzten Methoden sind definiert (z. B. Klassifikatoren, generative Modelle, Empfehlungssysteme).",
    "staerke": "schwach",
    "begruendung": "B.4.5 verlangt die Dokumentation von System- und Rechenressourcen einschließlich Ressourcenbedarf und Betriebsort. Für die Definition der Aufgabe selbst ist dies nur begleitend relevant."
   },
   {
    "ref": "MEASURE 2.12",
    "text": "Umweltauswirkungen und Nachhaltigkeit von Training und Betrieb des KI-Modells – wie in MAP erfasst – werden bewertet und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.4.5 verlangt die Dokumentation der genutzten System- und Rechenressourcen und liefert damit allenfalls die Datenbasis für eine Energiebetrachtung, nicht deren Bewertung."
   }
  ],
  "A.4.6": [
   {
    "ref": "MAP 1.2",
    "text": "Interdisziplinäre KI-Akteure mit vielfältigem demografischem Hintergrund sowie breiter Fach- und Anwendungserfahrung wirken an der Kontextbestimmung mit; ihre Beteiligung wird dokumentiert und interdisziplinäre Zusammenarbeit vorrangig ermöglicht.",
    "staerke": "stark",
    "begruendung": "A.4.6 verlangt die Dokumentation der eingesetzten Humanressourcen und ihrer Kompetenzen über alle Lebenszyklusphasen. B.4.6 fordert ausdrücklich „the need for diverse expertise“ und nennt Data Scientists, Human-Oversight-Rollen, Trustworthiness-Experten und Domänenexperten."
   },
   {
    "ref": "MAP 3.4",
    "text": "Prozesse zur Fachkunde von Bedienern und Fachanwendern hinsichtlich Leistung und Vertrauenswürdigkeit des KI-Systems sowie einschlägige technische Normen und Zertifizierungen sind definiert, bewertet und dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.4.6 verlangt die Dokumentation der Humanressourcen und ihrer Kompetenzen für Entwicklung, Deployment, Betrieb, Änderungsmanagement, Wartung sowie Verifikation und Integration des KI-Systems. Das trifft die Betreiber- und Praktikerkompetenz unmittelbar."
   },
   {
    "ref": "GOVERN 1.7",
    "text": "Prozesse und Verfahren regeln die sichere Außerbetriebnahme und Ablösung von KI-Systemen, ohne dabei Risiken zu erhöhen oder die Vertrauenswürdigkeit der Organisation zu mindern.",
    "staerke": "mittel",
    "begruendung": "A.4.6 nennt als einzige Stelle in Annex A das decommissioning ausdrücklich: Human Resources und Kompetenzen sind auch für change management, maintenance, transfer and decommissioning zu dokumentieren. Gefordert ist damit die Ressourcenseite, nicht der Außerbetriebnahmeprozess selbst."
   },
   {
    "ref": "GOVERN 2.2",
    "text": "Beschäftigte und Partner erhalten Schulungen zum KI-Risikomanagement, damit sie ihre Aufgaben im Einklang mit den einschlägigen Richtlinien, Verfahren und Vereinbarungen wahrnehmen können.",
    "staerke": "mittel",
    "begruendung": "A.4.6 verlangt die Dokumentation der Human Resources und ihrer Kompetenzen über alle Lebenszyklusphasen; B.4.6 nennt Rollen für human oversight sowie Experten für safety, security und privacy. Das definiert den Kompetenzbedarf, nicht die Schulung selbst."
   },
   {
    "ref": "GOVERN 3.1",
    "text": "Entscheidungen zum Erfassen, Messen und Behandeln von KI-Risiken über den gesamten Lebenszyklus stützen sich auf ein vielfältig zusammengesetztes Team (Demografie, Fachdisziplinen, Erfahrung, Expertise, Hintergründe).",
    "staerke": "mittel",
    "begruendung": "B.4.6 verlangt, den Bedarf an diverse expertise zu berücksichtigen, und nennt Data Scientists, Rollen für human oversight, Experten für safety, security und privacy sowie Domänenexperten; die Einbeziehung specific demographic groups wird nur bezogen auf Trainingsdaten genannt. Fachliche Vielfalt ist damit abgedeckt, demografische Vielfalt des Entscheidungsgremiums jedoch nur als Annex-B-Guidance und nicht normativ."
   },
   {
    "ref": "GOVERN 3.2",
    "text": "Richtlinien und Verfahren definieren und unterscheiden Rollen und Verantwortlichkeiten für das Zusammenwirken von Mensch und KI sowie für die Aufsicht über KI-Systeme.",
    "staerke": "mittel",
    "begruendung": "A.4.6 verlangt die Dokumentation der Human Resources und Kompetenzen; B.4.6 nennt ausdrücklich „roles related to human oversight of AI systems“. Das ordnet die Aufsichtsrollen ressourcenseitig zu."
   },
   {
    "ref": "MEASURE 3.1",
    "text": "Vorgehensweisen, Personal und Dokumentation sind vorhanden, um bestehende, unerwartete und neu auftretende KI-Risiken regelmäßig zu erkennen und zu verfolgen, etwa anhand der vorgesehenen und der tatsächlichen Leistung im Einsatz.",
    "staerke": "mittel",
    "begruendung": "A.4.6 fordert die Dokumentation der eingesetzten Humanressourcen und ihrer Kompetenzen über alle Lebenszyklusphasen und deckt damit den Aspekt „personnel“ der Subkategorie ab."
   },
   {
    "ref": "MANAGE 2.1",
    "text": "Die für die Behandlung von KI-Risiken erforderlichen Ressourcen werden berücksichtigt, ebenso tragfähige Alternativen ohne KI, um Ausmaß oder Eintrittswahrscheinlichkeit möglicher Auswirkungen zu verringern.",
    "staerke": "mittel",
    "begruendung": "A.4.6 verlangt die Dokumentation der Personalressourcen und Kompetenzen für Entwicklung, Deployment, Betrieb, Change Management, Wartung, Transfer und Decommissioning; die Guidance nennt ausdrücklich Rollen für menschliche Aufsicht und Fachleute für Sicherheit, Safety und Privacy. Deckt die personelle Seite der Risikomanagement-Ressourcen."
   },
   {
    "ref": "MANAGE 2.4",
    "text": "Mechanismen zum Übersteuern, Abschalten oder Deaktivieren von KI-Systemen mit bestimmungswidriger Leistung oder Wirkung bestehen und werden angewendet; die Verantwortlichkeiten dafür sind zugewiesen und bekannt.",
    "staerke": "mittel",
    "begruendung": "A.4.6 verlangt die Dokumentation der Personalressourcen und Kompetenzen ausdrücklich auch für Change Management, Transfer und Decommissioning des KI-Systems. Einzige Stelle, an der die Außerbetriebnahme namentlich adressiert ist, allerdings nur ressourcenseitig."
   },
   {
    "ref": "GOVERN 1.6",
    "text": "Mechanismen zur Inventarisierung der KI-Systeme bestehen und sind entsprechend den Risikoprioritäten der Organisation mit Ressourcen ausgestattet.",
    "staerke": "schwach",
    "begruendung": "A.4.6 verlangt die Dokumentation der eingesetzten Human Resources und ihrer Kompetenzen über alle Lebenszyklusphasen. Für ein Inventar der AI-Systeme selbst ist das nur eine Randdimension, betrifft aber die Ressourcierung."
   }
  ],
  "A.5.2": [
   {
    "ref": "GOVERN 1.3",
    "text": "Prozesse und Verfahren legen fest, welcher Umfang an Risikomanagement-Aktivitäten erforderlich ist; Maßstab ist die Risikotoleranz der Organisation.",
    "staerke": "stark",
    "begruendung": "B.5.2 a) verlangt festzulegen, unter welchen Umständen eine AI system impact assessment durchzuführen ist, u.a. nach criticality of the intended purpose, complexity of AI technology und level of automation sowie sensitivity of data. Das ist eine unmittelbare Entsprechung zur risikobasierten Staffelung der Aktivitäten."
   },
   {
    "ref": "MAP 5.1",
    "text": "Eintrittswahrscheinlichkeit und Ausmaß jeder erkannten Auswirkung – sowohl nützlich als auch schädlich – sind identifiziert und dokumentiert, gestützt auf die vorgesehene Nutzung, Erfahrungen mit KI-Systemen in vergleichbaren Kontexten, öffentliche Vorfallmeldungen, Rückmeldungen von Beteiligten außerhalb des entwickelnden oder bereitstellenden Teams sowie weitere Daten.",
    "staerke": "stark",
    "begruendung": "B.5.2 nennt als Prozesselemente „identification (e.g. sources, events and outcomes)“, „analysis (e.g. consequences and likelihood)“ und „evaluation (e.g. acceptance decisions and prioritization)“. Damit ist die Wahrscheinlichkeits- und Ausmaßbetrachtung je Auswirkung prozessual verankert."
   },
   {
    "ref": "GOVERN 3.1",
    "text": "Entscheidungen zum Erfassen, Messen und Behandeln von KI-Risiken über den gesamten Lebenszyklus stützen sich auf ein vielfältig zusammengesetztes Team (Demografie, Fachdisziplinen, Erfahrung, Expertise, Hintergründe).",
    "staerke": "mittel",
    "begruendung": "B.5.2 c) verlangt festzulegen, wer die AI system impact assessment durchführt, und e) die potenziell betroffenen Individuen und Gesellschaften zu bestimmen. Damit ist die personelle Zusammensetzung zu regeln, ohne Diversitätskriterien vorzugeben."
   },
   {
    "ref": "MAP 1.1",
    "text": "Zweckbestimmung, nutzbringende Anwendungen, kontextspezifische Rechtsvorschriften und Erwartungen sowie die vorgesehene Einsatzumgebung des KI-Systems sind verstanden und dokumentiert. Zu berücksichtigen sind dabei Nutzergruppen, positive wie negative Auswirkungen, Annahmen und Grenzen, Risiken über den KI-Lebenszyklus sowie TEVV (Test, Evaluation, Verification, Validation) und Systemkennzahlen.",
    "staerke": "mittel",
    "begruendung": "A.5.2 verlangt einen Prozess zur Bewertung der Folgen über den gesamten Lebenszyklus; B.5.2 nennt als Auslöser Kritikalität des Zwecks, Komplexität der Technologie und Sensitivität der Daten. Die Lebenszyklusperspektive von MAP 1.1 wird so erfasst, nicht aber die vollständige Kontextdokumentation."
   },
   {
    "ref": "MAP 3.1",
    "text": "Der potenzielle Nutzen der vorgesehenen Funktionalität und Leistung des KI-Systems ist geprüft und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.5.2 strukturiert den Impact-Assessment-Prozess in Identifikation, Analyse, Bewertung, Behandlung und Dokumentation und knüpft ihn an „intended purpose and use“. Der Prozess trägt die Nutzenanalyse, adressiert sie aber nicht eigens."
   },
   {
    "ref": "MAP 3.2",
    "text": "Potenzielle Kosten einschließlich nichtmonetärer Kosten aus erwarteten oder eingetretenen Fehlern sowie aus Funktionalität und Vertrauenswürdigkeit des Systems sind – bezogen auf die Risikotoleranz der Organisation – geprüft und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.5.2 definiert als Prozesselemente Identifikation, Analyse (Konsequenzen und Eintrittswahrscheinlichkeit), Bewertung und Behandlung. Der Prozess erfasst Schadensfolgen, kennt aber keine Kostenkategorie."
   },
   {
    "ref": "MAP 3.3",
    "text": "Der angestrebte Anwendungsbereich ist auf Basis der Systemfähigkeiten, des bestimmten Kontexts und der Kategorisierung des KI-Systems festgelegt und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.5.2 nennt als Einstufungskriterien Kritikalität des Zwecks und Einsatzkontexts, Komplexität der Technologie und Automatisierungsgrad sowie Sensitivität der Datentypen. Das kommt einer Kategorisierung von KI-Systemen am nächsten."
   },
   {
    "ref": "MEASURE 1.3",
    "text": "An den regelmäßigen Bewertungen und Aktualisierungen wirken interne Fachleute außerhalb des Entwicklungsteams und/oder unabhängige Prüfer mit. Entsprechend der Risikotoleranz werden zusätzlich Fachexperten, Nutzer, teamexterne KI-Akteure und betroffene Gruppen hinzugezogen.",
    "staerke": "mittel",
    "begruendung": "A.5.2 c) verlangt festzulegen, wer die AI-System-Folgenabschätzung durchführt, und A.5.2 e) die Identifikation potenziell betroffener Einzelpersonen und Gesellschaften. Eine Unabhängigkeit der durchführenden Personen von der Entwicklung wird jedoch nicht gefordert."
   },
   {
    "ref": "MEASURE 2.10",
    "text": "Das Datenschutzrisiko des KI-Systems – wie in MAP erfasst – wird geprüft und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.5.2 fordert einen Impact-Assessment-Prozess; B.5.2 nennt die Sensitivität der verarbeiteten Datenarten als Auslöser und Privacy ausdrücklich als eine der abzudeckenden Disziplinen."
   },
   {
    "ref": "MEASURE 2.12",
    "text": "Umweltauswirkungen und Nachhaltigkeit von Training und Betrieb des KI-Modells – wie in MAP erfasst – werden bewertet und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.5.2 etabliert nur den generischen Prozess zur Folgenabschätzung über den Lebenszyklus; Umweltauswirkungen sind darin ein möglicher, nicht benannter Prüfgegenstand."
   },
   {
    "ref": "MANAGE 1.1",
    "text": "Es wird festgestellt, ob das KI-System seine Zweckbestimmung und die festgelegten Ziele erreicht und ob Entwicklung oder Bereitstellung fortgeführt werden sollen.",
    "staerke": "schwach",
    "begruendung": "A.5.2 fordert einen Impact-Assessment-Prozess; die Guidance nennt als Verwendungszweck ausdrücklich, dass das Ergebnis Reviews und Genehmigungen auslösen kann. Nur mittelbarer Beitrag zur Fortsetzungsentscheidung."
   }
  ],
  "A.5.3": [
   {
    "ref": "GOVERN 4.2",
    "text": "Die Teams dokumentieren Risiken und mögliche Auswirkungen der von ihnen konzipierten, entwickelten, bereitgestellten, bewerteten und genutzten KI-Technologie und kommunizieren diese Auswirkungen auch über das Team hinaus.",
    "staerke": "stark",
    "begruendung": "A.5.3 verlangt, die Ergebnisse der AI system impact assessments zu dokumentieren und für einen definierten Zeitraum aufzubewahren; B.5.3 listet u.a. intended use und foreseeable misuse, positive und negative Auswirkungen sowie predictable failures. Diese Kernzuordnung fehlte in der Baseline."
   },
   {
    "ref": "MAP 3.1",
    "text": "Der potenzielle Nutzen der vorgesehenen Funktionalität und Leistung des KI-Systems ist geprüft und dokumentiert.",
    "staerke": "stark",
    "begruendung": "B.5.3 verlangt, unter anderem „positive and negative impacts of the AI system to the relevant individuals or groups of individuals, or both, and societies“ zu dokumentieren und die Ergebnisse aufzubewahren. Nutzenpotenziale werden damit ausdrücklich dokumentationspflichtig."
   },
   {
    "ref": "MAP 3.2",
    "text": "Potenzielle Kosten einschließlich nichtmonetärer Kosten aus erwarteten oder eingetretenen Fehlern sowie aus Funktionalität und Vertrauenswürdigkeit des Systems sind – bezogen auf die Risikotoleranz der Organisation – geprüft und dokumentiert.",
    "staerke": "stark",
    "begruendung": "B.5.3 verlangt die Dokumentation von „predictable failures, their potential impacts and measures taken to mitigate them“ sowie der negativen Auswirkungen. Das entspricht den Folgen erwarteter oder eingetretener KI-Fehler."
   },
   {
    "ref": "GOVERN 3.2",
    "text": "Richtlinien und Verfahren definieren und unterscheiden Rollen und Verantwortlichkeiten für das Zusammenwirken von Mensch und KI sowie für die Aufsicht über KI-Systeme.",
    "staerke": "mittel",
    "begruendung": "B.5.3 verlangt, unter anderem „the role of humans in relationships with system, including human oversight capabilities, processes and tools, available to avoid negative impacts“ zu dokumentieren. Das erzwingt die dokumentierte Differenzierung der Mensch-Maschine-Konfiguration."
   },
   {
    "ref": "MAP 3.5",
    "text": "Prozesse für Human Oversight (menschliche Aufsicht) sind entsprechend den Richtlinien aus der Funktion GOVERN definiert, bewertet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.5.3 verlangt die Dokumentation von „the role of humans in relationships with system, including human oversight capabilities, processes and tools, available to avoid negative impacts“. Die Aufsichtsprozesse werden damit im Impact Assessment dokumentiert."
   },
   {
    "ref": "MAP 5.1",
    "text": "Eintrittswahrscheinlichkeit und Ausmaß jeder erkannten Auswirkung – sowohl nützlich als auch schädlich – sind identifiziert und dokumentiert, gestützt auf die vorgesehene Nutzung, Erfahrungen mit KI-Systemen in vergleichbaren Kontexten, öffentliche Vorfallmeldungen, Rückmeldungen von Beteiligten außerhalb des entwickelnden oder bereitstellenden Teams sowie weitere Daten.",
    "staerke": "mittel",
    "begruendung": "B.5.3 verlangt die Dokumentation positiver und negativer Auswirkungen sowie „predictable failures, their potential impacts“. Das sichert die Dokumentationspflicht von MAP 5.1, ohne Wahrscheinlichkeiten eigens zu verlangen."
   },
   {
    "ref": "MEASURE 2.8",
    "text": "Risiken in Bezug auf Transparenz und Rechenschaftspflicht – wie in MAP erfasst – werden geprüft und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.5.3 fordert die Dokumentation und befristete Aufbewahrung der Ergebnisse der Impact Assessments und deckt damit die von NIST geforderte Dokumentation der Transparenz- und Verantwortlichkeitsrisiken ab."
   },
   {
    "ref": "MANAGE 1.4",
    "text": "Negative Restrisiken – die Summe aller nicht geminderten Risiken – gegenüber nachgelagerten Abnehmern des KI-Systems und gegenüber Endnutzern sind dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.5.3 verlangt die Dokumentation und Aufbewahrung der Impact-Assessment-Ergebnisse; die Guidance nennt vorhersehbaren Fehlgebrauch, negative Auswirkungen sowie „predictable failures, their potential impacts and measures taken to mitigate them“. Liefert die inhaltliche Basis, adressiert aber nicht die Weitergabe an Abnehmer."
   },
   {
    "ref": "MEASURE 2.10",
    "text": "Das Datenschutzrisiko des KI-Systems – wie in MAP erfasst – wird geprüft und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.5.3 regelt nur Form und Aufbewahrung der Ergebnisdokumentation der Impact Assessments, nicht die inhaltliche Untersuchung des Datenschutzrisikos."
   },
   {
    "ref": "MEASURE 2.12",
    "text": "Umweltauswirkungen und Nachhaltigkeit von Training und Betrieb des KI-Modells – wie in MAP erfasst – werden bewertet und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.5.3 sichert die Dokumentation und Aufbewahrung der Assessment-Ergebnisse, trifft aber keine Aussage zu Umwelt- oder Nachhaltigkeitsinhalten."
   }
  ],
  "A.5.4": [
   {
    "ref": "GOVERN 4.2",
    "text": "Die Teams dokumentieren Risiken und mögliche Auswirkungen der von ihnen konzipierten, entwickelten, bereitgestellten, bewerteten und genutzten KI-Technologie und kommunizieren diese Auswirkungen auch über das Team hinaus.",
    "staerke": "stark",
    "begruendung": "A.5.4 verlangt, die potenziellen Auswirkungen auf Individuen und Gruppen über den gesamten Lebenszyklus zu bewerten und zu dokumentieren; B.5.4 nennt fairness, accountability, transparency, security, safety, financial consequences, accessibility und human rights. Das ist die individuelle Impact-Dimension."
   },
   {
    "ref": "MEASURE 2.8",
    "text": "Risiken in Bezug auf Transparenz und Rechenschaftspflicht – wie in MAP erfasst – werden geprüft und dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.5.4 verlangt, potenzielle Auswirkungen auf Individuen und Gruppen zu bewerten und zu dokumentieren; B.5.4 nennt „accountability“ sowie „transparency and explainability“ ausdrücklich als zu prüfende Wirkungsbereiche."
   },
   {
    "ref": "MEASURE 2.10",
    "text": "Das Datenschutzrisiko des KI-Systems – wie in MAP erfasst – wird geprüft und dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.5.4 verlangt Bewertung und Dokumentation der Auswirkungen auf Individuen; B.5.4 nennt „security and privacy“ ausdrücklich als Wirkungsbereich und verweist auf Erwartungen von Personen, deren PII verarbeitet werden."
   },
   {
    "ref": "GOVERN 3.1",
    "text": "Entscheidungen zum Erfassen, Messen und Behandeln von KI-Risiken über den gesamten Lebenszyklus stützen sich auf ein vielfältig zusammengesetztes Team (Demografie, Fachdisziplinen, Erfahrung, Expertise, Hintergründe).",
    "staerke": "mittel",
    "begruendung": "B.5.4 verlangt, die besonderen Schutzbedarfe von Gruppen wie Kindern, beeinträchtigten und älteren Personen sowie Beschäftigten zu berücksichtigen, und empfiehlt, Experten wie Forschende, Fachexperten und Nutzer zu konsultieren. Das bringt externe Perspektivenvielfalt in die Bewertung."
   },
   {
    "ref": "GOVERN 5.1",
    "text": "Richtlinien und Praktiken stellen sicher, dass Rückmeldungen von Beteiligten außerhalb des entwickelnden oder bereitstellenden Teams zu möglichen individuellen und gesellschaftlichen Auswirkungen erhoben, bewertet, priorisiert und eingebunden werden.",
    "staerke": "mittel",
    "begruendung": "B.5.4 verlangt, die Erwartungen betroffener Individuen an die Trustworthiness zu bewerten und Mittel zu ihrer Berücksichtigung im Impact Assessment zu erwägen, und empfiehlt die Konsultation von Forschenden, Fachexperten und Nutzern. Das ist die inhaltliche Verarbeitung externer Perspektiven."
   },
   {
    "ref": "GOVERN 5.2",
    "text": "Mechanismen stellen sicher, dass geprüfte Rückmeldungen relevanter KI-Akteure regelmäßig in Systemdesign und Umsetzung einfließen.",
    "staerke": "mittel",
    "begruendung": "B.5.4 verlangt, die Erwartungen betroffener Individuen zu bewerten und die Mittel zu ihrer Berücksichtigung als Teil des Impact Assessments zu erwägen. Das ist der normierte Bewertungsschritt zwischen Feedback und Systemänderung."
   },
   {
    "ref": "MAP 1.1",
    "text": "Zweckbestimmung, nutzbringende Anwendungen, kontextspezifische Rechtsvorschriften und Erwartungen sowie die vorgesehene Einsatzumgebung des KI-Systems sind verstanden und dokumentiert. Zu berücksichtigen sind dabei Nutzergruppen, positive wie negative Auswirkungen, Annahmen und Grenzen, Risiken über den KI-Lebenszyklus sowie TEVV (Test, Evaluation, Verification, Validation) und Systemkennzahlen.",
    "staerke": "mittel",
    "begruendung": "A.5.4 verlangt Bewertung und Dokumentation der Auswirkungen auf Individuen und Gruppen; B.5.4 nennt Fairness, Transparenz, Sicherheit, Privatheit und Menschenrechte als Bewertungsfelder. Das entspricht dem NIST-Punkt „potential positive and negative impacts ... to individuals, communities“."
   },
   {
    "ref": "MAP 1.6",
    "text": "Systemanforderungen (z. B. Wahrung der Privatsphäre der Nutzer) werden bei den relevanten KI-Akteuren erhoben und von ihnen verstanden; Designentscheidungen berücksichtigen soziotechnische Wirkungen, um KI-Risiken zu adressieren.",
    "staerke": "mittel",
    "begruendung": "B.5.4 verlangt die Berücksichtigung von Erwartungen an die Vertrauenswürdigkeit sowie von Fairness, Transparenz, Sicherheit, Privatheit und Menschenrechten. Diese Felder sind die inhaltliche Basis für Anforderungen wie „the system shall respect the privacy of its users“."
   },
   {
    "ref": "MAP 3.1",
    "text": "Der potenzielle Nutzen der vorgesehenen Funktionalität und Leistung des KI-Systems ist geprüft und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.5.4 verlangt die Bewertung und Dokumentation der potenziellen Auswirkungen auf Individuen und Gruppen über den Lebenszyklus, inhaltlich entlang Fairness, Zugänglichkeit und Gesundheit. Positive Auswirkungen sind dabei mitgemeint."
   },
   {
    "ref": "MAP 3.2",
    "text": "Potenzielle Kosten einschließlich nichtmonetärer Kosten aus erwarteten oder eingetretenen Fehlern sowie aus Funktionalität und Vertrauenswürdigkeit des Systems sind – bezogen auf die Risikotoleranz der Organisation – geprüft und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.5.4 nennt als Auswirkungsfelder ausdrücklich „financial consequences“ neben Fairness, Sicherheit, Gesundheit, Zugänglichkeit und Menschenrechten. Damit sind monetäre und nicht-monetäre Folgen für Betroffene abgedeckt."
   },
   {
    "ref": "MAP 5.1",
    "text": "Eintrittswahrscheinlichkeit und Ausmaß jeder erkannten Auswirkung – sowohl nützlich als auch schädlich – sind identifiziert und dokumentiert, gestützt auf die vorgesehene Nutzung, Erfahrungen mit KI-Systemen in vergleichbaren Kontexten, öffentliche Vorfallmeldungen, Rückmeldungen von Beteiligten außerhalb des entwickelnden oder bereitstellenden Teams sowie weitere Daten.",
    "staerke": "mittel",
    "begruendung": "A.5.4 verlangt die Bewertung und Dokumentation der potenziellen Auswirkungen auf Individuen und Gruppen über den gesamten Lebenszyklus. Das liefert die inhaltliche Grundlage der je Auswirkung zu bestimmenden Größe."
   },
   {
    "ref": "MEASURE 1.2",
    "text": "Die Eignung der KI-Kennzahlen und die Wirksamkeit bestehender Maßnahmen werden regelmäßig bewertet und fortgeschrieben, einschließlich der Auswertung von Fehlermeldungen und von Auswirkungen auf betroffene Gruppen.",
    "staerke": "mittel",
    "begruendung": "A.5.4 fordert die Bewertung und Dokumentation der Auswirkungen auf Einzelpersonen und Gruppen über den gesamten Lebenszyklus, einschließlich Fairness, Sicherheit und Menschenrechten. Damit sind Auswirkungen auf betroffene Gruppen erfasst, nicht aber deren strukturierte Rückmeldung an das Metrikdesign."
   },
   {
    "ref": "MEASURE 1.3",
    "text": "An den regelmäßigen Bewertungen und Aktualisierungen wirken interne Fachleute außerhalb des Entwicklungsteams und/oder unabhängige Prüfer mit. Entsprechend der Risikotoleranz werden zusätzlich Fachexperten, Nutzer, teamexterne KI-Akteure und betroffene Gruppen hinzugezogen.",
    "staerke": "mittel",
    "begruendung": "A.5.4 empfiehlt in den weiteren Hinweisen ausdrücklich, bei Bedarf Experten wie Forschende, Fachexperten und Nutzende zu konsultieren, um Auswirkungen vollständig zu verstehen. Das entspricht der Konsultation von Domänenexperten, ist aber nur eine Empfehlung ohne Unabhängigkeitskriterium."
   },
   {
    "ref": "MEASURE 2.11",
    "text": "Fairness und Bias (systematische Verzerrung) – wie in MAP erfasst – werden bewertet und die Ergebnisse dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.5.4 fordert Bewertung und Dokumentation der Auswirkungen auf Individuen und Gruppen; B.5.4 nennt „fairness“ als ersten der zu betrachtenden Wirkungsbereiche und verlangt die Berücksichtigung besonders schutzbeduerftiger Gruppen."
   },
   {
    "ref": "MEASURE 4.1",
    "text": "Messansätze zur Identifikation von KI-Risiken sind auf den jeweiligen Einsatzkontext bezogen und werden unter Einbeziehung von Fachexperten und Endnutzern abgestimmt; die Ansätze sind dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.5.4 empfiehlt die Konsultation von Experten wie Forschenden, Fachleuten und Nutzern, um die potenziellen Auswirkungen des Systems vollständig zu erfassen."
   },
   {
    "ref": "MEASURE 4.2",
    "text": "Messergebnisse zur Vertrauenswürdigkeit im Einsatzkontext und über den KI-Lebenszyklus werden unter Mitwirkung von Fachexperten und weiteren relevanten KI-Akteuren daraufhin beurteilt, ob das System bestimmungsgemäß und gleichbleibend arbeitet; die Ergebnisse sind dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.5.4 empfiehlt, Fachleute und Nutzer heranzuziehen, um die Auswirkungen des Systems vollständig zu verstehen, und stützt damit die geforderte Expertenrückkopplung der Messergebnisse."
   },
   {
    "ref": "MAP 1.2",
    "text": "Interdisziplinäre KI-Akteure mit vielfältigem demografischem Hintergrund sowie breiter Fach- und Anwendungserfahrung wirken an der Kontextbestimmung mit; ihre Beteiligung wird dokumentiert und interdisziplinäre Zusammenarbeit vorrangig ermöglicht.",
    "staerke": "schwach",
    "begruendung": "B.5.4 empfiehlt, bei Bedarf Experten wie Forschende, Fachleute und Nutzende zu konsultieren, um Auswirkungen vollständig zu verstehen. Das ist nur ein punktueller Beteiligungsaspekt und keine durchgängige Kapazitätsanforderung."
   },
   {
    "ref": "MEASURE 2.2",
    "text": "Bewertungen unter Beteiligung von Menschen erfüllen die einschlägigen Anforderungen einschließlich des Probandenschutzes und bilden die relevante Population repräsentativ ab.",
    "staerke": "schwach",
    "begruendung": "A.5.4 verlangt, besondere Schutzbeduerfnisse von Gruppen wie Kindern, beeinträchtigten und älteren Personen sowie Beschäftigten zu berücksichtigen. Gemeint sind jedoch die von einem AI-System Betroffenen, nicht Teilnehmende an Evaluationsstudien."
   }
  ],
  "A.5.5": [
   {
    "ref": "GOVERN 4.2",
    "text": "Die Teams dokumentieren Risiken und mögliche Auswirkungen der von ihnen konzipierten, entwickelten, bereitgestellten, bewerteten und genutzten KI-Technologie und kommunizieren diese Auswirkungen auch über das Team hinaus.",
    "staerke": "mittel",
    "begruendung": "A.5.5 verlangt, die potenziellen gesellschaftlichen Auswirkungen zu bewerten und zu dokumentieren; B.5.5 nennt Umwelt, Wirtschaft, Regierungshandeln, Gesundheit und kulturelle Normen. Das deckt die gesellschaftliche Dimension der Risiken ab."
   },
   {
    "ref": "GOVERN 5.1",
    "text": "Richtlinien und Praktiken stellen sicher, dass Rückmeldungen von Beteiligten außerhalb des entwickelnden oder bereitstellenden Teams zu möglichen individuellen und gesellschaftlichen Auswirkungen erhoben, bewertet, priorisiert und eingebunden werden.",
    "staerke": "mittel",
    "begruendung": "A.5.5 verlangt die Bewertung und Dokumentation gesellschaftlicher Auswirkungen über den Lebenszyklus. Das entspricht dem societal impacts-Teil der Subkategorie, regelt aber keine Feedback-Erhebung."
   },
   {
    "ref": "MAP 1.1",
    "text": "Zweckbestimmung, nutzbringende Anwendungen, kontextspezifische Rechtsvorschriften und Erwartungen sowie die vorgesehene Einsatzumgebung des KI-Systems sind verstanden und dokumentiert. Zu berücksichtigen sind dabei Nutzergruppen, positive wie negative Auswirkungen, Annahmen und Grenzen, Risiken über den KI-Lebenszyklus sowie TEVV (Test, Evaluation, Verification, Validation) und Systemkennzahlen.",
    "staerke": "mittel",
    "begruendung": "A.5.5 verlangt die Bewertung gesellschaftlicher Auswirkungen; B.5.5 nennt ausdrücklich Umweltnachhaltigkeit, Wirtschaft, Gesundheit und Werte. Damit sind die NIST-Adressaten „society, and the planet“ abgedeckt."
   },
   {
    "ref": "MAP 3.1",
    "text": "Der potenzielle Nutzen der vorgesehenen Funktionalität und Leistung des KI-Systems ist geprüft und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.5.5 stellt ausdrücklich fest: „The societal impacts of AI systems can be both beneficial and detrimental“, und fragt etwa nach verbessertem Zugang zu Finanzdienstleistungen. Der gesellschaftliche Nutzen ist damit explizit Bewertungsgegenstand."
   },
   {
    "ref": "MAP 3.2",
    "text": "Potenzielle Kosten einschließlich nichtmonetärer Kosten aus erwarteten oder eingetretenen Fehlern sowie aus Funktionalität und Vertrauenswürdigkeit des Systems sind – bezogen auf die Risikotoleranz der Organisation – geprüft und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.5.5 nennt ökonomische, gesundheitliche, umweltbezogene und gesellschaftliche Schadenspotenziale einschließlich Desinformation. Das erfasst die nicht-monetären Kosten auf gesellschaftlicher Ebene."
   },
   {
    "ref": "MEASURE 2.12",
    "text": "Umweltauswirkungen und Nachhaltigkeit von Training und Betrieb des KI-Modells – wie in MAP erfasst – werden bewertet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.5.5 verlangt Bewertung und Dokumentation gesellschaftlicher Auswirkungen; B.5.5 nennt Umweltverträglichkeit einschließlich Treibhausgasemissionen und fordert, die Wirkung rechenintensiver Entwicklung im Kontext der Nachhaltigkeitsziele zu betrachten."
   },
   {
    "ref": "MAP 1.6",
    "text": "Systemanforderungen (z. B. Wahrung der Privatsphäre der Nutzer) werden bei den relevanten KI-Akteuren erhoben und von ihnen verstanden; Designentscheidungen berücksichtigen soziotechnische Wirkungen, um KI-Risiken zu adressieren.",
    "staerke": "schwach",
    "begruendung": "A.5.5 verlangt die Bewertung gesellschaftlicher Auswirkungen über den Lebenszyklus. Der Rückfluss dieser Bewertung in konkrete Systemanforderungen wird jedoch nicht ausdrücklich gefordert."
   },
   {
    "ref": "MAP 5.1",
    "text": "Eintrittswahrscheinlichkeit und Ausmaß jeder erkannten Auswirkung – sowohl nützlich als auch schädlich – sind identifiziert und dokumentiert, gestützt auf die vorgesehene Nutzung, Erfahrungen mit KI-Systemen in vergleichbaren Kontexten, öffentliche Vorfallmeldungen, Rückmeldungen von Beteiligten außerhalb des entwickelnden oder bereitstellenden Teams sowie weitere Daten.",
    "staerke": "schwach",
    "begruendung": "A.5.5 verlangt die Bewertung gesellschaftlicher Auswirkungen über den Lebenszyklus. Eine Quantifizierung nach Wahrscheinlichkeit und Ausmaß wird dort nicht gefordert."
   },
   {
    "ref": "MEASURE 1.2",
    "text": "Die Eignung der KI-Kennzahlen und die Wirksamkeit bestehender Maßnahmen werden regelmäßig bewertet und fortgeschrieben, einschließlich der Auswertung von Fehlermeldungen und von Auswirkungen auf betroffene Gruppen.",
    "staerke": "schwach",
    "begruendung": "A.5.5 verlangt die laufende Bewertung gesellschaftlicher Auswirkungen über den Lebenszyklus. Der Bezug zur Angemessenheit von Metriken und zur Fehlerberichterstattung ist nur thematisch."
   },
   {
    "ref": "MEASURE 1.3",
    "text": "An den regelmäßigen Bewertungen und Aktualisierungen wirken interne Fachleute außerhalb des Entwicklungsteams und/oder unabhängige Prüfer mit. Entsprechend der Risikotoleranz werden zusätzlich Fachexperten, Nutzer, teamexterne KI-Akteure und betroffene Gruppen hinzugezogen.",
    "staerke": "schwach",
    "begruendung": "A.5.5 verlangt die Bewertung gesellschaftlicher Auswirkungen und die Analyse, wie Akteure das System missbrauchen können. Betroffene Gemeinschaften sind damit Bewertungsgegenstand, nicht Konsultationspartner."
   },
   {
    "ref": "MEASURE 2.8",
    "text": "Risiken in Bezug auf Transparenz und Rechenschaftspflicht – wie in MAP erfasst – werden geprüft und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.5.5 adressiert gesellschaftliche Auswirkungen und berührt Transparenzrisiken nur mittelbar über Fehlinformation und Vertrauensverlust (B.5.5), nicht als eigene Prüfdimension."
   },
   {
    "ref": "MEASURE 2.11",
    "text": "Fairness und Bias (systematische Verzerrung) – wie in MAP erfasst – werden bewertet und die Ergebnisse dokumentiert.",
    "staerke": "schwach",
    "begruendung": "B.5.5 verlangt die Analyse, wie KI-Systeme unerwünschte historische soziale Verzerrungen verstärken können; das ist eine gesellschaftliche Betrachtung, keine Evaluation der Systemergebnisse."
   },
   {
    "ref": "MEASURE 4.1",
    "text": "Messansätze zur Identifikation von KI-Risiken sind auf den jeweiligen Einsatzkontext bezogen und werden unter Einbeziehung von Fachexperten und Endnutzern abgestimmt; die Ansätze sind dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.5.5 verpflichtet zur Bewertung gesellschaftlicher Auswirkungen und liefert damit Kontextwissen zum Einsatzumfeld, aber keine Messansätze zur Risikoidentifikation."
   }
  ],
  "A.6.1.2": [
   {
    "ref": "GOVERN 1.2",
    "text": "Die Merkmale vertrauenswürdiger KI sind in die Richtlinien, Prozesse und Verfahren der Organisation integriert.",
    "staerke": "stark",
    "begruendung": "A.6.1.2 verlangt, Ziele für verantwortungsvolle Entwicklung zu dokumentieren und Maßnahmen zu ihrer Erreichung in den Entwicklungslebenszyklus zu integrieren. B.6.1.2 illustriert dies am Beispiel fairness, das in Requirements, Datenakquise, Training und V&V einzuarbeiten ist."
   },
   {
    "ref": "GOVERN 4.1",
    "text": "Richtlinien und Praktiken fördern kritisches Denken und einen Sicherheitsvorrang bei Konzeption, Entwicklung, Bereitstellung und Nutzung von KI-Systemen, um negative Auswirkungen zu minimieren.",
    "staerke": "stark",
    "begruendung": "A.6.1.2 verlangt dokumentierte Ziele für verantwortungsvolle Entwicklung und die Integration von Maßnahmen zu ihrer Erreichung in den Entwicklungslebenszyklus. B.6.1.2 verlangt dazu Anforderungen und Leitlinien, etwa die Vorgabe bestimmter Testwerkzeuge gegen unwanted bias."
   },
   {
    "ref": "MAP 1.3",
    "text": "Auftrag und einschlägige Ziele der Organisation für die KI-Technologie sind verstanden und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.6.1.2 verlangt die Identifikation und Dokumentation von Zielen für die verantwortliche Entwicklung und deren Integration in den Entwicklungslebenszyklus. Das konkretisiert die Organisationsziele für die KI-Technologie."
   },
   {
    "ref": "MAP 1.6",
    "text": "Systemanforderungen (z. B. Wahrung der Privatsphäre der Nutzer) werden bei den relevanten KI-Akteuren erhoben und von ihnen verstanden; Designentscheidungen berücksichtigen soziotechnische Wirkungen, um KI-Risiken zu adressieren.",
    "staerke": "mittel",
    "begruendung": "B.6.1.2 verlangt, Ziele wie Fairness in die Anforderungsspezifikation, Datenbeschaffung, Modelltraining und Validierung zu integrieren. Damit fließen sozio-technische Erwägungen in Entwurfsentscheidungen ein."
   },
   {
    "ref": "MEASURE 1.1",
    "text": "Messansätze und Kennzahlen für die in MAP erfassten KI-Risiken werden ausgewählt und zuerst auf die wesentlichen Risiken angewendet. Risiken oder Merkmale der Vertrauenswürdigkeit, die nicht gemessen werden oder nicht messbar sind, werden dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.6.1.2 verlangt, Ziele verantwortlicher Entwicklung zu dokumentieren und Maßnahmen zu ihrer Erreichung in den Lebenszyklus zu integrieren (z. B. ein bestimmtes Testwerkzeug gegen unerwünschten Bias). Das berührt die Metrikauswahl nur mittelbar über Zielvorgaben."
   },
   {
    "ref": "MEASURE 2.8",
    "text": "Risiken in Bezug auf Transparenz und Rechenschaftspflicht – wie in MAP erfasst – werden geprüft und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.6.1.2 verlangt Ziele für verantwortliche Entwicklung und deren Integration in den Lebenszyklus; Transparenz kann ein solches Ziel sein, eine Risikoprüfung schreibt das Control aber nicht vor."
   },
   {
    "ref": "MEASURE 2.11",
    "text": "Fairness und Bias (systematische Verzerrung) – wie in MAP erfasst – werden bewertet und die Ergebnisse dokumentiert.",
    "staerke": "schwach",
    "begruendung": "B.6.1.2 führt Fairness nur als Beispiel für ein Entwicklungsziel an, das bis in Verifizierung und Validierung zu tragen ist; eine Fairness-Bewertung ist damit nicht normativ gefordert."
   }
  ],
  "A.6.1.3": [
   {
    "ref": "GOVERN 1.2",
    "text": "Die Merkmale vertrauenswürdiger KI sind in die Richtlinien, Prozesse und Verfahren der Organisation integriert.",
    "staerke": "stark",
    "begruendung": "A.6.1.3 verlangt definierte und dokumentierte Prozesse für verantwortungsvolle Gestaltung und Entwicklung; B.6.1.3 listet u.a. Testanforderungen, human oversight, Release-Kriterien und change control. Das deckt die Verankerung in processes and procedures ab."
   },
   {
    "ref": "GOVERN 3.2",
    "text": "Richtlinien und Verfahren definieren und unterscheiden Rollen und Verantwortlichkeiten für das Zusammenwirken von Mensch und KI sowie für die Aufsicht über KI-Systeme.",
    "staerke": "stark",
    "begruendung": "B.6.1.3 nennt als zwingend zu berücksichtigendes Prozesselement „human oversight requirements, including processes and tools, especially when the AI system can impact natural persons“. Damit ist die Verankerung in Prozessen und Verfahren gefordert."
   },
   {
    "ref": "GOVERN 4.1",
    "text": "Richtlinien und Praktiken fördern kritisches Denken und einen Sicherheitsvorrang bei Konzeption, Entwicklung, Bereitstellung und Nutzung von KI-Systemen, um negative Auswirkungen zu minimieren.",
    "staerke": "stark",
    "begruendung": "A.6.1.3 verlangt dokumentierte Prozesse für verantwortungsvolles Design und Entwicklung; B.6.1.3 nennt Testanforderungen, human oversight, release criteria sowie „approvals and sign-offs necessary at various stages“. Das etabliert die geforderten Praktiken."
   },
   {
    "ref": "GOVERN 5.2",
    "text": "Mechanismen stellen sicher, dass geprüfte Rückmeldungen relevanter KI-Akteure regelmäßig in Systemdesign und Umsetzung einfließen.",
    "staerke": "stark",
    "begruendung": "B.6.1.3 nennt als Prozesselemente ausdrücklich change control, „approvals and sign-offs necessary at various stages“ und engagement of interested parties. Das ist der Mechanismus, über den bewertetes Feedback in Design und Entwicklung einfließt."
   },
   {
    "ref": "MAP 3.5",
    "text": "Prozesse für Human Oversight (menschliche Aufsicht) sind entsprechend den Richtlinien aus der Funktion GOVERN definiert, bewertet und dokumentiert.",
    "staerke": "stark",
    "begruendung": "B.6.1.3 verlangt ausdrücklich „human oversight requirements, including processes and tools, especially when the AI system can impact natural persons“ als dokumentierten Bestandteil der Entwicklungsprozesse. Damit sind Definition und Dokumentation der Aufsichtsprozesse normativ verankert."
   },
   {
    "ref": "GOVERN 1.7",
    "text": "Prozesse und Verfahren regeln die sichere Außerbetriebnahme und Ablösung von KI-Systemen, ohne dabei Risiken zu erhöhen oder die Vertrauenswürdigkeit der Organisation zu mindern.",
    "staerke": "mittel",
    "begruendung": "A.6.1.3 verlangt dokumentierte Prozesse für den verantwortungsvollen Lebenszyklus; B.6.1.3 nennt life cycle stages (nach ISO/IEC 22989 einschließlich Retirement) sowie change control und approvals and sign-offs. Daraus ist der Phase-out-Prozess ableitbar, aber nicht explizit gefordert."
   },
   {
    "ref": "GOVERN 2.2",
    "text": "Beschäftigte und Partner erhalten Schulungen zum KI-Risikomanagement, damit sie ihre Aufgaben im Einklang mit den einschlägigen Richtlinien, Verfahren und Vereinbarungen wahrnehmen können.",
    "staerke": "mittel",
    "begruendung": "B.6.1.3 nennt als Element verantwortungsvoller Entwicklungsprozesse ausdrücklich „expertise (subject matter domain or other) required or training for developers of AI systems or both“. Das verankert Schulung im Entwicklungsprozess."
   },
   {
    "ref": "GOVERN 3.1",
    "text": "Entscheidungen zum Erfassen, Messen und Behandeln von KI-Risiken über den gesamten Lebenszyklus stützen sich auf ein vielfältig zusammengesetztes Team (Demografie, Fachdisziplinen, Erfahrung, Expertise, Hintergründe).",
    "staerke": "mittel",
    "begruendung": "B.6.1.3 nennt als Elemente verantwortungsvoller Entwicklungsprozesse die erforderliche expertise (subject matter domain or other) und die engagement of interested parties. Das verankert multidisziplinäre Beteiligung im Entwicklungsprozess."
   },
   {
    "ref": "GOVERN 4.3",
    "text": "Organisatorische Praktiken ermöglichen das Testen von KI, die Erkennung von Vorfällen und den Informationsaustausch.",
    "staerke": "mittel",
    "begruendung": "B.6.1.3 nennt als Element verantwortungsvoller Entwicklungsprozesse ausdrücklich „testing requirements and planned means for testing“ sowie release criteria. Das schafft die organisatorische Voraussetzung für AI-Tests."
   },
   {
    "ref": "MAP 1.2",
    "text": "Interdisziplinäre KI-Akteure mit vielfältigem demografischem Hintergrund sowie breiter Fach- und Anwendungserfahrung wirken an der Kontextbestimmung mit; ihre Beteiligung wird dokumentiert und interdisziplinäre Zusammenarbeit vorrangig ermöglicht.",
    "staerke": "mittel",
    "begruendung": "B.6.1.3 fordert als Bestandteil verantwortlicher Entwicklungsprozesse die Festlegung erforderlicher „expertise (subject matter domain or other)“ sowie die „engagement of interested parties“. Das entspricht dem NIST-Ziel interdisziplinärer Zusammenarbeit, ohne sie zu priorisieren."
   },
   {
    "ref": "MAP 1.6",
    "text": "Systemanforderungen (z. B. Wahrung der Privatsphäre der Nutzer) werden bei den relevanten KI-Akteuren erhoben und von ihnen verstanden; Designentscheidungen berücksichtigen soziotechnische Wirkungen, um KI-Risiken zu adressieren.",
    "staerke": "mittel",
    "begruendung": "B.6.1.3 nennt als Prozessbestandteile Human-Oversight-Anforderungen, Usability und Controllability sowie „engagement of interested parties“. Das adressiert die sozio-technische Dimension von Entwurfsentscheidungen."
   },
   {
    "ref": "MAP 2.3",
    "text": "Wissenschaftliche Integrität und TEVV-Aspekte sind identifiziert und dokumentiert, unter anderem zu Versuchsdesign, Datenerhebung und -auswahl (Verfügbarkeit, Repräsentativität, Eignung), Vertrauenswürdigkeit des Systems und Konstruktvalidierung.",
    "staerke": "mittel",
    "begruendung": "B.6.1.3 verlangt als Bestandteil verantwortlicher Entwicklungsprozesse „testing requirements and planned means for testing“, Erwartungen an Trainingsdaten sowie Freigabekriterien. Die TEVV-Erwägungen werden damit prozessual verankert."
   },
   {
    "ref": "MAP 3.4",
    "text": "Prozesse zur Fachkunde von Bedienern und Fachanwendern hinsichtlich Leistung und Vertrauenswürdigkeit des KI-Systems sowie einschlägige technische Normen und Zertifizierungen sind definiert, bewertet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.6.1.3 verlangt die Festlegung der erforderlichen Expertise bzw. Schulung für Entwickelnde von KI-Systemen als Bestandteil der Entwicklungsprozesse. Der Betriebsbereich wird dabei nur teilweise erfasst."
   },
   {
    "ref": "MAP 5.2",
    "text": "Praktiken und Personal für den regelmäßigen Austausch mit relevanten KI-Akteuren sowie für die Einbindung von Rückmeldungen zu positiven, negativen und unerwarteten Auswirkungen bestehen und sind dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.6.1.3 nennt „engagement of interested parties“ als zu berücksichtigenden Bestandteil der verantwortlichen Entwicklungsprozesse. Die Einbindung wird gefordert, aber nicht als wiederkehrende Praxis ausgestaltet."
   },
   {
    "ref": "MANAGE 1.1",
    "text": "Es wird festgestellt, ob das KI-System seine Zweckbestimmung und die festgelegten Ziele erreicht und ob Entwicklung oder Bereitstellung fortgeführt werden sollen.",
    "staerke": "mittel",
    "begruendung": "A.6.1.3 verlangt dokumentierte Prozesse für verantwortungsvolle Entwicklung; die Guidance listet Release-Kriterien sowie „approvals and sign-offs necessary at various stages“. Der Fokus liegt auf der Prozessdefinition, nicht auf der konkreten Einzelfallentscheidung."
   },
   {
    "ref": "MANAGE 2.2",
    "text": "Mechanismen zur dauerhaften Werterhaltung bereitgestellter KI-Systeme bestehen und werden angewendet.",
    "staerke": "mittel",
    "begruendung": "A.6.1.3 verlangt dokumentierte Prozesse für verantwortungsvolles Design und Entwicklung; die Guidance nennt Change Control, „usability and controllability“ sowie „engagement of interested parties“. Wirkt auf die Entwicklungsseite, nicht auf den Werterhalt im Betrieb."
   },
   {
    "ref": "MEASURE 1.3",
    "text": "An den regelmäßigen Bewertungen und Aktualisierungen wirken interne Fachleute außerhalb des Entwicklungsteams und/oder unabhängige Prüfer mit. Entsprechend der Risikotoleranz werden zusätzlich Fachexperten, Nutzer, teamexterne KI-Akteure und betroffene Gruppen hinzugezogen.",
    "staerke": "schwach",
    "begruendung": "A.6.1.3 nennt als Bestandteile verantwortlicher Entwicklungsprozesse unter anderem die erforderliche Fachexpertise, Freigaben und Sign-offs sowie die Einbindung interessierter Parteien. Eine personelle Trennung von Entwicklung und Bewertung ist darin nicht angelegt."
   }
  ],
  "A.6.2.2": [
   {
    "ref": "MAP 1.4",
    "text": "Der geschäftliche Nutzen bzw. der betriebliche Einsatzkontext ist klar definiert oder – bei der Bewertung bestehender KI-Systeme – erneut bewertet.",
    "staerke": "stark",
    "begruendung": "B.6.2.2 verlangt ausdrücklich die Dokumentation, „why the AI system is to be developed, for example, is this driven by a business case, customer request or by government policy“, und fordert die erneute Prüfung der Anforderungen, wenn das System nicht wie beabsichtigt arbeitet. Damit sind sowohl die Erstdefinition des Geschäftsnutzens als auch die Neubewertung bestehender Systeme abgedeckt."
   },
   {
    "ref": "MAP 1.6",
    "text": "Systemanforderungen (z. B. Wahrung der Privatsphäre der Nutzer) werden bei den relevanten KI-Akteuren erhoben und von ihnen verstanden; Designentscheidungen berücksichtigen soziotechnische Wirkungen, um KI-Risiken zu adressieren.",
    "staerke": "stark",
    "begruendung": "A.6.2.2 verlangt, Anforderungen für neue KI-Systeme oder wesentliche Erweiterungen zu spezifizieren und zu dokumentieren; B.6.2.2 fordert, dass diese Anforderungen den gesamten Lebenszyklus umfassen und bei neuen Erkenntnissen revidiert werden. Das ist die direkte Entsprechung zu „system requirements ... are elicited“."
   },
   {
    "ref": "MAP 3.3",
    "text": "Der angestrebte Anwendungsbereich ist auf Basis der Systemfähigkeiten, des bestimmten Kontexts und der Kategorisierung des KI-Systems festgelegt und dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.6.2.2 verlangt die Spezifikation und Dokumentation der Anforderungen für das KI-System; B.6.2.2 fordert zusätzlich die Dokumentation von Begründung und Zielen sowie die Revision, wenn das System nicht wie beabsichtigt arbeitet. Der angestrebte Anwendungsbereich wird damit festgelegt und dokumentiert."
   },
   {
    "ref": "GOVERN 5.2",
    "text": "Mechanismen stellen sicher, dass geprüfte Rückmeldungen relevanter KI-Akteure regelmäßig in Systemdesign und Umsetzung einfließen.",
    "staerke": "mittel",
    "begruendung": "B.6.2.2 verlangt, Systemanforderungen zu revidieren, wenn das System nicht wie beabsichtigt arbeitet oder „new information arises that can be used to change and to improve the requirements“. Das ist die Rückkopplung in die Spezifikation."
   },
   {
    "ref": "MAP 1.1",
    "text": "Zweckbestimmung, nutzbringende Anwendungen, kontextspezifische Rechtsvorschriften und Erwartungen sowie die vorgesehene Einsatzumgebung des KI-Systems sind verstanden und dokumentiert. Zu berücksichtigen sind dabei Nutzergruppen, positive wie negative Auswirkungen, Annahmen und Grenzen, Risiken über den KI-Lebenszyklus sowie TEVV (Test, Evaluation, Verification, Validation) und Systemkennzahlen.",
    "staerke": "mittel",
    "begruendung": "B.6.2.2 verlangt die Dokumentation der Begründung und Ziele eines KI-Systems sowie Anforderungen, die den gesamten Lebenszyklus umfassen. Das trifft die NIST-Forderung nach dokumentierten Annahmen zum Systemzweck und Risiken über den Lebenszyklus."
   },
   {
    "ref": "MAP 2.1",
    "text": "Die konkrete Aufgabe des KI-Systems und die zu ihrer Umsetzung eingesetzten Methoden sind definiert (z. B. Klassifikatoren, generative Modelle, Empfehlungssysteme).",
    "staerke": "mittel",
    "begruendung": "B.6.2.2 verlangt die Dokumentation von Begründung, Zielen und Anforderungen des KI-Systems einschließlich der Frage, wie das Modell trainiert werden kann. Die Aufgabe wird damit spezifiziert, die Methodenwahl nur mittelbar."
   },
   {
    "ref": "MANAGE 2.1",
    "text": "Die für die Behandlung von KI-Risiken erforderlichen Ressourcen werden berücksichtigt, ebenso tragfähige Alternativen ohne KI, um Ausmaß oder Eintrittswahrscheinlichkeit möglicher Auswirkungen zu verringern.",
    "staerke": "schwach",
    "begruendung": "A.6.2.2 verlangt die Dokumentation von Anforderungen und der Begründung, warum ein KI-System entwickelt wird (Business Case, Kundenwunsch, Politik), und die Revision der Anforderungen, wenn das System nicht wie beabsichtigt arbeiten kann. Berührt die Alternativenprüfung nur am Rand."
   }
  ],
  "A.6.2.3": [
   {
    "ref": "MAP 2.1",
    "text": "Die konkrete Aufgabe des KI-Systems und die zu ihrer Umsetzung eingesetzten Methoden sind definiert (z. B. Klassifikatoren, generative Modelle, Empfehlungssysteme).",
    "staerke": "stark",
    "begruendung": "B.6.2.3 verlangt die Dokumentation der Entwurfsentscheidungen einschließlich „machine learning approach (e.g. supervised vs. unsupervised)“ sowie „learning algorithm and type of machine learning model utilized“. Das entspricht exakt der NIST-Forderung nach definierter Aufgabe und Methode."
   },
   {
    "ref": "MEASURE 2.7",
    "text": "Security und Resilienz des KI-Systems – wie in MAP erfasst – werden bewertet und dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.6.2.3 verlangt, die im gesamten AI-Lebenszyklus betrachteten Sicherheitsbedrohungen zu dokumentieren, und nennt ausdrücklich AI-spezifische Bedrohungen wie Data Poisoning, Model Stealing und Model-Inversion-Angriffe. Das ist der konkreteste Anknüpfungspunkt für Sicherheitsbewertung und deren Dokumentation."
   },
   {
    "ref": "MAP 1.6",
    "text": "Systemanforderungen (z. B. Wahrung der Privatsphäre der Nutzer) werden bei den relevanten KI-Akteuren erhoben und von ihnen verstanden; Designentscheidungen berücksichtigen soziotechnische Wirkungen, um KI-Risiken zu adressieren.",
    "staerke": "mittel",
    "begruendung": "B.6.2.3 verlangt die Dokumentation von Entwurfsentscheidungen einschließlich Schnittstelle und Darstellung der Ausgaben sowie „how humans can interact with the system“. Entwurfsentscheidungen werden so nachvollziehbar festgehalten."
   },
   {
    "ref": "MEASURE 2.1",
    "text": "Testdatensätze, Kennzahlen und die eingesetzten Werkzeuge für TEVV (Test, Evaluation, Verification, Validation) sind dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.6.2.3 verlangt die Dokumentation von Design und Entwicklung einschließlich der Evaluation und Verfeinerung der Modelle sowie der Hardware- und Softwarekomponenten. Der Detailgrad bleibt hinter einer TEVV-spezifischen Dokumentation zurück."
   },
   {
    "ref": "MEASURE 2.9",
    "text": "Das KI-Modell wird erläutert, validiert und dokumentiert; die Ausgaben des Systems werden im jeweiligen Kontext – wie in MAP bestimmt – interpretiert und stützen eine verantwortungsvolle Nutzung und Governance.",
    "staerke": "mittel",
    "begruendung": "A.6.2.3 verlangt die Dokumentation von Design und Entwicklung; B.6.2.3 nennt Lernverfahren, Modelltyp, Modellevaluation sowie die Darstellung der Ausgaben als zu dokumentierende Entwurfsentscheidungen."
   },
   {
    "ref": "MANAGE 3.2",
    "text": "Für die Entwicklung genutzte Pre-trained Models (vortrainierte Modelle) werden in die regelmäßige Überwachung und Wartung des KI-Systems einbezogen.",
    "staerke": "mittel",
    "begruendung": "A.6.2.3 verlangt die Dokumentation von Design und Entwicklung; die Guidance nennt den verwendeten Lernalgorithmus und Modelltyp, Hardware- und Softwarekomponenten sowie KI-spezifische Sicherheitsbedrohungen wie Data Poisoning, Model Stealing und Model Inversion. Relevant für die Bewertung vortrainierter Modelle, aber entwicklungsbezogen."
   }
  ],
  "A.6.2.4": [
   {
    "ref": "GOVERN 4.3",
    "text": "Organisatorische Praktiken ermöglichen das Testen von KI, die Erkennung von Vorfällen und den Informationsaustausch.",
    "staerke": "stark",
    "begruendung": "A.6.2.4 verlangt definierte und dokumentierte Verifikations- und Validierungsmaßnahmen mit Kriterien für ihre Anwendung; B.6.2.4 nennt Testmethodiken und -werkzeuge, die Auswahl von Testdaten und deren Repräsentativität für die intended domain of use. Das ist die direkte Entsprechung zu enable AI testing."
   },
   {
    "ref": "MAP 2.3",
    "text": "Wissenschaftliche Integrität und TEVV-Aspekte sind identifiziert und dokumentiert, unter anderem zu Versuchsdesign, Datenerhebung und -auswahl (Verfügbarkeit, Repräsentativität, Eignung), Vertrauenswürdigkeit des Systems und Konstruktvalidierung.",
    "staerke": "stark",
    "begruendung": "A.6.2.4 verlangt definierte und dokumentierte Verifikations- und Validierungsmaßnahmen samt Kriterien; B.6.2.4 nennt Testmethoden und -werkzeuge, „selection of test data and their representation of the intended domain of use“ sowie Freigabekriterien. Das ist die zentrale TEVV-Entsprechung."
   },
   {
    "ref": "MEASURE 2.1",
    "text": "Testdatensätze, Kennzahlen und die eingesetzten Werkzeuge für TEVV (Test, Evaluation, Verification, Validation) sind dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.6.2.4 verlangt, Verifizierungs- und Validierungsmaßnahmen zu definieren und zu dokumentieren, ausdrücklich einschließlich Testmethodik und -werkzeugen, der Auswahl der Testdaten und ihrer Repräsentativität für die beabsichtigte Anwendungsdomäne sowie der Freigabekriterien. Das deckt Test-Sets, Metriken und Werkzeuge im Kern ab."
   },
   {
    "ref": "MEASURE 2.3",
    "text": "Leistungs- bzw. Zusicherungskriterien des KI-Systems werden qualitativ oder quantitativ gemessen und unter einsatznahen Bedingungen nachgewiesen; die Messungen sind dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.6.2.4 verlangt dokumentierte Evaluationskriterien einschließlich Zuverlässigkeits- und Safety-Anforderungen mit akzeptablen Fehlerraten sowie operativer Faktoren wie Datenqualität und beabsichtigter Nutzung mit akzeptablen Wertebereichen. Das AI-System ist ausdrücklich gegen diese dokumentierten Kriterien zu evaluieren."
   },
   {
    "ref": "MEASURE 2.5",
    "text": "Vor der Bereitstellung ist nachgewiesen, dass das KI-System valide und zuverlässig ist; Grenzen der Übertragbarkeit über die Entwicklungsbedingungen hinaus sind dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.6.2.4 verlangt definierte V&V-Maßnahmen mit Evaluationskriterien zu Zuverlässigkeit und Safety und schreibt vor, das AI-System gegen diese dokumentierten Kriterien zu evaluieren. Erfüllt es sie nicht, sind Zweckbestimmung, Leistungsanforderungen und Mängelbehandlung neu zu bewerten."
   },
   {
    "ref": "MEASURE 2.6",
    "text": "Das KI-System wird regelmäßig auf die in MAP erfassten Sicherheitsrisiken geprüft; vor Bereitstellung ist nachzuweisen, dass das Restrisiko die Risikotoleranz nicht überschreitet und ein Ausfall sicher erfolgt, auch jenseits der Wissensgrenzen. Sicherheitskennzahlen betreffen Zuverlässigkeit, Robustheit, Echtzeitüberwachung und Reaktionszeiten bei Ausfällen.",
    "staerke": "stark",
    "begruendung": "A.6.2.4 nennt ausdrücklich Zuverlässigkeits- und Safety-Anforderungen einschließlich akzeptabler Fehlerraten als Grundlage des Evaluationsplans und verlangt die Evaluation gegen diese dokumentierten Kriterien. Damit sind Safety-Kriterien normativ im V&V verankert."
   },
   {
    "ref": "MEASURE 2.9",
    "text": "Das KI-Modell wird erläutert, validiert und dokumentiert; die Ausgaben des Systems werden im jeweiligen Kontext – wie in MAP bestimmt – interpretiert und stützen eine verantwortungsvolle Nutzung und Governance.",
    "staerke": "stark",
    "begruendung": "A.6.2.4 fordert dokumentierte Verifizierungs- und Validierungsmaßnahmen samt Kriterien; B.6.2.4 verlangt ausdrücklich Methoden oder Metriken zur Bewertung, ob Beteiligte die Systemausgaben angemessen interpretieren können."
   },
   {
    "ref": "MEASURE 4.1",
    "text": "Messansätze zur Identifikation von KI-Risiken sind auf den jeweiligen Einsatzkontext bezogen und werden unter Einbeziehung von Fachexperten und Endnutzern abgestimmt; die Ansätze sind dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.6.2.4 fordert dokumentierte V&V-Maßnahmen und Kriterien; B.6.2.4 verlangt ausdrücklich die Auswahl von Testdaten und deren Repräsentativität für den vorgesehenen Anwendungsbereich."
   },
   {
    "ref": "MANAGE 1.1",
    "text": "Es wird festgestellt, ob das KI-System seine Zweckbestimmung und die festgelegten Ziele erreicht und ob Entwicklung oder Bereitstellung fortgeführt werden sollen.",
    "staerke": "stark",
    "begruendung": "A.6.2.4 verlangt dokumentierte Verifizierungs- und Validierungsmaßnahmen samt Bewertungskriterien; das KI-System ist gegen diese Kriterien zu bewerten und bei Nichterfüllung sind Zweckbestimmung, Leistungsanforderungen und Defizite neu zu erwägen. Das entspricht der NIST-Feststellung, ob das System seinen Zweck und seine Ziele erreicht."
   },
   {
    "ref": "GOVERN 4.1",
    "text": "Richtlinien und Praktiken fördern kritisches Denken und einen Sicherheitsvorrang bei Konzeption, Entwicklung, Bereitstellung und Nutzung von KI-Systemen, um negative Auswirkungen zu minimieren.",
    "staerke": "mittel",
    "begruendung": "B.6.2.4 verlangt Bewertungskriterien einschließlich reliability and safety requirements sowie acceptable error rates und fordert, bei Nichterreichen die intended use zu überdenken oder die Defizite zu managen. Das ist die kritische Prüfinstanz vor Freigabe."
   },
   {
    "ref": "MAP 2.2",
    "text": "Die Wissensgrenzen des KI-Systems sowie Nutzung und Beaufsichtigung seiner Ausgaben durch Menschen sind dokumentiert. Die Dokumentation reicht aus, damit relevante KI-Akteure informierte Entscheidungen treffen und daraus Maßnahmen ableiten können.",
    "staerke": "mittel",
    "begruendung": "B.6.2.4 verlangt Methoden und Metriken zur Bewertung, ob Entscheidende und Betroffene „can adequately interpret the AI system outputs“. Das trifft die NIST-Forderung nach ausreichender Information für informierte Entscheidungen."
   },
   {
    "ref": "MAP 3.2",
    "text": "Potenzielle Kosten einschließlich nichtmonetärer Kosten aus erwarteten oder eingetretenen Fehlern sowie aus Funktionalität und Vertrauenswürdigkeit des Systems sind – bezogen auf die Risikotoleranz der Organisation – geprüft und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.6.2.4 verlangt akzeptable Fehlerraten, Bewertungskriterien für Zuverlässigkeit und Sicherheit sowie dokumentierte Mechanismen zum Umgang mit schlechter Systemleistung. Das verknüpft Fehlverhalten und Vertrauenswürdigkeit mit definierten Schwellen."
   },
   {
    "ref": "MEASURE 1.1",
    "text": "Messansätze und Kennzahlen für die in MAP erfassten KI-Risiken werden ausgewählt und zuerst auf die wesentlichen Risiken angewendet. Risiken oder Merkmale der Vertrauenswürdigkeit, die nicht gemessen werden oder nicht messbar sind, werden dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.6.2.4 fordert dokumentierte Evaluationskriterien einschließlich akzeptabler Fehlerraten sowie die Dokumentation von Faktoren, die ein Verfehlen eines Mindestleistungsniveaus erklären können. Das deckt den Dokumentationsgedanken teilweise ab, adressiert aber nicht grundsätzlich nicht messbare Risiken."
   },
   {
    "ref": "MEASURE 1.2",
    "text": "Die Eignung der KI-Kennzahlen und die Wirksamkeit bestehender Maßnahmen werden regelmäßig bewertet und fortgeschrieben, einschließlich der Auswertung von Fehlermeldungen und von Auswirkungen auf betroffene Gruppen.",
    "staerke": "mittel",
    "begruendung": "A.6.2.4 verlangt, die Häufigkeit der Evaluation festzulegen, wobei sie sich auf Ergebnisse der AI-System-Folgenabschätzung stützen kann, und bei Nichterfüllung der Kriterien Zweckbestimmung und Leistungsanforderungen zu überdenken. Das entspricht der geforderten regelmäßigen Nachjustierung."
   },
   {
    "ref": "MEASURE 2.13",
    "text": "Die Wirksamkeit der in der Funktion MEASURE eingesetzten TEVV-Kennzahlen und -Prozesse wird bewertet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.6.2.4 fordert dokumentierte V&V-Maßnahmen mit Kriterien für ihre Anwendung; B.6.2.4 verlangt zudem, bei Nichterreichen der Kriterien Zweck, Leistungsanforderungen und Maßnahmen neu zu bewerten."
   },
   {
    "ref": "MEASURE 3.2",
    "text": "Für Konstellationen, in denen KI-Risiken mit verfügbaren Messverfahren schwer zu bewerten sind oder noch keine Kennzahlen vorliegen, werden alternative Ansätze zur Risikoverfolgung erwogen.",
    "staerke": "mittel",
    "begruendung": "B.6.2.4 verlangt, akzeptable Faktoren für das Nichterreichen eines Mindestleistungsniveaus zu benennen und Mechanismen zum Umgang mit dadurch bedingter schlechter Leistung zu dokumentieren."
   },
   {
    "ref": "MEASURE 4.2",
    "text": "Messergebnisse zur Vertrauenswürdigkeit im Einsatzkontext und über den KI-Lebenszyklus werden unter Mitwirkung von Fachexperten und weiteren relevanten KI-Akteuren daraufhin beurteilt, ob das System bestimmungsgemäß und gleichbleibend arbeitet; die Ergebnisse sind dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.6.2.4 verlangt die Bewertung des Systems gegen die dokumentierten Evaluationskriterien einschließlich Zuverlässigkeits-, Sicherheits- und Fehlerratenanforderungen über den Lebenszyklus."
   },
   {
    "ref": "MANAGE 2.2",
    "text": "Mechanismen zur dauerhaften Werterhaltung bereitgestellter KI-Systeme bestehen und werden angewendet.",
    "staerke": "mittel",
    "begruendung": "A.6.2.4 verlangt Bewertungskriterien einschließlich akzeptabler Fehlerraten und die Festlegung der Evaluierungsfrequenz sowie Mechanismen für den Umgang mit schlechter Systemleistung. Sichert die fortlaufende Zielerfüllung, ist aber primär auf Verifizierung und Validierung bezogen."
   },
   {
    "ref": "MANAGE 3.2",
    "text": "Für die Entwicklung genutzte Pre-trained Models (vortrainierte Modelle) werden in die regelmäßige Überwachung und Wartung des KI-Systems einbezogen.",
    "staerke": "mittel",
    "begruendung": "A.6.2.4 verlangt Verifizierungs- und Validierungsmaßnahmen und einen Plan zur Bewertung „the AI system components and the whole AI system“ hinsichtlich Auswirkungsrisiken. Erfasst zugekaufte Modellkomponenten, allerdings primär vor dem Release."
   },
   {
    "ref": "MANAGE 4.2",
    "text": "Messbare Aktivitäten zur kontinuierlichen Verbesserung sind in die Aktualisierung der KI-Systeme eingebunden und umfassen den regelmäßigen Austausch mit interessierten Parteien einschließlich relevanter KI-Akteure.",
    "staerke": "mittel",
    "begruendung": "A.6.2.4 verlangt dokumentierte Bewertungskriterien einschließlich akzeptabler Fehlerraten und die Festlegung der Evaluierungsfrequenz, die sich aus dem Impact Assessment ergeben kann. Liefert die messbaren Kriterien für Verbesserungen an Systemupdates."
   },
   {
    "ref": "MAP 1.5",
    "text": "Die Risikotoleranzen der Organisation sind bestimmt und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "B.6.2.4 verlangt die Festlegung akzeptabler Fehlerraten und akzeptabler Bandbreiten operativer Faktoren sowie den Umgang mit Unterschreitungen. Das ist Toleranz auf Systemebene und ersetzt keine organisationsweite Risikotoleranz."
   },
   {
    "ref": "MEASURE 2.2",
    "text": "Bewertungen unter Beteiligung von Menschen erfüllen die einschlägigen Anforderungen einschließlich des Probandenschutzes und bilden die relevante Population repräsentativ ab.",
    "staerke": "schwach",
    "begruendung": "A.6.2.4 verlangt die Auswahl von Testdaten und deren Repräsentativität für die beabsichtigte Anwendungsdomäne. Das betrifft Datenrepräsentativität, nicht die Repräsentativität einer Stichprobe menschlicher Versuchspersonen, und enthält keinerlei Probandenschutz."
   },
   {
    "ref": "MEASURE 2.7",
    "text": "Security und Resilienz des KI-Systems – wie in MAP erfasst – werden bewertet und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.6.2.4 lässt Testmethoden und Evaluationskriterien offen, sodass Sicherheitstests darunter gefasst werden können. Sicherheits- oder Robustheitstests werden jedoch nirgends ausdrücklich verlangt."
   },
   {
    "ref": "MEASURE 2.11",
    "text": "Fairness und Bias (systematische Verzerrung) – wie in MAP erfasst – werden bewertet und die Ergebnisse dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.6.2.4 verlangt Evaluationskriterien, die sich an den Zielen verantwortlicher Entwicklung (B.6.1.2) orientieren; Fairness wird dadurch nur mittelbar und nur bei entsprechender Zielsetzung geprüft."
   }
  ],
  "A.6.2.5": [
   {
    "ref": "MEASURE 2.5",
    "text": "Vor der Bereitstellung ist nachgewiesen, dass das KI-System valide und zuverlässig ist; Grenzen der Übertragbarkeit über die Entwicklungsbedingungen hinaus sind dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.6.2.5 verlangt einen Deployment-Plan und Freigabekriterien, die vor Release zu erfüllen sind, einschließlich bestandener V&V-Maßnahmen, erreichter Leistungsmetriken sowie Management-Freigaben. Das entspricht dem Nachweis der Einsatzreife vor Deployment."
   },
   {
    "ref": "MANAGE 1.1",
    "text": "Es wird festgestellt, ob das KI-System seine Zweckbestimmung und die festgelegten Ziele erreicht und ob Entwicklung oder Bereitstellung fortgeführt werden sollen.",
    "staerke": "stark",
    "begruendung": "A.6.2.5 fordert einen Deployment-Plan und die Erfüllung festgelegter Anforderungen vor dem Einsatz; die Guidance nennt ausdrücklich Release-Kriterien, zu erreichende Leistungsmetriken sowie Management-Freigaben und Sign-offs. Damit ist die Entscheidung, ob das Deployment fortgesetzt wird, normativ verankert."
   },
   {
    "ref": "GOVERN 2.3",
    "text": "Die oberste Leitung übernimmt die Verantwortung für Entscheidungen über Risiken bei Entwicklung und Bereitstellung von KI-Systemen.",
    "staerke": "mittel",
    "begruendung": "A.6.2.5 verlangt einen Deployment-Plan und die Erfüllung der Anforderungen vor dem Deployment; B.6.2.5 nennt dabei ausdrücklich „management approvals and sign-offs to be obtained“. Das ist die Entsprechung für Leitungsentscheidungen über das Deployment."
   },
   {
    "ref": "MEASURE 2.3",
    "text": "Leistungs- bzw. Zusicherungskriterien des KI-Systems werden qualitativ oder quantitativ gemessen und unter einsatznahen Bedingungen nachgewiesen; die Messungen sind dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.6.2.5 verlangt Freigabekriterien vor Deployment, die zu bestehende V&V-Maßnahmen, zu erreichende Leistungsmetriken und abzuschließende Nutzertests umfassen können. Zudem sind Unterschiede zwischen Entwicklungs- und Deployment-Umgebung im Deployment-Plan zu berücksichtigen."
   },
   {
    "ref": "MEASURE 2.9",
    "text": "Das KI-Modell wird erläutert, validiert und dokumentiert; die Ausgaben des Systems werden im jeweiligen Kontext – wie in MAP bestimmt – interpretiert und stützen eine verantwortungsvolle Nutzung und Governance.",
    "staerke": "schwach",
    "begruendung": "A.6.2.5 verlangt einen Deployment-Plan mit vorab zu erfüllenden Freigabekriterien; B.6.2.5 fordert bestandene V&V-Maßnahmen, adressiert die Modellerklärung selbst aber nicht."
   }
  ],
  "A.6.2.6": [
   {
    "ref": "GOVERN 4.3",
    "text": "Organisatorische Praktiken ermöglichen das Testen von KI, die Erkennung von Vorfällen und den Informationsaustausch.",
    "staerke": "stark",
    "begruendung": "A.6.2.6 verlangt die Festlegung der Betriebselemente einschließlich „system and performance monitoring, repairs, updates and support“; B.6.2.6 fordert Monitoring auf general errors and failures und Support-Prozesse, die regeln, how issues and incidents are reported. Das deckt die Erkennung von Vorfällen im Betrieb ab."
   },
   {
    "ref": "GOVERN 5.2",
    "text": "Mechanismen stellen sicher, dass geprüfte Rückmeldungen relevanter KI-Akteure regelmäßig in Systemdesign und Umsetzung einfließen.",
    "staerke": "stark",
    "begruendung": "B.6.2.6 verlangt Prozesse für Reparaturen und Updates auch als Reaktion auf „externally identified issues (e.g. non-compliance with customer expectations or legal requirement)“ sowie Support-Prozesse, die regeln, wie Issues und Incidents gemeldet werden. Das ist die Einarbeitung von Feedback in die laufende Implementierung."
   },
   {
    "ref": "GOVERN 6.2",
    "text": "Notfallprozesse regeln den Umgang mit Ausfällen oder Vorfällen bei Daten oder KI-Systemen Dritter, die als hochriskant eingestuft sind.",
    "staerke": "stark",
    "begruendung": "A.6.2.6 verlangt die Festlegung der Betriebselemente einschließlich repairs, updates and support; B.6.2.6 stellt klar, dass Support je nach Bezugsweg intern, extern oder beides sein kann und Support-Prozesse Meldewege, SLAs und Metriken berücksichtigen müssen. Das deckt die Reaktion auf Ausfälle bezogener Systeme ab."
   },
   {
    "ref": "MEASURE 2.3",
    "text": "Leistungs- bzw. Zusicherungskriterien des KI-Systems werden qualitativ oder quantitativ gemessen und unter einsatznahen Bedingungen nachgewiesen; die Messungen sind dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.6.2.6 verlangt Leistungskriterien und Metriken für den Betrieb (z. B. F1-Wert nach ISO/IEC TS 4213) und fordert, dass Bewertungsmethodiken die Eigenschaften von Betrieb und Nutzung möglichst genau abbilden. Das entspricht der Forderung nach Nachweis unter deploymentnahen Bedingungen."
   },
   {
    "ref": "MEASURE 2.4",
    "text": "Funktionalität und Verhalten des KI-Systems und seiner Komponenten – wie in MAP bestimmt – werden im Produktivbetrieb überwacht.",
    "staerke": "stark",
    "begruendung": "A.6.2.6 verlangt als Mindestumfang System- und Leistungsüberwachung im laufenden Betrieb, einschließlich der Überwachung auf allgemeine Fehler und Ausfälle sowie darauf, ob das System mit Produktionsdaten erwartungsgemäß arbeitet. Konzept- und Datendrift sowie kontinuierliches Lernen sind ausdrücklich zu überwachen."
   },
   {
    "ref": "MEASURE 2.7",
    "text": "Security und Resilienz des KI-Systems – wie in MAP erfasst – werden bewertet und dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.6.2.6 verlangt, AI-spezifische Informationssicherheitsbedrohungen für die eingesetzten und entwickelten AI-Systeme zu identifizieren, wiederum mit Data Poisoning, Model Stealing und Model Inversion als Beispielen. Damit ist die Sicherheitsbetrachtung auch im Betrieb verankert."
   },
   {
    "ref": "MEASURE 3.1",
    "text": "Vorgehensweisen, Personal und Dokumentation sind vorhanden, um bestehende, unerwartete und neu auftretende KI-Risiken regelmäßig zu erkennen und zu verfolgen, etwa anhand der vorgesehenen und der tatsächlichen Leistung im Einsatz.",
    "staerke": "stark",
    "begruendung": "A.6.2.6 fordert System- und Leistungsüberwachung im Betrieb; B.6.2.6 adressiert ausdrücklich Abweichungen gegenüber Produktionsdaten, Konzept- und Datendrift sowie nicht antizipierte Nutzungsarten."
   },
   {
    "ref": "MEASURE 4.2",
    "text": "Messergebnisse zur Vertrauenswürdigkeit im Einsatzkontext und über den KI-Lebenszyklus werden unter Mitwirkung von Fachexperten und weiteren relevanten KI-Akteuren daraufhin beurteilt, ob das System bestimmungsgemäß und gleichbleibend arbeitet; die Ergebnisse sind dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.6.2.6 fordert System- und Leistungsüberwachung im laufenden Betrieb; B.6.2.6 verlangt zu überwachen, ob das System mit Produktionsdaten wie erwartet arbeitet und seine Entwurfsziele weiterhin erfüllt."
   },
   {
    "ref": "MEASURE 4.3",
    "text": "Messbare Verbesserungen oder Verschlechterungen der Leistung werden anhand von Rückmeldungen relevanter KI-Akteure einschließlich betroffener Gruppen sowie anhand von Felddaten zu kontextrelevanten Risiken und Merkmalen der Vertrauenswürdigkeit ermittelt und dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.6.2.6 fordert fortlaufende Leistungsüberwachung; B.6.2.6 adressiert Leistungsveränderungen durch Konzept- und Datendrift sowie den daraus abgeleiteten Nachtrainingsbedarf."
   },
   {
    "ref": "MANAGE 2.2",
    "text": "Mechanismen zur dauerhaften Werterhaltung bereitgestellter KI-Systeme bestehen und werden angewendet.",
    "staerke": "stark",
    "begruendung": "A.6.2.6 verlangt die Festlegung und Dokumentation der Elemente des laufenden Betriebs, mindestens System- und Leistungsüberwachung, Reparaturen, Updates und Support; die Guidance adressiert ausdrücklich Concept und Data Drift sowie das Nachtrainieren, damit das System weiterhin seine Designziele erfüllt. Das erhält den Nutzen des eingesetzten Systems."
   },
   {
    "ref": "MANAGE 3.2",
    "text": "Für die Entwicklung genutzte Pre-trained Models (vortrainierte Modelle) werden in die regelmäßige Überwachung und Wartung des KI-Systems einbezogen.",
    "staerke": "stark",
    "begruendung": "A.6.2.6 verlangt System- und Leistungsüberwachung, Reparaturen, Updates und Support im laufenden Betrieb; die Guidance adressiert ausdrücklich Leistungsveränderungen durch Concept oder Data Drift und den daraus folgenden Bedarf an Retraining. Genau die von NIST geforderte Einbindung in die reguläre Überwachung und Wartung."
   },
   {
    "ref": "MANAGE 4.1",
    "text": "Pläne zur Überwachung des KI-Systems nach der Inbetriebnahme sind umgesetzt, einschließlich Erfassung und Auswertung von Rückmeldungen der Nutzer und weiterer relevanter KI-Akteure, Beschwerde- und Übersteuerungsmöglichkeiten, Außerbetriebnahme, Vorfallreaktion, Wiederherstellung und Änderungsmanagement.",
    "staerke": "stark",
    "begruendung": "A.6.2.6 verlangt die dokumentierten Elemente des laufenden Betriebs mit mindestens System- und Leistungsüberwachung, Reparaturen, Updates und Support; die Guidance fordert Prozesse für Fehlerbehebung, Update-Verfahren mit Zeitplan und Nutzerinformation, Verfahren für Betriebsänderungen sowie Supportwege für die Meldung von Problemen und Vorfällen."
   },
   {
    "ref": "MANAGE 4.2",
    "text": "Messbare Aktivitäten zur kontinuierlichen Verbesserung sind in die Aktualisierung der KI-Systeme eingebunden und umfassen den regelmäßigen Austausch mit interessierten Parteien einschließlich relevanter KI-Akteure.",
    "staerke": "stark",
    "begruendung": "A.6.2.6-Guidance verlangt Prozesse für Systemupdates einschließlich betroffener Komponenten, Update-Zeitplan und Nutzerinformation zum Update-Inhalt sowie Leistungskriterien mit Metriken und akzeptablen Werten. Damit sind Verbesserungsaktivitäten messbar in die Systemupdates integriert."
   },
   {
    "ref": "GOVERN 1.7",
    "text": "Prozesse und Verfahren regeln die sichere Außerbetriebnahme und Ablösung von KI-Systemen, ohne dabei Risiken zu erhöhen oder die Vertrauenswürdigkeit der Organisation zu mindern.",
    "staerke": "mittel",
    "begruendung": "A.6.2.6 verlangt die Festlegung der Elemente des laufenden Betriebs; B.6.2.6 fordert Prozesse für Updates und Änderungen der Systemoperationen einschließlich communication to users. Das deckt geordnete Änderungen einschließlich Abschaltung von Funktionen teilweise ab."
   },
   {
    "ref": "MAP 5.2",
    "text": "Praktiken und Personal für den regelmäßigen Austausch mit relevanten KI-Akteuren sowie für die Einbindung von Rückmeldungen zu positiven, negativen und unerwarteten Auswirkungen bestehen und sind dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.6.2.6 verlangt Supportprozesse dazu, „how issues and incidents are reported“, und die Prüfung der Angemessenheit, wenn Systeme auf unvorhergesehene Weise genutzt werden. Damit werden unerwartete Auswirkungen aufgegriffen und in den Betrieb zurückgeführt."
   },
   {
    "ref": "MEASURE 2.6",
    "text": "Das KI-System wird regelmäßig auf die in MAP erfassten Sicherheitsrisiken geprüft; vor Bereitstellung ist nachzuweisen, dass das Restrisiko die Risikotoleranz nicht überschreitet und ein Ausfall sicher erfolgt, auch jenseits der Wissensgrenzen. Sicherheitskennzahlen betreffen Zuverlässigkeit, Robustheit, Echtzeitüberwachung und Reaktionszeiten bei Ausfällen.",
    "staerke": "mittel",
    "begruendung": "A.6.2.6 verlangt Prozesse für Reaktion und Behebung von Fehlern und Ausfällen sowie Supportprozesse mit Service-Level-Agreements und Metriken. Das kommt Reaktionszeiten bei Systemausfällen am nächsten, bleibt aber unverbindlich formuliert."
   },
   {
    "ref": "MEASURE 2.13",
    "text": "Die Wirksamkeit der in der Funktion MEASURE eingesetzten TEVV-Kennzahlen und -Prozesse wird bewertet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.6.2.6 verlangt sicherzustellen, dass die zur Evaluation eingesetzten Mittel und Prozesse einschließlich der Auswahl der Evaluationsdaten Vollständigkeit und Zuverlässigkeit der Leistungsbeurteilung verbessern."
   },
   {
    "ref": "MEASURE 3.2",
    "text": "Für Konstellationen, in denen KI-Risiken mit verfügbaren Messverfahren schwer zu bewerten sind oder noch keine Kennzahlen vorliegen, werden alternative Ansätze zur Risikoverfolgung erwogen.",
    "staerke": "mittel",
    "begruendung": "B.6.2.6 fordert zu prüfen, ob erkannte Probleme mit bestehenden Maßnahmen beherrschbar sind, und andernfalls bestehende Maßnahmen zu ändern oder zusätzliche zu definieren."
   },
   {
    "ref": "MEASURE 3.3",
    "text": "Rückmeldeverfahren, über die Endnutzer und betroffene Gruppen Probleme melden und Systemergebnisse beanstanden können, sind eingerichtet und in die Bewertungskennzahlen des KI-Systems eingebunden.",
    "staerke": "mittel",
    "begruendung": "B.6.2.6 verlangt Supportprozesse, die regeln, wie Nutzer Hilfe erreichen, wie Probleme und Vorfälle gemeldet werden sowie welche Service-Level und Metriken dafür gelten."
   },
   {
    "ref": "MEASURE 4.1",
    "text": "Messansätze zur Identifikation von KI-Risiken sind auf den jeweiligen Einsatzkontext bezogen und werden unter Einbeziehung von Fachexperten und Endnutzern abgestimmt; die Ansätze sind dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.6.2.6 verlangt, akzeptable Werte je Metrik unter anderem auf Basis von Empfehlungen von Domänenexperten und der Analyse von Erwartungen interessierter Parteien festzulegen."
   },
   {
    "ref": "MANAGE 2.4",
    "text": "Mechanismen zum Übersteuern, Abschalten oder Deaktivieren von KI-Systemen mit bestimmungswidriger Leistung oder Wirkung bestehen und werden angewendet; die Verantwortlichkeiten dafür sind zugewiesen und bekannt.",
    "staerke": "mittel",
    "begruendung": "A.6.2.6 verlangt definierte Betriebselemente einschließlich Reparaturen und Updates; die Guidance fordert, dass bei Nutzung für nicht vorgesehene oder unerwartete Zwecke die Angemessenheit solcher Nutzungen zu erwägen ist. Führt zu Anpassung oder Außerbetriebnahme, nennt sie aber nicht explizit."
   },
   {
    "ref": "MANAGE 4.3",
    "text": "Vorfälle und Fehler werden relevanten KI-Akteuren einschließlich betroffener Gruppen mitgeteilt. Prozesse zur Verfolgung von Vorfällen und Fehlern, zur Reaktion darauf und zur Wiederherstellung werden befolgt und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.6.2.6-Guidance verlangt Prozesse für Reaktion und Reparatur bei Fehlern und Ausfällen, Kommunikation von Betriebsänderungen an Nutzer sowie Supportprozesse dazu, wie Probleme und Vorfälle gemeldet werden. Operative Grundlage der Vorfallbearbeitung."
   },
   {
    "ref": "MAP 1.4",
    "text": "Der geschäftliche Nutzen bzw. der betriebliche Einsatzkontext ist klar definiert oder – bei der Bewertung bestehender KI-Systeme – erneut bewertet.",
    "staerke": "schwach",
    "begruendung": "B.6.2.6 verlangt, die Angemessenheit zu prüfen, wenn KI-Systeme für andere als die vorgesehenen Zwecke genutzt werden. Das stützt die Neubewertung bestehender Systeme, ohne den Geschäftswert zu adressieren."
   }
  ],
  "A.6.2.7": [
   {
    "ref": "MAP 2.2",
    "text": "Die Wissensgrenzen des KI-Systems sowie Nutzung und Beaufsichtigung seiner Ausgaben durch Menschen sind dokumentiert. Die Dokumentation reicht aus, damit relevante KI-Akteure informierte Entscheidungen treffen und daraus Maßnahmen ableiten können.",
    "staerke": "stark",
    "begruendung": "B.6.2.7 verlangt in der technischen Dokumentation „technical limitations (e.g. acceptable error rates, accuracy, reliability, robustness)“ sowie „monitoring capabilities and functions that allow users or operators to influence the system operation“. Das deckt Systemgrenzen und Eingriffsmöglichkeiten dokumentiert ab."
   },
   {
    "ref": "MEASURE 2.5",
    "text": "Vor der Bereitstellung ist nachgewiesen, dass das KI-System valide und zuverlässig ist; Grenzen der Übertragbarkeit über die Entwicklungsbedingungen hinaus sind dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.6.2.7 verlangt die Dokumentation technischer Annahmen zur Deployment- und Betriebsumgebung sowie technischer Grenzen (akzeptable Fehlerraten, Genauigkeit, Zuverlässigkeit, Robustheit) und der V&V-Aufzeichnungen. Das deckt die Dokumentation der Einsatzgrenzen weitgehend ab."
   },
   {
    "ref": "MEASURE 2.9",
    "text": "Das KI-Modell wird erläutert, validiert und dokumentiert; die Ausgaben des Systems werden im jeweiligen Kontext – wie in MAP bestimmt – interpretiert und stützen eine verantwortungsvolle Nutzung und Governance.",
    "staerke": "stark",
    "begruendung": "A.6.2.7 verlangt technische Dokumentation je Adressatenkreis; B.6.2.7 listet Zweck, technische Grenzen, Designentscheidungen sowie Verifizierungs- und Validierungsnachweise als Inhalte auf."
   },
   {
    "ref": "MANAGE 2.4",
    "text": "Mechanismen zum Übersteuern, Abschalten oder Deaktivieren von KI-Systemen mit bestimmungswidriger Leistung oder Wirkung bestehen und werden angewendet; die Verantwortlichkeiten dafür sind zugewiesen und bekannt.",
    "staerke": "stark",
    "begruendung": "A.6.2.7 verlangt Dokumentation zum verantwortungsvollen Betrieb; die Guidance nennt ausdrücklich Rollback-Plan, „turning off features of the AI system“ sowie die Dokumentation der Rollen des Betriebs- und Verantwortungspersonals speziell für den Umgang mit Systemausfällen. Deckt Mechanismus und Verantwortungszuweisung gemeinsam ab."
   },
   {
    "ref": "GOVERN 1.7",
    "text": "Prozesse und Verfahren regeln die sichere Außerbetriebnahme und Ablösung von KI-Systemen, ohne dabei Risiken zu erhöhen oder die Vertrauenswürdigkeit der Organisation zu mindern.",
    "staerke": "mittel",
    "begruendung": "B.6.2.7 verlangt die Dokumentation eines Plans zum Umgang mit Fehlern und nennt dabei ausdrücklich rollback plan, „turning off features of the AI system“ und plan for notifying customers, users of changes. Das sind die textlich nächsten Elemente einer sicheren Außerbetriebnahme."
   },
   {
    "ref": "GOVERN 4.2",
    "text": "Die Teams dokumentieren Risiken und mögliche Auswirkungen der von ihnen konzipierten, entwickelten, bereitgestellten, bewerteten und genutzten KI-Technologie und kommunizieren diese Auswirkungen auch über das Team hinaus.",
    "staerke": "mittel",
    "begruendung": "A.6.2.7 verlangt die je Interessengruppe erforderliche technische Dokumentation; B.6.2.7 nennt als Elemente management activities (e.g. risk management) und „impact assessment documentation as described in B.5“. Damit werden Risiken und Auswirkungen adressatengerecht dokumentiert."
   },
   {
    "ref": "GOVERN 6.2",
    "text": "Notfallprozesse regeln den Umgang mit Ausfällen oder Vorfällen bei Daten oder KI-Systemen Dritter, die als hochriskant eingestuft sind.",
    "staerke": "mittel",
    "begruendung": "B.6.2.7 verlangt die Dokumentation eines „plan for managing failures“ und nennt rollback plan, „turning off features of the AI system“ und die Benachrichtigung von Kunden und Nutzern. Das adressiert eigene Systemausfälle; Ausfälle in Daten oder Systemen Dritter, auf die GOVERN 6.2 abstellt, sind nicht gesondert geregelt."
   },
   {
    "ref": "MAP 2.3",
    "text": "Wissenschaftliche Integrität und TEVV-Aspekte sind identifiziert und dokumentiert, unter anderem zu Versuchsdesign, Datenerhebung und -auswahl (Verfügbarkeit, Repräsentativität, Eignung), Vertrauenswürdigkeit des Systems und Konstruktvalidierung.",
    "staerke": "mittel",
    "begruendung": "B.6.2.7 nennt als Dokumentationselemente „verification and validation records“, Informationen über die Entwicklungsdaten und „assumptions made and quality measures taken on data quality (e.g. assumed statistical distributions)“. Das sichert die Dokumentationsforderung von MAP 2.3."
   },
   {
    "ref": "MAP 3.3",
    "text": "Der angestrebte Anwendungsbereich ist auf Basis der Systemfähigkeiten, des bestimmten Kontexts und der Kategorisierung des KI-Systems festgelegt und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.6.2.7 verlangt eine allgemeine Systembeschreibung einschließlich beabsichtigtem Zweck sowie technische Annahmen zu Deployment und Betrieb und technische Grenzen. Der Anwendungsbereich wird damit technisch dokumentiert."
   },
   {
    "ref": "MAP 3.5",
    "text": "Prozesse für Human Oversight (menschliche Aufsicht) sind entsprechend den Richtlinien aus der Funktion GOVERN definiert, bewertet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.6.2.7 verlangt die Dokumentation der Rollen des Betriebspersonals und der für die Nutzung verantwortlichen Stellen, insbesondere im Umgang mit Systemausfällen. Das dokumentiert die Aufsichtsverantwortung technisch-operativ."
   },
   {
    "ref": "MAP 4.2",
    "text": "Interne Risikosteuerungsmaßnahmen für die Komponenten des KI-Systems einschließlich der KI-Technologien Dritter sind identifiziert und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.6.2.7 verlangt die Dokumentation der während Entwicklung oder Betrieb ergriffenen Managementaktivitäten einschließlich Risikomanagement sowie der Verifikations- und Validierungsnachweise. Damit werden wirkende Kontrollen technisch dokumentiert."
   },
   {
    "ref": "MEASURE 2.1",
    "text": "Testdatensätze, Kennzahlen und die eingesetzten Werkzeuge für TEVV (Test, Evaluation, Verification, Validation) sind dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.6.2.7 nennt Verifizierungs- und Validierungsaufzeichnungen sowie Angaben zu den bei der Entwicklung verwendeten Daten und getroffenen Qualitätsmaßnahmen als Bestandteile der technischen Dokumentation. Der Fokus liegt jedoch auf der Bereitstellung an interessierte Parteien, nicht auf der TEVV-internen Nachvollziehbarkeit."
   },
   {
    "ref": "MEASURE 2.3",
    "text": "Leistungs- bzw. Zusicherungskriterien des KI-Systems werden qualitativ oder quantitativ gemessen und unter einsatznahen Bedingungen nachgewiesen; die Messungen sind dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.6.2.7 verlangt die Dokumentation technischer Annahmen zu Deployment und Betrieb sowie technischer Grenzen wie akzeptabler Fehlerraten, Genauigkeit, Zuverlässigkeit und Robustheit. Damit ist die Dokumentationspflicht für die Messergebnisse teilweise abgedeckt."
   },
   {
    "ref": "MEASURE 2.4",
    "text": "Funktionalität und Verhalten des KI-Systems und seiner Komponenten – wie in MAP bestimmt – werden im Produktivbetrieb überwacht.",
    "staerke": "mittel",
    "begruendung": "A.6.2.7 verlangt, Prozesse zur Überwachung der Systemgesundheit (Observability) zu dokumentieren sowie festzulegen, welche Ereignisse überwacht und wie Event-Logs priorisiert und ausgewertet werden. Das ergänzt die Überwachung um die Dokumentations- und Auswerteseite."
   },
   {
    "ref": "MEASURE 2.6",
    "text": "Das KI-System wird regelmäßig auf die in MAP erfassten Sicherheitsrisiken geprüft; vor Bereitstellung ist nachzuweisen, dass das Restrisiko die Risikotoleranz nicht überschreitet und ein Ausfall sicher erfolgt, auch jenseits der Wissensgrenzen. Sicherheitskennzahlen betreffen Zuverlässigkeit, Robustheit, Echtzeitüberwachung und Reaktionszeiten bei Ausfällen.",
    "staerke": "mittel",
    "begruendung": "A.6.2.7 verlangt die Dokumentation eines Plans zum Umgang mit Ausfällen, ausdrücklich einschließlich Rollback-Plan und Abschalten von Systemfunktionen. Das ist der einzige konkrete Anknüpfungspunkt für sicheres Ausfallverhalten."
   },
   {
    "ref": "MANAGE 1.4",
    "text": "Negative Restrisiken – die Summe aller nicht geminderten Risiken – gegenüber nachgelagerten Abnehmern des KI-Systems und gegenüber Endnutzern sind dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.6.2.7 verlangt technische Dokumentation je Kategorie interessierter Parteien einschließlich technischer Grenzen (akzeptable Fehlerraten, Robustheit), Risikomanagement-Aktivitäten und Impact-Assessment-Dokumentation. Adressiert Restrisiken aber als Teil der Technikdokumentation, nicht als konsolidierte Restrisikoaussage."
   },
   {
    "ref": "MANAGE 2.3",
    "text": "Für zuvor unbekannte Risiken wird nach deren Erkennung ein festgelegtes Verfahren zur Reaktion und Wiederherstellung befolgt.",
    "staerke": "mittel",
    "begruendung": "A.6.2.7 verlangt Dokumentation zum verantwortungsvollen Betrieb; die Guidance nennt ausdrücklich einen Plan zum Umgang mit Ausfällen einschließlich Rollback-Plan, Abschalten von Funktionen und Verfahren zur Untersuchung und Vermeidung von Fehlern. Nächstliegender Anker für Reaktion und Wiederherstellung, aber nur als Dokumentationsanforderung."
   },
   {
    "ref": "MANAGE 4.3",
    "text": "Vorfälle und Fehler werden relevanten KI-Akteuren einschließlich betroffener Gruppen mitgeteilt. Prozesse zur Verfolgung von Vorfällen und Fehlern, zur Reaktion darauf und zur Wiederherstellung werden befolgt und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.6.2.7-Guidance verlangt einen dokumentierten Plan zum Umgang mit Ausfällen einschließlich Benachrichtigung von Kunden und Nutzern, Angaben zu Systemausfällen und ihrer Minderung sowie Verfahren zur Untersuchung von Fehlern. Verbindet Vorfalldokumentation und Wiederherstellungsplanung."
   },
   {
    "ref": "MAP 1.1",
    "text": "Zweckbestimmung, nutzbringende Anwendungen, kontextspezifische Rechtsvorschriften und Erwartungen sowie die vorgesehene Einsatzumgebung des KI-Systems sind verstanden und dokumentiert. Zu berücksichtigen sind dabei Nutzergruppen, positive wie negative Auswirkungen, Annahmen und Grenzen, Risiken über den KI-Lebenszyklus sowie TEVV (Test, Evaluation, Verification, Validation) und Systemkennzahlen.",
    "staerke": "schwach",
    "begruendung": "B.6.2.7 nennt als Dokumentationselemente „technical assumptions about its deployment and operation“ und „technical limitations (e.g. acceptable error rates, accuracy, reliability, robustness)“. Das betrifft nur den technischen Teilaspekt von Annahmen und Grenzen, nicht das Kontext-Mapping insgesamt."
   },
   {
    "ref": "MEASURE 4.3",
    "text": "Messbare Verbesserungen oder Verschlechterungen der Leistung werden anhand von Rückmeldungen relevanter KI-Akteure einschließlich betroffener Gruppen sowie anhand von Felddaten zu kontextrelevanten Risiken und Merkmalen der Vertrauenswürdigkeit ermittelt und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "B.6.2.7 nennt im Betrieb vorgenommene Systemänderungen und Verifizierungsnachweise als Dokumentationsinhalte und sichert damit nur die Nachvollziehbarkeit der Veränderungen."
   }
  ],
  "A.6.2.8": [
   {
    "ref": "MEASURE 2.4",
    "text": "Funktionalität und Verhalten des KI-Systems und seiner Komponenten – wie in MAP bestimmt – werden im Produktivbetrieb überwacht.",
    "staerke": "stark",
    "begruendung": "A.6.2.8 verlangt Event-Logging mindestens während der Nutzung, um die Funktionalität rückverfolgbar zu machen und Leistung außerhalb der beabsichtigten Betriebsbedingungen zu erkennen. Das deckt die Beobachtung des tatsächlichen Systemverhaltens in Produktion ab."
   },
   {
    "ref": "GOVERN 4.3",
    "text": "Organisatorische Praktiken ermöglichen das Testen von KI, die Erkennung von Vorfällen und den Informationsaustausch.",
    "staerke": "mittel",
    "begruendung": "A.6.2.8 verlangt Event-Logging mindestens im Nutzungsbetrieb; B.6.2.8 nennt als Zweck ausdrücklich die „detection of the AI system's performance outside of the“ intended operating conditions. Das ist die technische Grundlage der Vorfallerkennung und fehlte in der Baseline."
   },
   {
    "ref": "MEASURE 2.6",
    "text": "Das KI-System wird regelmäßig auf die in MAP erfassten Sicherheitsrisiken geprüft; vor Bereitstellung ist nachzuweisen, dass das Restrisiko die Risikotoleranz nicht überschreitet und ein Ausfall sicher erfolgt, auch jenseits der Wissensgrenzen. Sicherheitskennzahlen betreffen Zuverlässigkeit, Robustheit, Echtzeitüberwachung und Reaktionszeiten bei Ausfällen.",
    "staerke": "mittel",
    "begruendung": "A.6.2.8 verlangt Event-Logs, die ein Arbeiten außerhalb der beabsichtigten Betriebsbedingungen erkennbar machen, einschließlich Ausgaben außerhalb des vorgesehenen Bereichs. Das adressiert das Erkennen des Überschreitens der Wissensgrenzen, nicht die Reaktion darauf."
   },
   {
    "ref": "MEASURE 3.1",
    "text": "Vorgehensweisen, Personal und Dokumentation sind vorhanden, um bestehende, unerwartete und neu auftretende KI-Risiken regelmäßig zu erkennen und zu verfolgen, etwa anhand der vorgesehenen und der tatsächlichen Leistung im Einsatz.",
    "staerke": "mittel",
    "begruendung": "A.6.2.8 verlangt Ereignisprotokollierung mindestens im Nutzungsbetrieb; B.6.2.8 nennt die Erkennung von Leistung außerhalb der vorgesehenen Betriebsbedingungen als ausdrücklichen Zweck."
   },
   {
    "ref": "MANAGE 4.1",
    "text": "Pläne zur Überwachung des KI-Systems nach der Inbetriebnahme sind umgesetzt, einschließlich Erfassung und Auswertung von Rückmeldungen der Nutzer und weiterer relevanter KI-Akteure, Beschwerde- und Übersteuerungsmöglichkeiten, Außerbetriebnahme, Vorfallreaktion, Wiederherstellung und Änderungsmanagement.",
    "staerke": "mittel",
    "begruendung": "A.6.2.8 verlangt Event-Logging mindestens während der Nutzung; die Guidance nennt Nachvollziehbarkeit des bestimmungsgemäßen Betriebs und die Erkennung von Leistung außerhalb der vorgesehenen Betriebsbedingungen. Technische Grundlage des Post-Deployment-Monitorings."
   },
   {
    "ref": "MANAGE 4.3",
    "text": "Vorfälle und Fehler werden relevanten KI-Akteuren einschließlich betroffener Gruppen mitgeteilt. Prozesse zur Verfolgung von Vorfällen und Fehlern, zur Reaktion darauf und zur Wiederherstellung werden befolgt und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.6.2.8 verlangt Event-Logging mindestens während der Nutzung zur Nachvollziehbarkeit und zur Erkennung von Leistung außerhalb der vorgesehenen Betriebsbedingungen, mit definierten Aufbewahrungsfristen. Stützt die Nachverfolgung und Dokumentation von Vorfällen und Fehlern."
   },
   {
    "ref": "MEASURE 3.2",
    "text": "Für Konstellationen, in denen KI-Risiken mit verfügbaren Messverfahren schwer zu bewerten sind oder noch keine Kennzahlen vorliegen, werden alternative Ansätze zur Risikoverfolgung erwogen.",
    "staerke": "schwach",
    "begruendung": "A.6.2.8 verlangt Ereignisprotokolle einschließlich Ausgaben außerhalb des vorgesehenen Betriebsbereichs und liefert damit qualitative Beobachtungsdaten, wo Metriken fehlen, ohne dies als Ersatzverfahren auszuweisen."
   }
  ],
  "A.7.2": [
   {
    "ref": "MAP 2.3",
    "text": "Wissenschaftliche Integrität und TEVV-Aspekte sind identifiziert und dokumentiert, unter anderem zu Versuchsdesign, Datenerhebung und -auswahl (Verfügbarkeit, Repräsentativität, Eignung), Vertrauenswürdigkeit des Systems und Konstruktvalidierung.",
    "staerke": "mittel",
    "begruendung": "B.7.2 verlangt Datenmanagementprozesse und nennt „representativeness of training data compared to operational domain of use“ sowie „accuracy and integrity of the data“. Das liefert den Prozessrahmen, nicht die Prüfmethodik."
   },
   {
    "ref": "MEASURE 2.7",
    "text": "Security und Resilienz des KI-Systems – wie in MAP erfasst – werden bewertet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.7.2 verlangt Datenmanagementprozesse, die Datenschutz- und Sicherheitsimplikationen sowie Sicherheits- und Safety-Bedrohungen aus datenabhängiger AI-Entwicklung einbeziehen. Das deckt den datenseitigen Teil der Angriffsfläche ab."
   },
   {
    "ref": "MEASURE 2.10",
    "text": "Das Datenschutzrisiko des KI-Systems – wie in MAP erfasst – wird geprüft und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.7.2 verlangt dokumentierte Datenmanagementprozesse; B.7.2 führt „privacy and security implications due to the use of data, some of which can be sensitive in nature“ als Pflichtthema."
   },
   {
    "ref": "MANAGE 2.2",
    "text": "Mechanismen zur dauerhaften Werterhaltung bereitgestellter KI-Systeme bestehen und werden angewendet.",
    "staerke": "mittel",
    "begruendung": "A.7.2 verlangt definierte Datenmanagementprozesse für Entwicklung und Verbesserung („enhancement“) des KI-Systems; die Guidance nennt ausdrücklich die Repräsentativität der Trainingsdaten gegenüber der operativen Einsatzdomäne. Erhält die Leistungsfähigkeit datenseitig."
   },
   {
    "ref": "MEASURE 2.2",
    "text": "Bewertungen unter Beteiligung von Menschen erfüllen die einschlägigen Anforderungen einschließlich des Probandenschutzes und bilden die relevante Population repräsentativ ab.",
    "staerke": "schwach",
    "begruendung": "A.7.2 nennt als Bestandteil des Datenmanagements Datenschutz- und Sicherheitsimplikationen sowie die Repräsentativität von Trainingsdaten gegenüber der operativen Anwendungsdomäne. Ein Bezug zu Evaluationen mit menschlichen Versuchspersonen fehlt."
   },
   {
    "ref": "MEASURE 2.5",
    "text": "Vor der Bereitstellung ist nachgewiesen, dass das KI-System valide und zuverlässig ist; Grenzen der Übertragbarkeit über die Entwicklungsbedingungen hinaus sind dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.7.2 nennt die Repräsentativität der Trainingsdaten gegenüber der operativen Anwendungsdomäne als Gegenstand des Datenmanagements. Das ist eine Vorbedingung für Generalisierbarkeit, aber kein Nachweisverfahren."
   },
   {
    "ref": "MEASURE 2.8",
    "text": "Risiken in Bezug auf Transparenz und Rechenschaftspflicht – wie in MAP erfasst – werden geprüft und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "B.7.2 nennt „transparency and explainability aspects including data provenance“ als Gegenstand des Datenmanagements; das erfasst jedoch nur die datenseitige Teilmenge der Transparenzrisiken."
   }
  ],
  "A.7.3": [
   {
    "ref": "MAP 2.3",
    "text": "Wissenschaftliche Integrität und TEVV-Aspekte sind identifiziert und dokumentiert, unter anderem zu Versuchsdesign, Datenerhebung und -auswahl (Verfügbarkeit, Repräsentativität, Eignung), Vertrauenswürdigkeit des Systems und Konstruktvalidierung.",
    "staerke": "stark",
    "begruendung": "B.7.3 verlangt die Dokumentation von Datenkategorien, Datenmenge, Datenquellen, Quellencharakteristik sowie „data subject demographics and characteristics (e.g. known or potential biases or other systematic errors)“. Das deckt Datenerhebung und -auswahl einschließlich Verfügbarkeit und Repräsentativität ab."
   },
   {
    "ref": "MAP 4.1",
    "text": "Vorgehensweisen zur Erfassung technischer und rechtlicher Risiken der Systemkomponenten – einschließlich der Nutzung von Daten oder Software Dritter sowie möglicher Verletzungen von Rechten des geistigen Eigentums oder sonstiger Rechte Dritter – bestehen, werden angewendet und dokumentiert.",
    "staerke": "stark",
    "begruendung": "B.7.3 verlangt die Dokumentation von „data rights (e.g. PII, copyright)“ sowie „prior handling of the data (e.g. previous uses, conformity with privacy and security requirements)“ und der Datenherkunft. Das ist der einzige Ort, an dem ISO 42001 Schutzrechte Dritter an Daten ausdrücklich adressiert."
   },
   {
    "ref": "GOVERN 6.1",
    "text": "Richtlinien und Verfahren adressieren KI-Risiken im Zusammenhang mit Dritten, einschließlich der Verletzung von Rechten des geistigen Eigentums oder sonstiger Rechte Dritter.",
    "staerke": "mittel",
    "begruendung": "A.7.3 verlangt, Details zu Beschaffung und Auswahl der genutzten Daten zu bestimmen und zu dokumentieren; B.7.3 nennt dabei ausdrücklich data rights (e.g. PII, copyright), prior handling of the data und provenance of the data. Das ist der einzige textliche Anknüpfungspunkt für Rechte Dritter."
   },
   {
    "ref": "MEASURE 2.10",
    "text": "Das Datenschutzrisiko des KI-Systems – wie in MAP erfasst – wird geprüft und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.7.3 verlangt Dokumentation von Datenbeschaffung und -auswahl; B.7.3 nennt Datenrechte (PII, Urheberrecht) und die Konformität der Vorverwendung mit Datenschutzanforderungen als Prüfpunkte."
   },
   {
    "ref": "MANAGE 3.1",
    "text": "KI-Risiken und -Nutzen aus Ressourcen Dritter werden regelmäßig überwacht; Risikosteuerungsmaßnahmen werden angewendet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.7.3 verlangt die Dokumentation von Details zu Beschaffung und Auswahl der Daten; die Guidance nennt ausdrücklich Datenquellen (gekauft, geteilt, offen, synthetisch), vorherige Handhabung, Datenrechte und Provenienz. Deckt die Datenkomponente von Drittressourcen ab."
   },
   {
    "ref": "MEASURE 2.2",
    "text": "Bewertungen unter Beteiligung von Menschen erfüllen die einschlägigen Anforderungen einschließlich des Probandenschutzes und bilden die relevante Population repräsentativ ab.",
    "staerke": "schwach",
    "begruendung": "A.7.3 verlangt die Dokumentation von Demografie und Merkmalen der Datensubjekte, von Datenrechten (z. B. PII) sowie der bisherigen Handhabung der Daten einschließlich Konformität mit Datenschutzanforderungen. Das berührt Probandenrechte nur über den Umweg der Datenbeschaffung."
   },
   {
    "ref": "MEASURE 2.11",
    "text": "Fairness und Bias (systematische Verzerrung) – wie in MAP erfasst – werden bewertet und die Ergebnisse dokumentiert.",
    "staerke": "schwach",
    "begruendung": "B.7.3 nennt Demografie und Merkmale der Datensubjekte einschließlich bekannter oder potenzieller Verzerrungen als zu dokumentierendes Beschaffungsdetail, ohne eine Bias-Messung vorzuschreiben."
   }
  ],
  "A.7.4": [
   {
    "ref": "MAP 2.3",
    "text": "Wissenschaftliche Integrität und TEVV-Aspekte sind identifiziert und dokumentiert, unter anderem zu Versuchsdesign, Datenerhebung und -auswahl (Verfügbarkeit, Repräsentativität, Eignung), Vertrauenswürdigkeit des Systems und Konstruktvalidierung.",
    "staerke": "stark",
    "begruendung": "B.7.4 verlangt, die Qualität von Trainings-, Validierungs-, Test- und Produktionsdaten zu definieren, zu messen und zu verbessern und die Eignung für den beabsichtigten Zweck sicherzustellen. Damit sind Eignung, Repräsentativität und Bias-Wirkung auf Leistung und Fairness erfasst."
   },
   {
    "ref": "MEASURE 2.11",
    "text": "Fairness und Bias (systematische Verzerrung) – wie in MAP erfasst – werden bewertet und die Ergebnisse dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.7.4 verlangt definierte Datenqualitätsanforderungen; B.7.4 fordert ausdrücklich, die Wirkung von Bias auf Systemleistung und Fairness zu berücksichtigen und Modell oder Daten entsprechend anzupassen."
   },
   {
    "ref": "MEASURE 2.3",
    "text": "Leistungs- bzw. Zusicherungskriterien des KI-Systems werden qualitativ oder quantitativ gemessen und unter einsatznahen Bedingungen nachgewiesen; die Messungen sind dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.7.4 verlangt definierte Datenqualitätsanforderungen, da die Datenqualität die Validität der Systemausgaben erheblich beeinflusst. Das ist eine Voraussetzung belastbarer Leistungsmessung, aber kein Messverfahren."
   }
  ],
  "A.7.5": [
   {
    "ref": "GOVERN 6.1",
    "text": "Richtlinien und Verfahren adressieren KI-Risiken im Zusammenhang mit Dritten, einschließlich der Verletzung von Rechten des geistigen Eigentums oder sonstiger Rechte Dritter.",
    "staerke": "mittel",
    "begruendung": "A.7.5 verlangt einen dokumentierten Prozess zur Erfassung der Datenprovenienz über den Lebenszyklus; B.7.5 verlangt zu erwägen, ob Maßnahmen zur Verifikation der Provenienz erforderlich sind. Das stützt die Prüfung fremder Rechtspositionen an Daten."
   },
   {
    "ref": "MAP 2.3",
    "text": "Wissenschaftliche Integrität und TEVV-Aspekte sind identifiziert und dokumentiert, unter anderem zu Versuchsdesign, Datenerhebung und -auswahl (Verfügbarkeit, Repräsentativität, Eignung), Vertrauenswürdigkeit des Systems und Konstruktvalidierung.",
    "staerke": "mittel",
    "begruendung": "A.7.5 verlangt einen dokumentierten Prozess zur Aufzeichnung der Datenprovenienz über die Lebenszyklen von Daten und System. Nachvollziehbare Datenherkunft ist Voraussetzung wissenschaftlicher Integrität, deckt sie aber nicht vollständig ab."
   },
   {
    "ref": "MAP 4.1",
    "text": "Vorgehensweisen zur Erfassung technischer und rechtlicher Risiken der Systemkomponenten – einschließlich der Nutzung von Daten oder Software Dritter sowie möglicher Verletzungen von Rechten des geistigen Eigentums oder sonstiger Rechte Dritter – bestehen, werden angewendet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.7.5 verlangt einen dokumentierten Prozess zur Aufzeichnung der Datenprovenienz; B.7.5 empfiehlt zu prüfen, ob Maßnahmen zur Verifikation der Herkunft erforderlich sind. Ohne belastbare Provenienz lassen sich IP-Ansprüchen Dritter nicht begegnen."
   },
   {
    "ref": "MANAGE 3.2",
    "text": "Für die Entwicklung genutzte Pre-trained Models (vortrainierte Modelle) werden in die regelmäßige Überwachung und Wartung des KI-Systems einbezogen.",
    "staerke": "mittel",
    "begruendung": "A.7.5 verlangt einen dokumentierten Prozess zur Aufzeichnung der Provenienz der verwendeten Daten über deren Lebenszyklus und den des KI-Systems, inklusive Prüfung, ob Verifizierungsmaßnahmen zur Herkunft erforderlich sind. Erfasst die Datenherkunft, nicht die Modellherkunft."
   },
   {
    "ref": "MEASURE 2.9",
    "text": "Das KI-Modell wird erläutert, validiert und dokumentiert; die Ausgaben des Systems werden im jeweiligen Kontext – wie in MAP bestimmt – interpretiert und stützen eine verantwortungsvolle Nutzung und Governance.",
    "staerke": "schwach",
    "begruendung": "A.7.5 fordert einen Prozess zur Aufzeichnung der Datenherkunft und liefert damit nur einen Baustein der Nachvollziehbarkeit, keine Modellerklärung oder Ausgabeinterpretation."
   }
  ],
  "A.7.6": [
   {
    "ref": "MAP 2.3",
    "text": "Wissenschaftliche Integrität und TEVV-Aspekte sind identifiziert und dokumentiert, unter anderem zu Versuchsdesign, Datenerhebung und -auswahl (Verfügbarkeit, Repräsentativität, Eignung), Vertrauenswürdigkeit des Systems und Konstruktvalidierung.",
    "staerke": "mittel",
    "begruendung": "B.7.6 verlangt dokumentierte Kriterien für die Auswahl der Datenaufbereitungsmethoden und nennt statistische Exploration, Bereinigung, Imputation, Normalisierung und Kodierung. Das entspricht dem methodischen Teil des „experimental design“."
   }
  ],
  "A.8.2": [
   {
    "ref": "MAP 2.2",
    "text": "Die Wissensgrenzen des KI-Systems sowie Nutzung und Beaufsichtigung seiner Ausgaben durch Menschen sind dokumentiert. Die Dokumentation reicht aus, damit relevante KI-Akteure informierte Entscheidungen treffen und daraus Maßnahmen ableiten können.",
    "staerke": "stark",
    "begruendung": "B.8.2 verlangt Informationen an Nutzende zu „how and when to override the system“, „needs for human oversight“, Genauigkeit und Leistung sowie Grenzen des Systems. Genau das fordert MAP 2.2 für die Nutzung und Beaufsichtigung der Systemausgaben."
   },
   {
    "ref": "MEASURE 2.9",
    "text": "Das KI-Modell wird erläutert, validiert und dokumentiert; die Ausgaben des Systems werden im jeweiligen Kontext – wie in MAP bestimmt – interpretiert und stützen eine verantwortungsvolle Nutzung und Governance.",
    "staerke": "stark",
    "begruendung": "A.8.2 fordert die notwendigen Informationen für Nutzer; B.8.2 nennt Zweck, Funktionsweise, Genauigkeits- und Leistungsangaben sowie Übersteuerungsmöglichkeiten und deckt damit die kontextbezogene Interpretation der Ausgaben ab."
   },
   {
    "ref": "MANAGE 1.4",
    "text": "Negative Restrisiken – die Summe aller nicht geminderten Risiken – gegenüber nachgelagerten Abnehmern des KI-Systems und gegenüber Endnutzern sind dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.8.2 verlangt die Bereitstellung der notwendigen Informationen an Nutzer; die Guidance nennt ausdrücklich technische Grenzen, Angaben zu Genauigkeit und Leistung sowie „relevant information from the impact assessment, including potential benefits and harms“. Damit sind Restrisiken gegenüber Endnutzern offenzulegen."
   },
   {
    "ref": "GOVERN 3.2",
    "text": "Richtlinien und Verfahren definieren und unterscheiden Rollen und Verantwortlichkeiten für das Zusammenwirken von Mensch und KI sowie für die Aufsicht über KI-Systeme.",
    "staerke": "mittel",
    "begruendung": "B.8.2 verlangt, Nutzer u.a. darüber zu informieren, „how and when to override the system“ und needs for human oversight. Das adressiert die Rollenklarheit auf der Nutzungsseite."
   },
   {
    "ref": "MAP 3.5",
    "text": "Prozesse für Human Oversight (menschliche Aufsicht) sind entsprechend den Richtlinien aus der Funktion GOVERN definiert, bewertet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.8.2 verlangt Angaben zu „how and when to override the system“ und „needs for human oversight“ gegenüber den Nutzenden. Das macht die Aufsichtsprozesse für die ausführende Ebene wirksam."
   },
   {
    "ref": "MEASURE 2.5",
    "text": "Vor der Bereitstellung ist nachgewiesen, dass das KI-System valide und zuverlässig ist; Grenzen der Übertragbarkeit über die Entwicklungsbedingungen hinaus sind dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.8.2 verlangt, Nutzenden Informationen zu Zweck, technischen Voraussetzungen und Grenzen des Systems bereitzustellen. Die Grenzen werden adressiert, jedoch aus Nutzersicht und nicht als Nachweis der Generalisierbarkeit."
   },
   {
    "ref": "MEASURE 3.3",
    "text": "Rückmeldeverfahren, über die Endnutzer und betroffene Gruppen Probleme melden und Systemergebnisse beanstanden können, sind eingerichtet und in die Bewertungskennzahlen des KI-Systems eingebunden.",
    "staerke": "mittel",
    "begruendung": "A.8.2 fordert die notwendigen Nutzerinformationen; B.8.2 nennt Kontaktinformationen sowie Angaben dazu, wie und wann das System übersteuert werden kann, als bereitzustellende Inhalte."
   },
   {
    "ref": "MANAGE 2.4",
    "text": "Mechanismen zum Übersteuern, Abschalten oder Deaktivieren von KI-Systemen mit bestimmungswidriger Leistung oder Wirkung bestehen und werden angewendet; die Verantwortlichkeiten dafür sind zugewiesen und bekannt.",
    "staerke": "mittel",
    "begruendung": "A.8.2 verlangt die notwendigen Informationen an Nutzer; die Guidance nennt ausdrücklich „how and when to override the system“ sowie den Bedarf menschlicher Aufsicht. Stellt die Übersteuerungsfähigkeit auf Nutzerseite sicher."
   },
   {
    "ref": "GOVERN 4.3",
    "text": "Organisatorische Praktiken ermöglichen das Testen von KI, die Erkennung von Vorfällen und den Informationsaustausch.",
    "staerke": "schwach",
    "begruendung": "A.8.2 verlangt, Nutzern die notwendigen Systeminformationen bereitzustellen. Das berührt den Teilaspekt „information sharing“ nur gegenüber einer Adressatengruppe und deckt weder Testpraktiken noch Vorfallerkennung ab; die tragenden Entsprechungen sind A.8.3 und A.8.4."
   },
   {
    "ref": "MAP 3.1",
    "text": "Der potenzielle Nutzen der vorgesehenen Funktionalität und Leistung des KI-Systems ist geprüft und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "B.8.2 verlangt die Weitergabe „relevant information from the impact assessment, including potential benefits and harms“ an Nutzende. Das betrifft die Kommunikation des Nutzens, nicht dessen Ermittlung."
   },
   {
    "ref": "MAP 3.4",
    "text": "Prozesse zur Fachkunde von Bedienern und Fachanwendern hinsichtlich Leistung und Vertrauenswürdigkeit des KI-Systems sowie einschlägige technische Normen und Zertifizierungen sind definiert, bewertet und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "B.8.2 nennt „educational materials for system use“ als eine den Nutzenden bereitzustellende Information. Das ist ein Hilfsmittel, aber kein Qualifizierungsprozess."
   },
   {
    "ref": "MEASURE 4.2",
    "text": "Messergebnisse zur Vertrauenswürdigkeit im Einsatzkontext und über den KI-Lebenszyklus werden unter Mitwirkung von Fachexperten und weiteren relevanten KI-Akteuren daraufhin beurteilt, ob das System bestimmungsgemäß und gleichbleibend arbeitet; die Ergebnisse sind dokumentiert.",
    "staerke": "schwach",
    "begruendung": "B.8.2 nennt Angaben zu Genauigkeit und Leistung als Nutzerinformation; das betrifft die Weitergabe der Ergebnisse, nicht deren Validierung."
   }
  ],
  "A.8.3": [
   {
    "ref": "GOVERN 4.3",
    "text": "Organisatorische Praktiken ermöglichen das Testen von KI, die Erkennung von Vorfällen und den Informationsaustausch.",
    "staerke": "stark",
    "begruendung": "A.8.3 verlangt, interested parties Möglichkeiten zur Meldung nachteiliger Auswirkungen bereitzustellen; B.8.3 nennt ausdrücklich externe Parteien und Beispiele wie unfairness. Das erschließt Vorfälle, die internes Monitoring nicht erfasst."
   },
   {
    "ref": "GOVERN 5.1",
    "text": "Richtlinien und Praktiken stellen sicher, dass Rückmeldungen von Beteiligten außerhalb des entwickelnden oder bereitstellenden Teams zu möglichen individuellen und gesellschaftlichen Auswirkungen erhoben, bewertet, priorisiert und eingebunden werden.",
    "staerke": "stark",
    "begruendung": "A.8.3 verlangt, Fähigkeiten bereitzustellen, mit denen interested parties nachteilige Auswirkungen des AI-Systems melden können; B.8.3 adressiert ausdrücklich Nutzer und andere externe Parteien. Das ist der zentrale Rückkanal von außen."
   },
   {
    "ref": "MAP 5.2",
    "text": "Praktiken und Personal für den regelmäßigen Austausch mit relevanten KI-Akteuren sowie für die Einbindung von Rückmeldungen zu positiven, negativen und unerwarteten Auswirkungen bestehen und sind dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.8.3 verlangt, Fähigkeiten bereitzustellen, mit denen interessierte Parteien nachteilige Auswirkungen des KI-Systems melden können; B.8.3 stellt klar, dass dies zusätzlich zum internen Monitoring gilt und auch Unfairness umfasst. Das ist die zentrale Entsprechung für die Aufnahme externen Feedbacks."
   },
   {
    "ref": "MEASURE 3.3",
    "text": "Rückmeldeverfahren, über die Endnutzer und betroffene Gruppen Probleme melden und Systemergebnisse beanstanden können, sind eingerichtet und in die Bewertungskennzahlen des KI-Systems eingebunden.",
    "staerke": "stark",
    "begruendung": "A.8.3 verpflichtet die Organisation, interessierten Parteien Möglichkeiten zur Meldung nachteiliger Auswirkungen bereitzustellen; B.8.3 nennt ausdrücklich Nutzer und externe Dritte sowie Unfairness als Meldegegenstand."
   },
   {
    "ref": "MANAGE 4.1",
    "text": "Pläne zur Überwachung des KI-Systems nach der Inbetriebnahme sind umgesetzt, einschließlich Erfassung und Auswertung von Rückmeldungen der Nutzer und weiterer relevanter KI-Akteure, Beschwerde- und Übersteuerungsmöglichkeiten, Außerbetriebnahme, Vorfallreaktion, Wiederherstellung und Änderungsmanagement.",
    "staerke": "stark",
    "begruendung": "A.8.3 verlangt, Fähigkeiten bereitzustellen, mit denen interessierte Parteien nachteilige Auswirkungen des Systems melden können; die Guidance stellt dies ausdrücklich neben die Betriebsüberwachung. Das ist der Mechanismus zur Erfassung von Rückmeldungen von Nutzern und anderen KI-Akteuren."
   },
   {
    "ref": "GOVERN 5.2",
    "text": "Mechanismen stellen sicher, dass geprüfte Rückmeldungen relevanter KI-Akteure regelmäßig in Systemdesign und Umsetzung einfließen.",
    "staerke": "mittel",
    "begruendung": "A.8.3 verlangt Meldemöglichkeiten für nachteilige Auswirkungen durch interested parties. Damit ist die Erfassungsseite des Feedbacks normiert, nicht dessen Einarbeitung in Design und Implementierung."
   },
   {
    "ref": "MAP 5.1",
    "text": "Eintrittswahrscheinlichkeit und Ausmaß jeder erkannten Auswirkung – sowohl nützlich als auch schädlich – sind identifiziert und dokumentiert, gestützt auf die vorgesehene Nutzung, Erfahrungen mit KI-Systemen in vergleichbaren Kontexten, öffentliche Vorfallmeldungen, Rückmeldungen von Beteiligten außerhalb des entwickelnden oder bereitstellenden Teams sowie weitere Daten.",
    "staerke": "mittel",
    "begruendung": "A.8.3 verlangt Meldemöglichkeiten für interessierte Parteien, um nachteilige Auswirkungen des KI-Systems zu melden; B.8.3 nennt ausdrücklich externe Parteien. Das ist die ISO-Entsprechung zu „feedback from those external to the team“."
   },
   {
    "ref": "MANAGE 4.3",
    "text": "Vorfälle und Fehler werden relevanten KI-Akteuren einschließlich betroffener Gruppen mitgeteilt. Prozesse zur Verfolgung von Vorfällen und Fehlern, zur Reaktion darauf und zur Wiederherstellung werden befolgt und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.8.3 verlangt Fähigkeiten für interessierte Parteien, nachteilige Auswirkungen (z. B. Unfairness) zu melden. Bildet den eingehenden Kanal, über den Vorfälle und Fehler betroffener Gruppen erfasst werden."
   },
   {
    "ref": "MEASURE 4.2",
    "text": "Messergebnisse zur Vertrauenswürdigkeit im Einsatzkontext und über den KI-Lebenszyklus werden unter Mitwirkung von Fachexperten und weiteren relevanten KI-Akteuren daraufhin beurteilt, ob das System bestimmungsgemäß und gleichbleibend arbeitet; die Ergebnisse sind dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.8.3 eröffnet Meldewege für nachteilige Auswirkungen und liefert damit Feldrückmeldungen, ohne diese als Eingangsgröße der Ergebnisvalidierung vorzuschreiben."
   },
   {
    "ref": "MEASURE 4.3",
    "text": "Messbare Verbesserungen oder Verschlechterungen der Leistung werden anhand von Rückmeldungen relevanter KI-Akteure einschließlich betroffener Gruppen sowie anhand von Felddaten zu kontextrelevanten Risiken und Merkmalen der Vertrauenswürdigkeit ermittelt und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.8.3 stellt Meldewege für nachteilige Auswirkungen bereit und liefert so Felddaten von Betroffenen, ohne deren Auswertung als Leistungsindikator zu verankern."
   }
  ],
  "A.8.4": [
   {
    "ref": "GOVERN 4.3",
    "text": "Organisatorische Praktiken ermöglichen das Testen von KI, die Erkennung von Vorfällen und den Informationsaustausch.",
    "staerke": "stark",
    "begruendung": "A.8.4 verlangt einen dokumentierten Plan zur Kommunikation von Incidents an die Nutzer; B.8.4 nennt zu regelnde Punkte wie Incident-Typen, Meldefristen, zu informierende Behörden und erforderliche Details. Das ist die Entsprechung zu identification of incidents und information sharing."
   },
   {
    "ref": "MANAGE 4.3",
    "text": "Vorfälle und Fehler werden relevanten KI-Akteuren einschließlich betroffener Gruppen mitgeteilt. Prozesse zur Verfolgung von Vorfällen und Fehlern, zur Reaktion darauf und zur Wiederherstellung werden befolgt und dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.8.4 verlangt einen dokumentierten Plan zur Kommunikation von Vorfällen an die Nutzer des KI-Systems; die Guidance fordert die Kenntnis der Meldepflichten nach Art des Vorfalls, Zeitrahmen, zu unterrichtende Behörden und erforderliche Detailtiefe. Kern der NIST-Forderung nach Vorfallkommunikation."
   },
   {
    "ref": "GOVERN 6.2",
    "text": "Notfallprozesse regeln den Umgang mit Ausfällen oder Vorfällen bei Daten oder KI-Systemen Dritter, die als hochriskant eingestuft sind.",
    "staerke": "mittel",
    "begruendung": "A.8.4 verlangt einen dokumentierten Plan zur Kommunikation von Incidents an die Nutzer; B.8.4 erlaubt die Integration in das allgemeine Incident-Management, mahnt aber AI-spezifische Besonderheiten an. Das deckt die Kommunikationsseite eines Drittparteivorfalls ab."
   },
   {
    "ref": "MEASURE 2.4",
    "text": "Funktionalität und Verhalten des KI-Systems und seiner Komponenten – wie in MAP bestimmt – werden im Produktivbetrieb überwacht.",
    "staerke": "schwach",
    "begruendung": "A.8.4 verlangt einen dokumentierten Plan zur Kommunikation von Vorfällen an Nutzende. Das setzt nach einem erkannten Ereignis an und ist kein Monitoring im Sinne der Subkategorie."
   },
   {
    "ref": "MEASURE 3.3",
    "text": "Rückmeldeverfahren, über die Endnutzer und betroffene Gruppen Probleme melden und Systemergebnisse beanstanden können, sind eingerichtet und in die Bewertungskennzahlen des KI-Systems eingebunden.",
    "staerke": "schwach",
    "begruendung": "A.8.4 regelt die Kommunikation von Vorfällen an Nutzer und damit die ausgehende Richtung; ein Rückkanal für Betroffene wird dadurch nicht geschaffen."
   }
  ],
  "A.8.5": [
   {
    "ref": "GOVERN 1.1",
    "text": "Rechtliche und regulatorische Anforderungen an KI sind verstanden, werden gesteuert und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.8.5 verlangt, die Berichtspflichten gegenüber interested parties zu bestimmen und zu dokumentieren; B.8.5 stellt klar, dass Jurisdiktionen die Weitergabe von Systeminformationen an Regulatoren verlangen können. Das deckt den dokumentierten Teil regulatorischer Pflichten ab."
   },
   {
    "ref": "GOVERN 4.2",
    "text": "Die Teams dokumentieren Risiken und mögliche Auswirkungen der von ihnen konzipierten, entwickelten, bereitgestellten, bewerteten und genutzten KI-Technologie und kommunizieren diese Auswirkungen auch über das Team hinaus.",
    "staerke": "mittel",
    "begruendung": "A.8.5 verlangt, die Berichtspflichten gegenüber interested parties zu bestimmen und zu dokumentieren; B.8.5 nennt als teilbare Inhalte ausdrücklich risks related to the system und results of impact assessments. Das ist die externe Kommunikationsseite."
   },
   {
    "ref": "GOVERN 4.3",
    "text": "Organisatorische Praktiken ermöglichen das Testen von KI, die Erkennung von Vorfällen und den Informationsaustausch.",
    "staerke": "mittel",
    "begruendung": "A.8.5 verlangt dokumentierte Berichtspflichten gegenüber interested parties; B.8.5 nennt als teilbare Inhalte technische Dokumentation, Verifikations- und Validierungsaufzeichnungen sowie logs and other system records. Das deckt den Informationsaustausch mit Behörden und Kunden ab."
   },
   {
    "ref": "MANAGE 1.4",
    "text": "Negative Restrisiken – die Summe aller nicht geminderten Risiken – gegenüber nachgelagerten Abnehmern des KI-Systems und gegenüber Endnutzern sind dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.8.5 verlangt die Ermittlung und Dokumentation der Berichtspflichten gegenüber interessierten Parteien; die Guidance nennt als zu teilende Inhalte ausdrücklich „risks related to the system“ und „results of impact assessments“. Bleibt jedoch an bestehende rechtliche Pflichten gebunden."
   },
   {
    "ref": "MANAGE 4.3",
    "text": "Vorfälle und Fehler werden relevanten KI-Akteuren einschließlich betroffener Gruppen mitgeteilt. Prozesse zur Verfolgung von Vorfällen und Fehlern, zur Reaktion darauf und zur Wiederherstellung werden befolgt und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.8.5 verlangt die Ermittlung und Dokumentation der Pflichten zur Berichterstattung an interessierte Parteien; die Guidance nennt Kunden und Regulierer sowie als Inhalte Risiken, Impact-Assessment-Ergebnisse und Systemprotokolle innerhalb angemessener Fristen. Reicht über Nutzer hinaus, bleibt aber pflichtengebunden."
   },
   {
    "ref": "MAP 2.2",
    "text": "Die Wissensgrenzen des KI-Systems sowie Nutzung und Beaufsichtigung seiner Ausgaben durch Menschen sind dokumentiert. Die Dokumentation reicht aus, damit relevante KI-Akteure informierte Entscheidungen treffen und daraus Maßnahmen ableiten können.",
    "staerke": "schwach",
    "begruendung": "A.8.5 verlangt die Bestimmung und Dokumentation der Berichtspflichten gegenüber interessierten Parteien, etwa Aufsichtsbehörden. Das betrifft externe Berichtspflichten, nicht die Entscheidungsunterstützung der operativen Akteure."
   }
  ],
  "A.9.2": [
   {
    "ref": "GOVERN 1.2",
    "text": "Die Merkmale vertrauenswürdiger KI sind in die Richtlinien, Prozesse und Verfahren der Organisation integriert.",
    "staerke": "mittel",
    "begruendung": "A.9.2 verlangt dokumentierte Prozesse für die verantwortungsvolle Nutzung von AI-Systemen, laut B.9.2 einschließlich erforderlicher Genehmigungen und Sourcing-Anforderungen. Damit reicht die Integration bis in die Nutzungsseite, bleibt inhaltlich aber offen."
   },
   {
    "ref": "GOVERN 4.1",
    "text": "Richtlinien und Praktiken fördern kritisches Denken und einen Sicherheitsvorrang bei Konzeption, Entwicklung, Bereitstellung und Nutzung von KI-Systemen, um negative Auswirkungen zu minimieren.",
    "staerke": "mittel",
    "begruendung": "A.9.2 verlangt dokumentierte Prozesse für die verantwortungsvolle Nutzung; B.9.2 nennt erforderliche Genehmigungen, Kosten für laufendes Monitoring, zugelassene Beschaffungswege und rechtliche Anforderungen. Das adressiert die Nutzungsseite von GOVERN 4.1."
   },
   {
    "ref": "GOVERN 6.1",
    "text": "Richtlinien und Verfahren adressieren KI-Risiken im Zusammenhang mit Dritten, einschließlich der Verletzung von Rechten des geistigen Eigentums oder sonstiger Rechte Dritter.",
    "staerke": "mittel",
    "begruendung": "A.9.2 verlangt dokumentierte Prozesse für die verantwortungsvolle Nutzung; B.9.2 nennt approved sourcing requirements und legal requirements applicable to the organization, ausdrücklich unabhängig davon, ob das System selbst entwickelt oder von Dritten bezogen wurde. Das ist der Policy-Anker für Drittbezug."
   },
   {
    "ref": "MAP 4.1",
    "text": "Vorgehensweisen zur Erfassung technischer und rechtlicher Risiken der Systemkomponenten – einschließlich der Nutzung von Daten oder Software Dritter sowie möglicher Verletzungen von Rechten des geistigen Eigentums oder sonstiger Rechte Dritter – bestehen, werden angewendet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.9.2 nennt als Erwägungen für den Einsatz eines KI-Systems „approved sourcing requirements“ und „legal requirements applicable to the organization“, unabhängig davon, ob das System selbst entwickelt oder bezogen wurde. Das adressiert Rechtsrisiken bei Drittkomponenten prozessual."
   },
   {
    "ref": "MANAGE 1.1",
    "text": "Es wird festgestellt, ob das KI-System seine Zweckbestimmung und die festgelegten Ziele erreicht und ob Entwicklung oder Bereitstellung fortgeführt werden sollen.",
    "staerke": "mittel",
    "begruendung": "A.9.2 fordert dokumentierte Prozesse für die verantwortungsvolle Nutzung; die Guidance nennt als Erwägungen zur Entscheidung über die Nutzung eines KI-Systems erforderliche Genehmigungen, Kosten, Beschaffungsanforderungen und rechtliche Anforderungen. Deckt die Nutzungsseite der Go/No-Go-Entscheidung ab."
   },
   {
    "ref": "MANAGE 2.1",
    "text": "Die für die Behandlung von KI-Risiken erforderlichen Ressourcen werden berücksichtigt, ebenso tragfähige Alternativen ohne KI, um Ausmaß oder Eintrittswahrscheinlichkeit möglicher Auswirkungen zu verringern.",
    "staerke": "mittel",
    "begruendung": "A.9.2 verlangt dokumentierte Prozesse für die verantwortungsvolle Nutzung; die Guidance nennt als Erwägung, ob ein bestimmtes KI-System überhaupt genutzt wird, einschließlich „cost (including for ongoing monitoring and maintenance)“. Erfasst Ressourcenerwägung und Nutzungsentscheidung, nicht aber den Vergleich mit Nicht-KI-Alternativen."
   },
   {
    "ref": "MAP 1.4",
    "text": "Der geschäftliche Nutzen bzw. der betriebliche Einsatzkontext ist klar definiert oder – bei der Bewertung bestehender KI-Systeme – erneut bewertet.",
    "staerke": "schwach",
    "begruendung": "B.9.2 nennt als Erwägungen für den Einsatz eines KI-Systems erforderliche Genehmigungen, Kosten einschließlich Monitoring und Wartung sowie genehmigte Bezugsanforderungen. Das berührt die Nutzenentscheidung nur am Rand."
   }
  ],
  "A.9.3": [
   {
    "ref": "GOVERN 1.2",
    "text": "Die Merkmale vertrauenswürdiger KI sind in die Richtlinien, Prozesse und Verfahren der Organisation integriert.",
    "staerke": "stark",
    "begruendung": "A.9.3 verlangt, Ziele für die verantwortungsvolle Nutzung von KI-Systemen festzulegen und zu dokumentieren; B.9.3 zählt dafür fairness, accountability, transparency, explainability, reliability, safety, robustness, privacy, security und accessibility auf. Diese Aufzählung deckt sich weitgehend mit den characteristics of trustworthy AI, deren Verankerung in Richtlinien und Prozessen GOVERN 1.2 fordert."
   },
   {
    "ref": "GOVERN 3.2",
    "text": "Richtlinien und Verfahren definieren und unterscheiden Rollen und Verantwortlichkeiten für das Zusammenwirken von Mensch und KI sowie für die Aufsicht über KI-Systeme.",
    "staerke": "stark",
    "begruendung": "B.9.3 verlangt festzulegen, in welchen Lebenszyklusphasen meaningful human oversight einzubauen ist, einschließlich human reviewers mit authority to override decisions und der Frage, ob automated decision-making überhaupt angemessen ist. Das ist die präziseste Entsprechung zu human-AI configurations."
   },
   {
    "ref": "GOVERN 4.1",
    "text": "Richtlinien und Praktiken fördern kritisches Denken und einen Sicherheitsvorrang bei Konzeption, Entwicklung, Bereitstellung und Nutzung von KI-Systemen, um negative Auswirkungen zu minimieren.",
    "staerke": "stark",
    "begruendung": "B.9.3 nennt als Ziele verantwortungsvoller Nutzung ausdrücklich safety, reliability, robustness and redundancy neben fairness, transparency und privacy und verlangt Mechanismen zu deren Erreichung. Das entspricht der safety-first-Ausrichtung."
   },
   {
    "ref": "MAP 3.5",
    "text": "Prozesse für Human Oversight (menschliche Aufsicht) sind entsprechend den Richtlinien aus der Funktion GOVERN definiert, bewertet und dokumentiert.",
    "staerke": "stark",
    "begruendung": "B.9.3 verlangt festzulegen, an welchen Lebenszyklusstellen „meaningful human oversight objectives“ zu verankern sind, einschließlich Prüfung und Übersteuerung von Ausgaben, Leistungsüberwachung, Meldung von Bedenken und der Frage, ob automatisierte Entscheidungen überhaupt angemessen sind. Das ist die zentrale Entsprechung zu „processes for human oversight“."
   },
   {
    "ref": "GOVERN 2.2",
    "text": "Beschäftigte und Partner erhalten Schulungen zum KI-Risikomanagement, damit sie ihre Aufgaben im Einklang mit den einschlägigen Richtlinien, Verfahren und Vereinbarungen wahrnehmen können.",
    "staerke": "mittel",
    "begruendung": "B.9.3 verlangt, dass das in human oversight eingebundene Personal informiert, geschult und mit den Instruktionen und Dokumentationen des AI-Systems sowie den eigenen Pflichten vertraut ist. Das ist eine explizite Schulungsanforderung für eine Schlüsselrolle."
   },
   {
    "ref": "MAP 2.2",
    "text": "Die Wissensgrenzen des KI-Systems sowie Nutzung und Beaufsichtigung seiner Ausgaben durch Menschen sind dokumentiert. Die Dokumentation reicht aus, damit relevante KI-Akteure informierte Entscheidungen treffen und daraus Maßnahmen ableiten können.",
    "staerke": "mittel",
    "begruendung": "B.9.3 verlangt die Festlegung, an welchen Lebenszyklusstellen wirksame menschliche Aufsicht erfolgt, einschließlich Prüfung und Übersteuerung von Ausgaben. Der Dokumentationsfokus liegt jedoch auf Zielen, nicht auf der Nutzerinformation."
   },
   {
    "ref": "MAP 3.4",
    "text": "Prozesse zur Fachkunde von Bedienern und Fachanwendern hinsichtlich Leistung und Vertrauenswürdigkeit des KI-Systems sowie einschlägige technische Normen und Zertifizierungen sind definiert, bewertet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.9.3 verlangt, dass das in der menschlichen Aufsicht tätige Personal „informed of, trained and understand the instructions and other documentation“ ist. Das verbindet Kompetenz mit Systemleistung und Aufsichtspflichten."
   },
   {
    "ref": "MANAGE 1.1",
    "text": "Es wird festgestellt, ob das KI-System seine Zweckbestimmung und die festgelegten Ziele erreicht und ob Entwicklung oder Bereitstellung fortgeführt werden sollen.",
    "staerke": "mittel",
    "begruendung": "A.9.3 verlangt dokumentierte Ziele für die verantwortungsvolle Nutzung (u. a. Fairness, Zuverlässigkeit, Sicherheit), die nach B.6.2.4 ausdrücklich als Bewertungsmaßstab in die Evaluierung einfließen. Liefert die „stated objectives“, gegen die gemessen wird."
   },
   {
    "ref": "MANAGE 2.4",
    "text": "Mechanismen zum Übersteuern, Abschalten oder Deaktivieren von KI-Systemen mit bestimmungswidriger Leistung oder Wirkung bestehen und werden angewendet; die Verantwortlichkeiten dafür sind zugewiesen und bekannt.",
    "staerke": "mittel",
    "begruendung": "A.9.3 verlangt Ziele für verantwortungsvolle Nutzung; die Guidance fordert menschliche Aufsicht einschließlich Prüfern mit „authority to override decisions made by the AI system“ sowie die Meldung von Bedenken bei veränderter Leistungsfähigkeit. Deckt Übersteuerung, nicht aber Deaktivierung."
   },
   {
    "ref": "MANAGE 4.1",
    "text": "Pläne zur Überwachung des KI-Systems nach der Inbetriebnahme sind umgesetzt, einschließlich Erfassung und Auswertung von Rückmeldungen der Nutzer und weiterer relevanter KI-Akteure, Beschwerde- und Übersteuerungsmöglichkeiten, Außerbetriebnahme, Vorfallreaktion, Wiederherstellung und Änderungsmanagement.",
    "staerke": "mittel",
    "begruendung": "A.9.3-Guidance verlangt menschliche Aufsicht mit Befugnis zur Übersteuerung von Systementscheidungen, Überwachung der Ausgabegenauigkeit und Meldung von Bedenken zu Ausgaben und Leistungsänderungen. Deckt Override, nicht aber ein Widerspruchsverfahren."
   },
   {
    "ref": "MAP 1.3",
    "text": "Auftrag und einschlägige Ziele der Organisation für die KI-Technologie sind verstanden und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.9.3 fordert dokumentierte Ziele für die verantwortliche Nutzung von KI-Systemen (z. B. Fairness, Transparenz, Sicherheit). Der Bezug zur übergeordneten Mission der Organisation bleibt dabei indirekt."
   },
   {
    "ref": "MEASURE 2.7",
    "text": "Security und Resilienz des KI-Systems – wie in MAP erfasst – werden bewertet und dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.9.3 nennt als Ziele verantwortlicher Nutzung unter anderem Zuverlässigkeit, Robustheit und Redundanz sowie Datenschutz und Sicherheit. Es handelt sich um Zielbegriffe ohne Bewertungs- oder Nachweisanforderung."
   }
  ],
  "A.9.4": [
   {
    "ref": "MAP 3.3",
    "text": "Der angestrebte Anwendungsbereich ist auf Basis der Systemfähigkeiten, des bestimmten Kontexts und der Kategorisierung des KI-Systems festgelegt und dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.9.4 verlangt sicherzustellen, dass das KI-System entsprechend seiner beabsichtigten Verwendung und der Begleitdokumentation genutzt wird; B.9.4 fordert zusätzlich, dass die verarbeiteten Daten zur Dokumentation passen. Das ist die unmittelbare Entsprechung des „targeted application scope“."
   },
   {
    "ref": "MANAGE 2.4",
    "text": "Mechanismen zum Übersteuern, Abschalten oder Deaktivieren von KI-Systemen mit bestimmungswidriger Leistung oder Wirkung bestehen und werden angewendet; die Verantwortlichkeiten dafür sind zugewiesen und bekannt.",
    "staerke": "stark",
    "begruendung": "A.9.4 verlangt, dass das KI-System entsprechend seiner Zweckbestimmung und Begleitdokumentation genutzt wird; die Guidance fordert Überwachung des Betriebs und, wo der Einsatz Bedenken hinsichtlich Auswirkungen oder rechtlicher Anforderungen auslöst, die Kommunikation an das zuständige Personal und an Drittlieferanten sowie Nachweisführung über Event-Logs. Kern der Reaktion auf zweckwidrige Ergebnisse."
   },
   {
    "ref": "MEASURE 2.9",
    "text": "Das KI-Modell wird erläutert, validiert und dokumentiert; die Ausgaben des Systems werden im jeweiligen Kontext – wie in MAP bestimmt – interpretiert und stützen eine verantwortungsvolle Nutzung und Governance.",
    "staerke": "mittel",
    "begruendung": "A.9.4 verpflichtet zur Nutzung des Systems entsprechend dem beabsichtigten Zweck und der Begleitdokumentation und stellt damit den von NIST geforderten Bezug zur verantwortlichen Verwendung her."
   },
   {
    "ref": "MANAGE 1.1",
    "text": "Es wird festgestellt, ob das KI-System seine Zweckbestimmung und die festgelegten Ziele erreicht und ob Entwicklung oder Bereitstellung fortgeführt werden sollen.",
    "staerke": "mittel",
    "begruendung": "A.9.4 verlangt, dass das KI-System gemäß seiner Zweckbestimmung und Begleitdokumentation genutzt wird; bei Bedenken hinsichtlich Auswirkungen sind diese intern und an Lieferanten zu kommunizieren. Adressiert die Zweckkonformität, nicht aber die formale Fortsetzungsentscheidung."
   },
   {
    "ref": "MEASURE 2.5",
    "text": "Vor der Bereitstellung ist nachgewiesen, dass das KI-System valide und zuverlässig ist; Grenzen der Übertragbarkeit über die Entwicklungsbedingungen hinaus sind dokumentiert.",
    "staerke": "schwach",
    "begruendung": "A.9.4 verlangt, das AI-System entsprechend seiner beabsichtigten Zweckbestimmung zu verwenden, und markiert damit die Grenze zulässiger Anwendung. Ein Nachweis der Validität außerhalb dieser Grenzen wird nicht gefordert."
   }
  ],
  "A.10.2": [
   {
    "ref": "GOVERN 6.1",
    "text": "Richtlinien und Verfahren adressieren KI-Risiken im Zusammenhang mit Dritten, einschließlich der Verletzung von Rechten des geistigen Eigentums oder sonstiger Rechte Dritter.",
    "staerke": "stark",
    "begruendung": "A.10.2 verlangt, die Verantwortlichkeiten im Lebenszyklus zwischen Organisation, Partnern, Lieferanten, Kunden und Dritten zuzuordnen; B.10.2 verlangt, alle beteiligten Parteien samt Rollen zu dokumentieren und ihre Verantwortlichkeiten zu bestimmen. Das adressiert die Risiken aus Drittbeteiligung unmittelbar."
   },
   {
    "ref": "MAP 4.1",
    "text": "Vorgehensweisen zur Erfassung technischer und rechtlicher Risiken der Systemkomponenten – einschließlich der Nutzung von Daten oder Software Dritter sowie möglicher Verletzungen von Rechten des geistigen Eigentums oder sonstiger Rechte Dritter – bestehen, werden angewendet und dokumentiert.",
    "staerke": "stark",
    "begruendung": "B.10.2 verlangt, alle am Lebenszyklus beteiligten Parteien - Daten-, Algorithmen- und Modelllieferanten - zu dokumentieren und ihre Verantwortlichkeiten zu bestimmen, einschließlich der Rollenverteilung bei PII. Damit wird die rechtliche Zurechnung von Komponentenrisiken systematisch erfasst."
   },
   {
    "ref": "GOVERN 6.2",
    "text": "Notfallprozesse regeln den Umgang mit Ausfällen oder Vorfällen bei Daten oder KI-Systemen Dritter, die als hochriskant eingestuft sind.",
    "staerke": "mittel",
    "begruendung": "A.10.2 verlangt die Zuordnung der Verantwortlichkeiten zwischen Organisation, Partnern, Lieferanten, Kunden und Dritten. Damit ist im Störfall geklärt, wer welche Maßnahme schuldet, nicht aber welche Notfallmaßnahme greift."
   },
   {
    "ref": "MAP 4.2",
    "text": "Interne Risikosteuerungsmaßnahmen für die Komponenten des KI-Systems einschließlich der KI-Technologien Dritter sind identifiziert und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.10.2 verlangt die Zuweisung der Verantwortlichkeiten im Lebenszyklus zwischen Organisation, Partnern, Lieferanten, Kunden und Dritten. Ohne diese Zuordnung lassen sich Kontrollen für fremdbezogene Komponenten nicht wirksam verorten."
   },
   {
    "ref": "MANAGE 3.1",
    "text": "KI-Risiken und -Nutzen aus Ressourcen Dritter werden regelmäßig überwacht; Risikosteuerungsmaßnahmen werden angewendet und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "A.10.2 verlangt die Aufteilung der Verantwortlichkeiten im KI-Lebenszyklus zwischen Organisation, Partnern, Lieferanten, Kunden und Dritten; die Guidance fordert, alle beteiligten Parteien, ihre Rollen und Verantwortlichkeiten zu dokumentieren. Regelt Zurechnung, nicht die laufende Überwachung."
   },
   {
    "ref": "GOVERN 2.2",
    "text": "Beschäftigte und Partner erhalten Schulungen zum KI-Risikomanagement, damit sie ihre Aufgaben im Einklang mit den einschlägigen Richtlinien, Verfahren und Vereinbarungen wahrnehmen können.",
    "staerke": "schwach",
    "begruendung": "A.10.2 verlangt die Zuordnung der Verantwortlichkeiten im Lebenszyklus zwischen Organisation, Partnern, Lieferanten, Kunden und Dritten. Das adressiert die Partnerseite nur zuständigkeits-, nicht qualifizierungsbezogen."
   }
  ],
  "A.10.3": [
   {
    "ref": "GOVERN 6.1",
    "text": "Richtlinien und Verfahren adressieren KI-Risiken im Zusammenhang mit Dritten, einschließlich der Verletzung von Rechten des geistigen Eigentums oder sonstiger Rechte Dritter.",
    "staerke": "stark",
    "begruendung": "A.10.3 verlangt einen Prozess, der sicherstellt, dass bezogene Dienste, Produkte und Materialien zum verantwortungsvollen Ansatz der Organisation passen; B.10.3 verlangt, Lieferantentypen und deren Risikoniveau bei Auswahl, Anforderungen und laufender Überwachung zu berücksichtigen. Das ist die Kern-Policy für Drittparteirisiken."
   },
   {
    "ref": "GOVERN 6.2",
    "text": "Notfallprozesse regeln den Umgang mit Ausfällen oder Vorfällen bei Daten oder KI-Systemen Dritter, die als hochriskant eingestuft sind.",
    "staerke": "stark",
    "begruendung": "B.10.3 verlangt, dass die Organisation vom Lieferanten Korrekturmaßnahmen verlangt, wenn dessen AI-System oder Komponenten nicht wie beabsichtigt arbeiten oder zu nicht ansatzkonformen Auswirkungen führen können, und dass Umfang der laufenden Überwachung risikoabhängig festgelegt wird. Das ist die Kernentsprechung zum Umgang mit Drittparteifehlern."
   },
   {
    "ref": "MAP 4.1",
    "text": "Vorgehensweisen zur Erfassung technischer und rechtlicher Risiken der Systemkomponenten – einschließlich der Nutzung von Daten oder Software Dritter sowie möglicher Verletzungen von Rechten des geistigen Eigentums oder sonstiger Rechte Dritter – bestehen, werden angewendet und dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.10.3 verlangt einen Prozess, der sicherstellt, dass die Nutzung von Leistungen, Produkten oder Materialien von Lieferanten dem verantwortlichen Ansatz der Organisation entspricht; B.10.3 nennt ausdrücklich bezogene Datensätze, Algorithmen, Modelle und Softwarebibliotheken sowie deren Risikobewertung. Das ist die direkte Entsprechung zu „use of third-party data or software“."
   },
   {
    "ref": "MAP 4.2",
    "text": "Interne Risikosteuerungsmaßnahmen für die Komponenten des KI-Systems einschließlich der KI-Technologien Dritter sind identifiziert und dokumentiert.",
    "staerke": "stark",
    "begruendung": "B.10.3 verlangt, Lieferantentypen, das jeweilige Risiko, die an sie gestellten Anforderungen sowie das laufende Monitoring zu bestimmen und zu dokumentieren, „how the AI system and AI system components are integrated“. Das deckt Kontrollen für Drittanbieter-KI-Technologien ab."
   },
   {
    "ref": "MANAGE 3.1",
    "text": "KI-Risiken und -Nutzen aus Ressourcen Dritter werden regelmäßig überwacht; Risikosteuerungsmaßnahmen werden angewendet und dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.10.3 verlangt einen Prozess, der sicherstellt, dass die Nutzung von Lieferantenleistungen dem verantwortungsvollen Ansatz der Organisation entspricht; die Guidance fordert risikoabhängige Lieferantenauswahl, Anforderungen an Lieferanten, „levels of ongoing monitoring and evaluation needed for the suppliers“ sowie Korrekturmaßnahmen des Lieferanten bei Abweichungen."
   },
   {
    "ref": "MANAGE 3.2",
    "text": "Für die Entwicklung genutzte Pre-trained Models (vortrainierte Modelle) werden in die regelmäßige Überwachung und Wartung des KI-Systems einbezogen.",
    "staerke": "stark",
    "begruendung": "A.10.3-Guidance nennt als Lieferantenleistungen ausdrücklich „sourcing datasets, machine learning algorithms or models“ und verlangt, zu dokumentieren, wie KI-Systemkomponenten in die eigenen Systeme integriert werden, sowie Korrekturmaßnahmen des Lieferanten bei nicht erwartungsgemäßer Leistung."
   }
  ],
  "A.10.4": [
   {
    "ref": "MANAGE 1.4",
    "text": "Negative Restrisiken – die Summe aller nicht geminderten Risiken – gegenüber nachgelagerten Abnehmern des KI-Systems und gegenüber Endnutzern sind dokumentiert.",
    "staerke": "stark",
    "begruendung": "A.10.4 fordert die Berücksichtigung von Kundenerwartungen; die Guidance nennt als Beispiel, identifizierte Risiken der Kundennutzung dadurch zu behandeln, dass dem Kunden angemessene Informationen gegeben werden, damit dieser die Risiken selbst behandeln kann, und die Grenzen der Einsatzdomäne zu kommunizieren. Genau die NIST-Forderung gegenüber Downstream-Abnehmern."
   },
   {
    "ref": "GOVERN 5.1",
    "text": "Richtlinien und Praktiken stellen sicher, dass Rückmeldungen von Beteiligten außerhalb des entwickelnden oder bereitstellenden Teams zu möglichen individuellen und gesellschaftlichen Auswirkungen erhoben, bewertet, priorisiert und eingebunden werden.",
    "staerke": "mittel",
    "begruendung": "A.10.4 verlangt, dass der verantwortungsvolle Ansatz die Erwartungen und Bedarfe der Kunden berücksichtigt; B.10.4 nennt Anforderungen aus Design-, Engineering- und Vertragsphasen. Das ist Feedback von der Kundenseite, nicht von betroffenen Dritten."
   },
   {
    "ref": "GOVERN 5.2",
    "text": "Mechanismen stellen sicher, dass geprüfte Rückmeldungen relevanter KI-Akteure regelmäßig in Systemdesign und Umsetzung einfließen.",
    "staerke": "mittel",
    "begruendung": "B.10.4 verlangt, Kundenerwartungen und -bedarfe zu verstehen und Risiken aus der Kundennutzung zu behandeln, etwa durch geeignete Information des Kunden. Das ist ein geregelter, wiederkehrender Feedbackkanal."
   },
   {
    "ref": "MAP 1.4",
    "text": "Der geschäftliche Nutzen bzw. der betriebliche Einsatzkontext ist klar definiert oder – bei der Bewertung bestehender KI-Systeme – erneut bewertet.",
    "staerke": "mittel",
    "begruendung": "Der in der Baseline genannte Titel „Customers“ gehört zu A.10.4: Die Organisation muss Kundenerwartungen und -beduerfnisse in ihrem verantwortlichen Ansatz berücksichtigen, auch in Form vertraglicher Anforderungen. Das prägt den Geschäftsnutzungskontext bei Anbieterrollen unmittelbar."
   },
   {
    "ref": "MAP 2.2",
    "text": "Die Wissensgrenzen des KI-Systems sowie Nutzung und Beaufsichtigung seiner Ausgaben durch Menschen sind dokumentiert. Die Dokumentation reicht aus, damit relevante KI-Akteure informierte Entscheidungen treffen und daraus Maßnahmen ableiten können.",
    "staerke": "mittel",
    "begruendung": "B.10.4 verlangt, dass bei Gültigkeit eines KI-Systems für eine bestimmte Domäne „the limits of the domain should be communicated to the customer“. Das entspricht der Offenlegung der Wissensgrenzen gegenüber abnehmenden Stellen."
   },
   {
    "ref": "MAP 3.3",
    "text": "Der angestrebte Anwendungsbereich ist auf Basis der Systemfähigkeiten, des bestimmten Kontexts und der Kategorisierung des KI-Systems festgelegt und dokumentiert.",
    "staerke": "mittel",
    "begruendung": "B.10.4 verlangt, die Grenzen der Gültigkeitsdomäne eines KI-Systems an die Kundenseite zu kommunizieren. Das setzt eine festgelegte und dokumentierte Einsatzdomäne voraus."
   },
   {
    "ref": "MANAGE 4.1",
    "text": "Pläne zur Überwachung des KI-Systems nach der Inbetriebnahme sind umgesetzt, einschließlich Erfassung und Auswertung von Rückmeldungen der Nutzer und weiterer relevanter KI-Akteure, Beschwerde- und Übersteuerungsmöglichkeiten, Außerbetriebnahme, Vorfallreaktion, Wiederherstellung und Änderungsmanagement.",
    "staerke": "mittel",
    "begruendung": "A.10.4 verlangt, dass der verantwortungsvolle Ansatz die Erwartungen und Bedarfe der Kunden berücksichtigt, die auch als vertragliche oder Nutzungsanforderungen auftreten können. Deckt die Erfassung von Rückmeldungen der Kundenseite ab."
   },
   {
    "ref": "MAP 5.2",
    "text": "Praktiken und Personal für den regelmäßigen Austausch mit relevanten KI-Akteuren sowie für die Einbindung von Rückmeldungen zu positiven, negativen und unerwarteten Auswirkungen bestehen und sind dokumentiert.",
    "staerke": "schwach",
    "begruendung": "B.10.4 verlangt, Kundenerwartungen und -beduerfnisse zu verstehen, auch aus Design-, Engineering- oder Vertragsanforderungen. Das erfasst nur eine Gruppe von AI-Akteuren."
   },
   {
    "ref": "MEASURE 3.3",
    "text": "Rückmeldeverfahren, über die Endnutzer und betroffene Gruppen Probleme melden und Systemergebnisse beanstanden können, sind eingerichtet und in die Bewertungskennzahlen des KI-Systems eingebunden.",
    "staerke": "schwach",
    "begruendung": "A.10.4 verlangt, Erwartungen und Beduerfnisse von Kunden im verantwortlichen Umgang mit KI zu berücksichtigen; betroffene Gemeinschaften ohne Kundenbeziehung sind davon nicht erfasst."
   }
  ]
 },
 "kennzahlen": {
  "paare": 485,
  "stark": 132,
  "mittel": 268,
  "schwach": 85,
  "nist_gesamt": 72,
  "nist_abgedeckt": 72,
  "iso_gesamt": 70,
  "iso_abgedeckt": 66,
  "luecken": 66
 }
}