智能体产品怎么合规设计？把责任锚定到人身上的四项原则

智能体和生成式AI的根本区别，是它从"会说"变成"会做"。会说话的模型说错了可以删，会办事的智能体办错了可能已经造成资金损失或数据外泄。所以智能体合规设计的起点不是内容审核，而是控制权设计：谁能让它做什么、做到什么程度、出问题时能不能叫停、事后能不能还原。法律上不存在"AI担责"这回事，《民法典》的过错责任与产品责任，落到主体上都是自然人、法人或非法人组织。把责任锚定在人身上，是所有技术方案的终点，也是判断产品合规与否的唯一实用标准。

一、智能体不是责任主体，人是

我国现行法律框架里，责任主体只能是"人"。侵权走《民法典》第一千一百六十五条的过错责任，产品缺陷走第一千二百零二条至第一千二百零七条的产品责任，两条路径落到的都是开发者、运营者、销售者、使用者。智能体没有法律人格，不具备承担责任的能力，也不具备成为被告的资格。

这个结论的实务含义是：任何"AI自己做的"这种抗辩，在法律上都不成立。产品方决定了智能体能调用哪些工具、默认权限有多大、异常时是否熔断，这些都是人做的决定，因而都在可归责的范围内。

由此推导出三条设计原则：

关键操作必须保留人工确认。 涉及资金划转、合同签署、数据删除、对外发布这四类动作时，智能体只能提供建议和预执行，最终确认权必须留给用户。这里的"确认"要能被证明发生过，而不是界面上有个弹窗就算。

操作日志必须全程留痕。 每一次工具调用、数据访问、决策输出，都要记录时间、内容、发起人、授权依据。留痕的目的不是应付检查，而是在纠纷中证明自己没有过错。

权限必须最小化。 禁止一揽子授权，禁止默认开启动态能力，禁止用同一个凭证跑通所有场景。权限越大，产品方对后果的可预见性越强，过错认定也就越容易。

二、四项原则怎么落到代码里

顶层文件确立的四项原则——安全可控、权责清晰、透明可释、公平普惠——不是口号，每一项都有对应的工程实现。

安全可控，落地形态是沙箱加熔断。 沙箱解决的是"能碰到什么"：把智能体的可访问范围限制在隔离环境中，对文件系统、网络出口、数据库连接分别设限，跨出边界即拒绝。熔断解决的是"什么时候停"：设置行为基线，一旦出现偏离预设规则的动作（短时间内高频访问敏感表、试图调用未授权工具、输出触发风险词库），系统自动暂停并告警。这里的关键设计是熔断必须是自动的，不能依赖人盯着。等到人工发现，损失通常已经发生。

权责清晰，落地形态是数字身份。 给每一个智能体实例分配唯一身份标识，执行操作时附带该身份的签名。这样出问题时能迅速定位到具体实例、其开发者、部署者、使用者，形成完整链条。多智能体协作场景下这一点尤其重要——A智能体调用B智能体、B再调用外部接口，如果没有身份串联，事后根本无法还原是谁触发的。

透明可释，落地形态是三层告知。 第一层，交互开始时明确告知用户对方是AI而非真人，且该提示不可折叠、不可一闪而过。第二层，执行前告知将要做什么，特别是涉及外部系统写入或资金变动的操作。第三层，执行后给出可读的动作摘要，让用户知道刚刚发生了什么。三层缺任何一层，都会在纠纷中被认定为未履行告知义务。

公平普惠，落地形态是输出审计。 智能体的决策质量取决于训练数据和规则设计。如果训练数据在性别、地域、年龄上存在偏差，输出会带歧视性。落地动作是定期抽样审计输出结果，检测特定群体的通过率、拒绝率是否存在系统性差异，发现偏差时补充数据或调整规则。这项工作的难点在于企业往往没有对照组，建议在冷启动阶段就保留基线和抽样记录。

三、身份与授权：责任链的技术锚点

正在推进的智能体身份鉴别与授权技术框架，核心问题只有一个：谁有权让智能体做什么。三个技术要点值得产品方提前布局。

双向身份认证。 不仅验证人类用户的身份，也要验证智能体本身的身份。只验人不验机，意味着智能体可以被劫持、被仿冒而无从察觉。一个被替换了系统提示的智能体，行为上仍是"合法登录"，但实际已经不是同一个行为主体。

动态授权。 权限不应是静态配置，而应根据任务场景、风险等级实时调整。同一账号在办公场景可读通讯录，在支付场景则不应具备转账能力。动态授权的实现前提是把权限从"账号级"细化到"动作级"。

即时撤销。 用户撤回授权或智能体出现异常时，系统要能立刻终止其全部在途权限，包括已经发出但尚未执行的指令。很多系统的撤销只对后续请求生效，已排队的动作照常执行，这在应急场景下等于没有撤销。

四、运行时安全的三个控制面

输入面。 对智能体接收的指令做实时过滤，重点是间接提示注入——用户在文档、网页、邮件里埋入指令，诱导智能体执行非预期动作。这类攻击绕过用户直接输入层，是最难防的一类。工程上的缓解手段包括：区分指令来源的信任等级、对外部内容中的指令性语句做标记而非执行、对高风险动作强制二次确认。

执行面。 不同智能体实例之间相互隔离，防止一个实例被攻破后横向影响其他实例。隔离要覆盖计算、存储、凭证三个层面，尤其要避免共享同一个高权限服务账号。

