presseportale/dev/archive/rechtliches-2026-10/auswertung-und-abschlussentscheidungen-2026-10-12.md

Rechtliches: Auswertung und Entscheidungen für den Paketabschluss

Prüfdatum: 12.10.2026

Codebasis: Arbeitsstand auf Commit 8124d20, vor Beginn ohne lokale Änderungen

Status: Fachliche Entscheidungsvorlage; keine erteilte Rechtsfreigabe und kein Nachweis des produktiven Betriebs

Geprüfte Ausgangsdokumente:

• Anwaltspaket Datenschutz und Rechtstexte, Entwurf vom 09.10.2026.
• Interessenabwägung Beweisarchiv, Entwurf vom 09.10.2026.

1. Meine Abschlussbewertung

Beide Dokumente werden benötigt und sollten erhalten bleiben. Das Paket ist in der vorliegenden Fassung noch nicht abschließbar. Das Anwaltspaket bündelt die externe Prüfung; die Interessenabwägung dokumentiert intern, warum welche Daten für die Beweisführung aufbewahrt werden. Ein Anwaltspaket in genau dieser Form ist keine gesetzliche Pflicht. Eine nachvollziehbare Begründung der gewählten Verarbeitung ist dagegen wesentlich für die Rechenschaftspflicht. Die Abwägung sollte Interesse, Erforderlichkeit und Gegeninteressen konkret prüfen; genau diese drei Prüfschritte beschreibt auch der EDSA in seinen Leitlinien 1/2024, Konsultationsfassung.

Die technische Grundlage des Archivs ist substanziell: Verschlüsselung, Rechteprüfung, Zweckangabe bei Inhaltsabrufen, Protokollierung, Legal Holds, Löschläufe und Restore-Abgleich sind vorhanden. Der Hauptmangel ist die fehlende Übereinstimmung zwischen tatsächlichem Datenlebenszyklus und den zugesagten Fristen bzw. Schutzmaßnahmen. Einige Aussagen sind auch innerhalb der Dokumente widersprüchlich.

Meine Empfehlung: Den Abschluss auf die bereits verwendeten Verarbeitungen konzentrieren. Nutzerbezogene Hub-Analyse, KI-Bildprüfung und Newsletter-Kampagnen bleiben deaktiviert und erhalten eigene Aktivierungskriterien. Ihre spätere Einführung muss diesen Abschluss nicht verzögern. Die im Anwaltspaket zusätzlich genannten Verträge, Refund-Regeln und bezahlten Platzierungen bekommen eigene Zuständigkeiten; sie dürfen nicht als mitgeprüft oder erledigt gelten.

Die nachstehenden Entscheidungen sind Empfehlungen. Sie ändern weder Produktivkonfiguration noch freigegebene Rechtstexte. In diesem Auftrag wurde die Auswertung angelegt; die Anwendung und die beiden Ausgangsdokumente wurden nicht geändert.

2. Zusammenfassung der beiden Dokumente

2.1 Anwaltspaket Datenschutz

Zweck: Die DSE von Version 0.3 auf einen belastbaren neuen Stand bringen und die Bildrechteprüfung mit AGB 0.7 koordinieren. Erfasst sind zehn Verarbeitungsbereiche D1–D10 und elf Fragen F1–F11.

Gut und beizubehalten: Die Trennung nach Verarbeitung, die konkreten Textentwürfe, die Benennung der Datenarten und die Unterscheidung zwischen bereits genutzten und geplanten Funktionen. Ein Anwalt erhält dadurch eine prüfbare Arbeitsgrundlage statt einer abstrakten Frageliste.

Zu korrigieren: Unzutreffende Löschzusagen, die absolute Zusage zum Fehlerprotokoll, die Darstellung des API-Schlüssels sowie der Eindruck, ein AVV allein löse die Datenschutzfragen der Bildprüfung. Angaben wie „ab nächstem Release“ müssen durch „im geprüften Code vorhanden; produktiver Einsatz nachzuweisen“ oder einen konkreten Auslieferungsnachweis ersetzt werden.

Entscheidung: Dokument als Versandunterlage behalten, vor Versand anhand dieser Auswertung berichtigen. Die Abschnitte zu deaktivierten Funktionen ausdrücklich als spätere Erweiterung ausweisen. Eine gemeinsame Sitzung ist sinnvoll; ein pauschales „Ja“ zu allen vorgeschlagenen Defaults wäre fachlich nicht ausreichend.

2.2 Interessenabwägung Beweisarchiv

Zweck: Die Speicherung von Originalen, Rechtebestätigungen und entfernten Veröffentlichungen für Nachweis, Rechtsverteidigung und Rückgriff begründen.

Gut und beizubehalten: Klare Zweckbindung, Betrachtung milderer Mittel, nicht öffentliche Aufbewahrung und die Trennung zwischen veröffentlichten und nie veröffentlichten Bildern. Das Archivkonzept sollte grundsätzlich erhalten bleiben.

