Ingmar's OrganizationWebsite besuchen →
← Zurück zum Blog

90 Tage zur Kontrolle: Shadow AI Governance, Discovery zuerst

4. September 2026
90 Tage zur Kontrolle: Shadow AI Governance, Discovery zuerst

Shadow AI Governance bedeutet, nicht genehmigte KI-Nutzung im Unternehmen sichtbar und kontrollierbar zu machen, statt sie zu verbieten. Gemeint sind Chatbots, Coding-Assistenten, selbstgebaute Agenten und MCP-Server, die Mitarbeiter ohne Freigabe der IT einsetzen. Die Priorität lautet: zuerst Discovery aufbauen, sensible Datenklassen identifizieren und erst danach gezielte Warn- oder Block-Regeln einführen. Wer sofort verbietet, ohne zu wissen, was überhaupt läuft, verliert die Kontrolle eher, als sie zu gewinnen.

Kurz gesagt:

  • Ohne zentrale Inventarisierung können Unternehmen Shadow AI nur schwer kontrollieren, da dezentrale Nutzung oft unentdeckt bleibt und Sicherheitsrisiken erhöht.
  • Hochsensible Daten in KI-Modellen lassen sich kaum vollständig löschen, wodurch Datenschutzverletzungen im Nachhinein schwer zu beheben sind.
  • Ohne klare Rollen sind Verantwortlichkeiten für Shadow AI schwer zuzuweisen, wodurch individuelle Teams unkontrolliert mit sensiblen Daten experimentieren können.
  • Effektive Governance basiert auf kontinuierlichen Entdeckungs-, Klassifizierungs-, Kontroll- und Monitoring-Prozessen, die regelmäßig überprüft werden sollten.
  • Externe Spezialisten für KI-Governance helfen, kritische Rollen schnell zu besetzen, wenn internes Fachwissen fehlt, und vermeiden so langfristige Compliance-Risiken.

Inhaltsverzeichnis

Was ist Shadow AI? Abgrenzung zu Shadow IT und zentrale Eigenschaften

Shadow AI bezeichnet den Einsatz von KI-Werkzeugen, Modellen oder autonomen Agenten, die ohne Wissen oder Freigabe der IT-Abteilung in Geschäftsprozesse gelangen. Das reicht vom Vertriebsmitarbeiter, der Kundendaten in einen öffentlichen Chatbot kopiert, bis zum Entwickler, der einen eigenen MCP-Server aufsetzt, um interne Systeme mit einem Sprachmodell zu verbinden.

Der Unterschied zu klassischer Shadow IT ist grundlegend. Shadow IT meint nicht genehmigte Software, Cloud-Dienste oder Geräte. Shadow AI dagegen bringt eine neue Kategorie von Identitäten ins Spiel: nicht menschliche Identitäten (Non-Human Identities), also API-Schlüssel, Service-Accounts und autonome Agenten, die selbstständig handeln, Daten abrufen und Entscheidungen treffen können. Ein Agent, der über Nacht Rechnungen prüft oder E-Mails beantwortet, hinterlässt ein völlig anderes Risikoprofil als eine unlizenzierte Excel-Erweiterung.

Traditionelle Sicherheitswerkzeuge sind hier oft blind, weil sie auf bekannte Signaturen, Domains oder Dateitypen trainiert sind. Ein Browser-Tab mit einem KI-Chat sieht für ein klassisches Web-Gateway harmlos aus. Ein Agentenskript, das über eine legitime API-Schnittstelle läuft, erzeugt keinen verdächtigen Netzwerkverkehr im herkömmlichen Sinn.

Drei Eigenschaften machen Shadow AI besonders schwer greifbar:

  • Sie entsteht dezentral, oft in einzelnen Teams oder bei einzelnen Personen, ohne zentrale Beschaffung.
  • Sie nutzt häufig legitime, bereits genehmigte Infrastruktur als Trägermedium, etwa Browser oder Entwicklerumgebungen.
  • Sie erzeugt eigene, nicht menschliche Identitäten mit Zugriffsrechten, die niemand systematisch verwaltet.

