DSGVO-konforme Softwareentwicklung und KI-Tools: Worauf es bei Entwicklung und Einsatz ankommt

Ich bin Softwareentwickler und kein Rechtsanwalt. Der Beitrag beschreibt die technische Umsetzung und ersetzt keine Rechtsberatung.

Seit dem Geltungsbeginn der DSGVO im Mai 2018 hat sich in der Softwareentwicklung grundlegend etwas verändert: Datenschutz ist keine nachträgliche Überlegung mehr, sondern muss von Anfang an Teil der Architektur sein. Privacy by Design und Privacy by Default, zwei in der Verordnung verankerte Prinzipien, klingen abstrakt, haben aber sehr konkrete Auswirkungen darauf, wie Software gebaut wird. Und seit ChatGPT, Microsoft Copilot, Google Gemini und Claude in jedem Büro angekommen sind, stellt sich dieselbe Frage noch einmal neu: Was passiert mit personenbezogenen Daten, die Mitarbeiter in ein KI-Werkzeug eintippen? In meiner Praxis erlebe ich regelmäßig, dass Unternehmen die DSGVO entweder als bürokratisches Hindernis behandeln oder sich mit rechtlich fragwürdigen Lösungen behelfen. Beides ist vermeidbar.

Wie sich DSGVO-konforme Software entwickeln lässt, beschreibe ich hier aus Sicht des Entwicklers, von den Anforderungen und Grundsätzen über Protokolle, Löschfristen, Betroffenenrechte und Testdaten bis zu Auftragsverarbeitung und Hosting in der EU. Im zweiten Teil geht es darum, wie Unternehmen KI-Tools einsetzen können, ohne personenbezogene Daten aus der Hand zu geben.

Welche Anforderungen die DSGVO an Software stellt

Die DSGVO regelt nicht Software als Produkt, sondern die Verarbeitung personenbezogener Daten. Für die Entwicklung lassen sich die meisten Anforderungen trotzdem auf wenige Artikel zurückführen. Art. 5 nennt die Grundsätze, also Rechtmäßigkeit, Verarbeitung nach Treu und Glauben und Transparenz, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung sowie Integrität und Vertraulichkeit, und verlangt, dass der Verantwortliche ihre Einhaltung nachweisen kann. Art. 25 fordert, diese Grundsätze schon in der Technik umzusetzen, Art. 32 eine dem Risiko angemessene Sicherheit, und die Artikel 12 bis 22 regeln die Rechte der betroffenen Personen, etwa auf Auskunft, Berichtigung und Löschung. Dazu kommen Art. 28 für Dienstleister, die Daten im Auftrag verarbeiten, Art. 30 für das Verzeichnis der Verarbeitungstätigkeiten, Art. 33 für die Meldung von Datenpannen und Art. 35 für die Datenschutz-Folgenabschätzung. Was daraus für Datenmodell, Zugriffsrechte, Protokolle und Löschroutinen folgt, zeigen die nächsten Abschnitte.

Was Privacy by Design in der Praxis bedeutet

Der Grundsatz ist einfach: Datenschutz wird in die Systemarchitektur eingebaut, nicht im Nachhinein aufgesetzt. Konkret heißt das, dass nur die Daten erhoben werden, die für den jeweiligen Zweck tatsächlich nötig sind. Personenbezogene Daten werden so früh wie möglich anonymisiert oder pseudonymisiert. Zugriffsrechte folgen dem Least-Privilege-Prinzip, jeder Nutzer und jede Komponente erhält nur die Rechte, die für die eigene Funktion notwendig sind. Und Daten werden nur so lange gespeichert, wie es der Zweck erfordert, mit automatisierten Löschroutinen statt guter Vorsätze.

Rechtlich richtet sich Art. 25 DSGVO an den Verantwortlichen, also an das Unternehmen, das die Software einsetzt, und nicht an den Hersteller. Der Verantwortliche muss dabei den Stand der Technik, die Kosten der Umsetzung, Art, Umfang und Zweck der Verarbeitung sowie die Risiken für die betroffenen Personen berücksichtigen. Die Hersteller von Produkten, Diensten und Anwendungen sollen nach Erwägungsgrund 78 ermutigt werden, den Datenschutz schon bei Entwicklung und Gestaltung zu berücksichtigen. In der Praxis landet die Aufgabe trotzdem beim Entwickler, denn ein Unternehmen kann Datenschutz durch Technikgestaltung nur umsetzen, wenn die Software es zulässt. Für Privacy by Default heißt das, dass die Voreinstellungen den sparsamsten Zustand abbilden. Ein neues Benutzerkonto sieht zunächst nur, was es für seine Aufgabe braucht, optionale Angaben bleiben leer, und keine Daten werden für einen unbestimmten Personenkreis sichtbar, solange das niemand bewusst einstellt.

Wie Art. 25 im Einzelnen zu verstehen ist, hat der Europäische Datenschutzausschuss in seinen Leitlinien 4/2019 zu Artikel 25 beschrieben, deren endgültige Fassung (Version 2.0) er am 20. Oktober 2020 angenommen hat. Sie gehen die Grundsätze aus Art. 5 einzeln durch, von Transparenz und Rechtmäßigkeit über Datenminimierung und Speicherbegrenzung bis zur Rechenschaftspflicht, und lassen sich gut als Prüfliste für die eigene Architektur nutzen. Verstöße gegen die Pflichten aus Art. 25 können nach Art. 83 Abs. 4 DSGVO mit einer Geldbuße von bis zu 10 Millionen Euro geahndet werden, bei Unternehmen auch mit bis zu 2 Prozent des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres, je nachdem, welcher Betrag höher ist.

Besonders kritische Daten

