DSGVO-konforme KI: Warum EU-Hosting nötig ist und nicht genügt

Die kurze Antwort

EU-Hosting entscheidet darüber, ob personenbezogene Daten den europäischen Rechtsraum verlassen. Es entscheidet nicht darüber, ob Ihr KI-System der DSGVO entspricht. Ein Server in Frankfurt macht aus einer unzulässigen Verarbeitung eine unzulässige Verarbeitung in Frankfurt.

Konform wird ein System durch vier Dinge, die mit dem Standort nichts zu tun haben: den Auftragsverarbeitungsvertrag, die Zweckbindung der eingelesenen Quellen, ein Löschkonzept, das bis in den Index reicht, und die Zugriffsrechte, die ein Dokument dort behält. Der Standort ist die Bedingung davor. Er ist notwendig, und er genügt nicht.

Wir schreiben das auf, weil in den meisten Erstgesprächen der Serverstandort die erste Frage ist und das Löschkonzept gar keine. Die zweite Frage kostet später mehr Geld als die erste.

Der Schrank daneben hat fünf Riegel: Den ersten schiebt der Serverstandort, die vier anderen entstehen erst beim Bauen und im Betrieb.

Was EU-Hosting tatsächlich regelt

Kapitel V der DSGVO regelt die Übermittlung in ein Drittland. Der Europäische Gerichtshof hat am 16. Juli 2020 das Privacy Shield für ungültig erklärt. Seit dem 10. Juli 2023 gilt der Angemessenheitsbeschluss zum EU-US Data Privacy Framework. Ob er Bestand hat, ist umstritten.

Wer nicht übermittelt, muss diese Frage nicht beantworten. Das ist der Nutzen des EU-Hostings, und er ist echt.

Zulässig ist eine Übermittlung nur in drei Fällen

• Für das Zielland liegt ein Angemessenheitsbeschluss vor.
• Es sind geeignete Garantien vereinbart.
• Eine der engen Ausnahmen der Verordnung greift.

Der Ort ist nicht eine Frage, sondern drei

Damit keine Übermittlung stattfindet, reicht es nicht, dass die Festplatte in Deutschland steht. Eine Übermittlung liegt auch dann vor, wenn jemand aus einem Drittland zu Wartungszwecken in das System sieht.

Drei Orte kommen für den Betrieb in Frage: Ihr eigenes Netz, ein Rechenzentrum in Deutschland oder ein Betrieb ohne Anbindung nach außen. Bei einem mittelständischen Armaturenhersteller steht die Plattform auf einem Linux-Server im eigenen Netz, erreichbar über eine eigene Subdomain des Unternehmens.

Auf der Karte daneben steht der Schrank mit Dateien, Index und Verläufen im Land, und trotzdem führen zwei Wege hinaus: der Aufruf des Modells und der Zugang zur Wartung.

Drei getrennte Fragen zum Ort

• Wo liegen die Originaldateien, der Index und die Chatverläufe?
• Wo läuft das Modell, das die Antwort erzeugt? Ein System in Frankfurt, das eine Programmierschnittstelle in den USA aufruft, übermittelt trotzdem.
• Wer kann von wo aus zu Wartungszwecken hineinsehen, und auf welcher Grundlage?

Auftragsverarbeitung: der Vertrag nach Artikel 28

Betreibt ein Dienstleister das System, sind Sie der Verantwortliche und er der Auftragsverarbeiter. Artikel 28 DSGVO schreibt dafür einen Vertrag mit festem Inhalt vor.

Was in diesem Vertrag stehen muss

• Gegenstand und Dauer der Verarbeitung
• Art und Zweck, Datenarten und betroffene Personen
• Weisungsbindung und Vertraulichkeit
• Sicherheitsmaßnahmen und Unterstützung bei Betroffenenrechten
• Löschung oder Rückgabe am Ende, dazu die Nachweispflichten

Zweckbindung: welche Quelle überhaupt hinein darf

Artikel 5 Absatz 1 Buchstabe b verlangt festgelegte, eindeutige und legitime Zwecke. Artikel 6 verlangt für jede Verarbeitung eine Rechtsgrundlage. Beides gilt für jede einzelne Quelle, die Sie in ein Wissenssystem einlesen, nicht für das System als Ganzes.

Der häufigste Fehler beim Aufbau ist der bequemste: den Fileserver komplett einlesen. Dort liegen Personalordner, alte Bewerbungen, Krankmeldungen und private Ablagen. Diese Daten wurden für einen Zweck erhoben, und der war nicht die Volltextsuche für die ganze Belegschaft. Der Umweg über die KI macht aus einer Zweckänderung keine zulässige.

Zweckbindung heißt beim Bauen also: Quellen einzeln entscheiden, mit einem Verantwortlichen je Quelle. Bei dem Armaturenhersteller war die erste aufbereitete Quelle die Preisliste des Hauses, nicht der Fileserver. Das ist keine Bescheidenheit, sondern die Reihenfolge, in der ein System prüfbar bleibt.

Eine Grenze weiter liegt Artikel 22. Er betrifft Entscheidungen, die ausschließlich automatisiert ergehen und rechtliche Wirkung entfalten. Ein Assistent, der einen Entwurf vorschlägt, den ein Mensch prüft und freigibt, fällt nicht darunter. Ein Ablauf, der ohne Prüfung durchläuft, kann darunter fallen.

Der Zweckbindung unterliegen auch die Daten, die das System selbst erzeugt. Ob Eingaben zur Verbesserung von Modellen verwendet werden dürfen, gehört vertraglich geklärt und technisch abgeschaltet, nicht andersherum.

Der Trichter daneben zeigt, wo diese Entscheidung sitzt: vor dem Einlesen, einmal je Quelle, und nicht einmal für das ganze System.

