AI 使用政策示例：员工真正能执行的 14 条规则

好的 AI 使用政策示例会说明真实任务、允许使用的工具和数据、必要审查，以及必须由人承担责任的节点。“负责任地使用 AI”不是可执行指令。下面 14 个示例展示如何把宽泛原则转化为适用于日常工作的规则。

研究与披露: 这些示例参考了 NIST AI 风险管理框架核心、NIST 生成式 AI 配套框架，以及 2026 年 9 月 4 日 Google 美国 SERP 中公开的职场政策模式。它们是原创示例，不属于法律意见，也没有复制任何雇主政策。

1. 使用公开信息起草内容

**允许：**使用已批准的 AI 工具，根据公开来源为非机密内容制作提纲或进行编辑。

**必须：**作者核实声明、打开引用来源、检查相关权利，并对最终措辞负责。

**禁止：**发布虚构引语、参考资料、客户结果或统计数据。

2. 研究与综合

**允许：**要求已批准工具整理所提供的来源并识别分歧。

**必须：**保存来源清单，标记缺乏支持的结论。引用底层出版物，而不是 AI 响应。

**禁止：**把生成文本或搜索摘要当成独立证据。

3. 会议记录

**允许：**只有在满足政策、参会者告知、访问和保留要求时，才可以转写和总结会议。

**必须：**会议负责人在分发前确认决定、行动负责人、日期和争议事项。

**禁止：**悄悄把推断出的行动变成已经分配的承诺。AI 会议记录指南提供了一种可审查格式。

4. 软件与代码

**允许：**对已获许可的代码仓库和许可证使用已批准的编码助手。

**必须：**按照人工编写变更所采用的相同标准，对代码进行审查、测试、扫描和归因。

**禁止：**把秘密信息或受限源代码发送给未经批准的服务，或仅仅因为代码可以编译就合并。

5. 客户沟通

**允许：**根据已批准的客户记录和支持指南起草回复。

**必须：**如果消息会产生实质影响，责任人应在发送前检查身份、账户事实、承诺、语气和升级规则。

**禁止：**虚构账户操作、退款、政策例外或法律承诺。

6. 机密数据与个人数据

**允许：**只有明确批准某项工具处理指定数据类别和用途时，才能在其中处理该类数据。

**必须：**最小化字段，遵守保留规则，并确认供应商的训练用途和访问设置。

**禁止：**假设付费套餐会自动允许处理所有机密或个人数据。

7. 就业决定

**允许：**完成偏差和可访问性审查后，使用已批准工具提供低风险行政支持，例如整理职位描述格式。

**必须：**任何会对候选人或员工进行评分、推荐、排名或产生重大影响的系统，都必须由法务和 HR 负责人批准。最终决定仍由人承担责任。

**禁止：**使用通用聊天机器人筛选简历或推断受保护特征。

8. 事故与意外输出

**必须：**停止受影响工作流，保留相关记录，通过安全或 AI 事故渠道报告，并识别下游接收者。

**禁止：**删除追踪记录，或者为了避免报告而静默修改输出。

9. 营销与公开声明

**允许：**根据已批准的产品事实、品牌指南和获得许可的素材起草营销活动变体。

**必须：**活动负责人在发布前核实产品能力、价格、客户证据、比较、披露和素材权利。可能变化的声明需要带日期的来源。

**禁止：**虚构客户评价、在没有研究的情况下暗示实测性能，或把合成人物呈现为真实客户。

10. 数据分析与报告

**允许：**使用已批准工具清洗、总结、可视化或解释允许处理的数据集。

**必须：**保存源数据、转换步骤、单位、筛选条件和假设。核对重要合计，并由报告负责人批准结论。

**禁止：**把受限记录上传到未经批准的工具，在不披露的情况下删除不方便的数据行，或把生成图表当成底层计算正确的证据。

11. 图片、音频与视频

**允许：**在满足训练数据、肖像、商标和平台要求时，为已批准的创意工作制作合成媒体。

**必须：**当政策、法律、合同或语境要求时，标注合成或经过实质修改的媒体。保留涉及可识别人物、客户素材和许可输入的批准记录。

**禁止：**冒充同事或公众人物、伪造纪实证据、移除水印或制作欺骗性媒体。

12. 翻译与本地化

**允许：**使用合适工具为已批准的来源材料起草译文。

**必须：**由具备资质的审查者检查含义、地区用语、姓名、数字、法律文本、文化语境和固定 URL。已批准的源文始终具有最高权威。

**禁止：**发布未经审查的高影响翻译说明，或为了语言自然度而静默改变产品承诺。

13. 采购与供应商评估

**允许：**总结公开供应商文档，并整理对已批准问卷的回复。

**必须：**采购和安全负责人在原始记录中核实合同、数据流、分包处理者、保留、训练用途、服务承诺和退出条款。

