KI und DSGVO im Unternehmen: Anbieter und Datenfluss prüfen.

Kurzantwort: Wann ist KI im Unternehmen DSGVO-gerecht einsetzbar?

KI kann im Unternehmen datenschutzgerecht eingesetzt werden, wenn für den konkreten Zweck eine tragfähige Rechtsgrundlage besteht, nur erforderliche Daten verarbeitet werden, Verantwortlichkeiten und Empfänger geklärt sind und angemessene technische sowie organisatorische Maßnahmen greifen. Hinzu kommen erfüllbare Betroffenenrechte, kontrollierte Speicher- und Löschwege und – bei voraussichtlich hohem Risiko – eine Datenschutz-Folgenabschätzung.

Stand 4. Oktober 2026 gibt es deshalb kein allgemeines Gütesiegel ‚DSGVO-konformes KI-Tool‘. Dieselbe Anwendung kann in einem Prozess ohne personenbezogene Daten unkritisch sein und in einem anderen Prozess sensible Beschäftigten-, Kunden- oder Gesundheitsdaten verarbeiten. Maßgeblich sind Konfiguration und tatsächliche Nutzung. Der Beitrag strukturiert die betriebliche Prüfung und ersetzt keine Rechtsberatung im Einzelfall.

Mit dem Verarbeitungsvorgang statt mit dem Produktnamen beginnen

Eine Anbieterprüfung ohne abgegrenzten Einsatzfall bleibt abstrakt. Beschreiben Sie zuerst, welche Information in den Prozess gelangt, welche KI-Funktion daraus welches Ergebnis erzeugt und welche menschliche oder technische Aktion folgt. Ein allgemeiner Zweck wie ‚Effizienzsteigerung‘ reicht weder für Datenminimierung noch für die Auswahl einer Rechtsgrundlage.

Freitext, E-Mails, Dokumente, Gesprächstranskripte und Wissensspeicher enthalten häufig mehr personenbezogene Daten als das Projektteam erwartet. Der Datenweg muss daher auch temporäre Dateien, Eingabehistorien, Modellprotokolle, Bewertungen, Supportzugriffe, Backups und die Ausgabe im führenden Fachsystem umfassen.

• Start- und Endpunkt des Geschäftsprozesses
• betroffene Personengruppen und erwartete Datenkategorien
• Eingaben, abgeleitete Merkmale, Ausgaben und Folgeaktionen
• Speicher, Protokolle, Empfänger, Zielsysteme und Administratorzugriffe
• fachlicher Zweck, erforderliche Felder und bewusst ausgeschlossene Inhalte

Verantwortlicher, Auftragsverarbeiter und eigene Anbieterzwecke trennen

Wer Zweck und wesentliche Mittel einer Verarbeitung festlegt, ist datenschutzrechtlich verantwortlich. Verarbeitet ein externer KI-Anbieter personenbezogene Daten ausschließlich nach dokumentierter Weisung, liegt nach der Orientierungshilfe der Datenschutzkonferenz häufig eine Auftragsverarbeitung vor. Entscheidet der Anbieter dagegen für eigene Zwecke über eine weitere Nutzung, kann diese Einordnung nicht allein durch die Überschrift eines Vertrags hergestellt werden.

Für jede Verarbeitungskomponente muss deshalb feststehen, wer Zweck, Datenquellen, Speicherfrist, Modellverbesserung und Empfänger bestimmt. Auch eine mögliche gemeinsame Verantwortlichkeit ist für den tatsächlichen Vorgang zu prüfen. Die Rollenklärung ersetzt die Rechtsgrundlage nicht: Verantwortliche müssen für ihre Verarbeitung und gegebenenfalls für eine Übermittlung eine passende Grundlage bestimmen.

• Welche Verarbeitung führt der Anbieter nur auf dokumentierte Weisung aus?
• Welche Telemetrie, Sicherheitsanalyse oder Produktverbesserung verfolgt er für eigene Zwecke?
• Wer entscheidet über Unterauftragnehmer, Speicherorte und Modellwechsel?
• Welche Partei beantwortet Auskunft, Berichtigung, Löschung und Widerspruch?
• Welche Rechtsgrundlage trägt den konkreten Zweck und mögliche Übermittlungen?

