AI生物安全风险解析：从能力评估到工程实践的判断框架

之前在技术社区刷到弗朗索瓦·肖莱（François Chollet）关于 AI 生物安全风险的一段公开讨论，发现不少开发者对“AI 会不会被用来制造生物威胁”这个话题存在两极分化的理解：一边认为大模型已经具备制造大规模威胁的能力，另一边则认为纯属过度恐慌。作为长期做 AI 应用落地的工程师，我梳理了一下肖莱公开表达过的观点、背后的技术论据，以及对我们日常开发工作的实际影响。这篇文章不是新闻稿，也不是观点辩论，而是一份偏工程视角的解读，方便做 AI 研发、安全合规和平台风控的同学建立一套可用的判断框架。

1. 先认识弗朗索瓦·肖莱

1.1 Keras 框架与他的技术背景

弗朗索瓦·肖莱是 Keras 深度学习框架的作者，目前主要研究方向是深度学习、机器智能和 AI 安全评估。对国内开发者来说，Keras 并不陌生，它早期以高层 API 的形式大幅降低了神经网络的搭建成本，很多人的第一个图像分类模型就是用 Keras 写出来的。

Chollet 的背景和纯学术研究者不太一样：他有大量工程经验，同时又长期聚焦“智能的定义”和“智能的测量”这类偏理论的问题。这种工程与理论并重的背景，让他在讨论 AI 风险时不太容易陷入单纯的“科幻式恐慌”或“技术乐观主义”，而是会回到“模型到底能做什么、不能做什么”这个原点上。

1.2 ARC-AGI 与他对 AI 智能的定义

肖莱开源过 ARC-AGI 基准测试集。这个基准的核心思想是：智能体应当具备在少量示例下快速适应新任务的能力，而不是在海量数据中记住已有模式。

ARC-AGI 里的题目对人类来说往往很容易，图形变换规律一眼就能看出来，但当时的大模型得分很低。这个现象被很多人引用，肖莱也借此反复强调一个判断：当前大语言模型表现出的“知识丰富度”和“真正的智能”是两回事。模型可以写出像模像样的回答，但面对从未见过的新问题，它并不具备稳定的推理和泛化能力。

这个判断非常重要，因为它直接决定了后续他对 AI 生物安全风险的态度。如果你认为大模型只是“高级文本联想机”，那么它被直接用来制造生物威胁的门槛就会高很多；如果你认为大模型已经是“近乎通用的问题解决者”，那么风险评估就会完全不同。

1.3 为什么 AI 从业者关注他的安全观点

现在做 AI 应用开发的团队，普遍要面对三类问题：模型能力边界在哪里、产品上线后会不会被恶意利用、合规审查怎么通过。肖莱的观点不是单纯的理论探讨，他给了一套可以用于实操的判断逻辑：

• 评估任何 AI 安全风险，先看模型实际能力，而不是想象中能力；
• 风险要按“链条”评估，而不是只看某个环节；
• 讨论安全问题时，数据和实验证据优于叙事。

这套逻辑对做模型选型、风控策略、安全评估的工程师来说，有直接参考价值。下面我们先把“AI 生物安全风险”这个概念拆开。

2. AI 生物安全风险到底是什么

2.1 概念边界

“AI 生物安全风险”并不是一个严格的学术术语，它在公开讨论中通常指：人工智能系统被人恶意使用或自主决策时，对生物安全（尤其是公共卫生安全）造成威胁的可能性。

具体来说，常见的讨论场景包括：

注意：这里说的“风险”既包括恶意攻击者主动利用 AI，也包括善意的生物研究中因为模型输出不准确而导致的意外事故。后者虽然在动机上不同，但在安全影响上同样值得关注。

2.2 风险传导链条

要评估 AI 在生物安全中的作用，不能笼统说“AI 可能被滥用”，而要把一条完整的风险链路拆出来。通常可以拆成五个阶段：

