Privatsphäre ist, was bleibt, nachdem das System vergessen gelernt hat

Das Recht auf Löschung ist kein Lösch-Button. In modernen Systemen ist es eine disziplinierte Frage nach Kopien, abgeleiteten Daten, Belegen, Ausnahmen und...

Privatsphäre ist, was bleibt, nachdem das System vergessen gelernt hat

Vergessen ist nicht das Gegenteil von Erinnern

Eine Papierakte hat ein beruhigend sichtbares Leben. Sie kommt an, wird irgendwo abgelegt, wird kopiert, wenn jemand einen Kopierer hat, und landet schließlich im Schredder oder im Archiv. Das Schwierige mag darin bestehen, zu entscheiden, ob sie vernichtet werden sollte, aber das Objekt selbst ist gefällig endlich. Ein digitaler Datensatz ist weniger höflich. Er kann als Zeile, als Anhang, als Suchindex, als Nachrichtenvorschau, als Sicherungsblock, als Audit-Eintrag, als Merkmal in einer Modelleingabe, als Vektor in einem Embedding-Speicher, als zwischengespeicherte Antwort oder als Wert gespeichert sein, der in das System einer anderen Organisation gelangt ist. Es reicht nicht, zu fragen, wo das Original lebt. Die nützlichere Frage ist, was daraus gemacht wurde, was es weiterhin ermöglicht, eine Person zu identifizieren, und welchem Zweck jede verbleibende Spur dient.

Das ist die praktische Würde im Recht auf Löschung. Es wird oft als Recht auf Vergessenwerden bezeichnet, ein anschaulicher, aber unvollkommener Ausdruck. Menschliches Vergessen ist zufällig, unvollständig und voller peinlicher Wiederkehr. Ein rechtmäßiger Löschprozess sollte bewusst erfolgen. Er sollte unterscheiden können zwischen einem Datensatz, der entfernt werden muss, und einem Datensatz, der aufbewahrt werden muss, weil das Gesetz es verlangt, einer bestrittenen Forderung, die für eine rechtliche Verteidigung verfügbar bleiben muss, und einem technischen Rest, der bis zu seinem geplanten Ablauf isoliert werden kann. Er sollte auch einem nützlichen Unternehmensinstinkt widerstehen: Löschung als Bildschirmzustand zu behandeln statt als Eigenschaft des Systems.

Die Datenschutz-Grundverordnung verspricht nicht, dass jeder mit einer Person verbundene Eintrag auf Anfrage verschwindet. Artikel 17 legt Gründe fest, aus denen ein Verantwortlicher personenbezogene Daten unverzüglich löschen muss, unter anderem wenn die Daten für den Zweck, für den sie erhoben oder verarbeitet wurden, nicht mehr notwendig sind, wenn die Einwilligung widerrufen wird und es keine andere Rechtsgrundlage gibt, und wenn die Verarbeitung unrechtmäßig war. Derselbe Artikel setzt Grenzen. Die Löschung gilt nicht, wenn die Verarbeitung beispielsweise für die Ausübung des Rechts auf freie Meinungsäußerung und Information, zur Erfüllung einer rechtlichen Verpflichtung, für im öffentlichen Interesse liegende Aufgaben unter bestimmten Umständen, aus Gründen des öffentlichen Gesundheitswesens, für Archivierungs-, Forschungs- oder Statistikzwecke unter bestimmten Garantien oder zur Geltendmachung rechtlicher Ansprüche erforderlich ist. Das ist keine Hintertür in einem Versprechen. Es ist die tatsächliche Form des Rechts.

Die Frage für einen Systembetreiber lautet also nicht: „Können wir Daten löschen?“ Fast jedes System kann etwas löschen. Die Frage ist, ob die Organisation für eine bestimmte Anfrage und einen bestimmten Verarbeitungszweck erklären kann, welche Daten sie hat, was mit diesen Daten geschehen ist, was sie aufbewahren muss oder darf, welche nachgelagerten Empfänger informiert werden müssen und wie die abgeschlossene Maßnahme überprüft werden kann. Der Unterschied klingt verfahrenstechnisch. In der Praxis ist er architektonisch. Ein Produkt, das nur weiß, wie man Informationen hinzufügt, wird feststellen, dass Löschung ein viel teureres Feature ist.

Das gilt besonders für KI-Systeme, ist aber nicht auf KI beschränkt. Suche, Analytik, Kundensupport, Identität, Sicherheitsüberwachung und Dokumentenverwaltung erzeugen alle Ableitungen. Ein Modell gibt dem Problem lediglich neue Namen: Tokens, Gradienten, Embeddings, Abruf-Indizes, Prompts und Ausgaben. Keiner dieser Begriffe löst die zugrunde liegende Frage auf, ob eine natürliche Person identifizierbar bleibt. Auch beantwortet ein Fachbegriff die rechtliche Frage nicht stillschweigend. Ein Embedding ist nicht automatisch anonym, weil es schwer zu lesen ist. Ein Protokoll ist nicht automatisch notwendig, weil es nützlich ist. Ein Backup ist nicht automatisch ausgenommen, weil es unbequem ist.

Privatsphäre nach dem Vergessen ist daher keine leere Seite. Es ist der Restzustand, der bleibt, nachdem eine Organisation eine rechtmäßige, verhältnismäßige und überprüfbare Entscheidung darüber getroffen hat, was nicht mehr verarbeitet werden soll. Die Qualität dieses Restzustands sagt den Menschen weit mehr über ein System als das Vorhandensein eines Löschknopfs es je tun wird.

Das Recht hat Bedingungen, und das macht es stärker

Das europäische Datenschutzrecht wird manchmal so beschrieben, als biete es dem Einzelnen einen universellen roten Knopf. Dieses Bild ist für eine Folie hübsch genug und falsch genug, um Probleme zu verursachen. Artikel 17 ist an den Zweck, die Rechtsgrundlage und die Umstände der Verarbeitung gebunden. Er enthält ein Recht, Pflichten für Verantwortliche und Ausnahmen, die andere Rechte und öffentliche Interessen schützen. Eine verantwortungsvolle Antwort beginnt damit, die Identität der anfragenden Person zu bestimmen, soweit dies erforderlich ist, die betroffenen Daten und den Verarbeitungszweck zu verstehen und zu entscheiden, ob ein Grund nach Artikel 17 und eine Ausnahme vorliegen. Die Antwort kann in der Löschung bestehen. Sie kann in einer begründeten Ablehnung ganz oder teilweise bestehen. Sie kann in der Einschränkung der Verarbeitung bestehen, während eine Streitigkeit beigelegt wird. Sie kann auch eine Anfrage betreffen, die auf ein System verweist, das die Organisation nicht kontrolliert.

