> ## Documentation Index
> Fetch the complete documentation index at: https://docs.samsa.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Content-Provenienz
> Wie die Samsa API KI-generierte Bilder kennzeichnet — C2PA-Signierung, unsichtbares Wasserzeichen, SVG-Scope-out — und wie du eine Datei prüfst.
Bilder, die die Samsa API erzeugt, sind KI-generierte oder KI-bearbeitete Inhalte.
Diese Seite erklärt, wie diese Ausgaben zur Provenienz gekennzeichnet werden, wie du
eine Datei prüfst und das eine Format, das die Kennzeichnung nicht abdecken kann.
Die Provenienz-Kennzeichnung der API-Ausgaben wird gerade ausgerollt. Die
Signier- und Wasserzeichen-Pipeline ist **dark-launched** — gebaut und hinter einem
Flag bereitgestellt — und wird auf ausgelieferte Rasterdateien angewendet, sobald
sie live geht. Das hier beschriebene Verhalten ist der beabsichtigte Zustand zum
Go-live; bis das Flag umgelegt wird, sind API-ausgelieferte Dateien noch nicht
gekennzeichnet.
## Was gekennzeichnet wird
Sobald die Provenienz-Kennzeichnung live ist, trägt jedes **Raster**-Bild, das die
API ausliefert — Generierung, Magic Edit, img2img, Variationen, Resize, Upscale und
Hintergrundentfernung — zwei Kennzeichen:
* **Ein C2PA-Manifest.** Ein branchenüblicher, kryptografisch signierter Content-
Credentials-Datensatz, eingebettet in die Datei, der angibt, dass das Bild
KI-generiert oder KI-bearbeitet ist und wie es erzeugt wurde.
* **Ein unsichtbares Wasserzeichen.** Ein dauerhaftes, nicht wahrnehmbares Kennzeichen
im Bild selbst, sodass die Provenienz einen Screenshot oder ein Entfernen der
Metadaten übersteht, das das C2PA-Manifest entfernen würde.
### KI-generiert vs. KI-bearbeitet
Der Provenienz-Datensatz spiegelt wider, **wie das Bild erzeugt wurde**, abgeleitet
aus der Operation:
| Kennzeichen | Operationen |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------- |
| **KI-generiert** | Bildgenerierung aus einem Prompt (`POST /images/generations`) |
| **KI-bearbeitet** | Operationen, die ein Eingabebild transformieren — Magic Edit, img2img, Variationen, Resize, Upscale, Hintergrundentfernung |
Die sichtbare EU-AI-Act-Kennzeichnung, die ein Betrachter sieht, wird angewendet,
wenn ein Bild **in der Samsa-App heruntergeladen** wird — sie ist ein Label auf der
Darstellungsebene und wird **nicht** auf die von der API ausgelieferten Dateien
angewendet. Die API gibt das Asset mit seinem eingebetteten C2PA-Manifest und
Wasserzeichen zurück; ein sichtbares Label auf dem Bild für deine eigenen
Endnutzer hinzuzufügen, ist die Entscheidung deiner Integration.
## Eine Datei prüfen
Das C2PA-Manifest ist mit jedem Standard-Content-Credentials-Tool lesbar — nichts
Samsa-Spezifisches ist erforderlich:
* **Content Credentials Verify** — der Web-Verifier unter
[contentcredentials.org/verify](https://contentcredentials.org/verify): ziehe ein
Bild hinein, um sein Manifest zu inspizieren.
* **`c2patool`** — das Open-Source-[C2PA-Kommandozeilentool](https://github.com/contentauth/c2pa-rs)
zum Lesen und Validieren von Manifesten in einer Pipeline.
Beide berichten die Angaben des Manifests und validieren seine Signatur, sodass du
die Provenienz einer Datei unabhängig von Samsa bestätigen kannst.
## SVG: ein Art.-50(2)-Scope-out
Die [Vektorisierung](/de/api-reference/image-ops/vectorize) erzeugt ein **SVG**, das
kein C2PA-Manifest oder eingebettetes Wasserzeichen tragen kann. SVG-Ausgaben sind
daher ein dokumentierter **EU-AI-Act-Art.-50(2)-Scope-out**: Vektordateien werden
**ohne Signatur und ohne Wasserzeichen** ausgeliefert.
Da diese Ausgabe nicht gekennzeichnet werden kann, muss eine Vektorisierungsanfrage
den Scope-out mit `svg_acceptance: true` bestätigen:
Die `svg_acceptance`-Bestätigung ist **Offenlegungs-/Prüfnachweis, kein
Compliance-Verzicht.** Sie hält fest, dass dem Aufrufer mitgeteilt wurde, dass das
SVG ohne Kennzeichnung ausgeliefert wird; sie ändert nichts an der zugrunde
liegenden Kennzeichnungspflicht, die beim Anbieter verbleibt und durch die
technische Machbarkeit begrenzt ist.
Zwei unabhängige Gates gelten, und beide lehnen **vor jeder Credit-Belastung** ab:
| Gate | Anforderung | Fehler |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------- |
| Bestätigung | `svg_acceptance` muss der literale Boolean `true` sein | [`422 svg_acceptance_required`](/de/api-reference/image-ops/vectorize) |
| Policy-Zustimmung | Deine Organisation hat die aktuellen ToS/AUP akzeptiert (serverseitig verifiziert — dem Anfrage-Flag wird für diese Tatsache nie vertraut) | `403 svg_phase1_scope_out_required` |
Akzeptiere die aktuellen Nutzungsbedingungen und die Acceptable Use Policy und
versuche es dann erneut; der serverseitig verifizierte Zustimmungsdatensatz — nicht
das Anfrage-Flag — schaltet die Auslieferung frei.
## Siehe auch
Die SVG-Operation und ihr `svg_acceptance`-Request-Vertrag.
Die sechs Operationen hinter diesen Ausgaben.
Der Fehler-Envelope und die Statuscodes.
Was jede Operation kostet.