Zu korrigieren: Die Bewertung „Auswirkungen gering“ ist ohne Differenzierung zu pauschal. Originale können GPS-Daten und weitere bislang nicht veröffentlichte Angaben enthalten. Auch das Fortbestehen eines entfernten Bildes kann für Betroffene erheblich sein. „Das Archiv erweitert die Kenntnis niemandes“ trägt deshalb als generelle Aussage nicht. Darüber hinaus stimmen Aussagen zu Löschvermerken, Zugriffen, Restore-Schutz und Legal Holds nicht vollständig mit dem Code überein.

Entscheidung: Als eigenständigen internen Nachweis fortführen, aber erst nach Korrektur und Umsetzung der beschlossenen Schutzmaßnahmen datieren und abzeichnen. Eine Unterschrift heilt keine Abweichung zwischen Text und Betrieb. Verantwortlicher, Freigabedatum, zuständige Person und nächster Prüftermin müssen eingetragen werden.

3. Abgleich D1–D10 mit dem Code

„Vorhanden“ bezeichnet hier den geprüften Repository-Stand. Daraus folgt keine Bestätigung der aktiven Produktivkonfiguration oder eines erfolgreichen produktiven Löschlaufs.

Bereich	Ergebnis des Codeabgleichs	Empfohlene Entscheidung
D1 Bildrechte und Beweisarchiv	Originale, Bestätigungen, Archiv und Aufbewahrungslogik vorhanden. Pressekontakte sowie Einreichername und -E-Mail sind tatsächlich enthalten. Entscheidende Abweichungen bei Restdaten, Holds und Restore; siehe Abschnitt 4.	Beibehalten, aber Datensatz, Frist und Restdaten vollständig beschreiben. Keine pauschale Freigabe des jetzigen Entwurfs.
D2 GlitchTip	Eigene Bereinigung, interne Nutzer-ID und verzögertes Laden des Browser-SDK vorhanden. Breadcrumb-Begleitdaten werden im aktuellen Code bereits entfernt. Ein vollständiger Ausschluss personenbezogener Inhalte ist nicht gewährleistet. 90 Tage werden nicht durch diesen Anwendungscode erzwungen.	Text begrenzen, Filter nachschärfen und tatsächliche GlitchTip-/Proxy-Aufbewahrung nachweisen.
D3 Anmeldesicherheit	Letzte Login-IP wird am Konto überschrieben. Bekannte fehlgeschlagene Anmeldungen werden mit gekürztem HMAC protokolliert, unbekannte als Tageszähler. Login-Limits haben kurze Laufzeiten.	Beschreiben wie implementiert. „Im Arbeitsspeicher“ durch „im kurzlebigen Zwischenspeicher“ ersetzen: Cache-Backend ist konfigurierbar, Standard ist Datenbank. Erfolgreiche Login-Ereignisse enthalten im gezeigten Listener den Anmeldeweg, keinen IP-Hash.
D4 Zustellbarkeit	Bounce-Datensätze werden nach konfigurierten 395 Tagen bereinigt. IMAP-Mails werden in Processed, Ignored, Unparsed verschoben; eine zeitgesteuerte Bereinigung dieser Ordner ist im geprüften Befehl nicht enthalten.	90 Tage für Rohmails als umzusetzende Vorgabe beschließen. Sperrliste zweckgebunden erhalten. Die Aussage „keine Mails mehr“ präzisieren: selbst angeforderte Magic Links sind von der Abmeldesperre ausgenommen.
D5 Aktivität/API	395 bzw. 90 Tage in Konfiguration und prunable() vorhanden, täglicher Scheduler eingetragen. API-Log speichert die ID des Token-Datensatzes, keinen geheimen Zugangsschlüssel.	DSE entsprechend berichtigen. Produktiven Rollout und ersten erfolgreichen Löschlauf belegen; nicht länger als fehlende Implementierung behandeln.
D6 Turnstile	remoteip wird serverseitig an Cloudflare übermittelt. Bei Nichterreichbarkeit standardmäßig Annahme mit Markierung; über Konfiguration änderbar.	Zusätzlichen Datenfluss aufnehmen. Einwilligungsfreiheit nicht allein mit „keine Werbecookies“ begründen.
D7 Hub-Analyse	UMAMI_PORTAL_ENABLED und UMAMI_IDENTIFY_USERS standardmäßig aus. Bei Aktivierung kann user-{id} gesendet werden; Portal-Analyse ist auf me.* beschränkt und bei Impersonation ausgenommen.	Für diesen Abschluss ausgeschaltet lassen. Kontobezogene Nutzungsanalyse nur nach eigenständiger Prüfung aktivieren. „Ohne Personenbezug“ nicht allein aus Cookielosigkeit ableiten.
D8 KI-Bildprüfung	Feature standardmäßig aus. Verkleinertes JPEG, maximal 1024 px, Aufruf der Chat-Completions-API; Prompt untersagt Personenidentifikation. Im Code kein Beleg einer vertraglich eingerichteten Nullspeicherung.	Gesperrt lassen. Anbieterrolle, AVV, Übermittlungsgrundlage, reale Speicherbedingungen und sensible Bildinhalte vor Aktivierung klären.
D9 Vorgangs-IP-Adressen	Klartextfelder in Kontakt-, Melde-, Widerrufs-, Kündigungs- und Buchungsdaten vorhanden. Kein allgemeiner 90-Tage-Bereinigungslauf dafür gefunden. Kontakt-Spam wird gesondert nach 30 Tagen gelöscht.	Eigene IP-Bereinigung mit klaren Ausnahmen und Nachweistest umsetzen. Buchungsbestätigungen auch im DSE-Text nennen; sie fehlen im vorgeschlagenen Absatz.
D10 Newsletter	Versand standardmäßig gesperrt. Empfängerauswahl basiert derzeit auf „aktiv und nicht abgemeldet“, nicht auf nachgewiesenem Opt-in.	Sperre beibehalten. Vor Aktivierung Einwilligungsnachweis und Empfängerauswahl ändern; das Einschalten eines Flags genügt nicht.

