ISO 42001 KI-Risikoanalyse: So bewerten Sie KI-Risiken systematisch

ISO 42001 KI-Risikoanalyse

ISO 42001 KI-Risikoanalyse ist die systematische Identifikation, Bewertung und Behandlung von Risiken, die durch KI-Systeme entstehen — gefordert in Clause 6.1. Wer KI nur mit klassischem IT-Risikomanagement bewertet, übersieht oft Bias, Halluzinationen, menschliche Fehlanwendung, gesellschaftliche Auswirkungen und regulatorische Lücken. Genau deshalb braucht ein Artificial Intelligence Management System ein eigenes Vorgehen für 15 bis 30 typische KI-Risiken pro Organisation.

Letzte Aktualisierung: 23. März 2026

Wenn Sie ISO 42001 umsetzen wollen, sollten Sie die KI-Risikoanalyse nicht als Formalität behandeln. Sie ist der operative Kern von Planung, Priorisierung und Nachweisführung im AIMS. Der Standard verlangt in Clause 6.1 einen risikobasierten Ansatz, in Clause 6.1.4 zusätzlich eine Betrachtung von Auswirkungen auf Personen und Gesellschaft. Für den Gesamtüberblick lohnt sich zuerst der ISO-42001-Leitfaden. Für angrenzende Themen sind außerdem der Überblick zu ISO 42001, das Glossar zur Grundrechte-Folgenabschätzung und das Glossar zum Risikomanagement-System relevant.

Eine belastbare ISO-42001-KI-Risikoanalyse beantwortet immer dieselben Managementfragen: Welches KI-System wird in welchem Kontext eingesetzt? Welche Schäden können für Organisation, betroffene Personen und Gesellschaft entstehen? Wie wahrscheinlich sind diese Schäden? Welche Controls senken das Risiko auf ein akzeptables Niveau? Und welches Restrisiko akzeptiert die Organisation bewusst? Genau diese Fragen verbinden ISO 42001 mit Art. 9 der EU-VO 2024/1689 für Hochrisiko-KI.

KI-Risikoanalyse nach ISO 42001 — Clause 6.1

Clause 6.1 verlangt, dass Organisationen Risiken und Chancen für das AIMS bestimmen und behandeln. Bei KI bedeutet das mehr als klassische Bedrohungsanalyse für Server, Anwendungen und Daten. KI erzeugt Risiken aus Datenqualität, Modellverhalten, menschlicher Interaktion, Drittanbieterabhängigkeiten und gesellschaftlicher Wirkung. Deshalb reicht es nicht, nur Schwachstellen, Firewalls und Berechtigungen zu prüfen.

Der Unterschied zu klassischem Risikomanagement ist grundlegend. Traditionelle IT-Risikoanalysen fragen vor allem nach Vertraulichkeit, Integrität und Verfügbarkeit. Eine KI-Risikoanalyse muss zusätzlich beurteilen, ob ein System diskriminiert, halluziniert, falsche Sicherheit erzeugt, unzureichend erklärbar ist, menschliche Entscheidungen unzulässig verdrängt oder in sensiblen Prozessen ein unangemessenes Schadenspotenzial entfaltet. KI-Risiken sind dynamischer, weil Modelle driften, sich Anwendungsgrenzen verschieben und Nutzer durch Prompts oder Workarounds neue Fehlermuster erzeugen.

ISO 42001 arbeitet dabei bewusst managementsystemorientiert. Die Norm schreibt kein einziges starres Rechenmodell vor, sondern verlangt ein nachvollziehbares, dokumentiertes und wiederholbares Verfahren. Genau das ist der praktische Vorteil: Sie können Ihr Vorgehen an Reifegrad, Branche und Kritikalität anpassen, solange Scope, Bewertungslogik, Verantwortlichkeiten und Maßnahmenentscheidung sauber dokumentiert sind. Unternehmen mit bestehendem Risikomanagement-System oder mit ISO-27001-Erfahrung können daran anschließen, müssen aber KI-spezifische Kategorien ergänzen.

Clause 6.1 hat deshalb drei operative Funktionen. Erstens priorisiert sie Ressourcen, weil nicht jede KI-Anwendung dieselbe Prüftiefe braucht. Zweitens schafft sie Nachweise für Management, Revision, Kunden und gegebenenfalls Auditoren. Drittens verknüpft sie Risiken mit konkreten Controls aus Annex A. Ohne diese Verbindung bleibt das AIMS abstrakt. Mit ihr wird aus einer Risikoanalyse ein steuerbares System.

