KI-Governance mit Informationssicherheit verbinden: Rollen, Kontrollen und Monitoring

Fachbeitrag von BlackMount

Fachredaktion BlackMountFachlich verantwortet von Jannik Christ · Geschäftsführer & Senior-Berater

Praxisorientierte Einordnung zu KI-Governance mit Informationssicherheit verbinden: Rollen, Kontrollen und Monitoring: Anforderungen verstehen, Risiken priorisieren und eine belastbare Umsetzung für EU AI Act aufbauen.

KI-Governance mit Informationssicherheit verbinden: Rollen, Kontrollen und Monitoring – Fachbeitrag von BlackMount

KI-Governance scheitert selten an fehlenden Grundsatzpapieren. Häufiger bleibt unklar, wer einen Anwendungsfall freigibt, welche Sicherheitskontrollen vor dem Start nachgewiesen werden müssen und wer nach einem Modellwechsel erneut entscheidet. Informationssicherheit kann diese Lücke schließen, wenn sie nicht nur technische Mindeststandards vorgibt, sondern gemeinsam mit Fachbereichen, Datenschutz, Legal und Risikomanagement ein durchgängiges Betriebsmodell aufbaut.

Das Ziel ist ein kontrollierter Lebenszyklus vom ersten Nutzungsvorschlag bis zur Außerbetriebnahme. Dabei müssen Chancen und Risiken gemeinsam betrachtet werden: Ein zu schwerfälliges Verfahren fördert Schatten-KI, ein rein innovationsgetriebenes Verfahren übersieht Datenabfluss, Fehlentscheidungen und regulatorische Pflichten. Gute Governance schafft deshalb unterschiedliche Wege für einfache, erhöhte und kritische Anwendungen.

Governance beginnt mit klaren Entscheidungsrechten

Eine Rollenliste ist erst nützlich, wenn sie konkrete Entscheidungen zuweist. Wer darf einen Prototyp mit synthetischen Daten starten? Wer genehmigt vertrauliche Daten in einem externen Modell? Wer akzeptiert eine fachliche Fehlerrate? Wer kann den Produktivbetrieb stoppen? Diese Fragen benötigen jeweils einen verantwortlichen Entscheider und definierte Mitwirkende.

Die Geschäftsleitung setzt Risikobereitschaft und strategische Leitplanken. Ein zentrales KI-Governance-Gremium entscheidet über kritische oder strittige Fälle. Der jeweilige Fachbereich bleibt Eigentümer von Zweck, Nutzen und fachlicher Wirkung. Informationssicherheit verantwortet das Sicherheitsrisikomodell und prüft technische Kontrollen, übernimmt aber nicht die Geschäftsentscheidung über den Einsatz.

Eine zentrale KI-Verantwortung ohne künstlichen Flaschenhals

Eine zentrale KI-verantwortliche Person oder Funktion koordiniert Inventar, Standards, Klassifizierung und Berichtswesen. Sie sorgt für einheitliche Begriffe und eskaliert Lücken. Sie sollte jedoch nicht jede kleine Änderung persönlich freigeben müssen. Sonst wächst die Warteschlange schneller als die Organisation lernen kann.

Das Betriebsmodell delegiert Entscheidungen anhand vordefinierter Risikoklassen. Niedrigrisiko-Anwendungen durchlaufen einen vereinfachten Self-Service mit technischen Leitplanken. Erhöhte Fälle benötigen zusätzliche Fachprüfungen. Kritische oder rechtlich sensible Anwendungen gehen in ein multidisziplinäres Gremium. Stichproben kontrollieren, ob die dezentrale Einordnung zuverlässig funktioniert.

Der Fachbereich bleibt für Zweck und Auswirkungen verantwortlich

Nur der Prozesseigentümer kann erklären, welche Entscheidung ein System unterstützt, welche Personen betroffen sind und welcher Schaden bei einer falschen Ausgabe entsteht. Diese Verantwortung darf nicht an IT oder Anbieter ausgelagert werden. Der Fachbereich definiert zulässige Nutzung, Leistungsanforderungen, menschliche Aufsicht und Ersatzverfahren.

Vor der Freigabe beschreibt er konkrete Fehlerszenarien: Welche falsche Empfehlung wäre besonders kritisch? Welche Nutzer könnten einer plausiblen Ausgabe zu stark vertrauen? Wie schnell wird eine Fehlfunktion erkannt? Auf dieser Grundlage legen Sicherheit und Qualität passende Tests fest. Damit werden Kontrollen an der tatsächlichen Geschäftswirkung ausgerichtet.

Informationssicherheit als Architekt und unabhängige Kontrollfunktion