Nicht alle Daten sind gleich riskant. Öffentlich verfügbare Produktbeschreibungen oder allgemeine Textentwürfe sind unkritisch. Heikel wird es bei Kundennamen, E-Mail-Adressen und Telefonnummern, bei Vertragsdetails und Angebotsinformationen, bei Personaldaten von Mitarbeitern und erst recht bei Gesundheitsdaten. Medizinische Daten gehören zur besonderen Kategorie nach Artikel 9 DSGVO und erfordern ein erhöhtes Schutzniveau. In meiner Arbeit für Facharztpraxen und Unternehmen im Sozialbereich habe ich gelernt, wie hoch die Anforderungen in diesen Branchen sind: Sie betreffen nicht nur die Datenbank, sondern den gesamten Verarbeitungsprozess von der Übertragung über die Speicherung und Zugriffsverwaltung bis zum Löschkonzept. Eine Arztpraxis, die Patientendaten in einer schlecht gesicherten Datenbank speichert oder unverschlüsselt über das Netzwerk überträgt, riskiert nicht nur Bußgelder, sondern das Vertrauen ihrer Patienten.

Technische und organisatorische Maßnahmen nach Art. 32 DSGVO

Für die Sicherheit der Verarbeitung verlangt Art. 32 DSGVO technische und organisatorische Maßnahmen, kurz TOM, die dem Risiko angemessen sind. Die Verordnung nennt als Beispiele die Pseudonymisierung und Verschlüsselung, die dauerhafte Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme, die rasche Wiederherstellung nach einem Zwischenfall und ein Verfahren, mit dem die Wirksamkeit der Maßnahmen regelmäßig überprüft wird. Die Pflicht trifft Verantwortliche und Auftragsverarbeiter gleichermaßen. Was davon im Code steckt und was im Betrieb geregelt wird, sollte vor dem ersten Release feststehen.

Verschlüsselung aller gespeicherten personenbezogenen Daten und TLS für jede Übertragung sind die Basis. Empfehlungen zu kryptographischen Verfahren und Schlüssellängen gibt das BSI in der Technischen Richtlinie TR-02102, zum Einsatz von TLS in deren Teil 2. Ich halte sie für einen guten Maßstab, wenn es um den Stand der Technik nach Art. 32 geht. Dazu kommen eine Protokollierung der Zugriffe auf sensible Daten, automatisierte Löschroutinen auf Basis definierter Aufbewahrungsfristen, Zwei-Faktor-Authentifizierung für Systeme mit Zugriff auf sensible Daten und regelmäßige Datensicherungen mit definierten Wiederherstellungszeiten. Keine dieser Maßnahmen ist exotisch. Ihr Wert liegt darin, dass sie von Anfang an eingeplant werden statt nach dem ersten Vorfall.

Einige dieser Maßnahmen zeigt die Software für Dienstplan und Zeiterfassung, die ich für eine Praxis in Freiburg entwickelt habe, etwa ein Änderungsprotokoll mit hinterlegten Aufbewahrungsfristen, die Zwei-Faktor-Anmeldung und die tägliche Datensicherung. Jede Installation hat eine eigene Datenbank, Server und Ziel der Sicherung werden bei der Einrichtung festgelegt.

Protokollierung: nachvollziehbar, aber sparsam

Protokolle sind für den Datenschutz zweischneidig. Sie werden gebraucht, weil der Verantwortliche nach der Rechenschaftspflicht in Art. 5 Abs. 2 DSGVO nachweisen muss, dass er die Grundsätze der Verordnung einhält, und weil eine Datenpanne nach Art. 33 DSGVO unverzüglich und möglichst binnen 72 Stunden, nachdem sie bekannt geworden ist, der Aufsichtsbehörde zu melden ist, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Betroffenen. Ohne Protokoll lässt sich in dieser Zeit kaum sagen, wer wann auf welche Daten zugegriffen hat. Gleichzeitig enthalten Protokolle selbst personenbezogene Daten, etwa Benutzerkennungen und IP-Adressen, im ungünstigsten Fall sogar ganze Datensätze, die bei der Fehlersuche mitgeschrieben wurden.

Ich empfehle deshalb, in technischen Protokollen, etwa Zugriffs- und Fehlerprotokollen, festzuhalten, wer wann welche Aktion an welchem Datensatz ausgeführt hat, aber nicht den Inhalt selbst. Passwörter, Gesundheitsangaben und vollständige Anfragen gehören nicht hinein. Bricht in der Dienstplan-Software ein Bedienschritt mit einer Fehlermeldung ab, hält sie Seite, Vorgang, angezeigte Meldung und Gerätetyp fest, ohne Formularinhalte und ohne Standort. Sie behält höchstens die neuesten 1.000 Einträge der letzten 90 Tage und löscht Älteres. Ein fachlicher Änderungsverlauf, etwa bei Arbeitszeiten oder Buchungen, ist etwas anderes. Dort soll erkennbar bleiben, was vorher eingetragen war. Für Buchungen und andere steuerlich relevante Aufzeichnungen schreibt § 146 Abs. 4 AO das ausdrücklich vor. Ein solcher Verlauf gehört zu den Daten selbst und folgt deren Zugriffsrechten und Löschfristen. Protokolle brauchen eigene Zugriffsrechte und eine eigene Aufbewahrungsfrist, nach der sie automatisch gelöscht werden. Verarbeitet die Software Daten von Beschäftigten, kommt eine arbeitsrechtliche Frage hinzu. Gibt es einen Betriebsrat, hat er nach § 87 Abs. 1 Nr. 6 BetrVG bei der Einführung und Anwendung technischer Einrichtungen mitzubestimmen, die dazu bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen. Dafür genügt nach der Rechtsprechung des Bundesarbeitsgerichts, dass ein System Verhaltens- oder Leistungsdaten einzelner Beschäftigter erhebt und aufzeichnet, auch wenn der Arbeitgeber sie gar nicht auswerten will. Das sollte früh im Projekt geklärt sein und nicht erst kurz vor dem Start.

