第 2 章 控制设计与运行有效性

学习目标

  • 区分控制的设计有效性与运行有效性,并选择相应的评估程序。
  • 判定所发现的问题适用于设计缺陷还是运行缺陷。
  • 选择能够甄别人工复核控制具备实质效力还是流于形式化审批的测试。
  • 将 AI 系统中访问管理与变更管理的对象扩展至模型、判定标准、提示词及知识文档并进行检查。
  • 研读供应商合同与服务机构报告,查明公司需要另行核实的事项。

引言

某保险公司的理赔主管自信地对审计团队说:“AI 计算出的金额全部由经办人员核对后予以确定。最终由人来决定,所以没有问题。”规程上也是这样写的,而且确认按钮只有经办人员才能点击。然而,当审计团队调取系统记录后发现,上个季度经办人员在 1,000 笔业务中修改 AI 金额的仅有 3 笔,平均每笔处理时间为 20 秒。

这项控制有效吗?答案是“尚不得而知”。规程和确认按钮仅仅能证明控制是如此设计的,却不能证明控制在相关期间内实际运行了。而且,较低的修改比例本身也说明不了任何问题。如果 AI 几乎没有出错,自然无需修改;而如果 AI 频繁出错,则说明经办人员放过了这些错误。要区分这两者,还需要更多的证据。评估控制正是始于将“存在控制”与“控制正在运行”区分开来并分别审视。

本章首先区分控制评估的两大支柱——设计与运行,并学习如何判定问题究竟出在哪里。随后,将深入探讨 AI 审计中最常引发争议的人工复核控制与形式化审批,并总结如何结合 AI 系统的特性,对访问管理、变更管理以及供应商管理控制展开审查。

核心概念

控制的种类

控制是防止风险转化为实质后果的机制。PCAOB AS 2201 将控制划分为防止差错或舞弊发生的预防性控制,以及及时发现已发生差错的检查性控制,并指出有效的内部控制通常结合使用这两种控制(AS 2201 .A8)。从执行主体来看,控制又可分为由人执行的人工控制和由系统执行的自动控制。

示例 预防性/检查性 人工/自动
经办人员核对 AI 计算金额后予以确认 预防性 人工
依据输入栏为空时确认按钮不可用 预防性 自动
质量负责人每月对已确认的 50 笔业务进行复审 检查性 人工
错误率超过基准时触发警报 检查性 自动(应对为人工)

这一分类决定了测试方法。对于由人工重复执行的控制,必须在整个期间内抽取样本进行检查;而对于完全自动化的控制,则可以通过审查其配置及其变更管理来高效核实。

设计有效性与运行有效性

设计有效性考察的是,如果控制由具备相应权限和能力的人员按规定执行,是否能够实现控制目标,并防止或发现差错或舞弊(AS 2201 .42)。运行有效性考察的则是,该控制是否实际按照设计运行,以及执行控制的人员是否具备必要的权限和能力(AS 2201 .44)。

打个比方,设计评估就像是检查灭火器是否摆放在正确的位置且型号正确,而运行评估则是检查在过去一年中是否按照检查表核对了压力并进行了更换。如果灭火器放错了地方,那么检查记录再完备也无法扑灭火灾。因此,必须先进行设计评估。IIA 准则同样指出,如果控制未得到恰当设计,全面评估其有效性所耗费的成本往往难以换来相应的效益(IIA 4.2)。

设计缺陷与运行缺陷

AS 2201 对这两种缺陷作出了如下定义(AS 2201 .A3):

  • 设计缺陷:缺少实现控制目标所必需的控制,或者现有的控制即使按照设计运行,也无法实现控制目标。
  • 运行缺陷:设计恰当的控制未按照设计运行,或者执行控制的人员不具备有效执行控制所必需的权限或能力。

在 AI 系统中,这一区分往往比想象中更容易混淆。请看以下示例。

情况 判定 理由
策略仅将模型替换列为审批对象,导致对结果产生重大影响的判定标准变更在未经审批的情况下生效 设计缺陷 即使按策略执行,也无法防范改变结果的变更
策略要求对所有变更进行审批,但部分变更未经审批即被部署 运行缺陷 设计正确但未得到执行
系统允许申请人自行审批本人的变更(职责分离缺陷) 设计缺陷 即使照常运行,也无法实现独立核实
复核经办人员更换为未经培训的新员工 运行缺陷 属于执行人员的能力问题