Die Informationssicherheit übersetzt Bedrohungsszenarien in Architekturprinzipien und Mindestkontrollen. Dazu gehören Identitäten, Berechtigungen, Schutz von Geheimnissen, Datenflüsse, Protokollierung, sichere Schnittstellen, Schwachstellenmanagement und Wiederherstellung. KI-spezifisch kommen Modell- und Datensupply-Chain, Prompt Injection, Model Extraction, Datenvergiftung und unsichere Werkzeugnutzung hinzu.

Je nach Organisationsmodell berät die Sicherheitsfunktion im Design und prüft später unabhängig die Umsetzung. Diese beiden Tätigkeiten sollten erkennbar getrennt sein. Wer eine Lösung selbst baut, kann ihre Wirksamkeit nicht allein bestätigen. Für besonders kritische Anwendungen sind unabhängige Tests oder eine zweite Prüfinstanz angemessen.

Datenschutz und Informationssicherheit gemeinsam, aber nicht austauschbar

Datenschutz bewertet Rechtsgrundlage, Zweckbindung, Transparenz, Betroffenenrechte und Risiken für natürliche Personen. Informationssicherheit schützt Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der gesamten Lösung. Beide Perspektiven überschneiden sich bei personenbezogenen Trainingsdaten, Protokollen, Berechtigungen und Vorfällen, bleiben aber fachlich verschieden.

Ein gemeinsamer Intake verhindert doppelte Datenerfassung. Systemzweck, Datenkategorien, Empfänger, Speicherorte und Schutzmaßnahmen werden einmal erhoben und von beiden Funktionen ergänzt. Ergebnisse wie Datenschutz-Folgenabschätzung und Bedrohungsmodell verweisen auf dieselbe Systemakte. Offene Konflikte, etwa zwischen umfangreicher Protokollierung und Datenminimierung, werden bewusst entschieden.

Legal und Compliance für Rolle, Pflichten und Vertragslage

Legal prüft, welche Rolle die Organisation nach dem AI Act einnimmt, ob eine verbotene Praxis oder Hochrisiko-Kategorie berührt ist und welche Informationspflichten bestehen. Außerdem bewertet die Funktion Urheberrecht, Haftung, Arbeitsrecht und vertragliche Einschränkungen. Eine reine Datenschutzprüfung deckt diese Fragen nicht ab.

Verträge müssen zur technischen Nutzung passen. Wenn der Fachbereich ein Modell feinabstimmt, unter eigener Marke anbietet oder in einen neuen Zweck überführt, kann sich die regulatorische Rolle ändern. Vertrags- und Systemänderungen lösen daher denselben Governance-Workflow aus. So bleibt die rechtliche Einordnung mit der realen Architektur synchron.

Einkauf als frühes Kontrolltor nutzen

Viele entscheidende Informationen lassen sich nur vor Vertragsschluss wirksam anfordern. Der Einkauf erhebt Modellversion, Datenverwendung, Unterauftragnehmer, Speicherregion, Sicherheitsnachweise, Vorfallunterstützung, Änderungsankündigung und Exit-Möglichkeiten. Kritische Lücken werden nicht mit einer allgemeinen Herstellerzusage geschlossen, sondern mit einer bewussten Risikoentscheidung.

Der Vertrag sollte das benötigte Monitoring ermöglichen. Wenn ein Anbieter sein Modell ohne Vorankündigung austauscht, kann der Betreiber keine belastbare Regression durchführen. Für kritische Nutzung werden daher Informationsfristen, Zugriff auf relevante Dokumentation, Unterstützung bei Untersuchungen und Rechte bei wesentlichen Verschlechterungen vereinbart. Standard-SaaS benötigt ein risikobasiert abgestuftes Profil.

Entwicklung und MLOps für reproduzierbare Systeme

Entwicklungsteams setzen technische Leitplanken um und erzeugen Nachweise im normalen Arbeitsprozess. Code, Modellartefakte, Datensätze, Prompts, Konfiguration und Evaluationen werden versioniert. Build- und Bereitstellungspipelines prüfen zugelassene Komponenten, Geheimnisse und Sicherheitsanforderungen. Die produktive Version lässt sich eindeutig auf Freigabe und Teststand zurückführen.

MLOps erweitert klassische DevSecOps-Verfahren um Daten- und Modelländerungen. Ein neuer Datensatz kann das Verhalten verändern, obwohl kein Anwendungscode angepasst wurde. Deshalb gehören Datenherkunft, Qualitätsprüfung, Drift-Erkennung, Modellregistrierung und Freigabestatus in den Änderungsprozess. Notfall-Rollback muss Modell, Konfiguration und abhängige Daten gemeinsam berücksichtigen.

