ISO 42001 Annex A: Alle 38 Controls in 9 Domänen erklärt

ISO 42001 Annex A enthält 38 Controls in 9 Kategorien — von KI-Governance über Datenmanagement bis hin zu menschlicher Aufsicht. Für Unternehmen ist das der operative Kern der Norm: Annex A zeigt nicht nur, welche Maßnahmen typischerweise zu einem KI-Managementsystem gehören, sondern auch, wie Sie Risiken, Verantwortlichkeiten und Nachweise strukturiert in ein Statement of Applicability übersetzen.

Viele Teams verstehen zuerst die Kapitel 4 bis 10 der Norm und scheitern dann an der praktischen Frage: Welche Kontrollen müssen wir wirklich auswählen, dokumentieren und priorisieren? Genau hier ist Annex A relevant. Wenn Sie die Grundlagen der Norm noch sortieren möchten, hilft zuerst der Überblick Was ist ISO 42001?, der vertiefende ISO-42001-Leitfaden und der Beitrag zu den ISO-42001-Anforderungen. Dieser Artikel konzentriert sich dagegen vollständig auf Annex A selbst.

Annex A im Überblick — 38 Controls in 9 Domänen

Annex A im Überblick bedeutet: Die ISO/IEC 42001:2023 stellt in Annex A einen normativen Referenzkatalog mit 38 Controls bereit, verteilt auf die Domänen A.2 bis A.10. Diese Controls stehen nicht isoliert neben den Clauses 4 bis 10, sondern ergänzen sie. Clauses 4 bis 10 definieren das Managementsystem, Annex A liefert die typischen KI-spezifischen Kontrollziele und Controls für die Umsetzung im Betrieb.

Die Struktur ist dabei wichtig. Clauses 4 bis 10 beantworten Fragen wie: Welcher Kontext ist relevant, welche Führung ist nötig, wie wird geplant, welche Ressourcen braucht das System, wie wird es betrieben, überwacht und verbessert? Annex A beantwortet die nächste Ebene: Welche konkreten Themen müssen Sie für KI überhaupt steuern, dokumentieren und mit Nachweisen hinterlegen? Darum ist Annex A für die Praxis oft greifbarer als die Managementsystem-Sprache der Hauptkapitel.

Für die Einordnung gilt außerdem: Nicht alle 38 Controls müssen automatisch umgesetzt werden. Gemäß dem risikobasierten Ansatz der Norm prüft die Organisation jeden Control auf Anwendbarkeit. Das Ergebnis landet im Statement of Applicability, kurz SoA. Dort halten Sie fest, ob ein Control anwendbar ist, wie Sie ihn umgesetzt haben, warum er eventuell ausgeschlossen wird, welche Person verantwortlich ist und welche Evidenz den Umsetzungsstatus belegt.

Genau deshalb ist Annex A nicht als starre Checkliste zu lesen. Die Norm erlaubt zusätzliche eigene Controls und ebenso begründete Ausschlüsse. Wenn Sie zum Beispiel kein eigenes Modell entwickeln, können bestimmte Lifecycle-Controls anders ausfallen als bei einem Anbieter mit Training, Retraining und eigenem Deployment. Trotzdem müssen Sie die Controls prüfen und die Entscheidung dokumentieren. Annex A ist also eine Referenzbasis, kein starres One-size-fits-all-Set.

Für den EU AI Act ist diese Logik besonders nützlich. Research im Projekt zeigt eine starke Überschneidung vor allem zu Art. 9 Risikomanagement, Art. 10 Daten-Governance, Art. 14 menschliche Aufsicht und Art. 17 Qualitätsmanagementsystem der EU-VO 2024/1689. Gleichzeitig bleibt ISO 42001 ein freiwilliger Governance-Standard und kein harmonisierter Standard für die vollständige AI-Act-Konformität. Wer Annex A sauber umsetzt, baut also eine belastbare Governance-Grundlage, ersetzt aber keine Rechtsprüfung. Mehr dazu lesen Sie im Beitrag ISO 42001 und EU AI Act.

Die neun Domänen verteilen sich wie folgt:

Damit Sie die 38 Controls vollständig sehen, folgt zuerst die Gesamttabelle. Die Formulierungen orientieren sich an der Struktur des Standards, die Kurzbeschreibungen sind für die Praxis paraphrasiert:

Die praktisch wichtigste Schlussfolgerung lautet: Annex A verbindet Governance, Betrieb und Nachweislogik. Wer nur Policies schreibt, aber keine Impact Assessments, Datenregeln, Monitoring- und Lieferantenprozesse aufsetzt, erfüllt die eigentliche Steuerungslogik der Norm nicht. Wer umgekehrt nur technische Maßnahmen umsetzt, aber keine Policy-, Rollen- und SoA-Ebene pflegt, kann Annex A ebenfalls nicht sauber belegen.

A.2 — KI-Policies

A.2 verlangt, dass Unternehmen KI nicht nur informell über Tool-Verbote oder Einzelanweisungen steuern, sondern über eine dokumentierte KI-Policy. Diese Policy ist der rote Faden für Entwicklung, Beschaffung, Einsatz und Überwachung von KI-Systemen. In der Praxis ist A.2 oft der erste sichtbare Governance-Baustein, weil hier festgelegt wird, nach welchen Prinzipien die Organisation KI überhaupt verantwortungsvoll entwickeln oder nutzen will.

A.2.2 fordert eine dokumentierte KI-Policy für Entwicklung oder Nutzung von KI-Systemen. Der entscheidende Punkt ist nicht die Existenz eines PDFs, sondern die Steuerungswirkung. Eine belastbare KI-Policy enthält typischerweise Ziele, Grundsätze, Anwendungsgrenzen, Eskalationslogik, Ausnahmeverfahren und Verweise auf weitere Richtlinien. Sie ist damit deutlich mehr als eine kurze “Do not upload confidential data”-Anweisung.

A.2.3 verlangt die Abstimmung mit anderen Unternehmensrichtlinien. Das ist für die Praxis zentral, weil KI fast nie ein isoliertes Thema ist. Die KI-Policy muss mit Datenschutz, Informationssicherheit, Compliance, Qualitätsmanagement, HR, Einkauf und Produktentwicklung zusammenspielen. Wenn Ihre Organisation bereits Vorgaben zu Datenklassifikation, Freigaben oder Third-Party-Risiken hat, darf die KI-Policy diese Logik nicht unterlaufen. Genau deshalb ist die Verknüpfung mit bestehenden Policy-Landschaften oft wichtiger als eine elegante Formulierung.

A.2.4 fordert die regelmäßige Überprüfung der KI-Policy. Das ist nötig, weil sich KI-Risiken, Use Cases, technische Architektur und Rechtslage schnell ändern. Ein statisches Dokument aus dem Einführungsprojekt wird dieser Dynamik nicht gerecht. Sinnvoll sind daher Review-Zyklen, Trigger für außerplanmäßige Aktualisierung und eine definierte Verantwortlichkeit für die Policy-Pflege.

Für KMU ist A.2 meist mit überschaubarem Aufwand umsetzbar. Ein pragmatischer Start besteht aus einer Kernpolicy mit fünf bis sieben Pflichtblöcken: Scope, Rollen, erlaubte und nicht erlaubte Nutzung, Freigabeprozesse, Umgang mit Daten, Monitoring und Vorfallsmeldung. Wichtig ist aber die Anbindung an reale Prozesse. Eine KI-Policy, die niemand im Einkauf, in HR oder in der Fachabteilung kennt, ist governance-seitig wertlos.

A.3 — Interne Organisation

A.3 übersetzt den Governance-Anspruch der Norm in Organisationsverantwortung. Die Kernaussage lautet: Ohne klare Zuständigkeiten und ohne ein Verfahren für gemeldete Bedenken bleibt verantwortungsvolle KI bloß ein Leitbild. Deshalb konzentriert sich diese Domäne auf zwei Controls mit hoher Hebelwirkung.

