2026 加州 AB 853 AI 检测工具：上传、URL、API 与隐私验收

你的 AI 检测页面能用，但为什么仍可能过不了验收？

如果你正在为加州用户上线生成式 AI 产品，加州 AB 853 AI 检测工具可能已经进入产品、工程和法务的联合排期。真正棘手的地方，不是做一个“上传文件后返回真假”的页面，而是要同时处理来源验证、个人信息隔离、公开访问、API 调用和用户反馈。

更容易被忽略的是，2026 年 8 月 2 日是 California AI Transparency Act 相关章节开始实施的日期；AB 853 延后的只是实施节点，并没有把检测工具要求改成可选项。加州现行法要求，达到门槛且在加州公开可访问的 GenAI 系统提供方，应免费提供 AI detection tool。(leginfo.legislature.ca.gov)

所以，验收时不能只问“能不能识别自家模型生成的图片”。你还需要证明：用户能通过上传、URL 和 API 使用工具，结果页能输出合规的 system provenance data，同时不返回 personal provenance data，提交内容也不会被无限期保存。

先判断：你的团队是不是 covered provider？

法条定义的 covered provider，是指创建、编写或以其他方式生产 GenAI 系统，并且该系统在加州地理范围内公开访问，同时拥有超过 1,000,000 名月度访问者或用户的主体。这里的重点是“谁生产系统”和“系统是否公开可访问”，不只是公司注册地在哪里。(leginfo.legislature.ca.gov)

可以按下面的顺序做内部判断：

1. 你是否拥有、开发或实质控制生成图片、音频、视频或混合内容的 GenAI 系统？
2. 加州用户是否可以直接访问，或通过公开产品入口使用？
3. 月度访问者或用户是否超过 1,000,000？
4. 你是模型提供方、产品运营方，还是只调用第三方 API 的普通企业用户？
5. 你的系统是否属于仅提供非用户生成内容的游戏、电视、流媒体、电影或互动体验？

普通企业用户调用第三方模型，通常不能仅凭“我使用了 AI”就认定自己是 covered provider；但如果企业自行训练、改造并公开运营系统，或者向第三方授权自己的 GenAI 系统，就需要让法务进一步确认角色边界。法律适用判断不能用一个产品经理的猜测替代正式审查。

⚠️ 注意： “模型开发者”“第三方接入方”“GenAI hosting platform”和“large online platform”并不是同一个角色。AB 853 对大平台和模型托管平台的新增义务，主要分阶段在 2027 年 1 月 1 日起实施，不应全部提前套到 2026 年 8 月的 AI 检测工具验收上。(leginfo.legislature.ca.gov)

加州 AB 853 AI 检测工具到底要支持哪些路径？

California AI Transparency Act detection tool 的核心要求，不是只提供一个内部调试接口。现行条文明确要求工具免费、公开可访问，并支持用户上传内容、提供指向在线内容的 URL，还要支持 API，让用户不访问提供方网站也能调用。(leginfo.legislature.ca.gov)

产品设计至少应覆盖这 3 条路径：

• 内容上传检测：支持图片、音频、视频以及混合内容；返回是否由自家 GenAI 系统创建或修改的判断。
• URL 内容检测：允许用户提交在线内容地址，服务端抓取时要处理重定向、超时、鉴权、robots 限制和恶意 URL。
• API 调用检测：提供稳定的认证、请求体、错误码、超时策略和版本控制，不能只把网页接口简单包装成一个不稳定的内部端点。

“公开访问”不等于完全没有安全控制。法律允许提供方为了防止或应对可证明的系统安全、完整性风险设置合理访问限制，但限制不能被设计成只有内部员工才能使用。验收时应记录限制触发条件、用户提示和解除方式，而不是只写一句“有风控”。

结果页应输出什么，哪些字段必须拦截？

AB 853 沿用的来源数据框架，把 provenance data 分成 system provenance data 和 personal provenance data。前者是不能合理关联到特定用户、且能说明设备、系统、服务或内容真实性的信息；后者包括个人信息，或能够合理关联到特定用户的设备、系统、服务信息。(leginfo.legislature.ca.gov)

因此，system provenance data 输出要求可以拆成两层：

可以展示的内容：

• 是否检测到来源数据；
• 内容是否由你的 GenAI 系统创建或修改；
• GenAI 系统名称与版本；
• 创建或修改时间；
• 唯一标识符；
• 与内容真实性、修改历史相关的非个人字段；
• 数字签名是否存在，以及签名验证状态。

默认不应展示的内容：

• 用户姓名、邮箱、账号标识；
• 可关联个人的设备序列号；
• 精确到个人的设备、系统或服务标识；
• 上传文件中未经过筛选的原始 provenance payload；
• 能通过组合字段重新识别内容创作者的信息。

建议把结果 API 设计成“允许字段白名单”，而不是先返回全部元数据、再依靠前端隐藏。例如：

