披露与内容来源

把规范写成验收标准，因为"我们披露了"不可测试。

你所受制的每一项披露义务——欧盟《人工智能法案》第 50 条的透明度义务、关于自动化通信的行业规则、平台政策、你自己的承诺——都能归约成一小组可核查的陈述。就那样把它们写下来，写进你的工单系统，否则这项要求会活在一份政策文档里，而不在产品里。

• 谁必须被告知。与系统交互的自然人。不是服务账号，不是另一个智能体，也不是你自己的后端——这听起来理所当然，直到你把拓扑画出来，发现那个人离模型隔着三跳。
• 什么时候。通行标准是最迟在首次交互时，这就排除了把披露放在对话结尾、或藏在一个没人会点的链接后面。落到实践里，这意味着每一个渠道的第一条外发消息都要带着它。
• 以什么形式。对一个通情达理的人来说清晰且可区分，且在他们实际使用的那个渠道里。六号灰字的页脚是给律师看的披露，不是给用户看的。
• 什么被豁免。大多数制度都会把显而易见的情形切出去——对一个具备合理知识的人而言从上下文即可看出的情形，以及通常还有执法用途。不要依赖"显而易见"：你的助手是不是明显是 AI，是一个关于你的用户的问题，而你可以去测它，不必去假定它。
• 义务落在谁身上。提供者与部署者承担的义务不同，而如果你两者都是——你造了它，又为客户运行它——那你两套都担。用问责与角色把这件事映射到具名负责人上，因为"合规部门管这个"正是一个渲染 bug 如何变成一项监管认定的。

在智能体系统里，"首次交互"是一个路由问题。

聊天机器人时代的披露有一个简单答案：用户打开聊天，第一条消息说明这是什么。智能体打破了它，因为模型的输出经常经由某个完全不同的系统抵达一个人，在一个没人挑选过的时刻，落在一个会把你附加的东西剥掉的容器里。

• 把从模型输出到人眼的每一条路径都枚举出来。产品内的聊天，当然——但还有智能体发出的邮件、它写的工单评论、日历邀请、Slack 消息、它生成的 PDF、它拨出的电话、它写的 PR 描述。它们中的每一条，都是一次与可能不同的人的、独立的首次交互。
• 被漏掉的总是那些异步路径。"智能体起草、人来发送"与"智能体来发送"是两种不同的义务。你的产品加上"直接发吧"的那一刻，一项合规属性就悄悄变了，而披露逻辑附近没有一行代码被碰过。
• 收件人不是用户。收到智能体邮件的那个人从没同意过你的条款，也从没看过你的引导流程。他们需要被告知的一切都必须在那条消息里，因为没有别的界面了。
• 语音的预算最紧，而规则最清楚。披露必须落在头几秒里、落在音频里，并且要能扛住一个只听了一半的人——而它还要与轮次接管的预算争抢。机制在外呼语音智能体里已经推演过了；这里的要点是：它是那个最明显必须被设计、而非被追加的渠道。
• 把它做成出口点的属性，而不是智能体的属性。持久的实现是一个统一的外发层，所有离开系统的东西都从那里经过，它知道渠道与收件人类别，并附上对应的披露。智能体会忘；一个收口点不会。这与集中化策略执行是同一个论证。

搞清楚哪种标记能跨过哪一道边界。

给合成内容打标记被当成一项要求，实际上是三种持久性差别极大的机制。在它们之间做选择是一个工程决定，而选错会产出一个在内容第一次被复制时就蒸发掉的合规故事。

• 密码学来源清单。C2PA Content Credentials——一份签名清单，记录一件资产由什么产生、此后被什么编辑过；它已被批准为 ISO/IEC 22144，背后的联盟如今囊括了大多数大型模型提供商、平台与相机厂商。在其适用之处它很强：可验证、可察觉篡改、并带有编辑历史。它的弱点在于，它是附着在文件上的元数据，任何不保留它就重新编码的流水线都会把它剥掉——而那是大多数流水线。
• 嵌入式水印。把信号嵌进像素、采样点或令牌选择本身，其中部署最广的是 Google 的 SynthID；它的文本版本已经发表并开源，第三方可以据以构建检测器，而它如今是与 Content Credentials 并行采用、而非彼此竞争的。对图像、音频与视频而言，这一种确实能扛住那些会摧毁元数据的变换——重编码、缩放、截屏。
• 可感知的标签。产物上或界面里那个看得见的"AI 生成"标记。技术上最弱，却是普通人唯一真正体验到的那个。无论如何都要发它：它履行了另外两者都不履行的、面向用户的那一半义务。
• 文本是难的那一类，而你应该在内部把这句话说出来。文本水印靠偏置令牌选择来工作，所以它的可检出性随长度、以及随模型当时有多大自由度而变。短输出携带的信号太少，而改写、翻译、或把文本过一遍另一个模型都会让它衰减。在你的提供商提供它的地方，水印值得开启；但它不是一件值得拿来搭建合规论证的东西。
• 检测的不对称性是那个陷阱。没有标记什么也证明不了——既不证明内容出自人手，也不证明它来自别处。任何把"未检出水印"当成一项认定的流程，都会产出错误的指控，而那正是内容审核里要避免的那个具体伤害。

