金融风控的 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 检查一样嵌入模型上线流程中，不合格自动驳回。
落地建议：先建特征白名单库和分组公平性检测脚本，作为模型上线前的两个硬性卡点。文档自动化可以后续迭代，但特征合规和公平性这两条是上线即需要就绪的底线。