Governance muss deshalb bei der Sichtbarkeit ansetzen, nicht bei den Regeln. Ohne Inventar keine Kontrolle.

Warum Shadow AI jetzt wichtig ist: Risiken, Business Impact und konkrete Folgen

Der Schaden durch unkontrollierte KI-Nutzung zeigt sich selten sofort, sondern häufig erst Monate später, wenn Daten längst verarbeitet und Modelle trainiert wurden. Genau das macht das Risiko tückisch.

Datenschutz ist der größte blinde Fleck. Werden vertrauliche oder personenbezogene Daten in ein öffentliches Sprachmodell eingegeben, können sie als sogenannte Memorized Outputs im Modell verbleiben. Die BfDI-Handreichung zu KI und Datenschutz verweist ausdrücklich auf die Verantwortlichkeitszuordnung nach Artikel 4 Nummer 7 der DSGVO und fordert eine differenzierte Prüfung von Eingaben, Ausgaben und memorisierten Daten. Das Problem: Einmal im Modell verankerte Informationen lassen sich praktisch nicht mehr gezielt löschen. Ein einzelner Prompt kann damit eine Datenschutzverletzung auslösen, die sich nicht mehr rückgängig machen lässt.

Sicherheitsvorfälle entstehen oft über Umwege. Selbstgebaute Agenten benötigen API-Schlüssel und Zugriffsrechte, die in der Praxis viel zu weit gefasst werden, weil niemand sie systematisch prüft. Ein Agent mit Schreibzugriff auf ein CRM-System, obwohl er nur lesen müsste, ist ein klassisches Beispiel für Over-Privilege. Gerät ein solcher Schlüssel in falsche Hände, wird aus einem kleinen Automatisierungsprojekt ein ernstes Sicherheitsproblem.

Compliance-Risiken treffen Unternehmen doppelt. Zum einen drohen Bußgelder und Auflagen, wenn Aufsichtsbehörden unkontrollierte KI-Nutzung feststellen. Zum anderen wird ein Audit erheblich schwieriger, wenn niemand im Haus eine vollständige Liste der eingesetzten KI-Systeme führen kann.

Governance-Grundsatz: Wissenschaftliche Untersuchungen empfehlen eine organisationsweite KI-Roadmap als Basis für Governance, um zu verhindern, dass einzelne Abteilungen isolierte, widersprüchliche Regeln aufstellen.

Die Folgen für den laufenden Betrieb sind ebenfalls real:

  • Fehlerhafte Agenten-Entscheidungen ohne menschliche Kontrollinstanz können Kundenkommunikation oder Bestellprozesse beschädigen.
  • Reputationsschäden entstehen schnell, wenn öffentlich wird, dass Kundendaten in einem nicht autorisierten KI-Tool gelandet sind.
  • Doppelte oder widersprüchliche KI-Workflows in verschiedenen Abteilungen verursachen stille Ineffizienz, die niemand beziffert.

Wer diese Risiken erst nach einem Vorfall ernst nimmt, zahlt deutlich mehr als der Aufbau einer strukturierten Governance im Vorfeld gekostet hätte.

Wie Shadow AI entsteht: Typische Szenarien und Beispiele aus der Praxis

Shadow AI entsteht selten aus böser Absicht. Meist ist es der pragmatischste Weg, ein Problem schnell zu lösen, wenn der offizielle Weg zu langsam oder zu unbekannt ist.

  1. Entwickler nutzen KI-Coding-Assistenten, um Code zu generieren oder zu debuggen, und fügen dabei unbemerkt Produktionscode oder Zugangsdaten in externe Prompts ein.
  2. Marketing-Teams experimentieren mit Text- und Bildgeneratoren, oft mit Kundendaten oder internen Kampagnenplänen als Kontext, weil ein genehmigtes Tool fehlt oder zu restriktiv wirkt.
  3. Einzelne Mitarbeiter bauen sich eigene Automatisierungs-Agenten, etwa über No-Code-Plattformen, die E-Mails lesen, Termine buchen oder Daten zwischen Systemen verschieben.
  4. Technisch versierte Teams richten eigene MCP-Server ein, um ein Sprachmodell mit internen Datenbanken oder Tools zu verbinden, meist ohne Rücksprache mit der Sicherheitsabteilung.
  5. Browser-Erweiterungen mit eingebetteten KI-Funktionen greifen im Hintergrund auf Formulardaten oder Zwischenablage-Inhalte zu, ohne dass Nutzer die Reichweite verstehen.

