Shadow AI sichtbar machen: Telemetrie statt neuem Vendor

Der Logicalis CIO Report 2026 liefert eine Zahl, die in den meisten IT-Leitungen unangenehm sitzt: Nur 37 Prozent der CIOs haben volle Sichtbarkeit auf die im Unternehmen genutzten KI-Tools. Bitkom kommt auf 40 Prozent der Unternehmen mit 20 oder mehr Mitarbeitenden, die private KI-Tool-Nutzung im eigenen Haus vermuten. Im Mittelstand verschärft sich das Bild: kleinere Governance-Pools, höhere Tool-Dichte pro Kopf, kürzere Onboarding-Wege bei neuen SaaS-Diensten. Wer das Problem ernst nimmt, bekommt aus mehreren Richtungen Verkaufsangebote für AI-Posture-Management. Wir sehen in Projekten regelmäßig, dass davon in 80 Prozent der Fälle nichts gebraucht wird. Drei Telemetrie-Quellen, die das Haus ohnehin hat, reichen für ein belastbares Inventar in unter zwei Wochen: DNS-Logs, SSO-Telemetrie, Endpoint-Discovery.

Warum „KI verbieten” nie funktioniert

Verbote verschieben das Problem vom Firmen-Notebook auf das Privat-Gerät. Wer einen Mail-Entwurf in ChatGPT polieren will, macht das spätestens am Smartphone. Was im Verbot landet, sind die Kontrolle und das Audit. Die produktive Strategie ist nicht „KI verbieten”, sondern „sehen, was läuft” und „akzeptable Nutzung definieren”. Sichtbarkeit ist die Voraussetzung jeder Governance-Diskussion. Ohne Sichtbarkeit redet man über Hypothesen, mit Sichtbarkeit über Fakten.

Pattern 1: DNS-Logs als 60-Minuten-Inventar

Jeder API-Aufruf an einen externen LLM-Anbieter verlässt das Netz über DNS. Wer DNS-Auflösungen sieht, sieht die Tools. Im Mittelstand sind die Sichtbarkeits-Quellen meist drei: Firewall-Logs auf pfSense oder OPNsense, Cisco Umbrella oder ähnliche DNS-Layer-Lösungen, lokale Pi-hole-Instanzen für gemanagte Netze.

Die relevante Domain-Liste für 2026 enthält die offensichtlichen Kandidaten und einige weniger offensichtliche. Wir sehen in der Praxis:

Wir sehen in Projekten regelmäßig, dass die ersten fünf das Bild nicht vollständig zeichnen. Ein Hausverwaltungs-Mandant mit unter 80 Mitarbeitenden hatte in sieben Tagen DNS-Auswertung acht unbekannte AI-API-Aufrufe in seinen Logs, davon drei zu kleineren Providern, die in der Standardliste der ersten fünf nicht auftauchen. Das war kein Sicherheitsvorfall, sondern eine ungesteuerte Tool-Auswahl durch einzelne Fachabteilungen. Ohne DNS-Inventar wäre das nie aufgefallen.

Aufwand: 60 Minuten für das Schreiben einer Auswertungs-Query gegen die vorhandenen DNS-Logs, einen halben Tag für Cross-Check und Dokumentation. Tools, die wir gerne nutzen, sind GoAccess oder ein simples Python-Skript, das die Logs gegen die obige Domain-Liste matched.

Pattern 2: SSO-Telemetrie als Tool-Discovery

DNS sieht direkte API-Calls. SSO sieht SaaS-Tools mit eingebauten LLM-Features. Das ist die wirklich unterschätzte Lücke. Notion AI, Slack AI, Atlassian Intelligence (Jira, Confluence), Linear, GitHub Copilot, Salesforce Einstein, HubSpot Breeze: alle laufen über OAuth oder SAML und tauchen damit im SSO-Provider auf. Wer Azure AD, Okta, Google Workspace oder Keycloak im Einsatz hat, hat das Inventar bereits, ohne es zu wissen.

Die Auswertung läuft über die Application-Tabelle des SSO-Providers. Wir filtern auf alle SaaS-Apps, die seit dem 1. Januar 2025 ein LLM-Feature ergänzt haben, und kreuzen das gegen die Liste der aktiven OAuth-Apps. Ein Versicherungs-Backoffice-Mandant mit 240 Endnutzern hatte 12 OAuth-Apps in seinem Azure-AD-Tenant, von denen sieben ein LLM-Feature im Hintergrund laufen lassen, ohne dass es als „AI-Tool” wahrgenommen wurde. Die Entdeckung war erleichternd und entlarvend zugleich: erleichternd, weil keine Schatten-Software in Eigenregie lief, entlarvend, weil die genutzten Tools alle Daten in eine LLM-Pipeline gespeist hatten, ohne dass jemand das aktiv freigegeben hatte.