**禁止：**让 AI 接受条款、选择供应商，或把缺失答案表述为承诺。

14. 自动化操作

**允许：**在工作流成文权限范围内，准备可撤销的操作或建议。

**必须：**在发送、采购、发布、删除或更改记录系统等后果性操作前，采用最小权限、限定凭据、限制、日志、幂等性和审批。

**禁止：**仅仅因为某项任务偶尔需要执行操作，就为通用助手授予长期广泛访问权限。

运行卡模板

任务：
业务负责人：
已批准工具和版本：
允许的数据类别：
禁止的输入：
所需来源：
人工审查检查项：
AI 可以执行的操作：
需要批准的操作：
保留的记录和期限：
事故渠道：
下次审查日期：

三个完整运行卡示例

低风险：内部研讨会提纲

任务：根据公开文章和已批准的团队简报起草研讨会提纲。
业务负责人：学习负责人。
已批准工具：组织管理的写作工作区。
允许的数据：公开数据和被分类为一般员工可访问的内部数据。
必要审查：负责人检查来源、议程、声明和可访问性。
AI 可以：总结、整理、起草和建议练习。
AI 不可以：邀请参与者、发布材料或虚构参与者反馈。
记录：已批准提纲和来源清单保留一年。
升级渠道：学习运营渠道。

中风险：客户续约简报

任务：根据已批准的账户记录准备内部续约简报。
业务负责人：客户总监。
已批准工具：获准处理客户机密数据的签约工作区。
允许的数据：指定 CRM 导出和已批准支持摘要。
必要审查：客户总监核实事实、承诺和待解决问题。
AI 可以：整理证据、识别缺失字段并起草简报。
AI 不可以：更改 CRM 记录、联系客户、报价或承诺条款。
记录：最终简报、引用的账户记录、审查者和日期。
升级渠道：销售运营和隐私联系人。

高风险：候选人筛选请求

任务：根据简历对申请者排名。
处理结论：不在一般可接受使用路径下批准。
原因：该任务对就业产生实质影响，可能带来歧视、
可访问性、隐私、透明度和记录义务。
下一步：将成文使用场景提交 HR、法务、隐私和安全团队
正式评估；与此同时继续使用现有人工审查招聘流程。

这些示例说明为什么只看相同动词并不足够。“总结文件”对于公开研讨会文章可能是低风险任务，对于医疗便利安排记录却可能是高风险任务。运行语境决定需要哪些控制。

如何为组织编写示例

从人们已经在执行的十项 AI 任务开始，而不是假想未来架构。访谈用户、检查真实数据流，并为每项任务编写一张运行卡。加入一个险情示例：展示看似相同却越过边界的操作，比增加一条抽象禁令更有教育意义。

然后用三个问题测试每个示例：

1. 新员工能否判断该用途是否允许？
2. 经理能否识别必要审查者和记录？
3. 安全团队能否确定涉及哪些数据和系统？

经理决策树

员工提出新用途时，经理可以询问：

1. 针对该确切数据类别，这项工具是否在批准登记表中？
2. 任务是否影响就业、法律权利、安全、财务、客户或公开声明？
3. AI 是否会发送、发布、采购、删除、授予访问或更改记录？
4. 审查者能否在影响发生前检查来源并修正输出？
5. 是否有负责人、保留记录、事故路径和停止工作流的方法？

如果第一项答案是否定的，应停止并申请工具审查。如果第二或第三项任一答案为肯定，就将用途转入高风险审批路径。如果缺乏证据或负责人，输出应保持草稿状态，直到缺口解决。

避免政策形式主义的上线方式

使用简短场景练习发布这些示例。要求团队为任务分类、识别允许数据、选择审查者，并说明最终保留什么记录。加入一个模糊案例，让人们练习升级处理而不是猜测。

跟踪问题、险情、未批准工具请求和事故。相同问题重复出现时，修订示例或批准工具登记表。不要通过增加宽泛禁令来回应每个边缘案例，而应澄清决策规则和负责人。

当工具更改条款、增加集成或操作能力、改变数据处理方式或引入新模型时，审查任务卡。即使产品名称不变，把起草变为自动发送的功能也会改变风险。

示例编写检查清单

[ ] 任务足够具体，两位经理会作出相同分类。
[ ] 已批准工具和数据类别均已注明。
[ ] 允许的辅助工作与最终权限相互分离。
[ ] 必要证据和审查可以观察。
[ ] 禁止行为包含一个贴近现实的险情。
[ ] 记录、保留和事故路由已经说明。
[ ] 地区或角色差异保持可见。
[ ] 示例具有负责人和下次审查日期。

保持跨部门示例一致

使用一套中央规则，再为财务、HR、销售、营销、工程、支持和法务添加部门运行卡。本地示例可能因为处理不同数据或决定而更加严格，但不应与组织级政策冲突。

