KI einsetzen, ohne beim Datenschutz Bauchschmerzen zu bekommen – ein Praxisblick für Unternehmen

Sie wollen KI im Unternehmen nutzen, aber ohne später beim Datenschutz „auf Sicht zu fahren“. Genau darum geht in der Handreichung „KI in Behörden – Datenschutz von Anfang an mitdenken“ vom 22.12.2025 von der Bundesbeauftragten für Datenschutz und die Informationsfreiheit: Wie Sie KI so einsetzen, dass Sie die wichtigsten Datenschutz-Grundprinzipien von der Planung über den Betrieb bis zur laufenden Kontrolle im Griff haben.

Der entscheidende Gedanke aus der Handreichung, die auch auf den Unternehmensalltag übertragbar ist: Bei KI entstehen personenbezogene Daten nicht nur dann, wenn jemand bewusst Namen und Details in ein Prompt schreibt. Personenbezug kann in Trainingsdaten stecken, in Ein- und Ausgaben auftauchen, durch Rückschlüsse (Inferenz) entstehen – und unter Umständen sogar im Modell selbst, wenn Inhalte „memorisiert“ werden. Wenn Sie diese Stellen einmal sauber identifizieren, wird vieles einfacher: Sie können Zuständigkeiten klären, eine passende Rechtsgrundlage wählen, Betroffenenrechte technisch und organisatorisch absichern und typische KI-Risiken wie Halluzinationen oder Verzerrungen (Bias) beherrschbar machen.

Wenn in einem Unternehmen über KI gesprochen wird, ist meistens etwas wie ein Chatbot gemeint: ein großes Sprachmodell (LLM), das Texte zusammenfasst, Mails entwirft, Fragen beantwortet oder Dokumente durchsucht. Genau auf solche LLM-basierten KI-Systeme richtet sich die Handreichung der BfDI. Sie wurde zwar für Behörden geschrieben, aber die datenschutzrechtlichen Grundfragen dahinter sind für Unternehmen genauso relevant: Wo stecken personenbezogene Daten, wer ist wofür verantwortlich, wie bleibe ich transparent, und wie gehe ich mit Löschung, Halluzinationen und Bias um?

Der wichtigste Perspektivwechsel, den die Handreichung gleich am Anfang nahelegt, ist dieser: Bei KI ist „personenbezogene Daten verarbeiten“ nicht nur das, was Sie bewusst in ein Prompt tippen. Personenbezug kann in mehreren Schichten entstehen – im Training, im Modell selbst und in Ein- und Ausgaben. Wenn Sie das einmal sauber auseinanderziehen, werden viele Diskussionen plötzlich viel klarer.

Wo in KI-Systemen personenbezogene Daten auftauchen können – und warum das für den Datenschutz entscheidend ist

In der Praxis passiert es schnell, dass man KI wie ein normales Software-Tool behandelt: Eingabe rein, Ausgabe raus, fertig. Die Handreichung macht aber deutlich, dass LLMs in mehreren Lebenszyklusphasen betrachtet werden müssen – Planung, Entwicklung, Implementierung, Betrieb und laufende Validierung. In jeder Phase können andere datenschutzrechtliche Anforderungen ausgelöst werden.

Personenbezug kann dabei schon bei den Trainingsdaten anfangen: Gerade wenn Trainingsdaten per Web Scraping gesammelt werden, enthalten sie in der Regel personenbezogene Daten – und selbst nach Aufbereitung und Filterung ist eine vollständige Anonymisierung oft praktisch kaum erreichbar.

Und jetzt kommt der Punkt, der viele überrascht: Die Handreichung beschreibt, dass personenbezogene Trainingsdaten „auf abstrakte Weise“ in Modellgewichten/Parametern landen können und unter bestimmten Bedingungen wieder reproduziert werden können (Memorisierung). Das bedeutet: Nicht nur Datenbank und Logfiles können personenbezogen sein, sondern unter Umständen auch das Modell selbst.

