Welche KI nutzt Ihr Team heute?
Nicht welche Tools offiziell freigegeben sind.
Nicht welche Lizenzen die IT eingekauft hat.
Sondern welche KI tatsächlich verwendet wird.
Diese Frage steht im Mittelpunkt eines W&V-Beitrags vom 21. September 2026. Fachanwältin Britta Klingberg beschreibt dort „Schatten-KI“ als KI-Nutzung, von der Geschäftsführung oder IT wenig oder gar nichts wissen. Ihre Einschätzung: Das größte Risiko liege in dieser unsichtbaren Nutzung. [1]
Der aktuelle Rechtsrahmen macht das Thema sichtbarer. Der EU AI Act gilt grundsätzlich seit dem 2. August 2026, mit gestaffelten Ausnahmen; die Transparenzpflichten nach Artikel 50 gelten seit diesem Datum. Die Europäische Kommission hat zudem angekündigt, die entsprechenden Regeln seit 2. August gemeinsam mit den zuständigen nationalen Behörden durchzusetzen. [2][3]
Doch für Management und Project Intelligence beginnt das Problem noch eine Ebene früher.
Wie will ein Unternehmen Regeln anwenden, wenn es gar nicht weiß, welche externen KI-Systeme in welchen Projekten genutzt werden?
Nicht jede unbekannte KI-Nutzung ist automatisch ein Rechtsverstoß
Diese Unterscheidung ist wichtig.
Der EU AI Act enthält unterschiedliche Pflichten für unterschiedliche Rollen, Systemarten und Einsatzkontexte. Nicht jede Nutzung eines KI-Tools löst dieselben Anforderungen aus. Auch die Transparenzpflichten nach Artikel 50 gelten nicht pauschal identisch für jede Form interner KI-Nutzung. [2][3]
Deshalb wäre es falsch, aus „Schatten-KI“ automatisch „illegal“ abzuleiten.
Die Managementfrage ist grundlegender:
Unsichtbare Nutzung verhindert belastbare Bewertung.
Wenn ein Tool nicht bekannt ist, kann niemand sauber prüfen:
- welcher Provider dahintersteht,
- welche Daten eingegeben werden,
- welcher Use Case betroffen ist,
- ob ein Vertrag existiert,
- welche Kosten entstehen,
- wer die Nutzung verantwortet,
- wie ein Wechsel oder Exit funktionieren würde.
Damit wird Shadow AI zu einem Supplier-Visibility-Problem.
Ein KI-Tool ist auch ein Supplier
In vielen Unternehmen wird KI organisatorisch anders behandelt als klassische Software oder externe Dienstleistungen.
Ein neues SaaS-Tool würde normalerweise zumindest irgendwann in Procurement, IT oder Vendor Management auftauchen.
Ein generatives KI-Tool wird dagegen schnell:
- über eine kostenlose Weboberfläche genutzt,
- mit einer Firmenkreditkarte gebucht,
- als Funktion in bestehender Software aktiviert,
- vom Dienstleister in einen Workflow eingebaut,
- testweise von einem Team eingeführt.
Technisch mag das nur „ein Tool“ sein.
Aus Governance-Sicht entsteht aber eine externe Abhängigkeit.
Denn ein Provider verarbeitet Daten, stellt Funktionen bereit, ändert Preise, entwickelt Modelle weiter und kann Bestandteil eines kritischen Projekts werden.
Damit ist KI-Nutzung auch Supplier-Nutzung.
Schatten-KI entsteht oft nicht aus böser Absicht
Es wäre zu einfach, Mitarbeitenden Regelbruch zu unterstellen.
Schatten-KI kann aus sehr pragmatischen Gründen entstehen:
Ein Team möchte schneller recherchieren.
Ein Projektleiter braucht Hilfe bei einer Präsentation.
Marketing testet Bildgenerierung.
Ein Entwickler verwendet ein Coding-Tool.
Eine Agentur bringt ihren eigenen KI-Stack mit.
Ein bestehender SaaS-Anbieter aktiviert neue AI-Funktionen.
Jede Einzelentscheidung kann vernünftig wirken.
Das Problem entsteht in der Summe.
Denn aus zehn kleinen Tools können zehn neue Providerbeziehungen, Datenpfade und Kostenmodelle werden, ohne dass jemand ein Gesamtbild besitzt.
Die erste Governance-Frage lautet nicht „Ist das erlaubt?“
Sie lautet:
„Wo wird es eingesetzt?“
Erst danach kommen die nächsten Fragen.
Ein sinnvolles Inventar sollte mindestens verbinden:
TOOL / PROVIDER → USE CASE → PROJEKT / PROZESS → DATEN → KOSTEN → OWNER → ENTSCHEIDUNG
Diese Kette verändert die Qualität der Governance erheblich.
Denn die Aussage:
„Wir nutzen ChatGPT, Copilot und weitere KI-Tools“
ist kaum steuerungsrelevant.
Die Aussage:
„Provider X wird im Angebotsprozess von Team Y genutzt, verarbeitet interne Kundendaten, kostet Z Euro im Monat und hat Owner A“
ist steuerbar.
Sieben blinde Flecken einer unbekannten AI-Supplier-Landschaft
1. Niemand kennt die tatsächliche Zahl der Provider
Eine offizielle Softwareliste zeigt nur beschaffte Systeme.
Nicht zwangsläufig:
- kostenlose Accounts,
- Trial-Versionen,
- persönliche Lizenzen,
- eingebettete KI-Funktionen,
- Tools von Agenturen oder Beratungen.
Damit kann die reale Supplier-Landschaft größer sein als das Vendor Register.
2. Projektabhängigkeiten bleiben unsichtbar
Ein Tool kann zunächst als Experiment starten.
Einige Monate später hängt ein Arbeitsschritt daran.
Noch später ist es Teil eines kritischen Prozesses.
Wenn dieser Übergang nicht dokumentiert wird, erkennt das Management nicht, wann aus einem Test eine operative Abhängigkeit geworden ist.
3. Datenflüsse sind schwer bewertbar
W&V beschreibt im Kontext des AI Act die praktische Frage, ob Unternehmen überhaupt wissen, was Mitarbeitende mit KI machen. [1]
Das ist nicht nur eine Kennzeichnungsfrage.
Es betrifft auch:
Welche Informationen werden eingegeben?
Kundendaten?
Interne Strategien?
Vertragsinhalte?
Unveröffentlichte Produktdaten?
Ohne Toolinventar gibt es keine belastbare Zuordnung zwischen Daten und Provider.
4. Kosten verteilen sich unterhalb der Sichtbarkeitsschwelle
Ein einzelnes KI-Abo fällt kaum auf.
50 verteilte Abos können bereits relevant sein.
Zusätzlich entstehen Kosten durch:
- API-Nutzung,
- Cloudverbrauch,
- Integrationen,
- externe Beratung,
- interne Administration.
Wenn niemand die Providerlandschaft konsolidiert, werden diese Kosten getrennt betrachtet.
5. Supplier-Risiken werden nur einmalig geprüft – oder gar nicht
Ein AI-Provider verändert sich.
Modelle werden aktualisiert.
Produkte werden umbenannt.
Funktionen werden ergänzt.
Preise ändern sich.
Nutzungsbedingungen ändern sich.
Damit reicht es nicht, einen Provider irgendwann einmal geprüft zu haben.
Noch schwieriger wird es, wenn er nie offiziell als Supplier erfasst wurde.
6. Verantwortlichkeit bleibt beim Nutzer hängen
In Schatten-Setups lautet der implizite Owner häufig:
„Derjenige, der das Tool nutzt.“
Das reicht nicht.
Denn ein Mitarbeiter kann Anwender sein, aber nicht automatisch verantwortlich für:
- Vertragsprüfung,
- Datennutzung,
- Supplier-Risiko,
- Budget,
- Exit-Plan,
- Compliance.
Der Use Case benötigt einen organisatorischen Owner.
7. Abschalten wird schwieriger als Einschalten
Ein Tool ist schnell eingeführt.
Die Exit-Frage kommt später.
Was passiert mit:
- gespeicherten Daten,
- Prompts,
- Workflows,
- APIs,
- Automatisierungen,
- dokumentiertem Wissen,
- laufenden Projekten?
Ein unbekannter Supplier hat auch keinen geplanten Offboarding-Prozess.
Warum ein generelles KI-Verbot das Problem nicht löst
Eine harte Policy klingt zunächst einfach:
„Nur freigegebene Tools verwenden.“
Das kann sinnvoller Teil der Governance sein.
Aber eine Policy schafft noch keine Visibility.
Mitarbeitende müssen wissen:
- welche Alternativen zugelassen sind,
- wie neue Tools beantragt werden,
- wer schnell entscheidet,
- welche Datenklassen wo genutzt werden dürfen,
- wie Experimente möglich bleiben.
Wenn der Freigabeprozess zu langsam oder unklar ist, steigt der Anreiz für Schattennutzung.
Die Managementfrage lautet deshalb nicht nur:
„Wie verhindern wir Shadow AI?“
Sondern:
„Wie machen wir legitime KI-Nutzung so einfach sichtbar, dass Umgehung unnötig wird?“
AI Governance beginnt mit einem brauchbaren Inventar
Ein AI-Inventar muss nicht sofort ein riesiges Compliance-Projekt sein.
Für operative Steuerung reichen zunächst sieben Felder:
- Provider / Tool
- Use Case
- Projekt oder Prozess
- verwendete Datenkategorie
- Kostenmodell
- fachlicher Owner
- Freigabe-/Review-Status
Damit entsteht erstmals ein Bild, das Procurement, IT, PMO und Fachbereich gemeinsam nutzen können.
AI Governance ist nicht nur Sache der IT
Die IT sieht Systeme.
Procurement sieht Verträge.
Legal sieht Pflichten.
Finance sieht Kosten.
Fachbereiche sehen Use Cases.
PMO sieht Projekte.
Wenn jede Funktion nur ihren Ausschnitt betrachtet, bleibt Shadow AI trotz vieler Kontrollen möglich.
Die eigentliche Governance-Aufgabe lautet deshalb:
diese Perspektiven auf denselben Use Case zu beziehen.
Was der AI Act an der Managementfrage verändert
Die EU-Kommission hat klargestellt, dass der AI Act seit 2. August 2026 grundsätzlich gilt, mit einzelnen gestaffelten Ausnahmen. Die Transparenzpflichten nach Artikel 50 gelten seit diesem Datum; Anbieter und Betreiber bestimmter Systeme müssen je nach Kontext definierte Transparenzanforderungen erfüllen. [2][3]
Für Unternehmen heißt das nicht, dass jedes KI-Projekt dieselbe Kennzeichnung braucht.
Es heißt aber:
Organisationen benötigen belastbare Prozesse, um überhaupt feststellen zu können, welche Pflichten für welchen Use Case relevant sind.
Genau daran scheitert unsichtbare Nutzung schon vor der juristischen Einzelfallprüfung.
Von Shadow AI zu Supplier Visibility
Ein pragmatisches Vorgehen kann in vier Stufen erfolgen.
1. FINDEN
Welche Tools und Provider werden tatsächlich genutzt?
2. ZUORDNEN
In welchem Projekt, Prozess und Use Case?
3. BEWERTEN
Welche Daten, Kosten, Abhängigkeiten und Anforderungen hängen daran?
4. ENTSCHEIDEN
Weiter nutzen, begrenzen, ersetzen, vertraglich regeln oder abschalten?
Damit wird aus einem unsichtbaren Tool eine steuerbare Entscheidung.
Project Intelligence: Die Providerliste reicht nicht
Aus Ramp7-Perspektive ist die relevante Verbindung:
PROVIDER → TOOL → USE CASE → PROJEKT → DATEN → KOSTEN → OWNER → ENTSCHEIDUNG
Ein Vendor Register allein zeigt nicht, wo ein Tool eingesetzt wird.
Eine Projektliste allein zeigt nicht, welche externen KI-Abhängigkeiten darin stecken.
Ein Kostenreport allein zeigt nicht, welchen Use Case ein Abo unterstützt.
Project Intelligence verbindet diese Perspektiven.
Daraus wird ausdrücklich nicht abgeleitet, dass Ramp7 heute Shadow AI automatisch entdeckt, Datenflüsse scannt, Compliance prüft, Security überwacht oder KI-Tools technisch blockiert.
Solche Produktclaims benötigen gesonderte Freigaben.
Acht Fragen für den nächsten AI-Governance-Review
- Können wir alle produktiv oder regelmäßig genutzten KI-Tools benennen?
- Wissen wir, welche Provider hinter eingebetteten AI-Funktionen stehen?
- Ist jeder relevante Use Case einem Projekt oder Prozess zugeordnet?
- Wissen wir, welche Datenkategorien in welchem Tool verarbeitet werden?
- Können wir Kosten je Provider und Use Case zusammenführen?
- Gibt es für jeden kritischen Use Case einen fachlichen Owner?
- Ist definiert, wie neue Tools schnell geprüft und freigegeben werden?
- Wissen wir, wie ein kritisches Tool ersetzt oder abgeschaltet werden könnte?
Wenn mehrere Antworten „Nein“ lauten, fehlt wahrscheinlich nicht die nächste KI-Policy.
Es fehlt Supplier Visibility.
Fazit: Unsichtbare KI ist vor allem unsichtbare Abhängigkeit
Der W&V-Beitrag bringt die praktische Herausforderung gut auf den Punkt:
Unternehmen können nur das organisieren, was sie kennen. [1]
Mit dem AI Act gewinnt diese Frage zusätzliche regulatorische Relevanz.
Aber auch ohne Rechtsrahmen ist die Managementlogik eindeutig.
Ein unbekanntes KI-Tool ist:
- ein unbekannter Provider,
- eine unbekannte Projektabhängigkeit,
- ein unbekannter Datenpfad,
- möglicherweise ein unbekannter Kostenblock.
Deshalb beginnt AI Governance nicht mit dem perfekten Regelwerk.
Sie beginnt mit einer einfachen Frage:
Welche KI nutzen wir eigentlich – wo, wofür und unter wessen Verantwortung?