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

**Stand:** 15.09.2026

**Grundlage:** [Umsetzungsvorschlag vom 15.09.2026](bildkennzeichnung-2026-09-15.md)

**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](../../app/Models/PressReleaseImage.php), [KI-Enum](../../app/Enums/AiImageDeclaration.php), [Bildmanager](../../resources/views/livewire/components/press-release-images-manager.blade.php), [Artikelseite](../../resources/views/web/release-detail.blade.php), [Veröffentlichungsservice](../../app/Services/PressRelease/PressReleaseService.php), [Rechtstextmodell](../../app/Models/LegalDocument.php), [PDF-Ausgabe](../../app/Services/PressRelease/ProofPdfRenderer.php).

## 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](../../database/migrations/2026_07_08_172113_backfill_ai_declaration_on_press_release_images.php), [Enum](../../app/Enums/AiImageDeclaration.php), [Artikelseite, Zeilen 47–50](../../resources/views/web/release-detail.blade.php#L47), [Vollständigkeitsprüfung, ab Zeile 572](../../app/Services/PressRelease/PressReleaseService.php#L572).

### 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](https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html).

**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](https://cv.iptc.org/newscodes/digitalsourcetype/algorithmicallyEnhanced), [IPTC: compositeWithTrainedAlgorithmicMedia](https://cv.iptc.org/newscodes/digitalsourcetype/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](../../app/Http/Controllers/Api/V1/PressReleaseImageController.php), [v1-Request](../../app/Http/Requests/Api/V1/StorePressReleaseImageRequest.php), [Legacy-Controller](../../app/Http/Controllers/Api/Legacy/LegacyPressReleaseImageController.php), [Resource](../../app/Http/Resources/PressReleaseImageResource.php), [API-Routen](../../routes/api.php).

### 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](../../app/Services/Image/ImageService.php#L117), [Variantenfehlerpfad, ab Zeile 244](../../app/Services/Image/ImageService.php#L244), [Pfadauflösung](../../app/Models/PressReleaseImage.php), [Mediencontroller](../../app/Http/Controllers/Web/PressReleaseImageMediaController.php), [Medienberechtigungen](../../app/Http/Controllers/Web/Concerns/AuthorizesPressReleaseMediaAccess.php), [API-Resource](../../app/Http/Resources/PressReleaseImageResource.php).

### 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](../../app/Models/LegalDocument.php), [AGB-Template](../../resources/views/web/agb.blade.php), [bestehendes Bestätigungsmodell](../../app/Models/BookingConfirmation.php), [bestehendes KI-Protokoll](../../app/Models/PressReleaseAiDeclaration.php).

### 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](../../resources/views/livewire/components/press-release-images-manager.blade.php#L292), [Veröffentlichung, ab Zeile 212](../../app/Services/PressRelease/PressReleaseService.php#L212), [Bildmigration](../../database/migrations/2026_04_23_171001_create_press_release_images_table.php), [Privatisierung](../../app/Services/PressRelease/PressReleaseMediaPrivatizer.php), [Draft-Archivierung](../../app/Console/Commands/PurgeExpiredPressReleaseDrafts.php).

### 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](../../app/Models/PressReleaseImage.php), [Lizenzmigration](../../database/migrations/2026_05_29_130849_add_license_fields_to_press_release_images.php), [Bildmanager](../../resources/views/livewire/components/press-release-images-manager.blade.php), [PDF-Bildangaben](../../app/Services/PressRelease/ProofPdfRenderer.php).

### 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](https://livewire.laravel.com/docs/4.x/properties).

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](https://developers.google.com/search/docs/appearance/structured-data/image-license-metadata).

### 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](https://schema.org/digitalSourceType).

**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](https://www.exiftool.org/TagNames.pdf).
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](https://developers.google.com/search/docs/appearance/structured-data/image-license-metadata#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](https://www.gesetze-im-internet.de/urhg/__13.html).
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](https://www.gesetze-im-internet.de/bgb/__199.html), [§ 102 UrhG](https://www.gesetze-im-internet.de/urhg/__102.html).
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](https://www.gesetze-im-internet.de/urhg/__95c.html).
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](../../tests/Feature/PressReleaseImageLicenseTest.php): prüft bereits Pflichtangaben und erwartet derzeit ausdrücklich, dass die Originaldatei gelöscht wird. Diese Erwartung beim Umbau gezielt ersetzen.
- [PressReleaseAiDeclarationTest](../../tests/Feature/PressReleaseAiDeclarationTest.php): Einreichungssperre, Deklaration und bestehender Snapshot.
- [PressReleaseImageApiTest](../../tests/Feature/Api/V1/PressReleaseImageApiTest.php): Upload, Löschung, Größenlimit, Zugriff und KI-Pflichtangabe.
- [PressReleaseMediaPrivatizerTest](../../tests/Feature/PressReleaseMediaPrivatizerTest.php): Umgang mit privaten und fehlenden Legacy-Medien.
- [LegalDocumentTest](../../tests/Feature/Legal/LegalDocumentTest.php): 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.