Annex-A-Controls der ISO 42001 im Überblick

Annex A der ISO/IEC 42001:2023 ist der normative Katalog aus 38 Reference-Controls in 9 Kontrollbereichen (A.2 bis A.10), aus dem Organisationen über die Statement of Applicability (SoA) risikobasiert die für sie relevanten Maßnahmen auswählen. Die Controls decken den gesamten Bogen vom KI-Politik-Rahmen über Rollen, Ressourcen, Lebenszyklus und Daten-Governance bis zur verantwortungsvollen Nutzung und zu Drittpartei-Beziehungen ab.

Annex A funktioniert dabei wie Annex A der ISO/IEC 27001 in Verbindung mit ISO 27002: Jeder Kontrollbereich hat ein Ziel ("To …") und eine Liste von Controls, die zusammen dieses Ziel erreichen. Die zugehörige Umsetzungs-Guidance steht im informativen Annex B.

Drei Schnellantworten:

• Wie viele? 9 Kontrollbereiche, 38 Controls. Abweichende Zählungen (39, 42 Controls; 10 Domänen) entstehen durch Zählkonventionen; die kanonische Zahl ist 9/38.
• Verpflichtend? Nein pauschal - die Auswahl erfolgt risikobasiert über die SoA. Jeder Control wird als anwendbar oder nicht anwendbar markiert, beides mit Begründung.
• Wofür wichtig? Annex A ist der operative Kern, an dem in Clause 8 (Operation) die KI-Governance konkret landet - und die zentrale Sampling-Grundlage im Audit.

Die 9 Kontrollbereiche im Überblick

Die folgende Tabelle fasst alle Annex-A-Kontrollbereiche mit Ziel und einer typischen Beispiel-Maßnahme zusammen.

A.2 bis A.5: Steuerung, Organisation, Ressourcen und Impact

A.2 (Policies related to AI) umfasst die Abstimmung der KI-Politik mit anderen Richtlinien (A.2.2), die KI-Politik selbst als vom Management genehmigte Richtung (A.2.3) und deren regelmäßige Überprüfung (A.2.4). Für einen Agent-Betreiber sollte die KI-Politik explizit Autonomiestufen (read-only / empfehlen / handeln mit Freigabe / autonom handeln), Tool-Use-Grenzen, Eskalations- und Human-in-the-Loop-Regeln, Modellanbieter-Diversität und verbotene Use-Cases (etwa keine autonome Rechtsberatung) abdecken.

A.3 (Internal organisation) regelt KI-Rollen und Verantwortlichkeiten mit Funktionstrennung (A.3.2) sowie einen Kanal zur Meldung von Bedenken (A.3.3). ISO 42001 schreibt keinen festen "AI Officer"-Titel vor; in mittelständischen DACH-Organisationen wird die AIMS-Manager-Rolle häufig mit CISO oder Datenschutzbeauftragtem kombiniert.

A.4 (Resources for AI systems) verlangt die Dokumentation von Ressourcen (A.4.2), Daten- (A.4.3), Tooling- (A.4.4), System-/Compute- (A.4.5) und Personalressourcen (A.4.6). Für Agent-Deployer ist A.4.2 das AI/Agent-Register - die Liste jedes produktiven Agenten mit Zweck, Owner, Modellabhängigkeiten, Datenquellen und Risikoklasse. Es ist das wichtigste Artefakt für das Audit-Sampling.

A.5 (Assessing impacts of AI systems) definiert den Impact-Assessment-Prozess (A.5.2), dessen Dokumentation (A.5.3) sowie die Bewertung der Auswirkungen auf Individuen (A.5.4) und auf Gruppen und Gesellschaft (A.5.5). Diese vier Controls sind der operative Anker für die Begleitnorm ISO/IEC 42005:2025 und überlappen funktional - ohne sie zu ersetzen - mit der DSGVO-DSFA (Art. 35) und der EU-AI-Act-FRIA (Art. 27).

A.6 bis A.10: Lebenszyklus, Daten, Information, Nutzung, Drittparteien

A.6 (AI system lifecycle) ist der umfangreichste Bereich: von Lebenszyklus-Zielen (A.6.1.2) über verantwortungsvolles Design (A.6.1.3), Anforderungsspezifikation (A.6.2.2), Design-Dokumentation (A.6.2.3), Verifikation und Validierung (A.6.2.4), Deployment (A.6.2.5), Betrieb und Monitoring (A.6.2.6), technische Dokumentation (A.6.2.7) bis zum Event-Logging (A.6.2.8). Letzteres etabliert eine explizite Logging-Pflicht, die funktional parallel zu Art. 12 EU AI Act (Logging für Hochrisiko-KI) läuft - und der in Agent-Deployments am häufigsten unzureichend belegte Control, weil meist nur Tool-Calls, nicht aber Modell-Inputs, Reasoning-Traces oder Human-Override-Events geloggt werden.

A.7 (Data for AI systems) verankert Daten-Governance: Daten für Entwicklung und Verbesserung (A.7.2), Beschaffung (A.7.3), Qualität (A.7.4), Provenienz/Herkunft (A.7.5) und Aufbereitung (A.7.6). A.7 ist Anker für den Querverweis auf die ISO/IEC-5259-Serie und richtet sich konzeptionell an Art. 10 EU AI Act aus. Wichtig: Auch bei reiner Nutzung von Drittanbieter-Foundation-Models bleibt A.7 anwendbar - er erfasst Retrieval-/RAG-Daten, Prompt-Templates und Evaluierungsdatensätze.

