跳轉到主要內容
當稽核師問「證明這些控制項真的被強制執行了」時，你主控台的一張截圖經不起推敲——它未簽署、它是你的，而且它可編輯。OrcaRouter 產生一份簽署的合規報告：一個從你即時閘道控制項快照而來的自含證據包，以 SHA256 雜湊，並以 Ed25519 簽署，因此任何持有報告的人都能驗證它由 OrcaRouter 產生且自產生以來未被竄改。 本頁端到端走完使用案例——產生報告、交付它，並讓稽核師獨立驗證它。框架目錄與每個套件對應到什麼，參見 框架 與 套件內容。

​
1. 簽署的 AI 合規報告包含什麼

報告按框架在你選擇的時間視窗內產生，並在產生時對八個證據區段快照，因此即使底層日誌在你的保留政策下老化失效，產物仍保持有效。
每份報告都涵蓋相同的有序區段，因此兩份報告可比較：
  • Coverage——你已安裝的套件對應到哪些框架控制項，每個標記為 covered / observe / gap / attested。
  • Enforcement——視窗內實際記錄的防護欄匹配與防火牆裁決（allowed / blocked / audited）。
  • Consent——本期記錄的同意狀態，分類為 valid / stale / revoked / none。
  • Change log——視窗內的防護欄歷史與工作區稽核列。
  • Admin access——誰持有 admin，以及執行了哪些特權動作。
  • Gaps——未涵蓋的控制項，包括永遠無法被閘道自動化的組織性（人員／流程）條款。報告把這些揭露為誠實的缺口，而非暗示 100% 自動化合規。
  • AI supply chain——該工作區可觸及的上游供應商（次處理者）與模型，用以對照你的 DPA 提供證據。
  • Access reviews——該工作區的 API 金鑰與特權成員名冊，用於金鑰輪替衛生。
標準形式的證據 JSON 以 SHA256 雜湊（小寫十六進位）。該內容雜湊以 Ed25519 簽署，而簽章加上一個簡短的金鑰 id（例如 orca-…）被嵌入產物中。改動一個位元組的證據，雜湊就不再相符；偽造雜湊，簽章就不再能對照 OrcaRouter 的公鑰驗證。
  • PDF——人類可讀的稽核師交付件，簽章與金鑰 id 印在上面。
  • JSON——機器可讀的證據匯出。（簽章是對證據的標準形式而非原始檔案位元組計算的，因此請透過公開的 verify 端點驗證它，而不是自己重新雜湊產物——參見 驗證一份報告。）
  • CSV——供試算表與 GRC 工具使用的扁平表格匯出。
預設情況下，成員與動作者的電子郵件在每次匯出中都被遮罩。當你的稽核師需要時，請逐份報告明確選用未編修的 PII。
報告會被蓋上地區戳記。每個產物在你工作區宣告的資料駐留地區（us / eu / uk / ap / cn / global）下儲存與提供；為某地區產生的報告不會在另一地區下提供。如果這對你的義務很重要，請在產生之前先設定駐留地。

​
2. 誰可以產生

瀏覽框架目錄、已安裝套件與就緒度對每個工作區成員開放且免費。產生一份報告需要工作區 Admin，且匯出受方案門檻限制：
  • 免費方案包含一份 PDF 報告，因此你可以展示這個產物。
  • CSV / JSON 匯出與額外報告需要付費方案。
兩條規則都在伺服器端強制執行——沒有只在客戶端的繞道方法。
從主控台產生：開啟 Compliance → Reports、挑選框架與時間視窗、選擇一個格式，然後點擊產生。產生是非同步的——報告列以 pending 出現、走到 generating，並落在 ready（或 failed，沒有部分產物）。所有這些都在你的主控台工作階段下對 /api/compliance/* 路由執行——不涉及中繼（sk-orca-…）金鑰。

​
3. 一個具體的完整演練

一位 SOC 2 稽核師想要 Q1 的強制執行證據。工作流程：
1

安裝框架（一次）

以付費方案上的 Admin 身分，從 Compliance → Frameworks 安裝 SOC 2 套件。安裝會具現化對應到框架控制項的防護欄與防火牆政策。參見 安裝一個套件。
2

產生報告

在 Compliance → Reports 中，選擇 soc2、把期間設為你的 Q1 視窗、選擇 PDF，然後產生。等待該列達到 ready，然後下載。
3

把它交給稽核師

把 PDF 寄給他們（或鑄造一個唯讀的稽核師分享連結讓他們自行拉取）。簽章與金鑰 id 印在報告上。
4

他們獨立驗證它

稽核師永遠不必信任你的主控台。他們重新雜湊證據、取得 OrcaRouter 的公鑰，並檢查簽章——全都對照公開、未驗證的端點（下一節）。

​
4. 稽核師如何驗證它

驗證不需要帳號也不需要中繼金鑰——它對照 api.orcarouter.ai 上的兩個公開端點執行。 首先，取得作用中的公鑰： 
curl https://api.orcarouter.ai/api/public/compliance/pubkey
# => { "algo": "ed25519", "key_id": "orca-…", "public_key": "<base64>" }
然後提交報告的內容雜湊、簽章與金鑰 id： 
curl -X POST https://api.orcarouter.ai/api/public/compliance/verify \
  -H "Content-Type: application/json" \
  -d '{
    "content_hash": "<sha256-hex from the report>",
    "signature":    "<base64 Ed25519 signature>",
    "sig_key_id":   "orca-…"
  }'
# => { "valid": true, "key_id": "orca-…" }
valid: true 表示證據雜湊由 OrcaRouter 簽署且自此未變更。一位寧可完全不呼叫我們端點的稽核師，可以拿已發佈的 Ed25519 公鑰，用任何標準密碼學程式庫驗證對該雜湊的簽章——報告可離線驗證。
寧可不把 PDF 作為附件寄出？改為鑄造一個唯讀的稽核師分享連結——一個權杖化的 URL，直接提供報告（及其簽章），無需登入。參見 匯出證據。

​
5. 這如何契合整體

簽署報告是合規流程末端的產物。它周圍的環節：

框架

完整目錄——SOC 2、HIPAA、GDPR、EU AI Act、ISO 27001/42001、NIST AI RMF、PCI DSS、OWASP LLM Top 10，以及區域集合。

安裝一個套件

在報告之前，先具現化一個框架的防護欄與防火牆政策。

資料駐留地

蓋印並釘住你的簽署報告儲存與提供所在的地區。

驗證一份報告

深入的驗證流程——公鑰、雜湊與離線檢查。
報告內的證據來自你已設定的控制項。要強化被報告的內容，請調校你的 防護欄 與 防火牆，並在 共同責任 中檢視閘道能與不能證明的邊界。