diff --git a/dev/archive/betrieb/deploy-v1.9.0.md b/dev/archive/betrieb/deploy-v1.9.0.md new file mode 100644 index 00000000..c7acf804 --- /dev/null +++ b/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. diff --git a/dev/archive/rechtliches-2026-10/antworten-rueckfragen-anwaltspaket-2026-10-12.md b/dev/archive/rechtliches-2026-10/antworten-rueckfragen-anwaltspaket-2026-10-12.md new file mode 100644 index 00000000..c5ffd3e6 --- /dev/null +++ b/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-`, 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. diff --git a/dev/archive/rechtliches-2026-10/anwaltspaket-datenschutz-2026-10.md b/dev/archive/rechtliches-2026-10/anwaltspaket-datenschutz-2026-10.md index 3e230d0b..6b27a0f3 100644 --- a/dev/archive/rechtliches-2026-10/anwaltspaket-datenschutz-2026-10.md +++ b/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) diff --git a/dev/archive/rechtliches-2026-10/auswertung-und-abschlussentscheidungen-2026-10-12.md b/dev/archive/rechtliches-2026-10/auswertung-und-abschlussentscheidungen-2026-10-12.md new file mode 100644 index 00000000..5b938214 --- /dev/null +++ b/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. diff --git a/dev/archive/rechtliches-2026-10/todo-umsetzungsreife-und-abschluss-2026-10.md b/dev/archive/rechtliches-2026-10/todo-umsetzungsreife-und-abschluss-2026-10.md new file mode 100644 index 00000000..5a71cbda --- /dev/null +++ b/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. diff --git a/dev/rechtliches/anlage-rechtstexte-live-2026-10-12.md b/dev/rechtliches/anlage-rechtstexte-live-2026-10-12.md new file mode 100644 index 00000000..78329084 --- /dev/null +++ b/dev/rechtliches/anlage-rechtstexte-live-2026-10-12.md @@ -0,0 +1,913 @@ +# Anlage zum Anwaltspaket: Rechtstexte im Live-Stand und Boost-Kennzeichnung + +**Abgerufen:** 12.10.2026 von den Live-Seiten (Release v1.8.0) +**Gehört zu:** [Versandfassung](anwaltspaket-datenschutz-2026-10-12.md), Anlage 3 + +Inhalt: + +- **A** Datenschutzerklärung 0.3 auf dem Hub [pressekonto.com/de/datenschutz](https://pressekonto.com/de/datenschutz) +- **B** Datenschutzerklärung 0.3 auf den Portalen [presseecho.de/de/datenschutz](https://presseecho.de/de/datenschutz) und [businessportal24.com/de/datenschutz](https://businessportal24.com/de/datenschutz) +- **C** AGB 0.6, auf allen drei Domains gleich +- **D** Boost: Note auf der Preisseite, Label auf Startseite und Branchenseite + +Die Texte sind wörtlich aus dem ausgelieferten HTML übernommen. Nur die Formatierung ist in Markdown umgesetzt: Überschriften, Listen, Fettdruck und Links. + +## Vorab: Hinweise zum Abgleich + +Beim Zusammenstellen fiel Folgendes auf. Der Anwalt sollte es kennen, bevor er den Text liest. + +1. **Gültigkeit der Änderungslinks, Portal-Fassung Abschnitt 7.** Dort steht pauschal „derzeit 15 Minuten“. Im System gibt es zwei Arten von Links an die Adresse des Pressekontakts: + - den **Zugangslink zur Verwaltung** von Mitteilung oder Newsroom: 15 Minuten, stimmt; + - den **Bestätigungslink aus „Mitteilung melden“** (der Pressekontakt öffnet damit die Auswahl seiner Anliegen): **72 Stunden** (`LEGAL_REPORT_LINK_TTL_HOURS`). + + In Fassung 0.4 sollten beide Fristen genannt werden. +2. **Backups, Abschnitt 13.** Dort steht „bis zu vier Wochen“; tatsächlich sind es 14 Tage. Die Korrektur ist im Entwurf für 0.4 bereits enthalten. +3. **Turnstile, Abschnitt 6a.** Der Abschnitt nennt nur das Kontaktformular und die Registrierung, und das stimmt mit dem heutigen Stand überein. Geplant ist, Turnstile auch im Widerrufs-, Kündigungs- und Meldeformular, bei der Rechtsanfrage und bei „Newsroom verwalten“ einzusetzen (Roadmap 4.4). Dann muss 6a mitwachsen. +4. **AGB-Verweise auf den Portalen.** Der Linktext lautet überall „pressekonto.com/…“. Auf presseecho.de und businessportal24.com führt der Link aber auf die gleichnamige Seite des jeweiligen Portals. Der Inhalt ist derselbe; das betrifft nur die Darstellung. +5. **Gleiche Nummer, anderer Inhalt.** Hub und Portale nummerieren ab Abschnitt 7 unterschiedlich: Abschnitt 9 ist auf dem Hub „Zahlungsabwicklung mit Stripe“, auf den Portalen „Medienprivileg“. Die Entwürfe für 0.4 im Anwaltspaket nennen deshalb jeweils die Fassung. + +--- + +## A. Datenschutzerklärung 0.3: Hub (pressekonto.com) + +**Stand: 3. Juli 2026 · Version 0.3.** 5a und 6a wurden seitdem ergänzt, ohne neue Versionsnummer. + +Die Abschnitte 7 bis 9 gibt es nur auf dem Hub: Kundenkonto, Anmeldelink, Stripe. + +### 1. Verantwortlicher + +Verantwortlicher für die Datenverarbeitung auf pressekonto.com ist: + +adametz.media +Inhaber: Kevin Adametz +In der Lake 4 +33739 Bielefeld +E-Mail: info@pressekonto.com + +### 2. Grundsätze und Rechtsgrundlagen + +Wir verarbeiten personenbezogene Daten nur, soweit dies für den Betrieb dieses Angebots, die Erbringung unserer Leistungen, die Bearbeitung von Anfragen oder aufgrund gesetzlicher Pflichten erforderlich ist. + +Die jeweilige Rechtsgrundlage nennen wir in den einzelnen Abschnitten dieser Datenschutzerklärung. Je nach Verarbeitung kommen insbesondere folgende Rechtsgrundlagen in Betracht: + +- Art. 6 Abs. 1 lit. b DSGVO, soweit die Verarbeitung zur Erfüllung eines Vertrags oder zur Durchführung vorvertraglicher Maßnahmen erforderlich ist, +- Art. 6 Abs. 1 lit. c DSGVO, soweit wir rechtlich zur Verarbeitung verpflichtet sind, +- Art. 6 Abs. 1 lit. f DSGVO, soweit die Verarbeitung zur Wahrung berechtigter Interessen erforderlich ist, +- Art. 85 DSGVO in Verbindung mit den jeweils anwendbaren medien- und presserechtlichen Sonderregelungen, soweit personenbezogene Daten zu journalistisch-redaktionellen Zwecken verarbeitet werden. + +Eine Weitergabe personenbezogener Daten an Dritte erfolgt nur, wenn sie in dieser Datenschutzerklärung beschrieben ist, wenn sie für die Leistungserbringung erforderlich ist, wenn eine gesetzliche Pflicht besteht oder wenn Sie eingewilligt haben. + +Wir verkaufen keine personenbezogenen Daten und schalten keine personalisierte Werbung. + +Die Übertragung dieser Website erfolgt verschlüsselt über TLS. + +### 3. Hosting und Server-Logs + +Unsere Systeme werden bei der Hetzner Online GmbH, Industriestr. 25, 91710 Gunzenhausen, Deutschland, betrieben. Mit Hetzner besteht ein Vertrag zur Auftragsverarbeitung gemäß Art. 28 DSGVO. + +Beim Aufruf unserer Seiten verarbeitet der Webserver technisch notwendige Verbindungsdaten. Dazu gehören insbesondere: + +- IP-Adresse, +- Zeitpunkt des Aufrufs, +- aufgerufene Seite, +- übertragene Datenmenge, +- Referrer-URL, +- User-Agent, +- technische Statuscodes. + +Die Verarbeitung erfolgt zur Bereitstellung, Sicherheit, Stabilität und Fehleranalyse unseres Angebots. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO. + +Die Server-Logs werden grundsätzlich nach 14 Tagen gelöscht, sofern kein sicherheitsrelevanter Vorfall oder eine rechtliche Pflicht eine längere Aufbewahrung erforderlich macht. + +### 4. Cookies und technisch notwendige Speicherungen + +Wir verwenden keine Marketing-Cookies und keine Tracking-Cookies. + +Auf pressekonto.com werden ausschließlich technisch notwendige Cookies und vergleichbare Speichertechnologien eingesetzt. Dazu gehören insbesondere Sitzungs-Cookies für den Login, Sicherheits-Token und technisch erforderliche Speicherungen für das Kundenkonto. Diese sind für den Betrieb des Kundenkontos und die Bereitstellung der von Ihnen angeforderten Funktionen erforderlich. Rechtsgrundlagen sind § 25 Abs. 2 Nr. 2 TDDDG und Art. 6 Abs. 1 lit. b DSGVO. Die Cookies und Token werden mit Ende der Sitzung oder nach kurzer Frist gelöscht. + +Da wir keine Marketing- oder Tracking-Cookies einsetzen, ist für diese Website kein Cookie-Banner erforderlich. + +### 5. Webanalyse mit Umami + +Wir nutzen die selbst gehostete Analysesoftware Umami auf eigenen Servern. + +Umami setzt keine Cookies in Ihrem Browser. Es findet kein website- oder geräteübergreifendes Tracking statt. Es werden keine Nutzerprofile erstellt. + +Bei der Erfassung werden IP-Adressen unmittelbar vollständig anonymisiert. Ein Rückschluss auf Ihre Person oder Ihr genaues Gerät ist dadurch ausgeschlossen. + +Verarbeitet werden ausschließlich aggregierte Nutzungsdaten, insbesondere: + +- Seitenaufrufe, +- Referrer, +- Gerätetyp, +- Browser, +- Betriebssystem, +- ungefährer Standort auf Länderebene. + +Die Verarbeitung erfolgt zur Reichweitenmessung, technischen Optimierung und Verbesserung unseres Angebots. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO. Eine Übermittlung der Analysedaten an externe Tracking- oder Werbedienstleister findet nicht statt. + +### 5a. Eigene Nutzungsstatistiken ohne Personenbezug + +Neben Umami führen wir auf unseren eigenen Servern drei einfache Ereignisprotokolle, mit denen wir die Reichweite veröffentlichter Pressemitteilungen belegen und den Weg von einer Benachrichtigung zum Kundenkonto nachvollziehen. Diese Protokolle enthalten keine IP-Adressen, keine Cookies und keine Kennungen, die eine Person oder ein Gerät wiedererkennbar machen. + +- **Aufrufe und Teilen-Klicks je Pressemitteilung.** Gespeichert werden die Meldung, der Zeitpunkt und bei einem Teilen-Klick der gewählte Kanal. Daraus entstehen die Aufrufzahlen und Tagesverläufe, die wir dem einreichenden Unternehmen zeigen. +- **Abrufe durch Such-, KI- und Feed-Dienste.** Ruft ein bekannter Dienst eine Meldung oder einen RSS-Feed ab, speichern wir den Dienst, die gekürzte Programmkennung (User-Agent), den Zeitpunkt und die betroffene Meldung beziehungsweise den Feed. Nennt ein Feed-Dienst in seiner Kennung eine Abonnentenzahl, übernehmen wir diese Zahl. Wer einen Feed abonniert hat, erfahren wir nicht. +- **Schritte vom Hinweis zum Konto.** Klickt ein Empfänger einen Link in einer unserer Benachrichtigungen, nutzt einen Anmeldelink, bearbeitet einen Newsroom, legt ein Konto an oder bucht erstmals, halten wir den Schritt, den Anlass (zum Beispiel „Veröffentlichungsmail") und das betroffene Unternehmen fest. Die Person und ihre E-Mail-Adresse werden dabei nicht gespeichert; die Auswertung zählt Unternehmen, nicht Menschen. + +Die Verarbeitung erfolgt zur Reichweitenmessung gegenüber unseren Kunden, zur Bewertung unserer Benachrichtigungen und zur Verbesserung unseres Angebots. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO. Die Protokolle werden nicht an Dritte weitergegeben und nicht mit anderen Daten zu Nutzerprofilen verbunden. + +### 6. Kontaktaufnahme + +Wenn Sie uns per E-Mail oder über ein Formular kontaktieren, verarbeiten wir die von Ihnen angegebenen Daten zur Bearbeitung Ihrer Anfrage. Dazu können insbesondere gehören: + +- Name, +- E-Mail-Adresse, +- Inhalt Ihrer Nachricht, +- betroffene URL, +- Zeitpunkt der Anfrage, +- technische Metadaten zur Missbrauchsvermeidung und Sicherheit. + +Rechtsgrundlage ist Art. 6 Abs. 1 lit. b DSGVO, soweit Ihre Anfrage mit einem Vertrag oder vorvertraglichen Maßnahmen zusammenhängt. In allen anderen Fällen ist Rechtsgrundlage Art. 6 Abs. 1 lit. f DSGVO. Soweit wir gesetzlich zur Bearbeitung oder Dokumentation verpflichtet sind, ist Rechtsgrundlage Art. 6 Abs. 1 lit. c DSGVO. + +Die Daten werden gelöscht, sobald die Anfrage abgeschlossen ist und keine gesetzlichen Aufbewahrungspflichten oder berechtigten Interessen an einer weiteren Speicherung entgegenstehen. + +Anfragen, die unser Spamfilter als unerwünschte Werbung oder automatisierte Eingabe erkennt, werden ohne Weiterleitung an unser Team zurückgehalten, damit wir Fehleinstufungen prüfen können, und spätestens nach 30 Tagen automatisch gelöscht. + +### 6a. Schutz vor automatisierten Anfragen (Cloudflare Turnstile) + +Um unsere Formulare vor automatisierten Eingaben (Spam, Bots) zu schützen, setzen wir im Kontaktformular und bei der Registrierung den Dienst Turnstile ein. Anbieter ist die Cloudflare, Inc., 101 Townsend St., San Francisco, CA 94107, USA. + +Turnstile wird erst geladen, wenn Sie das Kontaktformular öffnen oder die Registrierungsseite aufrufen. Der Dienst prüft anhand technischer Merkmale, ob die Eingabe von einem Menschen stammt; in der Regel ohne dass Sie etwas tun müssen. Dabei werden insbesondere verarbeitet: + +- IP-Adresse, +- Informationen zu Browser und Betriebssystem (z. B. User-Agent, Spracheinstellungen), +- Merkmale des Seitenaufrufs und der Interaktion mit der Prüfung, +- Zeitpunkt der Prüfung. + +Turnstile setzt nach Angaben von Cloudflare keine Cookies zu Werbe- oder Trackingzwecken und nutzt die Daten nicht für personalisierte Werbung. Wir erhalten von Cloudflare nur das Ergebnis der Prüfung. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO; unser berechtigtes Interesse liegt darin, Missbrauch unserer Formulare zu verhindern, etwa den massenhaften Versand von Bestätigungs-E-Mails an fremde Adressen. Für den Zugriff auf Informationen in Ihrem Endgerät ist Rechtsgrundlage § 25 Abs. 2 Nr. 2 TDDDG, da die Prüfung für den sicheren Betrieb des von Ihnen genutzten Formulars unbedingt erforderlich ist. + +Cloudflare kann Daten auch in den USA verarbeiten. Cloudflare ist nach dem EU-US Data Privacy Framework zertifiziert; die Übermittlung erfolgt auf Grundlage des Angemessenheitsbeschlusses der Europäischen Kommission (Art. 45 DSGVO). Weitere Informationen finden Sie in den Datenschutzhinweisen von Cloudflare ([cloudflare.com/privacypolicy](https://www.cloudflare.com/privacypolicy/)) und zu Turnstile ([cloudflare.com/turnstile-privacy-policy](https://www.cloudflare.com/turnstile-privacy-policy/)). + +### 7. Kundenkonto und Registrierung auf dem Hub + +Für die Nutzung von pressekonto ist ein Kundenkonto erforderlich. Dabei verarbeiten wir insbesondere: + +- Name, +- E-Mail-Adresse, +- Unternehmensangaben, +- Rechnungsdaten, +- steuerlich erforderliche Angaben, +- Angaben zu Firmenprofilen, +- Buchungsdaten, +- Tarifinformationen, +- Zahlungsstatus, +- eingereichte Pressemitteilungen, +- Entwürfe, +- Kontingente, +- Credits, +- Nutzungs- und Verwaltungsdaten des Kundenkontos. + +Rechtsgrundlage ist Art. 6 Abs. 1 lit. b DSGVO. + +Unser Angebot richtet sich ausschließlich an Unternehmer. Bei der Buchung bestätigen Sie, dass Sie in Ausübung Ihrer gewerblichen oder selbständigen beruflichen Tätigkeit handeln (§ 14 BGB). Diese Bestätigung protokollieren wir zu Nachweiszwecken. + +Ihre bei Vertragsschluss akzeptierte AGB-Fassung sowie im Veröffentlichungsvorgang abgegebene Erklärungen und Bestätigungen, zum Beispiel der Hinweis auf die dauerhafte Archivierung, protokollieren wir ebenfalls zu Nachweiszwecken. Rechtsgrundlagen sind Art. 6 Abs. 1 lit. c und lit. f DSGVO. + +### 8. Magic-Link: Anmeldung bei pressekonto + +Die Anmeldung bei pressekonto kann passwortlos über einen zeitlich begrenzten Anmeldelink („Magic-Link") erfolgen, den wir an Ihre hinterlegte E-Mail-Adresse senden. + +Verarbeitet werden: + +- E-Mail-Adresse, +- ein kryptographisch gehashtes Token, +- Zeitstempel, +- technische Metadaten zur Sicherheit und Missbrauchsvermeidung. + +Das Token ist nur zeitlich begrenzt gültig und verfällt nach einmaliger Nutzung oder nach Ablauf einer kurzen Gültigkeitsdauer automatisch. Die konkrete Gültigkeitsdauer wird systemseitig festgelegt und beträgt derzeit 15 Minuten. + +Rechtsgrundlage ist Art. 6 Abs. 1 lit. b DSGVO. + +### 9. Zahlungsabwicklung mit Stripe + +Zahlungen auf pressekonto.com werden über den Zahlungsdienstleister Stripe abgewickelt: + +Stripe Payments Europe, Ltd., 1 Grand Canal Street Lower, Grand Canal Dock, Dublin, Irland. + +Stripe erhält die für die Zahlungsabwicklung erforderlichen Daten, insbesondere: + +- Name, +- E-Mail-Adresse, +- Rechnungsdaten, +- Zahlungsmittel, +- Betrag, +- Zahlungsstatus, +- technische Zahlungsinformationen. + +Ihre vollständigen Zahlungsdaten, zum Beispiel vollständige Kreditkartennummern, werden direkt von Stripe über ein gesichertes Eingabefeld erfasst und verarbeitet. Sie berühren unsere Server zu keinem Zeitpunkt und liegen uns nicht vor. + +Rechtsgrundlage ist Art. 6 Abs. 1 lit. b DSGVO. + +Stripe verarbeitet personenbezogene Daten in eigener Verantwortung, soweit dies für die Zahlungsabwicklung, Betrugsprävention, Compliance und gesetzliche Pflichten erforderlich ist. Soweit Stripe personenbezogene Daten in Drittländern verarbeitet, erfolgt dies nach Angaben von Stripe auf Grundlage geeigneter Garantien, insbesondere EU-Standardvertragsklauseln und — soweit anwendbar — des EU-U.S. Data Privacy Framework. + +Weitere Informationen finden Sie in den Datenschutzhinweisen von Stripe. + +### 10. Automatisierte Inhaltsprüfung und Qualitätsbewertung + +Eingereichte Pressemitteilungen werden vor der Veröffentlichung automatisiert auf die Einhaltung unserer Veröffentlichungsrichtlinien geprüft und inhaltlich bewertet. + +Dabei können auch personenbezogene Daten verarbeitet werden, die in der Pressemitteilung enthalten sind. Soweit möglich, werden personenbezogene Daten vor der automatisierten Analyse minimiert oder entfernt. API-Anbindungen werden, soweit verfügbar, so konfiguriert, dass die übermittelten Inhalte nicht für Trainingszwecke fremder Modelle verwendet werden. + +Für die automatisierte Analyse können je nach Anfrage, Tätigkeit und Verfügbarkeit unterschiedliche KI- oder Analyse-Anbieter eingesetzt werden. Derzeit kommen insbesondere folgende Anbieter in Betracht: + +- OpenAI, +- Google Gemini, +- Anthropic Claude. + +Verarbeitet werden insbesondere: + +- Inhalt der eingereichten Pressemitteilung, +- minimierte oder anonymisierte Prüffassung, soweit technisch möglich, +- Bewertungsergebnis, +- Scores oder Risikomerkmale, +- Ablehnungskategorien, +- interne Hinweise zur Qualitätsbewertung, +- Ergebnis einer gegebenenfalls durchgeführten menschlichen Überprüfung. + +Führt die Prüfung zur Ablehnung einer Mitteilung, teilen wir Ihnen die Ablehnungskategorie mit. Sie können eine Überprüfung durch einen Menschen verlangen und dabei Ihren Standpunkt darlegen. Die Entscheidung wird dann erneut geprüft. + +Die Prüfergebnisse, Scores, Ablehnungskategorien und Begründungen werden intern der jeweiligen Pressemitteilung zugeordnet und grundsätzlich so lange gespeichert, wie die Pressemitteilung gespeichert oder veröffentlicht bleibt. Dies dient der Nachvollziehbarkeit der Veröffentlichungsentscheidung, der Qualitätssicherung, der Bearbeitung von Rückfragen sowie der Rechtsverteidigung. + +Rechtsgrundlagen sind Art. 6 Abs. 1 lit. b DSGVO und Art. 6 Abs. 1 lit. f DSGVO. Soweit gesetzliche Dokumentationspflichten bestehen oder Meldungen nach dem Digital Services Act betroffen sind, kann zusätzlich Art. 6 Abs. 1 lit. c DSGVO einschlägig sein. + +### 11. Meldeverfahren + +Wenn Sie über unser Meldeverfahren einen Inhalt melden, eine Änderung beantragen oder eigene personenbezogene Daten entfernen lassen möchten, verarbeiten wir die von Ihnen angegebenen Daten zur Bearbeitung der Meldung oder Anfrage. + +Dabei können insbesondere verarbeitet werden: + +- Name, +- E-Mail-Adresse, +- betroffene URL, +- Begründung der Meldung, +- ausgewählte Meldekategorie, +- Nachweise oder ergänzende Angaben, +- Zeitpunkt der Meldung, +- Vorgangsnummer, +- Bearbeitungsstatus, +- Entscheidung und Begründung, +- Kommunikationsverlauf. + +Die Verarbeitung erfolgt zur Bearbeitung Ihrer Meldung, zur Erfüllung gesetzlicher Pflichten, insbesondere nach dem Digital Services Act und der DSGVO, zur Dokumentation der Entscheidung sowie zur Rechtsverteidigung. + +Rechtsgrundlagen sind Art. 6 Abs. 1 lit. c DSGVO und Art. 6 Abs. 1 lit. f DSGVO. Soweit die Meldung mit einem bestehenden Vertrag oder Kundenkonto zusammenhängt, kann zusätzlich Art. 6 Abs. 1 lit. b DSGVO einschlägig sein. + +Meldedaten bewahren wir zur Dokumentation der Bearbeitung und Entscheidung grundsätzlich für drei Jahre nach Abschluss des Vorgangs auf. Eine längere Speicherung erfolgt nur, soweit dies zur Bearbeitung laufender Vorgänge, zur Erfüllung gesetzlicher Pflichten oder zur Rechtsverteidigung erforderlich ist. + +Meldungen und Änderungsanfragen können über die auf den Portalen vorgesehenen Wege ([Inhalte melden](https://pressekonto.com/de/melden)) oder die Melde-Links bei der jeweiligen Pressemitteilung eingereicht werden. + +Für Rückfragen zu bestehenden Meldungen nutzen Sie bitte die Eingangsbestätigung oder kontaktieren Sie uns über info@pressekonto.com. + +### 12. E-Mail-Versand + +Für den Versand transaktionaler E-Mails nutzen wir: + +ALL-INKL.COM - Neue Medien Münnich +Inhaber: René Münnich +Hauptstraße 68 +02742 Friedersdorf +Deutschland + +Transaktionale E-Mails sind insbesondere: + +- Magic-Links, +- Änderungslinks, +- Buchungsbestätigungen, +- Rechnungen oder Rechnungshinweise, +- Eingangsbestätigungen zu Meldungen, +- Benachrichtigungen zu Veröffentlichungen, +- System- und Sicherheitsmitteilungen. + +Dabei werden insbesondere verarbeitet: + +- E-Mail-Adresse, +- Empfängername, soweit vorhanden, +- Inhalt der jeweiligen Nachricht, +- Versandzeitpunkt, +- technische Zustelldaten, +- Statusinformationen zur Zustellung. + +Rechtsgrundlagen sind je nach Zweck der jeweiligen E-Mail Art. 6 Abs. 1 lit. b DSGVO, Art. 6 Abs. 1 lit. c DSGVO und Art. 6 Abs. 1 lit. f DSGVO. + +Mit dem Dienstleister besteht, soweit erforderlich, ein Vertrag zur Auftragsverarbeitung gemäß Art. 28 DSGVO. + +### 13. Speicherdauer, Backups und Aufbewahrungspflichten + +Wir speichern personenbezogene Daten nur so lange, wie es für die in dieser Datenschutzerklärung genannten Zwecke erforderlich ist. + +Es gelten insbesondere folgende Speicherfristen: + +- Server-Logs werden grundsätzlich nach 14 Tagen gelöscht, sofern kein sicherheitsrelevanter Vorfall eine längere Aufbewahrung erforderlich macht. +- Magic-Link-Token verfallen nach einmaliger Nutzung oder nach Ablauf von 15 Minuten. +- Die Ereignisprotokolle zu Aufrufen, Abrufen durch Dienste und Konversionsschritten (Abschnitt 5a) werden nach 395 Tagen gelöscht. +- Meldedaten werden grundsätzlich für drei Jahre nach Abschluss des Vorgangs gespeichert. +- Vertrags-, Buchungs- und Rechnungsdaten unterliegen handels- und steuerrechtlichen Aufbewahrungspflichten und werden nach Ablauf dieser Fristen gelöscht. +- Veröffentlichte Pressemitteilungen werden im Rahmen der Archivfunktion grundsätzlich dauerhaft gespeichert, soweit keine gesetzlichen Ansprüche auf Entfernung, Sperrung oder Änderung bestehen. +- Kontodaten werden nach Kontolöschung entfernt, soweit keine Aufbewahrungspflichten, offenen Vorgänge oder berechtigten Interessen an einer weiteren Speicherung entgegenstehen. + +Gelöschte Daten können in Sicherungskopien noch bis zu vier Wochen enthalten sein. Die Backups werden ausschließlich zur Wiederherstellung der Systeme im Sicherungsfall verwendet und nicht produktiv ausgewertet. + +### 14. Ihre Rechte + +Sie haben gegenüber uns nach Maßgabe der gesetzlichen Voraussetzungen folgende Rechte: + +- Recht auf Auskunft nach Art. 15 DSGVO, +- Recht auf Berichtigung nach Art. 16 DSGVO, +- Recht auf Löschung nach Art. 17 DSGVO, +- Recht auf Einschränkung der Verarbeitung nach Art. 18 DSGVO, +- Recht auf Datenübertragbarkeit nach Art. 20 DSGVO, +- Recht auf Widerspruch gegen Verarbeitungen auf Grundlage berechtigter Interessen nach Art. 21 DSGVO, +- Recht auf jederzeitigen Widerruf einer erteilten Einwilligung nach Art. 7 Abs. 3 DSGVO, ohne dass die Rechtmäßigkeit der aufgrund der Einwilligung bis zum Widerruf erfolgten Verarbeitung berührt wird. + +Die Ausübung Ihrer Rechte ist grundsätzlich kostenlos. In den gesetzlich vorgesehenen Ausnahmefällen, insbesondere bei offenkundig unbegründeten oder exzessiven Anträgen, können wir nach Maßgabe von Art. 12 Abs. 5 DSGVO ein angemessenes Entgelt verlangen oder die Bearbeitung ablehnen. + +Wenn wir begründete Zweifel an Ihrer Identität oder Berechtigung haben, können wir zusätzliche Informationen anfordern, die zur Bestätigung Ihrer Identität oder Berechtigung erforderlich sind. + +Zur Ausübung Ihrer Rechte können Sie uns kontaktieren unter: info@pressekonto.com + +Für Inhalte auf den Portalen nutzen Sie bitte vorrangig das Melde- und Änderungsverfahren unter: [pressekonto.com/de/melden](https://pressekonto.com/de/melden) + +### 15. Beschwerderecht + +Sie haben das Recht, sich bei einer Datenschutz-Aufsichtsbehörde zu beschweren. + +Zuständig für uns ist: + +Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen +Kavalleriestraße 2–4 +40213 Düsseldorf +Website: [www.ldi.nrw.de](https://www.ldi.nrw.de) + +--- + +## B. Datenschutzerklärung 0.3: Portale (presseecho.de, businessportal24.com) + +**Stand: 3. Juli 2026 · Version 0.3.** + +Wiedergegeben ist die Fassung von presseecho.de. businessportal24.com ist wortgleich; nur Domain und Portalname sind andere, nämlich in den Abschnitten 1, 4, 9, 11 und 14. + +Nur auf den Portalen gibt es Abschnitt 7 (Änderungslinks), 9 (Medienprivileg) und 10 (Newsroom). Abschnitt 13 hat zusätzlich den Satz „Für veröffentlichte Presseinhalte gelten die Besonderheiten aus Abschnitt 9.“ + +### 1. Verantwortlicher + +Verantwortlicher für die Datenverarbeitung auf presseecho.de ist: + +adametz.media +Inhaber: Kevin Adametz +In der Lake 4 +33739 Bielefeld +E-Mail: info@pressekonto.com + +### 2. Grundsätze und Rechtsgrundlagen + +Wir verarbeiten personenbezogene Daten nur, soweit dies für den Betrieb dieses Angebots, die Erbringung unserer Leistungen, die Bearbeitung von Anfragen oder aufgrund gesetzlicher Pflichten erforderlich ist. + +Die jeweilige Rechtsgrundlage nennen wir in den einzelnen Abschnitten dieser Datenschutzerklärung. Je nach Verarbeitung kommen insbesondere folgende Rechtsgrundlagen in Betracht: + +- Art. 6 Abs. 1 lit. b DSGVO, soweit die Verarbeitung zur Erfüllung eines Vertrags oder zur Durchführung vorvertraglicher Maßnahmen erforderlich ist, +- Art. 6 Abs. 1 lit. c DSGVO, soweit wir rechtlich zur Verarbeitung verpflichtet sind, +- Art. 6 Abs. 1 lit. f DSGVO, soweit die Verarbeitung zur Wahrung berechtigter Interessen erforderlich ist, +- Art. 85 DSGVO in Verbindung mit den jeweils anwendbaren medien- und presserechtlichen Sonderregelungen, soweit personenbezogene Daten zu journalistisch-redaktionellen Zwecken verarbeitet werden. + +Eine Weitergabe personenbezogener Daten an Dritte erfolgt nur, wenn sie in dieser Datenschutzerklärung beschrieben ist, wenn sie für die Leistungserbringung erforderlich ist, wenn eine gesetzliche Pflicht besteht oder wenn Sie eingewilligt haben. + +Wir verkaufen keine personenbezogenen Daten und schalten keine personalisierte Werbung. + +Die Übertragung dieser Website erfolgt verschlüsselt über TLS. + +### 3. Hosting und Server-Logs + +Unsere Systeme werden bei der Hetzner Online GmbH, Industriestr. 25, 91710 Gunzenhausen, Deutschland, betrieben. Mit Hetzner besteht ein Vertrag zur Auftragsverarbeitung gemäß Art. 28 DSGVO. + +Beim Aufruf unserer Seiten verarbeitet der Webserver technisch notwendige Verbindungsdaten. Dazu gehören insbesondere: + +- IP-Adresse, +- Zeitpunkt des Aufrufs, +- aufgerufene Seite, +- übertragene Datenmenge, +- Referrer-URL, +- User-Agent, +- technische Statuscodes. + +Die Verarbeitung erfolgt zur Bereitstellung, Sicherheit, Stabilität und Fehleranalyse unseres Angebots. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO. + +Die Server-Logs werden grundsätzlich nach 14 Tagen gelöscht, sofern kein sicherheitsrelevanter Vorfall oder eine rechtliche Pflicht eine längere Aufbewahrung erforderlich macht. + +### 4. Cookies und technisch notwendige Speicherungen + +Wir verwenden keine Marketing-Cookies und keine Tracking-Cookies. + +Auf presseecho.de setzen wir keine Marketing- oder Tracking-Cookies ein. Soweit technisch notwendige Speicherungen erforderlich sind, dienen sie ausschließlich dem sicheren Betrieb der Website oder der Bereitstellung ausdrücklich angeforderter Funktionen. + +Da wir keine Marketing- oder Tracking-Cookies einsetzen, ist für diese Website kein Cookie-Banner erforderlich. + +### 5. Webanalyse mit Umami + +Wir nutzen die selbst gehostete Analysesoftware Umami auf eigenen Servern. + +Umami setzt keine Cookies in Ihrem Browser. Es findet kein website- oder geräteübergreifendes Tracking statt. Es werden keine Nutzerprofile erstellt. + +Bei der Erfassung werden IP-Adressen unmittelbar vollständig anonymisiert. Ein Rückschluss auf Ihre Person oder Ihr genaues Gerät ist dadurch ausgeschlossen. + +Verarbeitet werden ausschließlich aggregierte Nutzungsdaten, insbesondere: + +- Seitenaufrufe, +- Referrer, +- Gerätetyp, +- Browser, +- Betriebssystem, +- ungefährer Standort auf Länderebene. + +Die Verarbeitung erfolgt zur Reichweitenmessung, technischen Optimierung und Verbesserung unseres Angebots. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO. Eine Übermittlung der Analysedaten an externe Tracking- oder Werbedienstleister findet nicht statt. + +### 5a. Eigene Nutzungsstatistiken ohne Personenbezug + +Neben Umami führen wir auf unseren eigenen Servern drei einfache Ereignisprotokolle, mit denen wir die Reichweite veröffentlichter Pressemitteilungen belegen und den Weg von einer Benachrichtigung zum Kundenkonto nachvollziehen. Diese Protokolle enthalten keine IP-Adressen, keine Cookies und keine Kennungen, die eine Person oder ein Gerät wiedererkennbar machen. + +- **Aufrufe und Teilen-Klicks je Pressemitteilung.** Gespeichert werden die Meldung, der Zeitpunkt und bei einem Teilen-Klick der gewählte Kanal. Daraus entstehen die Aufrufzahlen und Tagesverläufe, die wir dem einreichenden Unternehmen zeigen. +- **Abrufe durch Such-, KI- und Feed-Dienste.** Ruft ein bekannter Dienst eine Meldung oder einen RSS-Feed ab, speichern wir den Dienst, die gekürzte Programmkennung (User-Agent), den Zeitpunkt und die betroffene Meldung beziehungsweise den Feed. Nennt ein Feed-Dienst in seiner Kennung eine Abonnentenzahl, übernehmen wir diese Zahl. Wer einen Feed abonniert hat, erfahren wir nicht. +- **Schritte vom Hinweis zum Konto.** Klickt ein Empfänger einen Link in einer unserer Benachrichtigungen, nutzt einen Anmeldelink, bearbeitet einen Newsroom, legt ein Konto an oder bucht erstmals, halten wir den Schritt, den Anlass (zum Beispiel „Veröffentlichungsmail") und das betroffene Unternehmen fest. Die Person und ihre E-Mail-Adresse werden dabei nicht gespeichert; die Auswertung zählt Unternehmen, nicht Menschen. + +Die Verarbeitung erfolgt zur Reichweitenmessung gegenüber unseren Kunden, zur Bewertung unserer Benachrichtigungen und zur Verbesserung unseres Angebots. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO. Die Protokolle werden nicht an Dritte weitergegeben und nicht mit anderen Daten zu Nutzerprofilen verbunden. + +### 6. Kontaktaufnahme + +Wenn Sie uns per E-Mail oder über ein Formular kontaktieren, verarbeiten wir die von Ihnen angegebenen Daten zur Bearbeitung Ihrer Anfrage. Dazu können insbesondere gehören: + +- Name, +- E-Mail-Adresse, +- Inhalt Ihrer Nachricht, +- betroffene URL, +- Zeitpunkt der Anfrage, +- technische Metadaten zur Missbrauchsvermeidung und Sicherheit. + +Rechtsgrundlage ist Art. 6 Abs. 1 lit. b DSGVO, soweit Ihre Anfrage mit einem Vertrag oder vorvertraglichen Maßnahmen zusammenhängt. In allen anderen Fällen ist Rechtsgrundlage Art. 6 Abs. 1 lit. f DSGVO. Soweit wir gesetzlich zur Bearbeitung oder Dokumentation verpflichtet sind, ist Rechtsgrundlage Art. 6 Abs. 1 lit. c DSGVO. + +Die Daten werden gelöscht, sobald die Anfrage abgeschlossen ist und keine gesetzlichen Aufbewahrungspflichten oder berechtigten Interessen an einer weiteren Speicherung entgegenstehen. + +Anfragen, die unser Spamfilter als unerwünschte Werbung oder automatisierte Eingabe erkennt, werden ohne Weiterleitung an unser Team zurückgehalten, damit wir Fehleinstufungen prüfen können, und spätestens nach 30 Tagen automatisch gelöscht. + +### 6a. Schutz vor automatisierten Anfragen (Cloudflare Turnstile) + +Um unsere Formulare vor automatisierten Eingaben (Spam, Bots) zu schützen, setzen wir im Kontaktformular und bei der Registrierung den Dienst Turnstile ein. Anbieter ist die Cloudflare, Inc., 101 Townsend St., San Francisco, CA 94107, USA. + +Turnstile wird erst geladen, wenn Sie das Kontaktformular öffnen oder die Registrierungsseite aufrufen. Der Dienst prüft anhand technischer Merkmale, ob die Eingabe von einem Menschen stammt; in der Regel ohne dass Sie etwas tun müssen. Dabei werden insbesondere verarbeitet: + +- IP-Adresse, +- Informationen zu Browser und Betriebssystem (z. B. User-Agent, Spracheinstellungen), +- Merkmale des Seitenaufrufs und der Interaktion mit der Prüfung, +- Zeitpunkt der Prüfung. + +Turnstile setzt nach Angaben von Cloudflare keine Cookies zu Werbe- oder Trackingzwecken und nutzt die Daten nicht für personalisierte Werbung. Wir erhalten von Cloudflare nur das Ergebnis der Prüfung. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO; unser berechtigtes Interesse liegt darin, Missbrauch unserer Formulare zu verhindern, etwa den massenhaften Versand von Bestätigungs-E-Mails an fremde Adressen. Für den Zugriff auf Informationen in Ihrem Endgerät ist Rechtsgrundlage § 25 Abs. 2 Nr. 2 TDDDG, da die Prüfung für den sicheren Betrieb des von Ihnen genutzten Formulars unbedingt erforderlich ist. + +Cloudflare kann Daten auch in den USA verarbeiten. Cloudflare ist nach dem EU-US Data Privacy Framework zertifiziert; die Übermittlung erfolgt auf Grundlage des Angemessenheitsbeschlusses der Europäischen Kommission (Art. 45 DSGVO). Weitere Informationen finden Sie in den Datenschutzhinweisen von Cloudflare ([cloudflare.com/privacypolicy](https://www.cloudflare.com/privacypolicy/)) und zu Turnstile ([cloudflare.com/turnstile-privacy-policy](https://www.cloudflare.com/turnstile-privacy-policy/)). + +### 7. Magic-Link: Änderungslinks für Pressekontakte und berechtigte Personen + +Als in einer Pressemitteilung genannter Pressekontakt, ursprünglicher Auftraggeber, Firmeninhaber oder sonst berechtigte Person können Sie Änderungen über einen zeitlich begrenzten Änderungslink beantragen. Der Link wird an die in der Pressemitteilung oder im Kundenkonto hinterlegte E-Mail-Adresse gesendet. + +Verarbeitet werden: + +- E-Mail-Adresse, +- ein kryptographisch gehashtes Token, +- Zeitstempel, +- betroffene Pressemitteilung, +- beantragte Änderung, +- technische Metadaten zur Sicherheit und Missbrauchsvermeidung. + +Das Token ist nur zeitlich begrenzt gültig und verfällt nach einmaliger Nutzung oder nach Ablauf einer kurzen Gültigkeitsdauer automatisch. Die konkrete Gültigkeitsdauer wird systemseitig festgelegt und beträgt derzeit 15 Minuten. + +Rechtsgrundlagen sind je nach Vorgang Art. 6 Abs. 1 lit. b DSGVO, Art. 6 Abs. 1 lit. c DSGVO und Art. 6 Abs. 1 lit. f DSGVO. Die Verarbeitung dient insbesondere der sicheren Zuordnung berechtigter Änderungsanfragen, der Vertragsdurchführung, der Bearbeitung gesetzlicher Rechte und der Vermeidung von Missbrauch. + +### 8. Automatisierte Inhaltsprüfung und Qualitätsbewertung + +Eingereichte Pressemitteilungen werden vor der Veröffentlichung automatisiert auf die Einhaltung unserer Veröffentlichungsrichtlinien geprüft und inhaltlich bewertet. + +Dabei können auch personenbezogene Daten verarbeitet werden, die in der Pressemitteilung enthalten sind. Soweit möglich, werden personenbezogene Daten vor der automatisierten Analyse minimiert oder entfernt. API-Anbindungen werden, soweit verfügbar, so konfiguriert, dass die übermittelten Inhalte nicht für Trainingszwecke fremder Modelle verwendet werden. + +Für die automatisierte Analyse können je nach Anfrage, Tätigkeit und Verfügbarkeit unterschiedliche KI- oder Analyse-Anbieter eingesetzt werden. Derzeit kommen insbesondere folgende Anbieter in Betracht: + +- OpenAI, +- Google Gemini, +- Anthropic Claude. + +Verarbeitet werden insbesondere: + +- Inhalt der eingereichten Pressemitteilung, +- minimierte oder anonymisierte Prüffassung, soweit technisch möglich, +- Bewertungsergebnis, +- Scores oder Risikomerkmale, +- Ablehnungskategorien, +- interne Hinweise zur Qualitätsbewertung, +- Ergebnis einer gegebenenfalls durchgeführten menschlichen Überprüfung. + +Führt die Prüfung zur Ablehnung einer Mitteilung, teilen wir Ihnen die Ablehnungskategorie mit. Sie können eine Überprüfung durch einen Menschen verlangen und dabei Ihren Standpunkt darlegen. Die Entscheidung wird dann erneut geprüft. + +Die Prüfergebnisse, Scores, Ablehnungskategorien und Begründungen werden intern der jeweiligen Pressemitteilung zugeordnet und grundsätzlich so lange gespeichert, wie die Pressemitteilung gespeichert oder veröffentlicht bleibt. Dies dient der Nachvollziehbarkeit der Veröffentlichungsentscheidung, der Qualitätssicherung, der Bearbeitung von Rückfragen sowie der Rechtsverteidigung. + +Rechtsgrundlagen sind Art. 6 Abs. 1 lit. b DSGVO und Art. 6 Abs. 1 lit. f DSGVO. Soweit gesetzliche Dokumentationspflichten bestehen oder Meldungen nach dem Digital Services Act betroffen sind, kann zusätzlich Art. 6 Abs. 1 lit. c DSGVO einschlägig sein. + +### 9. Veröffentlichte Pressemitteilungen und Medienprivileg + +Die auf presseecho veröffentlichten Pressemitteilungen sind öffentlich zugängliche Presseinhalte und Teil eines dauerhaften Archivs. In Pressemitteilungen können personenbezogene Daten enthalten sein, zum Beispiel: + +- Namen von Ansprechpartnern, +- berufliche Kontaktdaten, +- Zitate, +- Funktionen im Unternehmen, +- Personalien, +- Bildmaterial, +- sonstige Angaben mit Personenbezug. + +Soweit die Verarbeitung zu journalistisch-redaktionellen Zwecken erfolgt, gelten die hierfür vorgesehenen Sonderregeln nach Art. 85 DSGVO in Verbindung mit dem jeweils anwendbaren Medien- und Presserecht. Für den Verantwortlichen mit Sitz in Nordrhein-Westfalen kommen insbesondere § 57 Abs. 1 Medienstaatsvertrag (MStV) sowie die einschlägigen Regelungen des Pressegesetzes für das Land Nordrhein-Westfalen in Betracht. + +Durch die medien- und presserechtlichen Sonderregeln können einzelne Betroffenenrechte eingeschränkt sein, soweit dies zur Wahrung der Meinungs- und Informationsfreiheit, der Pressefreiheit und der Archivfunktion erforderlich ist. Dies bedeutet nicht, dass Betroffenenrechte ausgeschlossen sind. Wir prüfen entsprechende Anfragen im Einzelfall. + +Unabhängig davon können Sie jederzeit die Entfernung, Aktualisierung oder Anonymisierung Ihrer persönlichen Kontaktdaten als natürliche Person beantragen. Auch Meldungen rechtswidriger Inhalte sind jederzeit kostenlos möglich. Die dafür vorgesehenen Wege finden Sie unter: [presseecho.de/de/melden](https://presseecho.de/de/melden). + +Angaben über juristische Personen, zum Beispiel GmbH oder AG, sind grundsätzlich keine personenbezogenen Daten im Sinne der DSGVO. Enthalten Angaben über Unternehmen zugleich Informationen über natürliche Personen, prüfen wir Betroffenenanfragen im Einzelfall. + +Informationen aus öffentlichen Registern, zum Beispiel dem Handelsregister, berücksichtigen wir bei dieser Prüfung entsprechend ihrer gesetzlichen Publizitätsfunktion. + +### 10. Newsroom und Firmenprofile + +Zu jedem veröffentlichenden Unternehmen kann ein öffentliches Firmenprofil („Newsroom") mit den vom Kunden bereitgestellten Angaben und dessen Pressemitteilungen angezeigt werden. + +Dabei können insbesondere verarbeitet und veröffentlicht werden: + +- Unternehmensname, +- Logo, +- Beschreibung, +- Anschrift oder Standortangaben, +- Website, +- Branchenangaben, +- Ansprechpartner, +- berufliche Kontaktdaten, +- veröffentlichte Pressemitteilungen. + +Verantwortlich für die inhaltlichen Angaben ist das jeweilige veröffentlichende Unternehmen. Die Verarbeitung durch uns erfolgt zur Vertragsdurchführung nach Art. 6 Abs. 1 lit. b DSGVO sowie, soweit einschlägig, zu journalistisch-redaktionellen Zwecken nach dem vorstehenden Abschnitt. + +Soweit Firmenprofile personenbezogene Daten enthalten, zum Beispiel Ansprechpartner oder Kontaktdaten, gelten die Hinweise aus dem vorstehenden Abschnitt entsprechend. + +### 11. Meldeverfahren + +Wenn Sie über unser Meldeverfahren einen Inhalt melden, eine Änderung beantragen oder eigene personenbezogene Daten entfernen lassen möchten, verarbeiten wir die von Ihnen angegebenen Daten zur Bearbeitung der Meldung oder Anfrage. + +Dabei können insbesondere verarbeitet werden: + +- Name, +- E-Mail-Adresse, +- betroffene URL, +- Begründung der Meldung, +- ausgewählte Meldekategorie, +- Nachweise oder ergänzende Angaben, +- Zeitpunkt der Meldung, +- Vorgangsnummer, +- Bearbeitungsstatus, +- Entscheidung und Begründung, +- Kommunikationsverlauf. + +Die Verarbeitung erfolgt zur Bearbeitung Ihrer Meldung, zur Erfüllung gesetzlicher Pflichten, insbesondere nach dem Digital Services Act und der DSGVO, zur Dokumentation der Entscheidung sowie zur Rechtsverteidigung. + +Rechtsgrundlagen sind Art. 6 Abs. 1 lit. c DSGVO und Art. 6 Abs. 1 lit. f DSGVO. Soweit die Meldung mit einem bestehenden Vertrag oder Kundenkonto zusammenhängt, kann zusätzlich Art. 6 Abs. 1 lit. b DSGVO einschlägig sein. + +Meldedaten bewahren wir zur Dokumentation der Bearbeitung und Entscheidung grundsätzlich für drei Jahre nach Abschluss des Vorgangs auf. Eine längere Speicherung erfolgt nur, soweit dies zur Bearbeitung laufender Vorgänge, zur Erfüllung gesetzlicher Pflichten oder zur Rechtsverteidigung erforderlich ist. + +Meldungen und Änderungsanfragen können über die auf den Portalen vorgesehenen Wege ([Inhalte melden](https://presseecho.de/de/melden)) oder die Melde-Links bei der jeweiligen Pressemitteilung eingereicht werden. + +Für Rückfragen zu bestehenden Meldungen nutzen Sie bitte die Eingangsbestätigung oder kontaktieren Sie uns über info@pressekonto.com. + +### 12. E-Mail-Versand + +Für den Versand transaktionaler E-Mails nutzen wir: + +ALL-INKL.COM - Neue Medien Münnich +Inhaber: René Münnich +Hauptstraße 68 +02742 Friedersdorf +Deutschland + +Transaktionale E-Mails sind insbesondere: + +- Magic-Links, +- Änderungslinks, +- Buchungsbestätigungen, +- Rechnungen oder Rechnungshinweise, +- Eingangsbestätigungen zu Meldungen, +- Benachrichtigungen zu Veröffentlichungen, +- System- und Sicherheitsmitteilungen. + +Dabei werden insbesondere verarbeitet: + +- E-Mail-Adresse, +- Empfängername, soweit vorhanden, +- Inhalt der jeweiligen Nachricht, +- Versandzeitpunkt, +- technische Zustelldaten, +- Statusinformationen zur Zustellung. + +Rechtsgrundlagen sind je nach Zweck der jeweiligen E-Mail Art. 6 Abs. 1 lit. b DSGVO, Art. 6 Abs. 1 lit. c DSGVO und Art. 6 Abs. 1 lit. f DSGVO. + +Mit dem Dienstleister besteht, soweit erforderlich, ein Vertrag zur Auftragsverarbeitung gemäß Art. 28 DSGVO. + +### 13. Speicherdauer, Backups und Aufbewahrungspflichten + +Wir speichern personenbezogene Daten nur so lange, wie es für die in dieser Datenschutzerklärung genannten Zwecke erforderlich ist. + +Es gelten insbesondere folgende Speicherfristen: + +- Server-Logs werden grundsätzlich nach 14 Tagen gelöscht, sofern kein sicherheitsrelevanter Vorfall eine längere Aufbewahrung erforderlich macht. +- Magic-Link-Token verfallen nach einmaliger Nutzung oder nach Ablauf von 15 Minuten. +- Die Ereignisprotokolle zu Aufrufen, Abrufen durch Dienste und Konversionsschritten (Abschnitt 5a) werden nach 395 Tagen gelöscht. +- Meldedaten werden grundsätzlich für drei Jahre nach Abschluss des Vorgangs gespeichert. +- Vertrags-, Buchungs- und Rechnungsdaten unterliegen handels- und steuerrechtlichen Aufbewahrungspflichten und werden nach Ablauf dieser Fristen gelöscht. +- Veröffentlichte Pressemitteilungen werden im Rahmen der Archivfunktion grundsätzlich dauerhaft gespeichert, soweit keine gesetzlichen Ansprüche auf Entfernung, Sperrung oder Änderung bestehen. +- Kontodaten werden nach Kontolöschung entfernt, soweit keine Aufbewahrungspflichten, offenen Vorgänge oder berechtigten Interessen an einer weiteren Speicherung entgegenstehen. + +Gelöschte Daten können in Sicherungskopien noch bis zu vier Wochen enthalten sein. Die Backups werden ausschließlich zur Wiederherstellung der Systeme im Sicherungsfall verwendet und nicht produktiv ausgewertet. + +### 14. Ihre Rechte + +Sie haben gegenüber uns nach Maßgabe der gesetzlichen Voraussetzungen folgende Rechte: + +- Recht auf Auskunft nach Art. 15 DSGVO, +- Recht auf Berichtigung nach Art. 16 DSGVO, +- Recht auf Löschung nach Art. 17 DSGVO, +- Recht auf Einschränkung der Verarbeitung nach Art. 18 DSGVO, +- Recht auf Datenübertragbarkeit nach Art. 20 DSGVO, +- Recht auf Widerspruch gegen Verarbeitungen auf Grundlage berechtigter Interessen nach Art. 21 DSGVO, +- Recht auf jederzeitigen Widerruf einer erteilten Einwilligung nach Art. 7 Abs. 3 DSGVO, ohne dass die Rechtmäßigkeit der aufgrund der Einwilligung bis zum Widerruf erfolgten Verarbeitung berührt wird. + +Für veröffentlichte Presseinhalte gelten die Besonderheiten aus Abschnitt 9. + +Die Ausübung Ihrer Rechte ist grundsätzlich kostenlos. In den gesetzlich vorgesehenen Ausnahmefällen, insbesondere bei offenkundig unbegründeten oder exzessiven Anträgen, können wir nach Maßgabe von Art. 12 Abs. 5 DSGVO ein angemessenes Entgelt verlangen oder die Bearbeitung ablehnen. + +Wenn wir begründete Zweifel an Ihrer Identität oder Berechtigung haben, können wir zusätzliche Informationen anfordern, die zur Bestätigung Ihrer Identität oder Berechtigung erforderlich sind. + +Zur Ausübung Ihrer Rechte können Sie uns kontaktieren unter: info@pressekonto.com + +Für Inhalte auf den Portalen nutzen Sie bitte vorrangig das Melde- und Änderungsverfahren unter: [presseecho.de/de/melden](https://presseecho.de/de/melden) + +### 15. Beschwerderecht + +Sie haben das Recht, sich bei einer Datenschutz-Aufsichtsbehörde zu beschweren. + +Zuständig für uns ist: + +Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen +Kavalleriestraße 2–4 +40213 Düsseldorf +Website: [www.ldi.nrw.de](https://www.ldi.nrw.de) + +--- + +## C. AGB 0.6 (alle Domains) + +**Stand: 3. Juli 2026 · Version 0.6.** Auf allen drei Domains wortgleich; auf den Portalen führen nur die Links auf die eigene Domain (siehe Hinweis 4). + +### § 1 Geltungsbereich und Vertragspartner + +(1) Diese Allgemeinen Geschäftsbedingungen (nachfolgend „AGB") gelten für alle Verträge über die Veröffentlichung von Pressemitteilungen und damit verbundene Leistungen, die über die Plattform **pressekonto** (erreichbar unter [pressekonto.com](https://pressekonto.com)) geschlossen werden. + +(2) Vertragspartner ist: adametz.media, Inhaber Kevin Adametz, In der Lake 4, 33739 Bielefeld (nachfolgend „Anbieter"). + +(3) Die Veröffentlichung der Pressemitteilungen erfolgt auf den vom Anbieter betriebenen **angeschlossenen Portalen**. Angeschlossene Portale sind derzeit: + +- presseecho.de +- businessportal24.com + +Der Anbieter kann weitere eigene Portale anschließen. Die jeweils aktuelle Liste ist auf [pressekonto.com](https://pressekonto.com/#familie) einsehbar. Der Anschluss weiterer Portale erweitert den Leistungsumfang und stellt keine Änderung dieser AGB dar. + +(4) **Das Angebot richtet sich ausschließlich an Unternehmer** im Sinne des § 14 BGB, juristische Personen des öffentlichen Rechts und öffentlich-rechtliche Sondervermögen. Ein Vertragsschluss mit Verbrauchern (§ 13 BGB) erfolgt nicht. Der Kunde bestätigt bei der Buchung ausdrücklich, dass er in Ausübung seiner gewerblichen oder selbständigen beruflichen Tätigkeit handelt; der Anbieter darf auf diese Bestätigung vertrauen. + +(5) Abweichende Geschäftsbedingungen des Kunden finden keine Anwendung, auch wenn der Anbieter ihrer Geltung nicht ausdrücklich widerspricht. + +### § 2 Begriffsbestimmungen + +- **Pressemitteilung (PM):** Ein vom Kunden eingereichter Beitrag mit presse- bzw. unternehmensbezogenem Nachrichtencharakter. +- **Slot:** Ein Veröffentlichungskontingent innerhalb eines Tarifs. Ein Slot wird nur durch eine tatsächlich erfolgte Veröffentlichung verbraucht. +- **Credit:** Eine vorausbezahlte Verrechnungseinheit für Zusatzleistungen. Die für den Erwerb von Credits und für Zusatzleistungen jeweils geltenden Preise ergeben sich aus der bei Buchung angezeigten Preis- und Leistungsbeschreibung. Alle Preise verstehen sich netto zuzüglich der gesetzlichen Umsatzsteuer. +- **Boost:** Eine zeitlich befristete hervorgehobene Platzierung einer veröffentlichten PM. +- **Inhaltsprüfung:** Die automatisierte Prüfung eingereichter PMs vor Veröffentlichung (siehe § 7). +- **Veröffentlichungsrichtlinien:** Die unter [pressekonto.com/richtlinien](https://pressekonto.com/de/richtlinien) einsehbaren inhaltlichen Anforderungen an PMs. Sie sind Bestandteil dieser AGB. + +### § 3 Registrierung und Vertragsschluss + +(1) Die Nutzung der Plattform setzt die Registrierung eines Kundenkontos auf [pressekonto.com](https://pressekonto.com) voraus. Die Registrierung ist kostenlos. Das Anlegen und Speichern von PM-Entwürfen ist ohne kostenpflichtige Buchung möglich. **Die Einreichung und Veröffentlichung von PMs setzt voraus, dass der Kunde mindestens ein Firmenprofil (Unternehmen) angelegt hat; jede PM wird im Namen eines Unternehmens veröffentlicht.** + +(2) Die Darstellung der Tarife und Leistungen auf der Plattform stellt kein bindendes Angebot dar, sondern eine Aufforderung zur Abgabe eines Angebots. Der Vertrag kommt zustande, indem der Kunde den Buchungsvorgang durch Klick auf die Schaltfläche „zahlungspflichtig bestellen" (oder gleichbedeutend) abschließt und der Anbieter die Buchung per E-Mail bestätigt. + +(3) Der Vertragstext wird vom Anbieter gespeichert. Der Kunde erhält die Vertragsbestimmungen einschließlich dieser AGB mit der Buchungsbestätigung in Textform. Die bei Vertragsschluss gültige AGB-Fassung wird dem Buchungsvorgang dauerhaft zugeordnet und ist für den Kunden im Kundenkonto abrufbar. + +(4) Der Kunde sichert zu, dass die bei Registrierung und Buchung angegebenen Daten zutreffend und vollständig sind, und hält sie aktuell. Dies gilt insbesondere für die Bestätigung seiner Unternehmereigenschaft (§ 1 Abs. 4) und die Angaben zu seinem Unternehmen. + +(5) Die für den Vertragsschluss zur Verfügung stehende Sprache ist ausschließlich Deutsch. + +(6) Informationen zur Verarbeitung personenbezogener Daten finden sich in der Datenschutzerklärung unter [pressekonto.com/datenschutz](https://pressekonto.com/de/datenschutz). + +### § 4 Leistungsumfang: Tarife, Slots und Tageslimits + +(1) Der Anbieter bietet folgende Leistungsmodelle an: + +- **Einzelveröffentlichung** („Einzel"): einmalige Veröffentlichung einer PM ohne Abonnement. +- **Abonnements** („Starter", „Business", „Pro", „Agency"): monatliche Veröffentlichungskontingente (Slots) gemäß der bei Buchung gültigen Leistungsbeschreibung unter [pressekonto.com/preise](https://pressekonto.com/de/preise). + +(2) Slots eines Abonnements gelten für den jeweiligen Abrechnungsmonat. Nicht genutzte Slots verfallen mit Ablauf des Abrechnungsmonats; hierauf wird in der Leistungsbeschreibung deutlich hingewiesen. **Slots stellen kein Geldguthaben dar, sind nicht auszahlbar und können nicht auf spätere Abrechnungsmonate übertragen werden.** + +(3) Ein Slot wird ausschließlich durch eine tatsächlich erfolgte Veröffentlichung verbraucht. **Wird eine PM im Rahmen der Inhaltsprüfung abgelehnt, wird kein Slot verbraucht.** Wird eine PM aufgrund eines technischen Fehlers des Anbieters nicht oder nicht wie vorgesehen veröffentlicht, wird der dafür eingesetzte Slot dem Kundenkonto unverzüglich wieder gutgeschrieben. + +(4) Zur Sicherung der redaktionellen Qualität der angeschlossenen Portale gelten je Tarif tägliche Veröffentlichungshöchstmengen (Tageslimits) gemäß Leistungsbeschreibung. Über das Tageslimit hinaus eingereichte PMs können für den Folgetag eingeplant werden. + +(5) Überschreitet der Kunde sein Monatskontingent, kann er zusätzliche Veröffentlichungen als Zusatzleistung gegen Credits buchen (Extra-PM, § 6). + +### § 5 Credits + +(1) Credits sind vorausbezahlte Verrechnungseinheiten für Zusatzleistungen (§ 6). Der Erwerb erfolgt über das Kundenkonto; die verfügbaren Credit-Pakete und Preise sind unter [pressekonto.com/preise](https://pressekonto.com/de/preise) ausgewiesen. + +(2) **Gültigkeit:** Erworbene Credits sind mindestens drei Jahre ab dem Ende des Kalenderjahres gültig, in dem der Erwerb erfolgte. Vor Ablauf der Gültigkeit informiert der Anbieter den Kunden rechtzeitig per E-Mail an die im Kundenkonto hinterlegte Adresse. + +(3) **Keine Auszahlung:** Eine Rückzahlung oder Barauszahlung erworbener Credits ist ausgeschlossen. Zwingende gesetzliche Ansprüche bleiben unberührt. + +(4) Credits sind an das Kundenkonto gebunden und nicht auf andere Konten übertragbar. + +(5) Bei der Verrechnung werden stets die ältesten Credits zuerst verbraucht (First-in-first-out). + +(6) **Kontolöschung:** Verfügt der Kunde bei einer von ihm veranlassten Löschung seines Kundenkontos noch über ein Credit-Guthaben, wird er im Löschvorgang ausdrücklich auf die Höhe des Guthabens und dessen ersatzlosen Verfall hingewiesen. Die Löschung wird erst nach gesonderter Bestätigung dieses Hinweises ausgeführt. Alternativ kann der Kunde das Konto bis zum Verbrauch oder zum Ablauf der Gültigkeit (Absatz 2) kostenlos fortführen. Gesetzliche Erstattungsansprüche bleiben unberührt. + +### § 6 Zusatzleistungen + +(1) **Extra-PM:** Veröffentlichung einer zusätzlichen PM über das Monatskontingent hinaus. Der Credit-Preis richtet sich nach dem gebuchten Tarif und ist in der Leistungsbeschreibung ausgewiesen. + +(2) **Boost:** Zeitlich befristete hervorgehobene Platzierung einer veröffentlichten PM (Startseite und Kategorieseite des jeweiligen Portals) in den Laufzeitstufen 7, 14 oder 30 Tage. Ein Boost ist nur für PMs buchbar, die die Inhaltsprüfung ohne Beanstandung durchlaufen haben (Status „Grün"). **Geschuldet ist ausschließlich die Platzierung während der gebuchten Laufzeit; eine bestimmte Reichweite, Zugriffszahl oder sonstige Werbewirkung wird nicht geschuldet.** Ist das jeweilige Portal während eines aktiven Boosts aus vom Anbieter zu vertretenden Gründen nicht erreichbar, verlängert sich die gebuchte Boost-Laufzeit um die Dauer der Nichterreichbarkeit. Kurzzeitige Unterbrechungen von weniger als 60 zusammenhängenden Minuten bleiben unberücksichtigt. + +(3) **Veröffentlichungsnachweis (PDF):** Auf Wunsch erstellt der Anbieter einen Nachweis der Veröffentlichung als PDF-Dokument zu dem in der Leistungsbeschreibung ausgewiesenen Credit-Preis. + +(4) Zusatzleistungen werden im Zeitpunkt der Buchung mit dem Credit-Guthaben verrechnet. Reicht das Guthaben nicht aus, ist ein Nachkauf im Buchungsvorgang möglich. + +### § 7 Inhaltsprüfung und Veröffentlichung + +(1) Jede eingereichte PM durchläuft vor Veröffentlichung eine automatisierte Inhaltsprüfung anhand der Veröffentlichungsrichtlinien. Die Prüfung dient dem Schutz der Leser, der Rechtskonformität und der redaktionellen Qualität der angeschlossenen Portale. + +(2) Ergebnis der Prüfung: + +- **Grün / Gelb:** Die PM wird nach Abschluss der Inhaltsprüfung veröffentlicht; ein Slot wird verbraucht. Gelb bedeutet, dass die PM trotz einzelner Hinweise oder Risikomerkmale nach automatisierter Prüfung veröffentlichungsfähig ist; Einzelheiten regeln die Veröffentlichungsrichtlinien. +- **Rot:** Die PM wird nicht veröffentlicht; es wird kein Slot verbraucht. Der Kunde erhält die Ablehnung mit Angabe der Ablehnungskategorie. + +(3) **Ein Anspruch auf Veröffentlichung besteht nicht**, wenn und soweit die PM gegen die Veröffentlichungsrichtlinien, gesetzliche Vorschriften oder Rechte Dritter verstößt. Die Ablehnungsgründe werden in den Veröffentlichungsrichtlinien kategorisiert; bei einer Ablehnung gibt der Anbieter mindestens eine einschlägige Ablehnungskategorie an. + +(4) **Menschliche Überprüfung:** Der Kunde kann gegen eine Ablehnung eine Überprüfung durch einen Menschen verlangen. Der Antrag erfolgt formlos über das Kundenkonto oder per E-Mail an info@pressekonto.com. Der Anbieter teilt das Ergebnis der Überprüfung in der Regel innerhalb von zwei Werktagen mit. Ist eine Prüfung innerhalb dieser Frist nicht möglich, informiert der Anbieter den Kunden über die Verzögerung. + +(5) Eine redaktionelle Bearbeitung eingereichter PMs durch den Anbieter findet nicht statt. Technisch bedingte Anpassungen (Formatierung, Erstellung von Anrisstexten/Teasern, Bildzuschnitte für Vorschaudarstellungen) bleiben vorbehalten und stellen keine inhaltliche Bearbeitung dar. + +(6) Der Zeitpunkt der Veröffentlichung ergibt sich aus dem Abschluss der Inhaltsprüfung; ein bestimmter Veröffentlichungszeitpunkt wird nicht geschuldet, es sei denn, er ist ausdrücklich vereinbart. + +### § 8 Pflichten des Kunden; Verantwortlichkeit für Inhalte + +(1) Der Kunde ist für den Inhalt seiner PMs allein verantwortlich. Er sichert zu, dass + +- er über alle für die Veröffentlichung erforderlichen Rechte an Texten, Bildern und sonstigen Inhalten verfügt, +- die Inhalte keine Rechte Dritter (insbesondere Urheber-, Marken-, Persönlichkeits- und Wettbewerbsrechte) verletzen, +- die Inhalte nicht gegen gesetzliche Vorschriften oder die Veröffentlichungsrichtlinien verstoßen, +- enthaltene Tatsachenbehauptungen zutreffend sind. + +(2) Der Kunde stellt den Anbieter von Ansprüchen Dritter frei, die auf einer schuldhaften Verletzung der Pflichten aus Absatz 1 beruhen, einschließlich der angemessenen Kosten der Rechtsverteidigung. + +(3) Wird der Anbieter wegen eines Kundeninhalts von Dritten oder Behörden in Anspruch genommen oder liegt ein begründeter Hinweis auf Rechtswidrigkeit vor (insbesondere über das Meldeverfahren nach dem Digital Services Act), ist der Anbieter berechtigt, die betroffene PM vorläufig zu depublizieren, bis der Sachverhalt geklärt ist. Der Kunde wird hierüber unverzüglich informiert und erhält Gelegenheit zur Stellungnahme. + +### § 9 Rechteeinräumung + +(1) Der Kunde räumt dem Anbieter an den eingereichten Inhalten das einfache, räumlich unbeschränkte Recht ein, die Inhalte für die Dauer der Veröffentlichung auf den angeschlossenen Portalen öffentlich zugänglich zu machen, zu vervielfältigen und technisch aufzubereiten (Formatierung, Teaser, Vorschaubilder, responsive Darstellungen). + +(2) Soweit der Kunde eine zusätzliche Verbreitung über **Partnerportale** auswählt oder diese ausdrücklich Bestandteil des gebuchten Tarifs ist, räumt der Kunde dem Anbieter das Recht ein, die PM an die in der Leistungsbeschreibung genannten Partner oder Partnerkategorien zur dortigen Veröffentlichung weiterzugeben. Ohne eine solche Auswahl oder Tarifzugehörigkeit erfolgt keine Weitergabe an Dritte. + +(3) Eine inhaltliche Veränderung, Kürzung oder Bearbeitung über Absatz 1 hinaus erfolgt nicht. + +(4) Die Rechteeinräumung nach Absatz 1 bleibt für die Dauer der Archivierung bestehen, auch wenn das Kundenkonto endet (§ 11 Abs. 5). + +### § 10 Preise, Zahlung, Rechnungen + +(1) Es gelten die zum Zeitpunkt der Buchung ausgewiesenen Preise. Alle Preise verstehen sich netto zuzüglich der gesetzlichen Umsatzsteuer. + +(2) Die Zahlung erfolgt über den Zahlungsdienstleister Stripe mit den im Buchungsvorgang angebotenen Zahlungsmitteln. Abonnementgebühren werden zu Beginn des jeweiligen Abrechnungszeitraums fällig und über das hinterlegte Zahlungsmittel eingezogen. + +(3) Rechnungen werden elektronisch erstellt und im Kundenkonto bereitgestellt sowie per E-Mail übermittelt. + +(4) Schlägt ein Einzug fehl, wird der Kunde benachrichtigt und erhält Gelegenheit zur Aktualisierung des Zahlungsmittels. Während eines Zahlungsverzugs kann der Anbieter die Annahme neuer PMs aussetzen; bereits veröffentlichte PMs bleiben online. + +(5) **Preisänderungen laufender Abonnements:** Der Anbieter kann die Preise laufender Abonnements mit Wirkung für die Zukunft anpassen. Eine Preisanpassung kommt insbesondere in Betracht, wenn sich Kosten für Hosting, technische Infrastruktur, Zahlungsabwicklung, gesetzliche oder regulatorische Anforderungen, Portalbetrieb oder sonstige für die Leistungserbringung wesentliche Kostenpositionen nicht nur unerheblich ändern; Kostensenkungen werden dabei ebenso berücksichtigt wie Kostensteigerungen. Die Preisanpassung darf den Umfang der eingetretenen Kostenänderung nicht überschreiten. Preisänderungen werden dem Kunden mindestens sechs Wochen vor dem Wirksamwerden in Textform angekündigt. Dem Kunden steht in diesem Fall ein Sonderkündigungsrecht zum Zeitpunkt des Wirksamwerdens zu; hierauf wird in der Ankündigung ausdrücklich hingewiesen. Für den zum Zeitpunkt der Ankündigung bereits bezahlten Abrechnungszeitraum bleibt der vereinbarte Preis unverändert. Bereits erworbene Credits sind von Preisänderungen nicht betroffen. + +### § 11 Laufzeit, Verlängerung, Kündigung + +(1) Einzelveröffentlichungen und Credit-Käufe begründen kein Dauerschuldverhältnis. + +(2) Abonnements haben eine Laufzeit von einem Monat (monatliche Zahlweise) bzw. zwölf Monaten (jährliche Zahlweise). Das Abonnement verlängert sich jeweils automatisch um die gewählte Laufzeit (einen Monat bzw. zwölf Monate), sofern es nicht vor Ablauf der laufenden Laufzeit gekündigt wird. **Die Kündigung ist jederzeit mit Wirkung zum Ende der laufenden Laufzeit möglich; bei monatlicher Zahlweise also monatlich, bei jährlicher Zahlweise zum Ende des jeweiligen Zwölfmonats-Zeitraums. Der Jahresrabatt („2 Monate gratis") gilt nur bei jährlicher Zahlweise.** + +(3) Die Kündigung ist möglich: + +- jederzeit über die Kündigungsfunktion im Kundenkonto (Selfservice) oder die [öffentliche Kündigungsseite](https://pressekonto.com/de/kuendigung), +- in Textform an info@pressekonto.com. + +Die Angabe von Zugangsdaten oder Passwörtern ist für die Kündigung per Textform nicht erforderlich. Der Anbieter bestätigt dem Kunden den Inhalt der Kündigung, Datum und Uhrzeit ihres Zugangs sowie den Zeitpunkt der Vertragsbeendigung unverzüglich auf elektronischem Wege in Textform. + +(4) Das Recht zur außerordentlichen Kündigung aus wichtigem Grund bleibt unberührt. Ein wichtiger Grund für den Anbieter liegt insbesondere vor bei wiederholten oder schwerwiegenden Verstößen gegen § 8. + +(5) Nach Vertragsende bleiben veröffentlichte PMs im Archiv der angeschlossenen Portale öffentlich zugänglich (Archivfunktion). Der Kunde behält über sein Kundenkonto Zugriff auf seine Inhalte und die Änderungsfunktionen; verbleibende Credits behalten ihre Gültigkeit nach § 5 Abs. 2. + +(6) **Datenexport:** Der Kunde kann die von ihm eingereichten Inhalte (Texte und Entwürfe) jederzeit in einem gängigen elektronischen Format erhalten; bis zur Bereitstellung einer Selfservice-Exportfunktion erfolgt die Herausgabe auf Anfrage an info@pressekonto.com. Gesetzliche Ansprüche (insbesondere Art. 20 DSGVO) bleiben unberührt. + +### § 12 Kein Widerrufsrecht (B2B) + +(1) Da sich das Angebot ausschließlich an Unternehmer richtet (§ 1 Abs. 4), besteht kein gesetzliches Widerrufsrecht. + +(2) Bestätigt ein Kunde bei der Buchung wahrheitswidrig, als Unternehmer zu handeln, kann er sich nach Treu und Glauben nicht auf Verbraucherschutzvorschriften berufen. + +### § 13 Depublikation, Änderungen, Meldeverfahren + +(1) Veröffentlichte PMs werden dauerhaft archiviert. **Auf die dauerhafte Archivierung wird der Kunde vor jeder Veröffentlichung im Veröffentlichungsvorgang ausdrücklich hingewiesen.** Eine nachträgliche Entfernung einer veröffentlichten PM aus der öffentlichen Ansicht der angeschlossenen Portale („Depublikation") ist bei rechtmäßigen Inhalten nur als freiwillige Serviceleistung des Anbieters gegen Entgelt möglich. Der jeweils geltende Preis (netto zuzüglich Umsatzsteuer) wird vor Beauftragung angezeigt. Bei einer Depublikation bleibt die ursprüngliche URL mit einem Hinweis auf die Entfernung bestehen („Tombstone"); eine vollständige Löschung der URL erfolgt nicht. Eine Entfernung aus Suchmaschinen-Caches, Archiven Dritter oder bereits erfolgten Weiterveröffentlichungen durch Dritte ist nicht geschuldet. **Gesetzliche Ansprüche des Kunden, insbesondere nach Datenschutzrecht, Persönlichkeitsrecht oder aufgrund rechtswidriger Inhalte, bleiben unberührt.** + +(2) **Unentgeltlich bleiben stets:** die Geltendmachung von Betroffenenrechten nach der DSGVO (insbesondere die Entfernung personenbezogener Kontaktdaten natürlicher Personen), Meldungen rechtswidriger Inhalte nach dem Digital Services Act sowie die Korrektur von Fehlern über das Änderungssystem. Einzelheiten regelt die Seite [Inhalte melden](https://pressekonto.com/de/melden). + +(3) Für nachträgliche Änderungen an veröffentlichten PMs stellt der Anbieter ein Änderungssystem bereit (Korrektur von Tippfehlern, Aktualisierung von Kontaktdaten). Umfang und Verfahren ergeben sich aus der Leistungsbeschreibung. + +### § 14 Gewährleistung und Haftung + +(1) Der Anbieter erbringt die Leistungen mit einer Verfügbarkeit von 98 % im Monatsmittel. Maßgeblich ist die Erreichbarkeit der Plattform (Kundenkonto und Buchungsfunktionen) sowie der angeschlossenen Portale. Kurzzeitige Unterbrechungen von weniger als 60 zusammenhängenden Minuten bleiben bei der Berechnung unberücksichtigt. Wird der Wert in einem Kalendermonat unterschritten, erhält der Kunde auf Antrag eine Gutschrift; diese berechnet sich zeitanteilig nach der Dauer der relevanten Nichterreichbarkeit im betroffenen Kalendermonat und ist auf die für diesen Monat gezahlte Abonnementgebühr begrenzt. Der Antrag ist innerhalb von vier Wochen nach Ablauf des betroffenen Kalendermonats zu stellen. Die Gutschrift wird auf etwaige Schadensersatzansprüche des Kunden wegen derselben Nichterreichbarkeit angerechnet. Ausgenommen von der Berechnung sind angekündigte Wartungsfenster und Störungen außerhalb des Einflussbereichs des Anbieters. + +(2) Der Anbieter haftet unbeschränkt für Vorsatz und grobe Fahrlässigkeit sowie für Schäden aus der Verletzung von Leben, Körper oder Gesundheit. + +(3) Bei einfacher Fahrlässigkeit haftet der Anbieter nur für die Verletzung wesentlicher Vertragspflichten (Kardinalpflichten), begrenzt auf den vertragstypischen, vorhersehbaren Schaden. + +(4) Die Haftung nach dem Produkthaftungsgesetz bleibt unberührt. + +(5) Der Anbieter macht sich die Inhalte der Kunden nicht zu eigen. Für fremde Inhalte gelten die Haftungsregeln des Digital Services Act. + +### § 15 Änderungen dieser AGB + +(1) Der Anbieter kann diese AGB mit Wirkung für die Zukunft ändern, soweit die Änderung erforderlich ist (z. B. Gesetzesänderungen, Rechtsprechung, neue Leistungsbestandteile) und den Kunden nicht unangemessen benachteiligt. + +(2) Änderungen werden dem Kunden mindestens vier Wochen vor Inkrafttreten in Textform mitgeteilt, unter Hervorhebung der geänderten Regelungen. + +(3) **Wesentliche Änderungen** — insbesondere solche, die Leistungsumfang, Preise oder Kündigungsrechte betreffen — bedürfen der ausdrücklichen Zustimmung des Kunden. Stimmt der Kunde nicht zu, wird der Vertrag zu den bisherigen Bedingungen fortgesetzt. Das Recht beider Parteien zur ordentlichen Kündigung bleibt unberührt. + +(4) Für unwesentliche Änderungen (z. B. redaktionelle Klarstellungen oder neue angeschlossene Portale, soweit hierdurch keine zusätzlichen Pflichten des Kunden entstehen) genügt die Mitteilung nach Absatz 2. + +### § 16 Schlussbestimmungen + +(1) Es gilt das Recht der Bundesrepublik Deutschland unter Ausschluss des UN-Kaufrechts. + +(2) Ist der Kunde Kaufmann, juristische Person des öffentlichen Rechts oder öffentlich-rechtliches Sondervermögen, ist Gerichtsstand der Sitz des Anbieters. + +(3) Der Anbieter ist nicht bereit und nicht verpflichtet, an Streitbeilegungsverfahren vor einer Verbraucherschlichtungsstelle teilzunehmen (§ 36 VSBG). + +**Stand:** 3. Juli 2026 · **Version:** 0.6 +Diese AGB gelten für Buchungen über pressekonto (pressekonto.com) mit Veröffentlichung auf presseecho.de und businessportal24.com. + +--- + +## D. Boost-Platzierung + +### D.1 Preisseite: Angebot + +Quelle: [presseecho.de/de/preise](https://presseecho.de/de/preise). pressekonto.com/de/preise leitet dorthin weiter, businessportal24.com/de/preise ist wortgleich. + +> **Boost-Platzierung** +> Prominente Platzierung Ihrer Meldung — als Startseiten-Boost (Startseite und Branchenseite) oder als günstigerer Kategorie-Boost (nur Branchenseite). + +| Stufe | 7 Tage | 14 Tage | 30 Tage | +|---|---|---|---| +| Startseiten-Boost | 12 Credits | 20 Credits | 35 Credits | +| Kategorie-Boost (nur Branchenseite) | 6 Credits | 10 Credits | 18 Credits | + +### D.2 Preisseite: Note zur Leistungsbeschreibung (Wortlaut) + +> **Boost — was Sie bekommen und was nicht** +> Geschuldet ist die Platzierung während der gebuchten Laufzeit — beim Startseiten-Boost auf Startseite und Kategorieseite, beim Kategorie-Boost auf der Kategorieseite der jeweiligen Rubrik. Die Zahl gleichzeitiger Boosts je Seite ist begrenzt; sind alle Plätze belegt, ist eine neue Buchung erst möglich, sobald ein Platz frei wird — verkauft wird also nur, was auch sichtbar ist. Eine bestimmte Reichweite oder Zugriffszahl versprechen wir nicht — das wäre unseriös. Buchbar nur für Mitteilungen mit Prüfergebnis Grün. Ist das Portal während eines aktiven Boosts aus von uns zu vertretenden Gründen länger als 60 Minuten am Stück nicht erreichbar, verlängert sich die Boost-Laufzeit entsprechend. + +Zum Vergleich: In den AGB steht der Boost in § 6 Abs. 2 (siehe C). Die AGB nennen nur den Startseiten-Boost (Startseite und Kategorieseite). Den Kategorie-Boost, der nur auf der Branchenseite erscheint, erwähnen sie nicht. + +### D.3 Kennzeichnung auf Startseite und Branchenseite + +> **Hinweis 13.10.2026:** Dieser Abschnitt beschreibt den Live-Stand vom 12.10.2026. Die Fassung, die geprüft werden soll („Gebuchte Platzierung“ mit Erklärung), steht in der Versandfassung, Frage 7, und in den Screenshots der Anlage 7. + +- **Label:** **„Top-Platzierung“**, in der englischen Fassung „Featured“. +- **Wo es erscheint:** an jeder Mitteilung, die einen laufenden Boost hat. Den Startseiten-Boost gibt es höchstens 5-mal gleichzeitig, den Kategorie-Boost höchstens 3-mal je Branche. + - **Startseite:** im oberen Bereich mit dem großen Aufmacher und der Liste daneben. Beim Aufmacher steht das Label als Schild auf dem Bild, in der Liste als kleiner Rahmen hinter der Überschrift. + - **Branchenseite:** beim Aufmacher als Schild auf dem Bild, in der Liste der oberen Meldungen als kleiner Rahmen hinter der Überschrift. +- **Darstellung:** Großbuchstaben in kleiner Schrift (rund 10 px). + - Auf dem Bild: weiß auf der Markenfarbe. + - In der Liste: in der Markenfarbe mit dünnem Rahmen. +- **Aufmacher:** Der Aufmacher trägt immer das Schild „Top-Meldung“, ob gebucht oder nicht. Ist er gebucht, steht „Top-Platzierung“ daneben. +- **Was es sonst nicht gibt:** keinen Hinweis wie „Anzeige“ oder „Gesponsert“ und keine Erklärung, was „Top-Platzierung“ bedeutet (weder als Tooltip noch als Link). +- **Screenshot:** Zum Zeitpunkt des Abrufs lief auf keinem Portal ein Boost, das Label war live also nicht zu sehen. Ein Screenshot ginge nur mit einem Test-Boost auf Live. + +**Frage an den Anwalt** (Anwaltspaket, Abschnitt „Boost-Platzierung“): Reicht „Top-Platzierung“ als Kennzeichnung einer bezahlten Platzierung aus, zum Beispiel nach § 5a Abs. 4 UWG oder § 22 MStV? Oder braucht es einen eindeutigen Hinweis wie „Anzeige“ oder „Gesponsert“? diff --git a/dev/rechtliches/anwaltspaket-datenschutz-2026-10-12.md b/dev/rechtliches/anwaltspaket-datenschutz-2026-10-12.md new file mode 100644 index 00000000..1a79e288 --- /dev/null +++ b/dev/rechtliches/anwaltspaket-datenschutz-2026-10-12.md @@ -0,0 +1,322 @@ +# Anwaltspaket Datenschutz und Rechtstexte — Versandfassung + +**Stand:** 13.10.2026 · ersetzt den Entwurf vom 09.10.2026; berücksichtigt die Codeabgleiche vom 12. und 13.10.2026 (Ist und Ziel getrennt) +**Verantwortlicher / Anbieter:** adametz.media, Inhaber Kevin Adametz, In der Lake 4, 33739 Bielefeld, info@pressekonto.com +**Angebot:** pressekonto.com (Kundenbereich, „Hub“), presseecho.de und businessportal24.com (Portale) +**Bezug:** Datenschutzerklärung (DSE) 0.3 vom 03.07.2026 mit Ergänzungen 5a (21.09.) und 6a (09.10.); AGB 0.6; Veröffentlichungsrichtlinien 0.2; Release v1.8.0 + +Einordnungen in diesem Dokument sind technische Beschreibungen und Vorschläge des Betreibers, keine Rechtsberatung. Jede Frage nennt unseren Standpunkt („Default“), damit Sie bestätigen oder widersprechen können. Hinter jeder Frage steht ein Antwortfeld. + +--- + +## 1. Anliegen + +Seit dem Relaunch im Juli 2026 sind Verarbeitungen hinzugekommen, die die DSE noch nicht oder nur pauschal beschreibt. Einige laufen produktiv. Wir bitten um: + +1. Prüfung und Freigabe der Textentwürfe für die DSE 0.4 (Abschnitt 4), +2. Antwort auf die Fragen in Abschnitt 5, +3. Prüfung des Pakets Bildrechte (AGB 0.7 mit § 8a und § 9, Bestätigungstext, Zustimmungsgate, Beweisarchiv mit Interessenabwägung) in derselben Sitzung, +4. Antwort auf vier Fragen zur Bearbeitung von Lösch- und Änderungsanfragen (Abschnitt 5, Nr. 12), +5. Entwurf oder Prüfung eines Syndikationsvertrags nach der Gliederung in Anlage 5. + +Drei Verarbeitungen, die im Entwurf vom 09.10. enthalten waren, haben wir aus diesem Paket herausgenommen und als spätere Aktivierungen markiert: Webanalyse im Kundenbereich mit Nutzerkennung, KI-Vorabprüfung von Bildern, Newsletter. Sie sind ausgeschaltet und bleiben es, bis sie eigenständig geprüft sind. Die dazugehörigen Fragen stehen am Ende von Abschnitt 5 als „später“. + +**Aufbau der DSE:** Eine Datei mit zwei Ausprägungen. Auf dem Hub erscheinen zusätzlich Kundenkonto, Anmeldelink und Stripe (Abschnitte 7 bis 9), auf den Portalen stattdessen Änderungslinks, Medienprivileg und Newsroom. Die Nummerierung unterscheidet sich ab Abschnitt 7; die Entwürfe in Abschnitt 4 nennen deshalb die Ausprägung und verweisen auf Abschnittstitel, nicht auf Nummern. Die Live-Texte beider Ausprägungen liegen als Anlage 3 bei. + +--- + +## 2. Übersicht der Verarbeitungen + +„Aktiv“ heißt: läuft produktiv. „Ziel“ heißt: beschlossen, im Code vorhanden oder beauftragt, produktiver Nachweis steht aus; die DSE 0.4 wird erst veröffentlicht, wenn die Zielfristen tatsächlich laufen. + +| Nr. | Verarbeitung | Status | Rechtsgrundlage (Default) | Frist (beschlossen) | +|---|---|---|---|---| +| D1 | Bild-Originale, Rechtebestätigung, Beweisarchiv | aktiv seit 28.09.2026 | Art. 6 Abs. 1 lit. f; Art. 9 Abs. 2 lit. f für sensible Bildinhalte; Art. 17 Abs. 3 lit. e im Einzelfall | Archiv drei Jahre nach Jahresende der Entfernung; Zugriffsprotokoll 395 Tage (Ziel; heute ohne Löschfrist) | +| D2 | Fehlerprotokoll (GlitchTip, selbst gehostet) | aktiv seit 05.10.2026 | lit. f; browserseitig § 25 Abs. 2 Nr. 2 TDDDG | 90 Tage | +| D3 | Anmeldesicherheit | aktiv, zuletzt erweitert 08.10.2026 | lit. b und f | Anmeldeereignisse 90 Tage; letzte Anmelde-IP 90 Tage nach letzter Anmeldung (Ziel) | +| D4 | E-Mail-Zustellung: Rückläufer, Sperrliste, Abmeldung | aktiv seit 15.09.2026 | lit. f; bei Abmeldungen zusätzlich lit. c i. V. m. Art. 21 Abs. 3 | Rohmails 90 Tage (Ziel), Datensätze 395 Tage, Sperrliste zweckgebunden | +| D5 | Aktivitätsverlauf und API-Zugriffsprotokoll | aktiv seit Juli 2026 | lit. f, API zusätzlich lit. b | 90 / 395 Tage je Ereignisart (Ziel), API 90 Tage | +| D6 | Cloudflare Turnstile | aktiv seit 09.10.2026 | lit. f; § 25 Abs. 2 Nr. 2 TDDDG; Art. 45 (DPF) | keine eigene Speicherung | +| D9 | IP-Adressen in Vorgangsdaten | aktiv seit Juli 2026, Frist Ziel | lit. f | IP nach 90 Tagen entfernt; Vorgang nach eigener Frist | +| D7 | Webanalyse im Kundenbereich mit Nutzerkennung | **ausgeschaltet, zurückgestellt** | — | — | +| D8 | KI-Vorabprüfung von Bildern | **ausgeschaltet, zurückgestellt** | — | — | +| D10 | Newsletter an Kontoinhaber | **Versand gesperrt, zurückgestellt** | — | — | + +--- + +## 3. Sachverhalt je Verarbeitung + +### D1 — Bild-Originale, Rechtebestätigung, Beweisarchiv + +Ausführlich in Anlage 1 (Decision-Update Bildrechte, Abschnitte 3 und 4) und Anlage 2 (Interessenabwägung). Gegenüber dem Decision-Update gilt der folgende, mit Code und Abwägung abgeglichene Stand: + +**Rechtebestätigung je Bild-Upload:** Zeitpunkt, bestätigter Wortlaut mit Fassung, AGB-Fassung, Konto bzw. API-Zugang, Firma, Rolle des Erklärenden (Kontoinhaber oder Partner-API; Ziel, heute nur Kanal: Formular, API, Magic-Link), Übermittlungsweg, SHA-256 der Datei, Angaben zu Bildnachweis und KI, mit geheimem Schlüssel gebildeter Prüfwert der IP-Adresse (HMAC), Browserkennung auf 250 Zeichen gekürzt. + +**Archivdatensatz bei Entfernung, Ersetzung oder Änderung eines veröffentlichten Inhalts:** zuletzt veröffentlichter Stand einschließlich der genannten Pressekontakte (Name, E-Mail, Telefon); Einreicher (Konto, Name, E-Mail, Firma); zu Bildern: Originaldatei mit Metadaten, veröffentlichte Fassung mit Nachweis und Kennzeichnung, Herkunftsauswertung, Rechtebestätigung; Zeitpunkte von Veröffentlichung und Entfernung; Grund als Kategorie; bei Änderungen vorheriger und neuer Stand; Bezug zum zugrunde liegenden Melde- oder Löschverfahren. + +**Ist und Ziel beim Archivdatensatz:** Heute schreibt das Archiv aus dem Meldevorgang auch die E-Mail-Adresse des Antragstellers mit, und Firma und Einreicher werden zum Zeitpunkt der Archivierung aus dem Konto gelesen, nicht zum Zeitpunkt der Einreichung. Beschlossenes Ziel: Das Archiv erhält nur die Vorgangsnummer, die Antragstellerdaten bleiben im Meldevorgang (drei Jahre); für neue Einreichungen wird ein unveränderlicher Nachweis der Einreicherdaten zum Einreichungszeitpunkt erzeugt; Altbestand wird als „bei Archivierung erfasst“ gekennzeichnet. Bereits versiegelte Archivpakete mit Antragsteller-E-Mails werden nicht stillschweigend verändert; dafür wird ein Inventar erstellt und eine Migrationsentscheidung getroffen (Frage 3). + +**Wer die Rechte bestätigt:** Es bestätigt, wer vertraglich gebunden ist; der Betreiber bestätigt nie. Hub-Formular und API mit eigenem Konto: der Kontoinhaber. API über Verteiler oder Agentur: der Partner (§ 8a Abs. 1 Satz 2, Syndikationsvertrag). Lädt der Betreiber ein Bild für einen Kunden hoch, wird es erst nach Bestätigung des Kontoinhabers per Magic-Link veröffentlicht. Für syndizierte Meldungen ohne Konto gibt es keinen Betreiber-Upload; ein Bild-Upload im Self-Service setzt ein Kundenkonto voraus, mit dem der Hochladende AGB und Unternehmerbestätigung annimmt und gebunden ist. Kontaktdaten können Pressekontakte weiterhin ohne Konto ändern. Das Bestätigungsprotokoll speichert heute Konto, Tokenkennung und Kanal (Formular, API, Magic-Link); die Rolle des Erklärenden als eigenes Feld ist Ziel. + +**Zugriff:** Originaldateien aktiver Bilder: berechtigte Redaktion. Archivierte Inhalte: Administratoren mit Compliance-Berechtigung. Jeder Abruf archivierter Inhalte und jede Änderung einer Aufbewahrungssperre wird mit Zweck protokolliert (Administrator mit Name und E-Mail-Adresse, Zeitpunkt, Art des Zugriffs, Zweck). Heute ist das Protokoll unveränderlich und wird nicht gelöscht; Ziel: Löschung nach 395 Tagen. + +**Fristen:** Drei Jahre nach Ende des Jahres der Entfernung, für alle Ereignistypen (Begründung je Typ in Anlage 2). Aufbewahrungssperre (Legal Hold) nur mit Pflichtvermerk und Prüfdatum (spätestens 90 Tage); nach Aufhebung kein Neustart der Frist, sondern Löschung zum regulären Zeitpunkt oder ein neues, begründetes Enddatum (Ziel; heute setzt der Code die Frist nach Aufhebung neu). Eine Einschränkung der Verarbeitung nach Art. 18 wird getrennt von der Sperre gespeichert und sperrt den normalen Abruf (Ziel). Nach Löschung bleiben nur Kennung, Objektschlüssel, Ereignisart, Zeitpunkte und Prüfsumme als Löschbeleg (Ziel; heute bleiben auch Akteur, Vermerke und Vorgangsverweise). Sicherungen 14 Tage; nach einer Wiederherstellung werden gelöschte Einträge anhand eines getrennt gesicherten Löschstands erneut entfernt (Verfahren vorhanden, Übung vor Veröffentlichung der 0.4). + +**Nie veröffentlichte Inhalte:** Vom Kunden gelöschte oder ersetzte Bilder und Entwürfe sofort gelöscht. Unbearbeitete Entwürfe 180 Tage nach letzter Änderung vollständig gelöscht (Ziel; heute werden nur die Bilder gelöscht und der Datensatz archiviert). Abgelehnte, nie veröffentlichte Einreichungen: Text und Bilder nach 180 Tagen gelöscht, ein minimaler Ablehnungsnachweis (Status, Zeitpunkt, Kategorie, Konto) drei Jahre nach Jahresende (Ziel). Bearbeitungsstände von Korrekturen 30 Tage. + +### D2 — Fehlerprotokoll (GlitchTip) + +Tritt im Server oder im Browser ein technischer Fehler auf, geht ein Fehlerbericht an eine selbst gehostete GlitchTip-Instanz (errors.adametz.media) auf einem Server der Hetzner Online GmbH im Rechenzentrum Falkenstein. + +- **Inhalt:** Fehlermeldung und Programmstelle, aufgerufene Adresse und Herkunftsseite (Abfrageparameter bis auf eine Freigabeliste entfernt, Token und Signaturen ersetzt), Browser und Betriebssystem, Softwarestand, bei angemeldeten Nutzern nur die interne Nutzer-ID. +- **Nicht in den Bericht aufgenommen:** IP-Adresse, Cookies, Formulareingaben, Inhalte von Anfragen; E-Mail-Adressen in Fehlertexten werden ersetzt. Eine vollständige Freiheit von personenbezogenen Angaben in technischen Freitexten kann nicht garantiert werden; die Bereinigung wird vor 0.4 nachgeschärft (freigegebene Abfrageparameter, keine Objektinhalte als Fehlertext). +- **Browser:** Die Fehlerbibliothek lädt erst beim ersten Fehler, ohne Cookies, ohne Sitzungsverfolgung; der Bericht geht direkt an den Fehlerserver. Dessen Webserver sieht dabei die Verbindungsdaten des Browsers (IP); diese Logs werden wie alle Server-Logs nach 14 Tagen gelöscht. +- **Frist:** 90 Tage (Einstellung der Instanz, wird belegt). + +### D3 — Anmeldesicherheit + +- **Fehlgeschlagene Anmeldungen mit unbekannter Adresse:** Tageszähler je Einstieg und Quelle; Quelle als gekürzter HMAC der IP-Adresse; 90 Tage. +- **Fehlgeschlagene Anmeldungen und Sperren bekannter Konten:** Eintrag im Aktivitätsverlauf mit gekürztem IP-HMAC; 90 Tage (Ziel; heute 395). +- **Erfolgreiche Anmeldungen:** Eintrag mit Anmeldeweg, ohne IP; 90 Tage (Ziel). +- **Begrenzung von Anmeldeversuchen:** Zähler je IP-Adresse (15 Minuten, Sperre ab 20 Versuchen) und je Kombination aus E-Mail-Adresse und IP-Adresse (1 Minute, höchstens 5) in einem kurzlebigen Zwischenspeicher (Redis); Einträge verfallen automatisch. +- **Letzte Anmeldung:** Zeitpunkt und IP-Adresse der letzten Anmeldung am Konto, für den Kontoinhaber auf der Sicherheitsseite sichtbar; bei jeder Anmeldung überschrieben; Löschung 90 Tage nach der letzten Anmeldung (Ziel). +- **Zwei-Faktor-Authentifizierung:** verschlüsseltes Geheimnis und Wiederherstellungscodes am Konto. +- **Passkeys:** öffentlicher Schlüssel, technische Kennungen des Authentifikators, vom Nutzer vergebener Name, Zeitpunkt der letzten Nutzung. +- **Anmeldung mit Google:** Google übermittelt Name, E-Mail-Adresse und Google-Kennung; gespeichert wird die Kennung. Google Ireland Ltd.; Übermittlung an Google LLC (USA) möglich, DPF. +- **Abmeldung anderer Geräte:** nur ein Zeitstempel am Konto. +- **Administratoren:** Bestand laut Datenbank (Stand 07.10.2026): ein aktives Betriebskonto mit Admin-Rolle und Passkey, ein aktives Altkonto mit Admin-Rolle (letzte Anmeldung 2012), ein aktives Altkonto mit Super-Admin-Merker und importierten, nie benutzten API-Schlüsseln, drei gesperrte Altkonten mit Admin-Rolle, keine Editoren. Die Altkonten verlieren alle Rechte, Schlüssel und Sitzungen und werden gesperrt oder gelöscht. Danach hat nur das Betriebskonto Admin-Zugriff, mit nicht öffentlicher Login-Adresse. Zweiter Faktor für Admins ist Pflicht. Datierte Liste vorher und nachher: Anlage 7 (BN-02) [Datum und Ergebnis nach Ausführung eintragen]. + +### D4 — E-Mail-Zustellung + +- **Rückläufer:** Unzustellbarkeitsmeldungen werden aus einem Postfach bei ALL-INKL abgeholt und ausgewertet: Empfängeradresse, Art und Text der Meldung, interne Referenz der auslösenden Mail. Datensätze 395 Tage. Die abgeholten Rohmails bleiben heute in Postfachordnern; Ziel: Löschung nach 90 Tagen in allen Ordnern. +- **Sperrliste:** Adressen, die dauerhaft unzustellbar sind oder sich abgemeldet haben, erhalten keine Benachrichtigungen mehr. Selbst angeforderte Anmeldelinks sind von der Abmeldesperre ausgenommen; Hard-Bounce-Sperren bleiben immer wirksam. Bestätigungslinks aus dem Meldeverfahren sind heute nicht ausgenommen (Ziel: ausdrücklich angeforderte Bestätigungen als eigene, getestete Versandregel zulassen). Entsperrung auf Anfrage. Die Liste ist unbefristet, solange sie ihren Zweck erfüllt. +- **Link-Datensätze:** Anmelde- und Änderungslinks sind 15 Minuten gültig, Meldebestätigungslinks 72 Stunden; die Datensätze (einschließlich IP) werden im täglichen Lauf gelöscht, sobald Verbrauch oder Ablauf mehr als 30 Tage zurückliegen. +- **Abmeldung:** Jede Benachrichtigung enthält einen Abmeldelink (auch Ein-Klick-Abmeldung im Mailprogramm). Empfänger ohne Konto (Pressekontakte) werden als Eintrag in der Sperrliste geführt. + +### D5 — Aktivitätsverlauf und API-Zugriffsprotokoll + +- **Aktivitätsverlauf** (nur Administratoren): Registrierungen, Anmeldungen mit Anmeldeweg, Statuswechsel von Mitteilungen, eingehende Anfragen, Mailversand mit Empfängeradresse und Betreff (auch an Pressekontakte ohne Konto; rund zwei Drittel der Mail-Einträge), Administratorhandlungen. Namen und E-Mail-Adressen im Klartext. Zweck: Nachvollziehbarkeit, Missbrauchserkennung, Support. Fristen je Ereignisart: Anmeldeereignisse 90 Tage, übrige 395 Tage (Ziel; heute 395 einheitlich, Löschlauf seit v1.8 vorhanden). +- **API-Zugriffsprotokoll:** je Anfrage Konto, Kennung des Token-Datensatzes (nicht der Schlüssel), Methode, Pfad, Statuscode, Dauer, IP-Adresse, Programmkennung. Zweck: Betrieb, Missbrauchserkennung, Nutzungsnachweis. 90 Tage (Löschlauf vorhanden). + +### D6 — Cloudflare Turnstile + +Im Kontaktformular und bei der Registrierung; Ausweitung auf Melde-, Widerrufs- und Kündigungsformular geplant. Ergänzend zum Live-Text 6a: Unser Server übermittelt bei der Prüfung die IP-Adresse des Nutzers an Cloudflare (`remoteip`). Ist Cloudflare nicht erreichbar, wird die Eingabe angenommen und intern markiert. Cloudflare-DPA über die Standardbedingungen; DPF-Zertifizierung von Cloudflare, Inc. [Prüfdatum eintragen]. + +### D9 — IP-Adressen in Vorgangsdaten + +Bei Kontaktanfragen, Meldungen, Widerrufen, Kündigungen und Buchungsbestätigungen wird die IP-Adresse des Absenders im Klartext gespeichert, bisher ohne Frist. Zweck: Missbrauchsabwehr und Nachweis des Eingangs. Ziel: IP-Adresse nach 90 Tagen entfernen (eigener Löschlauf inklusive Altbestand, mit dokumentierter Einzelfallverlängerung bei einem konkreten Vorfall); der Vorgang selbst folgt seiner fachlichen Frist. Der DSE-Absatz wird erst veröffentlicht, wenn der Lauf produktiv ist. + +### Zurückgestellt: D7, D8, D10 + +- **D7 Webanalyse im Kundenbereich:** Umami läuft cookielos auf den öffentlichen Seiten. Eine Ausweitung auf den Kundenbereich mit pseudonymer Nutzerkennung ist ausgeschaltet. Aktivierungsbedingungen: Kennung als HMAC, Widerspruchsschalter im Konto, eigener DSE-Absatz. +- **D8 KI-Vorabprüfung von Bildern:** Code vorhanden, Funktion ausgeschaltet. Vorgesehen: Bild verkleinert (1024 px), ohne Metadaten und ohne Kontobezug an OpenAI, Sichtung auf offensichtliche Probleme (Wasserzeichen von Bildagenturen, unzulässige Inhalte, Person erkennbar ja/nein ohne Identifizierung). OpenAI Ireland Ltd., DPA, Zero Data Retention eingerichtet. +- **D10 Newsletter:** Kampagnenmodul vorhanden, Versand technisch gesperrt. Das Modul wurde im Juli 2026 einmalig für die beiden Relaunch-Mails an Bestandskonten genutzt (Abschnitt 6); seitdem ist der Versand gesperrt. Vorgesehen: nur mit ausdrücklicher Einwilligung (Schalter im Konto, Standard aus, Bestätigung per E-Mail, Protokoll mit Textfassung und Zeitpunkt). Kein Rückgriff auf § 7 Abs. 3 UWG für die 66.368 übernommenen Altkonten (über 99 Prozent Gratiskonten, Nachweis einer Belehrung bei Erhebung nicht führbar). + +### Automatisierte Inhaltsprüfung (bestehender Abschnitt 10/8, Korrektur) + +Die DSE nennt OpenAI, Google Gemini und Anthropic Claude. Angebunden ist nur OpenAI; Gemini und Anthropic werden nicht genutzt. Fassung 0.4 nennt nur OpenAI. Der Betreiber gibt OpenAI Ireland Ltd. als Vertragspartner und eingerichtete Zero Data Retention an. Ein fehlender `store`-Parameter belegt das nicht; Geltungsbereich (Endpunkte, Modelle, Ausnahmen) und Datenresidenz werden vor Übernahme einer Speicherzusage in die DSE durch Organisations- und Projekteinstellungen sowie das DPA belegt (Betriebsnachweis). + +--- + +## 4. Textentwürfe für die DSE 0.4 + +Stil und Aufbau wie die bestehende DSE. Einordnung: „Hub“ nur auf pressekonto.com, „Portale“ nur auf presseecho.de und businessportal24.com, sonst beide. Platzhalter in eckigen Klammern. Textstellen, die eine noch nicht produktive Frist versprechen, sind mit *(Ziel)* markiert und werden erst mit dem Löschlauf veröffentlicht. + +### 3a. Fehlerprotokoll (beide, neu nach „Hosting und Server-Logs“) + +> Um technische Fehler schnell zu erkennen und zu beheben, übermitteln unsere Server und, nur wenn in Ihrem Browser ein Fehler auftritt, Ihr Browser einen Fehlerbericht an eine von uns selbst betriebene Fehlerdatenbank (GlitchTip) auf einem Server der Hetzner Online GmbH, Industriestr. 25, 91710 Gunzenhausen, im Rechenzentrum Falkenstein (Deutschland). +> +> Dabei werden insbesondere verarbeitet: +> - Fehlermeldung, betroffene Programmstelle und Zeitpunkt, +> - die aufgerufene Seite und die Herkunftsseite, bereinigt um Zugangs- und Bestätigungscodes, +> - Browser, Betriebssystem und Softwarestand, +> - wenn Sie angemeldet sind, Ihre interne Kundennummer. +> +> IP-Adressen, Cookies, Formulareingaben und Inhalte von Anfragen werden nicht in den Fehlerbericht aufgenommen; E-Mail-Adressen in Fehlertexten werden vor der Übermittlung ersetzt. Technische Freitexte eines Fehlers können im Einzelfall weitere Angaben enthalten; wir werten Fehlerberichte ausschließlich zur Fehlerbehebung aus. Im Browser wird die Fehlerkomponente erst beim Auftreten eines Fehlers geladen und setzt keine Cookies. Übermittelt Ihr Browser einen Bericht, sieht der Fehlerserver wie jeder Webserver die Verbindungsdaten Ihres Browsers; dafür gelten die Fristen aus dem Abschnitt „Hosting und Server-Logs“. +> +> Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO; unser berechtigtes Interesse liegt im sicheren und fehlerfreien Betrieb unseres Angebots. Soweit dabei Informationen aus Ihrem Endgerät ausgelesen werden, ist Rechtsgrundlage § 25 Abs. 2 Nr. 2 TDDDG. Fehlerberichte werden nach 90 Tagen gelöscht. + +### 7a. Anmeldung und Kontosicherheit (Hub, neu nach „Kundenkonto und Registrierung“) + +> Zum Schutz Ihres Kontos verarbeiten wir bei der Anmeldung folgende Daten: +> - Zeitpunkt und IP-Adresse Ihrer letzten Anmeldung; beides sehen Sie auf der Seite „Konto-Sicherheit“, damit Ihnen fremde Anmeldungen auffallen. Die Angabe wird bei jeder Anmeldung überschrieben und 90 Tage nach Ihrer letzten Anmeldung gelöscht *(Ziel)*. +> - Ihre Anmeldungen mit Zeitpunkt und Anmeldeweg (Passwort, Magic-Link, Google, Passkey) sowie fehlgeschlagene Anmeldeversuche und Sperren Ihres Kontos in unserem internen Aktivitätsverlauf. Bei fehlgeschlagenen Versuchen wird die IP-Adresse nur als gekürzter, mit einem geheimen Schlüssel gebildeter Prüfwert gespeichert. Diese Einträge löschen wir nach 90 Tagen *(Ziel)*. +> - Anmeldeversuche mit Adressen, zu denen kein Konto besteht, zählen wir nur als Tagessumme je Quelle (als gekürzter Prüfwert der IP-Adresse), gelöscht nach 90 Tagen. +> - Zur Begrenzung von Anmeldeversuchen zählen wir Fehlversuche je IP-Adresse (15 Minuten) und je Kombination aus E-Mail-Adresse und IP-Adresse (1 Minute) in einem kurzlebigen Zwischenspeicher; die Einträge verfallen danach automatisch. +> +> Wenn Sie die Zwei-Faktor-Authentifizierung einrichten, speichern wir das Geheimnis Ihrer Authenticator-App und Ihre Wiederherstellungscodes verschlüsselt. Wenn Sie einen Passkey anlegen, speichern wir dessen öffentlichen Schlüssel, technische Kennungen des Authentifikators, den von Ihnen vergebenen Namen und den Zeitpunkt der letzten Nutzung; Ihr privater Schlüssel und biometrische Merkmale verlassen Ihr Gerät nicht. Über Hinzufügen und Entfernen eines Passkeys informieren wir Sie per E-Mail. +> +> Rechtsgrundlage ist Art. 6 Abs. 1 lit. b DSGVO (Bereitstellung eines sicheren Kundenkontos) und Art. 6 Abs. 1 lit. f DSGVO (Schutz vor unbefugten Zugriffen). Zwei-Faktor-Daten und Passkeys löschen wir, wenn Sie sie entfernen, spätestens mit Ihrem Konto. +> +> **Anmeldung mit Google.** Wenn Sie „Mit Google anmelden“ wählen, übermittelt uns Google Ireland Limited, Gordon House, Barrow Street, Dublin 4, Irland, Ihren Namen, Ihre E-Mail-Adresse und eine Google-Kennung; die Kennung speichern wir an Ihrem Konto, um Sie bei der nächsten Anmeldung zuzuordnen. Für die Anmeldung bei Google gilt dessen Datenschutzerklärung. Eine Übermittlung an Google LLC in den USA ist möglich; Google LLC ist unter dem EU-US Data Privacy Framework zertifiziert (Art. 45 DSGVO). Rechtsgrundlage ist Art. 6 Abs. 1 lit. b DSGVO. + +### 7b. Aktivitätsverlauf und Programmierschnittstelle (Hub, neu) + +> Für die Nachvollziehbarkeit von Vorgängen, die Missbrauchserkennung und den Support führen wir einen internen Aktivitätsverlauf, auf den nur Administratoren Zugriff haben. Er enthält insbesondere Registrierungen, Statuswechsel von Pressemitteilungen, eingegangene Anfragen, versandte Benachrichtigungen mit Empfängeradresse und Betreff sowie Handlungen von Administratoren. Diese Einträge löschen wir nach 395 Tagen; Anmeldeereignisse nach 90 Tagen (Abschnitt „Anmeldung und Kontosicherheit“). +> +> Wenn Sie unsere Programmierschnittstelle (API) nutzen, protokollieren wir je Anfrage Ihr Konto und die Kennung des verwendeten Zugangsschlüssels (nicht den Schlüssel selbst), die aufgerufene Funktion, das Ergebnis, die Dauer sowie IP-Adresse und Programmkennung. Das Protokoll dient dem Betrieb, der Missbrauchserkennung und dem Nachweis der Nutzung und wird nach 90 Tagen gelöscht. +> +> Rechtsgrundlage ist jeweils Art. 6 Abs. 1 lit. f DSGVO; bei der API-Nutzung zusätzlich Art. 6 Abs. 1 lit. b DSGVO. + +### 12a. Zustellbarkeit und Abmeldung (beide, Ergänzung zu „E-Mail-Versand“) + +> Erhalten wir eine Meldung, dass eine E-Mail nicht zugestellt werden konnte, werten wir sie automatisch aus und speichern die Empfängeradresse, die Art und den Text der Meldung sowie eine interne Referenz der betroffenen E-Mail. Adressen, die dauerhaft nicht erreichbar sind, nehmen wir in eine Sperrliste auf. +> +> Jede Benachrichtigung enthält einen Link zur Abmeldung; Ihr Mailprogramm kann die Abmeldung auch direkt auslösen. Haben Sie kein Kundenkonto, zum Beispiel als in einer Pressemitteilung genannter Pressekontakt, speichern wir Ihre Abmeldung in derselben Sperrliste. An gesperrte Adressen senden wir keine Benachrichtigungen mehr; von Ihnen selbst angeforderte Anmeldelinks bleiben möglich. Eine Entsperrung erfolgt auf Ihre Anfrage an info@pressekonto.com. *(Ziel: „Anmeldelinks und von Ihnen angeforderte Bestätigungslinks“, sobald die Versandregel umgesetzt ist.)* +> +> Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO; unser berechtigtes Interesse liegt in der zuverlässigen Zustellung und darin, keine unerwünschten oder unzustellbaren E-Mails zu versenden. Bei Abmeldungen ist die Speicherung zudem erforderlich, um Ihren Widerspruch dauerhaft zu beachten (Art. 6 Abs. 1 lit. c in Verbindung mit Art. 21 Abs. 3 DSGVO). Die abgerufenen Zustellmeldungen löschen wir aus dem Postfach nach 90 Tagen *(Ziel)*, die ausgewerteten Datensätze nach 395 Tagen; Einträge der Sperrliste bleiben bestehen, solange sie für diesen Zweck erforderlich sind. + +### 6. Kontaktaufnahme (beide, Ergänzung) *(Ziel)* + +> Zum Schutz vor Missbrauch und zum Nachweis des Eingangs speichern wir bei Kontaktanfragen, Meldungen, Widerrufen, Kündigungen und Buchungsbestätigungen über unsere Formulare die IP-Adresse, von der die Anfrage gesendet wurde, und entfernen sie nach 90 Tagen. Kontaktanfragen löschen wir 180 Tage nach Abschluss; Anfragen mit Vertrags- oder Rechtsbezug speichern wir, solange es zur Bearbeitung und Dokumentation des Vorgangs erforderlich ist (Abschnitt „Speicherdauer“). + +### 6a. Turnstile (beide, drei Ergänzungen) + +> … setzen wir im Kontaktformular, bei der Registrierung und in weiteren Formularen, die Missbrauch auslösen können (zum Beispiel Melde-, Widerrufs- und Kündigungsformular), den Dienst Turnstile ein. … +> +> Bei der Prüfung übermittelt auch unser Server die IP-Adresse, von der das Formular gesendet wurde, an Cloudflare, damit das Ergebnis der Prüfung dieser Anfrage zugeordnet werden kann. Ist der Dienst nicht erreichbar, nehmen wir die Eingabe an und prüfen sie intern auf Missbrauch. + +### 10 (Hub) / 8 (Portale). Automatisierte Inhaltsprüfung (Änderung der Anbieterliste) + +> Für die automatisierte Analyse nutzen wir die Programmierschnittstelle von OpenAI Ireland Ltd., 1st Floor, The Liffey Trust Centre, 117–126 Sheriff Street Upper, Dublin 1, Irland. Mit OpenAI besteht ein Vertrag zur Auftragsverarbeitung. [Nur nach Nachweis des Geltungsbereichs:] Die Anbindung ist so eingerichtet, dass OpenAI die übermittelten Inhalte nicht speichert und nicht zum Training von Modellen verwendet (Zero Data Retention). [Datenresidenz EU aktiv: „Die Verarbeitung erfolgt in der EU.“ / sonst: „Eine Verarbeitung in den USA ist möglich; sie erfolgt auf Grundlage von EU-Standardvertragsklauseln.“] Setzen wir künftig weitere Anbieter ein, nennen wir sie hier. + +### 7 (Portale). Änderungslinks (Änderung) + +> … Die konkrete Gültigkeitsdauer wird systemseitig festgelegt und beträgt derzeit 15 Minuten für Zugangslinks zur Verwaltung einer Mitteilung oder eines Newsrooms und 72 Stunden für den Bestätigungslink, den Sie nach einer Meldung über „Mitteilung melden“ erhalten. + +### Bilder in Pressemitteilungen (beide, neu nach „Automatisierte Inhaltsprüfung“) + +> **Bilder in Pressemitteilungen: Originaldateien, Herkunftsprüfung und Rechtebestätigung** +> +> Wer ein Bild zu einer Pressemitteilung hochlädt, bestätigt dabei, zur Veröffentlichung berechtigt zu sein, und macht Angaben zum Bildnachweis und zum Einsatz von KI. Zu jedem veröffentlichten Bild speichern wir: +> +> - die hochgeladene Originaldatei einschließlich der darin enthaltenen Metadaten (zum Beispiel Kameradaten, Urheberangaben, Herkunftsdaten wie Content Credentials), +> - die veröffentlichte Fassung des Bildes mit dem angezeigten Bildnachweis und der angezeigten KI-Kennzeichnung, +> - das Ergebnis unserer automatischen Auswertung der Herkunftsdaten und die daraus von uns gesetzte Kennzeichnung, getrennt von der Angabe des Hochladenden, +> - die Bestätigung des Hochladenden mit Zeitpunkt, der Fassung des bestätigten Textes und der zugrunde liegenden AGB, dem angemeldeten Konto beziehungsweise dem verwendeten API-Zugang, der Firma, für die hochgeladen wurde, einer pseudonymisierten Ableitung der IP-Adresse und der auf 250 Zeichen gekürzten Kennung des verwendeten Browsers. +> +> Die IP-Ableitung wird mit einem geheimen Schlüssel gebildet. Sie ist pseudonymisiert, nicht anonym: Mit dem Schlüssel könnten wir prüfen, ob eine bestimmte Adresse zu ihr passt; ohne den Schlüssel ist das nicht möglich. +> +> Zweck dieser Speicherung ist der Nachweis, welche Datei mit welchen Angaben eingereicht wurde, falls Dritte Rechte an dem Bild geltend machen, sowie die Nachvollziehbarkeit unserer KI-Kennzeichnung. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO; unser berechtigtes Interesse liegt in der Nachweisführung und Rechtsverteidigung. Eine dokumentierte Abwägung liegt vor. +> +> Die Originaldatei ist nicht öffentlich abrufbar. Öffentlich ausgeliefert werden ausschließlich verkleinerte Fassungen, aus denen Standortdaten, Geräteseriennummern und sonstige technische Metadaten des Originals entfernt sind. Bildnachweis und KI-Kennzeichnung werden am Bild angezeigt. +> +> Bilder, die hochgeladen, aber nie veröffentlicht werden, löschen wir, wenn Sie sie löschen oder ersetzen, sofort; bleibt ein Entwurf 180 Tage unbearbeitet, löschen wir ihn mit seinen Bildern *(Ziel)*. Wird ein veröffentlichtes Bild entfernt oder ersetzt oder endet die Veröffentlichung der Mitteilung, werden die genannten Daten in unser Beweisarchiv (Abschnitt „Beweisarchiv“) überführt und dort nach den dort genannten Fristen gelöscht. + +### Beweisarchiv nach Entfernung von Inhalten (beide, neu) + +> **Beweisarchiv nach Entfernung von Inhalten** +> +> Wenn wir eine Pressemitteilung oder Teile davon aus dem öffentlichen Angebot entfernen, etwa auf Antrag, im Meldeverfahren, nach einer Datenschutzanfrage oder auf eigene Entscheidung, bleibt sie in allen öffentlich sichtbaren Bereichen unserer Portale entfernt, einschließlich Suche, Feeds und Sitemap. Wir beantragen zusätzlich die Löschung aus den gängigen Suchmaschinen; auf deren Aktualisierung haben wir keinen Einfluss. +> +> Einen auf das Notwendige beschränkten Datensatz zu der entfernten Veröffentlichung bewahren wir in einem getrennten, verschlüsselten Archiv auf: den zuletzt veröffentlichten Stand der Inhalte einschließlich der darin genannten Pressekontakte, die Angaben zum Einreicher (Konto, Name, E-Mail-Adresse, Firma zum Zeitpunkt der Einreichung *(Ziel)*), die zu den Bildern gespeicherten Daten (Abschnitt „Bilder in Pressemitteilungen“), die Zeitpunkte von Veröffentlichung und Entfernung, den Grund der Entfernung als Kategorie, bei Änderungen den vorherigen und den neuen Stand sowie die Vorgangsnummer eines zugrunde liegenden Melde- oder Löschverfahrens *(Ziel; bis zur Umsetzung: „sowie die Angaben des zugrunde liegenden Melde- oder Löschverfahrens einschließlich der Kontaktadresse des Antragstellers“)*. Zweck ist ausschließlich die Wahrung unserer Nachweis- und Verteidigungsinteressen gegenüber Rechteinhabern, Betroffenen und Behörden sowie der Rückgriff gegen den Einreicher. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO; soweit ein Bild ausnahmsweise besondere Kategorien personenbezogener Daten erkennen lässt, Art. 9 Abs. 2 lit. f DSGVO. Bei Daten, deren Löschung beantragt wurde, prüfen wir im Einzelfall, ob die weitere Aufbewahrung nach Art. 17 Abs. 3 lit. e DSGVO erforderlich ist, und halten das Ergebnis fest. +> +> Originaldateien aktiver Bilder sind für unsere Redaktion zugänglich; archivierte Inhalte nur für Administratoren mit gesonderter Berechtigung. Jeder Abruf archivierter Inhalte und jede Änderung einer Aufbewahrungssperre wird mit Angabe des Zwecks protokolliert; das Protokoll löschen wir nach 395 Tagen *(Ziel)*. Das Archiv wird für keinen anderen Zweck verwendet und nicht an Dritte weitergegeben, außer zur Rechtsverteidigung an unsere rechtlichen Berater oder auf gesetzlicher Grundlage an Behörden und Gerichte. +> +> Archiveinträge werden drei Jahre nach dem Ende des Jahres, in dem der Inhalt entfernt wurde, automatisch gelöscht. Läuft zu einem Inhalt eine rechtliche Auseinandersetzung, setzen wir eine dokumentierte Aufbewahrungssperre; nach deren Aufhebung wird der Eintrag zum regulären Zeitpunkt gelöscht oder, wenn ein dokumentierter Grund fortbesteht, zu einem festgelegten späteren Zeitpunkt *(Ziel)*. Verlangen Sie die Einschränkung der Verarbeitung, kennzeichnen wir den Eintrag gesondert und beschränken seine Verwendung auf die gesetzlich zulässigen Zwecke *(Ziel)*. Von einem gelöschten Eintrag bleibt nur ein technischer Löschvermerk (Kennung, Objektschlüssel, Ereignisart, Zeitpunkte, Prüfsumme); er verhindert, dass gelöschte Inhalte durch eine Wiederherstellung erneut verfügbar werden, und wird nach der im Abschnitt „Speicherdauer“ genannten Frist gelöscht *(Ziel)*. Sicherungskopien werden innerhalb von 14 Tagen überschrieben; nach einer Wiederherstellung aus einer Sicherung werden bereits gelöschte Einträge anhand eines getrennt gesicherten Löschstands erneut entfernt *(Ziel: getrennter Löschstand und Übung)*. + +### 13. Speicherdauer (beide, Liste der wesentlichen Fristen; Sitzungen, Reset- und API-Tokens sowie Warteschlangen werden vor Veröffentlichung ergänzt) + +> - Server-Logs: 14 Tage. +> - Anmelde- und Änderungslinks: einmalige Nutzung oder 15 Minuten gültig; Bestätigungslinks aus dem Meldeverfahren: 72 Stunden. Die zugehörigen Datensätze werden gelöscht, sobald Verbrauch oder Ablauf mehr als 30 Tage zurückliegen. +> - Ereignisprotokolle (Abschnitt „Eigene Nutzungsstatistiken“): 395 Tage. +> - Fehlerberichte: 90 Tage. +> - Aktivitätsverlauf: Anmelde- und Fehlversuchsereignisse 90 Tage, übrige Einträge 395 Tage; Tagessummen fehlgeschlagener Anmeldungen 90 Tage; API-Zugriffsprotokoll 90 Tage; IP-Adresse der letzten Anmeldung 90 Tage nach der letzten Anmeldung. +> - Zustellmeldungen: 90 Tage im Postfach, 395 Tage als ausgewerteter Datensatz; Sperrliste, solange erforderlich. +> - IP-Adressen aus Formularanfragen und Buchungsbestätigungen: 90 Tage. +> - Kontaktanfragen: 180 Tage nach Abschluss; Anfragen mit Vertrags- oder Rechtsbezug nach der Frist des jeweiligen Vorgangs. +> - Formulardaten zu Widerruf, Kündigung und Buchungsbestätigung: 180 Tage nach Bearbeitung; der Vertragsnachweis selbst nach den gesetzlichen Aufbewahrungsfristen. +> - Entwürfe, die nie veröffentlicht wurden: sofort bei Löschung durch Sie, sonst 180 Tage nach der letzten Änderung samt Bildern. +> - Abgelehnte, nie veröffentlichte Einreichungen: Text und Bilder 180 Tage nach der Ablehnung; ein Ablehnungsnachweis (Status, Zeitpunkt, Kategorie, Konto) drei Jahre nach Ende des Jahres der Ablehnung. +> - Bearbeitungsstände von Korrekturen: 30 Tage. +> - Meldedaten: drei Jahre nach Abschluss des Vorgangs. +> - Beweisarchiv: drei Jahre nach Ende des Jahres der Entfernung; Zugriffsprotokoll 395 Tage; technischer Löschvermerk bis zum späteren von 395 Tagen nach Löschung und 14 Tagen nach Ablauf der letzten rückspielbaren Sicherung. +> - Vertrags-, Buchungs- und Rechnungsdaten: gesetzliche Aufbewahrungsfristen (Buchungsbelege acht Jahre, Handels- und Geschäftsbriefe sechs Jahre). +> - Veröffentlichte Pressemitteilungen: dauerhaft im Archiv, soweit keine Ansprüche auf Entfernung bestehen. +> - Kontodaten: nach Kontolöschung, soweit keine Aufbewahrungspflichten entgegenstehen. +> +> Gelöschte Daten können in Sicherungskopien noch bis zu 14 Tage enthalten sein. Die Backups werden ausschließlich zur Wiederherstellung der Systeme im Sicherungsfall verwendet und nicht produktiv ausgewertet. + +### Versionshinweis (beide, am Ende) + +> **Stand: [Datum] · Version 0.4.** Änderungen gegenüber 0.3: Abschnitt „Eigene Nutzungsstatistiken“ (21.09.2026), Abschnitt „Schutz vor automatisierten Anfragen“ (09.10.2026), neu: Fehlerprotokoll, Anmeldung und Kontosicherheit, Aktivitätsverlauf und API, Zustellbarkeit und Abmeldung, Bilder in Pressemitteilungen, Beweisarchiv; überarbeitet: Kontaktaufnahme, Automatisierte Inhaltsprüfung, Änderungslinks, Speicherdauer. Frühere Fassungen: [Link]. + +--- + +## 5. Fragen an Sie + +Je Frage unser Default. Bitte bestätigen, ändern oder begründet verwerfen. + +| Nr. | Frage | Unser Default | Antwort | +|---|---|---|---| +| 1 | **AGB 0.7:** Freigabe von § 8a (neu), § 9 Abs. 1, 1a, 2, 4 (geändert), § 6 Abs. 2 (Kategorie-Boost, Kennzeichnung), § 8 Abs. 1 (KI-Angabe als Zusicherung), § 10 Abs. 6 (Erstattungen). Hält das Zusammenspiel im B2B nach § 307? Ist der Konflikt § 9 Abs. 1a / Abs. 2 gelöst? Deckt Abs. 1a die Vervielfältigung durch soziale Netzwerke beim Teilen? Genügt „Wahrung der wesentlichen Bildaussage“ gegen § 14 / § 39 UrhG? | Texte in Anlage 1 Abschnitt 3 und Anlage 4 | | +| 2 | **Einbeziehung 0.7:** Zustimmungsgate mit aktivem Klick je Fassung vor jedem neuen Kauf (Einzelveröffentlichung, Credits, neues Abonnement). Bereits bezahlte Leistungen bleiben ohne neue Zustimmung nutzbar: Abonnenten mit laufender Laufzeit und Kunden mit vor 0.7 erworbenen Credits (FIFO) erhalten „Später entscheiden“ und reichen unter 0.6 ein; „Später“ erzeugt keinen Annahmedatensatz. Stimmt ein Abonnent nicht zu, läuft der Vertrag nach § 15 Abs. 3 unter 0.6 weiter, auch bei automatischer Verlängerung; eine Umstellung erfolgt dann nur durch Änderungskündigung (ordentliche Kündigung zum Laufzeitende nach § 11 Abs. 2 mit Angebot eines neuen Vertrags unter 0.7). Der Dialog im Code kennt heute nur Annahme oder Abbruch; „Später entscheiden“ und der Bestandsschutz werden mit Deploy 3 gebaut (Screenshot des heutigen Stands in Anlage 7). Trägt das die bestehende Vertragslage? Ist die Änderungskündigung der richtige Weg, und welche Mitteilung und Frist sind nötig? Gilt die Anerkennung über den Bild-Schalter mit Fassung und Link zusätzlich als wirksame Erklärung? | Ja / Ja / Ja | | +| 3 | **Beweisarchiv:** Pauschale Drei-Jahres-Frist nach Jahresende für alle Ereignistypen (Begründung je Typ in Anlage 2)? Originaldatei mit allen Metadaten speichern? Art. 9 Abs. 2 lit. f als Grundlage für Bilder mit besonderen Kategorien? Aufbewahrungssperre und Einschränkung nach Art. 18 getrennt wie in D1? Umgang mit bereits versiegelten Archivpaketen, die Antragsteller-E-Mails enthalten: minimierte Nachfolgefassung mit Integritätsnachweis oder befristete Übergangsaufbewahrung? Abwägung in Anlage 2 ausreichend? | Ja zu allem; Altbestand: Nachfolgefassung | | +| 4 | **Medienprivileg in der Portal-DSE (Abschnitt 9):** Der Absatz beruft sich mit „soweit“ auf Art. 85 DSGVO und § 57 MStV, während das Portal sonst als Hoster ohne redaktionelle Bearbeitung auftritt. Ist der Absatz in dieser Form unschädlich, oder sollte er auf Archivfunktion und Informationsfreiheit (Art. 17 Abs. 3 lit. a) umgestellt werden? | Behalten, im Einzelfall nie allein darauf stützen | | +| 5 | **Hoster-Status:** Reichen Richtlinien-Formulierung („automatisierte Prüfung“), Verantwortlich-Zeile am Bild und Preisseiten-Wording, auch mit bezahlten Platzierungen und automatisiertem KI-Scoring? Ist der UrhDaG-Vermerk (Anlage 1, 3.9) tragfähig? Der Status als kleiner Diensteanbieter (§ 2 Abs. 3 UrhDaG) wird dabei nur als Reduzierung einzelner Pflichten verstanden, nicht als Freistellung. Ersetzt in 0.7 „redaktionelle Qualität“ (§ 4 Abs. 4, § 7 Abs. 1) durch „Qualität und Lesbarkeit“. | Ja / Ja | | +| 6 | **Art. 50 KI-VO:** (a) Geplant (C2PA-Prüfung, noch nicht in Betrieb; heute dienen Metadaten der Datei nur als Vorbelegung, die der Einreicher ändern kann): Wird das Portal durch eine aus geprüften Herkunftsdaten gesetzte, nicht abschwächbare Kennzeichnung zum Mitbetreiber nach Abs. 4? Korrekturweg (§ 8a Abs. 4) ausreichend? (b) Geplant (noch nicht gebaut): Eigene „Portal-Updates“ sollen per KI vorformuliert, vom Betreiber überarbeitet und freigegeben werden; gespeichert würden Entwurf, Endfassung, Diff, Freigebender, Zeitpunkt; die Rubrik nennt die KI-Unterstützung. Entfällt damit die Kennzeichnungspflicht? (c) Alt-API setzte bisher „ohne KI“ im Namen des Kunden; wird auf „keine Angabe“ umgestellt. | Nein / Ja / Ja | | +| 7 | **Boost-Kennzeichnung:** Bezahlte hervorgehobene Platzierung von Kundenmeldungen auf Startseite und Branchenseite. Label „Gebuchte Platzierung“ (en „Booked placement“) am Bild und in Listen, Tooltip „Das Unternehmen hat diesen Platz gebucht. Der Inhalt ist eine Pressemitteilung des Unternehmens.“, Satz auf der Preisseite, Klausel in § 6 Abs. 2. Die Erklärung erscheint am Desktop beim Überfahren, auf Mobil per Tipp auf das Label, und wird von Screenreadern mitgelesen. Die Kopfzeile über dem Aufmacher lautet „Aktuell“ statt bisher „Top-Auswahl“. Screenshots eines Test-Boosts (Startseite, Branchenseite, Mobil, Erklärung) liegen als Anlage 7 bei. Genügt das in der tatsächlichen Darstellung § 5a Abs. 4 UWG, Anhang Nr. 11 UWG und § 22 MStV? | Ja | | +| 8 | **Fehlerprotokoll im Browser:** lit. f plus § 25 Abs. 2 Nr. 2 TDDDG mit dem in 3a beschriebenen minimalen Datensatz, ohne Einwilligung? | Ja | | +| 9 | **Turnstile:** lit. f plus § 25 Abs. 2 Nr. 2 TDDDG; serverseitige IP-Übermittlung; DPF für Cloudflare, Inc. Text 6a mit Ergänzungen freigeben? | Ja | | +| 10 | **Aktivitätsverlauf:** 395 Tage für Mail-Einträge (Empfängeradresse, Betreff) auch zu Pressekontakten ohne Konto verhältnismäßig? Begründung: Nachweis der Benachrichtigung bei späteren Beschwerden. | Ja | | +| 11 | **Sperrliste:** Für Abmeldungen lit. c in Verbindung mit Art. 21 Abs. 3 DSGVO neben lit. f nennen; für Hard Bounces nur lit. f. | Ja | | +| 12 | **Lösch- und Änderungsanfragen** (Kontext in Anlage 6): (a) Grenze zwischen unentgeltlicher Erfüllung nach Art. 17 und entgeltlicher Depublikation: Der Preis trägt, wenn kein Betroffenenrecht einer natürlichen Person betroffen ist und ein kostenfreier Weg dafür besteht; bei eigenen Kunden zusätzlich, weil die Archivierung bei Vertragsschluss offengelegt war (§ 13 Abs. 1); bei übernommenem Altbestand ohne eigenen Vertrag ist die Depublikation rechtmäßiger Inhalte juristischer Personen eine freiwillige Leistung ohne Entfernungsanspruch. Hält § 13 Abs. 1 nach § 307? (b) Früher beworbener „kostenfreier Weg über connektar“, der praktisch nicht funktionierte: Irreführung nach § 5 UWG; Aussage entfernt und dokumentiert (Zeitraum, Entfernung). Verjährung: sechs Monate für Mitbewerber- und Verbandsansprüche, ein Jahr für Verbraucheransprüche nach § 9 Abs. 2, wobei Verbraucher hier nicht Kunden sind; vertragliche Ansprüche von Geschäftskunden gesondert. Keine weitere Maßnahme nötig? (c) Realnamen-Änderung: kostenfrei, wenn die genannte natürliche Person oder ein von ihr bevollmächtigtes Unternehmen es verlangt; Kontaktaktualisierung durch das Unternehmen nach Leistungsbeschreibung; sonstige Edits kostenpflichtig. (d) Art. 19 in der Syndikation: Portal benachrichtigt eigene Empfänger (Art. 17 Abs. 2 für die Öffentlichkeit), Verteiler die seinen; gegenseitige Meldung vertraglich. | Ja zu (a) bis (d) | | +| 13 | **Regresskette:** Gate-Annahme → Upload-Bestätigung (Rolle, Fassung, Konto, Zeitpunkt, IP-HMAC) → Original mit Hash → veröffentlichte Fassung → Archiv mit Hash, täglicher Hash-Export auf getrennten Speicher (Integritätsnachweis, kein qualifizierter Zeitstempel); Partnerbedingungen mit Annahmebeleg. Fehlt ein Glied? | Nein | | +| 14 | **Syndikationsvertrag:** Entwurf nach der Gliederung in Anlage 5, vorrangig § 2 bis § 5 (Rollen, Schnittstelle, Änderungen, Inhalte) vor dem Partnertermin im Oktober. | Entwurf durch Sie | | +| später | **KI-Vorabprüfung von Bildern (D8):** Genügen AVV, nachgewiesene Zero Data Retention, Minimierung (1024 px, keine Metadaten, kein Kontobezug) und eine dokumentierte Schwellwertprüfung zur DSFA, oder ist eine förmliche DSFA nötig? Art. 9 bei „Person erkennbar ja/nein“ ohne Identifizierung? | AVV plus Schwellwertprüfung; kein Art. 9 | | +| später | **Webanalyse im Kundenbereich (D7)** mit HMAC-Kennung und Widerspruch: lit. f ohne Einwilligung? | Ja | | +| später | **Newsletter (D10):** Opt-in mit Bestätigung und Protokoll ohne IP ausreichend; kein § 7 Abs. 3 UWG für Altkonten. | Ja | | + +--- + +## 6. Entscheidungen des Betreibers (Information, keine Fragen) + +| Bereich | Entscheidung | +|---|---| +| Nummerierung der DSE | Zwei Ausprägungen mit unterschiedlichen Nummern ab Abschnitt 7; Querverweise über Titel und stabile Anker | +| Fristen | Wie Abschnitt 2 und 4 (Liste 13); Vorfälle werden einzeln mit Vermerk länger gehalten | +| Letzte Anmelde-IP | Im Klartext sichtbar, überschrieben, 90 Tage nach letzter Anmeldung gelöscht | +| Webanalyse Kundenbereich, KI-Bildprüfung, Newsletter | Bleiben aus; eigene Aktivierungspakete | +| Juli-Mails an Altkonten | Versand über das interne Kampagnenmodul, beide mit Abmeldelink: am 21.07.2026 an 10 Konten mit laufendem Bestandsvertrag und Anmeldung in den letzten 12 Monaten (Bestandsschutz und Relaunch), am 22.07.2026 an 954 Konten mit Anmeldung in den letzten 12 Monaten (Info zum Relaunch). Konten ohne Anmeldung seit über 12 Monaten (rund 58.600) wurden bewusst nicht angeschrieben; die Empfängerfilter wurden dafür gebaut. Texte, Empfängerregel und Zahlen: Anlage 7. | +| Umami | Rohdatenfrist der Instanz 13 Monate | +| Beweisarchiv | Wie D1; Legal Hold ohne Fristneustart; Restdaten minimal; Zugriffsprotokoll 395 Tage; Original unverändert | +| Bildrechte-Bestätigung | Rolle je Einreichungsweg wie in D1; Betreiber bestätigt nie; Betreiber-Upload nur für Meldungen mit Konto; Self-Service-Upload von Bildern nur mit Konto, Kontaktdatenänderung auch ohne | +| Zustimmungsgate | Gate vor jedem neuen Kauf; „Später“ für laufende Abonnements und vor 0.7 gekaufte Credits; keine automatische Umstellung bei Verlängerung; Umstellung nur per Änderungskündigung (Frage 2) | +| Boost | „Gebuchte Platzierung“ mit Tooltip; Aufmacher ohne Buchung bleibt „Top-Meldung“ und wird automatisch bestimmt, keine manuelle Auswahl | +| Erstattungen | Modell: abgelehnte Einzel-PM nach einer kostenfreien Überarbeitung voll erstattet; nicht erbrachte Zusatzleistung als Credits gutgeschrieben; unverbrauchte Credits auf Antrag innerhalb von 14 Tagen nach Kauf erstattet, danach § 5 Abs. 3; Abonnements zum Laufzeitende, keine anteilige Erstattung außer bei Sonderkündigung nach § 10 Abs. 5; Erstattung auf demselben Zahlungsweg | +| Portal-Updates (geplant) | KI-Entwurf, Überarbeitung und Freigabe durch den Inhaber, dokumentiert; Rubrik nennt die KI-Unterstützung und den Verantwortlichen. Noch nicht gebaut. | + +--- + +## 7. Änderungen an den AGB (0.7), Zusammenfassung + +| Stelle | Änderung | Quelle | +|---|---|---| +| § 4 Abs. 4, § 7 Abs. 1 | „redaktionelle Qualität“ → „Qualität und Lesbarkeit“ | Hoster-Status | +| § 6 Abs. 2 | Kategorie-Boost, Slot-Begrenzung, Kennzeichnung als gebuchte Platzierung | Anlage 4, Abschnitt D | +| § 8 Abs. 1 | neuer Spiegelstrich: „seine Angaben zur Erstellung mit KI zutreffend sind; eigene Pflichten des Kunden aus der Verordnung (EU) 2024/1689 bleiben unberührt“ | Frage 6 | +| § 8a | neu, Text in Anlage 1 Abschnitt 3.1; in Abs. 1 Satz 1 ergänzt: „… die Nutzungen und Bearbeitungen nach § 9 einzuräumen“ | Frage 1 | +| § 9 | Abs. 1, 1a, 2, 3, 4 wie Anlage 1 Abschnitt 3.2 | Frage 1 | +| § 10 Abs. 6 | neu: Erstattungen (Wortlaut in Anlage 4, Abschnitt 7) | Abschnitt 6 | +| § 6 Abs. 2 neu, Wortlaut | „Zeitlich befristete hervorgehobene Platzierung einer veröffentlichten PM in den Laufzeitstufen 7, 14 oder 30 Tage. Der Startseiten-Boost umfasst die Startseite und die Kategorieseite des jeweiligen Portals, der Kategorie-Boost nur die Kategorieseite der gewählten Rubrik. Die Zahl gleichzeitiger Boosts je Seite ist begrenzt; die freien Plätze werden vor der Buchung angezeigt. Geboostete PMs werden als gebuchte Platzierung gekennzeichnet. Ein Boost ist nur für PMs buchbar, die die Inhaltsprüfung ohne Beanstandung durchlaufen haben (Status „Grün“). Geschuldet ist ausschließlich die Platzierung während der gebuchten Laufzeit; eine bestimmte Reichweite, Zugriffszahl oder sonstige Werbewirkung wird nicht geschuldet. [Satz zur Nichterreichbarkeit unverändert.]“ | | + +Bestätigungstext im Upload-Formular, Verantwortlich-Zeile und Richtlinien-Texte: Anlage 1, Abschnitte 3.3 bis 3.5. + +--- + +## 8. Reihenfolge nach Ihrer Antwort + +1. Antworten in die Entscheidungsdokumentation übernehmen; abweichende Defaults anpassen. +2. Löschläufe und Zielfristen produktiv setzen und belegen; Restore-Übung. +3. DSE 0.4, AGB 0.7, Richtlinien, Bestätigungstext mit § 8a-Verweis und Zustimmungsgate gemeinsam veröffentlichen (Deploy 3). +4. Interessenabwägung datieren und abzeichnen. + +## Anlagen + +1. Decision-Update Bildrechte und Beweisarchiv vom 22.09.2026 (Abschnitte 3, 4, 7, 8, 12) +2. Interessenabwägung Beweisarchiv, Fassung vom 12.10.2026 +3. Rechtstexte im Live-Stand vom 12.10.2026: DSE 0.3 Hub und Portale, AGB 0.6, Boost (Preisseite, Label) +4. Klärungsdokument vom 12.10.2026 (Begründungen zu allen Defaults, Erstattungsklausel, Bestätigungsrollen) +5. Gliederung Syndikationsvertrag (Anlage 4, Abschnitt 8) +6. Kontext Lösch- und Änderungsanfragen ([`handover_loesch-anfragen.md`](handover_loesch-anfragen.md), Stand 25.08.2026) +7. Screenshots und Belege ([`nachweise/`](nachweise/README.md)): Bild-Upload-Formular mit Rechtebestätigung und KI-Angabe, Bildnachweis mit Detailfenster, Sicherheitsseite, Zustimmungsgate (Entwicklungsumgebung), KI-Hinweis bei Texten, Test-Boost (Startseite, Branchenseite, Mobil, Erklärung), Berechtigungsliste (BN-02), Verträge und Einstellungen der Dienstleister, Juli-Mailtexte mit Empfängerregel und Zahlen diff --git a/dev/rechtliches/handover_loesch-anfragen.md b/dev/rechtliches/handover_loesch-anfragen.md new file mode 100644 index 00000000..d6bab621 --- /dev/null +++ b/dev/rechtliches/handover_loesch-anfragen.md @@ -0,0 +1,126 @@ +# Kontext: Beurteilung von Lösch- und Änderungsanfragen + +*Instruktionsblock für neue Chats. Aufgabe: eingehende Nachrichten zu veröffentlichten Pressemitteilungen rechtlich und inhaltlich einordnen, Kostenfolge bestimmen, Antwort formulieren.* + +*Kopie aus dem Projektwissen „Presseportale“ (Stand 25.08.2026), abgelegt am 13.10.2026 als Anlage 6 zum Anwaltspaket. Die im Decision-Update Bildrechte vom 22.09.2026 (Abschnitt 3.8) vorgesehenen Ergänzungen (Archiveintrag vor jeder Änderung, Archivinhalte in Art.-15-Auskünften, Standardabsatz zum Beweisarchiv in Antwortschreiben) sind hier noch nicht eingearbeitet.* + +--- + +## 1. Ausgangslage + +- Zwei Presseportale: **presseecho.de** (breite/allgemeine Themen) und **businessportal24.com** (Wirtschaft/Unternehmen). Verwaltung über den gemeinsamen Hub **pressekonto.com**. +- Betrieb als Solo-Projekt neben dem Hauptjob → jede Lösung muss ohne dauerhaften Betreuungsaufwand auskommen. +- Grundhaltung **„Anti-Zombie"**: keine versteckten Kosten, keine automatische Verlängerung, keine Mindestlaufzeit, transparente öffentliche Preise, direkter menschlicher Kontakt. Jede Entscheidung wird dagegen geprüft. +- Ein großer Teil der Meldungen kommt über Presseverteiler (v. a. **connektar.de**, teils **openPR**) per API. +- **connektar ist write-once:** Die technische Möglichkeit zur Propagierung von Änderungen/Löschungen besteht, wird aber nicht genutzt. → Das Portal übernimmt **alle** Zustandsänderungen nach Veröffentlichung selbst. Kunden **nicht** mehr auf den „kostenfreien Weg über connektar" verweisen (UWG-Risiko + Anti-Zombie-Widerspruch). +- Kein Anwalt im Team. Rechtliche Aussagen sind Einordnung, keine Rechtsberatung; offene Punkte gehören auf die Anwaltsagenda (§7). + +--- + +## 2. Entscheidungsachse (immer zuerst prüfen) + +Nicht das Datenfeld entscheidet, sondern: + +1. **Wer ist betroffen?** Natürliche Person (DSGVO greift) oder juristische Person (kein Betroffenenrecht)? +2. **Was bleibt nach Anonymisierung übrig?** Ein eigenständig zulässiges, werthaltiges Reststück — oder ein sinnloser Rumpf? + +**Wichtig:** „Personenbezogen" umfasst nicht nur Kontaktfelder, sondern auch Name, Autorenschaft und inhaltliche Aussagen einer identifizierbaren Person. Nur die Kontaktfelder zu leeren erfüllt einen Art.-17-Anspruch **nicht**, wenn der Realname stehen bleibt. + +--- + +## 3. Free/Paid-Matrix + +| Konstellation | Vorgehen | Kosten | +|---|---|---| +| Natürliche Person, PM über/von ihr | Volldepublizierung | **kostenfrei** | +| Natürliche Person, nur Kontaktdaten (Ansprechpartner in Firmen-PM) | Daten entfernen, PM bleibt | **kostenfrei** | +| Natürliche Person, Realname entfernen/pseudonymisieren | Änderung umsetzen | **kostenfrei** | +| Juristische Person, Register-/Firmendaten (§ 9 HGB) | Kontaktdaten nat. Person raus; Firmeneintrag bleibt | Volldepublizierung **optional 35 €** | +| Inhaltliche Änderung ohne Personenbezug (Text umschreiben, Bildtausch) | Edit + neuer Freigabelauf | **kostenpflichtig** | + +**Preis-Überlebensbedingung (kumulativ):** Eine Gebühr trägt nur, wenn (a) **kein** Personenbezug einer natürlichen Person vorliegt **und** (b) ein tatsächlich funktionierender kostenfreier Alternativweg existiert (= Magic-Link-Self-Service, **nicht** connektar). + +**Grundsatz:** DSGVO-Anliegen führen zu **Anonymisierung**, nicht zu Depublizierung. Depublizierung ist der separate, kostenpflichtige Fall. Ausnahme: Wenn nach Anonymisierung nur ein sinnloser Rumpf bleibt (Vanity-/Personen-PM), ist Depublizierung das richtige Mittel — diese Entscheidung trifft ein Admin, nicht der Antragsteller. + +--- + +## 4. Verifikation + +- **Regelweg:** Magic-Link an die **in der Veröffentlichung hinterlegte** Firmen-/Pressekontaktadresse — nie an die im Formular oder in der Mail angegebene. Damit ist nur der echte Kontakt handlungsfähig. +- **Nachweis nur bei begründeten Zweifeln** (Art. 12 Abs. 6), z. B. Absenderadresse ≠ hinterlegte Adresse. **Nie Ausweiskopie verlangen** (Datenminimierung). +- **Fallback „Kanal tot / keine Adresse hinterlegt":** Risiko-Asymmetrie kippt Richtung Umsetzen, wenn kein Missbrauchsmotiv erkennbar ist (eigene Privatdaten einer natürlichen Person). Dann: **Aktenvermerk** (Art. 5 Abs. 2) + **umkehrbare** Depublizierung + Hinweis auf Wiederherstellbarkeit. Kein Verifikationsverfahren, das den Antrag faktisch blockiert. +- **Dringlichkeitsrhetorik** („Notfall", „unverzüglich") ändert die Monatsfrist nicht und darf die Prüfung nicht überspringen. +- **Frist:** Reaktion innerhalb **eines Monats** ab Eingang (Art. 12 Abs. 3), auch bei Ablehnung. Schweigen ist die einzige wirklich riskante Option. + +--- + +## 5. Technische Checkliste bei Umsetzung + +- [ ] Daten aus sichtbarem Text **und** strukturierten Kontaktfeldern entfernen +- [ ] Bilder und Anhänge (Klarname in Cover/PDF/Signatur!) +- [ ] Interne Suche, Feed-/RSS-Ausgaben, Sitemap +- [ ] `noindex` + Entfernung aus dem Suchindex einreichen (Cache-Aktualisierung dauert Tage → im Schreiben erwähnen, kein eigener Einfluss) +- [ ] **Re-Sync-Sperre** — zwingend, sonst holt der nächste Import den alten Stand zurück +- [ ] **Art. 19 DSGVO:** Verteiler informieren; Betroffenen für netzwerkweite Entfernung an den Verteiler verweisen +- [ ] **Kein Credit-Abzug** im DSGVO-Pfad (Art. 12 Abs. 5) — technisch verifizieren +- [ ] **Audit-Log ohne Klartext-Altwerte** (sonst leben die Daten im Log weiter); Alt-Wert nur verschlüsselt + Löschfrist +- [ ] Ersetzung mit **Wortgrenzen** und **Namensvarianten** (Genitiv, „Herr X", „M. X"); Pflicht-Vorschau/Diff; Platzhalter oder Rolle statt Leerstring + +--- + +## 6. Referenzfälle (Muster) + +| Fall | Muster | Entscheidung | +|---|---|---| +| **HWP / Kaymaz** | GmbH, Registerdaten, Vorlagen-Streumail, Frist-Platzhalter leer | Persönliche Kontaktdaten kostenfrei raus; Firmeneintrag bleibt; Volldepublizierung optional 35 € | +| **Huraux** | Natürliche Person, Privatdaten, hinterlegter Kanal tot | Vollstattgabe kostenfrei, ohne formale Verifikation, Aktenvermerk + umkehrbar | +| **Gleue** | Natürliche Person, Kanal intakt | Vollstattgabe kostenfrei, Magic-Link an hinterlegte Adresse | +| **Rambo** | Realname → Pseudonym, connektar verweigert Fremdportal-Änderung | Kostenfrei umsetzen, kein connektar-Verweis | +| **Meet5 / Reinhardt** | Private Telefonnummer in alter PM, wird von LLMs als Kontakt ausgegeben | Nummer sofort kostenfrei entfernen, PM bleibt online; Magic-Link nur als Hinweis für künftige Fälle | + +--- + +## 7. Kommunikationsregeln + +- **Kein Verweis mehr auf connektar** als kostenfreier Änderungs-/Löschweg. +- **Aufsichtsbehörden-Hinweis** („Ihnen steht der Weg zur Aufsichtsbehörde offen") gehört **nicht** in ein Schreiben, das ein kostenfreies Angebot macht — dort wirkt er wie eine Einladung zur Beschwerde. Erst in den **zweiten** Brief, wenn tatsächlich (teilweise) **abgelehnt** wird. Im Angebotsfall neutral schließen. +- **Nicht überversprechen:** Was technisch passiert, ist **De-Identifikation / Schwärzung direkter Identifier**, keine „Anonymisierung" im DSGVO-Vollsinn. +- **Bei Ablehnung sachlich bleiben:** keine absoluten Behauptungen („Datenschutzrechte finden hier keine Anwendung" ist falsch, wenn personenbezogene Daten einer natürlichen Person enthalten sind — dann aufteilen). +- **Konversionschance nutzen:** Bei API-Einreichern, die nicht selbst ändern können, die Direktveröffentlichung als gleichwertige Option nennen — nie als Verkaufsdruck oder Mautstelle. +- **Kein Verkaufsdruck bei abgelehnten Meldungen:** kostenpflichtige Änderung dort nicht anbieten, wenn ein kostenloser Weg über den Verteiler existiert. + +--- + +## 8. Argumentationsreserve (nur juristische Person / Registerdaten) + +Kurzform für den Brief: *„Register- und Firmendaten sind nach § 9 HGB öffentlich einsehbar und betreffen die GmbH als juristische Person, der die genannten Datenschutzrechte nicht zustehen; eine Löschpflicht besteht daher nicht."* + +Vier Säulen, falls nachgehakt wird: +1. **Kein Schutzsubjekt** — DSGVO schützt nur natürliche Personen. +2. **Gesetzlich öffentlich** — § 9 HGB; kein Recht auf Herauslöschen rechtmäßiger Registertatsachen. +3. **Rechtsgrundlage + Ausnahme** — Art. 6 Abs. 1 lit. f (nicht Einwilligung); Art. 17 Abs. 3 lit. a (Informationsfreiheit); bei echter PM zusätzlich Medienprivileg (Art. 85 + LPG). +4. **Widerspruch ≠ Löschung** — Art. 21 löst eine Abwägung aus; „ohne meine Zustimmung" läuft leer, weil Einwilligung nie die Grundlage war. + +**Grenze:** Trägt nur Firmen-/Sachdaten. Bei **Presskit-/Profilseiten** aus Aggregat-/Registerdaten ist Säule 3 schwach → dann auf 1, 2, 4 stützen. Persönliche Kontaktdaten werden trotzdem kostenfrei entfernt. + +--- + +## 9. Offene Anwaltsfragen + +1. Grenze zwischen unentgeltlicher Erfüllung (Art. 17) und entgeltlichem freiwilligem Depublizierungsservice — trägt der Preis, wenn das Reststück eigenständig zulässig wäre? +2. UWG-Bewertung des früher als kostenfrei beworbenen connektar-Wegs. +3. Ab wann ist eine Realnamen-Änderung ein unentgeltliches Betroffenenrecht statt eines kostenpflichtigen Edits? +4. Art.-19-Zuständigkeit in der Syndication: Portal oder Verteiler? + +*Stand 13.10.2026: Die vier Fragen sind im Anwaltspaket (Versandfassung) als Frage 12 (a) bis (d) mit Default enthalten; Begründungen im Klärungsdokument, Abschnitt 4.* + +--- + +## 10. Arbeitsweise in diesem Kontext + +- Antworten auf **Deutsch**, Kundenkommunikation in deutscher Geschäftssprache. +- **Adversarial prüfen:** strukturelle Schwächen und rechtliche Edge Cases von sich aus benennen, nicht erst auf Nachfrage. +- **Trennen:** Geschäftsentscheidungen (selbst entscheidbar) von echten Rechtsfragen (Anwalt). +- Bei Entwürfen: **Platzhalter** setzen statt Fakten zu erfinden (Preise, Links, Daten, Namen). +- **KI-Spuren entfernen** in kundenseitiger Korrespondenz: keine Gedankenstrich-Häufung, keine Dreierfiguren, keine Label-Doppelpunkt-Konstruktionen, keine Nominalisierungsketten. +- Struktur bevorzugt: Tabellen, klare Optionen, Entscheidungslogik statt Fließtext. diff --git a/dev/rechtliches/interessenabwaegung-beweisarchiv-2026-10-12.md b/dev/rechtliches/interessenabwaegung-beweisarchiv-2026-10-12.md new file mode 100644 index 00000000..37ae3b03 --- /dev/null +++ b/dev/rechtliches/interessenabwaegung-beweisarchiv-2026-10-12.md @@ -0,0 +1,122 @@ +# Interessenabwägung nach Art. 6 Abs. 1 lit. f DSGVO + +## Bild-Originale, Rechtebestätigung und Beweisarchiv + +**Verantwortlicher:** adametz.media, Inhaber Kevin Adametz, In der Lake 4, 33739 Bielefeld, info@pressekonto.com +**Angebot:** pressekonto.com, presseecho.de, businessportal24.com +**Fassung:** 13.10.2026 (ersetzt die Entwürfe vom 09.10. und 12.10.2026) · **in Kraft gesetzt am:** [Datum des Deploy 3] · **nächste Überprüfung:** [Datum, spätestens 12 Monate danach] + +Dieses Dokument hält die Abwägung fest, auf die sich die DSE-Abschnitte „Bilder in Pressemitteilungen“ und „Beweisarchiv“ stützen. Es dient dem Nachweis nach Art. 5 Abs. 2 DSGVO und wird auf Anfrage der Aufsichtsbehörde vorgelegt. Es ist mit dem Code-Stand v1.8.0, dem Codeabgleich vom 12.10.2026 und den Betreiberentscheidungen vom 12. und 13.10.2026 abgeglichen. Punkte, die erst mit einer Umsetzung wahr werden, sind mit *(Ziel)* markiert; die DSE wird erst veröffentlicht, wenn sie umgesetzt sind. + +--- + +## 1. Gegenstand der Verarbeitung + +| Teil | Was | Wann | Wie lange | +|---|---|---|---| +| A | **Originaldatei** eines Bildes mit ihren Metadaten (Kameradaten, Urheberangaben, Herkunftsdaten; möglich auch Standortdaten und Geräteseriennummern), die **veröffentlichte Fassung** mit Bildnachweis und KI-Kennzeichnung, das Ergebnis der automatischen **Herkunftsauswertung** | bei jedem veröffentlichten Bild | solange die Mitteilung mit dem Bild veröffentlicht ist, danach Teil B | +| A | **Rechtebestätigung** des Hochladenden: Zeitpunkt, bestätigter Wortlaut und AGB-Fassung, Konto bzw. API-Zugang, Firma, Rolle des Erklärenden (Kontoinhaber oder Partner-API; *Ziel*, heute nur Kanal: Formular, API, Magic-Link), Übermittlungsweg, Prüfsumme der Datei, Angaben zu Bildnachweis und KI, mit geheimem Schlüssel gebildeter Prüfwert der IP-Adresse (HMAC), Browserkennung auf 250 Zeichen gekürzt | bei jedem Bild-Upload | wie oben | +| B | **Beweisarchiv:** zuletzt veröffentlichter Stand der Mitteilung einschließlich der darin genannten Pressekontakte (Name, E-Mail, Telefon); Einreicher (Konto, Name, E-Mail, Firma; *Ziel:* zum Zeitpunkt der Einreichung festgeschrieben, heute zum Zeitpunkt der Archivierung gelesen); die Daten aus Teil A; Zeitpunkte von Veröffentlichung und Entfernung; Grund als Kategorie; bei Änderungen vorheriger und neuer Stand; Bezug zum zugrunde liegenden Melde- oder Löschverfahren (*Ziel:* nur Vorgangsnummer; *heute:* einschließlich E-Mail-Adresse des Antragstellers; bereits versiegelte Pakete werden inventarisiert und nach anwaltlicher Antwort migriert oder befristet übergangsweise behalten) | wenn eine Mitteilung oder ein Bild aus dem öffentlichen Angebot entfernt, ersetzt oder geändert wird | drei Jahre nach Ende des Jahres der Entfernung; bei dokumentierter Aufbewahrungssperre bis zu deren Aufhebung, danach zum regulären Zeitpunkt oder zu einem neu begründeten Enddatum *(Ziel: Code setzt heute die Frist nach Aufhebung neu)* | +| B | **Restdaten nach Löschung (Löschvermerk):** Kennung, Objektschlüssel ohne Personenbezug, Ereignisart, Gegenstand, Zeitpunkte, Prüfsumme des gelöschten Inhalts, Schemaversion und Sicherungsstatus | mit der Löschung des Archivinhalts | bis zum späteren von 395 Tagen nach Löschung und 14 Tagen nach Ablauf der letzten rückspielbaren Sicherung *(Ziel: heute bleiben auch Akteur, Vermerke und Vorgangsverweise)* | +| B | **Einschränkung der Verarbeitung** (Art. 18): Kennzeichnung am Eintrag mit Grund, Zuständigem und Prüfdatum; normale Verwendung und Export gesperrt | auf Verlangen oder im Streitfall | bis zur dokumentierten Aufhebung *(Ziel: heute nur Aufbewahrungssperre, die lediglich die Löschung verhindert)* | +| B | **Zugriffsprotokoll:** Administrator, Aktion, angegebener Zweck, Zeitpunkt, bei Abruf archivierter Inhalte und bei Änderung einer Aufbewahrungssperre | bei jedem solchen Zugriff | 395 Tage ab Zugriff *(Ziel: heute unbefristet)* | + +**Nicht erfasst:** Bilder, die hochgeladen, aber nie veröffentlicht werden (sofortige Löschung bei Löschung oder Ersetzung durch den Kunden; unbearbeitete Entwürfe nach 180 Tagen), Nutzungs- oder Verhaltensdaten, Zahlungsdaten, sonstige Kontodaten. + +**Betroffene Personen:** Kontoinhaber und ihre Mitarbeiter (Einreicher), in Mitteilungen genannte Pressekontakte, auf Bildern abgebildete Personen, Urheber und Rechteinhaber, Antragsteller im Melde- und Löschverfahren (nur über die Vorgangsnummer verknüpft). + +**Zugriff:** Originaldateien aktiver Bilder: berechtigte Redaktion. Archivierte Inhalte: Administratoren mit Compliance-Berechtigung. Der Betreiber ist Einzelunternehmer; zwei Altkonten mit Administratorrechten werden gelöscht, die Rollen `admin` und `editor` werden danach vollständig geprüft (Betriebsnachweis). + +--- + +## 2. Berechtigtes Interesse + +1. **Nachweis gegenüber Rechteinhabern:** Macht ein Urheber oder Lizenzgeber Ansprüche wegen eines veröffentlichten Bildes geltend (§§ 97 ff. UrhG), muss belegbar sein, welche Datei mit welchen Angaben eingereicht wurde und was der Kunde dazu bestätigt hat. +2. **Nachweis gegenüber abgebildeten Personen** (§§ 22, 23 KUG) und Betroffenen, auch bei Schadensersatzforderungen nach Art. 82 DSGVO. +3. **Rückgriff gegen den Einreicher**, der die Rechte zugesichert hat (AGB § 8 Abs. 2, künftig § 8a Abs. 5). +4. **Nachweis gegenüber Behörden und Gerichten**, insbesondere zu Melde- und Abhilfeverfahren nach dem Digital Services Act und zur KI-Kennzeichnung (Art. 50 KI-VO). +5. **Nachvollziehbarkeit der eigenen KI-Kennzeichnung**, die das Portal aus Herkunftsdaten setzt. + +Diese Interessen sind rechtlich anerkannt (Rechtsdurchsetzung und -verteidigung, Erwägungsgrund 47) und konkret: Bildrechte-Abmahnungen sind bei Presseportalen ein typisches Risiko, und nach einer Entfernung auf Antrag liegt der Inhalt sonst nirgends mehr vor. + +Soweit ein Bild ausnahmsweise besondere Kategorien personenbezogener Daten erkennen lässt (Art. 9), stützt sich die Aufbewahrung zusätzlich auf Art. 9 Abs. 2 lit. f (Geltendmachung, Ausübung oder Verteidigung von Rechtsansprüchen). Das Portal hat das Bild nicht erhoben, sondern vom Kunden zur Veröffentlichung erhalten; die Aufbewahrung ist nicht öffentlich. + +--- + +## 3. Erforderlichkeit + +| Datum | Warum erforderlich | Geprüfte mildere Mittel | +|---|---|---| +| Originaldatei mit Metadaten | Nur das Original zeigt, welche Urheber- und Herkunftsangaben der Kunde mitgeliefert hat; die öffentlichen Varianten sind verkleinert und ohne Metadaten. Legt ein Anspruchsteller ein abweichendes Bild vor, belegt nur das Original den Inhalt. | Nur Prüfsumme und Metadatenauszug: belegt die Identität einer vorgelegten Datei, nicht deren Inhalt. Entfernen von Standort- und Gerätedaten aus dem gespeicherten Original: verändert die Beweisdatei und entwertet die Prüfsumme; Seriennummern können zudem die Urheberschaft belegen. Verworfen. Standort- und Gerätedaten werden nicht ausgewertet und nie veröffentlicht. | +| Rechtebestätigung mit Wortlaut, Fassung, Konto, Rolle, Zeitpunkt | Belegt, wer in welcher Rolle was wann zugesichert hat; Grundlage des Rückgriffs. Erklärender ist immer ein gebundener Vertragspartner (Kontoinhaber oder Partner); ein Bild-Upload ohne Konto gibt es nicht | keines; ohne diese Angaben ist die Bestätigung nicht nachweisbar | +| IP-Prüfwert und Browserkennung | Zusätzlicher Beleg, dass die Bestätigung aus der Sitzung des Kontos stammt (etwa bei bestrittener Abgabe durch einen Mitarbeiter) | IP im Klartext: verworfen, nur HMAC. Browserkennung: Kürzung auf 250 Zeichen; eine weitere Kürzung bringt keinen Gewinn, da die Kennung nur im Streitfall gelesen wird | +| Archiv: letzter veröffentlichter Stand mit Pressekontakten | Belegt, was öffentlich war, auch nach Löschung auf Antrag; die Kontaktzeile kann Gegenstand der Beanstandung sein | Nur Text ohne Kontaktangaben: verworfen | +| Archiv: Einreicher (Konto, Name, E-Mail, Firma) | Rückgriff setzt voraus, dass der Einreicher auch nach Kontolöschung identifizierbar bleibt | Nur Konto-ID: verworfen, nach Kontolöschung nicht mehr auflösbar. Weitere Kontodaten (Rechnungsdaten, Zahlungsdaten): nicht aufgenommen | +| Archiv: bei Änderungen alter und neuer Stand | Belegt Umfang und Zeitpunkt einer Korrektur | nur der neue Stand: verworfen | +| Archiv: Vorgangsnummer statt Antragstellerdaten *(Ziel)* | Verknüpfung zum Meldevorgang genügt; die Antragstellerdaten liegen dort mit eigener Frist | Antragsteller-E-Mail im Archiv: verworfen (Doppelspeicherung); heute noch enthalten, Altbestand wird gesondert behandelt | +| Zugriffsprotokoll | Erkennung von Fehlgebrauch; Nachweis der Zweckbindung gegenüber Betroffenen und Aufsicht | kürzer als 395 Tage: Beschwerden über Zugriffe kommen verzögert; länger: kein zusätzlicher Nutzen | + +**Frist drei Jahre nach Jahresende, je Ereignistyp:** + +| Ereignis | Warum drei Jahre | +|---|---| +| Veröffentlichtes Bild entfernt oder ersetzt | Urheberrechtliche Ansprüche verjähren regelmäßig in drei Jahren ab Jahresende der Kenntnis (§§ 195, 199 BGB); die Kenntnis des Rechteinhabers liegt typischerweise nahe am Zeitpunkt der Entfernung, weil die Entfernung oft auf seinen Hinweis erfolgt | +| Mitteilung depubliziert (Antrag, Meldeverfahren, eigene Entscheidung, Laufzeitende) | Ansprüche Dritter aus dem Inhalt und Rückgriff gegen den Einreicher, gleiche Verjährung | +| DSGVO-Änderung (Schwärzung, Pseudonymisierung) | Nachweis der Erfüllung eines Betroffenenrechts bei späterer Beschwerde oder Klage nach Art. 82; Verjährung drei Jahre | +| Kennzeichnungskorrektur | Nachweis gegenüber Kunde und Aufsicht, dass und warum eine Kennzeichnung geändert wurde; Beanstandungen nach Art. 50 KI-VO und UWG können nachlaufen | + +Die Frist ist eine betriebliche Regel, die sich an der Regelverjährung orientiert; sie bildet nicht jeden Verjährungsbeginn ab. Für konkret bekannte Ansprüche greift die Aufbewahrungssperre mit dokumentiertem Enddatum. + +--- + +## 4. Abwägung mit den Interessen der Betroffenen + +**Art der Daten:** überwiegend Daten, die zuvor öffentlich waren (Mitteilung, Bild, Pressekontakt) oder geschäftlich vom Kunden selbst angegeben wurden. Original-Metadaten können Standortdaten und Geräteseriennummern enthalten; sie werden nicht veröffentlicht und nicht ausgewertet. Bilder können ausnahmsweise besondere Kategorien erkennen lassen (Abschnitt 2, letzter Absatz). + +**Vernünftige Erwartungen:** Der Hochladende gibt die Bestätigung ausdrücklich ab und wird dabei auf AGB und Datenschutzerklärung hingewiesen. Bei einem Presseportal ist erwartbar, dass Veröffentlichungen und Zusicherungen zu Bildrechten dokumentiert werden. Pressekontakte und abgebildete Personen rechnen nicht mit einer Archivierung nach der Entfernung; die DSE informiert darüber in einem eigenen Abschnitt, und die Archivierung ist nicht öffentlich. + +**Risiken und Gegenmaßnahmen:** + +| Risiko | Maßnahme | +|---|---| +| Sensible Motive bleiben nach Entfernung im Original erhalten | Archivpakete anwendungsseitig verschlüsselt (AES-256, eigener Schlüssel außerhalb der Datenbank); Zugriff nur mit Compliance-Berechtigung und Zweckangabe, keine Auswertung, feste Frist; Grundlage Art. 9 Abs. 2 lit. f. Originaldateien aktiver Bilder liegen außerhalb des öffentlichen Speichers; ihre gesonderte Verschlüsselung ist durch den Code nicht belegt (Betriebsnachweis zur Infrastrukturverschlüsselung offen) | +| Archivierung ohne Kenntnis der Pressekontakte und Abgebildeten | DSE-Abschnitt „Beweisarchiv“; Hinweis in jedem Schreiben zu Löschanträgen („gelöscht“ nie ohne Archivhinweis); Auskunft nach Art. 15 umfasst Archivinhalte | +| Standort- und Gerätedaten im Original | nicht veröffentlicht, nicht ausgewertet, verschlüsselt; öffentliche Fassungen ohne diese Metadaten | +| Fehlgebrauch durch Administratoren | nur zwei Administratorkonten, zweiter Faktor Pflicht, Zweckangabe bei jedem Abruf, Zugriffsprotokoll, Änderungen am Protokoll gesperrt | +| Aufbewahrung über den Zweck hinaus | automatische Löschung mit Löschbeleg; Aufbewahrungssperre nur mit Pflichtvermerk, Prüfdatum (90 Tage) und bekanntem Enddatum; kein Fristneustart; Einschränkung nach Art. 18 getrennt *(Ziel)* | +| Wiederherstellung gelöschter Einträge aus Sicherungen | Sicherungen 14 Tage; getrennt gesicherter Löschstand, Abgleich nach jeder Wiederherstellung; Übung vor Veröffentlichung *(Ziel)* | +| Restdaten mit Personenbezug nach Löschung | Reduktion auf Kennung, Ereignisart, Zeitpunkte, Prüfsumme *(Ziel)* | + +**Auswirkungen auf die Betroffenen:** Die Archivierung verlängert die Verfügbarkeit eines Inhalts, den der Betroffene entfernt haben wollte, und eröffnet damit Offenlegungs- und Missbrauchsrisiken, auch für zuvor nicht öffentliche Metadaten und Kontaktangaben. Das Archiv ist nicht öffentlich und wird nicht ausgewertet; für Antragsteller einer Löschung bleibt der öffentliche Zustand entfernt. Das verbleibende Risiko wird durch die Maßnahmen oben und die feste Frist begrenzt; das Ergebnis in Abschnitt 5 steht unter dem Vorbehalt, dass die mit *(Ziel)* markierten Maßnahmen umgesetzt sind. + +**Betroffenenrechte:** + +- Auskunft (Art. 15) wird erteilt und umfasst Archivinhalte zur Person. +- Löschanträge zu Archiveinträgen werden im Einzelfall geprüft: Welcher Anspruch, wessen, warum noch möglich. Ergebnis und Grundlage (Art. 17 Abs. 3 lit. e oder Löschung) werden am Vorgang vermerkt. Keine pauschale Ablehnung wegen laufender Frist. +- Bei Widerspruch (Art. 21) wird geprüft, ob zwingende schutzwürdige Gründe (Rechtsverteidigung) überwiegen; Ergebnis am Vorgang. +- Einschränkung (Art. 18) wird technisch über die Aufbewahrungssperre mit dem Vermerk „eingeschränkt auf Antrag“ abgebildet. + +**Vermerkvorlage Löschantrag:** + +> Antrag vom [Datum], Vorgang [Nr.]. Betroffen: Archiveintrag [ID], Ereignis [Typ], entfernt am [Datum]. Möglicher Anspruch: [Urheber / abgebildete Person / Betroffener nach Art. 82 / Rückgriff gegen Einreicher], Verjährung voraussichtlich [31.12.20xx]. Ergebnis: Aufbewahrung erforderlich nach Art. 17 Abs. 3 lit. e bis [Datum] / Löschung veranlasst. [Name, Datum] + +--- + +## 5. Ergebnis + +Die Interessen des Verantwortlichen an Nachweis, Rechtsverteidigung und Rückgriff überwiegen. Die Daten sind auf das für diese Zwecke Erforderliche beschränkt, überwiegend zuvor öffentlich, nicht öffentlich zugänglich, verschlüsselt und zugriffsprotokolliert gespeichert und werden nach einer an der Verjährung ausgerichteten Frist automatisch gelöscht. Die Verarbeitung stützt sich auf Art. 6 Abs. 1 lit. f DSGVO, bei besonderen Kategorien zusätzlich auf Art. 9 Abs. 2 lit. f; über Löschanträge wird im Einzelfall nach Art. 17 Abs. 3 lit. e entschieden. + +--- + +## 6. Offene Punkte und Überprüfung + +- [ ] Umsetzung der mit *(Ziel)* markierten Punkte: Vorgangsnummer statt Antragsteller-E-Mail, Einreichungsnachweis zum Einreichungszeitpunkt, Rolle des Erklärenden, Hold-Ende ohne Fristneustart, Einschränkung nach Art. 18, Löschvermerk-Reduktion, Zugriffsprotokoll 395 Tage, getrennter Löschstand, Restore-Übung in vier Szenarien (Datenbank alt, Archivspeicher alt, beide alt, externes Ziel nicht erreichbar). +- [ ] Inventar der bereits versiegelten Archivpakete mit Antragsteller-E-Mails und Migrationsentscheidung nach anwaltlicher Antwort. +- [ ] Betriebsnachweis zur Verschlüsselung der aktiven Originaldateien. +- [ ] Prüfung und Bereinigung alter Deploy- und Migrationssicherungen, damit die 14-Tage-Aussage für alle Kopien gilt. +- [ ] Anwaltliche Prüfung (Anwaltspaket, Frage 3). +- Überprüfung dieses Dokuments: nach der Anwaltsantwort, bei Einführung der C2PA-Signaturprüfung, bei Bildern von API-Partnern, bei Bildern im Newsroom und spätestens nach 12 Monaten. + +--- + +**Abgezeichnet (erst nach Umsetzung der Zielmaßnahmen und anwaltlicher Antwort):** Kevin Adametz, Inhaber adametz.media, Bielefeld, [Datum] diff --git a/dev/rechtliches/klaerung-anwaltspaket-2026-10-12.md b/dev/rechtliches/klaerung-anwaltspaket-2026-10-12.md new file mode 100644 index 00000000..df1b6c0b --- /dev/null +++ b/dev/rechtliches/klaerung-anwaltspaket-2026-10-12.md @@ -0,0 +1,597 @@ +# Klärung Anwaltspaket: Entscheidungen, Antworten, Textänderungen + +**Stand:** 12.10.2026 · **Gehört zu:** [Versandfassung](anwaltspaket-datenschutz-2026-10-12.md) (Anlage 4), [Interessenabwägung](interessenabwaegung-beweisarchiv-2026-10-12.md), [Decision-Update Bildrechte](../bildrechte/Decision-Update_Bildrechte_Beweisarchiv_2026-09-22.md); Vorfassungen und Codeauswertung in [`dev/archive/rechtliches-2026-10/`](../archive/rechtliches-2026-10/) +**Grundlage:** Live-Rechtstexte vom 12.10.2026 (DSE 0.3 Hub und Portale, AGB 0.6, Boost), Antworten auf die neun Rückfragen, Betreiberangaben vom 12.10.2026 (unten), Codeabgleich aus der Auswertung. +**Status:** Entscheidungen vom 12. und 13.10.2026 eingearbeitet (Boost-Label, Refund-Modell B, Gate-Mechanik, Bestätigungsrollen beim Upload); Korrekturen aus `korrekturen-und-umsetzungsauftrag-2026-10-12.md` übernommen. Führende Aufgabenkennungen sind RP-01 bis RP-12 und BN-01 bis BN-09 aus dieser Datei; die U-Nummern in Abschnitt 11 verweisen darauf. Rechtliche Aussagen sind Einordnungen mit Begründung, keine Rechtsberatung. Jede Position ist so formuliert, dass der Anwalt sie bestätigen oder mit einem Satz kippen kann. + +--- + +## 0. Wie dieses Dokument zu lesen ist + +Jede Frage bekommt eine von drei Einstufungen: + +| Einstufung | Bedeutung | +|---|---| +| **G** Geschäftsentscheidung | Du entscheidest. Der Anwalt bekommt sie als Information, nicht als Frage. | +| **R+** Rechtliche Einordnung mit Default | Ich habe eine begründete Position. Der Anwalt bestätigt sie oder widerspricht. Bis dahin wird nach dem Default gebaut. | +| **R** Echte Rechtsfrage | Bleibt offen. Ich nenne meine Lesart und das Risiko, aber die Antwort entscheidet, was gebaut wird. | + +Betreiberangaben vom 12.10.2026, auf denen dieses Dokument aufbaut: + +1. AVV: Hetzner und ALL-INKL liegen vor. Cloudflare (Turnstile) und Stripe sind über deren Standardbedingungen abgedeckt. OpenAI: API über OpenAI Ireland, Zero Data Retention eingerichtet. +2. Die Admin-Konten `@me.com` und `@stern-consulting.eu` sind Altbestände. Einziges aktives Admin-Konto ist das Betriebskonto unter `@pressekonto.com` (Betreiberangabe 13.10.2026). Ablauf der Bereinigung: `nachweise/bn-02-ablauf.md`. +3. Zustimmungsgate (S12): seit 28.09.2026 mit Deploy 1b live, aber ausgeschaltet (`LEGAL_ACCEPTANCE_GATE=false`). Einschalten mit Deploy 3 zusammen mit AGB 0.7. Die Alt-API (`/service/…`, connektar) prüft das Gate nicht. +4. Go-Live-Mails im Juli: nicht an alle. Konten mit laufendem Abonnement erhielten eine Mail zu Bestandsschutz und Relaunch; Konten mit Anmeldung im letzten Jahr eine Info-Mail zum Relaunch; beide mit Abmeldelink. + +--- + +## 1. Was sich gegenüber dem Paket vom 09.10. ändert + +| Bereich | Vorher | Jetzt | +|---|---|---| +| Aktivitätsverlauf | 395 Tage einheitlich | Anmelde- und Fehlversuchsereignisse 90 Tage, übrige Ereignisse 395 Tage, API 90 Tage (E4) | +| Letzte Anmelde-IP | Überschrieben, keine Frist | Zusätzlich Löschung 90 Tage nach letzter Anmeldung (E3) | +| Legal Hold | Frist startet nach Aufhebung neu | Kein Neustart; reguläre Frist bleibt, neue Frist nur mit dokumentiertem Grund (E6) | +| Archiv-Restdaten | Tombstone mit Akteur und Vermerken | Nur Kennungen, Zeitpunkte, Hash; Zugriffsprotokoll 395 Tage (E7) | +| Archivdatensatz | Drei verschiedene Beschreibungen | Ein Datensatz, in DSE, Paket und Abwägung gleich (Abschnitt 4.4) | +| Fehlerprotokoll | Absolute Zusage „keine Namen, IPs, Formularinhalte“ | Enger formuliert, Transportlogs getrennt genannt (F2) | +| KI-Anbieter in DSE 10/8 | OpenAI, Gemini, Anthropic | Nur OpenAI, mit Zero Data Retention | +| Alt-API KI-Angabe | Setzt „ohne KI“ im Namen des Kunden | `not_declared`, keine Erklärung ohne Erklärenden (A6) | +| Boost-Label | „Top-Platzierung“ | „Gebuchte Platzierung“ mit Erklärung (Abschnitt 6) | +| AGB § 6 Abs. 2 | Kennt nur Startseiten-Boost | Kategorie-Boost und Kennzeichnung ergänzt (A1) | +| Umami Kundenbereich, KI-Bildprüfung, Newsletter | Fragen im Paket | Aus dem Paket herausgenommen, als spätere Aktivierungen mit eigener Checkliste (F6, F9, F7) | +| Portal-DSE Abschnitt 7 | „15 Minuten“ | Zwei Fristen: Zugangslink 15 Minuten, Meldebestätigungslink 72 Stunden; Link-Datensätze 30 Tage nach Verbrauch gelöscht | +| Archivdatensatz Ist/Ziel | „Vorgangsnummer statt Antragsteller-E-Mail“ als Ist | Heute enthält das Archiv die Antragsteller-E-Mail und liest Firma/Einreicher zum Archivierungszeitpunkt; beides wird Ziel, versiegelte Pakete bekommen eine Migrationsentscheidung | +| Gate-Mechanik | „Mit der Verlängerung gilt 0.7“ | Keine Umstellung ohne Zustimmung; Alt-Credits und laufende Abos ohne Gate; Umstellung nur per Änderungskündigung | +| Self-Service-Bilder | Pressekontakt bestätigt „handelnd für Firma“ | Bild-Upload im Self-Service nur mit Konto | +| Legal Hold | nur Löschstopp | Sperre und Einschränkung nach Art. 18 getrennt, Prüfdatum 90 Tage | + +--- + +## 2. Fragen F1 bis F11 + +### F1 Nummerierung je Host · **G** + +**Entscheidung:** Beide Hosts bekommen die Bild-Abschnitte als eigene Abschnitte direkt hinter „Automatisierte Inhaltsprüfung“ (Hub: nach 10, Portale: nach 8). Die Nummern bleiben je Host unterschiedlich; Querverweise im Text nennen den Abschnittstitel, nicht die Nummer, und jeder Abschnitt bekommt einen stabilen Anker (`#bilder`, `#beweisarchiv`, `#fehlerprotokoll`, `#kontosicherheit`). + +**Begründung:** Eine Vereinheitlichung der Nummern würde die bestehenden Hub-Abschnitte 7 bis 9 verschieben, ohne rechtlichen Gewinn. Transparenz verlangt Auffindbarkeit, nicht gleiche Ziffern. + +**Umsetzung:** Anker im Template; „Abschnitt 9b“ in allen Entwürfen durch „Abschnitt Beweisarchiv“ ersetzen. + +### F2 Fehlerprotokoll ohne Einwilligung · **R+** + +**Position:** Serverseitig Art. 6 Abs. 1 lit. f, ohne weitere Voraussetzungen. Browserseitig zusätzlich § 25 Abs. 2 Nr. 2 TDDDG, weil das Fehler-SDK Informationen aus dem Endgerät ausliest (Stack, URL, Browserkennung) und überträgt. Die Ausnahme trägt nur, wenn das Skript erst im Fehlerfall lädt, nichts im Endgerät speichert, keine Sitzung verfolgt und der Datensatz auf das Technische begrenzt ist. Das ist der heutige Stand; er muss so bleiben. + +**Warum nicht einfach „Ja“:** Die Aufsicht legt „Zugriff auf Informationen im Endgerät“ weit aus (EDSA-Leitlinien 2/2023). Die Rechtfertigung hängt an der Minimierung, nicht an der Cookielosigkeit. + +**Textänderung (3a):** Die absolute Zusage wird ersetzt. Neu: + +> IP-Adressen, Cookies, Formulareingaben und Inhalte von Anfragen werden nicht in den Fehlerbericht aufgenommen; E-Mail-Adressen in Fehlertexten werden vor der Übermittlung ersetzt. Technische Freitexte eines Fehlers können im Einzelfall weitere Angaben enthalten; wir werten Fehlerberichte ausschließlich zur Fehlerbehebung aus. Übermittelt Ihr Browser einen Bericht, sieht der Fehlerserver wie jeder Webserver die Verbindungsdaten Ihres Browsers; für diese Verbindungsdaten gelten die Fristen aus Abschnitt 3 (14 Tage). + +**Umsetzung vor 0.4:** Scrubber nach K7 nachschärfen (freigegebene Query-Werte prüfen, keine Objektinhalte als Fehlertext), GlitchTip-Instanz auf 90 Tage Aufbewahrung belegen, Proxy-Logs des Fehlerservers auf 14 Tage. + +### F3 Aktivitätsverlauf · **G**, Verhältnismäßigkeit **R+** + +**Entscheidung (E4):** + +| Ereignisart | Frist | Begründung | +|---|---|---| +| Anmeldungen, Fehlversuche, Sperren bekannter Konten | 90 Tage | Sicherheitszweck ist nach drei Monaten erfüllt; Vorfälle werden einzeln länger gehalten (Vermerk) | +| Tagessummen fehlgeschlagener Anmeldungen (unbekannte Adressen) | 90 Tage | wie oben | +| Registrierungen, Statuswechsel, Anfragen, Administratorhandlungen | 395 Tage | Support, Nachvollziehbarkeit von Vorgängen über ein Jahr plus Monat | +| Mailversand mit Empfänger und Betreff, auch an Nichtkunden | 395 Tage | Nachweis, dass und wann eine Benachrichtigung ging; Beschwerden kommen oft Monate später | +| API-Zugriffsprotokoll | 90 Tage | Betrieb und Abrechnungsnachweis; Rechnungen selbst liegen woanders | + +Zugriff: nach Löschung der zwei Altkonten nur noch `@pressekonto.com` und Betreiber. Keine eigene Berechtigungsstufe nötig, solange es zwei Konten sind. + +**Für den Anwalt:** Die 395 Tage für Mail-Einträge zu Nichtkunden (5.007 von 7.642 Einträgen betreffen Pressekontakte ohne Konto) sind der einzige Punkt, bei dem ich eine Bestätigung will. Mein Argument: Es ist der Nachweis einer Benachrichtigung, die ihrerseits lit. f gestützt ist; ohne Protokoll könnte das Portal auf „Sie haben mich nie informiert“ nichts erwidern. + +**Umsetzung:** `prunable()` je Ereignistyp (U4); Textentwurf 7b wird angepasst (Abschnitt 8). + +### F4 IP-Adresse der letzten Anmeldung · **R+** + +**Position:** Vertretbar unter lit. b und f. Die Anzeige der letzten Anmeldung mit IP ist eine anerkannte Sicherheitsfunktion; eine gekürzte IP wäre für den Kunden nicht wiedererkennbar und damit nutzlos. Ergänzung (E3): Löschung 90 Tage nach der letzten Anmeldung, damit inaktive Konten keine Klartext-IP über Jahre tragen. + +**Text (7a):** „… beides sehen Sie auf der Seite ‚Konto-Sicherheit‘. Die Angabe wird bei jeder Anmeldung überschrieben und 90 Tage nach Ihrer letzten Anmeldung gelöscht.“ + +**Umsetzung:** U1. + +### F5 Sperrliste, Rohmails, Rechtsgrundlage · **R+** + +**Entscheidung (E5):** Rohmails im Rückläufer-Postfach 90 Tage (alle Ordner: `Processed`, `Ignored`, `Unparsed`). Ausgewertete Zustellmeldungen 395 Tage. Sperrliste zweckgebunden ohne feste Frist. + +**Rechtsgrundlage, aufgelöst:** Das Paket war an dieser Stelle unentschieden (D4 nennt lit. c, F5 sagt lit. f genügt). Ich trenne nach Sperrgrund: + +| Sperrgrund | Grundlage | +|---|---| +| Dauerhaft unzustellbar (Hard Bounce) | lit. f: Schutz der Zustellbarkeit und Reputation | +| Abmeldung / Widerspruch | lit. f, zusätzlich lit. c in Verbindung mit Art. 21 Abs. 3 DSGVO und § 7 Abs. 3 Nr. 4 UWG: die Beachtung des Widerspruchs ist eine Pflicht, die ohne die Adresse nicht erfüllbar ist | + +**Zwei Präzisierungen, die die Auswertung gefunden hat:** (1) „keine Mails mehr“ stimmt nicht; selbst angeforderte Anmeldelinks gehen weiterhin. Text: „keine Benachrichtigungen mehr; von Ihnen selbst angeforderte Anmeldelinks bleiben möglich“. Nur der Anmeldelink ist heute von der Abmeldesperre ausgenommen; der Meldebestätigungslink ist eine andere Mailklasse. Erweiterung auf angeforderte Bestätigungen als eigene Versandregel (RP-08). Link-Datensätze werden 30 Tage nach Verbrauch oder Ablauf gelöscht, das gehört in Abschnitt 13. (2) Entsperrung: auf Anfrage an info@pressekonto.com, Hard-Bounce-Sperren zusätzlich bei nachgewiesener Zustellbarkeit. + +**Option, keine Pflicht:** Sperrliste als HMAC der normalisierten Adresse statt Klartext. Abgleich beim Versand über denselben HMAC, Entsperrung über die vom Nutzer genannte Adresse. Datenminimierung ohne Funktionsverlust. Phase 2. + +**Umsetzung:** U5; Text 12a angepasst (Abschnitt 8). + +### F6 Webanalyse im Kundenbereich · **G** + +**Entscheidung:** Bleibt aus (`UMAMI_PORTAL_ENABLED=false`, `UMAMI_IDENTIFY_USERS=false`). Aus dem Paket herausgenommen. Der Satz „Es werden keine Nutzerprofile erstellt“ bleibt richtig. Der Textentwurf „5 Ergänzung Webanalyse im Kundenbereich“ entfällt in 0.4. + +**Falls später gewünscht,** Aktivierungsbedingungen: Nutzer-ID nur als HMAC, nicht `user-`; Widerspruchsschalter im Konto; eigener DSE-Absatz; Rohdatenfrist der Instanz auf 13 Monate. Grundlage dann lit. f mit Widerspruch, keine Einwilligung nötig, solange keine Zusammenführung mit anderen Daten erfolgt. + +**Nebenbefund:** Für die Umami-Instanz auch heute eine Rohdatenfrist einstellen (13 Monate, passend zu 5a). Betriebsaufgabe, kein DSE-Thema. + +### F7 Newsletter und Altkonten · **G**, § 7 Abs. 3 UWG **R+** + +**Entscheidung:** Nur Opt-in. Doppelte Bestätigung per E-Mail. Protokoll je Einwilligung: Zeitpunkt, Adresse, Fassung des Einwilligungstextes, Quelle (Kontoschalter, Formular), Bestätigungszeitpunkt, Widerruf. Keine IP-Adresse; die Bestätigung über den Link ist der Nachweis. `CampaignRecipients` muss auf nachgewiesene Einwilligung umgestellt werden, bevor die Sperre fällt (U-Aufgabe, eigenes Paket). + +**§ 7 Abs. 3 UWG für die Altkonten:** Nein, aus drei Gründen. Die Ausnahme setzt eine Adresse voraus, die im Zusammenhang mit dem Verkauf einer Ware oder Dienstleistung erhoben wurde; über 99 Prozent der 66.368 Altkonten haben nie etwas gekauft. Für die 445 zahlenden Konten müsste bei der Erhebung auf das Widerspruchsrecht hingewiesen worden sein; die alte Datenschutzerklärung liegt nicht vor, der Nachweis ist nicht führbar. Und die Werbung müsste für ähnliche Leistungen sein; ein Relaunch-Newsletter eines neuen Angebots ist das für ein 2012 angelegtes Gratiskonto kaum. + +**Die Juli-Mails sind nach deiner Beschreibung in Ordnung, die Texte müssen das bestätigen:** Mails an Abonnenten zu Bestandsschutz und Relaunch sind Vertragsinformation (lit. b). Die Info-Mail an Konten mit Anmeldung im letzten Jahr ist eine Mitteilung über die Änderung eines Dienstes, den die Empfänger nutzen (Nutzungsverhältnis des Kontos), keine Werbung, solange sie keine Angebote bewarb. Beide hatten Abmeldelinks. Beide Mailtexte mit Versanddatum und Empfängerregel in den Rechtsordner legen; das ist der Nachweis, falls jemand fragt. + +### F8 Turnstile · **R+** + +**Position:** lit. f plus § 25 Abs. 2 Nr. 2 TDDDG trägt für Bot-Schutz an Formularen, die Missbrauch auslösen können (Mailversand an fremde Adressen). Stärker als bei reCAPTCHA, weil Cloudflare für Turnstile keine Werbeprofile bildet. Drittland: Cloudflare, Inc. ist unter dem EU-US DPF zertifiziert; Status vor Versand auf dataprivacyframework.gov prüfen und das Datum notieren. + +**Textänderungen (6a):** + +- Ergänzen: „Bei der Prüfung übermittelt auch unser Server die IP-Adresse, von der das Formular gesendet wurde, an Cloudflare, damit das Ergebnis der Prüfung dieser Anfrage zugeordnet werden kann.“ +- Ergänzen: „Ist der Dienst nicht erreichbar, nehmen wir die Eingabe an und prüfen sie intern auf Missbrauch.“ +- Formularliste erweiterbar formulieren: „im Kontaktformular, bei der Registrierung und in weiteren Formularen, die Missbrauch auslösen können (zum Beispiel Melde-, Widerrufs- und Kündigungsformular)“. Dann muss 6a bei Roadmap 4.4 nicht angefasst werden. + +### F9 KI-Vorabprüfung von Bildern · **G**, Aktivierungsbedingungen **R** + +**Entscheidung:** Bleibt aus. Aus dem Paket herausgenommen. Entwurf „9a Ergänzung KI-Vorabprüfung“ entfällt in 0.4. + +**Was vor einer Aktivierung feststehen muss** (Checkliste, dem Anwalt als spätere Frage): + +| Punkt | Stand | Offen | +|---|---|---| +| Vertragspartner | OpenAI Ireland Ltd. | Bestätigung in den Organisationseinstellungen | +| AVV | Online-DPA von OpenAI | Abschlussdatum notieren | +| Speicherung beim Anbieter | Zero Data Retention eingerichtet (Betreiberangabe) | Schriftliche Bestätigung oder Screenshot der Einstellung; prüfen, ob ZDR auch für Bildeingaben gilt, OpenAI nennt Ausnahmen | +| Drittlandübermittlung | Datenresidenz EU verfügbar | Ob aktiviert: [ja/nein]; sonst SCC/DPF nennen | +| Art. 9 | Prüfung „Person erkennbar ja/nein“ ist keine biometrische Verarbeitung (kein Template, keine Identifizierung) | Bilder können zufällig besondere Kategorien zeigen; Grundlage dann Art. 9 Abs. 2 lit. f (Rechtsverteidigung) oder lit. e (vom Betroffenen veröffentlicht), Einzelfall | +| DSFA | Keine Pflicht nach DSK-Muss-Liste (keine Bewertung persönlicher Aspekte, keine Überwachung) | Kurze Schwellwertprüfung dokumentieren | +| Art. 22 | Automatische Ablehnung betrifft ein Bild, keine Person; Weg zum Menschen offen | nichts | + +**Frage an den Anwalt:** Genügen AVV, ZDR-Nachweis, Minimierung und die dokumentierte Schwellwertprüfung, oder will er eine förmliche DSFA? + +### F10 Art. 50 KI-VO für Portal-Updates · **R+** (zusammen mit A6) + +**Rechtslage:** Art. 50 gilt seit dem 2. August 2026. Abs. 4 Satz 2 verpflichtet Betreiber, die KI-generierten Text veröffentlichen, um die Öffentlichkeit über Angelegenheiten von öffentlichem Interesse zu informieren, zur Offenlegung; ausgenommen, wenn der Text einer menschlichen Überprüfung oder redaktionellen Kontrolle unterlag und eine Person die redaktionelle Verantwortung trägt. + +**Position für Portal-Updates:** Produkt-Changelogs sind schon keine „Angelegenheiten von öffentlichem Interesse“. Unabhängig davon greift die Ausnahme, wenn die Überarbeitung belegbar ist. Beides zusammen reicht. + +**Entscheidung, damit es belegbar ist:** Pro Artikel speichern: KI-Entwurf, veröffentlichte Fassung, Diff, Freigebender, Zeitpunkt. In der Rubrik „Pressekonto“ eine feste Zeile: „Artikel dieser Rubrik entstehen mit KI-Unterstützung und werden vor Veröffentlichung von Kevin Adametz geprüft und freigegeben.“ Das ist keine Pflicht, passt aber zu Anti-Zombie und kostet nichts. Modell: `OPENAI_MODEL` wie bei den Prüfungen. + +**Was nicht geht:** Die Ausnahme auf Kundenmeldungen übertragen. Dort ist der Kunde Betreiber im Sinne der KI-VO; das Portal zeigt seine Erklärung an (siehe A6). + +### F11 Versionierung der DSE · **G** + +**Entscheidung:** Fassung 0.4 mit Datum und einem Änderungshinweis am Ende, der die Ergänzungen seit 0.3 auflistet (5a vom 21.09., 6a vom 09.10., die Abschnitte aus 0.4). Jede Fassung bleibt unter einer festen URL abrufbar (`/datenschutz/v0.3`). Eine DSE-Änderung braucht keine Zustimmung; das Gate gilt nur für AGB und Richtlinien. + +--- + +## 3. Anwaltsagenda A1 bis A7 + +### A1 AGB-Konsistenz § 8a und § 9 · **R** + +**Meine Lesart:** Die Texte aus dem Decision-Update halten im B2B nach § 307. + +- § 8a Abs. 5 verweist auf die verschuldensabhängige Freistellung in § 8 Abs. 2. Das ist die sichere Variante; eine verschuldensunabhängige Freistellung in AGB wäre angreifbar. +- § 9 Abs. 1a (Feeds, Open Graph): Die Vervielfältigung durch soziale Netzwerke beim Teilen stützt sich ohnehin auf die stillschweigende Einwilligung dessen, der Inhalte ohne technische Sperre ins Netz stellt (BGH, Vorschaubilder). Abs. 1a macht das ausdrücklich. Der Konflikt mit Abs. 2 ist durch den letzten Satz gelöst. +- „Wahrung der wesentlichen Bildaussage“: Zuschnitte für Vorschauen und ein Nachweisbalken sind Änderungen, die der Urheber nach § 39 Abs. 2 UrhG nach Treu und Glauben nicht versagen kann. Reicht. +- § 9 Abs. 4: Die nichtöffentliche Speicherung zur Beweissicherung nach Ende der Veröffentlichung ist eine Vervielfältigung und braucht die Einräumung. Ist drin. + +**Zwei kleine Ergänzungen für 0.7:** + +1. § 8a Abs. 1 Satz 1: „… einschließlich des Rechts, dem Anbieter die Nutzungen und Bearbeitungen nach § 9 einzuräumen.“ (Der Kunde ist oft nicht der Urheber; seine Lizenz muss Bearbeitungen decken.) +2. § 6 Abs. 2 Boost: Kategorie-Boost aufnehmen und die Kennzeichnung festschreiben. Textvorschlag in Abschnitt 6. + +**Frage an den Anwalt bleibt:** Gesamtfreigabe § 8a, § 9 Abs. 1, 1a, 2, 4 und § 6 Abs. 2 neu. + +### A2 Hoster-Status und UrhDaG · **R** + +**Meine Lesart:** Hoster-Status nach Art. 6 DSA bleibt erhalten. Automatisierte Vorprüfung (Spam, Kategorie, formale Qualität) ist freiwillige Untersuchung nach Art. 7 DSA. Kein Zu-eigen-Machen, solange keine inhaltliche Bearbeitung und keine Darstellung als eigener Inhalt. Die Verantwortlich-Zeile am Bild stützt das. + +**Zwei Dinge, die der Anwalt sehen muss:** + +1. **DSE Abschnitt 9 (Portale) beruft sich auf das Medienprivileg** (Art. 85 DSGVO, § 57 MStV). Das steht in Spannung zu A2: Wer Hoster ohne redaktionelle Bearbeitung ist, hat Mühe, journalistisch-redaktionelle Zwecke zu reklamieren. Die DSE formuliert mit „soweit“, das ist richtig. Meine Empfehlung: Wortlaut behalten, im Einzelfall nie allein auf das Medienprivileg stützen (das Löschanfragen-Handover sagt das in Säule 3 bereits). Frage: Hält der Anwalt den Absatz in dieser Hedge-Form für unschädlich, oder soll er auf „Archivfunktion und Informationsfreiheit, Art. 17 Abs. 3 lit. a“ umgestellt werden? +2. **„Redaktionelle Qualität“** steht in AGB § 4 Abs. 4 und § 7 Abs. 1. In 0.7 durch „Qualität und Lesbarkeit der Portale“ ersetzen (S10). + +**UrhDaG-Vermerk (3.9):** Tragfähig. Nr. 4 ist das entscheidende Merkmal: Pressemitteilungen sind zur freien Weiterverbreitung bestimmt; es gibt keinen Lizenzmarkt, mit dem das Portal um Publikum konkurriert. Der Status als kleiner Diensteanbieter (§ 2 Abs. 3, Umsatz unter 1 Mio. Euro) reduziert nur einzelne Pflichten; er ist keine Freistellung vom UrhDaG und wird nicht als Sicherheitsnetz geführt. + +### A3 Vertretung und Regress · **R+** + +**Position:** Kontoinhaber als Vertragspartner (§ 8a Abs. 1 Satz 2) ist sauber; eine Agentur bindet sich selbst, Vertretungsmachtfragen entfallen. Rückgriff läuft gegen den Kontoinhaber. + +**Wer die Bildrechte bestätigt, je Einreichungsweg (bestätigt 12.10.2026):** Es bestätigt, wer vertraglich gebunden ist. Der Admin bestätigt nie. Gibt es niemanden, der gebunden und erreichbar ist, gibt es kein Bild. + +| Weg | Vertragspartner des Portals | Wer bestätigt | Admin-Upload (E10) | +|---|---|---|---| +| Hub-Formular | Kontoinhaber | Kontoinhaber beim Upload | Bestätigungs-Magic-Link an die Konto-E-Mail | +| API v1 mit eigenem Konto | Kontoinhaber (Token-Inhaber) | per `rights_confirmed` im Namen des Kontos | Link an die Konto-E-Mail | +| API über Verteiler oder Agentur (connektar, openPR) | der Partner, nicht dessen Kunde (§ 8a Abs. 1 Satz 2, Syndikationsvertrag § 2) | Partner per `rights_confirmed` | Kein Admin-Upload. Bilder zu Partnermeldungen nur über die API (S22). Der Pressekontakt ist kein Vertragspartner und hat meist keine Vertretungsmacht. | +| Syndizierte Meldung, Pressekontakt wünscht nachträglich ein Bild | niemand, bis ein Konto angelegt ist | Bild-Upload im Self-Service nur mit Konto (entschieden 13.10.2026): Der Pressekontakt legt ein Konto an, nimmt AGB und Unternehmerbestätigung an und bestätigt dann als Kontoinhaber. Kontaktdaten ändern bleibt ohne Konto möglich. | Kein Admin-Upload. Anscheinsvollmacht wird nicht als Standardannahme eingebaut. | +| Altbestand ohne Konto und ohne Partner | niemand, bis ein Konto angelegt ist | wie vorherige Zeile | wie vorherige Zeile | + +Das Bestätigungsprotokoll speichert heute Konto, Tokenkennung und Kanal (`form`, `api`, `magic_link`); das sind keine rechtlichen Rollen. Ziel (RP-05): zusätzlich die Rolle des Erklärenden (Kontoinhaber oder Partner-API), den Vertragspartner und die angenommenen Dokumentfassungen als unveränderlichen Nachweis zum Einreichungszeitpunkt. + +**API:** `rights_confirmed` plus `confirm_text_version` je Upload, plus Annahme der AGB-Fassung über den Gate-Endpunkt (existiert). Für die Alt-API siehe A6 und Abschnitt 7 (Syndikationsvertrag): dort bindet der Vertrag den Partner. + +**Frage an den Anwalt:** Reicht die Kette Konto, Gate-Annahme, Upload-Bestätigung, Protokoll für den Regress, oder fehlt aus seiner Sicht ein Glied? + +### A4 Beweisarchiv · **R** (Rahmen), Einzelentscheidungen **G** + +Entscheidungen nach E6 bis E8, konkretisiert: + +| Punkt | Entscheidung | +|---|---| +| Standardfrist | Drei Jahre nach Ende des Jahres der Entfernung, für alle Ereignistypen. Begründung je Typ in der Abwägung (4.4). Der Anwalt kann einzelne Typen kürzen. | +| Legal Hold | Kein Neustart. `retain_until` bleibt. Beim Setzen: Anspruch, Datenumfang, Verantwortlicher, Prüfdatum (spätestens 90 Tage), bekanntes Enddatum. Bei Aufhebung zwei Wege: Löschung zum regulären Datum, oder neues Enddatum mit Pflichtvermerk. Codeänderung in `releaseLegalHold()`. | +| Einschränkung (Art. 18) | Getrennt vom Hold: Markierung sperrt normalen Abruf und Export; Ausnahmeverwendung nur mit Berechtigung, Zweck und Grundlage; Aufhebung nur nach Prüfung und Information des Betroffenen. Ein Löschstopp allein bildet Art. 18 nicht ab. | +| Restdaten nach Löschung | `id`, Objektschlüssel (`payload_path` oder stabiler opaker Schlüssel, ohne Namen im Pfad; ohne ihn funktioniert der Restore-Abgleich nicht), `subject_type`, `subject_id` (für Auskünfte nach Art. 15), `event`, `created_at`, `deleted_at`, `payload_hash`, Schemaversion, Sicherungsstatus. Akteur, Grund-Freitext, Hold-Vermerke, Verweise auf Rechtsvorgänge werden mit dem Payload entfernt. Frist: später von 395 Tagen nach Löschung und 14 Tagen nach Ablauf der letzten rückspielbaren Sicherung. | +| Zugriffsprotokoll | 395 Tage ab Zugriff, danach gelöscht. Nicht an die Lebensdauer des Eintrags gekoppelt. | +| Originaldatei | Unverändert, verschlüsselt, mit allen Metadaten. GPS und Seriennummern werden nicht ausgewertet; sie sind Teil der Beweisdatei. Eine Kürzung würde die Datei verändern und den Hash entwerten. Restrisiko dokumentiert. | +| Kontaktdaten | Pressekontakte im zuletzt veröffentlichten Stand: ja (sie waren öffentlich). Einreicher: Konto-ID, Name, E-Mail, Firma zum Zeitpunkt der Einreichung: ja (Rückgriff; das Konto kann später gelöscht sein). Keine weiteren Kontodaten. | +| Antragsteller im Meldeverfahren | Ziel: nicht im Archiv, nur Vorgangsnummer; die E-Mail bleibt im Meldevorgang (DSE 11, drei Jahre). Ist: `legalRequestBlock()` schreibt die E-Mail heute mit, und Firma/Einreicher werden zum Archivierungszeitpunkt gelesen. Neue Einreichungen bekommen einen unveränderlichen Einreichungsnachweis; versiegelte Altpakete werden inventarisiert, Migration (minimierte Nachfolgefassung mit Integritätsnachweis) oder befristete Übergangsaufbewahrung nach Anwaltsantwort (Frage 3). | +| Sensible Bildinhalte | Grundlage für die Aufbewahrung ist Art. 6 Abs. 1 lit. f und, soweit ein Bild besondere Kategorien zeigt, Art. 9 Abs. 2 lit. f (Rechtsverteidigung). Der Kunde hat das Bild veröffentlicht; das Portal bewahrt es nichtöffentlich auf. | +| Art. 17 Abs. 3 lit. e | Keine pauschale Ablehnung „weil Frist läuft“. Je Löschantrag ein kurzer Vermerk: welcher Anspruch, wessen, warum noch möglich. Vorlage in Abschnitt 4. | +| Backups | 14 Tage. Vor 0.4: alte Deploy- und Migrationskopien (Roadmap 1.5) prüfen und bereinigen, sonst stimmt die Zusage nicht. | +| Restore | Der Satz „bereits gelöschte Einträge werden erneut entfernt“ bleibt, aber erst nach Übung und mit unabhängigem Löschstand (RP-04). Verfahren: Löschauftrag mit Objektschlüssel vor der Entfernung, idempotente Übertragung an einen getrennt wiederherstellbaren Speicher mit Bestätigung, dann Löschung inklusive Derivate; bei Ausfall des Ziels Auftrag und Sperre halten und alarmieren; beim Restore Anwendung isoliert, Löschstand importieren, Altobjekte entfernen, dann freigeben. Szenarien: DB alt, Disk alt, beide alt, externes Ziel nicht erreichbar, Löschung zwischen zwei Exporten. | + +**Fragen an den Anwalt:** Pauschale Drei-Jahres-Frist je Typ, Original mit Metadaten, Art. 9 Abs. 2 lit. f als Grundlage für sensible Bildinhalte, Abwägung in der korrigierten Fassung. + +### A5 Einbeziehung AGB 0.7 · **R** („Später“-Pfad entschieden 12.10.2026) + +**Mechanik:** Gate mit aktivem Klick je Dokumentfassung vor jeder Einreichung. Das genügt § 305 Abs. 2 BGB und erst recht § 310 Abs. 1 im B2B. + +**Das Problem, das das Gate allein nicht löst:** § 15 Abs. 3 der AGB sagt, bei Ablehnung wesentlicher Änderungen läuft der Vertrag zu alten Bedingungen weiter. Ein Abonnent, der 0.7 ablehnt, hat dann weiterhin Anspruch auf seine Slots. Blockiert das Gate seine Einreichung, verweigert das Portal eine bezahlte Leistung. Anti-Zombie-Verstoß und Vertragsbruch. + +**Entscheidung (korrigiert 13.10.2026):** Das Gate steht vor jedem neuen Kauf (Einzelveröffentlichung, Credit-Paket, neues Abonnement). Bereits bezahlte Leistungen bleiben ohne neue Zustimmung nutzbar: Abonnenten mit laufender Laufzeit und Konten mit vor 0.7 gekauften Credits bekommen „Später entscheiden“ und reichen unter 0.6 ein (die Bildbestätigung verweist dann auf § 8 und § 9 der 0.6; Rechte und Freistellung sind dort geregelt). „Später“ erzeugt keinen Annahmedatensatz. Welche Credits alt sind, ergibt sich aus dem bestehenden FIFO (§ 5 Abs. 5): Solange Alt-Credits im Bestand sind, kein Gate; der erste Kauf nach 0.7 verlangt die Annahme. Keine eigene Buchhaltung je Kaufcharge. + +**Was nicht geht, und was ich zuerst falsch hatte:** „Mit der Verlängerung gilt 0.7“ wäre eine einseitige Umstellung. Die automatische Verlängerung nach § 11 Abs. 2 setzt denselben Vertrag fort, und § 15 Abs. 3 sagt ausdrücklich, dass der Vertrag ohne Zustimmung zu alten Bedingungen weiterläuft. Der Hebel für Abonnenten, die nicht zustimmen, ist die Änderungskündigung: ordentliche Kündigung zum Laufzeitende mit gleichzeitigem Angebot eines neuen Vertrags unter 0.7. Ob und wann du den ziehst, ist eine Geschäftsentscheidung; die Mechanik prüft der Anwalt (Frage 2). + +**Nebenbefund:** Richtlinien 0.2 gelten seit 22.09. in der Datenbank, das Gate ist aus. Kunden, die seitdem eingereicht haben, haben 0.2 nie angenommen. Beim Einschalten holen sie beide Fassungen nach; das ist so gewollt und unproblematisch, weil die Richtlinien Bestandteil der AGB sind (§ 2) und 0.2 keine neuen Pflichten enthält [vom Betreiber zu bestätigen]. + +**Frage an den Anwalt:** Trägt die Bestandsschutzlösung (Abos, Alt-Credits) die bestehende Vertragslage? Ist die Änderungskündigung der richtige Weg, mit welcher Mitteilung und Frist? Gilt die Anerkennung über den Bild-Schalter zusätzlich als wirksame Erklärung? + +### A6 Art. 50 KI-VO und Kundenmeldungen · **R+** + +**Position:** Das Portal wird durch die eigene Kennzeichnung nicht zum Mitbetreiber. „Betreiber“ nach Art. 3 Nr. 4 ist, wer ein KI-System in eigener Verantwortung verwendet. Das Portal verwendet beim Setzen der Kennzeichnung kein KI-System; es liest signierte Herkunftsdaten und zeigt die Erklärung des Kunden an. Die Pflicht aus Art. 50 Abs. 4 trifft den Kunden. Der Korrekturweg (§ 8a Abs. 4) deckt das Restrisiko einer falschen Kennzeichnung. + +**Der eigentliche Punkt ist die Alt-API.** Sie setzt heute bei Texten „ohne KI“ und speichert das als Erklärung des Kunden. Das ist eine Erklärung, die niemand abgegeben hat. Wer später behauptet, das Portal habe KI-Inhalte wissentlich unmarkiert gelassen, findet hier einen Ansatz. Entscheidung: Alt-API speichert `not_declared`, keine Kennzeichnung, kein Haken „bestätigt“. Mit dem connektar-Termin im Oktober wird `ai_declaration` Pflichtfeld und der Syndikationsvertrag weist die Erklärung dem Partner zu. Bis dahin ist `not_declared` die ehrliche Zwischenlösung. + +**Ergänzung AGB 0.7, § 8 Abs. 1, neuer Spiegelstrich:** „seine Angaben zur Erstellung mit KI zutreffend sind; eigene Pflichten des Kunden aus der Verordnung (EU) 2024/1689 bleiben unberührt.“ (Für Bilder steht das in § 8a Abs. 4; für Texte fehlt es.) + +**Anzeige:** Der Hinweiskasten „Nach Angaben des einreichenden Unternehmens …“ ist richtig formuliert: Stimme des Kunden, nicht des Portals. + +### A7 Gesamtpaket im Regressfall · **R+** + +**Die Kette steht:** Gate-Annahme (Fassung, Zeitpunkt) → Upload-Bestätigung (Textfassung, AGB-Fassung, Konto, Firma, Zeitpunkt, IP-HMAC, UA) → Original mit Hash → veröffentlichte Fassung → Archiv mit Hash. + +**Was ich ergänzen würde:** + +1. **Integritätsnachweis über die Zeit:** Täglicher Export der Payload-Hashes an den externen Speicher aus B4 (derselbe, der den Tombstone-Stand trägt). Dann lässt sich belegen, dass ein Archiveintrag seit Tag X unverändert ist. Aufwand gering, Beweiswert hoch. +2. **API-Nutzungsbedingungen** als eigenes Dokument in `legal_documents`, versioniert, Annahme über den Gate-Endpunkt gespeichert. Heute ist nur die Referenz geplant. +3. **Versicherung:** Eine Medien- oder Vermögensschadenhaftpflicht für Abmahnungen aus Kundeninhalten ist bei Presseportalen üblich. Geschäftsentscheidung, Angebot einholen; keine Rechtsfrage. + +**Frage an den Anwalt:** Fehlt aus seiner Sicht ein Glied? + +--- + +## 4. Die vier Fragen aus dem Löschanfragen-Handover + +### 1. Grenze unentgeltlich (Art. 17) gegen entgeltliche Depublikation · **R+** + +**Position:** Die Grenze ist die Person, nicht das Datenfeld. Übt eine natürliche Person ein Betroffenenrecht aus, ist alles, was zur Erfüllung nötig ist, kostenfrei (Art. 12 Abs. 5): Entfernung oder Pseudonymisierung ihrer Daten, und wenn danach nur ein sinnloser Rumpf bliebe, die ganze Mitteilung. Bleibt ein eigenständig zulässiges Reststück (Firmenmeldung ohne die Person), ist dessen Entfernung keine Erfüllung eines Betroffenenrechts mehr, sondern eine Leistung für das Unternehmen. Dafür darf ein Preis stehen. + +**Der Preis trägt**, wenn kumulativ: (a) kein Betroffenenrecht einer natürlichen Person betroffen ist, (b) ein kostenfreier Weg für das Betroffenenrecht besteht und funktioniert, (c) die Archivierung bei Vertragsschluss offengelegt war (§ 13 Abs. 1, Hinweis vor jeder Veröffentlichung). Alle drei sind heute erfüllt. B2B, keine Verbraucherkontrolle. + +**Frage an den Anwalt:** Bestätigung dieser Linie; Hinweis, falls er § 13 Abs. 1 („dauerhaft archiviert, Entfernung gegen Entgelt“) für § 307-anfällig hält. + +### 2. UWG-Bewertung des früher als kostenfrei beworbenen connektar-Wegs · **R+** + +**Position:** Die Aussage „Änderungen kostenfrei über connektar“ war irreführend (§ 5 Abs. 1 UWG), wenn der Weg praktisch nicht funktionierte. Der Weg existierte technisch, wurde aber nicht genutzt; die Aussage war also im Ergebnis falsch. Folgen: Die Aussage ist entfernt (Datum im Rechtsordner festhalten), kein Verweis mehr in Schreiben, keine proaktive Berichtigung nötig. Verjährung nach § 11 UWG: sechs Monate für Beseitigungs-, Unterlassungs- und Schadensersatzansprüche von Mitbewerbern und Verbänden, ein Jahr für Verbraucheransprüche nach § 9 Abs. 2; Verbraucher sind hier keine Kunden. Vertragliche Ansprüche von Geschäftskunden, die im Vertrauen auf die Aussage gehandelt haben, sind gesondert zu betrachten; bekannt ist kein Fall. Dokumentieren: Wortlaut, Zeitraum, Datum der Entfernung. Risiko: gering. + +### 3. Realnamen-Änderung: Betroffenenrecht oder kostenpflichtiger Edit · **R+** + +**Position:** Der Auslöser entscheidet. + +| Wer verlangt was | Einordnung | Kosten | +|---|---|---| +| Die genannte natürliche Person will ihren Namen raus oder ersetzt, selbst oder durch ein von ihr bevollmächtigtes Unternehmen | Art. 17 / Art. 21 | kostenfrei | +| Ehemaliger Mitarbeiter will seinen Namen aus Firmen-PM | Art. 17 | kostenfrei | +| Das Unternehmen will den Ansprechpartner aktualisieren (Person gewechselt) | Änderungssystem § 13 Abs. 3, „Aktualisierung von Kontaktdaten“ | kostenfrei nach heutiger Leistungsbeschreibung | +| Das Unternehmen will Text, Zitate, Bilder ändern | Inhaltliche Änderung, neuer Freigabelauf | kostenpflichtig | + +Grenzfall: Das Unternehmen will den Namen eines Dritten (etwa eines Kunden im Text) entfernen, ohne dass dieser es verlangt. Das ist ein Edit, kostenpflichtig. Verlangt es der Dritte selbst, kostenfrei. + +### 4. Art. 19 DSGVO in der Syndikation · **R+** + +**Position:** Jeder Verantwortliche benachrichtigt die Empfänger, denen er selbst Daten offengelegt hat. Das Portal hat an die Öffentlichkeit offengelegt; dafür gilt Art. 17 Abs. 2 (angemessene Maßnahmen, etwa Löschantrag bei Suchmaschinen). Partnerportale gibt es derzeit nicht; Feed-Abonnenten sind nicht identifizierbar, Art. 19 läuft dort leer („unmöglich oder unverhältnismäßig“). connektar als Verteiler hat an viele Portale offengelegt; Art. 19 trifft connektar für diese Empfänger. Das Portal ist nicht verpflichtet, flussaufwärts zu melden, sollte es aber vertraglich vereinbaren (Syndikationsvertrag, Abschnitt 7). Dem Betroffenen gegenüber: eigene Entfernung umsetzen, auf den Verteiler für die netzwerkweite Entfernung hinweisen, ohne das als Bedingung zu machen. + +--- + +## 5. Interessenabwägung: Korrekturen und geschlossene Punkte + +Die Abwägung wird in folgenden Punkten geändert; danach ist sie datier- und abzeichenbar. + +| Stelle | Änderung | +|---|---| +| Kopf | Verantwortlicher eintragen: adametz.media, Inhaber Kevin Adametz, In der Lake 4, 33739 Bielefeld. In Kraft: Datum des Deploy 3. Nächste Prüfung: 12 Monate. | +| 1 Teil B Datensatz | Antragsteller-E-Mail streichen; „Verweis auf den Meldevorgang (Vorgangsnummer)“ | +| 1 Teil B Frist | „bis zu deren Abschluss“ ersetzen durch „bei dokumentierter Aufbewahrungssperre bis zu deren Aufhebung; die reguläre Frist läuft weiter, eine neue Frist nur mit dokumentiertem Grund“ | +| 1 Zugriffsprotokoll | Frist: 395 Tage ab Zugriff | +| 1 neu | Restdaten nach Löschung: Kennungen, Ereignistyp, Zeitpunkte, Hash; Frist: solange rückspielbare Sicherungen existieren plus 14 Tage, mindestens aber 395 Tage für den Löschbeleg | +| 2 | Ergänzen: Art. 9 Abs. 2 lit. f für Bilder mit besonderen Kategorien | +| 3 Browserkennung | Entscheidung: 250 Zeichen bleibt; weitere Kürzung bringt keinen Gewinn, weil die Kennung ohnehin nur im Streitfall gelesen wird. Anwaltsfrage gestrichen. | +| 3 neu | Zeile je Ereignistyp (Bild entfernt, Depublikation, DSGVO-Änderung, Kennzeichnungskorrektur) mit eigener Begründung der drei Jahre | +| 4 Auswirkungen | „gering“ ersetzen durch Risikoliste: sensible Motive im Original, Archivierung ohne Kenntnis der Pressekontakte, Metadaten im Original, interner Fehlgebrauch; daneben die Maßnahme je Risiko | +| 4 Schutzmaßnahmen | Zugriff präzisieren: Originaldateien aktiver Bilder: berechtigte Redaktion; archivierte Inhalte: Compliance-Berechtigung; jeder Abruf archivierter Inhalte und jede Änderung einer Sperre mit Zweck protokolliert. Nicht „jeder Zugriff“. | +| 4 Schutzmaßnahmen | Restore-Zusage mit Verweis auf Übung und externen Löschstand (B4, U7); vor der Übung als „vorgesehen“ formulieren | +| 4 Betroffenenrechte | „werden abgelehnt“ ersetzen durch „werden im Einzelfall geprüft; Vermerk nach Vorlage“ | +| 6 | Offene Punkte 1 und 3 schließen; Punkt 2 (Restore-Übung) bleibt | + +**Vorlage Vermerk Löschantrag gegen Archiveintrag** (für Abschnitt 4, Betroffenenrechte): + +> Antrag vom [Datum], Vorgang [Nr.]. Betroffen: Archiveintrag [ID], Ereignis [Typ], entfernt am [Datum]. Möglicher Anspruch: [Urheber / abgebildete Person / Betroffener nach Art. 82 / Rückgriff gegen Kunde], Verjährung voraussichtlich [31.12.20xx]. Ergebnis: Aufbewahrung erforderlich nach Art. 17 Abs. 3 lit. e bis [Datum] / Löschung veranlasst. [Name, Datum] + +--- + +## 6. Boost-Platzierung · **R+**, Label **G** (entschieden 12.10.2026) + +**Rechtslage:** Eine Pressemitteilung ist erkennbar Unternehmenskommunikation; dafür genügt die Absenderangabe (§ 6 DDG). Nicht erkennbar ist, dass die Platzierung bezahlt wurde. Ein Aufmacher mit „Top-Platzierung“ wirkt wie eine redaktionelle Auswahl. Das berührt § 5a Abs. 4 UWG (kommerzieller Zweck nicht kenntlich), Anhang Nr. 11 UWG (bezahlte Inhalte als redaktionell) und § 22 Abs. 1 MStV (Werbung erkennbar und vom übrigen Inhalt unterscheidbar). Art. 26 DSA (Werbekennzeichnung auf Online-Plattformen) greift wegen der Kleinstunternehmen-Ausnahme in Art. 19 nicht, beschreibt aber den Standard. + +**Position:** „Top-Platzierung“ reicht nicht. „Anzeige“ wäre falsch, weil der Inhalt keine Anzeige ist, sondern eine Pressemitteilung, deren Platz bezahlt wurde. „Booster-Platzierung“ wurde erwogen und verworfen: Der Leser erfährt daraus nicht, dass der Platz gebucht wurde, und das Label wird so beurteilt, wie ein durchschnittlicher Leser es ohne Tooltip versteht. + +**Entscheidung:** + +| Element | Neu | +|---|---| +| Label | „Gebuchte Platzierung“ (en: „Booked placement“), auf Bild und in Listen, gleiche Optik wie heute. „Gebucht“ sagt sachlich, dass die Position gebucht wurde, und passt zur Sprache der Preisseite („buchbar“). | +| Erklärung | Tooltip und `title`: „Das Unternehmen hat diesen Platz gebucht. Der Inhalt ist eine Pressemitteilung des Unternehmens.“ Auf Mobil als Link auf einen Absatz der Seite „So funktioniert das Portal“ | +| Aufmacher ungebucht | „Top-Meldung“ bleibt; Auswahl muss automatisch sein (neueste Grün-Meldung oder Boost), keine manuelle Kuratierung, sonst entsteht redaktionelle Auswahl | +| Preisseite D.2 | Satz ergänzen: „Geboostete Meldungen sind als gebuchte Platzierung gekennzeichnet.“ | +| AGB § 6 Abs. 2 (0.7) | Textvorschlag unten | + +**AGB § 6 Abs. 2 neu:** + +> **(2) Boost:** Zeitlich befristete hervorgehobene Platzierung einer veröffentlichten PM in den Laufzeitstufen 7, 14 oder 30 Tage. Der Startseiten-Boost umfasst die Startseite und die Kategorieseite des jeweiligen Portals, der Kategorie-Boost nur die Kategorieseite der gewählten Rubrik. Die Zahl gleichzeitiger Boosts je Seite ist begrenzt; die freien Plätze werden vor der Buchung angezeigt. Geboostete PMs werden als gebuchte Platzierung gekennzeichnet. Ein Boost ist nur für PMs buchbar, die die Inhaltsprüfung ohne Beanstandung durchlaufen haben (Status „Grün“). Geschuldet ist ausschließlich die Platzierung während der gebuchten Laufzeit; eine bestimmte Reichweite, Zugriffszahl oder sonstige Werbewirkung wird nicht geschuldet. [Satz zur Nichterreichbarkeit unverändert.] + +**Frage an den Anwalt:** Bestätigung, dass „Gebuchte Platzierung“ mit Erklärung genügt. + +--- + +## 7. Refund-Regel · **G** (Modell B entschieden 12.10.2026), Klausel **R+** + +**Rahmen:** B2B, kein Widerrufsrecht (§ 12). Gesetzlich bleibt: Rückzahlung bei Nichtleistung (§ 326 Abs. 4 BGB), Gewährleistung, zwingende Ansprüche. Eine Erstattungsregel in AGB darf das nicht unterschreiten, darf aber darüber hinausgehen. Anti-Zombie verlangt, dass die Regel öffentlich steht und nicht vom Einzelfall abhängt. + +**Drei Modelle:** + +| | A: Gesetz plus Kulanz | B: Klare Regel (Empfehlung) | C: 14 Tage Geld zurück auf alles Unverbrauchte | +|---|---|---|---| +| Einzel-PM abgelehnt | Einzelfall | Eine kostenfreie Überarbeitung; bleibt es bei Rot oder will der Kunde nicht: volle Erstattung | volle Erstattung | +| Technischer Fehler | § 4 Abs. 3 | Slot/Credits zurück, bei Einzel-PM Erstattung | wie B | +| Boost nicht angezeigt | Einzelfall | Laufzeit verlängert (§ 6 Abs. 2); auf Wunsch anteilige Credit-Gutschrift | wie B | +| Bild wegen Rechtsverletzung entfernt | kein Ausschluss (E8) | keine Erstattung der PM, keine Zusatzkosten; Ersatzbild kostenfrei | wie B | +| Depublikation auf Kundenwunsch | – | keine Erstattung | keine Erstattung | +| Unverbrauchte Credits | § 5 Abs. 3: keine Auszahlung | Auf Antrag innerhalb von 14 Tagen nach Kauf: Erstattung des unverbrauchten Teils; danach § 5 Abs. 3 | jederzeit anteilig | +| Abonnement | Kündigung zum Laufzeitende | Kündigung zum Laufzeitende, keine anteilige Erstattung; Ausnahme Sonderkündigung bei Preisänderung (§ 10 Abs. 5): anteilig | 14 Tage nach Erstbuchung voll, wenn kein Slot verbraucht | +| Aufwand | niedrig, aber intransparent | niedrig, selten | mittel | + +**Entscheidung: Modell B.** Begründung: Die Fälle sind selten (seit Go-Live keine Erstattung, 3 Stornos), die Regel ist in zehn Zeilen erklärt, und die 14-Tage-Regel für Credits nimmt dem „keine Auszahlung“ in § 5 Abs. 3 die Härte, ohne das Modell zu öffnen. + +**Zahlungsweg:** Erstattung auf demselben Weg wie die Zahlung (Stripe-Refund, bei Überweisung Rücküberweisung). Für Vorkasse-Kunden wie FMI: statt des manuellen MAN-Pfads Stripe-Rechnung mit Banküberweisung als Zahlungsmethode nutzen; dann laufen Rechnung, Zahlungseingang und Erstattung über einen Weg. Geschäftsentscheidung, aber sie spart dir den Sonderpfad. + +**Klausel (AGB 0.7, § 10 neuer Abs. 6):** + +> **(6) Erstattungen.** Wird eine PM im Rahmen der Inhaltsprüfung abgelehnt und vom Kunden nicht erneut eingereicht oder erneut abgelehnt, erstattet der Anbieter den für diese Einzelveröffentlichung gezahlten Preis; bei Abonnements und Credits wird kein Slot und kein Credit verbraucht. Kann eine Zusatzleistung aus vom Anbieter zu vertretenden Gründen nicht erbracht werden, werden die dafür eingesetzten Credits gutgeschrieben. Erworbene Credits erstattet der Anbieter auf Antrag innerhalb von 14 Tagen nach dem Erwerb, soweit sie noch nicht eingesetzt wurden; danach gilt § 5 Abs. 3. Erstattungen erfolgen auf demselben Zahlungsweg. Gesetzliche Ansprüche bleiben unberührt. + +**Umsetzung:** Admin-Aktion „Erstatten“ mit Status `refunded` (existiert, wird nirgends gesetzt); Doppelerstattung (Geld und Credits) technisch ausschließen, Zahlungsstatus mit Stripe-Webhooks abstimmen; Hilfeseite „Erstattungen“ mit derselben Tabelle. + +--- + +## 8. Syndikationsvertrag: Gliederungsvorschlag + +Standarddokument für connektar, openPR und künftige Partner. Deutsch, Textform genügt. + +| § | Inhalt | Warum | +|---|---|---| +| 1 | Gegenstand: Übermittlung von PM des Partners bzw. seiner Kunden zur Veröffentlichung auf den Portalen; keine Exklusivität, keine Abnahmepflicht | | +| 2 | Rollen: Partner reicht im eigenen Namen ein und ist Vertragspartner für alle Pflichten (Spiegel von § 8a Abs. 1 S. 2); Partner sichert zu, von seinen Kunden zur Einreichung und zur Abgabe der Erklärungen (Rechte, KI) ermächtigt zu sein | A3, A6 | +| 3 | Schnittstelle: API v1; Pflichtfelder `ai_declaration`, `rights_confirmed`, `confirm_text_version`, Bildfelder; Alt-API-Abschaltdatum; Rate-Limits | Alt-API-Lücke | +| 4 | Änderungen und Löschungen: Partner übermittelt Änderungen und Löschungen seiner Kunden unverzüglich über die Schnittstelle; das Portal darf eigene Änderungen vornehmen (DSGVO, Meldeverfahren) und sperrt danach den Re-Sync; Partner akzeptiert das | Write-once | +| 5 | Inhalte: Veröffentlichungsrichtlinien gelten; Rechte an Text und Bild; KI-Angabe ist Erklärung des Kunden, nie Default; keine Veröffentlichungspflicht, automatisierte Prüfung; Ablehnung mit Ablehnungskategorie (§ 7 Abs. 2, Art. 17 DSA) | A2 | +| 6 | Benachrichtigungen: Das Portal informiert Pressekontakte über Veröffentlichung und Ablehnung; Partner stellt sicher, dass seine Kunden darüber informiert sind (Art. 13/14 DSGVO beim Partner) | Akquisekanal absichern | +| 7 | Rechteeinräumung: wie § 9 (einfaches Recht, Feeds, OG, Archiv, Beweissicherung), erteilt durch den Partner für seine Kunden | A1 | +| 8 | Datenschutz: beide eigenständig Verantwortliche, kein AVV, keine gemeinsame Verantwortung; Übermittlung lit. b/f; gegenseitige Benachrichtigung bei Betroffenenanfragen innerhalb von fünf Werktagen; Weiterleitung von Löschbegehren an die Gegenseite; Art. 19 je für eigene Empfänger | Löschanfragen-Frage 4 | +| 9 | Freistellung und Haftung: verschuldensabhängig, Spiegel von § 8 Abs. 2; Haftungsbegrenzung wie § 14 | | +| 10 | Entgelt und Statistik: unentgeltlich gegenseitig oder Konditionen; welche Zahlen das Portal liefert (Aufrufe je PM, 5a) | | +| 11 | Kennzeichnung: Quellenhinweis am Beitrag („über [Partner]“), Umgang mit Doppelveröffentlichung (Canonical) | | +| 12 | Laufzeit und Kündigung: unbefristet, monatlich kündbar; nach Ende bleiben veröffentlichte PM archiviert, Rechteeinräumung bleibt, keine neuen Einreichungen | Anti-Zombie | +| 13 | Vertraulichkeit, Änderungen in Textform, deutsches Recht, Gerichtsstand Bielefeld | | +| Anlagen | API-Spezifikation, Richtlinien in aktueller Fassung, Bildklausel (S23) | | + +**Für den Anwalt:** Entwurf nach dieser Gliederung erstellen oder prüfen lassen; vor dem connektar-Termin im Oktober mindestens § 3, § 4 und § 5 abstimmen. + +--- + +## 9. DSE 0.4: korrigierte Textentwürfe + +Ersetzt Abschnitt 4 des Anwaltspakets. Nur die geänderten Teile; unveränderte Entwürfe (Google-Anmeldung in 7a, 9a erster Teil) bleiben wie im Decision-Update. + +### 3a Fehlerprotokoll + +Wie im Paket, mit dem Absatz aus F2 anstelle von „IP-Adressen, Namen, E-Mail-Adressen, Cookies und Formularinhalte werden nicht übermittelt …“. + +### 7a Anmeldung und Kontosicherheit (Hub) + +> Zum Schutz Ihres Kontos verarbeiten wir bei der Anmeldung folgende Daten: +> - Zeitpunkt und IP-Adresse Ihrer letzten Anmeldung; beides sehen Sie auf der Seite „Konto-Sicherheit“, damit Ihnen fremde Anmeldungen auffallen. Die Angabe wird bei jeder Anmeldung überschrieben und 90 Tage nach Ihrer letzten Anmeldung gelöscht. +> - Ihre Anmeldungen mit Zeitpunkt und Anmeldeweg (Passwort, Magic-Link, Google, Passkey) sowie fehlgeschlagene Anmeldeversuche und Sperren Ihres Kontos in unserem internen Aktivitätsverlauf. Bei fehlgeschlagenen Versuchen wird die IP-Adresse nur als gekürzter, mit einem geheimen Schlüssel gebildeter Prüfwert gespeichert. Diese Einträge löschen wir nach 90 Tagen. +> - Anmeldeversuche mit Adressen, zu denen kein Konto besteht, zählen wir nur als Tagessumme je Quelle (als gekürzter Prüfwert der IP-Adresse), gelöscht nach 90 Tagen. +> - Zur Begrenzung von Anmeldeversuchen zählen wir Fehlversuche je IP-Adresse (15 Minuten) und je Kombination aus E-Mail-Adresse und IP-Adresse (1 Minute) in einem kurzlebigen Zwischenspeicher; die Einträge verfallen danach automatisch. +> +> [Absätze Zwei-Faktor, Passkeys, Google unverändert.] +> +> Rechtsgrundlage ist Art. 6 Abs. 1 lit. b DSGVO (Bereitstellung eines sicheren Kundenkontos) und Art. 6 Abs. 1 lit. f DSGVO (Schutz vor unbefugten Zugriffen). Zwei-Faktor-Daten und Passkeys löschen wir, wenn Sie sie entfernen, spätestens mit Ihrem Konto. + +### 7b Aktivitätsverlauf und Programmierschnittstelle (Hub) + +> Für die Nachvollziehbarkeit von Vorgängen, die Missbrauchserkennung und den Support führen wir einen internen Aktivitätsverlauf, auf den nur Administratoren Zugriff haben. Er enthält insbesondere Registrierungen, Statuswechsel von Pressemitteilungen, eingegangene Anfragen, versandte Benachrichtigungen mit Empfängeradresse und Betreff sowie Handlungen von Administratoren. Diese Einträge löschen wir nach 395 Tagen; Anmeldeereignisse nach 90 Tagen (Abschnitt Kontosicherheit). +> +> Wenn Sie unsere Programmierschnittstelle (API) nutzen, protokollieren wir je Anfrage Ihr Konto und die Kennung des verwendeten Zugangsschlüssels (nicht den Schlüssel selbst), die aufgerufene Funktion, das Ergebnis, die Dauer sowie IP-Adresse und Programmkennung. Das Protokoll dient dem Betrieb, der Missbrauchserkennung und dem Nachweis der Nutzung und wird nach 90 Tagen gelöscht. +> +> Rechtsgrundlage ist jeweils Art. 6 Abs. 1 lit. f DSGVO; bei der API-Nutzung zusätzlich Art. 6 Abs. 1 lit. b DSGVO. + +### 12a Zustellbarkeit und Abmeldung + +> Erhalten wir eine Meldung, dass eine E-Mail nicht zugestellt werden konnte, werten wir sie automatisch aus und speichern die Empfängeradresse, die Art und den Text der Meldung sowie eine interne Referenz der betroffenen E-Mail. Adressen, die dauerhaft nicht erreichbar sind, nehmen wir in eine Sperrliste auf. +> +> Jede Benachrichtigung enthält einen Link zur Abmeldung; Ihr Mailprogramm kann die Abmeldung auch direkt auslösen. Haben Sie kein Kundenkonto, zum Beispiel als in einer Pressemitteilung genannter Pressekontakt, speichern wir Ihre Abmeldung in derselben Sperrliste. An gesperrte Adressen senden wir keine Benachrichtigungen mehr; von Ihnen selbst angeforderte Anmeldelinks bleiben möglich. Eine Entsperrung erfolgt auf Ihre Anfrage an info@pressekonto.com. +> +> Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO; unser berechtigtes Interesse liegt in der zuverlässigen Zustellung und darin, keine unerwünschten oder unzustellbaren E-Mails zu versenden. Bei Abmeldungen ist die Speicherung zudem erforderlich, um Ihren Widerspruch dauerhaft zu beachten (Art. 6 Abs. 1 lit. c in Verbindung mit Art. 21 Abs. 3 DSGVO). Die abgerufenen Zustellmeldungen löschen wir aus dem Postfach nach 90 Tagen, die ausgewerteten Datensätze nach 395 Tagen; Einträge der Sperrliste bleiben bestehen, solange sie für diesen Zweck erforderlich sind. + +### 6 Kontaktaufnahme (Ergänzung) + +> Zum Schutz vor Missbrauch und zum Nachweis des Eingangs speichern wir bei Kontaktanfragen, Meldungen, Widerrufen, Kündigungen und Buchungsbestätigungen über unsere Formulare die IP-Adresse, von der die Anfrage gesendet wurde, und entfernen sie nach 90 Tagen. Die übrigen Angaben speichern wir, solange es zur Bearbeitung und Dokumentation des Vorgangs erforderlich ist (Abschnitt Speicherdauer). + +*Darf erst mit 0.4 erscheinen, wenn der Löschlauf inklusive Altbestand läuft (U1).* + +### 6a Turnstile (Ergänzungen) + +Die drei Sätze aus F8. + +### 10 (Hub) / 8 (Portale) Automatisierte Inhaltsprüfung (Änderung) + +Ersetzt die Anbieterliste: + +> Für die automatisierte Analyse nutzen wir die Programmierschnittstelle von OpenAI Ireland Ltd., 1st Floor, The Liffey Trust Centre, 117–126 Sheriff Street Upper, Dublin 1, Irland. Die Anbindung ist so eingerichtet, dass OpenAI die übermittelten Inhalte nicht speichert und nicht zum Training von Modellen verwendet (Zero Data Retention). Mit OpenAI besteht ein Vertrag zur Auftragsverarbeitung. [Falls Datenresidenz EU aktiv: Die Verarbeitung erfolgt in der EU. Sonst: Eine Verarbeitung in den USA ist möglich; sie erfolgt auf Grundlage von EU-Standardvertragsklauseln.] Setzen wir künftig weitere Anbieter ein, nennen wir sie hier. + +### 7 (Portale) Änderungslinks (Änderung) + +> … Die konkrete Gültigkeitsdauer wird systemseitig festgelegt und beträgt derzeit 15 Minuten für Zugangslinks zur Verwaltung einer Mitteilung oder eines Newsrooms und 72 Stunden für den Bestätigungslink, den Sie nach einer Meldung über „Mitteilung melden“ erhalten. + +### 9a Bilder (Änderungen gegenüber Decision-Update) + +- „einer gekürzten Kennung des verwendeten Browsers“ → „der auf 250 Zeichen gekürzten Kennung des verwendeten Browsers“ +- Letzter Absatz: „Bilder, die hochgeladen, aber nie veröffentlicht werden, löschen wir, wenn Sie sie löschen oder ersetzen, sofort; bleibt ein Entwurf 180 Tage unbearbeitet, löschen wir ihn mit seinen Bildern.“ + +### 9b Beweisarchiv (Neufassung der betroffenen Absätze) + +> Einen auf das Notwendige beschränkten Datensatz zu der entfernten Veröffentlichung bewahren wir in einem getrennten, verschlüsselten Archiv auf: den zuletzt veröffentlichten Stand der Inhalte einschließlich der darin genannten Pressekontakte, die Angaben zum Einreicher (Konto, Name, E-Mail-Adresse, Firma zum Zeitpunkt der Einreichung), die zu den Bildern gespeicherten Daten (Abschnitt Bilder), die Zeitpunkte von Veröffentlichung und Entfernung, den Grund der Entfernung als Kategorie, bei Änderungen den vorherigen und den neuen Stand sowie die Vorgangsnummer eines zugrunde liegenden Melde- oder Löschverfahrens. Zweck ist ausschließlich die Wahrung unserer Nachweis- und Verteidigungsinteressen gegenüber Rechteinhabern, Betroffenen und Behörden sowie der Rückgriff gegen den Einreicher. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO; soweit ein Bild ausnahmsweise besondere Kategorien personenbezogener Daten erkennen lässt, Art. 9 Abs. 2 lit. f DSGVO. Bei Daten, deren Löschung beantragt wurde, prüfen wir im Einzelfall, ob die weitere Aufbewahrung nach Art. 17 Abs. 3 lit. e DSGVO erforderlich ist, und halten das Ergebnis fest. +> +> Originaldateien aktiver Bilder sind für unsere Redaktion zugänglich; archivierte Inhalte nur für Administratoren mit gesonderter Berechtigung. Jeder Abruf archivierter Inhalte und jede Änderung einer Aufbewahrungssperre wird mit Angabe des Zwecks protokolliert; das Protokoll löschen wir nach 395 Tagen. Das Archiv wird für keinen anderen Zweck verwendet und nicht an Dritte weitergegeben, außer zur Rechtsverteidigung an unsere rechtlichen Berater oder auf gesetzlicher Grundlage an Behörden und Gerichte. +> +> Archiveinträge werden drei Jahre nach dem Ende des Jahres, in dem der Inhalt entfernt wurde, automatisch gelöscht. Läuft zu einem Inhalt eine rechtliche Auseinandersetzung, setzen wir eine dokumentierte Aufbewahrungssperre; nach deren Aufhebung wird der Eintrag zum regulären Zeitpunkt gelöscht oder, wenn ein dokumentierter Grund fortbesteht, zu einem festgelegten späteren Zeitpunkt. Verlangen Sie die Einschränkung der Verarbeitung, kennzeichnen wir den Eintrag gesondert und beschränken seine Verwendung auf die gesetzlich zulässigen Zwecke. Von einem gelöschten Eintrag bleibt nur ein technischer Löschvermerk (Kennung, Objektschlüssel, Ereignisart, Zeitpunkte, Prüfsumme), der verhindert, dass gelöschte Inhalte durch eine Wiederherstellung erneut verfügbar werden. Sicherungskopien werden innerhalb von 14 Tagen überschrieben; nach einer Wiederherstellung aus einer Sicherung werden bereits gelöschte Einträge anhand eines getrennt gesicherten Löschstands erneut entfernt. + +### 13 Speicherfristen (Liste für 0.4; Sitzungen, Reset- und API-Tokens, Warteschlangen vor Veröffentlichung ergänzen) + +> - Server-Logs: 14 Tage. +> - Anmelde- und Änderungslinks: einmalige Nutzung oder 15 Minuten gültig; Bestätigungslinks aus dem Meldeverfahren: 72 Stunden. Die zugehörigen Datensätze werden gelöscht, sobald Verbrauch oder Ablauf mehr als 30 Tage zurückliegen. +> - Ereignisprotokolle (Abschnitt 5a): 395 Tage. +> - Fehlerberichte: 90 Tage. +> - Aktivitätsverlauf: Anmelde- und Fehlversuchsereignisse 90 Tage, übrige Einträge 395 Tage; Tagessummen fehlgeschlagener Anmeldungen 90 Tage; API-Zugriffsprotokoll 90 Tage; IP-Adresse der letzten Anmeldung 90 Tage nach der letzten Anmeldung. +> - Zustellmeldungen: 90 Tage im Postfach, 395 Tage als ausgewerteter Datensatz; Sperrliste, solange erforderlich. +> - IP-Adressen aus Formularanfragen und Buchungsbestätigungen: 90 Tage. +> - Kontaktanfragen: 180 Tage nach Abschluss; Anfragen mit Vertrags- oder Rechtsbezug nach der Frist des jeweiligen Vorgangs. +> - Formulardaten zu Widerruf, Kündigung und Buchungsbestätigung: 180 Tage nach Bearbeitung; der Vertragsnachweis selbst nach den gesetzlichen Aufbewahrungsfristen. +> - Entwürfe, die nie veröffentlicht wurden: sofort bei Löschung durch Sie, sonst 180 Tage nach der letzten Änderung samt Bildern. +> - Abgelehnte, nie veröffentlichte Einreichungen: Text und Bilder 180 Tage nach der Ablehnung; ein Ablehnungsnachweis (Status, Zeitpunkt, Kategorie, Konto) drei Jahre nach Ende des Jahres der Ablehnung. +> - Bearbeitungsstände von Korrekturen: 30 Tage. +> - Meldedaten: drei Jahre nach Abschluss des Vorgangs. +> - Beweisarchiv (Abschnitte Bilder, Beweisarchiv): drei Jahre nach Ende des Jahres der Entfernung; Zugriffsprotokoll 395 Tage; technischer Löschvermerk bis zum späteren von 395 Tagen nach Löschung und 14 Tagen nach Ablauf der letzten rückspielbaren Sicherung. +> - Vertrags-, Buchungs- und Rechnungsdaten: gesetzliche Aufbewahrungsfristen (Buchungsbelege acht Jahre, Handels- und Geschäftsbriefe sechs Jahre). +> - Veröffentlichte Pressemitteilungen: dauerhaft im Archiv, soweit keine Ansprüche auf Entfernung bestehen. +> - Kontodaten: nach Kontolöschung, soweit keine Aufbewahrungspflichten entgegenstehen. +> +> Gelöschte Daten können in Sicherungskopien noch bis zu 14 Tage enthalten sein. + +**Gestrichen in 0.4:** Entwurf „5 Webanalyse Kundenbereich“ (F6), Entwurf „9a KI-Vorabprüfung“ (F9). + +--- + +## 10. Anwaltsagenda in Endfassung + +Was dem Anwalt tatsächlich vorgelegt wird, sortiert nach Gewicht. Alles andere bekommt er als Information. + +| Nr. | Frage | Unser Default | Bezug | +|---|---|---|---| +| 1 | AGB 0.7: § 8a, § 9 Abs. 1, 1a, 2, 4, § 6 Abs. 2 neu, § 8 Abs. 1 KI-Spiegelstrich, § 10 Abs. 6 Erstattungen. Freigabe. | Texte wie in Decision-Update 3.1/3.2 und hier Abschnitte 3, 6, 7 | A1, A6, Boost, Refund | +| 2 | Einbeziehung 0.7: Bestandsschutz für laufende Abos und Alt-Credits; Umstellung nur per Änderungskündigung. Trägt das? Richtiger Weg, Mitteilung, Frist? | Ja | A5 | +| 3 | Beweisarchiv: Drei-Jahres-Frist je Ereignistyp, Original mit Metadaten, Art. 9 Abs. 2 lit. f, Hold und Art. 18 getrennt, Migration versiegelter Altpakete mit Antragsteller-E-Mails, korrigierte Abwägung | Wie Abschnitt 3 A4 | A4 | +| 4 | Medienprivileg in DSE 9 (Portale): unschädlich in Hedge-Form oder umstellen auf Art. 17 Abs. 3 lit. a? | Behalten, nie allein darauf stützen | A2 | +| 5 | Hoster-Status mit automatisierter Prüfung und Boost; UrhDaG-Vermerk | Tragfähig | A2 | +| 6 | Art. 50 KI-VO: Portal kein Mitbetreiber; Portal-Updates mit dokumentierter Überarbeitung ohne Kennzeichnung | Ja | A6, F10 | +| 7 | Boost-Label „Gebuchte Platzierung“ mit Erklärung ausreichend? | Ja | Abschnitt 6 | +| 8 | Fehlerprotokoll im Browser: § 25 Abs. 2 Nr. 2 TDDDG mit minimalem Datensatz | Ja | F2 | +| 9 | Turnstile: § 25 Abs. 2 Nr. 2, DPF | Ja | F8 | +| 10 | Aktivitätsverlauf: 395 Tage für Mail-Einträge zu Nichtkunden verhältnismäßig? | Ja | F3 | +| 11 | Sperrliste: lit. c in Verbindung mit Art. 21 Abs. 3 für Abmeldungen | Ja | F5 | +| 12 | Löschanfragen 1 bis 4 | Wie Abschnitt 4 | Handover | +| 13 | Regresskette vollständig? | Mit den drei Ergänzungen aus A7 | A3, A7 | +| 14 | Syndikationsvertrag nach Gliederung Abschnitt 8 entwerfen oder prüfen | Entwurf durch Anwalt | Roadmap 3.5 | +| Später | KI-Bildprüfung: AVV, ZDR, Schwellwertprüfung ausreichend oder DSFA? | AVV plus Schwellwertprüfung | F9 | +| Später | Umami Kundenbereich, Newsletter: Aktivierungsbedingungen | Wie F6, F7 | | + +Als Information, keine Frage: F1, F3-Fristen, F4, F6, F7, F11, die Entscheidungen E1 bis E9, die DSE-Entwürfe aus Abschnitt 9. + +--- + +## 11. Was vor dem Versand und vor 0.4 passieren muss + +### Vor dem Versand (Dokumente) + +| Nr. | Aufgabe | +|---|---| +| V1 | Anwaltspaket auf diesen Stand bringen: Abschnitt 2 Fristen, Abschnitt 3 Sachverhalt (Token-Kennung, Zwischenspeicher, Magic-Link-Ausnahme, remoteip, Gate-Status), Abschnitt 4 durch Abschnitt 9 hier ersetzen, Abschnitt 5 Fragen durch Abschnitt 10 hier ersetzen, D7/D8/D10 als spätere Aktivierungen kennzeichnen | +| V2 | Interessenabwägung nach Abschnitt 5 korrigieren, Verantwortlichen eintragen | +| V3 | Anlage Rechtstexte: unverändert beilegen, plus Screenshot Gate (ausgeschaltet, Code vorhanden) | +| V4 | Zwei Mailtexte vom Juli (Abonnenten, aktive Konten) mit Versanddatum in den Rechtsordner | +| V5 | DPF-Status Cloudflare und OpenAI-Organisationseinstellungen (ZDR, Residenz) als Screenshot | + +### Vor DSE 0.4 / AGB 0.7 (Deploy 3) + +| Nr. | Aufgabe | Herkunft | +|---|---|---| +| U1 | IP-Bereinigung Vorgänge und letzte Login-IP, Altbestand | F4, D9 | +| U2 | Entwürfe und Ablehnungen: echte Löschung nach 180 Tagen; Ablehnungsnachweis minimal | E1, E2 | +| U3 | Legal-Hold-Ende ohne Neustart; Einschränkung Art. 18 getrennt; Löschvermerk mit Objektschlüssel minimiert; Zugriffsprotokoll 395 Tage; Vorgangsnummer statt Antragsteller-E-Mail; Inventar versiegelter Altpakete (RP-03, RP-05) | A4 | +| U4 | Aktivitätsverlauf je Ereignistyp | F3 | +| U5 | IMAP-Ordner 90 Tage (alle Ordner inventarisieren); Abmeldesperre: Anmeldelink ausgenommen, angeforderte Bestätigungslinks als eigene Regel (RP-08) | F5 | +| U6 | Scrubber nachschärfen; GlitchTip 90 Tage und Proxy-Logs 14 Tage belegen | F2 | +| U7 | Externer Löschstand mit Löschauftrag je Objekt, Hash-Export, Restore-Übung in fünf Szenarien (RP-04, B-01) | A4, A7 | +| U8 | Alt-API: `not_declared` statt „ohne KI“; bestehende `none`-Werte nur korrigieren, wenn ihre automatische Herkunft sicher feststellbar ist; echte Kundenerklärungen bleiben (RP-09) | A6 | +| U9 | Gate: Bestandsschutz für laufende Abos und Alt-Credits (FIFO); kein Annahmedatensatz bei „Später“; kein automatischer Versionswechsel (RP-06) | A5 | +| U10 | Boost-Label „Gebuchte Platzierung“ und Tooltip; Preisseite-Satz. **Im Code seit 13.10.2026** (Tooltip am Desktop, Tipp auf Mobil, Screenreader-Text; „Top-Auswahl“ → „Aktuell“; Admin-Aktion „Boost beenden“), Deploy offen | Abschnitt 6 | +| U11 | Admin-Upload nur für Meldungen mit Konto, Link an Konto-E-Mail; Self-Service-Bild-Upload nur mit Konto; Rolle und Vertragspartner im Protokoll; Einreichungsnachweis zum Einreichungszeitpunkt (RP-05) | A3 | +| U12 | Erstattungs-Aktion im Admin; Hilfeseite | Abschnitt 7 | +| U13 | Altkonten bereinigen: fünf Altkonten mit Admin-Rolle bzw. Super-Admin-Merker verlieren alle Rechte; Ablauf und Befehl `audit:admins` in `nachweise/bn-02-ablauf.md` | sofort | +| U14 | Alte Backups prüfen und bereinigen (Roadmap 1.5) | A4 | +| U15 | Umami-Rohdatenfrist 13 Monate | F6 | +| U16 | Betriebsnachweise BN-01 bis BN-09 aus der Korrekturdatei liefern (Release und Schalter je Host, Berechtigungen inkl. Editor-Rollen, Backupinventar, externer Löschstand, Instanzfristen, Verträge und DPF-Status, OpenAI-Einstellungen, Juli-Mailtexte mit Versandbeleg, Lauf- und Restore-Protokolle) | alle | +| U17 | Test-Boost auf Live für Screenshots (Startseite, Branchenseite, Mobil), nach Deploy von U10; danach über Admin ▸ Pressemitteilung ▸ „Boost beenden“ | Boost | + +--- + +## 12. Anti-Zombie-Check + +| Regel | Prüfung | +|---|---| +| Keine versteckten Kosten | Erstattungsregel öffentlich; Betroffenenrechte kostenfrei; Boost als gebucht gekennzeichnet | +| Keine automatische Zustimmung | Gate mit Klick; Abonnenten werden nicht blockiert, sondern bekommen „Später“ | +| Transparenz | Fristen in 13 vollständig; Archiv offen benannt; KI-Unterstützung bei Portal-Updates genannt; keine Erklärung im Namen des Kunden (Alt-API) | +| Kein Betreuungsaufwand ohne Nutzen | Alle Fristen laufen automatisch; Erstattungsfälle selten und regelbasiert; Sperrliste verwaltet sich selbst | +| Direkter menschlicher Kontakt | Entsperrung, Löschanträge, Kennzeichnungskorrektur laufen über eine Person | + +--- + +## 13. Wiedervorlage + +- Anwaltsantwort liegt vor: Abschnitt 10 abarbeiten, Defaults bestätigen oder ändern, dann V1/V2 final und Deploy 3. +- connektar-Termin Oktober: `ai_declaration` Pflicht, Syndikationsvertrag § 3 bis § 5, Alt-API-Abschaltdatum. +- Erster Credit-Verfall möglich am 31.12.2029: Erinnerungsmail nach § 5 Abs. 2 bis dahin bauen oder Klausel anpassen. +- Umsatz über 1 Mio. Euro oder redaktionelle Prüfung über Partner: Hoster-Status und UrhDaG neu bewerten. +- D7, D8, D10: eigene Aktivierungspakete mit den Checklisten aus F6, F9, F7. diff --git a/dev/rechtliches/korrekturen-und-umsetzungsauftrag-2026-10-12.md b/dev/rechtliches/korrekturen-und-umsetzungsauftrag-2026-10-12.md new file mode 100644 index 00000000..92c44cda --- /dev/null +++ b/dev/rechtliches/korrekturen-und-umsetzungsauftrag-2026-10-12.md @@ -0,0 +1,368 @@ +# Rechtspaket: Korrekturen, Antworten und Umsetzungsauftrag + +**Stand:** 12.10.2026 · Ergänzung nach Prüfung der überarbeiteten Dokumente und des Codes + +**Verantwortlicher:** adametz.media, Inhaber Kevin Adametz, In der Lake 4, 33739 Bielefeld, info@pressekonto.com. + +**Ziel:** Die fachlichen Widersprüche auflösen und einen ausführbaren Entwicklungsauftrag vorbereiten. Dieses Dokument enthält korrigierte Sachverhalte, Ersatztexte, konkrete Empfehlungen, eine Aufbewahrungsmatrix und Abnahmekriterien. Es dokumentiert keine bereits erfolgte Implementierung oder anwaltliche Freigabe. + +## 1. Ergebnis und Verbindlichkeit + +Die beschlossenen Grundrichtungen bleiben bestehen: bestehende Verarbeitungen transparent beschreiben, Daten begrenzen, Bildrechte nachweisen, das Beweisarchiv absichern und AGB wirksam einbeziehen. Die bisherigen Unterlagen beschreiben an mehreren Stellen bereits die gewünschte Zukunft als Gegenwart. Diese Aussagen werden nachfolgend berichtigt. + +**Arbeitsstand:** Für die technische Vorbereitung liegen jetzt konkrete Vorgaben vor. Die rechtlich abhängigen Teile werden erst nach den Antworten unter Abschnitt 8 endgültig umsetzungsreif. Produktivnachweise werden vor Veröffentlichung benötigt; sie lassen sich nicht aus dem DEV-Container oder einer lokalen Datenbankkopie ableiten. + +| Kennzeichnung | Bedeutung | +|---|---| +| **IST** | Im geprüften Code vorhanden; kein automatischer Nachweis über produktive Konfiguration oder erfolgreiche Ausführung. | +| **BETREIBER** | In den überarbeiteten Unterlagen vom Betreiber mitgeteilt; externer Beleg gegebenenfalls noch offen. | +| **BESCHLOSSEN** | Bereits dokumentierte Geschäftsentscheidung, insbesondere B1/B2 und Entscheidungen im Klärungsdokument. Rechtliche Bedingungen bleiben bestehen. | +| **VORSCHLAG** | Hier ergänzte Empfehlung beziehungsweise technische Arbeitsvorgabe; keine fingierte Betreiber- oder Anwaltsentscheidung. | +| **RECHT OFFEN** | Konkrete Frage mit Umsetzungsauswirkung, die zur anwaltlichen Prüfung bleibt. | +| **BETRIEBSNACHWEIS OFFEN** | Einstellung, Vertrag, Konto-, Versand- oder Laufnachweis außerhalb des geprüften Codes fehlt. | + +Für die nachfolgend ausdrücklich korrigierten Punkte ist dieses Dokument die führende technische Arbeitsgrundlage. Es ersetzt keine bestehenden Verträge. Unveränderte Originalfassungen bleiben als Quellen erhalten. Die Aufgaben erhalten eindeutige Kennungen **RP-01 bis RP-12**; alte U-Kennungen werden nur noch mit Dokumentnamen verwendet. + +### Umfang + +- **BESCHLOSSEN:** Aktive Datenschutzverarbeitungen, DSE, Bildrechte, Beweisarchiv und Zustimmungsgate gehören in das Kernpaket. +- **BESCHLOSSEN:** Hub-Analyse mit Nutzerkennung, KI-Bildprüfung und Newsletter-Kampagnen bleiben ausgeschaltet und erhalten eigene Aktivierungspakete. Das betrifft nicht die bereits laufende KI-Textanalyse oder öffentliche Nutzungsstatistik. +- **BESCHLOSSEN:** Syndikationsvertrag, Refund-Funktion und bezahlte Platzierungen werden als eigene Arbeitspakete geführt. Bereits aktive Verarbeitungen und Rechteketten müssen trotzdem jetzt zutreffend beschrieben und nötigenfalls korrigiert werden. +- **VORSCHLAG:** Neue Portal-Updates mit KI bleiben beim bestehenden Changelog-Paket. Ihre geplante Freigabedokumentation wird aus dem Ist-Sachverhalt des Rechtspakets entfernt. + +## 2. Sachliche Korrekturen mit Ersatztexten + +Die als „Zieltext“ bezeichneten Absätze dürfen erst nach Umsetzung und Abnahme in öffentliche Rechtstexte übernommen werden. Ein zutreffender Zwischenstand für bereits aktive Verarbeitungen soll nicht auf zukünftige Funktionen warten. + +### K1 — Archivinhalt und historische Einreicherdaten + +**IST:** `legalRequestBlock()` schreibt weiterhin `requester_email` in das Beweisarchiv. Beim Archivieren werden aktuelle Beziehungen zu Firma und Benutzer gelesen. Das ist kein sicherer Nachweis des ursprünglichen Einreichungsstands. Quellen: [PressReleaseArchiver](../../app/Services/Archive/PressReleaseArchiver.php), insbesondere `legalRequestBlock()`, `pressReleaseBlock()` und die Archivierungsaufrufe. + +**Ersatz für den technischen Sachverhalt:** + +> Das bestehende Archiv enthält neben Inhalts- und Rechtebelegen derzeit auch Angaben aus dem Meldevorgang einschließlich der Antragsteller-E-Mail. Firma und Einreicherdaten entsprechen den bei der Archivierung verfügbaren Daten. Beschlossenes Ziel ist, Antragstellerkontaktdaten auf den Meldevorgang zu begrenzen und für neue Einreichungen einen unveränderlichen Nachweis der erforderlichen Einreicherdaten zu erzeugen. + +**Umsetzungsvorgabe:** + +- Neue Einreichungen: Zeitpunkt, Konto-/Partnerkennung, Firma, erklärende Person, notwendige Kontaktadresse und jeweils angenommene Dokumentfassungen als Nachweis festhalten. Änderungen am laufenden Konto verändern diesen Nachweis nicht. +- Rechtebestätigungen: eigenen Bestätigungszeitpunkt und Erklärenden speichern; eine spätere Bildbestätigung darf nicht als Erklärung bei der ursprünglichen Texteinreichung erscheinen. +- Altbestand: Herkunft `bei Archivierung erfasst` beziehungsweise `historischer Nachweis vorhanden` kennzeichnen. Keine rückdatierte Rekonstruktion durch heutige Kontodaten. +- Neue Archivpakete: nur Vorgangsnummer statt Antragsteller-E-Mail aufnehmen, soweit die anwaltliche Prüfung den beschlossenen Datenumfang bestätigt. +- Bereits versiegelte Pakete: nicht stillschweigend verändern. Inventar und Migrationsentscheidung erstellen. Entweder nachvollziehbar minimierte Nachfolgefassung mit Integritätsnachweis und kontrollierter Entfernung der alten Fassung oder begründete befristete Übergangsaufbewahrung. Aktive Streitfälle gesondert prüfen. Bis dahin keine Aussage „Antragsteller-E-Mails sind nicht enthalten“. + +**Abnahme:** Änderungen an Konto/Firma beeinflussen einen neuen historischen Nachweis nicht; alte Daten werden korrekt als nachträglich erfasst ausgewiesen; der Umgang mit bestehenden Paketen ist protokolliert. + +### K2 — Löschvermerk, Aufbewahrung und Wiederherstellung + +**IST:** Der Löschvermerk enthält derzeit weitere Metadaten. Export und Wiederherstellungsabgleich benötigen `payload_path`; die beschlossene ausschließliche Feldliste ohne diesen Wert wäre funktionsschädlich. Export und Archiv liegen derzeit auf derselben Disk. Siehe [EvidenceArchive](../../app/Services/Archive/EvidenceArchive.php), `exportTombstones()` und Wiederherstellungsabgleich, sowie [Betriebsrunbook](../betrieb/deploy-runbook.md). + +**Korrigierter Vorschlag für Restfelder:** + +| Feld / Information | Entscheidung für die technische Spezifikation | +|---|---| +| `id` | Lokale technische Referenz; nicht allein als Identität beim Restore verwenden. | +| `payload_path` oder dauerhaft stabiler opaker Objektschlüssel | Erhalten. Muss ein Archivobjekt einschließlich gegebenenfalls alter Fassungen eindeutig identifizieren; darf keine Namen/E-Mails im Pfad enthalten. | +| `event`, `created_at`, `deleted_at`, `payload_hash` | Minimaler Lösch- und Integritätsnachweis; Hash nicht als anonym behandeln. | +| `subject_type`, `subject_id` | Bisher beschlossen; nicht zwingend für den dateibezogenen Restore. Nur behalten, wenn der konkrete Nachweiszweck bestätigt wird, sonst entfernen. | +| Akteur, Klartextgrund, Zusammenfassung, Hold-Freitext, Personen-/Rechtsvorgangsverweise | Nach Wegfall des Inhaltszwecks entfernen; keine indirekte Kopie in Audit-Freitexten anlegen. | +| Schemaversion und Sicherungsstatus | Technisch erforderlich für verlässlichen Import und Überwachung; keine Inhaltsdaten. | + +**Fristvorschlag:** Löschvermerk bis zum späteren der beiden Zeitpunkte aufbewahren: `deleted_at + 395 Tage` oder `Ende der letzten rückspielbaren Kopie + 14 Tage`. Die 395 Tage sind eine vorgeschlagene Nachweisfrist, keine gesetzliche Vorgabe. Fehlt das Ende einer Sicherung, muss die Kopie geklärt werden; daraus wird keine pauschale unbefristete Aufbewahrung aller Restfelder. + +**Konkretes Sicherungsverfahren als Vorschlag:** + +1. Vor Entfernung eines Archivobjekts einen dauerhaften Löschauftrag mit stabilem Objektschlüssel erstellen. Inhalt sofort für gewöhnliche Abrufe sperren. +2. Auftrag idempotent an einen unabhängig wiederherstellbaren Speicher übertragen und dessen Bestätigung festhalten. Täglicher Export dient zusätzlich als vollständiger Kontrollstand, nicht als einziger Schutz. +3. Objekt einschließlich bekannter Derivate löschen, erfolgreiche Löschung bestätigen und Restdaten minimieren. Scheitert ein Schritt, bleibt der Auftrag wiederholbar und wird alarmiert; die Löschung wird nicht als vollständig erledigt ausgewiesen. +4. Fällt das externe Ziel aus, Auftrag und Objektsperre erhalten, sofort alarmieren und die Fristverletzung eskalieren. Kein stilles endloses Zurückstellen von Löschungen; ein dokumentierter Ersatzweg benötigt ebenfalls unabhängig gesicherten Löschstand. +5. Bei Restore Anwendung isoliert lassen, aktuellen externen Löschstand und aktuelle Sperren importieren, Altobjekte entfernen, Integrität prüfen und erst anschließend normale Zugriffe freigeben. Bei unvollständigem Stand keine Freigabe des betroffenen Archivs. + +**Speicheranforderung:** Getrennter Restore-Lebenszyklus, eingeschränkte Schreibrechte, nachvollziehbare Versionen, passende Aufbewahrung und verfügbarer Verifikationsschlüssel. Derselbe Anbieter ist möglich; derselbe gemeinsam zurückgesetzte Datenbestand genügt nicht. Auswahl und Zugang bleiben Betriebsaufgabe. + +Ein Hash-Export unterstützt die Integritätsprüfung. Er ist allein weder manipulationssicherer Zeitstempel noch Garantie gerichtlicher Beweiskraft. Hashhistorie, Löschjournal und Schlüssel brauchen eigene Fristen; ein externer Export darf keine unbegrenzte zusätzliche Datensammlung erzeugen. + +**Zieltext für die DSE:** + +> Nach der Löschung eines Archivobjekts erhalten wir einen begrenzten technischen Löschvermerk, insbesondere Objektkennung, Ereignis, Zeitpunkte und Prüfsumme. Er verhindert, dass gelöschte Inhalte durch eine Wiederherstellung erneut verfügbar werden, und dient dem befristeten Nachweis der Löschung. Der Löschstand wird unabhängig von den wiederherzustellenden Daten gesichert. Seine Aufbewahrung richtet sich nach den noch rückspielbaren Sicherungen und der festgelegten Nachweisfrist. + +Die konkrete Frist aus der freigegebenen Matrix ist im endgültigen Abschnitt „Speicherdauer“ zusätzlich zu nennen. + +### K3 — Legal Hold und Einschränkung der Verarbeitung + +**IST:** Der Hold verhindert die Löschung. Er schränkt das Öffnen oder Exportieren nicht gesondert ein. Ein strukturiertes End-/Prüfdatum fehlt. Bei Aufhebung setzt der Code derzeit eine neue Standardfrist. Quellen: [EvidenceArchive](../../app/Services/Archive/EvidenceArchive.php), `setLegalHold()` / `releaseLegalHold()`, und [ArchiveEntry](../../app/Models/ArchiveEntry.php). + +**BESCHLOSSEN:** Kein automatischer Fristneustart. **VORSCHLAG:** Aufbewahrungssperre und Verarbeitungseinschränkung fachlich getrennt speichern. Art. 18 erlaubt bestimmte weitere Verwendungen, insbesondere zur Rechtsverteidigung; ein bloßer Löschstopp bildet diese Zweckbegrenzung nicht ab. [DSGVO, Art. 18](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32016R0679) + +| Zustand / Aktion | Vorgabe | +|---|---| +| Hold setzen | Konkreter Anspruch, erforderlicher Datenumfang, Verantwortlicher, Setzzeitpunkt und Prüfdatum; vorgeschlagen spätestens nach 90 Tagen. Ein bekanntes Enddatum zusätzlich erfassen. | +| Prüfdatum erreicht | Wiedervorlage und Eskalation; keine automatische Löschung eines weiterhin notwendigen Belegs allein wegen einer überfälligen Prüfung. | +| Hold aufheben | Ursprüngliches `retain_until` erhalten. Ist es überschritten, nächster Löschlauf; Verlängerung nur mit konkretem Grund und neuem Enddatum. | +| Einschränkung setzen | Betroffene Objekte markieren; normale Verwendung und Exporte sperren. Zulässige Ausnahmeverwendung nur mit Berechtigung, Zweck und dokumentierter Grundlage. | +| Einschränkung aufheben | Voraussetzung prüfen und notwendige vorherige Information der betroffenen Person berücksichtigen; bloße Hold-Aufhebung darf die Einschränkung nicht entfernen. | + +**Ersatztext für die Interessenabwägung:** + +> Aufbewahrungssperren sichern erforderliche Belege gegen Löschung. Eine Einschränkung der Verarbeitung wird davon getrennt behandelt: Weitere Verwendungen werden auf die im Einzelfall zulässigen Zwecke begrenzt. Beide Zustände erhalten dokumentierte Gründe, Zuständigkeiten und Prüftermine. Diese technische Trennung ist ein Umsetzungsziel. + +**Abnahme:** Überfälliger Eintrag wird nach Hold-Aufhebung ohne Neustart fällig; eingeschränkte Inhalte sind im normalen Abruf gesperrt; freigegebene Ausnahmeverwendungen werden nachvollziehbar protokolliert. + +### K4 — AGB-Gate, Abonnements und bereits bezahlte Leistungen + +**Problem:** „Später entscheiden“ und automatische Umstellung bei Verlängerung widersprechen der Zusage, ohne Zustimmung unter alten Bedingungen fortzuführen. Auch bereits erworbene Credits und Einzelbuchungen dürfen nicht allein wegen des nächsten Einreichungszeitpunkts als unbelastete neue Käufe behandelt werden. + +**VORSCHLAG für einen implementierbaren Ausgangspunkt:** Bestehende Leistungsansprüche bleiben ohne neue Zustimmung unter den ihnen zugeordneten Bedingungen nutzbar. Schweigen und „Später“ erzeugen keinen Annahmedatensatz. Ohne wirksame Änderung gilt die bisherige Vertragsgrundlage auch bei automatischer Verlängerung weiter. Soll das geschäftlich enden, benötigt es einen gesonderten rechtlich geprüften Änderungs-/Beendigungsprozess; dieser wird nicht durch den Gate-Code ersetzt. + +| Fall | Gate und Leistungsbehandlung | +|---|---| +| Neue Bestellung nach wirksamer Einführung | Neue AGB vor Abschluss aktiv annehmen; Fassung und Zeitpunkt sichern. | +| Bestehendes Abo, keine Zustimmung | „Später entscheiden“ und Leistung nach zugeordneteter Altgrundlage; keine automatische Sperre oder fingierte Annahme. | +| Automatische Verlängerung ohne Zustimmung | Keine technische Umschreibung auf 0.7. Altgrundlage fortführen, sofern kein gesondert geprüfter Vertragsprozess greift. | +| Vor Einführung gekaufte Credits / bezahlte Einzelbuchung | Erwerbsgrundlage und zugesagte Leistung respektieren; beim Verbrauch keine ungeprüfte zusätzliche Zustimmung als Zugangshürde. | +| Neue Credits / neue Einzelbuchung | Neue Vertragsgrundlage vor Kauf; Verbrauch mit dieser Zuordnung. | +| Gemischter Creditbestand | Verbrauch je Erwerbslos nachvollziehen; keine globale Kontofassung, die alte Leistungsansprüche überschreibt. | +| Altvertrag unbekannt | Keine pauschale Behauptung „0.6 angenommen“; vorhandene Nachweise prüfen und Übergangsfall markieren. | +| DSE geändert | Information mit Version und Datum; keine Vertragsannahme oder Einwilligung aus bloßer Kenntnisnahme ableiten. | + +Rechtebestätigung, AGB-Annahme und KI-Erklärung bleiben getrennte Erklärungen mit passenden Fassungen. Das Gate muss auf Formularen, API und sonstigen Einreichungswegen dieselben Vertragszuordnungen respektieren. Bereits vorhandene Bestätigungen dürfen nicht rückwirkend ersetzt werden. + +**Anwaltsfrage:** Trägt diese Bestandsschutzlösung die bestehenden AGB und Leistungsansprüche? Falls eine Umstellung ohne Zustimmung gewünscht ist: Welche konkrete rechtliche Grundlage, Mitteilung und Frist sind erforderlich? Bis zur Antwort ist der automatische Versionswechsel kein Implementierungsziel. + +### K5 — Bildrechte: Erklärender und Vertragspartner + +**IST:** Das Protokoll speichert unter anderem Konto, Tokenkennung und Kanal. `form`, `api` und `magic_link` sind keine rechtlichen Rollen. Quelle: [PressReleaseImageUploader](../../app/Services/PressRelease/Images/PressReleaseImageUploader.php), `recordConfirmation()`. + +**VORSCHLAG:** Neue Bildrechte-Erklärungen stets einem nachweisbar gebundenen Vertragspartner zuordnen. Eine Kontaktadresse oder „handelnd für Firma X“ allein genügt nicht als gesicherter Nachweis einer Vertretungsmacht. Anscheinsvollmacht wird nicht als Standardannahme in den Ablauf eingebaut. + +| Weg | Zielprozess | +|---|---| +| Kontoinhaber im Hub | Erklärung durch berechtigte Person des Vertragskontos; Person und Vertragspartner getrennt dokumentieren. | +| Eigene API | Tokenkennung dem Vertragskonto zuordnen; Rollen-/Versionsangabe serverseitig plausibilisieren. | +| Partner-API | Partner als Vertragspartner, erforderliche eigene Rechte und Erklärungsbefugnisse nachweisen; Partnerbedingungen mit Annahmebeleg zuordnen. | +| Admin lädt vorbereitend hoch | Keine Rechtebestätigung im Namen des Kunden. Veröffentlichung erst nach Bestätigung durch berechtigte Person des Vertragskontos. | +| Pressekontakt ohne Konto / Altbestand ohne gebundenen Partner | Bildänderung vorbereiten lassen; vor neuer Veröffentlichung Bestätigung durch gebundenen Partner oder ausdrückliche neue Vertragsbindung mit Berechtigungsprüfung. Kontoregistrierung allein beweist noch keine Vertretungsmacht. | + +Bestehende bezahlte Leistungen dürfen durch die Umstellung nicht ohne geprüfte Übergangsregel entzogen werden. Bis dahin ist ein betreuter Bestätigungsweg vorzusehen. Die Kontaktperson kann weiterhin unentgeltliche Betroffenenrechte geltend machen; dafür ist keine Kontoanlage erforderlich. + +**Nachweisfelder:** Erklärende Person, Vertragspartner, Rolle, Kanal, Konto-/Tokenreferenz soweit vorhanden, Text- und Vertragsfassung, Zeitpunkt, bestehender IP-HMAC, zugehöriger Bildhash und Herkunft der Vertretungs-/Partnerzuordnung. Keine geheimen API-Schlüssel speichern. Nur erforderliche Daten erfassen und mit dem zugehörigen Rechtebeleg befristen. + +**Abnahme:** Jeder neue Veröffentlichungsweg besitzt einen überprüfbaren Vertragspartner-/Erklärungsbezug; der Admin kann keine fremde Erklärung erzeugen; historische unbekannte Rollen bleiben als unbekannt erkennbar. + +### K6 — Mailausnahmen und Link-Aufbewahrung + +**IST:** Nur `MagicLoginLink` ist als selbst angeforderte Mail von der Abmeldesperre ausgenommen. Hard-Bounce-Sperren bleiben wirksam. Der Meldebestätigungslink ist eine andere Mailklasse. Quellen: [GateOutgoingMail](../../app/Listeners/GateOutgoingMail.php), [PressReleaseReportController](../../app/Http/Controllers/Web/PressReleaseReportController.php). + +**Sofort verwendbarer Ersatz für den beschriebenen Ist-Zustand:** + +> Nach einer Abmeldung versenden wir keine entsprechenden Benachrichtigungen mehr. Selbst angeforderte Anmeldelinks sind von dieser Abmeldesperre ausgenommen. Bei dauerhaft unzustellbaren Adressen bleibt der Versand gesperrt. Für eine Klärung oder Entsperrung können Sie uns unter info@pressekonto.com erreichen. + +**VORSCHLAG:** Eine Erweiterung auf ausdrücklich angeforderte Melde-/Änderungsbestätigungen als eigene, getestete Versandregel umsetzen, soweit sie zur Bearbeitung erforderlich ist. Abmeldung, Hard Bounce, Missbrauchssperre und technischer Versandstopp getrennt behandeln. Kein allgemeiner Bypass für Transaktionsmails und keine Umgehung eines Hard Bounce. + +**Korrektur zur Speicherdauer:** Gültigkeit und Speicherung unterscheiden. Der bestehende [Bereinigungsbefehl](../../app/Console/Commands/PurgeMagicLinks.php) löscht Datensätze, wenn Ablauf oder Verbrauch länger als 30 Tage zurückliegt. Das betrifft auch enthaltene IPs und Nutzungsdaten; es gibt keinen Grund, sie zusätzlich bis zur allgemeinen 90-Tage-IP-Frist zu halten. + +> Zugangslinks sind grundsätzlich einmalig und 15 Minuten gültig; Bestätigungslinks aus dem Meldeverfahren 72 Stunden. Zugehörige Linkdatensätze werden im täglichen Bereinigungslauf entfernt, sobald Verbrauch oder Ablauf mehr als 30 Tage zurückliegen. Unabhängig davon geführte Vorgangs- und Versandnachweise folgen ihren eigenen Fristen. + +### K7 — OpenAI und nicht belegte Betriebszusagen + +**BETREIBER:** OpenAI Ireland und eingerichtete Zero Data Retention werden angegeben. **IST:** Ein fehlender `store`-Parameter belegt keine vollständige Unterdrückung sämtlicher anbieterseitiger Speicherung. OpenAI unterscheidet Anwendungszustand, Missbrauchsprotokolle und gesonderte Datenkontrollen; deren Verfügbarkeit hängt auch von Endpunkt und Modell ab. [OpenAI: Data controls](https://developers.openai.com/api/docs/guides/your-data) + +**Antwort:** Die Zusage „OpenAI speichert keine übermittelten Inhalte“ ist erst nach dem konkreten Nachweis vertretbar und gegebenenfalls auf dessen Umfang zu begrenzen. Benötigt werden Projekt/Organisation, tatsächlich eingesetzte Endpunkte und Modelle, bestätigte ZDR-Einstellung einschließlich relevanter Ausnahmen, DPA und aktivierte Speicher-/Verarbeitungsregion. Private Safety Processing und andere Aufbewahrungsvarianten sind nicht ohne Prüfung gleichzusetzen. + +**Text für das Anwaltspaket:** + +> Die aktive Textanalyse nutzt die OpenAI-API. Der Betreiber gibt OpenAI Ireland als Vertragspartner und eingerichtete Zero Data Retention an. Der konkrete Geltungsbereich und die Datenresidenz werden vor Übernahme einer absoluten Speicherzusage durch Organisations-/Projekteinstellungen und Vertragsunterlagen belegt. KI-Bildprüfung bleibt ausgeschaltet. + +Die finale öffentliche Formulierung muss der belegten Konfiguration entsprechen. Fehlender Nachweis aktiviert nicht automatisch einen anderen Datenverarbeitungsmodus. + +**Weitere Korrekturen:** „Nur zwei Administratoren“ erst nach Berechtigungsprüfung einschließlich Editor-Rollen und aktiver Sitzungen; „14 Tage Backups“ erst nach Inventar einschließlich Sonderkopien; „Portal-Updates mit Diff gespeichert“ als zukünftiges Vorhaben. Ein nicht vorhandener Passwort-Reset-Token beweist nicht, dass keine Juli-Mail versandt wurde. Maßgeblich sind Versandbelege und Mailtexte, nicht verbliebene Tokenzahlen. + +### K8 — Rechtliche Kurzschlüsse und Interessenabwägung + +Folgende Aussagen werden als pauschale Schlussfolgerungen zurückgenommen: + +| Bisherige Aussage | Korrigierte Arbeitsposition | +|---|---| +| „Kunden nicht anspruchsberechtigt; sechs Monate“ | Anspruchsgrundlage und Betroffenengruppe unterscheiden. § 9 Abs. 2 UWG kennt Verbraucheransprüche; § 11 sieht dafür ein Jahr vor. Konkrete B2B- und vertragliche Ansprüche separat prüfen. | +| Kleinanbieterstatus als allgemeines UrhDaG-„Sicherheitsnetz“ | § 7 Abs. 5 enthält eine widerlegliche Vermutung zu bestimmten Blockierungspflichten, keine allgemeine Freistellung vom UrhDaG. | +| „Serverseitig lit. f ohne weitere Voraussetzungen“ | Zweck, Erforderlichkeit, Datenumfang und Interessenabwägung bleiben erforderlich. | +| „Cookielos / technisch minimal, deshalb ohne Einwilligung“ | Für Zugriffe auf Endgeräte die Voraussetzungen des § 25 TDDDG gesondert prüfen; Datenminimierung allein ersetzt die Prüfung nicht. | +| „Kein Art. 9, weil keine Identifizierung“ | Keine biometrische Identifizierung schließt andere besondere Datenkategorien nicht aus. Veröffentlichung durch einen Kunden ist nicht automatisch Veröffentlichung durch die betroffene Person. | +| „DSFA nicht erforderlich / Art. 22 betrifft kein Bild“ | Konkrete Risiken, Umfang und Auswirkungen bewerten. Die spätere Bildprüfung benötigt eine dokumentierte Vorprüfung vor Aktivierung. | +| „Anzeige wäre falsch, weil Pressemitteilung“ | Inhaltsart schließt einen kommerziellen Zweck der bezahlten Hervorhebung nicht aus. Kennzeichnung anhand der tatsächlichen Darstellung prüfen. | +| „Archive erweitern die Kenntnis niemandes“ | Archivierung verlängert Verfügbarkeit und eröffnet Missbrauchs-/Offenlegungsrisiken, auch für zuvor nicht öffentliche Metadaten und Kontaktangaben. | + +Rechtsquellen: [§ 9 UWG](https://www.gesetze-im-internet.de/uwg_2004/__9.html), [§ 11 UWG](https://www.gesetze-im-internet.de/uwg_2004/__11.html), [§ 7 UrhDaG](https://www.gesetze-im-internet.de/urhdag/__7.html), [§ 25 TDDDG](https://www.gesetze-im-internet.de/ttdsg/__25.html), [DSGVO](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32016R0679). + +**Ergänzende Vorgaben für die Interessenabwägung:** + +- Nicht allein auf Unveröffentlichung oder seltenen Zugriff abstellen. Für jeden Archivierungsanlass Zweck, notwendige Felder und mildere Alternative begründen; insbesondere Originalmetadaten und 250 Zeichen User-Agent nicht automatisch für erforderlich erklären. +- Verschlüsselung präzise beschreiben: Archivpakete werden anwendungsseitig verschlüsselt. Aktive Originaldateien liegen privat; deren separate Verschlüsselung ist durch den Upload-Code nicht belegt. Infrastrukturverschlüsselung benötigt einen eigenen Nachweis. +- Zugriffe unterscheiden: aktive Originale durch berechtigte Redaktion, entfernte Archivpakete über Compliance-Berechtigung. Protokolliert werden Abrufe archivierter Inhalte und Hold-Änderungen; nicht pauschal jede Listenansicht. +- Ergebnis unter Umsetzungsvorbehalt formulieren, bis Schutzmaßnahmen tatsächlich bestehen. Interessenabwägung spätestens vor Wirksamwerden der neuen Verarbeitung datieren und abzeichnen; bereits aktive Verarbeitung jetzt bewerten. Keine rückdatierte Freigabe. + +## 3. Aufbewahrungsmatrix als technische Arbeitsvorgabe + +Alle Fristen sind fachliche Zielwerte, soweit kein belegter Ist-Zustand genannt ist. **B** kennzeichnet übernommene Betreiberentscheidungen, **V** ergänzte Vorschläge. Rechtliche Bestätigung insbesondere für Archiv, Rechtsvorgänge und Nachweisfristen bleibt erforderlich. Verantwortlich für Zweck und Frist ist Kevin Adametz; Umsetzung und Laufüberwachung liegen bei Entwicklung/Betrieb, deren ausführende Zuständigkeit vor Beauftragung einzutragen ist. + +| Daten / Speicherumfang | Fristbeginn und Ziel | Regel / Ausnahme / Nachweis | +|---|---|---| +| Nie veröffentlichte Entwürfe, Text, Medien, Originale, Bestätigungen | **B:** 180 Tage seit letzter inhaltlicher Bearbeitung; bei wirksamer Nutzerlöschung unverzüglich | Tatsächlich löschen, nicht nur Status ändern. Hintergrundupdates verlängern die Frist nicht. Belegte Streitfälle gesondert; unklare Legacy-Veröffentlichung nicht automatisch löschen. | +| Abgelehnte, sicher nie veröffentlichte Einreichungen | **B:** Text/Bilder 180 Tage ab dokumentierter Ablehnung | Neues `rejected_at` oder belastbares Ereignis verwenden; fehlende historische Zeitpunkte nicht erfinden. | +| Minimaler Ablehnungsnachweis | **B:** drei Jahre nach Ende des Ablehnungsjahres | Nur Konto-/Vorgangsbezug, Status, Zeitpunkt, standardisierte Kategorie und gegebenenfalls notwendige Vertragsfassung. Kein abgelehnter Volltext im Freitext. | +| Normale Kontaktanfrage, Anhänge und zugehörige bearbeitungsbezogene Kopien | **V:** 180 Tage ab Abschluss | Im Code bisher nur Spam-Bereinigung. Vertrags-/Rechtsfälle gezielt umklassifizieren; kein pauschales Verlängern aller Kontakte. Offene Fälle monatlich prüfen. | +| Spam-Kontakte | **IST:** 30 Tage ab Eingang (`created_at`) | Bestehende Quarantänefrist; Fehlklassifizierung vor Löschung korrigierbar. | +| Melde-/Rechtsvorgang einschließlich Antragstellerkontakt | **B:** drei Jahre nach dokumentiertem Abschluss, ohne zusätzlichen Jahresendaufschlag | Konkreter fortbestehender Anspruch erhält dokumentierte Ausnahme. IP folgt kürzerer Frist. Archiv erhält nur Vorgangsreferenz nach K1. | +| Kündigung, Widerruf, Buchungsbestätigung | **V:** technisch gespeicherte Rohformulare 180 Tage nach Bearbeitung | Erforderlichen Vertrags-/Geschäftsnachweis separat kategorisieren; gesetzlich aufzubewahrende Unterlagen nicht mit Rohdaten löschen. Zugeordnete Frist vor Bestandslauf bestimmen. | +| Vorgangs-IP / letzte Login-IP | **B:** 90 Tage ab Erhebung beziehungsweise letzter Anmeldung | Kürzere Objektfrist geht vor. Letzten Login-Zeitpunkt nicht unbeabsichtigt mitlöschen; eigenen Zweck bewerten. Konkrete Sicherheitsfälle gesondert befristen. | +| Login- und Fehlversuchsereignisse, Kontosperren aus Anmeldeversuchen, Fehlversuchs-Tagessummen | **B:** 90 Tage ab Ereignis | Typen vollständig zuordnen; unbekannte Typen bei Einführung melden, statt beliebige Standardaufbewahrung zu etablieren. | +| Übrige notwendige Aktivitäts-/Mailereignisse | **B:** 395 Tage ab Ereignis | Empfänger und Betreff auf Zweck prüfen; keine Inhalte/Kontaktdaten zusätzlich in Freitext kopieren. Frist zu Nichtkunden gesondert rechtlich bestätigen. | +| API-Zugriffsprotokoll | **B / IST-Default:** 90 Tage ab Anfrage | Tokenkennung statt Geheimnis; Rechnung/Vertrag nicht durch technisches Zugriffslog ersetzen. | +| Magic-Link-Datensätze einschließlich IPs | **IST:** 30 Tage nach Verbrauch oder Ablauf, sobald eine der Bedingungen erfüllt ist | Täglicher Lauf; 15 Minuten/72 Stunden sind Gültigkeit, nicht Aufbewahrung. Weitere Tokentypen haben eigene Regeln. | +| Korrektur-Snapshots | **B / IST-Default:** 30 Tage ab Erzeugung gemäß `purge_after` | Offene Archivaufträge verhindern heute die Bereinigung. Tägliche Wiederholung, Alarm bei überschrittenem Ziel, begründete Einzelfallverlängerung; keine unsichtbare Daueraufbewahrung. | +| Veröffentlichte Mitteilung und benötigte aktive Bild-/Rechtenachweise | **B:** Dauer der zulässigen Veröffentlichung | Öffentlicher Inhaltsbestand und nichtöffentliche Nachweise unterscheiden; Nutzerkontolöschung entscheidet nicht automatisch über alle Veröffentlichungen. Entfernungsanträge einzeln bearbeiten. | +| Entfernte Beweisarchivpakete | **B:** drei Jahre nach Ende des Entfernungsjahres | Beispielsweise Entfernung 12.10.2026 → Fristende 31.12.2029; Löschung im ersten Lauf danach. K3 zu Hold/Einschränkung; je Ereignistyp rechtlich bestätigen. | +| Archivzugriffsprotokoll | **B:** 395 Tage ab Zugriff | Separate Bereinigung trotz gegenwärtigem Löschschutz des Modells spezifizieren. Nur benötigte Identität/Zweck; begründeten Streitnachweis vor Fristende gezielt übernehmen. | +| Minimierter Löschvermerk, externe Löschjournal-Kopien | **V:** späterer Zeitpunkt nach K2 | Keine unbegrenzten Exportgenerationen. Aktuelle erforderliche Löschkennungen müssen über alle erlaubten Restores hinweg verfügbar bleiben. | +| Bounce-Rohmails einschließlich Kopien in allen erfassten Ordnern | **B:** 90 Tage ab Eingang | `INBOX`, `Processed`, `Ignored`, `Unparsed`, Papierkorb/Archiv und weitere tatsächliche Kopien inventarisieren. IMAP-Löschmarkierung allein ist keine endgültige Entfernung. | +| Ausgewertete Bounce-Daten | **B:** 395 Tage ab Eingang des Rückläufers | Freitext minimieren, Sperrentscheidung getrennt erhalten. | +| Versand-Sperrliste | **B:** solange zur Beachtung der Sperre notwendig | **V:** jährliche Zweckprüfung; Mindestdaten Adresse, Grund, Zeitpunkt, Quelle. Abmeldung nicht durch Fristablauf reaktivieren; HMAC ist optionale spätere Minimierung. | +| Fehlerberichte / Server-, Proxy- und Transportlogs | **B:** 90 Tage ab Fehler / 14 Tage ab Logereignis | GlitchTip-Instanz und alle vorgeschalteten Logs getrennt belegen. App-Scrubber begrenzt nicht automatisch Proxylogs. | +| Eigene Ereignisstatistik / öffentliche Umami-Rohdaten | **B:** 395 Tage ab Ereignis / 13 Kalendermonate ab Erhebung | Aggregationen auf verbleibende Identifizierbarkeit prüfen; Instanzlöschung belegen. Hub-Nutzerkennung bleibt aus. | +| Kontodaten | Nach Kontolöschung, soweit kein konkreter anderer Zweck fortbesteht | Notwendige Vertrags-/Rechtenachweise abtrennen. Keine fortgesetzte allgemeine Kontonutzung für Archivzwecke. | +| Rechnungs-/Buchungsbelege, Geschäftsbriefe, übrige Vertragsnachweise | Je Dokumentklasse gesetzliche beziehungsweise begründete Frist | Vorgesehene 8/6 Jahre nicht auf alle Tabellen pauschal anwenden. Steuerberater/Anwalt bestätigt Klasse und Fristbeginn; Vertragsansprüche gesondert behandeln. | +| Backups einschließlich DB, Archiv, Volumes und Sonderkopien | **B:** höchstens 14 Tage reguläre Rückhaltezeit | Ausnahmen inventarisieren, Frist und Zweck bestimmen oder beseitigen. Keine generelle 14-Tage-Zusage, solange ältere rückspielbare Kopien existieren. | + +**Ausführungsregeln:** + +1. Einheitliche Fachzeitzone `Europe/Berlin` entsprechend `config/app.php`; Zeitstempel eindeutig speichern. Tagesfristen am jeweiligen Fristzeitpunkt, Jahresfristen nach Ablauf des 31.12. fällig. Kalenderjahre/-monate nicht stillschweigend als feste Tageszahl behandeln. +2. Ziel: tägliche Bereinigung fälliger Datensätze, erfolgreiche Ausführung grundsätzlich innerhalb von 24 Stunden nach Fälligkeit. Bestehende wöchentliche Läufe für betroffene neue Zusagen entsprechend anpassen. Fehlgeschlagene Läufe alarmieren und wiederholen. +3. Bereinigung umfasst Dateien, Ableitungen, Such-/Cachekopien und benötigte Versandkopien. Gesetzlich notwendige Nachweise vorher kontrolliert abtrennen; Backups über Rotation und Restore-Sperren behandeln. +4. Altbestand mit ursprünglichem Fristbeginn verarbeiten. Fehlende Daten kennzeichnen und gezielt klären; weder Fristen durch Migration neu starten noch unbekannte Fälle als sicher löschbar ansehen. +5. Bei Umstellung Bestandszählung und Vorschau, Prüfung der Ausnahmen, kleine nachvollziehbare Verarbeitungsschritte und Abschlussbericht ohne unnötige Personendaten vorsehen. +6. Holds gelten objekt-/zweckbezogen. Ein Streit um eine Rechnung verlängert nicht automatisch alle Login- oder Mailprotokolle. +7. Diese Matrix deckt den überprüften Paketumfang ab. Vor einer öffentlichen Bezeichnung als „vollständige Liste“ noch Sessions, Passwort-Reset-Tokens, API-Tokens, Warteschlangen/fehlgeschlagene Jobs und Anbieter-Kopien mit vorhandenen Systemregeln abgleichen; keine identischen Fristen allein wegen ähnlicher Namen annehmen. + +## 4. Antworten auf F1–F11 und A1–A7 + +Die Spalte „Antwort“ enthält die fachliche Arbeitsposition. „Recht offen“ bleibt eine begrenzte Prüfaufgabe und wird nicht durch ein pauschales „Default: Ja“ ersetzt. + +| Frage | Antwort / konkrete Vorgabe | Rest | +|---|---|---| +| F1 Nummerierung | Hostabhängige Nummern beibehalten, stabile Anker und Abschnittstitel für Querverweise. | Technische Umsetzung/Linkprüfung. | +| F2 Fehlerberichte | Feld-Positivliste, keine freien Formular-/Objektinhalte; technische Transportlogs separat. Server- und Browserverarbeitung getrennt begründen. | Recht offen: Notwendigkeit des Endgerätezugriffs; Betriebsnachweis der 90/14 Tage. | +| F3 Aktivität | 90/395 Tage nach Ereignistyp gemäß Matrix; Zugriff nach erforderlicher Aufgabe begrenzen, nicht allein mit „nur zwei Admins“ begründen. | Recht offen: notwendiger Umfang/Frist für Nichtkunden-Maileinträge. | +| F4 letzte Login-IP | 90-Tage-Bereinigung umsetzen; Bedarf einer vollständigen IP begründen. Zeitstempel und IP getrennt behandeln. | Abgleich, was die Sicherheitsseite tatsächlich zeigt; keine behauptete Anzeige übernehmen. | +| F5 Bounce/Sperrliste | 90/395 Tage, zweckgebundene Sperrliste; Ausnahmen wie K6. | Rechtsgrundlage passend zum Sperrgrund; Nachweis der Postfachbereinigung. | +| F6 Hub-Analyse | Ausgeschaltet lassen; keine Nutzerkennung aktivieren. Öffentliche Instanzfrist trotzdem belegen. | Spätere gesonderte Prüfung, keine Vorabzusage „ohne Einwilligung“. | +| F7 Newsletter/Altkonten | Nachgewiesenes Opt-in mit Bestätigung für spätere Kampagnen. Keine automatisierte Übernahme von Altkonten als Einwilligende. | Juli-Mailtexte, Empfängerregel und Versanddatum prüfen; vor Sichtung keine Aussage „in Ordnung“. | +| F8 Turnstile | Tatsächliche Formulare und serverseitige IP-Übermittlung nennen; Ausweitung als Ziel ausweisen. | Notwendigkeit, Ausfallverhalten, Anbieter-/Transfernachweise. | +| F9 KI-Bilder | Bleibt aus. Vor Aktivierung Datenumfang, besondere Kategorien, Folgen für Personen, DSFA-Vorprüfung und Anbieterbedingungen klären. | Eigenes Paket, keine Sperre für sachlich unabhängige Kernarbeiten. | +| F10 Portal-Updates | Geplanter Prozess: menschliche Überprüfung und dokumentierte Freigabe; nicht als vorhandene Funktion beschreiben. | Eigene Kennzeichnung/Art.-50-Prüfung vor Aktivierung. [KI-Verordnung, Art. 50](https://eur-lex.europa.eu/eli/reg/2024/1689/oj/deu) | +| F11 DSE-Versionen | Datierte Fassungen, Änderungshinweis, dauerhafte Altversionen; keine DSE-Zustimmung fingieren. | Veröffentlichung erst passend zum tatsächlichen Stand. | +| A1 Rechteklauseln | Nutzungen, Bearbeitungen, Vorschauen, soziale Netzwerke und Beweisarchiv ausdrücklich konsistent regeln. Keine pauschale Berufung auf stillschweigende Einwilligung für jede Weiterverwendung. | Anwalt prüft konsolidierten Volltext einschließlich Freistellung und Bearbeitungsgrenzen. | +| A2 Hoster/UrhDaG | Tatsächliche Tätigkeiten darstellen; Wortwahl allein entscheidet den Status nicht. Medienprivileg nicht als pauschale Löschabwehr verwenden. | Einordnung aktiver Funktionen und DSE-Absatz; K8. | +| A3 Vertretung | Rollen und Vertragspartner nach K5; Pressekontaktfall nicht mehr als geschlossene Regresskette beschreiben. | Zulässige Bestätigung/Vertragsbindung und Übergangsregel. | +| A4 Archiv | K1–K3 und Matrix anwenden; Original und Metadaten je Anlass begründen, Zugriff präzisieren. | Fristen, sensibler Inhalt und Altbestandsmigration rechtlich prüfen. | +| A5 Einbeziehung | Bestandsschutz einschließlich Verlängerung und Altcredits nach K4; keine automatische Annahme. | Geprüfter Ablauf und passende Vertragsfassungen. | +| A6 KI-Kundenmeldungen | Selbsterklärung des Einreichers erhalten. Alt-API darf ohne Erklärung nicht „ohne KI“ bestätigen. | Technisch `not_declared` mit unbekannter Herkunft; Partnerumstellung und rechtliche Pflichten konkret prüfen. | +| A7 Regressgesamtpaket | Kette pro Veröffentlichung belegbar machen; bloß vorhandene Datenfelder genügen nicht. Keine rückwirkende Ergänzung vermeintlicher Annahmen. | Partnerbedingungen, zeitlicher Integritätsnachweis und vollständige Musterakte. | + +Für die Alt-API gilt zusätzlich: Bestehende `none`-Werte nur dann korrigieren, wenn ihre automatische Herkunft zuverlässig festgestellt werden kann. Echte Kundenerklärungen bleiben erhalten. Unklare Historie kennzeichnen; Abwesenheit einer Angabe nicht als Angabe „ohne KI“ anzeigen. + +## 5. Löschanfragen und zusätzliche Themen + +### Vier Fragen zur Bearbeitung von Lösch-/Änderungsanfragen + +| Frage | Antwort / Empfehlung | +|---|---| +| Kostenfreie Rechte gegen bezahlte Depublikation | Erst feststellen, ob ein Betroffenenrecht geltend gemacht wird und welche Verarbeitung betroffen ist. Ein kostenpflichtiges Produkt ersetzt keinen notwendigen kostenfreien Rechteweg. Die Aussage „alle Voraussetzungen sind heute erfüllt“ entfällt ohne Nachweis, insbesondere für Altverträge. | +| Früher beworbener kostenloser connektar-Weg | Aussage, Zeitraum, Entfernung, tatsächliche Nutzbarkeit und konkrete Beschwerden dokumentieren. Keine pauschale Entwarnung oder Fristannahme; rechtliche Prüfung nach K8. Eine Massenmail zur Berichtigung wird nicht ohne Prüfung vorgeschlagen. | +| Realnamen-/Kontaktänderung | Anspruch und Vertretungsbefugnis prüfen, nicht ausschließlich Absender „Person oder Firma“. Ein bevollmächtigtes Unternehmen kann für eine betroffene Person handeln. Kommerzielle Änderungen ohne Rechtebezug bleiben ein getrenntes Angebot. | +| Empfänger in der Syndikation | Eigene tatsächliche Empfänger und erforderliche Benachrichtigungen ermitteln, Partnerfälle weiterleiten und Erledigung dokumentieren. Externe Kopien nicht als sicher gelöscht ausgeben. Partnerrollen anhand realer Zwecke/Entscheidungen prüfen, nicht vertraglich einfach behaupten. | + +Für Auskunft, Berichtigung, Löschung, Widerspruch und Einschränkung einen gemeinsamen Vorgang mit Eingangsdatum, Identitäts-/Vertretungsprüfung, Entscheidung, betroffenen Systemen, Empfängern und Wiedervorlage verwenden. Arbeitsvorschlag: Kevin Adametz als Verantwortlicher, Vertretung durch eine ausdrücklich benannte berechtigte Person; keine zusätzlichen Personaldokumente ohne konkreten Bedarf sammeln. + +### Boost, Refund und Syndikation + +- **Boost:** „Gebuchte Platzierung“ ist der bestehende Textvorschlag, keine bereits bestätigte rechtssichere Kennzeichnung. Bezahlten Charakter unmittelbar am Inhalt auf Desktop, Mobil, Listen und Teasern erkennbar machen; Tooltip allein genügt als Konzept nicht. Der Anwalt beurteilt echte Ansichten. Bis zur Freigabe keine neue Kennzeichnungszusage als umgesetzt ausweisen. +- **Refund:** Beschlossenes Modell B beibehalten. Tabelle und Klausel angleichen: Erstattung auch dann, wenn der Kunde die angebotene kostenfreie Überarbeitung einer abgelehnten Einzel-PM nicht nutzen möchte; nicht ausschließlich nach einer zweiten endgültigen Ablehnung. Gesetzliche Ansprüche bleiben unberührt. Doppelte Auszahlung/Creditgutschrift verhindern, Zahlungsstatus und Webhooks abstimmen. Wechsel des MAN-Zahlungswegs ist eine separate Geschäfts-/Technikentscheidung. +- **Syndikation:** Zunächst aktuelle Partnergrundlage sichern und falsche KI-Erklärungen beseitigen. Vertragsentwurf soll Erklärungsbefugnis, Rechteumfang, Korrektur-/Löschmeldungen, Re-Sync-Sperren und tatsächliche Datenschutzrollen regeln. „Ablehnung ohne Begründungspflicht“ nicht pauschal zusagen; gesetzliche Informationspflichten gesondert prüfen. +- **API-Nutzungsbedingungen:** Eigenes Dokument nur, wenn es einen zusätzlichen Regelungsbedarf gibt. Für den Nachweis entscheidend ist eine eindeutig zugeordnete, zugängliche und wirksam angenommene Vertragsfassung; nicht die Anzahl der Dokumente. + +## 6. Verbindlich zu liefernde Betriebsnachweise + +Hier bleiben nur Tatsachen offen, die der geprüfte Code nicht beweist. Eigentümer der Nachweisbeschaffung ist Kevin Adametz; Betrieb liefert technische Nachweise. Datierte Einstellungen ohne Geheimnisse/Token ablegen, keine personenbezogenen Kontolisten in frei zugängliche Dokumentation kopieren. + +| Kennung | Nachweis | Abnahmekriterium | +|---|---|---| +| BN-01 | Live-Release, Dokumentfassungen und relevante Feature-Schalter je Host | Hub-Identifizierung, Bildprüfung, Newsletter und Gate sind mit tatsächlichem Zustand dokumentiert; Code-Default genügt nicht. | +| BN-02 | Berechtigungen, aktive Konten, 2FA und Sitzungen | Nur erforderliche Konten/Rollen aktiv; Entzug kontrolliert. Kontolöschung ist nicht Voraussetzung für den Entzug unnötiger Adminrechte. | +| BN-03 | Backupinventar einschließlich DB, Disk, Redis-Persistenz, Deploy-/Migrationskopien | Jede rückspielbare Kopie hat Speicherort, Lebensdauer und Zuständigkeit. Sonderkopien widersprechen nicht mehr einer pauschalen 14-Tage-Zusage. | +| BN-04 | Externes Löschjournal und Schlüsselverwaltung | Unabhängiger Restore, Zugriffsrechte, Aufbewahrung, Fehleralarm und getesteter aktueller Import belegt. | +| BN-05 | GlitchTip, Proxy-/Webserverlogs, Umami und Bounce-Postfach | Einstellungen plus tatsächlicher Bereinigungslauf; 90/14 Tage, 13 Monate und 90-Tage-Postfachregel stimmen mit den Texten überein. | +| BN-06 | Tatsächliche Dienstleisterverträge und Transfergrundlagen | Vertragspartei, einschlägiges Dokument/Datum, Rollen und aktuelle Übermittlungsgrundlage belegt; bei Berufung auf DPF aktueller Status der richtigen Rechtseinheit. | +| BN-07 | OpenAI-Einstellungen | Nachweise nach K7, einschließlich konkreter aktiver Textanalyse; keine bloße Produktankündigung als Kontonachweis. | +| BN-08 | Juli-Mailtexte und Versand | Tatsächlicher Inhalt, Datum, Empfängerauswahl und Versandbeleg; Tokenanzahl nicht als Ersatz. | +| BN-09 | Lauf- und Restore-Protokolle | Produktive Löschläufe und isolierte Restore-Übung erfolgreich; konkrete Fehlerbehandlung nachgewiesen. | + +## 7. Entwicklungsaufgaben und Abnahme + +Alle nachstehenden Aufgaben sind **offen**. Dokumentkorrekturen sind mit dieser Ergänzung vorbereitet, nicht automatisch in öffentliche Texte veröffentlicht. Bestehende Tests sind Ausgangsbasis und ersetzen die Abnahme neuer Funktionen nicht. + +| Aufgabe | Ausführbarer Auftrag | Abnahme / Voraussetzung | Alte Zuordnung | +|---|---|---|---| +| **RP-01 — Dokumentstand** | K1–K8 in Sachverhalt und Interessenabwägung übernehmen; konsolidierte DSE/AGB/Bestätigungstexte mit Änderungsliste erstellen; Ist und Ziel kennzeichnen. | Keine unbewiesene Gegenwartsbehauptung; alle rechtlichen Bedingungen referenziert; alte Unterlagen als historische Quelle erkennbar. | V1–V3 beider Listen | +| **RP-02 — Fristen und Bestandsdaten** | Matrix auf konkrete Tabellen/Felder/Dateispeicher abbilden; Vorgangs-IP, Entwürfe, Ablehnungen, normale Kontakte und fachliche Vorgänge bereinigen. | Keine bloße Statusänderung als Löschung; Grenztage, Altbestand, offene Fälle, Dateien und Wiederholung geprüft. Fristen vor destruktivem Bestandslauf freigegeben. | bisher U1/U2; E1–E3/E9 | +| **RP-03 — Archiv und Einschränkung** | Hold ohne Neustart, gesonderte Einschränkung, strukturierte Prüffrist, minimale Restdaten und 395-Tage-Zugriffslog umsetzen. | K2/K3; Modell-Löschschutz kontrolliert anpassen, Integrität erhalten; notwendige Ausnahmen geprüft. | bisher U3 | +| **RP-04 — Externer Löschstand** | K2 implementieren, Exportversionierung/Fristen und Restore-Sperre ergänzen; Hashnachweis gesondert behandeln. | DB alt, Disk alt, beide alt, fehlendes externes Ziel, falsche Signatur, wiederholter Import und Löschung zwischen zwei Tagesexporten geprüft. BN-03/04 erforderlich. | bisher U7 | +| **RP-05 — Rechtebelege** | Historischen Einreichungsstand und Erklärendenrolle nach K1/K5 sichern; Bestätigung je Weg; Altarchivmigration planen. | Keine erfundene historische Erklärung; partnerlose Fälle und bezahlte Übergangsfälle geregelt; Musterakte vollständig. | Klärung U11; A3/A7 | +| **RP-06 — Vertragsgate** | K4 einschließlich Verlängerung, Altcredits, gemischter Guthabenlose und API umsetzen; Annahmen getrennt von „Später“. | Bereits erworbene Leistungen nutzbar; kein Annahmedatensatz ohne Erklärung; neue Käufe mit passender Fassung; rechtliche Übergangsantwort erforderlich. | Klärung U9; ursprüngliche Liste U8 | +| **RP-07 — Protokolle und Fehlerberichte** | Ereignisse 90/395 Tage, Fehler-Positivliste und freie Textfelder begrenzen. | Namen, E-Mails, Zugangsdaten und Formularwerte in URLs/Fehlerobjekten/Breadcrumbs als Prüffälle; tatsächlich gesendetes Schema prüfen. | bisher U4/U6 | +| **RP-08 — Mail und Links** | Bounce-Ordner vollständig bereinigen, Sperrgründe trennen, definierte angeforderte Bestätigungen zulassen, Linkfrist korrekt dokumentieren. | Abmeldung bleibt wirksam; Hard Bounce bleibt gesperrt; angeforderter berechtigter Vorgang erreichbar, alternativ manueller Weg; 30-Tage-Tokenbereinigung geprüft. | bisher U5 | +| **RP-09 — Legacy-API und Partner** | Automatische falsche KI-Erklärung beseitigen; Altbestand nach Herkunft behandeln; aktuelle Vertrags-/Erklärungszuordnung der Partner prüfen. | Neue unbekannte Angabe nicht als bestätigtes „ohne KI“; echte Erklärungen unverändert; Partnerübergang dokumentiert. | Klärung U8; A6 | +| **RP-10 — Betrieb und Berechtigungen** | BN-01 bis BN-09 liefern; Kontoberechtigungen bereinigen, Backups/Instanzfristen und Alarmwege einrichten. | Echte Nachweise statt Defaultwerte, benannte ausführende Zuständigkeit, offene Anbieterfragen geklärt. | ursprüngliche Liste U9; Klärung U13–U15 | +| **RP-11 — Zusatzpakete** | Boost-Kennzeichnung, Refund B und Syndikationsvertrag getrennt spezifizieren; Ist-Risiken in Kernfreigabe berücksichtigen. | Eigene Abnahme; keine ungeprüfte Erweiterung des Kern-Deploys. Gesetzlich notwendige Korrekturen aktiver Funktionen werden nicht verschoben. | Klärung U10/U12; Syndikation | +| **RP-12 — Texte und Freigabe** | Rechtliche Antworten einarbeiten, Interessenabwägung abzeichnen, passende Textfassungen und Gate-Zuordnungen ausrollen. | Zielmaßnahmen wirksam, Bestandsläufe/Restore nachgewiesen, Host-/Versionsprüfung, Rollback erhält Löschstand und Annahmen. | ursprüngliche Liste U8/U9 | + +**Reihenfolge:** RP-01 und technische Spezifikation parallel zur externen Klärung; danach RP-02 bis RP-10 nach Abhängigkeiten. RP-03 und RP-04 gemeinsam entwerfen, bevor Restfelder entfernt werden. RP-05 und RP-06 anhand freigegebener Rollen/Verträge bauen. RP-11 separat führen. RP-12 schließt das Kernpaket ab. + +**Gezielte Prüffälle für die spätere Implementierung:** Frist unmittelbar davor/danach und Jahreswechsel; derselbe Lauf zweimal; Dateifehler bei Teilverarbeitung; offener Archivauftrag; Hold plus Einschränkung; Kontolöschung nach Einreichung; fehlende historische Vertragsfassung; Abo-Verlängerung ohne Zustimmung; gemischte Credits; Partner-/Pressekontaktfall; Versand bei Abmeldung gegenüber Hard Bounce; Restore mit unvollständigem Löschstand. Die fachlichen Ergebnisse prüfen, nicht bloß interne Methodenaufrufe nachbauen. + +## 8. Verbleibende Entscheidungen — mit vorgeschlagener Antwort + +Diese Liste ersetzt die ungerichtete Frage „Ist alles ausreichend?“. Antworten jeweils mit Datum, Person und Bedingungen dokumentieren. Unabhängige technische Vorbereitung darf währenddessen weiterlaufen. + +| Kennung | Konkrete offene Entscheidung | Empfohlene Ausgangsposition | Wer / Auswirkung | +|---|---|---|---| +| **R-01** | Archiv je Ereignistyp: drei Jahre nach Jahresende, Originalmetadaten, sensible Inhalte, Antragstellerdaten und Altbestandsmigration tragfähig? | Minimaler Umfang nach K1–K3, keine pauschale Verweigerung von Rechten; Besonderheiten je Fall. | Anwalt + Betreiber; bestimmt RP-02/03/05 und DSE. | +| **R-02** | Sind 395 Tage Mail-/Archivzugriffslog und Löschbeleg, 180 Tage abgeschlossene Kontakte und übrige Matrixfristen verhältnismäßig? | Matrix als konkrete Prüfbasis; kürzere Frist verwenden, wenn Nachweiszweck fehlt. | Anwalt + Betreiber; bestimmt endgültige Löschkonfiguration. | +| **R-03** | Tragen Bestandsschutz, Verlängerung und Altcredits nach K4 die bestehende Vertragslage? | Keine automatische Umstellung ohne wirksame Grundlage; bestehende Ansprüche erfüllen. | Anwalt; Voraussetzung RP-06-Freigabe. | +| **R-04** | Welche Bindung/Vertretung genügt bei Partnern und Pressekontakten, und sind konsolidierte Bildrechtsklauseln wirksam? | Gebundener Vertragspartner und überprüfbare Erklärung statt angenommener Anscheinsvollmacht. | Anwalt + Betreiber; Voraussetzung neuer Bildwege. | +| **R-05** | Fehler-SDK/Turnstile ohne Einwilligung im konkret belegten Umfang zulässig? | Nur begründeter notwendiger Umfang; keine pauschale Zusage aus Cookielosigkeit. | Anwalt; bei negativem Ergebnis betroffenen Browserdienst anpassen/deaktivieren, manuelle Kontaktwege erhalten. | +| **R-06** | Hoster-/Medienprivileg, KI-Kennzeichnung, Löschentgelte und frühere connektar-Aussage korrekt behandelt? | Aktive Tätigkeiten und konkrete Texte vorlegen; keine allgemeine Haftungs-/Anspruchsfreiheit behaupten. | Anwalt; bestimmt betroffene Rechtstexte und aktive Prozesse. | +| **B-01** | Welcher unabhängige Speicher, welche Schlüssel-/Alarmzuständigkeit? | Geeignete vorhandene Infrastruktur mit getrenntem Restore und Ereignissicherung nach K2. | Betreiber/Betrieb; Voraussetzung RP-04-Implementierung. | +| **B-02** | Welche produktiven Einstellungen und Verträge gelten tatsächlich? | BN-01 bis BN-08 belegen; Betreiberangabe und technischen Nachweis getrennt halten. | Betreiber/Betrieb; Voraussetzung zutreffender öffentlicher Zusagen. | + +**Zuordnung der 14 Fragen der Versandfassung:** Nr. 1 → R-04/RP-11; Nr. 2 → R-03; Nr. 3 → R-01/R-02; Nr. 4/5 → R-06; Nr. 6 → A6 und separates Portal-Updates-Paket; Nr. 7 → RP-11; Nr. 8/9 → R-05; Nr. 10/11 → R-02 und K6; Nr. 12 → Abschnitt 5/R-06; Nr. 13 → K1/K2/K5; Nr. 14 → RP-11. Die drei späteren Aktivierungen bleiben F6/F7/F9 zugeordnet. Damit verschwindet keine bisherige Frage durch die Konsolidierung. + +**Geschäftliche Zuständigkeit:** Kevin Adametz bleibt für Umfang, Betreiberangaben und Freigabe zuständig. Anwalt sowie ausführende Entwicklungs-/Betriebsverantwortliche sind in der Übergabe namentlich einzutragen; ihre Mitwirkung oder Zustimmung wird hier nicht behauptet. + +## 9. Ab wann kann das Paket als umsetzungsreif gelten? + +- [ ] RP-01 liegt als widerspruchsfreier konsolidierter Entwurf mit dieser Korrekturfassung vor. +- [ ] R-01 bis R-06 sind beantwortet oder betreffen nach dokumentierter Abgrenzung ausschließlich ein späteres Zusatzpaket. +- [ ] B-01 und die für den Entwicklungsauftrag benötigten Teile von B-02 sind geklärt. +- [ ] Matrix ist freigegeben, auf konkrete Speicherorte abgebildet und enthält Regeln für Altbestand und Ausnahmen. +- [ ] RP-02 bis RP-10 haben benannte Zuständigkeiten und die oben festgelegten Abnahmekriterien; neue abweichende Entscheidungen sind eingearbeitet. + +**Dann:** „Kernpaket umsetzungsreif“. Bereits fachlich geklärte Teilaufgaben können vorher beginnen. Die verbleibenden Fragen sind keine Aufforderung, sämtliche Vorarbeiten anzuhalten. + +**Abgeschlossen** ist das Paket erst nach Implementierung, passenden erfolgreichen Tests, nachgewiesenen Lösch-/Restore-Läufen, erfüllten rechtlichen Bedingungen, abgezeichneter Interessenabwägung und Veröffentlichung der zutreffenden Fassungen. Produktive Datums-/Releaseangaben werden erst dann eingetragen. Ein Rollback darf gelöschte Inhalte oder widerrufene Berechtigungen nicht wieder aktivieren. + +## 10. Quellen und Prüfgrenzen + +Interne Grundlage: [Versandfassung](anwaltspaket-datenschutz-2026-10-12.md), [Klärungsdokument](klaerung-anwaltspaket-2026-10-12.md), [Interessenabwägung](interessenabwaegung-beweisarchiv-2026-10-12.md), [Live-Rechtstexte als Anlage](anlage-rechtstexte-live-2026-10-12.md), [ursprüngliche Codeauswertung](../archive/rechtliches-2026-10/auswertung-und-abschlussentscheidungen-2026-10-12.md), [Betreiberentscheidungen in der To-do-Liste](../archive/rechtliches-2026-10/todo-umsetzungsreife-und-abschluss-2026-10.md) und [Rückfragen/Betreiberergänzungen](../archive/rechtliches-2026-10/antworten-rueckfragen-anwaltspaket-2026-10-12.md). + +Die genannten Codebefunde wurden lesend abgeglichen. Diese Bearbeitung ändert Dokumentation und Navigation, keine Anwendung, Produktivkonfiguration oder Daten. Die zuvor dokumentierten 82 Tests mit 559 Assertions beziehen sich auf die frühere Ausgangsprüfung; sie belegen keine der hier neu vorgeschlagenen Funktionen. Für diese Dokumentänderung werden Verweise und Struktur geprüft, keine neuen Anwendungstests behauptet. + +Rechtliche Primärquellen wurden am 12.10.2026 zur Einordnung herangezogen und stehen bei den betreffenden Aussagen. Konkrete Vertragswirksamkeit, Interessenabwägung und externe Betriebszustände bleiben auf den beschriebenen Sachverhalt und die noch zu liefernden Nachweise angewiesen. diff --git a/dev/rechtliches/nachweise/README.md b/dev/rechtliches/nachweise/README.md new file mode 100644 index 00000000..eb6f5fc2 --- /dev/null +++ b/dev/rechtliches/nachweise/README.md @@ -0,0 +1,46 @@ +# Nachweise zum Anwaltspaket + +**Stand:** 13.10.2026 · Gehört zu [Versandfassung](../anwaltspaket-datenschutz-2026-10-12.md) und [Korrekturen, Abschnitt 6 (BN-01 bis BN-09)](../korrekturen-und-umsetzungsauftrag-2026-10-12.md). + +Regel: keine vollständigen E-Mail-Adressen, Tokens oder Schlüssel in diesem Ordner. Konten nur mit ID und Domain. + +Status: ✅ liegt vor · ◐ aus Code/Daten vorbelegt, auf Live bestätigen · ☐ offen (Betreiber) + +## Vor dem Versand + +| Datei | Status | Hinweis | +|---|---|---| +| `bn-02-berechtigungen-2026-10-XX.md` | ☐ | Vorher/Nachher-Liste mit `php artisan audit:admins`; Ablauf in [`bn-02-ablauf.md`](bn-02-ablauf.md) | +| `boost-01-startseite-desktop.png` | ☐ | U10 ist im Code; erst nach dem Deploy aufnehmen. Boost danach unter Admin ▸ Pressemitteilung ▸ „Boost beenden“ beenden | +| `boost-02-branchenseite-desktop.png` | ☐ | dito | +| `boost-03-startseite-mobil.png` | ☐ | 390 px | +| `boost-04-tooltip.png` | ☐ | Maus über dem Label; auf Mobil erscheint dieselbe Erklärung per Tipp | +| `ui-01-upload-rechtebestaetigung.png` | ☐ | Hub ▸ Mitteilung bearbeiten ▸ Titelbild hochladen, Abschnitt „3 · Bestätigung“. Der Aufklapper heißt „Vollständiger Wortlaut“, nicht „Details“. | +| `ui-02-upload-ki-angabe.png` | ☐ | Radiogruppe „KI-Kennzeichnung“. **Eine gesperrte Vorbelegung gibt es noch nicht** (C2PA-Prüfung ist Phase 2); höchstens „Angaben aus den Metadaten der Datei vorbelegt“ mit einem Bild mit IPTC-Quelle. | +| `ui-03-bild-nachweiszeile.png` | ☐ | Unter dem Bild steht nur „Foto: … · KI-…“. „Bild und Angaben: [Firma], eingereicht am …“ steht nur im Overlay (→ ui-04). | +| `ui-04-bild-detailfenster.png` | ☐ | „i“-Knopf links unten am Bild. Die Zeile heißt „Kennzeichnung: …“, nicht „Quelle der Kennzeichnung“. | +| `ui-05-konto-sicherheit.png` | ☐ | `/admin/me/security` | +| `ui-06-zustimmungsgate-dev.png` | ☐ | lokal mit `LEGAL_ACCEPTANCE_GATE=true` und aktiver Buchung. Der Dialog zeigt nur die Versionsnummer, kein Datum, und keine Schaltfläche „Später entscheiden“. | +| `ui-07-ki-hinweis-text.png` | ☐ | z. B. `presseecho.de/de/press-release/online-fachkurs-unterstutzt-gefahrdungsbeurteilungen-nach-biostoffv`. Die Admin-Liste hat keinen Filter nach KI-Angabe; die 9 Mitteilungen kommen aus der Datenbank. | +| `avv-hetzner.pdf` | ☐ | | +| `avv-all-inkl.pdf` | ☐ | | +| `cloudflare-dpf-2026-10-XX.png` | ☐ | füllt „[Prüfdatum eintragen]“ in D6 | +| `cloudflare-dpa.png` | ☐ | | +| `openai-dpa.pdf` | ☐ | | +| `openai-zdr.png` | ☐ | | +| `openai-residency.png` | ☐ | Live nutzt laut Code `api.openai.com`, nicht den EU-Endpunkt | +| `openai-endpoints.md` | ◐ | aus dem Code; Live-Werte über BN-01 | +| `stripe-dpa.png` | ☐ | | +| `avv-fehlt.md` | ☐ | nur falls ein Vertrag fehlt | +| `juli-mail-abonnenten.md` | ◐ | Kampagne #1, 21.07.2026 | +| `juli-mail-aktive-konten.md` | ◐ | Kampagne #2, 22.07.2026 | +| `juli-mail-versand.md` | ◐ | Regel und Zahlen; Live-Abgleich per Befehl in der Datei | + +## Vor Deploy 3 (parallel zur Anwaltsprüfung) + +| Datei | Status | Hinweis | +|---|---|---| +| `bn-01-release-und-schalter.md` | ◐ | Vorlage mit Befehlen und Code-Standards | +| `bn-03-backups.md` | ☐ | inkl. Roadmap 1.5 und `redis-cli CONFIG GET save` / `appendonly` | +| `bn-05-instanzfristen.md` | ☐ | GlitchTip 90 Tage, Nginx-Logrotate 14 Tage, Umami 13 Monate, Löschregel Bounce-Postfach | +| BN-04, BN-09 | – | entstehen mit RP-04 | diff --git a/dev/rechtliches/nachweise/bn-01-release-und-schalter.md b/dev/rechtliches/nachweise/bn-01-release-und-schalter.md new file mode 100644 index 00000000..3cee930c --- /dev/null +++ b/dev/rechtliches/nachweise/bn-01-release-und-schalter.md @@ -0,0 +1,36 @@ +# BN-01: Release und Schalter auf Live + +**Erhoben am:** [Datum] · **von:** [Name] · **Server:** [Host] + +## Befehle (auf dem Live-Server im App-Verzeichnis) + +```bash +php artisan --version +git describe --tags --always +grep -E '^(APP_ENV|SESSION_DRIVER|CACHE_STORE|UMAMI_ENABLED|UMAMI_PORTAL_ENABLED|UMAMI_IDENTIFY_USERS|LEGAL_ACCEPTANCE_GATE|IMAGE_RIGHTS_V2|IMAGE_PRECHECK|IMAGE_PRECHECK_STAGE|NEWSLETTER_SENDING_ENABLED|AUTH_REQUIRE_STRONG_ADMIN|OPENAI_API_URL|OPENAI_MODEL|CLASSIFICATION_MODEL|CONTENT_SCORE_MODEL|TURNSTILE_FAIL_OPEN|ARCHIVE_RETENTION_YEARS|BOUNCE_RETENTION_DAYS|MONITORING_ACTIVITY_RETENTION_DAYS|MONITORING_API_USAGE_RETENTION_DAYS|MONITORING_FAILED_LOGIN_RETENTION_DAYS|LOG_DAILY_DAYS)=' .env +php artisan tinker --execute 'foreach (["agb","datenschutz","richtlinien"] as $t) { $d = App\Models\LegalDocument::current($t); echo $t.": ".($d->version ?? "-")." ab ".($d->effective_from ?? "-").PHP_EOL; }' +``` + +Die `grep`-Zeile gibt nur Schalter und Fristen aus, keine Schlüssel. Fehlt ein Schlüssel in der Ausgabe, gilt der Code-Standard (Spalte „Standard“). + +## Ergebnis + +| Schlüssel | Bedeutung | Standard im Code | Live | +|---|---|---|---| +| Release-Tag | | | | +| `php artisan --version` | | | | +| `UMAMI_ENABLED` | Umami auf öffentlichen Seiten | false | | +| `UMAMI_PORTAL_ENABLED` | Umami im Kundenbereich (D7) | false | | +| `UMAMI_IDENTIFY_USERS` | Nutzerkennung an Umami (D7) | false | | +| `LEGAL_ACCEPTANCE_GATE` | Zustimmungsgate | false | | +| `IMAGE_RIGHTS_V2` | Bild-Upload mit Rechtebestätigung (D1) | false | | +| `IMAGE_PRECHECK` | KI-Vorabprüfung von Bildern (D8) | false | | +| `NEWSLETTER_SENDING_ENABLED` | Newsletter-Versand (D10) | false | | +| `AUTH_REQUIRE_STRONG_ADMIN` | Zweiter Faktor für Admins | true | | +| `SESSION_DRIVER` / `CACHE_STORE` | Speicher für Sitzungen und Anmeldezähler | database / database | | +| `OPENAI_API_URL` / `OPENAI_MODEL` | Endpunkt und Modell der Textprüfung | api.openai.com / gpt-5.4-mini | | +| `TURNSTILE_FAIL_OPEN` | Eingabe annehmen, wenn Cloudflare nicht erreichbar | true | | +| Fristen (`ARCHIVE_…`, `BOUNCE_…`, `MONITORING_…`, `LOG_DAILY_DAYS`) | | 3 J. / 395 / 395 / 90 / 90 / 14 | | +| AGB / DSE / Richtlinien laut `legal_documents` | aktive Fassungen | 0.6 / 0.3 / 0.2 | | + +**Muss stimmen, damit das Paket zutrifft:** `IMAGE_PRECHECK` aus (das Paket nennt D8 „ausgeschaltet“; in der lokalen Entwicklungsumgebung ist es an), `NEWSLETTER_SENDING_ENABLED` aus, `UMAMI_IDENTIFY_USERS` aus, `LEGAL_ACCEPTANCE_GATE` aus (laut Paket ausgeschaltet bis Deploy 3), `IMAGE_RIGHTS_V2` an (D1 „aktiv seit 28.09.2026“). diff --git a/dev/rechtliches/nachweise/bn-02-ablauf.md b/dev/rechtliches/nachweise/bn-02-ablauf.md new file mode 100644 index 00000000..6f456382 --- /dev/null +++ b/dev/rechtliches/nachweise/bn-02-ablauf.md @@ -0,0 +1,92 @@ +# BN-02: Rollenprüfung auf Live, Ablauf + +**Ziel:** eine datierte Liste vorher und nachher. Die Nachher-Liste ist der Nachweis. +**Stand der Planung:** 13.10.2026, Bestand aus der lokalen Kopie der Live-Datenbank vom 07.10.2026. + +## Bestand (Kopie vom 07.10.2026) + +| ID | Domain | Rechte | Status | Daten am Konto | Vorgehen | +|---|---|---|---|---|---| +| 1 | pressekonto.com | `admin`, 1 Passkey, kein TOTP | aktiv | Betriebskonto | bleibt; neue Login-Adresse, Super-Admin-Merker, TOTP als Reserve | +| 18847 | me.com | **Super-Admin-Merker**, Rolle `customer`, 2 importierte API-Schlüssel (nie benutzt) | aktiv, letzte Anmeldung 14.07.2026 | 2 Mitteilungen, 2 Firmen; alter Entwicklerzugang des Betreibers | Merker entziehen, Schlüssel widerrufen, Sitzungen beenden, sperren, Adresse durch Zufallsadresse ersetzen | +| 15258 | stern-consulting.eu | `admin` | aktiv, letzte Anmeldung 2012 | keine | Rolle entziehen, löschen | +| 2 | stern-tours.de | `admin` | gesperrt | 1.762 Mitteilungen | Rolle `admin` → `customer` | +| 3 | googlemail.com | `admin` | gesperrt | 5 Mitteilungen, 7 Firmen | Rolle `admin` → `customer` | +| 13665 | gmx.at | `admin` | gesperrt | 2 Firmen | Rolle `admin` → `customer` | + +**Warum das alte Entwicklerkonto gesperrt statt gelöscht wird:** Beim Löschen eines Kontos werden seine Pressemitteilungen über den Fremdschlüssel mitgelöscht (`press_releases.user_id`, `cascadeOnDelete`), ohne Eintrag im Beweisarchiv. Ein gesperrtes Konto ohne Rechte, Schlüssel und Sitzungen hat keinen Zugang mehr. Löschen erst, wenn über die 2 Mitteilungen entschieden ist. Die Zufallsadresse unter der reservierten Domain `.invalid` gibt die alte Adresse frei, ist nicht erratbar und kann keine Mail empfangen. + +Die drei gesperrten Altkonten (2, 3, 13665) behalten ihre Adresse: Sie gehören zu Firmen mit veröffentlichten Mitteilungen, haben nach dem Rollenwechsel nur Kundenrechte und können sich als gesperrte Konten nicht anmelden. + +## Schritt 1: Vorher-Liste + +```bash +php artisan audit:admins > ~/bn-02-vorher.md +``` + +Ohne `--with-emails` enthält die Datei nur Domains und darf in diesen Ordner. Die Fassung mit vollständigen Adressen bleibt außerhalb des Repositorys. + +## Schritt 2: Betriebskonto vorbereiten + +1. Postfach für die neue Login-Adresse anlegen, mit einer zufälligen Zeichenfolge im lokalen Teil. Sie steht nirgends öffentlich und lässt sich nicht aus Name oder Rolle ableiten. +2. Im Hub unter Profil die E-Mail-Adresse ändern. Die Bestätigung wird zurückgesetzt; bis zum Klick auf den Link in der Bestätigungsmail ist der Admin-Bereich gesperrt (`verified`). +3. Super-Admin-Merker setzen. Das geht nur durch einen Super-Admin oder per Tinker: + + ```bash + php artisan tinker --execute 'App\Models\User::findOrFail(1)->forceFill(["is_super_admin" => true])->save();' + ``` + +4. Unter Konto-Sicherheit zusätzlich TOTP einrichten. Ohne zweiten Weg sperrt ein verlorener Passkey das einzige Admin-Konto aus. + +## Schritt 3: Altkonten bereinigen + +Vorher die IDs mit der Vorher-Liste abgleichen. Die Tabelle oben stammt aus der Kopie vom 07.10.2026. + +```bash +php artisan tinker --execute ' +$revoke = app(App\Services\Auth\SessionRevocation::class); + +$alt = App\Models\User::findOrFail(18847); +$alt->tokens()->delete(); +$alt->forceFill([ + "is_super_admin" => false, + "is_active" => false, + "email" => "gesperrt-".Illuminate\Support\Str::lower(Illuminate\Support\Str::random(24))."@pressekonto.invalid", +])->save(); +$revoke->revokeAllFor($alt); + +$leer = App\Models\User::findOrFail(15258); +$leer->syncRoles([]); +$leer->tokens()->delete(); +$leer->forceDelete(); + +foreach ([2, 3, 13665] as $id) { + App\Models\User::findOrFail($id)->syncRoles(["customer"]); +} +echo "ok\n";' +``` + +## Schritt 4: Nachher-Liste + +```bash +php artisan audit:admins > bn-02-berechtigungen-2026-10-XX.md +``` + +Die Zeile „Stand …: 1 Konto mit Zugang zum Admin-Bereich, davon 1 mit zweitem Faktor …“ geht ins Anwaltspaket (D3). Am Ende der Datei die Zugänge außerhalb der Anwendung eintragen (Ploi, Hetzner-Konsole, SSH). + +## Notfallzugang + +Den Notfallzugang hat der Betreiber über SSH auf dem Live-Server. Sperrt sich das Admin-Konto aus (Passkey verloren, kein TOTP), werden Zweitfaktoren per Tinker zurückgesetzt. Danach wie gewohnt anmelden und den Zweitfaktor unter Konto-Sicherheit neu einrichten: + +```bash +php artisan tinker --execute ' +$u = App\Models\User::findOrFail(1); +$u->passkeys()->delete(); +$u->forceFill(["two_factor_secret" => null, "two_factor_recovery_codes" => null, "two_factor_confirmed_at" => null, "is_active" => true])->save(); +app(App\Services\Auth\SessionRevocation::class)->revokeAllFor($u); +echo "Zweitfaktoren zurückgesetzt\n";' +``` + +Ohne Zugriff auf das Postfach geht ein neues Passwort ebenfalls per Tinker (`$u->forceFill(["password" => "…"])->save();`, wird gehasht). Den Vorgang danach im Aktivitätsverlauf oder hier mit Datum vermerken. + +Für die Nachher-Liste unter „Zugänge außerhalb der Anwendung“: SSH, Ploi und Hetzner-Konsole nur Betreiber [bestätigen oder ergänzen]. diff --git a/dev/rechtliches/nachweise/juli-mail-abonnenten.md b/dev/rechtliches/nachweise/juli-mail-abonnenten.md new file mode 100644 index 00000000..0966ca75 --- /dev/null +++ b/dev/rechtliches/nachweise/juli-mail-abonnenten.md @@ -0,0 +1,34 @@ +# Juli-Mail an Konten mit Bestandsvertrag (BN-08) + +**Quelle:** Kampagne #1 im internen Newsletter-Modul (Admin ▸ Newsletter), Tabelle `newsletter_campaigns`. Abgelesen am 13.10.2026 aus der lokalen Kopie der Live-Datenbank (letzter Eintrag dort 07.10.2026). Auf Live gegenprüfen, siehe `juli-mail-versand.md`. + +| | | +|---|---| +| Betreff | Ihr Vertrag läuft weiter wie bisher – unser Portal ist neu | +| Angelegt | 21.07.2026, 12:19 | +| Versendet | 21.07.2026, 16:31 (Kampagne abgeschlossen) | +| Versandweg | `App\Mail\NewsletterCampaignMail`, zentrales Mail-Layout, Abmeldelink mit One-Click-Abmeldung (RFC 8058), Abmeldeart „Newsletter“ | + +## Text (wörtlich, Links als Text) + +> Sie haben bei presseecho.de / businessportal24.com einen laufenden Vertrag. Deshalb schreiben wir Sie direkt an: Seit dem 20.07.2026 läuft unser Portal auf einem neuen System. +> +> Für Ihren Vertrag gilt Bestandsschutz. Er läuft unverändert weiter, zum gleichen Preis und im gewohnten jährlichen Rhythmus. Sie müssen nichts tun. +> +> Falls Sie den Vertrag irgendwann nicht mehr brauchen, kündigen Sie ihn zum Ende der laufenden Abrechnungsperiode. Eine Antwort auf diese E-Mail genügt. Sie können auch auf eines der neuen Pakete wechseln, alle Preise stehen offen auf der Website. Müssen Sie aber nicht. Ihr Vertrag bleibt gültig, solange Sie ihn behalten möchten. +> +> Neu ist vor allem das Portal selbst. Wir haben es komplett neu gebaut. Ihre Pressemitteilungen laden schneller, sehen auf dem Handy endlich vernünftig aus, und die Technik dahinter ist so umgestellt, dass Google die Meldungen besser auswerten kann. Das gilt auch für alles, was Sie in der Vergangenheit veröffentlicht haben. Die Meldungen bleiben online und profitieren mit. +> +> Entdecken Sie die neuen Funktionen und Umfang der Presseportale. Weitere Features sind in Entwicklung. +> +> Eine Sache ändert sich im Alltag: Ihr Konto verwalten Sie künftig über pressekonto.com. Dort liegen Zugangsdaten, Firmenprofil und Rechnungen an einer Stelle. Beim nächsten Login [setzen Sie einmalig ein neues Passwort / bekommen Sie einen Anmeldelink per E-Mail]. +> +> Ihre Daten haben wir nach der aktualisierten Datenschutzerklärung übernommen. Sie ist im Portal verlinkt. +> +> Wenn etwas hakt oder unklar ist, antworten Sie einfach auf diese Mail. +> +> Freundliche Grüße +> +> Ihr Team von pressekonto + +**Hinweis:** Der Platzhalter in eckigen Klammern ist so versendet worden. diff --git a/dev/rechtliches/nachweise/juli-mail-aktive-konten.md b/dev/rechtliches/nachweise/juli-mail-aktive-konten.md new file mode 100644 index 00000000..b061f8e6 --- /dev/null +++ b/dev/rechtliches/nachweise/juli-mail-aktive-konten.md @@ -0,0 +1,34 @@ +# Juli-Mail an Konten mit Anmeldung im letzten Jahr (BN-08) + +**Quelle:** Kampagne #2 im internen Newsletter-Modul, Tabelle `newsletter_campaigns`. Abgelesen am 13.10.2026 aus der lokalen Kopie der Live-Datenbank (letzter Eintrag dort 07.10.2026). Auf Live gegenprüfen, siehe `juli-mail-versand.md`. + +| | | +|---|---| +| Betreff | Unser Portal ist neu – Ihr Account ist schon umgezogen | +| Angelegt | 22.07.2026, 10:35 | +| Versendet | 22.07.2026, 10:35 bis 19:34 laut Aktivitätsverlauf; Kampagne abgeschlossen am 23.07.2026, 02:49 | +| Versandweg | `App\Mail\NewsletterCampaignMail`, zentrales Mail-Layout, Abmeldelink mit One-Click-Abmeldung (RFC 8058), Abmeldeart „Newsletter“ | + +## Text (wörtlich, Links als Text) + +> Sie haben sich in den letzten Monaten bei presseecho.de / businessportal24.com angemeldet. Deshalb schreiben wir Sie direkt an: Seit dem 20.07.2026 läuft unser Portal auf einem neuen System. +> +> Das Wichtigste vorab: Ihr Account und Ihre Daten sind übernommen, Ihre veröffentlichten Pressemitteilungen bleiben online. Kosten oder Verpflichtungen entstehen Ihnen dadurch nicht. Es wird nichts automatisch gebucht, und nichts verlängert sich still. Ob und wann Sie wieder veröffentlichen, entscheiden Sie. Alle Preise stehen offen auf der Website. +> +> Neu ist vor allem das Portal selbst. Wir haben es komplett neu gebaut. Pressemitteilungen laden schneller, sehen auf dem Handy endlich vernünftig aus, und die Technik dahinter ist so umgestellt, dass Google die Meldungen besser auswerten kann. Das gilt auch für alles, was Sie in der Vergangenheit veröffentlicht haben. +> +> Eine Sache ändert sich im Alltag: Ihr Konto verwalten Sie künftig über pressekonto.com. Dort liegen Zugangsdaten, Firmenprofil und Rechnungen an einer Stelle, und von dort veröffentlichen Sie auf dem Portal. Beim nächsten Login [setzen Sie einmalig ein neues Passwort / bekommen Sie einen Anmeldelink per E-Mail]. Für Veröffentlichungen brauchen Sie künftig ein hinterlegtes Firmenprofil. Falls Ihres unvollständig ist, weist das System Sie beim Login darauf hin. +> +> Ihre Daten haben wir nach der aktualisierten Datenschutzerklärung übernommen. Sie ist im Portal verlinkt. Sollten Sie Ihren Account nicht mehr benötigen, können Sie ihn jederzeit löschen lassen. +> +> Wenn etwas hakt oder unklar ist, antworten Sie einfach auf diese Mail. +> +> Freundliche Grüße +> +> Ihr Team von pressekonto + +**Hinweis:** Der Platzhalter in eckigen Klammern ist so versendet worden. + +## Nicht versendet + +Kampagne #3 „Ihr Konto bei presseecho.de / businessportal24.com: Systemumzug abgeschlossen“ (an alle Konten, angelegt 22.07.2026) steht bis heute auf Entwurf, mit 0 Empfängern. Die übrigen rund 58.600 aktiven Altkonten (59.602 aktiv abzüglich der rund 965 Empfänger) haben also keine Information zum Umzug bekommen. diff --git a/dev/rechtliches/nachweise/juli-mail-versand.md b/dev/rechtliches/nachweise/juli-mail-versand.md new file mode 100644 index 00000000..754203bc --- /dev/null +++ b/dev/rechtliches/nachweise/juli-mail-versand.md @@ -0,0 +1,38 @@ +# Juli-Mails: Empfängerregel und Versandzahlen (BN-08) + +**Stand:** 13.10.2026, vorbelegt aus der lokalen Kopie der Live-Datenbank (letzter Eintrag 07.10.2026). Die Zahlen werden vor dem Versand des Pakets auf Live bestätigt (Befehl unten). + +## Empfängerregel + +Die Regel steht in `app/Services/Newsletter/CampaignRecipients.php`. Sie gilt für beide Mails: aktive Konten mit E-Mail-Adresse, ohne Newsletter-Abmeldung. Dazu kommen je Mail die gespeicherten Filter: + +| Mail | Filter laut Kampagne | In einem Satz | +|---|---|---| +| #1 Bestandsvertrag | `legacy_contract: true`, `login: within`, `login_months: 12` | Konten mit laufendem Bestandsvertrag (Zahlungsvereinbarung „grandfathered“) **und** Anmeldung in den letzten 12 Monaten. | +| #2 Aktive Konten | `login: between 0–12 Monate`, `exclude_campaign_id: 1` | Konten mit Anmeldung in den letzten 12 Monaten, ohne die Empfänger von Mail #1. | + +**Begründung (Betreiber, 13.10.2026):** Die Beschränkung auf Konten mit Anmeldung in den letzten 12 Monaten war Absicht; die Filter wurden dafür gebaut. Konten ohne Anmeldung seit über einem Jahr gelten als nicht mehr genutzt und wurden nicht angeschrieben. Das gilt auch für Bestandsverträge ohne Anmeldung in diesem Zeitraum. + +## Anzahl + +| Mail | Empfänger laut Kampagne | versendet | fehlgeschlagen | übersprungen | Einträge „E-Mail versendet“ im Aktivitätsverlauf | +|---|---|---|---|---|---| +| #1 | 10 | 10 | 0 | 0 | 11 (21.07.2026, 12:20–16:31) | +| #2 | 970 | 954 | 5 | 11 | 955 (22.07.2026, 10:35–19:34) | + +**Auffälligkeiten, auf Live zu klären:** + +- Bei Mail #1 gibt es einen Eintrag mehr im Aktivitätsverlauf als in der Kampagne. Wahrscheinlich eine Testmail um 12:20, vor dem eigentlichen Versand um 16:31. +- Die Einzelprotokoll-Tabelle `newsletter_campaign_recipients` enthält zu Mail #2 nur 500 Zeilen (497 versendet, 3 fehlgeschlagen). Kampagnenzähler und Aktivitätsverlauf nennen dagegen rund 955. + +## Prüfung auf Live + +```bash +php artisan tinker --execute ' +foreach (App\Models\NewsletterCampaign::query()->orderBy("id")->get() as $c) { + echo $c->id." | ".$c->status." | ".$c->subject." | total ".$c->recipients_total." | sent ".$c->sent_count." | failed ".$c->failed_count." | skipped ".$c->skipped_count." | ".$c->sent_at.PHP_EOL; + echo " Protokollzeilen: ".json_encode(DB::table("newsletter_campaign_recipients")->where("newsletter_campaign_id", $c->id)->selectRaw("status, count(*) n")->groupBy("status")->pluck("n", "status")).PHP_EOL; +}' +``` + +Gegenprobe im Admin: Berichte ▸ Aktivität, Typ „E-Mail“, Suche nach dem Betreff. diff --git a/dev/rechtliches/nachweise/openai-endpoints.md b/dev/rechtliches/nachweise/openai-endpoints.md new file mode 100644 index 00000000..6cda7107 --- /dev/null +++ b/dev/rechtliches/nachweise/openai-endpoints.md @@ -0,0 +1,16 @@ +# OpenAI: Endpunkte und Modelle (BN-07) + +**Stand:** 13.10.2026, aus dem Code (Release v1.8.x). Die Werte auf Live werden mit BN-01 bestätigt (`OPENAI_API_URL`, `OPENAI_MODEL`, `CLASSIFICATION_MODEL`, `CONTENT_SCORE_MODEL`, `IMAGE_PRECHECK`). + +**Kurzfassung:** Die Textprüfung nutzt `POST https://api.openai.com/v1/chat/completions` mit `gpt-5.4-mini`, ohne `store`-Parameter und ohne Organisations- oder Projekt-Header. + +| Zweck | Klasse | Endpunkt | Modell | Status | +|---|---|---|---|---| +| Textprüfung (Rot/Gelb/Grün) | `OpenAiClassificationDriver` | `chat/completions` | `CLASSIFICATION_MODEL`, sonst `OPENAI_MODEL` (Standard `gpt-5.4-mini`) | aktiv | +| Inhaltsbewertung (Content-Score) | `OpenAiContentScoreDriver` | `chat/completions` | `CONTENT_SCORE_MODEL`, sonst `OPENAI_MODEL` | aktiv | +| KI-Vorabprüfung von Bildern (D8) | `OpenAiImagePrecheckDriver` | `chat/completions` (Bild als base64) | `IMAGE_PRECHECK_MODEL`, sonst `OPENAI_MODEL` | nur mit `IMAGE_PRECHECK=true` | + +- Alle Anfragen enthalten nur `model`, `response_format: json_object` und `messages`. Authentifizierung per API-Schlüssel, ohne `OpenAI-Organization`- oder `OpenAI-Project`-Header. Welche Organisation und welches Projekt gelten, bestimmt also der Schlüssel. +- Basis-URL ist `api.openai.com`, nicht `eu.api.openai.com`. Ein Projekt mit EU-Datenresidenz setzt nach OpenAI-Dokumentation den EU-Endpunkt voraus. Prüfen, bevor „Verarbeitung in der EU“ in die DSE kommt (`openai-residency.png`). +- Andere KI-Anbieter (Gemini, Anthropic) sind nicht angebunden. Sie stehen nur in Kommentaren als „folgt später“. +- Fällt OpenAI aus, prüft die Anwendung regelbasiert weiter (`deterministic`), ohne einen anderen Anbieter. diff --git a/dev/roadmap.md b/dev/roadmap.md index e5336e49..ff67426b 100644 --- a/dev/roadmap.md +++ b/dev/roadmap.md @@ -83,9 +83,26 @@ oder Release versehen. Mehrere Datenverarbeitungen laufen bereits, ohne dass die Datenschutzerklärung sie nennt. Das ist der größte offene Block und am besten **ein** Paket an den -Anwalt. **Entwurf liegt vor:** [`rechtliches/anwaltspaket-datenschutz-2026-10.md`](rechtliches/anwaltspaket-datenschutz-2026-10.md) -(Sachverhalt D1–D10, Textentwürfe DSE 0.4, Fragen F1–F11; vor dem Versand -Abschnitt 7 des Pakets erledigen). +Anwalt. **Überarbeiteter Entwurf:** [Anwaltspaket vom 12.10.2026](rechtliches/anwaltspaket-datenschutz-2026-10-12.md). +Vor Versand die [Korrekturen, Antworten und den Umsetzungsauftrag](rechtliches/korrekturen-und-umsetzungsauftrag-2026-10-12.md) +einarbeiten: Ist-/Zielstand, Aufbewahrungsmatrix, Vertragsübergang, Beweisarchiv +und Aufgaben RP-01 bis RP-12. Diese Ergänzung ist die führende technische +Arbeitsgrundlage für die dort berichtigten Punkte, keine rechtliche Freigabe. + +**Arbeitsordner (Stand 13.10.2026):** `dev/rechtliches/` enthält nur noch die +Versandfassung, ihre Anlagen (Interessenabwägung, Live-Rechtstexte, Klärung, +Kontext Löschanfragen) und die Korrekturen mit RP-01 bis RP-12 und BN-01 bis +BN-09. Belege sammelt [`rechtliches/nachweise/`](rechtliches/nachweise/README.md) +mit Checkliste; Vorfassungen, Codeauswertung, To-do-Liste und Rückfragen liegen +in [`archive/rechtliches-2026-10/`](archive/rechtliches-2026-10/). Hub-Analyse +mit Nutzerkennung, KI-Bildprüfung und Newsletter bleiben bis zu ihren eigenen +Aktivierungspaketen ausgeschaltet. + +**Vor dem Versand:** Nachweise laut Checkliste einsammeln (BN-02 Rollen, Boost- +und Funktions-Screenshots, Verträge, Juli-Mails auf Live bestätigen), Deploy mit +U10 („Gebuchte Platzierung“, „Aktuell“, „Boost beenden“, `audit:admins`, +im Code seit 13.10.2026), dann Platzhalter in D3, D6 und im OpenAI-Absatz +auflösen und Anschreiben formulieren. | # | Punkt | Quelle | Aufwand | |---|---|---|---| @@ -136,7 +153,7 @@ aber nirgends belegt. | 5.10 | Die 6 Slug-Kollisionen aus der Newsroom-Zusammenführung einzeln ansehen. | [Protokoll Teil 3](archive/2026-09-nutzergewinnung/umsetzung-protokoll.md) | | 5.11 | GlitchTip: behandelte Einträge auflösen (nur Betreiber), Eintrag 10 „[object Object]“ beobachten. | [GlitchTip](glitch-tip/README.md) | | 5.12 | Slow-Request-Auswertung mit Live-Daten (Command und Report-Seite existieren). | [Migration 11](archive/migration-2026/11-NOCH-ZU-TUN-OPTIMIERUNGEN.md) | -| ~~5.13~~ | ~~Server-Log-Rotation auf 14 Tage kürzen~~ — **erledigt 09.10.2026** (vorher 52 Tage; DSE Abschnitt 3 und 13 stimmen wieder). Backups rotieren nach 14 Tagen, Server-Monitoring speichert höchstens 14 Tage (Betreiber, 09.10.2026). | [Anwaltspaket](rechtliches/anwaltspaket-datenschutz-2026-10.md) | +| ~~5.13~~ | ~~Server-Log-Rotation auf 14 Tage kürzen~~ — **erledigt 09.10.2026** (vorher 52 Tage; DSE Abschnitt 3 und 13 stimmen wieder). Backups rotieren nach 14 Tagen, Server-Monitoring speichert höchstens 14 Tage (Betreiber, 09.10.2026). | [Anwaltspaket](rechtliches/anwaltspaket-datenschutz-2026-10-12.md) | ---