企业把大模型接进内部知识库，到底要不要备案？

声明：本文讨论的是基于公开法规与实务口径的适用范围判断方法与工程落地方式，不含任何产品推广，也不构成法律意见。涉及具体项目的结论，请以属地网信部门口径及属地最新要求为准。

0 先给结论

只向本企业员工开放、不向境内公众提供生成式人工智能服务的内部知识库，通常不适用《生成式人工智能服务管理暂行办法》，也就不需要办理生成式人工智能服务备案或登记。

但这句话的后半段更重要："不适用这部办法"只等于少填一张表，不等于免除其他责任。 数据合规、个人信息保护、商业秘密、等级保护、行业监管、生成合成内容标识、事故责任，一个都没有减少。

所以这个问题的正确答案不是"要"或"不要"，而是一条判断链：

1. 你的服务是否向境内公众提供？——决定《暂行办法》适不适用。
2. 如果适用，你的形态走备案还是走登记？——决定时间成本（备案通常 6–8 个月，登记通常 1–3 个月）。
3. 无论前两步是什么结论，哪些义务仍然躲不掉？——决定实际工作量。

绝大多数把这个问题问错的团队，都是跳过了第一步，直接问"备案还是登记"。这一步跳过，后面的答案必然错。

1 法条依据：豁免写在哪儿

判断这件事只有一个核心依据，先把它读准。

《生成式人工智能服务管理暂行办法》第二条

• 第一款：利用生成式人工智能技术向中华人民共和国境内公众提供生成文本、图片、音频、视频等内容的服务，适用本办法。
• 第二款：行业组织、企业、教育和科研机构、公共文化机构、有关专业机构等研发、应用生成式人工智能技术，未向境内公众提供生成式人工智能服务的，不适用本办法的规定。

第十七条：提供具有舆论属性或者社会动员能力的生成式人工智能服务的，应当按照国家有关规定开展安全评估，并按照《互联网信息服务算法推荐管理规定》履行算法备案和变更、注销备案手续。

第二十二条（术语）：生成式人工智能服务提供者，是指利用生成式人工智能技术提供生成式人工智能服务（包括通过提供可编程接口等方式提供生成式人工智能服务）的组织、个人。

从条文里可以直接读出三个要点：

第一，判断的核心变量是"服务对象"，不是技术、不是部署方式、不是模型来源。

模型是不是自研、有没有微调、部署在谁的机房里、跑在几张卡上——这些都不在适用条件里。条文里唯一决定适用与否的，是"向不特定公众提供"这个事实。

第二，豁免的主体范围写得很宽，企业明确在列。

"行业组织、企业、教育和科研机构……"——企业是被点名写进豁免主体里的。这不是法律漏洞，是立法者有意把企业内部应用排除在专项监管之外。

第三，豁免的条件是"未向境内公众提供"，而不是"没有对外收费"。

免费、内部、不赚钱，都不能单独构成豁免理由。真正要看的是：谁能用、怎么拿到账号、从哪能访问到。

还有个容易忽略的细节：第二十二条把"通过提供可编程接口等方式"明确算进"提供服务"。所以"我们只是提供 API，没有面向用户的界面"不构成豁免理由。

关于"备案"与"登记"的分野（只在前一步结论为"适用"时才有意义）：

这里有个实务中正在收紧的点，值得单独提醒：登记通道的前提是"未对模型做出影响生成内容的调整"。如果在此基础上做了私有语料注入（RAG）、输出逻辑改造、场景化定制，输出内容实质上由你的工程决定，那么登记的前提就站不住了，实务口径倾向于按独立生成式服务走备案。RAG 知识库恰好落在这一点上——这也是"内部知识库"这个问题为什么会被反复追问的原因。

2 第一步：什么算"向境内公众提供"

"公众"的法律含义是不特定多数人。判断的关键不是名单上有多少人，而是准入是不是由你控制、对象是不是特定。

我在项目里把它拆成四要素加一个加分项。

要素一：准入方式（账号从哪来）

要素二：对象身份（是"自己人"，还是有独立法律主体）

要素三：网络暴露面

仅内网 → 内网加 VPN → 零信任 → 公网可访问，暴露面逐步扩大。

这里有一个高频技术坑：公网不可访问，但域名可以从公网解析。安全上它拦得住访问，但在判断"是否向公众提供"时，它说明服务在架构上是按对外形态设计的。稳妥做法是域名解析同样限制在内部 DNS，不要出现"能解析但连不上"的中间状态。

要素四：内容出口

生成内容只在企业内部流转，与生成内容直接对外发布（营销物料、对外报告、公开文章），性质完全不同。后者会把生成合成内容标识义务一并带进来。

