Alle BeiträgeStrategie
Der CIO-Test für KI-Governance
Eine KI-Richtlinie sagt, was Agenten tun sollen. Ihre Konten und Werkzeuge entscheiden, was sie tun können. Ein Test mit drei Fragen für jede Zeile der Richtlinie zeigt einem CIO, welche Teile der KI-Governance halten und welche nur auf dem Papier stehen.
Ein Agent im Kundenservice entwirft Antworten und stellt bei berechtigten Fällen eine Gutschrift aus. Die KI-Richtlinie des Unternehmens sagt, dass Agenten ohne Freigabe keinen Finanzdatensatz ändern. In einem Risiko-Review fragt jemand schlicht: Wer hat die Gutschriften freigegeben, die der Agent letzte Woche ausgestellt hat?
Die Antwort zu finden dauert einen Nachmittag. Der Agent läuft auf einem Integrationskonto. Dieses Konto darf Gutschriften buchen, weil die Person, die es eingerichtet hat, die Berechtigungen einer Teamleitung im Kundenservice kopiert hat, und diese Teamleitung darf buchen. Nichts im System hat nach einer Freigabe gefragt. Die Richtlinie war richtig. Kein System hat sie durchgesetzt.
Das ist eine der häufigsten Lücken, die wir finden, und sie hängt an keiner Branche. Nachlässigkeit ist es auch nicht. Die Richtlinie wurde für Menschen geschrieben, und Menschen lesen sie. Agenten nicht.
Drei Fragen für jede Zeile der Richtlinie
Nehmen Sie jede Zeile der Richtlinie und fragen Sie:
- Welches System setzt sie durch? Nicht welches Team und nicht welches Dokument. Welches System sagt nein.
- Was geschieht bei einem Verstoß? Die Aktion wird abgelehnt, eine benannte Person erhält eine Meldung, oder es geschieht nichts.
- Welcher Nachweis zeigt, dass sie gehalten hat? Ein Datensatz, den Sie vorlegen können, bevor das Meeting endet.
Dann markieren Sie die Zeile: durchgesetzt, teilweise durchgesetzt oder nur geschrieben. Nach unserer Erfahrung sind beim ersten Durchgang viele Zeilen, die Agenten betreffen, nur teilweise durchgesetzt. Oft gibt es die Kontrolle für Menschen, aber sie wurde nie auf die Konten ausgeweitet, mit denen Agenten arbeiten.
Fünf Zeilen im Test
| Zeile der Richtlinie | Durchgesetzt durch | Nachweis |
|---|---|---|
| Jeder Agent hat einen benannten Verantwortlichen im Fachbereich | Das Identitätssystem gibt jedem Agenten ein eigenes Konto, und nur, wenn das Agentenregister einen Verantwortlichen nennt. Geht dieser und übernimmt niemand, wird das Konto gesperrt. | Registereintrag, mit dem Konto verknüpft |
| Agenten ändern keinen Finanzdatensatz ohne Freigabe | Das Konto des Agenten kann einen Entwurf anlegen, ihn aber nicht buchen. Buchen braucht die eigene Anmeldung einer freigebenden Person, gebunden an genau diesen Entwurf. | Freigabeprotokoll: wer welche Änderung wann freigegeben hat |
| Kundendaten bleiben in freigegebenen Regionen | Agenten erreichen KI-Modelle nur über Endpunkte in diesen Regionen, auch ein Ausweichmodell. Andere Endpunkte sind im Netzwerk gesperrt. | Endpunktkonfiguration und das Protokoll gesperrter Aufrufe |
| Wir können jeden Agenten schnell stoppen | Ein Schalter pro Agent entzieht seine Zugangsdaten und verhindert, dass wartende Aktionen noch laufen. Er wird jedes Quartal getestet. | Datum und Ergebnis des letzten Tests |
| Eine Modelländerung ist eine Systemänderung | Prompts, Modellversionen und Schwellenwerte laufen durch das Änderungsmanagement und werden vor der Freigabe an echten Fällen des letzten Monats getestet. | Änderungsdatensatz mit Testergebnissen |
Die Kontrollen selbst sind alt: Identitätsmanagement, Funktionstrennung, Netzwerkregeln, Änderungsmanagement. Neu ist der Akteur. Ein Agent ist weder ein Mensch noch ein klassisches Dienstkonto, denn er wählt seinen nächsten Schritt selbst. Deshalb müssen die Kontrollen dort sitzen, wo der Agent handelt, in seinem Konto und seinen Werkzeugen, nicht in seinen Anweisungen.
Zwei Details entscheiden, ob eine Zeile wirklich hält. Das erste ist das Ausweichmodell: Eine Datenregel, die das Hauptmodell abdeckt, aber nicht das Modell, auf das der Agent bei Überlast ausweicht, ist nur teilweise durchgesetzt. Das zweite ist der Stoppschalter: Zugangsdaten zu entziehen reicht nicht, wenn Aktionen in der Warteschlange trotzdem laufen. Testen Sie beides gezielt.
Ein Verantwortlicher pro Zeile, von Anfang bis Ende
Der Test legt meist ein zweites Problem offen. Recht oder Risikomanagement schreibt die Zeile. Die IT baut die Kontrolle. Die interne Revision prüft den Nachweis. Jedes Team macht seinen Teil gut, und niemand ist dafür verantwortlich, ob die Zeile hält.
Geben Sie deshalb jeder Zeile einen Verantwortlichen für alle drei Antworten, meist eine erfahrene Person aus IT oder Risikomanagement. Einmal im Quartal beantwortet diese Person eine Frage: Hält diese Zeile noch, und woher wissen wir das? Wenn sich ein Modell ändert oder ein neuer Agent dazukommt, entscheidet sie, ob die Kontrolle ihn noch abdeckt.
Die Stärke nach der riskantesten Aktion richten
Volle Kontrollen für jeden Agenten machen Governance zur Warteschlange, und um Warteschlangen finden Teams einen Weg herum. Richten Sie die Stärke deshalb danach, was ein Agent tun kann.
- Liest und fasst zusammen. Ein Verantwortlicher und Lesezugriff nur auf die Daten im Umfang.
- Entwirft Arbeit, die ein Mensch versendet. Dazu ein Protokoll, was er entworfen und was der Mensch geändert hat.
- Ändert Datensätze in einem führenden System. Dazu Freigabe oder Prüfung seiner Änderungen und ein getesteter Stoppschalter.
- Bewegt Geld oder verpflichtet das Unternehmen gegenüber Kunden, Lieferanten oder Behörden. Freigabe vor jeder Aktion und eine zweite freigebende Person ab einem vereinbarten Betrag.
Ordnen Sie jeden Agenten nach der riskantesten Aktion ein, die er ausführen kann, nicht nach der, die er meistens ausführt. Der Gutschrift-Agent von oben gehörte in die letzte Gruppe, obwohl er den größten Teil des Tages Entwürfe schrieb. Oft ist es besser, die Berechtigung zu entfernen, als eine Kontrolle hinzuzufügen.
So kann ein CIO auch schneller Ja sagen. Ein Agent, der zusammenfasst, bekommt in Tagen eine Antwort, und die sorgfältige Prüfung bleibt den wenigen Agenten vorbehalten, die echten Schaden anrichten können.
Woher der Agent auch kommt
Agenten kommen auf drei Wegen ins Unternehmen: Die IT baut sie, Fachbereiche bauen sie auf Low-Code-Plattformen, und Anbieter liefern sie in Produkten mit, die das Unternehmen schon nutzt. Die Tabelle bleibt gleich. Nur die Quelle des Nachweises ändert sich. Für eigene Agenten liefern ihn Ihre Teams. Für den Agenten eines Anbieters sind die Einstellungen und Protokolle des Produkts der Ort. Wo sie das noch nicht leisten, begrenzen Sie, was dieser Agent ändern darf, und bringen Sie die Lücke ins nächste Produkt-Review.
Was wir ablehnen und was wir ändern würden
Wir bauen kein Governance-Dashboard, bevor die Kontrollen existieren. Ein Dashboard, das den Status einer Richtlinie meldet, die nichts durchsetzt, gibt einem Vorstand falsche Sicherheit, und das ist schlimmer als kein Dashboard.
Was wir ändern würden: Früher haben wir den Test mit den Agenten begonnen, die die IT gebaut hatte, weil sie dokumentiert waren. Heute beginnen wir mit den Agenten, die in bereits genutzten Produkten eingeschaltet wurden. Sie stehen am seltensten auf irgendeiner Liste.
Wo Sie anfangen
Bringen Sie die Richtlinie auf eine Seite. Schreiben Sie für jede Zeile die drei Antworten und den Status auf. Wählen Sie eine Zeile, die nur geschrieben ist und die Agenten mit den meisten Rechten betrifft. Setzen Sie diese Zeile in diesem Quartal durch. Im nächsten Quartal machen Sie den Test erneut und bringen dem Prüfungsausschuss die Seite, nicht die Richtlinie.
Eine Richtlinie sagt, was das Unternehmen beabsichtigt. Konten und Werkzeuge entscheiden, was ein Agent tut. Governance ist die Arbeit, diese Lücke zu schließen, Zeile für Zeile.