Daten, die das System selbst erzeugt

• Chatverläufe
• Hochgeladene Dateien
• Bewertungen von Antworten
• Nutzungsprotokolle

Löschkonzept: warum Löschen im Quellsystem nichts löscht

Artikel 5 Absatz 1 Buchstabe e verlangt Speicherbegrenzung, Artikel 17 gibt der betroffenen Person ein Recht auf Löschung. In einer Dateiablage ist das eine Zeile im Konzept. In einem Wissenssystem ist es die aufwändigste Zusage überhaupt, weil ein eingelesenes Dokument danach an mehreren Stellen gleichzeitig liegt.

Wer die Datei im Quellsystem löscht, hat davon eine Kopie erwischt. Ein Löschkonzept muss deshalb den Weg rückwärts beschreiben: welche Kopie wo entsteht, wer sie löscht, in welcher Frist, und wie mit Sicherungen umgegangen wird, die sich nicht gezielt bereinigen lassen.

Technisch hängt das an der Aufnahmestrecke. Jeder Abschnitt im Index muss seine Herkunft mitführen, bis hinunter auf Dokument und Stelle. Das ist derselbe Datensatz, der dem Nutzer die Fundstelle unter der Antwort anzeigt. Wie Abschnitte, Vektoren und Fundstellen zusammenhängen, steht in RAG-Systeme erklärt.

Wer Antworten mit Quellenangabe baut, hat die Löschung zur Hälfte gebaut. Wer darauf verzichtet, kann später nicht sagen, welche Abschnitte zu welchem Dokument gehören. Chatverläufe brauchen eine eigene Frist, denn sie sind der Ort, an dem gelöschte Inhalte am längsten überleben.

Die Kette daneben zeigt den Weg einer eingelesenen Datei: Löschen im Quellsystem trifft die erste Station, die drei danach bleiben stehen, und die Sicherungen sind darin noch nicht einmal gezeichnet.

Die Kaskade daneben zeigt, wie weit das reicht: Der Hahn am Quellsystem ist zu, und in den vier Becken darunter steht das Wasser unverändert.

Wo ein eingelesenes Dokument überall liegt

• Als Originaldatei im Quellsystem
• Als aufbereiteter Text aus der Dokumentstrecke
• Als Textabschnitte mit ihren Vektoren in der Vektordatenbank
• Als zitierter Ausschnitt in den Chatverläufen aller Nutzer, die danach gefragt haben
• In Zwischenspeichern und in jeder Sicherung, die seither gelaufen ist

Rechtevererbung: was ein Dokument im Index verliert

Auf dem Fileserver gehört zu jedem Ordner eine Berechtigung. Im Index gehört sie zunächst nicht mehr dazu. Ein Textabschnitt aus einem Papier, das nur die Geschäftsführung lesen darf, ist nach dem Einlesen ein Textabschnitt wie jeder andere. Die Suche findet ihn, das Modell liest ihn vor.

Die Frage lautet deshalb nicht, wer sich anmelden darf. Sie lautet, welche Abschnitte die Suche für diesen einen Nutzer zurückgeben darf. Anmeldung und Rechte sind zwei verschiedene Baustellen. Single Sign-on über den vorhandenen Verzeichnisdienst löst die erste und lässt die zweite unberührt.

Für die zweite gibt es einen richtigen und einen falschen Weg. Richtig ist, vor der Suche zu filtern: Die Gruppen des Nutzers werden zum Filter über die Abschnitte, und das Modell bekommt nur zu sehen, was der Nutzer selbst sehen dürfte. Falsch ist, die fertige Antwort nachträglich zu kürzen. Was einmal im Kontext des Modells stand, steht in der Antwort und danach im Chatverlauf.

Bei dem Armaturenhersteller liefert der bestehende Microsoft-Entra-ID-Tenant Anmeldung und Gruppen. Eine Rechtesteuerung auf Dokumentebene ist daraus zunächst nicht entstanden, sie war als zweiter Schritt vorgesehen. Wir schreiben das hin, weil an genau dieser Stelle Angebote gern mehr behaupten, als im System steht.

Die Gegenüberstellung daneben zeigt den Unterschied: links wird gekürzt, nachdem das Modell schon alles gelesen hat, rechts filtert der Index, bevor das Modell überhaupt etwas zu sehen bekommt.

Was ein Filter vor der Suche voraussetzt

• Jeder Abschnitt bekommt beim Einlesen ein Rechtemerkmal.
• Die Vektordatenbank hält die Trennung durch, etwa über getrennte Bereiche je Gruppe.
• Die Rechte im Quellsystem sind gepflegt. Meistens ist das der eigentliche Aufwand, und er liegt bei Ihnen.

Was Sie als Nächstes tun

Nicht mit dem Server anfangen. Mit einer Liste anfangen. Fünf Punkte sollten geklärt sein, bevor die erste Zeile konfiguriert wird.

Vor dem Aufbau zu klären

• Jede Quelle einzeln aufschreiben, die das System lesen soll, mit einem Verantwortlichen im Haus je Quelle.
• Je Quelle festhalten, ob personenbezogene Daten darin stehen, welchem Zweck sie dienen und auf welcher Rechtsgrundlage.
• Das Rechtemodell aus dem vorhandenen Verzeichnisdienst ableiten, bevor eingelesen wird, nicht danach.
• Löschfristen je Quelle festlegen, Chatverläufe, Protokolle und Sicherungen eingeschlossen.
• Die Empfängerkette aufschreiben: Modell, Betrieb, Sicherung. Was nicht in einen Auftragsverarbeitungsvertrag passt, wird ersetzt oder gestrichen.