Daten & Governance: Kopien, Fristen, Zurechnung

Jeder Schritt erzeugt eine Kopie

Bei klassischer Software weiß man, wo die Daten liegen: in der Datenbank, im Backup, vielleicht im Protokoll. Bei einem Agenten entstehen mit jedem Schritt neue Kopien, und die meisten davon hat niemand ausdrücklich angelegt.

Kontextfenster

Alles, was der Agent liest, geht als Eingabe an den Modellanbieter — bei jeder Runde erneut.

Trajektorie

Das Protokoll enthält Werkzeugargumente und Rückgaben im Wortlaut. Eine vollständige zweite Kopie.

Memory

Was der Agent behält, liegt in eurem Speicher — dauerhaft, oft ohne Verfallsdatum.

Zwischenergebnisse

Zusammenfassungen, Einbettungen, Auswertungsdatensätze. Abgeleitet und trotzdem personenbezogen.

Zielsysteme

Was der Agent schreibt, landet dort, wo er hinschreibt — inklusive dessen, was er aus einer anderen Quelle mitgebracht hat.

Vier Grundsätze, die den Entwurf bestimmen

Für personenbezogene Daten gelten benannte Grundsätze, und sie sind für die Architektur unmittelbar relevant — nicht als Rechtsfrage, sondern als Anforderung an den Bau.

• Zweckbindung — Daten werden für festgelegte, eindeutige und legitime Zwecke erhoben. Ein anderer Zweck ist eine neue Entscheidung, keine Fortsetzung.
• Datenminimierung — dem Zweck angemessen, erheblich und auf das notwendige Maß beschränkt. Nicht: alles, was greifbar ist.
• Speicherbegrenzung — in einer Form gespeichert, die eine Identifikation nicht länger als nötig ermöglicht.
• Rechenschaftspflicht — die Einhaltung muss nachgewiesen werden können, nicht nur behauptet.

Der letzte Punkt ist der, der die Technik am stärksten formt. Nachweisen können heißt: Es muss ein Artefakt geben, das zeigt, welche Daten wohin geflossen sind, wie lange sie bleiben und wer eine Aktion ausgelöst hat. Ein Konzeptpapier ist kein Nachweis; ein Protokoll mit Korrelationskennung ist einer.

Minimierung setzt am Abruf an

Der verbreitete Reflex bei zu vielen Daten im Kontext ist eine Anweisung: „Verwende nur die Felder, die du brauchst.“ Das ist eine Bitte an ein System, das die Daten bereits gesehen hat — und gesehen ist gesendet.

Zweckbindung bricht an unauffälligen Stellen

Daten, die für einen Zweck erhoben wurden, für einen anderen zu verwenden, ist eine eigene Entscheidung. Bei Agenten passiert dieser Wechsel selten bewusst — er passiert als Nebenwirkung nützlicher Funktionen.

Erhoben für

Die Bearbeitung eines konkreten Kundenvorgangs.

Verwendet für

Einen Memory-Eintrag, der in künftigen Läufen gelesen wird. Ein anderer Zweck: dauerhafte Profilbildung.

Verwendet für

Einen Testfall im Evaluationsdatensatz. Ein anderer Zweck: Produktentwicklung.

Verwendet für

Eine Auswertung über Kundenverhalten. Ein anderer Zweck: Analyse.

Die zweite und dritte Zeile sind die, die in diesem Track empfohlen wurden — Memory für Wiederverwendbares, Testfälle aus echtem Verkehr. Beides ist technisch richtig und beides ist ein Zweckwechsel. Die Konsequenz ist nicht, darauf zu verzichten, sondern es ausdrücklich zu entscheiden und die Daten dafür aufzubereiten: anonymisiert, pseudonymisiert oder mit eigener Rechtsgrundlage.

Die Trajektorie ist kein neutrales Protokoll

Im Modul zur Verlässlichkeit stand die Forderung, jeden Schritt mit Argumenten und Rückgaben aufzuzeichnen. Diese Forderung ist richtig und erzeugt genau das hier beschriebene Problem: eine vollständige zweite Kopie aller Daten, die der Agent gesehen hat.

