Schatten-KI blockieren & auf BRANE umleiten

1. Einordnung: Sperren ist Steuerung, keine Mauer

Netzwerk-Blocking verhindert Shadow-AI nicht vollständig — private Smartphones, Copy-Paste und eingebettete KI-Funktionen in SaaS-Tools erreicht es nicht. Seine Aufgabe ist eine andere: die sanktionierte interne KI zum Weg des geringsten Widerstands machen und Sichtbarkeit schaffen.

Die Zahlen dazu (Deutschland, 2025/26):

• In ~42 % der deutschen Unternehmen wird private KI-Nutzung beobachtet oder vermutet; nur 26 % stellen offiziellen KI-Zugang bereit — bei 20–99 Mitarbeitenden sogar nur 23 % (Bitkom, Okt. 2025).
• 66 % der Büroangestellten geben zu, KI-Tools zu nutzen, die sie für verboten halten. Reine Verbote verlagern die Nutzung auf Privatgeräte — dorthin, wo die IT nichts mehr sieht.
• Auch die Datenschutzkonferenz (DSK) empfiehlt ausdrücklich interne Nutzungsregeln statt unkontrollierter „offener“ KI-Systeme (Orientierungshilfe „KI und Datenschutz“, 2024).

2. Vorgehen in vier Phasen

Phase 0 — Messen (1–2 Wochen, Aufwand: klein)

Vor dem Sperren die Ist-Nutzung erheben — das ist zugleich die Baseline für den Erfolgsnachweis:

• M365-Umgebungen: Microsoft Defender for Cloud Apps → Cloud Discovery → Kategorie „Generative AI“ filtern. Zeigt pro App Nutzerzahl und Datenvolumen — ohne Zusatzinstallation, wenn Defender for Endpoint (Business Premium/E5) im Einsatz ist.
• Alle anderen: Firewall-KI-Kategorie 1–2 Wochen im Monitor-Modus laufen lassen; DNS-/Proxy-Logs nach den Domains aus Abschnitt 3 auswerten.
• Ergebnis: welche Dienste, wie viele Nutzer, welche Abteilungen.

Phase 1 — Netzwerk-Sperre (Aufwand: klein bis mittel)

Weg A — Firewall-Kategorie (empfohlen, wenn NGFW vorhanden): Alle gängigen Hersteller haben inzwischen eine fertige, selbst-aktualisierende KI-Kategorie:

Hersteller	Kategorie	Hinweis
Sophos Firewall	App-Kategorie „Generative AI“ (Signatur-Paket ≥ 18.20.86)	Benötigt Web Protection / Xstream
Fortinet FortiGate	FortiGuard-Webfilter „Artificial Intelligence Technology“ (Kategorie 100), ab FortiOS 7.4.1	Ohne SSL-Deep-Inspection wird per SNI geblockt (wirksam, aber Browser-Fehlerseite statt Sperrseite)
Palo Alto	URL-Kategorie „artificial-intelligence“, granulare Unterkategorien (z. B. AI Conversational Assistant)	Bietet auch „Continue“-Coaching-Seite
Check Point	App-Kategorie „Generative AI Tools“
Cisco Umbrella / DNSFilter	DNS-Kategorie „Generative AI“	Neue KI-Apps werden automatisch ergänzt

Weg B — DNS-Filter (wenn keine NGFW-Lizenz): Interner DNS/AD-DNS mit Override-Zonen oder Pi-hole/AdGuard Home mit gepflegter Liste. Beste freie Liste: UT1 „ai“ der Université Toulouse (täglich gespiegelt auf GitHub: olbat/ut1-blacklists, Datei blacklists/ai/domains). Manuell gepflegte Einzellisten veralten in Wochen — jemand muss die Pflege besitzen.

Bypass-Wege gleich mitschließen (Pflichtprogramm, je ~15 Minuten)

1. QUIC/HTTP-3 blocken: UDP 443 (und UDP 80) ausgehend sperren — sonst tunnelt der Browser an der TLS-Inspektion vorbei. Sauberer Fallback auf TCP, keine Nutzerauswirkung.
2. DoT blocken: TCP/853 ausgehend sperren.
3. DoH blocken: bekannte öffentliche DoH-Resolver sperren (dns.google, cloudflare-dns.com, 1.1.1.1, 8.8.8.8, 9.9.9.9 …); viele NGFWs haben eine „DNS over HTTPS“-App-Signatur.
4. Browser-DoH per Policy aus: Chrome/Edge DnsOverHttpsMode = off per GPO/Intune; Firefox: Canary-Domain use-application-dns.net am internen Resolver mit NXDOMAIN beantworten und/oder Enterprise Policy DNSOverHTTPS: Enabled=false.

Phase 2 — Freundliche Umleitung statt Fehlermeldung (Aufwand: mittel)