对文本而言，站得住的产物是你这一侧的一份记录。

既然没有标记能可靠地在短文本上存活，诚实的立场就是：别再试图从产物本身证明来源，转而让自己能从自己的系统里证明它。这是一个记录问题，而你已经拥有它所需的大部分机器了。

• 记录你生成了什么、什么时候、为谁、用哪个模型与提示词版本。一份内容级的来源记录，与产生它的那次运行相连。当有人在六个月后问某个段落是不是出自你的系统时，是它回答了这个问题，而水印回答不了。
• 对输出做哈希并保留哈希值。它把"这是不是我们写的"从一场争论变成一次查表，而且它能在文本被重新排版之后存活——那是水印做不到的。
• 复用你为审计已经建好的那条轨迹。审计轨迹与决策回执里描述的那些运行记录，只要你把输出标识加进去，就能承载这件事。在这里最常见的浪费，是再建一个平行的来源存储。
• 留存期限按义务定，不按存储账单定。一份在投诉窗口关闭之前就过期的来源记录，是一份你付了钱又用不上的记录。从数据治理拿到那个期限，并把它写明。
• 在记录里区分"生成"与"辅助"。完全合成的输出、被模型编辑过的人类文本、以及模型只审阅过的人类文本，是三件不同的事，对应三个不同的披露答案，而只有你的系统知道发生的是哪一件。在写入时就把它记下来；事后是推断不出来的。

智能体之间：披露必须被传递下去，而没有协议替你做。

有意思的新情形，恰恰是规则起草时没有围绕它设想过的那一种。你的智能体调用了合作伙伴的智能体，后者产出的内容最终被合作伙伴那边的一个人读到。义务附着在那个人身上，离你隔着好几个系统，而当前互操作层里没有任何东西会跨过这一跳携带"这段内容是合成的"这一事实。

• 把来源当作载荷契约的一部分。如果你与另一个系统交换生成内容，就约定一个说明此事的字段并一路带下去。这对一个工具 schema 只是很小的增加，而它是唯一能让接收方系统去履行它自己那份义务的东西。
• 智能体身份是相邻的，但不够。Agent Card 与发现层说明的是谁在调用——见Agent Card 与发现与 A2A 深入解析——但把调用方标识为智能体，并不等同于把它返回的内容标记为生成物。
• 作为接收方，也要决定你的姿态。当内容从另一个智能体那里抵达时，你是记录它的来源、把它传下去，还是丢掉？丢掉是默认行为，而这正是一条智能体链如何把合成内容洗成看起来像有人撰写的东西。
• 不要让中间的那个人抹掉记录。如果一个人审阅并转发了模型生成的文本，披露问题并没有消失——它变了。你的记录应当区分"由智能体发送"与"经具名人类批准后发送"，因为那正是将来会被追问的那个区分。

像验证一个功能那样验证它，因为它也像功能那样会回归。

披露被实现一次，然后无声地坏掉，通常坏在一次改版、一个新渠道，或一次由完全不知道那个字符串很吃重的人做出的模板改动上。它需要的是 CI 里的测试，不是一年一次的复查。

• 每条出口路径一条自动化检查。对你在第 2 步枚举出的每一个渠道，一条断言首条外发消息中存在披露的测试。这是这一页上性价比最高的控制措施，而它是一天的工作量。
• 断言标记能扛过你自己的流水线。生成一张图片，让它走完你的缩放、存储与 CDN 路径，再验证凭证在另一端仍然可读。大多数团队会发现自己的缩略图服务把它剥掉了——在上线之后。
• 测理解度，而不是测存在性。把界面给没见过它的人看，问他们觉得自己在跟什么说话。"对通情达理的人清晰"是一个用户研究问题，答案很便宜，而它正是你将被据以衡量的那条标准。更宽的论述在透明与可解释。
• 把"这会不会新增一条通往人的路径？"加进你的上线检查清单。新渠道、新集成、新的外发自动化——每一个都会把第 2 步的所有问题重问一遍，而检查清单就是它被抓住的地方。
• 维护一份"你标记了什么、怎么标记的"登记表。一张表：内容类型、渠道、披露机制、标记机制、负责人、上次验证时间。它是你会被要求拿出来的那份文档，而维护它的过程会浮出那些没人记得的路径。

相关：智能体 vs 聊天机器人讲这条边界最初为什么挪了位置，治理落地讲它如何与项目其余部分并存。