1. 知识获取：攻击者需要知道从哪些公开资料中获取关键信息；
2. 方案设计：把零散信息整合成可行的实验方案；
3. 原料与设备：获得对应的生物材料、化学试剂和实验设备；
4. 实验验证：在真实环境中反复试错，完成可复现的操作；
5. 规模扩散：让最终产物产生大范围影响。

在这条链条中，AI 的角色并不是均匀的。大模型对第 1、2 阶段可能有帮助，但对第 3、4 阶段的帮助有限，因为涉及物理世界操作，模型无法直接执行；对第 5 阶段的影响，更多取决于传播机制而非模型能力。

2.3 为什么现在讨论变多了

近两年讨论升温有三个技术背景：

第一，大语言模型的信息整合能力确实变强了。过去需要大量检索才能拼凑出的专业信息，现在通过多轮对话就能获得一份结构完整的文档。

第二，AI 在生命科学领域的应用快速增加。蛋白质结构预测、基因序列分析、药物分子设计这些工作已经在用深度学习模型加速，其中一些模型本身就有双用途属性。

第三，自动化实验设备开始出现。虽然“AI 全自动生物实验室”还没有真正成熟，但“模型生成方案 + 自动化设备执行”的组合，让研究者重新审视风险链条。

理解了这些背景，再来看肖莱的具体观点，会清晰很多。

3. 肖莱的核心观点拆解

3.1 能力评估是第一位的

肖莱在公开讨论中反复强调一个原则：“在谈论风险之前，先评估能力。”他认为，很多关于 AI 生物安全风险的讨论，都基于一种预设：语言模型已经能够像一位资深生物学家一样完成复杂的推理和实验设计。但他认为当前的大模型并不具备这种能力。

他常用的类比是：语言模型只是在文本分布上做概率预测。它能生成“看起来专业的 DNA 序列描述”或“看起来合规的实验流程”，但生成这些文本并不等于理解背后的生物机制，更不等于能在实验室中复现。

从工程角度看，这个判断可以转化成一句话：我们不能仅仅因为模型输出在语言上“正确”，就认为它在现实世界中有效。

3.2 “最后一公里”问题

肖莱观点里最核心的一个论点是“最后一公里”问题。具体来说，即使大模型能够输出一份看起来完整的威胁方案，从方案到现实威胁之间还隔着大量物理实验：

• 实验需要真实的生物材料、试剂和设备；
• 实验过程存在大量不可预测的变量，需要不断调整参数；
• 结果需要经过多轮验证，而不是文本生成一次就能成功；
• 专业操作依赖“默会知识”，即教科书上不会写的经验细节。

因此，他认为当前 AI 系统无法替代这“最后一公里”的物理实现过程。攻击者真正需要的不是一份文本方案，而是实验室能力和反复试错的成本。

3.3 知识可及性不等于新增风险

肖莱还提出过一个值得思考的论据：如果风险来自“知识可及性”，那么很多关键知识其实早已公开。生物教科书、学术论文、专利文档、公开数据库里，一直都可以查到双用途研究的相关内容。

在这个前提下，需要追问的是：大模型到底“新增”了什么风险？

如果说大模型只是把已经公开的信息做了整合，那它相比搜索引擎的优势是“效率提升”，而不是“知识解锁”。风险从“需要专业检索能力”变成“需要会写提示词”，门槛确实降低了，但并没有从“不可能”变成“可能”。

3.4 对极端风险叙事的态度

肖莱对“AI 即将制造下一次大流行”这类极端叙事持谨慎态度。他多次提醒，这类说法如果缺少可验证的技术证据，容易把公众注意力和监管资源引向错误方向。

不过，他也明确表示，这并不意味着 AI 安全不值得关注。他的观点更接近：应该把精力放在可以验证、可以测量的具体风险上，而不是围绕不可能发生的极端场景建立恐慌。

这种“基于证据的安全评估”思路，恰恰是工程团队应该学习的。

