Robert Frank (DigiCert) erläutert die zentralen Anforderungen an den Produktivbetrieb von C2PA-Signaturen, von zertifizierten Signaturdiensten und offiziellen Vertrauensketten bis zur langfristigen Prüfbarkeit. Unternehmen sollten Zertifikat und Konformität vor der Wahl des SDKs klären, um Risiken und Folgekosten zu vermeiden.
Robert Frank, „Area VP EMEA“ bei DigiCert, beleuchtet in seiner aktuellen Stellungnahme, was der Produktivbetrieb von C2PA-Signaturen tatsächlich verlangt – jenseits der schnell integrierten „Software Development Kits“ (SDKs). Ausgehend von den seit August 2026 geltenden Transparenzpflichten des „EU AI Act“ und dem kalifornischen „AI Transparency Act“ zeigt er auf, warum Herkunftsnachweise nun über produktive Systeme und Abteilungsgrenzen hinweg dauerhaft prüfbar gehalten werden müssen.
C2PA-Signaturen
C2PA-Signaturen sind kryptografisch abgesicherte Herkunftsnachweise für digitale Inhalte, die eine technische Vertrauensbasis schaffen, indem sie nachvollziehbar machen, woher Inhalte stammen und wie sie erstellt und verändert wurden – insbesondere im Umgang mit KI-generierten Medien, Desinformation und Markenmissbrauch.
Er erläutert den Unterschied zwischen Erkennung und Nachweis, warum das „Conformance Program“ und die offizielle „C2PA Trust List“ den eigentlichen Aufwand darstellen, weshalb ein Codesignatur-Zertifikat für C2PA nicht ausreicht und welche Folgekosten die Wahl der Signaturkette gerade für große Archive hat. Sein zentrales Anliegen ist die Empfehlung, dass wer eine Integration plant, die Frage nach Zertifikat und Konformität vor die Frage nach der Bibliothek stellen sollte.
Regelwerke setzen maschinelles Nachvollziehen der Herkunft eines Mediums voraus
Seit dem 2. August 2026 gelten nun die Transparenzpflichten gemäß Artikel 50 [] der europäischen KI-Verordnung („EU AI Act“). Wer also fortan täuschend echte KI-Inhalte veröffentlicht oder generative Systeme betreibt, muss deren Einsatz erkennbar offenlegen – und Anbieter sind verpflichtet, ihre Ausgaben zusätzlich maschinenlesbar markieren.
Am selben Tag wurde zudem in Kalifornien der „California AI Transparency Act“ wirksam, nachdem AB 853 den ursprünglichen Termin verschoben hatte, um ihn an den europäischen Stichtag anzugleichen. Ab Januar 2027 kommt demnach dort eine Pflicht für große Online-Plattformen hinzu, vorhandene Herkunftsdaten weder zu entfernen noch zu ignorieren. Keines dieser beiden Regelwerke schreibe C2PA vor – beide setzten aber voraus, dass sich die Herkunft eines Mediums überhaupt maschinell nachvollziehen lässt, und dafür sei derzeit kein zweiter offener Standard in Sicht.
Frank kommentiert: „Solange Herkunftsnachweise Sache einzelner Pilotprojekte waren, blieb der Betriebsaufwand im Hintergrund. Mit den beiden Stichtagen rückt er nach vorn, weil Signaturen nun über produktive Systeme und über Abteilungsgrenzen hinweg erzeugt und dauerhaft prüfbar gehalten werden müssen.“ Das quelloffene C2PA-SDK zu integrieren, sei hierzu ein sinnvoller Anfang – für den Produktivbetrieb genüge es aber nicht.
Informationen dürfen nicht als gewöhnliche Metadaten mitlaufen
„Content Credentials“ gelten als die sichtbare Schicht eines deutlich größeren Vertrauensmodells. Frank führt aus: „Darunter liegt ein Manifest mit den Herkunftsangaben, eine kryptographische Signatur, die dieses Manifest schützt, und ein Zertifikat, das die Anwendung oder den Dienst ausweist, der die Signatur erzeugt hat.“
Die „Coalition for Content Provenance and Authenticity“ definiere hierfür einen technischen Standard. Je nach Arbeitsablauf protokolliere das Manifest, welche Anwendung ein „Asset“ erzeugt oder bearbeitet hat, welche Schritte daran vorgenommen wurden, wer die Herkunftsangabe verantwortet und ob generative Werkzeuge beteiligt waren. Entscheidend sei, „dass diese Informationen nicht als gewöhnliche Metadaten mitlaufen“. Sie seien signiert.
Klassische Metadaten würden einen Export oder eine Konvertierung häufig nicht überstehen, und wo sie überstehen, ließen sie sich mit wenig Aufwand verändern. Eine C2PA-Signatur mache jedoch jede nachträgliche Änderung erkennbar: „Der Betrachter sieht das ,Content Credential’, getragen wird es jedoch von der Signatur darunter.“
Erkennung und Nachweis als zwei verschiedene Anforderungen
Der Standard dokumentiere, was der Signierende über die „Asset“-Entstehung erklärt, und schütze diese Erklärung gegen nachträgliche Veränderung. Über das Material selbst treffe er keine eigene Aussage.
„Erkennungsverfahren arbeiten anders. Sie analysieren Bild oder Video und geben ein Wahrscheinlichkeitsurteil aus, dessen Trefferquote mit jeder neuen Generator-Generation tendenziell sinkt. Für eine Offenlegungspflicht taugt ein solches Urteil ohnehin nur bedingt, denn nachweisen lässt sich damit nichts. Der Standard setzt deshalb früher an und erlaubt Urhebern und Anwendungen, überprüfbare Aussagen über ein Werk zu hinterlegen.“
Diese Logik finde sich auch im Verhaltenskodex wieder, welchen das EU-Büro für Künstliche Intelligenz zur Kennzeichnung KI-generierter Inhalte erarbeiten lasse und der von seinen Unterzeichnern mehrere Markierungsebenen verlange.
„Conformance Program“ als der eigentliche Aufwand
Die Spezifikation sei offen veröffentlicht, die SDKs zum Erzeugen und Prüfen signierter Inhalte ebenfalls. „Wer damit beginnt, kommt schnell zu einem funktionierenden Prototyp. Nur entsteht daraus noch kein Dienst, dem das Ökosystem vertraut.“
Damit ein produktiver Signaturdienst und die von ihm erzeugten ,Content Credentials’ als vertrauenswürdig gelten, müsse das signierende Produkt die technische und sicherheitsbezogene Prüfung des „Conformance Program“ bestehen und das rechtliche Onboarding abschließen. Erst dann sei es als „Generator Product“ berechtigt, ein „Claim Signing Certificate“ von einer Zertifizierungsstelle auf der offiziellen „C2PA Trust List“ zu beziehen und in die öffentliche „Conforming Products List“ aufgenommen zu werden.
Der Ablauf entspreche dem einer Produktzertifizierung. „Verlangt werden der Nachweis der Spezifikationstreue und die Erfüllung der Sicherheitsanforderungen, einschließlich eines belastbaren Schlüsselschutzes und einer geordneten Zertifikatsverwaltung.“ Diese Kontrollen griffen überall dort, wo „Assets“ entstehen oder verändert werden, also auch in Design, Kommunikation und bei beauftragten Agenturen. Marketingorganisationen bekämen damit Anforderungen auf den Tisch, „die bislang in der IT-Sicherheit lagen“.
Hinzu komme die Dauerhaftigkeit der Verpflichtung. Spezifikation und Konformitätsanforderungen entwickelten sich weiter, und eine Implementierung müsse diese Änderungen im laufenden Betrieb nachvollziehen, um ihre Anerkennung im „Ökosystem“ zu behalten.
„Interim Trust List“ trägt nur bis zum Piloten
„Viele frühe Umsetzungen arbeiteten mit der ,Interim Trust List’ der ,Content Authenticity Initiative’ oder mit selbst gebauten Signaturdiensten. Beides eignet sich für Evaluierung und Machbarkeitsnachweise, wofür die ,Interim Trust List’ auch geschaffen wurde“, so Frank.
Produktive Bereitstellungen würden auf der offiziellen „C2PA Trust List“ erwartet, damit „Content Credentials“ über konforme Anwendungen und Dienste hinweg einheitlich prüfbar blieben. Je stärker Validatoren sich auf diese Liste stützten, desto wahrscheinlicher werde, dass Material, das heutige Testwerkzeuge noch akzeptieren, in künftigen Umgebungen keine Anerkennung mehr finde.
Für Organisationen mit großen Archiven habe dies Folgekosten: Veröffentlichte Inhalte blieben jahrelang im Umlauf, und ein nachträgliches Neusignieren ganzer Bestände sei aufwändig, „sofern die Originale überhaupt noch vorliegen“. Die Wahl der Signaturkette entscheide deshalb mit darüber, ob heute veröffentlichtes Material in zwei Jahren noch als vertrauenswürdig validiert werden könne.
Jedes Signaturzertifikat ist spezifisch
Digitale Signaturen seien der Kern von C2PA, aber nicht jedes vorhandene Zertifikat passe auf diesen Zweck. „Viele Teams kennen Dokumenten- und Codesignaturen aus anderen Zusammenhängen und gehen davon aus, damit versorgt zu sein.“
C2PA folge einem eigenen Vertrauensmodell: Ein Dokumentenzertifikat weise den Unterzeichner aus, ein Codesignatur-Zertifikat den Herausgeber einer Software. Ein „C2PA-Claim-Signing-Certificate“ weise die Anwendung oder den Dienst aus, „der die Signatur erzeugt hat, damit ein Prüfer erkennen kann, welche geprüfte Implementierung hinter den Herkunftsangaben steht“.
Die Ausstellung müsse der Spezifikation und ihren Konformitätsanforderungen folgen. Ein bestehender Unternehmensvertrag für Codesignaturen decke das nicht ab, „auch wenn dieselbe Zertifizierungsstelle beides anbietet“.
Unterscheidung zwischen Anwendung und Absender
„Weil das Zertifikat die signierende Anwendung ausweist, liegt der Schluss nahe, dass sie die einzige Identität sei, die ein ,Content Credential’ transportieren kann. Die ,Creator Assertions Working Group’ hat dafür ein Identitäts-Framework entwickelt, mit dem eine Organisation ihre eigene kreative Identität kryptografisch neben der signierenden Anwendung ausweisen kann.“
Ein Medienhaus oder eine Agentur bleibe damit als Urheber erkennbar, „selbst wenn eine fremde Anwendung oder ein verwalteter Dienst die Signatur erzeugt“.
Für Häuser, die ihre Werkzeuge regelmäßig wechseln oder Produktionsschritte auslagern, bleibe die eigene Urheberschaft dadurch über einen Werkzeugwechsel hinweg zurechenbar.
Vertrauensinfrastruktur selbst betreiben oder delegieren
Jenseits des Prototyps zähle die Infrastruktur um die Signatur herum. Der größere Teil davon betreffe Schlüssel und Zertifikate. Private Signaturschlüssel müssten so geschützt sein, „dass sie den Sicherheitsanforderungen des Programms standhalten“; Zertifikate müssten vor Ablauf erneuert werden, und der Zugriff auf die Signaturfunktion brauche eine Authentifizierung, „die sich im Prüfungsfall belegen lässt“.
Der Rest sei gewöhnlicher Dienstbetrieb. Verfügbarkeit und Monitoring gehörten dazu, ebenso die Pflege der unterstützten Medienformate und die Anbindung an vorhandene „Content-Pipelines“.
Dies alles lasse sich intern aufbauen. Die Kontrolle über die Signaturumgebung liege dann vollständig im Haus, und mit ihr die dauerhafte Verantwortung für Sicherheit und Konformität. Frank gibt zu bedenken: „Eine verwaltete Signaturplattform verlagert diesen Teil nach außen und stellt die Signaturfunktion über eine Schnittstelle bereit. Welcher Weg trägt, hängt vom Sicherheitsmodell ab und davon, ob eine Organisation Vertrauensinfrastruktur selbst betreiben will.“
Prüfung der Signaturkette wird wohl demnächst aus der „Entwicklung“ in die „Beschaffung“ wechseln
Die Prüfkriterien für beide Wege seien dieselben, und sie seien darüber hinaus auch öffentlich nachvollziehbar. Die „Conforming Products List“ zeige, „ob ein Produkt das Konformitätsverfahren durchlaufen hat und auf welchem ,Assurance Level’ es dabei eingestuft wurde. Die ,Trust List’ zeigt, welche Zertifizierungsstellen ,Claim Signing Certificates’ ausstellen dürfen. Wer beschafft, kann beides selbst nachschlagen, und muss sich nicht auf die Herstellerangaben verlassen.“
Danach werde es spezifischer: „Zu klären ist, welche Medienformate ein Dienst signiert und ob er die Identitätsbehauptungen der ,Creator Assertions Working Group’ unterstützt, denn davon hängt ab, ob die eigene Organisation im ,Credential’ überhaupt sichtbar wird. Ebenso gehört in den Vertrag, wer die Anpassung an neue Fassungen der Spezifikation übernimmt und in welcher Frist. Genau an dieser Stelle entscheidet sich, ob eine Integration nach zwei Spezifikationsrunden noch trägt oder erneut aufgemacht werden muss.“
Frank merkt abschließend an: „Ich rechne damit, dass die Prüfung der Signaturkette in den kommenden Monaten aus der Entwicklung in die Beschaffung wandert, weil Redaktionen und Plattformen die offizielle ,Trust List’ tatsächlich abzufragen beginnen und weil die kalifornischen Plattformpflichten ab Januar 2027 dort ansetzen. Teams, die jetzt eine Integration planen, sollten die Frage nach Zertifikat und Konformität deshalb vor die Frage nach der Bibliothek stellen!“
An der Signaturkette hänge alles bereits signierte Material, und eine spätere Korrektur treffe längst veröffentlichte Bestände.
Zentrale Erkenntnisse der DS-Redaktion
- Der rasante Fortschritt Generativer Künstlicher Intelligenz (GenKI) eröffnet nicht nur bisher ungeahnte kreative Potenziale, sondern schafft auch Werkzeuge für Missbrauch – für Täuschung und Betrug.
- Der Gesetzgeber musste auf diese Entwicklung reagieren und einen Ordnungsrahmen schaffen – so etwa in Gestalt der europäischen KI-Verordnung („EU AI Act“).
- Auch für Urheber mit eigenen Schöpfungen einer gewissen Werkhöhe ist es wichtig, dass ihre Urheberschaft nicht verwischt wird – denn es handelt sich um Geistiges Eigentum, welches auch monetarisiert werden kann.
- Robert Frank hat den Begriff des „Vertrauensmodells“ erwähnt – in Ergänzung zu Technisch-Organisatorischen Maßnahmen (TOM) im Kontext eines juristischen Ordnungsrahmens wäre es förderlich, auch im KI-Umfeld eine Vertrauenskultur zu etablieren, denn die KI-Akzeptanz am Markt und in der Gesellschaft wird kaum in einer misstrauischen Atmosphäre gedeihen.
- KI muss stets als ein Werkzeug mit Wertschöpfungs-, aber auch Zerstörungspotenzial angesehen werden – daher ist die „Zumutung“ durch die vom Gesetzgeber geforderte Einhegung nicht zu vermeiden (ähnlich der technischen Überwachung bzw. Unfallverhütung bei physischen Werkzeugmaschinen).
Fazit der DS-Redaktion
C2PA-Signaturen sollen Transparenz über Herkunft und Bearbeitung digitaler Inhalte schaffen und das Vertrauen in KI-generierte Medien stärken . Für den dauerhaften Einsatz sind zertifizierte Signaturdienste und eine verlässliche Vertrauenskette entscheidend. Unternehmen sollten daher Zertifikat und Konformität vor der technischen Integration klären, um Risiken und Folgekosten zu minimieren.
Weitere Informationen
Bibliothek der Universität Zürich, Blog der UB Zürich, Nobutake Kamiya, 27.01.2026
Digitales Misstrauen: Kann C2PA die Wahrheit im KI-Zeitalter retten?
DATENSICHERHEIT.DE, 22.08.2026
AI Act als Motivation: KI-Erfolgsfaktor Vertrauen
DATENSICHERHEIT.DE, 16.08.2026
EU AI Act: Handlungsdruck auf IT- und Datenverantwortliche im KI-Umfeld bleibt hoch
DATENSICHERHEIT.DE, 05.08.2026
EU AI Act: Aktuelle KI-Vorfälle unterstreichen Notwendigkeit der Regeln