Der Unterschied zwischen „IT hat schon wieder was gesperrt“ und „aha, wir haben ja was Besseres“ ist die Sperrseite.

Das HTTPS-Problem ehrlich benannt: Wer chatgpt.com per DNS auf einen internen Server umbiegt, bekommt im Browser zuerst eine TLS-Zertifikatswarnung — der interne Server kann kein gültiges Zertifikat für chatgpt.com vorweisen. Es gibt genau drei saubere Auswege:

1. Interne CA auf verwaltete Geräte verteilen (GPO/Intune, AD CS oder CA des Filterherstellers). Der Sperrserver stellt dann pro Domain gültige Zertifikate aus. Beste UX, funktioniert nur auf verwalteten Geräten.
2. Sperrseite von Firewall/Proxy ausliefern lassen — wenn TLS-Inspektion ohnehin aktiv ist, liefert die NGFW eine echte, anpassbare Sperrseite.
3. TLS-Fehler akzeptieren und die Umleitung stattdessen kommunikativ lösen (Intranet-Meldung, E-Mail, Browser-Startseite). Null Aufwand, schlechteste UX.

Inhalt einer guten Umleitungsseite (bewährtes „Coach-Page“-Muster):

1. Was passiert ist, ohne Schuldzuweisung: „ChatGPT ist im Firmennetz nicht verfügbar.“
2. Warum, in einem Satz: Datenschutz/Kundendaten — nicht „verboten“.
3. Die Alternative, ein Klick entfernt: großer Button → interne BRANE-URL, idealerweise mit SSO — der Nutzer chattet 10 Sekunden später.
4. Ausweichpfad: Kontakt/Formular für Ausnahmen und Tool-Wünsche (entlastet den Helpdesk und speist die Governance).

Minimalbeispiel:

<!doctype html><meta charset="utf-8">
<title>Externe KI ist hier nicht verfügbar</title>
<div style="max-width:520px;margin:15vh auto;font-family:system-ui;text-align:center">
  <h1>Dieser KI-Dienst ist im Firmennetz nicht verfügbar</h1>
  <p>Zum Schutz von Kunden- und Unternehmensdaten leiten wir KI-Anfragen
     über unsere interne, sichere KI-Plattform.</p>
  <p><a href="https://brane.IHRE-DOMAIN.de" style="display:inline-block;
     padding:12px 28px;background:#0085C7;color:#fff;border-radius:8px;
     text-decoration:none;font-weight:600">→ BRANE öffnen — gleiche Frage, sicher</a></p>
  <p style="color:#667"><small>Tool-Wunsch oder Ausnahme nötig?
     <a href="mailto:it@IHRE-DOMAIN.de">IT kontaktieren</a></small></p>
</div>

Sanfter Einstieg: Wo verfügbar, zunächst Warn-Modus statt Hart-Block (Microsoft Defender „Warn“, Palo Alto „Continue“-Seite): Hinweis + Weiter-auf-eigene-Verantwortung, nach 2–4 Wochen auf Block umstellen.

Phase 3 — Betrieb (laufend, Aufwand: klein)

• Ausnahmeprozess definieren (wer darf was beantragen, wer entscheidet, SLA).
• Monatsreport: Block-Ereignisse (Firewall/DNS) neben BRANE-Nutzung stellen. Erfolg = Block-Ereignisse sinken, weil die interne Nutzung steigt — nicht, weil die Nutzung auf Handys abwandert.
• Kategorie-Feeds aktuell halten; bei Einzellisten: Quartals-Review.

3. Domain-Referenz

Tier 1 — Große Consumer-Chatbots (immer sperren)

Dienst	Domains	Hinweise
ChatGPT	chatgpt.com (Wildcard) · chat.openai.com (Legacy-Redirect) · ios.chat.openai.com, android.chat.openai.com, desktop.chat.openai.com (native Apps!) · auth.openai.com, auth0.openai.com · *.oaistatic.com · *.oaiusercontent.com (Datei-Up-/Downloads) · sora.com, sora.chatgpt.com	*.openai.com nicht pauschal wildcarden, sonst stirbt auch platform.openai.com (Entwicklerkonsole). Geteilte Drittanbieter (Stripe, Cloudflare-Challenges, Intercom) nie global sperren.
Claude	claude.ai · *.claudeusercontent.com · downloads.claude.ai · optional platform.claude.com + api.anthropic.com (trifft dann auch API/Claude Code)	Sauberster Fall: alles dedizierte Domains.
Google Gemini	gemini.google.com (eigene A-Records, per DNS/SNI sperrbar) · bard.google.com (Legacy) · aistudio.google.com, makersuite.google.com · notebooklm.google.com · API: generativelanguage.googleapis.com	Nie per IP sperren, nie accounts.google.com. KI-Antworten in der Google-Suche sind per DNS nicht abtrennbar. Der von Google unterstützte Weg ist der Workspace-Service-Toggle (NotebookLM hat einen eigenen).
Microsoft Copilot	copilot.microsoft.com · copilot.com · copilot.ai · copilot.cloud.microsoft	bing.com/chat und m365.cloud.microsoft/chat sind nicht per DNS abtrennbar (geteilte Domains). Microsoft rät explizit von Netzwerk-Sperren ab — unterstützte Wege: M365 Integrated-Apps-Sperre, Edge-Policies, AppLocker, Tenant Restrictions v2 gegen private Microsoft-Konten.

