Klausel 6: Planning

Klausel 6 ist das Herzstück von ISO 42001. Hier entstehen die Dokumente, die dein AIMS von einer Absichtserklärung in ein funktionierendes System verwandeln.

---

Worum es geht

Planung bedeutet in ISO 42001 nicht "wir machen mal einen Plan". Es bedeutet: Du identifizierst systematisch, was schiefgehen kann, bewertest die Auswirkungen, definierst Gegenmaßnahmen und setzt dir messbare Ziele. Vier zentrale Dokumente entstehen in dieser Klausel:

1. Das AI Risk Assessment (Risikobewertung)
2. Der Risk Treatment Plan (Maßnahmenplan)
3. Das Statement of Applicability, kurz SoA (welche Controls du anwendest)
4. Das AI System Impact Assessment (Folgenabschätzung)

Ohne diese Dokumente hat dein AIMS kein Rückgrat. Klausel 6 produziert mehr Pflichtdokumente als jede andere Klausel.

---

6.1.1 Risks and Opportunities: Was kann passieren?

Was du tun musst

Identifiziere Risiken und Chancen, die adressiert werden müssen. Die Norm betont beides: nicht nur was schiefgehen kann, sondern auch welche Möglichkeiten sich ergeben.

Viele Unternehmen konzentrieren sich ausschließlich auf Risiken und vergessen die Chancen. Aber die Norm fragt auch: Welche positiven Effekte kann dein AIMS erzielen? Zum Beispiel: Verbessertes Kundenvertrauen durch transparente KI-Governance. Oder: Wettbewerbsvorteil durch frühzeitige Zertifizierung.

Die geplanten Maßnahmen müssen in deine AIMS-Prozesse integriert und auf Wirksamkeit evaluiert werden. Eine Maßnahme, die im Plan steht, aber nie umgesetzt wird, ist wertlos.

---

6.1.2 AI Risk Assessment: Welche Risiken hat deine KI?

Was du tun musst

Du musst einen dokumentierten Prozess für die AI-Risikobewertung definieren und beibehalten. Dieser Prozess braucht drei Bestandteile:

Risikokriterien legen fest, wie du Risiken bewertest. Was ist ein hohes Risiko, was ein niedriges? Diese Kriterien müssen nachvollziehbar aus deinem Kontext (Klausel 4.1) und den Anforderungen deiner Stakeholder (Klausel 4.2) abgeleitet sein. Wenn du in der Automobilindustrie bist, wiegen Risiken für die Produktqualität schwerer als in einem Beratungsunternehmen.

Eine Methodik beschreibt, wie du vorgehst. Welche Skalen verwendest du? Wer bewertet? Wie oft? Das muss konsistent und wiederholbar sein.

Dokumentierte Ergebnisse sind Pflicht. Die Norm sagt explizit: "retain documented information of the results." Ohne schriftliches Risk Assessment gibt es eine Major Nonconformity.

Der Unterschied zum "normalen" Risikomanagement

Wenn du schon ISO 27001 hast, kennst du Risk Assessments. Der Unterschied bei ISO 42001: Die Risiken beziehen sich spezifisch auf KI-Systeme. Nicht auf IT-Infrastruktur allgemein, sondern auf Fragen wie: Was passiert, wenn das Modell driftet? Was wenn die Trainingsdaten Bias enthalten? Was wenn der AI Provider sein Modell ändert, ohne dich zu informieren?

Regelmäßige Durchführung

Risk Assessments sind keine einmalige Aktion. Die Norm fordert, dass du sie in geplanten Intervallen durchführst. Wie oft, entscheidest du. Aber "einmal 2024 gemacht und seitdem nicht mehr angefasst" reicht nicht.

---

6.1.3 AI Risk Treatment: Was tust du dagegen?

Was du tun musst

Für jedes identifizierte Risiko definierst du eine Behandlungsmaßnahme. Das Ergebnis ist der Risk Treatment Plan, ein Dokument, das zeigt, welches Risiko du wie behandelst, wer verantwortlich ist und bis wann.

Das Statement of Applicability (SoA)

Das SoA ist eines der wichtigsten Dokumente in deinem AIMS. Es listet alle 38 Controls aus Annex A auf und sagt für jede: Wenden wir an, oder wenden wir nicht an. Für jede, die du nicht anwendest, musst du begründen warum.

Das SoA muss durch das Top-Management genehmigt werden. Nicht durch den KI-Beauftragten, nicht durch die IT-Leitung. Die Geschäftsführung gibt das SoA frei.

Control-Auswahl muss risiko-getrieben sein

