Einwilligung und das Recht auf Vergessenwerden

🌐 Auch in 28 Sprachen

English · Español · 日本語 · Português (Brasil) · Français · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Mit KI erstelltes Bild

Von KI übersetzt. Noch nicht von der Community geprüft. Auf Englisch lesen

Modul 5 von 6 im Kapitel Datenqualität und Governance, Kapitel 5 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Datenschutzgesetze prägen den Entwurf · Weiter: Schützen, aufbewahren und nachweisen

Die Frage, die dieses Modul beantwortet: Wie entwerfen Sie für die Einwilligung, und für das Löschen einer Person?

Steve Trucking hat die Telefonnummer eines Empfängers. Einfache Frage: Dürfen wir ihm eine SMS schicken? Vielleicht. Über die heutige Lieferung? Über die von morgen? Dürfen wir die Nummer für eine Werbeaktion nutzen? Was, wenn er Nein zu SMS gesagt hat, oder Ja zu Lieferupdates, aber Nein zu Marketing, und dann seine Meinung geändert hat?

Jetzt die andere Richtung. Der Empfänger sagt: Löschen Sie meine personenbezogenen Informationen. Wo sind sie? In Salesforce, wahrscheinlich, aber wir haben gelernt, dass das nicht die ganze Antwort ist. Sie kamen von einem Handelspartner. Sie sind vielleicht in einer Kundendatenplattform, im Feldverlauf, in einem Archiv, einer Liefernotiz, einem Export, einem Integrationsprotokoll, dem Gespräch eines Agenten. Einwilligung und Löschung klingen wie Richtlinienfragen, aber am Ende muss das System sie beantworten. Das ist Architektur.

Einwilligung ist Daten

Das erste Prinzip: Einwilligung ist Daten. Reduzieren Sie sie nicht auf Has_Opted_In__c = true. Die echte Frage ist nie nur „Hat er eingewilligt?“ Sie lautet: Einwilligung wozu, über welchen Kanal, an welche Adresse oder Nummer, zu welchem Zweck, wann, hat sie sich geändert, und können wir sie nachweisen? Wenn das Geschäft auf Grundlage dieser Antworten entscheidet, müssen sie als strukturierte Daten gespeichert werden. Ein Absatz in einer Datenschutzerklärung reicht nicht, und ein Kontrollkästchen auf einem Webformular auch nicht: Das Kontrollkästchen erfasst ein Ereignis; die Architektur muss festhalten, was das Ereignis bedeutet.

Nutzen Sie das Modell, das Salesforce schon gebaut hat

Meine Position: Nutzen Sie das standardmäßige Einwilligungsmodell, wo immer Sie können, statt dasselbe in benutzerdefinierten Feldern neu zu bauen. Das Einwilligungsdatenmodell von Salesforce verwaltet Einwilligungen auf vier Ebenen, jede eine genauere Frage (Understand the Salesforce Consent Data Model (opens in a new tab), auf Englisch):

• Globale Einwilligung, auf der Einzelperson (Individual): Wer ist diese Person, und hat sie zu allem Nein gesagt?
• Einwilligung je Engagement-Kanal (Contact Point Type Consent): Dürfen wir diese Art von Kanal nutzen, etwa SMS oder E-Mail?
• Einwilligung je Kontaktpunkt: Was ist mit dieser bestimmten Telefonnummer oder E-Mail-Adresse?
• Datenverwendungszweck (Data Use Purpose): Aus welchem Grund: Lieferbenachrichtigungen, Service, Marketing?

Zusammen kann die Architektur die Frage beantworten: „Dürfen wir die Informationen dieser Person über diesen Kontaktpunkt für diesen Zweck verwenden?“, was weit nützlicher ist als „Einwilligung = ja“. Jeder Datensatz, der sich auf eine Einzelperson bezieht, kann daran teilnehmen: Leads, Kontakte, Personenaccounts, Benutzer.

Click to enlarge

Vier Fragen, jede enger als die vorige. Ein einzelnes Opt-in-Kennzeichen beantwortet keine davon gut.

Der Zweck zählt

