录音本来只有一份。语音智能体做出了六份。
你的同意提示、你的留存规则、你的删除任务，全都指向那份通话录音，而录音如今已是这段对话里最不值一提的副本：同样的六十秒还以 ASR 转写稿的形式存在，以模型上下文窗口的形式存在，以你传给某个工具的参数的形式存在，以追踪服务里的一条 span 的形式存在，还以写进 CRM 的一段摘要的形式存在。这六份里有五份是智能体造出来的，一条策略都没继承到。把同意状态机和脱敏边界建在每一个落地点前面，否则你治理的只是一件产物，泄漏的是另外五件。
在写下任何一条规则之前，先把副本清点出来。
人工呼叫中心每通电话产出一件持久产物，并且有一条写明白了的删除路径。语音智能体则把同一段音频扇出到一堆系统里——它们分别采购、按不同的时钟留存，有几个还由不同的厂商运营。
- 音频——你现有策略唯一点到名的那份副本，通常也是唯一有人真去删的那份。
- 转写稿——由你的 ASR 厂商产出，往往他们那边也留一份，而且比音频好搜索得多——而这恰恰是它更糟糕的原因。
- 模型上下文——每一轮都要发出去的滚动转写，它可能被你的推理厂商记录下来，依据的留存协议与你采购团队读过的那份并不是同一份。
- 工具参数——你传进查询调用里的出生日期、账号、地址。它们落进了没人把它归类为「通话数据」的应用日志里。
- 追踪数据——可观测性厂商那里的 span、提示词与补全，留存时长的默认值是按调试方便挑的。见轨迹采样与留存。
- 回写——智能体填进 CRM 的处置码、摘要与备注，往后好几年都会被从没听过这通电话的人读到。那件产物有它自己的失效模式。
把清点做成一页表：一个落地点一行，列出谁在运营它、它的留存期是多久、哪个删除任务能够到它。多数团队第一遍就会发现有三个落地点在第三列上答不出来——这就是结论：你没法对一个你都不知道它存着数据的系统履行删除请求。
披露是智能体必须持有的一种状态，不是它开头说一次的一句话。
自 2026 年 8 月 2 日起，欧盟《AI 法案》第 50 条的透明度义务已直接适用于与人交互的系统，而 AI 语音智能体正是那个标志性的例子：除非从上下文中显而易见，来电者必须知道自己在跟 AI 讲话，背后是最高 1500 万欧元或全球营业额 3% 的敞口。该义务同样适用于已经投放市场的系统，所以没有什么过渡期可以等。
工程上的后果是：「我们在问候语里说了」是一个不完整的实现，因为一通电话的入口远不止问候语一个。
- 双向的热转接。从人工转给智能体的来电者，从来没听到过那段问候语。从智能体转给人工的来电者，则应当被告知交接发生了；两条路径都属于转接设计的一部分。
- 回拨与外呼。一通外呼面对的是一个毫无上下文的来电者，而这句披露要跟「人们会挂断电话的头三秒」抢时间。
- 抢话打断。打断问候语的来电者没听到它的后半句。如果你的披露藏在一句能被盖过去的话里，它就没有被可靠地送达——把标记放在会话上，并在第一个实质性回合上重申。
- 被直接问到时。「我是在跟机器人说话吗？」应当触发一条硬编码路径给出的、真实且不含糊的回答，而不是模型当下想生成什么就生成什么。
把它当会话状态来跟踪——disclosure_delivered_at，连同送达它的那个界面——并写进与同意记录同一条记录里。监管方要问的不是「脚本里写了什么」，而是「证明它在这通电话上发生过」。
同意管着录音缓冲区，而缓冲区通常开得太早。
美国有十二个州——加利福尼亚、康涅狄格、特拉华、佛罗里达、伊利诺伊、马里兰、马萨诸塞、蒙大拿、新罕布什尔、俄勒冈、宾夕法尼亚、华盛顿——要求录音需经全体当事人同意；其余各州遵循联邦的单方同意标准。这一点广为人知。实践中出问题的是顺序：媒体流通常在通话接通的那一瞬就开始流动，录音器也在同一刻挂上去，而同意在四秒之后才到。那四秒是一段未经同意的录音，而它存在于上面六个落地点的每一个里。
- 让录音器挂在同意事件上，而不是挂在呼叫建立上。如果你的平台做不到，就先在内存里缓冲、拒绝时丢弃——但要清楚，一段你从不落盘的缓冲仍然是一份副本，在评估文档里就该这么写，而不是假装它不存在。
- 不要拿电话号码去判定司法辖区。区号已经十年说明不了一个人此刻站在哪里了。按「可能适用的最严格规则」来判定，实践中就意味着到处默认按全体同意来做，并把单方同意州当成一项你多半并不需要的优化。
- 拒绝必须是一条被支持的路径，而不是一个错误。提前决定：智能体是不录音继续、还是转人工、还是结束通话——并且按任务来决定，因为有些任务确实不能在无录音的情况下进行。
- 同意录音不等于同意用于训练。这是两个不同的目的，法律依据也越来越分开。如果你的评测集是从生产通话里搭出来的，那份许可是它自己的一条记录；你从中构建评测语料时也要守同样的规矩。
把同意决定作为结构化数据存在会话上——时间戳、话术版本、来电者的回应、以及所适用的辖区规则——并把它盖到每一件派生产物上。一份无法自证其同意来源的转写稿，终有一天会被你的法务要求批量删除，而批量删除正是好数据一起陪葬的方式。
卡片数据根本就不该抵达智能体这条腿。
这是唯一一处事后脱敏根本不成立的地方，也是语音智能体版本确实比人工版本更难的地方。在 PCI DSS v4.0.1 之下，呼叫中心一直依赖的人工「暂停—恢复」录音，充其量被视作一项部分控制措施，因为它依赖有人记得去按：标准要求持卡人数据被自动且可预期地排除在范围之外。能通过评估的架构，是把这些数字完全挡在智能体这条腿、录音和坐席桌面之外——用 DTMF 掩码（来电者按键输入号码，按键音被拦截并替换成一个安抚音），或者交接给智能体根本看不到的 IVR 或支付链接。
由大模型驱动的智能体还多出两个人工坐席没有的麻烦。
- 模型没法「不看」。人工坐席可以被训练成把视线从屏幕上移开。而在智能体这条腿上说出来的任何东西，按定义就已经在上下文窗口里了，从那里它又进了厂商的请求负载、你的追踪数据，甚至可能进了某个提示词缓存前缀。这里没有「把眼睛挪开」这一说。
- 来电者会主动报出来。人们会在没人问的时候、在半句话中间、在任何支付流程开始之前，就把卡号念出来。你需要的是入向音频路径上一个能抑制并丢弃的探测器，而不是提示词里一条请求模型忽略它已经收到的东西的规则——这正是提示词层面的规则不该承载任何要紧边界的原因。
把这个模式推广到卡片之外。健康信息、政府证件号、完整出生日期，都值得问同一个问题：这个值需要抵达模型才能完成任务，还是只需要抵达某个工具？只需要抵达工具的，就在模型观察不到的通道里采集，然后传一个引用过去。
一个脱敏服务，摆在每一个落地点前面，在写入时生效。
常见的失败是按落地点各做各的脱敏：ASR 流水线里一个清洗器，日志库里另一套正则，追踪 SDK 上什么都没有。现在你有三个探测器，对「什么是电话号码」有三种不同的定义，而你的合规姿态取决于其中最弱的那个。
- 在写路径上脱敏，而不是在读路径上。在已存的原始数据之上盖一层遮罩视图，能防住的只有一名好奇的员工，此外什么都防不住——防不住备份、防不住入侵、防不住传票、也防不住厂商自己的留存。
- 只跑一个探测器，并且给它打版本。探测器改进之后，你需要知道哪些产物是在旧版本下写出来的。把探测器版本和同意记录盖在一起。
- 脱敏是有损的，这是特性，所以要有意识地规划那个可逆的情形。如果争议处理需要原文，答案是一个访问严格受控、自带审计轨迹的保险库——而不是「我们把原始副本留在追踪数据里，以防万一」。
- 在生成摘要之前脱敏，而不是之后。智能体自己的回写会把你擦掉的东西重建出来：「来电者确认了后四位」没问题，而一段热心地把完整号码复述一遍的摘要，就是这份数据在一个你从未分类过的系统里的新副本。
- 量一量漏检率。抽样已脱敏的转写稿，让人去核，然后把这个数字公布出来。一个从没人量过的探测器，就是一个所有人都默认它完美的探测器。
用一次演练证明删除真的够到了这六份。
上面每一项控制都是一个关于未来的承诺。要知道它是否成立，唯一的办法是拿一通真实通话端到端地演一遍，赶在外部有人来要求你之前。
- 每季度做一次删除演练。打一通电话、记下 session id、等一天，然后发起一次删除请求并逐一核验那六个落地点。给它计时。你量到的这个数字，就是客户问起时你诚实的答案，而它通常比策略文档里写的糟糕得多。
- 点名那些由厂商掌控的落地点。ASR 厂商、推理厂商、可观测性平台，各有各的留存期，也各有各的删除 API——或者压根没有。这是一个采购问题，但答案在工程这边，它属于第三方与厂商风险。
- 把删除与法律保全对齐。这两项义务在设计上就是冲突的，而冲突必须由一条写明白的规则来裁决，而不是由「哪个任务先跑」来裁决——见留存与法律保全。
- 别忘了记忆。如果智能体会跨通话做个性化，来电者的数据同样躺在一个任何录音留存策略都不曾提及的记忆存储里；针对智能体记忆的删除确实是另一个独立的问题。
这一周就从这里开始：挑一通上个月的真实通话，把它的每一份副本实地找出来。不是找架构图——是找到真正的那些行、对象和 span。做过这个练习的团队，通常会翻出两个被自己忘掉的落地点，和一个留存默认值从来不是他们挑的厂商，而这份清单比你能写出来的任何一份策略文档都更适合当第一个冲刺的内容。
延伸：来电者认证讲电话线路上信任问题的另一半，数据治理讲这一切所依托的分类，面向智能体的欧盟 AI 法案讲披露之外的那些义务。