Warum die DSGVO die erste Frage ist, nicht die letzte

Viele KI-Projekte sind technisch einwandfrei und gehen trotzdem nie in Betrieb, weil die Datenschutzfrage bis zum Schluss aufgeschoben wurde — und die Antwort am Ende „nein“ lautete. Für ein mittelständisches Unternehmen, das Kundendaten, Mitarbeiterdaten oder Lieferanteninformationen verarbeitet, ist die Datenschutz-Grundverordnung keine Fußnote, die man kurz vor dem Start ergänzt. Sie bestimmt, welche Daten das System berühren darf, wo es laufen darf und woran es sich erinnern darf. Als nachträgliche Überlegung behandelt, wird sie zu einem teuren Umbau. Als Entwurfsvorgabe behandelt, ist sie meist nur eine Reihe sinnvoller technischer Randbedingungen.

Die gute Nachricht: Die DSGVO wurde technologieneutral geschrieben. Sie verbietet KI nicht, und sie erwähnt sie nicht einmal. Sie stellt an ein KI-System dieselben Fragen wie an jede andere Software, die personenbezogene Daten verarbeitet: auf welcher Rechtsgrundlage, zu welchem Zweck, mit wie vielen Daten, unter wessen Kontrolle und wie lange. Wer das klar beantworten kann, für den ist ein KI-System nicht verbotener als ein CRM. Die Schwierigkeit ist, dass KI-Systeme es besonders leicht machen, diese Fragen schlecht zu beantworten — indem sie mehr Daten aufsaugen als nötig, sie an Orte senden, an die sie nicht gehören, und sich Dinge merken, die sie nie behalten sollten.

Der Kerngedanke. Die DSGVO verbietet KI nicht. Sie verlangt einen bewussten Umgang mit personenbezogenen Daten — und genau den bringen die besten KI-Architekturen ohnehin mit. Konformität und gutes Engineering zeigen weit häufiger in dieselbe Richtung, als man erwartet.

Die DSGVO-Pflichten, die ein KI-System berühren

Sechs Pflichten leisten in der Praxis die meiste Arbeit. Keine davon ist exotisch, und keine ist spezifisch für KI — aber jede landet an einer konkreten Stelle im Aufbau des Systems.

Eine Rechtsgrundlage

Sie brauchen einen rechtlichen Grund, um personenbezogene Daten überhaupt zu verarbeiten: Einwilligung, Vertrag, berechtigtes Interesse und so weiter. Für eine KI-Funktion heißt das, sagen zu können, warum Sie eine bestimmte Datenkategorie in das System geben dürfen — und vor allem, ob „wir haben sie bereits für X erhoben“ auch „jetzt nutzen wir sie zusätzlich, um ein Modell zu trainieren oder zu betreiben“ abdeckt. Das Zweckentfremden vorhandener Daten für KI ist die Stelle, an der viele Projekte still über die Grenze treten.

Zweckbindung und Datenminimierung

Daten, die für einen Zweck erhoben wurden, sollten nicht stillschweigend zum Treibstoff für einen anderen werden, und ein System sollte nur die Daten berühren, die es wirklich braucht. Das ist die Pflicht, die KI-Systeme am leichtfertigsten verletzen. Es ist verlockend, einem Modell die gesamte Kundentabelle zu geben, „damit es Kontext hat“, wenn die Aufgabe nur drei Felder benötigt. Datenminimierung ist beides: eine rechtliche Pflicht und, praktischerweise, gutes Design — weniger Daten hinein bedeutet weniger Risiko, weniger Kosten und einen kleineren Schaden, falls doch etwas schiefgeht.

Transparenz

Menschen haben ein Recht darauf zu erfahren, dass ihre Daten verarbeitet werden und, in groben Zügen, wie. Wenn ein KI-System jemanden spürbar betrifft — eine Bewerbung vorsortiert, einen Fall priorisiert —, muss sich das in verständlicher Sprache erklären lassen, nicht in Modellgewichten vergraben.

Sicherheit

Personenbezogene Daten müssen durch angemessene technische Maßnahmen geschützt werden: Zugriffskontrollen, Verschlüsselung und eine klare Grenze um den Bereich, in dem sich die Daten bewegen dürfen. Bei KI ist diese Grenze das Entscheidende, denn der einfachste Weg, eine Funktion zu bauen, besteht oft darin, die Daten an einen Dienst zu senden, der außerhalb dieser Grenze liegt.

Betroffenenrechte

Menschen können fragen, was Sie über sie gespeichert haben, sie können eine Berichtigung verlangen und sie können die Löschung verlangen. Ein System muss diese Anfragen erfüllen können — was voraussetzt, dass Sie tatsächlich wissen, welche personenbezogenen Daten die KI enthält, und sie entfernen können. Ein Modell oder ein Index, der personenbezogene Daten still aufgenommen hat, ohne dass man sie finden oder löschen kann, ist eine dauerhafte Haftung.

Rechenschaft und Dokumentation