{
  "source_status": "detected",
  "generated_by_system": true,
  "system_provenance": {
    "provider": "example-system",
    "version": "v3",
    "created_at": "2026-07-27T10:00:00Z",
    "content_identifier": "redacted-id"
  },
  "personal_provenance": {
    "returned": false
  }
}

这里的字段只是工程示例，不代表法规规定的唯一 JSON 格式。核心原则是：后端先完成个人来源数据过滤，前端再展示 system provenance data，不能把隐私保护寄托在网页组件上。

latent disclosure 和 manifest disclosure，别混成一个水印

很多团队会把“页面上显示 AI 生成”和“文件里写入可检测来源”统称为水印，但两者的产品责任不同。

Manifest disclosure 是面向普通人的显著披露。它应清晰、醒目、适合内容媒介，并让合理用户能够理解内容是 AI 生成的。比如视频页面上的明显标签、音频播放界面的提示或图像旁的说明。

Latent disclosure 则是潜在披露，存在于内容或元数据中，普通人未必直接看到，但检测工具应能识别。现行法要求其在技术可行且合理的范围内，传达提供方名称、系统名称与版本、创建或修改时间、唯一标识符，并且要能被自家的检测工具检测。(leginfo.legislature.ca.gov)

完整验证闭环应当是：

1. 生成服务创建内容；
2. 生成链路写入 latent disclosure；
3. 内容经过压缩、转码或常规编辑；
4. 用户把文件上传到检测工具；
5. 检测工具识别披露并返回 system provenance data；
6. 结果页明确区分“检测到来源数据”和“未检测到来源数据”；
7. 用户可提交误报、漏报或无法识别的反馈；
8. 工程团队把反馈关联到检测器版本和内容类型。

如果你的工具只会识别“自家数据库里保存过的文件哈希”，却无法验证文件中的潜在披露，那么它很可能只是内容比对服务，不是完整的来源检测工具。

上传、URL 和 API 的隐私留存怎样设计？

AI 检测工具隐私留存要求的核心是最小化处理。法条要求不得收集或保留用户个人信息，但用户主动提交反馈并明确选择接受联系时，可以收集联系方式；提交的内容也不能保留超过履行该章节所必要的时间，同时不得保留内容中的 personal provenance data。(leginfo.legislature.ca.gov)

工程上可以采用下面的 5 步留存方案：

1. 接收前告知：上传页、URL 页和 API 文档分别说明处理目的、临时缓存、失败重试和删除规则。
2. 进入隔离区：文件先进入短时对象存储，禁止进入通用媒体库、训练数据集和客服下载目录。
3. 先解析后过滤：提取必要的 system provenance data，过滤 personal provenance data，再生成结果。
4. 处理完成即删除：删除原始文件、抓取缓存和未过滤元数据；如果因安全调查需要保留，应单独记录法律依据、负责人和期限。
5. 反馈单独授权：反馈内容与检测样本分离，只有用户明确同意联系时才保存联系方式，并限定为改进检测有效性。

URL 检测还要增加网络安全控制：禁止访问云平台元数据地址和内网网段，限制重定向次数，设置响应体大小上限，对压缩包和脚本内容进行拒绝或沙箱处理。API 日志则不应默认记录完整媒体内容、完整 URL 查询参数或可能包含个人信息的原始 provenance payload。

💡 经验：“不保存文件”不等于“没有留存”。对象存储版本、失败重试队列、CDN 缓存、APM 请求体、备份快照和调试日志，都可能让原始内容继续存在。隐私验收必须沿着数据生命周期逐层查，而不是只检查主数据库。

上线前怎样做一轮可复现的验收？

不要只用 2 张正常图片测试。建议产品、工程、隐私和法务共同建立带版本号的测试集，并至少完成以下 8 步：

1. 准备自家系统生成的图片、音频、视频和混合内容样本。
2. 准备同格式的真实内容、第三方模型内容和人工编辑内容。
3. 对样本执行裁剪、压缩、转码、改名和容器格式转换。
4. 分别走上传、URL 和 API 3 条入口。
5. 验证结果是否能区分“自家系统创建”“自家系统修改”“未检测到”“格式不支持”和“无法访问 URL”。
6. 检查返回字段，确认 system provenance data 可读，personal provenance data 不出现在页面、API、日志和下载文件中。
7. 对断网、超时、恶意 URL、超大文件、错误 MIME 类型和重复请求执行安全测试。
8. 提交误报和漏报反馈，验证是否有授权记录、工单关联、版本号以及后续改进闭环。

特别要测试披露被破坏后的结果。比如视频重新编码后 latent disclosure 消失，或者图片经过社交平台下载后元数据被清除，工具应返回“未检测到来源数据”或“无法验证”，而不是武断地返回“确定不是 AI”。

验收证据建议包含：需求编号、测试样本哈希、输入路径、API 请求 ID、检测器版本、返回字段快照、日志检索结果、删除任务记录和责任人签字。这样发生争议时，团队能说明当时测试了什么，而不是只保留一张成功页面截图。