Dies ist kein Grund, aus einer Anfrage einer betroffenen Person einen kleinen Hindernislauf zu machen. Die DSGVO verlangt von Verantwortlichen, die Ausübung der Rechte zu erleichtern. Artikel 12 verlangt, dass Informationen und Mitteilungen über Maßnahmen, die auf eine Anfrage hin ergriffen wurden, präzise, transparent, verständlich und leicht zugänglich sind. Er verlangt grundsätzlich, dass Informationen über ergriffene Maßnahmen unverzüglich und in jedem Fall innerhalb eines Monats nach Eingang der Anfrage bereitgestellt werden. Die Frist kann bei Bedarf um zwei weitere Monate verlängert werden, wobei die Komplexität und die Anzahl der Anfragen zu berücksichtigen sind, aber der Verantwortliche muss die Person innerhalb des ersten Monats über die Verlängerung und ihre Gründe informieren. Ein System, das seine eigenen Datenflüsse erst im dritten Monat identifizieren kann, hat keine verfahrensrechtliche Verteidigung gefunden. Es hat ein Governance-Problem gefunden.

Der Europäische Datenschutzausschuss macht in seinen Leitlinien für kleine und mittlere Unternehmen den operativen Punkt deutlich: Personen können unter bestimmten Umständen die Löschung verlangen, und Organisationen sollten Verfahren für die Bearbeitung von Anträgen auf Rechteausübung haben. Ein Verfahren ist keine Rechtsmeinung, die in einem gemeinsamen Laufwerk abgelegt ist. Es ist ein funktionierender Weg von der Anfrage zur Entscheidung zur Umsetzung. Es umfasst die Rollen, die eine Entscheidung treffen dürfen, die Datenzuordnungen, die es ihnen ermöglichen, die relevante Verarbeitung zu sehen, die Lieferanten und Empfänger, die möglicherweise benachrichtigt werden müssen, die Aufbewahrungsfristen, die eine Ausnahme erklären, und die Nachweise, die es einem späteren Prüfer ermöglichen, zu verstehen, was getan wurde.

Der Gerichtshof hat dazu beigetragen, eine weitere Unterscheidung sichtbar zu machen. Seine Urteile zur Dereferenzierung betreffen die Darstellung von Links durch Suchmaschinen, nicht eine Anweisung, die zugrunde liegende Veröffentlichung von der Quellwebsite zu löschen. In der Rechtssache Google Spain entschied der Gerichtshof, dass ein Betreiber einer Suchmaschine für die Verarbeitung personenbezogener Daten verantwortlich sein kann, die auf von Dritten veröffentlichten Webseiten erscheinen, und dass eine betroffene Person unter bestimmten Umständen die Entfernung von Links aus einer Ergebnisliste verlangen kann, die nach einer Suche nach dem Namen der Person angezeigt wird. In späteren Fällen befasste sich der Gerichtshof unter anderem mit sensiblen Daten, der territorialen Reichweite der Dereferenzierung und unrichtigen Informationen. Diese Fälle machen aus jeder unliebsamen Tatsache keinen Löschungsanspruch. Sie zeigen, warum ein System die betroffene Ebene benennen muss: Quellveröffentlichung, Index, Ergebnisliste, Cache, Auszug oder eine andere Kopie.

Diese Ebenendisziplin ist auch innerhalb von Organisationen wichtig. Ein Mitarbeiter kann einen Verantwortlichen bitten, einen Kontaktdatensatz zu löschen, der für einen Rekrutierungszweck nicht mehr benötigt wird. Der Verantwortliche muss möglicherweise eine separate Aufbewahrungspflicht für Gehaltsabrechnungs- oder Gleichbehandlungsnachweise prüfen. Eine öffentliche Stelle kann einen Datensatz im Rahmen einer gesetzlichen Aufgabe verarbeiten und muss das anwendbare Recht prüfen, anstatt eine Antwort aus dem Privatsektor zu wiederholen. Ein Verleger muss möglicherweise die Meinungs- und Informationsfreiheit abwägen. Das Ergebnis kann nicht allein durch die Datenbank-Terminologie entschieden werden.

Es ist verlockend, die Bedingungen zu beklagen, weil sie ein einfaches Versprechen verhindern. Aber sie machen das Versprechen bedeutsam. Ein Recht, das rechtliche Pflichten, andere Grundrechte und die praktischen Unterschiede zwischen Systemen ignoriert, würde zu einer bloßen Zeremonie verkommen. Der europäische Ansatz verlangt eine rechenschaftspflichtige Entscheidung, keine theatralische. Das erfordert mehr Aufwand. Es macht eine Ablehnung aber auch anfechtbar und eine Löschung glaubwürdig.

Löschung beginnt damit, die Verarbeitungsorte zu ermitteln. Das Diagramm ist eine Systemkarte, keine Aussage darüber, dass jeder Ort rechtlich gleich behandelt wird.

Ein Datensatz kann vom Bildschirm verschwinden und im System bleiben

Der einfachste Löschfehler ist jedem bekannt, der eine Anwendung entwickelt hat: Ein Element aus der Produktoberfläche entfernen, die zugrunde liegenden Daten im Speicher belassen und annehmen, die Aufgabe sei erledigt, weil normale Nutzer es nicht mehr sehen können. Manchmal ist ein Soft Delete genau das richtige operative Design. Es kann eine kurze Rückgängig-Phase ermöglichen, die Replikation sicherer machen oder vermeiden, dass eine Beziehung, die noch aufgelöst werden muss, bricht. Aber Soft Delete ist nicht allein deshalb eine Löschung, weil die Oberfläche ruhiger geworden ist. Seine Verwendung muss mit einem definierten Zweck, einer Aufbewahrungsfrist, Zugriffskontrollen und einer späteren Aktion verbunden sein, die den Datenzustand tatsächlich verändert.