Sie müssen Konformität nachweisen können, nicht nur behaupten: Dokumentation dessen, was das System tut, welche Daten es nutzt und — wo die Verarbeitung risikoreich ist — eine Datenschutz-Folgenabschätzung. Das ist in einer Demo unsichtbar und in einem echten Betrieb unverzichtbar.

Personendaten aus Ihren Systemen KI-Verarbeitung on-premise oder EU Ergebnis & Aktion zurückgeschrieben minimieren protokolliert DSGVO-Pflichten — per Architektur, nicht per Kleingedrucktem Grundlage Minimierung Protokoll Löschung Auskunft
Eine konforme KI-Pipeline: beim Eingang minimieren, die Verarbeitung unter Ihrer Kontrolle halten, protokollieren, was passiert — und jede DSGVO-Pflicht hat einen konkreten Ort im System.

Wo KI-Projekte tatsächlich scheitern

In der Praxis entstehen die meisten DSGVO-Probleme in KI-Projekten aus einer kurzen Liste vermeidbarer Fehler. Es lohnt sich, sie klar zu benennen, denn jeder einzelne lässt sich am Anfang leicht wegkonstruieren und ist später schmerzhaft zu beheben.

Personenbezogene Daten an einen Dienst außerhalb Ihrer Kontrolle senden. Der schnellste Weg, eine Funktion zu bauen, ist oft, ein großes Cloud-Modell aufzurufen, das außerhalb der EU gehostet wird. Diese eine Entwurfsentscheidung kann aus einer Routineaufgabe eine grenzüberschreitende Übermittlung personenbezogener Daten machen — mit allem rechtlichen Gewicht, das dazugehört. Das ist nicht immer falsch, aber es ist nie eine Entscheidung, die man versehentlich treffen sollte.

Ohne Grundlage trainieren oder feinabstimmen. „Wir haben die Daten ohnehin“ ist nicht dasselbe wie „wir dürfen ein Modell darauf trainieren“. Kunden- oder Mitarbeiterdaten zum Feinabstimmen eines Modells zu nutzen, ist ein neuer Zweck und braucht seine eigene Begründung. Schlimmer noch: Ein Modell, das auf personenbezogenen Daten trainiert wurde, kann sich Teile davon faktisch merken — was das nächste Problem deutlich verschärft.

Kein Weg zum Löschen. Wenn jemand sein Recht auf Löschung wahrnimmt, müssen Sie seine Daten entfernen — auch aus jedem KI-Index oder Modell, das sie aufgenommen hat. Systeme, die personenbezogene Daten ohne Landkarte in eine Vektordatenbank oder ein feinabgestimmtes Modell schaufeln, können einer Löschanfrage nur mit großem Aufwand nachkommen.

Kein Prüfpfad. Wenn eine Aufsichtsbehörde, ein Prüfer oder ein Kunde fragt, was das System mit den Daten einer bestimmten Person getan hat, ist „wir glauben, das war in Ordnung“ keine Antwort. Ohne Protokollierung lässt sich nicht rekonstruieren, was geschehen ist — und Sie können Ihre Konformität nicht nachweisen, selbst wenn sie gegeben war.

Ein Muster, das auffällt. Fast jedes ernste DSGVO-Versagen in einem KI-Projekt ist die Folge einer von zwei Abkürzungen: Daten dorthin senden, wohin sie nicht gehören, oder Daten behalten, ohne sie finden und entfernen zu können. Beides sind Architekturentscheidungen, und beide sind von Anfang an günstig richtig zu machen.

Konformität durch Architektur, nicht durch Kleingedrucktes

Der verlässliche Weg, konform zu bleiben, ist nicht, eine längere Datenschutzerklärung zu schreiben. Er besteht darin, das System so zu bauen, dass der konforme Weg der einzige Weg ist — dass die Kontrollen, die die DSGVO verlangt, Eigenschaften der Architektur sind und nicht Versprechen in einem Dokument. Genau darum geht es im Diagramm oben: An jeder Stufe geschieht das Richtige, weil das System so gebaut ist.

Wenige Entscheidungen leisten den Großteil der Arbeit. Halten Sie die Verarbeitung dort, wo die Daten sein dürfen — auf Ihrer eigenen Infrastruktur oder in einer EU-Region —, damit „wohin gehen die Daten?“ eine langweilige, gut begründbare Antwort hat. Genau hier hört der Betrieb eines offenen Modells auf eigener Hardware auf, eine Vorliebe zu sein, und wird zur verantwortungsvollen Option. Minimieren Sie am Punkt der Datenaufnahme, sodass das System immer nur die Felder sieht, die es braucht, und pseudonymisieren Sie, wo die Aufgabe es zulässt, damit Namen und Kennungen gar nicht erst beim Modell ankommen. Protokollieren Sie jeden Zugriff und jede Entscheidung, damit der Prüfpfad von vornherein existiert, statt nachträglich angebaut zu werden. Und bauen Sie Löschung und Aufbewahrungsfristen in die Datenschicht ein, sodass „diese Person entfernen“ eine unterstützte Operation ist und kein Forschungsprojekt.

