Uber确认数据泄露：数千司机驾照信息经由Fireworks AI被盗

Uber近日确认，一起数据泄露事件导致数千名司机的驾照信息被黑客窃取。说个细节，这些敏感数据并非直接存储在Uber自家服务器上，而是由AI云服务公司Fireworks AI保管。这一事件揭开了AI供应链中一个容易被忽视的安全盲区。

事件核心：数据在AI云平台被窃

据Uber官方确认，此次泄露涉及数千名司机的驾照信息。这些信息原本由Fireworks AI存储，后者是一家提供AI模型部署与推理服务的云平台。黑客在一次安全事件中攻入了Fireworks AI的系统，并获取了这批数据。

Uber在声明中强调，泄露发生在第三方服务商侧，而非Uber自有基础设施。但无论数据存放在哪里，司机的驾照信息都属于高敏感个人数据，一旦流出可能被用于身份盗用、欺诈开户等非法用途。

为什么AI云平台成了攻击目标？

Fireworks AI这类平台的业务模式，是帮企业快速部署和运行大模型。为了完成推理和微调任务，客户往往需要把训练数据、业务数据甚至用户数据上传到平台侧。这无意中让AI云服务商变成了一个高价值的数据聚合点。

攻击者的逻辑很直接：与其逐家攻破企业，不如瞄准集中托管多家企业数据的AI平台。一次得手，可能波及多个客户。Uber这次事件并非孤例，它暴露的是整个AI供应链的共性风险——企业把数据交给第三方AI服务商时，往往默认对方的安全能力足够可靠，却很少做深度审计。

推理与微调是理解这类平台数据风险的关键。推理指用训练好的模型对新输入生成输出，通常只需输入数据；微调则是在预训练模型基础上用特定领域数据继续训练，使模型适配具体任务。微调往往需要上传带有真实业务信息的样本数据，甚至包含用户个人字段。Fireworks AI 这类平台同时提供两种服务，客户为省事常把原始数据直接上传，平台因此被动成为敏感数据的集中存储点。即便企业主观上只想“跑个推理”，工程实践中也容易把完整数据集一并传上去，这是 AI 供应链风险被放大的技术根源。

对AI服务采购的警示

这起事件给所有使用外部AI服务的企业提了个醒。

数据最小化原则

企业需要重新审视：交给AI平台的数据是否真的必要？如果只是做推理，能否用脱敏或合成数据替代真实用户信息？驾照信息这类高敏感字段，本就不该出现在非必要的第三方环境中。

供应商安全审计

选择AI云服务商时，安全资质和事件响应能力应成为硬性门槛。合同中需要明确数据泄露的责任划分、通知时限和赔偿机制。Uber此次能快速确认泄露范围，说明其至少保留了数据流向的可追溯性，这一点值得借鉴。

数据处理者与数据控制者的区分是评估此类风险的法律基础。按通用数据保护框架，决定数据处理目的和方式的一方是控制者（如 Uber），受托处理数据的一方是处理者（如 Fireworks AI）。控制者对外承担主要合规责任，但处理者同样负有安全保障、协助通知等义务。现实中，处理者责任边界常靠合同约定，而非统一强制标准，导致出事后追责困难。企业做供应商审计时，应重点核查对方是否具备独立的安全认证、漏洞响应流程和子处理者清单，并在合同中写入审计权与泄露通知时限。

事件响应与用户沟通

数据泄露发生后，受影响司机的知情权和后续保护措施是关键。企业应主动提供信用监控、身份保护等补救服务，而不是被动等待监管施压。

更深层的行业问题

AI基础设施层正在快速膨胀，但安全投入未必同步跟上。Fireworks AI这类创业公司增长压力大，安全团队规模和成熟度往往落后于业务扩张速度。当它们服务Uber这样的巨头客户时，承载的数据敏感度已经远超其安全体系的设计假设。

监管层面，AI服务商作为数据处理者的责任边界仍不够清晰。Uber确认了泄露事实，但具体攻击路径、受影响司机数量、Fireworks AI的安全缺陷细节，目前公开信息有限。可以确定的是，随着AI云服务渗透率提升，类似事件只会增多，行业需要更严格的数据处理者认证和持续监督机制。

对普通司机和用户而言，这起事件再次说明：个人敏感信息一旦交出，控制权就不在自己手中。选择服务时关注企业的数据安全记录，或许是当下最现实的自我保护方式。

数据最小化与脱敏、合成数据是降低此类风险的直接手段。数据最小化指只收集和传递完成特定任务所必需的最少字段；脱敏是通过遮蔽、泛化或替换去掉可识别个人身份的信息；合成数据则是用模型生成统计特征相似但不对应真实个体的数据。对驾照信息这类高敏感字段，企业应优先在本地完成必要处理，仅向 AI 平台传递脱敏或合成后的样本。需要说明的是，脱敏并非绝对安全，字段组合仍可能重新识别个体，因此还需配合访问控制和传输加密，才能实质降低第三方泄露的后果。