AI Governance für Unternehmen: ein praktischer Einstieg

KI-Assistenten und Agenten verbreiten sich in vielen Unternehmen schneller, als Regeln dafür entstehen. AI Governance sorgt dafür, dass klar ist, wer einen Anwendungsfall verantwortet, was die KI darf und wer eingreift, wenn etwas schiefläuft. Dieser Beitrag zeigt einen praktischen Einstieg: vom Bestand über Rollen und Freigaben bis zu einem 90-Tage-Plan.

Warum Unternehmen AI Governance brauchen

Ein ausdrücklich fiktives Beispiel: Das Vertriebsteam fasst Kundentermine mit einem KI-Assistenten zusammen. Die IT baut einen Agenten, der Tickets vorsortiert. Im Marketing entstehen Texte mit einem Werkzeug, das jemand privat getestet hat. Nach einigen Monaten fragt der Datenschutz, welche Kundendaten in welche Dienste fließen. Die Finanzabteilung wundert sich über steigende Lizenz- und Nutzungskosten. Und als der Ticket-Agent eine Anfrage falsch zuordnet, weiß niemand genau, wer ihn anpassen oder abschalten darf.

Solche Situationen entstehen selten aus bösem Willen. Sie entstehen, weil vier Fragen nicht beantwortet sind:

Wer verantwortet den Anwendungsfall und seine Ergebnisse?
Welche Daten, Werkzeuge und Aktionen sind erlaubt?
Wie erfolgen Freigabe, Überwachung und Eingreifen?
Wie werden Qualität, Nutzen und Kosten bewertet?

AI Governance (im Deutschen auch KI-Governance) ist der organisatorische und technische Rahmen, der diese Fragen für jeden Anwendungsfall beantwortet. Das Rahmenwerk für KI-Risikomanagement des NIST (AI RMF) ordnet diese Aufgaben in vier Funktionen: Govern, Map, Measure und Manage. Es ist freiwillig nutzbar und eignet sich gut als Gliederungshilfe. Laut NIST wird die Version 1.0 derzeit überarbeitet.

KI-Nutzung und Agenten sind nicht dasselbe

Für die Governance lohnt eine klare Unterscheidung (mehr dazu: Unterschied zwischen Chatbots und KI-Agenten). Bei allgemeiner KI-Nutzung formuliert, fasst zusammen oder erklärt ein Assistent etwas. Ein Mensch entscheidet, was mit dem Ergebnis passiert. Ein Agent kann dagegen Werkzeuge aufrufen und selbst Aktionen ausführen: ein Ticket anlegen, eine E-Mail senden, einen Datensatz ändern. Damit steigen die Anforderungen an Identitäten, Berechtigungen, Freigaben und Protokollierung deutlich. Ein Fehler ist dann kein schlechter Text mehr, sondern eine Änderung in einem Zielsystem.

Zuerst Transparenz schaffen

Du kannst nur steuern, was du kennst. Deshalb beginnt AI Governance mit Transparenz. Der erste Schritt ist eine Bestandsaufnahme aller KI-Anwendungen und Agenten. Auch das NIST-Rahmenwerk nennt ein Inventar der KI-Systeme ausdrücklich als Teil der Governance (GOVERN 1.6 im AI RMF 1.0).

Pro Anwendung oder Agent reichen für den Anfang diese Mindestangaben:

Zweck und Kreis der Nutzenden: Wofür wird die Anwendung genutzt und von wem?
Fachlicher Owner und technischer Betreiber: Wer verantwortet den Nutzen, wer den Betrieb?
Plattform und Anbieter: Auf welcher Plattform läuft sie, welcher Anbieter steckt dahinter?
Datenquellen und sensible Daten: Welche Quellen werden gelesen, sind personenbezogene oder vertrauliche Daten dabei?
Identitäten, Berechtigungen und angebundene Werkzeuge: Unter welcher Identität arbeitet die Anwendung, mit welchen Rechten und Schnittstellen?
Mögliche Aktionen und betroffene Zielsysteme: Was kann sie verändern und wo?
Betriebsstatus und bekannte Kosten: Test, Pilot oder Produktion, und was kostet sie heute?

