合规与信任

合规章节不提供法律意见。这里讨论的是企业客户在安全、法务、采购和业务评审中真正会问的问题，以及产品侧应该准备什么证据。

AI 产品的合规评审通常不是从法规条文开始，而是从客户的五个不安开始：

主题客户真正担心什么产品方要证明什么常见失败
数据会不会回流prompt、附件、工具结果、输出、反馈样本是否进入供应商训练、内部 eval、调试样本或人工质检每类数据的去向、保留期、访问人群、训练/评估用途、删除链路只说“默认不训练”，却没有解释文件、batch、cache、日志、支持工单和反馈样本
供应商边界是否清楚上游模型、云厂商、搜索、浏览器、OCR、向量库、第三方 connector 是否都能接触客户数据sub-processor 清单、区域、用途、合同/DPA、可替换策略、功能级数据控制官网只列模型品牌，实际功能还调用了额外服务
Agent 会不会越权行动Agent 拿到工具权限后，是否能跨租户读取、发邮件、删数据、改权限、付款或写生产系统OAuth scope、工具 allowlist、动作分级、HITL、高风险 blocklist、管理员控制“需要用户确认”只出现在文案里，工具层没有强制策略检查
输出错了谁负责Agent 给出建议、生成草稿、调用工具或执行动作后，用户、客户企业、产品方和上游供应商如何分责责任边界、确认记录、可逆/不可逆动作策略、合同条款、错误上报和补救流程把所有错误都写成“模型可能出错”，却没有区分建议、草稿和真实执行
事故后能否说清楚出错后能否重放当时的上下文、模型版本、工具调用、参数、确认人、策略判断和影响范围审计日志、trace、版本记录、删除/导出流程、事故通知和 postmortem 模板日志只够工程 debug，不够客户审计、法务追责和数据删除

一句“我们有 SOC2”只能回答安全管理成熟度。Agent 产品还必须回答更细的问题：数据有没有被复制到新位置，功能开关是否改变保留策略，工具权限是否被模型绕过，用户确认是否真的可追溯，事故发生后能否隔离影响并向客户解释。

企业客户会问什么

尽调问题不能只回答应准备的实质材料
我们的数据会被用于训练吗？“不会”上游模型供应商条款链接、企业合同/DPA、账户级 data control 截图、产品自己的训练/评估数据策略
prompt 和 output 会保留多久？“按供应商默认”按功能列出的保留表：推理、文件、batch、代码执行、web search、prompt cache、日志、人工质检
哪些供应商会处理数据？“OpenAI/Anthropic 等”sub-processor 清单、区域、用途、数据类型、是否跨境、是否可替换
员工能否查看客户内容？“严格控制”RBAC、break-glass 流程、审批记录、访问日志样例、客户可请求的访问审计
Agent 能不能代表用户行动？“会有确认”工具 scope 表、高风险动作清单、HITL 策略、管理员配置截图、审计日志字段
出错后能否追溯？“有日志”task trace 示例：model call、tool call、参数、返回、确认人、版本、成本、错误分类
能否删除、导出、停用？“支持删除”删除 API/流程、备份删除周期、导出格式、租户停用后的数据处理
如何处理 prompt injection？“有安全策略”外部内容隔离、工具前策略检查、敏感动作二次确认、blocklist/allowlist、检测与复盘流程

这张表应该成为 trust packet 的目录，而不是只放在内部文档里。

先画一张数据流图

数据流要按“每一种数据类型”画，而不是只画系统组件：

数据类型例子可能去向关键控制
用户输入prompt、聊天消息、任务目标模型 API、任务日志、客服后台租户隔离、日志脱敏、保留期
附件PDF、图片、表格、代码仓库片段文件解析、向量库、模型 API、临时存储文件级权限、临时 URL、删除流程
上下文历史消息、记忆、检索片段、skillsprompt assembly、cache、模型 API最小化、可解释来源、cache 边界
工具结果CRM 记录、邮件正文、网页内容、数据库查询模型上下文、审计日志、调试样本敏感字段过滤、外部内容不可信标记
模型输出回复、草稿、计划、tool arguments用户界面、工具调用、日志输出标记、HITL、版本记录
反馈样本thumbs up/down、人工修正、失败轨迹eval 数据集、产品分析、训练候选集opt-in、脱敏、数据集隔离、可删除

