2 篇博文 含有标签「responsible-ai」

大多数工程团队对待伦理问题，就像他们过去对待安全问题一样：在功能发布之后、有人投诉之时才去处理。这种类比令人不安。2004年，SQL注入还是个"以后再修"的问题。如今，每个正规团队的CI中都有自动注入检测。AI伦理审查正处于同样的拐点——不提前建立门控机制的团队，终将以惨痛教训明白它存在的意义。

问题不在于初衷，而在于结构。安全审查有20年的标准化先发优势：OWASP清单、CVE评分、渗透测试、上线前的强制审批。伦理审查则没有这些规范。大多数团队既没有定义明确的触发条件，也没有清单、退出标准，更没有指定的责任人。结果是：一个医疗算法将黑人患者被识别为需要护理的比例降低了超过50%——不是因为工程师心怀恶意，而是因为没有人在上线前运行分组准确率分析。一个招聘模型系统性地降低了含有"女性"一词的简历排名——用历史数据训练，未经公平性审查就发布，几个月后才在生产中被发现。这些不是边缘案例，而是在伦理作为上线后没有牙齿的复选框时必然发生的结果。

你的 AI 功能通过了压力测试。达到了延迟 SLA。回滚程序运行正常。成本估算在预算之内。你的 post-mortem 模板每一行旁边都有一个绿色的对勾。

上线两个月后，该产品出现在一篇关于歧视性结果的调查文章中。你花了六周时间进行法律审查。

这就是双重报纸测试旨在弥补的差距。大多数工程团队为技术故障构建了完善的发布前流程——可靠性退化、API 不稳定、基础设施成本飙升。他们阅读有关停机的 post-mortem 并进行相应优化。但第二类 AI 故障能直接穿透这些流程，因为它们看起来不像 bug：功能完全按设计运行，但伤害仍然发生了。