监控面。 通过行为基线建模识别异常模式。基线的粒度决定了检测效果，建议至少覆盖调用频次、访问对象分布、时段分布、失败率四个维度。单纯的阈值告警会产生大量误报，导致运维最终关掉告警，这是最常见的形式化安全。

五、必做清单

| 合规维度 | 具体动作 | 参考依据 |

|---|---|---|

| 算法备案 | 具有舆论属性或社会动员能力的智能体服务须备案 | 互联网信息服务算法推荐管理规定 |

| 生成式服务备案 | 向境内公众提供生成式服务须履行备案与安全评估 | 生成式人工智能服务管理暂行办法 |

| 个人信息保护 | 处理前取得单独同意；涉敏感个人信息须做影响评估 | 个人信息保护法第二十九、五十五条 |

| 内容安全 | 建立输出审核与违法不良信息处置机制 | 生成式人工智能服务管理暂行办法第九条 |

| 数据安全 | 访问数据分类分级，重要数据不得出境 | 数据安全法第二十一、三十一条 |

| 应急响应 | 制定安全事件预案，明确分级、流程、报告义务 | 网络安全法第二十五条 |

| 用户告知 | 显著位置告知服务由智能体提供，说明能力边界与局限 | 智能体规范应用与创新发展实施意见 |

| 标识义务 | 生成内容依规添加显式与隐式标识 | 生成合成内容标识办法 |

这张表的价值不在打勾，而在于每一项背后都要有可出示的材料。备案有编号，评估有报告，告知有截图，留痕有日志。拿不出来的，视为没做。

六、五个高频误区

误区一：把团体标准当成软要求。 团体标准本身不具强制力，但其中确立的技术路线很可能被后续国家标准或监管规则吸收。等到变成强制要求再改架构，成本是提前布局的数倍。

误区二：以为内部使用的智能体不受监管。 纯内部研发、不向公众提供服务的，不适用生成式服务的管理要求。但通过接口向外部客户提供能力，即视为对外提供服务；即便纯内部使用，仍受网络安全法、数据安全法、个人信息保护法约束。

误区三：把留痕做成事后补录。 日志如果是靠人工填表，在争议中的证明力接近于零。可采信的留痕必须是系统自动生成、不可事后编辑、带时间戳的。

误区四：把用户体验当免责理由。 "默认开启是为了流畅"在监管视角下恰恰是过错证据——它说明产品方预见到了风险却选择不设限制。

误区五：认为智能体没有金融牌照就完全不能碰金融场景。 需区分场景：仅提供信息展示或辅助建议的，不需要金融牌照；能够直接执行交易（自动下单、代为申请贷款）的，构成金融业务的自动化处理，运营主体必须具备相应资质。边界在于是否形成对交易的实质代理，而不在于界面里有没有出现"理财"两个字。

广东华商律师事务所潘杰峰律师点评

智能体带来的最大变化，是产品缺陷的后果从"说了不该说的话"变成"做了不该做的事"。前者可以删除、可以道歉，后者可能已经造成资金损失或数据外泄，道歉解决不了问题。

我建议管理层在立项阶段就问一个问题：如果明天发生一次智能体误操作，你能否在两天内还原出它做了什么、为什么这么做、谁授权了这一步？如果答案是否定的，当前最紧要的不是补合规文档，而是补留痕。文档可以后写，日志不能后补。

第二点提醒是关于默认设置的。很多团队为了体验流畅，把高风险能力做成默认开启、把确认弹窗做成可跳过。这在监管视角下是明显的过错证据，因为产品方已经预见到了风险，却主动选择了不设限制。把默认值改成关闭、把确认做成不可跳过，体验损失有限，抗辩空间大得多。

第三点，涉及金融、医疗、政务等强监管场景的产品，建议上线前主动做一次专项评估并留存记录。这份记录在后续问询中的价值，远高于事后的任何解释。以上分析基于公开信息与现行规范，具体产品的合规架构建议结合技术方案另行评估。

FAQ

问：智能体的行为留痕要留到什么程度才算合规？

答：核心标准是"可还原"，不是"数据量大"。需要能回答四个问题：谁在什么时间发起了什么指令；智能体调用了哪些工具、访问了哪些数据；执行结果是什么；高风险动作是否经过用户确认。形式上可以是结构化日志、会话记录或审计表，重点在完整性与可检索性。建议对涉及资金、对外发送、数据删除三类动作做重点留痕，并明确日志保存期限与访问权限——日志本身含大量敏感信息，无节制地留反而是新的风险点。

问：智能体误操作造成用户损失，产品方能否以"用户指令如此"免责？

答：很难。责任判断看控制力，而产品方决定了智能体能做什么、默认权限多大、异常时是否熔断，这些都是可控范围。以用户指令为由抗辩通常只能减轻责任，难以完全免除。实际降低风险的做法有三条：在用户协议中明确能力边界与使用限制；在产品侧对高风险动作设置确认流程与单笔限额；事件发生后能提供完整执行记录，证明已尽注意义务。

问：只做企业内部使用的智能体，需要办理备案吗？

答：一般不需要办理生成式服务备案，但有两个边界要注意。一是通过接口向外部客户提供能力，即视为对外提供服务，需要按要求履行程序；二是纯内部使用仍受网络安全法、数据安全法、个人信息保护法约束，涉及员工个人信息处理的须履行告知义务。此外，若使用已备案的第三方模型能力，义务并不因此转移——备案主体是服务提供者，使用方仍需对自身场景下的合规负责。