Ein Handelspartner schickt Steve Trucking die Nummer eines Empfängers, damit die Crew die Lieferung abstimmen kann. Das macht den Empfänger nicht zum Marketing-Lead. Dieselben Daten können verschiedene erlaubte Verwendungen haben: Lieferabstimmung, Service-Nachfassen, Marketing, KI-Personalisierung. Wenn Richtlinie oder Gesetz sie unterschiedlich behandeln, muss das Modell sie unterscheiden. Die Frage ist nicht Haben wir die Telefonnummer? Sie lautet: Was dürfen wir damit tun?

Und die Einwilligung ist nicht immer die Rechtsgrundlage. Manche Verwendungen beruhen auf anderen Grundlagen, die das Gesetz vorsieht, und das stellt die Rechtsabteilung fest. Bauen Sie keine Architektur, die annimmt, jede Datenschutzentscheidung sei ein Opt-in-Kontrollkästchen. Unterstützen Sie, was die Richtlinie sagt: Hängt eine Verwendung von einer Einwilligung ab, modellieren und erzwingen Sie die Einwilligung; gilt eine andere Grundlage, speichern Sie trotzdem, was nötig ist, um zu entscheiden, ob die Verwendung erlaubt ist.

Die Einwilligung hat einen Lebenszyklus und eine Autorität

Menschen erteilen Einwilligungen, widerrufen sie, ändern Präferenzen, wechseln Nummern. Das Geschäft fügt neue Zwecke hinzu; Gesetze ändern sich. Entwerfen Sie also den Lebenszyklus: was gewählt wurde, wann, wie, für welchen Zweck, und was beim Widerruf passiert. Und hier wird es interessant: Wenn ein Empfänger seine Einwilligung widerruft, weiß Salesforce es. Die Messaging-Plattform? Die Analytik? Der Agent? Eine Einwilligung, die in einem System lebt, während andere auf veralteter Erlaubnis handeln, ist keine echte Kontrolle.

Das heißt zu fragen, welches System für die Einwilligung maßgeblich ist. Salesforce, eine Präferenzplattform, etwas anderes? Wie auch immer die Antwort lautet, lassen Sie nicht fünf Systeme unabhängig entscheiden, ob dieselbe Person derselben Verwendung zugestimmt hat. Die Einwilligung braucht, was alle gesteuerten Daten brauchen: einen Eigentümer, einen maßgeblichen Datensatz, einen Weg zur Synchronisation und Durchsetzung.

Jetzt sagt die Person: Vergessen Sie mich

Der erste Reflex ist, den Kontakt zu löschen und es als erledigt zu betrachten. Aber die Daten der Person liegen vielleicht auf einem Kontakt, einer Lieferung, einer Liefernotiz, einem Kundenvorgang, einem Foto, im Feldverlauf, in Snowflake, in einem Archiv, einem Integrationsprotokoll, einem Suchindex oder dem Gesprächsverlauf eines Agenten. Deshalb beginnt meine Position zur Löschung früher: Löschen ist in der Praxis selten und schwer, also kontrollieren Sie zuerst, wohin personenbezogene Daten gehen. Entwerfen Sie so, dass sie an möglichst wenigen Orten landen. Wenn dann eine Anfrage kommt, verschleiern oder entkoppeln Sie sie dort, wo das die Richtlinie erfüllt, und spüren Sie jede Kopie auf: Feldverlauf, Archive, Data 360 und jetzt Suchindizes und Gespräche mit Agenten.

Beginnen Sie die Suche nicht erst, wenn die Anfrage kommt. Dann ist es zu spät, die Landschaft zu verstehen. Glossar, Herkunft und Klassifizierung aus Modul 3 waren kein Papierkram; sie machen das erst möglich. Sie wissen bereits, welche Felder personenbezogene Daten enthalten und wohin die Kopien gegangen sind.

Click to enlarge

Eine Vergessen-Sie-mich-Anfrage ist eine Entscheidung für jede Kopie.

Die Uhr läuft

Diese Anfragen kommen mit Fristen. Nach der DSGVO muss die Organisation auf den Antrag einer Person unverzüglich reagieren, in jedem Fall aber innerhalb eines Monats nach Eingang des Antrags; bei komplexen oder zahlreichen Anträgen kann diese Frist um weitere zwei Monate verlängert werden, die Person muss aber innerhalb des ersten Monats darüber informiert werden, zusammen mit den Gründen (Artikel 12 Absatz 3, Verordnung (EU) 2016/679 (opens in a new tab)). Andere Gesetze setzen eigene Fristen; welche gelten, sagt Ihnen die Rechtsabteilung. So oder so: Ein Monat reicht nicht, um die Landschaft erst zu entdecken. Das ist die Frist, die die Karte der Kopien schlagen muss.