Die technischen Einstiegspunkte sind meist unspektakulär: ein Browser-Tab, ein persönlicher API-Key, ein lokal gehosteter Dienst auf einem Entwicklerlaptop. Keiner dieser Wege erfordert eine Sicherheitslücke im klassischen Sinn.

Die eigentliche Ursache liegt organisatorisch. Wenn es keinen schnellen, offiziell genehmigten Weg gibt, ein KI-Tool zu testen oder freizugeben, suchen sich Teams selbst einen Weg. Genau diese Lücke zwischen Bedarf und Angebot ist der fruchtbarste Boden für Shadow AI. Ein Unternehmen, das drei Wochen für die Freigabe eines Tools braucht, während der Wettbewerb es in drei Tagen einsetzt, produziert damit indirekt seine eigene Schatten-IT.

Der operative Governance-Loop: Discover, Classify, Control, Monitor

Ein funktionierendes Governance-Modell ist kein einmaliges Projekt, sondern ein wiederkehrender Zyklus aus vier Phasen. Jede Phase hat eine eigene Logik, eigene Werkzeuge und eigene Fallstricke.

Vierstufiger Kreislauf der AI Governance

Discover: Sichtbarkeit als Fundament

Discovery muss mehrere Telemetriequellen zusammenführen, sonst entstehen blinde Flecken. Cloud-Logs zeigen, welche externen KI-Dienste über Firmenkonten oder Firmen-IPs angesprochen werden. Endpoint-Daten zeigen lokale Installationen und Browser-Erweiterungen. Identity-Systeme zeigen, welche Service-Accounts und API-Schlüssel existieren und wer sie angelegt hat.

Entscheidend ist die Verknüpfung dieser Quellen in einem einzigen Inventar. Praxisberichte zeigen, dass Discovery Cloud- und Endpoint-Daten verbinden muss, weil Agenten eigene, nicht menschliche Identitäten besitzen, die in keinem klassischen Nutzerverzeichnis auftauchen. Jeder gefundene Agent, jeder Service-Account, jedes MCP-Server-Deployment braucht einen benannten Besitzer. Ohne Besitzer lässt sich ein Fund später nicht deprovisionieren, er bleibt einfach liegen.

Drei Telemetriequellen in einem KI-Inventar

Classify: Risiko differenzieren, nicht pauschalisieren

Nicht jedes gefundene KI-Tool verdient die gleiche Reaktion. Sinnvoll ist eine Einteilung in Risiko-Stufen, die sich an der Datenklasse orientiert, mit der ein Tool arbeitet:

  • Niedriges Risiko: öffentliche, nicht sensible Inhalte, keine Kundendaten, kein Systemzugriff.
  • Mittleres Risiko: interne, nicht regulierte Daten, begrenzter API-Zugriff auf einzelne Systeme.
  • Hohes Risiko: personenbezogene Daten, Finanzdaten, Zugriff auf Produktionssysteme oder Kundendatenbanken.

Diese Einstufung entscheidet direkt über die Kontrollstufe in der nächsten Phase. Ein Tool mit hohem Risiko braucht eine andere Reaktion als ein harmloses Textgenerator-Experiment im Marketing.

Control: Vom Verbot zum sanktionierten Pfad

Governance funktioniert am besten stufenweise, nicht als Schalter zwischen Erlaubt und Verboten. Ein etabliertes Muster ist die Abfolge Audit, dann Warnung, dann Block. Zunächst wird beobachtet und dokumentiert, ohne zu stören. Bei riskantem Verhalten folgt eine Warnung an den Nutzer. Erst bei klaren Verstößen greift eine Sperre.

