dev: Rechtspaket mit Nachweisordner, Archiv und Deploy-Notiz v1.9.0

Versandfassung mit Codeabgleich vom 13.10. korrigiert (Zugriffsprotokoll
des Beweisarchivs als Ziel, Admin-Bestand, Juli-Mails mit Zahlen und
Empfängerregel, C2PA als geplant, Gate-Dialog heute), Anlage 6 abgelegt.
Neuer Ordner rechtliches/nachweise mit Checkliste, Juli-Mailtexten,
OpenAI-Endpunkten, BN-01-Vorlage und BN-02-Ablauf inklusive Notfallzugang.
Vorfassungen, Codeauswertung, To-do-Liste und Rückfragen nach
archive/rechtliches-2026-10. Deploy-Notiz archive/betrieb/deploy-v1.9.0.md.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

dev/archive/betrieb/deploy-v1.9.0.md

@@ -0,0 +1,33 @@
+# Deploy v1.9.0 — Rechtspaket: Boost-Kennzeichnung und Rollenprüfung
+
+**Stand:** 13.10.2026 · **Live bisher:** `v1.8.1` · Ablauf nach [git-deploy.md](../../betrieb/git-deploy.md), Abschnitte C und D.
+
+**Inhalt** (Aufgaben U10 und BN-02 aus dem [Anwaltspaket](../../rechtliches/anwaltspaket-datenschutz-2026-10-12.md)):
+
+- Boost-Label „Gebuchte Platzierung“ (en „Booked placement“) statt „Top-Platzierung“ auf Start- und Branchenseite. Die Erklärung erscheint am Desktop beim Überfahren und auf Mobil per Tipp; Screenreader lesen sie mit.
+- Kopfzeile über dem Aufmacher „Aktuell“ statt „Top-Auswahl“.
+- Preisseite: „Geboostete Meldungen sind als gebuchte Platzierung gekennzeichnet.“
+- Admin ▸ Pressemitteilung: Panel „Gebuchte Platzierung“ mit Aktion „Boost beenden“. Sie braucht einen Pflichtgrund und `billing:manage`, bucht keine Credits zurück und schreibt den Verlaufstyp „Boost beendet“.
+- `php artisan audit:admins`: Berechtigungsliste als Markdown (Nachweis BN-02).
+
+**Umfang:** keine Migration, keine neuen `.env`-Werte, Scheduler unverändert, neue Assets (beide Builds, mitcommittet). Suite 2.527 grün, einer übersprungen; Larastan ohne Meldung.
+
+## Deploy
+
+```bash
+cd ~/pressekonto.com
+bash dev/betrieb/deploy.sh v1.9.0
+```
+
+## Prüfungen danach
+
+- `/health` meldet `v1.9.0`, die Betriebsüberwachung ist grün.
+- Startseite presseecho.de: Kopfzeile „… · Aktuell“; ohne laufenden Boost erscheint kein Label.
+- Preisseite: Satz zur Kennzeichnung in der Note „Boost — was Sie bekommen und was nicht“.
+- `php artisan audit:admins` läuft und zeigt den Bestand.
+
+## Direkt im Anschluss (Rechtspaket)
+
+1. Rollenprüfung nach [bn-02-ablauf.md](../../rechtliches/nachweise/bn-02-ablauf.md): Vorher-Liste, neue Login-Adresse und Super-Admin-Merker für das Betriebskonto, Altkonten bereinigen, Nachher-Liste.
+2. Test-Boost auf eine eigene Test-Mitteilung buchen (Credits über Admin ▸ Benutzer gutschreiben). Screenshots `boost-01` bis `boost-04` nach [nachweise/README.md](../../rechtliches/nachweise/README.md) aufnehmen, dann unter Admin ▸ Pressemitteilung „Boost beenden“.
+3. Zeile im Protokoll von `git-deploy.md` und in der Release-Tabelle der Roadmap nachtragen.

dev/archive/rechtliches-2026-10/antworten-rueckfragen-anwaltspaket-2026-10-12.md