Ein Löschkonzept gehört in die Software

Nach meiner Erfahrung können viele Anwendungen Daten anlegen, ändern und anzeigen, aber nicht sauber löschen. Die DSGVO verlangt dagegen, dass Daten gelöscht oder anonymisiert werden, sobald sie für ihren Zweck nicht mehr gebraucht werden. Nach dem Grundsatz der Speicherbegrenzung in Art. 5 Abs. 1 lit. e DSGVO dürfen personenbezogene Daten nur so lange in einer Form gespeichert sein, die die Identifizierung der Personen erlaubt, wie es der Zweck erfordert, und nach Art. 17 DSGVO muss der Verantwortliche sie unverzüglich löschen, wenn etwa der Zweck entfallen ist oder eine Einwilligung widerrufen wurde und keine andere Rechtsgrundlage besteht. Zugleich gibt es Pflichten, Unterlagen aufzubewahren, im Steuer- und Handelsrecht etwa nach § 147 AO und § 257 HGB. Für diesen Fall sieht Art. 17 Abs. 3 lit. b eine Ausnahme vor, solange die Aufbewahrung zur Erfüllung einer rechtlichen Verpflichtung erforderlich ist.

Technisch heißt das, dass jede Datenart eine Löschregel bekommt, mit Zweck, Frist und Auslöser, etwa dem Vertragsende oder dem letzten Kontakt. Daten, die nur noch aufbewahrt werden müssen, werden für den laufenden Betrieb gesperrt, sind also nur noch für berechtigte Personen zugänglich, und werden gelöscht oder anonymisiert, sobald die Frist abgelaufen ist. Datensicherungen gehören in das Konzept, weil gelöschte Datensätze dort noch eine Weile weiterleben. Ein klarer Rotationsplan legt fest, wann auch die letzte Sicherung mit diesen Daten überschrieben ist. Und Löschen sollte wirklich Löschen bedeuten, nicht nur ein Kennzeichen „gelöscht“, das jeder Administrator wieder zurücknehmen kann.

Wer ein Löschkonzept aufbaut, stößt schnell auf die DIN 66398, die Leitlinie zur Entwicklung eines Löschkonzepts mit Ableitung von Löschfristen für personenbezogene Daten. Sie ist aber zurückgezogen und durch die DIN EN ISO/IEC 27555:2025-09 ersetzt, die deutsche Fassung der internationalen Leitlinien zur Löschung personenbezogener Daten. Nach Angaben des Editors der DIN 66398 beschreibt die neue Norm dieselbe Vorgehensweise, mit wenigen Unterschieden im Detail. Der Europäische Datenschutzausschuss schreibt in den oben erwähnten Leitlinien zu Artikel 25 (Randnummer 53), der Verantwortliche solle systematische Verfahren für die Löschung oder Anonymisierung in die Verarbeitung einbinden. Ein Konzept, das nur auf dem Papier steht, genügt also nicht. Sinnvoll ist außerdem, dass die Software festhält, wann welche Datenart nach welcher Regel gelöscht wurde, ohne die gelöschten Inhalte selbst zu protokollieren, und dass sie nach dem Einspielen einer älteren Sicherung die seither fälligen Löschungen erneut ausführt.

Wie teuer es werden kann, wenn ein IT-System nicht rechtzeitig löschen kann, zeigt das Verfahren gegen die Deutsche Wohnen SE. Nach der Pressemitteilung des Landgerichts Berlin I vom 9. Juni 2026 hatte die Berliner Beauftragte für Datenschutz und Informationsfreiheit im Oktober 2019 ein Bußgeld von rund 14,5 Millionen Euro verhängt. Das Gericht hielt eine Geldbuße von 900.000 Euro für angemessen. Es sah als erwiesen an, dass das Unternehmen nach dem Geltungsbeginn der DSGVO nicht rechtzeitig die erforderlichen Änderungen in seinem IT-System eingeführt hatte, um die fristgemäße Löschung der Daten ehemaliger Mieterinnen und Mieter zu gewährleisten, und wertete das als Verstoß gegen die Grundsätze der Datenminimierung und der Speicherbegrenzung. Rechtskräftig war das Urteil zum Zeitpunkt der Pressemitteilung noch nicht. Bei Altsystemen, die keine Löschung vorsehen, lohnt deshalb früh die Frage, ob sich eine Löschfunktion nachrüsten lässt oder ob eine Neuentwicklung der bessere Weg ist.

Betroffenenrechte in der Software umsetzen

Eine Software mit personenbezogenen Daten sollte den Verantwortlichen dabei unterstützen, die Rechte der betroffenen Personen zu erfüllen. Nach Art. 12 Abs. 3 DSGVO muss er der Person auf einen Antrag hin unverzüglich, spätestens aber innerhalb eines Monats mitteilen, welche Maßnahmen er ergriffen hat. Die Frist kann um zwei weitere Monate verlängert werden, wenn das wegen der Komplexität und der Zahl der Anträge erforderlich ist. Wer Auskunft, Berichtigung oder Löschung jedes Mal von Hand aus mehreren Tabellen zusammensucht, kommt da schnell in Bedrängnis. Diese Funktionen gehören deshalb von Anfang an in die Planung.

