信用评分与自动化决策

多年来，对信用评分（scoring）模型的合规分析止步于数据保护。如今，有三套制度叠加在同一项决定之上——向个人发放或拒绝发放贷款——而且各自关注的重点不同：

• 第2023/2225号指令（欧盟），即CCD2，关注对消费者的结果：决定影响消费者时其享有哪些权利、哪些数据不得使用，以及应当评估什么。
• 第2024/1689号条例（欧盟），即《人工智能法案》，关注系统本身：如何构建、使用什么数据训练、如何形成文档，以及由谁监督。
• GDPR关注数据处理：法律依据、对数据主体的告知，以及对仅基于自动化处理作出的决定的限制。

实际后果是，只处理了三个方面中的一个的项目，几乎必然在另外两个方面存在缺口。而且所有情形中最常见的缺口都是一样的：模型运行正常，却无法解释。模型可以预测得很准，却同时无法用客户能够理解的方式告诉客户为什么被拒贷，也无法向监管机构证明模型是如何构建的。

还应明确一个统领其余内容的观点：这三项法规都不禁止自动化。它们要求的是，自动化必须可逆、可解释且受监督。一个自行决策、无法人工复核、也无法解释其输出的模型，并不是高效的模型：它是不合规的模型。

这三项权利读起来很快，落实起来却很慢，因为每一项涉及系统的不同层面。人工干预权属于组织层面：需要人员、培训，以及对其推翻模型的权限范围作出清晰界定。解释权属于技术层面：要求模型给出理由，而不仅仅是一个数字，这在实践中决定了哪些模型架构可行。复核权属于程序层面：必须收集客户的主张，留下已予考虑的记录，并为新的决定说明理由。

第二项权利迫使最多的项目重新考虑方案。一个非常精确但不透明的模型——例如深度集成模型——可能无法使用，原因不在于其性能，而在于其输出无法转化为有意义的解释。这是一个架构层面的决定，应在设计阶段作出，而不是等到第一次投诉出现时。

还有一个联系不容忽视：远程金融服务指令同时规定，在使用自动化工具的合同前阶段，消费者有权获得人工干预。这是两项不同的法规指向同一个地方——订立合同之前和作出放贷决定时——因此升级处理机制必须覆盖这两个时点。

CCD2界定了哪些信息可以作为信用评估的依据，并明确排除了两类此前常见于替代性信用评分（scoring）模型的数据来源：

• GDPR规定的特殊类别数据，并明确提到健康数据。
• 来自社交网络的数据。

第一项禁止与一般数据保护制度一致，并不令人意外。第二项才是改变项目的：多年来，数字行为信号和社交足迹的使用一直被视为向没有信用记录的人群放贷的途径。在消费信贷的信用评估中，这条路已被堵死。

但真正需要技术工作的后果是另一个，而且法条中并未写明：近似变量。模型可能不使用健康数据，却纳入了与健康数据高度相关的变量——药店消费模式、商户类型、特定类别消费的频率等。形式上没有使用被禁止的数据；实质上它进入了决策。清理模型中的这类近似变量不是文件审查，而是一项统计工作，必须在实际变量上进行并留下书面记录。

而且这项分析一举两得。它既是CCD2对数据方面的要求，在很大程度上也是《人工智能法案》在高风险系统的数据治理标题下提出的要求。只做一次，就可以同时用于两套档案。

这一分类没有争议空间：对自然人的信用评估被明确列入附件三“获取基本服务”类别。使用人工智能系统来决定是否放贷的贷款人，运营的就是高风险系统，并须承担随之而来的一切后果。

其中有两项义务值得停下来细看，因为它们最容易被误解。人工监督不能靠一个无人使用的撤销按钮来满足：法规要求的设计须能实现有效的监督，这意味着监督人员要理解系统输出，有实际时间进行评估，并有真正的能力偏离该输出。而记录留存也不是应用程序的日志：它指的是能够还原系统在某一笔具体业务中为何作出该决定的痕迹，哪怕是数月之后。

好消息是，这与CCD2已有的要求存在重叠。消费信贷指令要求的人工干预机制，在很大程度上就是《人工智能法案》要求的人工监督；而能够解释拒贷决定的可追溯性，也正是能够留存记录的可追溯性。分开设计会造成重复劳动。如果您已通过其他途径在处理《人工智能法案》，建议与《人工智能法案》合规分析交叉衔接。

GDPR第22条赋予数据主体一项权利：不受仅基于自动化处理作出的、对其产生法律后果或对其造成类似重大影响的决定的约束。拒绝贷款完全属于这种情形，因此大多数机构对此问题已有既定立场。

现在改变的是，这一立场需要结合另外两项法规重新审视，因为标准已经提高。许多模型依赖的理由是：由于存在名义上的人工复核，决定并非“仅”由自动化作出。CCD2和《人工智能法案》从两个角度收紧了这一解读：前者明确赋予人工干预、解释和复核的权利；后者要求人工监督在设计上就是有效的。仅仅形式上的复核，已不足以支撑这一论点。

结果是，这三项法规汇聚到同一项实务成果上，只需构建一次：每笔业务一份决策档案，记录输入了哪些数据、系统给出了什么输出、由谁复核、客户如有主张提出了什么主张，以及最终决定如何说明理由。这份档案既是遵守GDPR的证明，也是CCD2规定的人工干预的证据，同时还是《人工智能法案》所要求的记录。

该表中有两处措辞值得关注，因为它们产生的工作量最大。第一处是“对现有义务的适当考虑”：仅了解收入是不够的，还必须纳入客户已经承担的财务负担。这就要求解决该数据从何而来——查询数据库、客户提供的信息、账户聚合——并将所作选择形成文档。

第二处是“与业务量相适应”。这是一项比例原则条款，应从两个方向理解。对小型贷款人而言，这意味着不会要求其具备大型机构那样的体系。对大型贷款人而言，意思恰恰相反：预期标准随业务量上升，因此手工作坊式的程序在达到一定规模之后就站不住脚了。比例原则并不总是一种减负。

设想这样一个场景，因为这正是需要解决的问题：一位被拒贷的客户打来电话询问原因。“您没有通过我们的评估系统”这样的回答已经行不通。指令赋予的是有意义且通俗易懂的解释权，这两个形容词都有实质内容。

有意义是指，解释必须针对在这一具体决定中确实起作用的因素，而不是对模型的泛泛描述。通俗易懂是指，解释必须使用客户的语言，而不是风控团队的语言：说“工龄变量的百分位数”等于什么也没解释。

这需要三样东西，必须在收到第一次请求之前建立好：

• 技术上的归因能力。系统必须能够说明在这笔业务中是哪些因素推动了决定，而不是平均而言的因素。这会影响模型的架构。
• 通俗语言的理由目录。事先写好并经审核的、将每个因素转化为消费者能够理解的一句话的表述，使解释不取决于由谁接听电话。
• 主张与复核机制。客户提供的信息从哪里进入、由谁评估，以及如何为新的决定说明理由。

还应注意一个界限：解释并不等于披露模型。消费者理解决定的权利，与机构不让评估系统遭受逆向工程或欺诈的正当利益之间，需要取得平衡。这种平衡在理由目录的设计中解决——足够具体以便有用，又足够概括以免成为如何欺骗模型的手册——并且最好以书面形式说明理由。