Dazu kommt ein zweites KI-spezifisches Thema: Inferenz. Ein LLM kann aus vermeintlich harmlosen Eingaben Rückschlüsse ziehen – zum Beispiel auf Herkunft oder Wohnort. Die Handreichung nennt als Beispiel, dass das Wort „Kiez“ über Kontextwissen auf Berlin als wahrscheinlichen Ort der sprachlichen Sozialisation hinweisen kann. Das ist wichtig, weil es zeigt: Selbst wenn Sie keine „klassischen“ personenbezogenen Angaben eintippen, kann in einem Prompt Personenbezug entstehen.

Und schließlich können auch Ausgaben personenbezogen sein: weil sie Daten aus der Eingabe wiederholen, weil sie aus verbundenen Quellen stammen, weil sie aus dem Modell reproduziert werden oder weil sie sogar personenbezogene Daten halluzinieren.

Wenn Sie also Datenschutz für KI sauber aufsetzen wollen, ist der erste Schritt eigentlich immer derselbe: Sie identifizieren konkret, welche Verarbeitungsvorgänge in Ihrem Setup stattfinden, also in welcher Lebenszyklusphase und an welcher Stelle personenbezogene Daten vorkommen können.

Wer ist verantwortlich – Sie, Ihr Anbieter, oder beide?

Ein zweiter Klassiker in Unternehmen: „Wir nutzen doch nur ein Tool – der Anbieter ist verantwortlich.“ Die Handreichung rät hier zu einer differenzierten Betrachtung, weil Verantwortlichkeit (Art. 4 Nr. 7 DSGVO) von Zwecken und Mitteln abhängt und je Verarbeitungsvorgang getrennt geprüft werden muss.

Gerade bei LLMs macht die technische Architektur einen großen Unterschied. Die Handreichung skizziert typische Konstellationen:

Wenn ein Dritter im Wesentlichen nur Infrastruktur bereitstellt (zum Beispiel Cloud-Rechenleistung) und Sie betreiben dort ein Modell, wählen es aus, speichern es, haben direkten Zugriff auf die Modellinstanz und nutzen es für eigene Zwecke, dann sind sie für die Verarbeitung verantwortlich – der Dritte handelt typischerweise als Auftragsverarbeiter.

Wenn Sie dagegen ein „geschlossenes“ Modell über eine Schnittstelle nutzen, bei dem der Anbieter die alleinige Kontrolle über die Parameter behält und Sie nicht auf das Modell einwirken können (kein Löschen der Modellinstanz, keine Anpassung), dann sind Sie nach der Handreichung in der Regel nicht für die Verarbeitung personenbezogener Daten im LLM selbst verantwortlich, wobei Sie natürlich weiterhin verantwortlich sind für das, was Sie an personenbezogenen Daten in Eingaben verarbeiten.

Und wenn Sie ein Basismodell auswählen und eine eigene Instanz bekommen, die Sie per Fine-Tuning oder weiterem Training anpassen können, dann sind Sie nach der Handreichung für memorisierte Daten in dieser Instanz verantwortlich, soweit und solange Sie erheblichen Einfluss nehmen können und z. B. die Löschung der Instanz veranlassen können, auch wenn Sie keinen „Klartext-Zugriff“ auf memorisierte Inhalte haben.

Für die Unternehmenspraxis heißt das: „KI aus der Cloud“ ist nicht automatisch „Datenschutz outgesourced“. Sie müssen Ihre Rolle pro Szenario sauber festlegen, und wenn ein Dienstleister Daten in Ihrem Auftrag verarbeitet, die passenden Verträge nach Art. 28 DSGVO aufsetzen.

Zweck festlegen und dokumentieren – ohne sich in KI-Begriffen zu verheddern

Beim Datenschutz ist der Zweck kein Formalismus, sondern der Anker. Die Handreichung betont, dass die Zweckbestimmung dokumentiert werden muss, unter anderem im Verzeichnis der Verarbeitungstätigkeiten (Art. 30 DSGVO).

Pragmatisch wichtig: Für den Einsatz von KI ist es nicht erforderlich, die Technologie ausdrücklich in der Zweckfestlegung zu benennen. Es genügt, wenn der konkrete Zweck technologieneutral beschrieben wird. In der Handreichung wird das am Beispiel der automatisierten Zuordnung eingehender E-Mails erläutert: Der Zweck ist die Bearbeitung/Zuordnung von E-Mail-Eingängen; KI ist „nur“ das technische Mittel.

