跳转到主要内容
当审计员问”证明这些控制确实被执行了”时，一张你控制台的截图 经不起推敲——它未签名、它是你的，而且可编辑。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 供应链（AI supply chain）——工作区可触达的上游 提供商（子处理者）和模型，用以对照你的 DPA 提供证据。
  • 访问审查（Access reviews）——为密钥轮换卫生提供工作区 的 API 密钥和特权成员名册。
规范化的证据 JSON 用 SHA256（小写十六进制）哈希。该内容 哈希用 Ed25519 签名，签名加上一个短密钥 id（例如 orca-…） 被嵌入制品。改动一个字节的证据，哈希就不再匹配；伪造哈希， 签名就不再针对 OrcaRouter 的公钥验证通过。
  • PDF——人类可读的审计员交付件，签名和密钥 id 印在 上面。
  • JSON——机器可读的证据导出。（签名是针对证据的规范化 形式计算的，而非原始文件字节，所以请通过公共验证端点验证， 而不要自己重新哈希制品——参见 验证一份报告。）
  • CSV——用于电子表格和 GRC 工具的扁平表格导出。
默认情况下，成员和操作者邮箱在每次导出中都被掩码。当你的 审计员需要时，可按报告明确选择不脱敏的 PII。
报告是区域戳记的。每个制品在你工作区声明的 数据驻留区域 （us / eu / uk / ap / cn / global）下存储和提供服务； 为某一区域产生的报告不会在另一区域下提供服务。如果这对你的 义务重要，请在生成之前设置驻留地。

​
2. 谁能生成

浏览框架目录、已安装的包和就绪度对每个工作区 member 开放， 且免费。生成一份报告需要工作区 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，以及区域集合。

安装一个包

在对一个框架出报告之前先实体化它的防护栏和防火墙策略。

数据驻留

戳印并钉定你的签名报告存储和提供服务所在的区域。

验证一份报告

深入的验证流程——公钥、哈希和离线检查。
报告内部的证据来自你已配置的控制。要强化所报告的内容，请调优 你的 防护栏 和 防火墙，并在 责任共担 中审视网关 能证明与不能证明什么的边界。