presseportale/dev/archive/2026-09-audit/bildkennzeichnung-feedback-audit-2026-09-15.md

Feedback / Audit: Bildnachweis, KI-Kennzeichnung und Rechtebestätigung

Stand: 15.09.2026

Grundlage: Umsetzungsvorschlag vom 15.09.2026

Codebasis: Arbeitsverzeichnis /var/www/html, HEAD d60f31d78e33033207896cd8ea070a54f44ca54d, einschließlich des beim Audit vorhandenen Arbeitsstands.

Prüfumfang: Statischer Codeabgleich, lesende Prüfung der relevanten Datenbankstrukturen und bestehender Tests sowie Gegenprüfung technischer Standards anhand offizieller Quellen. Keine Implementierung.

1. Gesamturteil

Die Richtung ist sinnvoll. Den Entwurf würde ich vor der Umsetzung an mehreren Stellen korrigieren. Weniger Formularfelder, ein sichtbarer Bildnachweis, eine eigenständige KI-Kennzeichnung und eine nachvollziehbare Zustimmung passen zur Anwendung. Der bestehende Code bietet dafür bereits wichtige Grundlagen.

Die größten Probleme liegen in der Bestandsmigration, der Vertrauensbewertung von Metadaten und den Übergängen zwischen Upload, Veröffentlichung und späterer Löschung. Einige als vorhanden vorausgesetzte Bausteine fehlen; andere sind bereits anders umgesetzt.

Die fünf wichtigsten Ergebnisse:

1. Bestehende KI-Deklarationen unbedingt erhalten. Der vorgeschlagene pauschale Wechsel auf not_declared würde vorhandene Angaben überschreiben und öffentliche KI-Hinweise entfernen.
2. algorithmicallyEnhanced ist kein belastbarer KI-Nachweis. Der IPTC-Wert umfasst ausdrücklich auch gewöhnliches Schärfen und Entrauschen.
3. Eine gültige C2PA-Signatur und frei editierbare IPTC-Angaben sind unterschiedliche Vertrauensstufen. Die aktuelle Sperrregel vermischt sie.
4. Die Bild-API existiert bereits. Sie muss zum ersten produktiven Einsatz der neuen Regeln berücksichtigt werden; das geplante JSON-Beispiel entspricht außerdem nicht dem heutigen Upload-Vertrag.
5. Originalablage, Zustimmung und Löschregeln müssen gemeinsam geplant werden. Eine private Disk allein schützt das Original nicht vor öffentlicher Auslieferung über die vorhandene Medienroute.

Prioritäten in diesem Audit: P1 = vor Umsetzung beziehungsweise Livegang verbindlich klären; P2 = in die Umsetzungsspezifikation aufnehmen. Es wird damit kein bereits eingetretener Produktionsschaden behauptet.

2. Was bereits vorhanden ist

Thema	Bestehender Code	Konsequenz für den Vorschlag
Öffentlich sichtbarer Bildnachweis	copyright, mit Fallback auf author; Ausgabe unter dem Artikelbild	Bestehende Ausgabe erweitern, Daten nicht unverbunden duplizieren
KI-Kennzeichnung pro Bild	AiImageDeclaration mit original, ai_generated, ai_edited; öffentlicher Badge	Kein vollständiger Neubau erforderlich
Rechteangaben beim Upload	Gemeinsamer Volt-Bildmanager für Kunden und Admins; rights_confirmed_at und Lizenzfelder	Vereinfachung ist möglich; bestehende Nachweise erhalten
KI-Snapshot beim Einreichen	PressReleaseService::logAiDeclaration() und press_release_ai_declarations	Neue Bildrechtebestätigung mit diesem Ablauf abstimmen
Private Bildspeicherung	Neue Pressebilder werden standardmäßig auf local gespeichert	Öffentliches Derivat und privates Beweisoriginal brauchen getrennte Zugriffspfade
Bild-API	Eigene v1- und Legacy-Bilduploads	Neue Regeln müssen sämtliche aktiven Einstiegspunkte erfassen
Rechtstextversionen	legal_documents mit Typ, Version, Gültigkeitsdatum und Notiz	Keine bereits vorhandene Tabelle legal_document_sections; Textarchivierung fehlt als eigener Baustein
Weitere Darstellung	Kundenansicht, Adminansicht, öffentliche Vorschau und Beleg-PDF	Zusätzlich zur Artikelseite in den Änderungsumfang aufnehmen

Codebelege: Bildmodell, KI-Enum, Bildmanager, Artikelseite, Veröffentlichungsservice, Rechtstextmodell, PDF-Ausgabe.

3. Priorisierte Befunde

F01 · P1 · Die Bestandsmigration widerspricht dem Bestandsschutz

Entwurf: Abschnitt 2.1 setzt alle bestehenden Bilder auf ai_declaration = not_declared. E1 und Abschnitt 0 verlangen gleichzeitig, den Bestand unverändert zu lassen.

Code: Es gibt bereits ausdrücklich deklarierte KI-Bilder. Die Migration vom 08.07.2026 hat zusätzlich Bilder mit is_ai_generated = true auf ai_generated gesetzt. Die öffentliche Artikelseite erzeugt ihren KI-Hinweis aus ai_declaration.