Hard Delete hat seine eigenen Grenzen. Das Löschen einer Zeile kann einen Suchindex bis zum nächsten Indexierungszyklus zurücklassen. Ein Objektspeicher kann eine Versionsverwaltung haben. Ein Content-Delivery-Cache kann eine Antwort bis zum Ablauf oder zur Ungültigmachung vorhalten. Eine Nachrichtenwarteschlange kann ein Ereignis enthalten, das noch nicht verarbeitet wurde. Ein Data Warehouse kann einen Snapshot aufgenommen haben. Ein Dienst kann die Daten an einen Auftragsverarbeiter, einen Unterauftragsverarbeiter oder einen Empfänger übertragen haben. Die praktische Lehre ist nicht, dass Löschung unmöglich ist. Sie ist, dass eine Organisation ein Inventar benötigt, das genau genug ist, um diese Orte zu unterscheiden, und eine Richtlinie, die festlegt, was an jedem einzelnen Ort geschieht.

Es gibt eine weitere Unterscheidung zwischen Inhalt und Nachweis. Ein Kundendienst-Ticket kann die Nachricht einer Person enthalten. Ein System kann einen Nachweis benötigen, dass ein Ticket existierte, gelöst und nach einer genehmigten Regel gelöscht wurde. Die gesamte Nachricht für immer aufzubewahren, um zu beweisen, dass sie gelöscht wurde, ist ein kleines bürokratisches Meisterstück, aber keine Datenschutzkontrolle. Ein besseres Design bewahrt nur den minimalen Nachweis auf, der für die Rechenschaftspflicht nötig ist, getrennt von den Inhalten, die keinen Zweck mehr haben. Dieser Nachweis könnte eine Anfragekennung, den Entscheidungstyp, den Zeitpunkt der Fertigstellung, die anwendbare Aufbewahrungskategorie und die erreichten Systeme umfassen. Das Design hängt von der Organisation ab. Das Prinzip nicht: Ein Nachweis sollte die unnötigen personenbezogenen Daten nicht neu erschaffen.

Backups verdienen dieselbe klare Sprache. Ein Backup kann für Verfügbarkeit, Sicherheit oder Notfallwiederherstellung notwendig sein. Es ist dennoch eine Verarbeitung. Die praktische Frage ist, ob das Backup separat zugänglich ist, wie lange es wiederherstellbar bleibt, wer es wiederherstellen kann, ob es in den normalen Löschablauf einbezogen ist und wie verhindert wird, dass eine wiederhergestellte Umgebung Daten, die inzwischen aus dem Live-System entfernt wurden, stillschweigend wieder einführt. Eine vernünftige Richtlinie kann sich auf den definierten Rotationszeitraum des Backups stützen, statt jeden historischen Backup-Block einzeln zu verändern. Aber eine Richtlinie muss dies klarstellen, den Zugriff in der Zwischenzeit schützen und sicherstellen, dass die Wiederherstellung nach Möglichkeit dem aktuellen Datenzustand folgt. „Es ist im Backup“ beschreibt ein Problem. Es ist keine Antwort darauf.

Logs sind ähnlich gelagert. Sicherheits- und Betriebslogs können unverzichtbar sein. Sie sind unter Umständen der einzige Nachweis über einen Zugriff, einen fehlgeschlagenen Authentifizierungsversuch oder eine Produktionsänderung. Sie können aber auch Kennungen, Adressen, Anforderungsinhalte oder Textfragmente enthalten, die für die Diagnose nie benötigt wurden. Ein gutes Logging-Design minimiert bereits bei der Erfassung, pseudonymisiert oder schwärzt, wo dies angemessen ist, trennt sensible Nutzdaten von Ereignismetadaten, beschränkt den Zugriff und sieht Aufbewahrungsfristen vor. Bei einem Löschungsersuchen jeden sensiblen Datenbestand aufzuspüren, ist zwar möglich, aber ein schlechter Ersatz dafür, bereits beim Design festzulegen, was das Log niemals hätte enthalten dürfen.

Ein technisch Verantwortlicher muss nicht sofortiges, einheitliches Löschen auf allen Geräten zusagen, um verantwortungsvoll zu handeln. Er muss aber den Lebenszyklus benennen können: Was wird sofort unzugänglich, was wird im nächsten Verarbeitungslauf entfernt, was bleibt unter einer dokumentierten Aufbewahrungsfrist bestehen, was bleibt bis zum Ablauf geschützt, und was geschieht, falls eine Wiederherstellung stattfindet. Diese Darstellung gibt einer Person, einer Aufsichtsbehörde und einem Betreiber etwas Konkretes an die Hand. Eine grüne Bestätigungsmeldung gibt ihnen sehr wenig.

Abgeleitete Daten sind kein Ausweg

Moderne Systeme transformieren personenbezogene Daten häufig, bevor sie sie verwenden. Sie extrahieren ein Datum aus einem Dokument, klassifizieren eine Nachricht, berechnen einen Wert, leiten eine Sprache ab, erstellen einen Suchindex, erzeugen eine Zusammenfassung, verknüpfen zwei Konten oder wandeln Text und Bilder in Vektoren für die Ähnlichkeitssuche um. Diese Transformationen können nützlich sein. Sie können aber auch den Eindruck erwecken, dass sich eine Organisation über personenbezogene Daten hinausbewegt hat. Das ist nicht zwangsläufig der Fall.

Die DSGVO ist technologieneutral. Ihre Erwägungsgründe erläutern, dass pseudonymisierte Daten, die einer natürlichen Person durch Hinzuziehung zusätzlicher Informationen zugeordnet werden könnten, als Informationen über eine identifizierbare natürliche Person zu betrachten sind. Sie erläutern außerdem, dass bei der Bestimmung der Identifizierbarkeit alle Mittel zu berücksichtigen sind, die vom Verantwortlichen oder einer anderen Person nach allgemeinem Ermessen wahrscheinlich genutzt werden, etwa Kosten, Zeitaufwand, verfügbare Technologie und technologische Entwicklungen. Die Frage ist nicht, ob eine Darstellung wie ein Name in einer Tabelle aussieht. Die Frage ist, ob sie sich in der tatsächlichen Situation auf eine identifizierte oder identifizierbare Person bezieht.

Ein Embedding macht diesen Punkt auf lehrreiche Weise unbequem. In einem Abrufsystem kann ein Dokument in Abschnitte unterteilt und als numerische Vektoren dargestellt werden, damit eine Abfrage semantisch ähnliches Material finden kann. Der Vektor ist kein lesbarer Absatz. Er kann jedoch mit einem Quelldokument, einem Mandanten, einem Benutzer, einer Zugriffskontrolle, einem Metadatenfeld oder einem Abrufschlüssel verknüpft sein. Er kann es dem System ermöglichen, als Reaktion auf eine Abfrage personenbezogenes Material auszuwählen. Die Organisation kann ihn nicht allein deshalb als anonym bezeichnen, weil ein Mensch aus einer Koordinatenliste keinen Satz rekonstruieren kann. Sie muss die Darstellung, die zugehörigen Daten, die Verknüpfungsmöglichkeiten und den Verarbeitungszweck bewerten.