Löschen, entidentifizieren oder aufbewahren?

Eine Anfrage heißt nicht unbedingt, dass alles überall verschwindet. Manche Datensätze müssen oder dürfen aufbewahrt werden; manche operativen Datensätze können bleiben, hören aber auf, die Person zu identifizieren; manche Daten können entidentifiziert werden. Die geltende Richtlinie und das Gesetz entscheiden; die Architektur unterstützt jedes Ergebnis, Ort für Ort: löschen, entidentifizieren oder unter einer genehmigten Anforderung aufbewahren (und dann: wer darf sie sehen, wie lange, warum?).

Erinnern Sie sich an die Unterscheidung aus Modul 4. Entkoppeln zählt nur dann als Vergessen, wenn die Person vernünftigerweise nicht mehr re-identifiziert werden kann. Pseudonymisierte Daten sind weiterhin personenbezogene Daten. Nutzen Sie Verschleierung nicht als Abkürzung um eine rechtliche Anforderung herum.

Sie können nicht löschen, was Sie nicht finden

Bevor Sie jemanden löschen können, müssen Sie ihn finden. Die Anfrage kommt von einer E-Mail-Adresse. Ein Handelspartner hat „Jane Smith“ geschickt, ein anderer „J. Smith“, und die Telefonnummer hat sich geändert. Der Empfänger ist überhaupt kein Kontakt; seine Angaben stehen auf jeder Lieferung. Dieselbe Person hat Lieferungen für zwei verschiedene Partner bekommen. Ein System kennt sie über die E-Mail, ein anderes über eine externe ID. Die Löschung hängt von der Identität ab, und Sie wollen nicht die Daten von jemand anderem löschen, weil Ihr Abgleich zu aggressiv war. Identitätsarchitektur ist Teil der Datenschutzarchitektur.

Steve Trucking macht es noch schwerer. Ein Handelspartner darf nie die Lieferungen oder Empfänger eines anderen sehen. Wenn dieselbe Person Lieferungen für zwei Partner bekommen hat, muss der Betrieb diese Beziehungen getrennt halten, während der Datenschutz die Person vielleicht trotzdem über beide hinweg finden muss. Lösen Sie den Datenschutz nicht, indem Sie die Sicherheitsgrenze brechen, und schützen Sie die Grenze nicht, indem Sie Datenschutzanfragen unmöglich machen. Die Architektur muss beides können.

Auch Fotos und Freitext sind Daten

Es ist leicht, Datenschutz als Felder zu denken: Name, E-Mail, Telefon, Adresse. Aber Steve Trucking macht Millionen Lieferfotos im Jahr, und manche zeigen Menschen oder das Innere eines Zuhauses. Eine Aufbewahrungs- oder Löschrichtlinie, die nur strukturierte Felder betrachtet, ist unvollständig; genauso eine, die Dateien, Dokumente, Transkripte, Protokolle und KI-Prompts und -Antworten ignoriert.

Und Freitext ist gefährlich. Sie entfernen Name, Telefon und Adresse und finden dann diese Liefernotiz: „Jane unter 602-555-0198 anrufen. Torcode 4821. Hund ist im Garten.“ Da ist es. Liefernotizen als sensibel zu klassifizieren sagt Ihnen, dass es ein Problem geben kann; es findet und entfernt nicht die personenbezogenen Daten im Text. Manchmal ist die beste Antwort, zu verhindern, dass unnötige persönliche Details überhaupt dort landen. Kontrollieren Sie zuerst, wohin personenbezogene Daten gehen.

Privacy Center ist ein Werkzeug, nicht die ganze Architektur

Salesforce Privacy Center hilft, diese Prozesse zu betreiben. Seine Richtlinien zum Recht auf Vergessenwerden werden pro Objekt aufgebaut, um alles zu erfassen, was Sie entfernen wollen, und laufen gegen einen bestimmten Kundendatensatz (Delete Data with Right to Be Forgotten Policies (opens in a new tab), auf Englisch). Das ist nützlich. Aber „Wir haben Privacy Center gekauft, also sind wir fertig“ ist keine Architektur. Die Daten der Person liegen vielleicht außerhalb der Reichweite eines einzelnen Werkzeugs: Data 360, das Data Warehouse, Partnersysteme, Archive, Protokolle, Suche, Dateien, Gespräche mit Agenten. Das Unternehmen braucht trotzdem eine Antwort auf Unternehmensebene, und Sie müssen prüfen, was jedes Werkzeug tatsächlich abdeckt, bevor Sie sich darauf verlassen.