Inventar-Karte mit sieben Feldern für einen KI-Anwendungsfall, dargestellt als Symbole von Zweck über Owner, Plattform, Daten, Identität und Aktionen bis zu Status und Kosten — Sieben Mindestangaben pro KI-Anwendung oder Agent im Inventar.

Plattformregister nutzen, Abdeckung prüfen

Viele Plattformen bringen eigene Register mit. Ein Beispiel ist die Agent Registry im Microsoft 365 Admin Center. Sie zeigt unter anderem Agenten ohne Owner und Agenten, die außerhalb von Agent 365 verwaltet werden. Microsoft weist dort selbst darauf hin, dass ein in Copilot Studio veröffentlichter Agent nicht automatisch im Admin Center erscheinen muss. Ein Register ist also ein guter Ausgangspunkt, aber kein Beweis für Vollständigkeit. Prüfe, welche Plattformen, Eigenentwicklungen und lokalen Werkzeuge es nicht erfasst.

Vergiss dabei nicht die eingekauften Anwendungen mit integrierten KI-Funktionen. CRM-, HR- oder Ticket-Systeme können neue KI-Funktionen auch über ein normales Update erhalten. Sie gehören genauso ins Inventar wie selbst gebaute Agenten.

Nach Risiko priorisieren und Lücken schließen

Ein vollständiges Inventar entsteht nicht in einer Woche. Priorisiere deshalb nach Risiko: Zuerst kommen Anwendungen mit sensiblen Daten, mit Kontakt zu Kundschaft oder Öffentlichkeit und mit schreibenden Aktionen. Für jede kritische Lücke legst du eine verantwortliche Person und einen Termin fest, zum Beispiel für einen fehlenden Owner oder zu weit gefasste Berechtigungen.

Behandle bereits produktive Agenten ausdrücklich. Solche Agenten laufen womöglich ohne nachträgliche Prüfung weiter, wenn sie vor den neuen Regeln entstanden sind. Für sie gilt: Owner bestätigen, Rechte prüfen, Protokollierung sicherstellen und festhalten, wie man sie stoppt. Erst danach entscheidest du, ob sie unverändert weiterlaufen.

Das passende Organisationsmodell wählen

Wo die Verantwortung für AI Governance liegt, hängt von Größe, Kultur und Reifegrad ab. Kein Modell ist allgemein überlegen.

Modell	Verantwortung	Vorteile	Typische Herausforderungen	Passt, wenn …
Zentralisiert	Ein zentrales Team prüft und betreibt KI-Anwendungen	Einheitliche Standards, klare Zuständigkeit	Engpass, Distanz zu den Fachbereichen	das Unternehmen klein ist oder stark reguliert arbeitet
Dezentralisiert	Jeder Fachbereich regelt KI selbst	Nähe zum Geschäft, hohes Tempo	Uneinheitliche Regeln, doppelte Arbeit, Lücken	Bereiche sehr unabhängig sind und eigene Kompetenz haben
Hub-and-Spoke	Ein zentraler Hub setzt Standards, Fachbereiche verantworten ihre Fälle	Gemeinsame Basis mit Nähe zum Geschäft	Klare Abgrenzung der Aufgaben nötig	mehrere Bereiche KI nutzen und ein gemeinsamer Rahmen fehlt

Für größere Unternehmen ist Hub-and-Spoke oft eine sinnvolle Ausgangsbasis. Ein zentraler KI-Hub oder ein Center of Excellence (CoE) schafft gemeinsame Standards, Vorlagen und Beratung. Er unterstützt die Teams, ohne ihnen die Verantwortung abzunehmen. Die Fachbereiche verantworten ihre Anwendungsfälle und deren Nutzen.