• Redaktion beim Schreiben — bekannte Muster ersetzen, bevor der Eintrag entsteht. Nachträgliche Redaktion ist eine Löschung mit Restrisiko.
• Felder statt Freitext — strukturierte Argumente lassen sich gezielt redigieren; ein Freitextprompt nicht.
• Kürzere Aufbewahrung als für gewöhnliche Betriebsprotokolle, weil der Inhalt sensibler ist.
• Engerer Leserkreis — Trajektorien gehören nicht in dasselbe Dashboard wie Latenzkurven.
• Zwei Ebenen — eine gekürzte, breit lesbare Fassung und eine vollständige mit engem Zugriff und kurzer Frist.

Die letzte Zeile ist der übliche Kompromiss. Er löst den Konflikt nicht auf, sondern teilt ihn: Die breite Fassung trägt den Alltagsbetrieb, die vollständige die seltene Untersuchung. Wer nur eine Ebene hat, muss sich zwischen Nachvollziehbarkeit und Sparsamkeit entscheiden — und tut das dann implizit.

Zur Redaktion selbst gehört eine ehrliche Einschränkung: Musterbasierte Erkennung findet Kreditkartennummern und E-Mail-Adressen zuverlässig, Namen und Freitextangaben nicht. Ein Werkzeugargument notiz mit dem Satz „Frau Berger hat wegen der Kündigung angerufen“ passiert jeden Filter. Deshalb ist die Feldstruktur der Werkzeuge die wirksamere Maßnahme: Was gar nicht erst als Freitext übergeben wird, muss auch nicht erkannt werden.

Abgeleitete Daten sind auch Daten

Der häufigste Irrtum in diesem Bereich: Eine Zusammenfassung, eine Einbettung oder ein Memory-Eintrag gelte als etwas Neues und nicht mehr als die ursprünglichen Daten.

Abgeleitete Daten — Alles, was aus personenbezogenen Daten erzeugt wurde und weiterhin eine Person identifizierbar macht — Zusammenfassungen, Vektor-Einbettungen, Memory-Notizen, Auswertungsdatensätze, Zwischenstände. Die Ableitung ändert die Form, nicht den Bezug.

Praktisch heißt das: Wer eine Löschpflicht erfüllen will, muss alle Ableitungen mitfinden. Eine Vektor-Einbettung eines Kundenschreibens ist kein anonymer Zahlenvektor, sondern eine Repräsentation dieses Schreibens — und ein Memory-Eintrag „Kunde 8841 hat Zahlungsschwierigkeiten“ ist eine besonders langlebige Ableitung.

Besonders unangenehm ist der Fall des Vektorindex. Er wirkt technisch wie ein Zahlenfeld ohne Inhalt, und viele Implementierungen speichern den Ursprungstext gleich mit, damit ein Treffer lesbar ist. Damit liegt neben der Ableitung auch das Original — an einem Ort, den das Inventar häufig nicht kennt, weil er als Suchindex und nicht als Datenspeicher geführt wird.

Löschbarkeit entsteht beim Schreiben

Eine Löschpflicht trifft alle Kopien, und ob sie erfüllbar ist, entscheidet sich Monate vorher — nämlich in dem Moment, in dem eine Kopie angelegt wurde.

Der Grund ist mechanisch: Löschen kann man nur, was auffindbar ist. Ein Memory-Eintrag ohne Angabe, zu welcher Person er gehört, ist nicht löschbar — man müsste ihn lesen und bewerten, und bei Zehntausenden Einträgen ist das keine Option. Deshalb ist die entscheidende Regel eine Schreibregel.

Ein weiterer Punkt wird regelmäßig übersehen: Wer Daten an andere Verantwortliche weitergegeben hat, muss diese über ein Löschverlangen unterrichten. Bei einem Agenten, der in fremde Systeme schreibt, ist das keine theoretische Pflicht — es ist der Grund, warum das Inventar auch die Zielsysteme enthalten muss.