判定之所以重要,是因为提出的建议截然不同。对于设计缺陷,必须修改策略或系统;而对于运行缺陷,则必须纠正执行过程或更换执行人员。

测试技术与证据强度

测试控制的技术有四种:向经办人员了解情况的询问、察看执行过程的观察、查阅执行记录的文档检查、以及由审计人员独立重新执行控制的重新执行。AS 2201 将这四种技术通常所获取证据的强度由弱到强依次列出,并明确指出仅凭询问无法支持控制有效的结论(AS 2201 .50)。实际证据的强度取决于控制的性质以及所执行程序的组合(.49, .51)。

在设计评估中,结合了询问、观察与文档检查的穿行测试通常是充分的(AS 2201 .43)。虽然根据风险高低及所执行的具体程序,穿行测试有时也能为运行有效性提供充分的证据(.49),但如果风险较高或需要全面审视整个期间的执行情况,则需要进行抽样测试。穿行测试是指自始至终追踪一笔交易的全过程,向经办人员询问,并同步查看实际操作界面与记录的方法。而在运行评估中,则需从整个期间抽取样本进行文档检查或重新执行。测试所覆盖的期间越长,对控制有效性提供的证据就越充分(AS 2201 .52)。

遇到偏差时

样本中出现未执行控制的情况,即存在偏差,并不意味着可以直接得出控制无效的结论。AS 2201 指出,有效的控制也无法提供绝对保证,因此并非只有单项控制在毫无偏差的情况下运行才算有效(AS 2201 .48)。审计人员会将偏差出现的频率与可容忍偏差率进行对比(第 3 章),并评估偏差的原因和性质。因疏忽导致的偏差与蓄意绕过控制,其严重程度截然不同。

反之,也不能因为未造成实际损失就轻视缺陷。AS 2201 说明,缺陷的严重程度并不取决于差错是否实际发生,而是取决于控制未能防止或发现差错的合理可能性及其潜在影响程度(AS 2201 .63–.64)。例如,离职人员账号两周内未被停用但并无登录记录,这一事实可用于评估影响,却无法抹去偏差本身的存在。

人工复核控制应具备的要素

在 AI 系统中,最常见的控制便是“经人工核对后予以确定”。韩国《人工智能基本法》将人工管理与监督列为高影响人工智能提供者的职责(第34条第1款第4项),NIST AI RMF 规定应定义、评估并记录人工监督程序(MAP 3.5),并设立相应的机制与责任,以便在 AI 系统产生非预期结果时能够替换或关停该系统(MANAGE 2.4)。GAO 框架同样要求为了落实问责制而制定人工监督程序(实践 3.9)。

人工复核若要具有实质意义,必须具备以下四项要素:

  1. 权限:复核人员必须能够推翻 AI 的结果。如果仅能留下意见,而 AI 的结果仍被自动优先采纳,则监督便流于形式。
  2. 信息:复核人员必须能够查看做出判断所必需的原始数据以及 AI 做出该判断的依据。
  3. 时间:每笔业务的处理时限目标或队列积压压力不得导致实际判断无法进行。
  4. 能力:复核人员必须具备做出该判断所需的专业知识并接受过相应培训。

如果复核程序从一开始就未赋予推翻权限、未提供原始数据或未给予充足时间,则属于设计缺陷。如果程序制定合理,但实际负责复核的人员不具备必要的权限或能力,则按照 AS 2201 的定义,属于运行缺陷。

形式化审批与自动化偏差

形式化审批(常被称为“橡皮图章”)是指程序上虽有复核,但实际上直接对 AI 结果照单全收的状态。其根源在于自动化偏差。NIST AI 600-1 指出,随着生成式 AI 可靠性的提高,人类可能会过度依赖系统,或将系统结果置于其他信息源之上,而对这类自动化系统的过度依赖可能会放大似是而非的错误回答(confabulation)或偏见等其他风险。