Eine dreistufige Klassifizierung für den Governance-Alltag

Eine praktikable interne Einteilung ergänzt die gesetzliche Risikoklasse. Stufe eins umfasst unterstützende Anwendungen mit unkritischen Daten, reinem Entwurfscharakter und wirksamer menschlicher Prüfung. Stufe zwei betrifft vertrauliche Daten, externe Wirkung oder relevante Prozessabhängigkeit. Stufe drei erfasst Entscheidungen über Personen, sicherheitskritische Funktionen, autonome Aktionen und Anwendungen mit hohem Schadenspotenzial.

Jede Stufe besitzt verbindliche Kontrollen und Freigaben. Die AI-Act-Klassifizierung bleibt daneben separat dokumentiert. Ein System kann intern Stufe drei sein, ohne rechtlich Hochrisiko-KI zu sein. Umgekehrt kann eine gesetzlich definierte Hochrisiko-Anwendung bei begrenztem Unternehmensumfang dennoch sämtliche regulatorischen Anforderungen auslösen.

Der Intake als kurze, aber intelligente Eingangstür

Der Antrag erfasst Problem, vorgesehenen Zweck, Nutzer, betroffene Personen, Daten, Anbieter, Automatisierungsgrad, Ausgabeverwendung und verbundene Systeme. Adaptive Folgefragen vertiefen nur relevante Bereiche. Ein Marketingassistent ohne personenbezogene Daten benötigt keinen ebenso langen Fragebogen wie ein System zur Bewerberbewertung.

Der Intake liefert sofort eine vorläufige Route: genehmigter Standarddienst, vereinfachte Prüfung, vertiefte Analyse oder vorläufiger Stopp. Ein Serviceversprechen mit klaren Reaktionszeiten macht den offiziellen Weg attraktiver als Schattennutzung. Wiederkehrende Anwendungsfälle erhalten Referenzarchitekturen und vorab bewertete Anbieter.

Ein Kontrollprofil statt einer Sammlung unverbindlicher Empfehlungen

Das Kontrollprofil verbindet Risiko, konkrete Maßnahme, Verantwortlichen, Häufigkeit und Nachweis. Für einen internen generativen Assistenten können dies zentrale Anmeldung, beschränkte Wissensräume, Quellenanzeige, Schutz gegen indirekte Prompt Injection, genehmigte Modellversion und Protokollierung von Werkzeugaufrufen sein. Jede Kontrolle besitzt ein prüfbares Akzeptanzkriterium.

Kontrollen werden nach Lebenszyklus geordnet: Planung, Daten, Entwicklung, Test, Bereitstellung, Betrieb, Änderung und Außerbetriebnahme. Dadurch wird sichtbar, wann eine Maßnahme wirksam werden muss. Ein Hinweis in der Benutzeroberfläche ist beispielsweise keine ausreichende Kontrolle gegen unberechtigten Datenzugriff; technische Berechtigungen müssen bereits bei der Abfrage greifen.

Freigaben an Evidenz und Restrisiko binden

Ein System geht produktiv, wenn Pflichtnachweise vorhanden, Tests bestanden und Restrisiken auf der richtigen Ebene akzeptiert sind. Eine Freigabe auf Basis des Projektzeitplans allein untergräbt Governance. Zeitlich befristete Ausnahmen benötigen kompensierende Maßnahmen, Eigentümer, Ablaufdatum und erneute Entscheidung.

Die Freigabe dokumentiert Version und Einsatzgrenzen. Sie gilt nicht automatisch für neue Datenquellen, weitere Nutzergruppen oder zusätzliche Werkzeugrechte. Diese Grenzen werden technisch unterstützt, soweit möglich. Ein System, das nur Entwürfe erstellen darf, sollte nicht unbemerkt direkt Veröffentlichungen oder Zahlungen auslösen können.

Monitoring in vier Beobachtungsebenen aufbauen

Die erste Ebene überwacht technische Gesundheit wie Fehler, Latenz und Verfügbarkeit. Die zweite betrachtet Sicherheitsereignisse, etwa ungewöhnliche Datenmengen, Schutzverletzungen oder privilegierte Werkzeugaufrufe. Die dritte misst Modell- und Datenverhalten einschließlich Drift, Qualitätsverlust und Auffälligkeiten in bestimmten Fallgruppen. Die vierte erfasst fachliche Auswirkungen, Beschwerden und fehlerhafte Entscheidungen.