Auswirkung: Bereits abgegebene Angaben gehen verloren. Bei bisher als ai_edited oder ai_generated gekennzeichneten Bildern kann der öffentliche Hinweis verschwinden. Ohne Erweiterung des PHP-Enums führt ein gespeichertes not_declared beim Enum-Cast außerdem zu einem Fehler. Nach einer Erweiterung würde die heutige Einreichungsprüfung den Wert dennoch nicht erkennen: Sie prüft nur auf NULL.

Empfehlung:

• Vorhandene Werte in ai_declaration, copyright, author und den bisherigen Rechtefeldern erhalten.
• Nur die fehlende historische Herkunft als legacy beziehungsweise unknown ergänzen; nicht die Deklaration selbst ersetzen.
• Für fehlende Deklarationen zunächst das vorhandene NULL weiterverwenden. Ein vierter Enum-Wert ist nur sinnvoll, wenn alle Leser, Validatoren und Veröffentlichungsprüfungen angepasst werden.
• Bestandsschutz ausdrücklich für alte Entwürfe, abgelehnte PMs und erneutes Einreichen definieren. Ein neues Ersatzbild unterliegt immer den neuen Regeln.
• Bestandsschutz über eine serverseitige Regelversion oder einen eindeutig definierten Stichtag feststellen, nicht über ein frei setzbares Request-Feld.

Belege: Backfill, Enum, Artikelseite, Zeilen 47–50, Vollständigkeitsprüfung, ab Zeile 572.

F02 · P1 · C2PA-Verifikation braucht mehr als signature_valid

Entwurf: Eine gültige Signatur löst die Sperre aus. Unsigned IPTC/XMP löst dieselbe Sperre aus; das Datenmodell beschreibt sie zugleich als Ergebnis „verifizierter Metadaten“.

Eine kryptografisch gültige Signatur allein beantwortet weder, ob dem Unterzeichner vertraut wird, noch ob alle relevanten Bindungen an die hochgeladene Datei gültig sind. Frei bearbeitbare IPTC/XMP-Felder besitzen diese Signaturprüfung überhaupt nicht. Die C2PA-Spezifikation unterscheidet die Prüfung von Manifest, Aussagen, Signatur, Dateibindung und Vertrauenskette. Quelle: C2PA-Spezifikation, Validierung.

Empfehlung: Ein normalisiertes Ergebnis mit getrennten Zuständen vorsehen, etwa:

• absent: keine unterstützten Herkunftsdaten gefunden;
• validated_trusted: relevante Prüfungen erfolgreich, Unterzeichner nach definierter Vertrauensliste akzeptiert;
• validated_untrusted: technisch geprüft, Vertrauensanker nicht akzeptiert;
• invalid: Prüfung fehlgeschlagen;
• unsupported oder error: nicht unterstützt beziehungsweise technische Prüfung nicht abgeschlossen;
• ergänzend unsigned_metadata für ungesicherte IPTC/XMP-Angaben.

Eine automatische Mindestkennzeichnung würde ich auf belastbare, vertrauenswürdig validierte Aussagen begrenzen. Bei ungesicherten Angaben würde ich vorbelegen und eine begründete Korrektur protokollieren. Soll auch dort geschäftlich zwingend gesperrt werden, muss das ausdrücklich als Portalregel formuliert werden; die Anzeige darf sie nicht als verifizierte Content Credentials ausgeben.

Zusätzlich fehlen Regeln für widersprüchliche C2PA-/XMP-Angaben, mehrere Manifeste, referenzierte Ausgangsbilder und KI-Bestandteile eines zusammengesetzten Bildes. Der digitalSourceType eines Bestandteils darf nicht blind als Typ des gesamten Endbilds übernommen werden. Diese Fälle mit echten Dateien und festgelegten Erwartungen prüfen. Prüfergebnis und verwendete Vertrauens-/Regelversion speichern.

F03 · P1 · algorithmicallyEnhanced nicht automatisch als KI-Bearbeitung sperren

Entwurf: Abschnitt 3.3 und O3 schlagen ai_edited mit Sperre vor.

Gegenprüfung: IPTC beschreibt den Wert als algorithmische Änderung oder Korrektur ohne Veränderung des Hauptinhalts, ausdrücklich beispielsweise Schärfung und Rauschreduzierung. Generative KI ist dafür keine Voraussetzung. Für generative Ergänzungen wie Inpainting und Outpainting existiert compositeWithTrainedAlgorithmicMedia. IPTC: algorithmicallyEnhanced, IPTC: compositeWithTrainedAlgorithmicMedia.

Die Sperre widerspricht damit dem eigenen Formulartext, der übliche Schärfung ausdrücklich ausnimmt. Auch die Behauptung, Kameras schrieben diesen Wert nicht, ist keine ausreichende Grundlage für die Zuordnung.

Empfehlung: Allein daraus keine KI-Kennzeichnung ableiten. Als technischen Bearbeitungshinweis speichern; nur zusätzliche eindeutige KI-Aussagen berücksichtigen. Vollständige IPTC-URIs normalisieren, statt nur auf unqualifizierte Kurzbezeichnungen zu vergleichen.