形式化审批的迹象通常如下:

  • 修改或推翻的比例远低于 AI 已知的错误率。
  • 每笔业务的处理时间过短,不足以阅读原始数据。
  • 具备批量审批功能且实际被使用。
  • 推翻结果时被要求填写理由,但在照单全收时却无需留下任何记录。

这些迹象属于“疑点”而非“定论”。资深复核人员亦不例外,因此不能以业务熟练为由将其排除在测试之外。

选择排查形式化复核的测试方法

采用何种测试最为合适,取决于留存了哪些证据、允许进行何种操作,以及审计团队具备何种判断能力。

情况 适用的测试 理由
已知 AI 确实会出错且原始数据已留存 审计人员对已审批业务样本进行重新复核(重新执行) 直接揭示被漏过的错误
做出判断需要专业知识,但系统保留了界面查阅记录 分析是否查阅及查阅时长的日志 从总体中筛选出疑似形式化复核的业务;判断质量由专家重新复核予以补充
AI 出错极少难以发现漏检错误,且允许投入测试用例 掺入不予实际处理的测试用错误业务,检查是否能被过滤筛除 检验复核人员是否具备筛除错误的能力
尚处于运行前阶段且被要求提供设计意见 查阅规程、培训资料与系统界面的穿行测试 属于评估设计有效性的阶段

投入测试用例虽然十分有效,但可能对生产系统造成影响,因此必须先取得公司内部规章的依据以及管理层的共识。重新执行仅在审计团队自身能够做出同等判断时才有意义;若不具备该能力,则应邀请具备资质的专家参与。无论在何种情况下,仅凭访谈即告终结的测试都是不够充分的。

访问控制

AI 系统的访问控制关注的是“谁能够改变结果”。不仅是模型文件与部署配置,生成式 AI 的提示词、判定基准分、检索所用的知识文档、外部工具的连接配置,都会改变最终结果。审计人员应核实以下事项:

  1. 修改权限是否仅授予确有需要的人员(最小权限原则)。
  2. 是否定期复核权限清单。复核时,应将权限清单与人事记录中的在职人员名单进行比对,核对独立数据源。
  3. 员工离职或调岗时,是否在策略规定的期限内收回权限。
  4. 是否保留修改日志,并且是否有人对该日志进行复核。

修改日志属于事后发现的检查性控制。保留日志这一事实并不能替代最小权限等预防性控制。

变更管理控制

传统 IT 审计中的变更管理侧重于程序代码的变更。而在 AI 系统中,变更的范畴更为广泛。模型的重新训练或替换、判定基准分的调整、提示词的修改、知识文档的更新、外部供应商基础模型的更换,都会改变最终结果。若变更管理策略仅将其中一部分列为审批对象,其余部分游离于控制之外,则属于设计缺陷。

测试变更管理控制的常规流程如下:首先从策略中确认属于审批对象的变更事项及有权审批人;接着由审计人员直接从生产系统中提取实际部署日志,与审批记录逐一核对;最后对不一致的情况调查原因。同时,还要核查申请人与审批人是否为同一人,以及经审批的内容与实际部署的内容是否一致。

自动控制与基线策略

诸如“必须输入依据才能点击确认按钮”这类的完全自动控制,通常不会面临因人为失误而失效的风险(AS 2201 .B28)。AS 2201 说明,如果针对程序变更、访问和运行的一般控制是有效的且持续接受测试,并且确认自动控制自建立基线(上次测试)以来未发生变更,则可以得出该自动控制持续有效的结论(.B29)。这被称为基线(标杆)策略。

然而,自动控制的运行可能依赖于相关文件、表格、数据和参数(AS 2201 .B30),且随着时间推移必须重新建立基线(.B33)。对于 AI 系统而言,判定基准分或参考单价表正是此类参数。如果“按钮设置未变,但参考表格发生了变更”,那么控制实质上已经改变了。

供应商管理控制

许多 AI 系统运行在外部供应商的模型或服务之上。即使外包,风险依然留存于公司。NIST AI RMF 规定,应制定应对第三方相关 AI 风险的策略与程序(GOVERN 6.1),针对认定为高风险的第三方数据或 AI 系统的故障制定应急程序(GOVERN 6.2),定期监控第三方资源的风险(MANAGE 3.1),并将用于开发的预训练模型纳入定期监控(MANAGE 3.2)。如果委托处理个人信息,还应结合审查韩国《个人信息保护法》第26条所规定的委托合同文件以及对受托人的监督情况。