加分项：规模与传播可能性

内测、定向公测如果达到一定规模，实务中可能被视为已经开始提供服务。所以"我们还在内测"不是一张长期有效的免责说明，它只在规模确实可控、对象确实限定时成立。

判定结果只有四种

3 "内部"不是一个是非题，是一条光谱

这是最容易被简化掉的部分。实务中"内部"至少有以下七种形态，结论并不相同。

表里第 6 行是实务中最容易翻车的一格。做 B2B 不当然排除"向境内公众提供"：如果你的企业客户拿你的产品去面向不特定公众提供服务（客服类产品最典型），上游仍可能被认定为向境内公众提供服务。这时责任怎么分，需要在交付协议里写清楚，而不是靠"我们只卖给企业"这句话。

第 4、5 行还有一个技术性问题值得提前处理：多实例部署下的规模如何合并计算。你给十个客户各部署一套，每套一万用户，规模口径是按单实例算还是合并算？属地或行业口径如果设有用户规模阈值，这个问题要在交付协议里先约定，不要等到申报时才谈。

4 五个"以为不用、其实要"的场景

场景一：给客户用的"内部版"知识库。 客户把这个知识库接进自己的客服系统，面向它的用户。你的身份已经从"内部工具"变成链条上的一环。

场景二：只在内部用，但生成内容要对外发布。 员工用知识库生成营销文案、对外报告、公开文章——服务没对外，内容出去了。生成合成内容标识义务随之而来。

场景三：邀请制公测、免费试用。 "免费"不是豁免理由，"内测"也不是长期状态。规模一旦上来，实务中就视为已开始提供服务。

场景四：封装第三方已备案模型再对外。 上游已备案，不等于你有备案身份。调用方只要面向公众提供，就是"服务提供者"，需要独立办理登记或备案。

场景五：我们只是提供 API。 第二十二条已经把"通过提供可编程接口等方式"明确纳入"提供服务"。

5 三个"以为要、其实不用"的场景

场景一：员工用通用大模型办公。 写文案、翻译、整理会议纪要——企业在这一关系中是使用者，不是提供者。但这不代表没有义务：员工把哪些内容贴进了公网模型，本身就是个人信息处理行为。

场景二：封闭内网、只开给员工的知识问答工具。 这正是第二条第二款直接覆盖的情形。

场景三：企业内部代码助手，代码不入库、不外发。 同上，属于内部研发应用。

顺便说一句：这三个场景"不需要备案"，但第 6 节列的义务一个都不能省。很多团队把"不用备案"听成了"不用管"，这是两回事。

6 不备案 ≠ 无义务：躲不掉的六类责任

这一节值得单独强调。实务中存在一种很典型的心理：既然法律给了"不面客就不专项监管"的口子，那内部系统就可以不设防。这个推论是错的——豁免只是"少填一张表"，不是"免责牌"。

第一，数据安全与个人信息保护。 《网络安全法》《数据安全法》《个人信息保护法》照常适用。内部系统同样要做数据分类分级、权限管控、处理告知与同意。员工把包含客户身份证号、银行卡号的表格粘进公开模型换取"格式整理建议"，在法律评价上就是向他人提供个人信息，并不会因为员工的主观目的是办公而改变性质。

第二，商业秘密与知识产权。 知识库的语料从哪来？合同、标书、源代码、客户名单进了语料，授权链在哪？这是内部知识库最现实的风险点，也是对外交付时最容易引发纠纷的地方。

第三，网络安全与等级保护。 等保测评、日志留存（网络日志留存不少于六个月）、访问控制，与是否面客无关。

第四，行业监管。 金融、能源、政务、医疗等行业对内部系统有独立的数据保护与审计要求，不会因为"不对外提供服务"而放松。银行内网运行的模型仍需通过等级保护测评与行业科技风险审查。

第五，生成合成内容标识。 一旦生成内容对外发布，标识义务随之而来。标识要在导出、复制、转发后仍然保留。

第六，事故责任。 内部模型泄露客户信息、误删生产数据、输出被篡改导致业务决策错误——相关责任主体无从逃脱，安全生产、刑事法律中均设有相应条款。

有两个公开报道的行业案例能说明内部场景的风险形态，很值得放进评审材料里讲：

• 某银行员工为获取"按格式整理"的建议，把一份包含客户身份证号码与银行卡号的表格粘贴到公开模型对话窗口，数据由此出境，所在机构在此之前并不知情。
• 某制造企业把一个已被植入恶意代码的 RAG 知识库接入全员问答助手，在没有人直接操作模型的情况下，错误指令被悄然执行，内部问答内容被篡改数百次。

