Shadow AI: Warum Discovery die Basis für KI-Trust ist

Die meisten Organisationen unterschätzen nicht den Aufwand der KI-Verordnung. Sie unterschätzen, wie viel KI sie bereits einsetzen. Zwischen dem, was in der offiziellen Systemübersicht steht, und dem, was Mitarbeitende täglich tatsächlich nutzen, liegt regelmäßig eine Lücke — und diese Lücke ist nicht bloß unangenehm, sie untergräbt die Aussagekraft jedes Nachweises, den eine Organisation über ihre KI-Nutzung führt.

Ein Register, das nur die bekannten Systeme enthält, sagt nichts über die unbekannten aus. Genau das ist der Kern des Problems, das unter dem Stichwort Shadow AI diskutiert wird.

Was Shadow AI konkret bedeutet

Shadow AI meint KI-Nutzung, die außerhalb der dokumentierten Prozesse einer Organisation stattfindet. Sie entsteht selten aus böser Absicht und fast immer aus vier Richtungen:

• Direkte Nutzung öffentlicher Dienste durch Fachbereiche, die ein Werkzeug ausprobieren und es dann still im Arbeitsalltag behalten.
• Eingebettete Funktionen in Standardsoftware, die ein Anbieter per Update aktiviert — CRM, Ticketing, Office-Suiten, Personalsoftware.
• Fachbereichs-Projekte, die als Automatisierung oder Analyse geführt werden und deren KI-Anteil nie als solcher benannt wurde.
• Weiterverwendete Modelle in Vorprodukten, die über die Lieferkette in eigene Anwendungen wandern, ohne dass der Einkauf davon Kenntnis hat.

Der regulatorische Punkt: Die Verordnung (EU) 2024/1689 knüpft ihre Pflichten nicht daran, ob eine Organisation ein System als KI führt. Maßgeblich ist die Definition in Artikel 3 Nummer 1 und die Rolle, die man einnimmt. Ein System, das nirgends im internen Register steht, ist regulatorisch nicht weniger vorhanden.

Warum die Rollenfrage die Lage verschärft

Bei nicht erfasster Nutzung geht die Organisation stillschweigend davon aus, reine Betreiberin zu sein — jemand, der ein fremdes System bestimmungsgemäß verwendet. Artikel 25 der KI-Verordnung zeigt, dass diese Annahme brüchig ist: Wer ein Hochrisiko-KI-System unter eigenem Namen oder eigener Marke in Verkehr bringt, es wesentlich verändert oder seine Zweckbestimmung so ändert, dass es zum Hochrisikosystem wird, gilt als Anbieter und übernimmt dessen vollständige Pflichten.

Genau solche Veränderungen passieren in Shadow-AI-Konstellationen typischerweise unbeobachtet. Ein Fachbereich baut auf einem allgemeinen Modell eine Bewertungslogik für Bewerbungen oder Kundenanträge. Aus Sicht des Fachbereichs ist das eine Auswertung. Aus Sicht der Verordnung kann daraus ein Anwendungsfall nach Anhang III geworden sein — mit Konformitätsbewertung, technischer Dokumentation nach Artikel 11 und Registrierungspflicht. Wer solche Fälle erst im Audit entdeckt, hat keine Nachweislücke, sondern eine Rollenverwechslung. Welche Anwendungsfälle Anhang III im Einzelnen erfasst, ist im Detail unter hochrisiko-ki.com aufbereitet.

Nicht erfasst heißt: nicht nachweisbar

Mehrere zentrale Pflichten setzen voraus, dass die Organisation weiß, welche Systeme sie betreibt.

Artikel 4 verlangt von Anbietern und Betreibern, ein ausreichendes Maß an KI-Kompetenz bei ihrem Personal und bei Personen sicherzustellen, die in ihrem Auftrag mit KI-Systemen umgehen. Schulung setzt Kenntnis der Systeme voraus.