Operative Leitfäden betonen dabei, dass Governance einen sanktionierten Pfad bieten muss, statt nur zu verbieten. Ein Team, das ein KI-Tool nutzen will, braucht eine schnelle, klar definierte Möglichkeit, es offiziell zu beantragen und ein Ausnahmeverfahren, wenn die Standardregel im Einzelfall nicht passt. Policy ohne Enforcement bleibt wirkungslos. Papier hält keinen Prompt zurück.

Profi-Tipp: Setzen Sie eine zeitnahe Frist für die Genehmigung neuer KI-Tools mit niedrigem Risiko. Verzögerungen erhöhen die Wahrscheinlichkeit, dass Mitarbeiter den Antrag überspringen und das Tool trotzdem nutzen.

Monitor: Der Kreislauf schließt sich

Ein vollständiger Audit Trail dokumentiert, wer welches Tool wann genutzt hat und mit welchen Daten. Jeder Fund aus der Discovery-Phase braucht eine feste Review-Cadence, etwa vierteljährlich, damit neue Schatten-Tools nicht unbemerkt entstehen, während alte bereits kontrolliert wurden. Monitoring ist kein Abschluss, sondern der Übergang zurück zur nächsten Discovery-Runde.

Technische Kontrollen und organisatorische Maßnahmen

Governance lebt von konkreten technischen Hebeln, nicht von Absichtserklärungen. Drei Kategorien tragen den größten Teil der Last.

Web- und Endpoint-DLP mit inhaltsbezogener Redaction. Praxisanbieter berichten, dass Endpoint- und Web-DLP mit content-aware Redaction zu den wirksamsten Hebeln gehören, um zu verhindern, dass sensible Daten überhaupt erst in ein externes Prompt-Fenster gelangen. Eine Regel, die Kreditkartennummern oder Personalausweisdaten automatisch aus einem Texteingabefeld entfernt, bevor es abgeschickt wird, verhindert den Schaden an der Quelle.

Redaction filtert sensible Daten vor der KI-Nutzung

Identity-Governance für nicht menschliche Identitäten. API-Schlüssel und Service-Accounts von Agenten brauchen dieselbe Sorgfalt wie menschliche Nutzerkonten, oft mehr. Regelmäßige Rotation von Secrets, automatische Ablauffristen für Schlüssel und eine klare Zuordnung zu einem verantwortlichen Owner gehören zum Minimum.

Least Privilege und Zugriffsverwaltung. Ein Agent sollte grundsätzlich nur die Rechte erhalten, die seine konkrete Aufgabe erfordert, nicht mehr. Privileged-Access-Management-Systeme und zentrales Token-Management verhindern, dass ein einzelner kompromittierter Schlüssel Zugriff auf das gesamte System eröffnet.

Ergänzend gehört lückenloses Logging dazu:

  • Jede Interaktion eines Agenten mit einem Produktionssystem wird protokolliert, nicht nur Fehler oder Ausnahmen.
  • Logs werden an einem zentralen Ort gesammelt, der unabhängig vom jeweiligen Tool zugänglich bleibt.
  • Anomalien, etwa ungewöhnliche Zugriffszeiten oder Datenvolumen, lösen automatische Alarme aus.

Der Rahmen für diese Maßnahmen lässt sich an etablierten Standards ausrichten, etwa dem NIST AI Risk Management Framework, der ISO/IEC 42001 für Managementsysteme im KI-Bereich oder den OWASP-Empfehlungen für agentische KI-Systeme. Keine dieser Kontrollen ersetzt die anderen. Ein DLP-Filter ohne Identity-Governance lässt Agenten mit zu weiten Rechten trotzdem laufen, und Logging ohne definierte Owner erzeugt nur Datenmüll, den niemand auswertet.

Rechtliche Anforderungen und Compliance-Mapping