当两个部门共享工作流时，指定交接方式。例如，营销团队可以起草公开客户案例，销售团队确认账户事实，法务审查权利和声明，客户负责人取得批准。运行卡应说明谁能阻止发布，以及所有人审查哪个来源版本。

依据运行卡抽查已完成工作。确认使用了已批准工具、没有受限输入、证据和审查者有记录，并且操作保持在范围内。用发现的问题改进示例，不要把每次修正都视为不当行为。

对示例进行版本控制

为每张运行卡指定负责人、版本、生效日期和变更历史。把它连接到工具登记项和底层政策条款。产品获得新集成或自主操作能力时，应在启用功能前审查受影响的运行卡。

归档旧版本，使事故审查者能够确定过去任务适用哪条说明。清楚标记归档卡，避免员工继续使用。没有生效日期的知识库页面可能悄悄把过时建议变成当前政策。

一致地回应错误

区分善意失误、指引不清、疏忽行为和蓄意误用。响应措施可以包括停止工作流、修正外部记录、通知受影响人员、重新培训、更改访问权限、修订示例，或采用现有行为处理程序。不要在 AI 政策中临时创造新的惩罚框架。

发生错误后询问五个问题：

1. 适用规则和批准的替代方案是否清晰且容易找到？
2. 工具或界面是否让不安全路径比批准路径更容易？
3. 哪些数据、人员、系统和下游决定受到影响？
4. 哪项预防或检测控制本应发挥作用？
5. 需要进行什么纠正、通知、评估或监控变更？

按比例保留证据。可能需要相关提示词、输出、版本、工具操作、批准、接收者和修正记录，但事故并不能成为收集无关员工内容的理由。

使用事故发现改进运行卡。如果多人因为已批准调试工具过慢而粘贴受限日志，那么组织既有行为问题，也有工作流设计问题。

与受影响人员共同审查示例

政策、安全和法务团队了解控制要求，员工则知道工作会在哪些位置变得模糊。与实际执行任务的人，以及适当情况下受输出影响的人一起审查示例草稿。

要求他们在没有提示的情况下为边缘案例分类。如果有经验的经理得出不同答案，应在培训前修订运行卡。测试批准路径在真实截止期限下是否可行，以及升级处理能否及时得到响应。

对于 HR、客户或可访问性敏感的工作流，让了解接收者体验的人参与。技术上合规的规则如果删除人工渠道或强迫他人披露个人信息，仍可能造成伤害。

组织级条款可以使用配套的 AI 政策模板，并参考 企业如何使用 AI 指南将政策映射到分阶段工作中。

常见问题

AI 可接受使用示例应该包含什么？

注明任务、已批准工具、允许数据、必要审查、禁止行为、责任人、保留记录和升级路径。

示例可以替代正式 AI 政策吗？

不能。政策定义组织级权限和原则，示例则把这些规则转换成适用于具体工作的决定。

每项 AI 输出都应该接受人工审查吗？

审查深度应与影响匹配。低风险头脑风暴可能只需作者常规审查；就业、法律、财务、安全、公开发布和客户影响工作需要由责任人明确审查。

示例可以比核心政策更频繁地变化吗？

可以。把任务示例和批准工具登记表保存在可控文档中，以便随着工具和工作流变化进行更新，同时保留负责人和变更历史。

公司应该发布多少个 AI 使用示例？

先覆盖员工最常执行的十到十五项任务，以及影响最大的禁止或需批准案例。当重复问题揭示真正缺口时，再增加示例。

政策示例应该指定具体供应商吗？

在单独登记表或运行卡中注明已批准工具，这样产品变化时不必重写核心政策。产品名称必须始终与允许用途和数据范围配对。

员工不确定时应该怎么办？

提供一个容易联系的渠道和响应负责人。政策应该鼓励员工在提交受限数据或执行后果性操作前暂停并询问。

承包商和供应商应该如何使用这些示例？

在入职和合同中加入适用运行卡，限制其只能访问已批准系统，并说明报告义务。没有明确访问和说明时，不要假设外部人员使用相同的工具登记表或数据环境。

可以使用个人 AI 账户处理工作吗？

只有当政策明确允许该账户、用途和数据时才可以。托管账户通常具有更强的身份、配置、支持和离职控制；付费个人账户不会自动获得批准。

已批准的 AI 工具不可用时怎么办？

使用成文人工备用流程或另一项明确批准的工具。服务中断不代表可以把公司数据转移到个人账户或未经审查的服务。

经理应该检查员工的 AI 提示词吗？

访问应基于明确的业务、安全、审计或事故目的，并提供适当告知和权限。常规、不受限制的监控会带来隐私和信任问题，也可能捕获敏感内容。

将已批准的运行卡及其来源材料放入 Ottermind，在任务中把权限、证据、交付物和审查标准保存在一起。