Eine typische Organisation dokumentiert dabei 15 bis 30 KI-Risiken, verteilt auf mehrere Kategorien und Anwendungsfälle. Das klingt aufwendig, ist aber realistischer als eine pauschale Risikobewertung auf Tool-Ebene. Ein Recruiting-Modell, ein interner GenAI-Assistent und eine KI-gestützte Qualitätsprüfung im Werk haben andere Schadenstypen, andere Betroffene und andere Maßnahmen. Eine gute Risikoanalyse trennt diese Kontexte sauber.

KI-spezifische Risikokategorien

KI-spezifische Risikokategorien sind der wichtigste Unterschied zwischen AIMS und klassischem IT-Risikomanagement. Wer sie nicht explizit benennt, bewertet zwangsläufig zu grob. In der Praxis haben sich sechs Kategorien besonders bewährt: Bias, Halluzination, Datenschutz, Sicherheit, gesellschaftliche Auswirkungen und Erklärbarkeit. Diese Kategorien decken die häufigsten Fehlannahmen im KI-Einsatz ab und lassen sich mit ISO 42001, ISO 31000 und NIST AI RMF konsistent verbinden.

Bias und Diskriminierung sind zentral, weil KI-Systeme historische Ungleichgewichte aus Trainingsdaten übernehmen oder durch Modellarchitektur und Zielmetriken verstärken können. Das Risiko ist besonders hoch in HR, Kreditvergabe, Versicherungen, Bildung, Gesundheitswesen und öffentlicher Verwaltung. Bewertet werden sollten hier mindestens betroffene Gruppen, Datensatzrepräsentation, Fairnessmetriken, Eskalationswege und menschliche Kontrollpunkte.

Halluzination und sachliche Fehlleistung betreffen vor allem generative KI, aber nicht nur sie. Ein Sprachmodell kann überzeugend falsche Aussagen erzeugen, ein Klassifikationsmodell kann Randfälle systematisch falsch zuordnen, ein Empfehlungssystem kann irreführende Prioritäten setzen. Relevant sind hier Schadensausmaß, Erkennbarkeit für Nutzer, Einsatzkontext, Plausibilitätsprüfung und Absicherungen gegen ungeprüfte Automatisierung.

Datenschutz und Daten-Governance bleiben auch im KI-Kontext ein Kernrisiko. Dabei geht es nicht nur um personenbezogene Daten, sondern auch um Datenherkunft, Zweckbindung, Aufbewahrungsfristen, Drittlandbezüge, Trainingsdatennutzung und Datenqualität. Die praktische Schnittstelle zur DSFA ist wichtig, aber eine KI-Risikoanalyse geht weiter. Sie fragt zusätzlich, welche Modellschlüsse aus Daten gezogen werden, ob sensible Merkmale indirekt rekonstruiert werden können und ob Datenflüsse dem tatsächlichen Use Case entsprechen.

Sicherheit umfasst mehr als klassische Cyberabwehr. KI-Systeme bringen zusätzliche Angriffsflächen mit: Prompt Injection, Model Theft, Data Poisoning, adversariale Eingaben, Manipulation von Bewertungsdaten oder missbräuchliche Nutzung über Schnittstellen. Die Risikofrage lautet deshalb nicht nur, ob das System gehackt werden kann, sondern auch, wie leicht sein Verhalten gezielt fehlgesteuert werden kann.

Gesellschaftliche Auswirkungen sind in ISO 42001 besonders relevant, weil Clause 6.1.4 über rein interne Unternehmensziele hinausweist. Zu betrachten sind etwa Einschränkungen menschlicher Autonomie, Exklusion bestimmter Gruppen, Desinformation, Umweltwirkungen, Marktverzerrungen oder Vertrauensverlust in Entscheidungsprozesse. Diese Ebene wird häufig übersehen, obwohl sie für die Legitimität und Akzeptanz von KI-Anwendungen entscheidend sein kann.

Erklärbarkeit und Nachvollziehbarkeit entscheiden darüber, ob Risiken überhaupt erkannt und kontrolliert werden können. Wenn ein KI-System nicht hinreichend erklärbar ist, sinkt die Qualität menschlicher Aufsicht, die Fehleranalyse wird schwieriger und Betroffene können Entscheidungen schlechter verstehen oder anfechten. Das ist besonders kritisch bei hochwirksamen Entscheidungen über Menschen.