Codebelege:

• D1: PressReleaseArchiver, insbesondere depublicationState() ab Zeile 113 und pressReleaseHeader() ab Zeile 305; ImageRightsConfirmation und ImageUploader, recordConfirmation() ab Zeile 458.
• D2: ErrorReportScrubber, Browser-Fehlererfassung, Sentry-Konfiguration.
• D3: RecordAuthActivity, LoginCompletion, LoginIpThrottle, FortifyServiceProvider, Cache-Konfiguration.
• D4: FetchMailBounces, PurgeConversionEvents, GateOutgoingMail, Bounce-Konfiguration.
• D5: ActivityEvent, ApiUsageLog, LogApiUsage, Monitoring-Konfiguration, Scheduler.
• D6: TurnstileVerifier, verify() ab Zeile 59.
• D7: Umami-Komponente, Services-Konfiguration.
• D8: Bildkonfiguration, OpenAiImagePrecheckDriver, PrecheckImagePreparer.
• D9: ContactMessage, LegalRequest, WithdrawalRequest, TerminationRequest, BookingConfirmation, Scheduler.
• D10: Newsletter-Konfiguration, CampaignSender, CampaignRecipients, query()-Umfeld ab Zeile 142.

4. Wesentliche Korrekturen vor einem Abschluss

K1 — Die 180-Tage-Zusage beschreibt keine vollständige Löschung

Im Anwaltspaket steht, Entwürfe und nie veröffentlichte abgelehnte Einreichungen würden nach 180 Tagen samt Medien gelöscht. PurgeExpiredPressReleaseDrafts, insbesondere Zeilen 66–81, löscht die Bilder nie veröffentlichter Meldungen und setzt alte Entwürfe auf archived. Die Meldungsdatensätze bleiben bestehen. Abgelehnte Meldungen behalten ihren Status; Legacy-Fälle werden besonders behandelt. Der Lauf erfolgt wöchentlich, nicht exakt am 180. Tag.

Meine Entscheidungsempfehlung: Die falsche Zusage vor Versand berichtigen. Als Ziel echte Löschung nie veröffentlichter Entwürfe einschließlich zugehöriger personenbezogener Daten nach 180 Tagen festlegen. Bei abgelehnten Einreichungen nur einen konkret begründeten minimalen Nachweis separat befristen. Keine unbefristete Volltextaufbewahrung allein unter dem Etikett „Vertragsdokumentation“. Die Umsetzung muss mögliche frühere Veröffentlichungen und belegte Streitfälle schützen.

Auch „Bearbeitungsstände nach 30 Tagen“ benötigt eine Präzisierung: PurgeRedactionSnapshots lässt Snapshots mit offenem Archivauftrag bestehen. Das ist eine Fehlerbehandlung, die überwacht werden muss, keine garantierte Höchstfrist. Das langfristige Beweisarchiv kann denselben Vorher-Stand unabhängig davon enthalten.

K2 — Die 90-Tage-Frist für Vorgangs-IP-Adressen ist noch ein Vorhaben

D9 erkennt die Lücke bereits richtig. Sie ist im geprüften Code weiterhin offen. Die Spam-Bereinigung von ContactMessage ersetzt keine IP-Bereinigung regulärer Anfragen. Der DSE-Absatz darf erst als tatsächliches Verfahren veröffentlicht werden, wenn Bereinigung und Altbestandslauf vorhanden sind.

Meine Entscheidungsempfehlung: 90 Tage als technische Obergrenze für diese IP-Felder beschließen, mit dokumentierter Einzelfallverlängerung bei einem konkreten Vorfall. Der fachliche Vorgang bleibt davon getrennt. Zusätzlich die tatsächliche Umsetzung der bestehenden DSE-Frist für Meldevorgänge prüfen: Ein allgemeiner automatischer Löschlauf für LegalRequest war im geprüften Scheduler nicht erkennbar; ein dokumentierter manueller Prozess wurde nicht nachgewiesen.