在 AI 供应商合同中,审计人员尤其会审查以下条款:

条款 防范的风险
提前通知基础模型及提示词变更并提供变更明细 因未经预告的变更导致结果发生改变的风险
提供变更前后的评估结果及重新评估资料 公司无法对变更进行验证的风险
禁止将客户数据用于目的之外(包括模型训练) 数据被挪作他用的风险
公司的审计及调阅资料权利 无法核实供应商控制的风险
故障与事故通知及应对义务 发现问题出现滞后的风险

安全认证、故障赔偿及保密条款同样重要,但必须明确区分的是,这些条款并不能直接应对未经预告的模型替换及性能下降等 AI 特有风险。

研读服务机构报告

供应商通常会提供由独立审计师出具的服务机构报告。虽然 PCAOB AS 2601 是在财务报表审计中规范此类报告的标准,但研读该报告的原理完全可以借鉴并应用于 AI 厂商所提供的其他鉴证报告。AS 2601 总结的注意事项如下:

  1. **报告的种类。**仅涵盖截至特定基准日控制是否得到设计并付诸实施的报告,虽有助于制定审计计划,但不能作为运行有效性的证据(AS 2601 .12, .37)。只有对期间内的运行有效性进行了测试的报告,才能成为此类证据。
  2. **范围。**报告仅针对所列明的控制目标发表意见,未测试的控制目标则不予发表意见(.44)。例如,仅涵盖访问管理和可用性的报告,对是否被用于模型训练完全未提供任何信息。
  3. **期间。**测试期间越短,或测试后间隔时间越长,报告所能提供的确信程度就越低(.16)。
  4. **互补性用户机构控制(complementary user organization controls)。**若服务机构的控制是以用户机构方面的控制为前提而设计的,报告中会明确披露这些控制(.31, .46)。如果公司未能有效运行这些控制,报告的结论便失去了前提依据。

深入阅读

有意义的人工复核成本

“每笔业务均由人工仔细复核”的设计听起来很安全,但在实际中很容易演变为走形式的审批。如果一名每天需要处理数百笔业务的复核人员每笔只能分配到几秒钟,那么无论操作规程要求什么,复核往往都会倾向于直接顺从AI给出的结果。在这种情况下,审计人员如果仅仅建议“加强复核”,同样的问题只会反复出现。

更好的设计是根据风险对复核进行分流。例如,对金额较大、对客户不利的决定、AI置信度较低的业务由人工深入复核,其余业务则以抽样重新复核等发现性控制来代替。此时,审计人员需要核实三点:分流标准是否与风险紧密挂钩,需要深入复核的业务是否给予了充足的时间和信息,抽样重新复核的结果是否真正推动了标准或模型的改进。减少人工复核这一决定本身属于管理层的风险判断,审计人员关注的是该决定是否在风险容忍度之内,以及该决定由谁批准。

智能体的工具权限与人工审批

AI智能体会直接调用发送邮件、下达订单、修改记录等工具。这意味着访问控制的对象从人员账号扩展到了智能体的权限。OWASP建议,作为提示词注入(用户输入或外部文档中隐藏的指令导致模型偏离预期行为的攻击)的应对措施,应将模型的访问权限限制在预期任务所需的最低限度,对高权限操作设置人工审批,并定期进行将模型视作不可信用户的渗透测试。在指令中写上“严禁泄露个人信息”仅仅是应对措施之一,单凭这一点不能被视为足够安全。

审计人员的问题将转换为与人员账号相同的分析框架:是否具备智能体持有的工具权限清单?该权限是否为业务所需的最低限度?对难以撤回的操作(如转账、删除、对外发送)是否设置了人工审批?智能体的行为记录是否保存在智能体自身无法篡改的地方?最后一个问题将延伸至第3章的日志完整性。

工作场景

一缕保险:修改比例0.6%的含义

财产保险公司“一缕保险”在AI将旅行险理赔申请分为“赔付”与“审核”后,由9名经办人员对“赔付”案件进行核实并确认。在审计团队获取的运行数据中,经办人员将AI的判断转为“审核”的比例为0.6%,每笔业务的核实时间中位数为11秒。理赔部门主管解释称:“这是因为AI十分准确,所以很少需要修改。”