Dasselbe gilt für einen abgeleiteten Wert. Ein Risikowert, eine Präferenzkategorie oder ein Eignungsindikator kann weniger Rohdetails enthalten als die Quelldaten und dennoch erhebliche Auswirkungen auf die Person haben. Es kann sich um personenbezogene Daten handeln, wenn sie sich auf eine identifizierte oder identifizierbare Person beziehen. Die Quelldaten zu löschen, während ein Wert erhalten bleibt, der weiterhin eine Entscheidung beeinflusst, ist keine saubere Lösung. Es kann die Person lediglich in eine undurchsichtigere Form überführen. Das System benötigt eine Regel für abgeleitete Daten: welche zusammen mit der Quelle gelöscht werden, welche neu berechnet werden, welche nicht mehr verwendet werden dürfen, welche aufgrund einer separaten Pflicht aufbewahrt werden müssen und wer darüber entscheidet.

Es gibt keinen universellen technischen Test, der jeden Derivatanfall abschließend klärt. Manche aggregierten Statistiken können anonym sein. Manche können weiterhin anfällig für Einzelidentifizierung oder Verknüpfung sein. Manche Modellparameter lassen sich in einem bestimmten Kontext möglicherweise nicht vernünftig einer Einzelperson zuordnen. Andere können mit Trainingsdaten, einem eng begrenzten Modell oder einer Angriffsfläche verbunden sein, die die Bewertung verändert. Das Konzept der anonymen Informationen in der DSGVO ist kein dekoratives Etikett für Daten, deren Interpretation man unbequem gemacht hat. Der Verantwortliche muss eine Bewertung vornehmen, die auf den Mitteln und dem Kontext der Identifizierung beruht.

Diese Unsicherheit ist kein Grund, jeden Derivatanfall als dauerhaft problematisch zu beschreiben. Sie ist ein Grund, die Herkunft nachzuvollziehen. Ein Team sollte wissen, welche Eingabesammlungen für einen Feature-Store, einen Index, einen Trainingslauf oder eine Berichtstabelle verwendet wurden; welche Versionen eines Derivats erzeugt wurden; welche Systeme diese konsumieren; und welche Reaktion eine Änderung an der Quelle auslösen muss. Die Nachvollziehbarkeit der Herkunft verwandelt eine unbequeme Frage in eine klar umrissene technische Aufgabe. Ohne sie wird jede Anfrage zu Rechten zu einer archäologischen Expedition durch Jobnamen, Storage-Buckets und die Erinnerung von jemandem an eine Migration vor zwei Wintern.

Maschinelles Lernen wirft eine schwierige Frage auf, keine magische Ausnahme

Maschinelles Lernen erschwert die Löschung, weil Training kein Ablagevorgang ist. Ein Trainingsbeispiel kann Parameter über eine lange Abfolge von Aktualisierungen hinweg beeinflussen, zusammen mit vielen anderen Beispielen. Ein eingesetztes Modell kann in mehrere Umgebungen kopiert worden sein. Ein späteres Modell kann auf der Grundlage eines früheren verfeinert worden sein. Ein Team kann Auswertungsdaten, Prompts, Abruf-Korpora und Feedback-Protokolle verwenden, die jeweils unterschiedlichen Lebenszyklen folgen. Wenn die Daten einer Person in ein solches System gelangt sind, kann eine Organisation nicht verantwortungsvoll mit einem Achselzucken über die Mathematik antworten. Sie kann auch nicht ehrlich versprechen, dass eine Löschung in einer Datenbank jeden möglichen Einfluss auf jeden Parameter beseitigt.

Der erste Schritt ist die Trennung der Systeme. Ein Abruf-Korpus ist kein trainiertes Modell. Wenn ein Dokument als Quelle für den Abruf dient, kann die Löschung das Entfernen oder Deaktivieren des Dokuments, seiner Textabschnitte, Metadaten und Indexeinträge umfassen, gefolgt von einer Prüfung, dass der Abruf es nicht mehr erreicht. Ein Prompt-Protokoll ist kein Embedding-Speicher. Ein Feintuning-Datensatz ist kein Sicherheits-Audit-Trail. Ein Modell-Checkpoint ist kein aktueller Quelldatensatz. Die richtige Reaktion kann für jede Oberfläche unterschiedlich sein, aber eine Reaktion kann erst gestaltet werden, wenn die Oberflächen benannt sind.

Für Trainingsdaten kann die rechtliche und technische Analyse eine Entscheidung darüber erfordern, ob ein erneutes Training, ein Ersatz, eine Einschränkung, eine Aufbewahrung oder eine andere Maßnahme angemessen ist. Forschung zum maschinellen Verlernen ist relevant, weil sie Methoden untersucht, um den Einfluss bestimmter Daten zu verringern, ohne ein Modell von Grund auf neu zu trainieren. Sie ist kein allgemeiner Nachweis, dass ein System vergessen hat. Methoden haben Annahmen, Modellklassen, Datenbedingungen und Verifikationsgrenzen. Eine Organisation sollte eine experimentelle Technik nicht als universelle Umsetzung von Artikel 17 vermarkten. Sie sollte auch nicht auf eine perfekte Technik warten, bevor sie bessere Datenkontrollen entwirft.

Bessere Kontrollen beginnen vorgelagert. Minimieren Sie die erhobenen Daten. Trennen Sie personenbezogene Daten von Trainingsmaterial, wo es der beabsichtigte Zweck erlaubt. Legen Sie eine Aufbewahrungsfrist fest, bevor die Anhäufung die Frage emotional kostspielig macht. Führen Sie versionierte Aufzeichnungen über Datensätze und Trainingsläufe. Machen Sie Opt-in oder andere rechtmäßige Bedingungen explizit, wo sie die relevante Grundlage sind. Vermeiden Sie, dass ein Produktions-Prompt-Archiv stillschweigend zu einem Korpus für die Modellentwicklung wird. Halten Sie Auswertungs- und Supportmaterial von Trainingsdaten unterscheidbar. Je weniger ein System auf unbekannte Herkunft angewiesen ist, desto präziser kann es eine Löschungsfrage beantworten.