Tier 2 — Weitere Chatbots (Kategorie-Filter deckt die meisten ab)

perplexity.ai (+ pplx.ai) · poe.com (+ *.poecdn.net) · *.deepseek.com · grok.com + x.ai (Achtung: Grok in X unter x.com/i/grok nur per Pfadfilter) · chat.mistral.ai (+ code.mistral.ai) · meta.ai (eingebettete Meta-KI in WhatsApp/Instagram ist nicht abtrennbar) · character.ai (+ c.ai) · you.com · pi.ai (+ heypi.com) · chat.qwen.ai + tongyi.aliyun.com · kimi.com (+ kimi.ai, kimi.moonshot.cn) · manus.im · chat.z.ai, chatglm.cn · doubao.com · yuanbao.tencent.com · yiyan.baidu.com · genspark.ai · duck.ai · janitorai.com · jasper.ai · copy.ai · elevenlabs.io

Tier 3 — API-Endpunkte (bewusst entscheiden)

Endpunkt	Kollateralschaden bei Sperrung
api.openai.com	Alle lokalen Skripte/SDKs, IDE-Plugins, Fachanwendungen mit eigenem Key
api.anthropic.com	Claude Code CLI und SDKs komplett
generativelanguage.googleapis.com	Gemini-SDKs. Nie *.googleapis.com — das trifft Drive, OAuth, GCP
openrouter.ai	Web + API auf einer Domain — siehe Warnung oben (BRANE-Cloud-Anbindung!)
api.mistral.ai, api.groq.com, api.together.ai, api.x.ai, api.deepseek.com, api.perplexity.ai, api.cohere.com, api.fireworks.ai	Nur Entwickler-Tooling, geringer Kollateralschaden
*.openai.azure.com, bedrock*.amazonaws.com	Trifft auch eigene sanktionierte Azure-OpenAI-/Bedrock-Deployments — nie pauschal
Coding-Assistenten: *.cursor.sh + *.cursorapi.com · *.githubcopilot.com · *.codeium.com/*.windsurf.com	Copilot: Business-Plan-Endpunkte (*.enterprise.githubcopilot.com) lassen sich getrennt erlauben, Free/Pro sperren

Grenzen der Netzwerk-Sperre (ehrlich kommunizieren)

Per Domain nicht erreichbar: KI in der Google-Suche und in Bing, Grok in X, Meta-KI in WhatsApp/Instagram, eingebettete KI in sanktioniertem SaaS (Notion, Slack, Zoom, Canva, Grammarly), lokale Browser-Modelle (WebGPU), private Smartphones im Mobilfunknetz, Copy-Paste. Mobile Apps nutzen zudem Certificate Pinning — TLS-Inspektion sieht sie nicht; hier hilft nur der Hostname-Block plus MDM. Diese Lücken sind der Grund, warum die Netzwerkebene mit einer Endpoint-/Browser-Ebene kombiniert wird — die BRANE Browser Extension (Roadmap) adressiert genau diese Schicht.

4. Rechtlicher Rahmen (Deutschland)

• Mitbestimmung (§ 87 Abs. 1 Nr. 6 BetrVG): Gateways, Proxies und Filter, die protokollieren, sind objektiv zur Verhaltenskontrolle geeignet — nach gefestigter BAG-Linie mitbestimmungspflichtig, unabhängig von der Absicht. Das ArbG Hamburg (16.01.2024 – 24 BVGa 1/24) hat Nutzungsrichtlinien für ChatGPT über Privat-Accounts zwar mitbestimmungsfrei gestellt — sobald aber Sperr-/Umleitungsinfrastruktur mit Logging in der eigenen IT läuft, gilt das Urteil ausdrücklich nicht. Praxis: Betriebsrat früh einbinden; bestehende IT-/Internet-Betriebsvereinbarung prüfen und ergänzen. Häufig ist Browser-/Internetnutzung dort schon geregelt — dann ist der Weg kurz.
• Datenschutz (Art. 6 DSGVO, § 26 BDSG): Block- und DNS-Logs mit Nutzerbezug sind personenbezogene Daten. Grundsätze: aggregierte Statistik statt personenbezogener Dashboards, Stichproben statt Dauerüberwachung, definierte Löschfristen, DSFA bei systematischer Überwachung. Ob Privatnutzung des Internets erlaubt ist, ändert den zulässigen Auswertungsumfang erheblich — vorher klären und schriftlich regeln.
• EU AI Act, Art. 4 (KI-Kompetenz): Seit 02/2025 in Kraft, seit 08/2026 durchsetzbar — Arbeitgeber müssen für ausreichende KI-Kompetenz der Beschäftigten sorgen. Eine KI-Nutzungsrichtlinie + Schulung + sanktioniertes internes Tool ist genau das Compliance-Artefakt, das Art. 4 verlangt — dieser Leitfaden zahlt direkt darauf ein.
• Orientierung: BSI „Generative KI-Modelle — Chancen und Risiken“ (2025), DSK-Orientierungshilfe „KI und Datenschutz“ (2024), Bitkom-Leitfaden „Generative KI im Unternehmen“.

5. Kommunikation: erst ankündigen, dann schärfen

Reihenfolge, die sich bewährt hat:

1. T−2 Wochen: Ankündigung (Intranet/E-Mail): Warum (Datenschutz, nicht Misstrauen), was sich ändert, was stattdessen da ist (BRANE, mit Login-Link und 3-Zeilen-Anleitung), ab wann.
2. T−0: Warn-Modus aktiv (wo verfügbar), Umleitungsseite live.
3. T+2 bis 4 Wochen: Hart-Block. Parallel kurze BRANE-Onboarding-Sessions je Abteilung (zahlt auf AI-Act-Art.-4-Schulung ein).
4. Laufend: Tool-Wunsch-Kanal offen halten; Quartalsbericht an die Geschäftsführung (Nutzung intern vs. Block-Ereignisse).

Textbaustein für die Ankündigung:

Ab dem [DATUM] sind öffentliche KI-Dienste wie ChatGPT im Firmennetz nicht mehr erreichbar. Der Grund ist nicht die KI — sondern wohin dabei unsere Daten fließen. Mit [BRANE-URL] steht euch ab sofort eine interne KI zur Verfügung, die dieselben Aufgaben übernimmt und bei der Firmendaten das Haus nicht verlassen. Fragen, Wünsche, Ausnahmen: [KONTAKT].

6. Checkliste

• Phase 0: 1–2 Wochen Ist-Messung (Cloud Discovery / Firewall-Monitor-Modus)
• Betriebsrat informiert / Betriebsvereinbarung geprüft
• Datenschutz: Logging-Konzept (aggregiert, Löschfristen), ggf. DSFA
• Ankündigung an Belegschaft raus (T−2 Wochen)
• NGFW-KI-Kategorie oder DNS-Filter mit gepflegter Liste aktiv
• openrouter.ai-Zugang der BRANE-Box per Allowlist gesichert
• QUIC (UDP 443), DoT (853), bekannte DoH-Resolver gesperrt; Browser-DoH per GPO aus
• Umleitungsseite live (interne CA verteilt oder Proxy-Sperrseite)
• BRANE-Button auf der Sperrseite getestet (SSO, 1 Klick)
• Warn-Modus 2–4 Wochen, dann Hart-Block
• Ausnahmeprozess definiert und kommuniziert
• Monatsreport: Block-Ereignisse vs. BRANE-Nutzung

Quellen (Auswahl)

• OpenAI: Network recommendations for ChatGPT (help.openai.com, Artikel 9247338)
• Anthropic/Claude Code: code.claude.com/docs/en/network-config
• Google Workspace: support.google.com/a/answer/14571493 (Gemini-Service-Toggle)
• Microsoft: learn.microsoft.com/copilot/manage · learn.microsoft.com/defender-cloud-apps/tutorial-shadow-it
• Fortinet: „Protecting GenAI access using web filter“ (FortiOS-Doku) · Sophos Community: „Generative AI policy enforcement“
• UT1-Blacklist „ai“: dsi.ut-capitole.fr/blacklists (GitHub-Mirror: olbat/ut1-blacklists)
• DoH/QUIC: help.zscaler.com/zia/managing-quic-protocol · support.mozilla.org (Canary-Domain)
• Bitkom: Presseinformation „Beschäftigte nutzen Schatten-KI“ (Okt. 2025) · Leitfaden „Generative KI im Unternehmen“
• BSI: „Generative KI-Modelle — Chancen und Risiken für Industrie und Behörden“ (2025)
• DSK: Orientierungshilfe „KI und Datenschutz“ (Mai 2024)
• ArbG Hamburg, 16.01.2024 – 24 BVGa 1/24 (Besprechungen: Gleiss Lutz, Bird & Bird, CMS)
• EU AI Act Art. 4: artificialintelligenceact.eu/article/4