消费信贷智能体

在画流程图之前，先画出那四个受监管的行为。

在美国，Regulation B（12 CFR Part 1002，ECOA 的实施细则）管的是整段互动，而不只是那个信贷决定。有四个时刻带着义务，而智能体四个都碰得到。

• 问了什么。§1002.5 限制对受保护特征的询问——种族、肤色、宗教、民族出身、性别，以及在特定情形下的婚姻状况与生育意愿——仅有窄窄的例外，比如以住房作担保的贷款所需的监测信息。而一场自由对话本身就是一台提问机器。
• 有没有人被劝退。§1002.4(b) 禁止向申请人或潜在申请人作出那种会让一个通情达理的人基于受禁理由而放弃提出或推进申请的表述。这项责任附着在「说了一句话」上，既不需要有申请，也不需要有决定。
• 申请是什么时候完整的。§1002.9 的三十天通知时钟，从收到一份完整申请起算。一个在凌晨两点收齐最后一份缺失文件的智能体，已经把那口钟启动了。
• 通知上写了什么。§1002.9(b)(2) 要求给出不利行动的具体主要理由——不是一个类别，不是一句暗示，也不是指向某个模型。

对话式智能体是一位受监管的访谈者。把它的问题枚举出来。

直觉的做法是叮嘱模型别问受保护特征。那是一句提示词，而提示词是一种偏好——至于为何这一层扛不住一道你必须握住的管控，见指令层级。何况申请人还会在没被问的情况下主动说出受保护信息，而这是任何叮嘱都拦不住的。

• 从一份封闭的问题清单出发。智能体可以问的每一个问题，都是一份经过评审的清单里的一条，并写明用途。模型选择下一个问哪条、以及怎么措辞才亲切；它不创作新问题。清单之外的追问，交给人。
• 在进来的路上过滤，而不是在出去的路上。主动提供的受保护信息在接入处就被剥掉，压根不进入决策上下文。只要它进了上下文，你就得去争辩它有没有被用上；而如果它从未进来，就没什么可争的。
• 把代理变量当作同一类来处理。居住社区、学校、母语、姓名来源、境外地址史。这些正是一次差别性影响分析会找出来的变量，而一个读非结构化文档的智能体，不管你问没问过，都会把它们吞进去。这里「按权限、按用途受限」的检索很要紧——见按权限感知的检索。
• 把法定要求采集的监测数据放在另一条路上。在必须采集的场合，它进合规存储，绝不进入那个据以作出决定的上下文。

// The intake contract. The model picks from this; it does not extend it.
{ "question_id": "income.employment.gross_monthly",
  "purpose": "capacity",
  "required_for": ["installment", "revolving"],
  "phrasing": "model-composed, reviewed template",
  "storage": "decision_context" }

// Anything not in the registry:
{ "action": "route_to_human", "reason": "off-script inquiry" }

在这里，「乐于助人」产出的就是劝退。

一个被训练成替用户省时间的助手，会告诉一位边缘申请人「你多半过不了」，并建议对方先攒六个月的良好还款记录再回来。这句话在几乎任何别的产品里都真心有用，而在这一个产品里，它就是 §1002.4(b) 里的劝退风险——说给一位潜在申请人听，此时还不存在任何申请，没有随附的不利行动通知，也没有任何记录表明曾作出过一个决定。

• 绝不让智能体预测结果。它可以陈述标准，也可以解释流程。它不可以说这个人身上大概会发生什么，无论说得多么体贴。
• 把「中途放弃」当作一项被测量、被分层的结果。记录申请人在哪里停下，并在你的公平信贷项目可用的地域与人口维度上比较流失。某一群体在同一步骤集中流失，就是一个差别性影响信号，而它出现的地方没有任何模型测试会去看。
• 永远让人还是能申请。「提交这份申请并拿到一个决定」的路径，必须在对话的每一个时点都够得着，包括在智能体刚解释完标准看起来很紧之后。
• 把智能体的获客界面当作广告来评审。§1002.4(b) 同样覆盖广告，而一个对话式预资格小部件，无论你们组织内部把它归在哪个部门，都是向潜在申请人作出的表述。