Außerdem weist die Handreichung darauf hin, dass es im Rahmen der KI-Entwicklung zusätzliche Zwecke geben kann, etwa das Vorhalten von Datensätzen für Fortentwicklung oder zur Erfüllung von Betroffenenrechten, und dass das wiederum mit Datenminimierung und Speicherbegrenzung zusammengedacht werden muss.

Rechtsgrundlage: ohne geht es nicht – und die Eingriffstiefe zählt

Die Handreichung stellt klar: Für Verarbeitungen im KI-Kontext braucht es eine Rechtsgrundlage. Gleichzeitig gilt die Technologieneutralität der DSGVO: eine Verarbeitung „mit KI“ ist nicht automatisch anders zu bewerten als herkömmliche technische Verfahren.

Sie arbeitet im Behördenkontext mit dem Gedanken der „Eingriffstiefe“ und der Frage, wann ein schwerwiegender Eingriff vorliegt und ggf. eine spezifische Rechtsgrundlage nötig ist. Dabei nennt sie als Faktoren unter anderem, ob eine automatisierte Entscheidung im Sinne von Art. 22 DSGVO vorliegt oder ob sensible Daten bzw. besonders viele Daten verarbeitet werden, um neues personenrelevantes Wissen zu erzeugen.

Für Unternehmen ist die konkrete Auswahl der Rechtsgrundlage je nach Use Case zu prüfen. Der Punkt aus der Handreichung, den den Sie mitnehmen sollten, ist vor allem: Sie müssen die Rechtmäßigkeit Ihrer Verarbeitungsvorgänge sauber begründen können, und die tatsächlichen Risiken/Eingriffe hängen stark davon ab, wie Sie das System einsetzen und absichern.

Besondere Kategorien (Art. 9 DSGVO): Training ist nicht gleich Betrieb

Sobald sensible Daten im Spiel sind – etwa Gesundheitsdaten oder biometrische Daten – wird es deutlich anspruchsvoller: Art. 9 DSGVO enthält ein grundsätzliches Verbot mit eng begrenzten Ausnahmen.

Die Handreichung macht hier eine Differenzierung auf, die für die Praxis extrem wichtig ist: In der Entwicklungsphase leistungsfähiger Modelle sind riesige, unstrukturierte Datenmengen üblich, und es ist oft nicht praktikabel, besondere Kategorien vorab vollständig herauszufiltern. Um Betroffene zu schützen und Entwicklung dennoch zu ermöglichen, hält die Handreichung es für zulässig und geboten, zwischen zielgerichteter und nicht-zielgerichteter Verarbeitung zu unterscheiden. Zielgerichtet ist eine Verarbeitung, wenn sie darauf abzielt, die sensiblen Merkmale einer bestimmten Person zuordenbar auszuwerten; nicht-zielgerichtet ist sie, wenn sensible Daten nur verarbeitet werden, um allgemeine Muster zu lernen, ohne diese Eigenschaften einer Person zuzuordnen.

Damit diese Einordnung nicht nur Theorie bleibt, nennt die Handreichung Indizien und risikomindernde Maßnahmen, die für eine nicht-zielgerichtete Verarbeitung sprechen können: Zum Beispiel Bereinigung der Trainingsdaten um identifizierende Angaben, Deduplikation zur Vermeidung von Overfitting, Fine-Tuning mit dem Ziel, keine personenbezogenen Daten auszugeben, oder das meiden von Quellen, die besonders wahrscheinlich sensible Daten enthalten.

Ganz wichtig ist aber auch der zweite Teil der Aussage: Im Produktivbetrieb sind die Anforderungen des Art. 9 Abs. 2 DSGVO „vollumfänglich“ einzuhalten – insbesondere bei Eingaben und Ausgaben. Und sogar der Betrieb eines Modells kann eine Verarbeitung sensibler Daten darstellen, wenn besondere Kategorien im Modell abstrakt enthalten sind und reproduziert werden könnten; dann braucht es neben einer Rechtsgrundlage auch einen Ausnahmetatbestand nach Art. 9 Abs. 2 DSGVO.