Für das Auskunftsrecht nach Art. 15 DSGVO braucht die Software einen Weg, die Daten zu einer Person zusammenzustellen und als Kopie herauszugeben, bei einem elektronischen Antrag in einem gängigen elektronischen Format. Dazu kommen die Angaben, die Art. 15 Abs. 1 verlangt, etwa Zwecke, Empfänger und geplante Speicherdauer. Die Berichtigung nach Art. 16 ist meist einfach umzusetzen, anspruchsvoller ist die Einschränkung der Verarbeitung nach Art. 18. Technisch ähnelt sie dem Sperren, das ich beim Löschkonzept beschrieben habe. Die Daten bleiben gespeichert, dürfen aber nur noch in eng begrenzten Fällen verarbeitet werden, etwa mit Einwilligung der Person oder zur Geltendmachung von Rechtsansprüchen. Das Recht auf Datenübertragbarkeit nach Art. 20 betrifft Daten, die die Person selbst bereitgestellt hat, wenn die Verarbeitung auf einer Einwilligung oder einem Vertrag beruht und automatisiert erfolgt. Für sie muss ein Export in einem strukturierten, gängigen und maschinenlesbaren Format möglich sein, etwa als CSV oder JSON. Für vernetzte Produkte kommen die Zugangsrechte des EU Data Act hinzu, die nach Angaben der Bundesnetzagentur für nicht personenbezogene Daten ebenso gelten wie für personenbezogene.

In der Software für Dienstplan und Zeiterfassung habe ich eine Datenauskunft nach Art. 15 DSGVO als Download umgesetzt. Jede Person lädt ihre gespeicherten Daten per Klick als maschinenlesbare Datei herunter, darunter Stammdaten, Arbeitszeiten, Abwesenheiten, Schichten und Anträge. IBAN, Steuer-ID und Sozialversicherungsnummer stehen nicht in der Datei, sie sind auf schriftliche Anfrage erhältlich. Welche Angaben in einen solchen Export gehören und welche besser getrennt herausgegeben werden, legen Sie am besten mit Ihrem Datenschutzbeauftragten fest, bevor die Funktion gebaut wird. Eine Download-Funktion nimmt dem Verantwortlichen auch nicht die Prüfung ab, ob eine Auskunft im Einzelfall weitere Angaben braucht.

Beruht eine Verarbeitung auf einer Einwilligung, muss der Verantwortliche nach Art. 7 DSGVO nachweisen können, dass die Person eingewilligt hat, und der Widerruf muss so einfach sein wie die Erteilung. Für die Software bedeutet das, Zeitpunkt und Inhalt jeder Einwilligung festzuhalten und den Widerruf an derselben Stelle anzubieten, an der die Einwilligung erteilt wird. Wie Erteilung und Widerruf an einer Stelle aussehen können, zeigt die Arbeitszeiterfassung meiner Dienstplan-Software. Mitarbeitende erteilen und widerrufen dort ihre Einwilligung in die zuschaltbare Standorterfassung beim Stempeln auf der Seite „Datenschutz“, auf der sie auch ihre Daten herunterladen. Die Erfassung gilt nur für Personen, die eingewilligt haben, gestempelt wird auch ohne Einwilligung, und ein Widerruf löscht die gespeicherten Standortdaten.

Echte Kundendaten gehören nicht in die Testumgebung

Ein Punkt, der in Projekten gern untergeht, sind Testdaten. Es ist bequem, für die Fehlersuche oder einen Lasttest eine Kopie der Produktivdatenbank zu ziehen. Damit landen echte personenbezogene Daten auf Entwicklerrechnern, in Testsystemen mit schwächeren Zugriffsrechten und manchmal in Fehlerberichten oder Screenshots. Rechtlich stellt sich dann die Frage, ob diese Weiterverarbeitung nach Art. 6 Abs. 4 DSGVO mit dem Zweck vereinbar ist, für den die Daten ursprünglich erhoben wurden. Das muss der Verantwortliche im Einzelfall prüfen und begründen. Einfacher ist es, gar nicht erst in diese Lage zu kommen.

Ich empfehle synthetische Testdaten, die realistisch aussehen, aber zu keiner echten Person gehören, oder Daten, die vor der Übergabe an die Entwicklung anonymisiert werden. Das entspricht der Kurzposition des Bundesbeauftragten für den Datenschutz und die Informationsfreiheit zu personenbezogenen Daten bei Softwareentwicklung und Tests. Danach sind Entwicklung und Tests in der Regel eigenständige Verarbeitungen, für die alle Anforderungen der DSGVO gelten, sobald dabei personenbezogene Daten verarbeitet werden. Zuerst ist zu prüfen, ob anonyme Daten genügen, dann, ob pseudonymisierte Daten reichen, und erst zuletzt, ob Echtdaten unbedingt erforderlich sind. Das bloße Entfernen oder Ersetzen von Namen reicht für eine Anonymisierung nach der Kurzposition grundsätzlich nicht, weil auch Kombinationen anderer Merkmale eine Person erkennbar machen können. Nur wirklich anonyme Daten fallen nach Erwägungsgrund 26 nicht mehr unter die DSGVO. Pseudonymisierte Daten bleiben personenbezogen, solange sich die Personen mit zusätzlichen Informationen wieder zuordnen lassen. Lässt sich ein Fehler nur mit echten Daten nachstellen, gehört die Analyse in eine Umgebung mit denselben Zugriffsrechten, Protokollen und Löschregeln wie das Produktivsystem und nicht auf einen Entwicklerrechner. Das gilt für interne Entwicklungsabteilungen genauso wie für externe Dienstleister, und wer als Externer dafür auf die Daten zugreift, braucht einen Auftragsverarbeitungsvertrag.

Software für Forschung und Entwicklung (F&E) datenschutzgerecht entwickeln