审计团队首先寻找了可以验证该解释是否属实的基准。上线前的验证报告中有一项结果显示,AI判定为“赔付”的案件中约有4%根据条款并不属于赔付对象。如果AI有4%的差错,而人工仅纠正了0.6%,这一差距是显著的。不过,由于模型在上线后可能已经得到改进,审计团队并未将这一差距作为定论,而是将其作为测试的切入点。

围绕测试方法提出了三种方案。经办人员访谈仅凭询问无法得出结论,因此被降为辅助程序。将测试用错误案件混入队列的方案,由于要在生产系统中注入不会实际处理的理赔申请,按照公司内部规定需要信息保护委员会的批准,且在审计周期内难以获批。剩下的只有重新执行。理赔申请原始文件均保存完好,且针对旅行险条款的判断可由未曾参与该产品审核、具有保险从业背景的审计团队成员独立完成。

审计团队从上一季度已确认的2.1万笔“赔付”案件中随机抽取了60笔,依照条款重新进行了判断。其中有2笔本不属于赔付对象,却通过了经办人员的核实。审计团队还一并查看了核实操作界面。界面上醒目展示的只有AI的判断结果和金额,附件材料必须点击单独的标签页才能打开,且界面上还设有“全部确认”按钮。审计团队将结果从两个维度进行了梳理:将这2笔归为运行偏差(结合可容忍偏差率的评估按照第3章的方法进行),并将无需打开材料即可直接确认的界面设计以及批量确认按钮,记录为未能向复核人员提供必要信息的控制设计层面的原因。在报告中,该设计缺陷被列为发现事项的成因,而漏检的2笔案件则作为展现其影响的证据。

杨柳食品:一份供应商报告就足够了吗

食品制造企业“杨柳食品”使用外部供应商的生成式AI服务来摘要合作供应商合同并标注风险条款。当审计团队索取针对供应商控制的证据时,采购团队出示了供应商提供的服务机构报告,并表示“结论是无保留意见,无需另行核查”。

审计团队从三个维度审读了该报告。第一,类型。该报告是对12个月内控制运行有效性进行测试的报告。第二,范围。控制目标为访问管理、变更管理、备份与恢复。审计团队关注的重点之一“合同原文是否会被用于供应商的模型训练”,并未包含在任何控制目标中。第三,用户实体补充控制。报告以“客户单位须在管理控制台中立即停用已离职员工账号”为前提。

审计团队将报告中已验证和未验证的事项整理成表格。变更管理与访问管理采信了报告作为证据,但为了核实补充控制,团队将杨柳食品控制台中的34名用户名单与人事档案进行了比对。结果发现2名离职员工的账号仍处于激活状态,其中一人已离职6周。由于是否用于训练不在报告范围内,审计团队单独核查了合同、数据处理条款以及管理员设置界面。合同中虽然包含禁止用于模型训练的条款,但在管理员设置中,“用于改进服务的数据共享”却处于开启状态。

采购团队虽然寄希望于“无保留意见”的表述,但一旦读懂该意见所针对的具体内容,公司自身必须落实的两件事便显现出来。审计团队将离职员工账号未及时收回列为运行缺陷,将数据共享设置列为与合同约定不符的配置缺陷,分别计入审计发现事项。对于后一事项的成因,记录为缺乏将合同约定的数据条件落实到管理员配置中并进行核验的相关流程。

易错点

  1. “已有操作规程,因此控制是有效的。” 操作规程仅是控制设计的证据。在被审计期间的实际运行情况须通过运行测试来验证。
  2. “最终由人工决策,因此监督已足够充分。” 只有当人员具备推翻结果的权限、信息、时间与能力时,监督才具有实质意义。
  3. “修改比例很低,说明AI很准确。” 修改比例仅代表人工顺从AI结果的程度。只有将其与AI的实际差错率进行对照,才具有实质意义。
  4. “复核时间长即代表复核具有实质性。” 停留在操作界面的时长并不能体现判断质量。需要重新执行等直接证据予以佐证。
  5. “访谈多人即可验证运行有效性。” 仅凭询问无法得出结论,即便增加同类证据的数量,也无法弥补证据质量的不足。
  6. “只要出现一起偏差,控制即告失败。” 应当结合可容忍标准,综合评估偏差的发生频率与产生原因后再行判断。
  7. “既然留有修改记录,权限范围宽一些也无妨。” 操作记录属于发现性控制,不能替代最小权限原则等预防性控制。
  8. “供应商报告为无保留意见,供应商相关风险即已消除。” 只有审读报告的类型、范围、涵盖期间及用户实体补充控制,才能知晓具体核实了哪些内容。