F04 · P1 · API-Phase und API-Vertrag passen nicht zum bestehenden System

Code: v1 nimmt ein einzelnes Bild im Feld image an, separat unter POST /api/v1/press-releases/{id}/images. Legacy verwendet press_release_image[image]. v1 verlangt bereits eine KI-Deklaration; der Legacy-Controller setzt dagegen fest original. Ein Rechtebestätigungsprotokoll gibt es in diesen Bildcontrollern noch nicht.

Probleme im Entwurf:

• Das JSON mit images[] und „base64 oder URL“ ist ein neuer Vertrag und keine bloße Ergänzung vorhandener Felder.
• „Bild verwerfen, PM weiterverarbeiten“ passt nicht zum separaten Bildupload: Die PM existiert dabei bereits.
• Werden diese Zugänge erst in Phase 2 berücksichtigt, können neue Uploads weiterhin ohne die neuen Nachweise entstehen. Ob ein bestimmter Partner momentan Bilder liefert, ändert nichts an den vorhandenen Endpunkten.

Empfehlung: Den bestehenden Multipart-Upload beibehalten und gezielt erweitern. Für einen ungültigen separaten Bildupload ist 422 die klare Antwort; die bestehende PM bleibt erhalten. Eine Sammelverarbeitung mit Teilfehlern nur als ausdrücklich neu spezifizierte Schnittstelle planen. Externe Bild-URLs würden zusätzlich einen abgesicherten Download mit Grenzen für Zieladressen, Weiterleitungen, Zeit und Datenmenge erfordern.

Zum ersten produktiven Einsatz entweder beide Uploadpfade auf den gemeinsamen Ablauf umstellen oder eine klar definierte Übergangsregel durchsetzen. Legacy-Kompatibilität bewusst entscheiden; keine heimliche Umstellung auf original und kein unbemerkter Bildverlust. Bestehende Response-Felder kompatibel ergänzen, inklusive effektiver Kennzeichnung und maschinenlesbarer Warncodes.

Belege: v1-Controller, v1-Request, Legacy-Controller, Resource, API-Routen.

F05 · P1 · Original und öffentliches Derivat müssen technisch strikt getrennt bleiben

Code: ImageService::storePressReleaseImage() erzeugt Varianten und löscht anschließend normalerweise die hochgeladene Originaldatei. path zeigt dann auf das Cover. Die API nennt diese Darstellung trotzdem urls.original. Die Medienroute liefert Bilder veröffentlichter PMs anonym aus, auch wenn deren Disk local heißt.

Folgerung: Das Beweisoriginal darf weder in path noch in der öffentlich verwendeten variants-Map landen. Die Bezeichnung „private Disk“ reicht als Schutz nicht aus.

Zusätzlich besteht ein relevanter Fehlerpfad: Wenn keine Cover-Variante entsteht, fällt der Service auf die hochgeladene Quelldatei zurück. Eine unverändert übernommene Pipeline garantiert deshalb nicht „öffentlich immer nur bereinigtes Derivat“.

Empfehlung:

• Original vor der bisherigen Transformation in einen gesonderten privaten Bereich kopieren, erfolgreichen Schreibvorgang prüfen und SHA-256 bilden.
• Hash, Herkunftsprüfung und gespeichertes Original müssen dieselben Bytes betreffen.
• Öffentliches Speichern nur bei erfolgreicher Erzeugung des vorgesehenen Derivats; kein Rückfall auf das Original.
• Zugriff auf Beweisoriginale über eine separate, eng autorisierte Funktion. Öffentliche Medienrouten, Vorschau-Signaturen und API-Resources dürfen diesen Pfad nicht zugänglich machen.
• Die bestehende Bedeutung von urls.original kompatibel behandeln und dokumentieren; sie darf nicht plötzlich auf das Beweisoriginal umgebogen werden.

Belege: ImageService, ab Zeile 117, Variantenfehlerpfad, ab Zeile 244, Pfadauflösung, Mediencontroller, Medienberechtigungen, API-Resource.

F06 · P1 · Das vorausgesetzte Rechtstextsystem existiert so noch nicht

Code und Datenbankschema: Vorhanden ist legal_documents. Es speichert Versionsmetadaten, aber keinen archivierten Textinhalt. legal_document_sections findet sich im Anwendungscode und abgefragten Schema nicht. Der AGB-Inhalt steht im Blade-Template.

Auswirkung: confirmation_text_version = img-confirm-v2 alleine macht den tatsächlich angezeigten Wortlaut noch nicht dauerhaft rekonstruierbar. Abschnitt 1f ist eine zusätzliche technische Abhängigkeit und muss vor einer gültigen Bestätigung bereitstehen.

Empfehlung: Das vorhandene Versionssystem gezielt erweitern oder ein kleines, unveränderliches Archiv der Bestätigungstexte ergänzen. Speichern beziehungsweise unveränderlich referenzieren:

• vollständigen angezeigten Text mit Version, Sprache und aufgelösten Portalbezeichnungen;
• die maßgebliche AGB-Fassung;
• Datei-Hash und bestätigte Angaben einschließlich Lizenz-/Quellenangaben;
• handelnden Benutzer und gegebenenfalls zusätzlich die Token-ID;
• Firma/Vertretungskontext zum Bestätigungszeitpunkt.