Diese Ebenen benötigen gemeinsame Korrelationsmerkmale wie System-, Modell- und Konfigurationsversion. Nur so lässt sich erkennen, ob eine Qualitätsverschlechterung nach einem Modellwechsel auftrat. Dashboards werden nicht nach verfügbarer Telemetrie gestaltet, sondern nach konkreten Entscheidungen: Warnen, untersuchen, begrenzen, zurückrollen oder abschalten.

Schwellenwerte und Eskalation vor dem Vorfall definieren

Für kritische Messgrößen werden Normalbereich, Warnschwelle und Stoppkriterium festgelegt. Ein einzelner fehlerhafter Entwurf kann eine Korrektur auslösen; eine systematische Benachteiligung oder ein Datenabfluss verlangt sofortige Eskalation. Die Schwelle hängt von Geschäftswirkung und Umkehrbarkeit ab, nicht nur von statistischer Häufigkeit.

Runbooks benennen Empfänger, Entscheidungsrecht, Beweissicherung und Ersatzverfahren. Ein technisches Team kann eine API sperren, doch der Fachbereich entscheidet über manuellen Weiterbetrieb. Legal und Datenschutz bewerten Meldungen an Behörden oder Betroffene. Übungen testen, ob diese Rollen auch außerhalb der Bürozeiten handlungsfähig sind.

Menschliche Aufsicht als operative Kontrolle gestalten

Aufsicht benötigt mehr als eine Rollenbenennung. Die Person muss Grenzen kennen, ausreichende Kontextinformationen sehen und tatsächlich eingreifen können. Oberflächen sollten Unsicherheit, Quellen und relevante Warnungen sichtbar machen. Hohe Fallzahlen oder enge Zielzeiten dürfen nicht dazu führen, dass Ausgaben faktisch automatisch übernommen werden.

Die Wirksamkeit wird mit Testfällen geprüft. Plausible Fehlantworten zeigen, ob Nutzer kritisch bleiben. Kennzahlen wie Übersteuerungsrate allein sind mehrdeutig: Eine niedrige Rate kann für hohe Qualität oder blinde Übernahme stehen. Stichproben und qualitative Auswertung ergänzen daher quantitative Messung.

KI-Kompetenz rollenbezogen entwickeln

Allgemeine Sensibilisierung erklärt Chancen, Grenzen, erlaubte Werkzeuge und Meldewege. Entwickler benötigen zusätzlich Kenntnisse zu Daten- und Modellangriffen, sicheren Schnittstellen und Evaluation. Einkäufer müssen Informationslücken und Vertragsrisiken erkennen. Aufsichtspersonen trainieren konkrete Fehlerszenarien ihres Fachprozesses.

Kompetenz wird nicht nur durch Teilnahmebescheinigungen nachgewiesen. Übungen, Fallentscheidungen und Stichproben zeigen, ob die Rolle ihre Aufgabe beherrscht. Inhalte werden nach Vorfällen, neuen Angriffsmustern oder regulatorischen Änderungen aktualisiert. Ein zentraler Lernpfad erleichtert Nachweis, ersetzt aber nicht die systemspezifische Einweisung.

Das KI-Inventar als Steuerungs- und Monitoringquelle

Das Inventar enthält Verantwortliche, Zweck, Klasse, Modell, Daten, Schnittstellen, Freigabestatus, letzte Prüfung und nächste Überprüfung. Es ist mit Beschaffung, Identitätsverwaltung und Änderungsprozess verbunden. Neue Systeme entstehen dadurch nicht erst bei der jährlichen Abfrage im Register.

Technische Funde werden mit dem Inventar abgeglichen. Ein unbekannter API-Schlüssel oder neuer SaaS-Dienst erzeugt einen Klärfall. Umgekehrt zeigt ein registriertes, aber nicht mehr genutztes System Handlungsbedarf für Zugriffsentzug und Löschung. Das Inventar unterstützt damit Governance, Incident Response und Kostenkontrolle zugleich.

Kennzahlen für Geschäftsleitung und Kontrollfunktionen

Managementkennzahlen zeigen unklassifizierte produktive Systeme, kritische offene Findings, überfällige Reviews, ungeprüfte wesentliche Änderungen, Anbieter ohne erforderliche Nachweise und Vorfälle mit hoher Auswirkung. Ergänzend werden Durchlaufzeit des Intake und Anteil genehmigter Standardlösungen beobachtet, damit Governance nicht unbemerkt zum Innovationshindernis wird.