Artikel 26 verpflichtet Betreiber von Hochrisiko-KI-Systemen unter anderem dazu, die Systeme gemäß Betriebsanleitung zu verwenden, die menschliche Aufsicht kompetenten Personen zu übertragen und die automatisch erzeugten Protokolle aufzubewahren, soweit sie ihrer Kontrolle unterliegen. Protokolle eines Systems, dessen Existenz nicht bekannt ist, bewahrt niemand auf.

Artikel 12 verlangt für Hochrisiko-KI-Systeme eine Protokollierung über den gesamten Lebenszyklus. Auf der Managementseite entspricht dem die ISO/IEC 42001: Ihr Anhang A adressiert unter anderem die Ressourcen für KI-Systeme und ihre Dokumentation — ein AIMS ohne belastbare Systemübersicht hat keinen definierten Anwendungsbereich und ist damit auch nicht sinnvoll auditierbar. In der Reifegradbetrachtung nach AIMS (ISO 42001 × CMMI v3) bleibt eine Organisation ohne verlässliche Discovery auf der untersten Stufe stehen, unabhängig davon, wie sorgfältig die bekannten Systeme dokumentiert sind.

Discovery ist ein Prozess, kein Projekt

Die übliche Reaktion auf Shadow AI ist eine einmalige Erhebung: Fragebogen an die Fachbereiche, Liste konsolidieren, Register anlegen. Das Ergebnis ist am Tag der Fertigstellung bereits veraltet, weil die vier oben genannten Einfallstore weiter offen sind — insbesondere aktivierte Anbieterfunktionen, die niemand aktiv eingeführt hat.

Eine tragfähige Discovery kombiniert deshalb mehrere Quellen dauerhaft:

• Technische Signale: ausgehende Verbindungen zu Modell- und Inferenzdiensten, API-Schlüssel, Berechtigungsvergaben in verbundenen Anwendungen.
• Kaufmännische Signale: Ausgabenpositionen, Abonnements, Verträge mit KI-Bezug, Änderungen in Anbieter-Leistungsbeschreibungen.
• Organisatorische Signale: Änderungs- und Projektanträge, neue Automatisierungen, Datenschutz-Folgenabschätzungen.
• Anbieterseitige Signale: Release-Notes und Funktionsankündigungen von Standardsoftware, die neue KI-Funktionen aktivieren.

Entscheidend ist weniger die Vollständigkeit eines einzelnen Laufs als die Wiederholbarkeit: Jeder Lauf muss festhalten, wann er stattfand, was er abdeckte und was er ausdrücklich nicht abdeckte. Erst das macht aus einer Momentaufnahme einen Nachweis über die Zeit.

Der Trust-Blickwinkel

Der Unterschied zwischen einem gefüllten Register und einer Trust-Architektur liegt in der Herkunft der Einträge. Ein Register, in das Fachbereiche gemeldet haben, dokumentiert Aussagen. Eine Discovery, die technische, kaufmännische und organisatorische Signale zusammenführt und ihre Herkunft mitführt, dokumentiert Beobachtungen. Nur Letzteres lässt sich einem Prüfer gegenüber begründen — nachweisbar, audit-ready, mit erkennbarer Quelle und erkennbarer Lücke.

Deshalb ist Discovery kein Vorprojekt der Compliance, sondern deren Fundament. Wer nicht sagen kann, welche KI-Systeme im Einsatz sind, kann zu keiner der nachgelagerten Pflichten eine belastbare Aussage treffen: nicht zur Risikoklassifizierung, nicht zur menschlichen Aufsicht, nicht zur Protokollierung, nicht zur Meldung von Vorfällen.

Bis zur Durchsetzung der Hochrisiko-Anforderungen am 02.12.2027 bleibt Zeit, diesen Prozess aufzubauen und über mehrere Zyklen laufen zu lassen. Der praktische Wert zeigt sich nicht im ersten Lauf, sondern im dritten — wenn sichtbar wird, was sich seit dem letzten verändert hat.

Wer Discovery als dauerhafte Funktion aufsetzt, gewinnt nicht nur ein Register, sondern eine Zeitreihe. Genau daraus entsteht Evidenz, die einem Audit standhält. Mehr zur AEGIRA Trust-Platform: aegira.ai