AV-Vertrag und Anbieterprüfung als ausführbaren Kontrollsatz gestalten

Artikel 28 DSGVO verlangt mehr als das Vorhandensein einer PDF-Datei. Der Verantwortliche darf nur Auftragsverarbeiter einsetzen, die hinreichende Garantien bieten. Vertrag, technische Dokumentation und produktive Einstellungen müssen zusammen erkennen lassen, welche Daten zu welchem Zweck verarbeitet werden, wie Weisungen wirken, wie Sicherheitsvorfälle gemeldet werden und wie Daten nach Vertragsende zurückgegeben oder gelöscht werden.

Unterauftragnehmer sind als konkrete Verarbeitungskette zu prüfen. Eine lange, dynamische Liste ohne Aufgaben, Orte und Änderungsweg erschwert die Bewertung. Legen Sie fest, wie Änderungen angekündigt werden, wer fachlich und datenschutzrechtlich prüft und welche Reaktion bei einem nicht akzeptablen neuen Unterauftragnehmer möglich ist.

• Gegenstand, Dauer, Art, Zweck, Datenarten und betroffene Personengruppen
• Weisungsbindung sowie dokumentierte eigene Zwecke des Anbieters
• Unterauftragnehmer mit Aufgabe, Ort und kontrolliertem Änderungsverfahren
• technische und organisatorische Maßnahmen mit Bezug zum Schutzbedarf
• Unterstützung bei Betroffenenrechten, Vorfällen und Datenschutz-Folgenabschätzung
• Rückgabe, Export und überprüfbare Löschung bei Wechsel oder Vertragsende

Verarbeitungsort und Drittlandtransfer als zwei Fragen behandeln

Eine wählbare EU-Region ist ein relevantes Architekturmerkmal, aber kein vollständiger Transfernachweis. Zu prüfen sind unter anderem Support- und Administratorzugriffe, Telemetrie, Missbrauchserkennung, Backups, Schlüsselverwaltung und Unterauftragnehmer. Erst der tatsächliche Datenweg zeigt, ob personenbezogene Daten den Europäischen Wirtschaftsraum verlassen oder von dort aus zugänglich werden können.

Für Übermittlungen in Drittländer benötigt der Verantwortliche die Voraussetzungen des Kapitels V DSGVO. Ein Angemessenheitsbeschluss der Europäischen Kommission kann eine Grundlage bilden; andernfalls kommen je nach Fall geeignete Garantien wie Standardvertragsklauseln und erforderliche ergänzende Maßnahmen in Betracht. Die Prüfung muss das konkrete Empfängerland, den Zugriff und die Schutzmaßnahmen abbilden – nicht nur die Konzernzentrale des Anbieters.

• Primärverarbeitung, Protokolle, Backups und Support getrennt lokalisieren
• Fernzugriffe und administrative Berechtigungen einbeziehen
• Transfergrundlage je Empfänger und Verarbeitungsschritt dokumentieren
• Verschlüsselung, Schlüsselkontrolle und weitere Maßnahmen praktisch bewerten
• Änderungen an Regionen und Unterauftragnehmern als erneuten Prüfauslöser behandeln

Training, Eingabehistorie und Protokollierung getrennt konfigurieren

Die Aussage ‚Ihre Daten werden nicht zum Training genutzt‘ beantwortet nur einen Teil der Verarbeitung. Zusätzlich muss geklärt werden, ob Eingaben und Ausgaben in einer Historie, für Missbrauchserkennung, Qualitätssicherung, Support oder Telemetrie gespeichert werden. Für jeden Zweck braucht es nachvollziehbare Datenkategorien, Zugriffe, Fristen und Löschereignisse.