4. 技术论证：能力边界在哪里

4.1 文本生成与湿实验的鸿沟

要理解为什么大模型在生物安全链条中作用有限，需要先认识到“文本生成”和“湿实验”之间存在本质鸿沟。

大模型的所有输出都来自训练数据中的文本模式。它没有在真实物理环境中操作过移液枪、培养箱或显微镜，也没有亲眼见过细胞在特定条件下的真实反应。它生成的是“对文本的预测”，而不是“对实验结果的预测”。

举个通俗例子：一个模型读过大量菜谱后，可以生成一份看起来完整的“红烧肉”步骤。但如果你让它真的做出这道菜，它不知道火候差异、食材含水量、锅具导热性这些实际操作因素。生物实验的复杂度和不确定性，远高于做菜，因为每一批细胞状态、每一种试剂的批次、每一个实验室的环境都可能影响结果。

4.2 模型输出与已验证知识的区别

在专业领域，模型输出的最大问题不是“完全错误”，而是“看起来正确但实际不可靠”。这种不可靠性有两种表现：

第一种是幻觉。模型可能生成一段在语法、术语上都很专业的序列描述，但其中包含着实质性的错误。对于不具备专业能力的用户来说，很难发现这些错误。

第二种是表面合理性。模型可能综合了多篇论文的信息，但生成的内容缺乏可重复性验证。在生物实验中，“可重复性”是底线要求，文本层面的合理性远不足以支撑真实操作。

从安全角度来说，这种不可靠性实际上构成了一种“天然障碍”：攻击者如果完全依赖模型输出，很可能得到一份无法落地的方案。当然，这不能成为放松安全防护的理由，但能帮助我们更理性地评估风险等级。

4.3 模型幻觉带来的双面影响

值得注意的是，模型幻觉对安全的影响是双向的。

一方面，幻觉降低了模型作为“专业工具”的可靠性，从而降低了它被用于恶意目的的直接价值。一个无法稳定输出正确序列方案的系统，很难成为攻击者依赖的核心工具。

另一方面，幻觉也带来了新的风险：如果 AI 被用在生物研究辅助场景中，研究人员可能因为信任模型输出而忽略实验验证，导致实验事故。

这两种影响提醒我们，在做 AI 安全评估时不能只看“模型会不会被恶意利用”，还要看“模型在正常使用中会不会因为错误输出造成危害”。

4.4 能力是动态的，评估要持续进行

肖莱也明确承认，当前的能力评估只是阶段性的。随着模型在工具调用、长程推理、多模态理解等方面的能力提升，AI 在风险链条中的角色可能发生变化。

比如，如果未来模型能够稳定调用外部工具完成信息检索、数据分析、文档生成，并且具备更强的推理一致性，那么它在“方案设计”阶段的能力会显著增强。

再比如，如果自动化实验设备与 AI 系统的接口成熟，模型的角色可能从“提供方案”延伸到“控制实验流程”。这个变化会显著改变风险链条的评估结果。

因此，一个负责任的技术团队，应该把安全风险评估做成持续过程，而不是一次性的上线检查。

5. 面向 AI 开发者的安全实践

无论我们对风险程度持什么判断，工程上都有一个基本原则：默认采用安全设计。下面分享一套我们在实际项目中用过的 AI 应用安全评估方法。

5.1 上线前的安全自评框架

在做 AI 应用上线评估时，建议团队按以下维度自查：

• 模型能力：模型是否具备生成与生物、化学、安全相关高危险内容的能力？
• 业务场景：当前业务场景是否涉及生物信息、医药研发、安全分析等敏感领域？
• 用户范围：产品面向大众还是受限的专业用户？
• 输出可控性：模型输出是否经过过滤、审核和人工复核？
• 审计能力：系统是否记录了完整的输入输出日志，能否追溯到具体用户？

