OpenAI 內容來源驗證 API 怎麼接入？2026 開發者流程

時間起點：本週先確認訊號範圍

OpenAI 官方文件列出 兩類值得分開處理的來源訊號：圖片中的 C2PA Content Credentials，以及圖片或音訊中的 SynthID。這代表 OpenAI 內容來源驗證 API 適合核驗受支援的 OpenAI 來源訊號，不是通用 AI 生成內容偵測器；本週先對照官方支援範圍，再決定是否接入上傳審核流程。OpenAI 來源訊號說明與API 指南都提醒：沒有檢出訊號，不等於內容不是 AI 生成。

適合負責內容審核或事實核查產品的開發者，參考 API 接入與結果處理流程。
需要辨識圖片來源的技術負責人，可用本文規劃審核節點與分流狀態。
維護媒體上傳服務的工程師，可據此檢查檔案格式、訊號覆蓋與異常處理。

先做適用性判斷

將「來源訊號核驗」和「判斷內容真假」拆成兩項產品能力。C2PA Content Credentials 是隨內容攜帶的來源資訊；C2PA 規範亦說明，處理及轉換可能影響憑證能否與內容一同保留。C2PA Content Credentials 規範 SynthID 則是另一種水印訊號。兩者不是同一種機制，也不能涵蓋所有生成工具或所有媒體檔案。

支援情況會受產品、模型、檔案類型及處理路徑影響。不要只在上線時讀一次文件；每當你更換圖片轉檔、壓縮或音訊處理流程，都應重新確認相應輸入是否仍在官方支援範圍內。

接入前的流程盤點

先畫出檔案從使用者上傳到公開發布的路徑，再決定核驗位置。若上傳後立即壓縮、裁切或轉碼，來源資訊可能在核驗前就被改動。若等到發布後才檢查，則需要另外設計撤回或補審機制。對多階段處理的服務，可在保留原始上傳檔案的前提下核驗，並於媒體轉換後按業務需要再次確認。

在呼叫前，記下產品實際會接收的圖片或音訊格式、最大檔案限制的官方現行說明、是否保留原始檔，以及要留存哪些審核紀錄。不要自行假設所有格式都可送驗；應逐項對照API 指南中的請求方式與支援說明，並查看建立核驗請求的介面參考。官方範例、欄位名稱與 SDK 要求可能更新，實作時以當下文件為準。

權限也要先納入設計：API 憑證留在伺服器端，不放進瀏覽器程式碼或公開的行動端程式；記錄請求識別資訊與必要狀態即可，避免把完整媒體檔案、憑證或不必要的個人資料複製到一般應用程式日誌。若團隊正在整理服務帳戶與平台使用問題，可參閱VPSSpark 幫助中心。

呼叫 API 並保存原始回應

Python SDK 的核驗請求可依官方方法文件建立。以下範例示意提交本機檔案並保存結構化回應；實際參數名稱、相依套件版本及可用欄位，請以建立核驗請求的官方參考為準：

from pathlib import Path
from openai import OpenAI

client = OpenAI()

with Path("upload.png").open("rb") as media:
    response = client.content_provenance.checks.create(file=media)

result = response.model_dump()
print(result)

不要把這段示例中的檔名或檔案類型當成完整支援清單。上線前，用官方文件列明的請求格式測試你的實際檔案，再檢查 SDK 解析後的結構化回應。若你的 SDK 版本尚未提供對應方法，先核對 SDK 文件與 API 介面參考，不要自行把回應欄位名稱寫死。

建議保留原始回應的伺服器端副本，另外轉換成自家穩定的審核狀態。這樣當 API 新增欄位或訊號種類時，你可以更新映射邏輯，不必讓前端直接依賴外部回應結構。請同時確認官方錯誤碼說明與速率限制指南，再設置重試策略與佇列容量。

解析結果而不是判定真假

