松下把 33.4 万人花名册传给 AI：被禁止路径上的合规失灵

一名员工，把一份 33.4 万人的花名册交给了聊天机器人。

10 月 23 日，松下集团旗下 Panasonic Operational Excellence（简称 PEX）发布公告。他们跟子公司松下数字一起在推进人力资源信息系统项目，项目负责人之一把系统里的数据传到了一个公司明令禁用的外部生成式 AI 服务上。

传上去的内容覆盖现员工、前员工，以及这些员工登记为紧急联系人的家属。PEX 在公告里写了"向受影响者致歉"，并说明目前没有发现这批数据遭到泄露。

这件事的核心不是"有人违规"这四个字。核心是：企业为了效率让员工用 AI，而员工为了效率把不该给的东西给了 AI。链路上每一步都有人在做当时看起来最合理的选择。

33.4 万人是怎么凑出来的

公告把受影响人群拆成了四组，每一组都超出一般人对"一起泄露"的想象边界。

• 7.5 万名现员工：工号、地址、电话、邮箱
• 17.8 万名前员工：同样的四项，其中包含 1978 到 2026 财年之间退休的人，以及业务被并购后转到其他公司的员工
• 5.5 万名现员工家属：姓名、地址、电话、邮箱，作为紧急联系人登记
• 2.6 万名前员工家属：同上，但只限 2016 年及以后退休者登记的

前员工这一栏是 17.8 万，比现员工多出一倍多。松下用的是集团统一的人力资源信息系统，日本区域凡是使用这套系统的公司员工全在里面。一个人离职、退休、跟着并购业务换了东家，历史记录跟着走完了半辈子。

家属那一栏更微妙。这些信息是员工本人在入职或某个时点自己填进去的，填的时候是当成"万一我出事请联系谁"的应急用途。填写那一刻谁也不会想到，五十年后这份表格会被另一个公司的一位员工复制粘贴进一个对话框。

被上传的数据，是截至 2026 年 4 月登记在系统里的内容。也就是说，这批数据在违规行为发生前，已经在系统里静静躺了半年。

那条被明确禁止的路径

公告里那句话是关键：这个外部生成式 AI 服务，是公司内部明令禁止使用的。

这说明两件事。其一，公司内部有规定，而且规定很明确，不是"原则上不建议"，是禁止。其二，规定没有拦住这次操作。一个项目负责人，手上有集团统一 HR 系统的数据访问权，有正当的工作理由需要处理这批数据，他选择了最顺手的那个工具。

• 他做的是一件完全正当的工作：推人力资源信息系统项目
• 他用了一个公司禁用的工具：外部生成式 AI 服务
• 他做完了就删了：删除聊天记录，删除工作电脑上的相关数据

删除动作最值得注意。删除行为说明他知道这事不该做，也说明他有意识地在收拾痕迹。但从结果上看，删除聊天记录并不等于数据消失。

按服务方的合规要求，即使用户删掉聊天记录，数据仍会从删除之日起保留 30 天，用于安全管理与法务合规。松下方面说得很清楚：从 10 月 25 日起，这批数据不再被保留。也就是说，从上传到彻底清除，中间隔了大约一个月。

为什么说"没有泄露"并不让人安心

松下方面给出的结论有两条：服务方表示数据没有被纳入训练资料库；目前没有出现这批数据泄露的情况。

两条都成立，但它们的成立方式需要细看。

"没有纳入训练"这条，根据松下的说法，是因为服务方在上传当时关闭了用于 AI 训练的功能。这是一种功能开关状态，而不是一种承诺。它由服务商单方面设置并告知，公司这边没有独立验证的途径。开关关着的时候数据安全，开关什么时候被打开、数据在什么状态下被访问，外界看不到。

"目前没有泄露"这条，监测窗口只有一个月。违规发生到公司发现之间隔了多久，公告没有说明。发现之后到上报个人信息保护委员会，又过了多长时间。公告里提到发现日期是 9 月 29 日，对外公布是 10 月 23 日，中间隔了近一个月。