A.3.2 fordert definierte und zugewiesene KI-Rollen und Verantwortlichkeiten. Das betrifft nicht nur eine zentrale “AI Governance”-Rolle. In der Praxis geht es um eine Matrix: Wer verantwortet Freigaben, wer führt Risiko- oder Impact Assessments durch, wer prüft Datenquellen, wer bewertet Lieferanten, wer entscheidet bei Vorfällen, wer darf Änderungen an Modellen oder Prompt-Setups freigeben, und wer berichtet an die Leitung? Gerade in mittelständischen Organisationen ist eine saubere Rollenverteilung wichtiger als neue Jobtitel.

A.3.3 verlangt einen Prozess zur Meldung von Bedenken über die Rolle der Organisation in Bezug auf ein KI-System über den gesamten Lifecycle hinweg. Das betrifft interne Hinweise ebenso wie Eskalationen aus Betrieb, Datenschutz, Qualität, HR oder Kundenservice. Praktisch kann dieser Prozess an bestehende Hinweisgeber-, Incident- oder Qualitätskanäle angeschlossen werden. Entscheidend ist, dass KI-bezogene Bedenken nicht zwischen Ticketsystem, Mail-Postfach und Team-Chat verschwinden.

Die Relevanz für den EU AI Act ist hoch. Gerade bei Hochrisiko-KI nach Anhang III braucht es nachvollziehbare Rollen, Eskalationswege und Verantwortlichkeiten. Auch menschliche Aufsicht ist ohne organisatorische Zuweisung nicht belastbar. In Audits zeigt sich daher schnell, ob A.3 nur auf dem Organigramm existiert oder wirklich gelebt wird.

Ein typischer Fehler ist die Konzentration auf eine einzige “verantwortliche Person”. Das widerspricht der Realität. KI-Governance ist fast immer eine verteilte Aufgabe zwischen Management, Produkt, IT, Datenschutz, Recht, Einkauf und Fachbereich. A.3 verlangt deshalb keine Symbolfigur, sondern ein tragfähiges Verantwortungsmodell.

A.4 — Ressourcen für KI-Systeme

A.4 ist die Domäne für Bestandsaufnahme und Dokumentationsdisziplin. Die Kernaussage lautet: Wer seine Ressourcen nicht kennt, kann weder Risiken noch Verantwortlichkeiten oder Nachweise sauber steuern. Diese Domäne ist besonders wichtig, weil viele Organisationen zwar über Modelle und Tools sprechen, aber kaum belastbare Informationen zu Datenquellen, Rechenumgebungen, unterstützenden Werkzeugen oder Kompetenzen dokumentiert haben.

A.4.2 fordert die Dokumentation relevanter Ressourcen je Lifecycle-Phase und weiterer KI-bezogener Aktivitäten. Das ist der Kern eines AI Asset Inventory. Erfasst werden sollten mindestens Systemname, Zweck, fachliche Eigentümer, betroffene Prozesse, Lifecycle-Status, kritische Abhängigkeiten und regulatorische Einordnung. Im Projekt-Research wird gerade dieses Inventar als Schlüssel für die Zuordnung zu Anhang-III-Kategorien des EU AI Act beschrieben.

A.4.3 betrifft Datenressourcen. Hier wird dokumentiert, welche Daten verwendet werden, woher sie kommen, wofür sie genutzt werden, wie sie klassifiziert sind und welche Risiken mit ihnen verbunden sind. Diese Dokumentation ist die Brücke zu A.7.

A.4.4 betrifft Tooling-Ressourcen. Dazu zählen Entwicklungsumgebungen, Annotationstools, Prompt-Plattformen, Evaluationswerkzeuge, MLOps-Komponenten oder externe APIs. Viele Risiken entstehen nicht nur im Modell selbst, sondern in der umgebenden Toolchain.

A.4.5 fokussiert System- und Rechenressourcen. Das ist relevant für Hosting, Cloud-Abhängigkeiten, Zugriffsmodelle, Protokollierung, Skalierung und Business Continuity. Gerade bei ausgelagerten Setups ist diese Transparenz nötig, um Verantwortlichkeiten gegenüber Drittparteien sauber zuzuordnen.