Software für Forschung und Entwicklung verarbeitet oft mehr personenbezogene Daten, als es auf den ersten Blick scheint: Messreihen mit Probanden, Befragungen, Sensordaten aus Feldtests, Nutzungsdaten aus einer Pilotphase oder Datensätze, mit denen ein KI-Modell trainiert wird. Die DSGVO hat für die Forschung eigene Regeln und fasst den Begriff weit. Nach Erwägungsgrund 159 soll die Verarbeitung zu wissenschaftlichen Forschungszwecken weit ausgelegt werden und etwa die technologische Entwicklung und Demonstration, die angewandte Forschung und die privat finanzierte Forschung einschließen. Ob ein konkretes Entwicklungsprojekt darunter fällt, ist eine Rechtsfrage, die der Verantwortliche im Einzelfall mit seinem Datenschutzbeauftragten klären sollte.

Fällt ein Projekt darunter, gelten einige Erleichterungen. Eine Weiterverarbeitung für wissenschaftliche Forschungszwecke gilt nach Art. 5 Abs. 1 lit. b DSGVO nicht als unvereinbar mit dem ursprünglichen Zweck, und nach Art. 5 Abs. 1 lit. e dürfen solche Daten länger gespeichert werden. Beides steht aber unter dem Vorbehalt von Art. 89 Abs. 1 DSGVO. Danach braucht die Verarbeitung geeignete Garantien für die Rechte der Betroffenen, vor allem technische und organisatorische Maßnahmen, mit denen die Datenminimierung sichergestellt wird. Die Pseudonymisierung nennt die Vorschrift ausdrücklich als mögliche Maßnahme, und lässt sich der Zweck auch ohne Identifizierung der Personen erreichen, ist er auf diese Weise zu erfüllen. In Deutschland regelt § 27 BDSG zusätzlich die Verarbeitung besonderer Kategorien wie Gesundheitsdaten zu Forschungszwecken. Er verlangt unter anderem, diese Daten zu anonymisieren, sobald der Forschungszweck es erlaubt, und bis dahin die Merkmale, über die sich Angaben einer Person zuordnen lassen, gesondert zu speichern. Unter engen Voraussetzungen erlaubt er auch, die Rechte auf Auskunft, Berichtigung, Einschränkung und Widerspruch zu beschränken. Die Funktionen dafür gehören trotzdem in die Software, denn ob eine Beschränkung greift, entscheidet sich im Einzelfall.

Für die Software heißt das vor allem, Identität und Forschungsdaten zu trennen. Pseudonymisierung bedeutet nach Art. 4 Nr. 5 DSGVO, dass sich die Daten ohne zusätzliche Informationen keiner bestimmten Person mehr zuordnen lassen und diese zusätzlichen Informationen gesondert aufbewahrt und durch technische und organisatorische Maßnahmen geschützt werden. Ich empfehle, Namen und Kontaktdaten in einer eigenen Datenbank oder zumindest in eigenen Tabellen mit eigenen Zugriffsrechten zu führen und die Mess- oder Befragungsdaten nur mit einem Pseudonym zu speichern. Als Pseudonym eignet sich eine zufällig erzeugte Kennung, keine fortlaufende Nummer und kein Hashwert aus dem Namen, denn der lässt sich durch Ausprobieren bekannter Namen zurückrechnen. Auf die Zuordnungstabelle sollte nur eine kleine, benannte Gruppe zugreifen dürfen, und jeder Zugriff gehört ins Protokoll. Pseudonymisierte Daten bleiben dabei personenbezogen, wie oben bei den Testdaten beschrieben, und für eine Anonymisierung genügt es nicht, Namen zu entfernen. Bei kleinen Stichproben oder seltenen Merkmalen lässt sich eine Person oft schon über die Kombination aus Alter, Wohnort und Zeitpunkt erkennen. Exporte für Auswertungen und Veröffentlichungen sollten deshalb nur die Felder enthalten, die die Auswertung braucht, und wo möglich gröbere Angaben, etwa Altersgruppen statt Geburtsdatum.

Für Entwicklung und Tests der F&E-Software selbst gilt dasselbe wie bei jeder anderen Anwendung. Echte Probandendaten gehören in die Umgebung, in der geforscht wird, nicht auf Entwicklerrechner. Für Tests reichen in aller Regel synthetische Datensätze, die Struktur und Wertebereiche der echten Daten nachbilden. Werden mit den Forschungsdaten KI-Modelle trainiert, kommt eine weitere Frage hinzu. Nach der Stellungnahme 28/2024 des Europäischen Datenschutzausschusses vom 18. Dezember 2024 ist im Einzelfall zu prüfen, ob ein solches Modell anonym ist. Das setzt voraus, dass es sehr unwahrscheinlich ist, Personen aus den Trainingsdaten zu identifizieren oder ihre Daten über Abfragen aus dem Modell herauszuholen.

Zur Projektdokumentation gehören aus Sicht des Datenschutzes einige Unterlagen, die am besten zusammen mit der Software entstehen: der Eintrag im Verzeichnis der Verarbeitungstätigkeiten nach Art. 30 DSGVO, eine Beschreibung der Garantien nach Art. 89 Abs. 1, also welche Daten pseudonymisiert werden, wer die Zuordnung herstellen darf und wann anonymisiert oder gelöscht wird, und gegebenenfalls die Datenschutz-Folgenabschätzung nach Art. 35 DSGVO, die bei einer umfangreichen Verarbeitung besonderer Kategorien wie Gesundheitsdaten ausdrücklich vorgeschrieben ist. Dazu passt eine technische Beschreibung des Datenflusses: Woher kommen die Daten, in welchen Systemen liegen sie, und wer exportiert was wohin. Weil Art. 25 DSGVO den Datenschutz durch Technikgestaltung auch für Forschungsprojekte verlangt, sind diese Punkte Anforderungen für den Anfang des Projekts und keine Formalität für das Ende.

Der Auftragsverarbeitungsvertrag, den viele vergessen