第二个案例特别值得注意："内部"的风险形态与面向公众的服务正好相反——暴露面小，但攻击面深，且没有外部监管压力和用户投诉来倒逼你发现。 外部服务出问题会被投诉、被通报；内部服务出问题，往往是几个月后从一份对不上的报表里被发现。

7 工程实现：把"适用范围判定"做成系统能力

前面讲的是判断方法。这一节讲怎么让它不依赖某个人记得住。

核心思路：适用范围判定不是一次性的法律意见，而是一个有输入、有规则、有留痕、有触发器的系统能力。

原因很简单：这个结论会变。今天是纯内部，明天市场部要开给经销商，后天要做免费试用——每一次变化都会让结论失效，而做出这些决定的人通常不会想到去通知合规。

7.1 判定输入：部署姿态台账

把判断需要的事实固化成一份可审计的台账，放在配置中心里，跟着服务走。

7.2 判定规则：把结论写成可执行的条件

判定规则写成声明式，好处是改口径时只改配置、不改代码，而且每次判定的依据可以原样留档。

注意最后那条 default：规则没覆盖的组合一律转人工复核，不做默认放行。 这与内容审核里的 fail-closed 是同一个原则——适用范围判定的错误代价，比多问一次高得多。

7.3 变更触发器：让结论跟着事实走

把会推翻结论的动作，全部登记成触发器。

其中 T1 到 T4 是 P0，因为它们单独一条就足以把结论从"不适用"翻到"适用"。T6 单独说一下：模型迭代或大规模微调之后，备案信息需要更新，不能沿用旧编号，这一点在内部知识库切换底座模型时最容易被忘。

7.4 数据出口控制：内部知识库的真正风险在这里

对内部知识库来说，"是不是要备案"是低频问题，"数据会不会从看不见的地方出去"是高频问题。控制点要成对做：入口拦粘贴，出口审外发。

7.5 证据链：把"我们判断过"变成"我们能证明我们判断过"

监管检查时，需要的不是你今天的结论，而是你在什么时候、基于什么事实、按什么规则得出的结论。

8 一页纸结论模板（可直接改）

关于 XXX 知识问答助手适用范围的结论 判定日期：2026-09-14｜判定人：XXX｜规则版本：scope-rules 2026-09 一、事实：本服务私有化部署于公司内网，仅面向在册员工（1800 人）及受服务合同约束的外包人员（120 人）开放，账号由管理员按名册开通、随人事变动回收；域名仅内部 DNS 可解析；生成内容仅在公司内部流转，导出功能已保留来源标识。 二、结论：本服务未向中华人民共和国境内公众提供生成式人工智能服务，依据《生成式人工智能服务管理暂行办法》第二条第二款，不适用该办法，无需办理生成式人工智能服务备案或登记。 三、仍然适用的义务：网络安全等级保护、数据分类分级与个人信息保护、商业秘密与语料授权管理、访问日志留存（不少于六个月）、行业监管要求。 四、结论失效条件（出现任一情形须重新判定）：向任何外部主体开放账号；域名可从公网解析或服务公网可达；开放自助注册或公开试用；生成内容对外发布；更换底座模型或大规模微调；接入新的私有语料源。

第四部分是这份模板真正的价值所在。一份只写"我们不需要备案"的结论，价值接近于零；一份写清"什么情况下这个结论会失效"的结论，才是可以拿去做工程约束的东西。

9 上线前检查清单（24 项）

A 判定与留档（4 项）

• [ ] 部署姿态台账已建立且与实际一致
• [ ] 适用范围结论已出具一页纸并留档
• [ ] 结论中列明了失效条件
• [ ] 结论有明确的责任人与复核周期

B 访问面（5 项）

• [ ] 账号开通走名册或 SSO，无自助注册入口
• [ ] 无任何外部法律主体在账号清单中，或已逐案评估
• [ ] 域名不可从公网解析，服务不可从公网直连
• [ ] 离职、转岗、合作终止的权限回收有自动化流程
• [ ] 外包、劳务人员的访问范围有单独管控

C 数据与内容（5 项）

• [ ] 语料来源与授权链可追溯
• [ ] 敏感字段在语料入库前完成标记与处置
• [ ] 员工粘贴到外部模型的行为有检测与阻断
• [ ] 输出涉及个人信息时有脱敏策略
• [ ] 删除请求能覆盖长期记忆、向量库、缓存、备份与日志副本

D 标识（3 项）

• [ ] 生成内容用于对外发布时附生成合成内容标识
• [ ] 导出、复制的对话内容保留标识
• [ ] 标识在二次转发后不丢失