Der EU AI Act ist stufenweise anwendbar. PwC weist darauf hin, dass Transparenzpflichten seit August 2026 gelten, während zentrale Hochrisiko-Anforderungen schrittweise eingeführt werden. Unternehmen, die jetzt mit der Ausrichtung beginnen, vermeiden den Druck, kurz vor einer Fristsetzung alles gleichzeitig umsetzen zu müssen.

National ergänzt das KI-MIG, das Gesetz zur Marktüberwachung und Innovationsförderung von KI, die europäische Regelung. Es regelt Zuständigkeiten, Innovationsförderung und Registerpflichten für bestimmte Hochrisiko-KI-Systeme. Die Bundesnetzagentur übernimmt dabei die Rolle als zentrales Koordinierungszentrum für die nationale Durchführung. Wer Governance aufbaut, sollte diese Stelle als Anlaufpunkt kennen, nicht erst im Streitfall.

Auf der Datenschutzseite gilt die DSGVO unverändert, mit spezifischen Anforderungen an KI-Systeme:

  • Eingaben und Ausgaben von KI-Systemen müssen dokumentiert und im Zweifel prüfbar sein, besonders bei personenbezogenen Daten.
  • Die Verantwortlichkeit nach Artikel 4 Nummer 7 DSGVO muss klar einer Stelle im Unternehmen zugeordnet sein, nicht diffus bei „der IT“ liegen.
  • Memorisierte Daten in trainierten oder feinabgestimmten Modellen erfordern eine gesonderte Prüfung, da sie sich anders verhalten als klassische Datenbankeinträge.

Diese drei Ebenen, EU AI Act, KI-MIG und DSGVO, überlappen sich in der Praxis. Ein Unternehmen, das ein Hochrisiko-System ohne Registrierung betreibt, verstößt potenziell gegen das KI-MIG. Verarbeitet dasselbe System zusätzlich personenbezogene Daten ohne klare Verantwortlichkeit, kommt ein DSGVO-Verstoß hinzu. Governance-Programme, die diese Ebenen getrennt behandeln, verdoppeln unnötig den Aufwand.

Rollen und Verantwortlichkeiten: Wer das Programm trägt

Governance scheitert selten an der Technik, sondern an fehlenden Zuständigkeiten. Drei Rollen bilden den Kern eines funktionierenden Programms:

  • AI Governance Officer: verantwortet die Klassifizierung von Risiken, die Ausnahmeverfahren und die Kommunikation mit Fachabteilungen.
  • AI Governance Lead oder Council: trifft strategische Entscheidungen, priorisiert Ressourcen und stimmt die Roadmap mit der Geschäftsleitung ab.
  • AI Security Engineer: implementiert technische Kontrollen wie DLP, Identity-Governance und Logging und reagiert auf konkrete Vorfälle.

MLOps-Spezialisten ergänzen dieses Trio, sobald Unternehmen eigene Modelle betreiben oder Agenten in Produktionsumgebungen einsetzen. Jede dieser Rollen braucht klare Zuständigkeit für Owner-Zuweisung, Review-Termine und die Bearbeitung von Ausnahmeanträgen, sonst bleiben Discovery-Ergebnisse ungenutzt in einer Tabelle liegen.

Profi-Tipp: Besetzen Sie die Rolle des AI Governance Officer nicht nebenbei aus dem bestehenden Datenschutz-Team. Die Kombination aus technischem Verständnis für Agenten und regulatorischem Wissen ist selten, und eine Doppelbelastung führt fast immer dazu, dass Governance zur Nebensache wird.

Wann lohnt sich externe Rekrutierung? Immer dann, wenn intern niemand die Kombination aus KI-technischem Verständnis, Sicherheitswissen und regulatorischer Erfahrung mitbringt, was in den meisten mittelständischen und größeren Organisationen der Fall ist. Genau diese Kombination ist auf dem Arbeitsmarkt knapp, spezialisierte Vermittlung wie durch Polydigital verkürzt dabei die Suche erheblich.

Messgrößen, KPIs und Review-Prozesse

