DSGVO-konforme KI-Workflows in der Praxis umsetzen

Die Datenschutzfrage bleibt in Zusammenhang mit KI in vielen Unternehmen unbeantwortet. Lesen Sie, was dagegen hilft.Gorodenkoff | shutterstock.com



Die Zahl steht seit März im Raum: 77 Prozent der deutschen Unternehmen sehen einer Bitkom-Umfrage zufolge Datenschutzanforderungen als größtes Hemmnis für ihre Digitalisierungsbemühungen – noch vor dem Fachkräftemangel (70 Prozent). Die naheliegende Schlussfolgerung lautet: Die DSGVO bremst KI aus. Das stimmt nur selten.



In der Bitkom-Studie „Datenschutz in der deutschen Wirtschaft“ (PDF) vom Februar 2026 geben zwar 69 Prozent der Unternehmen an, dass Datenschutzvorgaben den Einsatz von KI-Trainingsdaten hemmen. In der Praxis scheitern Projekte jedoch so gut wie nie daran. Sondern an der Vertragsfrage, die niemand vor dem ersten Prompt gestellt hat.



Wie groß die gefühlte Last ist, zeigt dieselbe Studie an anderer Stelle: 97 Prozent der Unternehmen empfinden den Compliance-Aufwand als hoch. Das ist in Teilen allerdings ein hausgemachtes Problem, weil die Rollenfrage ungeklärt bleibt. Wer KI-Workflows für Kunden betreibt, ist Auftragsverarbeiter. Wer sie im eigenen Haus einsetzt, bleibt verantwortlich, auch wenn ein Dienstleister das System gebaut hat. Daraus ergibt sich,




wer den Auftragsverarbeitungsvertrag (AVV) braucht,



wer die Betroffenenanfragen beantwortet, und



wer bei einer Panne meldet.




In Projekten, in denen das ab dem ersten Tag festgehalten wird, löst sich ein erstaunlich großer Teil des gefühlten Aufwands in Luft auf.



Wer Claude über die kostenlose Version oder ein Pro-Abo nutzt, arbeitet ohne Auftragsverarbeitungsvertrag, Für API-, Team- und Enterprise-Kunden schließt Anthropic den AVV seit dem 1. Januar 2026 automatisch mit ab.Bei OpenAI ist die Lage strukturell gleich: die API bietet AVV samt Standardvertragsklauseln.



Für die Praxis bedeutet das: Ob ein Workflow DSGVO-konform betrieben werden kann, entscheidet der Vertragstyp, nicht die Technologie. Ein Mitarbeiter, der einen privaten ChatGPT-Account mit einer Kundenkorrespondenz füttert, verarbeitet personenbezogene Daten ohne Rechtsgrundlage. Derselbe Vorgang über eine API mit AVV ist hingegen ein normaler Auftragsverarbeitungsfall.



Warten ist keine Lösung



Ein Einwand liegt nahe: Brüssel lockert die DSGVO doch gerade. Das trifft zwar teilweise zu – an entscheidenden Stellen jedoch nicht. So hat die Kommission im November 2025 den Digital Omnibus vorgelegt, ein Paket aus zwei getrennten Verordnungsentwürfen. Der KI-Teil ist „durch“ – die EU-Verordnung 2026/1744 Ende Juli 2026 in Kraft getreten. Der Datenschutz-Part ist es nicht.



Dabei enthält dieser die Punkte, die den Projektalltag verändern könnten:




eine geschärfte Definition personenbezogener Daten,



Erleichterungen für pseudonymisierte Datensätze, sowie



das Training von KI-Modellen auf Grundlage berechtigten Interesses.




Der Europäische Datenschutzausschuss und der Europäische Datenschutzbeauftragte haben in ihrer gemeinsamen Stellungnahme vom Februar 2026 erhebliche Bedenken gegen die neue Datendefinition angemeldet, eine Ratsposition liegt bis heute nicht vor. Wer seine Architektur auf dieser Grundlage errichtet, baut also auf Grundlage eines Textes, dessen Endfassung niemand kennt und von dem unklar ist, wann er in Kraft treten könnte. Fakt ist: Für jedes System, das in diesem Jahr produktiv geht, gilt also die DSGVO in ihrer heutigen Fassung.



Eine datenschutzrechtliche Neuerung ist allerdings bereits in Kraft, und sie findet sich an unerwarteter Stelle. Die KI-Änderungsverordnung fügt einen neuen Artikel (4a) zur KI-Verordnung hinzu. Dieser erlaubt es, besondere Kategorien personenbezogener Daten ausnahmsweise zu verarbeiten, um Verzerrungen zu erkennen und zu korrigieren. Das gilt ausdrücklich nicht nur für Hochrisiko-Systeme, sondern auch für die Anbieter und Betreiber anderer KI-Systeme und -Modelle.



Die Bedingungen sind dabei eng gefasst:




Der Zweck darf sich nicht mit anderen Daten erreichen lassen,



es braucht Pseudonymisierung, Zugriffskontrolle und Dokumentation,



eine Weitergabe an Dritte ist ausgeschlossen, und



die Daten sind nach der Korrektur zu löschen.