@@ -0,0 +1,174 @@
+# Antworten auf die Rückfragen zum Anwaltspaket
+
+> **Korrektur 13.10.2026 (archiviert):** Abschnitt 1 ist überholt. Die Juli-Mails wurden über das Newsletter-Modul versendet (21.07. an 10, 22.07. an 954 Konten), nicht über `auth:send-go-live-mails`. Belege: [`nachweise/`](../../rechtliches/nachweise/README.md).
+
+> **Historischer Befund mit Ergänzungen:** Die [Korrekturen und Antworten](../../rechtliches/korrekturen-und-umsetzungsauftrag-2026-10-12.md) präzisieren insbesondere Juli-Versand, OpenAI-Speicherung, Berechtigungen und geplante Portal-Updates. Die frühere Schlussfolgerung aus verbliebenen Reset-Tokens auf nicht versandte Mails ist nicht belastbar; Betreiberangaben und Versandnachweise sind getrennt zu berücksichtigen.
+
+**Stand:** 12.10.2026 · **Gehört zu:** [`anwaltspaket-datenschutz-2026-10.md`](anwaltspaket-datenschutz-2026-10.md)
+
+**Grundlage:** Code (Release v1.8.0), Live-Seiten und Summen aus der lokalen Kopie der Live-Datenbank (Stand etwa 07.10.2026; nur Zählungen, keine Personendaten).
+
+**Status:** ✅ aus Code und Daten beantwortet · ◐ teilweise, Rest beim Betreiber · ✗ nur der Betreiber weiß es
+
+| Nr. | Status | Kurzantwort |
+|---|---|---|
+| 1 | ◐ | Überwiegend Gratiskonten. Nach Datenlage nicht informiert. Die alte Datenschutzerklärung liegt nicht im Repository. |
+| 2 | ✅ | Noch nicht gebaut. Weder Modell noch Protokoll der Überarbeitung stehen fest. |
+| 3 | ✅ | Ja. Texte werden auf der Detailseite gekennzeichnet, Bilder am Bild, im Bildnachweis und im Vorschaubild. |
+| 4 | ◐ | Credits verfallen technisch nicht. Agency ist monatlich kündbar. Eine Erstattung gibt es im System nicht. Überweisung nur bei Altkunden. |
+| 5 | ◐ | OpenAI-Aufrufe ohne Speicherung (`store`). Ob die Verträge vorliegen, weiß nur der Betreiber. Gemini und Anthropic stehen in der DSE, werden aber nicht genutzt. |
+| 6 | ✅ | 6 Konten mit Admin-Rechten, davon 3 aktiv. Mails an Nichtkunden werden mit Adresse und Betreff protokolliert. |
+| 7 | ◐ | Die Zähler liegen in Redis, nicht im Arbeitsspeicher von PHP. Ob Redis auf die Platte schreibt, zeigt nur der Server. |
+| 8 | ◐ | Nutzer-ID nur im Kundenbereich des Hubs, derzeit ausgeschaltet. Die Frist für Rohdaten ist eine Einstellung der Instanz. |
+| 9 | ✅ | Einzelunternehmen „adametz.media, Inhaber Kevin Adametz“, so auch im Impressum. |
+
+---
+
+## 1. Altkonten (F7, § 7 Abs. 3 UWG) — ◐
+
+**Zahlen**
+
+- 66.368 übernommene Konten: 50.485 von businessportal24, 15.883 von presseecho.
+- Angelegt zwischen Juli 2010 und Juli 2026; 59.602 davon sind aktiv.
+- 46.627 Konten haben mindestens eine Mitteilung veröffentlicht.
+- **Nur 445 Konten haben je eine Rechnung bekommen.** Das sind 887 Rechnungen von 2010 bis 2026, bezahlt per PayPal (475) und Überweisung (rund 300).
+- Weit über 99 % sind also **Gratiskonten**. Auf den alten Portalen war Veröffentlichen kostenlos.
+
+**Information bei der Migration**
+
+- Nach der Datenlage **wurden die Konten nicht informiert**. Der Befehl `auth:send-go-live-mails` erzeugt pro Konto ein Token zum Zurücksetzen des Passworts. Aus dem Juli 2026 liegt genau eines vor, bei rund 60.000 Mails müssten es Zehntausende sein.
+- Seit dem 20.07. haben sich nur 23 Altkonten angemeldet.
+- Roadmap 5.8 führt die Go-Live-Mails weiter als „Stand unbekannt“.
+- **Betreiber bitte bestätigen.**
+
+**Datenschutzerklärung bei der Erhebung:** Sie liegt nicht im Repository. Quelle wäre das Archiv der alten Portale, zum Beispiel die Wayback Machine für presseecho.de und businessportal24.com 2010–2026. ✗
+
+**Bewertung für F7:** Wer nie etwas gekauft hat, ist kein Bestandskunde im Sinne von § 7 Abs. 3 UWG. Infrage kämen höchstens die 445 zahlenden Konten, und auch nur mit Hinweis auf das Widerspruchsrecht bei der Erhebung. Das stützt die Empfehlung „nur Opt-in“.
+
+## 2. Portal-Updates: Modell und dokumentierte Überarbeitung (F10, A6) — ✅
+
+- **Noch nicht gebaut.** Die Pipeline aus dem [Decision-Update Changelog](../../changelog/Decision-Update_Changelog_Automatisierung_2026-10-04.md) steht auf Roadmap 6.6, nicht begonnen.
+- **Modell:** Für die Portal-Updates ist noch keines festgelegt. Die bestehenden Prüfungen laufen über OpenAI, Standard `gpt-5.4-mini` (`OPENAI_MODEL`). Naheliegend ist, dasselbe Modell zu nehmen.
+- **Überarbeitung, wie geplant:**
+  - Stufe 3: Admin-Liste zum Streichen, Umformulieren und Freigeben.
+  - Stufe 5: manuelle Freigabe des Artikels.
+  - Entschieden ist bisher nur „jeder Artikel wird vom Betreiber überarbeitet und freigegeben“ (O4). Diff und Freigabeprotokoll sind noch nicht festgelegt.
+- **Vorschlag, damit „dokumentierte Überarbeitung“ belegbar ist:** pro Artikel speichern
+  - den KI-Entwurf und die veröffentlichte Fassung,
+  - den Unterschied zwischen beiden,
+  - wer freigegeben hat und wann.
+
+  Das kostet wenig, wenn es beim Bau gleich mit angelegt wird.
+- **Kundenmeldungen (A6):** Das Portal bearbeitet Kundentexte nicht (AGB § 7 Abs. 5). Die KI-Angabe ist eine Selbsterklärung des Einreichers, siehe Frage 3.
+
+## 3. Kennzeichnung von KI-Inhalten in Kundenmeldungen (F10, A6) — ✅
+
+`ai_generated` gehört zur Bild-Deklaration. Für Texte heißen die Werte `mostly_ai` und `fully_ai`.
+
+**Texte**
+
+- Ist eine Mitteilung als „ganz oder überwiegend mit generativer KI erstellt“ deklariert, steht auf der **Detailseite über dem Text** ein Hinweiskasten. Er spricht in der Stimme des Einreichers: „KI-generiert: Nach Angaben des einreichenden Unternehmens wurde diese Pressemitteilung ganz oder überwiegend mit generativer KI erstellt.“
+- In Listen und Teasern erscheint keine Kennzeichnung.
+- Bestand: 9 Mitteilungen `mostly_ai`, 5.122 `none`. Rund 176.000 Altmeldungen haben keine Angabe.
+
+**Bilder**
+
+- Bei `ai_generated` oder `ai_edited` gibt es ein **Schild am Bild** auf der Detailseite: „KI-generiert“ bzw. „KI-bearbeitet“.
+- Der Hinweis erscheint außerdem in der Bildinformation, mit Angabe der Quelle der Kennzeichnung, und in der Nachweiszeile der Teaser.
+- Er ist auch in das Vorschaubild für soziale Netzwerke eingeblendet.
+- Bestand: 24 `ai_generated`, 8 `ai_edited`, 7 Altbilder mit KI-Merker.
+
+**Lücke**
+
+- Die **Alt-API** (`/service/…`, connektar) setzt bei Texten selbst „ohne KI“ und bestätigt das im Namen des Kunden.
+- API v1 verlangt die Angabe dagegen als Pflichtfeld.
+- Siehe Roadmap 2, „connektar `ai_declaration`“.
+
+## 4. Credits, Kündigung, Erstattung, Überweisung — ◐
+
+- **Verfall:**
+  - AGB § 5 Abs. 2: mindestens drei Jahre ab Ende des Kaufjahres.
+  - **Im Code gibt es weder einen Verfall noch die versprochene Erinnerungsmail.** Credits verfallen derzeit also nie.
+  - Die Erinnerung muss vor dem ersten möglichen Ablauf gebaut sein. Für Käufe aus 2026 ist das der 31.12.2029.
+- **Agency** (199 €/Monat) wird wie alle Tarife monatlich oder jährlich bezahlt. Bei monatlicher Zahlung ist er nach AGB § 11 Abs. 2 monatlich kündbar.
+- **Erstattung:**
+  - Das System hat keinen Ablauf dafür. Die Status „refunded“ sind angelegt, werden aber nirgends gesetzt.
+  - In den Daten seit Go-Live: keine erstattete Zahlung, 17 bezahlte und 3 stornierte Rechnungen.
+  - Bisherige Fälle liefen, wenn überhaupt, im Stripe-Dashboard. Wie sie abgerechnet wurden, weiß nur der Betreiber. ✗
+- **Überweisung:**
+  - Für Neukunden nur Stripe.
+  - Überweisung gibt es nur für Altkunden mit Bestandsschutz („MAN-Kreis“): 23 alte Zahlungsvereinbarungen, bisher 3 MAN-Rechnungen.
+  - „FMI“ kommt im Code und in den Altdaten nicht vor. Bitte die Abkürzung erklären. ✗
+
+## 5. Auftragsverarbeitungsverträge, OpenAI (D2, D4, D6, D8, F9) — ◐
+
+- **Verträge:** Ob sie abgeschlossen sind, weiß nur der Betreiber. ✗ Wo man sie üblicherweise abschließt:
+  - **Hetzner:** online in Robot bzw. der Cloud Console. Die DSE behauptet in Abschnitt 3, dass er besteht.
+  - **ALL-INKL:** im KAS-Kundenbereich.
+  - **Cloudflare:** Die Customer-DPA ist Teil der Nutzungsbedingungen.
+  - **Stripe:** Die DPA ist Teil des Services Agreement. Laut DSE ist Stripe für die Zahlungsabwicklung aber selbst verantwortlich.
+- **OpenAI:**
+  - Die drei Prüfungen (Klassifizierung, Inhaltsbewertung, Bild-Vorabcheck) rufen `chat/completions` ohne `store`-Parameter auf. Die Anfragen werden damit nicht für spätere Verwendung gespeichert.
+  - Ob ein DPA abgeschlossen ist und ob Zero Data Retention beantragt wurde, steht nicht im Code. Beides sind Einstellungen der Organisation bei OpenAI. ✗
+  - Ohne Zero Data Retention bewahrt OpenAI Anfragen bis zu 30 Tage zur Missbrauchskontrolle auf.
+
+  API über OpenAI Ireland
+https://openai.com/de-DE/index/offering-zero-data-retention-for-frontier-models/
+https://openai.com/de-DE/index/expanding-data-residency-access-to-business-customers-worldwide/
+Um die Option „Keine Datenaufbewahrung“ (Zero Data Retention / ZDR) für die Prüfung Ihrer Pressemitteilungen zu aktivieren, müssen Sie die KI über die OpenAI API an Ihr Presseportal anbinden. Für die neueste Generation der Frontier-Modelle nutzt OpenAI das Verfahren Private Safety Processing (PSP). Dadurch werden missbräuchliche Muster vollautomatisch erkannt, ohne dass OpenAI Ihre Prompts oder die Texte der Pressemitteilungen dauerhaft aufbewahrt oder für menschliche Reviews speichert. "das ist gemacht worden. Eine andere Möglichkeit besteht derzeit nicht."
+
+- **Befund DSE Abschnitt 10/8:** Dort stehen „Google Gemini“ und „Anthropic Claude“. **Beide sind nicht angebunden.** Es läuft nur OpenAI, beziehungsweise ohne Schlüssel eine regelbasierte Prüfung. In Fassung 0.4 sollte nur OpenAI stehen, mit einer Formulierung für künftige Anbieter.
+
+## 6. Aktivitätsverlauf (F3) — ✅
+
+- **Zugriff:**
+  - Jeder mit Admin-Zugang sieht den Verlauf unter Admin ▸ Berichte ▸ Aktivität. Eine eigene Berechtigung gibt es dafür nicht.
+  - Admin-Zugang haben die Rollen `admin` und `editor` sowie der Super-Admin-Merker.
+  - Betroffen sind **6 Konten, davon 3 aktiv**:
+    - das Konto unter `@pressekonto.com` (letzte Anmeldung 07.10.2026),
+    - eines unter `@me.com` (14.07.2026),
+    - eines unter `@stern-consulting.eu` (letzte Anmeldung 2012).
+  - Die drei inaktiven (`@stern-tours.de`, `@googlemail.com`, `@gmx.at`) sind gesperrt.
+  - **Bitte prüfen**, ob die beiden aktiven Fremdkonten dir gehören. Wenn nicht: Admin-Rolle entziehen. Seit v1.4 brauchen Admins zwar einen zweiten Faktor, das ändert aber nichts an der Frage des Zugriffs.
+- **Mails an Nichtkunden:**
+  - **Ja.** Jede versendete Mail wird mit **Empfängeradresse und Betreff** protokolliert, als „Handelnder“ steht der Kontoname oder sonst die Adresse.
+  - Das betrifft auch Pressekontakte ohne Konto. 5.007 von 7.642 Mail-Einträgen gehören zu keinem Konto.
+  - Ein Name erscheint bei Nichtkunden nur, wenn er im Betreff steht.
+  - Seit v1.8 gilt eine Löschfrist von 395 Tagen.
+
+## 7. Speicher der Anmeldebegrenzung (F4, Text 7a) — ◐
+
+- **Wo die Zähler liegen:** Sie laufen über den Laravel-Cache. Der steht laut Vorlage auf **Redis** (`CACHE_STORE=redis`), ebenso die Sessions. Den Wert in der Live-`.env` bitte bestätigen.
+- **Was gezählt wird:**
+  - Fehlversuche je IP-Adresse: 15 Minuten, Sperre ab 20.
+  - Zusätzlich Versuche je **Kombination aus E-Mail-Adresse und IP**: 1 Minute, höchstens 5.
+  - Text 7a nennt nur die IP-Adresse.
+- **„Im Arbeitsspeicher“ stimmt nur eingeschränkt.** Redis hält die Daten im Arbeitsspeicher, schreibt je nach Konfiguration aber Sicherungen auf die Platte (RDB/AOF). Prüfen auf dem Server:
+
+  ```
+  redis-cli CONFIG GET save
+  redis-cli CONFIG GET appendonly
+  ```
+
+  ✗
+- **Vorschlag für 7a:** „… für höchstens 15 Minuten in einem Zwischenspeicher; die Einträge verfallen danach automatisch.“ Damit stimmt der Text unabhängig von der Redis-Konfiguration.
+- Getrennt davon gibt es die Tageszählung fehlgeschlagener Anmeldungen (`failed_login_tallies`, 90 Tage). Sie steht bereits im Paket.
+
+## 8. Umami (F6) — ◐
+
+- **Wo die Nutzer-ID gesetzt wird:**
+  - Nur im **Kundenbereich auf dem Hub** (Routen `me.*`), nie während eines Support-Zugriffs auf ein Kundenkonto.
+  - Nur wenn `UMAMI_PORTAL_ENABLED` **und** `UMAMI_IDENTIFY_USERS` an sind. **Beide sind derzeit aus** (Roadmap 3.6).
+  - Auf den Portalen gibt es nie eine Nutzer-ID.
+- **Form der ID:** `user-<Datenbank-ID>`, unverschlüsselt. Pseudonym nur gegenüber Umami; der Betreiber kann sie direkt zuordnen. Falls der Anwalt es verlangt, lässt sie sich mit einem Prüfwert (HMAC) verschleiern.
+- **Frist für Rohdaten:**
+  - Die Anwendung legt keine fest; sie ist eine Einstellung der Instanz auf sys.adametz.media.
+  - Nach meinem Kenntnisstand löscht Umami ohne eigene Einrichtung nichts automatisch.
+  - Bitte auf der Instanz prüfen und eine Frist festlegen, zum Beispiel 13 Monate, passend zu 5a. ✗
+
+## 9. Verantwortlicher (DSE Abschnitt 1) — ✅
+
+- Einzelunternehmen, ohne eigene Rechtsform.
+- Schreibweise: **„adametz.media, Inhaber: Kevin Adametz, In der Lake 4, 33739 Bielefeld“**. So steht es in DSE, AGB § 1 Abs. 2 und Impressum (§ 5 DDG, USt-IdNr. DE298729654).
+- „Adametz Media“ kommt in den Rechtstexten nicht vor.
+- Bitte bestätigen, dass sich daran nichts ändert, etwa durch eine Gründung.