K3 — „Bis zum Abschluss“ widerspricht dem Legal-Hold-Code

EvidenceArchive::releaseLegalHold(), Zeilen 296–313, setzt bei Aufhebung wieder die volle Archivfrist ab Jahresende. Bei Aufhebung im Oktober 2030 läuft sie bis 31.12.2033. Anwaltspaket und Tabelle der Interessenabwägung sagen dagegen „bis zum Abschluss“; weiter unten nennt die Abwägung selbst einen Neustart.

Meine Entscheidungsempfehlung: Keinen automatischen vollständigen Fristneustart als Standard. Ursprüngliche Frist erhalten; nach Abschluss eines Streitfalls prüfen, ob ein konkret dokumentierter weiterer Nachweiszweck besteht. Falls ja, gesondertes Enddatum und Wiedervorlage; andernfalls Löschung, sobald auch die reguläre Frist abgelaufen ist. Das erfordert eine Codeänderung.

Die regelmäßige Verjährung beträgt drei Jahre; ihr Beginn hängt aber unter anderem von Anspruchsentstehung und Kenntnis ab, nicht schlicht vom Entfernen eines Bildes. Die gewählte Archivfrist ist daher eine betriebliche Regel, keine vollständige Abbildung aller Verjährungsfälle. § 195 BGB, § 199 BGB.

K4 — Löschvermerke und Zugriffsprotokolle behalten Personenbezug

EvidenceArchive::tombstone(), ab Zeile 665, entfernt den Payload und setzt deleted_at. Referenzen auf Akteur, Gegenstand und Rechtsvorgang sowie Hold-Vermerke bleiben in der Archivzeile. Das ist kein vollständig inhaltsloser oder anonymer Restdatensatz.

Das Zugriffsprotokoll enthält zusätzlich Admin-ID, Name, E-Mail und Zweck. Änderungen und Löschungen über das Modell sind gesperrt. Eine Aufbewahrungsgrenze fehlt; der offene Punkt in der Interessenabwägung ist tatsächlich unerledigt.

Meine Entscheidungsempfehlung: Bei Payload-Löschung auch Fallfreitexte, unnötige Personenreferenzen und zugehörige Zugriffsdetails löschen oder irreversibel reduzieren. Für einen konkreten Streit über Archivzugriffe darf ein gesondert begründeter Hold bestehen. Übrig bleiben nur die für Restore-Schutz und Löschbeleg erforderlichen Identifikatoren und Zeitpunkte. Auch diese Restdaten erhalten eine überprüfbare Aufbewahrungsregel, mindestens orientiert daran, wie lange rückspielbare Sicherungen existieren. Abrufe aktiver Originale werden dagegen über den allgemeinen Aktivitätsverlauf protokolliert und fallen unter dessen konfigurierte 395 Tage. Diese Frist ausdrücklich vom bislang unbegrenzten Archivzugriffslog unterscheiden.

K5 — Restore-Schutz benötigt einen unabhängigen aktuellen Löschstand

Der Tombstone-Export liegt auf derselben Archiv-Disk wie die Beweise. Werden Datenbank und Archiv-Disk auf einen alten Stand zurückgesetzt, kann der aktuelle Löschstand fehlen. Das Runbook, Zeilen 348–354, nennt ein automatisches externes Exportziel ausdrücklich als noch nicht gebaut. Der Abgleich ist ein gesonderter administrativer Befehl.

Meine Entscheidungsempfehlung: Aktuellen Löschstand unabhängig vom zurückzusetzenden Speicher sichern; zeitliche Lücken zwischen Löschung, Export und externer Sicherung berücksichtigen. Restore-Ablauf verbindlich machen und in isolierter Umgebung für „DB alt“, „Disk alt“ und „beide alt“ üben. Erst dann die unbedingte Zusage veröffentlichen, dass bereits gelöschte Einträge nach einer Wiederherstellung erneut entfernt werden. Der aktuelle Stand ist mehr als eine bloß fehlende Übung.

K6 — Zugriffsschutz präzise beschreiben

Archivierte Inhalte benötigen compliance:manage. Originale aktiver Bilder sind auch für berechtigte Redakteure erreichbar; bei bereits entfernten Bildern greift zusätzlicher Compliance-Schutz. Belege: Admin-Routen, Zeilen 47–61 und ab 164; Evidence-Controller, ab Zeile 44; Permission.

Inhaltsabrufe und Hold-Änderungen werden protokolliert. Die Archivlistenansicht liest Metadaten ohne gleichartige Zweckabfrage und Zugriffsprotokollierung. Die Aussage „jeder Zugriff“ ist deshalb zu weit.

Meine Entscheidungsempfehlung: Den bestehenden fachlichen Unterschied dokumentieren: „Originaldateien aktiver Bilder: berechtigte Redaktion; archivierte Inhalte: Compliance-Administratoren. Jeder Abruf archivierter Inhalte sowie jede Änderung einer Aufbewahrungssperre wird mit Zweck protokolliert.“ Verschlüsselung des Archivpayloads nicht mit einer Verschlüsselung sämtlicher Datenbankmetadaten gleichsetzen.