Eine Pflicht zur „Verzerrungsprüfung“ entsteht daraus nicht. Wer diese dennoch durchführen will, hat dafür seit Ende Juli aber eine ausdrückliche Rechtsgrundlage. Dass diese gefehlt hat, war bisher der häufigste Grund dafür, davon abzusehen.



Für US-Anbieter kommt die Übermittlungsfrage dazu. Hier hat sich die Rechtslage 2025 vorerst geklärt: Das Gericht der Europäischen Union hat im September 2025 die Klage gegen das EU-US Data Privacy Framework abgewiesen (PDF). Der Angemessenheitsbeschluss für die USA bleibt damit bestehen. Der Kläger hat zwar Ende Oktober 2025 Rechtsmittel eingelegt, ein Verhandlungstermin ist jedoch bis heute nicht angesetzt. Ein drittes Schrems-Szenario ist also möglich. Wann darüber entschieden wird, weiß niemand.



Für die Architekturentscheidung folgt daraus eine einfache Regel: Nutzen Sie das Data Privacy Framework, aber bauen sie nicht darauf. Wer seine KI-Workflows so aufsetzt, dass Standardvertragsklauseln als zweites Standbein bereitliegen und datenhaltende Komponenten in der EU laufen, muss nur in Sachen Verträge nachziehen, wenn das Framework gekippt wird – und nicht seine Systeme umbauen.



Was Regulatoren tatsächlich erwarten



Die deutschen Datenschutzbehörden haben ihre Erwartungen präzisiert, und sie sind praktischer, als ihr Ruf es vermuten lässt. Die Datenschutzkonferenz (DSK) hat Mitte Juni 2025 eine Orientierungshilfe (PDF) zu technischen und organisatorischen Maßnahmen bei KI-Systemen veröffentlicht. Sie ist als „lebendes“ Dokument angelegt und “denkt” in Lebenszyklus-Phasen: Design, Entwicklung, Betrieb, Außerbetriebnahme. Wer diese Phasen durchdekliniert, hat eine brauchbare Prüfliste und weiß, was eine Behörde im Fall einer Beschwerde sehen will.



Im Oktober 2025 hat die DSK zudem eine Orientierungshilfe zu generativen KI-Systemen mit RAG-Methode nachgeliefert (PDF). Für Automatisierungsprojekte im Mittelstand ist das der relevantere der beiden Leitfäden, denn in diesem Umfeld wird selten ein eigenes Modell trainiert. Stattdessen wird ein „fremdes“ Modell auf eigene Dokumente angesetzt – und genau dieser Fall wird hier durchgespielt.



Zwei Punkte verdienen in diesem Zusammenhang besondere Aufmerksamkeit, weil sie in der Praxis am häufigsten fehlen:




Die Betroffenenrechte: Löschung und Widerspruch nach Artikel 17 und 21 DSGVO müssen sich im Workflow technisch umsetzen lassen. Eine Datenschutzerklärung, die das Recht beschreibt, während der Workflow keine Löschfunktion kennt, dokumentiert den Verstoß gleich mit.



Die Protokollierung: Wer nicht nachvollziehen kann, welche Daten wann durch welchen Verarbeitungsschritt gelaufen sind, kann auf eine Auskunftsanfrage nach Artikel 15 schlicht nicht antworten.




4 Bausteine für DSGVO-konforme KI-Workflows



Die eingangs zitierten 77 Prozent aus der Bitkom-Studie repräsentieren am Ende weniger die Rechtslage selbst. Eher die Unsicherheit im Umgang mit ihr. Unternehmen, die ihre KI-Workflows entlang der folgenden vier Bausteine aufsetzen, können die „Datenschutz-Hürde” zielführend nehmen.




AVV vor Produktivstart, für jede Komponente: Das Sprachmodell ist dabei erst der Anfang. Denselben Arbeitsverarbeitungsvertrag brauchen auch die Workflow-Plattform, das CRM und der Hosting-Anbieter dazwischen. Die Kette ist nur so konform wie ihr schwächstes Glied. Eine Faustregel für die Praxis: Wenn ein Werkzeug keinen AVV anbietet, handelt es sich um die Consumer-Version des Produkts – und die gehört nicht in einen Geschäftsprozess.



Datenminimierung im Workflow-Design: Ein Automatisierungsschritt braucht selten den ganzen Datensatz. Wer dem Modell nur die Felder übergibt, die der konkrete Schritt erfordert, reduziert die Angriffsfläche und macht die spätere Auskunft trivial. Das kostet eine Stunde, erspart im Betrieb aber diverse Diskussionen.



Betroffenenrechte als Funktion, nicht als Absichtserklärung: Löschung und Verarbeitungsstopp einzelner Personen gehören als ausführbarer Pfad in den Workflow. Das klingt aufwendig, ist es aber nicht, wenn es von Anfang an mitgedacht wird. Es nachträglich einzubauen, wird hingegen richtig teuer.



Der dokumentierte Rest: Verarbeitungsverzeichnis-Eintrag, Protokollierung, eine kurze Schulung der Mitarbeiter, die mit dem System arbeiten. Nichts davon ist besonders anspruchsvoll. Aber es muss existieren – bevor die erste Anfrage kommt.




(fm)



Dieser Beitrag wurde im Rahmen des deutschsprachigen Experten-Netzwerks von Foundry veröffentlicht. Lust mitzumachen? Jetzt bewerben!