AI安全管理制度要写什么：一份可执行的框架与落地步骤
AI安全管理制度不是一份写满原则的文件，而是一组能落到具体动作上的规则：谁能用模型、能传什么数据、出了问题谁处理、日志留多久。
如果制度发布后没人能照着执行，它就只是文档。
下面给出一份可直接套用的框架，以及发布前后的检查方法。
先明确制度管的是谁、管什么
起草前先划清边界，否则条款会写得过宽或过窄。
建议先回答三个问题：
- 适用对象：是全体员工、研发团队，还是只针对接入模型接口的业务系统。内部使用和对外提供服务的风险不同，条款应分开写。
- 覆盖范围：包括哪些模型入口，例如自建推理服务、公有云模型 API、办公场景中的对话工具。
- 责任角色：明确制度归口部门、模型接口负责人、数据提供方和应急联系人。没有具体角色，条款很难追责。
这一步的产出通常是一张清单，列出系统名称、负责人、数据敏感级别和对外暴露情况，后续条款都围绕这张清单展开。
制度条款的六个必备部分
数据分级与输入限制
按敏感程度把数据分成几档，并写明每一档能否输入模型。
例如客户身份信息、密钥、未公开的财务数据属于禁止输入类；
公开资料和脱敏后的测试数据可以输入。
条款要写成可判断的表述，而不是“注意保护敏感信息”这类空话。
同时明确脱敏要求：需要输入业务数据时，先去掉姓名、手机号、证件号等字段，并保留脱敏记录。
账号与权限管理
模型接口不应共用一把密钥。
制度中应规定：按业务或人员分配独立凭证，离职或转岗及时回收，密钥不得写入代码仓库和前端代码。
可以配合下面的检查项：
# 检查代码仓库中是否误提交密钥
grep -rn "sk-" /path/to/repo --include="*.py" --include="*.js"发现硬编码密钥时，先轮换密钥，再清理提交记录，不能只删掉当前文件。
调用日志与留存
制度要写明记录哪些字段、保存多久、谁能查看。
常见字段包括调用时间、调用方标识、模型名称、输入输出摘要和异常标记。
日志本身可能含敏感内容，因此要规定日志的访问权限和脱敏方式，避免日志成为新的泄露点。
输出审核与使用边界
模型输出不能直接作为对外结论发布。
制度中应区分场景：面向客户的文案、合同条款、技术方案等需要人工复核；
内部辅助写作可以抽查。
同时写明禁止行为，例如用模型生成虚假证明材料、绕过审核直接对外发送。
异常处置与应急响应
提前写清发现滥用、泄露或异常调用时的动作顺序：先停用相关凭证或关闭接口，再保留日志，随后通知负责人并评估影响范围。
制度里给出联系人和升级路径，比事后临时找人更有效。
培训与定期复查
规定新员工入职培训和年度复查，复查内容包括账号清单、密钥轮换记录、日志留存情况和制度条款是否仍匹配现有系统。
复查结果留档，便于后续调整。
发布前后的落地检查
制度写完后，用几个可验证的动作确认它真的能执行：
- 随机找一名使用者，看能否说清自己可以用哪些数据、遇到异常找谁；
- 抽查模型接口是否存在共用密钥，密钥是否可追溯到具体负责人；
- 检查日志是否按制度要求的字段和期限留存，能否按调用方检索；
- 模拟一次异常调用，看停用凭证和通知流程是否按制度走通。
检查中发现的问题应回写到制度或系统配置中，而不是只做一次口头提醒。
容易踩的几个坑
- 只写原则不写动作：例如只写“加强数据保护”，没有说明哪些数据不能输入、由谁判断。
- 制度与系统脱节：制度要求独立密钥，但实际接口仍共用一把，执行时无从查起。
- 日志留存与隐私冲突：日志记录完整输入输出却未限制访问，反而扩大风险。
- 一次写完不再更新：新增模型入口或业务系统后，适用范围和负责人没有同步调整。
常见疑问
制度需要多细？ 以新员工能照着判断“这件事能不能做”为标准，不必写成操作手册，但关键限制要给出判断条件。
小团队也要写吗？ 只要在使用模型处理业务数据，就建议至少覆盖数据输入限制、账号权限和异常联系人三部分，篇幅可以短，但要能执行。
制度和技术配置哪个优先？ 两者配合：制度定规则，技术手段负责强制执行，例如接口鉴权、限流和日志采集，缺一不可。
制度的价值在于被使用。
建议先按上面的框架写出初版，再通过一次实际检查验证条款是否可执行，根据结果逐步补充，而不是等到出问题才回头修订。