K7 — Das Fehlerprotokoll wird bereinigt, ist aber nicht garantiert personenfrei

Der Serverfilter ersetzt E-Mail-Muster in Meldungen, entfernt Request-Bodys/Cookies und Breadcrumb-Begleitdaten. Er lässt jedoch beispielsweise freigegebene Query-Werte wie q und utm_*, Breadcrumb-Nachrichten und andere Freitexte bestehen. scrubQuery() übernimmt erlaubte Werte ohne zusätzliche Textbereinigung. Namen und IPs innerhalb beliebiger Fehlertexte werden nicht allgemein erkannt.

Im Browser, rejectionToError(), können zudem bis zu 300 Zeichen eines abgelehnten Objekts als Fehlertext serialisiert werden. Die anschließende E-Mail-Ersetzung beseitigt nicht alle denkbaren Formular- oder Geheimniswerte. Das ist ein belegter möglicher Datenweg, kein Nachweis, dass konkrete Produktivdaten bereits abgeflossen sind.

Eine direkte Browserverbindung zum Fehlerserver macht dessen Betreiber technisch auch die Quell-IP zugänglich. Die Bereinigung des Fehlerereignisses belegt keine IP-Freiheit der Transport- oder Webserverlogs.

Meine Entscheidungsempfehlung: Fehlererfassung auf definierte technische Felder begrenzen, erlaubte Query-Inhalte prüfen und beliebige Objektinhalte nicht als Diagnosemeldung übernehmen. In der DSE zwischen Fehlerdatensatz und Verbindungsdaten unterscheiden. Die Zusage „Namen, IP-Adressen und Formularinhalte werden nicht übermittelt“ in dieser Absolutheit nicht freigeben. 90 Tage für GlitchTip durch die Instanzkonfiguration und deren Bereinigung belegen.

K8 — Die KI-Bildprüfung braucht mehr als einen AVV

Die Größenreduktion und das Entfernen von Metadaten sind sinnvolle Maßnahmen. Erkennbare Personen, Dokumente oder sensible Situationen können trotzdem im Bild selbst enthalten sein. „Keine Identifizierung“ beantwortet daher nicht jede Datenschutzfrage.

Die offizielle OpenAI-Dokumentation zu Data Controls nennt für Chat Completions regulär 30 Tage Abuse-Monitoring-Aufbewahrung. Abweichende Kontrollen sind gesondert einzurichten; für bestimmte Bildinhalte bestehen Ausnahmen auch unter strengeren Einstellungen. Daraus folgt für dieses Paket: „Keine Speicherung beim Anbieter“ ist ohne belegte kontospezifische Bedingungen nicht tragfähig. Trainingsnutzung und Speicherung sind unterschiedliche Fragen.

Meine Entscheidungsempfehlung: D8 aus dem aktuellen Aktivierungsumfang herausnehmen. Vor späterer Freigabe tatsächlichen Vertragspartner, AVV, Transfermechanismus, Speicherbedingungen und den Umgang mit sensiblen Motiven festlegen. Eine zusätzliche Datenschutz-Folgenabschätzung nicht pauschal behaupten, sondern deren Erforderlichkeit anhand der konkreten Verarbeitung prüfen lassen.

5. Meine Entscheidungen zu F1–F11

