KI-Governance für KMU: Datenklassen, EU AI Act & CLOUD Act
Stand: Mai 2026 Zielgruppe: Geschäftsführung, Datenschutzbeauftragte, IT-Leitung, Informationssicherheit, Einkauf, Compliance, Fachbereichsleitung, KI-/Digitalisierungsverantwortliche. Zweck: Allgemeine Beratungs-, Entscheidungs- und Orientierungsvorlage für den kontrollierten Einsatz von KI-Systemen in Unternehmen — nutzbar für KMU/SMU sowie als Diskussionsgrundlage in Geschäftsführungs- oder Datenschutz-Runden.
1. Executive Summary
Der Einsatz von KI-Systemen in Unternehmen ist im Jahr 2026 kein reines Innovations- oder IT-Thema mehr. Er betrifft Datenschutz, Informationssicherheit, Arbeitsrecht, Geschäftsgeheimnisse, Urheberrecht, Haftung, Lieferantenmanagement, Cloud-Strategie und Governance.
Die zentrale Frage lautet nicht:
„Welches KI-Tool ist datenschutzkonform?"
Die bessere Frage lautet:
„Welches KI-System ist für welche Datenklasse, welchen Use Case, welches Betriebsmodell, welche regulatorische Risikostufe und welche Unternehmensanforderung vertretbar?"
Ein KI-System wird nicht allein dadurch datenschutzkonform, dass es in einer EU-Region betrieben wird oder mit „Enterprise Security", „DSGVO-konform" oder „Privacy first" beworben wird. Entscheidend ist die kontrollierte Kombination aus:
- Datenklassifizierung
- Use-Case-Bewertung
- Anbieter- und Betriebsmodell
- AVV/DPA
- Drittlandtransferprüfung
- US-CLOUD-Act-/Schrems-Risiko
- Retention- und Logging-Konzept
- SSO, SCIM, Rollen und Audit Logs
- No-Training-Zusage
- interne Nutzungsrichtlinie
- Mitarbeiterschulung / AI Literacy
- EU-AI-Act-Einordnung
- Betriebsrat / Arbeitnehmervertretung, falls vorhanden
- technische Durchsetzung gegen Shadow AI
- laufende Überprüfung, da Anbieter, Modelle und regulatorische Rahmenbedingungen sich schnell ändern
Die wichtigste Empfehlung:
Unternehmen sollten nicht „ein KI-Tool für alles" freigeben, sondern eine KI-Freigabematrix nach Datenklassen und Use Cases einführen.
2. Zielbild: KI-Governance statt reine Tool-Auswahl
Viele Unternehmen beginnen ihre KI-Strategie mit der Frage, ob sie ChatGPT, Claude, Gemini, Copilot, Grok, Mistral, Langdock oder eine andere Lösung einsetzen sollen. Diese Frage ist verständlich, aber zu spät in der Entscheidungskette.
Die richtige Reihenfolge lautet:
- Welche Aufgaben sollen mit KI unterstützt werden?
- Welche Daten werden dabei verarbeitet?
- Welche Schutzklasse haben diese Daten?
- Handelt es sich um personenbezogene Daten?
- Handelt es sich um Geschäftsgeheimnisse?
- Gibt es arbeitsrechtliche oder mitbestimmungsrechtliche Auswirkungen?
- Kann der Use Case unter den EU AI Act fallen?
- Reicht ein Business-SaaS-Tool?
- Braucht es eine Enterprise/API-Lösung?
- Ist eine EU-/DE-/Sovereign-/On-Prem-Lösung erforderlich?
- Welche technischen und organisatorischen Kontrollen müssen eingerichtet werden?
Die Kernaussage:
KI-Einsatz wird nicht durch einen einzelnen Anbieter rechtssicher, sondern durch eine Kombination aus Anbieterwahl, Betriebsmodell, Datenklassifizierung, Verträgen, technischen Kontrollen, internen Nutzungsregeln und dokumentierter Governance.
3. Strategischer Grundsatz
Unternehmen sollten KI-Systeme nach drei Ebenen bewerten:
3.1 Rechtliche Ebene
- DSGVO
- BDSG
- Geschäftsgeheimnisgesetz
- Arbeitsrecht
- Mitbestimmung / Betriebsrat
- Urheberrecht
- Vertragsrecht
- Berufsgeheimnisse, falls relevant
- Branchenregulierung
- EU AI Act
- Drittlandtransfer
- US CLOUD Act
3.2 Technische Ebene
- Hosting-Region
- Datenfluss
- Verschlüsselung
- Retention
- Logging
- Zugriffskontrolle
- SSO / SCIM
- Rollenmodell
- Auditierbarkeit
- DLP
- Secret Scanning
- Prompt- und Output-Filter
- RAG-Berechtigungskonzept
- Agenten-/Tool-Berechtigungen
- Monitoring
- Notfall- und Löschkonzept
3.3 Organisatorische Ebene
- KI-Richtlinie
- Tool-Freigabeliste
- Datenklassen
- Schulung / AI Literacy
- Verantwortlichkeiten
- Freigabeprozesse
- Dokumentation
- DSFA/DPIA bei hohen Risiken
- Anbieterprüfung
- Vertragsprüfung
- regelmäßige Reviews
4. Regulatorischer Rahmen
4.1 DSGVO
Die DSGVO beantwortet primär die Frage:
Darf das Unternehmen diese personenbezogenen Daten in diesem KI-System für diesen Zweck verarbeiten?
Wichtige Prüfpunkte:
| Prüffeld | Bedeutung |
|---|---|
| Rechtsgrundlage | Art. 6 DSGVO, ggf. Art. 9 DSGVO bei besonderen Kategorien personenbezogener Daten |
| Zweckbindung | Daten dürfen nicht beliebig für neue KI-Zwecke weiterverwendet werden |
| Datenminimierung | Nur erforderliche Daten in KI-Systeme eingeben |
| Transparenz | Betroffene Personen müssen wissen, was mit ihren Daten geschieht |
| AVV/DPA | notwendig, wenn Anbieter als Auftragsverarbeiter agiert |
| TOMs | technische und organisatorische Maßnahmen |
| Löschfristen | Retention und Löschung müssen geregelt sein |
| Betroffenenrechte | Auskunft, Löschung, Berichtigung, Widerspruch |
| DSFA/DPIA | bei hohem Risiko erforderlich |
| Subprozessoren | Unterauftragnehmer prüfen |
| Drittlandtransfer | Kapitel V DSGVO, SCCs, DPF, TIA, zusätzliche Maßnahmen |
4.2 US CLOUD Act und Drittlandtransfer
Der US CLOUD Act ist relevant, wenn ein Anbieter oder dessen Muttergesellschaft US-Recht unterliegt.
Das betrifft insbesondere viele international führende KI- und Cloud-Anbieter, unter anderem:
- OpenAI
- Anthropic
- Microsoft
- AWS
- xAI
- Perplexity
- IBM
- teilweise Cohere, je nach Vertrags- und Hostingstruktur
Wichtig:
Eine EU-Region reduziert Risiken, beseitigt aber nicht automatisch jedes Drittland- oder CLOUD-Act-Risiko. Laut EDPB/EDPS kann der US CLOUD Act bei US-Anbietern zu Konflikten mit DSGVO-/EU-Recht führen; deshalb sind EU-Region, AVV/DPA, SCCs, Transfer Impact Assessment, Retention und technische Zusatzmaßnahmen gemeinsam zu prüfen.
Prüffragen:
| Prüffrage | Bedeutung |
|---|---|
| Ist der Anbieter oder die Muttergesellschaft US-rechtlich erreichbar? | Potenzielles Herausgabeverlangen möglich |
| Liegen Daten in der EU? | Hilfreich, aber nicht allein ausreichend |
| Können US-Admins, Support oder Subprozessoren zugreifen? | Supportzugriff kann relevant sein |
| Gibt es kundenseitig kontrollierte Schlüssel? | Reduziert Klartextzugriff |
| Gibt es Zero Data Retention? | Reduziert Datenbestand beim Anbieter |
| Gibt es Standardvertragsklauseln? | Für Drittlandtransfer relevant |
| Gibt es ein Transfer Impact Assessment? | Bewertung des tatsächlichen Risikos |
| Gibt es DPF-Zertifizierung? | Kann Übermittlung stützen, ersetzt aber nicht jede Risikoprüfung |
| Gibt es EU-/DE-souveräne Betriebsmodelle? | Für hohe Schutzklassen oft überzeugender |
4.3 EU-US Data Privacy Framework und Schrems-Risiko
Das EU-US Data Privacy Framework wurde durch die Europäische Kommission als Angemessenheitsrahmen etabliert. Das Gericht der Europäischen Union hat die Angemessenheitsentscheidung im September 2025 bestätigt. Dennoch bleibt das Thema für Unternehmen beobachtungsbedürftig, weil politische Veränderungen, weitere Rechtsmittel und zukünftige Entscheidungen die Rechtslage erneut verändern können.
Für Unternehmen bedeutet das:
- US-Anbieter sind nicht automatisch ausgeschlossen.
- DPF, SCCs und TIA können eine Nutzung ermöglichen.
- Für besonders sensible Daten sollte dennoch eine Ausweichstrategie mit EU-/DE-/Sovereign- oder On-Prem-Optionen bestehen.
- Bei sehr sensiblen Daten sollte nicht allein auf die Stabilität transatlantischer Transfermechanismen vertraut werden.
Empfohlene Formulierung für Entscheidungsunterlagen:
Für Standardaufgaben können US-Enterprise-Anbieter vertretbar sein, wenn AVV/DPA, Drittlandtransferprüfung, Retention, No-Training-Zusage und technische Schutzmaßnahmen sauber geregelt sind. Für Kernprozesse mit hochvertraulichen oder personenbezogenen Daten sollten zusätzlich europäische, souveräne oder private Betriebsmodelle geprüft werden.
4.4 EU AI Act
Der EU AI Act beantwortet die Frage:
Welche regulatorischen Pflichten entstehen durch den Einsatz dieses KI-Systems?
Ein Unternehmen ist häufig nicht Modellanbieter, sondern Deployer bzw. Betreiber eines KI-Systems.
| Rolle | Beispiel | Relevanz |
|---|---|---|
| Provider | Modellanbieter wie OpenAI, Anthropic, Google, Mistral, xAI | Pflichten für Modell-/Systemanbieter |
| Deployer / Betreiber | Unternehmen nutzt KI intern oder gegenüber Kunden | Betreiberpflichten je Use Case |
| Integrator / Dienstleister | Unternehmen baut KI-Systeme für Kunden | kann je nach Gestaltung selbst in Pflichten rutschen |
| Distributor | vertreibt oder vermittelt KI-Systeme | Pflichten je Rolle |
| Importer | bringt KI-Systeme aus Drittstaaten in den EU-Markt | zusätzliche Pflichten möglich |
5. EU-AI-Act-Zeitplan
| Datum | Thema | Bedeutung für Unternehmen |
|---|---|---|
| 2024-08-01 | AI Act in Kraft getreten | Start der Übergangsfristen |
| 2025-02-02 | Verbotene Praktiken und AI Literacy | KI-Kompetenz muss organisatorisch angegangen werden |
| 2025-08-02 | GPAI-Regeln und Governance | betrifft vor allem Modellanbieter, indirekt aber auch Beschaffung |
| 2026-08-02 | Großteil der Regeln, viele Hochrisiko-Anwendungen | Use-Case-Inventar und Risikoklassifizierung sollten vorher stehen |
| 2027-08-02 | bestimmte Hochrisiko-Systeme in regulierten Produkten | relevant bei KI in Produkten/Sicherheitskomponenten |
Wichtig:
Politische Diskussionen über Fristverschiebungen oder Vereinfachungen sollten beobachtet werden. Für die interne Planung sollte jedoch mit den aktuell geltenden Fristen gearbeitet werden, solange keine formale Änderung in Kraft ist.
6. AI Literacy als sofortige Pflicht
Die Pflicht zur KI-Kompetenz ist seit Februar 2025 relevant.
Für Unternehmen heißt das:
- Mitarbeitende dürfen KI nicht „einfach irgendwie" nutzen.
- Es braucht dokumentierte Grundschulungen.
- Besonders wichtig sind:
- Datenschutz
- Geschäftsgeheimnisse
- Halluzinationen
- Urheberrecht
- Prompt Injection
- Quellcode und Secrets
- Meeting-Transkription
- Freigabematrix nach Datenklassen
- Grenzen automatisierter Entscheidungen
- menschliche Kontrolle
- interne Eskalationswege
6.1 Minimalmaßnahmen
| Maßnahme | Umsetzung |
|---|---|
| KI-Basisschulung | alle Mitarbeitenden |
| Power-User-Schulung | Projektleitung, Assistenz, IT, Geschäftsführung, Compliance |
| KI-Richtlinie | kurz, verständlich, verbindlich |
| Tool-Freigabeliste | erlaubt / eingeschränkt / verboten |
| Nachweis | Teilnehmerliste, Schulungsunterlage, Aktualisierung alle 6–12 Monate |
| Wiederholung | bei neuen Tools, neuen Use Cases oder regulatorischen Änderungen |
7. Branchenspezifische Einordnung
Dieser Report ist allgemein nutzbar. Die konkrete Risikobewertung hängt aber stark von Branche und Datenarten ab.
7.1 Typische sensible Daten in Unternehmen
| Datenart | Schutzbedarf |
|---|---|
| Kundennamen und Kontaktdaten | personenbezogen |
| private oder geschäftliche Kundenprojekte | vertraulich / ggf. personenbezogen |
| Angebote und Kalkulationen | Geschäftsgeheimnis |
| Verträge | vertraulich / personenbezogen |
| interne Strategien | Geschäftsgeheimnis |
| Quellcode | vertraulich / IP-relevant |
| technische Dokumentationen | vertraulich |
| Sicherheitskonzepte | hoch vertraulich |
| Mitarbeiterdaten | personenbezogen |
| Bewerbungsunterlagen | personenbezogen / HR-kritisch |
| Meetingaufzeichnungen | personenbezogen, ggf. besonders sensibel |
| Finanzdaten | vertraulich / ggf. personenbezogen |
| Rechts- und Steuerunterlagen | hoch vertraulich |
| Gesundheitsdaten | besonders schutzwürdig |
| Betriebsrats- oder Konfliktgespräche | arbeitsrechtlich sensibel |
| Projektpläne und Zeichnungen | je nach Kontext vertraulich, ggf. personenbezogen |
| Forschungs- und Entwicklungsdaten | Geschäftsgeheimnis |
7.2 Wichtiger Grundsatz
Daten, die auf den ersten Blick rein sachbezogen wirken, können durch Kontext, Projektname, Adresse, Kundenzuordnung, Metadaten oder Dokumentenverknüpfung Personenbezug oder Geschäftsgeheimnischarakter erhalten.
Beispiele:
- Projektunterlagen mit Kundennamen
- Bau- oder Lagepläne mit Adresse
- Supporttickets mit personenbezogenen Details
- Screenshots mit internen Systemdaten
- Quellcode mit Zugangstokens
- Meetingnotizen mit Mitarbeiterbewertung
- Finanz- oder Angebotsdaten mit Einzelkundenbezug
8. Datenklassenmodell für Unternehmen
8.1 Empfohlene Datenklassen
| Klasse | Bezeichnung | Beispiele | Grundregel |
|---|---|---|---|
| K0 | Öffentlich | Website-Texte, öffentliche Produktdaten, Presseinformationen, öffentliche Projektbeschreibungen | frei nutzbar, aber Qualität prüfen |
| K1 | Intern | interne Ideen, nichtkritische Notizen, allgemeine Konzepte, interne Vorlagen ohne vertrauliche Inhalte | Business-KI möglich |
| K2 | Vertraulich | Angebote, Projektpläne, Kundendokumente, Kalkulationen, Quellcode ohne Secrets, interne Strategien | Enterprise/API mit AVV, No Training, Retention, SSO, Audit |
| K3 | Personenbezogen / hoch vertraulich | Kundendaten, Mitarbeiterdaten, Bewerbungen, Meetingtranskripte, Vertragsdaten, private Projektinformationen | nur geprüfte Enterprise-/EU-/Sovereign-Setups |
| K4 | Reguliert / streng vertraulich | Gesundheitsdaten, Rechts-/Steuerakten, KRITIS, Behördenprojekte, Sicherheitsarchitektur, Berufsgeheimnisse | Sovereign Cloud, On-Prem, Air-Gap oder Spezialfreigabe |
8.2 Entscheidungslogik
Entscheidungsablauf als strukturierte Liste:
- KI-Use-Case geplant → Datenklasse bestimmen
- Datenklasse zuordnen und Tooltyp wählen:
- K0 Öffentlich → Consumer oder Business möglich
- K1 Intern → Business-/Team-Account mit No-Training
- K2 Vertraulich → Enterprise/API: AVV, SSO, Audit, Retention
- K3 Personenbezogen / hoch vertraulich → EU-/Sovereign-/Private Setup + DSFA prüfen
- K4 Reguliert / streng vertraulich → Sovereign, On-Prem, Air-Gap, eigene Schlüssel
- AI-Act-Kritikalität prüfen:
- Nein → Freigabe nach Policy
- Ja (HR, Gesundheit, Bonität, Biometrie, automatisierte Entscheidungen) → Rechts-/DSB-/AI-Act-Prüfung erforderlich
9. Anbietergruppen
9.1 Consumer-KI
Beispiele:
- ChatGPT Free / Plus / Pro als Einzelperson
- Claude Free / Pro / Max als Einzelperson
- Google Gemini App privat
- Grok auf X / X Premium / Premium+
- SuperGrok / Grok.com individual
- Perplexity Pro individual
Einschätzung:
Für öffentliche Informationen, allgemeine Ideation und persönliche Produktivität nutzbar. Nicht für vertrauliche Unternehmensdaten, Kundendaten, personenbezogene Daten, Quellcode, Verträge, interne Strategien oder Meetingtranskripte freigeben.
9.2 Business-/Team-SaaS
Beispiele:
- ChatGPT Business
- Claude Team
- Google Workspace Gemini
- Microsoft Copilot for Microsoft 365
- Grok Business
- Langdock
- CompanyGPT / InnFactory
- Perplexity Enterprise Pro
Einschätzung:
Geeignet für interne und teilweise vertrauliche Daten, wenn AVV/DPA, No-Training, SSO, Retention, Audit Logs und Admin-Kontrollen sauber geregelt sind.
9.3 Enterprise-/API-Modelle
Beispiele:
- OpenAI API / ChatGPT Enterprise
- Anthropic API / Claude Enterprise
- Google Vertex AI / Gemini API
- Microsoft Azure OpenAI / Azure AI Foundry
- AWS Bedrock
- xAI API / Grok Enterprise
- Mistral La Plateforme / Enterprise
- Cohere Enterprise
- IBM watsonx.ai
Einschätzung:
Für eigene Anwendungen, RAG, kontrollierte Workflows und Projekt-/Kundendaten besser als Consumer-KI. Datenschutz hängt stark von Region, Vertrag, Retention, Logging und Modellrouting ab.
9.4 Deutsche / europäische / souveräne Optionen
Beispiele:
- T-Systems Sovereign Cloud powered by Google Cloud
- Google Distributed Cloud / air-gapped Varianten
- STACKIT AI Model Serving
- IONOS AI Model Hub
- Aleph Alpha / PhariaAI / Cohere-Aleph Alpha
- Mistral AI
- Private/on-prem LLM
Einschätzung:
Besonders relevant für Unternehmen mit hohen Datenschutzanforderungen, öffentlicher Hand, regulierten Branchen, KRITIS, Gesundheits-/Sozialdaten, Steuer-/Rechtsakten, Berufsgeheimnissen oder streng vertraulichen Projektinformationen.
10. Funktionsmatrix wichtiger KI-Dienste
Legende:
- ✅ = vorhanden / stark
- ◐ = vorhanden, aber eingeschränkt, plan- oder modellabhängig
- ❌ = nicht Kernfunktion / nicht sinnvoll
- ? = öffentlich nicht eindeutig belastbar
| Dienst | LLM/Text | Vision/Bildverstehen | Audio/Speech | Bildgenerierung | Video | Embeddings/RAG | Agents/Tools | Realtime Search/Web | Coding |
|---|---|---|---|---|---|---|---|---|---|
| ChatGPT Consumer | ✅ | ✅ | ✅ | ✅ | ◐ | ◐ | ✅ | ✅/◐ | ✅ |
| ChatGPT Business | ✅ | ✅ | ✅ | ✅ | ◐ | ✅/◐ | ✅ | ✅/◐ | ✅ |
| ChatGPT Enterprise | ✅ | ✅ | ✅ | ✅ | ◐ | ✅ | ✅ | ✅/◐ | ✅ |
| OpenAI API | ✅ | ✅ | ✅ | ✅ | ◐ | ✅ | ✅ | ◐ | ✅ |
| Claude Consumer | ✅ | ✅ | ◐ | ❌/◐ | ❌ | ◐ | ◐ | ◐ | ✅ |
| Claude Team | ✅ | ✅ | ◐ | ❌/◐ | ❌ | ◐ | ✅/◐ | ◐ | ✅ |
| Claude Enterprise | ✅ | ✅ | ◐ | ❌/◐ | ❌ | ✅/◐ | ✅ | ◐ | ✅✅ |
| Anthropic API | ✅ | ✅ | ◐ | ❌/◐ | ❌ | ✅/◐ | ✅ | ◐ | ✅✅ |
| Google Gemini Consumer | ✅ | ✅✅ | ✅ | ✅ | ✅/◐ | ◐ | ✅/◐ | ✅ | ✅ |
| Google Workspace Gemini | ✅ | ✅ | ✅/◐ | ✅/◐ | ✅/◐ | ✅/◐ | ✅/◐ | ✅/◐ | ◐ |
| Google Vertex AI / Gemini API | ✅ | ✅✅ | ✅/◐ | ✅ | ✅/◐ | ✅ | ✅ | ◐ | ✅ |
| T-Systems Sovereign Cloud powered by Google Cloud | ✅ | ✅ | ◐ | ◐ | ◐ | ✅ | ✅ | ◐ | ✅ |
| Google Distributed Cloud / Air-Gap | ✅ | ✅/◐ | ◐ | ◐ | ◐ | ✅ | ✅/◐ | ❌/◐ | ✅/◐ |
| Microsoft Copilot for M365 | ✅ | ✅/◐ | ✅/◐ | ✅/◐ | ◐ | ✅ über M365 Graph | ✅/◐ | ✅/◐ | ◐ |
| Azure OpenAI / Azure AI Foundry | ✅ | ✅ | ✅ | ✅ | ◐ | ✅ | ✅ | ◐ | ✅ |
| AWS Bedrock | ✅ | ✅/◐ | ◐ | ✅/◐ | ✅/◐ | ✅ | ✅ | ◐ | ✅ |
| xAI Grok on X / X Premium+ | ✅ | ✅ | ✅ | ✅ | ✅/◐ | ◐ | ✅/◐ | ✅✅ | ✅ |
| SuperGrok / Grok.com | ✅ | ✅ | ✅ | ✅ | ✅/◐ | ◐ | ✅/◐ | ✅✅ | ✅ |
| xAI API | ✅ | ✅/◐ | ◐ | ✅/◐ | ✅/◐ | ◐ | ✅/◐ | ✅/◐ | ✅ |
| Grok Business | ✅ | ✅ | ✅ | ✅ | ✅ | ◐ | ✅ | ✅✅ | ✅ |
| Grok Enterprise | ✅ | ✅ | ✅ | ✅ | ✅ | ◐ | ✅ | ✅✅ | ✅ |
| Perplexity Consumer/Pro | ✅ | ◐ | ◐ | ◐ | ❌/◐ | ◐ | ◐ | ✅✅ | ◐ |
| Perplexity Enterprise | ✅ | ◐ | ◐ | ◐ | ❌/◐ | ✅/◐ | ✅/◐ | ✅✅ | ◐ |
| IBM watsonx.ai | ✅ | ◐ | ◐ | ◐ | ◐ | ✅ | ✅ | ◐ | ✅/◐ |
| Cohere | ✅ | ◐ | ❌/◐ | ❌/◐ | ❌/◐ | ✅✅ | ✅/◐ | ◐ | ✅/◐ |
| Mistral AI | ✅ | ✅/◐ | ◐ | ✅/◐ | ◐ | ✅ | ✅/◐ | ◐ | ✅ |
| Aleph Alpha / PhariaAI | ✅ | ◐ | ◐ | ◐ | ◐ | ✅ | ✅ | ◐ | ✅/◐ |
| STACKIT AI Model Serving | ✅ | ◐ | ❌/◐ | ◐ | ❌/◐ | ◐ | API-basiert | ❌/◐ | ✅/◐ |
| IONOS AI Model Hub | ✅ | ◐ | ❌/◐ | ✅/◐ | ❌/◐ | ✅ | API-basiert | ❌/◐ | ✅/◐ |
| Langdock | ✅ über Modellmix | ✅/◐ | ◐ | ✅/◐ | ◐ | ✅ | ✅ | ✅/◐ | ✅ |
| CompanyGPT / InnFactory | ✅ über Modellmix | ✅/◐ | ◐ | ◐ | ◐ | ✅ | ✅/◐ | ◐ | ✅/◐ |
| Private/on-prem LLM | ✅ | ◐ | ◐ | ◐ | ◐ | ✅ | ✅ | ❌/◐ | ✅/◐ |
11. Datenschutz- und Enterprise-Kontrollmatrix
Legende:
- ✅ = gut dokumentiert / typischer Enterprise-Standard
- ◐ = möglich, aber plan-, regions-, modell- oder vertragsabhängig
- ❌ = nicht geeignet / nicht ersichtlich
- ? = öffentlich nicht ausreichend eindeutig
- ⚠️ = besonderes Risiko / sorgfältige Prüfung notwendig
| Dienst | AVV/DPA | EU-/DE-Region | Retention-Kontrolle | Zero Data Retention | SSO | SCIM | Audit Logs | No Training mit Business-Daten | CLOUD-Act-/Drittlandrisiko | Grundbewertung |
|---|---|---|---|---|---|---|---|---|---|---|
| ChatGPT Consumer | ❌/◐ | ◐ | ◐ | ❌ | ❌ | ❌ | ❌ | ◐ Einstellungen abhängig | ⚠️ hoch | Nicht für Unternehmensdaten freigeben |
| ChatGPT Business | ✅/◐ | ◐ | ◐ | ❌/◐ | ◐ | ◐ | ◐ | ✅ | ⚠️ hoch/mittel | Für K1, teils K2 nach Prüfung |
| ChatGPT Enterprise | ✅ | ✅/◐ | ✅/◐ | ◐ | ✅ | ✅/◐ | ✅/◐ | ✅ | ⚠️ mittel/hoch | Sehr leistungsfähig, für K2 gut prüfbar |
| OpenAI API | ✅ | ✅/◐ | ✅/◐ | ✅ für qualifizierte Endpunkte/Kunden | API/IAM extern | API/IAM extern | ◐ | ✅ | ⚠️ mittel/hoch | Sehr gut für kontrollierte Apps |
| Claude Consumer | ❌/◐ | ? | ◐ | ❌ | ❌ | ❌ | ❌ | ◐ abhängig von Consumer-Einstellungen | ⚠️ hoch | Nicht für vertrauliche Unternehmensdaten |
| Claude Team | ✅/◐ | ? | ◐ | ❌/◐ | ◐ | ◐ | ◐ | ✅/◐ | ⚠️ hoch/mittel | Für K1, K2 nur nach Prüfung |
| Claude Enterprise | ✅ | ?/◐ | ✅/◐ | ◐/✅ je Vertrag | ✅/◐ | ✅/◐ | ✅/◐ | ✅ | ⚠️ mittel/hoch | Fachlich stark, Datenschutz über Vertrag klären |
| Anthropic API | ✅ | ?/◐ | ✅/◐ | ✅ für berechtigte Nutzung | API/IAM extern | API/IAM extern | ◐ | ✅ Commercial Products | ⚠️ mittel/hoch | Gut, oft über Bedrock/Vertex/Azure prüfbarer |
| Google Gemini Consumer | ❌/◐ | ◐ | ◐ | ❌ | ❌ | ❌ | ❌ | ◐ | ⚠️ hoch | Nicht für vertrauliche Unternehmensdaten |
| Google Workspace Gemini | ✅ | ◐ | ◐ | ❌/◐ | ✅ | ✅/◐ | ✅ | ✅/◐ | ⚠️ mittel/hoch | Gut für Google-Workspace-Kunden |
| Google Vertex AI / Gemini API | ✅ | ✅/◐ | ◐ | ◐ | ✅ über Cloud IAM | ✅/◐ | ✅ | ✅/◐ | ⚠️ mittel/hoch | Sauberere Gemini-Variante für Apps |
| T-Systems Sovereign Cloud powered by Google Cloud | ✅ | ✅✅ | ✅/◐ | ◐ | ✅/◐ | ✅/◐ | ✅/◐ | ✅/◐ | ◐ reduziert | Sehr stark für Google/Gemini mit Souveränitätsanforderung |
| Google Distributed Cloud / Air-Gap | ✅ | ✅✅ | ✅/◐ | ◐ | ✅/◐ | ✅/◐ | ✅/◐ | ✅/◐ | ◐ stark reduziert | Für sehr hohe Schutzklassen interessant |
| Microsoft Copilot for M365 | ✅ über Microsoft-Verträge | ✅/◐ | ◐ | ❌/◐ | ✅ | ✅ | ✅ | ✅/◐ | ⚠️ mittel/hoch | Gut bei Microsoft-365-Landschaft |
| Azure OpenAI / Azure AI Foundry | ✅ | ✅/◐ | ◐ | ◐ | ✅ Entra ID | ✅/◐ | ✅ | ✅/◐ | ⚠️ mittel/hoch | Sehr stark für Enterprise-Architekturen |
| AWS Bedrock | ✅ | ✅/◐ je Modell | ✅/◐ | ◐ | ✅ IAM | ✅/◐ | ✅ CloudTrail/CloudWatch | ✅/◐ | ⚠️ mittel/hoch | Starkes Multi-Modell-Gateway |
| xAI Grok on X / X Premium+ | ❌/◐ | ? | ◐ | ❌ | ❌ | ❌ | ❌ | ? | ⚠️ hoch | Nicht für vertrauliche Unternehmensdaten |
| SuperGrok / Grok.com | ❌/◐ | ? | ◐ | ❌/◐ | ❌/◐ | ❌ | ❌/◐ | ? | ⚠️ hoch | Nur K0/K1 mit Vorsicht |
| xAI API | ✅ | ? | ◐ | ✅ Enterprise-Feature | ◐ | ◐ | ?/◐ | ✅/◐ | ⚠️ hoch | Entwicklerisch interessant, Datenschutz intensiv prüfen |
| Grok Business | ✅/◐ | ? | ✅/◐ Custom Retention | ?/◐ | ◐/✅ | ◐/✅ | ✅/◐ | ✅ | ⚠️ hoch | Funktional stark, für K2/K3 vorsichtig |
| Grok Enterprise | ✅ | ? | ✅/◐ | ✅/◐ | ✅ | ✅ | ✅/◐ | ✅ | ⚠️ hoch | In Shortlist aufnehmen, aber nicht erste Wahl für sensible DE-Daten |
| Perplexity Consumer/Pro | ❌/◐ | ? | ◐ | ❌/◐ | ❌ | ❌ | ❌/◐ | ◐ | ⚠️ hoch | Nur öffentliche Recherche |
| Perplexity Enterprise | ✅/◐ | ? | ✅/◐ | ◐/✅ je Vertrag | ✅/◐ | ✅/◐ | ✅/◐ | ✅/◐ | ⚠️ hoch | Gut für Recherche, sensible Daten prüfen |
| IBM watsonx.ai | ✅ | ◐ | ◐ | ◐ | ✅/◐ | ✅/◐ | ✅/◐ | ◐ | ⚠️ mittel/hoch | Stark für Governance/Enterprise |
| Cohere | ✅/◐ | ◐ | ◐ | ◐ | ✅/◐ | ✅/◐ | ✅/◐ | ✅/◐ | ◐/⚠️ | Stark für RAG/Enterprise Search |
| Mistral AI | ✅/◐ | ✅/◐ | ◐ | ◐ | ✅/◐ | ✅/◐ | ◐ | ✅/◐ | ◐ geringer als US-Anbieter | Sehr guter EU-Kandidat |
| Aleph Alpha / PhariaAI | ✅/◐ | ✅/◐ | ◐ | ◐ | ✅/◐ | ✅/◐ | ✅/◐ | ✅/◐ | ◐ niedrig/mittel | Sehr interessant für regulierte/öffentliche Kunden |
| STACKIT AI Model Serving | ✅/◐ | ✅✅ | ✅/◐ | ◐/✅ laut Betriebsmodell prüfen | ✅/◐ | ✅/◐ | ✅/◐ | ✅ | ✅/◐ niedrig | Sehr gute deutsche Option |
| IONOS AI Model Hub | ✅ | ✅/◐ | ◐ | ◐ | ✅/◐ | ✅/◐ | ✅/◐ | ✅/◐ | ✅/◐ niedrig/mittel | Gute deutsche/EU-Cloud-Option |
| Langdock | ✅/◐ | ✅/◐ | ◐ | abhängig vom Modell | ✅/◐ | ✅/◐ | ✅ | abhängig vom Modell | abhängig vom Modell | Sehr gut als kontrollierter KI-Arbeitsplatz |
| CompanyGPT / InnFactory | ✅/◐ | ◐ | ◐ | abhängig vom Modell | ✅/◐ | ✅/◐ | ✅/◐ | abhängig vom Modell | abhängig vom Modell | Als Langdock-Alternative prüfen |
| Private/on-prem LLM | intern | ✅✅ | ✅✅ | ✅✅ | ✅ intern | ✅ intern | ✅ intern | ✅ | ✅ sehr niedrig | Maximal kontrollierbar, aber Betriebsaufwand |
12. Beispiel-Freigabe: Alle genannten Dienste nach Datenklasse
Diese Matrix ist bewusst konservativ formuliert. Sie dient als Startpunkt für die interne Klassifizierung.
Legende:
- ✅ = grundsätzlich freigebbar
- ◐ = nur mit Einschränkungen / nach Prüfung / je Vertrag
- ❌ = nicht freigeben
- ⚠️ = nur mit besonderer DSFA/TIA/Einzelfreigabe
| Dienst | K0 Öffentlich | K1 Intern | K2 Vertraulich | K3 Personenbezogen / hoch vertraulich | K4 Reguliert / streng vertraulich | Kommentar |
|---|---|---|---|---|---|---|
| ChatGPT Consumer Free/Plus/Pro | ✅ | ◐ | ❌ | ❌ | ❌ | Nur für öffentliche oder anonymisierte Inhalte. Keine Kunden-, Projekt-, Personen- oder Geschäftsgeheimnisse. |
| ChatGPT Business | ✅ | ✅ | ◐ | ❌/◐ | ❌ | Für interne Arbeit geeignet; K2 nur mit Unternehmensrichtlinie, DPA/AVV, Retention-Prüfung und Admin-Kontrollen. |
| ChatGPT Enterprise | ✅ | ✅ | ✅/◐ | ◐ | ❌/◐ | Für K2 gut geeignet; K3 nur mit DPA, Retention, ggf. EU Data Residency, TIA, DSFA. |
| OpenAI API | ✅ | ✅ | ✅/◐ | ◐/⚠️ | ❌/◐ | Für eigene Apps gut, wenn ZDR/Retention, EU-Residency und Logging geregelt sind. |
| Claude Consumer Free/Pro/Max | ✅ | ◐ | ❌ | ❌ | ❌ | Keine vertraulichen Unternehmensdaten in Consumer-Claude. |
| Claude Team | ✅ | ✅ | ◐ | ❌/◐ | ❌ | Für K1 gut; K2 nur nach Vertrag/Retention/No-Training-Prüfung. |
| Claude Enterprise | ✅ | ✅ | ✅/◐ | ◐/⚠️ | ❌/◐ | Fachlich sehr stark; K3 nur mit Enterprise-Vertrag, Retention/ZDR, TIA, DSFA. |
| Anthropic API | ✅ | ✅ | ✅/◐ | ◐/⚠️ | ❌/◐ | Für K2 stark; K3 besser mit ZDR oder über Bedrock/Vertex/Azure mit passender Region. |
| Google Gemini Consumer App | ✅ | ◐ | ❌ | ❌ | ❌ | Normale Gemini-App nicht für vertrauliche Unternehmensdaten. |
| Google Workspace Gemini | ✅ | ✅ | ◐/✅ | ◐/⚠️ | ❌/◐ | Gut für Workspace-Kunden; Meeting-/Drive-/Audit-/Retention-Regeln nötig. |
| Google Vertex AI / Gemini API | ✅ | ✅ | ✅ | ◐/✅ | ◐ | Saubere Gemini-Variante für Apps; EU-Region, IAM, Audit Logs, DPA prüfen. |
| T-Systems Sovereign Cloud powered by Google Cloud | ✅ | ✅ | ✅ | ✅/◐ | ✅/◐ | Beste Option, wenn Gemini/Google-Technologie mit Souveränitätsargumentation gewünscht ist. |
| Google Distributed Cloud / Air-Gap | ✅ | ✅ | ✅ | ✅ | ✅/◐ | Für sehr hohe Schutzanforderungen; Umsetzung komplex und vertrags-/projektabhängig. |
| Microsoft Copilot for M365 | ✅ | ✅ | ◐/✅ | ◐/⚠️ | ❌/◐ | Gut in M365-Umgebungen; Graph-Zugriffe, Berechtigungen und Meetingdaten streng regeln. |
| Azure OpenAI / Azure AI Foundry | ✅ | ✅ | ✅ | ◐/✅ | ◐ | Sehr guter Enterprise-Standard; CLOUD-Act/TIA trotzdem beachten. |
| AWS Bedrock | ✅ | ✅ | ✅ | ◐/✅ | ◐ | Sehr stark für Multi-Modell-Architekturen; je Modell und Region prüfen. |
| xAI Grok on X / X Premium+ | ✅ | ◐ | ❌ | ❌ | ❌ | Nur öffentliche Recherche/Ideation. Nicht für Unternehmensgeheimnisse. |
| SuperGrok / Grok.com Individual | ✅ | ◐ | ❌/◐ | ❌ | ❌ | Nur K0/K1 mit Vorsicht; keine K2/K3-Freigabe ohne Enterprise-Vertrag. |
| xAI API | ✅ | ✅/◐ | ◐/⚠️ | ❌/⚠️ | ❌ | DPA/ZDR möglich, aber EU-Region und Drittlandthema intensiv prüfen. |
| Grok Business | ✅ | ✅ | ◐/⚠️ | ❌/⚠️ | ❌ | Funktional stark, aber für deutsche Datenschutzfreigaben vorsichtig einstufen. |
| Grok Enterprise | ✅ | ✅ | ◐/✅ | ◐/⚠️ | ❌/◐ | Mit DPA, SSO/SCIM, Retention, Audit, ZDR ggf. für K2 prüfbar; K3 nur Einzelfreigabe. |
| Perplexity Consumer/Pro | ✅ | ◐ | ❌ | ❌ | ❌ | Für öffentliche Recherche, nicht für vertrauliche Daten. |
| Perplexity Enterprise | ✅ | ✅ | ◐ | ❌/◐ | ❌ | Gut für Recherche; interne vertrauliche Daten nur mit Vertrag, Retention, No-Training, Audit. |
| IBM watsonx.ai | ✅ | ✅ | ✅/◐ | ◐/✅ | ◐ | Für Enterprise Governance interessant; konkrete Cloud-/Hybrid-Architektur prüfen. |
| Cohere | ✅ | ✅ | ✅/◐ | ◐ | ◐ | Besonders für RAG/Enterprise Search; Hosting/Region/Vertrag prüfen. |
| Mistral AI | ✅ | ✅ | ✅/◐ | ◐/✅ | ◐ | EU-Anbieter; guter Kandidat für K2/K3, wenn Modellleistung genügt. |
| Aleph Alpha / PhariaAI | ✅ | ✅ | ✅ | ✅/◐ | ◐/✅ | Sehr interessant für Behörden/regulierte Branchen; Vertrags-/Deploymentmodell prüfen. |
| STACKIT AI Model Serving | ✅ | ✅ | ✅ | ✅/◐ | ◐/✅ | Deutsche Cloud, gute Option für datensensible API-Workflows. |
| IONOS AI Model Hub | ✅ | ✅ | ✅ | ✅/◐ | ◐ | Gute deutsche/EU-Option für RAG, Chatbots und Open-Source-Modelle. |
| Langdock | ✅ | ✅ | ✅/◐ | ◐/✅ | ◐ | Sehr gut als kontrollierte Unternehmens-KI, aber Klassifizierung hängt vom gewählten Modellrouting ab. |
| CompanyGPT / InnFactory | ✅ | ✅ | ✅/◐ | ◐ | ◐ | Als deutscher KI-Workspace prüfen; Modellrouting entscheidet. |
| Private/on-prem LLM | ✅ | ✅ | ✅ | ✅ | ✅ | Beste Kontrolle; dafür Betriebs-, Sicherheits- und Modellqualitätsaufwand. |
13. Anbieterstrategie nach Datenschutzanforderung
Anbieterstrategie nach Datenklasse als strukturierte Liste:
- K0 Öffentlich: Consumer KI möglich, Business KI möglich
- K1 Intern (Business KI):
- ChatGPT Business
- Claude Team
- Workspace Gemini
- Copilot M365
- Langdock
- K2 Vertraulich (Enterprise/API):
- ChatGPT Enterprise / OpenAI API
- Claude Enterprise / Anthropic API
- Azure OpenAI
- AWS Bedrock
- Vertex AI
- Mistral / Cohere / IBM
- K3 Personenbezogen / hoch vertraulich (EU/Sovereign/Private bevorzugt):
- T-Systems Sovereign Cloud
- STACKIT
- IONOS AI Model Hub
- Aleph Alpha / PhariaAI
- Private LLM
- K4 Reguliert / streng vertraulich (On-Prem / Air-Gap / Sovereign):
- Private/on-prem LLM
- Google Distributed Cloud Air-Gap
- T-Systems Sovereign
14. Sortierung nach Datenschutz- und Souveränitätsniveau
14.1 Höchste Datenschutz-/Souveränitätsstufe
| Rang | Dienst | Warum |
|---|---|---|
| 1 | Private/on-prem LLM | maximale Kontrolle über Daten, Logs, Netzwerk, Schlüssel |
| 2 | Google Distributed Cloud / Air-Gap | stark isolierbares Betriebsmodell |
| 3 | T-Systems Sovereign Cloud powered by Google Cloud | Google/Gemini-Fähigkeiten mit deutscher Souveränitätsargumentation |
| 4 | STACKIT AI Model Serving | deutsche Cloud, starkes Datensouveränitätsargument |
| 5 | IONOS AI Model Hub | deutsche/EU-Cloud, RAG/Model-Hub-Funktionalität |
| 6 | Aleph Alpha / PhariaAI | starker Fokus auf souveräne/regulierte KI |
| 7 | Mistral AI Enterprise/private Deployment | EU-Anbieter, gute Option bei passender Modellleistung |
14.2 Beste Enterprise-Cloud-Optionen
| Rang | Dienst | Warum |
|---|---|---|
| 1 | Azure OpenAI / Azure AI Foundry | stark bei Enterprise-IAM, Logging, Region, Microsoft-Integration |
| 2 | AWS Bedrock | Multi-Modell-Gateway, IAM, KMS, CloudTrail/CloudWatch |
| 3 | Google Vertex AI / Gemini API | sauberere Gemini-Variante für eigene Apps |
| 4 | OpenAI API / ChatGPT Enterprise | starke Modell-/UX-Breite, Enterprise-Kontrollen |
| 5 | Claude Enterprise/API | sehr stark für Dokumente, Analyse, Coding |
| 6 | IBM watsonx.ai | stark bei Governance und Enterprise-Prozessen |
| 7 | Cohere | gut für RAG und Enterprise Search |
14.3 Beste Mitarbeitenden-KI-Plattformen
| Rang | Dienst | Warum |
|---|---|---|
| 1 | Langdock | kontrollierter KI-Arbeitsplatz, Modellrouting, Governance |
| 2 | ChatGPT Enterprise | starke UX, breite Fähigkeiten, Enterprise-Kontrollen |
| 3 | Google Workspace Gemini | ideal bei Google Workspace |
| 4 | Microsoft Copilot for M365 | ideal bei Microsoft 365 |
| 5 | Claude Enterprise | stark für Wissensarbeit und Coding |
| 6 | CompanyGPT / InnFactory | deutscher KI-Workspace, Alternative zu Langdock |
| 7 | Grok Enterprise | funktional spannend, aber Datenschutzprüfung intensiver |
15. Anbieterprofile
15.1 OpenAI / ChatGPT / OpenAI API
Stärken
- sehr starke LLMs
- Vision
- Audio
- Bildgenerierung
- Coding
- Assistants/Agents
- Enterprise UX
- API-Ökosystem
Datenschutzrelevanz
- Business-/Enterprise-Daten laut Anbieter nicht fürs Training
- Enterprise Privacy
- Data Residency für berechtigte Kunden
- Retention-Kontrollen
- Zero Data Retention für qualifizierte API-Use-Cases
- SSO/Audit/Admin-Funktionen je Plan
Empfehlung
- Consumer: nur K0/K1 mit Vorsicht
- Business: K1, K2 eingeschränkt
- Enterprise/API: K2 gut, K3 nur mit Prüfung
- K4 eher nicht erste Wahl, außer Sonderarchitektur/ZDR/private Schutzmaßnahmen
15.2 Anthropic / Claude
Stärken
- sehr stark bei langen Texten
- Analyse
- Coding
- Agentic Workflows
- Dokumentenverständnis
- gute Modellqualität
Datenschutzrelevanz
- Commercial Products mit No-Training-Zusage
- API-Retention kontrollierbar
- Zero Data Retention für berechtigte API-/Enterprise-Fälle
- Enterprise-Vertrag für sensible Nutzung erforderlich
- EU-/Regionenlage je Zugangsweg prüfen
Empfehlung
- Consumer: nicht für vertrauliche Daten
- Team: K1, K2 nur mit Prüfung
- Enterprise/API: K2 stark, K3 nur mit DPA, Retention/ZDR, TIA, DSFA
- Für europäische Kunden oft besser über AWS Bedrock, Google Vertex oder Azure prüfen, wenn dort Region/Governance besser passt
15.3 Google Gemini Consumer
Stärken
- starke Multimodalität
- Web-/Google-Nähe
- gute Consumer-UX
Datenschutzrelevanz
- Consumer-Kontext
- Activity-/Review-/Retention-Themen
- keine geeignete Standardfreigabe für vertrauliche Unternehmensdaten
Empfehlung
- Nur K0
- K1 nur mit großer Vorsicht
- K2-K4 nicht freigeben
15.4 Google Workspace Gemini
Stärken
- Integration in Gmail, Docs, Sheets, Slides, Meet, Drive
- Meeting-Zusammenfassungen
- interne Wissensarbeit
- gute Nutzerakzeptanz bei Google-Workspace-Kunden
Datenschutzrelevanz
- Unternehmensvertrag
- Admin-Kontrollen
- Audit Logs
- Workspace-DPA
- No-Training-/Privacy-Zusagen für Workspace-Kontext
- Drive-/Meet-/Berechtigungskonzepte kritisch
Empfehlung
- K1 gut
- K2 je nach Policy möglich
- K3 nur mit strengen Meeting-/Retention-/Berechtigungsregeln
- K4 nicht erste Wahl
15.5 Google Vertex AI / Gemini API
Stärken
- Gemini über API
- Vision
- Embeddings
- RAG
- Agenten
- Cloud IAM
- Audit Logs
- Data Residency je Service/Region
- Zero-Data-Retention-Optionen durch konkrete Konfigurationen möglich
Datenschutzrelevanz
- deutlich besser kontrollierbar als Consumer-Gemini
- DPA und Cloud-Verträge
- Region und Modellverfügbarkeit prüfen
- Drittlandtransfer/CLOUD-Act-Thema bleibt bei Google grundsätzlich relevant
Empfehlung
- K2 gut
- K3 mit EU-Region, DSFA, Retention, IAM, Audit, TIA
- K4 eher T-Systems/Distributed Cloud/private Variante prüfen
15.6 T-Systems Sovereign Cloud powered by Google Cloud
Stärken
- Google-Cloud-Technologie
- Souveränitätsargumentation
- deutsche Betriebs-/Kontrollkomponenten
- relevant für Unternehmen, die Gemini/Google-Technologie nutzen wollen, aber Standard-Google kritisch bewerten
Datenschutzrelevanz
- stärkere Datenresidenz- und Souveränitätskontrollen
- geeignet für höhere Schutzklassen
- konkrete Service- und Modellverfügbarkeit prüfen
- Vertrag und TOMs entscheidend
Empfehlung
- Sehr guter Kandidat für K2/K3
- Für K4 je nach Variante, ggf. Google Distributed Cloud / Air-Gap prüfen
15.7 Microsoft Copilot for M365
Stärken
- tiefe Microsoft-365-Integration
- Word, Excel, PowerPoint, Teams, Outlook
- Graph-basierte Unternehmenskontexte
- gute Nutzerakzeptanz in Microsoft-Umgebungen
Datenschutzrelevanz
- Microsoft-Verträge
- Entra ID
- Purview, Compliance, Audit je Lizenz
- kritischer Punkt: Berechtigungen im M365 Graph
- Copilot kann nur so sicher sein wie die SharePoint-/Teams-/OneDrive-Berechtigungen
Empfehlung
- K1 gut
- K2 möglich, wenn Berechtigungen sauber sind
- K3 nur mit strenger Governance
- K4 nicht erste Wahl
15.8 Azure OpenAI / Azure AI Foundry
Stärken
- OpenAI-Modelle über Azure
- Entra ID
- Azure-Regionen
- Monitoring
- Private Networking
- KMS/Key-Management-Optionen je Architektur
- gut für Enterprise-Apps
Datenschutzrelevanz
- DPA/AVV über Microsoft
- US-Hyperscaler: CLOUD-Act/TIA beachten
- Region, Logging, Abuse Monitoring, Retention prüfen
Empfehlung
- K2 sehr gut
- K3 gut prüfbar
- K4 nur mit sehr strenger Architektur oder souveräner Alternative
15.9 AWS Bedrock
Stärken
- Multi-Modell-Gateway
- Claude, Llama, Mistral, Cohere, Amazon Nova etc.
- IAM, KMS, CloudTrail, CloudWatch
- RAG/Knowledge Bases
- gute Enterprise-Architektur
Datenschutzrelevanz
- DPA/AVV über AWS
- nach Anbieterangaben werden Kundeneingaben nicht zur Verbesserung der Basismodelle genutzt und nicht mit Modellanbietern geteilt
- Region und Modellverfügbarkeit prüfen
- US-Hyperscaler: CLOUD-Act/TIA beachten
Empfehlung
- K2 sehr gut
- K3 gut prüfbar
- K4 nur mit Spezialarchitektur/private/souveräne Alternative
15.10 xAI / Grok / X.com
Varianten
- Grok auf X / X Premium+
- SuperGrok / Grok.com individual
- xAI API
- Grok Business
- Grok Enterprise
Stärken
- LLM
- Vision
- Voice
- Bild
- Video
- sehr starke Realtime-/X-/Web-Nähe
- Business/Enterprise mit SSO/SCIM/Retention/Audit-Claims
Datenschutzrelevanz
- Consumer-X/Grok nicht für vertrauliche Unternehmensdaten
- xAI DPA vorhanden
- Grok Business/Enterprise nennt No Training, Custom Retention, SSO/SCIM und Advanced Audit/Security Controls
- EU-/DE-Region öffentlich nicht ausreichend klar
- US-Anbieter
- X/Grok-Regulierungsvorgeschichte in der EU beachten
Empfehlung
- Grok auf X: nur K0
- SuperGrok: K0/K1 mit Vorsicht
- Grok Business: K1, K2 nur mit Prüfung
- Grok Enterprise/API: K2 prüfbar, K3 nur mit Einzelfreigabe, K4 eher nicht
15.11 Perplexity
Stärken
- Recherche
- Websuche
- Quellenarbeit
- schnelle Informationsbeschaffung
- Enterprise Search je Plan
Datenschutzrelevanz
- Consumer/Pro nicht für vertrauliche Daten
- Enterprise mit Retention-/Audit-/No-Training-Regelungen je Vertrag prüfen
- US-Anbieter
- Quellen-/Halluzinationsrisiko beachten
Empfehlung
- K0 sehr gut
- K1 möglich
- K2 nur Enterprise und mit klarer Regel
- K3/K4 nicht erste Wahl
15.12 IBM watsonx.ai
Stärken
- Enterprise AI
- Governance
- Modellverwaltung
- Hybrid-/Enterprise-Ansatz
- watsonx.governance
Datenschutzrelevanz
- gute Enterprise-/Governance-Story
- IBM-Verträge, DPA, Security Policies
- Hosting- und Betriebsmodell prüfen
- US-Anbieter, aber stark auf Enterprise ausgerichtet
Empfehlung
- K2 gut
- K3 prüfbar
- K4 je nach Hybrid-/Private-Setup
15.13 Cohere
Stärken
- Enterprise LLM
- RAG
- Embeddings
- semantische Suche
- private Deployments möglich
- nach Aleph-Alpha-Bezug strategisch für Europa interessant
Datenschutzrelevanz
- DPA/Enterprise-Verträge prüfen
- Hosting und Deployment entscheidend
- Drittlandtransfer je Setup
Empfehlung
- K2 gut
- K3 prüfbar
- K4 nur bei privatem/souveränem Deployment
15.14 Mistral AI
Stärken
- EU-Anbieter
- gute offene und kommerzielle Modelle
- LLM
- Vision je Modell
- Embeddings
- Agents/API
- Enterprise/private Deployments möglich
Datenschutzrelevanz
- EU-Herkunft ist starkes Argument
- DPA vorhanden
- konkrete Hosting-/Subprozessoren trotzdem prüfen
- Modellleistung pro Use Case testen
Empfehlung
- K2 gut
- K3 gut prüfbar
- K4 nur bei privatem/souveränem Deployment
15.15 Aleph Alpha / PhariaAI / Cohere-Aleph Alpha
Stärken
- deutsche/europäische Souveränitätspositionierung
- Behörden-/Regulierungsnähe
- erklärbare KI
- Enterprise-Governance
- potenziell private/souveräne Deployments
Datenschutzrelevanz
- sehr interessant für öffentliche Hand und regulierte Branchen
- nach Unternehmens-/Produktentwicklung aktuellen Vertragsstand prüfen
- Deploymentmodell entscheidet
Empfehlung
- K2 sehr gut
- K3 gut
- K4 je nach privatem/souveränem Setup
15.16 STACKIT AI Model Serving
Stärken
- deutsche Cloud
- API Model Serving
- Open-Source-/EU-Modelle
- Datensouveränitätsargument
- geeignet für eigene Apps und RAG
- OpenAI-kompatible API möglich
Datenschutzrelevanz
- deutsche/europäische Betriebsumgebung
- keine Speicherung/Training laut Anbieterangaben prüfen und vertraglich absichern
- Speicherung/Retention konkret prüfen
- Modellverfügbarkeit und Leistungsniveau testen
- trotz deutscher Anbieterstruktur Subprozessoren und technische Lieferkette prüfen
Empfehlung
- K2 sehr gut
- K3 gut
- K4 je nach Architektur möglich
15.17 IONOS AI Model Hub
Stärken
- deutscher/europäischer Cloudanbieter
- Model Hub
- RAG
- Vektordatenbanken
- Open-Source-Modelle
- gutes KMU-Argument
Datenschutzrelevanz
- DPA/AVV und Cloud-Verträge prüfen
- EU-/DE-Hosting je Dienst
- Modell- und Subprozessorenkette prüfen
Empfehlung
- K2 gut
- K3 gut prüfbar
- K4 nur mit strenger Architektur
15.18 Langdock
Stärken
- deutscher KI-Arbeitsplatz
- Modellgateway
- Governance
- SSO/Audit/Policy-Funktionen
- RAG/Wissensbasis
- kann OpenAI, Anthropic, Gemini, Mistral etc. je Konfiguration bündeln
Datenschutzrelevanz
- sehr gut zur Vermeidung von KI-Wildwuchs
- Datenschutz hängt stark vom gewählten Modellrouting ab
- EU-only Optionen wichtig
- AVV, Subprozessoren, Retention, Audit und Modellkette prüfen
- Kostenstruktur, Tokenweitergabe und Mandantenmodell im konkreten Angebot prüfen
Empfehlung
- K1 sehr gut
- K2 gut
- K3 je nach Modellrouting/Setup möglich
- K4 eher nur mit sehr restriktivem Setup
15.19 CompanyGPT / InnFactory
Stärken
- deutscher KI-Workspace
- Modellmix
- Unternehmens-KI
- RAG/Knowledge-Funktionen
Datenschutzrelevanz
- als Langdock-Alternative interessant
- Modellrouting entscheidet
- Vertrag, AVV, Retention, Unterauftragnehmer prüfen
Empfehlung
- K1 gut
- K2 prüfbar
- K3 nur bei strengem Setup
- K4 eher nicht erste Wahl
15.20 Private/on-prem LLM
Stärken
- volle Kontrolle
- keine externe Datenübertragung
- eigene Logs
- eigene Schlüssel
- eigene Netzwerkgrenzen
- ideal für stark vertrauliche Daten
Schwächen
- Betriebskosten
- GPU-Infrastruktur
- MLOps
- Security-Verantwortung
- Modellqualität nicht immer auf GPT/Claude/Gemini-Niveau
- Wartung und Updates
- interne Haftung für Betrieb und Security
Empfehlung
- beste Option für K4
- sinnvoll für sensible RAG-Systeme
- häufig Hybridstrategie: on-prem für sensible Daten, Enterprise-Cloud für allgemeine Produktivität
16. Wirtschaftliche Betrachtung: Cloud, Sovereign Cloud, On-Prem
16.1 Keine pauschale Aussage möglich
Eine seriöse TCO-Rechnung muss berücksichtigen:
| Kostenfaktor | Cloud/API | On-Prem/Private |
|---|---|---|
| Upfront-Kosten | niedrig | hoch |
| Tokenkosten | variabel | indirekt über Hardware/Strom/Betrieb |
| GPU-Auslastung | Anbieterproblem | eigenes Risiko |
| Wartung | Anbieter | intern/Partner |
| Modellupdates | Anbieter | intern/Partner |
| Security | geteilt | weitgehend eigene Verantwortung |
| Datenschutzkontrolle | vertrags-/anbieterabhängig | maximal kontrollierbar |
| Skalierung | einfach | hardwarebegrenzt |
| Ausfallsicherheit | Anbieter/SLA | selbst planen |
| Modellqualität | oft Frontier | meist kleinere/offene Modelle |
| Compliance-Dokumentation | Anbieterunterlagen verfügbar | intern aufzubauen |
| Time-to-Market | schnell | langsamer |
| Vendor Lock-in | je Anbieter | je Architektur geringer oder höher |
16.2 Sinnvolle Hybridstrategie
Für viele Unternehmen ist keine reine Strategie optimal. Empfehlenswert ist häufig ein hybrides Modell:
Hybridstrategie als strukturierte Liste:
- Öffentliche / einfache Aufgaben: Business SaaS / ChatGPT / Gemini / Claude
- Interne Wissensarbeit: Langdock / Copilot / Workspace Gemini
- Vertrauliche Projektarbeit: Enterprise API / Azure OpenAI / Bedrock / Vertex / Mistral — flankiert durch Audit, SSO, Retention, DPA
- Hochsensible Daten: STACKIT / IONOS / T-Systems / Private LLM — mit Sovereign-/On-Prem-Setup und eigenen Schlüsseln
17. Meeting-Transkription, Protokolle und § 201 StGB
17.1 Warum das kritisch ist
KI-Mitschriften verarbeiten regelmäßig:
- Namen
- Stimmen
- Meinungen
- Leistungs-/Arbeitsverhalten
- Kundendaten
- Projektinformationen
- personenbezogene Aussagen
- möglicherweise sensible Daten
Deshalb sind Meeting-Transkripte mindestens K2, oft K3.
17.2 § 201 StGB
In Deutschland schützt § 201 StGB die Vertraulichkeit des nichtöffentlich gesprochenen Wortes.
Für Unternehmen bedeutet das:
- Nichtöffentliche Gespräche dürfen nicht einfach aufgezeichnet werden.
- Ein KI-Bot im Meeting ist keine automatische Rechtsgrundlage.
- Ein Hinweis in der Einladung kann hilfreich sein, ersetzt aber nicht immer eine wirksame Einwilligung.
- Bei externen Gesprächen sollte eine ausdrückliche Zustimmung eingeholt werden.
- Bei Beschäftigten muss Freiwilligkeit besonders sorgfältig betrachtet werden.
- Falls ein Betriebsrat existiert, ist Mitbestimmung sehr wahrscheinlich relevant.
17.3 Empfohlene Regel für Meeting-Mitschnitte
KI-Mitschriften sind nur zulässig, wenn alle Teilnehmenden vorab transparent informiert wurden, der Zweck klar ist, keine sensiblen Sonderkategorien oder hochvertraulichen Inhalte verarbeitet werden und Audio/Rohtranskript nach definierter Frist gelöscht werden. Bei externen oder sensiblen Meetings sollte eine ausdrückliche Zustimmung eingeholt werden.
17.4 Speaker Diarization
Speaker Diarization kann kritisch sein, wenn Sprecher technisch identifiziert oder wiedererkannt werden.
Empfehlung:
| Funktion | Empfehlung |
|---|---|
| reine Zusammenfassung ohne Sprecherzuordnung | bevorzugt |
| Sprecher A / Sprecher B ohne Identifikation | ggf. vertretbar |
| automatische Namenszuordnung | nur mit Freigabe |
| Stimmprofil / Wiedererkennung | sehr kritisch, DSFA prüfen |
| Emotionserkennung | vermeiden / AI-Act- und arbeitsrechtlich hochkritisch |
17.5 Beispieltext für Meeting-Einladung
Hinweis: Dieses Meeting kann mit einem freigegebenen KI-Tool transkribiert und zusammengefasst werden. Zweck ist ausschließlich die Erstellung eines Protokolls und die Nachverfolgung von Aufgaben. Die Aufzeichnung bzw. das Rohtranskript wird nur berechtigten Personen zugänglich gemacht und gemäß interner Löschfrist gelöscht. Wenn Sie damit nicht einverstanden sind, geben Sie bitte vor Beginn des Meetings Bescheid; dann wird eine manuelle Mitschrift verwendet.
Für sensible Meetings besser:
Für dieses Meeting wird keine KI-Mitschrift verwendet. Es wird nur eine manuelle Ergebnisnotiz erstellt.
18. Betriebsrat und Mitbestimmung
Wenn ein Betriebsrat existiert, sollte dieser frühzeitig eingebunden werden.
Relevante Punkte:
| Thema | Bewertung |
|---|---|
| Einführung einer zentralen KI-Plattform | wahrscheinlich mitbestimmungsrelevant, wenn Nutzungsdaten/Logs entstehen |
| Prompt-/Nutzungslogs | können Verhalten/Leistung messbar machen |
| AI Monitoring | sehr kritisch |
| Meetingtranskription | mitbestimmungs- und datenschutzrelevant |
| HR-/Recruiting-KI | besonders kritisch |
| Emotionserkennung | vermeiden |
| Leistungsbewertung mit KI | vermeiden oder nur nach gesonderter Prüfung |
Empfehlung:
Frühzeitig Arbeitnehmervertretung einbinden und eine Rahmenregelung für KI-Nutzung, Monitoring-Ausschlüsse, Protokollierung, Transparenz und Zweckbindung schaffen.
19. Urheberrecht und KI-generierte Arbeitsergebnisse
Für viele Unternehmen ist Urheberrecht besonders relevant, etwa bei:
- Design
- Architektur
- Software
- Marketing
- Produktentwicklung
- Forschung
- Dokumentation
- Konzepten
- Präsentationen
- Bild- und Videomaterial
19.1 Problem
KI kann Entwürfe, Varianten, Texte, Visualisierungen, Code, Layouts oder Konzepte erzeugen. Nicht alles ist automatisch urheberrechtlich geschützt.
19.2 Empfehlung
Für schutzfähige Ergebnisse sollte der menschliche Beitrag dokumentiert werden:
| Dokumentation | Zweck |
|---|---|
| ursprüngliche Skizzen / Ideen | menschlicher Ausgangspunkt |
| Variantenentscheidungen | kreative Auswahl |
| Prompt- und Änderungsverlauf | Steuerungsleistung |
| manuelle Überarbeitung | schöpferischer Beitrag |
| fachliche Freigabe | Verantwortung |
| finale Version | dokumentiertes Arbeitsergebnis |
| Versionshistorie | Nachweis der menschlichen Bearbeitung |
| Quellen und Referenzen | Risikoreduktion bei fremden Rechten |
Formulierung:
KI sollte als Assistenzsystem verstanden werden. Der kreative und fachliche menschliche Beitrag muss dokumentiert werden, insbesondere bei Entwürfen, Software, Designs, Konzepten und urheberrechtlich relevanten Ergebnissen.
20. Shadow AI und technische Governance
20.1 Problem
Shadow AI entsteht, wenn Mitarbeitende private oder nicht freigegebene KI-Tools nutzen.
Risiken:
- Abfluss von Kundendaten
- Abfluss von Geschäftsgeheimnissen
- unkontrollierte personenbezogene Verarbeitung
- fehlende Löschung
- fehlende AVV/DPA
- keine Auditierbarkeit
- Training mit Unternehmensdaten
- Urheberrechts- und Haftungsrisiken
- fehlende Kontrolle über Browser-Extensions
- Prompt-Injection-Risiken
- nicht dokumentierte KI-Entscheidungen
20.2 Technisches Schichtenmodell
Technisches Schichtenmodell als strukturierte Liste:
- Policy Layer
- Tool-Freigabeliste
- Datenklassen K0–K4
- Nutzungsrichtlinie
- Identity Layer
- SSO
- SCIM
- Rollen / RBAC
- Gateway Layer
- KI-Gateway
- Modellrouting
- Prompt-Filter
- Data Protection Layer
- DLP
- PII-Redaktion
- Secret Scanning
- Monitoring Layer
- Audit Logs
- SIEM
- Anomalieerkennung
- Agent Governance Layer
- MCP-/Tool-Berechtigungen
- Least Privilege
- Human Approval Gates
20.3 Toxic Combinations / Agentenrisiko
Ein neues Risiko entsteht durch Kombination mehrerer eigentlich harmloser Werkzeuge.
Beispiel:
- KI-Agent liest Slack, Teams, E-Mail oder interne Dokumente.
- In einem Dokument oder einer Nachricht steht eine indirekte Prompt Injection.
- Agent hat zusätzlich Zugriff auf GitHub, SharePoint, CRM, ERP oder Projektordner.
- Agent führt eine ungewollte Aktion aus oder gibt Daten preis.
Empfehlung:
| Maßnahme | Zweck |
|---|---|
| Least Privilege | Agent darf nur, was nötig ist |
| getrennte Tool-Kontexte | Chat ≠ Code ≠ CRM ≠ Dateisystem |
| Human Approval Gates | keine kritischen Aktionen ohne Freigabe |
| Prompt-Injection-Filter | Schutz vor manipulierten Dokumenten |
| Audit Logs | Nachvollziehbarkeit |
| Secrets nie in Agentenkontext | Schadensbegrenzung |
| read-only by default | Agenten nicht sofort schreiben lassen |
| Sitzungsbasierte Freigaben | keine dauerhaften Vollzugriffe |
| Risiko-Scoring für Tools | sensible Tools höher absichern |
21. Interne KI-Nutzungsrichtlinie
21.1 Kurzregel
Keine personenbezogenen, vertraulichen, kundenspezifischen, rechtlichen, steuerlichen, HR-, Gesundheits-, Vertrags-, Sicherheits-, Quellcode- oder Zugangsdaten in nicht freigegebene KI-Systeme eingeben.
21.2 Erlaubt / nur mit Freigabe / verboten
| Erlaubt in freigegebenen Tools | Nur mit Freigabe | Verboten in Consumer-KI |
|---|---|---|
| öffentliche Texte verbessern | Kundendokumente | personenbezogene Daten |
| allgemeine Ideen sammeln | interner Code | Passwörter |
| öffentliche Recherche | Angebote | API Keys |
| nichtvertrauliche Übersetzungen | Verträge | Secrets / Tokens |
| generische Codebeispiele | Meetingtranskripte | Gesundheitsdaten |
| Zusammenfassungen öffentlicher Inhalte | interne Strategien | HR-Daten |
| Präsentationsentwürfe ohne vertrauliche Daten | RAG über interne Ablagen | Rechts-/Steuerakten |
| Layoutideen ohne Kundendaten | Kundendaten | private Informationen |
| allgemeine Normenrecherche | Kalkulationen | Mitarbeiterbewertungen |
| öffentliche Referenzprojekte | Projektunterlagen | Sicherheitskonzepte |
22. Mindestanforderungen an freigegebene KI-Systeme
Für K2 und höher sollten mindestens diese Anforderungen gelten:
| Anforderung | K2 | K3 | K4 |
|---|---|---|---|
| AVV/DPA | Pflicht | Pflicht | Pflicht |
| No Training mit Kundendaten | Pflicht | Pflicht | Pflicht |
| EU-/DE-Region | stark empfohlen | Pflicht/nahe Pflicht | Pflicht oder Sovereign/On-Prem |
| Retention-Kontrolle | Pflicht | Pflicht | strikte Kontrolle |
| Zero Data Retention | empfohlen | stark empfohlen | Pflicht/nahe Pflicht |
| SSO | Pflicht | Pflicht | Pflicht |
| SCIM/Offboarding | empfohlen | Pflicht | Pflicht |
| Audit Logs | Pflicht | Pflicht | Pflicht |
| Rollen/Rechte | Pflicht | Pflicht | Pflicht |
| DLP/Secret Scanning | empfohlen | Pflicht | Pflicht |
| TIA bei Drittlandbezug | Pflicht | Pflicht | Pflicht |
| DSFA/DPIA | prüfen | häufig Pflicht | Pflicht |
| menschliche Aufsicht | Use-Case-abhängig | Pflicht bei riskanten Use Cases | Pflicht |
| interne Nutzungsrichtlinie | Pflicht | Pflicht | Pflicht |
| AI-Act-Use-Case-Register | empfohlen | Pflicht/empfohlen | Pflicht |
23. EU AI Act: praktische Einordnung für Unternehmen
23.1 Normaler KI-Assistent
Beispiele:
- Textentwurf
- Brainstorming
- Zusammenfassung
- Übersetzung
- interne Recherche
Bewertung:
- meist kein Hochrisiko
- trotzdem Transparenz, AI Literacy, Governance und Datenschutz beachten
23.2 KI mit Kundendaten
Beispiele:
- Kundendokumente analysieren
- Angebote erstellen
- Projektdokumentation zusammenfassen
- Supportantworten vorbereiten
- Protokolle strukturieren
Bewertung:
- DSGVO und Geschäftsgeheimnisse relevant
- AI Act abhängig vom konkreten Zweck
- menschliche Kontrolle erforderlich
23.3 KI in HR / Recruiting / Mitarbeiterbewertung
Bewertung:
- besonders kritisch
- potenziell Hochrisiko
- DSFA wahrscheinlich
- Betriebsrat/Arbeitsrecht prüfen
- menschliche Aufsicht
- Dokumentationspflichten
Empfehlung:
Nicht als erster Pilot. Nur mit gesonderter rechtlicher, datenschutzrechtlicher und arbeitsrechtlicher Prüfung.
23.4 KI in Gesundheit / Pflege / Medizin
Bewertung:
- besondere Kategorien personenbezogener Daten
- hoher Schutzbedarf
- mögliche Medizinprodukte-/AI-Act-Relevanz
- DSFA sehr wahrscheinlich
Empfehlung:
Nur mit streng kontrollierter Infrastruktur, spezialisierter Rechtsprüfung und klarer menschlicher Verantwortung.
23.5 KI für Entscheidungen mit erheblicher Wirkung
Beispiele:
- Kreditentscheidung
- Kündigungsvorbereitung
- Bewerberranking
- Leistungsbewertung
- Versicherungs-/Risikobewertung
Bewertung:
- sehr kritisch
- AI Act und DSGVO relevant
- Transparenz, Dokumentation, menschliche Aufsicht
Empfehlung:
KI nur unterstützend, nicht autonom entscheidend einsetzen.
24. Empfohlene Shortlists nach Szenario
24.1 Maximale Modellleistung
| Priorität | Anbieter |
|---|---|
| 1 | OpenAI Enterprise/API |
| 2 | Claude Enterprise/API |
| 3 | Google Vertex AI / Gemini API |
| 4 | Azure OpenAI |
| 5 | AWS Bedrock |
Zusatz:
Bei US-Anbietern immer CLOUD-Act/TIA/Region/Retention prüfen.
24.2 Gemini gewünscht, aber nicht normale Google-Gemini-Consumer-Dienste
| Priorität | Anbieter |
|---|---|
| 1 | Google Vertex AI / Gemini API mit EU-Region |
| 2 | Google Workspace Gemini Enterprise |
| 3 | T-Systems Sovereign Cloud powered by Google Cloud |
| 4 | Google Distributed Cloud / Air-Gap bei sehr hohem Schutzbedarf |
Formulierung:
Wenn Gemini fachlich gewünscht ist, sollte nicht die normale Gemini-App betrachtet werden, sondern Workspace Enterprise, Vertex AI oder eine souveräne Google-Cloud-Variante.
24.3 Deutsche/europäische Souveränität
| Priorität | Anbieter |
|---|---|
| 1 | T-Systems Sovereign Cloud powered by Google Cloud |
| 2 | STACKIT AI Model Serving |
| 3 | IONOS AI Model Hub |
| 4 | Aleph Alpha / PhariaAI |
| 5 | Mistral AI |
| 6 | Private/on-prem LLM |
24.4 Mitarbeitende schnell produktiv machen
| Priorität | Anbieter |
|---|---|
| 1 | Langdock |
| 2 | ChatGPT Enterprise |
| 3 | Google Workspace Gemini |
| 4 | Microsoft Copilot for M365 |
| 5 | Claude Enterprise |
| 6 | CompanyGPT / InnFactory |
24.5 Grok/xAI als Option
Empfohlene Einordnung:
Grok Business/Enterprise sollte in eine Anbieter-Matrix aufgenommen werden, weil es funktional stark ist: Realtime Search, Voice, Image, Video und LLM. Für europäische Unternehmen sollte es aber aktuell vorsichtiger eingestuft werden als Azure OpenAI, AWS Bedrock, Vertex AI, T-Systems, STACKIT oder IONOS, weil xAI ein US-Anbieter ist, die EU-/DE-Region öffentlich nicht ausreichend klar ist und X/Grok regulatorisch im Fokus stand. Für öffentliche Recherche ist Grok sehr interessant. Für vertrauliche Daten nur mit Grok Enterprise/API, DPA, ZDR, Retention, SSO/SCIM, Audit Logs und Transferprüfung.
25. Roadmap für Unternehmen
Phase 1: Inventory & Discovery
Zeitraum: sofort
Ziel:
- alle genutzten KI-Tools erfassen
- Shadow AI identifizieren
- private Accounts erkennen
- Browser-Extensions prüfen
- SaaS-Tools mit KI-Funktionen erfassen
- Meetingbots identifizieren
- M365/Google/Slack/Notion/Asana/CRM-KI-Funktionen prüfen
Ergebnis:
| Ergebnis | Inhalt |
|---|---|
| KI-Tool-Inventar | alle offiziellen und inoffiziellen KI-Tools |
| Datenflussübersicht | wohin gehen Daten? |
| Risikoeinstufung | K0-K4 und AI-Act-Risiko |
| Sofortmaßnahmen | Tools sperren, freigeben oder ersetzen |
Phase 2: Risk Classification
Ziel:
- Use Cases bewerten
- Datenklassen zuordnen
- AI-Act-Risiko prüfen
- DSFA-Bedarf erkennen
- Betriebsratsthemen identifizieren
Ergebnis:
| Ergebnis | Inhalt |
|---|---|
| Use-Case-Register | alle KI-Anwendungsfälle |
| Datenklassenmatrix | K0-K4 je Use Case |
| AI-Act-Vorprüfung | verboten / gering / begrenzt / hoch |
| DSFA-Liste | Fälle mit hohem Datenschutzrisiko |
| Betriebsratsthemen | mitbestimmungspflichtige Systeme |
Phase 3: Governance Implementation
Ziel:
- KI-Richtlinie einführen
- Tool-Freigabeliste erstellen
- Schulung durchführen
- SSO/SCIM aktivieren
- Audit Logging einführen
- Meetingregeln etablieren
Ergebnis:
| Ergebnis | Inhalt |
|---|---|
| KI-Nutzungsrichtlinie | kurz, verständlich, verbindlich |
| Tool-Freigabeliste | erlaubt / eingeschränkt / verboten |
| Schulungsnachweis | AI Literacy |
| Meeting-Mitschrift-Regel | Zustimmung, Löschung, sensible Meetings |
| Anbieterprüfliste | AVV, DPA, TIA, TOMs, Subprozessoren |
Phase 4: Anbieter- und Architekturentscheidung
Ziel:
- Shortlist auswählen
- Angebote einholen
- Datenschutzprüfung durchführen
- TCO vergleichen
- Pilot definieren
Mögliche Zielarchitektur:
| Bereich | Empfehlung |
|---|---|
| Mitarbeitenden-KI | Langdock, ChatGPT Enterprise, Workspace Gemini oder Copilot |
| Frontier-Modelle | OpenAI, Claude, Gemini via Enterprise/API |
| vertrauliche Projektarbeit | Azure OpenAI, AWS Bedrock, Vertex AI, Mistral |
| hohe Datenschutzanforderung | T-Systems, STACKIT, IONOS, Aleph Alpha |
| streng vertrauliche Daten | Private/on-prem LLM oder Sovereign/Air-Gap |
| Recherche | Perplexity Enterprise oder Grok Enterprise nur für K0/K1/K2 nach Prüfung |
Phase 5: Pilot und Audit Readiness
Ziel:
- Pilot produktiv machen
- Logs prüfen
- Richtlinie verbessern
- Schulungen wiederholen
- AI-Act-Dokumentation vervollständigen
Ergebnis:
| Ergebnis | Inhalt |
|---|---|
| Pilotbericht | Nutzen, Risiken, Kosten |
| Audit Logs Review | Nutzung und Auffälligkeiten |
| Policy Update | Anpassungen |
| Schulungsupdate | Lessons Learned |
| AI-Act-Dokumentation | Use-Case-Register, Risiko, Human Oversight |
26. Leitfragen für die interne Entscheidungsrunde
26.1 Use Cases
- Welche KI-Anwendungen sind konkret geplant?
- Geht es um Text, Dokumente, Audio, Meetings, Code, Bilder, CAD, BIM, Video oder Datenanalyse?
- Sollen nur Mitarbeitende KI nutzen oder auch Kunden?
- Wird KI nur assistieren oder Entscheidungen vorbereiten?
- Gibt es HR-, Recruiting-, Gesundheits-, Pflege-, Rechts- oder Steuerdaten?
- Gibt es KI-Funktionen in bestehender Projektmanagement-, CRM-, ERP- oder Fachsoftware?
26.2 Daten
- Welche Datenklassen sollen verarbeitet werden?
- Gibt es personenbezogene Daten?
- Gibt es besondere Kategorien personenbezogener Daten?
- Gibt es Kundendaten oder Projektgeheimnisse?
- Gibt es Quellcode, Zugangsdaten oder Sicherheitsinformationen?
- Gibt es Meetingtranskripte?
- Sind Dokumente über Kontext, Metadaten oder Kundenbezug personenbeziehbar?
- Werden Kalkulationen, Honorare, Verträge oder vertrauliche Preisstrukturen verarbeitet?
26.3 Infrastruktur
- Nutzt das Unternehmen Microsoft 365?
- Nutzt das Unternehmen Google Workspace?
- Gibt es AWS, Azure oder Google Cloud?
- Gibt es SSO/IdP?
- Gibt es bereits DLP, SIEM, Audit Logging?
- Gibt es Datenklassifizierung?
- Gibt es zentrale Geräteverwaltung?
- Gibt es Browser-/Extension-Management?
26.4 Datenschutz und Compliance
- Gibt es einen Datenschutzbeauftragten?
- Gibt es Vorgaben gegen US-Anbieter?
- Ist EU-Hosting ausreichend oder wird deutsche/souveräne Cloud verlangt?
- Gibt es bereits AVV-/DPA-Prozesse?
- Gibt es ein Verzeichnis von Verarbeitungstätigkeiten?
- Gibt es DSFA-Erfahrung?
- Gibt es Betriebsrat oder Arbeitnehmervertretung?
- Gibt es Kundenverträge mit KI- oder Geheimhaltungsklauseln?
27. Gesprächsstrategie für Beratung und Management
27.1 Einstieg
Das Thema sollte nicht als reine Toolauswahl behandelt werden, sondern als kontrollierte KI-Governance. Die zentrale Frage ist: Welche Datenklasse darf in welches KI-System?
27.2 Datenschutzposition
Eine EU-Region ist hilfreich, reicht aber nicht allein. Zusätzlich zu prüfen sind AVV/DPA, Trainingsnutzung, Retention, Subprozessoren, Supportzugriffe, Drittlandtransfer, CLOUD Act, SSO, Audit Logs und interne Nutzungsregeln.
27.3 AI-Act-Position
Der EU AI Act betrifft nicht nur Anbieter wie OpenAI oder Google. Wenn ein Unternehmen KI einsetzt, kann es als Betreiber Pflichten haben. Besonders kritisch sind HR, Recruiting, Mitarbeiterbewertung, Gesundheit, Bonität, Biometrie und automatisierte Entscheidungen.
27.4 Anbieterposition
Für normale interne Wissensarbeit können Enterprise-KI-Plattformen reichen. Für vertrauliche oder personenbezogene Daten braucht es Enterprise/API/Sovereign-Setups. Für sehr sensible Daten sollten deutsche Cloud, souveräne Cloud oder on-prem geprüft werden.
27.5 Grok/xAI-Position
Grok ist funktional spannend, insbesondere wegen Realtime Search, Voice, Image und Video. Datenschutzseitig sollte Grok Business/Enterprise aktuell konservativ eingestuft werden. Nicht X Premium oder Consumer-Grok für Unternehmensdaten. Wenn überhaupt, dann Enterprise/API mit DPA, ZDR, SSO/SCIM, Audit Logs, Retention und Transferprüfung.
28. Beispielhafte Management-Zusammenfassung
KI kann erhebliche Produktivitätsgewinne bringen, darf aber nicht unkontrolliert eingeführt werden. Der sichere Weg besteht darin, KI-Nutzung nicht pauschal zu erlauben oder zu verbieten, sondern nach Datenklassen und Use Cases zu steuern.
Consumer-Tools eignen sich nur für öffentliche und nichtkritische Inhalte. Für interne und vertrauliche Unternehmensdaten braucht es Business- oder Enterprise-Lösungen mit AVV/DPA, No-Training-Zusage, Retention-Kontrolle, SSO, Audit Logs und klaren Nutzungsregeln. Für personenbezogene, regulierte oder besonders vertrauliche Daten sollten EU-, deutsche, souveräne oder private Betriebsmodelle geprüft werden.
US-Anbieter sind nicht automatisch ausgeschlossen, erfordern aber zusätzliche Prüfung hinsichtlich Drittlandtransfer, EU-US Data Privacy Framework, US CLOUD Act, Subprozessoren, Supportzugriffen und technischen Schutzmaßnahmen. Der EU AI Act macht zusätzlich eine Use-Case-Governance erforderlich, insbesondere bei HR, Recruiting, Gesundheit, Bonität, Biometrie und automatisierten Entscheidungen.
Empfohlen wird ein strukturiertes Vorgehen:
- KI-Tool-Inventar erstellen.
- Datenklassen K0-K4 einführen.
- Use Cases nach Risiko bewerten.
- Anbieter-Freigabeliste erstellen.
- Mitarbeitende schulen.
- Meeting-Mitschnitte gesondert regeln.
- Enterprise-/Sovereign-Pilot starten.
- AI-Act-Use-Case-Register aufbauen.
29. Finales Beratungsfazit
Die entscheidende Botschaft:
Es gibt nicht „die eine datenschutzkonforme KI". Es gibt nur freigegebene KI-Systeme für klar definierte Datenklassen und Use Cases.
Praktische Zielarchitektur:
Praktische Zielarchitektur als strukturierte Liste:
- Unternehmen → KI-Governance mit Bausteinen:
- Datenklassifizierung K0–K4
- Use-Case-Register
- Anbieter-Freigabeliste
- Interne Nutzungsrichtlinie
- DSGVO / AVV / TIA / DSFA
- AI-Act-Bewertung
- Tool-Zuordnung nach Datenklasse:
- Consumer KI nur K0
- Business KI für K1/K2 eingeschränkt
- Enterprise/API für K2/K3
- Sovereign/On-Prem für K3/K4
- Begleitende Maßnahmen:
- Mitarbeiterschulung (aus Nutzungsrichtlinie)
- Datenschutzfreigabe (aus DSGVO/AVV/TIA/DSFA)
- AI-Act-Compliance (aus AI-Act-Bewertung)
Konkrete Empfehlung:
- Consumer-KI nicht für Unternehmensdaten freigeben.
- Business-/Enterprise-KI für K1/K2 strukturieren.
- Für K3/K4 EU-/DE-/Sovereign-/Private-Setups prüfen.
- US-Anbieter nicht pauschal ausschließen, aber CLOUD Act/TIA beachten.
- EU AI Act nicht vergessen: Use Case entscheidet.
- Meeting-Mitschnitte gesondert regeln.
- Tool-Freigabeliste und interne KI-Richtlinie einführen.
- Grok/xAI aufnehmen, aber konservativ einstufen.
- Gemini nicht als Consumer-App, sondern über Workspace/Vertex/T-Systems betrachten.
- Als erster Schritt: Workshop zu Use Cases und Datenklassen.
30. Sofort umsetzbare To-do-Liste
Innerhalb von 7 Tagen
- alle verwendeten KI-Tools erfassen
- private KI-Nutzung abfragen
- Consumer-KI für Kundendaten untersagen
- Meeting-KI vorläufig nur mit expliziter Zustimmung erlauben
- KI-Basisrichtlinie als 1-Seiter verteilen
Innerhalb von 30 Tagen
- Datenklassen K0-K4 einführen
- Tool-Freigabeliste erstellen
- Datenschutz, IT, Informationssicherheit und ggf. Betriebsrat einbinden
- AVV/DPA der Wunsch-Anbieter prüfen
- erste Mitarbeiterschulung durchführen
- Pilotanbieter auswählen
Innerhalb von 60–90 Tagen
- Enterprise-/Sovereign-Pilot starten
- Audit Logs aktivieren
- SSO/SCIM einrichten
- RAG-/Dokumentenstrategie definieren
- DSFA für kritische Use Cases prüfen
- AI-Act-Use-Case-Register erstellen
31. Wie DATENMASSIV unterstützt
Drei Bausteine, die viele der oben genannten Schritte direkt umsetzen helfen:
AI Hub & Toolbox — ein zentraler, mandantenfähiger KI-Hub, der die in Abschnitt 20 beschriebene Gateway-/Policy-Schicht für KMU sofort nutzbar macht: gebündelter Zugang zu Modellen, Datenklassen-Routing, Audit Logs, gemeinsame Prompt- und Wissensbasis. Live-Demo: ai-hub-green.vercel.app
Interaktive KI-Workshop-Plattform — strukturierte Lernpfade, Live-Übungen und rollenbezogene Prompt-Bibliotheken zur Erfüllung der AI-Literacy-Pflicht (Abschnitt 6) und zur Reduktion von Shadow AI (Abschnitt 20). Mitarbeitende werden befähigt, statt nur instruiert.
AI-First-Audit & Onboarding — strukturierte Bestandsaufnahme (Phase 1 der Roadmap, Abschnitt 25), Use-Case-Bewertung und individuelle KI-Strategie inklusive Datenklassenmodell, Tool-Freigabeliste und KI-Richtlinie.
Kontakt und mehr Informationen: datenmassiv.com
32. Quellen- und Prüfhinweise für weitere Due Diligence
Für die finale rechtliche und technische Freigabe sollten zu jedem Anbieter die aktuellsten Dokumente geprüft werden:
- Anbieter-DPA / AVV
- Terms of Service / Commercial Terms
- Privacy Policy
- Data Retention Policy
- Subprocessor List
- Security Whitepaper
- SOC 2 / ISO 27001 / C5-Berichte
- EU Data Residency Dokumentation
- Zero Data Retention Dokumentation
- Admin-/Audit-Log-Dokumentation
- AI-Act-Dokumentation / Model Cards / System Cards
- Standard Contractual Clauses
- Data Privacy Framework Status
- Transfer Impact Assessment
- technische und organisatorische Maßnahmen
- Betriebsvereinbarung / interne Policy
- Löschkonzept
- Rollen- und Berechtigungskonzept
- Protokollierungs- und Monitoring-Konzept
33. Disclaimer
Dieser Report ist eine strategische Orientierungs- und Entscheidungsgrundlage. Er ersetzt keine individuelle Rechtsberatung, keine Datenschutz-Folgenabschätzung, keine Vertragsprüfung und keine technische Sicherheitsprüfung. Für konkrete Freigaben sollten Datenschutzbeauftragte, IT-Sicherheit, Rechtsberatung, Einkauf und betroffene Fachbereiche einbezogen werden.