Datenschutzfreundliche Voreinstellungen sollten die Nutzung von Eingaben für Training oder Produktverbesserung deaktivieren, wenn sie für den vereinbarten Prozess nicht erforderlich ist. Firmenkonten, zentrale Administration und kontrollierte Arbeitsbereiche sind dafür belastbarer als private Einzelkonten. Die wirksame Konfiguration gehört mit Datum und Produktversion in den Freigabenachweis.

Datenminimierung an jeder Systemgrenze technisch durchsetzen

Datenminimierung bedeutet nicht nur, Felder vor einem Prompt zu entfernen. Der Prozess sollte bereits beim Eingang Fallarten trennen, unnötige Anhänge abweisen, vertrauliche Inhalte kennzeichnen und dem Modell nur den für den nächsten Schritt erforderlichen Kontext bereitstellen. Pseudonymisierung kann das Risiko senken, beseitigt den Personenbezug aber nicht automatisch.

Modellzugriff, Prozesssteuerung und schreibende Rechte in CRM, ERP oder DMS sollten getrennt bleiben. Das Modell liefert einen Vorschlag oder eine strukturierte Ausgabe; eine kontrollierte Prozessschicht validiert Format, Werte und Berechtigung. Verbindliche Aktionen erfolgen mit einer begrenzten technischen Identität und werden im Zielsystem bestätigt.

• Fallart und Schutzbedarf vor dem Modellaufruf bestimmen
• nur erforderliche Felder und Dokumentausschnitte übertragen
• besondere Daten und unzulässige Inhalte in einen gesonderten Weg leiten
• Ausgaben gegen Regeln und verlässliche Referenzdaten prüfen
• Schreibrechte pro Aktion, Objekt und Zielsystem begrenzen

Betroffenenrechte über alle Speicher und Ableitungen ausführbar machen

Auskunft, Berichtigung, Löschung, Einschränkung und Widerspruch müssen im realen Systemverbund bearbeitet werden können. Eine Kundennummer im CRM hilft nur, wenn Eingaben, Protokolle, Vektorspeicher, Bewertungen und erzeugte Vorgänge über geeignete Schlüssel auffindbar sind. Gleichzeitig darf ein Suchindex nicht zum neuen unkontrollierten Personenregister werden.

Die Datenschutzkonferenz weist darauf hin, dass ein nachgeschalteter Ausgabefilter nicht generell als Löschung der zugrunde liegenden personenbezogenen Daten genügt. Planen Sie deshalb je Speicherart, ob Daten gelöscht, gesperrt, korrigiert oder aus einem Wissensbestand und seinen Ableitungen neu aufgebaut werden müssen. Der Anbieter muss die dafür erforderlichen Informationen und Funktionen liefern.

• Vorgangs- und Betroffenenbezug über definierte Schlüssel herstellen
• Rohdaten, Historie, Logs, Embeddings, Bewertungen und Zielsysteme erfassen
• Lösch- und Berichtigungswirkung je Speicherart festlegen
• Anbieterunterstützung und Bearbeitungsfristen praktisch testen
• Ausnahmen durch Aufbewahrungspflichten fachlich begründen und begrenzen

Risiko, DSFA und automatisierte Entscheidungen gesondert prüfen

Vor dem Einsatz ist das Risiko für Rechte und Freiheiten natürlicher Personen anhand von Art, Umfang, Umständen und Zweck der Verarbeitung zu bewerten. Ist voraussichtlich ein hohes Risiko zu erwarten, ist vor Beginn eine Datenschutz-Folgenabschätzung nach Artikel 35 DSGVO erforderlich. Die Beteiligung von KI allein entscheidet diese Frage nicht; sensible Daten, systematische Bewertung, große Reichweite oder erhebliche Folgen können das Risiko jedoch erhöhen.

Ob eine ausschließlich automatisierte Entscheidung im Sinne von Artikel 22 DSGVO vorliegt, ist eine zusätzliche Prüfung. Eine menschliche Bestätigung verhindert dies nicht automatisch, wenn die prüfende Person weder ausreichende Informationen noch Zeit oder tatsächliche Änderungsbefugnis besitzt. Wirkung, Eingriffsmöglichkeit und Eskalation müssen daher im Prozessdesign sichtbar sein.