Frage	Empfehlung	Begründung / Bedingung
F1 Nummerierung	Gemeinsame Themenstruktur auf allen Hosts; Hub-spezifische Inhalte kenntlich machen.	Bildrechte und Archiv auf allen betroffenen Hosts beschreiben. Überschriften und stabile Anker statt widersprüchlicher interner Verweise verwenden.
F2 Fehlerprotokoll ohne Einwilligung	Für technisch erforderliche Fehlerdiagnose vertretbare Prüfposition, aber kein pauschales Ja.	Datenumfang nach K7 korrigieren. Browserzugriffe gesondert prüfen; Cookielosigkeit entscheidet die Frage nicht allein.
F3 Aktivitätsverlauf 395 Tage	Den einheitlichen Default nicht ungeprüft übernehmen. Vorschlag: gewöhnliche Login-/Fehlversuchsereignisse 90 Tage, übrige Support-/Geschäftsereignisse höchstens 395 Tage mit Zweckbegründung.	Sicherheitsvorfälle gezielt länger halten. Dieselbe Frist wie Nutzungsstatistik ist allein keine Begründung. Dies ist eine vorgeschlagene Änderung, nicht der aktuelle Code.
F4 Letzte Login-IP	Beibehalten, wenn die Anzeige einen konkreten Sicherheitsnutzen hat; zusätzlich Löschung nach z. B. 90 Tagen ohne neue Anmeldung vorsehen.	Überschreiben begrenzt die Anzahl, aber nicht die Dauer bei inaktiven Konten. Kürzung auf eine hinreichende Anzeigepräzision prüfen.
F5 Sperrliste/Rohmails	Sperrliste zweckgebunden erhalten; Rohmails nach 90 Tagen löschen.	Nur notwendige Sperrdaten behalten, Entsperrung und periodische Prüfung regeln. In D4 steht einmal zusätzlich lit. c, F5 sagt lit. f genüge: anwaltlich eine konsistente Grundlage je Sperrgrund festlegen, eine gesetzliche Pflicht gegebenenfalls konkret benennen.
F6 Hub-Analyse mit Nutzer-ID	Für diesen Abschluss auslassen und ausgeschaltet halten.	user-123 bleibt dem Konto zuordenbar. Nutzen zuerst mit aggregierter Analyse prüfen; eine Änderung des DSE-Satzes allein schafft keine tragfähige Grundlage.
F7 Newsletter	Nur nachgewiesenes Opt-in, keine pauschale Nutzung der Altkonten.	Bestätigung, Wortlaut/Fassung, Zeitpunkt, Quelle und Widerruf dokumentieren. Empfängerauswahl muss Einwilligung voraussetzen. Die Voraussetzungen der Bestandskundenausnahme sind gesondert, nicht durch ein vorhandenes Konto erfüllt.
F8 Turnstile	Den zusätzlichen serverseitigen IP-Datenfluss aufnehmen.	Anbieterrolle, Drittlandübermittlung und tatsächliche Endgerätezugriffe im Einsatz prüfen. Technischen Ausfallpfad sachlich beschreiben.
F9 KI-Bildprüfung	Default „AVV und Absatz genügen“ ablehnen.	Voraussetzungen nach K8, danach separate Freigabe.
F10 KI-Textkennzeichnung	Redaktionelle Ausnahme für eigene Texte nur bei tatsächlich belegter menschlicher Prüfung und übernommener redaktioneller Verantwortung verwenden.	Kein automatischer Übertrag auf sämtliche Kundenmeldungen, keine generelle Ausnahme für KI-Bilder oder Deepfakes. Freigabeprozess und Verantwortlichen dokumentieren.
F11 DSE-Version	Neue Fassung mit Datum und nachvollziehbarem Änderungshinweis veröffentlichen.	Vorher alle Hostvarianten und Fristen abgleichen. DSE-Information von der Einbeziehung neuer AGB/Richtlinien unterscheiden; die DSE benötigt nicht pauschal eine Zustimmung.

Für F2/F6/F8 ist § 25 TDDDG maßgeblich: Er betrifft nicht nur Cookies, sondern auch bestimmte Zugriffe auf Informationen im Endgerät; die Ausnahme hängt insbesondere an der unbedingten Erforderlichkeit für den gewünschten Dienst. Für F7 siehe § 7 UWG. Für die begrenzte redaktionelle Ausnahme in F10 siehe Art. 50 Abs. 4 KI-VO.

6. Entscheidungen zur Interessenabwägung

Originale und veröffentlichte Fassungen grundsätzlich behalten. Der Beweiswert einer Originaldatei ist nachvollziehbar; eine Prüfsumme ersetzt die Datei nicht. Die pauschale Speicherung aller Metadaten bleibt aber eine zu begründende Abwägungsentscheidung. Für GPS-Daten, Geräteseriennummern und sensible Motive mildere Mittel konkret prüfen. Metadatenentfernung verändert zugleich die Beweisdatei; deshalb ist eine bloße technische Kürzung ohne abgestimmtes Nachweiskonzept keine ausreichende Lösung.

Kontaktdaten nur im nachweislich relevanten Umfang aufnehmen. Die damals tatsächlich veröffentlichte Kontaktzeile kann zum Nachweis erforderlich sein. Daraus folgt nicht automatisch die Erforderlichkeit beliebiger zusätzlicher Kontodaten. Pressekontakt und Einreicher getrennt begründen und nicht lediglich „den DSE-Text verlängern“.

Drei Jahre nach Jahresende als zu prüfende Standardregel behalten. Ereignistypen differenzieren: Entfernung eines veröffentlichten Bildes, vollständige Depublikation, kleine Korrektur und Kennzeichnungsänderung haben nicht automatisch denselben Beweisbedarf. Für nie veröffentlichte Inhalte bleibt das Beweisarchiv grundsätzlich ausgeschlossen. Für konkrete Rechtsstreitigkeiten gilt ein dokumentierter Hold mit regelmäßiger Wiedervorlage; kein unbegründeter Neustart nach dessen Ende.

Löschanträge nicht pauschal wegen laufender Frist ablehnen. Art. 17 Abs. 3 lit. e DSGVO ist eine Ausnahme vom Löschanspruch, soweit die weitere Speicherung für Rechtsansprüche erforderlich ist; die Frist allein ersetzt diese Prüfung nicht. Die eigentliche Verarbeitungsgrundlage bleibt separat zu begründen. Lösch- und Widerspruchsfälle benötigen eine dokumentierte Einzelentscheidung. DSGVO, insbesondere Art. 17–21.

