NVIDIA昨天发了一条推文，宣布与行业伙伴共同发起"开放安全AI联盟"。目标是共享模型、工具和研究成果，推动AI安全技术的发展。

原文很短，但信息量不小。"When the industry builds in the open, together"——这个表述本身就很有意思。过去两年AI安全的讨论，基本被几家闭源公司主导。OpenAI有red teaming框架，Anthropic有constitutional AI，Google有安全AI框架。每家都在说自己怎么做安全，但没人真正共享过底层工具。

现在NVIDIA选择了一条不一样的路。

开放安全 听起来很美

说实话，AI安全问题这两年越来越复杂。模型越做越大，攻击面跟着膨胀。从最开始的提示注入（prompt injection），到后面的模型窃取（model stealing），再到最近越来越活跃的对抗样本攻击——攻击者盯上AI系统已经不是什么新鲜事了。

我看过一些企业的安全部署日志，其中一个案例很有意思：一家金融公司部署了开源模型做客服，上线第三天就有人通过精心构造的输入绕过了内容过滤，诱导模型输出了内部API的调用方式。翻了下原文的细节——不是模型本身不安全，而是模型和外部系统之间的接口没有任何访问控制。

这个案例说明了什么？AI安全绝不只是"模型本身安不安全"的问题。它涉及整个系统链路：输入过滤、输出校验、API鉴权、数据隔离、审计日志。

NVIDIA的开放联盟想解决的就是这个问题。他们提出的方向是共享防护技术和工具集，让安全能力不再是每个团队各自造轮子。

闭源安全工具的困境

但问题来了。闭源AI公司做安全，有一个结构性问题：他们的安全工具只在自己的模型上验证过。

打个比方，OpenAI的red teaming工具是为GPT系列设计的，拿到Llama上好不好用？没人知道。Google的AI安全框架深度绑定Cloud Vertex AI，企业自建的模型能不能用？得大量适配。

这里有一个被忽视的细节：真正需要AI安全工具的，其实是那些用开源模型自己搭建系统的中小企业。它们没有专门的red team，没有安全研究员，能依赖的就是社区共享的工具和最佳实践。闭源厂商的安全方案对它们来说门槛太高、适配成本太大。

盯着一组数据看了好一会：根据Mandiant去年的报告，超过60%的AI相关安全事件发生在使用开源模型的企业中。不是因为开源模型更不安全，而是因为——说白了——用开源模型的团队往往是技术团队直接上手，没有安全团队介入。

开放联盟能改变什么

NVIDIA这个联盟的核心逻辑是：安全能力应该像开源软件一样，可以被共享、审查和改进。

举个例子，如果联盟成员共享了一个针对RAG系统的安全测试套件，任何企业都能拿它来测试自己的检索增强生成应用是否容易受到数据投毒攻击。这种共享比起每个企业自己写测试脚本，效率高太多了。

但事情没有这么简单。开放AI安全有一个天然矛盾：你共享的安全工具本身也可能被攻击者利用。如果一个检测提示注入的工具被公开了，攻击者可以研究它、绕过它。

我看到NVIDIA的推文里用了"building in the open"这个词，而不是"open source"。可能是故意的——不是把所有安全工具都开源，而是在一个可信联盟内部共享。怎么说呢，这介于开源和闭源之间的第三种路线，也许是目前最务实的方案。

对开发者的影响

对普通开发者来说，这个联盟最大的价值在于：以后部署AI系统，不用从零开始搭安全体系了。

以前：部署模型 → 上线 → 出问题 → 补安全。

现在如果联盟的工具有了：部署模型 → 跑安全检测套件 → 修复问题 → 上线。

这个流程变化，对于没有专门安全团队的中小团队来说，意义很大。但真正麻烦的是后面：安全不是一次性工程，模型更新了、数据集变了、接口改了，攻击面都会跟着变化。持续的安全测试怎么做？合规审计怎么自动化？这些才是长期的工程问题。

关于维基框架

维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。

官网：framewiki.com

Gitee：gitee.com/wiki-framework

GitHub：github.com/wiki-framework

示例项目：gitee.com/cdkjframework/framewiki-example

📄 许可证：MulanPSL-2.0（木兰宽松许可证，第2版）