Wer als Softwareentwickler im Auftrag eines Unternehmens personenbezogene Daten verarbeitet, etwa weil er die Anwendung betreibt oder Daten migriert, ist Auftragsverarbeiter. Nach Auffassung der Datenschutzkonferenz gilt das auch für Wartung und Fernwartung, also für Fehleranalysen und Supportarbeiten in den Systemen des Auftraggebers, sobald dabei ein Zugriff auf personenbezogene Daten nötig oder auch nur möglich ist (DSK-Kurzpapier Nr. 13). Das erfordert einen Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO zwischen Auftraggeber und Entwickler. Er ist schriftlich abzufassen, ein elektronisches Format genügt. In der Praxis fehlt dieses Dokument leider noch immer häufig. Ich weise meine Kunden proaktiv auf diese Anforderung hin und stelle entsprechende Vertragsunterlagen zur Verfügung.

Was mindestens im Vertrag stehen muss, regelt Art. 28 Abs. 3. Dazu gehören Gegenstand, Dauer, Art und Zweck der Verarbeitung, die Art der Daten und die Kategorien betroffener Personen. Der Auftragsverarbeiter arbeitet nur auf dokumentierte Weisung, verpflichtet die beteiligten Personen zur Vertraulichkeit, trifft die Maßnahmen nach Art. 32, unterstützt bei Anfragen von Betroffenen und gibt die Daten nach Ende des Auftrags zurück oder löscht sie. Weitere Auftragsverarbeiter wie einen Hoster oder einen KI-Dienst darf er nur mit Genehmigung des Auftraggebers einbinden. Auch ein KI-Anbieter, dessen Dienst personenbezogene Daten verarbeitet, darf sie ohne AVV nicht bekommen.

Hosting in der EU und Übermittlungen in Drittländer

Wo eine Anwendung läuft, ist keine Formalie. Personenbezogene Daten dürfen nach Art. 44 DSGVO nur dann in ein Land außerhalb der EU und des EWR übermittelt werden, wenn die Bedingungen des fünften Kapitels der Verordnung erfüllt sind, in der Regel also ein Angemessenheitsbeschluss der EU-Kommission nach Art. 45 vorliegt oder geeignete Garantien nach Art. 46 bestehen, etwa die Standarddatenschutzklauseln der Kommission. Für die USA gilt seit dem 10. Juli 2023 ein Angemessenheitsbeschluss zum EU-US Data Privacy Framework, allerdings nur für Unternehmen, die daran teilnehmen. Ob er auf Dauer hält, ist offen. Die beiden Vorgänger, Safe Harbour und Privacy Shield, hat der Europäische Gerichtshof 2015 und 2020 für ungültig erklärt.

Ein Hosting in der EU vereinfacht vieles, löst aber nicht alles. Sehen Sie deshalb bei jedem Dienst nach, wo die Daten tatsächlich verarbeitet werden, und zwar nicht nur beim Server, sondern auch bei Datensicherung, E-Mail-Versand, Fehlerüberwachung und Support. Ein Rechenzentrum in Frankfurt hilft wenig, wenn die Fehlerberichte mit Kundendaten an einen Dienst in den USA gehen. Auch bei einem Anbieter mit Rechenzentrum in der EU lohnt der Blick darauf, wo der Konzern seinen Sitz hat und welchem Recht er unterliegt.

Datenschutz im Entwicklungsalltag und eine Checkliste für das erste Release

Damit diese Anforderungen nicht erst kurz vor dem Start auffallen, gehören sie in den normalen Ablauf eines Projekts. Halten Sie bei jeder Anforderung, die personenbezogene Daten berührt, fest, welche Daten sie braucht, zu welchem Zweck und wie lange, und nehmen Sie den Datenschutz in die Abnahmekriterien auf, so wie Tests und Dokumentation. Im Code-Review verdienen neue Datenfelder, Protokollausgaben und Aufrufe externer Dienste besondere Aufmerksamkeit, denn dort entstehen leicht unbeabsichtigte Datenflüsse. Auch die eigene Werkzeugkette verarbeitet oft personenbezogene Daten, etwa in Tickets mit Screenshots, in den Protokollen der Build-Pipeline oder in der Fehlerüberwachung. Wer Software als Produkt am Markt anbietet, muss außerdem den Cyber Resilience Act beachten. Er verpflichtet Hersteller seit dem 11. September 2026, aktiv ausgenutzte Schwachstellen zu melden. Ab dem 11. Dezember 2027 kommt unter anderem eine Bewertung der Cybersicherheitsrisiken von der Planung über die Entwicklung bis zur Wartung hinzu.

Vor dem ersten Release sollten sich einige Fragen klar beantworten lassen, die zusammen eine kurze Checkliste ergeben. Welche personenbezogenen Daten verarbeitet die Software, zu welchem Zweck und auf welcher Rechtsgrundlage? Hat jede Datenart eine Löschregel, und wird sie technisch durchgesetzt, auch in Protokollen und Sicherungen? Lassen sich Auskunft, Berichtigung, Löschung und Export für eine Person innerhalb der Frist erledigen? Sind Rollen und Rechte so eng wie möglich gefasst und die Voreinstellungen sparsam? Welche Dienste außerhalb der eigenen Systeme bekommen Daten, wo verarbeiten sie diese, und gibt es mit allen, die im Auftrag verarbeiten, einen Auftragsverarbeitungsvertrag? Ist geklärt, ob eine Datenschutz-Folgenabschätzung nötig ist und ob ein Betriebsrat mitbestimmt? Und kommt die Entwicklung ohne Echtdaten aus?

KI-Tools: Das Grundproblem sind Daten, die das Unternehmen verlassen