Übertragbarkeit und Nachweis

Manche Gesetze geben Menschen auch das Recht, eine Kopie ihrer Daten zu bekommen. Beachten Sie, dass es dasselbe Suchproblem ist: Löschung fragt Wo sind die Daten dieser Person, damit wir handeln können? Übertragbarkeit fragt Wo sind sie, damit wir sie bereitstellen können? Beide beruhen auf Identität, Klassifizierung, Herkunft, dem Systeminventar und der Eigentümerschaft.

Und dann: Wie weisen Sie nach, dass Sie es getan haben? Anfrage eingegangen, Identität geprüft, Systeme durchsucht, Maßnahmen ergriffen, Ausnahmen festgehalten, aufbewahrte Daten begründet, Abschluss protokolliert. Hier gibt es eine echte Spannung: Sie entfernen die personenbezogenen Daten von jemandem und behalten gleichzeitig genug Nachweise, um zu zeigen, dass Sie die Anfrage ordnungsgemäß bearbeitet haben. Genau deshalb sollte die Architektur Aufbewahrungsregeln nicht selbst erfinden. Rechts- und Compliance-Teams entscheiden, welche Nachweise bleiben müssen; die Architektur bewahrt sie, ohne die Daten zu bewahren, die sie entfernen sollte.

Über die Prüfung hinaus: Was KI ändert. KI schafft neue Zwecke und neue Kopien. Die Erlaubnis, Daten zur Erbringung eines Dienstes zu nutzen, deckt nicht automatisch das Grounding eines Agenten, Personalisierung oder Training ab; der Datenverwendungszweck (Data Use Purpose) ist der natürliche Ort, sie zu unterscheiden. Und personenbezogene Daten können in Prompts, Grounding-Kontext, Gesprächen, Zusammenfassungen, Such- und Vektorindizes und Protokollen überleben. „Wir haben den Quelldatensatz gelöscht“ ist keine vollständige Antwort, wenn sich die KI-Schicht noch erinnert.

Was Architekt:innen hier entscheiden

• Wie Einwilligung und erlaubte Nutzung modelliert werden, damit Systeme beantworten können: wer, welcher Kanal, welcher Kontaktpunkt und welcher Zweck.
• Welches System für die Einwilligung maßgeblich ist und wie Widerrufe jedes System erreichen, das darauf handelt.
• Wohin sich personenbezogene Daten verbreiten können: Felder, Freitext, Dateien, Historie, Analytik, Archive, Integrationen, Suche und KI.
• Wie eine Anfrage die richtige Person findet und an jedem Ort Löschung, Entidentifizierung oder genehmigte Aufbewahrung auslöst.
• Welche Nachweise bleiben, um zu belegen, dass Einwilligungen und Datenschutzanfragen bearbeitet wurden.

Einwilligung und Löschung sehen aus wie Gegensätze (Dürfen wir diese Daten nutzen? Können wir aufhören und sie entfernen?), aber sie beruhen auf denselben Grundlagen: Identität, Zweck, Klassifizierung, Herkunft, Eigentümerschaft, Durchsetzung und Nachweis. Nutzen Sie das standardmäßige Einwilligungsmodell, kontrollieren Sie, wohin personenbezogene Daten gehen, wissen Sie, wo die Kopien sind, und entwerfen Sie den Löschprozess, bevor die erste Anfrage kommt. Wenn jemand fragt „Können Sie mich vergessen?“, braucht die Architektur eine bessere Antwort als „Wir glauben schon.“

Weiterlesen

• Salesforce-Hilfe, Understand the Salesforce Consent Data Model (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.
• Verordnung (EU) 2016/679 (DSGVO) (opens in a new tab), Artikel 12 Absatz 3, die Frist für die Bearbeitung eines Antrags, geprüft am 2026-10-14.
• Salesforce-Hilfe, Delete Data with Right to Be Forgotten Policies (opens in a new tab) (Privacy Center, auf Englisch), geprüft am 2026-10-14.