KI-spezifische Risiken im ISMS steuern

Problem in der Praxis

In vielen Organisationen entstehen KI-Anwendungen schneller als die Risikosteuerung. Fachbereiche nutzen generative Modelle, binden externe Modell-Dienste ein oder reichern Prozesse mit KI-Funktionen an, bevor diese Systeme im Risikoregister auftauchen.

Der vorhandene Risikoprozess greift dann nicht, weil seine Kategorien nicht passen. Ein Sprachmodell ist kein klassischer Server und keine klassische Anwendung. Sein Verhalten ist nicht deterministisch, seine Trainingsdaten sind oft nicht einsehbar, und ein wesentlicher Teil der Wertschöpfung liegt bei einem externen Anbieter. Begriffe wie Halluzination, Prompt Injection, Data Poisoning oder Modell-Drift haben im klassischen Bedrohungskatalog keinen Platz.

Die Folge ist eine Steuerungslücke: Es gibt Risiken, die niemand bewertet, weil sie in keine bestehende Schublade fallen. Gleichzeitig entsteht Aktionismus, der ein separates KI-Risikoregister neben dem ISMS aufbaut, das niemand pflegt und das im Audit nicht zusammenpasst.

CISO-Einordnung

Für den CISO ist die Leitfrage nicht, ob KI-Risiken neu sind, sondern wie der bestehende Regelkreis sie aufnimmt. Sechs Risikoklassen sind dabei praktisch relevant:

• Modellrisiken: nicht-deterministisches Verhalten, Modell-Drift, Robustheit gegen Manipulation, gezielte Umgehung (Model Evasion) und manipulierte Eingaben (Adversarial Examples).
• Datenrisiken: Qualität, Repräsentativität und Herkunft von Trainings- und Eingabedaten, Manipulation des Trainings (Data Poisoning), unbeabsichtigter Abfluss vertraulicher oder personenbezogener Daten.
• Promptrisiken: Prompt Injection, Jailbreaks und das Ausleiten von Kontext- oder Systeminformationen über manipulierte Eingaben.
• Lieferkettenrisiken: Abhängigkeit von externen Universal- bzw. Basismodellen (GPAI), unklare Modellherkunft, fehlende Transparenz nachgelagerter Anbieter, Anbieterausfall und Versionswechsel ohne Vorwarnung.
• Halluzination: sachlich falsche, aber überzeugend formulierte Ausgaben, die in nachgelagerten Entscheidungen als Fakten behandelt werden.
• Bias: systematische Verzerrungen mit Folgen für Fairness, Gleichbehandlung und Grundrechte, besonders bei Personenbezug.

Diese Klassen sind keine neue Normstruktur, sondern eine Sortierhilfe. Sie zeigen, dass KI-Risiken Wirkungen jenseits der klassischen Schutzziele haben: falsche Inhalte, unfaire Ergebnisse und rechtliche Wirkungen auf betroffene Personen. Der EU AI Act adressiert genau diesen Bereich über einen risikobasierten Ansatz und verlangt für Hochrisiko-KI ein Risikomanagement über den gesamten Lebenszyklus sowie Anforderungen an Genauigkeit, Robustheit und Cybersicherheit (Art. 15). Letztere bilden die direkte Brücke zum klassischen ISMS.

Umsetzungsperspektive

Der bestehende ISMS-Risikoprozess (Identifikation, Analyse, Bewertung, Behandlung, Restrisikoakzeptanz, Überwachung) bleibt der Rahmen. Er wird an drei Stellen erweitert:

• Asset-Begriff erweitern: Modelle, Trainings- und Eingabedaten, Prompts bzw. Prompt-Vorlagen und externe Modell-Dienste werden als eigene Asset-Typen aufgenommen und einem Owner zugeordnet.
• Bedrohungskatalog ergänzen: Die sechs Risikoklassen werden als wiederkehrende Bedrohungsszenarien hinterlegt, damit jede KI-Anwendung systematisch gegen sie geprüft wird.
• Metriken und Kontrollen anpassen: Neben technischen Kontrollen treten KI-spezifische Prüfpunkte wie menschliche Aufsicht (human oversight), Ausgabe-Validierung, Logging der Nutzung und definierte Eskalationswege.

Als methodische Referenz für diese Erweiterung eignet sich das NIST AI Risk Management Framework (AI RMF 1.0, public domain). Seine vier Funktionen Govern, Map, Measure und Manage lassen sich auf den ISMS-Regelkreis abbilden: Govern für Rollen und Aufsicht, Map für Kontext und Risikoidentifikation, Measure für Bewertung der Vertrauenswürdigkeitsmerkmale und Manage für Behandlung und Restrisiko. Das ergänzende Generative-AI-Profil (NIST AI 600-1) liefert eine Strukturhilfe für Risiken generativer Systeme.

Wer ein KI-Managementsystem nach ISO/IEC 42001 anstrebt, profitiert davon, dass diese Norm der gleichen Grundstruktur wie ISO/IEC 27001 folgt und sich daher in das bestehende ISMS integrieren lässt (gemeinsame Governance, Risiko- und Auditprozesse). Sie wird hier nur als Strukturbezug genannt; konkrete Control-Inhalte gehören nicht in diesen Artikel. Der Anschluss an den ISO- und NIST-Risikoprozess ist in den zugehörigen Risiko-Artikeln des Korpus vertieft.