Sensible Inhalte gesondert behandeln. Keine Identifizierung bedeutet nicht, dass ein Bild niemals Gesundheitsdaten oder andere besondere Kategorien enthält. Erforderlichkeit und einschlägige Ausnahme müssen für solche Fälle gesondert geklärt werden. Rechtsverteidigung kann relevant sein, ist aber keine pauschale Freigabe für jede Bildspeicherung. DSGVO, Art. 9.

Risiken und Gegenmaßnahmen ehrlich bewerten. Statt „Auswirkungen gering“: Risiken fortbestehender sensibler Bilder, unerwarteter Archivierung, Metadaten und missbräuchlicher interner Zugriffe benennen. Dagegen die konkret umgesetzten Berechtigungen, Verschlüsselung, Zweckbindung, Fristen und Kontrollen stellen. Betroffeneninformation für nicht selbst hochladende Kontakte bzw. Abgebildete und Umgang mit Auskunft/Einschränkung in der Freigabe klären.

Backups nicht als erledigt behandeln. Die 14 Tage sind im Ausgangspaket eine Betreiberangabe, kein in dieser Prüfung verifizierter Betriebsnachweis. Die Roadmap, Punkt 1.5 nennt zusätzlich noch zu löschende alte Backups. Vor einer allgemeinen 14-Tage-Zusage müssen Umfang und Inhalt dieser Sonderkopien geprüft und gegebenenfalls bereinigt sein. Einmalige Deploy- oder Migrationssicherungen können die reguläre Rotation unterlaufen.

7. Welche Fragen beim Anwalt verbleiben

Die Agenda A1–A7 aus dem Decision-Update Bildrechte sollte erhalten bleiben, mit präzisierten Aufträgen:

Agenda	Konkreter Prüfauftrag
A1 AGB-Konsistenz	§ 8a und § 9 einschließlich Rechteeinräumung, Bearbeitung, Social-Media-Ausgabe und Rückgriff im Zusammenspiel freigeben. Code kann die Wirksamkeit nicht beweisen.
A2 Rolle des Portals	Tatsächliche Moderation, eigene Beiträge, Kennzeichnung und Leistungsversprechen bei der Einordnung berücksichtigen; Hoster-Status nicht allein aus dem Wording ableiten.
A3 Vertretung/Bestätigung	Kontoinhaber, Agentur, API-Akteur und Admin-Upload sauber zuordnen; Umfang des rechtlich belastbaren Rückgriffs prüfen.
A4 Archiv	Originale/Metadaten, Kontaktdaten, Ereignistypen, Standardfrist, Hold-Ende, Restdaten und sensible Inhalte ausdrücklich beurteilen. Die korrigierte Interessenabwägung vorlegen.
A5 Einbeziehung	Neue AGB/Richtlinien bei Bestandskunden und konkreten Einreichungen rechtlich tragfähig einbeziehen; Bestätigungsfassung und technisches Gate zusammen freigeben.
A6 KI-Kennzeichnung	Textausnahme nach F10 von Bildkennzeichnung trennen; Verantwortlichkeit für portalgesetzte Angaben und Korrekturverfahren prüfen.
A7 Gesamtpaket	Nach Beantwortung der Einzelpunkte schriftlich festhalten, welche Texte freigegeben sind, welche Betriebsbedingungen gelten und welche Restrisiken akzeptiert werden.

Syndikationsvertrag, Kennzeichnung bezahlter Boost-Platzierungen und Refund-Regel sind durch diesen Codeabgleich nicht abschließend bewertet. Sie können separat offen bleiben, sofern sie ausdrücklich aus dem Umfang dieses Datenschutz-/Archivabschlusses herausgenommen und weiterverfolgt werden. Die vier im Anwaltspaket referenzierten Löschanfragen sind weiterhin als eigene Prüfanlage beizufügen.

8. Konkrete Abschlusskriterien