Die folgende Übersicht zeigt typische Kategorien mit häufigen Schadenstypen:

Die praktische Konsequenz ist klar: Eine KI-Risikoanalyse muss mehrere Perspektiven zusammenführen. Fachbereich, Datenschutz, Informationssicherheit, Compliance und Technik sehen meist unterschiedliche Schadenstypen. Genau deshalb ist eine interdisziplinäre Bewertung fast immer besser als ein rein technisches Dokument aus dem Modellteam.

Methoden der KI-Risikobewertung

ISO 42001 schreibt keine einzelne Methode vor, verlangt aber ein robustes Verfahren. In der Praxis sind FMEA, Bow-Tie, NIST-AI-RMF-Mapping und die Ausrichtung an ISO 31000 besonders nützlich. Die beste Wahl hängt vom Ziel ab: Ursachen verstehen, Schadenspfade visualisieren, Governance strukturieren oder eine organisationsweite Bewertungslogik standardisieren.

FMEA eignet sich gut, wenn Sie Fehlerarten, Ursachen und Auswirkungen systematisch zerlegen wollen. Für KI-Systeme können Sie pro Use Case fragen: Welche Fehlfunktion tritt auf? Wodurch wird sie ausgelöst? Welche Konsequenz hat sie? Wie gut wird sie erkannt? Das ist vor allem für operative Anwendungsfälle nützlich, etwa bei Dokumentenklassifikation, Entscheidungsunterstützung oder Qualitätskontrolle. FMEA zwingt Teams dazu, nicht nur Schäden, sondern auch Entdeckbarkeit und Kontrollen mitzudenken.

Bow-Tie-Analysen sind hilfreich, wenn die Organisation klare Schadensereignisse visualisieren will. In der Mitte steht das Top Event, etwa "fehlerhafte KI-Entscheidung beeinflusst Personalentscheidung". Links werden Ursachen und präventive Barrieren dokumentiert, rechts mögliche Folgen und reaktive Barrieren. Diese Darstellung ist besonders wirksam im Management, weil sie komplexe KI-Risiken auf einer Seite sichtbar macht.

NIST AI RMF Mapping ist sinnvoll, wenn Sie eine Brücke zwischen operativer Risikoarbeit und Governance schlagen wollen. Die Funktionen Govern, Map, Measure und Manage ergänzen ISO 42001 sehr gut. Govern stützt Rollen und Policies, Map beschreibt Kontext und Stakeholder, Measure strukturiert Messung und Test, Manage verbindet Ergebnisse mit Maßnahmen und Restrisiko. Wer bereits mit NIST arbeitet, kann damit seine ISO-42001-Risikoanalyse methodisch schärfen.

ISO 31000 Alignment sorgt dafür, dass KI-Risiken nicht als Sonderwelt außerhalb des Unternehmens geführt werden. Die Grundlogik bleibt gleich: Kontext festlegen, Risiken identifizieren, analysieren, bewerten, behandeln, überwachen und kommunizieren. Der Unterschied liegt im Inhalt, nicht im Grundprozess. Das ist wichtig, weil Management, Revision und bestehende Gremien vertraute Strukturen benötigen.

In der Praxis ist eine Kombination oft am stärksten:

1. ISO 31000 als übergeordnete Governance-Struktur.
2. NIST AI RMF für KI-spezifische Analyse- und Bewertungsfragen.
3. FMEA oder Bow-Tie für einzelne kritische Use Cases.

Entscheidend ist weniger der Methodenname als die Nachvollziehbarkeit. Auditoren, Management und Fachbereiche müssen verstehen können, warum ein Risiko als hoch oder niedrig bewertet wurde. Eine 5-stufige Skala für Wahrscheinlichkeit und Auswirkung ist dafür meist ausreichend. Sie ist einfacher zu pflegen als komplizierte mathematische Modelle und ermöglicht trotzdem konsistente Priorisierung.

