Ein Satz vorweg, damit die Erwartung stimmt. Ich erteile keine Rechtsberatung, und dieser Text ist keine. Die rechtliche Bewertung Ihres Agentensystems liegt bei Ihnen, bei Ihrem Datenschutzbeauftragten und, wenn es eng wird, bei Ihrer Kanzlei. Was ich beschreiben kann, ist die andere Hälfte. Damit Ihr Datenschutzbeauftragter überhaupt bewerten kann, braucht er Artefakte, die jemand bauen muss, und diese Artefakte entstehen im Build oder gar nicht. Ein Agentensystem nachträglich datenschutzfähig zu machen ist deutlich teurer, als es von Anfang an so zu bauen.
Der Grund liegt in der Technik. Ein Agent liest Datensätze, gibt Ausschnitte davon an ein Modell weiter, hält Zwischenergebnisse und schreibt Protokolle. Jeder dieser vier Schritte erzeugt eine Kopie personenbezogener Daten an einem Ort, an dem vorher keine lag. Wer das nicht vorher entwirft, entwirft es hinterher unter Zeitdruck.
Der Auftragsverarbeitungsvertrag ist eine Liste, keine Unterschrift
Art. 28 DSGVO verlangt, dass die Verarbeitung im Auftrag auf einem Vertrag beruht, der Gegenstand, Dauer, Art und Zweck der Verarbeitung festlegt, dazu die Art der Daten und die Kategorien betroffener Personen. Das klingt nach Formular. In der Praxis ist es eine Inventur, und die Inventur ist die eigentliche Arbeit.
Sie brauchen für jeden Agenten eine Zeile, die sagt, welche Datenkategorien er anfasst. Nicht "Kundendaten", sondern Name, Geschäftsadresse, Bestellhistorie, Freitext aus dem Ticket. Der Freitext ist dabei die unangenehme Kategorie, weil niemand kontrolliert, was Kunden hineinschreiben. Ein Postfach-Agent liest, was auch immer ankommt, und darunter sind Gesundheitsangaben in einer Reklamation und Kontoverbindungen in einer Signatur.
Dazu kommt die Kette der Unterauftragsverarbeiter, und die ist bei Agenten länger als bei klassischer Software. Der Modellanbieter ist einer. Der Cloud-Anbieter, in dem der Agent läuft, ist einer. Ein Dienst für Sprachtranskription oder Texterkennung ist einer. Wenn Sie diese Liste nicht führen, führt sie niemand, denn jeder einzelne Dienst kam über einen API-Schlüssel ins Haus und nicht über eine Beschaffung.
Praktisch heißt das, vor dem Build steht eine Tabelle, eine Zeile pro Agent, mit Systemen, Datenkategorien, beteiligten Dienstleistern und Verarbeitungsorten. Sie ist Vorlage für den Vertrag und Vorlage für das Verzeichnis von Verarbeitungstätigkeiten nach Art. 30. Beide Dokumente ziehen aus derselben Quelle.
Technische und organisatorische Maßnahmen, die man vorführen kann
Art. 32 verlangt Maßnahmen, die zum Risiko passen. Der Test, den ich anlege, ist einfach. Können Sie die Maßnahme jemandem in fünf Minuten vorführen. Wenn nicht, ist es eine Absichtserklärung.
Bei Agentensystemen gibt es dafür vier Stellen, die häufig fehlen.
Jeder Agent bekommt eigene Zugangsdaten mit eigenem Rechteumfang. Ein Schlüssel, der alles öffnet, ist bequem und macht die Frage, wer was sehen konnte, unbeantwortbar. Der Abstimmungsagent braucht Leserecht auf zwei Hauptbücher, nicht auf das Personalsystem, und dass er nie hineingeschaut hat, sollen nicht die Protokolle beweisen müssen, sondern der fehlende Zugang.
Der Modellzugang wird pro Workflow getrennt. Getrennte Schlüssel, getrennte Projekte, getrennte Abrechnung. Das ist die einzige Art, später zu belegen, welche Daten in welchen Verarbeitungskontext geflossen sind.
Die Schreibrechte sind enger als die Leserechte. Ein Agent, der Vorgänge einordnet, braucht kein Löschrecht. Ein Agent, der Entwürfe schreibt, braucht kein Senderecht. Diese Grenzen gehören in den Code und nicht in den Prompt, weil ein Prompt eine Bitte ist.
Die Verschlüsselung im Transport ist selbstverständlich. Interessanter ist der Speicher dazwischen, also Warteschlangen, Zwischenablagen und Caches, in denen ein Agent Arbeitsstände hält. Die vergisst man beim Aufschreiben zuverlässig, weil sie kein Produkt sind, sondern ein Nebenprodukt.
Zweckbindung und Datenminimierung entscheiden sich am Modellzugriff
Art. 5 verlangt, dass Daten zweckgebunden und auf das Notwendige beschränkt verarbeitet werden. Bei einem Agenten fällt diese Entscheidung an genau einer Stelle, nämlich dort, wo er den Kontext für den Modellaufruf zusammenstellt.
Der bequeme Weg ist, den ganzen Datensatz mitzuschicken. Er funktioniert sofort und verarbeitet zwanzig Felder, um eine Frage zu beantworten, für die drei reichen. Der saubere Weg ist eine Feldliste pro Aufruf, die im Code steht und die jemand lesen kann. Das kostet im Build ein paar Stunden und macht aus der Frage, welche Daten das Modell sieht, eine Datei statt einer Vermutung.
Zwei Techniken helfen zusätzlich. Pseudonymisieren Sie, was für die Entscheidung keine Rolle spielt. Ein Agent, der Tickets einordnet, braucht selten den Namen des Absenders, und ein Platzhalter reicht bis zu dem Moment, in dem die Antwort herausgeht. Und trennen Sie Nachschlagen von Übergeben. Der Agent kann eine Stammdatensuche ausführen und das Ergebnis verwenden, ohne die Tabelle dafür in den Kontext zu legen.
Klären Sie außerdem schriftlich, was der Modellanbieter mit den Eingaben tut, ob sie in ein Training fließen, wie lange sie für Missbrauchsprüfungen aufbewahrt werden und in welcher Region das passiert. Das gehört in dieselbe Tabelle wie die Unterauftragsverarbeiter, in Textform, mit Datum und Vertragsstand.
Protokollierung hilft und erzeugt neue Daten
Bei Agenten gibt es zur Protokollierung keine Alternative. Ohne Protokoll können Sie nicht sagen, wer wann welche Änderung ausgelöst hat, und damit können Sie weder eine Auskunft nach Art. 15 erteilen noch einen Vorfall nach Art. 33 beurteilen.
Das Protokoll ist aber selbst eine Verarbeitung, und meistens eine ausführliche. Ein vollständiger Mitschnitt jedes Modellaufrufs enthält per Definition die personenbezogenen Daten, die Sie an anderer Stelle minimiert haben. Deshalb trenne ich zwei Ebenen. Das Prüfprotokoll hält Zeitstempel, Agentenkennung, Vorgangsnummer, getroffene Entscheidung, Regelversion und Ergebnis. Es ist schmal, maschinell auswertbar und lange aufbewahrbar. Der Inhaltsmitschnitt hält Eingabe und Ausgabe des Modells. Er ist für Fehlersuche und Qualitätsmessung nützlich, gehört an einen getrennten Ort, hat engere Zugriffsrechte und eine kurze Frist.
Den Rest dieses Themas, nämlich die Frage, ab wann Protokolle das Verhalten von Beschäftigten abbilden, behandle ich in einem eigenen Text zum Betriebsrat. Es reicht hier zu sagen, dass Protokolldaten die Stelle sind, an der Datenschutz und Mitbestimmung sich treffen.
Löschen braucht einen Job, keine Absicht
Ein Löschkonzept, das aus einer Frist in einer Richtlinie besteht, löscht nichts. Es braucht pro Datenort eine Frist, einen Mechanismus und ein Protokoll darüber, dass der Mechanismus lief.
Zählen Sie die Orte. Das Quellsystem, in dem der Vorgang liegt. Der Zwischenspeicher des Agenten. Das Prüfprotokoll. Der Inhaltsmitschnitt. Die Ablage für Anhänge. Der Suchindex oder Vektorspeicher, falls Sie einen einsetzen. Die Sicherungen. Der letzte ist der, den die meisten Konzepte offenlassen, und das ist eine Frage, die Ihr Datenschutzbeauftragter entscheidet, nicht der Entwickler.
Der Vektorspeicher verdient besondere Aufmerksamkeit. Eine Einbettung ist eine Ableitung aus einem Text und verschwindet nicht, wenn Sie den Text löschen. Halten Sie deshalb die Zuordnung von Vektor zu Quelldatensatz vor, sonst wird aus einem Löschauftrag ein Projekt.
Ein Löschlauf, der wöchentlich läuft und eine Zeile ins Protokoll schreibt, ist einer der billigsten Bausteine des ganzen Systems und einer der wenigen, die eine Prüfung sofort bestehen.
Beim Drittlandtransfer müssen Sie wissen, wo die Aufrufe landen
Sobald ein Agent ein Modell außerhalb der EU aufruft, liegt eine Übermittlung in ein Drittland vor, und dafür braucht es eine Grundlage nach Kapitel V, in der Regel einen Angemessenheitsbeschluss oder Standardvertragsklauseln nebst einer Bewertung des Einzelfalls. Welche Grundlage trägt, entscheiden Ihre Juristen.
Ihre technische Aufgabe ist die Sichtbarkeit. Für jeden Agenten muss beantwortbar sein, welcher Endpunkt in welcher Region aufgerufen wird, ob die Region vertraglich oder nur durch eine Einstellung festgelegt ist, und was passiert, wenn der Anbieter bei Überlast in eine andere Region ausweicht. Der letzte Punkt ist der, der Konfigurationen still kaputt macht. Wo es EU-gebundene Verarbeitung gibt, lassen Sie sie sich schriftlich geben, und prüfen Sie die Einstellung nach jedem Anbieterwechsel erneut.
Wenn die Bewertung ergibt, dass ein Workflow die EU nicht verlassen darf, ist das eine Architekturentscheidung und keine Einstellung. Sie fällt vor dem Build, weil sie die Auswahl der Modelle und damit die Kalkulation bestimmt.
Rechenschaftspflicht heißt, es liegt schon da
Art. 5 Abs. 2 verlangt, dass Sie die Einhaltung nachweisen können. In der Praxis scheitert das selten am Willen und fast immer daran, dass die Nachweise erst auf Anfrage zusammengesucht werden.
Halten Sie deshalb sechs Dinge aktuell, und zwar dort, wo auch der Code liegt. Das Verarbeitungsverzeichnis. Die Beschreibung der Maßnahmen nach Art. 32. Die Liste der Unterauftragsverarbeiter mit Vertragsstand. Das Löschkonzept mit Fristen pro Datenort. Die Ergebnisse der Schattenläufe, denn sie belegen, dass Sie vor dem Produktivbetrieb geprüft haben. Und eine kurze Notiz zur Frage, ob eine Datenschutz-Folgenabschätzung nach Art. 35 nötig ist, mit dem Ergebnis und dem Datum.
Diese Unterlagen in Textform neben dem Code zu halten, klingt nach Kleinigkeit und ist der Unterschied zwischen einer Prüfung, die zwei Stunden dauert, und einer, die zwei Wochen dauert. Ihr Datenschutzbeauftragter bewertet. Ihre Aufgabe im Build ist, ihm etwas zu geben, das er bewerten kann.