dev/archive/rechtliches-2026-10/anwaltspaket-datenschutz-2026-10.md

@@ -218,6 +218,6 @@ Stil und Aufbau wie die bestehende DSE. Abschnittsnummern vorläufig; die Einord
 
 1. Decision-Update Bildrechte und Beweisarchiv vom 22.09.2026 (`dev/bildrechte/Decision-Update_Bildrechte_Beweisarchiv_2026-09-22.md`), Abschnitte 3, 4, 7, 8
 2. Interessenabwägung Beweisarchiv (`dev/rechtliches/interessenabwaegung-beweisarchiv-2026-10.md`)
-3. Aktuelle DSE (Fassung 0.3 mit 5a und 6a), AGB 0.6
-4. Boost-Platzierung (`dev/archive/release/boost-platzierung-offen.md`)
+3. Aktuelle DSE (Fassung 0.3 mit 5a und 6a, Hub und Portale) und AGB 0.6 im Wortlaut: [`../../rechtliches/anlage-rechtstexte-live-2026-10-12.md`](../../rechtliches/anlage-rechtstexte-live-2026-10-12.md), Teile A–C, mit Hinweisen zum Abgleich
+4. Boost-Platzierung: Note der Preisseite im Wortlaut und Label „Top-Platzierung“ auf Start- und Branchenseite in derselben Anlage, Teil D; Hintergrund in `dev/archive/release/boost-platzierung-offen.md`
 5. Screenshots (siehe Abschnitt 7)

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