A.4.6 betrifft Humanressourcen und Kompetenzen über Entwicklung, Deployment, Betrieb, Änderung, Wartung, Übergabe und Stilllegung hinweg. Dieses Control ist mehr als eine Schulungsliste. Es verlangt Sichtbarkeit darüber, welche Personen oder Rollen welche Fähigkeiten für KI tatsächlich besitzen. Wer dieses Thema vertiefen will, findet den Grundlagenbezug in /glossar/ki-managementsystem/ und in unserem Beitrag zu ISO 42001 im Überblick.

Für KMU ist A.4 oft der schnellste Hebel mit dem größten Nutzen. Ein sauberes Inventar räumt sehr schnell drei typische Probleme aus dem Weg: unbekannte Schatten-KI, unklare Zuständigkeiten und fehlende Evidenz im Audit.

A.5 — Bewertung der Auswirkungen von KI-Systemen

A.5 ist der vielleicht am meisten unterschätzte Teil von Annex A. Die Kernaussage lautet: Die Norm will nicht nur technische oder organisatorische Risiken sehen, sondern auch die möglichen Auswirkungen des KI-Systems auf Individuen, Gruppen und die Gesellschaft. Genau hier zeigt sich der Unterschied zwischen einer engen IT-Perspektive und echter KI-Governance.

A.5.2 verlangt einen Prozess für AI Impact Assessments. Das bedeutet: Die Organisation muss definieren, wann ein Impact Assessment erforderlich ist, welche Fragen geprüft werden, wer beteiligt wird, welche Kriterien gelten und wie Ergebnisse freigegeben werden. Ein gutes AIIA ähnelt nicht einfach einer IT-Risikobewertung, sondern betrachtet Folgen für Fairness, Transparenz, Autonomie, Sicherheit, Fehlgebrauch und gesellschaftliche Wirkungen.

A.5.3 fordert die Dokumentation und Aufbewahrung der Ergebnisse. Damit wird das Impact Assessment prüfbar und wiederverwendbar. Praktisch sollten Sie Version, Datum, Scope, Betroffene, identifizierte negative und positive Auswirkungen, Maßnahmen, Restrisiken und Freigabe dokumentieren.

A.5.4 verlangt die Bewertung von Auswirkungen auf Individuen oder Gruppen. Das ist der direkte Anknüpfungspunkt für Diskriminierung, Fehlentscheidungen, unfaire Behandlung, Fehlklassifikation oder Eingriffe in Rechte und Chancen. Gerade für HR, Scoring, Bildung, Zugang zu Leistungen oder sicherheitsrelevante Kontexte ist dieser Control essenziell. Ergänzend lohnt sich der vertiefende Beitrag zu ISO 42001 Bias und Fairness.

A.5.5 verlangt die Bewertung gesellschaftlicher Auswirkungen. Das erweitert die Perspektive über Einzelfälle hinaus. Gesellschaftliche Auswirkungen können etwa verstärkte Intransparenz, Vertrauensverlust, systematische Benachteiligung, Manipulationsanreize oder problematische Skaleneffekte sein. Dieser Control ist besonders relevant, wenn KI-Systeme breite Nutzergruppen, öffentliche Dienste oder sensible Informationsräume beeinflussen.

Für die Verbindung zum EU AI Act ist A.5 hochrelevant, weil sich hier die Brücke zu Grundrechten, Risikobetrachtung und Folgen für betroffene Personen schließen lässt. Gleichzeitig geht A.5 konzeptionell breiter als viele rein rechtliche Compliance-Checks. In der Praxis ist genau das wertvoll: Sie identifizieren Risiken früher, als wenn Sie nur die Frage “Ist das hochriskant?” stellen.

A.6 — KI-System-Lifecycle

A.6 ist das operative Zentrum von Annex A. Die Kernaussage lautet: Verantwortungsvolle KI entsteht nicht an einem einzigen Kontrollpunkt, sondern über Anforderungen, Entwicklung, Prüfung, Deployment, Betrieb, Dokumentation und Logging hinweg. Diese Domäne ist deshalb die größte des Annexes und enthält neun Controls.

A.6.1.2 verlangt dokumentierte Ziele für verantwortungsvolle Entwicklung. Das verhindert, dass Entwicklung ausschließlich nach Geschwindigkeit, Kosten oder Accuracy optimiert wird. Ziele können beispielsweise Fairness-Schwellen, Transparenzanforderungen, Sicherheitskriterien oder Anforderungen an menschliche Eingriffsmöglichkeiten umfassen.