如果这张表回答不清，就不要急着谈认证。认证是证明管理体系，数据流才是客户判断风险的入口。

供应商与功能矩阵

企业客户最关心的不是“你用了哪个模型”，而是“启用某个功能后，数据控制是否变化”。至少要维护这样的表：

功能典型供应商能力客户风险产品方承诺
普通模型调用主流商业 API 通常可承诺 API 输入输出不用于训练；可能仍有短期滥用监控日志prompt/output 暴露给上游提供当前条款链接、账户设置、保留期和删除策略
文件上传 / 文件 API文件可能需要独立存储和处理，不一定等同于普通推理请求文件保留、解析副本、向量化副本标注文件保留期、删除链路、向量索引删除
Batch批任务通常有异步队列和结果文件结果保存时间、失败重试、批量敏感数据标注结果保留和自动清理时间
Code execution代码、输入文件和执行结果可能进入沙箱代码/数据泄露、运行产物保留沙箱隔离、网络策略、产物清理
Web search / 浏览器工具查询和网页内容可能经过额外服务搜索查询、网页注入、cookie/会话风险域名授权、cookie 隔离、网页内容不可信处理
Prompt caching静态前缀可能被供应商缓存cache key、保留期、跨租户隔离只缓存非敏感静态前缀，说明 TTL 和禁用策略
人工质检 / 支持员工可能查看任务内容内部访问扩大审批、最小权限、访问日志、客户可审计

这张表要随着供应商条款和产品功能变化更新。不要把“API 默认不训练”扩展成“所有 AI 功能都零保留”。

Agent 权限控制

Agent 合规不只是隐私。越权动作比模型幻觉更容易造成真实损失。

最低控制面：

控制具体做法
最小权限每个工具只申请完成任务需要的 OAuth scope，不用全量读写权限
租户隔离task、memory、tool credentials、logs 都带 tenant 边界
工具 allowlist客户管理员决定哪些工具可用，哪些系统永远不可触达
高风险 blocklist银行、薪酬、合同签署、权限管理、生产数据库写入等默认禁止自主执行
动作分级只读、草稿、可撤销写入、不可逆写入、对外发送分开处理
HITL对外发送、付款、删除、权限变更、批量操作必须确认
策略检查tool call 前检查权限，tool result 后检查是否包含敏感外泄
Kill switch客户或平台可一键暂停某个 agent、工具或租户任务

客户需要看到的不只是“我们有权限控制”，而是具体到每类工具的 scope、默认策略、管理员能否覆盖、审计字段是什么。

审计日志应该长什么样

Agent 日志至少要支持回答“当时到底发生了什么”：

{
  "task_id": "task_123",
  "tenant_id": "acme",
  "user_id": "u_456",
  "model": "provider/model/version",
  "prompt_version": "2026-08-10.3",
  "tool_call": {
    "name": "gmail.sendDraft",
    "arguments_hash": "sha256:...",
    "target": "[email protected]",
    "risk_tier": "high"
  },
  "human_confirmation": {
    "required": true,
    "confirmed_by": "u_456",
    "confirmed_at": "2026-08-10T06:00:00Z"
  },
  "data_controls": {
    "retention_policy": "enterprise-30d",
    "training_use": "disabled",
    "region": "us"
  },
  "result": "success"
}

真实系统里可以对参数和值做脱敏或 hash，但字段必须能支撑追责、客户解释、事故复盘和删除请求。

Trust Packet

面向企业客户，建议准备一份可以随尽调发送的包：

  • 数据流图；
  • sub-processor 清单；
  • 按功能拆分的数据保留表；
  • 上游模型供应商当前条款链接、DPA/BAA/企业合同附件；
  • 账户级 data control 配置证明；
  • 工具权限模型和 OAuth scope 表；
  • 高风险动作清单和 HITL 策略；
  • 审计日志字段说明和样例；
  • 删除、导出、停用、备份清理流程；
  • prompt injection 和外部内容处理策略；
  • 事故响应 SLA、客户通知模板、postmortem 模板；
  • 受监管客户的部署差异说明。

这才是“打消顾虑”的材料：客户安全团队能审、法务能引用、采购能归档、业务负责人能理解。

和其他章节的衔接

参考资料

这页有帮助吗？
在 GitHub 编辑