Die Handreichung nennt außerdem Indizien, wie man im Betrieb eine nicht-zielgerichtete Verarbeitung sensibler Daten stützen kann – etwa systemweite Input-/Output-Filter, ein System-Prompt, der sensible Ausgaben verbietet, eine RAG-Architektur, die Antworten auf eine Vektordatenbank stützt statt auf „gelerntes Modellwissen“, und klare Richtlinien für Nutzer, die Extraktion untersagen und Meldewege definieren.

Datenminimierung und Speicherbegrenzung: nicht „wenig Daten“, sondern „notwendige Daten“

Die Handreichung formuliert sehr praxisnah: Große Datenmengen sind für die Entwicklung von LLMs häufig notwendig, und das ist nicht per se unvereinbar mit Datenminimierung. Datenminimierung heißt nicht zwingend „absolute Reduzierung“, sondern: Der Verantwortliche muss sicherstellen und dokumentieren, dass die Verarbeitung angemessen und auf das notwendige Maß beschränkt ist – und dass der Zweck nicht in zumutbarer Weise mit weniger personenbezogenen Daten erreichbar wäre. Die Erforderlichkeit ist dabei nicht für jedes einzelne Datum zu prüfen, sondern bezogen auf den Gesamtumfang der verwendeten Daten.

Als praktische Wege nennt die Handreichung, synthetische Daten zu erwägen, Trainings-/Testdaten zu anonymisieren oder zumindest zu pseudonymisieren (wobei auch diese Schritte wiederum eine Rechtsgrundlage brauchen) und in der Planungsphase darauf hinzuwirken, dass im Produktivbetrieb möglichst wenig personenbezogene Daten in Eingaben verarbeitet werden – zum Beispiel durch Eingabefilter oder standardisierte Prompts.

Besonders relevant für Unternehmen: Viele KI-Tools speichern Prompts und Ausgaben gerne „zur Qualitätsverbesserung“ oder „Analyse“. Die Handreichung ist hier klar: Eine Speicherung personenbezogener Prompts und Ausgaben zu Analysezwecken ist nur bei klarer Zweckbindung und angemessener Aufbewahrungsfrist zulässig. Wenn sie nicht erforderlich ist, empfiehlt sie standardisierte Löschroutinen, etwa nach Abschluss jeder Verwendung.

Menschliche Aufsicht und Art. 22 DSGVO: wann „KI unterstützt“ zu „KI entscheidet“ wird

KI kann Entscheidungsprozesse stark automatisieren. Die Handreichung erinnert daran, dass bei automatisierten Entscheidungen, die gegenüber Betroffenen rechtliche Wirkung entfalten oder ähnlich erheblich beeinträchtigen, Vorsicht geboten ist. Gleichzeitig macht sie deutlich: Wenn ein Mensch wirklich in den Prozess eingebunden ist, das Ergebnis eigenständig bewertet und nicht „maßgeblich geleitet“ wird, dann ist das Verbot des Art. 22 Abs. 1 DSGVO nicht einschlägig. Voraussetzung ist aber echte Entscheidungsbefugnis und passende Kompetenz.

Für Unternehmen ist das praktisch ein Governance-Thema: Sie brauchen Prozesse, in denen klar ist, wann KI nur vorbereitet und wann KI faktisch entscheidet und Sie müssen sicherstellen, dass der menschliche Entscheider nicht nur pro forma unterschreibt.

Datenschutz-Folgenabschätzung: früh dran sein und den ganzen Lebenszyklus anschauen

Die Handreichung betont bei der Datenschutz-Folgenabschätzung (DSFA) zwei Dinge, die im Alltag gerne schiefgehen: Erstens muss sie „vorab“ erfolgen, also vor Beginn der Verarbeitung. Zweitens sollte sie Trainings-, Test-, Implementierungs- und Nutzungsphase erfassen – nicht nur den Go-live. Außerdem soll der Datenschutzbeauftragte frühzeitig eingebunden werden, und je nach Fall kann auch eine Konsultation der betroffenen Öffentlichkeit relevant sein.

Wenn Sie KI im Unternehmen einführen, ist das ein guter Reality-Check: Die DSFA zwingt Sie, nicht nur auf das Tool zu schauen, sondern auf das Gesamtsystem, den Zweck, die Datenflüsse, die Risiken und die Maßnahmen.

