设想一名新员工：团队同事都在用AI工具，却从没人给他看过获批工具政策。后来，IT来问为什么客户数据进了个人账户。这个场景是示意性的，但其中的控制缺口是真实的：同事怎么做，并不构成授权。
这个缺口——介于“没人说不行”与“这实际上已获批准”之间——正是大多数日常职场AI失误的起点。本文不讲一般安全规则是什么；工作中的隐私与数据卫生已经覆盖。本文讲的是大多数人完全跳过的更窄、更机械的一步：真正找到你自己雇主的政策文件，阅读要紧的部分，并知道当发现根本没有政策时该怎么办。
职场AI政策实际是什么
可用的政策，是一份具体、带版本、有明确责任人的文件或内网页面。它应当写明：获批的工具与账号配置、允许使用的数据、人工审核与披露要求、新工具的审批、事件上报，以及后果。同事的一条消息或一种习惯，都不能代替它。
组织可能把它发布在IT安全wiki、可接受使用政策、员工手册、采购目录，或一份具名的获批工具清单里。请把标题、责任人、版本或日期以及链接记下来，这样日后规则若发生变化，你能看得出来。
索要这份文件是合理的。《欧盟AI法案》第4条要求受其规制的提供者和部署者，结合具体场景与风险，采取措施支持员工及代表其操作AI系统的其他人具备足够的AI素养（AI Act, Article 4）。该条款是否以及如何适用于某个组织，是一个法律问题；它本身并不授权员工使用某个工具或某类数据。
实际该去哪里找
在假定没有政策之前，按顺序检查这些地方：
- **公司内网或员工手册。**搜索“AI”“artificial intelligence”“generative AI”，或具体工具名（ChatGPT、Copilot、Gemini）——政策有时归在IT安全或可接受使用政策下，而不是独立的AI章节。
- **IT或安全的获批软件清单。**许多公司为任何类别维护受认可工具清单，AI工具越来越多地以具体层级或配置名称出现在其中。
- **你的入职材料或最近一次全员会议录音。**AI政策公告常常只在会议上说一次，之后再也不提——检查你是否错过了。
- **你的经理。**一个直接、具体的问题——“我们团队有获批的AI工具吗，有什么东西我不该粘贴进去？”——比独自搜索更快得到真实答案。
- **直接问IT或安全。**若前四项一无所获，就以书面形式、点名询问负责工具审批的团队，让答案留下记录。
把答案连同标题、责任人、版本或生效日期以及链接，保存在获批的工作位置。不要把机密的政策材料复制进个人笔记账号。每当出现新的数据类别、新工具、新账号或对外交付物时，重新核对一次。
造成最多麻烦的误解
一种破坏性很强的假设，是把沉默当成许可：“没人告诉我不能用ChatGPT做这个，所以应该没问题。”若你找不到授权，就把敏感数据视为尚未获准进入该工具，并在把AI用于客户数据、未发布计划、财务信息或其他员工个人信息之前，先询问负责的责任人。沉默既不能确立批准，也不能确立禁止；它留下的是一个悬而未决的控制问题。
第二个常见错误走向另一端：假定适用于一种情境的政策覆盖所有情境。已批准企业级AI工具用于起草内部备忘录的公司，未必已批准它用于面向客户的沟通、HR决策，或涉及其他员工数据的任何事——要读范围，而不只是“有没有一个‘可以’”。
一个具体例子
同一家中型企业的两名员工都想用AI协助起草客户提案。一人搜索内网，找到描述带特定登录的企业配置工具的页面，并使用它。另一人假定“AI就是AI”，把客户合同细节粘进个人ChatGPT账户，因为另一团队的同事也这么做且看似没问题。两人中只有一人真正核对了雇主批准的是什么；另一人依赖的是一个目前碰巧尚未造成可见问题的假设。这种差异平时看不见，直到审计、客户投诉或数据事件把问题直接摆到面前。
若你就具体工具与具体数据类别找不到清晰答案，在获授权的责任人书面答复之前，把客户数据、其他员工的个人信息以及机密材料一律排除在外。在欧盟，个人数据的使用还必须符合该组织已记录的GDPR角色、目的、法律依据、安全措施与处理者安排；本文无法为某个特定雇主判定这些（GDPR）。若已经发生了误粘贴，请走事件上报流程，而不要隐瞒或临时自行补救。见不要把工作机密粘贴进消费级AI。
真正的政策通常会规定什么
找到实际文件后，请对照下面这些控制项来读，而不是扫一眼是否有笼统的“允许使用AI”标题：
| 看什么 | 为何要紧 |
|---|---|
| 具名的获批工具 | 只说“允许使用AI”而不点名工具，等于没有提供任何可用信息 |
| 要求使用的账号、租户或配置 | 光有品牌名，看不出获批的是个人登录还是企业租户 |
| 禁止或受限的数据类别 | 客户数据、财务信息、源代码和HR数据，往往与一般起草有不同规则 |
| 新工具的审批流程 | 告诉你想用的工具尚未在清单上时该怎么办 |
| 必须的人工审核与禁止交由AI的决策 | 指明哪里的输出必须被核对，以及哪里根本不能用AI |
| 披露要求 | 使用AI时是否需要告知经理或客户——一旦知道政策的具体规则，参见职场AI披露：何时必须的决策框架 |
| 数据保留、记录与事件上报 | 告诉你哪些必须留痕，以及误粘贴或输出不安全之后该怎么做 |
| 未获批使用的后果 | 让你具体了解真正的利害所在，而不只是抽象风险 |
若文件遗漏了本表中的实质性控制项，就把它视为不足以覆盖你打算做的事，并向获授权的政策责任人索要缺失的答案。
若确实没有政策
有些组织尚未写过专门的AI政策。这种缺失并不能推翻既有的安全、保密、隐私、可接受使用、采购或客户方面的规则。在该情形下：
- 就具体的工具、账号、任务和数据类别，向获授权的政策责任人——通常是IT、安全、隐私、法务、采购或被授权的经理——索取一份书面决定。
- 对涉及客户数据、他人个人信息或机密商业信息的任何事，默认采取最保守解读，无论捷径看起来多方便。
- 把问题写成书面（发给具名人员的邮件或Slack消息），留下你询问过的记录，而不是依赖日后无法指回的口头答复。
- 若你的角色经常涉及真正敏感的数据，考虑把政策缺失作为值得修补的具体、实际缺口提出——不是投诉，而是具体请求：“我们能否就哪一种AI工具获准用于X类工作，得到一页纸的答复？”
本周找到你的政策
用职场AI政策阅读卡真正定位雇主的政策，记录它关于工具、数据和审批流程说了什么，并记下任何部分不清楚时该问谁。若结果是根本没有政策，该卡也会带你走完直接向经理提出的保守默认问题。无论哪种结果，都比继续猜测更有用。
来源与审阅边界
- 英国ICO的内部AI使用政策是一份官方的真实范例，涵盖获批用途、个人数据、输出核对与事件处理；它不是可以凌驾于其他雇主规则之上的模板。
- 爱尔兰国家网络安全中心面向公共部门机构的生成式AI指引展示了在高治理场景中，获批工具与业务数据方面的限制是什么样子。
本文帮你定位政策控制项；它不为某个特定组织解释劳动权利、合同、GDPR角色或《欧盟AI法案》。合格的劳动法、隐私与法律审阅仍待完成。