Die Kennung sollte dabei ein Pseudonym sein und nicht der Klarname. Ein Memory-Eintrag, der auf subject:8841 verweist, ist löschbar, ohne selbst eine weitere Kopie des Namens zu sein — und die Zuordnung von Pseudonym zu Person liegt an genau einer Stelle, die man schützen und im Inventar führen kann. Wer stattdessen den Namen als Schlüssel verwendet, macht jeden Index über diesen Schlüssel zu einer weiteren Kopie.

Was beim Modellanbieter passiert

Der Kontext geht bei jeder Runde an den Modellanbieter. Damit ist die Verarbeitung durch einen Dritten kein Randthema, sondern die Voraussetzung des Betriebs — und sie gehört genauso inventarisiert wie eure eigenen Speicher.

• Was gesendet wird — der vollständige Kontext, nicht nur die letzte Nachricht. Auch Werkzeugdefinitionen und Verlauf.
• Wie lange es bleibt — die Aufbewahrungsregel des Anbieters, nicht die eigene Annahme darüber.
• Ob es zur Modellverbesserung genutzt wird — eine vertragliche Frage mit technischen Folgen.
• Ob eine Betriebsart ohne Datenspeicherung verfügbar ist — und welche Funktionen dann nicht nutzbar sind.

Der letzte Punkt ist der überraschende: Eine Betriebsart ohne Datenspeicherung ist meist nicht mit allen Funktionen kombinierbar. Serverseitige Werkzeuge, die Zwischenstände halten müssen, sind typische Ausnahmen. Wer diese Kombination braucht, steht vor einer echten Entscheidung — und die fällt besser vor dem Bau als danach.

Ein Detail mit Folgen: Zwischengespeicherte Prompt-Präfixe liegen weiter beim Anbieter, auch wenn sie in der Abrechnung günstiger erscheinen. Wer personenbezogene Daten in den festen Vorspann legt, um Caching zu nutzen, hat damit eine dauerhafte Kopie an einer Stelle erzeugt, an der er sie nicht selbst löschen kann. Der Vorspann gehört deshalb frei von personenbezogenen Daten — Richtlinien und Formatvorgaben ja, Kundendaten nein.

Zurechenbarkeit als ununterbrochene Kette

Eine Aktion, die ein Agent ausführt, muss einem Menschen zurechenbar sein — nicht aus Misstrauen, sondern weil ohne Zurechnung weder Verantwortung noch Nachweis möglich sind.

Die Kette bricht an drei typischen Stellen. Erstens beim Sammelkonto: Wenn der Agent mit einem gemeinsamen Dienstkonto handelt, steht im Zielsystem dieses Konto und nicht die Person. Zweitens bei der Übergabe: Wenn ein Lauf einen anderen Lauf auslöst, muss die Kennung mitwandern. Drittens im Zeitplan: Ein nächtlicher Lauf ohne auslösenden Menschen braucht eine benannte verantwortliche Rolle, sonst ist er niemandem zurechenbar.

Wer hat ausgelöst

Die Person aus der authentifizierten Sitzung — oder bei geplanten Läufen eine benannte verantwortliche Rolle.

Was wurde getan

Die Trajektorie mit den tatsächlichen Aufrufen, nicht die Zusammenfassung.

Womit

Die Fassung des Verhaltensartefakts, unter der der Lauf lief.

Wohin

Die Zielsysteme, mit der Korrelationskennung in deren eigenen Protokollen.

Der dritte Bruch, der geplante Lauf ohne auslösenden Menschen, verdient eine eigene Regel. Ein nächtlicher Aufräumlauf ist keinem Nutzer zuzurechnen und braucht deshalb eine benannte verantwortliche Rolle, die im Protokoll steht — nicht als Freitext, sondern als Kennung, die auf eine reale Zuständigkeit zeigt. Ohne sie stehen im Prüfprotokoll des Zielsystems Aktionen, die niemand veranlasst hat.

Der Konflikt, der bleibt

