Bildquelle: extern
Damit ISO 42001 im KI-Betrieb trägt, brauchen Teams klare Incident-, Change- und Lieferantenwege
Viele Organisationen nähern sich ISO 42001 aktuell über Governance, Richtlinien und den Wunsch, KI-Nutzung endlich strukturiert nachweisen zu können. Das ist verständlich. Die Norm ISO/IEC 42001:2023 ist laut ISO der erste internationale Standard für ein Artificial Intelligence Management System, also für ein Managementsystem rund um die verantwortliche Entwicklung, Bereitstellung und Nutzung von KI. Genau darin liegt aber auch ein häufiger Denkfehler: Wer die Norm nur als Auditprojekt betrachtet, unterschätzt den operativen Teil.
Spätestens dann, wenn generative KI im Support, in internen Wissensportalen, in Entwicklungswerkzeugen oder in Fachprozessen produktiv genutzt wird, reicht ein schönes Policy-Deck nicht mehr aus. Dann geht es um Ausfälle, falsche Antworten, unklare Zuständigkeiten, geänderte Modelle, neue Datenquellen, Dienstleisterwechsel und Rückfallmechanismen. Advisera beschreibt diesen Punkt sehr greifbar am Beispiel eines KI-Chatbots im Kundensupport: Risiken entstehen nicht abstrakt, sondern konkret durch irreführende Antworten, Datenschutzprobleme oder Downtime. NIST formuliert denselben Kern in seinem AI Risk Management Framework breiter: Vertrauenswürdigkeit muss über Design, Entwicklung, Einsatz und Bewertung hinweg gemanagt werden, nicht nur auf dem Papier.
Für IT- und Service-Organisationen heißt das praktisch: ISO 42001 wird erst dann belastbar, wenn klassische Betriebsprozesse sauber mitziehen. Drei davon entscheiden besonders stark über die Prüffähigkeit im Alltag: Incident Management, Change Management und Lieferantensteuerung.
Ohne sauberen Scope bleibt das KI-Managementsystem ein Luftbild
Der erste operative Fehler passiert meist ganz am Anfang. Unternehmen definieren ein AI Management System, inventarisieren aber nicht sauber, welche KI-Systeme tatsächlich im produktiven oder produktionsnahen Einsatz sind. Genau das ist problematisch, weil die Norm laut ISO und NQA für Organisationen gilt, die KI-basierte Produkte oder Services entwickeln, bereitstellen oder nutzen. Wer den Scope nur auf ein zentrales Leuchtturmprojekt zuschneidet, übersieht schnell Copiloten im Service Desk, Übersetzungsfunktionen in SaaS-Werkzeugen, interne Assistenzsysteme im Wissensmanagement oder KI-Module in zugekauften Plattformen.
Für den Betrieb ist deshalb eine nüchterne Bestandsaufnahme wichtiger als jede Hochglanz-Governance. Teams sollten pro KI-Anwendungsfall mindestens festhalten, welchem Service er zugeordnet ist, welche Datenquellen genutzt werden, welcher Fachbereich verantwortlich ist, welche externe Plattform beteiligt ist und wie ein Rückfall auf einen nicht-KI-gestützten Prozess aussieht. Erst mit dieser Service-Sicht wird klar, welche KI-Funktion eigentlich in welche Betriebslandschaft eingreift.
Diese Zuordnung ist kein Verwaltungsballast. Sie entscheidet später darüber, ob Incidents richtig geroutet, Änderungen genehmigt und Lieferantenrisiken überhaupt sichtbar werden. Ein AIMS ohne belastbares Inventar ist im Audit schwer erklärbar und im Tagesgeschäft fast wirkungslos.
Incident Management muss KI-Fehler als Betriebsereignis behandeln
Gerade bei generativer KI werden Störungen noch zu oft als inhaltliche Unschärfe statt als echter Betriebsfall behandelt. Das ist riskant. Falsche Antworten, Halluzinationen, unzulässige Empfehlungen, ungewollte Datenabflüsse oder ein ausgefallener Modellprovider sind keine bloßen Qualitätsmacken, sondern können Support, Compliance und Kundenerlebnis direkt treffen. Advisera nennt für Support-Chatbots genau solche Risiken und empfiehlt Gegenmaßnahmen wie Validierung gegen eine eigene Wissensbasis, Sicherheits- und Datenschutzkontrollen sowie den Fallback auf einen menschlichen Agenten.
Im KI-Betrieb bedeutet das, dass Incident Management erweitert werden muss. Service Desks und Betriebsverantwortliche brauchen klare Kriterien, wann ein KI-Vorfall eröffnet wird. Es sollte unterscheidbar sein, ob ein Problem auf ein Modell, auf Retrieval-Daten, auf Prompting, auf Berechtigungen, auf einen externen API-Ausfall oder auf eine fehlerhafte Schutzregel zurückgeht. Andernfalls landen sehr unterschiedliche Ursachen in derselben diffusen Störungsklasse.
Ebenso wichtig ist ein dokumentierter Rückfallpfad. Wenn ein KI-Assistent im Self Service falsche Antworten liefert, muss klar sein, wie auf konventionelle Suche, feste Wissensartikel oder menschliche Bearbeitung zurückgeschaltet wird. Dieser Fallback darf nicht bloß theoretisch existieren. Er muss getestet, kommuniziert und in Runbooks hinterlegt sein. Genau hier zeigt sich der Reifegrad eines AIMS im Alltag: nicht daran, ob irgendwo „Responsible AI“ steht, sondern daran, ob Teams im Störungsfall innerhalb von Minuten eine sichere Betriebsalternative aktivieren können.
Change Management muss Modell-, Prompt- und Datenänderungen sichtbar machen
Ein zweiter Schwachpunkt ist das Änderungsmanagement. In vielen Teams wird KI noch so behandelt, als sei nur der erste Produktivgang relevant. Danach werden Prompts angepasst, Moderationsregeln verschärft, Modellversionen gewechselt oder neue Wissensquellen angebunden, ohne dass diese Eingriffe wie echte produktive Änderungen geführt werden. Dabei verändert schon ein scheinbar kleines Prompt-Update das Verhalten eines Systems mitunter stärker als ein klassischer UI-Patch.
Das NIST AI RMF betont ausdrücklich, dass Risiken über Design, Entwicklung, Nutzung und Bewertung hinweg gemanagt werden müssen. Für IT-Organisationen folgt daraus eine sehr greifbare Regel: Alles, was Ausgaben, Datenzugriffe, Entscheidungslogik oder externe Abhängigkeiten eines KI-Systems spürbar verändert, gehört in nachvollziehbare Change-Pfade. Das betrifft Modellwechsel ebenso wie neue Guardrails, geänderte Retrieval-Indizes, neue Datenfreigaben oder die Einführung agentischer Tools mit Systemzugriff.
Praktisch heißt das nicht, jeden Prompt in ein wochenlanges CAB zu schicken. Aber es braucht eine sinnvolle Staffelung. Niedrigrisiko-Änderungen können standardisiert und mit Pflichtnachweisen versehen werden, etwa Testprotokoll, Stichprobenbewertung und Rollback-Option. Änderungen mit Einfluss auf personenbezogene Daten, regulatorische Entscheidungen, externe Kommunikation oder produktive Automatisierung sollten dagegen klar höher eingestuft werden. Wer diese Differenzierung nicht sauber festlegt, bekommt entweder lähmende Bürokratie oder unkontrollierte Schattenänderungen. Beides widerspricht dem Geist eines funktionierenden Managementsystems.
Lieferantensteuerung ist bei KI oft der eigentliche Risikokern
Der dritte große Block ist Lieferantenmanagement. Viele produktive KI-Services hängen heute an externen Modellen, API-Anbietern, Hosting-Plattformen, Vektordatenbanken oder SaaS-Funktionen, deren KI-Anteil im Standardvertrag nur am Rand beschrieben ist. Genau deshalb reicht klassische Beschaffung hier oft nicht aus. Wenn ein Provider Trainings- oder Logging-Mechanismen ändert, Regionen umzieht, Limits anpasst oder ein Modell ersetzt, hat das direkte Auswirkungen auf Qualität, Datenschutz, Kosten und Supportaufkommen.
ISO beschreibt 42001 als Managementsystem für den verantwortlichen Umgang mit KI, also ausdrücklich auch für Nutzung, nicht nur Entwicklung. Daraus folgt: Organisationen müssen externe KI-Abhängigkeiten in ihre normale Lieferantensteuerung hineinziehen. Das umfasst verlässliche Leistungs- und Sicherheitszusagen, Transparenz über Datenflüsse, klare Eskalationswege, Hinweise zu Modelländerungen und nachvollziehbare Verantwortlichkeiten im Störungsfall.
Besonders wichtig ist die Frage, wer bei einem Incident tatsächlich handlungsfähig ist. Wenn ein interner Service Desk nur ein Symptom sieht, der SaaS-Anbieter auf einen Hyperscaler verweist und der Modellprovider selbst keine direkte Beziehung zum Kunden hat, zerfällt die Verantwortungskette im Ernstfall schnell. Ein belastbares AIMS braucht deshalb nicht nur eine Lieferantenliste, sondern auch definierte Servicegrenzen, Ansprechpartner, Meldewege und eine ehrliche Bewertung, welche Risiken sich an Dritte auslagern lassen und welche gerade nicht.
Auditfähigkeit entsteht aus gelebten Nachweisen, nicht aus Folien
Wie operativ das Thema wirklich ist, zeigt auch der Zertifizierungspfad. NQA weist darauf hin, dass für die Initial Certification Audit zwei Pflichtphasen durchlaufen werden und das Managementsystem vor der Zertifizierung mindestens drei Monate in Betrieb gewesen sein muss. Hinzu kommen Management Review und ein vollständiger Zyklus interner Audits. Das ist ein wichtiger Realitätscheck: Eine Organisation kann ISO 42001 nicht glaubwürdig „kurz vor Prüfung“ einschalten.
Wer später auditfähig sein will, sollte deshalb früh echte Evidenz sammeln. Dazu gehören beispielsweise dokumentierte KI-Incidents, bewertete Änderungen, Freigaben für neue Datenquellen, Lieferantenreviews, Schulungsnachweise, Risikoentscheidungen und Wirksamkeitskontrollen. Genau solche Artefakte zeigen, dass das Managementsystem im Alltag getragen wird. Fehlen sie, bleibt die Norm trotz guter Absichten abstrakt.
Für ITSM-nahe Teams ist das eine Chance. Viele Bausteine existieren bereits, nur eben noch nicht KI-spezifisch genug. Tickets, Changes, Known Errors, Supplier Reviews und Service-Owner-Strukturen müssen meist nicht neu erfunden, sondern präziser auf KI-Fälle zugeschnitten werden.
Was Teams vor einer ISO-42001-Zertifizierung konkret festziehen sollten
- KI-Inventar mit Service-Bezug aufbauen: Jeder produktive oder produktionsnahe KI-Anwendungsfall braucht Owner, Scope, Datenquellen, Lieferanten und Fallback.
- KI-Incidents sauber klassifizieren: Modellfehler, Datenprobleme, Provider-Ausfälle und Fehlverhalten im Prompting nicht in einer Sammelkategorie verstecken.
- Fallbacks testen: Menschliche Übernahme, Abschaltpfade und alternative Servicewege müssen praktisch nutzbar sein.
- Change-Regeln für KI definieren: Modell-, Prompt-, Tool- und Datenänderungen mit Risikoabstufung, Testnachweisen und Rollback-Logik versehen.
- Lieferantensteuerung nachschärfen: Datenflüsse, SLA, Eskalationswege, Modellwechsel und regionale Abhängigkeiten explizit prüfen.
- Audit-Evidenz laufend sammeln: Management Review, interne Audits und operative Nachweise nicht erst kurz vor der Zertifizierung zusammenziehen.
Fazit
ISO 42001 ist für IT- und Service-Organisationen kein reines Governance-Etikett, sondern ein Betriebsversprechen. Wer KI produktiv einsetzt, muss zeigen können, wie Risiken erkannt, Änderungen kontrolliert, Lieferanten gesteuert und Störungen abgefedert werden. Genau dort entscheidet sich, ob aus einem AIMS ein belastbares Managementsystem wird oder nur eine saubere Dokumentationshülle.
Je früher Teams Incident Management, Change Management und Lieferantensteuerung auf KI-Realitäten zuschneiden, desto einfacher wird später nicht nur ein mögliches Audit, sondern vor allem der Alltag mit produktiver KI. Und genau darum sollte es am Ende gehen: weniger Folienreife, mehr Betriebsreife.
