Summary

  • XXX 或 REDACTED 只是正文里的字符，不是机器可验证的结构；原话可能恰好包含同样字符，跨语言后约定还会失效。
  • VCON 核心草案能够关联较少删改的前序版本、约束外部内容哈希并由处理者签名，但这些机制证明的是版本关系、字节完整性与签名者身份，不证明删改完整或替代值真实。
  • 高后果使用者需要独立、可验证的转换凭据和本地动作限制。本文提出的最小凭据是 Daniel Kade 的操作分析，并非 draft-rosenberg-vcon-redaction-00 已经标准化的要求。

可见的标记为什么仍然不可计算

把账号替换成 XXX，对阅读者似乎足够清楚：这里有内容被遮掉了。但这份“清楚”只存在于约定里。说话者可能真的读出了产品代码 XXX；转写程序可能本来就用这个词表示无法辨认的声音；换一种语言，REDACTED 甚至不再像提示词。

因此，正文中的标记无法可靠回答三个问题：哪一段是源内容，哪一段是隐私处理的结果，处理范围究竟到哪里。若系统为了消除痕迹，改成同样格式、同样长度的逼真假账号，表面歧义会消失，事实歧义却更深。后续客服或智能体可能把假账号用于真实退款。

2026 年 9 月 29 日发布的 draft-rosenberg-vcon-redaction-00 把这类问题拆成可讨论的属性。它是一份个人提交、拟定状态为 Informational 的 Internet-Draft，内容是用例与要求讨论。它不是 RFC，不是 VCON 工作组已采纳文本，不代表 IETF 共识，也没有证明任何生产部署。

草案区分删改是否明确告知软件、是否暴露受影响位置、是否暴露相关参与者，以及编辑对人或模型是否可察觉。它也区分真正移除内容和仅给内容打标签、交由受信接收方控制显示。四组属性彼此独立：保留时间位置可能泄露证人出现；隐藏参与者可能破坏责任归属；不可察觉的替换可能最有利于保密，却最容易诱发错误动作。

VCON 已有的是版本承诺

VCON 核心草案第 04 版定义了 redacted 对象。删改后的 VCON 应通过 UUID 指向未删改或删改较少的前序版本；也可以包含受限 URL 和内容哈希，而 URL 一旦存在，哈希就必须存在。生成衍生版本的实体应为其签名。数组成员若被彻底移除，核心草案建议留下空占位，避免后续索引移动。

这些规定解决了真实问题。UUID 建立版本关系，哈希约束外部内容字节，签名说明谁对这个衍生结果作出声明，占位符保持内部引用稳定。

但核心草案明确不规定文本、音频和视频的具体删改方法。签名只能说明某把密钥签过这些字节，不能说明检测器找到了所有个人信息，不能说明保留字段仍然准确，也不能让合成语音或假账号成为原始观察。占位符本身还可能泄露被移除内容的位置。

这正是“现实层”不能混合的地方。源对话是一层；面向某种披露目的生成的隐私视图是另一层；处理者关于操作的声明是第三层；后续付款或账号变更又是一层。可验证的联系很重要，但联系不等于继承权威。

五种处理方式交换了不同证据

删除整个 dialog 对象，能彻底带走其中的敏感值，也可能带走客户投诉、请求理由和代理回应。数组索引会移动，旧引用可能落在错误对象上。剩余记录不一定让人看出中间缺过一轮对话。

保留 dialog 壳层，可以保留参与者、开始时间、持续时间和索引。审计者知道这里发生过交互，却看不到一个混合语句中的非敏感事实。若保护目标正是证人身份，壳层保留的参与者信息反而构成泄露。

用 XXX 或 REDACTED 作可见替换，至少提醒许多人“这里变过”，但无法给软件提供精确位置、数据类型或操作语义。原文与标记发生字面碰撞时，任何猜测都不安全。

用逼真值替换，消除了醒目的编辑痕迹，却制造了可操作的假事实。草案用退款场景说明：假账号若被后续代理当真，保护原账号的动作会把钱送错地方。隐私强度与证据安全从来不是同一根刻度。

打标签则保留原值，要求接收方根据权限隐藏。它更能保存证据，也把风险转移到每个查看器、导出器和转发者。只要一个消费者忽略标签，敏感信息就仍然暴露。

转换凭据至少要回答什么

对于能够触发付款、凭证变化、法律归因或模型训练的衍生记录，本文主张附带独立签名的转换凭据。这里列出的字段是操作分析，不是第 00 版草案已经规定的完整格式。

凭据首先承诺源 VCON 和衍生 VCON 的标识与哈希，写明策略版本和处理目的。每个受影响位置都要有机器可读定位、处理前的数据或语义类别，以及操作类别：移除、保留壳层、可见替换、逼真替换、标签或加密。

它还要说明位置和参与者身份是有意保留还是压低；记录处理者、签名密钥适用范围与处理时间；逐一保存定位验证结果，并对任何无法解析的位置关闭使用。最后必须把消费者限制写成机器可执行条件：逼真替代值不得直接用于付款、账号或凭证修改、法律认定和未区分来源的训练。

RFC 6901 的 JSON Pointer 可以指向精确位置，但把错误处理留给应用；定位失效不能当成普通警告。RFC 7515 的 JWS 可以保护声明完整性，RFC 8785 能让 JSON 规范化后重复计算承诺。它们都不能证明处理者发现了全部敏感项。覆盖率测试、受控抽样和文本—音频—视频一致性核对仍然是独立证据。

面向智能体会话的相关草案使这条边界更紧迫。提示词、工具输入输出、文件内容、凭证和可执行命令都可能进入对话记录。可验证智能体对话草案也明确指出：有效签名识别签名者，但不保证内容真实；运行时、记录器、存储、验证者和决策者处在不同信任边界。

所以后续动作也应留下单独凭据，关联衍生版本承诺、转换凭据、本地规则和最终效果。调查时才能分别回答：源里有什么，处理者改了什么，消费者获准相信什么，以及动作负责人实际做了什么。

来源与限制

第 00 版仍是早期讨论文本，存在未定的结构与错误处理问题。本文没有评测任何联络中心、模型厂商、删改产品或 VCON 实现，也不判定某种处理在具体司法辖区是否合法。GDPR 第 5 条与 NIST SP 800-122 提供了数据最小化、准确性和保护义务的背景，但不为本文提出的凭据背书。