A.6.1.3 verlangt dokumentierte Prozesse für verantwortungsvolle Entwicklung. Hier geht es um die konkrete Entwicklungslogik: Welche Reviews finden statt, wann sind Tests Pflicht, welche Freigaben sind nötig, welche Rollen müssen eingebunden werden?

A.6.2.2 fordert Anforderungen und Spezifikationen für neue oder wesentlich geänderte KI-Systeme. Ohne diese Anforderungsebene werden spätere Validierung und Auditierbarkeit schwach. Unternehmen müssen definieren, was das System leisten soll, welche Grenzen gelten und welche Kriterien für Akzeptanz und Sicherheit relevant sind.

A.6.2.3 verpflichtet zur Dokumentation von Design und Entwicklung. Das ist wichtig für Nachvollziehbarkeit, Verantwortungszuordnung und spätere Änderungen.

A.6.2.4 verlangt Verifikation und Validierung. Praktisch heißt das: Sie definieren Testarten, Testkriterien, Abnahmekriterien und den Kontext, in dem Ergebnisse bewertet werden. Genau hier liegt eine starke inhaltliche Nähe zu Art. 15 EU-VO 2024/1689 bei Genauigkeit, Robustheit und Cybersicherheit.

A.6.2.5 betrifft das Deployment. Ein KI-System darf nicht einfach live gehen, nur weil das Modell technisch lauffähig ist. Nötig sind ein definierter Deployment-Plan, Vorbedingungen, Freigaben und Abnahme.

A.6.2.6 adressiert Betrieb und Monitoring. Die Norm nennt ausdrücklich Monitoring, Reparaturen, Updates und Support. Das zeigt: Governance endet nicht mit Go-live.

A.6.2.7 fordert technische Dokumentation für relevante interessierte Parteien. Dazu können Nutzer, Partner oder Aufsichtsbehörden gehören. Diese Anforderung ist besonders wichtig für die Brücke zu Dokumentationspflichten im EU AI Act.

A.6.2.8 betrifft Ereignisprotokolle. Gerade hier zeigt das Research im Projekt eine wesentliche Lücke zum EU AI Act: ISO 42001 fordert die Bestimmung geeigneter Logging-Phasen, während Art. 12 EU AI Act bei Hochrisiko-KI deutlich spezifischer und technischer ist. Annex A hilft also, das Thema zu verankern, ersetzt aber keine detaillierte regulatorische Logging-Architektur.

Für Unternehmen mit eigenem Development oder materialreichen Anpassungen ist A.6 meist der ressourcenintensivste Block. Für reine Deployments eingekaufter Systeme ist er dennoch relevant, nur verschieben sich die Schwerpunkte stärker zu Spezifikation, Abnahme, Betrieb, Dokumentation und Monitoring.

A.7 — Daten für KI-Systeme

A.7 bündelt die Daten-Governance des Standards. Die Kernaussage lautet: Datenqualität, Datenherkunft und Datenaufbereitung sind keine Nebenthemen, sondern Kernkontrollen für KI-Risiken. Gerade weil der EU AI Act in Art. 10 hohe Anforderungen an Daten-Governance stellt, ist A.7 einer der praktisch wichtigsten Teile von Annex A.

A.7.2 verlangt definierte, dokumentierte und implementierte Datenmanagementprozesse für Entwicklung und Verbesserung von KI-Systemen. Es geht also nicht nur um Training im engen Sinn, sondern um einen beherrschten Umgang mit Daten über Änderungs- und Verbesserungszyklen hinweg.

A.7.3 adressiert Akquisition und Auswahl von Daten. Unternehmen müssen dokumentieren, wie Daten ausgewählt werden, woher sie stammen und nach welchen Kriterien sie geeignet sind. Das ist zentral für Lizenzfragen, Bias-Risiken, Zweckbindung und Repräsentativität.

A.7.4 verlangt Anforderungen an Datenqualität und deren Einhaltung. Datenqualität ist im KI-Kontext mehr als technische Vollständigkeit. Relevante Kriterien sind etwa Genauigkeit, Konsistenz, Aktualität, Repräsentativität und Eignung für den konkreten Einsatzkontext.