Governance ohne Messung bleibt eine Behauptung. Sinnvolle Kennzahlen sind konkret und wiederholbar:

  • Anzahl neu entdeckter KI-Tools und Agenten pro Quartal.
  • Durchschnittliche Zeit bis zur Owner-Zuweisung nach einem Fund.
  • Anteil gesperrter oder blockierter sensibler Uploads an KI-Systeme.
  • Anzahl der Audit-Findings und deren Behebungsquote.
  • Anteil der Ausnahmeanträge im Verhältnis zu genutzten sanktionierten Pfaden.

Diese Metriken sollten nicht nur Funde zählen, sondern Verhalten steuern. Gute Programme messen laut Praxisbeobachtungen gezielt die Zeit bis zur Owner-Zuweisung und die Nutzung sanktionierter Pfade, weil genau diese Werte zeigen, ob Governance tatsächlich greift oder nur Papier produziert. Ein monatliches Reporting an die Geschäftsleitung und eine klare Eskalationsstufe für kritische Funde runden den Prozess ab.

Die 90-Tage-Checkliste für den Einstieg

  1. Woche 1 bis 4: Discovery-Sprint starten, alle Cloud-, Endpoint- und Identity-Quellen zusammenführen, erstes Inventar erstellen.
  2. Woche 3 bis 6: Datenklassifikation durchführen und Stakeholder aus Fachabteilungen einbinden, damit Regeln akzeptiert werden.
  3. Woche 5 bis 8: Katalog sanktionierter Tools veröffentlichen, schnelles Genehmigungsverfahren für Ausnahmen einführen, erste DLP-Audits durchführen.
  4. Woche 8 bis 12: Identity-Mapping abschließen, jedem Fund einen Owner zuweisen, Reporting-Dashboard für die Geschäftsleitung aufsetzen.

Perspektive von Ingmar: Die menschliche Lücke schließen

Die meisten Governance-Programme scheitern nicht an fehlenden Frameworks, sondern an fehlenden Menschen, die diese Frameworks tatsächlich betreiben können. Ich sehe immer wieder Unternehmen, die eine Policy verabschieden, aber niemanden haben, der Discovery-Ergebnisse täglich pflegt oder Ausnahmeanträge innerhalb einer Woche bearbeitet. Genau diese Lücke zwischen Anspruch und Umsetzung entscheidet, ob Governance funktioniert oder nur dokumentiert wird. Wer die richtige Kombination aus technischem und regulatorischem Verständnis früh besetzt, spart sich Monate an Nachbesserung.

— Ingmar

Polydigital: Gezielte Besetzung von KI-Governance-Rollen

Es gibt spezialisierte Anbieter, die Fachkräfte bereitstellen, um einen Governance-Loop tatsächlich am Laufen zu halten, statt nur auf dem Papier zu existieren. Während viele Unternehmen intern monatelang nach einem AI Governance Officer oder AI Security Engineer suchen, gibt es spezialisierte Vermittlungen, die Fachkräfte für diese Schnittstellenrollen zwischen Technik, Sicherheit und Regulierung identifizieren.

Polydigital

Das Angebot solcher spezialisierten Vermittlungen reicht von der Rollenberatung über die proaktive Identifikation neu entstehender Positionen bis zur Direktansprache passender Kandidaten und einem geprüften Kandidatenpool für Interims- oder Festanstellungen. Gerade bei Rollen wie MLOps Engineer oder AI Solutions Architect, die es vor wenigen Jahren in dieser Form noch gar nicht gab, zahlt sich spezialisierte Personalsuche aus, weil klassische Besetzungswege hier oft ins Leere laufen. Wer jetzt Governance aufbauen will und intern die passenden Profile nicht findet, sollte ein Erstgespräch mit Polydigital vereinbaren, um zu klären, welche Rolle als nächstes besetzt werden muss.

Quellen

Für die Vertiefung eignen sich das KI-MIG als nationale Durchführungsregelung, die BfDI-Handreichung zu KI und Datenschutz sowie internationale Rahmenwerke wie das NIST AI Risk Management Framework, ISO/IEC 42001 und die OWASP-Leitlinien für agentische KI-Systeme.

BabyLoveGrowth