Auch das Wort „Einfluss“ hat seine Grenzen. Eine Person mag besorgt sein, dass ein Text einmal Teil eines Trainingsdatensatzes war. Ein technisches Team kann möglicherweise feststellen, dass der Quelldatensatz aus einem aktuellen Korpus entfernt wurde, aber nicht im weiten philosophischen Sinne belegen, dass kein Fragment von Einfluss in irgendeinem Parameter eines historischen Modells verbleibt. Datenschutzrecht wird nicht einfacher, wenn eine Organisation eine konkrete Beschreibung durch Metaphysik ersetzt. Die Verpflichtung besteht darin, die Verarbeitung, die Rechtsgrundlagen und die Maßnahmen nach dem Gesetz zu bewerten. Die Organisation sollte den Umfang ihrer Schlussfolgerung, die abgedeckten Systeme und die verbleibende Einschränkung erläutern. Präzision ist freundlicher als ein übertriebenes Versprechen.

Für KI-Bereitsteller liegt die praktische Last oft ebenso sehr im Beschaffungswesen wie in der Technik. Ein Anbieter sollte erklären können, was er mit Eingabeaufforderungen, hochgeladenen Dateien, Telemetriedaten und optionalem Feedback tut; welche davon für Training oder Dienstverbesserung verwendet werden; welche Aufbewahrungskontrollen existieren; wie ein Kunde Informationen erhalten kann, die zur Beantwortung von Anträgen auf Rechteausübung erforderlich sind; und was in einer gemeinsamen im Vergleich zu einer dedizierten Umgebung geschieht. Ein Vertrag, der lediglich „DSGVO-konform“ sagt, hat nicht die Informationen geliefert, die für den Betrieb eines Löschungsprozesses erforderlich sind. Er hat ein Adjektiv geliefert.

Suchmaschinen lehren eine nützliche Lektion über Ebenen

Die Rechtsprechung des Gerichtshofs zur Dereferenzierung ist hier gerade deshalb nützlich, weil sie enger ist als der populäre Begriff „Recht auf Vergessenwerden“. Die Fälle betreffen die Frage, ob und unter welchen Bedingungen eine Suchmaschine Links aus namensbezogenen Ergebnissen entfernen muss. Sie schaffen keine einfache Befugnis, die Geschichte an ihrer Quelle zu verändern. Diese Unterscheidung zeigt, dass es bei Datenschutzfragen oft darum geht, wie Informationen verfügbar gemacht, verknüpft und verstärkt werden, nicht nur darum, ob ein Datensatz einmal existierte.

In Google Spain befasste sich der Gerichtshof mit Links in der Ergebnisliste einer Suchmaschine zu Seiten, die von einem Dritten veröffentlicht wurden. Die Entscheidung stellte klar, dass die Tätigkeit einer Suchmaschine eine Verarbeitung personenbezogener Daten darstellen kann und dass der Betreiber unter bestimmten Bedingungen verpflichtet sein kann, Links aus Ergebnissen zu entfernen, die nach einer Suche nach dem Namen einer Person angezeigt werden. Die Entscheidung war kein Auftrag an die Zeitung, die die ursprünglichen Bekanntmachungen veröffentlicht hatte. Ein Systembetreiber, der auf eine interne Wissensdatenbank blickt, kann daraus lernen: Suchindizes, Vorschauen und Ergebnisranking sind Verarbeitungsebenen mit eigenen Konsequenzen.

GC and Others befasste sich mit Anträgen auf Entfernung von Links zu Webseiten mit sensiblen personenbezogenen Daten. Der Gerichtshof befasste sich mit der erforderlichen Abwägung und den Pflichten, die für einen Suchmaschinenbetreiber entstehen können. Google v CNIL befasste sich mit der territorialen Reichweite und entschied unter den Umständen jenes Falles, dass das EU-Recht keine Dereferenzierung auf allen Versionen einer Suchmaschine weltweit verlangte, während wirksame Maßnahmen erforderlich waren, um den Zugriff aus Mitgliedstaaten auf Links, die aus EU-Versionen entfernt wurden, zu verhindern oder ernsthaft zu erschweren. TU and RE betraf einen Antrag in Bezug auf angeblich unrichtige Informationen und klärte Elemente der Beweislast und die Behandlung von Vorschaubildern. Diese Urteile sind sachverhaltsbezogene Rechtsentscheidungen, keine Bereitstellungs-Checkliste. Zusammen machen sie einen systemischen Punkt: Der Link, die Ergebnisliste, das Bildvorschaubild und die ursprüngliche Seite haben nicht automatisch denselben Rechtsbehelf.

Dieser Punkt überträgt sich gut. Ein Unternehmensportal kann einen Quelldatensatz rechtmäßig für einen begrenzten Zweck aufbewahren, während der Zugriff über eine breite Suchoberfläche unverhältnismäßig ist. Ein technisches Supportsystem benötigt möglicherweise einen geschützten Prüfprotokolleintrag, während seine Autovervollständigungsvorschau die Daten eines ehemaligen Kunden nicht einer großen Gruppe anzeigen sollte. Ein Dokument könnte aus einem Abrufkorpus entfernt werden, während eine modellgenerierte Zusammenfassung in einem anderen Speicher verbleibt. Die richtige Antwort besteht nicht darin, jede Ebene für identisch zu erklären. Sie besteht darin, zu verstehen, wie die Ebene Exposition, Zweck und Risiko verändert.

Die Behörde warnt zudem vor einem verbreiteten Kurzschluss: Sichtbarkeit als einziges Datenschutzproblem zu betrachten. Ein Datensatz kann technisch verborgen sein und dennoch verarbeitet, abgefragt, profiliert, übertragen oder wiederhergestellt werden. Umgekehrt kann eine Organisation einen sorgfältig begrenzten Datensatz benötigen, um nachzuweisen, dass sie ordnungsgemäß reagiert hat, einen Rechtsanspruch zu wahren oder einer gesetzlichen Pflicht nachzukommen. Datenschutz ist kein Wettbewerb darum, in jeder erdenklichen Situation möglichst wenige Daten zu erzeugen. Er ist eine Disziplin aus Zweck, Erforderlichkeit, Verhältnismäßigkeit und Kontrolle.

Deshalb sollte ein Löschungsverzeichnis auch Abruf- und Darstellungspfade umfassen. Es sollte klären, welche Indizes den Datensatz führen, welche Caches ihn ausliefern, welche Exporte ihn enthalten, welche APIs ihn zurückgeben, welche abgeleiteten Felder für Ranking oder Empfehlungen genutzt werden und welche Backup-Wiederherstellungspfade ihn wieder aktivieren könnten. Die Liste wird nicht elegant sein. Sie wird nützlicher sein als Eleganz.