这些维度可以组合成一个简单的风险等级判断：业务场景越敏感、用户范围越开放、输出可控性越弱，风险等级越高。

5.2 一个简单的风险评估脚本示例

为了便于团队落地，我们通常会把上面的评估维度做成一个可配置的脚本。下面是一个简化示例，重点是提供一种工程化思路，而不是完整的商业安全工具。

# 文件路径：risk_assessment.py # 功能：根据业务维度计算 AI 应用的基础风险评分 # 说明：这是一个用于内部评审的简化示例，实际使用请按业务扩展 def assess_risk( domain: str, user_scope: str, output_control: bool, has_audit: bool, model_capability: str ) -> dict: """ 简单风险评分：分数越高，风险越大 domain: 业务领域 user_scope: open 表示公开用户，closed 表示受限用户 output_control: 是否对模型输出做二次过滤 has_audit: 是否有审计日志 model_capability: 模型能力等级，如 low / medium / high """ score = 0 reasons = [] # 1. 业务领域权重 domain_weights = { "general": 1, "education": 2, "code": 2, "bioinfo": 5, "security": 5, } domain_score = domain_weights.get(domain, 1) score += domain_score reasons.append(f"业务领域 {domain}，权重 {domain_score}") # 2. 用户范围 if user_scope == "open": score += 2 reasons.append("面向公开用户，风险增加") else: score += 0 reasons.append("面向受限用户，风险可控") # 3. 输出控制 if not output_control: score += 2 reasons.append("缺少输出过滤，风险增加") else: reasons.append("已配置输出过滤") # 4. 审计能力 if not has_audit: score += 1 reasons.append("缺少审计日志，追溯困难") # 5. 模型能力 capability_weights = {"low": 1, "medium": 2, "high": 3} capability_score = capability_weights.get(model_capability, 1) score += capability_score reasons.append(f"模型能力 {model_capability}，权重 {capability_score}") # 风险等级 if score <= 5: level = "低" elif score <= 8: level = "中" else: level = "高" return { "score": score, "level": level, "details": reasons, } if __name__ == "__main__": result = assess_risk( domain="general", user_scope="open", output_control=True, has_audit=True, model_capability="medium", ) print("风险评分:", result["score"]) print("风险等级:", result["level"]) for item in result["details"]: print(" -", item)

运行这个脚本需要 Python 3.6 以上环境，直接执行即可看到输出结果。实际的评估维度会复杂得多，但这个示例可以帮助团队建立“将安全评估量化”的意识。

5.3 Red Teaming 与安全测试方法论

除了静态评估，动态安全测试同样重要。在 AI 应用领域，这种测试通常被称为 Red Teaming，即由专门的安全测试团队模拟攻击者视角，尝试绕过模型的输出限制。

Red Teaming 的工程化流程通常包括：

1. 明确测试边界：定义哪些主题属于高风险内容；
2. 设计测试用例：覆盖直接提问、间接诱导、角色扮演、多轮语境叠加等场景；
3. 记录模型输出：判断模型是否遵守安全策略；
4. 迭代修复：针对绕过成功的案例，增加输入过滤或输出约束；
5. 回归验证：修复后重新运行完整用例集，确认没有引入新问题。

需要强调的是，Red Teaming 测试用例的设计必须在合规框架内进行，测试团队不应真的生成危险内容，而是通过模型“是否拒绝回答”“是否引导至安全方向”来判断安全策略的有效性。最终目的是验证防护机制，而不是学习危险方法。

5.4 部署阶段的防护措施

在模型完成评估和测试后，部署阶段仍然不能掉以轻心。推荐的防护措施包括：

• 输入侧过滤：对用户输入进行关键词和意图识别，拦截明显的高风险请求；
• 输出侧过滤：对模型输出进行二次审核，匹配高风险主题时直接拦截；
• 权限分级：对高能力模型或高风险场景设置更高的调用权限；
• 审计日志：记录每一次调用的用户、时间、输入摘要和输出摘要，保证可追溯；
• 熔断机制：当系统检测到异常集中的风险请求时，自动触发限流或暂停服务。