A.7.5 betrifft Datenherkunft und Datenlinie. Dieses Control ist in Audits oft Gold wert, weil es nachvollziehbar macht, wo Daten herkommen, wie sie verändert wurden und in welcher Version sie in einem System oder Training verwendet wurden.

A.7.6 verlangt Kriterien und Methoden für Datenaufbereitung. Das schließt Bereinigung, Transformation, Labeling, Feature Engineering oder Filterung ein. Genau an diesen Stellen entstehen oft verdeckte Verzerrungen.

Für viele Organisationen ist A.7 der Punkt, an dem abstrakte Governance plötzlich operativ wird. Sie müssen definieren, welche Daten überhaupt zulässig sind, wie bias-sensible Merkmale geprüft werden, welche Qualitätsgrenzen gelten und wie Änderungen an Datenquellen kontrolliert werden. Wer das vertiefen will, findet Anschluss in den Beiträgen ISO 42001 Bias und Fairness und /glossar/iso-42001/.

A.8 — Information für interessierte Parteien

A.8 stellt sicher, dass relevante interessierte Parteien die nötigen Informationen erhalten, um Risiken und Auswirkungen eines KI-Systems zu verstehen und zu bewerten. Die Kernaussage lautet: Transparenz ist kein weiches Kommunikationsthema, sondern eine formale Kontrollanforderung.

A.8.2 verlangt Systemdokumentation und Informationen für Nutzer. Das betrifft Bedienung, Grenzen, Voraussetzungen, Risiken, Fehlermöglichkeiten und gegebenenfalls Eskalationswege. Gerade bei KI-Systemen mit Entscheidungsunterstützung ist unklare Nutzerinformation ein direkter Risikotreiber.

A.8.3 verlangt Fähigkeiten für externe Meldungen zu negativen Auswirkungen. Nutzer, Kunden oder andere Betroffene müssen adverse Impacts melden können. Praktisch kann das über Support-Prozesse, Beschwerdekanäle, Formulare oder Ansprechpartner erfolgen.

A.8.4 fordert einen Kommunikationsplan für Vorfälle. Damit wird festgelegt, wer wann welche Informationen an Nutzer oder andere relevante Parteien weitergibt. Diese Logik ist für sicherheitskritische oder hochriskante Kontexte besonders wichtig.

A.8.5 verlangt dokumentierte Informationspflichten gegenüber interessierten Parteien. Dazu gehören je nach Kontext Nutzer, Kunden, Partner, Management, Prüfstellen oder Behörden. Dieser Control zwingt Organisationen dazu, Transparenzpflichten systematisch zu ordnen, statt sie bei Bedarf improvisiert zu erfüllen.

Die Nähe zum EU AI Act ist offensichtlich. Transparenzpflichten, Informationszugang und Incident-Kommunikation sind auch dort zentrale Themen. Annex A ist hier ein guter Governance-Rahmen, ersetzt aber keine genaue Rechtsanalyse zu den spezifischen Pflichten einzelner Rollen.

A.9 — Nutzung von KI-Systemen

A.9 richtet den Blick auf den tatsächlichen Einsatz der Systeme. Die Kernaussage lautet: Selbst ein gut entwickeltes KI-System kann problematisch werden, wenn es falsch genutzt, außerhalb des vorgesehenen Zwecks eingesetzt oder ohne wirksame menschliche Aufsicht betrieben wird.

A.9.2 verlangt dokumentierte Prozesse für verantwortungsvolle Nutzung. Dazu zählen Freigaberegeln, Nutzungsgrenzen, Review-Pflichten, Eskalation, Überwachung und Schulungsbezug. Besonders bei generativer KI ist das entscheidend, weil viele Risiken erst im Nutzungskontext entstehen.

A.9.3 verlangt dokumentierte Ziele für verantwortungsvolle Nutzung. Damit wird festgelegt, welche Nutzungsergebnisse gewollt sind und welche Governance-Ziele eingehalten werden müssen. Das kann sich auf Qualität, Nachvollziehbarkeit, menschliche Freigabe oder Missbrauchsprävention beziehen.

