KI-Governance muss beim Modellwechsel mitwandern : Wie man mit übertragbarer KI-Governance Kontrollen am Risiko ausrichtet
Unternehmen wechseln ihre Modelle für künstliche Intelligenz (KI) heute oft schon nach Monaten, nicht nach Jahren – da beispielsweise die Kosten für das ursprünglich verwendete Modell steigen, weil ein anderes in Tests besser abschneidet oder weil Compliance-Vorgaben es verlangen. Was dabei regelmäßig leidet, ist die Governance.
Der typische Fall sieht so aus: Ein Team will eine bestehende KI-Anwendung auf ein anderes Modell umstellen. Die Tests versprechen mehr Leistung bei geringeren Kosten – es bleiben dieselben Nutzer, dieselben Daten, derselbe Geschäftsprozess. Das Produktteam rechnet daher mit einer Formalie. Dann fragt die Sicherheitsabteilung, was aus der bereits festgelegten KI-Governance wird. Die Frage ist berechtigt, denn Zugriffsregeln, Datenschutz, Protokollierung und menschliche Freigaben hängen in der Praxis oft an den Einstellungen genau einer Modellplattform. Ein Wechsel hat damit Einfluss auf die real geltende Richtlinie – auch wenn sich am Geschäftsvorgang an sich nichts ändert.
Modelle und Anbieter werden weiter wechseln – Anforderungen an Zweckbindung, sensible Daten, Rechenschaft und zulässige Aktionen müssen deshalb am Anwendungsfall hängen, nicht am Modell!
KI-Vielfalt erschwert die einheitliche Steuerung
Kaum ein Unternehmen kommt noch mit einem einzigen Modell aus. Die Entwicklung optimiert auf Leistung, regulierte Abläufe verlangen bestimmte Umgebungen und die Belegschaft nutzt längst KI-Funktionen, die fest in Business-Anwendungen eingebaut sind. Jedes Modell, jedes Werkzeug, jede Schnittstelle ist jedoch eine weitere Stelle, an der die Governance ansetzen muss: Ein Team protokolliert womöglich Prompts, aber keine Tool-Aufrufe – ein anderes prüft hochgeladene Dateien, lässt aber Inhalte aus dem eigenen Repository ungeprüft durch. Ein vergleichbarer Ablauf in der Nachbarabteilung verlangt eine menschliche Freigabe – oder eben nicht.
Auf dem Papier gilt nach einem Modellwechsel gegebenenfalls weiterhin die gleiche KI-Richtlinie. In der Praxis bedeutet sie aber von Implementierung zu Implementierung etwas anderes. In dieser Lücke entsteht sogenannter Governance-Drift: zwischen den Regeln, die ein Unternehmen zu haben glaubt, und den Kontrollen, die seine KI-Systeme tatsächlich durchsetzen.
Freigabelisten schaffen Optionen, aber keine Sicherheit
Freigabelisten für Modelle sind sinnvoll: Sie helfen, Anbieter zu bewerten, offensichtliche Risiken auszuschließen und den Teams eine belastbare Auswahl zu geben. Aber eine Freigabe schafft nur eine vertrauenswürdige Option – ob die Nutzung sicher ist, entscheidet der Kontext: Ein freigegebenes Modell taugt vielleicht für öffentliche Inhalte, ist aber für unveröffentlichte Finanzzahlen völlig unbrauchbar – ein freigegebener Assistent darf Entwürfe schreiben, eine Entscheidung mit Tragweite gehört aber trotzdem vor menschliche Augen.
Der Anwendungsfall ist der stabilere Anker für die Governance: Wer oder was nutzt KI, zu welchem geschäftlichen Zweck, mit welchen Daten – und mit der Befugnis, was auszulösen? Nur den Zugriff zu regeln, genügt dabei nicht: Governance muss regeln, was die KI mit ihrem Zugriff macht; und diese Antwort darf sich beim Modellwechsel nicht ändern. Die Modellauswahl ist eine Implementierungsentscheidung – Anwendungsfall und akzeptables Risiko sind Governance-Entscheidungen.
Fünf Anforderungen an eine übertragbare KI-Governance
Übertragbare KI-Governance definiert ein einheitliches Anforderungsprofil, das jede KI-Implementierung erfüllen muss – abgestuft nach ihrem Risiko.
- Identität und Verantwortung: Jede Interaktion muss einem bekannten Nutzerkonto, einer Anwendung, einem Dienst oder einem Agenten zugeordnet sein. Und jeder Anwendungsfall braucht eine verantwortliche Person auf Geschäftsseite, die für Zweck und Risiko einsteht.
- Zulässiger Zweck: Die Werkzeugfreigabe klärt, ob ein Dienst genutzt werden darf – der Zweck klärt, wofür. Öffentliche Informationen zusammenzufassen, Kundendaten auszuwerten oder ein Konto zu ändern, erforden beispielsweise drei völlig verschiedene Aufsichtsstufen.
- Datengrenzen: Regeln für personenbezogene Daten, Quellcode, Zugangsdaten, geistiges Eigentum und regulierte Informationen müssen überall gleich greifen – im Prompt, beim Upload, im Retrieval und in angebundenen Werkzeugen.
- Ausgabe- und Aktionsgrenzen: Governance legt fest, was ein System erzeugen und was es ausführen darf. Aktionen mit erheblicher Wirkung brauchen eine menschliche Bestätigung, ein Vier-Augen-Prinzip – oder ein klares Verbot.
- Nachweisbarkeit und Prüfbarkeit: Unternehmen brauchen genügend Nachweise, um wichtige KI-Ergebnisse nachzuvollziehen und zu belegen, dass die Kontrollen gegriffen haben. Diese Nachweise müssen Untersuchungen ermöglichen, die Wirksamkeit der Kontrollen belegen und Tests auch nach einem Anbieterwechsel zulassen.
Zusammen bilden diese fünf Punkte einen „Governance-Vertrag“ für den Anwendungsfall. Die Technik darunter darf sich ändern, die Bedingungen bleiben.
Der Modellwechsel-Test
Wo Governance noch an einem einzelnen Werkzeug „klebt“, zeigen sechs Fragen. Angenommen, das Modell wird morgen ausgetauscht:
- Sind dieselben Nutzer und Dienste weiterhin autorisiert?
- Gelten dieselben Anforderungen an Daten und Aufbewahrung?
- Werden verbotene Nutzungen und Aktionen weiterhin unterbunden?
- Bleiben die Schwellen für menschliche Freigaben bestehen?
- Bleiben Nachweisbarkeit, Nachvollziehbarkeit und Transparenz erhalten?
- Löst der Wechsel selbst die nötigen Tests aus?
Jedes „Nein“ markiert eine Governance, die am Anbieter hängt, und damit eine Lücke bei der Migration.
Dieser Test taugt allerdings für mehr als nur einen Modellwechsel: etwa auch, wenn jemand vom öffentlichen Assistenten zum eingebetteten Copiloten wechselt, wenn ein Prototyp in Produktion geht, wenn eine Anwendung Zugriff auf Unternehmensdaten bekommt oder ein Workflow erstmals selbst handeln darf.
Kontrollen am Risiko ausrichten
Einheitliche Anforderungen bedeuten dabei keine einheitliche Kontrolltiefe. Ein internes Werkzeug, das Texte zusammenfasst, braucht einen weniger strengen Audit-Trail als ein Agent, der auf Kundendaten zugreift und Finanzprozesse auslöst. Dafür haben verschiedene Anbieter unterschiedliche Funktionen und unterschiedliche Fehlerbilder: Anwendungsfälle mit hohem Risiko verlangen belastbarere Nachweise, engere Grenzen, gründlichere Prüfungen und schnelleres Eingreifen. Für Fälle mit geringem Risiko genügt ein leichterer Prozess. Die Teams wissen dann, was auf sie zukommt – und die Sicherheitsabteilung kann ihre Kräfte dort konzentrieren, wo ein Ausfall am meisten kostet.
Fazit
Der erste Schritt sind einheitliche Anforderungen: Je mehr Teams, Anwendungen, Werkzeuge und Modelle KI nutzen, desto schwerer lassen sich getrennte Implementierungen derselben Richtlinie steuern. Dafür braucht es einen praktikablen Weg, um Zugriffe zu steuern, Nutzung zu beobachten, Risiken zu bewerten und Richtlinien auf verteilte KI-Aktivität anzuwenden. Ein KI-Gateway kann diese gemeinsame Steuerungsebene zwischen der KI-Nutzung im Unternehmen und den Modellen dahinter einziehen. Governance definiert, was konsistent bleiben muss – das Gateway ist dann der Ort, an dem sich das team-, werkzeug- und modellübergreifend überwachen und durchsetzen lässt.
Es ist sinnvoll, dieses Prinzip auf das gesamte Unternehmen auszudehnen und Erkennung, Schutz und Governance für KI, die von Beschäftigten, Anwendungen und Agenten genutzt wird, zu vereinheitlichen. Dann entsteht eine übergreifende Architektur, um Richtlinien überall dort durchzusetzen, wo KI eingesetzt oder eingebettet wird oder zum Handeln befugt ist. In diesem Zusammenhang ist es zudem angeraten, neue Modelle im Kontext der Anwendung im Unternehmen nicht nur vorab auf Anomalien zu testen: Vielmehr sollten derartige Scans automatisiert und regelmäßig durchgeführt werden, da schon eine neue Version innerhalb einer Modellfamilie Verhaltensänderungen im Zusammenhang mit bereits etablierten (System-)Prompts aufweisen kann, die etwaige Anpassungen in den eigenen KI-Applikationen sowie im Bereich der Guardrails erforderlich machen können.
Modelle werden besser, Anbieter wechseln, Teams finden ständig neue Einsatzmöglichkeiten. Ein tragfähiges Governance-Modell rechnet mit dieser Bewegung, anstatt sie auszubremsen – und hält die Anforderungen des Unternehmens trotzdem ein.
Thomas Boele ist Global Director, Solutions Engineering für AI Security bei Check Point Software
Literatur
[1] Check Point, AI Security Governance Framework, A practical model for helping CISOs securely enable AI across platforms, workforce tools, AI applications, and autonomous agents, White Paper, undatiert,
www.checkpoint.com/resources/items/white-paper-ai-security-governance-framework (Registrierung erforderlich)