Transparenz und Betroffenenrechte: KI ist kein „Transparenz-Freifahrtschein“

Transparenz ist in der DSGVO Grundprinzip (Art. 5 Abs. 1 lit. a) und wird durch Informationspflichten (Art. 13/14) und Auskunft (Art. 15) konkretisiert. Die Handreichung sagt gleichzeitig etwas, das viele überrascht: Eine allgemeine Pflicht, über den Einsatz von KI „als solchen“ zu informieren, lässt sich aus der DSGVO nicht herleiten. Informiert werden muss vor allem darüber, wer verarbeitet, zu welchem Zweck und auf welcher Rechtsgrundlage. Bei automatisierten Entscheidungen im Sinne von Art. 22 gibt es allerdings besondere Transparenzanforderungen, inklusive „aussagekräftiger Informationen über die involvierte Logik“ sowie Tragweite und angestrebte Auswirkungen.

Spannend wird es bei Art. 15 Abs. 1 lit. h) DSGVO: Die Handreichung greift die Auffassung des EuGH auf, dass Betroffene ein echtes Recht auf Erläuterung der Funktionsweise des Mechanismus der automatisierten Entscheidungsfindung und des Ergebnisses haben. Praktisch heißt das: Sie müssen in der Lage sein zu erklären, welche personenbezogenen Daten wie verwendet wurden.

Weil LLMs probabilistisch arbeiten, nennt die Handreichung sogar eine praktische Vorgehensweise für Auskunft: Es kann notwendig sein, das Modell auf Grundlage vorhandener Daten mehrfach mit variierenden Prompts nach der betroffenen Person zu fragen und die Ausgaben zu prüfen, ob sie personenbezogene Daten enthalten, die über die Eingabe hinausgehen – und dabei ist sicherzustellen, dass diese Eingaben nicht anderweitig (z. B. zum Training) verwendet werden.

Berichtigung und Löschung: Betroffenenrechte gelten auch für KI – aber die Umsetzung ist speziell

Die Handreichung ist hier sehr deutlich: Gegenstand von Berichtigung/Löschung können grundsätzlich alle personenbezogenen Daten sein – in Trainingsdaten, in Ein- und Ausgaben und im KI-Modell selbst. Deshalb sollten Verantwortliche im Vorhinein Abläufe festlegen, wie mit entsprechenden Anträgen umzugehen ist.

Bei der Löschung (Art. 17 DSGVO) wird es technisch besonders knifflig. Besteht ein Löschanspruch, muss die Löschung im Ergebnis dazu führen, dass die Daten irreversibel so unkenntlich gemacht werden, dass sie nicht bzw. nicht mit vertretbarem Aufwand weiterverarbeitet werden können. Als „sicherste Lösung“ nennt die Handreichung das regelmäßige Ersetzen des KI-Modells durch ein neues Modell, das ohne die zu löschenden Trainingsdaten trainiert wurde. Alternativ kommen Machine-Unlearning-Methoden in Betracht; außerdem sollen Daten auch aus Trainingsdaten für zukünftige Updates entfernt werden.

Gleichzeitig sagt die Handreichung: Ein- und Ausgabefilter können als Übergangslösung sinnvoll sein, gelten nach Auffassung der DSK aber an sich nicht als Löschung.

Und wenn Sie sich fragen „Was ist Machine Unlearning eigentlich in der Realität?“: Die Handreichung ordnet das ein als sehr neues Forschungsfeld. Methoden seien meist noch nicht effektiv bzw. ressourcenintensiv und könnten Einbußen bei der Genauigkeit mit sich bringen.

Datenrichtigkeit und Halluzinationen: die Pflicht bleibt bei Ihnen

Ein weiterer sehr praktischer Abschnitt der Handreichung dreht sich um Datenrichtigkeit (Art. 5 Abs. 1 lit. d) DSGVO). Personenbezogene Ausgaben müssen richtig sein, und die Richtigkeit ist unabhängig davon zu gewährleisten, ob jemand aktiv eine Berichtigung verlangt. Unrichtigkeit kann aus fehlerhaften oder veralteten Trainingsdaten entstehen oder aus Halluzinationen, also Ausgaben, die formal berechnet wurden, aber nicht inhaltlich durch Trainingsdaten gedeckt sind. Für den Grundsatz der Datenrichtigkeit ist es unerheblich, aus welchem dieser Gründe die Ausgabe unrichtig ist.