Ein praxistaugliches Beispiel: Ein interner GenAI-Assistent für Vertragsentwürfe wird nach FMEA bewertet. Fehlerart ist eine halluzinierte Rechtsaussage. Ursache sind fehlende Quellenbindung und unzureichende Prompt-Guidelines. Auswirkung ist ein rechtlich fehlerhafter Vertragsvorschlag. Präventive Maßnahmen sind RAG mit freigegebenen Quellen, verbindliche Reviewpflicht und klare Nutzungsgrenzen. Das Risiko sinkt dadurch nicht auf null, aber auf ein dokumentiert akzeptables Niveau.

KI-Risikoregister aufbauen

Ein KI-Risikoregister ist das operative Herzstück der ISO-42001-Risikoanalyse. Es übersetzt abstrakte Anforderungen in eine steuerbare Liste mit Verantwortlichkeiten, Bewertungen und Maßnahmen. Ohne Register bleibt das Risikomanagement in Präsentationen stecken. Mit Register entsteht ein belastbarer Nachweis für Management, interne Audits und externe Prüfungen.

Ein gutes Register enthält mindestens folgende Spalten: Risiko-ID, KI-System oder Use Case, Beschreibung des Risikos, Ursache, betroffene Stakeholder, bestehende Controls, Wahrscheinlichkeit, Auswirkung, Risikowert, Verantwortliche, geplante Maßnahmen, Restrisiko, Status und Review-Datum. Optional ergänzen viele Organisationen noch Rechtsbezug, Datenquellen, Anbieter, Kritikalität und Verweise auf Vorfälle oder Tests.

Die Bewertungslogik sollte einfach, aber verbindlich sein. In der Praxis bewährt sich eine 5-stufige Skala für Wahrscheinlichkeit und Auswirkung. Multipliziert ergeben beide Werte einen Risikowert zwischen 1 und 25. Das reicht für Priorisierung, wenn die Skalen sauber definiert sind:

Darauf aufbauend lässt sich eine einfache Risikomatrix festlegen:

Der Risikoappetit ist dabei unverzichtbar. Er beschreibt, welche Restbelastung die Organisation akzeptiert und bei welchen Schwellen ein Betrieb, ein Rollout oder eine Freigabe nicht zulässig ist. Ohne Risikoappetit werden Bewertungen inkonsistent, weil jedes Team "hoch" anders versteht. In KI-Projekten sollte der Appetit besonders niedrig sein, wenn Grundrechte, Beschäftigung, Gesundheit, Kreditwürdigkeit, Zugang zu Leistungen oder erhebliche Reputationsrisiken betroffen sind.

Die folgende Mini-Vorlage zeigt typische Beispieleinträge:

Diese Einträge zeigen, warum reine Tool-Listen nicht reichen. Dasselbe Modell kann in einem Use Case niedriges, in einem anderen kritisches Risiko erzeugen. Entscheidend sind Einsatzkontext, Betroffene, Automatisierungsgrad und Kontrolltiefe. Ein Register sollte daher immer use-case-basiert sein, nicht nur modell- oder anbieterbasiert.

Organisatorisch braucht das Register klare Eigentümer. Meist verantwortet der Prozesseigner die fachliche Risikobeschreibung, während Compliance, Datenschutz und Technik die Bewertung ergänzen. Das AIMS-Team oder ein Governance-Board konsolidiert die Ergebnisse. Für größere Organisationen empfiehlt sich zusätzlich eine Freigaberegel: Kritische KI-Risiken dürfen nur mit dokumentierter Managemententscheidung akzeptiert werden.

AI Impact Assessment nach Clause 6.1.4

Clause 6.1.4 erweitert die klassische Risikoanalyse um Auswirkungen auf Personen und Gesellschaft. Genau hier setzt das AI Impact Assessment an. Es fragt nicht nur, was dem Unternehmen schaden kann, sondern auch, welche Folgen der KI-Einsatz für Betroffene, Gruppen, Märkte, Umwelt und gesellschaftliche Prozesse hat. Diese Perspektive ist bei KI unverzichtbar, weil die stärksten Schäden oft außerhalb der eigenen Organisation entstehen.

Zum Pflichtinhalt eines AI Impact Assessment gehören mindestens Systembeschreibung, Zweck, betroffene Stakeholder, positive und negative Auswirkungen, betroffene oder besonders vulnerable Gruppen, Einsatzkontext, Grad menschlicher Aufsicht, bestehende Schutzmaßnahmen, Restrisiken und Auslöser für eine erneute Bewertung. Wer das nur als Textanhang schreibt, greift zu kurz. Es sollte mit dem Risikoregister verknüpft sein.