Bei API-Nutzung sind Tokeninhaber und konkretes Token hilfreicher als nur actor_type = api_key. Bei Admin-Uploads muss erkennbar bleiben, dass der Admin gehandelt hat; das darf nicht als Bestätigung des Kunden protokolliert werden. Eine Firma oder ein Token kann später geändert beziehungsweise gelöscht werden, ohne dass damit der historische Kontext verschwinden darf.

Den Satz „Ohne diese Tabelle ist der Toggle im Streitfall wertlos“ würde ich ersetzen: Entscheidend ist die rekonstruierbare Bestätigung samt Identität und Inhalt, nicht ein bestimmter Tabellenname. Welche Nachweise rechtlich genügen, gehört in die vorgesehene Anwaltsprüfung.

Belege: LegalDocument, AGB-Template, bestehendes Bestätigungsmodell, bestehendes KI-Protokoll.

F07 · P1 · Aufbewahrung und Veröffentlichung sind noch nicht durchgängig abgesichert

Code: Kunden können Bilder bei Entwürfen oder abgelehnten PMs ändern; Admins können im gemeinsamen Bildmanager auch andere Status bearbeiten, außer Archived. v1 beschränkt Änderungen auf Entwurf/abgelehnt. Der Legacy-Bildupload besitzt diese Statusprüfung nicht. publish() prüft die neuen Bildrechte naturgemäß noch nicht; die heutige KI-Vollständigkeitsprüfung erfolgt beim Einreichen.

Empfehlung: Für jedes neue Bild muss beim öffentlichen Wirksamwerden eine gültige Bestätigung zur aktuellen Datei und Deklaration vorliegen. Das betrifft auch Admin-Bildtausch nach Veröffentlichung und Legacy-Nachlieferungen. Bestehende PMs dürfen durch die neuen Regeln nicht unbeabsichtigt blockiert werden; diese Ausnahme muss ausdrücklich auf den geschützten Bestand begrenzt sein.

Die Löschung benötigt ebenfalls ein vollständiges Modell:

• deletePressReleaseImage() löscht heute Dateien sofort; Bildzeilen werden anschließend weich gelöscht. Der neue Beweisbestand braucht eine davon getrennte Aufbewahrungsentscheidung.
• Die ursprüngliche Bildtabelle hat einen kaskadierenden Fremdschlüssel zur PM. Ein späteres hartes Löschen darf Bestätigungen nicht ungewollt mit entfernen. PressReleaseMediaPrivatizer besitzt außerdem einen gezielten forceDelete()-Pfad für fehlende Legacy-Dateien; dessen Bestandsscope beibehalten.
• legal_hold wird erwähnt, aber nicht modelliert. Zuständigkeit, Setzen, Aufheben und Vorrang vor der Löschung fehlen.
• Für nie veröffentlichte Bilder, entfernte Entwürfe und Bildtausch gibt es kein eindeutiges Datum „nach Depublizierung“. Dafür eigene Friststarter definieren; der bestehende Draft-Purge archiviert lediglich.

Den Löschmechanismus und seine Fristberechnung würde ich zusammen mit der Originalspeicherung planen und zum Livegang betriebsfähig machen. Das Wort „BALD“ ist für bereits gesammelte Beweisdaten keine belastbare Aufbewahrungsregel.

Belege: Bildmanager, ab Zeile 292, Veröffentlichung, ab Zeile 212, Bildmigration, Privatisierung, Draft-Archivierung.

F08 · P2 · Datenmodell als Erweiterung konkretisieren

Der Entwurf beschreibt einige bestehende Felder als neue Spalten und lässt andere benötigte Felder offen:

Punkt	Empfehlung
credit gegenüber vorhandenem copyright	Vorerst copyright als Speicherfeld für den sichtbaren Nachweis weiterverwenden; credit kann ein API-/Formularname sein. Eine echte Umbenennung braucht eine vollständige Migration aller Leser und Schreiber.
ai_declaration, license_url	Bereits vorhanden; keine zweite Spalte anlegen. Derzeit ist ai_declaration ein varchar(20) mit PHP-Enum-Cast.
credit NOT NULL, Originalhash, Bestätigungs-FK	Für Bestand ohne diese Daten nullable beziehungsweise anderweitig explizit migrationsfähig; Pflichtregeln für neue Uploads serverseitig durchsetzen.
rights_confirmation_id und Rückverweis auf Bild	Zirkuläre Referenz: Bild zunächst mit leerem Bestätigungsverweis, dann Bestätigung, dann Verweis setzen; gemeinsam in einer Transaktion. Alternativ aktuelle gültige Bestätigung über eine Beziehung ermitteln.
alt_text	Noch kein gleichnamiges Bildfeld vorhanden; heute werden description/title verwendet. Speicherung, Länge und Fallback festlegen.
credit_source	legacy/unknown und einen Firmennamenvorschlag abbilden; „woher vorgeschlagen“ und „wer final bestätigt“ sind verschiedene Informationen.
license_url	DB aktuell 255 Zeichen, Formularvalidierung bis 2048; Länge bei dieser Änderung konsistent festlegen.
is_ai_generated, license_type	Weiterverwendung und Übergang definieren; Kunden-/Adminansicht und PDF lesen diese Felder noch.