Wenn ein Mitarbeiter einen Kundenbrief in ChatGPT einfügt, um ihn umzuformulieren, verlassen personenbezogene Daten das Unternehmen. Je nach Anbieter und Einstellung werden sie möglicherweise für das Training zukünftiger Modelle verwendet. Das ist datenschutzrechtlich problematisch, auch wenn es technisch simpel ist, und viele Unternehmen nutzen solche Werkzeuge, ohne den nach Artikel 28 erforderlichen Vertrag abgeschlossen zu haben. Das Risiko ist dabei selten der geplante Einsatz, sondern der unkontrollierte durch einzelne Mitarbeiter, die schlicht produktiv sein wollen.

Lösungsansätze für den Unternehmenseinsatz

Der einfachste Weg sind Unternehmensverträge. Die meisten großen Anbieter bieten Business- oder Enterprise-Tarife, die einen AVV einschließen und das Training auf Basis Ihrer Daten deaktivieren. Beispiele sind ChatGPT Business und Enterprise von OpenAI, Microsoft Copilot, früher Microsoft 365 Copilot, und Gemini in Google Workspace. Die Zusagen unterscheiden sich im Detail. Microsoft etwa nimmt nach seiner Dokumentation zum Unternehmensdatenschutz, Stand Oktober 2026, die Websuche und die Modelle von Anthropic von der EU-Datengrenze aus. Wer den europäischen Rechtsraum nicht verlassen will, bevorzugt Anbieter mit Rechenzentren in der EU, etwa den Azure OpenAI Service in Sweden Central oder Mistral AI aus Frankreich. Bei Azure hängt der Ort der Verarbeitung allerdings von der Art der Bereitstellung ab. Eingaben und Antworten bleiben nur dann in Europa, wenn die Bereitstellung auf eine europäische Azure-Geografie wie Schweden oder auf die EU-Datenzone beschränkt ist. Bei einer globalen Bereitstellung kann Microsoft sie in jeder Azure-Region verarbeiten. Bleiben die Daten tatsächlich in Europa, erleichtert das die Compliance. Gehört der Anbieter zu einem Konzern mit Sitz in den USA, gilt aber auch hier, was ich oben zum Hosting in der EU beschrieben habe.

Für besonders sensible Daten ist eine selbst gehostete Lösung die sicherste Option. Offene Modelle wie Llama, Mistral oder Qwen lassen sich auf eigenen Servern oder in einer privaten Cloud betreiben, und ihre Qualität reicht für viele Anwendungsfälle vollkommen aus. Wann sich das rechnet und wo die Grenzen liegen, beschreibe ich im Beitrag über lokale Sprachmodelle im Mittelstand. Eine pragmatische Zwischenlösung ist die Pseudonymisierung vor der Eingabe: Personenbezogene Daten werden vor der Übergabe an das KI-Tool durch Platzhalter ersetzt, aus einem Kundennamen wird "KUNDE_A", aus einer Adresse "[E-MAIL]", und das Ergebnis wird anschließend zurückübersetzt. Das ist aufwendiger, aber datenschutzrechtlich deutlich sauberer.

Organisatorische Maßnahmen für KI-Tools

Technik allein reicht nicht. Unternehmen, die KI-Tools einsetzen, brauchen klare interne Richtlinien: Welche Daten dürfen in welche Werkzeuge eingegeben werden? Wer schult die Mitarbeiter? Muss das KI-Tool im Verarbeitungsverzeichnis nach Artikel 30 DSGVO dokumentiert werden? In vielen Fällen lautet die Antwort ja. Dieselben Fragen stellen sich, sobald KI-Agenten eigenständig mit Kundendaten arbeiten, dort kommt die technische Durchsetzung der Grenzen noch hinzu.

Die Datenschutzkonferenz empfiehlt in ihrer Orientierungshilfe „Künstliche Intelligenz und Datenschutz“ vom 6. Mai 2024, klar und dokumentiert festzulegen, ob, unter welchen Voraussetzungen und zu welchen Zwecken welche KI-Anwendungen genutzt werden dürfen, am besten mit Beispielen für erlaubte und untersagte Einsätze. Für die berufliche Nutzung sollten Beschäftigte Geräte und Konten des Arbeitgebers bekommen, statt private zu nutzen, und durch Schulungen und Leitfäden sensibilisiert werden. Datenschutzrechtlich vorzugswürdig sind nach der Orientierungshilfe Anwendungen, die Ein- und Ausgaben nicht zum Training verwenden.

Hat eine Verarbeitung voraussichtlich ein hohes Risiko für die Betroffenen zur Folge, verlangt Art. 35 DSGVO vorab eine Datenschutz-Folgenabschätzung. Die Verordnung nennt dabei ausdrücklich die Verwendung neuer Technologien und schreibt die Abschätzung unter anderem bei einer umfangreichen Verarbeitung von Gesundheitsdaten vor. Ob das zutrifft, sollte vor der Entwicklung geklärt sein, denn die Ergebnisse fließen oft direkt in die Anforderungen an die Software ein.

Häufige Fragen zur DSGVO-konformen Softwareentwicklung

Was macht Software DSGVO-konform?

Software ist nie für sich allein DSGVO-konform, denn die Verordnung regelt die Verarbeitung personenbezogener Daten, und dafür ist das Unternehmen verantwortlich, das die Software einsetzt. Die Software kann diese Verarbeitung aber gut oder schlecht unterstützen. Gut ist sie dann, wenn sie nur die nötigen Daten erhebt, den Zugriff nach Rollen begrenzt, Daten verschlüsselt speichert und überträgt, Zugriffe nachvollziehbar protokolliert, Löschfristen umsetzt und Auskunft und Datenexport für Betroffene ermöglicht.

Was ist der Unterschied zwischen Privacy by Design und Privacy by Default?

