KI-Governance: Befristete Ausnahmen nachvollziehbar führen
Führen Sie KI-Governance-Ausnahmen mit begrenztem Umfang, klarer Risikoverantwortung, Ersatzkontrollen, wirksamem Ablauf und dokumentiertem Abschluss.
Ein Ausnahmeregister für KI-Governance dokumentiert eine befristete, klar begrenzte Abweichung von einer vereinbarten Kontrolle. Es hält fest, wer das entstehende Risiko akzeptiert hat und wodurch die Ausnahme endet. Es darf nicht zu einem zweiten Regelsystem werden, in dem informelle Notizen Befugnisse erweitern. Jede Ausnahme braucht eine konkrete Bereitstellung, eine Ersatzkontrolle, einen Prüftermin und ein durchsetzbares Ende oder eine Stoppentscheidung.
Dieser Artikel richtet sich an Governance- und Serviceverantwortliche für begrenzte Pilotprojekte mit Unternehmensagenten. Im Beispiel wird die Verarbeitung vorübergehend auf ein Dokumentformat beschränkt, während ein Konnektor verbessert wird. Das rechtfertigt keine Umgehung von Mandantentrennung, menschlicher Entscheidungsbefugnis oder anderen unverzichtbaren Kontrollen. Manche Bedingungen müssen die Freigabe weiterhin verhindern, weil ihr Fehlen den Anwendungsfall grundsätzlich ungeeignet macht.
Ausnahme, Vorfall und Änderung unterscheiden
Eine Ausnahme akzeptiert eine definierte Einschränkung für einen begrenzten Zweck. Ein Vorfall beschreibt ein beobachtetes Problem, das eine Reaktion verlangt. Eine Änderung modifiziert das genehmigte System oder Verfahren. Diese Datensätze können zusammenhängen, dürfen einander aber nicht verdecken. Versagt eine Kontrolle unerwartet, löscht eine nachträglich erfasste Ausnahme weder den Vorfall noch belegt sie die Berechtigung früherer Aktionen.
Die NIST-FAQ zum AI RMF beschreibt das Framework als freiwillige Orientierung zum Risikomanagement. Das folgende Register ist ein betrieblicher Vorschlag für diese Aufgabe. Es ist weder ein vorgeschriebenes NIST-Formular noch ein Rechtskonformitätsnachweis. Welche Pflichten gelten und welche Kontrollen nicht ausgenommen werden dürfen, muss im tatsächlichen Organisationskontext qualifiziert beurteilt werden.
Den Umfang enger als die gesamte Bereitstellung fassen
Eine Ausnahme sollte Kontrolle, Kandidat, Prozess, Mandant und Umgebung genau benennen. „Pilot-Ausnahme“ ist zu allgemein, um dem Betrieb zu zeigen, was weiterlaufen darf. Beschreiben Sie erlaubte und ausgeschlossene Tätigkeiten getrennt. Beispielsweise darf der Worker Entwürfe aus einem freigegebenen Dateiformat vorbereiten, während nicht unterstützte Formate in die manuelle Bearbeitung gehen. Das ist eine nachvollziehbare Einschränkung statt einer pauschalen Erlaubnis.
| Registerfeld | Erforderliche Entscheidung | Beispiel für einen unzureichenden Eintrag |
|---|---|---|
| Kontrollreferenz | Welche genehmigte Anforderung wird nicht vollständig erfüllt? | Allgemeine Aussage, einige Kontrollen seien noch unfertig |
| Begrenzter Umfang | Welche Fälle und welcher Bereitstellungsstand sind betroffen? | Erlaubnis für sämtliche zukünftigen Agenten und Kunden |
| Risikoverantwortung | Wer darf genau dieses Risiko akzeptieren? | Die beantragende Entwicklung genehmigt die Ausnahme allein |
| Ersatzkontrolle | Was reduziert die Auswirkungen während der Einschränkung? | Überwachungsversprechen ohne benannte Signale und Reaktion |
| Ablaufbedingung | Welches Datum oder Ereignis beendet die Erlaubnis? | Prüftermin ohne festgelegtes Verhalten bei Fristablauf |
| Behebung | Wer beseitigt den Grund für die Ausnahme? | Unzugewiesener Backlog-Eintrag ohne Abnahmekriterien |
| Abschlussnachweis | Wodurch wird die Wirksamkeit der Kontrolle belegt? | Erledigtes Ticket ohne wiederholbare Überprüfung |
Erfassen Sie auch abgelehnte Anträge. Sie erklären bestehende Grenzen und verhindern, dass dieselbe Bitte so lange umformuliert wird, bis jemand zustimmt. Der Zugriff auf das Register kann selbst beschränkt werden müssen, insbesondere bei Schwachstellenbeschreibungen oder vertraulichen Fallreferenzen. Teilen Sie zweckgerechte Zusammenfassungen, statt jede betriebliche Einzelheit uneingeschränkt verfügbar zu machen. Transparenz bedeutet nicht automatisch vollständige Offenlegung gegenüber jedem Empfänger.
Durch Ausnahmen keine unbegrenzten Befugnisse schaffen
Risikoannahme und Aktionsautorisierung sind getrennte Entscheidungen. Ein Serviceverantwortlicher kann im Pilotbetrieb geringeren Komfort akzeptieren, ohne dem Agenten neue Datenzugriffe oder zusätzliche Aktionen zu erlauben. Eine notwendige Befugnisänderung muss ihren regulären Prüf- und Durchsetzungsweg durchlaufen. Das Register darf auf diese Entscheidung verweisen, sie aber nicht ersetzen. Eine Notiz im Register ist deshalb kein Ausführungstoken.
Definieren Sie vorab, welche Kontrollen über den gewöhnlichen Ausnahmeprozess nicht aufgehoben werden können. Die Liste hängt von Organisation und Aufgabe ab und sollte vor dem ersten Antrag genehmigt sein. Entzieht eine Abweichung dem Anwendungsfall seine wesentliche Grundlage, kann die richtige Antwort eine Verringerung des Umfangs oder ein späterer Start sein. Eine neue Bezeichnung für eine Ersatzmaßnahme löst dieses Problem nicht automatisch.
Überwachung mit einer konkreten Reaktion verbinden
„Verstärkte Überwachung“ ist keine vollständige Ersatzkontrolle. Benennen Sie Signal, Erfassungsweg, Verantwortung, Reaktionszeit und Maßnahme bei Eintritt. Sollen nicht unterstützte Dokumente manuell bearbeitet werden, zählen Sie zurückgewiesene Eingaben und prüfen, ob nicht doch ein Ersatzparser unbemerkt weiterarbeitet. Die Kontrolle muss den tatsächlich ausgeführten Weg betreffen, nicht nur die Darstellung in der Benutzeroberfläche.
Schätzen Sie die zusätzliche Arbeit durch die Ersatzkontrolle. Eine manuelle Prüfpflicht ist wirkungslos, wenn niemand sie erfüllen kann. Erfassen Sie erwartetes Fallvolumen, verfügbare qualifizierte Prüfende und die Annahmegrenze bei ausgelasteter Kapazität. Behandeln Sie die Zahlen als zu prüfende Planungsannahmen. Sie sind noch kein Nachweis bereits erreichter Betriebsleistung und sollten später mit beobachteten Werten abgeglichen werden.
Ablauf als Verhalten statt Erinnerung definieren
Nach Ablauf muss der betroffene Berechtigungs- oder Bereitstellungspfad in den dokumentierten sicheren Zustand wechseln, sofern keine neue Entscheidung vorliegt. Eine Erinnerungs-E-Mail beweist dieses Verhalten nicht. Je nach Umfang kann das System neue Fälle stoppen, ein Werkzeug beschränken oder eine neue Freigabe verlangen. Bereits eingetretene externe Wirkungen benötigen weiterhin einen eigenen Abgleich und werden nicht durch den Fristablauf aufgehoben.
Eine Verlängerung erzeugt eine neue Entscheidung mit Bezug auf die bisherige Ausnahme, aktuelle Nachweise und den Grund der noch offenen Behebung. Ändern Sie nicht einfach das alte Ablaufdatum und verlieren damit die ursprüngliche Zusage. Wiederholte Verlängerungen sind eine wichtige Beobachtung. Sie können zeigen, dass aus einer vorübergehenden Einschränkung eine dauerhafte Entwurfsentscheidung geworden ist, die eine andere Governance-Beurteilung verlangt.
Das Register an einem synthetischen Pilotprojekt prüfen
Erstellen Sie eine Ausnahme für ein einzelnes Dateiformat in einem synthetischen Pilotprojekt. Reichen Sie eine erlaubte Datei, eine nicht unterstützte Datei und einen Fall eines anderen Mandanten oder Kandidaten ein. Der Ausnahmerahmen soll den ersten erlaubten Weg ermöglichen. Für die anderen bleiben die normalen Kontrollen wirksam. Die bloße Existenz einer Ausnahme darf keinen unzugehörigen Zugriff erweitern.
Stellen Sie die Testuhr über das Ablaufdatum und kontrollieren das vereinbarte Stoppverhalten. Versuchen Sie anschließend eine Verlängerung mit Nachweisen aus einer anderen Bereitstellung. Die Prüfung muss die Abweichung erkennen, statt ein äußerlich vollständiges Formular anzunehmen. Wiederholen Sie den Versuch bei abwesender Risikoverantwortung. Eine nicht qualifizierte Vertretung darf nicht allein zur Entlastung der Warteschlange genehmigen.
Die Ausnahme mit Korrekturevidenz schließen
Ist die Behebung bereit, wiederholen Sie den ursprünglich fehlgeschlagenen Fall und relevante Regressionstests. Erfassen Sie korrigierten Kandidaten und Ergebnis. Die Prozessverantwortung sollte bestätigen, ob die Einschränkung tatsächlich beseitigt wurde oder sich lediglich der fachliche Umfang geändert hat. Das sind unterschiedliche Abschlussgründe, die in der Historie erkennbar bleiben müssen. Ein formal geschlossenes Ticket beantwortet diese Frage nicht von selbst.
Verknüpfen Sie Vorfälle, Änderungen und Freigaben, damit andere Prüfende die Folge rekonstruieren können. Löschen Sie eine abgelaufene Ausnahme nicht allein deshalb, weil sie inaktiv geworden ist. Ihre Historie kann erklären, warum ein Fall einen eingeschränkten Weg nahm oder eine Bereitstellung nur unter Aufsicht erlaubt war. Solche Informationen bleiben auch nach Behebung der ursprünglichen Einschränkung relevant.
Wiederkehrende Ursachen im Gesamtbestand prüfen
Berichten Sie aktive, abgelaufene, verlängerte und geschlossene Ausnahmen getrennt mit Alter und betroffenem Umfang. Eine sinkende Anzahl ist nicht automatisch eine Verbesserung. Prüfen Sie, ob Einträge entfernt, zusammengeführt oder neu eingeordnet wurden. Untersuchen Sie wiederkehrende Ursachen wie unklare Zuständigkeit, fehlende Nachweise, unrealistische Prüfkapazität oder ungeklärte Integrationsverträge. Eine reine Anzahl erklärt weder Risiko noch Arbeitsbedarf.
Die Vorlage ist nützlich, wenn der Betrieb erkennen kann, was heute erlaubt ist, wer dafür verantwortlich ist und was morgen passiert, falls sich nichts ändert. Das ist handlungsfähiger als eine Tabelle akzeptierter Risiken ohne Verbindung zum Laufzeitverhalten, zur Behebung oder zu den Personen, die die nächste Entscheidung treffen müssen. Genau diese Verbindung sollte bei jeder regelmäßigen Überprüfung erhalten bleiben.
Vorlage und ergänzende Umsetzungsleitfäden nutzen
Nutzen Sie den übergeordneten Leitfaden für die umfassendere Architektur und wenden Sie diesen Artikel auf eine klar begrenzte Umsetzung an. Die ergänzenden Artikel behandeln verwandte Entscheidungen, ohne diese Vorlage zu ersetzen.
Bearbeitbare Vorlage herunterladen. Nächster Schritt.
Technischer Entwurf vom 18. Oktober 2026. Primärquellen wurden an diesem Datum geprüft; die fachliche Prüfung steht noch aus. Die Vorlagen beschreiben vorgeschlagene Tests, keine gemessenen Kundenergebnisse. OATI bleibt eine Entwicklervorschau. Lokale Implementierungsnachweise belegen keine unabhängige Prüfung, Kundenabnahme oder Produktionsreife einer konkreten Bereitstellung.