Die sichtbare Nachweiszeile sollte über eine gemeinsame Auflösung für neue Angaben und Bestandsfallbacks verfügen. Historische Details müssen nicht im vereinfachten Formular erscheinen, sollten aber erhalten bleiben.

Belege: Bildmodell, Lizenzmigration, Bildmanager, PDF-Bildangaben.

F09 · P2 · Prüfung und Zustimmung an die konkrete Dateiversion binden

Eine Prüfung nach der Dateiauswahl genügt nicht, wenn zwischen Prüfung und Speichern die Datei oder die bestätigten Angaben wechseln. Im heutigen Formular gibt es noch keine Herkunftsprüfung und dementsprechend auch keine Bindung an deren Ergebnis.

Empfehlung: Prüfungsergebnis serverseitig an Upload-ID beziehungsweise Hash binden. Bei Dateiwechsel Prüfung, Vorbelegung und Zustimmung zurücksetzen. Eine manuelle Nachweisänderung nicht anschließend durch verspätete Prüfergebnisse überschreiben. Relevante Änderungen nach der Zustimmung erfordern eine neue Zustimmung.

Die endgültigen Werte, der Hash, der Actor und die Textversion werden serverseitig bestimmt. Öffentliche Livewire-Properties sind grundsätzlich Eingaben des Clients; eine ausgegraute Auswahl ist keine Absicherung. Quelle: Livewire 4, Properties und Sicherheit.

Dateispeicherung und Datenbanktransaktion müssen als zusammenhängender Vorgang mit Fehlerbereinigung gestaltet werden. Ein DB-Rollback löscht keine gespeicherten Dateien. Gleichzeitige Uploads müssen außerdem die bestehende „ein Titelbild“-Regel zuverlässig einhalten. Ein passender gemeinsamer Upload-Service kann diese Regeln für Volt, v1 und Legacy bündeln; der vorhandene ImageService bleibt für die Bildverarbeitung zuständig.

F10 · P2 · „Kein Treffer“ und „Prüfung fehlgeschlagen“ getrennt anzeigen

Entwurf: Bei Timeout wird derselbe Formularzustand wie bei fehlenden Herkunftsdaten verwendet.

Das ist für den Nutzer eine falsche Aussage. Eine bewusst aufwendig präparierte Datei könnte außerdem einen Timeout provozieren und so eine sonst vorgesehene Sperre umgehen.

Empfehlung: Bei Fehler „Herkunftsdaten konnten nicht geprüft werden“ anzeigen. Entscheiden, ob nur das Speichern als Entwurf erlaubt ist oder ob eine manuelle Erklärung bei ungeprüfter Herkunft ausreicht. Letzteres kann eine bewusste Produktregel sein, darf aber nicht als vollständig durchgesetzte Metadatensperre beschrieben werden. Technische Fehlerstatus, Wiederholungen und Ausfallquote erfassen.

F11 · P2 · Die Kategorie „Originalfoto“ ist für Nicht-KI-Bilder zu eng

Das Formular erfasst auch Logos, Diagramme, Screenshots, Illustrationen und klassische Renderings. Ohne KI sind diese nicht zwingend „Originalfotos“. Ebenso beweist ein Hinweis auf eine Digitalaufnahme nicht, dass später keine KI-Bearbeitung stattgefunden hat.

Empfehlung: Die erste Option etwa „Ohne generative KI erstellt oder bearbeitet“ nennen und die Definition üblicher Bearbeitung unmittelbar ergänzen. Den internen Wert original kann man aus Kompatibilitätsgründen zunächst erhalten.

max(original, ai_edited, ai_generated) ist eine Portalregel, keine natürliche Rangfolge des Wahrheitsgehalts. Ein KI-erzeugter Bestandteil in einer Fotomontage macht nicht automatisch das komplette Bild zu einem vollständig KI-generierten Bild. Erst den relevanten Metadatenbefund fachlich zuordnen, danach die vereinbarte Mindestkennzeichnung anwenden. Nutzerangabe, abgeleiteter Befund und effektive Ausgabe getrennt speichern, damit die Entscheidung erklärbar bleibt.

F12 · P2 · Bildnachweis, Urheber und Lizenz nicht gleichsetzen

Ein vorbefüllter Firmenname kann praktisch sein, ist aber nicht automatisch der richtige Bildnachweis. Dasselbe gilt für eine Agentur-Credit-Line gegenüber dem eigentlichen Urheber oder einem Copyright-Vermerk.

Empfehlung:

