presseportale/dev/rechtliches/korrekturen-und-umsetzungsauftrag-2026-10-12.md

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, 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, exportTombstones() und Wiederherstellungsabgleich, sowie Betriebsrunbook.

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, setLegalHold() / releaseLegalHold(), und ArchiveEntry.

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

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, 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, PressReleaseReportController.

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 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

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, § 11 UWG, § 7 UrhDaG, § 25 TDDDG, DSGVO.

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
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, Klärungsdokument, Interessenabwägung, Live-Rechtstexte als Anlage, ursprüngliche Codeauswertung, Betreiberentscheidungen in der To-do-Liste und Rückfragen/Betreiberergänzungen.

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.