合规
Agent 产品的合规边界——第三方模型 API、训练数据回流、模型输出责任都是传统 SaaS 没有的摩擦点。五大主题与章节导读。
每次推理客户数据都离开你
Agent 产品所有合规问题都源于同一个事实：每次推理都把客户数据（prompt 内容、附件、上下文）发送给第三方模型供应商（Anthropic、OpenAI 等）。客户数据至少经过两个组织——你的产品 + 上游模型方——合规承诺必须覆盖整条链。
这条数据链衍生出三个 agent 产品合规独有的问题：
1. 数据离开你的控制范围
传统 SaaS 的合规边界由你的部署架构决定——客户数据始终在你的基础设施内流转。Agent 产品的客户数据每次推理都跨组织传输，每个组织对数据的保留、训练、二次使用规则都必须显式约定，不能依赖默认设置。
2. 输出内容的责任主体不清
传统 SaaS：用户做决策，产品提供工具。如果用户用 Notion 写错了合同条款，是用户的责任。
Agent 产品：agent 自主做决策。如果 agent 帮用户写错了合同条款，责任在谁——用户、产品方、还是模型供应商——没有成熟法律先例。多数合规框架（SOC2、GDPR）也没有专门条款。
3. 训练数据回流问题
传统 SaaS：客户数据用于产品功能，使用范围由合同明确。
Agent 产品：上游模型供应商可能保留 prompt / output 用于模型训练。这一行为通常通过商业合同可以禁用（OpenAI、Anthropic 都提供”零保留”选项），但默认是保留——产品方必须显式选择性地切断这条链路并向客户证明。
五个核心主题
数据驻留与跨境
客户数据在哪个地理区域处理 / 存储是合规的第一问。
- 你自己的基础设施在哪——AWS us-east-1、自建 IDC、Cloudflare 边缘节点
- 上游模型 API 调用走哪个地理 endpoint——Anthropic、OpenAI 各有 US / EU 区域端点
- 中间组件（向量数据库、缓存层、日志管道）的位置
- 合规约束矩阵：GDPR 数据出境、中国《数据出境安全评估办法》、美国 ITAR、各地特定行业规则（医疗、金融）
审计轨迹
Agent 行为的可追溯粒度是 agent 产品合规的核心要求。
- 任务级：用户提交 → agent 计划 → 工具调用序列 → 输出
- Token 级：每步消耗的输入 / 输出 token、cache 命中情况、调用模型
- Tool-call 级：哪个工具被调用、参数、返回值、是否触发 HITL
- 留存期与查询能力：合规通常要求 1-7 年留存、< 1 小时查询响应
实操难点：Token 级日志数据量巨大（百倍于 task 级），需要分层存储 + 索引策略。
模型输出责任
详见 model-output-liability。核心议题：
- 自主决策与 HITL 分界线在哪
- 合同里责任如何分配
- 保险产品是否覆盖 agent 错误
行业认证
不同认证适用范围：
- SOC2 Type II：通用安全控制，B2B 销售必备；典型 12-18 个月获得
- HIPAA：医疗行业；需要 BAA 协议 + 上游模型方的 HIPAA 合规支持
- GDPR：欧盟用户；DPA + 数据出境机制 + 用户删除权
- CCPA / 中国 PIPL：地区性，要求类似 GDPR 但条款不同
- ISO 27001：国际化大客户偏好；与 SOC2 部分重叠
- 行业专项：FedRAMP（美国政府）、Bafin（德国金融）、各国特定数据法
获得顺序通常是：SOC2 → GDPR DPA → ISO 27001 → 行业专项。
数据回流与训练
详见 data-feedback。核心议题：
- 默认情况下上游模型供应商是否保留 prompt / output
- 如何在合同与技术层切断回流
- 向客户如何证明”数据不被用于训练”
与其他章节的衔接
- 审计轨迹的实现：operations/overview 的日志管道
- HITL 在 ROI 模型中的位置：economics/controls-and-roi
- 涉合规的客户上线流程：playbooks/onboarding