松下数据泄露：企业AI禁令为何屡屡失效

数据未被窃取。它被上传了。是故意的。

10月23日，松下发布了一则表面上看似平常的声明——一起涉及33万人的数据泄露事件，于9月29日向日本个人信息保护委员会报告，并采用了大企业希望此事不要上头条时才会用到的那种冷静程序性语言予以解决。

但仔细读来，一个更加令人不安的事实浮现出来。这不是一次外部黑客攻击。没有零日漏洞被利用，没有钓鱼邮件骗得初级工程师交出凭证，也没有供应链被入侵。数据是从松下自身的网络中走出去的，由公司内知道自己在做什么的人主动上传的。

而且他们明知此举违规。

到底发生了什么，直白地说

此次泄露发生在松下与其子公司松下数字共同管理的人力资源信息系统部署期间。项目团队中的一员或多人将已存储在公司内部人力资源系统的数据粘贴到了第三方生成式AI服务中——而松下明确禁止在内部使用此类服务。

涉及的数据涵盖约75,000名在职员工、178,000名离职员工（包括转入被收购企业的员工），以及约81,000名注册为紧急联系人的家属。员工记录中没有姓名，但家属记录中有姓名。地址、电话号码和电子邮件地址伴随这两类记录存在。

发现上传行为后，相关人员立即删除了AI服务中的聊天记录，并从工作电脑上清除了相关数据。随后他们内部上报，松下通知了隐私委员会。AI服务提供商确认这些数据不会用于模型训练，但其标准保留政策意味着相关信息在删除后仍保留在文件中达30天——直至约10月25日。

没有任何个人信息被公开或出售，也没有确认任何欺诈行为。松下表示受影响人员目前无需采取任何行动。

从任何技术标准来看，这是一起可控事件。但可控并不等于安全。而真正值得关注的故事是：它确实发生了——而且是通过一种本应极其容易防范的机制发生的。

政策与实践之间的鸿沟

松下这起事件揭示了一个远超该公司自身范围的结构性问题。生成式AI工具现已嵌入全球知识工作者的日常工作流程中。它们速度快、方便，并且日益难以在不严重损害生产力的情况下加以阻止。当员工面临服从任意禁令或寻找规避方案之间的选择时——而规避几乎总是可行的——规避方案往往会胜出。

一位欧洲跨国机构的资深HR技术管理者曾私下告诉我，其组织在一次内部审计中发现了类似未经授权使用AI的情况：开发人员将架构设计图粘贴到公共聊天界面中，销售团队将客户合同上传至免费层模型，HR员工通过消费级工具运行薪资基准查询。清单很长。政策纸面上存在。但执行最多只能说断断续续。

松下涉及的33万条记录并非通过某个单薄的疏忽时刻泄露出去。这个规模暗示了一种持续的模式——数据是在一个至少跨越数月的活跃项目时间线上分批上传的。这意味着要么组织对这种行为持容忍态度，要么对项目团队实际在做什么完全缺乏可见性。

谁受益，谁受损，接下来会发生什么

直接的输家是信任。松下是一家建立在数十年工程公信力之上的品牌。当这样一家巨头公司无法阻止员工将内部HR数据输入不受监管的云服务时，启示并非松下特别粗心大意，而是每个存在类似政策空白的跨国企业都同样脆弱。

员工失去隐私。家属失去隐私。离职员工——他们有理由期望就业期间共享的数据不会无限期地存在于AI训练管道中——失去了"离职即终结与雇主数据关系"的保障。松下的隐私负责人可以说数据未被用于训练。服务提供商可以确认这一点。但举证责任现在落到了公司和供应商身上，要求他们证明保留政策不仅写在纸上，而且得到执行、可审计，并且不依赖于企业承诺。

监管者赢得主动权。日本个人信息保护委员会收到了正式报告。其他地方的类似披露也将随之而来，形成不断增长的执法先例库，从而重塑公司设计AI治理框架的方式——不是在事故发生后，而是在事故发生之前。

最实际的影响可能来自内部。松下表示将审查个人信息处理规则及AI使用管理，并加强相关方的教育。这是标准的公司回应。更棘手的问题是：仅靠政策教育能否改变行为，还是必须依靠技术控制——数据防泄漏工具、网络层AI使用限制、应用层沙箱——来承担更重的责任。

真正的启示

松下的数据泄露事件可能不会主导全球科技新闻。没有客户数据库被公开曝光，没有勒索软件要求，也没有在披露当天宣布监管罚款。按大多数标准衡量，这是一起因妥善解决而趋于平静的微小事件。

但正是微小事件让结构性故障显露真身。一家在HR系统中拥有33万人员的公司具备资源、专业知识和监管压力来做好这件事。如果松下都无法阻止自己的项目团队将内部数据上传到被禁用的AI服务，那么不具备这些优势的任何公司都没有现实机会。

金丝雀还没有唱起来。它只是活着站在那里，在一个大多数企业尚未承认存在的矿井中。