ISO 42001 Statement of Applicability: die Landkarte des AIMS

Wer ein KI-Managementsystem nach ISO/IEC 42001 aufbaut, stößt früher oder später auf ein Dokument, das mehr Gewicht trägt als sein unscheinbarer Name vermuten lässt: das Statement of Applicability, kurz SoA. Es ist nicht bloß eine Anlage zur Zertifizierung, sondern die Landkarte des gesamten Systems — die Stelle, an der eine Organisation verbindlich erklärt, welche Maßnahmen sie anwendet, welche sie ausschließt und warum. Ein Auditor, der ein AIMS prüft, beginnt fast immer hier. Und ein AIMS, dessen SoA nicht mit der gelebten Realität übereinstimmt, ist unabhängig von allen guten Absichten angreifbar.

Was das SoA ist — und was es nicht ist

ISO/IEC 42001:2023 verlangt das Statement of Applicability in Clause 6.1.3, im Kontext der KI-Risikobehandlung. Nachdem eine Organisation ihre KI-bezogenen Risiken bewertet hat, muss sie entscheiden, wie sie diese behandelt — und dazu die Referenzmaßnahmen aus Annex A der Norm heranziehen. Das SoA dokumentiert das Ergebnis dieser Entscheidung: Für jede Maßnahme des Anhangs wird festgehalten, ob sie anwendbar ist, ob sie umgesetzt wird und, im Fall eines Ausschlusses, mit welcher Begründung.

Damit ist das SoA kein Risikoregister und kein Maßnahmenplan. Das Risikoregister erfasst, was schiefgehen kann; der Maßnahmenplan beschreibt, wer bis wann etwas tut. Das SoA steht dazwischen und beantwortet eine andere Frage: Welche Kontrollen gelten für uns überhaupt — und stehen wir dazu? Es ist die verbindliche Selbstauskunft der Organisation über den Umfang ihres eigenen Kontrollrahmens. Genau deshalb ist es das Dokument, an dem sich Konsistenz oder Widerspruch eines AIMS am schnellsten zeigt.

Annex A als Ausgangspunkt, nicht als Pflichtkatalog

Ein verbreitetes Missverständnis lautet, Annex A sei eine Liste, die man vollständig abhaken müsse. Das ist nicht der Fall. Annex A liefert Referenz-Kontrollziele und -Kontrollen; Annex B ergänzt sie mit Umsetzungsleitlinien. Die Norm erwartet, dass eine Organisation begründet auswählt — nicht, dass sie alles undifferenziert übernimmt. Eine Maßnahme darf ausgeschlossen werden, wenn sie im konkreten Kontext nicht einschlägig ist. Ein Unternehmen, das ausschließlich fremdbezogene KI-Systeme betreibt und keine eigenen Modelle entwickelt, wird Kontrollen rund um den Entwicklungslebenszyklus anders behandeln als ein Anbieter, der Modelle selbst trainiert.

Entscheidend ist die Qualität der Begründung. „Nicht anwendbar" ohne nachvollziehbaren Grund ist die häufigste Schwachstelle, die in Audits auffällt. Jeder Ausschluss ist eine Behauptung über die eigene Organisation, und diese Behauptung muss belastbar sein. Wer eine Kontrolle streicht, weil er glaubt, sie sei aufwendig, produziert genau die Art von Aussage, die im Ernstfall nicht hält. Wer sie streicht, weil die zugrunde liegende Tätigkeit nachweislich nicht stattfindet, trifft eine saubere Scoping-Entscheidung.

Warum das SoA ein lebendes Dokument sein muss

Die eigentliche Herausforderung beginnt nach der ersten Erstellung. Ein SoA beschreibt einen Zustand — und Zustände verschieben sich. Ein Fachbereich führt ein neues KI-Feature ein, ein Dienstleister ändert die Architektur seines Modells, eine bislang ausgeschlossene Tätigkeit wird plötzlich real. In jedem dieser Fälle kann eine Aussage im SoA still veralten, ohne dass jemand es bemerkt. Und ein veraltetes SoA ist schlimmer als ein lückenhaftes: Es behauptet eine Ordnung, die es nicht mehr gibt.

