“我的模型被一个人 fork 走了，第二天他接进了公司客服系统，机器人说错话，客户索赔，现在对方律师函发到我的开源项目邮箱里。我该怎么披露风险、怎么自保？”
这是我上个月在一个开源社群里看到的真实求助帖。回帖里最高赞的答案只有一句话：“谁让你当初不在 README 里写清楚？”听起来很扎心，但这就是现在做开源AI的现状：代码可以免费，责任可不会自动免掉。
最高法层面新出台的涉AI规定，把这把火又烧旺了一截。开源社区里讨论最凶的不是“AI能不能开源”，而是“开源AI软件的风险披露到底怎么写才算数”。很多人以为免责就是 LICENSE 里那句“AS IS”加上一行“后果自负”，但这次监管透出的风向显然没那么简单——它更关心你披露了什么、披露给了谁、披露得够不够具体。
这篇文章不打算复述条文，我也不是法律专业人士，只从我这些年维护开源AI项目、帮团队做过合规审查的实操角度，把“风险披露”这件事掰开揉碎：风险出在哪、披露该怎么做、哪些坑写了也白写，以及一套能直接抄到仓库里的落地清单。
1. 新规之后，开源AI的“免责”逻辑彻底变了
1.1 开源AI和传统开源软件不是一回事
先纠正一个特别常见的误区：很多人把开源AI当成“开源软件”来管理，照着当年 GitHub 上开源库的做法，LICENSE 文件一贴，免责声明抄两行，就觉得完事了。
传统开源软件的行为是确定性的，代码摆在那，跑出 bug 可以复现、可以定位、可以修，出了问题责任链条相对清楚。但AI模型不是这样。一个模型的行为没法通过穷举测试来保证，同样的提示词在不同参数、不同版本、不同推理框架下可能产出完全不同的结果。它更像是一个“能力集合”而不是一件“工具”，你很难说清楚某个错误输出到底是“缺陷”还是“正常概率事件”，这就让传统的产品责任逻辑很难直接套用。
新规之所以让开源圈紧张，本质上就是因为监管开始正视 AI 这种“不可穷举”的特性。“按现状提供、不承担任何责任”这句话，在代码世界里勉强够用，在 AI 世界里会被追问一句：你有没有把你知道的风险提前说出来？
1.2 监管的落点从“结果追责”转向“过程披露”
我看了各方的解读文章，不管具体条文细节如何，行业里普遍形成的共识是：这轮监管更看重“你有没有尽到告知义务”。责任判断的坐标系变了——过去主要看“出了事之后谁有过错”，现在更多看“出事之前你有没有把风险讲清楚”。
对开源AI项目来说，这意味着开发者手里的“免责声明”不再只是一句法律套话，而是一份“我已经尽到合理注意义务”的证据。你有没有在模型卡里标注训练数据的来源？有没有提示模型在哪些场景下会失效？有没有明确写出禁止用途？这些细节，会比 LICENSE 里那句通用的“AS IS”有用得多。
1.3 开源不豁免责任，只改变责任的表现形式
这里必须把话说透：开源许可证解决的是“源代码能不能被使用、修改、再分发”的问题，它从来不解决“出了问题谁负责”的问题。开源不等于甩手掌柜。
回顾过去几年行业里的纠纷爆发点，其实很集中：数据集版权侵权的连带责任、模型输出误导用户造成损失、下游开发者把模型接入高风险场景后出事。这三种场景里，没有一种是因为“代码是开源的”就自动免责的。开源改变的只是软件的交付方式，责任始终有人承担——就看披露做得好不好，把责任挡在了哪一环。
2. 先把账算清楚：开源AI项目到底背着哪些风险
想做好披露，第一步不是写文档，而是先盘点风险。我给好几个开源项目做过这种“风险体检”，基本都会落到下面四类，建议你对号入座。
2.1 模型输出的“不可控”风险
这类风险最容易理解：大模型会产生幻觉、有偏见、会被越狱。你的模型在评测集上表现再好，也挡不住某个用户用一个刁钻的提示词让助手输出有害内容，或者它在专业领域一本正经地胡说八道。
举个例子，一个做健康科普的开源对话模型，训练数据都是正规医学教材，但模型本身没有行医资质。用户问“我这症状是不是癌症”，模型给了个模棱两可的猜测，用户当真了，耽误了就医。这个责任算谁的？如果模型卡里明确写了“本项目不提供医疗建议，输出内容仅供参考，请务必咨询专业医生”，并且 README 里用加粗大字提醒了，那开发者的处境就完全不同。
2.2 训练数据与版权合规风险
这是目前开源AI领域最大的一颗雷。很多开源模型的训练数据来自爬虫抓取、公开数据集拼凑、甚至用户上传内容的二次利用。数据里可能包含受版权保护的作品、个人信息、肖像，也可能包含违反平台条款的内容。
麻烦在于，开源模型的“传染性”极强。你的模型一旦发布，下游项目会基于它做微调、再训练、接入产品，训练数据的合规瑕疵会像基因一样遗传给整个生态。等版权方找上门的时候，你面对的就不是一个项目的问题，而是一整条上下游链条的连带追问。所以风险披露里必须包含数据来源说明——哪怕一句话说清楚“训练数据包含哪些公开语料、哪些是自采数据”，都能在争议发生时证明你没有隐瞒。
2.3 下游滥用与场景错配风险
这条最容易被开发者忽视。你的模型发出去之后，你真的控制不了它会被谁用、用在哪儿。有人把它二次打包成付费 API 转售；有人拿它微调成一个生成钓鱼邮件的工具；有人直接把它接进自动驾驶、金融风控这类高风险系统。
我见过一个真实案例：某个开源代码生成模型，发布时只写了“实验用途”，结果三个月后被人微调后用于生成攻击脚本，一时舆论哗然。开发者很委屈，但复盘时发现，项目里既没有可接受使用政策，也没有任何防滥用机制。这种时候，一句“与我无关”是站不住脚的。合理的做法是写清楚允许和禁止的用途，并在发布渠道上醒目提示。
2.4 供应链与依赖的“隐形”风险
开源AI项目很少是纯自研的。底层可能用了某个开源大模型，处理层用了第三方库，推理又依赖某个量化工具。这些依赖里每一环都有自己的许可证和免责条款，合在一起就可能出现冲突。
最常见的是许可证传染问题。GPL 系许可证要求衍生作品也要开源，你用了 GPL 组件又不打算开源整个项目，就会埋下合规隐患。另一个是已知漏洞不披露——你用的推理框架爆出了高危漏洞，你还继续把它打包进新版本发布，这就会被认定为主观放任。供应链风险披露的核心，是把依赖清单、各自许可证、已知问题和更新时间全部透明化。
下面这张表是我常用的风险盘点模板，建议直接抄进项目 Wiki：
| 风险类别 | 常见场景 | 需要披露的关键信息 |
|---|---|---|
| 输出不可控 | 幻觉、偏见、越狱、错误专业建议 | 已知局限性、评测边界、适用场景 |
| 数据合规 | 版权、个人信息、肖像、抓取来源 | 数据来源、是否含个人信息、清洗方式 |
| 下游滥用 | 二次打包、恶意微调、高风险接入 | 禁止用途、可接受使用政策、技术护栏 |
| 供应链 | 依赖许可证冲突、已知漏洞 | 依赖清单、许可证、安全公告、更新日志 |
3. 四个关键披露动作：从一句话免责到一套披露机制
风险盘点完之后，才是动笔写披露的时候。很多人上来就写“本软件不承担任何责任”，这句话不是没用，而是远远不够。真正有效的风险披露，至少包含下面四个动作。
3.1 README 模型卡：把“能力边界”放进项目门面
模型卡（Model Card）这个概念最早是学术圈提出的，现在已经成为开源AI项目的标配。它不是学术论文的附属品，而是普通用户下载模型前最先看到、也最容易理解的说明书。
一份合格的模型卡至少要回答这几个问题：这个模型是什么？用什么数据训练的？在什么评测基准上表现如何？已知的失败模式有哪些？适合哪些场景？不适合哪些场景？我见过写得很好的模型卡，甚至会在“已知限制”里列出几个具体的翻车输入样例，让用户直观看到模型在什么情况下会答错。
注意：模型卡不是 README 的复制品。README 讲“怎么跑起来”，模型卡讲“这个东西靠不靠谱、在哪儿不靠谱”，两件事别混在一起。
3.2 LICENSE 里的免责声明：从“AS IS”升级为场景化声明
大多数开源项目直接采用 MIT、Apache 2.0 这类现成许可证，里面自带一段免责条款。但这段条款是模板化的，它保护不了具体场景。真正有效的做法，是在 LICENSE 之外单独加一段“项目专属免责声明”。
这段声明里应该包含四个要素：披露主体（谁写的、谁来维护）、免责范围（对哪些类型的损失不负责）、已知风险（明确列出本项目当前已知的坑）、使用条件（使用者需要遵守什么前提）。下面是你可以直接改的模板：
免责声明（Disclaimer） 1. 本项目为开源研究性质，按“现状”（AS IS）提供，不附带任何明示或默示的保证。 2. 项目维护者不对模型输出的正确性、可靠性、安全性作任何承诺。模型可能产生错误、 偏见、有害或冒犯性内容，使用者须自行评估并承担使用后果。 3. 本项目不适合直接用于医疗、法律、金融、自动驾驶等高风险场景。如确需使用， 使用者必须进行独立的测试、评估和人工审核，并自行承担全部责任。 4. 已知限制与失败模式详见 MODEL_CARD.md。使用者应在使用前阅读并理解该文件。 5. 任何基于本项目的二次开发、微调、再分发，均须保留本声明，并对衍生行为负责。这段模板不是法律意见，但它把“告知义务”的颗粒度做到了具体的场景级别。真出事的时候，你能拿出证据证明：我不仅说了“后果自负”，我还说了具体哪里会出问题。
3.3 可接受使用政策：把“不能干什么”写死
可接受使用政策（Acceptable Use Policy）是很多开源AI项目缺失的一环。它的作用不是告诉用户“你能干什么”，而是把“你不能干什么”一条一条钉死。
以文本生成模型为例，至少应该明确禁止：生成或传播违法信息；生成可用于网络攻击、诈骗、钓鱼的内容；处理未授权的个人隐私信息；用于自动决策系统中的高风险决策；冒充特定身份进行欺骗。每一条禁用项都应该尽量具体，不要用“不得从事非法活动”这种万金油，那等于没说。
我建议把可接受使用政策单独做成一个文件，并在 README 顶部给出醒目的链接。很多用户在下载时会直接忽略长文档，但一个加粗的一行字“使用本项目前请阅读可接受使用政策”能大大降低“用户没看到”的争议概率。
3.4 发布与更新的披露时机：别只在首发时写一次
风险披露不是一次性工作。很多项目的披露失效，恰恰是因为只在首次发布时写了一份，之后模型更新、数据变更、依赖升级全都不同步。
模型更新之后，旧版本的能力边界和风险画像可能完全失效。你训练了一个更强的新版本，但新版本的失败模式、数据来源、评测结果都要重新披露。依赖库出现安全漏洞时，你需要在安全公告里同步更新披露信息，而不是悄悄升级了事。
我个人的习惯是：把“披露更新”当成发版流程的固定环节。每次发版之前，对照模型卡检查一遍——数据变了吗？能力边界变了吗？已知限制变了吗？有变化就改文档，再发布。这个习惯能帮你省掉很多售后麻烦。
4. 警惕“无效披露”：这些做法写了免责声明也救不了你
讲完正确做法，得泼几盆冷水。披露做对了能挡责任，做错了就是自欺欺人。下面这几种情况，属于典型的“写了也白写”。
4.1 故意或重大过失，披露挡不住
免责声明的保护范围是有边界的。如果你明知训练数据存在严重的版权问题还继续使用，明知模型存在可以被轻易利用的越狱漏洞却不修复，甚至故意在产品里埋后门，那任何披露都救不了你。
这不是法律预测，这是基本的生活逻辑：披露的本质是“我不知道且没有义务知道”的诚实说明，而“故意”两个字一出现，披露就从免责声明变成了自认证据。所以在做披露之前，先把自己的技术债还干净——该修的把漏洞修了，该换的脏数据换了，该加的过滤加了。披露是给一个已经尽力做好本分的项目再加一层保护，而不是给一个破罐子破摔的项目找借口。
4.2 披露内容和实际操作自相矛盾
这是最容易被忽略的坑。有些项目表面上披露做得很好看，实际上漏洞百出。最典型的矛盾是：免责声明里写着“不得用于医疗领域”，模型卡里却放了一大堆医疗领域的评测数据，下载页的广告语写着“医疗问答神器”。这种言行不一，在争议发生时会直接让披露的可信度归零。
法律实践中，裁判者看的是一个项目的“整体表现”，而不是文档里某一句漂亮话。你说你提示了风险，但你的宣传、你的评测、你的示例代码都在诱导用户往高风险场景用，那这份披露就是反噬你的证据。记住一条原则：披露说什么，你的项目行为和物料就得配得上什么，言行不一致的披露比不披露更危险。
4.3 披露的对象和语言搞错了
披露是给使用者看的，不是给搜索引擎看的。很多开源项目在 GitHub 仓库里放了一堆英文法律文本，但项目的主要用户是中文开发者，不少人根本看不懂，也懒得看。这种情况下，一旦出事，你说“我披露过了”，用户说“我根本不知道”，两边都有道理，但披露的实际效果为零。
有效的做法是：核心风险提示用目标用户最熟悉的语言，放在最容易看到的位置，用加粗、引用块、置顶评论等方式反复强化。你可以把英文的完整法律文本放在附属文件里，但 README 的第一屏、模型下载页的说明、文档的快速开始部分，必须用用户看得懂的语言把最核心的风险讲清楚。
4.4 模型更新后没有重新披露
前面讲披露时机时已经提到了这个问题，这里再强调一下它的严重性。假设你的 V1 模型训练数据是公开的、能力有限、风险相对可控，披露写得很完善。然后你发了 V3 版本，训练数据换成了大规模爬取的数据，能力大幅提升，但也出现了新的越狱风险。如果你没同步更新披露，用户手里拿的还是 V1 时代的说明，那这份说明对于 V3 来说就是一张废纸。
行业里对此越来越有共识：风险披露必须跟随模型版本走，旧版本有旧版本的披露，新版本有新版本的披露，二者不能混用。最简单的做法是在模型文件的发布说明里附上对应的披露版本号，确保模型权重和披露文档一一对应。
5. 落地清单：给开源AI仓库补上这套风险披露文件
最后，给打算立刻动手的读者一份可以直接照做的清单。不需要法律背景，跟着做就能把项目的风险披露从“一句话”提升到“一套机制”。
5.1 仓库文件结构
一个合规感拉满的开源AI仓库，推荐至少包含以下文件：
| 文件 | 作用 | 必须包含的内容 |
|---|---|---|
| README.md | 项目入口 | 一句话项目定位、风险提示链接、快速开始 |
| MODEL_CARD.md | 模型说明书 | 模型架构、训练数据、评测结果、已知限制 |
| LICENSE | 许可证 | 采用的开源许可证全文 |
| DISCLAIMER.md | 免责声明 | 场景化免责条款，可按第 3.2 节的模板改写 |
| AUP.md | 可接受使用政策 | 具体禁用场景、行为准则 |
| NOTICE.md | 第三方声明 | 依赖组件、数据来源、第三方许可证 |
| SECURITY.md | 安全公告 | 漏洞报告渠道、已知安全问题、修复计划 |
| CHANGELOG.md | 变更记录 | 版本变更、披露信息更新记录 |
这些文件最好用中英双语。中文保证目标用户能看懂，英文保证国际社区和后续可能的司法场景下的可读性。别嫌麻烦，一份双语模板只需要做一次，之后每次更新只是改内容，不是重写。
5.2 措辞的核心原则
写披露措辞的时候，记住三句话：具体优于笼统，场景优于概念，肯定优于否定。
具体优于笼统，是说“模型可能在长文本推理中出现事实错误”比“模型可能存在错误”有用；场景优于概念，是说“不建议用于医疗诊断、法律咨询、投资决策”比“不建议用于高风险场景”有用；肯定优于否定，是说“您在使用前必须阅读 MODEL_CARD.md”比“请勿忽略文档”有用。
一句话总结：让一个完全不了解AI的人，读了你的披露之后，能清楚地知道这个东西可能出什么问题、在哪儿最容易出问题、出事之后找谁。能做到这三点，这份披露就是合格的。
5.3 配套技术措施：披露不能只停留在文档
文档之外，还要有一些技术动作配合。比如在模型的推理接口里加输入输出的内容过滤，限制生成长度、设置敏感词拦截；比如在发布模型权重时附上哈希校验值，防止权重被篡改后责任说不清；比如提供使用反馈渠道，让用户能报告模型输出的问题——这不只是为了收集 bug，更是“我已建立风险响应机制”的证据。
技术措施和文档披露是一体两面的关系。文档披露回答了“你知道什么风险”，技术措施回答了“你为这些风险做了什么”。两者都齐全，才算得上完整的风险披露体系。只写文档不做防护，和只做防护不写文档一样，都是偏科的。
5.4 维护节奏
最后是维护节奏的建议。我建议每个项目至少做到：每次发版前更新模型卡和相关披露；每季度做一次依赖许可证和已知漏洞审查；在 README 的 issue 模板里增加“报告风险行为”的选项；收到安全反馈后及时更新 SECURITY.md。做到这四点，你的风险披露就不是一张静态的纸，而是一个活跃运转的系统。
拿我自己举例，最早给开源模型补模型卡的时候，内心是拒绝的，觉得又麻烦又没人看。后来坚持做了两三个版本之后，我发现最大的受益者不是用户，是我自己——写模型卡逼着我把数据来源、评测边界、失败模式一个个查清楚，很多潜在的问题在发版之前就被提前暴露了，社区里追着问“这个模型能不能用于XX场景”的私信也少了一大半。
风险披露这件事，说到底不是写给监管看的，是写给使用者看的，也是写给你自己看的。它是一份工程质量的体检报告，而不是一张事后甩锅的免责金牌。先把项目做干净，再把这套披露机制配齐，你手里的开源AI项目才能在合规的钢丝上走得稳一点。如果你正在维护开源AI项目，不妨今天就打开仓库，对照这份清单看看，还差哪几份文件。
地级市绿色数据中心DID2016-2025年)