Die Controls, die du im SoA auswählst, müssen sich aus deinem Risk Assessment ableiten. Du wendest einen Control nicht an, "weil er in der Norm steht", sondern weil er ein identifiziertes Risiko behandelt. Umgekehrt: Wenn du ein Risiko identifiziert hast, aber keinen passenden Control ausgewählt hast, fehlt die Verbindung.

Was viele falsch machen

Kein SoA vorhanden. Ohne Statement of Applicability fehlt die zentrale Übersicht über deine Controls.

SoA ohne Begründung für Ausschlüsse. "Control A.7.3 nicht anwendbar" reicht nicht. Du musst sagen warum.

SoA nicht durch Top-Management genehmigt. Das ist eine explizite Anforderung.

Controls ohne Risikobezug. Wenn die Control-Auswahl nicht erkennbar aus dem Risk Assessment abgeleitet ist, fehlt die Systematik.

---

6.1.4 AI System Impact Assessment: Wen betrifft deine KI?

Was du tun musst

Neben dem Risk Assessment musst du ein Impact Assessment durchführen. Der Unterschied ist entscheidend:

Risk Assessment fragt: Was sind die Risiken für deine Organisation? Impact Assessment fragt: Was sind die Auswirkungen auf Individuen, Gruppen und die Gesellschaft?

Das Risk Assessment schützt dich. Das Impact Assessment schützt andere.

Wenn deine Qualitätskontrolle ein fehlerhaftes Bauteil durchlässt, ist das ein Risiko für dein Unternehmen (Haftung, Reputation). Aber es ist auch eine Auswirkung auf den Endverbraucher (Sicherheit). Beides muss bewertet werden, getrennt.

Was viele falsch machen

Risk Assessment und Impact Assessment vermischt. Beide in ein Dokument zu packen ist erlaubt, aber die Unterscheidung muss erkennbar sein. Risiken für die Organisation und Auswirkungen auf Betroffene sind zwei verschiedene Perspektiven.

Impact Assessment fehlt komplett. Viele Unternehmen machen ein Risk Assessment, vergessen aber das Impact Assessment. Beides ist Pflicht.

→ So hat es die Musterfirma gemacht: Risk Register und SoA ansehen

---

6.2 AI Objectives: Was willst du erreichen?

Was du tun musst

Du musst messbare AI Objectives definieren. Diese Ziele müssen zur AI Policy passen und konkret genug sein, um ihren Fortschritt messen zu können.

Gute AI Objectives folgen dem SMART-Prinzip: spezifisch, messbar, erreichbar, relevant, terminiert. "Wir wollen verantwortungsvolle KI" ist kein Objective. "Bis Q3 2026 sind alle drei KI-Systeme im Risk Register erfasst und bewertet" ist ein Objective.

Du musst auch festlegen, wer verantwortlich ist, welche Ressourcen nötig sind und wie du den Fortschritt misst.

---

6.3 Planning of Changes: Änderungen kontrollieren

Was du tun musst

Wenn du Änderungen an deinem AIMS planst, müssen diese kontrolliert durchgeführt werden. Das gilt für geplante Änderungen (neues KI-System, neuer Provider, Scope-Erweiterung) genauso wie für unbeabsichtigte Änderungen (Model Drift, Datenschieflagen, Personalwechsel).

Viele Unternehmen haben einen Prozess für geplante Änderungen, aber keinen für unbeabsichtigte. Genau dort liegen die Risiken. Ein Modell, das über Monate langsam schlechter wird, weil sich die Eingabedaten verändert haben, ist eine unbeabsichtigte Änderung. Wenn du keinen Mechanismus hast, der das erkennt, hast du eine Lücke.

---

Zusammenfassung

| Bereich | Kernfrage | Documented Information? | |---|---|---| | 6.1.1 Risks & Opportunities | Was kann passieren? | Nein | | 6.1.2 Risk Assessment | Welche Risiken hat deine KI? | Ja. Pflicht. | | 6.1.3 Risk Treatment + SoA | Was tust du dagegen? | Ja. Pflicht. | | 6.1.4 Impact Assessment | Wen betrifft deine KI? | Ja. Pflicht. | | 6.2 Objectives | Was willst du erreichen? | Ja (als Zieldokumentation) | | 6.3 Changes | Wie kontrollierst du Änderungen? | Nein, aber Prozess nötig |

→ Weiter: Klausel 7, Unterstützung → Zurück zur Übersicht

---

Begriffe in diesem Artikel: AI Risk Assessment, Risk Treatment Plan, Statement of Applicability (SoA), AI System Impact Assessment, AI Objectives, Controls, Annex A, Model Drift, Bias, Major Nonconformity, SMART, Planning of Changes