Hier zeigt sich der Unterschied zwischen einem AIMS auf dem Papier und einem AIMS mit Reifegrad. Im Maturity-Modell AIMS (ISO 42001 × CMMI v3) ist nicht die Existenz des Dokuments das Reifekriterium, sondern seine belegbare Aktualität: Wird das SoA bei Änderungen im KI-Bestand nachgeführt? Lässt sich zeigen, wann eine Anwendbarkeitsentscheidung zuletzt überprüft wurde und auf welcher Grundlage? Eine Organisation auf einer höheren Reifestufe kann diese Fragen nicht mit Beteuerungen beantworten, sondern mit Aufzeichnungen. Das SoA wird damit vom statischen Zertifizierungsartefakt zu einem Nachweisinstrument, das seinen eigenen Zustand dokumentiert.

Die Brücke zum EU AI Act

Das SoA ist ein ISO-Instrument, kein Rechtsbegriff des EU AI Act. Dennoch berühren sich beide Welten an einer praktisch bedeutsamen Stelle. Wer ein AIMS nach ISO 42001 betreibt, schafft damit eine strukturierte Grundlage, um die Pflichten der Verordnung (EU) 2024/1689 — etwa Risikomanagement, Dokumentation und Aufsicht — organisatorisch zu verankern. Das SoA wird zur Nahtstelle: Es macht sichtbar, welche internen Kontrollen die Organisation überhaupt vorhält, an die sich regulatorische Anforderungen andocken lassen. Mit Blick auf die Durchsetzung des EU AI Act ab dem 02.12.2027 ist das kein akademischer Vorteil. Eine Organisation, die ihren Kontrollrahmen bereits sauber dokumentiert und pflegt, muss ihn nicht unter Zeitdruck rekonstruieren.

Wichtig bleibt die Trennschärfe: Ein gepflegtes SoA erfüllt den EU AI Act nicht automatisch, und ein ISO-42001-Zertifikat ist keine Konformitätsvermutung nach der Verordnung. Was das SoA leistet, ist etwas Grundlegenderes — es zwingt die Organisation, ihre eigenen Kontrollen zu benennen und zu diesen Aussagen zu stehen. Genau diese Nachweisbarkeit, nicht das Zertifikat als solches, ist die Substanz, auf der belastbares AI-Trust aufsetzt.

Was ein belastbares SoA auszeichnet

Ein SoA verdient sein Gewicht, wenn drei Dinge zusammenkommen: Vollständigkeit gegenüber Annex A, sodass keine Kontrolle unkommentiert bleibt; nachvollziehbare Begründungen für jeden Ein- und Ausschluss, die einem kritischen Dritten standhalten; und ein sichtbarer Bezug zur Realität, der zeigt, dass die dokumentierten Entscheidungen dem tatsächlichen KI-Bestand entsprechen und aktuell gehalten werden. Fehlt das dritte Element, bleibt selbst ein formal makelloses SoA eine Momentaufnahme, deren Halbwertszeit niemand kennt.

Wer den Aufbau eines AIMS plant, sollte das SoA deshalb nicht als letzten Schritt vor dem Audit behandeln, sondern als das Steuerungsdokument, um das sich die übrige Dokumentation gruppiert. Es ist der Ort, an dem eine Organisation am ehrlichsten über sich selbst Auskunft gibt — und damit der Ort, an dem sich Vertrauenswürdigkeit zuerst prüfen lässt.

Mehr dazu, wie sich ein KI-Kontrollrahmen von Aufgabenlisten zu belastbaren Nachweisen entwickelt, in unseren Beiträgen zur AEGIRA Trust-Platform: aegira.ai.