KI-Anbieter und Einsatzfall in acht Stationen freigeben

Ein wiederholbarer Freigabeprozess verbindet Datenschutz, Informationssicherheit, Fachbereich und technische Umsetzung. Er beginnt mit dem Einsatzfall und endet erst, wenn Vertrag, Konfiguration, Integrationen und Betriebsverantwortung dieselbe zulässige Verarbeitung beschreiben.

Offene Punkte erhalten einen Besitzer und eine Sperrwirkung. Ein fehlender Löschtest oder eine unklare Unterauftragnehmerkette darf nicht durch eine allgemeine Risikofolie ersetzt werden. Die Freigabe benennt ausdrücklich erlaubte Fallarten, ausgeschlossene Daten und Ereignisse, die eine erneute Prüfung auslösen.

• 1. Zweck, Fallarten, Daten und Wirkung des Prozesses abgrenzen
• 2. Datenfluss einschließlich Logs, Support, Backups und Zielsystem zeichnen
• 3. Rollen, Rechtsgrundlage, Empfänger und Informationspflichten klären
• 4. Vertrag, Unterauftragnehmer, Orte und Transfergrundlagen prüfen
• 5. Datenminimierung, Konten, Rechte und Speicherfristen konfigurieren
• 6. Betroffenenrechte, Löschung, Export und Vorfallweg praktisch testen
• 7. Risiko, DSFA-Bedarf, menschliche Kontrolle und Ausschlüsse entscheiden
• 8. Freigabe versionieren und Monitoring sowie Prüfauslöser festlegen

Beispielprozess: E-Mails klassifizieren und kontrolliert an ein Ticketsystem übergeben

Ein Unternehmen möchte eingehende Service-E-Mails nach Anliegen und Dringlichkeit klassifizieren. Der kontrollierte Weg übernimmt die Nachricht zunächst in eine Annahmezone, entfernt nicht benötigte Signaturbilder, erkennt besonders schutzbedürftige Fallarten und übermittelt nur Betreff, erforderlichen Textausschnitt und eine pseudonyme Vorgangs-ID an den KI-Dienst.

Der Dienst darf die Daten nur für die beauftragte Klassifikation verarbeiten; Training und langfristige Eingabehistorie sind deaktiviert. Eine Prozessschicht validiert Kategorie und Dringlichkeit, legt das Ticket mit begrenzten Rechten an und speichert Original sowie Entscheidung im dafür vorgesehenen System. Sensible oder unsichere Fälle gehen an ein zuständiges Team. Löschung, Berichtigung und Auskunft laufen über die Vorgangs-ID durch alle beteiligten Speicher.

Das Beispiel ist ein Anwendungsszenario, keine Aussage über einen realen Kunden. Ob diese Gestaltung im Einzelfall genügt, hängt von Daten, Zweck, Rechtsgrundlage, Anbieter und Schutzbedarf ab.

Datenschutz als kontrollierten Betriebs- und Änderungsprozess führen

Eine einmalige Freigabe deckt spätere Modell-, Funktions- oder Vertragsänderungen nicht automatisch ab. Überwachen Sie deshalb Versionen, Unterauftragnehmer, Verarbeitungsorte, Speicheroptionen, Berechtigungen, Fehlerbilder und Beschwerden. Technische Tests müssen bestätigen, dass ausgeschlossene Daten, Löschwege und Freigabeschwellen auch nach Updates noch funktionieren.

Prüfauslöser gehören in Beschaffung und Change-Management: neuer Zweck, zusätzliche Datenquelle, längere Aufbewahrung, neuer Empfänger, veränderte Region, anderer Modellanbieter, neue schreibende Aktion oder ein höherer Automatisierungsgrad. Der Freigabestand sollte erkennen lassen, welche Vertrags- und Konfigurationsversion zu welchem Zeitpunkt galt und wer die Änderung genehmigt hat.