Welcher rechtliche Rahmen gilt bei KI-Einsatz?
Beim Einsatz von KI-Systemen sind in Deutschland zwei regulatorische Rahmen relevant. Der erste, und älter, ist die Datenschutz-Grundverordnung (DSGVO). Sie gilt für jede Verarbeitung personenbezogener Daten — unabhängig davon, ob sie durch Menschen, klassische Software oder KI-Modelle erfolgt. Der zweite, neuer, ist die EU KI-Verordnung (AI Act), die seit Anfang 2025 in Kraft ist und je nach Risikoklasse der KI-Anwendung zusätzliche Anforderungen stellt.
Für die meisten mittelständischen Automatisierungsprojekte — Rechnungsverarbeitung, E-Mail-Triage, Dokument-Klassifizierung — gilt die KI-Verordnung in der Kategorie „minimales Risiko" oder „begrenztes Risiko". Die praktischen Auflagen bleiben überschaubar. Die DSGVO-Pflichten dagegen sind voll zu erfüllen — und hier passieren in der Praxis die meisten Fehler.
Das Verständnis der Risikoklassen lohnt sich trotzdem. Systeme, die Entscheidungen mit rechtlicher Wirkung treffen (etwa automatische Ablehnung eines Kredits) oder die in sensiblen Bereichen wie Personalrekrutierung oder Gesundheit eingesetzt werden, fallen in die Kategorie „hohes Risiko" und unterliegen deutlich strengeren Anforderungen. Die meisten Prozessautomatisierungen im Mittelstand sind davon nicht betroffen.
Die Kernfrage: Welche Daten verlassen Ihr Haus?
Die wichtigste Entscheidung ist früh und technisch: Welche Daten werden zur Verarbeitung an welches Sprachmodell übergeben — und wo läuft dieses Modell physisch?
Die großen US-Anbieter — OpenAI, Anthropic, Google — bieten ihre Modelle zu einem großen Teil aus US-Infrastruktur an. Das ist für viele datenschutzrechtliche Anwendungen problematisch, obwohl inzwischen EU-Hosting-Optionen bei manchen Anbietern verfügbar sind (Microsoft Azure OpenAI mit EU-Regionen, Anthropic über AWS EU, und andere).
Für besonders sensible Daten — Personaldaten, Gesundheitsinformationen, detaillierte Finanzdaten — ist auch EU-Hosting unter US-Anbieter-Kontrolle oft nicht ausreichend, da der CLOUD Act der USA die Herausgabe auch aus EU-Rechenzentren theoretisch verlangen kann. Für solche Fälle bleibt die Option lokaler Modelle: Ein Modell wie Llama, Mistral oder Qwen läuft auf Ihrer eigenen Hardware oder auf einem europäischen Hoster Ihrer Wahl.
Die Entscheidung zwischen diesen Optionen ist nicht nur rechtlich, sondern auch wirtschaftlich. Lokale Modelle sind technisch anspruchsvoller zu betreiben und erreichen bei komplexen Aufgaben noch nicht die Qualität der großen Modelle. Für gut umrissene Aufgaben — Klassifizierung, Extraktion strukturierter Daten — sind sie jedoch völlig ausreichend.
Welche Verträge brauchen Sie mit dem KI-Anbieter?
Wenn Sie personenbezogene Daten an einen KI-Anbieter zur Verarbeitung übergeben, handelt es sich in den meisten Fällen um eine Auftragsverarbeitung im Sinne der DSGVO. Das heißt: Sie brauchen einen Auftragsverarbeitungs-Vertrag (AVV) mit dem Anbieter.
Die etablierten Anbieter stellen solche AVV standardmäßig bereit — OpenAI über den Enterprise-Vertrag, Anthropic, Google Cloud, Microsoft Azure. Prüfen Sie in diesen Verträgen vor allem drei Punkte. Erstens: Werden Ihre Eingabedaten zum Training des Modells verwendet? Bei den Business- oder API-Angeboten dieser Anbieter in aller Regel nicht — aber es lohnt sich, das explizit zu bestätigen. Zweitens: Wie ist die Unterauftragsverarbeitung geregelt, wenn der Anbieter seinerseits Infrastruktur-Provider einsetzt? Drittens: Wie sind die Löschpflichten und Aufbewahrungsfristen geregelt?
Zusätzlich empfehlen wir eine schriftliche Datenschutz-Folgenabschätzung, bevor ein KI-System produktiv geht, das mit personenbezogenen Daten arbeitet. Die Folgenabschätzung dokumentiert die Risiken der Verarbeitung, die getroffenen Gegenmaßnahmen und die Freigabe durch die Datenschutzbeauftragte. Sie ist in vielen Fällen nicht strikt vorgeschrieben, aber die Dokumentation schützt Sie im Fall einer Prüfung.
Technische Gegenmaßnahmen.
Unabhängig vom Anbieter lohnt sich eine Reihe technischer Maßnahmen, die das Risiko der Datenverarbeitung reduzieren.
Pseudonymisierung und Minimierung. Bevor Daten an das Modell gehen, prüfen Sie, welche Felder wirklich gebraucht werden. Namen, E-Mail-Adressen und Kundennummern lassen sich oft durch Platzhalter ersetzen und nach der Verarbeitung wieder einsetzen — das Modell sieht nur die Daten, die es für die Aufgabe braucht.
On-Premise-Vorverarbeitung. Die Trennung der Dokumente, die Extraktion erster Strukturen, das Entfernen nicht benötigter Inhalte kann auf Ihrer eigenen Infrastruktur erfolgen, bevor der eigentliche Sprach-verstehende Schritt an das Modell geht. So bleibt ein großer Teil der Daten kontrolliert lokal.
Logging und Nachvollziehbarkeit. Jede Verarbeitung sollte protokolliert sein — welche Daten wurden wann an welches Modell übermittelt, welche Antwort kam zurück. Das ist nicht nur DSGVO-konform, sondern hilft auch bei der späteren Fehlerdiagnose.
Zugriffskontrolle. Der Zugriff auf den Agent und auf die verarbeiteten Daten muss kontrolliert sein — wer startet den Prozess, wer sieht die Ergebnisse, wer kann Eskalationen bearbeiten. Dies ist Standard-IT-Sicherheit, wird im KI-Kontext aber manchmal vergessen.
Dokumentationspflichten.
Die DSGVO verlangt ein Verzeichnis der Verarbeitungstätigkeiten. Ein KI-System, das personenbezogene Daten verarbeitet, muss dort aufgeführt sein. Die typischen Felder — Zweck der Verarbeitung, Kategorien der Daten, Empfänger, Löschfristen, technische und organisatorische Maßnahmen — sind auszufüllen wie für jede andere Verarbeitung auch.
Hinzu kommen spezifische Pflichten aus dem AI Act. Je nach Risikoklasse gelten unterschiedliche Dokumentations- und Transparenzpflichten. Für die meisten mittelständischen Automatisierungen reicht eine knappe System-Dokumentation (Zweck, Trainingsdaten-Grundlagen soweit bekannt, Leistungsgrenzen) — die Verordnung fordert nicht mehr, als ein sorgfältiger IT-Betrieb ohnehin dokumentiert.
Bei Interaktionen mit Personen — wenn beispielsweise Kunden mit einem KI-Agent chatten oder E-Mails austauschen, ohne es zu wissen — gilt eine Transparenz-Pflicht: Die Person muss erfahren, dass sie mit einem KI-System interagiert. Eine unauffällige Kennzeichnung in der Signatur oder im Gesprächs-Intro reicht in den meisten Fällen.
Wie wir die DSGVO in einem Versicherungs-Projekt umgesetzt haben.
Ein konkretes Beispiel aus unserer Arbeit zeigt, wie die abstrakten Anforderungen in ein tragfähiges Setup übersetzt werden — und wo die Stolperfallen liegen. Für einen mittelständischen Sachversicherer haben wir ein Triage-System gebaut, das 1.200 Schadensmeldungen pro Woche klassifiziert und an die Fachabteilungen weiterleitet. Personenbezogene Daten im Zentrum: Namen, Anschriften, Policennummern, Schadensbeschreibungen, in Einzelfällen auch Gesundheits- oder Haftungsangaben.
Die erste Entscheidung fiel beim Hosting. Wir haben uns früh gegen ein in den USA gehostetes Sprachmodell entschieden, obwohl die Vertrags-Option formal vorhanden gewesen wäre. Für Versicherungsdaten in dieser Granularität wollten weder wir noch die Datenschutzbeauftragte des Mandanten sich auf den CLOUD-Act-Ausschluss verlassen. Stattdessen nutzen wir ein EU-gehostetes Modell über einen deutschen Zwischen-Anbieter, dessen Vertrag den CLOUD Act explizit ausschließt und dessen Infrastruktur in Frankfurt steht.
Die zweite Entscheidung betraf die Datenminimierung. Eine eingehende Schadensmeldung enthält oft 30 bis 50 personenbezogene Felder — nicht alle sind für die Klassifizierung nötig. Wir haben deshalb eine Vorverarbeitungs-Schicht gebaut, die in der Infrastruktur des Versicherers läuft, bevor Daten an das Sprachmodell übergeben werden. Namen werden durch Platzhalter ersetzt, Adressen auf Postleitzahlen-Ebene reduziert, Policennummern durch interne Tokens ausgetauscht. Nach der Klassifizierung werden die ursprünglichen Werte deterministisch wieder eingesetzt. Das Modell sieht nur den Inhalts-Kern der Meldung, nicht die Identität.
Die dritte Entscheidung war organisatorisch. Die Datenschutzbeauftragte des Versicherers war von Projektwoche zwei an eingebunden, nicht erst bei der Fertigstellung. Wir haben ihr einen Data-Flow-Diagram mit allen Verarbeitungsschritten vorgelegt, die eingesetzten Modell-Anbieter im Detail erläutert und eine Datenschutz-Folgenabschätzung vorbereitet. Diese frühe Einbindung kostete uns in der ersten Woche zwei Termine und sparte in den letzten Wochen vor Livegang schätzungsweise drei bis vier Wochen — die typische Wartezeit, wenn eine Folgenabschätzung erst am Ende geschrieben wird.
Im Betrieb dokumentieren wir jede Klassifizierungs-Entscheidung mit Zeitstempel, eingesetztem Modell, Token-Anzahl und Confidence-Score. Falls ein Betroffener von seinem Auskunftsrecht nach Art. 15 DSGVO Gebrauch macht, lässt sich in Minuten nachweisen, wann seine Meldung verarbeitet wurde und wie die Entscheidung zustande kam. Dieses Logging ist technisch unspektakulär, aber für die rechtliche Tragfähigkeit des Systems entscheidend — und es wäre ohne frühe Abstimmung mit der Datenschutzbeauftragten wahrscheinlich zu schlank geraten.
Was wir aus diesem Projekt gelernt haben: Der Datenschutz ist nicht das Haupthindernis, als das er oft wahrgenommen wird. Er verschiebt aber Aufwand. Eine Stunde Abstimmung in Projektwoche zwei ersetzt zehn Stunden Nacharbeit in den letzten Wochen vor Livegang. Die vollständige technische und rechtliche Beschreibung des Projekts finden Sie in unserer Fallstudie zur Schadens-Triage.
Eine Checkliste für den Start.
Wenn Sie ein KI-Automatisierungsprojekt DSGVO-konform aufstellen wollen, arbeiten Sie die folgenden Punkte vor dem Projektstart ab.
Welche personenbezogenen Daten werden verarbeitet? Kategorisieren Sie: einfache Daten (Kontaktdaten), besondere Daten (Gesundheit, Herkunft), kritische Daten (Finanzen, Vertragsbeziehungen). Klären Sie für jede Kategorie, welches Hosting-Modell in Frage kommt.
Liegt ein gültiger Auftragsverarbeitungs-Vertrag mit dem gewählten Anbieter vor? Prüfen Sie Training-Ausschluss, Unterauftrag, Lösch-Regelungen.
Wurde die Datenschutz-Folgenabschätzung erstellt und von der Datenschutzbeauftragten gezeichnet?
Sind technische Schutzmaßnahmen implementiert: Pseudonymisierung, Vorverarbeitung, Logging, Zugriffskontrolle?
Ist die Verarbeitung im Verzeichnis der Verarbeitungstätigkeiten dokumentiert?
Wenn alle diese Fragen geklärt sind, stehen einem rechtssicheren Betrieb in aller Regel keine grundlegenden Hindernisse im Weg. Bei AI Atelier arbeiten wir bei jedem Projekt diese Fragen mit Ihnen durch und unterstützen bei der Freigabe — gerne in Abstimmung mit Ihrer Datenschutzbeauftragten oder einem Ihrer bevorzugten Rechtsberater. Wenn Sie einen konkreten Fall durchsprechen wollen, ist ein 45-minütiges Erstgespräch ein guter Einstieg.