金融风控的 AI 部署红线:模型上线前的合规审查清单

发布时间:2026/7/24 19:37:44
金融风控的 AI 部署红线:模型上线前的合规审查清单 金融风控的 AI 部署红线模型上线前的合规审查清单一、合规不是上线后才补的文件一条被驳回的上线申请审批流程走了两天AI 团队提交了一个新的信用评分模型。离线评估报告显示 AUC 提升 3 个百分点KS 值从 0.38 提升到 0.44。所有人都在等一个通过。但在最后的合规审查环节模型被打回了。原因是模型的特征列表里包含了一个用户手机型号特征。合规团队指出根据最新的个人信息保护法规手机型号与用户信用评估之间没有经过充分论证的业务必要性。使用这一特征进行信贷决策在监管检查中可能被视为过度收集个人信息用于自动化决策。这不是模型质量问题也不是算法问题。这是AI 部署的合规红线——模型上线不只是看效果好不好还要看输入特征是否合规、输出决策是否可解释、是否存在歧视性偏差。而这些审查如果等到上线前最后一天才发现整个发版计划都会被推到重来。基础设施不需要漂亮话。合规审查清单应该像 CI 流水线里的 lint 检查一样是模型上线前的自动卡点而不是人工签字的流程障碍。二、特征合规审查不是所有数据都能拿来做风控金融风控模型的特征合规审查有四个必须回答的问题第一特征与风控决策的业务必要性。特征是否与信用风险和欺诈风险有直接的统计相关性如果相关性低于某个阈值如 Pearson 系数 0.05该特征被认为是不必要的。这不是一个技术判断而是有监管含义的合规判断。第二特征是否属于敏感个人信息。种族、宗教信仰、性取向、健康数据、生物识别信息——这些在任何风控场景下都不允许作为模型特征。即使模型训练时自动学到了这些维度的区分度也需要通过特征剔除或对抗训练的方式消除影响。第三特征的数据来源是否合规。特征数据是通过用户明确授权获取的还是从第三方数据服务商购买的如果是购买的数据数据服务商是否有合规的数据采集和转让资质数据来源的不合规会导致模型处于先天违法的状态。第四特征的时效性是否合理。使用过去 5 年的历史逾期记录作为特征可能是合理的但使用5 年前的手机型号就不合理了。特征的时效性窗口应与业务场景相关过期的历史数据对决策的边际贡献无限趋近于零但合规风险不递减。审查流程应当自动化特征列表在上线前自动与合规特征库做匹配。合规特征库维护了已审核通过的特征白名单。如果模型引入了不在白名单中的新特征自动转入人工审查队列。三、模型公平性检测分数分布不能因性别/地域出现系统性偏差AI 模型的公平性问题在金融风控中比其他领域更加尖锐。如果模型因为训练数据的偏差对某个地域的用户群体给出了系统性偏低的信用评分这是歧视性问题也是法律问题。模型公平性的量化检测通过分组 AUC 和 Equal Opportunity 指标来实现。将用户按受保护属性分组性别、地域、年龄区间计算每组用户中模型对真正有风险的用户的识别率True Positive Rate模型对无风险用户的误杀率False Positive Rate如果不同组之间的 TPR 差异超过 5 个百分点或 FPR 差异超过 3 个百分点说明模型对某些组存在系统性偏差。偏差的来源可能是训练数据中该组的正负样本比例严重失衡需要通过采样策略或损失函数加权来修复。// 模型公平性检测 type FairnessChecker struct { thresholdTPR float64 // TPR 差异阈值默认 0.05 thresholdFPR float64 // FPR 差异阈值默认 0.03 } func (c *FairnessChecker) Check(samples []Sample, groupField string) *FairnessReport { groups : c.groupBy(samples, groupField) report : FairnessReport{Groups: make(map[string]*GroupMetrics)} for name, groupSamples : range groups { tp : 0; fp : 0; totalPos : 0; totalNeg : 0 for _, s : range groupSamples { if s.Label 1 { // 真正有风险 totalPos if s.PredScore s.Threshold { tp } } else { totalNeg if s.PredScore s.Threshold { fp } } } tpr : float64(tp) / float64(totalPos) fpr : float64(fp) / float64(totalNeg) report.Groups[name] GroupMetrics{TPR: tpr, FPR: fpr} } // 计算各组的 TPR/FPR 最大差异 report.MaxTPRGap c.maxGap(report.Groups, TPR) report.MaxFPRGap c.maxGap(report.Groups, FPR) report.IsFair report.MaxTPRGap c.thresholdTPR report.MaxFPRGap c.thresholdFPR return report }四、模型文档与决策透明度监管检查时不能不知道金融监管对模型文档的要求远超一般 AI 项目。上线前至少需要准备以下材料模型技术文档模型类型、架构、训练数据来源和统计摘要、特征列表及业务含义、评估指标。公平性评估报告分组 AUC/TPR/FPR 比较、偏差分析、修复措施如有。性能基准报告P50/P95/P99 推理延迟、吞吐量上限、降级策略。变更记录模型版本与历史上线记录的映射每次变更的原因和效果对比。这些文档不应是事后补的 PPT而是从模型训练阶段就开始自动生成。MLflow 或类似实验追踪系统可以记录训练参数、数据集版本、评估指标上线前由工具一键导出为标准化的上线报告。五、总结金融风控的 AI 部署红线本质是在效果和合规之间建立可量化的审查流程。核心要点特征合规是硬卡点。敏感信息禁止使用不必要特征需要论证数据来源必须有授权。模型公平性要量化检测。TPR/FPR 的分组差异不能超过阈值偏差来源要追溯到训练数据。文档建设要自动化和持续化。不靠人肉写报告靠 MLflow 等工具自动生成并归档。合规审查应该流水线化。像 CI 检查一样嵌入模型上线流程中不合格自动驳回。落地建议先建特征白名单库和分组公平性检测脚本作为模型上线前的两个硬性卡点。文档自动化可以后续迭代但特征合规和公平性这两条是上线即需要就绪的底线。