Hub-and-Spoke-Modell: zentrales KI-Kompetenzzentrum mit Standards, Vorlagen und Beratung, verbunden mit vier Fachbereichen, die jeweils eigene KI-Anwendungen verantworten — Der Hub setzt Standards, die Fachbereiche verantworten ihre Anwendungsfälle.

Verantwortlichkeiten konkret festlegen

Regeln wirken erst, wenn Personen sie tragen. Das NIST-Rahmenwerk sieht dokumentierte Rollen und Kommunikationswege vor und sieht die Leitung in der Verantwortung für Risikoentscheidungen (GOVERN 2.1 und 2.3). Typische Rollen sind:

Sponsor oder verantwortliche Führungskraft: gibt das Mandat, setzt Prioritäten und trägt die Gesamtverantwortung.
AI-CoE oder koordinierender Lead: pflegt Standards, Inventar und Intake und berät die Teams.
Business Owner: verantwortet Zweck, Nutzen und Ergebnisse eines Anwendungsfalls.
Data Owner: entscheidet, welche Daten wofür genutzt werden dürfen.
Architektur, Security und IAM: definieren technische Leitplanken, Identitäten und Berechtigungen.
Plattformbetrieb und SOC: betreiben, überwachen und reagieren auf Vorfälle.
Datenschutz und Legal: bewerten rechtliche Anforderungen.
Unabhängige Prüfung: etwa die interne Revision, die prüft, ob Regeln tatsächlich wirken.

Die Rollen lassen sich anfangs auf bestehende Teams verteilen. Ein CoE braucht ein Mandat und reservierte Arbeitszeit, aber nicht automatisch eine große neue Abteilung. Wichtig ist die Trennung der Aufgaben: Der Betrieb sorgt für einen sicheren Lauf. Die Risikoprüfung bewertet vor der Freigabe. Die unabhängige Prüfung kontrolliert später, ob beides funktioniert. NIST empfiehlt für regelmäßige Bewertungen ebenfalls Personen, die nicht selbst an der Entwicklung beteiligt waren (MEASURE 1.3).

Wer entscheidet was?

Vier Entscheidungen sollten vor dem ersten produktiven Agenten feststehen:

Priorisieren: Sponsor und CoE legen fest, welche Anwendungsfälle zuerst kommen.
Produktion freigeben: Der Business Owner gibt frei, nachdem Security, Datenschutz und Betrieb ihre Prüfung abgeschlossen haben.
Verbleibende Risiken akzeptieren: Das darf nur eine Führungskraft mit passender Befugnis, nicht das Projektteam selbst.
Einen Agenten stoppen: Betrieb und SOC dürfen im Notfall sofort abschalten, ohne vorher eine Freigabe einzuholen. Der Business Owner wird danach informiert.

Wie diese Rollen heißen, ist zweitrangig. Entscheidend ist, dass jede Entscheidung genau einer Rolle zugeordnet ist.

Einen einfachen Intake und risikogerechte Freigaben einführen

Zwei Begriffe werden oft vermischt. Das CoE ist eine organisatorische Funktion. Der Intake ist der Prozess, über den neue Anwendungsfälle aufgenommen und bewertet werden. Ein schlanker Ablauf hat fünf Schritte:

Idee erfassen: kurzes Formular mit Zweck, Daten, Aktionen und Owner.
Bewerten: Einstufung in eine interne Risikostufe.
Kontrollen festlegen: Welche Tests und Nachweise sind für diese Stufe nötig?
Testen: begrenzter Test mit echten, aber unkritischen Aufgaben.
Freigeben: Entscheidung durch die zuständige Rolle, inklusive Termin für die nächste Überprüfung.

Intake-Ablauf in fünf Schritten von der Idee bis zur Freigabe: Idee erfassen, Risiko bewerten, Kontrollen festlegen, testen und freigeben, verbunden durch Prüfpunkte — Fünf Schritte vom erfassten Anwendungsfall bis zur Freigabe.