Aufwand: drei bis fünf Stunden für die Auswertung, ein Tag für die Bewertung der gefundenen Apps gegen das eigene Datenschutz-Konzept. Im Azure-AD-Portal genügt die Application-Übersicht, in Okta die System-Logs-API, in Google Workspace die Reports-API.

Pattern 3: Endpoint-Discovery für lokale Modelle

Lokal installierte LLMs sind das dritte Inventar-Loch. Browser-Extensions für Claude oder ChatGPT, lokale Modell-Runner wie Ollama, LM Studio oder GPT4All laufen am DNS vorbei (Ollama macht keine externen Calls) und am SSO ohnehin. Sichtbar werden sie nur am Endpoint selbst.

Drei Tools liefern hier Resultate:

Microsoft Intune mit Compliance-Policies, die installierte Anwendungen reporten. Wer Intune im Einsatz hat, schreibt einen Custom-Compliance-Check, der nach Ollama, LM Studio, GPT4All, Jan und ein paar anderen sucht. Das Ergebnis landet im Standard-Reporting.

Jamf für die Mac-Flotte mit derselben Logik, plus zusätzlich Browser-Extension-Inventar über die Configuration Profiles.

osquery als Open-Source-Alternative, läuft auf Linux, Mac, Windows, hat eine einfache SQL-artige Query-Sprache und macht das Endpoint-Inventar zur Datenbank-Abfrage. Für Häuser ohne Intune oder Jamf der pragmatische Weg.

Ein Logistik-Mittelständler mit 180 Endpoints hatte 17 Prozent seiner Geräte mit Ollama oder LM Studio bestückt. Das war kein Compliance-Skandal, sondern ein Hinweis, dass die Entwickler im Haus aktiv lokale Modelle ausprobierten. Das richtige Folge-Gespräch war nicht „ihr habt da was Illegales installiert”, sondern „lasst uns einen sauberen Setup-Standard für lokale Modelle bauen, damit ihr unterstützt seid”. Sichtbarkeit hat das Gespräch erst möglich gemacht.

Aufwand: ein Tag für die Custom-Query oder Compliance-Policy, zwei bis drei Tage für die Auswertung über die Flotte. Bei sauberer Vorhandensein eines Endpoint-Management-Tools sind das Stunden, nicht Tage.

Was die drei Quellen zusammen zeigen

Nach zwei Wochen Inventur-Sprint hat das Haus drei Listen: externe AI-APIs aus DNS, SaaS-Tools mit AI-Features aus SSO, lokale Modell-Installationen aus Endpoint-Discovery. Die Schnittmenge dieser drei Listen ist das Inventar-Bild, das die Logicalis-Zahl meint, wenn sie von „voller Sichtbarkeit” spricht. In 80 Prozent der Mittelstands-Projekte erreichen wir damit eine belastbare Abdeckung. Die restlichen 20 Prozent betreffen Edge Cases wie Mobile-Geräte mit Privat-Browser-Profilen oder Webhook-basierte Integrationen, die ohne Browser-Session laufen. Für diese Fälle lohnen weitere Maßnahmen, aber sie sind nicht der Anfang.

NIS-2 verlangt in Art. 21 ein Risikomanagement, das auch die eingesetzten IT-Systeme erfasst. Ein dokumentiertes KI-Inventar nach dem hier beschriebenen Verfahren erfüllt diese Anforderung praktisch direkt. Die Audit-Diskussion wird damit kurz und sachlich. Wir haben den NIS-2-Kontext separat im Beitrag zu NIS-2-Compliance ausgearbeitet.

Drei Anti-Patterns

„Wir kaufen einen AI-Discovery-Vendor.” Ein Posture-Management-Tool liegt im Mittelstand schnell bei 30.000 bis 80.000 Euro pro Jahr und liefert für die ersten 80 Prozent nichts, was DNS plus SSO plus osquery nicht auch liefert. Der richtige Zeitpunkt für einen Vendor ist, wenn die drei Quellen ausgereizt sind und konkrete Posture-Fragen offen bleiben. Das ist selten der erste Sprint.