回應先按原始訊號類型、檢測結果與驗證狀態解析。你可以將業務狀態設計為「發現受支援訊號」、「未發現受支援訊號」及「待處理／人工複核」。第三種狀態涵蓋請求失敗、逾時、未知回應或無法依現行欄位安全映射的情況。不要將不同原因壓成一個布林值，再顯示成「AI／非 AI」。

分流時採用下列條件：

• 若回應顯示檢出受支援訊號，將它記為來源線索，交由產品流程確認來源聲明；不要宣稱內容真實、完整或沒有編輯。
• 若回應為 not_detected，只記錄「未發現受支援訊號」，保留其他審核判斷；不得據此宣告非 AI 生成。
• 若逾時、上傳失敗或欄位無法辨識，標記為待處理或送人工複核；不要把錯誤狀態當成通過。
• 若業務要求判斷事實真偽或發布風險，另接內容政策與人工查核流程，不能用來源核驗結果替代。

注意：not_detected 的範圍有限。官方說明指出，元資料可能被移除、水印可能退化，內容也可能出自舊模型或其他 AI 來源；所以未檢出不是排除 AI 生成的證據。

把結構化回應轉成業務狀態時，建議保留訊號類型、API 回應中的核驗狀態、請求時間、內部媒體識別碼及人工處理結果。只記錄支援稽核與故障排查所需的資料，設定存取權限與保留期限；若媒體涉及個人或敏感內容，更不要把原始檔案不必要地寫入一般應用程式日誌。

上線驗收與決策評分

用一組涵蓋正常、未檢出及異常狀態的測試媒體走完整條呼叫鏈，驗收項目包括：請求是否在正確的審核節點發出、原始回應是否可追查、狀態映射是否保留未知情況、逾時與上傳失敗是否進入待處理流程，以及人工覆核結果能否回寫。這是工程驗收，不是對 API 偵測率或延遲的性能承諾。

若「範圍理解」或「失敗處理」評為低，先不要自動化發布決策；保留人工覆核，並回頭確認目前的支援類型、欄位說明與 SDK 要求。官方 API 文件或介面欄位有變動時，也應重新跑過這條驗收鏈。

常見接入問題

OpenAI 內容來源驗證 API 可以核驗其他工具生成的圖片嗎？
它不是通用 AI 偵測器。只有文件所述、目前受支援的 OpenAI 來源訊號屬於核驗範圍；其他工具生成的內容若沒有受支援訊號，可能不會檢出。產品與檔案處理路徑變動時，重新查看官方指南。

not_detected 是否代表圖片不是 AI 生成？
不代表。它只表示此次核驗未找到受支援訊號。元資料可能已被移除，水印可能退化，也可能是舊模型或其他 AI 來源；應維持未確認狀態，再依產品風險安排人工複核。

怎樣將核驗結果接入審核流程？
在上傳後、發布前選擇合適節點，保存原始結構化回應，並映射成訊號檢出、未檢出及待處理等內部狀態。對逾時、錯誤與未知回應另設路徑，不要把它們當作未檢出。

API 呼叫範例中的參數與支援格式是否固定？
不要假設固定。官方介面文件會說明現行請求方法、檔案支援範圍與 SDK 使用方式；你應在每次調整上傳或轉檔流程時重新核對。程式碼範例用來理解呼叫模式，不是支援格式的完整清單。

若你目前以自建規則或單一布林值做判斷，常見問題是無法區分來源線索與事實判定、轉檔後訊號可能消失、失敗狀態也容易被誤當成通過。接入 OpenAI 內容來源驗證 API，可以補上受支援來源訊號的核驗環節，但仍需保留獨立的人工審查與內容政策。若測試鏈路還需要持續運行的開發環境，可按負載與設備需求比較本機、一般雲端服務及租用 Mac；需要臨時 Mac 算力時，可將 VPSSpark 納入評估，帳戶與租用相關資訊可從VPSSpark 幫助中心查閱。