为什么“能返回结果”仍然可能不合规？

以下几类实现看似完成了功能，实际上风险很高：

• 只做网页，不做 API：用户必须登录并打开页面才能检测，无法满足不访问网站即可调用的产品路径。
• 只识别自家文件：没有解析 latent disclosure，也不能处理经压缩、转码或外部传播的内容。
• 结果页展示全部元数据：把个人来源信息、设备标识或上传者账号一起返回。
• 上传内容进入训练集：检测工具样本被用于模型训练或质量分析，但没有单独授权。
• 反馈机制只是邮箱：没有记录用户是否同意联系，也无法把反馈关联到检测器版本。
• 长期保存 URL 抓取结果：把第三方页面、媒体文件和查询参数留在缓存或备份里。
• 把 manifest 当成 latent：页面上有显著标签，但文件内部没有可被自家工具验证的潜在披露。
• 没有失败态：所有结果只有“AI”或“非 AI”，无法表达来源缺失、格式不支持和验证不确定性。

加州现行法还规定，违反该章节可能按每次违规 5,000 美元承担民事罚款，并且每个违规日可视为独立违规。这个数字不是用来替代法务判断，而是提醒团队：上线后的持续监控、版本变更和日志证据同样重要。(leginfo.legislature.ca.gov)

欧盟 Article 50 的能力可以复用多少？

如果产品同时面向欧盟，EU AI Act Article 50 同样强调生成合成音频、图像、视频或文本内容时，应采用机器可读标记，并使其能够被识别为人工生成或操纵内容；该透明度义务的日期为 2026 年 8 月 2 日。(artificialintelligenceact.eu)

工程能力上，可以复用：

• 机器可读标记的写入与解析；
• 内容来源、修改历史和唯一标识的统一数据模型；
• 检测器版本管理；
• 压缩、转码、编辑后的鲁棒性测试；
• 结果页的来源状态和验证失败状态。

但两地要求不能直接画等号。加州规则明确要求免费、公开访问、上传内容或 URL、API 调用、个人来源数据不输出和反馈机制；EU AI Act Article 50 主要围绕透明度与机器可读标记展开。复用的是底层能力，不是把一个地区的合规清单原封不动当成另一个地区的法律结论。

本站 AB 853 AI 检测工具验收矩阵

下面这份矩阵是本站分析用的工程验收占位表，不代表已完成任何实际测试，也不替代法律意见。你可以复制到项目管理系统，再为每一项补充样本、负责人和证据链接。

你现在最该问的 3 个问题

问：只支持图片检测，能不能先上线？

如果你的 GenAI 系统会生成或修改音频、视频，不能把图片页面当成完整验收。法条描述的工具范围覆盖图像、视频、音频以及它们的组合，产品应按实际输出模态逐项确认。(leginfo.legislature.ca.gov)

问：API 一定要开放给所有匿名用户吗？

不一定。工具需要公开可访问，但可以为了可证明的安全或完整性风险设置合理限制。实际设计可以使用 API 密钥、限流、配额和滥用检测，但不能把 API 变成只有内部服务账号才能访问的隐藏接口。(leginfo.legislature.ca.gov)

问：检测结果显示“没有 provenance data”，是不是就代表内容不是 AI 生成？

不是。它只能说明当前提交内容中没有被工具验证到可用来源数据，可能是来源从未写入，也可能在编辑、转码、截图或平台处理过程中丢失。结果文案应明确表达“未检测到”与“确认不是 AI”的差异。

用什么环境完成最终验收更稳？

不少团队会直接在现有 Windows 工作站、Linux 云主机或共享开发机上完成全部测试，但这类方案有几个现实缺点：测试环境容易被其他项目抢占，媒体编解码和浏览器版本不一致，远程桌面链路会影响上传与 URL 抓取复现，而且隐私日志和调试文件常常混在公共环境里。

如果验收还涉及 macOS 客户端、Safari 行为、Apple 设备采集链路或本地媒体处理，临时采购硬件又会增加设备折旧、账号配置和团队共享成本。更实际的做法，是把短期测试环境与长期生产架构分开：生产服务继续按法规要求设计，客户端兼容性和跨设备验证则使用独立的 Mac 环境。

通过 ZilCloud 的 Mac 云端方案，产品和工程团队可以按测试周期准备独立 Mac 环境，减少共享机器带来的权限混用、环境漂移和排队等待；需要预算评估时，可先查看 ZilCloud 价格页面。它不能替代法务审查，也不会自动让 AI 检测工具合规，但能让 Safari、macOS 媒体处理、客户端上传和 API 联调拥有更可复现的验收环境。

最后，建议你把本文矩阵保存下来，由产品、工程、隐私与法务共同完成 covered provider 确认、上传／URL／API 测试、来源数据过滤和留存审查。本文用于工程与产品规划，不构成法律意见；正式上线前仍应以加州现行法规原文及专业法律意见为准。