E 变更管理（4 项）

• [ ] 开放外部账号已登记为 P0 触发器
• [ ] 服务暴露到公网已登记为 P0 触发器
• [ ] 开放注册/试用已登记为 P0 触发器
• [ ] 更换底座模型或大规模微调会触发备案信息复核

F 证据链（3 项）

• [ ] 判定输入、规则版本、命中记录三者可回溯到同一时点
• [ ] 访问日志留存不少于六个月
• [ ] 模型备案信息与调用协议已归档

10 六个反模式

反模式一：把"内部"当成一个不需要证明的状态。 "我们只在内部用"往往是一句口头描述。判定要的是账号台账、网络边界、对象清单，不是印象。

反模式二：用"免费"或"内测"当豁免理由。 豁免条件写的是"未向境内公众提供"，与是否收费、是否正式发布无关。

反模式三：认为上游已备案就可以套用。 调用方只要面向公众提供，就是服务提供者，需要独立办理登记或备案。

反模式四：跳过第一步直接问"备案还是登记"。 这等于把"适不适用"和"走哪条轨"两个问题混成一个，得到的答案必然不准。

反模式五：只做一次判定，不做变更触发。 结论会随产品变化失效。没有触发器的判定，等于没有判定。

反模式六：把"不用备案"听成"不用管"。 这是本文最想纠正的一条。豁免的是专项监管程序，不是数据、个人信息、行业监管与事故责任。

11 与其他制度的关系

12 FAQ

Q1：只给员工用，员工几千人，还算"特定"吗？ "特定"的判断依据是准入是否由你控制、对象是否有确定范围，不是人数。按名册开通、随人事变动回收，对象是可确定的。但如果人数增长到失去名册管控（例如开放给所有合作方人员自助申请），性质就会变。

Q2：外包、劳务派遣人员算不算"公众"？ 通常偏特定，前提是你能说明合同约束与权限管控方式。稳妥做法是把这类人员的访问范围单独管控，并在结论里写明依据。

Q3：给经销商开的账号算不算对外提供？ 需要逐案判断，并且倾向从严。经销商是独立法律主体，它可能代表自身对外使用，也可能把你的服务再对下开放。建议单独做一次判定并留档，不要并入员工范围一起处理。

Q4：我们只提供 API，能不能豁免？ 不能。第二十二条明确把"通过提供可编程接口等方式"纳入提供服务。

Q5：客户买了我们的私有化部署，自己内部用，我们要不要备案？ 交付方通常不是服务提供者，但可能构成技术支持者。关键在交付协议里把角色、面向公众的责任归属、以及多实例规模如何计算写清楚。

Q6：内部知识库接了 RAG，会不会影响判定？ 对"是否适用"这一问没有影响（纯内部仍不适用）；但如果服务本身面向公众，RAG 会直接影响"走备案还是登记"——私有语料注入属于影响生成内容的调整，登记前提可能不再成立。

Q7：模型换了底座，需要做什么？ 重新判定适用范围，并复核备案信息。模型迭代或大规模微调后不能沿用旧备案编号。

Q8：结论要多久复核一次？ 建议设常规复核周期，同时用第 7.3 节的触发器做事件驱动复核。实务中事件驱动比周期复核更有效，因为结论失效通常是被某个产品动作触发的。

13 结语

回到最初的问题。

"企业把大模型接进内部知识库，到底要不要备案？"

答案取决于三件事，而且必须按顺序问：

第一，服务对象是谁——如果只有受管控的员工，未向境内公众提供，通常不适用，不需要备案或登记。这一条有明确的法条依据。

第二，如果对外提供了，走哪条轨——自研或微调走备案，预留 6–8 个月；调用已备案模型且未做影响生成内容的调整走登记，约 1–3 个月。RAG 注入私有语料属于影响生成内容的调整，会动摇登记前提。

第三，无论前两步结论如何，哪些义务仍然在——数据、个人信息、商业秘密、等保、行业监管、内容标识、事故责任。豁免的只是"少填一张表"。

最后一句工程上的判断：适用范围判定应该是一个系统能力，不是一次法律意见。 因为结论会随产品变化失效，而触发变化的动作（开放外部账号、切公网、开试用、换模型）通常发生在工程和市场的手里，不在合规的手里。把判定输入做成台账、把规则做成配置、把变更做成触发器、把过程做成证据链——这四件事做完，"要不要备案"这个问题就不再依赖某个人记得住了。

本文为公开法规与实务口径下的判断方法整理，不构成法律意见；具体项目请以属地网信部门口径为准。文中提到的行业案例来自公开报道，未指向具体主体。