A.8 (Information for interested parties) deckt System-Dokumentation und Nutzerinformationen wie Model Cards (A.8.2), externes Reporting (A.8.3), Vorfall-Kommunikation (A.8.4) und Information für Stakeholder (A.8.5) ab. A.8.2 mappt eng auf Art. 13 EU AI Act (Transparenz / Instructions for Use), A.8.4 auf Art. 73 (Meldung schwerer Vorfälle) und auf die Deployer-Pflichten aus Art. 26.

A.9 (Use of AI systems) umfasst Prozesse für verantwortungsvolle Nutzung (A.9.2), entsprechende Ziele (A.9.3) und den bestimmungsgemäßen Gebrauch (A.9.4). A.9.4 ist für Deployer kritisch: Wird ein Agent außerhalb des vom Anbieter erklärten Intended Use betrieben, kann dies Art.-25-Konsequenzen (wesentliche Veränderung) im AI Act auslösen und sollte automatisch ein neues A.5-Impact-Assessment anstoßen.

A.10 (Third-party & customer relationships) regelt die Verantwortungsverteilung in der Wertschöpfungskette (A.10.2), Lieferanten (A.10.3) und Kunden (A.10.4). Für Deployer, die auf Drittanbieter-Foundation-Models oder Agent-Plattformen setzen, dokumentiert A.10.3 die vertragliche und operative Provider/Deployer-Aufteilung inklusive Due Diligence zu Zertifizierungen, Datenschutz und Modell-Versionierung.

Wie Annex A in die SoA eingebunden ist

Annex A wird nicht pauschal umgesetzt, sondern über die Statement of Applicability (SoA) ausgewählt - das meistgeprüfte Dokument jedes ISO-42001-Audits, mandatiert durch Clause 6.1.3. Jeder Control erscheint in der SoA mit:

1. Control-Referenz und -Titel (z. B. A.6.2.8 Event-Logging)
2. Anwendbarkeits-Entscheidung (anwendbar / nicht anwendbar)
3. Begründung (das behandelte Risiko bzw. der Ausschlussgrund)
4. Umsetzungsstatus (geplant / in Arbeit / umgesetzt / überwacht)
5. Verweis auf Nachweise (Policy, Verfahren, Record, System)
6. Owner

Der häufigste Nonconformity-Befund in der Audit-Praxis 2024–2026 sind Ausschlüsse ohne risikobasierte Begründung - ein "n/a" mit Standard-Einzeiler. Ebenfalls typisch: ein Control als anwendbar markieren, aber das zugrunde liegende Dokument nicht pflegen (etwa A.4.2 "applicable" ohne echtes Ressourcen-Register), sowie eine statische SoA, die bei neuen Agenten oder Modellwechseln nicht aktualisiert wird.

Konkretes Umsetzungsbeispiel: Customer-Service-Agent

Ein mittelständischer Deployer (ca. 800 Mitarbeitende) betreibt einen Kundenservice-Agenten auf Basis eines Drittanbieter-Foundation-Models mit RAG-Anbindung an die interne Wissensbasis. Die SoA-Logik für die kritischen Controls:

• A.4.2 anwendbar: Eintrag im AI/Agent-Register - Zweck "First-Level-Support", Owner Service-Lead, Modellabhängigkeit dokumentiert, Risikoklasse "mittel".
• A.5.2–A.5.5 anwendbar: kundenseitiger Agent mit Wirkung auf Individuen; AISIA mit Fundamental-Rights- und Privacy-Screen.
• A.6.2.8 anwendbar: Logging von Prompt und System-Instruction, Modell-ID und -Version, Tool-Calls, Retrieval-Queries und Dokument-IDs, Outputs, Human-Override- und Eskalations-Events. Retention: in der Regel das Längere aus 6 Monaten und sektoraler Vorgabe, mit Begründung in der SoA.
• A.6 Entwicklungs-Controls (z. B. Modell-Training): teilweise ausschließbar, da keine Eigenentwicklung - Begründung: "Organisation entwickelt keine KI-Modelle; alle Modelle von Drittanbietern, abgedeckt unter A.10.3."
• Messbares Ziel (Clause 6.2): "≥ 90 % Genauigkeit auf dem Gold-Standard-Evaluierungsset, rollierende 30-Tage-Messung, monatliches Reporting."

Diese Auswahl ist auditfest, weil jeder Einschluss und jeder Ausschluss eine nachvollziehbare, risikobasierte Begründung trägt - und weil hinter jedem "applicable" ein echtes Artefakt liegt.

Hinweis: Dieser Beitrag dient der fachlichen Orientierung und stellt keine Rechtsberatung dar. Zuordnungen zu DSGVO, EU AI Act und konkreten Artikelnummern (z. B. Art. 12, 13, 25, 35, 73) sollten vor verbindlicher Umsetzung mit Ihrer Rechtsabteilung abgestimmt werden.

Für Agenturen und B2B-Entscheider

Wer KI-Agenten produktiv betreibt, braucht keine "zertifizierte KI" - ISO 42001 zertifiziert das Managementsystem (AIMS/KIMS), nicht das einzelne Modell. Der schnellste Weg zur Auditreife führt über drei Hebel: ein vollständiges AI/Agent-Register (A.4.2), belastbares Event-Logging je Agent (A.6.2.8) und eine gepflegte, risikobasiert begründete SoA. Blck Alpaca unterstützt DACH-Unternehmen und Agenturen dabei, Annex-A-Controls schlank und auditfest aufzusetzen - integriert mit bestehenden ISO-27001-/9001-Systemen und ausgerichtet auf die überlappenden EU-AI-Act-Pflichten. So wird aus dem Control-Katalog ein steuerbares Governance-System statt einer Dokumenten-Sammlung.