Sehr hilfreich ist der praktische Maßstab, den die Handreichung nennt: Ob personenbezogene Ausgabedaten „unrichtig“ sind, ist unter Berücksichtigung der Erwartungshaltung des Durchschnittsnutzers im konkreten Kontext zu ermitteln. Und es macht einen Unterschied, ob eine Ausgabe als Tatsache dargestellt wird oder ob sie durch einen deutlichen Hinweis als Ergebnis einer Wahrscheinlichkeitsberechnung gekennzeichnet wird, das vor weiterer Verwendung zu überprüfen ist. Ein solcher Hinweis kann im Einzelfall bereits eine „angemessene“ Abhilfemaßnahme sein.

Für Unternehmen heißt das ganz bodenständig: Wenn KI Texte erstellt, Empfehlungen gibt oder Inhalte zusammenfasst, brauchen Sie Leitplanken, damit niemand Halluzinationen als Fakten übernimmt.

Fairness und Bias: nicht nur ein Ethik-Thema, sondern Datenschutz-Grundsatz

Die Handreichung verankert Bias/Fairness im Datenschutz-Grundsatz von Treu und Glauben (Art. 5 Abs. 1 lit. a): Unfaire Verarbeitung kann vorliegen, wenn Betroffene ungerechtfertigt diskriminiert werden. Bei KI können Biases schwerwiegende Auswirkungen haben, weil Trainingsdaten gesellschaftliche Verzerrungen enthalten oder bestimmte Gruppen unterrepräsentiert sind.

Für die Praxis gibt die Handreichung zwei sehr handfeste Hebel mit:

Erstens kann man ein LLM auf Bias in den Ausgaben prüfen, indem man deckungsgleiche Anfragen stellt, die sich nur in einzelnen personenbezogenen Merkmalen unterscheiden (zum Beispiel ein Name, der Rückschlüsse auf Geschlecht oder Ethnie erlaubt) und beobachtet, ob die Ausgaben ohne sachlichen Grund unterschiedlich ausfallen. Wenn das passiert, sollte der Einsatz überdacht werden.

Zweitens kann man organisatorisch gegensteuern: Nutzer sollten über mögliche Verzerrungen informiert sein und wissen, wie sie mit verzerrten Ausgaben umgehen sollen, in dem sie zum Beispiel Ausgaben nicht weiterverwenden und Eingaben erneut ohne Personenbezug durchführen.

Rechenschaft, Monitoring und Dienstleister: KI ist nichts, was man einmal „abnimmt“ und dann vergisst

Ein Punkt, der für Unternehmen besonders relevant ist, steht in der Handreichung sehr klar: Die gesetzlichen Anforderungen müssen fortlaufend während des gesamten Betriebs eingehalten werden. Technische oder rechtliche Entwicklungen können Änderungen am System, am Modell oder an internen Regelwerken erforderlich machen. Deshalb ist fortlaufendes Monitoring „unabdingbar“, um Auswirkungen im Einsatz zu bewerten, neue Risiken festzustellen und Maßnahmen anzupassen.

Und jetzt zur oft heiklen Anbieterfrage. Wenn Sie ein Modell eines anderen Herstellers als Verantwortlicher einsetzt und dieses Modell personenbezogene Trainingsdaten memorisiert hat, müssen Sie im Rahmen der Rechenschaftspflicht darlegen, dass Sie für Ihre eigenen Verarbeitungen (auch der memorisierten Daten) eine Rechtsgrundlage haben. Gleichzeitig sagt die Handreichung ausdrücklich: Man kann nicht pauschal davon ausgehen, dass ein rechtswidrig entwickeltes KI-Modell nie rechtmäßig eingesetzt werden kann. Entscheidend ist, dass Sie die Rechtmäßigkeit Ihrer Verarbeitungen gewährleisten und nachweisen können und dass Sie sich in geeigneter Weise vergewissern, dass die Entwicklung rechtmäßig war. Dafür beschreibt sie eine abgestufte Nachforschungspflicht, deren Umfang vom konkreten Risiko für Betroffene abhängt.