@@ -0,0 +1,225 @@
+# 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](anwaltspaket-datenschutz-2026-10.md), Entwurf vom 09.10.2026.
+- [Interessenabwägung Beweisarchiv](interessenabwaegung-beweisarchiv-2026-10.md), 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](https://www.edpb.europa.eu/system/files/2024-10/edpb_guidelines_202401_legitimateinterest_en.pdf).
+
+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](../../../app/Services/Archive/PressReleaseArchiver.php), insbesondere `depublicationState()` ab Zeile 113 und `pressReleaseHeader()` ab Zeile 305; [ImageRightsConfirmation](../../../app/Models/ImageRightsConfirmation.php) und [ImageUploader](../../../app/Services/PressRelease/Images/PressReleaseImageUploader.php), `recordConfirmation()` ab Zeile 458.
+- D2: [ErrorReportScrubber](../../../app/Support/Monitoring/ErrorReportScrubber.php), [Browser-Fehlererfassung](../../../resources/js/error-reporting.js), [Sentry-Konfiguration](../../../config/sentry.php).
+- D3: [RecordAuthActivity](../../../app/Listeners/RecordAuthActivity.php), [LoginCompletion](../../../app/Services/Auth/LoginCompletion.php), [LoginIpThrottle](../../../app/Services/Auth/LoginIpThrottle.php), [FortifyServiceProvider](../../../app/Providers/FortifyServiceProvider.php), [Cache-Konfiguration](../../../config/cache.php).
+- D4: [FetchMailBounces](../../../app/Console/Commands/FetchMailBounces.php), [PurgeConversionEvents](../../../app/Console/Commands/PurgeConversionEvents.php), [GateOutgoingMail](../../../app/Listeners/GateOutgoingMail.php), [Bounce-Konfiguration](../../../config/bounces.php).
+- D5: [ActivityEvent](../../../app/Models/ActivityEvent.php), [ApiUsageLog](../../../app/Models/ApiUsageLog.php), [LogApiUsage](../../../app/Http/Middleware/LogApiUsage.php), [Monitoring-Konfiguration](../../../config/monitoring.php), [Scheduler](../../../routes/console.php).
+- D6: [TurnstileVerifier](../../../app/Services/Spam/TurnstileVerifier.php), `verify()` ab Zeile 59.
+- D7: [Umami-Komponente](../../../resources/views/components/web/umami.blade.php), [Services-Konfiguration](../../../config/services.php).
+- D8: [Bildkonfiguration](../../../config/images.php), [OpenAiImagePrecheckDriver](../../../app/Services/Image/Precheck/Drivers/OpenAiImagePrecheckDriver.php), [PrecheckImagePreparer](../../../app/Services/Image/Precheck/PrecheckImagePreparer.php).
+- D9: [ContactMessage](../../../app/Models/ContactMessage.php), [LegalRequest](../../../app/Models/LegalRequest.php), [WithdrawalRequest](../../../app/Models/WithdrawalRequest.php), [TerminationRequest](../../../app/Models/TerminationRequest.php), [BookingConfirmation](../../../app/Models/BookingConfirmation.php), [Scheduler](../../../routes/console.php).
+- D10: [Newsletter-Konfiguration](../../../config/newsletter.php), [CampaignSender](../../../app/Services/Newsletter/CampaignSender.php), [CampaignRecipients](../../../app/Services/Newsletter/CampaignRecipients.php), `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](../../../app/Console/Commands/PurgeExpiredPressReleaseDrafts.php), 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](../../../app/Console/Commands/PurgeRedactionSnapshots.php) 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()](../../../app/Services/Archive/EvidenceArchive.php), 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](https://www.gesetze-im-internet.de/bgb/__195.html), [§ 199 BGB](https://www.gesetze-im-internet.de/bgb/__199.html).
+
+### K4 — Löschvermerke und Zugriffsprotokolle behalten Personenbezug
+
+[EvidenceArchive::tombstone()](../../../app/Services/Archive/EvidenceArchive.php), 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](../../../app/Models/ArchiveAccessLog.php) 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](../../betrieb/deploy-runbook.md), 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](../../../routes/admin.php), Zeilen 47–61 und ab 164; [Evidence-Controller](../../../app/Http/Controllers/Admin/PressReleaseImageEvidenceController.php), ab Zeile 44; [Permission](../../../app/Authorization/Permission.php).
+
+Inhaltsabrufe und Hold-Änderungen werden protokolliert. Die [Archivlistenansicht](../../../resources/views/livewire/admin/archive/index.blade.php) 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](../../../app/Support/Monitoring/ErrorReportScrubber.php) 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](../../../resources/js/error-reporting.js), `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](https://developers.openai.com/api/docs/guides/your-data) 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](https://www.gesetze-im-internet.de/ttdsg/__25.html) 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](https://www.gesetze-im-internet.de/uwg_2004/__7.html). Für die begrenzte redaktionelle Ausnahme in F10 siehe [Art. 50 Abs. 4 KI-VO](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/deu).
+
+## 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](https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?from=EN&qid=1672161133881&uri=CELEX%3A32016R0679).
+
+**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](https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?from=EN&qid=1672161133881&uri=CELEX%3A32016R0679).
+
+**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](../../roadmap.md) 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](../../bildrechte/Decision-Update_Bildrechte_Beweisarchiv_2026-09-22.md) 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:
+
+```bash
+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.

dev/archive/rechtliches-2026-10/todo-umsetzungsreife-und-abschluss-2026-10.md

@@ -0,0 +1,181 @@
+# To-do-Liste: Rechtspaket umsetzungsreif machen und abschließen
+
+> **Fortgeschriebener Arbeitsstand:** Die eingetragenen Betreiberentscheidungen bleiben erhalten. Die [Korrekturen mit Aufbewahrungsmatrix und Umsetzungsauftrag](../../rechtliches/korrekturen-und-umsetzungsauftrag-2026-10-12.md) konkretisieren die Vorbereitung und führen neue Aufgaben unter RP-01 bis RP-12. Die U-Kennungen unten sind historische Verweise; sie dürfen nicht mit den anders belegten U-Kennungen im Klärungsdokument vermischt werden.
+
+**Stand:** 12.10.2026
+
+**Grundlage:** [Auswertung mit Codeabgleich und Entscheidungen](auswertung-und-abschlussentscheidungen-2026-10-12.md).
+
+**Ziel:** Erst die fachlichen Vorgaben so weit klären, dass die Entwicklung ohne offene Grundsatzentscheidungen arbeiten kann. Danach umsetzen, prüfen und das Paket freigeben.
+
+**Aktueller Stand:** Codeabgleich vorhanden; 82 bestehende Tests mit 559 Assertions bestanden. Die nachstehenden Entscheidungen, Umsetzungen und Betriebsnachweise sind damit noch nicht erledigt. Vorgeschlagene Fristen sind Arbeitsvorschläge aus der Auswertung, keine bereits erteilten Freigaben.
+
+## 1. Deine nächsten Aufgaben als Betreiber
+
+Diese fünf Punkte benötigen deinen Beitrag. Aufbereitung, Dokumentkorrekturen, technische Spezifikation und spätere Implementierung können wir übernehmen.
+
+### B1 — Umfang festlegen
+
+- [ ] Festhalten, dass dieses Paket die bereits genutzten Datenschutzverarbeitungen und das Bildrechte-/Beweisarchiv einschließlich DSE, Bildrechtsklauseln, Bestätigungstext und Zustimmungsgate umfasst.
+JA
+- [ ] Entscheiden, ob die Empfehlung übernommen wird: Hub-Analyse mit Nutzerkennung, KI-Bildprüfung und Newsletter-Kampagnen bleiben ausgeschaltet und werden separat behandelt.
+JA
+- [ ] Syndikationsvertrag, Refund-Regel und bezahlte Platzierungen eigenen Arbeitspaketen mit Verantwortlichen zuordnen, soweit sie nicht in diesem Paket abgeschlossen werden sollen.
+JA
+
+**Ergebnis:** Ein schriftlich festgelegter Umfang. Für bereits aktive Funktionen lässt sich eine notwendige Klärung nicht durch bloßes Verschieben aus dem Paket erledigen. Deshalb müssen die tatsächlichen Aktivierungsstände unter B3 geprüft werden.
+
+### B2 — Gewünschte Aufbewahrungsregeln auswählen
+
+Die folgende Tabelle ist die Entscheidungsvorlage. Du legst die geschäftliche Zielrichtung fest; der Anwalt prüft die rechtliche Tragfähigkeit. Wir übersetzen das Ergebnis anschließend in konkrete Löschregeln.
+
+| Entscheidung | Meine vorgeschlagene Zielrichtung | Was abschließend feststehen muss |
+|---|---|---|
+| **E1 Nie veröffentlichte Entwürfe** | Nach 180 Tagen ohne Bearbeitung vollständig löschen. | Fristbeginn, Umgang mit verknüpften Datensätzen und Ausnahmen für belegte Streitfälle. |
+| **E2 Abgelehnte, nie veröffentlichte Einreichungen** | Medien nach 180 Tagen entfernen; Volltext nicht unbefristet behalten. Allenfalls minimalen Ablehnungs-/Vertragsnachweis befristet erhalten. | Welche Nachweisfelder erforderlich sind und wie lange sie bleiben. Diese Frist ist noch offen und muss vor der Umsetzung festgelegt werden. |
+| **E3 IP-Adressen** | Vorgangs-IP-Adressen nach 90 Tagen entfernen; letzte Login-IP nach 90 Tagen ohne neue Anmeldung entfernen. | Betroffene Felder, Fristbeginn und Verfahren bei einem konkreten Sicherheitsvorfall. Der Vorgang selbst bekommt eine eigene Frist. |
+| **E4 Aktivitätsverlauf** | Gewöhnliche Anmelde- und Fehlversuchsereignisse 90 Tage; übrige notwendige Support-/Geschäftsereignisse höchstens 395 Tage. API-Zugriffe 90 Tage. | Zuordnung jedes Ereignistyps zu einer Frist; welche Daten für welchen Zweck gebraucht werden. |
+| **E5 E-Mail-Daten** | Rohmails im Bounce-Postfach nach 90 Tagen, ausgewertete Bounce-Datensätze nach 395 Tagen löschen. Sperrliste zweckgebunden erhalten. | Fristbeginn, betroffene Ordner einschließlich Sonderfälle, Minimalfelder der Sperrliste sowie Prüfrhythmus und Entsperrverfahren. |
+| **E6 Archiv und Legal Hold** | Drei Jahre nach Jahresende als zu prüfende Standardfrist; kein automatischer vollständiger Fristneustart nach Streitende. | Frist je Ereignistyp; Überprüfung und Ende eines Holds; Behandlung weiterer konkret begründeter Ansprüche. |
+| **E7 Archivrest und Zugriffslog** | Beim Löschen des Beweisinhalts auch unnötige Personenreferenzen, Freitexte und Zugriffsdetails entfernen; minimale Löschkennungen für Restore-Schutz behalten. | Exakte Restfelder und deren Endfrist bzw. eindeutig auswertbare Löschbedingung. Abstimmung mit allen rückspielbaren Backups. |
+| **E8 Originaldateien und Kontakte** | Original und veröffentlichte Fassung grundsätzlich als Nachweis behalten; Kontakte und Einreicherdaten nur im begründeten Umfang. | Umgang mit GPS-/Gerätemetadaten, sensiblen Bildern, kleinen Korrekturen und zusätzlichen Kontaktdaten. |
+| **E9 Fachliche Vorgänge und Snapshots** | Vorhandene Fristen mit dem tatsächlichen Löschverfahren abgleichen; IP-Löschung und Vorgangslöschung getrennt behandeln. | Fristen für reguläre Kontakte, Meldeverfahren, Widerrufe, Kündigungen, Buchungsnachweise und abgelehnte Meldungen; Ausnahmebehandlung bei offenen Archivaufträgen. |
+
+- [ ] Für E1–E9 jeweils „Vorschlag übernehmen“ oder eine konkrete Abweichung notieren.
+Vorschlag übernehmen
+- [ ] Offene Restfristen und Datenumfänge als ausdrückliche Fragen an den Anwalt kennzeichnen.
+
+**Ergebnis:** Beschlossene Arbeitsvorschläge für die anwaltliche Prüfung. Noch keine Löschung von Bestandsdaten.
+
+### B3 — Betriebsinformationen bereitstellen bzw. prüfen lassen
+
+- [ ] Verantwortlichen mit Firmenname/Anschrift sowie Ansprechpartner für Datenschutz, Betrieb und Freigabe festlegen.
+adametz.media
+Inhaber: Kevin Adametz
+In der Lake 4
+33739 Bielefeld
+Deutschland
+
+E-Mail: info@pressekonto.com
+Telefon: +49 5206 7076721 (kein telefonischer Support)
+
+- [ ] Tatsächliche Produktivstände von Hub-Analyse, Nutzerkennung, Bildprüfung, Newsletterversand und Zustimmungsgate bestätigen lassen.
+- [ ] Aktive AGB-/DSE-Fassung und produktiven Release-Stand feststellen lassen.
+- [ ] Speicherfristen der GlitchTip-Instanz und ihrer Webserver-/Proxylogs belegen lassen.
+- [ ] Backupübersicht erstellen lassen: reguläre Sicherungen, Archiv-Disk, Datenbank und alte Deploy-/Migrationskopien; jeweilige Speicherorte und tatsächliche Aufbewahrung.
+- [ ] Prüfen lassen, ob im Bounce-Postfach bereits eine serverseitige Löschregel existiert und welche Ordner sie erfasst.
+- [ ] Vorhandene Anbieter-/Auftragsverarbeitungsunterlagen für die tatsächlich eingesetzten Dienste zusammenstellen, insbesondere Hosting, E-Mail, Fehlerprotokoll und Turnstile; fehlende Unterlagen markieren.
+- [ ] Zuständigen und Ablauf für Auskunft, Löschung, Widerspruch, Einschränkung und sensible Bildinhalte benennen.
+
+Die offen punkte hier Einmal vor belegen mit den Standards defauls beziehungsweise schau auch in den Datenschutz /system nach dem aktuellen Stand 
+**Ergebnis:** Eine datierte Bestandsübersicht mit Belegverweisen. Eine vorhandene Einstellung belegt noch keinen erfolgreichen Löschlauf; die Laufnachweise folgen vor dem Abschluss.
+
+### B4 — Unabhängige Sicherung des Löschstands ermöglichen
+
+- [ ] Mit dem Betrieb einen Speicherort auswählen, der bei einem Restore von Anwendung und Archiv nicht auf denselben alten Stand zurückgesetzt wird.
+- [ ] Zuständigkeit, Zugang, Kosten und Aufbewahrung für diesen Speicher festlegen. Vorhandene geeignete Infrastruktur kann verwendet werden; ein Neukauf ist keine Vorgabe.
+- [ ] Technisches Konzept erstellen lassen: Wie wird jeder relevante Löschstand gesichert, welche zeitliche Lücke bleibt, und wie wird ein Fehler bemerkt?
+- [ ] Isolierte Umgebung und Verantwortlichen für die spätere Restore-Übung festlegen.
+
+**Ergebnis:** Umsetzbarer Betriebsauftrag. „Wir exportieren täglich“ genügt allein nicht; Löschungen seit dem letzten Export müssen berücksichtigt sein.
+
+### B5 — Anwaltliche Prüfung organisieren
+
+- [ ] Ansprechpartner und Prüfungstermin vereinbaren.
+- [ ] Das unter V1/V2 korrigierte Paket mit deinen Entscheidungen aus B2 und den Betriebsinformationen übergeben.
+- [ ] Schriftliche Antworten zu den aktuell einschlägigen Fragen F1–F11 und A1–A7 anfordern; Fragen zu zurückgestellten Funktionen ausdrücklich als spätere Aktivierungsthemen kennzeichnen.
+- [ ] Ausdrückliche Rückmeldung zu Datenumfang, Aufbewahrungsfristen, Hold-Ende, Restdaten, Originalmetadaten, sensiblen Inhalten sowie DSE-/AGB-Texten einholen.
+
+**Ergebnis:** Antworten und Bedingungen, die eine konkrete Umsetzung ermöglichen. Der Versand ist deine Aufgabe, sofern du uns nicht gesondert damit beauftragst.
+
+## 2. Vorbereitung, die wir übernehmen können
+
+### V1 — Sachverhalt und Dokumente berichtigen
+
+- [ ] [Anwaltspaket](anwaltspaket-datenschutz-2026-10.md) anhand K1–K8 der Auswertung korrigieren.
+- [ ] [Interessenabwägung](interessenabwaegung-beweisarchiv-2026-10.md) hinsichtlich Restdaten, Zugriffen, Hold-Ende, Restore-Voraussetzungen und tatsächlichen Risiken berichtigen.
+- [ ] „Heute umgesetzt“, „beschlossenes Ziel“ und „später geplant“ eindeutig auseinanderhalten.
+- [ ] Richtige technische Angaben aufnehmen: Token-ID statt geheimer API-Schlüssel, kurzlebiger Cache statt garantierter RAM-Speicherung, Ausnahme für angeforderte Magic Links und zusätzliche IP-Übermittlung an Turnstile.
+- [ ] Unterschiedliche Rollen für aktive Originale und entfernte Archivinhalte benennen; Umfang der protokollierten Zugriffe präzisieren.
+
+**Abhängigkeit:** Sachliche Korrekturen können sofort erfolgen; Zieltexte hängen von B2/B3 und den späteren Anwaltsantworten ab.
+
+### V2 — Eine vollständige Aufbewahrungsmatrix erstellen
+
+- [ ] Für jede Datenart festhalten: Zweck, Datenfelder, Speicherorte/Kopien, Fristbeginn, Dauer, Löschbedingung, Ausnahme, zuständige Person und technischer Nachweis.
+- [ ] Insbesondere Originale, Rechtebestätigungen, Archivinhalt, Restdaten, Zugriffslogs, Vorgänge, IPs, Rohmails, Sperrliste, Fehlerberichte und Backups aufnehmen.
+- [ ] Bei zeitgesteuerten Läufen den tatsächlichen Löschzeitpunkt definieren: täglich oder wöchentlich, Zeitzone, Grenztage, Fehlerfall und Wiederholung.
+- [ ] Entscheiden, wie bereits überfällige Bestandsdaten behandelt werden; keinen neuen Fristbeginn allein durch die Umstellung erzeugen.
+- [ ] Minimalfelder und konkrete Fristen für bislang offene Fälle aus E2/E7/E9 nach der Anwaltsantwort eintragen.
+
+**Ergebnis:** Eine einzige verbindliche Vorgabe für Code, Betrieb und Rechtstexte. Solange eine für die Umsetzung notwendige Frist oder Löschbedingung fehlt, ist der betroffene Teil nicht umsetzungsreif.
+
+### V3 — Anwaltsunterlagen vervollständigen
+
+- [ ] Aktuelle tatsächlich verwendete DSE/AGB und die korrigierten Entwürfe beifügen.
+- [ ] Bildrechte-Agenda A1–A7 und die vier referenzierten Fragen zu Löschanfragen beifügen.
+- [ ] Ansichten von Rechtebestätigung, Bildnachweis und Kontosicherheit als Anlagen vorbereiten.
+- [ ] E1–E9 und F1–F11 mit Vorschlag, Antwortfeld und späterem Antwortdatum versehen.
+- [ ] Nach Rücklauf jede Bedingung einem Textabschnitt, einer Entwicklungsaufgabe oder einer Betriebsaufgabe zuordnen.
+
+### V4 — Umsetzungsauftrag und Abnahme festschreiben
+
+- [ ] Die Aufgaben U1–U9 unten anhand der geprüften Entscheidungen konkretisieren.
+- [ ] Für jede Aufgabe die fachliche Vorgabe, betroffene Daten, Altbestandsbehandlung und messbare Abnahmekriterien eintragen.
+- [ ] Entwicklungs-, Betriebs- und Freigabeverantwortliche namentlich zuordnen.
+- [ ] Reihenfolge festlegen: Löschregeln und unabhängiger Löschstand abstimmen, Umsetzung testen, Bestandsläufe kontrolliert durchführen, Betrieb nachweisen, Rechtstexte veröffentlichen.
+- [ ] Rückfallverhalten festlegen: Ein Rollback darf weder erledigte Löschungen rückgängig machen noch ohne Nachweis neue Funktionen aktivieren.
+
+## 3. Ab wann ist das Paket umsetzungsreif?
+
+- [ ] B1: Umfang schriftlich festgelegt.
+- [ ] B2/V2: Vollständige Aufbewahrungsmatrix einschließlich aller offenen Restfristen und Ausnahmen vorhanden.
+- [ ] B3: Relevanter produktiver Iststand und Betreiberangaben geklärt; fehlende Laufnachweise sind konkret als Abnahmeaufgaben erfasst.
+- [ ] B4: Geeigneter unabhängiger Speicher und ausführbares Restore-Konzept festgelegt.
+- [ ] B5/V3: Anwaltliche Antworten zu den umsetzungsbestimmenden Fragen liegen vor und sind eingearbeitet.
+- [ ] V1: Beide Ausgangsdokumente beschreiben denselben Ist- und Zielstand.
+- [ ] V4: Aufgaben, Zuständigkeiten und Abnahmekriterien vollständig; keine Grundsatzentscheidung mehr an die Entwicklung delegiert.
+
+**Dann lautet der Status: „Umsetzungsreif“.** Dafür müssen die Änderungen noch nicht produktiv sein. Ein nachweislich unabhängiger, bereits geklärter Teil kann vorher umgesetzt werden; ungeklärte Fristen oder Datenlöschungen werden dadurch nicht automatisch freigegeben.
+
+## 4. Anschließende Umsetzung und ihre Abnahmekriterien
+
+Dieser Abschnitt macht den späteren Weg zum Abschluss sichtbar. Er ist der Arbeitsvorrat nach Herstellung der Umsetzungsreife.
+
+| Aufgabe | Umsetzung | Abnahme |
+|---|---|---|
+| **U1 Vorgangs-IP-Adressen** | Bereinigung aller beschlossenen Felder einschließlich Buchungsbestätigungen und letzter Login-IP; Altbestand und Vorfallsausnahmen berücksichtigen. | Grenzfälle vor/nach Frist getestet; fachlicher Vorgang bleibt erhalten; Ausnahme funktioniert; erster Bestandslauf protokolliert. |
+| **U2 Entwürfe, Ablehnungen und Vorgänge** | Echte Löschung bzw. Reduktion nach E1/E2/E9; verknüpfte Daten und Medien einbeziehen. | Nie veröffentlichte Inhalte nach Regel entfernt; veröffentlichte/unklare Legacy-Fälle und Holds geschützt; Fehlversuche werden erneut verarbeitet. |
+| **U3 Archiv und Hold-Ende** | Beschlossene Fristlogik sowie Minimierung der Restdaten und Archivzugriffslogs umsetzen. | Kein unbegründeter Fristneustart; fällige personenbezogene Reste verschwinden; laufender Hold schützt erforderliche Daten; Restore-Kennungen bleiben im benötigten Umfang nutzbar. |
+| **U4 Anmelde-/Aktivitätsfristen** | Ereignistypen der Matrix zuordnen und Bereinigung anpassen; vorhandene API-Frist verifizieren. | Ereignistypen und Grenztage getestet; dokumentierte Ausnahme für Sicherheitsvorfälle; produktiver Löschlauf belegt. |
+| **U5 Bounce-Postfach und Sperrliste** | Rohmails in allen vereinbarten Ordnern bereinigen; nötigenfalls auch tatsächlich erhaltene Kopien berücksichtigen; Sperrdaten und Prüfprozess auf das Beschlossene begrenzen. | Überfällige Rohmails entfernt; Sperren weiterhin wirksam; unklare Rückläufer nach festgelegtem Verfahren behandelt; Lauf überwacht. |
+| **U6 Fehlerberichte** | Technische Felder begrenzen, freie Query-/Fehler-/Objektinhalte reduzieren; Instanz- und Transportlogfristen umsetzen. | Testfälle mit Namen, E-Mails, IPs und geheimen/formularbezogenen Werten in Query, Meldung und Fehlerobjekt geprüft; tatsächlich gesendete Daten entsprechen dem beschriebenen Schema. |
+| **U7 Löschstand und Restore** | Unabhängige Sicherung, Aktualitäts-/Fehlerprüfung und verbindlichen Restore-Ablauf umsetzen. | Übungen „DB alt“, „Disk alt“, „beide alt“ bestanden; bereits Gelöschtes bleibt entfernt; notwendige Holds und Schlüssel verfügbar; Exportlücken behandelt. |
+| **U8 Dokumente und Einbeziehung** | Geprüfte DSE, AGB/Bildrechtsklauseln, passende Bestätigungsfassung und Zustimmungsgate vorbereiten; Informationen auf allen Hosts abstimmen. | Texte entsprechen der fertigen Umsetzung; Versionsverweise stimmen; relevante Einreichungswege geprüft; Bestandskundenverfahren entspricht der Freigabe. |
+| **U9 Betrieb und Bestandsnachweise** | Scheduler/Alarme, Backuprotation, Sonderkopien, manuelle Betroffenenprozesse und Verantwortlichkeiten nachweisen. | Echte Laufprotokolle und vollständige Backupübersicht vorhanden; alte Sonderkopien gemäß Entscheidung behandelt; D7/D8/D10 weiterhin wie beschlossen deaktiviert. |
+
+**Zuordnung zur Auswertung:** U1 → K2/F4; U2 → K1/K2; U3 → K3/K4; U4 → D3/D5/F3; U5 → D4/F5; U6 → K7; U7 → K5; U8 → K6/F1/F10/F11/A1–A7; U9 → Betriebsgrenzen und Abschlusskriterien. K8/F6/F7/F9 bleiben bei beschlossenem Aufschub separate Aktivierungspakete.
+
+## 5. Wann kannst du „abgeschlossen“ abhaken?
+
+- [ ] U1–U9 im beschlossenen Umfang umgesetzt und abgenommen; jede Ausnahme ausdrücklich dokumentiert.
+- [ ] Gezielte Tests nach den Änderungen bestanden. Die bisherigen 82 Tests sind die Ausgangsbasis, nicht die Abnahme zukünftiger Änderungen.
+- [ ] Altbestandsbereinigung und produktive Löschläufe nachgewiesen.
+- [ ] Restore-Übung erfolgreich und Ergebnisse dokumentiert.
+- [ ] Finale Texte anhand des tatsächlich erreichten Stands geprüft; anwaltliche Bedingungen erfüllt.
+- [ ] Interessenabwägung durch den Verantwortlichen datiert und abgezeichnet; nächster Prüftermin spätestens nach zwölf Monaten eingetragen.
+- [ ] Geprüfte Texte und erforderliches Zustimmungsgate mit passenden Fassungen veröffentlicht; betroffene Hostvarianten kontrolliert.
+- [ ] Roadmap und Paketstatus aktualisiert; zurückgestellte Funktionen bleiben als separate offene Aufgaben sichtbar.
+
+**Abschlussvermerk:** Datum, produktiver Release-Stand, freigegebene Dokumentfassungen, verantwortliche Person und Verweise auf Test-, Lösch- und Restore-Nachweise festhalten.
+
+## 6. Empfohlene Reihenfolge
+
+1. **Du:** B1/B2 entscheiden und B3/B4 beim Betrieb klären lassen.
+2. **Wir:** Parallel sachliche Dokumentkorrekturen vorbereiten; mit deinen Angaben Aufbewahrungsmatrix und Anwaltsunterlagen vervollständigen.
+3. **Du + Anwalt:** B5 bearbeiten; umsetzungsbestimmende Fragen schriftlich beantworten.
+4. **Wir + Betrieb:** Antworten in Aufgaben und Abnahmekriterien übernehmen. Damit ist die Umsetzungsreife erreicht.
+5. **Entwicklung + Betrieb:** U1–U9 umsetzen, testen und die tatsächlichen Betriebsnachweise liefern.
+6. **Du + Anwalt + Entwicklung:** Endstand freigeben, veröffentlichen und den Abschluss dokumentieren.
+
+Die bestehenden Informationslücken zu bereits laufenden Verarbeitungen sollten bei der anwaltlichen Prüfung zuerst behandelt werden. Zutreffende Informationen zum aktuellen Stand können als eigene Zwischenfassung vorbereitet werden; zukünftige Lösch- oder Schutzmaßnahmen dürfen dabei noch nicht als umgesetzt beschrieben werden.