Nachweis ist etwas anderes als Behauptung

Wenn ein System behauptet, Daten löschen zu können, stellen sich zwei getrennte Fragen. Die erste ist, ob das Design einen legitimen, dokumentierten Weg dafür vorsieht. Die zweite ist, ob eine Organisation nachweisen kann, dass dieser Weg bei einer bestimmten Anfrage eingehalten wurde, ohne mehr personenbezogenes Material aufzubewahren, als der Nachweis erfordert. Das erste ist eine Produkteigenschaft. Das zweite ist Rechenschaftspflicht.

Ein nützliches Löschungsprotokoll ist bewusst bescheiden. Es muss nicht die gesamte Anfrage, Dokumente oder Kontohistorie einer Person in einer neuen Compliance-Datenbank reproduzieren. Es kann eine Anfragenreferenz, das Ergebnis der Identitätsprüfung, sofern angemessen, die Kategorie der Anfrage, betroffene Systeme, die Entscheidung und die rechtliche Begründung auf angemessener Ebene, Handlungsdaten, Ausnahmen oder Aufbewahrungsgründe, Benachrichtigungen an Empfänger, sofern erforderlich, sowie den Status der asynchronen Löschung oder des Backup-Ablaufs festhalten. Die genauen Felder hängen vom Verantwortlichen und vom Kontext ab. Entscheidend ist, dass eine spätere Prüfung den Weg nachvollziehen kann, ohne die sensiblen Inhalte aus Fragmenten rekonstruieren zu müssen.

Die Überprüfung sollte der Datenoberfläche entsprechen. Ein Datensatz in einer Live-Anwendung kann geprüft werden, indem bestätigt wird, dass eine autorisierte Abfrage ihn nicht mehr zurückgibt. Ein Abrufsystem kann mit der ursprünglichen Kennung und relevanten Abfragemustern getestet werden, ohne breite Versuche zu unternehmen, personenbezogene Inhalte zu rekonstruieren. Ein Index kann seinen Löschungsstatus melden. Eine Warteschlange kann den Abschluss anzeigen. Ein Backup-Prozess kann zeigen, dass ein Wiederherstellungsabbild unter seiner Aufbewahrungsregel geschützt ist und dass die Wiederherstellung ein aktuelles Löschungsverzeichnis oder eine gleichwertige Kontrolle anwendet. Die Überprüfung muss keine metaphysische Negation beweisen. Sie muss Belege liefern, die der gemachten Aussage angemessen sind.

Hier lauert eine kleine Falle. Ein Team kann ein beeindruckendes Dashboard bauen, auf dem alles grün leuchtet, ohne dass es eine stabile Beziehung zur tatsächlichen Arbeit hat. Ein aussagekräftiges Dashboard benennt Datenoberfläche, Aktion, Status, Verantwortlichen, Beleg und nächste Überprüfung. Es ermöglicht, zwischen „Anfrage angenommen“, „Live-Datensatz gelöscht“, „Benachrichtigung an Empfänger ausstehend“, „Backup wartet auf Ablauf“ und „aus rechtlichen Gründen aufbewahrt“ zu unterscheiden. Diese Status haben unterschiedliche Bedeutungen. Sie zu „gelöscht“ zusammenzufassen, verwandelt Unsicherheit in User-Interface-Design.

Nachweisbare Löschung hängt auch vom Änderungsmanagement ab. Ein Quellsystem kann ersetzt, ein Auftragsverarbeiter hinzugefügt, ein Indexformat geändert, ein neues Analyseziel eingeführt oder die Aufbewahrungsrichtlinie eines KI-Anbieters überarbeitet werden. Wenn das Löschungsverfahren nicht an diese Änderungen angepasst wird, beschreibt das Verfahren nach und nach ein System, das es nicht mehr gibt. Das Ergebnis ist aus jeder operativen Disziplin bekannt: ein schönes Runbook und ein realer Dienst, die sich in entgegengesetzte Richtungen bewegen. Regelmäßig eine kleine Stichprobe des Pfads zu testen, einschließlich des sperrigen Systems, ist meist aufschlussreicher, als ein großes Assurance-Dokument zu beauftragen, das niemand ausführen kann.

Für eine öffentliche Behörde oder ein reguliertes Unternehmen ist dies kein enges Datenschutzthema. Die Datenschutzbeauftragte oder der Datenschutzbeauftragte mag die Auslegung anleiten, aber die Technik verantwortet Schnittstellen und Löschmechanik, das Produkt verantwortet Zweck und Nutzerpfad, der Einkauf verantwortet die Informationspflichten gegenüber Lieferanten, die Sicherheit verantwortet Zugriffs- und Wiederherstellungskontrollen, und der Betrieb verantwortet die Umsetzung unter Druck. Eine einzelne verantwortliche Person kann nicht jede Ebene allein prüfen. Eine Ebene ohne Verantwortung wird nicht dadurch sicher, dass es schwer ist, über sie zu sprechen.

Ein verteidigungsfähiger Prozess hält Entscheidung und Umsetzung fest, ohne eine zweite, unnötige Biografie der Person zu schaffen.

Aufbewahrung ist die andere Hälfte des Löschens

Viele Löschprobleme beginnen lange vor einer Anfrage. Sie beginnen, wenn ein System überhaupt keine Aufbewahrungsentscheidung hat. Daten kommen an, weil sie vielleicht nützlich werden könnten. Protokolle werden dauerhaft, weil Speicher billig ist. Exporte werden behalten, weil eine künftige Prüfung vielleicht danach fragt. Trainingsdaten werden angesammelt, weil ein späteres Modell davon profitieren könnte. Jede Entscheidung wirkt für sich genommen harmlos. Zusammen machen sie aus einer Organisation die Eigentümerin eines großen, schlecht verstandenen Archivs und verteuern jede Löschungsanfrage, machen sie unsicherer und streitanfälliger.

