模板
AI 政策模板：适用于工作的实用可接受使用政策
有效的 AI 政策会告诉员工现在可以做什么、哪些事项需要批准、哪些行为被禁止，以及答案不明确时由谁决定。下面的模板是运行起点，并非法律意见。请根据组织的合同、司法管辖区、数据分类、用工实践、安全计划和实际工具进行调整。
研究与披露: 本模板参考了 NIST AI 风险管理框架、NIST 生成式 AI 配套框架和 OECD AI 原则，资料复核日期为 2026 年 9 月 4 日。本文为原创编辑材料，必须由组织的法务、隐私、安全、人力资源和业务负责人审查。
可复制并调整的 AI 政策模板
标题：负责任的 AI 可接受使用政策
负责人：[角色或团队]
生效日期：[日期]
审查日期：[日期]
1. 目的
本政策定义工作人员如何为[组织]评估、采购、构建和使用 AI 系统。
适用于使用组织数据或代表组织行事的员工、承包商和供应商。
2. 已批准用途
工作人员可以将批准工具登记表中的工具用于[列出的低风险用途]。
必须遵循下文的数据、审查、归因和记录保存规则。
3. 需要批准的用途
在使用 AI 作出会影响就业、资格、安全、法律权利、财务、客户、
公开声明、受监管记录或生产系统的决定或输出之前，必须获得[角色]批准。
4. 禁止用途
不得使用未经批准的工具、绕过访问控制、冒充他人、伪造证据、
在没有责任人的情况下作出具有后果的最终决定，也不得提交该工具
未获准处理的数据类别。
5. 数据处理
遵守现有数据分类政策。除非具体工具和用途已经批准，否则不得输入凭据、
受限个人数据、客户机密数据、源代码、合同或未公开财务信息。
6. 人工审查
指定负责人必须在使用或分享输出前，核实重要事实、来源、计算、权利、
偏差风险和必要披露。
7. 透明度与归因
当法律、合同、平台规则、专业标准或组织惯例要求时，披露实质性的 AI 协助。
不得将 AI 响应引用为事实声明的来源。
8. 采购与开发
采用前记录目的、负责人、数据流、供应商、保留期限、训练用途、
安全控制、失败模式、评估和退出计划。
9. 记录与事故
保存该使用场景要求的记录。发现意外披露、有害输出、政策绕过、重大错误
或未授权操作后，应在[时间]内报告至[事故渠道]。不得隐瞒或静默修正事故。
10. 例外与执行
[角色]可以批准一项包含范围、控制措施、负责人和到期时间的限时书面例外。
违规行为按照现有安全和行为政策处理。添加风险分级表
| 级别 | 示例 | 默认规则 |
|---|---|---|
| 低 | 使用公开信息进行头脑风暴 | 使用已批准工具并接受常规审查 |
| 中 | 根据公司数据起草内部分析 | 使用已批准数据路径、指定审查者并保存来源 |
| 高 | 就业、信贷、法律、健康、安全或公开声明 | 正式评估并由责任人批准 |
| 禁止 | 欺骗、非法歧视、共享凭据、绕过控制 | 不得使用 |
风险取决于具体语境，而不是工具标签。总结公开文章和筛选求职者可能使用相似技术，却需要完全不同的控制措施。
定义员工会使用的术语
如果日常工作无法映射到政策词汇，这项政策就会失效。应加入简短定义：
- **AI 系统：**使用机器学习或生成模型来生成、分类、预测、推荐、提取或执行操作的软件；
- **已批准工具：**针对规定用途和数据类别获得批准的具体服务、套餐、配置和集成；
- **AI 辅助输出：**由 AI 系统进行实质性起草、转换、分析或推荐的工作；
- **后果性决定：**影响就业、访问、资格、权利、安全、财务、客户或其他重大利益的决定；
- **责任人：**对最终使用或操作拥有权限并承担责任的人；
- **受限数据：**因政策、合同、法律或安全分类而受到处理限制的信息；
- **人工审查：**依据既定标准进行真实检查，而不是在无法查看证据时点击批准；
- **事故：**意外披露、有害或歧视性输出、重大错误、控制绕过、未授权操作或其他政策违规。
这些定义应与公司现有语言一致。如果安全和隐私计划已经定义机密数据或事故严重程度，不要另建一套不同含义。
分配角色和决策权
| 角色 | 最低职责 |
|---|---|
| 高管负责人 | 设定风险容忍度、解决重大例外、为实施提供资源 |
| 政策负责人 | 维护政策、示例、工具登记表、培训和审查日历 |
| 业务负责人 | 定义使用场景、结果、审查者和可接受失败水平 |
| 安全团队 | 审查身份、访问、集成、日志、测试和事故响应 |
| 隐私团队 | 审查个人数据、目的、最小化、保留和个人权利 |
| 法务或合规 | 审查适用义务、合同、披露和高影响用途 |
| 采购团队 | 保存供应商承诺、分包处理者、续约和退出条款 |
| 人力资源 | 负责员工沟通、培训和就业相关用途 |
| 用户 | 遵守批准范围、审查输出、保护数据并报告事故 |
为每条审批路径指定决策人，而不只是一个群组。跨职能委员会可以提供建议，但员工需要知道谁可以回答“批准”“拒绝”或“暂不批准”。
维护已批准工具登记表
将变化较快的产品详情放在核心政策之外的受控登记表中：
| 字段 | 需要达到的具体程度示例 |
|---|---|
| 产品 | 供应商、产品、企业套餐和已批准账户类型 |
| 负责人 | 负责配置和续约的团队 |
| 允许用户 | 指定群组或角色 |
| 允许用途 | 起草公开内容；在限定来源下总结内部资料 |
| 允许数据 | 公开和一般内部数据；不含受限个人数据 |
| 集成 | 仅限已批准的存储和身份连接 |
| 训练用途 | 合同约定和配置状态 |
| 保留 | 默认值、配置值和删除流程 |
| 必要审查 | 作者审查；指定输出需要专家审查 |
| 禁止操作 | 不得发送、发布、删除或更改记录 |
| 批准日期 | 决策记录和批准人 |
| 审查日期 | 定期复审或合同事件 |
批准应附着于具体配置和用途，而不是品牌名称。消费者账户、企业账户、API 部署、浏览器扩展和连接操作功能可能具有不同的数据处理方式和权限。
将数据分类与工具使用连接起来
根据组织现有分类调整以下矩阵：
| 数据类别 | 默认 AI 规则 | 可能的例外 |
|---|---|---|
| 公开 | 可以使用已批准工具 | 常规内容和权利审查 |
| 一般内部 | 使用已批准的托管工具 | 目的、访问和保留控制 |
| 机密 | 除非明确批准，否则拒绝 | 具有合同和技术控制的指定工作流 |
| 受限个人数据或受监管数据 | 必须进行高风险评估 | 仅限明确批准的系统、目的、字段和审查者 |
| 凭据和认证秘密 | 不得输入提示词或追踪记录 | 使用专用秘密管理，而不是政策例外 |
派生数据也必须纳入范围。即使删除附件，提示词也可能暴露客户关系。文件名、摘要、嵌入、日志、工具参数和截图都可能继承来源的分类级别。
为操作和 Agent 添加规则
生成式工具正在从起草转向执行。政策必须延伸到内容之外：
AI 系统只有在满足以下条件时，才可以执行外部操作或更改记录系统：
- 操作属于已批准使用场景；
- 凭据被限制在最低必要权限；
- 允许的目标、金额、频率和时间窗口受到约束；
- 系统验证输入并防止重复执行；
- 后果性操作需要授权角色批准；
- 操作和批准均被记录；
- 已测试停止、撤销和恢复路径。把发送、发布、采购、删除、授予访问、更改记录和联系人分别视为独立权限。允许起草电子邮件并不代表允许发送。
创建高风险用途评估
批准高风险用途前，要求提供一份简短记录：
业务目的和预期收益：
受影响人员和决定：
责任人：
AI 角色和人工权限：
输入、输出、数据类别和数据流：
供应商、模型、集成和版本：
已知限制和可预见误用：
准确性、公平性、可访问性、隐私和安全评估：
告知、解释、申诉和纠正机制：
监控和事故阈值：
记录与保留：
回滚和替代流程：
批准人、条件、到期时间和下次审查：批准不是永久性的。将其范围限制在已测试的工作流、人群、数据和配置。出现新模型、新操作能力、新集成、新人群或新决策目的等重大变化时，应重新评估。
处理例外但不制造漏洞
一项例外应说明请求内容、业务理由、为何没有可用替代方案、数据、用户、控制措施、负责人、开始时间、到期时间和批准人。设置时间限制并防止静默续期。紧急访问应按照既有流程接受事后审查。
不要因为工作已经开始或供应商试用即将结束就批准例外，那会奖励绕过政策的行为。跟踪重复请求，它们可能说明已批准工具集合不足，或者规则不够清晰。
添加 AI 事故响应手册
1. 在安全可行时停止或隔离受影响工作流。
2. 保存相关输入、输出、版本、操作和访问记录。
3. 通过指定渠道通知事故负责人。
4. 识别受影响人员、系统、记录和下游接收者。
5. 根据需要限制访问、撤销凭据或撤回输出。
6. 让安全、隐私、法务、HR、沟通或业务负责人参与。
7. 在需要时修正记录并通知受影响方。
8. 记录原因、控制缺口和纠正措施。
9. 将失败加入培训、评估或监控。
10. 风险重大时，在重新启动前重新授权工作流。AI 政策应该引用现有事故处理计划，而不是另建一套严重程度标准。需要改变的是必须保存的证据：模型和提示词版本、来源上下文、工具调用、批准和生成的交付物。
实施检查清单
- 盘点实际 AI 使用情况，包括免费浏览器工具和嵌入式功能。
- 使政策与现有安全、隐私、记录、采购和行为规则一致。
- 发布包含允许数据类别和使用场景的已批准工具登记表。
- 为工作人员提供快速提问和申请新工具的路径。
- 使用贴近现实的允许、需批准和禁止示例进行培训。
- 记录例外事项的负责人和到期日期。
- 每季度审查事故、供应商变更和高风险用途。
不要只依赖每年一次的确认书。只有当政策出现在采购、入职、工作流设计和审查清单中时，它才真正有用。
用决策而不是定义进行培训
向员工提供简短场景：
- 销售人员能否把客户合同粘贴到免费助手中，以总结续约日期？
- 营销人员能否依据当前官方来源生成产品对比？
- 经理能否让 AI 对员工晋升进行排名？
- 开发人员能否提交可能包含凭据的生产错误日志？
- 助手能否起草会议摘要并自动分配任务？
针对每个场景，询问其中涉及哪个工具、哪些数据、哪位审查者、什么操作和什么记录。培训的成功标准是员工选择正确路径并知道向谁询问，而不是背出一条定义。
在决策发生的位置加入政策提醒，例如采购表单、浏览器访问、数据分类标签、工作流模板、发布检查清单、代码审查和事故接收渠道。
衡量政策是否有效
有用的信号包括：
- 已记录且指定负责人的活跃 AI 工具比例；
- 按风险级别统计的审批周转时间；
- 具有当前有效评估的高风险用途比例；
- 未批准工具和受限数据事件；
- 按政策模糊领域分类的员工问题；
- 按原因、负责人和时长统计的例外；
- 事故、险情、修正时间和重复原因；
- 已批准高风险工作流的评估与监控覆盖率；
- 场景式培训完成情况。
不要把问题数量为零设为目标。提问可能说明人们在风险发生前暂停了操作。更健康的目标是快速、一致地解决问题，并减少反复出现的歧义。
政策维护日历
| 频率 | 审查内容 |
|---|---|
| 每月 | 工具登记表变更、即将到期的例外、重大事故 |
| 每季度 | 高风险使用场景、重复问题、供应商和集成变更 |
| 每年 | 核心政策、角色、培训、风险容忍度和相关政策 |
| 事件触发 | 新法律、合同、模型、能力、数据用途、人群或事故 |
发布变更日志。对于重大变化，应确定哪些现有使用场景必须重新评估，不要假设新规则无需实施工作就能自然覆盖它们。
如需具体场景，请参阅 AI 使用政策示例。对于技术威胁边界，请将这份政策与 AI Agent 安全清单结合使用。
常见问题
小公司可以使用这份 AI 政策模板吗？
可以，但必须明确责任归属。包含一份批准工具清单、清晰数据规则和容易联系的决策人的短政策，比无人能够执行的长政策更有效。
政策应该禁止在所有 AI 工具中使用机密数据吗？
政策应该禁止在未经批准的工具中使用机密数据。获得批准的企业系统可能根据合同和控制措施处理特定数据类别，但这些权限应按工具和使用场景记录。
谁应该负责 AI 政策？
由一名承担责任的高管负责，并接受法务、隐私、安全、人力资源、采购和业务部门的意见。没有决策人的委员会只会造成延误和歧义。
AI 政策应该多久更新一次？
按照固定周期审查，并在重要工具、法律、合同、事故或高风险用途变化时更新。批准工具登记表应该比核心政策更容易更新。
这份模板属于法律意见吗？
不属于。它只是一项运行起点。必须由具备资质的法律顾问和相关专家根据适用法律、合同、用工实践、受监管活动和司法管辖区进行调整。
员工应该披露每一次 AI 使用吗？
披露应遵守适用法律、合同、专业义务、平台规则和组织惯例。政策应该规定何时需要内部记录和外部通知，而不是使用一条模糊的统一规则。
公司可以批准整个类别的 AI 工具吗？
广泛的类别批准存在风险，因为不同套餐、配置、集成、保留和操作权限并不相同。应针对规定的数据和用途批准具体服务与配置，并设置审查日期。
使用 Ottermind 将已批准政策、工具登记表和审查规则转换为可复用的项目上下文，再让团队开始制作交付物。