Nicht jeder Prompt braucht einen Antrag. Wer in einem bereits freigegebenen Werkzeug arbeitet, nutzt einfach die geltenden Regeln. Eine Prüfung ist dagegen sinnvoll, wenn eine neue geteilte Anwendung entsteht, Daten an externe Dienste gehen oder ein Agent zusätzliche Aktionen erhält.

Interne Risikostufen

Eine einfache, unternehmenseigene Einteilung kann so aussehen. Sie ist ein Beispiel und muss an dein Unternehmen angepasst werden:

Gering (Stufe 1): Assistenz ohne sensible Daten, Ergebnis wird immer von einem Menschen geprüft.
Mittel (Stufe 2): interne Daten oder geteilte Anwendungen, aber keine schreibenden Aktionen.
Hoch (Stufe 3): sensible Daten, Kontakt zu Kundschaft oder Aktionen in Zielsystemen.

Diese Stufen sind keine Risikoklassen im Sinne des EU AI Act. Die KI-Verordnung (EU) 2024/1689 hat eigene Kategorien mit eigenen rechtlichen Folgen. Ob ein System darunter fällt, prüft der Datenschutz oder die Rechtsabteilung gesondert.

Auch rein lesende Anwendungen können in eine hohe Stufe gehören. Ein Assistent, der nur liest, aber Zugriff auf Personalakten oder Vertragsdaten hat, kann vertrauliche Inhalte an falsche Personen ausgeben. Entscheidend sind die Daten und die möglichen Auswirkungen, nicht nur die Frage, ob geschrieben wird.

Kurz zum rechtlichen Rahmen

Organisatorische Empfehlungen und gesetzliche Pflichten solltest du getrennt halten. Zwei Punkte zur KI-Verordnung, Stand Oktober 2026 und ohne Anspruch auf Rechtsberatung:

KI-Kompetenz (Artikel 4): Anbieter und Betreiber von KI-Systemen müssen Maßnahmen ergreifen, die die KI-Kompetenz ihres Personals und weiterer Personen fördern, die in ihrem Auftrag mit KI-Systemen arbeiten. Seit der Änderung durch den Digital-Omnibus verlangt der Artikel 4 nicht mehr, ein bestimmtes Kompetenzniveau zu garantieren.
Zeitplan: Laut Zeitplan der EU-Kommission gelten die meisten Regeln seit dem 2. August 2026. Die Pflichten für Hochrisiko-Systeme nach Anhang III wurden durch die Verordnung (EU) 2026/1744 auf den 2. Dezember 2027 verschoben.

Technische Mindestkontrollen praktisch nachweisen

Eine Richtlinie beschreibt, was gelten soll. Ein Nachweis zeigt, dass es tatsächlich gilt. Ohne Nachweise bleibt AI Governance ein Papier. Für Agenten sind diese Kontrollen das Minimum:

Eindeutige Identitäten und begrenzte Berechtigungen: Jeder Agent bekommt eine eigene Identität mit den kleinsten nötigen Rechten. Microsoft Entra Agent ID ist ein Beispiel für eigene Agenten-Identitäten. Laut Microsoft setzt die Ausweitung der Entra-Sicherheitsfunktionen auf Agenten Microsoft Agent 365 voraus.
Schutz vertraulicher Daten und Kundentrennung: Daten unterschiedlicher Kundschaft oder Mandanten bleiben technisch getrennt. Werkzeuge wie Microsoft Purview Data Security Posture Management zeigen, welche sensiblen Daten KI-Apps und Agenten nutzen.
Freigegebene Werkzeuge und serverseitig geprüfte Aktionen: Der Agent darf nur freigegebene Werkzeuge aufrufen. Jede Aktion prüft das Zielsystem selbst, nicht das Sprachmodell.
Tests gegen Prompt Injection und unzulässigen Datenzugriff: Versteckte Anweisungen in Dokumenten oder Webseiten können ein Modell umlenken. Das OWASP-Projekt beschreibt Prompt Injection als Risiko, für das es bisher keinen sicheren Schutz gibt. Teste deshalb gezielt. Einen Überblick gibt der Beitrag zu Angriffsvektoren und Schutzmaßnahmen in der KI-Sicherheit.
Menschliche Freigaben für risikoreiche Aktionen: Kritische Schritte warten auf eine Bestätigung durch einen Menschen.
Nachvollziehbare Protokollierung: Wer hat wann was ausgelöst, mit welchem Ergebnis?
Incident-Prozess und getestete Abschaltung: Der Ablauf im Ernstfall ist dokumentiert und wurde geübt.