Der Grundsatz der Speicherbegrenzung in der DSGVO besagt, dass personenbezogene Daten in einer Form aufbewahrt werden sollten, die die Identifizierung betroffener Personen nur so lange ermöglicht, wie es für die Zwecke, für die sie verarbeitet werden, erforderlich ist, vorbehaltlich einer längeren Speicherung für im öffentlichen Interesse liegende Archivzwecke, für wissenschaftliche oder historische Forschungszwecke oder für statistische Zwecke, sofern geeignete Garantien bestehen. Der Grundsatz schreibt nicht einen einzigen Kalender für jede Organisation vor. Er verlangt ein Urteil, das an den Zweck gebunden ist. Ein Aufbewahrungsplan sollte daher Datenkategorien, Zweck, Rechtsgrundlage, übliche Frist, Auslöseereignis, Ausnahme, Vernichtungsmaßnahme, Verantwortliche oder Verantwortlichen und Überprüfungszeitpunkt benennen. „So lange wie nötig“ ist ein Grundsatz. Er wird erst dann zu einer operativen Regel, wenn jemand sagen kann: nötig wofür, bis wann und entschieden von wem.

Diese Struktur ist für KI hilfreich, weil sie verhindert, dass ein breites Etikett wie Trainingsdaten mehrere verschiedene Dinge verdeckt. Ein Rohbeitrag, ein bereinigter Datensatz, ein Merkmalssatz, eine Modellversion, ein Verlauf von Eingabeaufforderungen, ein Auswertungssatz und ein Überwachungsprotokoll können jeweils unterschiedliche Zwecke und Aufbewahrungserwägungen haben. Sie in einem einzigen unbestimmten Behälter zusammenzufassen, verschlechtert sowohl Innovation als auch Rechenschaftspflicht. Sie zu trennen, garantiert keine rechtliche Antwort, macht sie aber möglich.

Aufbewahrungsentscheidungen profitieren auch von einer Verweigerungsbedingung. Was würde uns dazu bringen, diese Daten nicht mehr aufzubewahren? Ein abgeschlossener Vertrag, ein beigelegter Streit, das Ende einer gesetzlichen Frist, eine abgeschlossene Sicherheitsuntersuchung, eine ersetzte Modellversion, das Ablaufen eines Wiederherstellungsfensters oder die Entscheidung, einen Forschungszweck nicht weiterzuverfolgen, können allesamt echte Auslöser sein. Es geht nicht darum, für alles eine Löschuhr zu automatisieren. Es geht darum, ein System zu vermeiden, in dem die einzige Bedingung für das Aufbewahren von Daten darin besteht, dass noch niemand verlangt hat, sie zu erklären.

Es gibt hier einen kleinen niederländischen Instinkt, den es zu bewahren lohnt: Ein Schrank ist nicht deshalb aufgeräumt, weil er eine Tür hat. Er ist aufgeräumt, weil man das Relevante finden, wissen kann, warum es dort ist, und es entfernen kann, ohne umzuziehen. Ein Datenbestand verdient mindestens diesen Standard. Ein Aufbewahrungsplan, der einem Gespräch mit den Menschen, die das System betreiben, nicht standhält, ist kein Plan. Er ist eine Wettervorhersage in Rechtssprache.

Das bedeutet nicht, dass jede Organisation jede Löschungsentscheidung zentralisieren muss. Lokale Teams verstehen ihre Prozesse oft besser. Es bedeutet, dass lokale Regeln gemeinsame Konzepte, sichtbare Verantwortlichkeit und einen Weg zur Eskalation benötigen. Andernfalls ist das Archiv des einen Teams die Verletzung eines anderen, und die Anfrage einer Person wird durch ein Labyrinth höflich benannter Dienste geleitet.

Was ein ehrlicher KI-Anbieter sagen kann

Ein ehrlicher KI-Anbieter behauptet nicht, dass alle Kundendaten verschwinden, sobald eine Anfrage eintrifft. Er versteckt sich auch nicht hinter der Schwierigkeit von Modellen. Er beschreibt die Grenze des Dienstes. Was für die Inferenz verarbeitet wird. Was für Kontoverwaltung, Sicherheit, Support, Abrechnung oder Missbrauchsprävention aufbewahrt wird. Ob Eingaben und Ausgaben gespeichert werden. Ob sie für Training, Evaluierung oder Dienstverbesserung verwendet werden. Welche Prozessoren und Regionen beteiligt sind. Wie Kunden die Aufbewahrung konfigurieren können. Welche Dokumentation für Anfragen betroffener Personen existiert. Welche Maßnahmen sofort erfolgen, welche asynchron sind und welche von einer separaten rechtlichen Prüfung abhängen.

Für Käufer sind die Beschaffungsfragen praktisch. Können wir eine klare Datenflusskarte erhalten? Können wir die Rollen von Verantwortlichem und Auftragsverarbeiter für die relevante Verarbeitung identifizieren? Können wir Material in brauchbarer Form exportieren oder löschen? Sind Abruf-Indizes und abgeleitete Speicher im dokumentierten Lebenszyklus enthalten? Was passiert mit Sicherungskopien? Wie werden Änderungen an Unterauftragsverarbeitern kommuniziert? Kann der Anbieter uns helfen, innerhalb des geltenden Zeitrahmens auf eine Anfrage zu antworten? Sind Trainings- und Dienstverbesserungsnutzungen Opt-in, Opt-out, vertraglich ausgeschlossen oder nur auf einer Seite beschrieben, die sich nach dem Kauf ändern kann? Welche technischen Aufzeichnungen sind verfügbar, um Maßnahmen nachzuweisen?

Die Antworten werden variieren. Ein großer gemeinsamer Dienst kann nicht immer dieselbe Kontrolle bieten wie eine dedizierte Umgebung. Ein Sicherheitsprotokoll kann nicht immer im selben Moment wie ein Kontoprofil gelöscht werden. Ein gesetzliches Archiv kann nicht wie eine Verbraucherpräferenz behandelt werden. Diese Unterschiede sind nicht unbedingt Fehler. Stillschweigen darüber ist es. Die richtige Reaktion des Käufers ist, das dokumentierte Verhalten des Dienstes mit dem Zweck, den Pflichten und dem Risiko der Organisation abzugleichen. Ein Produkt kann für eine hochsensible Aufgabe ungeeignet sein, selbst wenn es für ein risikoarmes Entwurfswerkzeug vollkommen geeignet ist.

Bei Dweve vertritt unser Trust Centre dieselbe enge Auffassung von Nachweisen. Eine öffentliche Seite kann Kontrollen und Dokumentationsgrenzen beschreiben, aber sie kann nicht jede Kundenbereitstellung zertifizieren oder die Rechtsgrundlage für die Verarbeitung eines Kunden festlegen. Diese Grenze ist wichtig. Eine Plattform kann Aufbewahrungskontrollen, Aufzeichnungen und überprüfbare Arbeitsabläufe unterstützen. Die Organisation, die sie nutzt, trägt weiterhin die Verantwortung für ihren Zweck, ihre Datenentscheidungen und die Entscheidung, auf eine bestimmte Person zu antworten. Gute Produkttexte sollten diese Verantwortung klarer machen, nicht stillschweigend übernehmen.