Typische Fehler

1. KI-Risiken werden in einem separaten Register geführt, das vom ISMS-Risikoprozess abgekoppelt ist.
2. Modelle und Trainingsdaten werden nicht als Assets erfasst, sodass sie in keiner Bewertung auftauchen.
3. Externe Modell-Dienste werden als reine IT-Beschaffung behandelt, nicht als Lieferkettenrisiko mit Anbieter- und Versionsabhängigkeit.
4. Halluzination und Bias werden als technische Detailprobleme abgetan statt als steuerungspflichtige Risiken mit Geschäfts- und Rechtsfolgen.
5. Menschliche Aufsicht wird im Dokument behauptet, aber nicht mit konkreten Rollen, Prüfschritten und Eskalationswegen hinterlegt.

Risiken und Trade-offs

Eine zu enge Übernahme klassischer Kategorien verfehlt KI-spezifische Wirkungen wie Halluzination und Bias. Eine zu breite, eigenständige KI-Risikowelt erzeugt dagegen Doppelstrukturen, die im Betrieb nicht gepflegt werden.

Es besteht ein Spannungsfeld zwischen Innovationsgeschwindigkeit und Kontrolle. Zu strenge Vorgaben verlagern KI-Nutzung in den Schatten der Organisation; zu lockere Vorgaben lassen unbewertete Risiken zu. Beides ist steuerungsrelevant.

Auch die Lieferkette bringt einen Trade-off: Externe Basismodelle senken Entwicklungsaufwand, erhöhen aber Abhängigkeit und reduzieren Transparenz. Verlagerung des Risikos auf den Anbieter ist nur begrenzt möglich, da die Verantwortung für den Einsatz beim Betreiber bleibt.

Entscheidungspunkte

• Werden KI-Risiken im bestehenden ISMS-Risikoregister geführt oder droht ein abgekoppeltes Parallelregister?
• Welche KI-Anwendungen sind so wesentlich, dass sie eine vertiefte Risikobewertung und ggf. eine Einstufung nach dem AI Act erfordern?
• Welche Risiken werden technisch mitigiert, welche organisatorisch durch menschliche Aufsicht, und welche bewusst als Restrisiko akzeptiert?
• Wie wird die Abhängigkeit von externen Modell-Anbietern bewertet und vertraglich abgesichert?
• Welche Metriken belegen, dass Halluzination, Bias und Robustheit tatsächlich überwacht werden?

Praktische Empfehlungen

1. Nehmen Sie die sechs KI-Risikoklassen als feste Bedrohungsszenarien in den bestehenden ISMS-Risikoprozess auf, statt ein neues System zu bauen.
2. Erweitern Sie den Asset-Begriff um Modelle, Daten, Prompts und externe Modell-Dienste und vergeben Sie klare Owner.
3. Nutzen Sie das NIST AI RMF (public domain) als methodische Brücke und ISO/IEC 42001 als Strukturbezug zur ISMS-Integration.
4. Verankern Sie menschliche Aufsicht und Ausgabe-Validierung als konkrete Kontrollen mit Rollen und Eskalationswegen, nicht als Absichtserklärung.
5. Behandeln Sie Modell-Lieferketten wie kritische Drittparteien, inklusive Anbieter-, Versions- und Ausstiegsrisiko.
6. Verfolgen Sie die regulatorische Lage aktiv: Der AI Act ist gestaffelt anwendbar, und einzelne Fristen können sich verschieben.

Relevante Normreferenzen

• EU AI Act (Verordnung (EU) 2024/1689): EU-Recht, frei zugänglich und zitierbar. In Kraft seit 01.08.2024, risikobasierter Ansatz; Art. 15 (Genauigkeit, Robustheit, Cybersicherheit) als Brücke zum ISMS. Anwendung gestaffelt nach Art. 113; verbotene Praktiken und KI-Kompetenz seit 02.02.2025, GPAI seit 02.08.2025, Hochrisiko-Pflichten für Anhang III ab 02.08.2026 und für Anhang I (Art. 6 Abs. 1) ab 02.08.2027. Eine Verschiebung der Hochrisiko-Stichtage ist über das Vereinfachungspaket ("Digital Omnibus") nur vorgeschlagen und bis zur Veröffentlichung im Amtsblatt als vorläufig zu behandeln (zu prüfen).
• NIST AI RMF (AI 100-1, AI 600-1): US-Rahmenwerk, public domain, freiwillig. Methodische Referenz (Govern/Map/Measure/Manage) für die Erweiterung des Risikoprozesses.
• ISO/IEC 42001:2023: AI-Managementsystem, nur als Strukturbezug genannt (reference-only). Integrierbar in ein bestehendes ISMS über die gemeinsame Grundstruktur.
• ISO/IEC 27001: klassisches ISMS als Fundament des Risikoprozesses, nur als Referenz genannt (reference-only).