摘要

  • IETF 于 9 月 27 日通告 Andreas Ehstand 的第一版个人互联网草案，讨论自动化及代理系统中“人类监督行为”的用语。它没有获得 IETF 背书，也未规定审计格式、协议或合格门槛。
  • 草案将观察、针对明确属性的核查、选择行动方案的决策，以及基于既有权限的授权放行分开。放行属于一种决策，却不能替代核查。
  • 没有区分行为种类的“批准”记录，只能证明系统记下了一次交互。要同时证明“某项属性被检查”与“某项行动获准”，须分别寻找这两种行为的证据。

假设软件代理拟好一笔付款，人打开审核页，按下确认，系统写入“人工批准”。这并非已发生的事件，而是检验记录含义的简单例子。人可能只看到了页面，也可能核对过收款方；可能决定退回付款，也可能在自己的授权额度内将它放行。若日志只留下一个通用标记，事后读者不能从这个标记推回任何一种较强的解释。

draft-ehstand-oversight-acts-00 要解决的正是词语被混用的问题。IETF 通告显示其发布日期为 9 月 27 日、作者为 Andreas Ehstand；Datatracker 将其列为正在生效的个人互联网草案，明确提示它并非 IETF 认可的正式标准工作。文件只提出术语，不设计协议、数据格式、操作程序或测量办法。把它写成已经实施的监督规范，会颠倒提案与现实的关系。

文本首先约束“观察”：被监督对象呈现在人面前，只说明对象曾被展示，不能证明人理解了内容。“核查”则必须先有一个明确属性，例如付款对象是否与订单一致；结果可以是符合、不符合，或无法判定。即便这一项查过了，也不能因此声称整个付款无误。“决策”回答采取哪种处置，本身不暗示事前做过核查。“授权放行”进一步要求决策者在作出该行为以前，已经拥有覆盖相应行动的权限；点击按钮不会凭空创造该权限。记录若没有指明权限来源和放行范围，其证明力便受到限制。

这套区分对审计链有实际影响。草案指出，若使用记录的人同时需要知道某个属性被检查、行动也获得许可，便需要一份核查记录与一份放行记录。多次观察不会累计成核查，多次放行也不会证明结果正确。给一条含糊记录加上数字签名，能够帮助核实由谁签发，却不能让记录自动涵盖没有发生、没有记清或没有权限支持的行为。W3C 的可验证凭证数据模型也将凭证验证与特定用途的有效性判断分开；这里提到它只是解释证据边界，不表示 W3C 采纳了这份新草案的术语。

更棘手的是“失效仍显得通过”的核查环节。如果系统在关闭审核页时，无论人有没有真正检查属性，都生成同一个“已核查”标记，那么正常日志就看不出漏查。草案讨论核查环节对错误的可发现性及针对环节的测试，同时不规定怎么造测试样本、测多少次或什么结果算合格。它还提示橡皮图章式批准、对象在审核后被替换、记录夸大行为种类、放行超出原授权等风险；另一方面，对人的每次浏览行为留痕，也可能变成监督员工的工具，却未必增加对代理输出的认识。

因此，治理问题不是在流程图里画出一个“人工参与”方框，而是分别回答：人面对哪个版本的对象、核查了哪个属性、选择了何种处置、依靠哪项事先授予的权限放行。以上是 Daniel Kade 根据一份个人提案作出的编辑分析，不是 IETF 对现有产品的裁定，更不是某个运营者已失职的证据。Heng Lu 关于不要把形式参与自动写成代表性授权的提醒，适用于阅读这种日志；但要判断具体行为，仍须回到具体证据。

来源