要点速览

主题 核心要点
设计 vs 运行 设计:按规定执行能否达成控制目标(AS 2201 .42)。运行:实际是否照此执行、执行人员是否具备相应权限与能力(.44)
缺陷的认定 缺少控制或照常执行仍无法达成目标属于设计缺陷;设计合理但未执行或能力不足属于运行缺陷(.A3)
测试强度 通常为 询问 < 观察 < 检查记录 < 重新执行。仅凭询问无法得出结论(.50)。实际强度取决于控制与程序本身
设计评估 穿行测试通常足以支持(.43)。若设计存在缺陷,运行测试的价值即大打折扣(IIA 4.2)
偏差与严重程度 存在偏差并不直接等同于控制失败(.48)。严重程度取决于发生错报的合理可能性,而非实际造成的损失(.64)
人工复核 权限、信息、时间与能力。自动化偏差在熟练人员身上同样会发生(AI 600-1)
走过场式复核的测试 根据留存证据、容许范围及审计团队的专业判断能力,采用重新执行、日志分析、测试用例或穿行测试
AI变更的范围 模型、判定标准、指令、知识文档、供应商基础模型
自动化控制 若变更、访问、运行的一般控制有效且持续受到测试,并在控制未发生变更的前提下,可采用基准策略(.B28–.B29)。需密切关注参数变更
服务机构报告 类型(是否仅限设计)、范围(控制目标)、期间、用户实体补充控制(AS 2601)

查阅官方文档

自测

2-1. 不使用灭火器的比喻,以 AI 判定标准的变更审批为例,用两句话说明设计有效性与运行有效性的区别。

2-2. 审核负责人变更为未接受培训的新员工,这种情况属于设计缺陷还是运行缺陷?请以 AS 2201 的定义为依据进行回答。

2-3. 按证明力由弱到强的顺序列出四种控制测试方法,并写出仅靠询问完成的测试为何不能作为得出结论的依据。

2-4. 写出人工审核要具备实质性所需具备的四个要素,并将缺少其中某一要素时表现出的形式化审批信号逐一对应起来。

2-5. 列举在 AI 系统中应纳入变更管理对象的五种变更,并选出在传统 IT 变更管理中容易遗漏的两种。

2-6. 写出收到服务机构报告时应确认的四个事项,并选出其中最常与 AI 固有风险发生冲突的项并说明理由。

2-7. (设计)针对能够向客户发送邮件并执行退款的 AI 智能体,拟定审计人员需要核查的四个访问控制问题。

实操练习

练习

制定人工审核控制测试计划(45分钟)

  1. 选择一项由人工核对 AI 结果的业务(也可以是假想业务)。
  2. 针对权限、信息、时间、能力这四项要素,各写出一行说明其在设计中是如何体现的。
  3. 写出留存的证据(原始数据、界面日志、理由记录)以及允许使用的方法(是否允许投入测试用例)。
  4. 参考本章表格,选择一种运行测试方法和一项辅助程序,并写出弃用的方法及其理由。

完成标准: 写明了四个要素的设计评估,所选测试能够结合留存证据和允许范围得到合理解释,且对弃用的方法有至少一行的理由说明。

练习

制作供应商控制确认表(30分钟)

  1. 选择一项公司正在使用的外部 AI 服务,收集其合同(或公开条款)以及收到的保证材料。
  2. 对照本章供应商合同条款表中的五行内容,逐行写下“有/无/不明确”及依据语句。
  3. 若有服务机构报告,写明其类型、范围、期间及用户端补充控制,并找出两项以上无法通过报告确认的风险。

完成标准: 五项条款均有判定结果与依据,且对报告未能覆盖的各项风险均各写有一行单独核查的方法。