A.9.4 fordert die Nutzung gemäß beabsichtigtem Verwendungszweck. Dieser Control ist hochrelevant, weil viele reale Vorfälle genau aus Zweckverschiebungen entstehen. Ein internes Assistenzsystem wird plötzlich für leistungsrelevante Bewertungen genutzt, ein KI-Tool für Texthilfen wird faktisch zum automatisierten Entscheider. Governance-seitig ist das ein klassischer Drift vom “intended use” zum problematischen Schatteneinsatz.

Der stärkste fachliche Anschluss liegt hier beim Thema Human Oversight. Menschliche Aufsicht ist nicht nur ein Development-Thema, sondern vor allem eine Nutzungsfrage: Wann muss geprüft, übersteuert, dokumentiert oder eskaliert werden? A.9 ist damit die Domäne, in der Policies und Betriebsrealität zusammenlaufen.

A.10 — Beziehungen mit Dritten

A.10 macht klar, dass KI-Governance nicht an der Unternehmensgrenze endet. Die Kernaussage lautet: Wer externe Modelle, Datensätze, APIs, Plattformen, Integratoren oder Beratungspartner nutzt, muss Verantwortlichkeiten und Risiken ausdrücklich steuern. Gerade für moderne KI-Stacks ist A.10 daher selten optional.

A.10.2 verlangt die Zuweisung von Verantwortlichkeiten zwischen Organisation, Partnern, Lieferanten, Kunden und sonstigen Dritten. Das verhindert die typische Grauzone “dafür ist der Anbieter zuständig”. In der Praxis müssen Unternehmen sauber trennen: Wer entwickelt, wer hostet, wer deployt, wer überwacht, wer dokumentiert, wer reagiert bei Vorfällen?

A.10.3 fordert einen Lieferantenprozess, der sicherstellt, dass eingekaufte Leistungen mit dem eigenen Ansatz zur verantwortungsvollen KI-Entwicklung und -Nutzung vereinbar sind. Das ist mehr als klassisches Vendor Management. Relevante Prüfpunkte sind etwa Datenherkunft, Modellupdates, Logging, Transparenz, Sicherheitsmaßnahmen, Bias-Risiken, Support, Auditierbarkeit und Subunternehmerstruktur.

A.10.4 fordert, dass Kundenerwartungen und Kundenbedürfnisse berücksichtigt werden. Das ist insbesondere für Anbieter und Integratoren wichtig. Wenn Kunden Transparenz, Einschränkungen, Erklärbarkeit oder vertragliche Zusicherungen erwarten, muss diese Erwartung in die Governance-Logik zurückgespielt werden.

Research im Projekt zeigt, dass A.10 besonders stark auf Art. 17 EU AI Act einzahlt, weil ein belastbares Qualitätsmanagement für Hochrisiko-KI ohne Lieferantensteuerung in der Praxis nicht funktioniert. Wer viele externe Komponenten nutzt, sollte A.10 deshalb nicht als Beschaffungsanhang lesen, sondern als Kernteil seines AIMS.

Statement of Applicability (SoA) erstellen

Ein Statement of Applicability erstellen heißt: Sie übersetzen Annex A von einer Referenzliste in ein steuerbares, auditierbares Arbeitsdokument. Die Kernaussage lautet deshalb: Das SoA ist nicht bloß eine Tabelle für Auditoren, sondern das zentrale Steuerungsdokument für die Auswahl, Begründung und Evidenz Ihrer Controls.

Ein belastbares SoA enthält mindestens diese Spalten:

Die Reihenfolge für die Erstellung ist pragmatisch:

1. Definieren Sie zuerst Scope und KI-Inventar.
2. Prüfen Sie danach alle 38 Controls einzeln.
3. Bewerten Sie je Control, ob er für Ihre Rolle, Ihre Systeme und Ihre Risiken anwendbar ist.
4. Begründen Sie Ausschlüsse konkret, nicht pauschal.
5. Verknüpfen Sie jeden anwendbaren Control mit echter Evidenz.