Zwei Anforderungen dieses Tracks widersprechen einander, und es hilft, das auszusprechen statt es in jeder Diskussion neu zu entdecken.

Nachvollziehbarkeit verlangt

Vollständige Trajektorien mit Argumenten und Rückgaben, lange genug aufbewahrt, um einen späten Befund zu untersuchen.

Sparsamkeit verlangt

So wenig Kopien wie möglich, so kurz wie möglich, so eng zugänglich wie möglich.

Der Konflikt ist nicht auflösbar, sondern zu entscheiden — und zwar ausdrücklich, je Datenklasse. Eine brauchbare Form: Betriebsdaten ohne Personenbezug lange aufbewahren, personenbezogene Anteile kurz und redigiert, und für die seltene Untersuchung ein Verfahren mit Freigabe statt Dauerzugriff.

Bemerkenswert ist, dass beide Seiten aus demselben Grundsatz folgen können. Die Rechenschaftspflicht verlangt Nachweise und damit Aufzeichnung; die Speicherbegrenzung verlangt kurze Fristen. Wer den Widerspruch bemerkt, hat beide Grundsätze verstanden — und die Auflösung liegt nicht darin, einen von beiden zu gewichten, sondern die Daten so zu trennen, dass jede Klasse ihre eigene Regel bekommt.

Ein Inventar, das stimmt

Alles in diesem Modul hängt an einer Liste: Wo entstehen Kopien? Diese Liste ist nach drei Monaten Betrieb regelmäßig unvollständig, weil Kopien an Stellen entstehen, die niemand als Speicher wahrgenommen hat.

• Jeder neue Speicher braucht einen Eintrag — als Teil der Definition of Done, nicht als nachträgliche Dokumentation.
• Jedes neue Werkzeug wird eingeordnet — welche Daten es liefert und ob sie personenbezogen sind.
• Eine Gegenprobe je Quartal — eine echte Löschanfrage im Testsystem, die durch alle Speicherorte läuft.
• Fehlende Einträge sind Befunde — was die Gegenprobe findet, gehört behoben und nicht nur ergänzt.

Die Gegenprobe ist der einzige Punkt, der das Inventar ehrlich hält. Ein Inventar ohne regelmäßigen Test ist eine Behauptung — und die Rechenschaftspflicht verlangt einen Nachweis, nicht eine Behauptung.

Ein zweiter Grund für unvollständige Inventare ist organisatorisch: Kopien entstehen dort, wo jemand ein Problem gelöst hat. Ein Zwischenspeicher für Werkzeugantworten, ein Export für eine Auswertung, eine Kopie der Trajektorien in ein Analysewerkzeug — alle drei sind vernünftige Entscheidungen, und keine davon fühlt sich beim Bauen wie das Anlegen eines Datenspeichers an. Deshalb gehört die Frage in die Prüfliste jeder Änderung: Entsteht hier eine Kopie, und wenn ja, wie lange bleibt sie?

Was der Check prüft

• Erkennen, an welchen Stellen ein Agentenlauf Kopien personenbezogener Daten erzeugt.
• Datenminimierung an der Werkzeugrückgabe umsetzen statt im Prompt.
• Eine Trajektorie so gestalten, dass sie nachvollziehbar und sparsam zugleich ist.
• Eine Aufbewahrungskonfiguration lesen und den Speicher finden, der darin fehlt.
• Abgeleitete Daten als personenbezogen behandeln, wenn sie es sind.
• Löschbarkeit beim Schreiben herstellen statt beim Löschverlangen zu suchen.
• Einen Zweckwechsel erkennen, bevor er als Nebenwirkung passiert.
• Die Verarbeitung beim Modellanbieter mit ihren Einschränkungen einplanen.
• Eine Zurechnungskette bis in die Zielsysteme durchziehen.

Der gemeinsame Nenner: Governance an einem Agenten ist keine Dokumentationsaufgabe, sondern eine Reihe von Entwurfsentscheidungen, die zum Zeitpunkt des Schreibens getroffen werden. Was beim Schreiben nicht mitgegeben wurde, ist später nicht mehr herstellbar.