企业把AI接进工作区，最常问的是：模型回答得准不准？速度快不快？价格合不合适？Notion这次披露的安全事件，把另一个问题推到了前面：为了让AI工作，用户的数据会经过谁的系统，又会在那里留下什么？
11月10日更新的安全公告中，Notion表示，第三方AI供应商Fireworks AI发生安全事件，影响范围不到Notion工作区的1%。Notion分析Fireworks于11月8日确认的数据集后发现，其中包含用于Insights功能的Notion AI聊天记录。大多数受影响工作区的这些记录没有标明作者或所属工作区，也不包含工具调用结果。
这是一个范围有限、但边界很清楚的事件：出问题的入口在外部供应商，暴露的数据却来自用户与AI的实际对话。它不是“所有Notion AI聊天都泄露”，也不是Notion称自己的系统被攻破；但它足以说明，AI产品的隐私边界不会停在用户眼前那个聊天框。
发生了什么：第一次判断之后，数据范围又扩大了
按Notion公告的时间线，11月2日晚，Fireworks通知Notion有一小批数据遭恶意访问。Notion当时调查后认为，数据集包含AI合成测试数据，不涉及Notion AI客户数据。11月3日上午，Notion表示已断开与Fireworks的系统连接，删除Fireworks系统中存放的相关数据，并停止双方系统通信。这一处置针对供应商侧的数据和连接，不能证明此前可能被未经授权方取得的数据副本已经删除。
11月6日，Fireworks又告知Notion，攻击者可能访问了客户数据。Notion随后重新调查；11月8日，Fireworks确认最终受影响的数据集。Notion分析后发现，其中包含用于Insights分类任务的AI聊天记录，并于11月9日联系受影响客户。
这段时间线的关键不只是“供应商遭遇安全事件”，而是受影响数据的判断经历了更新：最初确认的是合成测试数据，之后才确认另一个数据集含客户聊天记录。Notion称，Insights功能已暂停，并停止通过Fireworks提供开放权重模型推理服务；这不等于全部Notion AI功能关闭。调查仍在继续。
所以，事件范围和处置状态需要按Notion的最新公告表述。现有信息支持“不到1%的工作区受到影响，部分数据集中包含聊天记录”，不支持“Notion全部AI对话已公开”或“所有客户都需要采取相同操作”这样的泛化说法。
为什么聊天记录会经过另一家AI公司？
一个AI功能看上去属于某个应用，背后却可能由多层服务共同完成。应用负责界面、账号和数据权限；模型推理服务负责接收问题并生成内容；分类、检索、监控等辅助任务还可能由不同服务处理。企业接入AI供应商时，数据流可能经过应用厂商和模型基础设施商，甚至再延伸到存储、日志和安全工具。
Notion公告称，Fireworks既曾用于Notion的Insights分类任务，帮助客户了解自身AI使用情况，也曾作为推理供应商，在产品中提供开放权重模型服务。此次被识别出的聊天记录，属于Insights功能使用的数据集。换句话说，记录出现在供应商侧，并不必然意味着用户当时正在和Fireworks的模型直接聊天；它也可能是产品为了完成分析或分类任务，把相关文本交给了外部服务。
这里必须把两条用途分开。第一条是本次被Notion确认涉及的数据用途：Notion AI聊天记录进入Insights使用情况分类数据集，Fireworks在11月8日确认的数据集中包含这类记录。公开公告没有说明该数据集具体存放在哪个系统、何时生成、通过哪个账号被访问，因此下图只概括数据用途，不代表已确认的存储位置和处理时序：
Notion AI聊天记录 → Insights使用情况分类数据 → Fireworks供应商侧 → 相关数据集被纳入受影响范围
第二条是另一项独立的服务用途：Notion产品通过Fireworks调用开放权重模型进行推理。Fireworks称目前没有发现其Inference服务受到影响；Notion也表示已停止通过Fireworks提供开放权重模型推理。现有公告没有说此次聊天记录是在实时推理请求中被截获，不能把两条链路混为一谈：
Notion产品中的开放权重模型服务 → Fireworks推理基础设施
这个区分引出一个更具体的问题：即使推理端点采用零数据留存策略，额外的数据分类、分析或评估任务是否仍会形成需要独立管理的数据集？Fireworks称Inference、Training SDK和Nexus默认零数据留存；同时其公告披露，其他内部应用和开发环境仍涉及秘密、账单信息、数据集或不完整模型权重等风险。零留存必须对应到具体产品、端点和用途，不能外推到供应商全部系统。
“不到1%”不等于可以忽略，记录没有标签也不等于没有风险
Notion表示，事件影响不到1%的工作区，并称大多数受影响工作区的聊天记录无法归属到具体用户或工作区，也不含工具调用结果。这些限制降低了数据直接对应到个人或公司身份的可能性，但不能让聊天文本本身失去敏感性。
一段没有姓名和工作区标签的对话，仍可能包含客户名称、项目背景、合同片段、内部计划或代码。上下文足够具体时，即使缺少显式身份字段，也可能被熟悉业务的人认出来。是否含工具调用结果，也关系到泄露内容，但不能单独说明聊天文本安全或不敏感。
因此，风险应按数据内容和可关联性判断，而不是只看工作区占比。对被Notion联系的客户，Notion建议在工作区中安全查看受影响数据，并把数据视为可能暴露；若在相关时间段把密码、API密钥或其他凭证粘贴进Notion AI，应轮换这些凭证。Notion表示，未收到通知的客户目前无需采取行动，但调查仍在进行。
企业AI的供应商清单，不能只写模型名称
过去采购AI服务时，企业常把重点放在“用哪家模型”。这次事件说明，真正需要盘点的是一整条处理链：问题文本经过哪些服务、每个服务承担什么任务、供应商会不会留存输入、数据集如何隔离、删除请求能否传递到下游，以及出现事件时谁负责通知客户。
尤其要把“产品功能数据”和“模型训练数据”分开看。Notion公告里涉及的是Insights分类任务数据，并未说此次聊天记录被用于训练模型。不要把“被供应商处理”自动改写成“被拿去训练”；两者是不同的用途和风险。但企业也不能因为没有训练用途，就忽略供应商保存、日志、评估和分类处理过程。
对于提供AI功能的应用公司，第三方模型服务的安全承诺还需要落到系统配置和合同边界中，例如数据保留周期、是否用于训练、访问权限、子处理商列表、删除机制、事件通报时限和审计记录。用户在产品界面看到的隐私说明，最好能与实际部署配置对应起来。
对于使用AI工具的公司，员工培训也不能只停留在“不要输入机密”。企业需要知道哪些功能会把文本交给外部供应商、哪些数据经过脱敏、哪些聊天会被保留用于分析。否则，员工即使遵守“不用陌生聊天机器人”的要求，也可能通过熟悉的办公软件，把敏感内容送进未充分了解的处理链。
Fireworks披露的技术路径：凭证、开发环境与数据集是三层问题
要理解这次事件，得把“发生在Fireworks的入侵”和“Notion聊天记录被纳入受影响数据集”分开看。两家公司公告能拼出事件轮廓，但还没有公开完整取证报告、日志样本或攻击者逐步操作的技术细节。因此，不能把尚未公开的横向移动路径、具体漏洞或访问命令写成事实。
Fireworks在10月6日最初披露，攻击者未经授权使用了Fireworks内部凭证，并访问了少数客户账户评估任务中的环境变量，其中可能包含API Key和Token。当时公司表示，尚未发现客户模型、数据集、训练数据、推理流量或个人信息在其安全边界内遭未授权访问；调查仍在继续。
11月9日更新的公告扩大了已知范围。Fireworks称，托管其研发机器的一家第三方云服务商在10月23日发生安全事件；10月24日，未经授权的一方借此到达Fireworks开发机器，并运行了未授权工作负载，造成额外客户数据影响。Fireworks称当天发现活动并采取处置措施。后续调查发现，少数账户还涉及账户与账单信息、秘密，以及部分不完整模型权重和数据集；公司表示没有发现Inference、Training SDK和Nexus这些默认零数据留存服务受到影响，并强调调查仍可能带来新发现。
Notion的公告则讲了自己这一侧的数据集：Fireworks在11月2日通知有小批数据遭访问，Notion最初判断是合成测试数据；11月6日收到可能涉及客户数据的通知后重新调查，11月8日确认的数据集包含Insights分类使用的Notion AI聊天记录。**两份公告共同确认供应商事件与Notion记录相关，但公开材料没有逐条披露某段聊天从Notion进入哪个存储桶、由哪个账号读取、在何时被复制。**文章不应把这条缺失的取证链自行补全。
这也解释了为什么“零数据留存”不能被当作覆盖供应商所有系统的万能承诺。它可能针对某项推理API的请求和输出，却不自动涵盖评估任务、分析分类、调试日志、账单系统、开发环境和备份。要判断是否适用，必须把具体产品、端点、功能和子处理商逐项对上。
企业怎么验证第三方AI数据处理链？看证据，不只看承诺
第一，拿到一张覆盖功能级的数据流图。以每个AI功能为单位，标出用户输入、应用服务器、模型端点、分类或检索服务、日志、存储和子处理商；记录每一步传什么字段、由谁发起、保存多久、在哪个区域。像Notion Insights这样的辅助分类任务，要单独列出，不能藏在“模型调用”一栏里。
第二，把合同中的数据条款映射到实际配置。分别确认请求和输出是否留存、是否用于训练、评估和分析任务是否例外、支持人员能否访问、子处理商如何变更、删除如何传递到备份。供应商说ZDR时，要求确认其对应的具体服务和配置，不能直接推定同一供应商的所有产品、后台任务和研发环境都零留存。
第三，用可追踪的合成数据做端到端验证。企业可以在测试租户放入不含真实个人信息的唯一标记文本，触发待测功能，再分别检查应用日志、网关日志和供应商请求记录，确认哪些服务实际收到标记、日志留下了什么、删除操作能否被追踪。生产聊天内容不适合拿来做“试试看有没有留存”的探针。
第四，核对日志和身份权限是否能支持事后调查。至少要能关联请求ID、租户、功能、端点、时间、密钥身份和响应状态，同时避免把完整敏感提示词写进普通日志。供应商侧应能说明密钥轮换、最小权限、隔离开发环境、异常导出告警和日志保留策略。Fireworks最初公告提到评估任务环境变量中的凭证，说明秘密如何注入临时作业、作业结束后是否清理，是需要具体核查的配置问题。
第五，把删除与事件响应也变成可验证流程。终止某项AI功能后，确认主存储、任务队列、分析数据集和备份分别怎样删除；事先约定供应商告警到客户通知的时限、受影响数据清单的字段、凭证轮换和访问日志复核方式。Fireworks的两次范围更新也说明，事故初期结论可能变化，客户需要收到可更新、可执行的影响清单。
企业接入AI服务，至少要逐项核对三类数据：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
随后把这些检查接到审计日志、供应商事件通知和删除证明上：请求ID应能关联租户、功能、端点、时间和密钥身份；供应商事件通知要能提供受影响数据类型与客户范围；删除操作应覆盖主存储、分析数据集、任务队列和备份，并留下可复核记录。测试时可用不含真实个人信息的唯一标记文本走完整流程，检查哪些端点收到数据、日志记录了什么，以及删除动作是否可追踪。 这些核查不意味着企业完全避免第三方服务，而是让“数据去了哪里、留了多久、谁能访问、出事后怎么查”能够被回答并留下证据。SOC 2或ISO等认证可以作为供应商管理的一部分，但它们不能替代某个具体AI功能的端到端数据流验证。
参考来源
-
Notion安全公告：Fireworks AI incident（2026年11月10日更新） -
Fireworks AI：2026年10月安全事件初始公告 -
Fireworks AI：2026年10月安全事件更新（11月9日）