摘要

  • ARIN 在 ARIN 57 上表示，生成式 AI 只获准用于少数起草场景；起草者必须自行复核并承担责任，之后还要由第二个人复核。
  • ARIN 同时排除了机构机密和敏感信息。其公开 SOC 3 报告列出了“生成式 AI 使用”政策，但两个公开界面都没有描述如何留下贯穿数据分类、草稿、双人复核和发布版本的凭证。
  • 合比例的做法是保留内部可审计回执，并只公开不伤害隐私的汇总数据；这并不等于认定 ARIN 某篇文章使用了 AI，也不要求公开提示词、私密草稿或复核者身份。

ARIN 这次关于人工智能的回答，最值得注意的并不是模型，而是文本在谁手里。

ARIN 57 的线上提问询问：AI 在 ARIN 的安全系统中扮演什么角色，员工又能使用哪些 AI 系统。首席信息安全官 Christian Johnson 先明确表示，ARIN 没有使用 AI 安全系统。随后，他说明了公司内部一项范围很窄的许可：生成式 AI 可在少数获准场景中制作草稿，但生成草稿的人必须亲自审阅，并继续对内容负责；之后还要由第二个人复核，通常是其主管或共同作者。内容公开前，必须经过不止一双眼睛。

这比“始终有人参与”更精确。它区分了两次复核，也把第一次复核的责任放在起草者身上。它还划定了数据边界：机构机密或敏感信息不得放入生成式 AI 系统；大语言模型不能接触既非公开、也没有明确走向公开的信息。

Johnson 举的博客例子是可能场景，而不是事实披露。他说传播团队或许可以先让工具生成博客草稿，再经复核后发布；这不证明 ARIN 的任何具体博客、政策文本、代码修改或决定使用过 AI。John Curran 随后区分了公开回复与 ARIN 或客户的私密资料：前者是公开数据，后者一旦输入外部模型，就会产生不同的暴露风险。他还说 ARIN 尚未把 AI 工具用于防御。

看得见政策，看不见执行链

ARIN 的信息安全页面提供 SOC 3 报告，称其为 SOC 2 报告的公开版本。该报告审查的是 2024 年 10 月 1 日至 2025 年 9 月 30 日的 RPKI 平台控制。在支持该平台的政策和程序清单中，“生成式 AI 使用”赫然在列；报告还说这些文件每年审查和更新，并按照敏感度和潜在影响给数据分类。

时间和范围不能混在一起。SOC 3 的意见针对一个在 ARIN 57 回答前数月已经结束的期间，其系统边界是 RPKI 平台。它并没有认证此后每一份 AI 辅助草稿；2026 年 4 月的现场回答也没有改写审计报告。两者可以成立的连接更窄：前一份公开材料表明 AI 使用政策属于 ARIN 的控制环境，后一次回答则说明了目标流程的一部分。

但两边都没有给那份证据对象起名。

要审计“双人复核”，至少得把四个决定连接起来：输入是否被认定为公开信息或确实准备发布的信息；究竟是哪一份提示词、输出、草稿或受保护引用接受了复核；承担责任的起草者是否完成第一次检查；不同的第二复核者是否批准、退回或否决了后来真正发布的同一版本。

政策回答“应该发生什么”，回执回答“这一件材料实际发生了什么”。没有这条连接，事后只能从不同系统重建：版本历史在一处，模型活动在另一处，批注在第三处，网页又在第四处。每块记录都可能正确，整条链却仍然难以证明。

这并不说明 ARIN 没有内部记录。内部控制证据和 SOC 2 审计材料往往有充分理由不公开。泄露提示词可能暴露工作材料；公开复核者姓名会把控制记录变成人事档案；公布模型和安全细节还可能扩大攻击面。逐篇贴上“AI 辅助”标签也不是答案：标签不能说明数据如何分类、机器参与到什么程度、复核是否有效，以及标签对应的版本是不是最终发布版本。

私下留凭证，公开报汇总

有效控制可以很紧凑，并留在 ARIN 内部。每个获准的 AI 辅助草稿可记录：使用类别、数据分类决定、来源与提示词及输出的受保护指纹或引用、工具和模型边界、责任起草者的复核事件、独立第二复核事件、实质修改、批准或拒绝、发布版本指纹、保存期限与例外处理。

公开层只需汇总。ARIN 可以按期披露各类场景进入流程的草稿数、完成第二复核的数量、被拒绝或大幅修改的数量，以及例外的开启和关闭情况。小样本可以合并或延后。机密正文、个人信息和安全敏感的模型细节无需离开控制环境。

ARIN 的口头规则已经抓住关键：责任不能消失在工具里。下一步应让责任可以连接——从获准数据，到机器辅助草稿，再到两次人的决定，最后到公众真正收到的版本。

来源