换算成时间轴，公司是在事发一个多月之后才对外公布的。这一个月里，数据一直躺在服务商的服务器上。

这里有个容易被忽略的点：这次能确认"没有泄露"，前提是有人及时发现了并报告。那家公司是一个大企业的子公司，有专职的信息安全团队，有法务，有明确的报告流程。换成一家中小公司，违规操作可能几个月都没人知道，数据已经被拿去做别的事情。

"员工违规"是个太好用的说法

把这次事件定性为"一名员工违反规则"，法务上站得住脚。但落到机制层面，这个定性让太多问题可以被跳过。

一个项目负责人，手上握着 33 万人的个人信息和家属紧急联系人信息。是什么配置让他能一次性导出这么多内容？是数据权限管理过粗，还是测试环境不够干净、真实数据被顺手带进了新工具的试用？公告没有回答。

公司有"禁止使用外部生成式 AI"的明文规定。为什么这条规定没能拦住他？是员工不知道，是知道了觉得项目紧急可以例外，还是觉得大文件粘贴进去效率更高？这三种情况的应对方式完全不同。

• 不知道：需要靠提示、培训、入口拦截
• 知道但例外：需要审批通道和例外流程设计
• 觉得方便：需要技术手段让违规操作本身变麻烦

这三种情况在企业里并存。松下的公告没有区分它们，等于把治理问题退回给了"加强教育"这个万能答案。

这次其实没有造成实质损失

得承认几件事。

涉事员工主动删除了聊天记录和电脑上的数据，没有销毁证据的意图。服务方及时核对了训练开关状态，并且按合规要求在 10 月 25 日之后不再保留。公司自己查清了影响范围，主动向监管报告并向受影响者致歉。这几点让这件事停在了一个相对可控的位置。

换个角度看，这是一次运气不坏的违规。员工有意愿自我纠正，服务方的合规流程起了作用，公司有处理能力。再设想几个变量：员工没删、聊天记录被截图外传、服务方那个训练开关当时是开着的、或者这家违规发生在一家没有专属安全团队的公司。每换掉一个变量，故事走向就完全不同。

这次没有酿成事故，靠的是几个变量恰好都对。治理要做的，是让"都对"不再依赖运气。

任何手里有员工数据的人都能抄的作业

松下这次公开的信息其实很完整，别的公司照着自查并不难。要查的东西大致是这四类。

• 员工手里能拿到什么：HR 系统、考勤系统、通讯录、招聘简历里，哪些是可以整表导出的
• 禁止使用的工具名单是否真的被拦住：靠培训，靠入口的登录拦截，还是靠设备上的策略
• 真实数据有没有混进测试环境：新工具试用、供应商演示、POC 项目里，最容易顺手拖一份真数据
• 出了事怎么被发现：有没有 DLP 监测、异常上传告警、员工举报渠道

第二条是这次事件里最值得记的教训。禁用的规定如果只存在于内部文档里，它对项目负责人来说就只是一句"我们公司不让用"。真正有效的做法是让违规动作在技术上做不到——浏览器插件拦截、DLP 监测对上传行为报警、内部工具的登录入口走白名单。这不是不信员工，是把合规要求翻译成摩擦成本。

最后一条也常被忽略。这次能出问题，很大程度上是"人"先发现的。发现之后，公司用了一个月才对外公布。这一个月的沉默期里，企业承担着已知风险却选择让受影响者不知情。真正完善的机制应该包含时间线：多久内上报监管、多久内通知受影响者、多久内公开。松下这次的节奏不算快，这个位置是可以改进的。

生成式 AI 工具进入企业这件事本身没有错。让员工在真实工作里用 AI，比发一份禁止使用的通知有效得多。松下的问题不在于推得太快，而在于数据和工具之间的闸门还没修好。先让水流起来，闸门可以后补，但已经流走的部分追不回来。这类数据治理的话题，云栈社区里也常有同行讨论。

主要信源：松下集团 PEX 2026 年 10 月 23 日公告、ASCII 日文版报道（2026 年 10 月 26 日）、IT 之家报道。