• Firmennamen nur klar als überprüfbaren Vorschlag anzeigen; vorhandene Nutzertexte nicht ersetzen.
• Neben klassischem IPTC Credit auch dessen XMP-Entsprechung berücksichtigen. Mehrere Creator, Sprachvarianten und zu lange Werte kontrolliert normalisieren; Nachweistexte nicht still abschneiden.
• Die Felder creator, copyrightNotice und creditText beim späteren Export nur mit den jeweils bekannten Informationen befüllen. Einen frei formulierten Credit nicht pauschal in alle drei Felder kopieren.
• license_url und source_url fachlich getrennt halten, selbst wenn die Oberfläche vereinfacht wird. Ein Link zur Agentur oder Ursprungsseite ist nicht automatisch eine Lizenz.
• Nur zulässige Linkschemata veröffentlichen und alle aus Dateien gewonnenen Texte bei HTML-/JSON-Ausgabe korrekt escapen.

Google unterscheidet diese Angaben ausdrücklich; license soll auf eine Beschreibung der tatsächlichen Nutzungsbedingungen verweisen. Quelle: Google-Bildmetadaten.

F13 · P2 · Öffentliche Ausgabe und Metadatenexport genauer abgrenzen

Die sichtbare Zeile plus Detailinformation ist nachvollziehbar. Die heutige Artikelseite besitzt bereits Nachweiszeile und KI-Badge; die Umsetzung sollte diese konsistent weiterentwickeln.

Ergänzungen zum Umfang:

• Kundenansicht, Adminansicht, anonyme Vorschau und ProofPdfRenderer mitziehen. Historische Belegausgaben müssen zur jeweils dokumentierten Fassung passen.
• Keine internen Notizen, IP-Hashes, privaten Pfade oder ungefilterten Tool-Dumps im Overlay beziehungsweise API-Response ausgeben. Nur ausdrücklich freigegebene Herkunftsfelder anzeigen.
• Korrekturen mit den vorhandenen Web-Caches abstimmen. Öffentliche Mediendateien werden derzeit mit max-age=86400 ausgeliefert; bei geänderten Derivat-Metadaten Dateiversionen beziehungsweise Cache-Verhalten berücksichtigen.
• Das vorhandene NewsArticle.image ist derzeit eine URL-Liste. Eine Erweiterung um ImageObject ist möglich. digitalSourceType ist eine Schema.org-Eigenschaft; gültiges Schema und tatsächliche Unterstützung durch Suchmaschinen sind getrennt zu prüfen. Quelle: Schema.org.

Technische Korrekturen zu Abschnitt 3.4:

1. Der aktuelle GD-Service behält JPEG/PNG/WebP als Ausgabeformat bei; eine generelle WebP-Konvertierung existiert nicht. Der Export muss die tatsächlich erzeugten Formate unterstützen.
2. Für WebP dokumentiert ExifTool das Schreiben von EXIF, XMP und ICC-Profilen. Klassisches IPTC:CopyrightNotice ist deshalb keine formatübergreifende Schreibstrategie. Passende XMP-Felder verwenden und nach dem Schreiben wieder auslesen. Quelle: ExifTool-Tagdokumentation.
3. Ein exportiertes XMP-Feld stellt keine C2PA-Signatur des Derivats her. Die Herkunftsanzeige muss sich ausdrücklich auf die beim Upload geprüfte Originaldatei beziehen.
4. „Damit tragen Google, LinkedIn und andere Plattformen … weiter“ ist zu verbindlich. Metadaten schaffen eine Auswertungsmöglichkeit. Google garantiert deren Anzeige ausdrücklich nicht; für LinkedIn ist im Entwurf kein Nachweis einer solchen Garantie vorhanden. Quelle: Google-Bildmetadaten, Troubleshooting.

F14 · P2 · Formularzustände, Korrekturweg und Betrieb vervollständigen

Formular:

• E4 erlaubt eine Höherstufung, Zustand A behauptet dagegen „kann nicht geändert werden“. Bei Mindestwert ai_edited muss die erlaubte Wahl von ai_generated weiterhin möglich sein, falls diese Regel bestehen bleibt.
• Zustand A kann laut Zuordnung auch durch unsigned IPTC entstehen. Dann ist „Diese Datei enthält Content Credentials“ falsch. Unterschiedliche Herkunftstexte vorsehen.
• „Ausgestellt von“ nur aus den dafür geeigneten Zertifikatsinformationen ableiten; claim_generator ist nicht automatisch Urheber oder verifizierter Produktname. Unbekannte Aussteller und fehlende Zeitangaben brauchen Fallbacks.
• Die Kundenoberfläche verwendet aktuell überwiegend „Sie“. Für diese Änderung dabei bleiben oder einen bewussten portalweiten Wechsel planen.
• Ein Kontaktlink für Widersprüche reicht als Einstieg. Intern braucht es dennoch einen autorisierten, protokollierten Korrekturweg mit Grund, Bearbeiter und altem/neuem Wert. Die ursprüngliche Prüfung bleibt erhalten.
• Für das Overlay vorhandene Flux-Komponenten prüfen. Popover und modaler Dialog benötigen unterschiedliche Fokusführung; Tastaturbedienung, Rückgabe des Fokus und zugängliche Beschriftung ausdrücklich abnehmen.

Betrieb:

• „Beides ist in unter einer Sekunde durch“ erst nach Messung behaupten. Ein Timeout ist keine Laufzeitgarantie.
• Toolversionen und Binärquellen festlegen; Installation in der tatsächlichen App-/Worker-Laufzeit reproduzierbar machen. Im Sail-Projekt reicht eine Installation ausschließlich auf dem Host nicht.
• Dateityp, Dateigröße und Bildabmessungen vor kostenintensiver Verarbeitung begrenzen. Aktuell erlaubt der Bildmanager 16 MiB, die API 8 MiB; diesen Unterschied entscheiden oder dokumentieren.
• Prozesse mit Argumentlisten und kontrollierten lokalen Pfaden starten; CPU-/Speicher-/Ausgabegrenzen und Behandlung externer Manifestverweise festlegen.
• Originalspeicherung, Backups, Toolpflege und Fehlerbearbeitung erzeugen Betriebsaufwand. Im Anti-Zombie-Check besser zwischen „keine zusätzlichen Kundengebühren“ und tatsächlichen Betriebskosten unterscheiden.

4. Rechtliche Annahmen, die gezielt zurück an den Anwalt sollten

Die vorgesehenen Anwaltsfragen sind sinnvoll. Ergänzen beziehungsweise präzisieren würde ich folgende Punkte; dies ist keine rechtliche Freigabe der Texte:

1. Nachweisplatzierung und Teaser: § 13 UrhG enthält nicht wörtlich die im Entwurf in Anführungszeichen gesetzte Vorgabe „in üblicher Weise“. Er betrifft die Anerkennung der Urheberschaft und die Bestimmung der Bezeichnung. Aus ihm folgt keine pauschale Freistellung für Vorschaubilder. „Listen/Teaser ohne Nachweis“ und unveränderte OpenGraph-Bilder deshalb anhand der tatsächlich verwendeten Lizenzen prüfen. § 13 UrhG.
2. Aufbewahrungsfrist: „Drei Jahre nach Depublizierung“ lässt sich nicht einfach mit der regelmäßigen Verjährung gleichsetzen. § 199 BGB knüpft deren Beginn grundsätzlich an Jahresende und Kenntnis an; § 102 UrhG verweist zudem auf weitere Vorschriften. Eine konkrete Frist samt Ausnahmen, nie veröffentlichten Uploads und Rechtsstreitfällen festlegen lassen. § 199 BGB, § 102 UrhG.
3. Entfernung von Rechteinformationen: Prüfen, ob das Verschieben der Wiederaufnahme von Rechte-Metadaten in Phase 2 angesichts der genutzten Bilder und Lizenzen vertretbar ist. § 95c UrhG enthält ein an bestimmte Voraussetzungen gebundenes Verbot der Entfernung/Änderung von Rechteinformationen; das ist weder ein pauschales Verbot jeder Metadatenbereinigung noch automatisch irrelevant. § 95c UrhG.
4. Datensparsamkeit: Die Originale enthalten möglicherweise mehr als GPS und Seriennummern, etwa Namen oder Ortsangaben. Erforderlichkeit, Zugriff, Frist, Backups und Umfang des Provenance-Snapshots konkret festlegen. Einen IP-Hash nicht als anonym garantieren; für die technische Umsetzung eher einen zweckgebundenen, geheimnisgestützten Hash mit Versionierung prüfen.
5. Vertragspartner und Vertretung: Klären, wer bei Agentur-, Admin- und API-Uploads welche Erklärung für wen abgibt. Das protokollierte Firmenprofil ist nicht automatisch der Vertragspartner oder Rechteinhaber.
6. Zusammenspiel der Zusicherungen: Umfang der Bearbeitungs-/Syndikationsrechte, Freistellung und Korrektur einer falschen automatischen Kennzeichnung prüfen. Das Datenbankprotokoll belegt eine abgegebene Erklärung; es beweist nicht selbst das Vorliegen aller Rechte und garantiert keinen erfolgreichen Regress.

5. Vorschlag für eine angepasste Umsetzung

Ich würde die geplante Architektur beibehalten, aber den ersten produktiven Lieferumfang anders schneiden:

Schritt	Inhalt	Ergebnis
1. Regeln festziehen	Bestandsschutz, Vertrauensstufen, KI-Zuordnung, API-Übergang, Korrekturweg, Aufbewahrung und Rechtstexte	Eindeutige Regeln vor Schema und Formular
2. Datenmodell ergänzen	Bestehende Werte erhalten; Herkunftsbefund, Originalreferenz, unveränderliche Bestätigung und Fristdaten ergänzen	Verlustfreie Migration
3. Gemeinsamen Upload-Ablauf bauen	Original sichern und prüfen, Nutzereingaben validieren, effektive Kennzeichnung bestimmen, Derivate und Bestätigung konsistent speichern	Dieselben Regeln für Volt, v1 und Legacy
4. Formular vereinfachen	Bestehenden Bildmanager umbauen; Vorschläge, Prüfstatus, Zustimmung und erlaubte Korrekturen	Weniger Aufwand mit nachvollziehbarer Entscheidung
5. Ausgabe und Lebenszyklus schließen	Nachweis/Overlay, Vorschau/PDF, Veröffentlichungsgates, Entfernung, Aufbewahrung, legal_hold, Cache-Korrekturen	Durchgängiges Verhalten bis zur Löschung
6. Weitere Verbreitung ergänzen	Formatgerechte Metadaten, strukturierte Daten und tatsächlich benötigte Feed-Verträge	Konsistente Weitergabe; juristisch erforderliche Teile gegebenenfalls bereits in Schritt 5