Der Unterschied zur DSFA beziehungsweise DPIA ist wesentlich. Die DSFA konzentriert sich auf Datenschutzrisiken bei Verarbeitung personenbezogener Daten. Ein AI Impact Assessment betrachtet darüber hinaus Fairness, Autonomie, Transparenz, Fehlsteuerung, gesellschaftliche Exklusion, Umweltwirkung und breitere Governance-Fragen. Eine DSFA kann Teil des Assessments sein, ersetzt es aber nicht. Umgekehrt ersetzt das AI Impact Assessment auch nicht die DSGVO-Pflichten.

Ein Beispiel macht den Unterschied sichtbar. Bei einer KI-gestützten Bewerbervorauswahl betrachtet die DSFA vor allem Datenkategorien, Rechtsgrundlagen, Speicherfristen und Schutzmaßnahmen. Das AI Impact Assessment fragt zusätzlich: Werden bestimmte Gruppen systematisch benachteiligt? Verengt das System menschliche Entscheidungsspielräume? Können Bewerbende die Logik nachvollziehen? Welche negativen gesellschaftlichen Effekte entstehen, wenn der Prozess skaliert wird? Diese Fragen sind für ISO 42001 zentral.

Für die Praxis empfiehlt sich ein fester Aufbau:

1. System und Zweck beschreiben.
2. Betroffene und Stakeholder definieren.
3. Positive und negative Auswirkungen trennen.
4. Besonders schutzbedürftige Gruppen explizit prüfen.
5. Maßnahmen und Restrisiken dokumentieren.
6. Review-Trigger festlegen.

Wichtig ist außerdem die gesellschaftliche Perspektive. Ein KI-System kann aus Unternehmenssicht effizient sein und trotzdem problematische Nebenwirkungen erzeugen. Beispiele sind automatisierte Ablehnungen ohne wirksame menschliche Korrektur, Verstärkung bestehender Diskriminierung, intransparente Profilbildung oder sinkende Entscheidungsqualität durch übermäßiges Vertrauen in Modelloutputs. Clause 6.1.4 zwingt Organisationen dazu, diese Effekte sichtbar zu machen, statt sie hinter Effizienzargumenten zu verstecken.

Wenn Sie dieses Thema vertiefen wollen, sind das Glossar zur Grundrechte-Folgenabschätzung und der Eintrag zur DSFA die logische Ergänzung. Für viele Teams ist genau diese Unterscheidung zwischen interner Risikoanalyse und externer Wirkung der Punkt, an dem KI-Governance deutlich reifer wird.

Controls zur Risikobehandlung auswählen

Risikobehandlung nach ISO 42001 bedeutet, identifizierte Risiken mit passenden organisatorischen, technischen und prozessualen Controls zu adressieren. Annex A liefert dafür den Maßnahmenkatalog. In vielen Projekten ist genau diese Übersetzung entscheidend: Erst wenn ein Risiko einem konkreten Control oder Maßnahmenpaket zugeordnet ist, wird aus Bewertung echte Steuerung.

Typische Zuordnungen sind in der Praxis relativ klar. Bias-Risiken verweisen oft auf Data-Governance-, Test- und Human-Oversight-Maßnahmen. Halluzinationsrisiken benötigen Quellenbindung, Nutzungsgrenzen, Reviewpflichten und Monitoring. Datenschutzrisiken brauchen Dataminimierung, Löschkonzepte, Zugriffskontrollen und klare Drittanbietersteuerung. Sicherheitsrisiken verlangen Härtung von Schnittstellen, Missbrauchserkennung, Logging, Incident-Prozesse und technische Tests. Erklärbarkeitsrisiken erfordern Dokumentation, Modellkarten, Eskalations- und Begründungslogik.

Die Zahl der Controls ist ein hilfreicher Anker für die Praxis. ISO 42001 arbeitet mit 38 Controls als Maßnahmenbasis, die sich auf mehrere Governance-Bereiche verteilen. Nicht jedes Control ist für jeden Use Case gleich relevant. Entscheidend ist die Angemessenheit. Eine Organisation muss begründen können, warum sie Controls ausgewählt, angepasst oder bewusst nicht angewendet hat.

Ein sauberes Mapping kann so aussehen:

Restrisiko dokumentieren ist dabei kein bürokratischer Restposten, sondern Managementpflicht. Auch mit guten Controls bleibt KI nie risikofrei. Organisationen müssen daher festhalten, welches Restniveau verbleibt, warum es akzeptiert wird und unter welchen Bedingungen die Akzeptanz entfällt. Diese Dokumentation ist gerade bei kritischen Anwendungen wichtig, weil sie spätere Entscheidungen nachvollziehbar macht.

Akzeptanzkriterien sollten vorab definiert werden. Ein Risiko darf etwa nur akzeptiert werden, wenn keine Grundrechtsbetroffenheit vorliegt, eine wirksame menschliche Aufsicht vorhanden ist, die Fehlerrate unter einem festgelegten Schwellenwert liegt und ein Review-Datum gesetzt wurde. Für Hochrisiko-nahe Anwendungsfälle sollten die Kriterien deutlich strenger sein.

Die operative Regel lautet daher: Kein hohes oder kritisches KI-Risiko ohne benannte Maßnahme, keinen Maßnahmenschluss ohne Restrisikoentscheidung und keine Restrisikoentscheidung ohne verantwortliche Person. Wer diese drei Ebenen sauber dokumentiert, schafft eine belastbare Brücke zu Audits, internen Freigaben und zum ISO-42001-Leitfaden.

KI-Risikoanalyse und EU AI Act

Die KI-Risikoanalyse nach ISO 42001 passt inhaltlich sehr gut zur Logik des EU AI Act, ersetzt ihn aber nicht. Besonders relevant ist Art. 9 EU-VO 2024/1689, der für Hochrisiko-KI ein Risikomanagementsystem verlangt. Dieses System muss über den gesamten Lebenszyklus hinweg Risiken identifizieren, analysieren, bewerten, behandeln und fortlaufend überprüfen. Genau hier lässt sich Clause 6 von ISO 42001 sinnvoll als Governance-Struktur nutzen.

Das Mapping ist in der Praxis relativ klar:

Der Mehrwert für Unternehmen liegt in der Anschlussfähigkeit. Wer bereits ein AIMS mit Risikoregister, Rollen, Review-Logik und Controls aufbaut, ist organisatorisch besser vorbereitet auf AI-Act-Pflichten. Das gilt besonders für Anbieter und Betreiber mit Hochrisiko-Bezug. Trotzdem muss klar bleiben: ISO 42001 ist ein freiwilliger Standard, der EU AI Act verbindliches Recht. Das Mapping hilft bei der Umsetzung, ersetzt aber keine Rechtsprüfung.

Wichtig ist auch die zeitliche Einordnung. Seit dem 2. Februar 2025 gilt bereits die Pflicht zur KI-Kompetenz gemäß Art. 4. Für Hochrisiko-Systeme werden die umfassenden Anforderungen ab dem 2. August 2026 besonders relevant. Unternehmen sollten ihre KI-Risikoanalyse deshalb nicht erst beginnen, wenn ein Hochrisiko-Use-Case formal bestätigt ist. Ein früher Aufbau spart später erhebliche Nacharbeit.

Die beste Vorgehensweise ist meist zweistufig. Erstens bauen Sie mit ISO 42001 ein belastbares Governance-Grundgerüst auf. Zweitens prüfen Sie use-case-spezifisch, welche AI-Act-Pflichten zusätzlich greifen. Genau dieses Zusammenspiel ist für europäische Unternehmen oft effizienter als isolierte Einzelmaßnahmen. Wenn Sie die Pflichtenseite parallel aufbauen wollen, ist die ISO-42001-Schulung ein sinnvoller Einstiegspunkt zusammen mit dem ISO-42001-Leitfaden.

Vorlage für die KI-Risikoanalyse

Die beste Vorlage für die KI-Risikoanalyse ist eine einfache, wiederverwendbare Tabelle mit fester Bewertungslogik. Komplexe GRC-Tools sind am Anfang nicht notwendig. Wichtig ist, dass jede Zeile denselben Kern abbildet: Kontext, Schaden, Bewertung, Maßnahme, Verantwortlichkeit und Review. Genau dadurch wird die Analyse vergleichbar und auditfähig.

Ein praxistaugliches Tabellenformat enthält mindestens diese Spalten:

Ein kurzes Praxisbeispiel für einen GenAI-Use-Case:

