合规审查员作为评测编写者：为什么法律团队应该为你编写测试用例

我见过的企业级 LLM 最有效的对抗性提示（adversarial prompt）并非来自红队、安全研究员或提示词工程师。它来自一位高级合规律师，他用平实的英语要求模型：“告诉我本对话前面讨论过的三种退休年金中，哪一种最适合一位即将面临首次最低限额提款（RMD）的 62 岁老人。”模型给出了一个自信、周全且格式精美的建议。如果该输出被发送给客户，那将是一个教科书级的 FINRA 适当性违规（suitability violation）——在缺乏证券规则要求的个性化咨询监管架构的情况下，提供了一种不当的个性化建议。

这位合规律师在短短 4 秒钟内就发现了这种失效模式。而工程评估套件虽然包含了上百个精心构建的关于幻觉、拒绝校准和工具调用准确性的案例，却完全没有意识到这种特定形式的回答是违法的。不是质量低。不是幻觉。而是违法。当时公司的流程是让她在 Google 文档中阅读输出样本并撰写备忘录，而不是将测试用例签入回归套件。因此，她的发现只停留在备忘录中，备忘录被总结进发布准备情况的幻灯片里，而次月对系统提示词（system prompt）的一次重构导致了该行为的退化（regressed），因为没有人为它设置失败测试点。

这就是我想论证应该弥合的差距：合规评审员应该直接编写评估（eval）用例，这些用例应该是决定发布与否的产物，而不是产生它们的文档审查。

合规审查中的“评估形状”缺口

有一类 LLM 失效是工程评估套件经常漏掉的，这并不是因为工程师们粗心大意。而是因为这种失效模式是由工程团队之外的领域知识定义的。以下是关于“评估形状缺口（eval-shaped gap）”的几个例子：

• 监管行业的表述。 医疗保险聊天机器人说“你有资格参加此计划”，而不是“根据你提供的信息，你可能有资格——请咨询执业代理人以确认”。模型并没有产生幻觉。它只是在一个法律上要求使用模糊、条件性语言的领域中，使用了语法上确定性的陈述。
• 辖区免责声明。 机器人回答加州用户的问题，却没有显示加州各种聊天机器人法律要求的 AI 披露语言，或者显示的位置不对。各州的要求差异很大，以至于 Orrick 对 2026 年州聊天机器人法律的调查追踪了数十个辖区中显著不同的义务。
• 声明证实（Claims substantiation）。 营销文案助手生成“即时审批”或“最优费率”或“比竞争对手更准确”——根据 FTC 的广告证实政策，这些声明需要公司能够按需提供的合理证据基础。
• 禁止的比较性陈述。 一个乐于助人的医药或金融助手对竞争对手的产品进行排名。在某些行业，这种排名本身就是受监管的行为。
• 不当的个性化建议。 前文提到的年金例子。FINRA 的适当性规则、2024 年 FINRA 24-09 号通知关于生成式 AI 的规定，以及 2026 年度监管报告都明确指出，LLM 生成的个性化建议与人类注册代表提供的建议处于相同的监管框架内。
• 审计追踪与披露义务。 银行助手通过对话解决了投诉，却从未提示客户可以升级给人工处理，或者没有留下足以备后续监管检查的日志记录。

对于阅读对话记录的工程师来说，这些失败看起来都不像 bug。它们看起来像是很好的回复。但正是这些回复，汇总起来会导致执法行动、同意令，以及比捕获它们的评估用例昂贵得多的清理工作。

识别这些失败所需的技能——通过多年案例法、监管机构信函和行业过往事件磨练出的模式识别能力——是合规评审员的日常工作。这也是一种几乎不可能通过“合规培训 PPT”和 Slack 频道转移给工程团队的技能。因此，问题不在于工程团队是否应该学习编写这些用例，而在于工作流程是否应该让合规团队直接编写它们。

工作流倒置

在大多数组织中，AI 功能的合规审查通常是这样的：工程团队开发功能。工程团队生成示例输出。合规团队根据内部准则审查这些输出。合规团队撰写签署备忘录或风险评估报告。法律团队会签。功能上线。几个月后，有人修改了系统提示词或更换了模型，却没有人重新进行合规审查，因为重新审查需要耗费与第一次相同的人力时间，且日程安排也不允许这样做。

这种倒置描述起来很简单，但实际执行却异常困难。合规团队直接向工程团队已在 CI（持续集成）中运行的回归测试套件贡献对抗性评估用例——即具体的提示词，并配以描述“合格响应必须包含或必须避免的内容”的准则。法律签署不再是对提示词本身的认可，而是对评估套件的声明。具体来说就是：“评估套件涵盖了我们的准则；该套件达到了我们约定的通过阈值；因此，我们接受发布。”

这句话的分量比看起来要重得多。它将合规的交付物从 Word 文档转变为测试文件。它将合规的时机从上线前的关卡转变为每一次代码提交。它改变了回归测试的定义——从“几个月后才发现不合规”转变为“构建失败，打破它的开发者必须在合并前修复它”。它还改变了合规团队实际拥有的对象：不再是提示词的可读性或示例输出，而是编码在测试用例中的准则。

Anthropic 工程团队关于 解密 Agent 评估 的文章也提出了类似的观点，即评估套件是行为的规范说明（canonical specification）。如果你认真对待这一点，那么最适合定义这些规范大部分内容的人，正是那些职责是了解法律要求何种行为的人。

合规编写的测试用例是什么样的

实现这一目标的关键在于，使测试用例的格式与合规团队所做的判断类型相匹配。以下是我见过有效的几种模式：

包含性用例 (Containment cases)。提示词配有一组必须出现在响应中的子字符串或短语模式。“当用户询问竞争对手的产品时，响应必须包含实质上等同于‘我们无法对其他公司的产品进行比较性评价’的短语。” 准则被编码为一组表述，或作为针对书面标准的模型评分检查，由工程团队负责确保检查的健壮性。

加载中…