Kontrollfunktionen benötigen tiefere Daten zu Testabdeckung, Ausnahmen, Drift und Wirksamkeit menschlicher Aufsicht. Jede Kennzahl besitzt Definition, Quelle, Eigentümer und Schwelle. Absolute Zahlen ohne Bezug zur Systemlandschaft sind irreführend; fünf offene Findings bei fünf kritischen Systemen bedeuten etwas anderes als bei fünfhundert.

Interne Prüfung und kontinuierliche Verbesserung

Audits prüfen nicht nur das Vorhandensein von Richtlinien, sondern verfolgen einzelne Systeme durch den Lebenszyklus. Sie vergleichen registrierten Zweck, reale Nutzung, Berechtigungen, Modellversion, Tests, Monitoring und Vorfallbehandlung. Abweichungen zeigen, wo Governance im Tagesgeschäft umgangen oder missverstanden wird.

Erkenntnisse aus Audits, Beschwerden, Beinahevorfällen und Leistungsabweichungen fließen in Risikomodell und Kontrollprofile. ISO 42001 strukturiert diese Verbesserung als Managementsystem; das NIST AI RMF ordnet Aktivitäten in Govern, Map, Measure und Manage. Organisationen können beide Perspektiven nutzen, ohne parallele Prozesse aufzubauen.

Beispiel: Generativer Vertriebsassistent

Ein Vertriebsassistent fasst CRM-Daten zusammen und erstellt E-Mail-Entwürfe. Der Fachbereich verantwortet Zweck und fachliche Prüfung. Datenschutz bewertet Kundendaten; Informationssicherheit prüft Identitäten, Datenfluss, Modellanbieter und Prompt-Injection-Risiko. Einkauf sichert vertraglich ab, dass Eingaben nicht zum allgemeinen Modelltraining genutzt werden.

Das System darf nur Entwürfe erstellen und keine Nachricht autonom senden. Quellen werden angezeigt, Werkzeugzugriffe protokolliert und Berechtigungen aus dem CRM übernommen. Ein Wechsel des Basismodells startet definierte Regressionstests. Beschwerden, Datenabflussindikatoren und auffällige Halluzinationen besitzen eigene Eskalationswege.

Beispiel: KI-gestützte Qualitätskontrolle in der Produktion

Eine Bildanalyse erkennt mögliche Produktfehler. Produktion und Qualitätsmanagement definieren akzeptable Fehlerklassen und Folgen falscher Freigaben. OT-Sicherheit bewertet Netztrennung, Manipulation von Kameradaten und Verfügbarkeit. Das Modellteam dokumentiert Trainingsdaten, Testbedingungen und Versionen.

Das Monitoring unterscheidet technische Ausfälle, Datenveränderungen und Qualitätsdrift. Bei Überschreiten der Schwelle wechselt der Prozess auf manuelle Prüfung. Neue Produktvarianten dürfen erst nach repräsentativen Tests in das Modell einfließen. Damit sind Geschäftsprozess, Sicherheit und Modellqualität in einem gemeinsamen Kontrollkreis verbunden.

Typische Fehlentwicklungen im Governance-Modell

Ein zentraler Ausschuss für jede Kleinigkeit führt zu Umgehung und langen Wartezeiten. Eine vollständig dezentrale Freigabe erzeugt dagegen uneinheitliche Klassen und blinde Flecken. Ebenso problematisch ist eine Sicherheitsprüfung, die nur den Cloudanbieter bewertet und die konkrete Integration, Datenquelle und menschliche Nutzung ignoriert.

Weitere Warnzeichen sind Inventare ohne Aktualisierungstrigger, Ausnahmen ohne Ablaufdatum, Monitoring ohne Schwellen und Schulungen ohne Rollenbezug. Gegenmaßnahmen sind risikobasierte Entscheidungsstufen, technische Standardplattformen, klare Servicezeiten und unabhängige Stichproben. Governance muss im Alltag einfacher sein als Schattennutzung.

Fazit: KI-Governance muss im Betrieb entscheiden können

Wirksame KI-Governance verbindet strategische Leitplanken mit konkreten Entscheidungsrechten, technischen Kontrollen und laufendem Monitoring. Fachbereiche besitzen Zweck und Wirkung, Informationssicherheit gestaltet und prüft Schutzmaßnahmen, während Legal, Datenschutz, Einkauf und Entwicklung ihre jeweilige Verantwortung in denselben Lebenszyklus einbringen.

BlackMount unterstützt beim Aufbau einer sicheren und prüfbaren KI-Governance: von Rollenmodell und Intake über Kontrollprofile und Freigaben bis zu Monitoring, Incident Response und Managementbericht. Das Ergebnis ist ein skalierbares Betriebsmodell, das sichere Standardfälle beschleunigt und kritische Anwendungen konsequent steuert.