Zuletzt aktualisiert: März 2026
Was bedeutet “datenschutzfreundlich” bei KI konkret?
Datenschutzfreundliche KI für Unternehmen ist kein Marketingbegriff, sondern eine technische und rechtliche Anforderung. Das DSGVO-Fundament besteht aus zwei Artikeln, die direkt auf KI-Systeme anwendbar sind.
Art. 25 DSGVO (Privacy by Design und Privacy by Default) verlangt, dass Datenschutz von Anfang an in die Systemarchitektur eingebaut wird, nicht nachträglich. Für KI-Einsatz bedeutet das: minimale Datenerhebung, klare Zweckbindung und datenschutzfreundliche Voreinstellungen. Wenn ein Chatbot standardmäßig alle Konversationen zur Modellverbesserung weiterleitet, ist das eine Art.-25-Verletzung, sofern keine Einwilligung vorliegt.
Art. 28 DSGVO (Auftragsverarbeitung) greift, sobald ein KI-Anbieter personenbezogene Daten im Auftrag des Unternehmens verarbeitet. Dann ist ein Auftragsverarbeitungsvertrag (AVV) zwingend. Laut den Datenschutzbehörden der Länder muss der AVV Zweckbestimmung, Weisungsrecht, technisch-organisatorische Maßnahmen (TOMs), Sub-Auftragsverarbeiter und Audit-Rechte regeln. Ein AVV allein reicht aber nicht: Das Unternehmen bleibt als Verantwortlicher in der Pflicht, die tatsächliche Einhaltung zu kontrollieren.
Die Kombination aus beidem, technische Architektur und vertragliche Absicherung, ergibt erst einen datenschutzfreundlichen KI-Einsatz. Laut einer Bitkom-Studie 2025 mit 603 befragten deutschen Unternehmen haben 69 Prozent das Gefühl, dass der Datenschutz das Training und den Einsatz von KI-Modellen erschwert. Das ist kein Argument gegen Datenschutz, sondern eines für durchdachte Architekturentscheidungen von Anfang an.
Drei Betriebsmodelle im Vergleich: SaaS, Private Cloud EU, On-Premise
Die Wahl des Betriebsmodells ist die wichtigste Datenschutzentscheidung beim KI-Einsatz. Sie bestimmt, wer Zugriff auf Ihre Daten hat, unter welchem Rechtsrahmen diese verarbeitet werden und welche Kontrollmöglichkeiten Sie haben.
| Kriterium | SaaS (z.B. ChatGPT, Copilot) | Private Cloud EU | On-Premise / lokale LLMs |
|---|---|---|---|
| Datenspeicherort | Server des Anbieters (oft USA) | EU-Rechenzentrum (z.B. Hetzner, IONOS) | Eigene Hardware im Unternehmen |
| AVV erforderlich | Ja (sofern vorhanden) | Ja (eigener Hosting-Anbieter) | Nein (keine externe Verarbeitung) |
| Drittstaatenübermittlung | Häufig (USA, Standardvertragsklauseln) | Keine | Keine |
| Modellkontrolle | Keine (Anbieter bestimmt) | Hoch (Modellwahl flexibel) | Vollständig |
| Trainingsnutzung der Daten | Abhängig von Vertrag, oft unklar | Nein (eigener Betrieb) | Nein |
| Protokollierung / Auditierbarkeit | Eingeschränkt | Vollständig konfigurierbar | Vollständig konfigurierbar |
| Typische Einsatzfälle | Allgemeine Textaufgaben, nicht-sensible Daten | Interne Wissensdatenbanken, HR, Recht | Hochsensible Daten, strenge Compliance |
| Infrastrukturaufwand | Gering | Mittel | Hoch (GPU-Hardware, Wartung) |
Bei SaaS-Lösungen ist besondere Vorsicht geboten: Selbst wenn ein europäischer Datenspeicherort versprochen wird, kann der Anbieter Support-Zugriffe oder Modellanfragen über US-Infrastruktur routen. Der Europäische Gerichtshof hat mit dem Schrems-II-Urteil klargestellt, dass reine Standardvertragsklauseln ohne begleitende technische Maßnahmen nicht ausreichen, wenn US-Behörden auf Daten zugreifen können.
DSGVO-Checkliste für den KI-Einsatz
Bevor ein KI-System produktiv genutzt wird, sollte das Unternehmen fünf Punkte geprüft haben. Diese Liste deckt die häufigsten Lücken ab, die bei Datenschutz-Audits auffallen.
1. Auftragsverarbeitungsvertrag (AVV)
Für jeden KI-Anbieter, der personenbezogene Daten verarbeitet, muss ein AVV nach Art. 28 DSGVO vorliegen. Prüfen Sie insbesondere die Sub-Auftragsverarbeiter-Klausel: Viele Anbieter leiten Anfragen an Drittanbieter weiter (z.B. Azure OpenAI, AWS Bedrock), die ebenfalls im AVV erfasst sein müssen.
2. Technisch-organisatorische Maßnahmen (TOMs)
Verschlüsselung der Daten in Übertragung und Speicherung, Zugangskontrolle, Backups und Incident-Response-Prozesse müssen dokumentiert sein. Bei selbst gehosteten Lösungen liegt die Verantwortung vollständig beim Unternehmen.
3. Zweckbindung
KI-Systeme dürfen Daten nur für den festgelegten Zweck verarbeiten. Wenn ein System für Kundenkorrespondenz eingesetzt wird, darf es nicht gleichzeitig zur Personalbeurteilung genutzt werden. Die Zwecke müssen im Verzeichnis der Verarbeitungstätigkeiten (Art. 30 DSGVO) dokumentiert sein.
4. Berechtigungskonzept
Wer darf welche Wissensräume und Datenquellen abfragen? Ein Recruiter sollte keinen Zugriff auf Finanzdaten haben, auch nicht indirekt über eine KI, die auf alle internen Dokumente zugreift. Rollenbasierte Zugriffssteuerung ist keine optionale Komfortfunktion, sondern Datenschutzpflicht.
5. Protokollierung und Auditierbarkeit
Welcher Nutzer hat wann welche Anfrage gestellt und welche Daten wurden verarbeitet? Ohne Protokollierung ist weder eine Datenschutzverletzung rekonstruierbar noch eine Löschpflicht (Art. 17 DSGVO) kontrollierbar umsetzbar.
EU AI Act ab 2026: Was ändert sich für den Datenschutz?
Der EU AI Act gilt seit August 2024. Die vollständige Anwendbarkeit für Hochrisiko-KI-Systeme greift ab August 2026. Für den Datenschutz-Rahmen in Unternehmen sind drei Punkte relevant.
Risikoklassifizierung: KI-Systeme im Personalbereich (Recruiting, Leistungsbeurteilung) und in der Kundenbonitätsprüfung gelten als Hochrisiko-KI. Diese Systeme unterliegen strengeren Dokumentations-, Transparenz- und Monitoring-Pflichten. Ein KI-System, das Bewerberprofile vorqualifiziert, ist damit kein internes Tool mehr, sondern ein reguliertes System.
Schnittstelle zur DSGVO: AI Act und DSGVO sind keine konkurrierenden Regelwerke, sondern ergänzende. Der AI Act verlangt Grundrechtefolgenabschätzungen für Hochrisiko-Systeme, die inhaltlich der Datenschutz-Folgenabschätzung (DPIA) nach Art. 35 DSGVO ähneln. Unternehmen, die bereits eine solide DSGVO-Governance haben, können diese Dokumentation als Basis nutzen. Laut einer KPMG-Analyse zum EU AI Act ist die Kombination beider Regelwerke für Unternehmen die zentrale Compliance-Herausforderung 2026.
Nationale Umsetzung: Am 11. Februar 2026 beschloss das Bundeskabinett den Entwurf des KI-Marktüberwachungs- und Innovationsförderungsgesetzes (KI-MIG), das die deutschen Aufsichtsstrukturen für den AI Act festlegt. Unternehmen sollten prüfen, ob ihre KI-Systeme in Risikokategorien fallen, die eine Registrierung in der EU-Datenbank für Hochrisiko-KI erfordern.
Praxisbeispiel: Personaldienstleister mit DSGVO-konformem CV-Handling
Aus einem Projekt von Schauersberger Software.
Ein Personaldienstleister verarbeitet täglich eingehende Bewerbungsunterlagen, darunter Lebensläufe mit Geburtsdaten, Adressen und teils Gesundheitsangaben. Das Ziel: automatisiertes Auslesen, Strukturieren und Abgleichen mit offenen Stellen.
Das Datenschutzproblem mit einem Standard-SaaS-Tool: Lebensläufe enthalten personenbezogene Daten, die auf US-Servern verarbeitet würden, ohne klare Zweckbindung und ohne Löschfristen. Eine Drittstaatenübermittlung wäre für Bewerberdaten kaum begründbar.
Die Lösung war eine Private Cloud auf einem deutschen Hetzner-Server mit einem lokal betriebenen Sprachmodell für die Dokumentenverarbeitung. Die Architektur im Detail: Lebensläufe werden hochgeladen, vom lokalen Modell geparst und strukturiert in eine interne Datenbank geschrieben. Das Modell hat keinen Internetzugang, keine Anbindung an externe APIs. Recruiter erhalten pro Bewerbung eine strukturierte Zusammenfassung mit relevantem Qualifikationsprofil. Löschfristen sind technisch erzwungen: Nach sechs Monaten ohne Aktivität werden Bewerberdaten automatisch gelöscht.
Das Ergebnis: Die manuelle Vorqualifizierung entfällt weitgehend. Die Datenschutz-Folgenabschätzung nach Art. 35 DSGVO war möglich, weil alle Datenflüsse intern und vollständig dokumentiert sind.
Entscheidungsmatrix: Welches Betriebsmodell passt wann?
Die Frage ist nicht, welches Betriebsmodell “am sichersten” ist, sondern welches zur tatsächlichen Datenlage, dem verfügbaren Budget und den Compliance-Anforderungen passt.
SaaS mit EU-Datenresidenz
Wann sinnvoll
Allgemeine Textaufgaben ohne Personenbezug, kein Zugriff auf interne Dokumente, keine sensiblen Branchen (kein Gesundheitswesen, keine Personalakte, kein Recht). Schneller Einstieg, minimaler Infrastrukturaufwand.
Private Cloud EU
Wann sinnvoll
Interne Wissensdatenbanken mit personenbezogenen Daten, Branchen mit erhöhtem Schutzbedarf, Teams ab 10 Nutzern mit regelmäßigem Dokumentenzugriff. Gutes Verhältnis aus Kontrolle, Leistung und Kosten.
On-Premise / lokale LLMs
Wann sinnvoll
Hochsensible Daten (Patientendaten, Gehaltsinformationen, Staatsgeheimnisse), strenge Compliance-Vorgaben, keine externe Anbindung gewünscht oder zulässig. Höchster Infrastrukturaufwand und Anfangsinvestition.
Eine Faustregel: Sobald das KI-System auf Dokumente zugreift, die Sie nicht bedenkenlos per E-Mail an einen externen Dienstleister schicken würden, scheidet Standard-SaaS aus. Private Cloud EU ist für die meisten deutschen KMUs der pragmatische Mittelweg: volle Kontrolle über Architektur und Datenflüsse, kein Betrieb eigener Hardware.
Die endgültige Entscheidung hängt aber immer vom konkreten Anwendungsfall ab. Ein Steuerberater, der Mandantendaten verarbeitet, hat andere Anforderungen als eine Marketing-Agentur, die Blogbeiträge erstellt. Beides lässt sich datenschutzfreundlich lösen, aber mit unterschiedlichen Architekturen.