这些措施不一定全部要上，团队可以根据业务场景选择组合。核心原则是：安全设计要嵌入整个产品链路，而不是依赖模型自己“拒绝回答”。

6. 这场讨论给我们的启示

6.1 区分不同维度的 AI 风险

关于 AI 安全的讨论，最常犯的错误是把不同类型的风险混为一谈。结合肖莱的讨论，我建议把 AI 风险至少分成三类：

第一类是“使用风险”，即现有模型已经表现出偏见、幻觉、隐私泄露等问题，这类风险已经发生，需要靠工程手段持续治理。

第二类是“误用风险”，即模型被攻击者用于恶意目的。这类风险取决于能力、可及性和物理场景约束，需要逐链条评估。

第三类是“远期风险”，即未来更强大的 AI 系统可能出现的失控或滥用。这类风险存在很大不确定性，很难用当前数据验证。

不同风险的正确处理方式不同。处理使用风险靠产品和算法优化，处理误用风险靠权限和监控，处理远期风险靠研究和政策储备。混淆这三类风险，会导致资源错配。

6.2 技术评估先于叙事

肖莱的讨论带给我们最大的工程启示，是在 AI 安全问题上坚持“技术评估先于叙事”。

在一个新功能上线前，团队往往面临来自各方的压力：产品方希望尽快发布，安全方希望充分评估，管理层希望控制成本。在这种情况下，基于可测量指标的评估流程，比基于感觉的讨论更有效。

具体做法可以是：把“能力边界”拆成可验证的子问题，比如“模型能否通过某个专业测试”“模型能否调用外部工具完成某类任务”“模型输出在专业场景上的准确率是多少”。每一个子问题都有数据支撑，讨论就不容易空转。

6.3 从“不可知论”中走出来

面对 AI 安全这种充满未知的话题，一种常见的态度是“无法验证，因此不必认真”。另一种则是“存在风险，因此必须全面禁止”。这两种态度都不是良好的工程态度。

更务实的选择是：承认不确定性，但为可验证的风险建立防护机制，为不可验证的风险保留监控和调整空间。这就像做容灾设计：你无法预知所有故障模式，但可以通过备份、监控、演练来提升系统的整体韧性。

对 AI 开发者来说，这意味着：即使你认为当前模型不具备制造生物威胁的能力，仍然应该做好输出过滤和审计；即使你认为未来 AI 可能带来新的风险，也不需要在今天为不确定的未来停止所有技术探索。

7. 总结与后续学习方向

通过这篇文章，我们梳理了几个关键点：

第一，弗朗索瓦·肖莱在 AI 生物安全风险上的核心判断建立在能力评估之上。他不会因为模型能生成“看起来专业”的内容，就认为模型具备真实的专业操作能力。

第二，AI 生物安全风险是一个链条问题，包含知识获取、方案设计、材料准备、实验验证和规模扩散等多个环节。AI 在不同环节的作用差异很大，不能一概而论。

第三，无论对风险程度怎么判断，工程上都应该默认采用安全设计。风险自评、Red Teaming、输出过滤、审计日志、熔断机制，这些手段都是团队可以直接落地的。

如果你对 AI 安全这个方向感兴趣，下一步可以关注三个技术方向：一个是 AI 安全评测方法，比如各类红队测试基准和评估框架；一个是生物信息学与 AI 的交叉应用，理解模型在蛋白质结构、基因序列等任务上的真实能力边界；还有一个是 AI Agent 安全，尤其是未来模型具备工具调用能力后，如何在执行链条上设置安全边界。

这些方向不需要你成为安全专家，但如果你在 AI 应用团队工作，掌握这些基础评估方法，能在很大程度上避免“只有恐慌、没有对策”的局面。希望这篇文章能帮你建立一套自己的判断框架。