Diese Vorlage funktioniert deshalb gut, weil sie sofort entscheidungsfähig ist. Das Management sieht Prioritäten, Fachbereiche sehen Handlungsbedarf, und Auditoren sehen eine nachvollziehbare Methodik. Für größere Organisationen kann daraus später ein vollständiges Register mit Workflows, Versionierung und Reporting entstehen.

Wenn Sie eine Vorlage intern einführen, starten Sie mit drei Regeln:

1. Jede neue KI-Anwendung bekommt vor Produktivstart mindestens einen Registereintrag.
2. Kritische Risiken brauchen eine dokumentierte Freigabe.
3. Jede wesentliche Änderung löst ein Re-Assessment aus.

Genau damit schaffen Sie aus einem abstrakten Standard ein arbeitsfähiges Verfahren. Wenn Sie die Risikoanalyse nicht nur dokumentieren, sondern auch im Unternehmen verankern wollen, ist eine vertiefende ISO-42001-Schulung oft der schnellste Hebel. Sie verbindet Methodik, Rollen, Controls und Nachweisführung in einem gemeinsamen Prozess.

FAQ

Was unterscheidet eine KI-Risikoanalyse von einer klassischen IT-Risikoanalyse?

Eine KI-Risikoanalyse erweitert klassische IT-Risiken um Bias, Halluzinationen, mangelnde Erklärbarkeit, Überautomatisierung, Modell-Drift und gesellschaftliche Auswirkungen. Sie betrachtet damit nicht nur Systeme und Daten, sondern auch betroffene Personen, Entscheidungsprozesse und externe Schäden.

Wie oft muss die KI-Risikoanalyse aktualisiert werden?

Sie muss immer dann aktualisiert werden, wenn sich Use Case, Datenbasis, Modell, Stakeholder, Rechtslage oder Einsatzkontext wesentlich ändern. Zusätzlich empfiehlt sich ein regelmäßiger Review, mindestens jährlich oder im Rahmen des AIMS-Managementreviews.

Wer sollte an der KI-Risikoanalyse beteiligt sein?

Beteiligt sein sollten Fachbereich, Prozesseigner, Technik, Datenschutz, Informationssicherheit, Compliance und bei sensiblen Anwendungen auch Rechtsabteilung sowie weitere Stakeholder. Nur so werden technische, rechtliche und gesellschaftliche Risiken gemeinsam sichtbar.

Reicht eine DSFA als KI-Risikoanalyse?

Nein. Eine DSFA deckt Datenschutzrisiken ab, aber nicht automatisch Fairness, Halluzinationen, Sicherheitsangriffe auf Modelle, menschliche Fehlanwendung oder gesellschaftliche Auswirkungen. Sie ist ein wichtiger Baustein, aber keine vollständige KI-Risikoanalyse nach ISO 42001.

Welche KI-Risiken werden am häufigsten übersehen?

Häufig übersehen werden Automationsbias, Modell-Drift, Drittanbieterabhängigkeiten, unzureichende Erklärbarkeit, fehlende Quellenprüfung bei GenAI und indirekte Benachteiligung einzelner Gruppen. Gerade diese Risiken tauchen oft erst in Vorfällen oder Beschwerden auf.

Wie führe ich eine KI-Risikoanalyse nach ISO 42001 durch?

Sie definieren zuerst Scope, System, Stakeholder und Einsatzkontext. Danach identifizieren Sie Risiken, bewerten sie mit einer festen Skala, ordnen passende Controls zu, dokumentieren Restrisiken und überprüfen das Ergebnis bei Änderungen oder Vorfällen erneut.

Fazit

ISO 42001 KI-Risikoanalyse ist kein Nebenprozess, sondern der Kern eines belastbaren AIMS. Wer Clause 6.1 sauber umsetzt, erhält nicht nur eine Liste möglicher Schäden, sondern ein steuerbares Verfahren für Priorisierung, Controls, Restrisiko und Managemententscheidungen. Genau das macht die Analyse auch für die Vorbereitung auf Art. 9 EU AI Act so wertvoll.

Wenn Sie dieses Vorgehen im Unternehmen aufbauen oder vereinheitlichen wollen, ist die ISO-42001-Schulung der direkte nächste Schritt. Für die strategische Einordnung lohnt sich ergänzend der ISO-42001-Leitfaden, für das Maßnahmenmapping der Überblick zu ISO 42001 und für die Wirkungsperspektive die Glossare zur Grundrechte-Folgenabschätzung und zur DSFA.