Pragmatische Alternative: Falls die C2PA-Verifikation den ersten Schritt zu groß macht, zunächst die Formularvereinfachung, nachvollziehbare Selbstdeklaration, Originalablage und versionierte Zustimmung umsetzen. Metadaten zunächst als Hinweise auslesen und speichern. Automatische Sperren erst nach einer getesteten Vertrauens- und Zuordnungslogik aktivieren. Das wäre eine bewusste Änderung von E4, die fachlich entschieden werden muss.

Diese Alternative vermeidet eine voreilige, teilweise falsche Automatik und liefert trotzdem früh den wesentlichen Nutzen: weniger Formularaufwand und nachvollziehbare Angaben.

6. Konkrete Abnahmetests für die spätere Implementierung

Für diesen reinen Dokumentationsaudit wurden keine Tests verändert oder ausgeführt. Die folgenden Fälle gehören in die Implementierung; reine Fake-Bilder reichen für die Herkunftsprüfung nicht aus.

Bereich	Wesentliche Fälle
Migration	Vorhandene original-/ai_generated-/ai_edited-Werte und Credits unverändert; leere Bestandswerte bleiben darstellbar; neues Ersatzbild erhält neue Regeln
Metadaten	Vertrauenswürdig signiertes KI-Bild; untrusted Signatur; beschädigte Dateibindung; unsigned XMP; widersprüchliche Quellen; mehrere Manifeste und KI-Bestandteile; fehlender oder unbekannter Source-Type
Zuordnung	algorithmicallyEnhanced ohne generative KI erzwingt keinen KI-Hinweis; URI-Normalisierung; Screenshot/Illustration ohne KI; generativ ergänztes Foto
UI-Manipulation	Gesperrte Mindestkennzeichnung kann nicht unterschritten werden; erlaubte Änderung funktioniert; Dateiwechsel und spätes Prüfergebnis verwenden keine alte Zustimmung
Fehler	Timeout, fehlendes Binary, ungültiges JSON, zu großer Output, Schreibfehler und gescheiterte Derivaterzeugung; niemals versehentlich öffentliches Original
Atomarität	DB-Fehler nach Dateispeicherung; Wiederholung eines Requests; parallele Titelbilduploads; keine Bestätigung für die falsche Datei
Zugriff	Beweisoriginal weder öffentlich noch über normale Vorschau-/Varianten-URLs erreichbar; berechtigter interner Zugriff; keine internen Daten in API/Overlay
API	v1 und Legacy; fehlende Pflichtangaben; ungültige Textversion; Statusgrenzen; Metadatenkonflikt; kompatible Responses
Bestätigung	Wortlaut und Sprache später rekonstruierbar; korrekter Benutzer/Token/Admin; Bildtausch; geänderte Firma; Wechsel der Textversion bei geöffnetem Formular
Lebenszyklus	Alte PM erneut eingereicht; Admin-Bildtausch an veröffentlichter PM; Entfernen; nie veröffentlichter Upload; Fristablauf; gesetzter und aufgehobener legal_hold
Ausgabe	Beide Portale, Kunden-/Adminansicht, Vorschau, PDF; Nachweiszeile ohne Klick; kein falscher C2PA-Text; Metadaten nach Export aus allen ausgelieferten Formaten wieder lesbar

Geeignete bestehende Anknüpfungspunkte:

• PressReleaseImageLicenseTest: prüft bereits Pflichtangaben und erwartet derzeit ausdrücklich, dass die Originaldatei gelöscht wird. Diese Erwartung beim Umbau gezielt ersetzen.
• PressReleaseAiDeclarationTest: Einreichungssperre, Deklaration und bestehender Snapshot.
• PressReleaseImageApiTest: Upload, Löschung, Größenlimit, Zugriff und KI-Pflichtangabe.
• PressReleaseMediaPrivatizerTest: Umgang mit privaten und fehlenden Legacy-Medien.
• LegalDocumentTest: gültige Rechtstextversion und zukünftige Fassungen.

7. Prüfgrenzen und Abschluss

Die Codebefunde beruhen auf den verlinkten Implementierungen und dem lesend abgefragten Schema. Externe Quellen wurden für C2PA/IPTC, Metadatenexport und die genannten gesetzlichen Bezugspunkte herangezogen. Es wurden keine echten C2PA-Dateien verarbeitet, keine Laufzeit- oder Lastmessungen durchgeführt und keine juristischen Einzelfälle bewertet. Ob einzelne API-Partner derzeit Bilder einliefern, wurde nicht anhand produktiver Uploaddaten untersucht.

Fazit: Formularvereinfachung, sichtbaren Nachweis und dokumentierte Zustimmung würde ich umsetzen. Vorher würde ich vor allem Bestandsmigration, Metadatenvertrauen, API-Einbindung und Original-/Bestätigungslebenszyklus korrigieren. Dafür ist eine gezielte Erweiterung des vorhandenen Systems ausreichend; ein kompletter Neubau ist nicht erforderlich.