Die genannten Produkte sind Beispiele. Ihre Funktionen sind in der Herstellerdokumentation beschrieben. Ob sie in deiner Umgebung wirklich wirken, zeigt erst ein eigener Nachweis: ein Test, ein Protokollauszug, eine geübte Abschaltung.

Der Systemprompt ist keine Zugriffskontrolle

Eine Anweisung wie „Gib keine Gehaltsdaten aus“ im Systemprompt schützt nicht zuverlässig. OWASP rät ausdrücklich, Berechtigungsprüfungen nicht an das Sprachmodell zu delegieren, sondern außerhalb davon durchzusetzen (LLM07: System Prompt Leakage). Was der Agent nicht sehen soll, darf seine Identität gar nicht erst lesen können.

Freigaben müssen konkret sein

Eine menschliche Freigabe ist nur so gut wie die Information, die dabei angezeigt wird. „Agent möchte fortfahren, ja oder nein?“ reicht nicht. Erkennbar sein muss, welche konkrete Aktion mit welchen Parametern genehmigt wird: zum Beispiel „E-Mail an diese drei Empfangsadressen mit diesem Text senden“ oder „Ticket 4711 auf Priorität hoch setzen“.

Kein universeller Kill Switch

Versprich keinen Schalter, der alles sofort stoppt. Wenn du einen Agenten deaktivierst, laufen gestartete Prozesse eventuell weiter. Nachrichten in Warteschlangen werden womöglich noch verarbeitet. Bereits ausgestellte Tokens können bis zu ihrem Ablauf gültig bleiben. Bei Microsoft Entra liegt die Standardlebensdauer eines Access Tokens zum Beispiel zwischen 60 und 90 Minuten. Plane die Eindämmung deshalb in Schritten und teste sie, bevor du sie brauchst.

Mit klar begrenzten Piloten starten

Statt eines großen Programms helfen wenige, klar begrenzte Piloten (siehe auch Best Practices für die KI-Implementierung im Unternehmen). Drei illustrative Beispiele:

Pilot	Zweck	Grenze	Erfolgsmessung
Wissensassistent	Antworten auf Basis freigegebener Arbeitsanweisungen	Nur freigegebene Dokumente, keine Aktionen	Anteil korrekter Antworten in einer festen Testfragenliste
IT-Assistent	Anleitungen und Ticketentwürfe für häufige Anliegen	Entwürfe ja, Tickets anlegen nur nach Bestätigung	Bearbeitungszeit inklusive Prüfung, Anteil unveränderter Entwürfe
Kundenservice-Assistent	Antwortentwürfe für das Serviceteam	Kein direkter Versand an Kundschaft	Qualität laut Prüfung, Nacharbeit, Antwortzeit

Lege Qualitätskriterien und eine Vergleichsbasis fest, bevor der Pilot startet. Ohne Ausgangswerte lässt sich später nicht sagen, ob es besser geworden ist. Rechne bei der Zeitersparnis immer die Zeit für menschliche Prüfung und Nacharbeit mit ein. Eine eingesparte Stunde ist außerdem nicht automatisch eine realisierte Einsparung von Personalkosten. Sie wird es erst, wenn die frei gewordene Zeit sinnvoll genutzt oder Kapazität bewusst angepasst wird.