„Wir machen eine Mitarbeiter-Umfrage.” Mitarbeiter beantworten die Frage „Welche KI-Tools nutzt ihr?” systematisch falsch. Wer ein Tool nutzt, das in einer Grauzone steht, gibt es nicht zu. Wer eines nutzt, das technisch unscheinbar wirkt (Browser-Extension, kleine Plugin-Integration), erinnert sich nicht. Die Antworten sind nicht falsch aus Unehrlichkeit, sondern aus Erinnerungslücken und Tabu-Effekten. Telemetrie ist Mitarbeiter-Befragungen in dieser Frage strukturell überlegen.

„Wir blockieren KI-Domains.” Verschiebt das Problem ins Privat-Gerät und zerstört gleichzeitig die Compliance-fähige Telemetrie. Wer blockiert, sieht nicht mehr, was läuft. Wer akzeptiert und beobachtet, kann steuern.

Brücke zum Watermarking

Ohne Inventar kein Watermarking. Wer nicht weiß, welche Systeme im Haus KI-Output erzeugen, kann nicht entscheiden, welche davon nach Art. 50(2) maschinenlesbar kennzeichnen müssen. Der hier beschriebene Inventur-Sprint ist die Voraussetzung für jeden Watermarking-Plan. Wir haben den regulatorischen und implementierungs-technischen Teil dazu separat in unserem Beitrag zur Watermarking-Pflicht aufgearbeitet, der ab dem 2. August 2026 für Provider generativer KI-Systeme greift.

Fazit und Inventur-Checkliste

Shadow AI ist im Mittelstand kein Vendor-Problem, sondern ein Telemetrie-Problem. Wer die vorhandenen Quellen sauber auswertet, hat in zwei Wochen ein belastbares Inventar, das NIS-2-anschlussfähig ist und die Voraussetzung für jede weitere Governance-Diskussion bildet. Die folgende Checkliste fasst den Sprint zusammen und ist als druckbare Vorlage gedacht.

Gesamtaufwand: ein Wochenende konzentrierter Arbeit oder zwei Wochen verteilt, je nach Team-Größe. Kein neuer Vendor, kein neues Tool, keine Posture-Management-Subscription.

EverBright IT begleitet Mittelständler bei der Shadow-AI-Inventur von der Telemetrie-Auswertung bis zur Übergabe an die Watermarking-Planung. Mehr zu unserer KI-Beratung oder direkt Kontakt aufnehmen.

Häufige Fragen

Brauche ich für die Shadow-AI-Inventur ein neues Tool?

In 80 Prozent der Mittelstands-Setups nicht. DNS-Logs, SSO-Telemetrie und Endpoint-Management-Reports liefern die nötige Datengrundlage. Ein dediziertes AI-Posture-Management-Tool wird erst sinnvoll, wenn diese drei Quellen ausgereizt sind und konkrete Posture-Fragen offen bleiben.

Wie oft sollte die Inventur wiederholt werden?

Quartalsweise ist der pragmatische Rhythmus. Die Tool-Landschaft ändert sich monatlich, ein quartalsweiser Sprint erkennt neue Anbieter, neue SaaS-Features und neue lokale Installationen früh genug. Wer in regulierten Branchen unterwegs ist, sollte den Rhythmus auf monatlich oder ereignisbezogen verkürzen.

Was passiert mit den Mitarbeitern, deren Shadow-AI-Tools auftauchen?

Nichts Disziplinarisches, sondern ein Gespräch. Shadow AI ist Symptom, nicht Schuld. Mitarbeiter greifen zu nicht-genehmigten Tools, wenn das genehmigte Tool fehlt oder nicht passt. Das Folge-Gespräch ist „welches Problem wolltet ihr lösen” und mündet in einer Tool-Freigabe oder einer offiziellen Alternative.

Reicht DNS-Logging alleine?

Nein. DNS sieht nur direkte API-Calls. SaaS-Tools mit eingebauten LLM-Features (Notion AI, Slack AI, Atlassian Intelligence) tauchen im DNS nicht als „AI-Domain” auf, weil der Aufruf serverseitig beim Anbieter passiert. Erst SSO macht diese Schicht sichtbar.

Wie passt das zu NIS-2?

NIS-2 Art. 21 verlangt ein Risikomanagement mit dokumentiertem System-Inventar. Ein nach diesem Verfahren erstelltes KI-Inventar erfüllt die Anforderung praktisch direkt und ist bei Audits als Nachweis vorzeigbar. Für wesentliche und wichtige Einrichtungen nach NIS-2 ist das Inventar nicht Kür, sondern Pflicht.