Metadaten-Verlust bei KI-Bildern: Warum Standard-Pipelines C2PA-Signaturen zerstören
Generative KI liefert Bilder mit vollständigen Herkunftsnachweisen. Viele Bildverarbeitungs-Workflows löschen diese Signaturen unbemerkt. Das Ergebnis: rechtlich relevante Compliance-Lücken, die niemand sieht.
Das Problem
Ein Bild verliert seinen Herkunftsnachweis – ohne sichtbare Veränderung
Das Bild sieht danach identisch aus. Die C2PA-Signatur ist trotzdem weg. Hier ist warum.
Wie Standard-Bibliotheken destruktiv arbeiten
Viele etablierte Bildverarbeitungs-Frameworks – darunter Java ImageIO, Python Pillow in der Standardkonfiguration oder viele CMS-interne Bild-Resizer – arbeiten nach demselben Muster: Sie dekodieren beim Einlesen nur das RGB-Pixelraster und ignorieren alle Metadaten-Blöcke aus Performance-Gründen. EXIF, IPTC und C2PA-Zertifikate werden dabei still verworfen. Beim anschließenden Speichern entsteht eine neue Bilddatei ohne jede Herkunftsinformation.
Das Bild ist pixelidentisch mit dem Original. Aber es hat keinen Beweis mehr, dass es KI-generiert ist – und erfüllt damit nach derzeitiger Lesart nicht mehr die Anforderungen an die technische Transparenz nach dem EU AI Act.
Wo es passiert
Typische Stellen im Workflow wo Metadaten verloren gehen
Hohes Risiko
- CMS-interne Bild-Resizer (WordPress, Shopify, Contentful)
- Standard-Bild-Decode/-Encode-Routinen (Java ImageIO, Python Pillow ohne EXIF-Option)
- Automatische Komprimierung beim Upload
- Screenshot-basierte Bild-Erfassung
- Social-Media-Plattformen beim Hochladen (meist Kompression + Metadaten-Stripping)
Geringes Risiko
- Direktlieferung vom KI-API ohne Zwischenverarbeitung
- Adobe-Produkte (aktive C2PA-Integration)
- Explizit metadaten-erhaltende Bibliotheken (z. B. libvips mit korrekter Konfiguration)
- Rohe Dateiübertragung ohne Decode/Encode
Lösung
Architektur für verlustfreie Verarbeitung
Ein Workflow, der Compliance-Anforderungen erfüllt, muss Metadaten explizit als separate Verarbeitungsebene behandeln.
Phase 1 – Isolierung
Metadaten-Blöcke (C2PA, EXIF, IPTC, XMP) werden auf Binärebene ausgelesen und separat gesichert, bevor das Bild in einen Bildverarbeitungs-Kontext geladen wird. Keine Standard-Decode-Routine darf zu diesem Zeitpunkt das Bild öffnen.
Phase 2 – Pixel-Transformation
Alle Bildtransformationen (Resize, Wasserzeichen, Kompression, Farbkorrektur) werden ausschließlich auf der Pixelebene durchgeführt. Die gesicherten Metadaten-Blöcke bleiben in dieser Phase vollständig isoliert.
Phase 3 – Injektion
Beim finalen Schreibvorgang werden die ursprünglichen Metadaten-Blöcke wieder in die Ausgabedatei eingebettet – optional ergänzt um neue Bearbeitungseinträge (z. B. „Wasserzeichen hinzugefügt"). Das Zertifikat bleibt lückenlos erhalten und beschreibt den vollständigen Bearbeitungsweg.