Privacy by Design nach Art. 25 Abs. 1 DSGVO betrifft die Gestaltung der Verarbeitung insgesamt, von der Planung bis zum Betrieb, also Architektur, Datenmodell, Rechte und Löschroutinen. Privacy by Default nach Art. 25 Abs. 2 betrifft die Voreinstellungen. Ohne Zutun der Nutzer sollen nur die Daten verarbeitet werden, die für den jeweiligen Zweck erforderlich sind, und sie dürfen nicht ohne Eingreifen der Person einer unbestimmten Zahl von Menschen zugänglich werden.

Was gehört in ein Löschkonzept für eine Software?

Ein Löschkonzept legt für jede Datenart Zweck, Frist und den Auslöser für den Fristbeginn fest und bestimmt, ob am Ende gelöscht oder anonymisiert wird. Dazu kommen die Aufbewahrungspflichten, die eine Löschung aufschieben, der Umgang mit Protokollen und Datensicherungen und ein Nachweis, dass tatsächlich gelöscht wurde. Eine Methode dafür beschreibt die DIN EN ISO/IEC 27555, die im September 2025 die frühere DIN 66398 ersetzt hat.

Was ist bei F&E-Software für den Datenschutz zu beachten?

Forschung im Sinne der DSGVO ist weit gefasst und kann auch technologische Entwicklung umfassen. Dafür gibt es Erleichterungen, etwa bei Zweckbindung und Speicherdauer, aber nur mit geeigneten Garantien nach Art. 89 Abs. 1 DSGVO. Technisch heißt das vor allem, Identitäten getrennt von den Forschungsdaten zu speichern, so früh wie möglich zu pseudonymisieren oder zu anonymisieren, mit synthetischen Testdaten zu entwickeln und Datenflüsse zu dokumentieren. Ob ein Projekt als Forschung gilt, klärt am besten Ihr Datenschutzbeauftragter.

Brauche ich einen Auftragsverarbeitungsvertrag mit meinem Softwareentwickler?

Ja, wenn der Entwickler im Auftrag Ihres Unternehmens personenbezogene Daten verarbeitet oder bei Wartung und Fehlersuche Zugriff darauf haben kann. Arbeitet er ausschließlich mit Testdaten und kommt mit echten personenbezogenen Daten nie in Berührung, verarbeitet er keine Daten in Ihrem Auftrag, und ein AVV ist dafür nicht nötig. Die genaue Abgrenzung im Einzelfall nimmt am besten Ihr Datenschutzbeauftragter vor.

Muss die Software in der EU gehostet werden?

Die DSGVO selbst schreibt keinen Serverstandort vor. Übermittlungen in Länder außerhalb der EU und des EWR sind aber nur unter den Bedingungen der Artikel 44 bis 49 zulässig, und ein Hosting in der EU erspart diese Prüfung zumindest für den Server selbst. Strengere Vorgaben gibt es in einzelnen Bereichen. Wer als Leistungserbringer der gesetzlichen Krankenversicherung, etwa als Arztpraxis, Sozial- und Gesundheitsdaten mit Cloud-Diensten verarbeitet, muss nach § 393 SGB V unter anderem auf den Ort der Verarbeitung, eine Niederlassung des Anbieters im Inland und ein C5-Testat achten.

Dürfen Mitarbeiter personenbezogene Daten in ChatGPT oder andere KI-Tools eingeben?

Das hängt vom Tarif und von den internen Regeln ab. Voraussetzungen sind ein Tarif mit Auftragsverarbeitungsvertrag, eine Rechtsgrundlage für die Verarbeitung und eine interne Regel, welche Daten in welches Werkzeug dürfen. In kostenlose Verbraucherversionen gehören personenbezogene Daten aus dem Unternehmen nach meiner Einschätzung nicht, weil es dort in der Regel keinen solchen Vertrag gibt. Wo es geht, ist die Pseudonymisierung vor der Eingabe der sicherere Weg.

Welche KI-Tools lassen sich DSGVO-konform einsetzen?

Kein KI-Tool ist für sich allein DSGVO-konform. Es kommt darauf an, wie ein Unternehmen es einsetzt. Achten Sie auf einen Unternehmenstarif mit Vertrag zur Auftragsverarbeitung, der das Training mit Ihren Ein- und Ausgaben ausschließt, auf einen geklärten Ort der Verarbeitung und darauf, dass Beschäftigte über Konten des Unternehmens arbeiten und nicht über private. Außerdem sollte dokumentiert sein, welche Arten von Daten in das Werkzeug eingegeben werden dürfen. Beispiele für solche Unternehmenstarife nenne ich oben bei den Lösungsansätzen. Für besonders sensible Daten bleibt ein selbst betriebenes Modell die Lösung mit der meisten Kontrolle.

Fazit

DSGVO-konforme Softwareentwicklung ist kein Mehraufwand, sie ist gute Softwareentwicklung. Wer Datenschutz von Anfang an in seine Architektur einbaut, spart sich teure Nachbesserungen und schützt gleichzeitig seine Kunden und sein Unternehmen. Für KI-Tools gilt dasselbe: Wer von Anfang an den richtigen Anbieter wählt, den AVV abschließt und klare interne Regeln definiert, kann KI produktiv und sicher einsetzen. Die Alternative, der unkontrollierte Einsatz durch Mitarbeiter, ist das eigentliche Risiko.

Im Oktober 2026 habe ich diesen Beitrag überarbeitet und erweitert, unter anderem um Abschnitte zu den Anforderungen der DSGVO an Software, zu Protokollen, zum Löschkonzept, zu den Betroffenenrechten, zu Testdaten, zu Software für Forschung und Entwicklung, zum Hosting in der EU und zum Datenschutz im Entwicklungsalltag sowie um häufige Fragen und aktuelle Quellen zu den Unternehmenstarifen der KI-Anbieter.