先给结论：算法影响评估正在被写进采购和法规。若只让开发方自填清单，不让被影响的人提问，评估就是演戏。试点已经证明：不会训练模型的人，也能挑战系统前提，指出技术审计漏掉的伤害。评估权若和开发方重合，结论不会停系统。没有外部压力去执行，报告只会归档。

为什么「再做一份影响表」常常什么都改变不了

痛点是把评估理解成文档齐不齐。环境、财政、人权领域早就有影响评估，算法把这套搬过来时，最容易丢的是：谁有权提出问题、谁当裁判、结论能否停部署。开发方自己填、自己当论坛、自己决定改哪几条，就是评估者和被评估者塌成一家。塌了以后，清单可以很长，系统仍按原计划上线。

被影响的人不需要会训练模型。他们需要的是：系统要解决什么、数据从哪来、错了找谁、能不能不用这套自动化。试点里，参与者指出过技术审计不会写进表格的风险：把无家可归当成犯罪线索、让幸存者再次受创、让健康咨询滑向聊天依赖。他们也反复追问敏感数据、监视，以及这件事该不该被自动化。这些不是「外行意见」，是前提错误。

评估要有构成部件，不能只有标题。至少要说清：合法性从哪来、谁是行动者、谁是论坛、测什么伤害、方法如何被争议、公众如何进入、结论如何被执行、不执行有什么后果。部件可以按场景搭配，但不能缺到只剩一张自评表。自评表没有咨询义务，就是没评估。

五步把影响评估从归档文件收成能停系统的门禁

1. 问题由被影响的人先提。开发方的风险登记只能当对照，不能当议程。议程对不上社区问题，评估无效。
2. 评估权与开发权分开。同一机构里的「独立小组」若仍向项目负责人汇报，不算分开。论坛必须能公开结论，并能要求补测。
3. 伤害范围不能只量化歧视指标。分配、尊严、代表、监视、该不该自动化，都要进表。进不了表的，用案例写进附件，不准因为不好打分就删掉。
4. 结论必须带救济和停用条件。写得出风险却写不出谁赔偿、谁停用，报告只是告知。告知不是问责。
5. 要有外部压力接住发现。媒体、采购条款、监管抽查，至少一条能把「已识别风险」变成「必须改或必须停」。没有外部压力，评估会滑成仪式。

现场有三条。其一，方法选择就是权力分配。测什么、不测什么、谁的话算证据，决定谁被保护。把评估设计成只有工程师能操作的流水线，社区再怎么到场也只是旁听。旁听可以拍照，不能改默认。其二，参与会被做成一次性工作坊。工作坊结束，模型继续迭代，评估却冻在上线前那一版。迭代不触发重评，等于用旧报告给新系统背书。重评门槛要写死：数据、用途、影响人群任一变更，评估作废。其三，公共机构采购最容易把评估外包给供应商方法。供应商提供模型、提供评测、提供「已咨询」的模板。机构留下的只有签字。签字后问责仍在公职人员身上。所以基线、抽查权和停用权必须留在买方，不能写进同一份实施合同里被买走。

度量六件事：议程是否来自被影响的人、论坛是否独立、非量化伤害是否进附件、停用条件是否可观察、变更是否触发重评、发现有没有外部执行通道。六件说不清，评估就是演戏。演戏会占用所有人的时间，还让下一次真正的伤害更难被当成新闻，因为「我们已经评估过了」。

有人会说社区意见冲突、没法收敛。冲突不是失败，是评估该记录的内容。记录冲突、记录选择、记录谁被优先，比假装共识更接近问责。假装共识的报告最好看，也最不能在事故后拿出来用。事故后人们会问：当时谁反对、反对被怎么处理。报告里没有反对，只有顺利通过，调查会从这份报告开始追责。

建设者若真要评估，就得接受评估可能得出「不该上」。上不了也是结果。部署者若把「必须上」写在评估开始之前，后面所有咨询都是装饰。装饰一旦成为行业习惯，法规写得再细，也只是多了一摞不会停机的文件。

结论：评估要能停系统，才配写进采购

不听被影响的人、评估权和开发权重合、没有停用和外部压力，影响评估就是仪式。仪式可以很专业，系统仍会按原计划处理那些没有被请进房间的人。

你下次收评估报告，先找社区问题清单和停用条件。两份对不上正文，报告退回，不准当放行附件。

本文侧重全链路风控方法论。落地时请用自身业务单据做回放验证，不要把示例阈值直接当生产策略。 相关：风控体检 · 方案资源