In einen Server gesteckte Netzwerkkabel als Sinnbild für Dateninfrastruktur, die unter eigener Kontrolle bleibt
Halten Sie die Verarbeitung dort, wo die Daten sein dürfen — auf eigener Infrastruktur oder in einer EU-Region. „Wohin gehen unsere Daten?“ sollte eine langweilige Antwort haben.

So gebaut, schreibt sich die Konformitätsgeschichte von selbst. Fragt jemand, wohin die Daten gehen, lautet die Antwort „nirgendwohin, wo sie nicht hindürfen“. Fragt jemand, was das System getan hat, zeigt es das Protokoll. Bittet jemand um Löschung, gibt es dafür eine Schaltfläche. Nichts davon ist teurer als es unsauber zu tun — oft ist es günstiger, weil Sie nicht später dafür bezahlen, Entscheidungen rückgängig zu machen, die Sie nie hätten treffen sollen.

DSGVO und EU AI Act: zwei Hüte, ein System

Die beiden Regelwerke werden leicht verwechselt, deshalb lohnt sich Präzision. Die DSGVO regelt personenbezogene Daten — wie Sie Informationen über Menschen erheben, nutzen und speichern dürfen. Der EU AI Act regelt KI-Systeme — wie sie gebaut, dokumentiert und beaufsichtigt werden müssen, je nachdem, wie riskant ihr Einsatz ist. Ein einzelnes System kann beide Hüte tragen: Eine KI, die Bewerbungen vorsortiert, verarbeitet personenbezogene Daten (DSGVO) und trifft folgenreiche Entscheidungen über Menschen (ein höheres Risiko unter dem AI Act).

Die praktische Schlussfolgerung ist beruhigend. Dieselbe Architektur, die Sie auf der richtigen Seite der DSGVO hält — Daten unter Ihrer Kontrolle, Minimierung, Protokollierung, Dokumentation, menschliche Aufsicht —, ist zugleich das meiste von dem, was der AI Act verlangt. Einmal gut gebaut, erfüllen Sie beides. Wenn Sie die Details zum zweiten Regelwerk möchten, behandeln wir sie in „Der EU AI Act, verständlich erklärt“.

Eine kurze Checkliste für die Praxis

Bevor Sie sich auf eine KI-Funktion festlegen, die personenbezogene Daten berührt, fangen fünf Fragen die meisten Probleme früh ab:

  1. Grundlage: Was ist unsere Rechtsgrundlage, diese Daten für diesen Zweck zu nutzen — und deckt sie das Training ebenso ab wie den Betrieb des Modells?
  2. Ort: Wo werden die Daten verarbeitet, und können wir sie innerhalb einer Grenze halten, die wir kontrollieren?
  3. Minimierung: Was ist die kleinste Menge an Feldern, die die Aufgabe wirklich braucht, und können wir den Rest pseudonymisieren?
  4. Löschung: Wenn jemand die Entfernung verlangt, können wir seine Daten überall finden und löschen, wo das System sie hält — einschließlich Index und feinabgestimmtem Modell?
  5. Nachweis: Könnten wir belegen, was das System getan hat — aus Protokollen und Dokumentation, die bereits existieren?

Wenn eine Antwort „wir sind uns nicht sicher“ lautet, ist das kein Grund, das Projekt aufzugeben. Es ist ein Grund, die Frage vor dem Bauen zu klären, solange es noch günstig ist, den Entwurf zu ändern.

Wo Tippel ins Spiel kommt

Datenschutz ist keine Schicht, die wir am Ende ergänzen; er ist eine der Randbedingungen, um die wir von der ersten Skizze an entwerfen. Weil Tippel auf einem Open-Source-Stack baut, der auf Ihrer eigenen Infrastruktur laufen kann, ist es der Normalfall und keine Sonderanfrage, personenbezogene Daten innerhalb einer Grenze zu halten, die Sie kontrollieren. Minimierung, Protokollierung und ein echter Löschweg gehören zur Art, wie das System zusammengesetzt ist — was bedeutet, dass die Dokumentation, die ein Prüfer oder eine Datenschutzbeauftragte verlangt, ein Nebenprodukt sauberen Bauens ist und keine nachträgliche Hektik.

Der beste Ort, die Datenschutzfragen zu klären, ist, bevor etwas gebaut wird. Genau dafür ist der KI-Readiness-Check da: In ein bis zwei Wochen klärt er, welche Daten Ihr Anwendungsfall wirklich braucht, wo er rechtlich und technisch laufen kann und wie die konforme Architektur aussieht — mit einem ehrlichen Go/No-Go am Ende. Er macht aus „dürfen wir das überhaupt?“ eine klare Antwort, mit der Sie planen können. Wenn Sie es lieber erst besprechen möchten, nehmen Sie Kontakt auf.