Typische gute Begründungen sind spezifisch. “Nicht relevant” reicht fast nie. Belastbar wäre eher: “A.6.1.3 nur teilweise anwendbar, weil keine Eigenentwicklung erfolgt; für eingekaufte Systeme werden stattdessen Spezifikation, Abnahme, Nutzungsfreigabe und Lieferantenprüfung dokumentiert.” Ebenso zulässig ist Delegation, wenn sie sauber belegt wird, etwa bei Cloud- oder Plattformleistungen. Aber auch dann bleibt die Organisation accountable.

Für KMU ist das SoA oft der beste Priorisierungshebel. Nicht jeder Control braucht denselben Reifegrad im ersten Monat. Ein kleines Unternehmen kann mit KI-Policy, Rollenmatrix, Inventar, AIIA-Prozess, Datenqualitätsregeln, Monitoring-Grundlogik und Lieferantenprüfung starten und komplexere Automatisierung später ausbauen. Genau diese Staffelung muss das SoA sichtbar machen.

Wenn Sie dazu eine vertiefte Anleitung suchen, lesen Sie ergänzend den Beitrag ISO 42001 Statement of Applicability. Wenn Sie aus dem Überblick direkt in die Praxis gehen möchten, ist eine spezialisierte ISO-42001-Schulung der schnellste Weg, um Annex A, SoA und die Verbindung zum EU AI Act teamfähig aufzusetzen.

FAQ

Müssen alle 38 Controls umgesetzt werden?

Nein. Alle 38 Controls müssen geprüft werden, aber nicht jeder Control ist automatisch anwendbar. Die Norm arbeitet risikobasiert. Entscheidend ist, dass Sie im SoA sauber dokumentieren, welche Controls gelten, welche ausgeschlossen werden und warum.

Was ist der Unterschied zwischen Annex A und Annex B?

Annex A enthält die normativen Referenz-Controls. Annex B enthält die Implementierungshinweise dazu. Vereinfacht gesagt: Annex A beschreibt den Kontrollkatalog, Annex B hilft bei der Umsetzung. Im Ticket-Kontext ist außerdem wichtig, dass Annex B mit 44 Implementierungshinweisen einen deutlich operativeren Blick auf dieselben Themen liefert.

Wie erstellt man ein Statement of Applicability?

Sie erstellen ein SoA, indem Sie Scope, KI-Systeme und Risiken bestimmen und danach alle 38 Controls systematisch prüfen. Für jeden Control dokumentieren Sie Anwendbarkeit, Begründung, Status, Verantwortlichkeit und Evidenz. Dadurch wird Ihre Annex-A-Auswahl auditierbar.

Welche Controls sind am wichtigsten für KMU?

Für KMU sind in der Regel A.2, A.3, A.4, A.5, die zentralen A.6-Lifecycle-Controls, A.7 zur Datenqualität, A.9 zur verantwortungsvollen Nutzung und A.10 für Lieferanten am wichtigsten. Diese Controls erzeugen mit relativ wenig Bürokratie den größten Governance-Effekt.

Wie mappen die Controls auf den EU AI Act?

Die stärksten Überschneidungen liegen bei Risikomanagement, Daten-Governance, Transparenz, Human Oversight, Monitoring und Qualitätsmanagement. Das betrifft vor allem Art. 9, 10, 14 und 17 EU-VO 2024/1689. Annex A hilft also stark bei der organisatorischen Umsetzung, ersetzt aber weder Verbotsprüfung noch Konformitätsbewertung.

Was sollten Unternehmen nach diesem Artikel als Nächstes tun?

Der sinnvollste nächste Schritt ist fast immer ein kleines Annex-A-Arbeitsset: KI-Inventar aufbauen, KI-Policy festlegen, Rollen zuweisen, AIIA-Prozess definieren und ein erstes SoA anlegen. Danach können Sie die relevanten Controls priorisiert vertiefen, statt die ganze Norm auf einmal umzusetzen.

Wenn Sie Annex A nicht nur verstehen, sondern im Unternehmen praktisch anwenden möchten, starten Sie mit unserer ISO-42001-Schulung. Für die strategische Einordnung helfen außerdem der ISO-42001-Leitfaden, der Überblick Was ist ISO 42001? und der Beitrag ISO 42001 und EU AI Act.