这正是「只在决定那一点上设人工检查点」在这个领域放错了位置的具体原因：等到那个决定存在时，四个受监管行为里已经有三个成了往事。

用代码定义「完整申请」，因为现在是智能体在决定它何时发生。

三十天的时钟自收到一份完整申请起算，而「完整」如今取决于智能体对「刚解析的那张工资单够不够」的判断。若把这一点留作隐含，它就会变成一次时限违规，在几个月后的检查中浮出水面，而当时的记录根本重建不出完整性是何时达成的。

• 把完整性判定写成规则，不要写成提示词。一份具名的必需项清单，每一项由一份经核验的材料满足。智能体负责收集；规则负责判定；状态跃迁是一个带时间戳的日志事件。
• 有意识地发出「申请不完整」的通知。Reg B 为不完整申请给出了明确的处理路径；一个只会永远继续要材料的智能体，哪条路径都没选。
• 让这口钟在运维里可见。每一份在办申请都显示剩余天数，并在触线前告警，因为这个失效模式既安静又带日期。
• 诚实地处理撤回。一位不再回复的申请人并没有撤回申请；把「推断出的撤回」当作一个需要规则和记录的决定来对待，而不是一次超时。

理由必须点名一个由智能体抽取出来的因素——所以要在拒贷样本上测抽取准确率。

把评分留在一个变量经过枚举、并且经过申报的模型里，放在智能体之外。这一点本手册与承保智能体是共通的，也正是「黑箱解释难题」压根不会出现的原因。信贷特有的那部分更微妙：如今一个申报变量的取值，常常来自一个智能体对文档的解析，而通知必须准确地陈述理由，而不只是听起来合理。

• 每一个抽取出来的值都是一个带溯源的具名变量。哪份文档、哪一页、哪个模型版本，以及置信度。「收入不足」只有在你能拿出那个收入数字及其出处时，才是一条站得住的理由。
• 专门在拒贷样本上测抽取准确率。总体准确率会被干净的批准件压住。真正会产生通知的那些案子——薄档案、不规则收入、手写或外文材料——才是难啃的长尾，而那里的错误率才是预测「错误理由」与投诉的那个数字。每月抽样并人工打分。
• 低置信度要在决定之前转人工，而不是在通知寄出之后。在抽取环节弃答很便宜；一封寄出去的通知上写错主要理由则不便宜。这是把校准当作一个运营阈值来用。
• 理由要少而具体。披露一长串边缘因素会把真正起决定作用的那个盖住；标准要的是「主要理由」，而一封读起来像模型转储的通知，既满足不了申请人，也满足不了检查人员。
• 绝不让模型自由撰写通知正文。理由取自一份与申报变量绑定的固定目录。智能体可以做本地化和排版；不利行动通知里由生成式产出的散文，是一份没人评审过的法律文件。

注意压在这之上的第二套通知制度：当消费者信用报告起了作用时，FCRA 的不利行动义务同样适用，并有其自己的内容要求与时限。一个事件，两封通知，而两者的输入都被同一个智能体碰过。

把检查人员会要的那份卷宗建起来，并留一条能跟它争辩的路。

请求的形状永远一样：把这份申请还原到它被裁定那一天的样子。有五件产物能回答它，而它们一件也没法事后拼出来。

• 完整对话记录，与卷宗一同留存，因为四个受监管行为里有三个就是话语本身。在这个领域，轨迹就是证据，不是调试时的奢侈品。
• 带溯源的变量取值，以及为它们评分的模型版本——与模型风险管理所要求的是同一条「按时间点重建」。
• 完整性事件与通知日期，好让那口钟是一条记录，而不是一次推断。
• 本期的公平信贷测试结果，包括 STEP 3 里那份按阶段统计的流失，而不只是已裁定申请上的结果差异。
• 一条真的能走通的申诉路径。一位说「收入数字错了」的申请人，应当能找到一个有权更正该变量并重跑的人，这是带着明确救济的可申诉性，而不是一个投诉邮箱。