Sie gibt sogar ein Beispiel, wann eine Nachweispflicht bei einfachen Verarbeitungen (wie Zusammenfassen von Eingabetexten) erfüllt sein kann: etwa wenn der Hersteller die DSGVO-Konformität des Trainings vertraglich zusichert und/oder entsprechend darstellt und keine gerichtlichen oder behördlichen Entscheidungen die DSGVO-Widrigkeit festgestellt haben.

Ganz pragmatisch – und für viele Unternehmen ein Muss – ist auch der Abschnitt zum Training mit Ihren Eingaben. Gerade bei AI-as-a-Service behalten sich manche Anbieter vor, Eingaben und Ausgaben der Benutzer für weiteres Training zu verwenden. Die Handreichung sagt: Aufgrund der Möglichkeit der Memorisierung und der potenziell sensiblen bzw. personenbezogenen Inhalte, die Mitarbeiter eingeben (interne Dokumente, Bewerbungsunterlagen, Gesundheitsnachweise usw.), muss vertraglich ausgeschlossen werden, dass der Anbieter Ein- und Ausgaben für weiteres Training nutzt.

Und noch ein Aspekt, der im Einkauf oft zu kurz kommt: LLMs werden häufig in Drittländern oder durch Unternehmen aus Drittländern gehostet; das birgt Risiken staatlicher Zugriffe oder sogar gerichtlicher Untersagungen von Löschungen. Bei Drittlandübermittlungen sind die Voraussetzungen der DSGVO einzuhalten.

Ein kleiner, alltagstauglicher Fahrplan

Wenn Sie das alles auf einen „Was tun wir jetzt konkret?“-Weg runterbrechen, läuft es in der Logik der Handreichung meistens so: Sie kartieren Daten und Verarbeitungsvorgänge über den Lebenszyklus, klären Rollen und Verträge, definieren Zwecke und Rechtsgrundlagen, bauen technische und organisatorische Schutzmaßnahmen ein (Filter, System-Prompts, RAG, Zugriffskonzepte, Löschroutinen), regeln Transparenz und Betroffenenprozesse, und betreiben das Ganze mit Monitoring und Schulungen weiter, statt es einmal abzuhaken.

Fazit

Wenn Sie KI im Unternehmen einsetzen wollen, lohnt es sich, das Thema Datenschutz nicht als „Extra-Schleife“ zu sehen, sondern als Teil des Projekts von Anfang an. Die Handreichung zeigt ziemlich klar: Bei LLMs entsteht Personenbezug nicht nur durch offensichtliche Eingaben wie Namen oder Kundendaten. Er kann in Trainingsdaten stecken, durch Rückschlüsse entstehen, in Prompts und Ausgaben auftauchen und je nach System und Einflussmöglichkeiten sogar das Modell selbst betreffen. Genau deshalb bringt es wenig, Datenschutz nur auf „Wir geben nichts Persönliches ein“ zu reduzieren.

Für die Praxis bedeutet das: Sie brauchen Klarheit über Ihren konkreten Use Case und Ihre Datenflüsse, Sie müssen Verantwortlichkeiten und Verträge sauber einordnen und Sie sollten technische und organisatorische Schutzmaßnahmen so bauen, dass Betroffenenrechte, Löschung, Transparenz und Datenrichtigkeit auch wirklich funktionieren. Halluzinationen und Bias sind dabei keine Randthemen, sondern berühren direkt Grundprinzipien wie Richtigkeit und Fairness.

Und ganz ehrlich: Der wichtigste Gedanke am Ende ist wahrscheinlich, dass KI kein System ist, das man einmal freigibt und dann vergisst. Die Handreichung legt viel Wert auf laufendes Monitoring, weil Modelle, Einsatzkontexte und Risiken sich ändern. Wenn Sie das als festen Bestandteil Ihrer Governance akzeptiern, können Sie KI sinnvoll nutzen und behalten gleichzeitig den Datenschutz so im Griff, dass Sie ihn gegenüber Geschäftsführung, Mitarbeitern und Betroffenen auch überzeugend erklären können.