KI-Governance sollte bestimmen, unter welchen Bedingungen ein Workload weitergehen darf. Die relevante Einheit ist der konkrete Einsatz mit Zweck, Nutzern, Daten, Befugnissen, Reichweite und Folgen. Ein persönlicher Schreibassistent und ein autonomer Prozess, der Lieferantenstammdaten verändert, gehören nicht durch dieselbe Freigabe.
Eine praktische Steuerungsebene verbindet das Risiko mit sechs Bereichen: Umgebung, Identität, Daten, Aktionen, Release und Betrieb. Die Kontrollen werden stärker, wenn Sensibilität, delegierte Befugnisse, betroffene Population und schlechte Umkehrbarkeit zunehmen.
Warum Richtlinien allein nicht funktionieren
Übergeordnete Prinzipien sind notwendig. Sie setzen Erwartungen an Fairness, Datenschutz, Sicherheit, Transparenz und Verantwortung. Sie sagen einem Maker aber nicht, wo gebaut werden darf, welcher Konnektor zulässig ist, wer eine Aktion freigibt oder welcher Nachweis für Produktion nötig ist.
Wird eine Richtlinie nicht in einen Umsetzungsweg übersetzt, entstehen zwei schlechte Ergebnisse. Teams warten auf eine breite Genehmigung, die niemand sicher erteilen kann, oder sie arbeiten in Standardumgebungen und geteilten Bereichen weiter, weil Kontrollen zu spät kommen.
Auch Microsofts Leitfaden für zonenbasierte Governance trennt Umgebungen und Kontrollen nach Zweck und Risiko. Das folgende Modell erweitert diese Logik zu einem Workload-Nachweis, der Produktänderungen übersteht und nicht auf eine Plattform begrenzt ist.
Eine Steuerungsebene schließt diese Lücke. Sie verbindet Entscheidungsrechte, technische Leitplanken und betriebliche Evidenz. Der erlaubte Weg muss vor der Implementierung bekannt sein.
Den Workload steuern, nicht die Produktbezeichnung
Dasselbe Produkt kann sehr unterschiedliche Exposition erzeugen. Ein Copilot-Studio-Agent beantwortet Fragen aus freigegebenen internen Dokumenten. Ein anderer ruft Beschäftigtendaten ab, gibt eine Empfehlung und verändert anschließend einen Vorgang. Die gemeinsame Bezeichnung macht die Kontrollanforderungen nicht gleich.
Vier Faktoren bestimmen die Eskalation:
- Datensensibilität: Werden öffentliche, interne, personenbezogene, vertrauliche oder regulierte Informationen verwendet?
- Befugnis: Antwortet das System nur oder darf es erstellen, verändern, senden, genehmigen oder löschen?
- Reichweite: Nutzt es eine Fachperson, ein Team, die Organisation oder externe Personen?
- Umkehrbarkeit: Kann ein Fehler rechtzeitig erkannt und ohne wesentlichen Schaden zurückgenommen werden?
Das Produkt bestimmt die verfügbaren Kontrollen. Der Workload bestimmt, welche davon benötigt werden.
Sechs Kontrollbereiche schaffen eine umsetzbare Grundlage
| Bereich | Entscheidung | Typischer Nachweis |
|---|---|---|
| Umgebung | Wo darf gebaut, getestet und betrieben werden? | Umgebungsklasse, Region sowie Trennung von Entwicklung, Test und Produktion |
| Identität | Welche Nutzer- oder Dienstidentität handelt mit welchen Rechten? | Authentifizierung, minimale Rollen, Conditional Access und Eigentum |
| Daten | Welche Quellen, Konnektoren und Ziele sind erlaubt? | Quellenregister, Sensibilität, Aufbewahrung, Datenrichtlinien und Berechtigungstests |
| Aktion | Was darf das System empfehlen oder verändern? | Werkzeugliste, Validierung, Freigaben, Verbote und Notfallstopp |
| Release | Welche Evidenz ist für eine Änderung erforderlich? | Testergebnisse, Sicherheitsprüfung, Freigabe, Version und Rollback |
| Betrieb | Wie wird der Dienst beobachtet und gepflegt? | Monitoring, Audit, Kostenkontrolle, Incident-Prozess, Support und Prüfung |
Der Nachweis muss verständlich sein. “DLP konfiguriert” genügt nicht. Festgehalten werden erlaubte Quellen und Konnektoren, blockierte Kombinationen und das Verhalten, das Nutzer bei einer Richtlinienverletzung erleben.
Zonen machen den normalen Weg sichtbar
Für viele Organisationen reichen drei Zonen.
Erkundungszone: Persönliches oder kleines Lernen mit synthetischen oder risikoarmen Daten, begrenzten Konnektoren, ohne folgenreiche autonome Aktion und mit Ablaufdatum.
Team-Service-Zone: Reale geschäftliche Nutzung für eine definierte Zielgruppe. Erforderlich sind fachlicher Eigentümer, freigegebene Quellen, ausdrückliche Freigabe, grundlegendes Monitoring, Support und kontrollierter Release.
Organisations- oder Hochrisikozone: Große Reichweite, sensible Daten oder folgenreiche Aktionen. Erforderlich sind getrennte Lebenszyklusumgebungen, stärkere Identitäts- und Datenkontrollen, repräsentative Evaluation, formale Freigabenachweise, Incident-Verfahren und regelmäßige Prüfung.
Zonen reduzieren wiederkehrende Verhandlung, dürfen aber nicht starr werden. Ein einzelner wesentlicher Faktor kann einen Workload eskalieren. Eine kleine Zielgruppe macht eine irreversible Finanzaktion nicht risikoarm.
Beispiel einer Governance-Entscheidung
Ein Beschaffungsassistent beantwortet zunächst Richtlinienfragen und erstellt eine Checkliste für die Lieferantenaufnahme. Er nutzt freigegebene Dokumente, handelt im Nutzerkontext und verändert keine Systeme. Damit passt er in die Team-Service-Zone.
Anschließend soll er Lieferanten automatisch im ERP-System anlegen. Das Produkt bleibt gleich, der Workload nicht. Der Agent nutzt nun eine privilegierte Integration, verarbeitet geschäftliche und personenbezogene Daten und erzeugt Datensätze mit finanziellen Folgen.
Die Steuerungsebene verschärft die Bedingungen. Lieferantenkennung und Pflichtfelder werden deterministisch validiert. Dubletten- und Sanktionsprüfungen bleiben maßgebliche externe Kontrollen. Ein Beschaffungsmitarbeiter gibt die Anlage frei. Die Integration nutzt eine eingeschränkte Dienstidentität. Test und Produktion sind getrennt. Anlagen, Fehler und Übersteuerungen werden protokolliert. Der fachliche Eigentümer prüft Ausnahmemuster.
Governance verhindert die Chance nicht. Sie verändert die Bedingungen, unter denen mehr Befugnis vertretbar wird.
Entscheidungen an den frühestmöglichen verantwortbaren Punkt legen
Umgebung, Identität und Daten sind Architekturentscheidungen. Eine Prüfung nach erfolgreichem Prototyp verursacht oft teuren Umbau. Governance-Spezialisten sollten deshalb wiederverwendbare Wege definieren und nicht an jedem Maker-Gespräch teilnehmen.
Plattformteams können Muster für typische Workloads bereitstellen: interner Wissensassistent, Dokumententwurf, Eingangsklassifikation, Freigabeunterstützung und handelnder Agent. Jedes Muster beschreibt Standardumgebung, erlaubte Konnektoren, erforderliche Evidenz und Eskalationsauslöser.
So entsteht kontrollierte Selbstbedienung. Maker bewegen sich schnell innerhalb bekannter Grenzen. Spezialisten konzentrieren sich auf Ausnahmen und folgenreiche Systeme.
Erzeugt dieses Modell mehr Bürokratie?
Das kann geschehen, wenn jeder Workload ein eigenes Gremium und ein langes Dokument benötigt. Eine gute Steuerungsebene bewirkt das Gegenteil. Sie standardisiert häufige Entscheidungen, automatisiert durchsetzbare Kontrollen und verlangt zusätzliche Evidenz nur bei steigender Exposition.
Ein weiteres Risiko ist Scheinsicherheit. Eine grüne Zone macht nicht jede Umsetzung sicher. Eigentum, Quellenqualität und Verhalten müssen weiterhin geprüft werden. Zonen beschreiben den erwarteten Weg und ersetzen kein fachliches Urteil.
Messen, ob Governance verantwortlichen Fluss ermöglicht
Governance wird nicht nur an fertigen Richtlinien oder blockierten Aktionen gemessen. Relevant sind Zeit von der Idee zum klassifizierten Experiment, Zeit vom Pilot zur Produktionsentscheidung, Anteil der Workloads mit Eigentümer, Ausnahmen, verwaiste Assets, Kontrollfehler und Incidents. Auch beendete Experimente sind wichtig, wenn ihre Evidenz keine Erweiterung rechtfertigt.
Ein gesundes System erzeugt sichere Freigaben und klare negative Entscheidungen. Ziel ist nicht maximale Bereitstellung, sondern schneller und konsistenter zum richtigen Ergebnis zu gelangen.
Der nächste praktische Schritt
Fünf reale KI-Workloads in unterschiedlichen Stadien werden ausgewählt. Für jeden werden die vier Eskalationsfaktoren und sechs Kontrollbereiche festgehalten. Wo Teams uneinig sind, wird die wichtigste Governance-Arbeit sichtbar.
Amplified Pi übersetzt diese Diagnose in Risikozonen, technische Leitplanken und einen Release-Pfad. Governance wird Teil des Strategic AI Rollout: ein Mechanismus, der wertvolle Arbeit unter angemessener Kontrolle in den Betrieb bringt und keine Mauer, die erst entsteht, wenn die Chance bereits wartet.
