误解一：用模型就要备案
备案针对面向境内公众提供生成式服务的提供者。企业内部的文档助手、代码补全通常不在此列，一旦开放给外部用户使用，性质就变了。判断的关键是服务对象与实际开放范围，而不是有没有用大模型，误判会直接影响预算投向。边界在于内部开放与对外服务的义务清单并不相同。
误解二：开源模型责任更轻
开源只改变获取方式，不改变使用者的义务。语料合法性、内容标识与个人信息处理仍由使用方承担，模型许可协议也不能对抗监管要求。把开源当免责理由，是最容易在检查中失分的一类想法，也会削弱内部对合规判断的信任。为什么这种想法危险：责任不会因为开源而转移。
误解三：加免责声明就够
标识要求包含显式提示与隐式元数据，且不得删除篡改。一句页面底部的免责声明既不显式也不可追溯，起不到标识作用。真正的边界是：标识解决可识别性，不解决内容真实性与侵权责任，两者要分别取证。
误解四：合规是法务一个部门的事
法务能判条款，但语料在业务手里、日志在 IT 手里、发布在运营手里。没有业务与技术配合，合规只能停在意见层面。可行做法是设跨部门小组并指定单一联络人，把判断变成可执行的检查项，否则推动时无人真正负责。怎么推动：先挑一个高频场景跑通，再逐步扩面。
误解五：过了等保就等于合规
等保测评覆盖系统与网络的安全基线；生成式 AI 还涉及语料、标识、算法与个人信息等专门要求。两者是并列关系，不能互相替代，审计时分别取证，客户尽调往往同时索要两类材料，缺一类就要临时补。边界在于两者覆盖的风险范围并不相同。
适用与不适用
适合谁
- 被各种合规说法困扰、需要判断优先级的负责人
- 正在做合规预算与范围论证的企业
- 需要向业务解释为什么不能走捷径的合规人员
不适合谁
- 期望找到一条通用捷径、不愿区分场景的企业
- 把合规理解为一次性拿证、拿完就结束的项目
典型场景
某企业的业务部门听说同行 AI 客服做了备案，要求 IT 也去办。合规负责人先确认该系统只对内部员工开放，判定不触发备案，转而要求补语料授权说明与对话字段脱敏，并把结论写进评审记录，在季度会上同步给业务线负责人，避免下次重复讨论。
可执行步骤
- 收集内部流传的合规说法，逐条标注出处与适用条件，区分法规要求与同行做法
- 对每条说法补上例外情形，特别是服务对象、开放范围与数据流向三个变量
- 按本企业业务形态判断是否适用，形成一页书面结论并注明判断依据，并附适用条款出处
- 把结论沉淀为内部问答与评审检查项，减少同类问题在部门之间反复讨论
- 对确实适用的条款排整改计划，明确责任人与完成期限，每季度复核一次
常见坑
- 拿同行做法当标准，忽略业务形态与服务对象差异，方案照搬后落地即失效，还要重新解释一遍，方案还得重做一轮
- 把免责声明当成标识方案，检查时无法举证，也说不清标识的位置与形式，客户追问时更被动，事后也无法追溯
- 用等保测评报告覆盖所有合规问题，评审时被逐条追问，反而拖长项目周期，信任也被消耗，客户尽调也会扣分
- 结论只存在个人记忆里，换人后重新争论一遍，判断标准随人而变，交接成本很高，评审结论难以复用
自检与验收清单
- 每条说法是否标注了适用条件，并与例外分开写
- 结论是否有书面记录，是否有审批人签字确认，可追溯
- 是否区分了系统安全要求与 AI 专门要求，并分别取证归档
- 对外口径是否与内部判断一致，有无单独的对外版本
常见问题
同行做了备案，我们是否也要做？
取决于服务是否面向境内公众。内部系统与对外产品的义务不同，建议先写清服务对象、开放范围与内容形态，再对照条款判断，必要时向主管部门或专业机构确认，不要照搬同行结论。
加了 AI 提示还会被追责吗？
提示只解决可识别性，不免除内容真实性与侵权责任。对外发布的营销、报告类内容仍需人工复核与责任人签认，出现问题时企业仍要承担相应后果，不能以已标注为由抗辩。
合规能不能一次性做完？
很难。模型、业务与监管都在变，合规更像持续运行的机制：定期复审、事件触发复审、留痕可查。把它当成项目一次交付，通常半年后就与现状脱节，反而制造虚假安全感，也无法应对新的检查要求。