Die wertvollste Aussage eines Anbieters ist oft eine Einschränkung. „Dieser Datensatz verbleibt in geschützten Sicherungskopien, bis der angegebene Rotationszeitraum endet.“ „Dieser Dienst verwendet die angegebenen Kundeninhalte unter diesen Bedingungen nicht für Training.“ „Dieser Index wird asynchron entfernt, und der Status kann hier überprüft werden.“ „Wir können diese Aussage für eine Drittanbieter-Integration nicht machen.“ Diese Sätze mögen weniger magisch erscheinen als ein universelles Datenschutzversprechen. Sie ermöglichen es einem Käufer, einen echten Prozess zu gestalten.

Fragen, die sich lohnen, bevor die Anfrage eintrifft

Eine Organisation muss keinen Datenschutzverstoß, keinen belasteten Menschen oder einen heldenhaften Vorfall mitten in der Nacht erfinden, um ihr Löschkonzept zu testen. Sie kann während der regulären Arbeitszeit eine klar gekennzeichnete hypothetische Anfrage verwenden. Angenommen, eine Person verlangt die Löschung von Material, das in einem kundenorientierten System gespeichert ist. Welches Team erhält die Anfrage? Wie wird die Identität geprüft, ohne übermäßig viele neue Informationen zu erheben? Welche Zwecke sind relevant? Welche Systeme enthalten Quelldaten, Ableitungen, Indizes, Protokolle, Caches, Exporte und Wiederherstellungskopien? Welche Auftragsverarbeiter benötigen eine Anweisung oder Benachrichtigung? Welche Ausnahme oder Aufbewahrungspflicht gilt gegebenenfalls? Wer darf entscheiden? Wer darf ausführen? Wie wird die Organisation das Ergebnis erklären?

Dann stellen Sie die unbequemen technischen Fragen. Kann eine Fachkraft das aktuelle Dateninventar finden, ohne dass ein ehemaliger Entwickler benötigt wird? Kann ein Suchindex unabhängig von seiner Quelltabelle geprüft werden? Taucht eine gelöschte Kennung nach einer Wiederherstellung erneut auf? Verwenden Stapelverarbeitungen alte Snapshots? Kann ein Embedding-Speicher seinen Dokumenten und Mandanten zugeordnet werden? Erfasst eine Überwachungspipeline standardmäßig die Inhalte von Eingabeaufforderungen? Unterliegen Exportdateien denselben Aufbewahrungsregeln wie ihre Quelle? Erzeugt der Nachweisbeleg einen neuen Berg sensibler Inhalte? Das sind keine Randfälle, die hinzugefügt wurden, um eine Richtlinie seriös wirken zu lassen. Es sind die normalen Folgen von Systemen, die Kopien anfertigen, um zu funktionieren.

Stellen Sie schließlich die Frage der Governance: Was würde die Organisation dazu bringen, ihre Antwort zu ändern? Eine neue rechtliche Verpflichtung, eine bestrittene Identität, ein laufendes Rechtsverfahren, eine geänderte Vertragsvereinbarung mit einem Anbieter, eine fehlgeschlagene Löschüberprüfung, ein wiederhergestelltes Backup, eine neue Modellpipeline oder eine Entscheidung einer Aufsichtsbehörde können jeweils von Bedeutung sein. Ein Prozess ohne Überprüfungsauslöser ist schlicht eine erste Annahme, die zur Richtlinie befördert wurde.

Nichts davon ersetzt eine Rechtsberatung im Einzelfall. Die Anforderungen der DSGVO, nationales Recht, branchenspezifische Pflichten, Verträge und die Fakten der Verarbeitung sind alle von Bedeutung. Aber Organisationen brauchen keinen Rechtsstreit, um damit zu beginnen, die Bedingungen für eine verständliche Antwort zu schaffen. Sie müssen ihre Systeme gut genug kennen, um aufhören zu können, ein einfaches Versprechen für eine komplizierte Wirklichkeit anzubieten.

Datenschutz ist die Qualität des Restbestands

Die Absicht hinter dem Löschen besteht nicht darin, die Vergangenheit ungeschehen zu machen. Es geht darum, Menschen eine sinnvolle Kontrolle zu geben, wenn Daten nicht mehr verarbeitet werden müssen, wenn die Einwilligung widerrufen wurde, wenn die Verarbeitung unrechtmäßig ist oder wenn ein anderer Grund aus Artikel 17 vorliegt. Es verlangt von Verantwortlichen, personenbezogene Daten als etwas zu behandeln, das für einen Zweck gehalten wird, und nicht als Rohmaterial mit unbefristetem Aufenthaltsrecht. Es verlangt, Ausnahmen zu erklären, statt sie als Nebelmaschine zu nutzen. Es verlangt von Systemen, genügend Herkunftsnachweise zu führen, damit das Vergessen bewusst geschehen kann.

Für digitale Dienste ist der stille Test, was übrig bleibt. Nachdem ein Datensatz von einem Produktbildschirm entfernt wurde, was ist noch aktiv? Nachdem ein Dokument aus einem Abrufkorpus entfernt wurde, welche abgeleitete Darstellung wählt es weiterhin aus? Nachdem ein Konto gelöscht wurde, welches Protokoll wird zu welchem Zweck und wie lange aufbewahrt? Nachdem ein Backup wiederhergestellt wurde, was verhindert, dass ein ausgemusterter Datensatz zurückkehrt? Nachdem sich ein Modell geändert hat, welche Datenhistorie kann eingesehen werden? Nachdem eine Anfrage abgeschlossen ist, kann die Organisation ihre Arbeit belegen, ohne ein weiteres verstecktes Profil anzulegen?

Ein System wird diese Fragen selten mit einer einzigen Aktion und einem einzigen Zeitstempel beantworten. Das ist normal. Was nicht normal ist, ist so zu tun, als verschwänden die Fragen, weil die Daten schwierig, verteilt oder profitabel sind. Datenschutz ist nicht der Moment, in dem ein Dienst einen Löschbefehl lernt. Es ist das, was übrig bleibt, nachdem das System gelernt hat, mit einem Zweck, einer Grenze und einem Protokoll seiner eigenen Zurückhaltung zu vergessen.

Quellen