从真正有含义的原则开始。
公平、透明、问责、人工监督、隐私与安全,以及可靠性,是常见的原则,也是正确的原则;它们可以追溯到多数国家框架所依循的经合组织(OECD)AI 原则。但原则只有与某项决定挂钩时才有意义。当有人必须在模型上线前检验它是否产生差别性结果时,公平才变得真实。当受某项决定影响的人能够得知 AI 参与其中并追问缘由时,透明才变得真实。请把每条原则写成你的团队必须回答的问题,而不是你希望他们认同的价值观。
不要从零开始发明这套框架。
你不必从第一性原理出发去设计一套治理体系。采用一个公认标准的主干,再加以调整即可。美国国家标准与技术研究院(NIST)的《AI 风险管理框架》把工作归纳为四个朴素的职能:治理、梳理、衡量与管理,任何团队都能照做。ISO/IEC 42001 规定了一套可供认证的 AI 管理体系,正如 ISO 27001 之于信息安全。ISO/IEC 23894 则专门针对 AI 风险。借用一个成熟结构,可以省去数月的内部争论,也向合作伙伴和监管方表明,你的做法是深思熟虑的,而非临时拼凑。
把原则转化为结构。
为 AI 明确归属,使得负责的对象永远不是 AI,而是某个人。保留一份 AI 使用情况的清单,也包括员工自行采用的工具,因为你无法治理看不见的东西。按风险为每种用途分级,以对人的影响和决定的可逆性为坐标轴,并让高风险用途在上线前先经过一道审批。这正是框架与愿望之间的区别:每一个风险决定都有归属者,也有关卡。
把控制措施放在风险所在之处。
让控制措施与风险大小相称,而不是用一份清单套用于所有情形。对后果重大的决定,始终让人来负责,也就是那些触及个人权利、金钱、安全或获取服务的决定。在部署前检验偏差与可靠性,部署后再按计划定期复检,因为模型会漂移,其下的数据也会变化。监测运行中的系统,记录它们的行为,并设定清晰的升级路径,使一线员工在发现异常时清楚地知道该向谁报告。低风险用途可以快速推进;高风险用途则应承担相应的摩擦。
不仅治理你自建的,也要治理你采购的。
多数机构所采用的 AI,远多于自己所构建的,它们嵌在你已经在用的软件里,以及你新增的供应商那里。你的框架也必须覆盖这些。要询问供应商:他们的模型从何而来、用什么数据训练、如何处理你的数据,以及当模型在你脚下发生变化时会怎样。一套只覆盖内部自建模型的负责任框架,会漏掉大部分真实的风险敞口。
让它持续运转,而不是办一次上线。
失败的样子,是一份精美却再没人打开的政策。记录你的决定,好让其中的推理在人员更替后依然留存。维护一套你真正演练过、而不仅是写下来的事件与升级流程。按固定节奏复审整套框架,每季度一次,或在任何重大变更之后,并淘汰那些不再产生价值的控制措施。负责任的 AI 需要持续维护,而不是一次性交付。
让它与你的规模相匹配。
十个人的团队不需要一份四十页的政策,而一家银行也无法只靠一页纸运转。让框架的分量与你的风险和规模相匹配。目标不是治理越多越好,而是治理恰到好处:让后果重大的决定有人负责、经过检验、留有记录,并且所需的繁文缛节越少越好。一套人们真正会遵守的简单框架,胜过一套束之高阁的繁复框架。