Priorität	Aufgabe	Verantwortlich	Erledigt, wenn …
Vor Versand	Sachverhalt berichtigen	Betreiber + Entwicklung	K1–K8 eingearbeitet; Ist, Ziel und deaktivierte Funktionen eindeutig getrennt; kein unzutreffendes Lösch- oder Speicherungsversprechen.
Vor Freigabe	Aufbewahrungsmatrix beschließen	Betreiber + Anwalt	Für Original, Bestätigung, Payload, Archivmetadaten, Zugriffslog, Rohmail, Vorgang und dessen IP sind Zweck, Fristbeginn, Dauer, Ausnahme und Löschverantwortlicher festgelegt.
Vor Abschluss	Löschlücken schließen	Entwicklung	D9, nie veröffentlichte Textdatensätze, Rohmails sowie Archivrestdaten haben die beschlossene Bereinigung; Altbestand berücksichtigt; gezielte Tests grün.
Vor Abschluss	Hold-Verhalten angleichen	Entwicklung + Anwalt	Dokument und Code setzen dieselbe Regel um; Abschluss eines Streitfalls erzeugt keine unbegründete neue Vollfrist.
Vor Abschluss	Fehlerberichte minimieren	Entwicklung + Betrieb	Gegenbeispiele mit personenbezogenen Query-Werten und Fehlerobjekten geprüft; übermittelte Felder sowie getrennte Transportlogs dokumentiert.
Vor Abschluss	Betriebsnachweise sichern	Betrieb	D5-Löschläufe, GlitchTip-Frist, IMAP-Bereinigung und Backuprotation belegt; Sonderbackups geprüft.
Vor Abschluss	Restore nachweisen	Betrieb + Entwicklung	Unabhängiger aktueller Löschstand verfügbar; alle drei Restore-Szenarien erfolgreich geübt und protokolliert; Schlüsselwiederherstellung und Hold-Stand geprüft.
Vor Veröffentlichung	Rechtstexte freigeben	Anwalt + Betreiber	DSE, Bildrechtsklauseln, Bestätigungstext und Einbeziehung abgestimmt; Interessenabwägung korrigiert, datiert und abgezeichnet.
Zum Release	Versionen und Gate ausrollen	Entwicklung + Betreiber	DSE auf allen Hosts konsistent; AGB/Richtlinien mit passenden Bestätigungsfassungen; Gate erst mit freigegebenen Fassungen aktiv.
Separat	D7/D8/D10 aktivieren	Produkt + Anwalt + Entwicklung	Eigene Voraussetzungen erfüllt; bis dahin Flags nachweislich aus. Keine Voraussetzung für den jetzigen Abschluss.

Freigaberegel: Das Paket erhält erst dann den Status „abgeschlossen“, wenn alle einschlägigen Zeilen vor Abschluss/Veröffentlichung/Release nachweislich erledigt sind. Bis dahin lautet der sachgerechte Status „Codeabgleich abgeschlossen, rechtliche und betriebliche Freigabe offen“. Ein korrigiertes Anwaltspaket kann zuvor als ehrlicher Ist-/Zielstand zur Prüfung versandt werden.

9. Prüfverfahren und Grenzen

Geprüft wurden die beiden Dokumente, die referenzierte Bildrechteagenda, die aktuelle DSE-View, zentrale Archiv-, Bild-, Monitoring-, Login-, Mail- und Newsletterpfade, deren Konfigurationen, der Scheduler sowie einschlägige vorhandene Tests. Laravel-12-Dokumentation zu Verschlüsselung, Autorisierung und Scheduling wurde über Laravel Boost abgefragt. Gesetzes- und Anbieterquellen wurden am 12.10.2026 abgerufen; Empfehlungen sind von bestätigten Codebefunden getrennt.

Produktive Datenbestände, Hostingverträge, AVV, aktive Remote-Konfigurationen, Cron-Erfolge, Server-/Proxylogs und Backupbestände wurden nicht inspiziert. Die im Anwaltspaket genannten Produktivtermine wurden nicht unabhängig bestätigt. Konfigurationsdefaults sind keine Aussage über aktive Produktionsflags. Die AGB-Fassung kann aus legal_documents stammen; der Fallback 0.6 in config/legal.php beweist die produktive Fassung nicht.

Folgender gezielter Testlauf wurde direkt im DEV-Container ausgeführt:

php artisan test --compact tests/Feature/Archive/EvidenceArchiveTest.php tests/Feature/Archive/EvidenceArchiveFollowUpTest.php tests/Feature/Monitoring/LogRetentionTest.php tests/Feature/Monitoring/ErrorReportingTest.php tests/Feature/Monitoring/BrowserErrorReportingTest.php tests/Feature/Images/ImageLifecycleTest.php

Ergebnis: 82 Tests bestanden, 559 Assertions, Laufzeit 21,77 Sekunden. Geprüft wurden die vorhandenen Tests zu Beweisarchiv, Archiv-Nacharbeiten, Protokollfristen, Server- und Browserfehlerberichten sowie Bildlebenszyklus. Der zunächst verwendete Sail-Aufruf scheiterte an der im DEV-Container nicht verfügbaren Docker-/Podman-Anbindung; nach Klarstellung des Betreibers erfolgte der erfolgreiche direkte PHP-Aufruf.

Die bestandenen Tests bestätigen die von ihnen abgedeckten Implementierungsfälle. Sie widerlegen nicht die festgestellten Abweichungen zwischen Dokumenten und Code und ersetzen weder produktive Konfigurationsnachweise noch eine betriebliche Restore-Übung. Für die reine Auswertungsdatei wurden keine neuen Anwendungstests angelegt.

Die lokalen Markdown-Dateiverweise wurden auf vorhandene Ziele geprüft; die neue Datei wurde auf Whitespace-Fehler geprüft.

Diese Auswertung ist eine technische und fachliche Entscheidungsvorlage. Die verbindliche rechtliche Bewertung der Abwägung und Vertragsklauseln bleibt Teil der ausdrücklich vorgesehenen anwaltlichen Freigabe.