Ein realistischer 90-Tage-Einstiegsplan

Der folgende Plan für den Start mit AI Governance ist ein anpassbarer Vorschlag. Er zeigt eine sinnvolle Reihenfolge, keinen festen Zeitplan.

Zeitraum	Aufgabe	Überprüfbares Ergebnis
Tage 1–10	Mandat, Rollen, Umfang und erste Nutzungsregeln	Unterschriebenes Mandat, benannte Rollen, veröffentlichte Nutzungsregeln
Tage 11–30	Inventar, Priorisierung, Intake und Kontrollanforderungen	Inventar mit Mindestangaben, priorisierte Lückenliste, Intake-Formular, Kontrollkatalog je Stufe
Tage 31–60	Begrenzte Piloten, Tests und Betriebsübungen	Testergebnisse, Ergebnisse einer Abschaltübung, Messwerte gegen die Vergleichsbasis
Tage 61–90	Bewertung, geeignete Betriebsübernahme und Ausbauentscheidung	Bewertungsbericht, Übergabe an den Betrieb, dokumentierte Entscheidung zum Ausbau

Ein Kalendertermin ersetzt keinen Nachweis. Wenn am Tag 60 die Abschaltübung fehlt, geht der Pilot nicht in Produktion, nur weil der Plan es vorsieht. Dann verschiebt sich der Termin, nicht die Anforderung.

Typische Fehler und eine kurze Start-Checkliste

Diese sieben Fehler sind beim Einstieg in AI Governance typisch:

Governance auf ein Tool reduzieren: Ein Register oder ein Dashboard ersetzt keine Rollen und Entscheidungen.
Nur auf Security schauen: Ein sicherer Agent, der falsche Antworten gibt, ist trotzdem ein Problem. Fachliche Qualität gehört dazu.
Regeln ohne verantwortliche Personen festlegen: Eine Regel ohne Owner wird nicht durchgesetzt.
Bestehende Agenten übersehen: Was schon läuft, braucht dieselbe Prüfung wie etwas Neues.
Ein großes Framework entwerfen, ohne es zu testen: Probiere den Intake an zwei oder drei echten Fällen aus, bevor du ihn ausrollst.
Nutzen behaupten, ohne Ausgangswerte zu messen: Ohne Vergleichsbasis bleibt jeder Erfolg eine Vermutung.
Den laufenden Betrieb nach dem Piloten vergessen: Überwachung, Kosten, Updates und Überprüfungstermine brauchen eine feste Zuständigkeit.

Start-Checkliste für die erste Arbeitsrunde

Sponsor und koordinierende Person sind benannt.
Die vier Grundfragen sind für das Unternehmen beantwortet.
Das Inventar ist angelegt, mit Mindestangaben für mindestens die bekannten produktiven Agenten.
Für jeden produktiven Agenten sind Owner und Abschaltweg bekannt.
Die internen Risikostufen sind entworfen und als unternehmenseigen gekennzeichnet.
Ein erster Pilot mit Zweck, Grenze und Vergleichsbasis ist ausgewählt.

Fazit und nächster Schritt

AI Governance beginnt nicht mit einem großen Regelwerk, sondern mit Klarheit: Wer ist verantwortlich, was ist erlaubt, wie wird geprüft und wer greift ein. Der konkrete nächste Schritt ist einfach. Bring die zuständigen Personen aus Fachbereich, IT, Security und Datenschutz für eine Stunde zusammen. Erfasst gemeinsam den Bestand und wählt einen begrenzten Anwendungsfall aus, an dem ihr den Ablauf ausprobiert.

Vertiefung: KI-Governance aufbauen: ein praxisnahes Rahmenwerk für Unternehmen