問題的規模
單個 AI 圖像生成器每天可能生成數百萬張圖像。每張都必須單獨簽名來源元數據 — 在這個規模下手動方法是不可能的。
案例研究 — AI 公司
將合規建入您的
AI 管道
生成式 AI 公司如何將 Capture 的多層來源整合到推理管道中 — 從圖像生成器到 LLM — 在不犧牲效能的情況下符合歐盟 AI 法案第 50 條。
挑戰
為什麼 AI 提供者是主要合規目標
第 50(2) 條將標記義務直接落在生成合成內容的 AI 系統提供者身上。 這意味著如果您建構或運營生成式 AI 模型 — 無論是用於圖像、視頻、音頻還是文本 — 您有責任確保每個輸出在到達任何用戶之前都攜帶機器可讀的來源標記。
效能限制
用戶期望亞秒級生成。任何合規層都必須增加可忽略的延遲。使回應時間翻倍的簽名步驟對生產工作負載來說是不可接受的。
下游責任
如果您的 API 客戶在歐盟分發未標記的 AI 內容，您（作為提供者）和他們（作為部署者）都面臨執行。在 API 輸出中建入合規保護整個鏈。
架構
Capture 在您的管道中的位置
AI 模型生成內容
您的模型（圖像、視頻、音頻或文本）正常生成輸出。無需更改模型架構、訓練數據或推理代碼。
Capture 簽名輸出
對 Capture 的一次 API 呼叫嵌入 C2PA 憑證（生成器身份、時間戳、內容雜湊）並通過 ERC-7053 在鏈上註冊內容雜湊。中位延遲低於 100 毫秒。
交付給用戶
簽名的內容返回給用戶或下游 API 消費者。C2PA 憑證隨文件傳輸；鏈上記錄可獨立發現。
按需審計
Capture 儀表板提供可匯出的合規報告，顯示每個已簽名資產、其鏈上記錄和驗證狀態 — 隨時供監管機構或第三方審計員使用。
使用案例 1
圖像生成 API
情境
一家 AI 圖像生成公司提供每天生成 50 萬+ 張圖像的 API。 其客戶將生成的圖像用於營銷、電子商務和社交媒體 — 其中大量到達歐盟受眾。
整合
該公司將 Capture 的 Node.js SDK 作為圖像交付管道中的後處理步驟。擴散模型生成圖像後， SDK 使用 C2PA 憑證簽名並在鏈上註冊雜湊 — 所有操作在一次非同步呼叫中完成，不阻塞回應。
結果
- 每張 API 生成的圖像自動攜帶雙層來源
- 平均簽名開銷：每張圖像 47 毫秒（P99：92 毫秒）
- 零模型架構或訓練管道更改
- 下游客戶預設獲得第 50 條合規內容
使用案例 2
大型語言模型（LLM）輸出
情境
一家企業 AI 公司運行大型語言模型，為財富 500 強客戶生成報告、摘要和面向客戶的內容。 根據第 50(2) 條，用於公開傳播的 AI 生成文本必須攜帶機器可讀的來源標記。
結果
- 所有生成的報告攜帶可驗證的 AI 來源憑證
- 企業客戶無需額外整合即可獲得合規就緒的輸出
- 每個資產清楚記錄哪些輸出經過人工審查、哪些完全由 AI 生成
- 審計軌跡顯示完整的生成和審查歷史
效能
為生產規模而建
<100ms
中位簽名延遲
50萬+
每天簽名的資產（生產環境）
99.9%
API 正常運行時間 SLA
1-2 週
典型整合時間
常見問題
AI 管道合規問答
第 50 條是否適用於所有 AI 公司？
第 50 條適用於生成合成內容（圖像、視頻、音頻或文本）的 AI 系統提供者以及分發此類內容的部署者。如果您的 AI 系統生成的內容到達歐盟用戶，您就在範圍內 — 無論公司總部在哪裡。
如果我們的 AI 模型被下游客戶使用怎麼辦？
作為 AI 系統的提供者，您與部署者共享標記義務。最高效的方法是在 API 輸出中內建標記，使每個下游客戶自動獲得合規內容。這正是 Capture SDK 所實現的。
簽名是否會增加推理管道的延遲？
Capture 簽名 API 的中位延遲低於 100 毫秒。對於推理需要 2-30 秒的圖像生成管道，簽名開銷可忽略不計。對於文本生成，簽名在回應組裝後非同步進行。
我們可以簽名文本輸出嗎？
可以。C2PA 支援文本內容憑證。對於 LLM 輸出，Capture 建立一個嵌入模型身份、生成時間戳和內容雜湊的 C2PA 清單。ERC-7053 鏈上記錄提供持久的第二層。這滿足了文本內容的第 50(2) 條。
微調或自定義模型怎麼辦？
Capture 的簽名與模型無關。無論您使用 GPT-4、Llama、Stable Diffusion 還是專有模型，簽名步驟都在生成後進行。C2PA 生成器斷言識別您的特定模型和版本。
如何處理用戶在生成後修改的內容？
每次修改都可以作為清單鏈中的新 C2PA 操作簽名。原始生成憑證保留，修改被附加。這建立了可審計的編輯歷史，無論發生多少次編輯都滿足第 50 條。