Notion 11 月 10 日更新公告指出，Fireworks AI 事件涉及不到 1% 的 Notion 工作區。Notion 說明，後續確認的資料集包含用於 Insights 功能的 Notion AI 對話紀錄；受影響工作區中的大多數紀錄沒有標示使用者或工作區，也不含工具呼叫結果。公告同時提醒，即使紀錄無法直接歸屬到特定帳號，對話文字本身仍可能寫有敏感內容。Notion 公告

Notion 表示沒有其他功能受影響，也未稱所有 Notion AI 對話都遭存取。讀者要追問的是：輸入資料經過哪些服務、哪些紀錄會保存、供應商出事後誰確認影響範圍。以下時間線依雙方公告整理，Fireworks 調查仍在進行。

但這裡要先問一個更前面的問題：AI 功能背後有哪些服務商？「模型預設不保存提示」的承諾，是否涵蓋了對話分析、分類任務、資料集與開發環境？AI 隱私與企業資料的檢查方向可作為背景；這次事件則提供一個具體情境，讓使用者把服務依賴和資料用途逐項對起來。

Fireworks AI 事件中，哪些 Notion AI 資料受到影響？

依 Notion 11 月 10 日更新公告，後續確認的資料集含有供 Insights 功能使用的 AI 對話紀錄，影響不到 1% 的工作區；Notion 表示其他功能未受影響，調查仍持續進行。

Notion 說，Fireworks 於 11 月 2 日首次通報少量資料遭存取。初查只發現合成測試資料，未見客戶資料。11 月 3 日，Notion 切斷連線並刪除 Fireworks 端資料。

11 月 6 日 Fireworks 再通報可能涉及客戶資料；11 月 8 日確認新資料集後，Notion 才辨識出 Insights 對話紀錄，並於隔日聯繫受影響客戶。初步判斷不等於調查結論。

Notion 將這批紀錄描述為 Insights 功能使用的聊天逐字內容。大多數受影響工作區的紀錄沒有使用者或工作區標籤，也沒有工具呼叫結果；但「無法歸屬」只代表紀錄缺少這些標籤，不能推成文字中沒有姓名、公司資訊、醫療內容、財務資料或密碼。是否含有可識別內容，要由收到通知的工作區依 Notion 指引檢視資料。

Fireworks 10 月 10 日公告稱，10 月 6 日內部憑證遭未授權使用，有限客戶帳號的評估環境變數曾遭存取；當時未見模型、資料集、訓練資料或推論流量受影響。10 月公告。11 月 9 日更新說早期已知遭存取的是儲存 secrets，後來另發現帳務資料，少數帳號的 secrets、資料集及未完成模型受影響。

Fireworks 表示 10 月 24 日偵測並處置；11 月 9 日更新確認部分帳務資料、資料集與未完成模型權重受影響，調查仍可能有新發現。

由 2026 年 10 月 6 日至 11 月 9 日的事件時間線，標示 Fireworks 憑證與雲端事件，以及 Notion 收到初步通知、確認資料集和通知客戶的日期。
Notion 收到可能涉及客戶資料的後續通報後，才確認 Insights 對話紀錄在資料集中，初步判斷並非調查結論。

AI 對話送出後，資料會經過哪些服務邊界？

同一項 AI 功能可能把提示、檢索內容、模型輸出與使用分析交給不同服務處理；資料是否保存，要按功能、供應商、方案和工作區設定分別確認。

使用者看到對話框，背後可能有多條資料路徑。提示詞送模型生成回答；檢索增強生成（RAG，先找出資料庫內容再交給模型）會取用工作區文件；使用紀錄也可能送往分類或分析服務。對話紀錄、推論和分析用途不同，「不訓練」或「零資料保留」不能概括全部處理。

Fireworks 在 Notion 的服務中負責 Insights 分類與開放權重模型推論。Notion 11 月 11 日的 AI 說明稱，預設不以客戶資料訓練模型。

企業方案保存政策依模型而異，多數提供零資料保留，少數不提供者預設關閉，需管理者啟用；Free、Plus 與 Business 方案則稱供應商會在 30 天內刪除資料。實際適用仍要核對功能、供應商和設定。

處理角色可能接觸的資料採購或設定時要確認
AI 產品服務商提示、工作區檢索內容、對話紀錄、帳號與使用紀錄哪些功能會啟用、資料如何保存與刪除、管理者能否停用
模型或推論供應商送交推論的提示與必要上下文、生成結果資料是否留存、是否用於訓練、不同模型政策是否一致
分析或分類供應商對話片段、使用事件、分類結果是否含原始文字、是否帶有帳號標籤、保留多久
雲端或開發環境供應商機器、憑證、日誌、資料集或測試內容人員與機器的存取權限、日誌監控、事件通知和下游供應商

Notion 說明其 AI 使用多種大型語言模型，並揭露子處理者。名單回答「有哪些角色」，條款要回答「各自處理什麼」。企業應再核對管理介面的功能開關、保存例外及供應商變更通知。供應商名單與條款也可參照AI 服務合約中應確認的五項責任，將資料處理和事件責任納入採購核對。

「For the vast majority of impacted workspaces, these chats were unattributable.」 （Notion 事件公告，意譯：大多數受影響工作區的對話無法歸屬到特定使用者或工作區）

為什麼供應商事件會影響使用者看不見的資料？

風險會沿著資料用途、供應商依賴與存取權限延伸；即使主要模型推論有資料保留限制，分析資料集或開發環境仍可能形成另一條需要治理的路徑。

Fireworks 有兩條路徑：10 月 6 日內部憑證事件波及有限客戶帳號的評估環境變數；10 月 23 日第三方雲端事件後，攻擊者隔日進入研發機器執行未授權工作負載。另兩例：OpenAI 稱 2023 年 3 月快取程式錯誤可能讓部分使用者看到他人對話標題及部分 Plus 用戶付款資料，修補後通知可能受影響者。OpenAI 事件說明。2023 年 Microsoft AI 團隊分享訓練資料時，Wiz 發現權限過廣的 SAS 權杖開放額外 38TB 私人資料；Microsoft 撤銷權杖。Wiz 調查。

Fireworks 稱，尚未發現 Inference、Training SDK 與 Nexus 受影響，這些服務預設採零資料保留；調查仍在進行。Notion 確認受影響資料集為 Insights 對話紀錄。採購時要核對承諾涵蓋的產品與任務，以及資料是否另供分析、記錄或複製。

供應鏈風險管理（C-SCRM，組織對產品與服務供應鏈的資安風險管理）關心的是依賴關係和控制措施。NIST 指引建議企業依自身風險脈絡辨識、採用並調整供應鏈管理措施，也提出外部系統存取應受監控與稽核，且遠端存取應限於必要人員和任務。NIST SP 800-161 Rev. 1並非 AI 專用規則，但可作為檢查外包服務、子處理者與存取控制的治理參照。

「Our investigation is ongoing and may reveal additional information.」 （Fireworks 事件更新，調查仍在進行，可能會有新資訊）

雙方公告是當事方說明，並非獨立鑑識報告。Notion 說收到初次通知後切斷連線，後續再辨識受影響範圍；企業仍須核對工作區通知、資料內容和憑證狀態。單一事件不能代表所有服務商，應回到資料流與控制責任判斷。

AI 工作區資料流向圖，以箭頭連接使用者提示、工作區檢索、模型推論、對話紀錄、分析分類與雲端開發環境，並標出各服務邊界。
不訓練或零資料保留等承諾，需按功能與資料路徑核對，不能概括分析、紀錄和開發環境。

個人與企業可以怎麼檢查 AI 服務的資料邊界？

先按資料敏感度決定可輸入內容，再確認供應商、用途、保存期限、管理權限與事件通報；若服務通知憑證可能受影響，應依官方指引輪替或撤銷並查閱存取紀錄。

個人使用者可先減少輸入資料。避免直接貼上密碼、API 金鑰、病歷、財務帳戶資料或未公開商業內容；整理文件前，先移除姓名、聯絡方式、識別碼及非必要附件。「刪除對話」是否連帶刪除供應商、備份或分析資料，應查服務條款。

若收到 Notion 或其他服務商的事件通知，先確認通知是否指向自己的帳號或工作區，再依官方提供的方法檢視受影響資料。若曾貼入密碼、API 金鑰或其他憑證，刪除對話不會讓已曝光憑證失效；要依憑證所屬平台的指引撤銷或輪替，並檢查近期登入、權限變更和 API 呼叫紀錄。對醫療、財務或商業機密資料，依組織政策和適用規範處理，不要只憑單一供應商的通用說明判斷是否需要通報。

企業應把以下項目納入採購、續約與功能啟用。處理敏感個資、醫療或財務資料、商業機密的組織，以及負責採購、資安、法遵、資料治理和應變的人員，都要確認誰負責審核資料路徑。

  1. 畫出資料路徑：列出產品、模型、推論、分析、雲端和子處理者，標明提示、檢索內容、輸出、紀錄與憑證的去向。
  2. 核對用途與保存：確認各供應商接收資料的原因、保存期間、訓練用途和刪除方式，按功能分別核對。
  3. 盤點權限與日誌：確認人員和機器的存取條件、多因素驗證、最小權限、日誌保存及企業可取得的稽核紀錄。
  4. 寫清事件責任：確認通知時限、影響範圍更新、調查配合、憑證撤銷、刪除證明和聯絡窗口。
  5. 準備替代流程：確認服務停用時的影響與替代方式，演練通知判讀、使用者通知和後續追蹤。

啟用新功能或更換模型時，重新核對供應商、用途、保存期限和通知方式。合約、設定、公告與獨立驗證是不同證據；「不訓練」不代表不保存，「零資料保留」也有適用範圍。依資料敏感度決定是否輸入，並預先安排停用與追查方式。

  • 按功能列出資料接收者、用途與保存方式。
  • 分開核對供應商承諾、產品設定與事件通報責任。
  • 敏感資料先減量；憑證可能曝光時撤銷或輪替。
五個依序相連的治理檢查步驟，包含資料流向、用途與保存、權限與日誌、事件通報與憑證輪替，以及替代流程。
把資料用途、存取控制、事件責任與替代方案納入同一套檢查流程，才能在啟用前和事件發生時採取行動。

常見問題

Q1：Fireworks AI 事件是否代表所有 Notion AI 對話都外洩？

不是。Notion 公告稱事件涉及不到 1% 的工作區，確認的資料集包含 Insights 對話紀錄，並表示其他 Notion 功能未受影響。是否屬於受影響工作區，應以 Notion 個別通知為準。

Q2：對話沒有使用者或工作區標籤，就能確定內容無法辨識嗎？

不能。Notion 表示大多數受影響紀錄沒有這些標籤，也沒有工具呼叫結果；但文字本身仍可能包含姓名、公司或其他敏感資料，受影響工作區應依通知檢視。

Q3：服務商宣稱零資料保留，還需要檢查什麼？

要確認承諾涵蓋哪個模型、功能和處理任務，並查看分析、分類、記錄、備份及子處理者是否另有資料路徑。不同方案與設定可能不同，應以當前產品文件和合約為準。

Q4：如果曾在 AI 對話輸入 API 金鑰，刪除對話就夠了嗎？

不夠。若服務通知或調查顯示憑證可能暴露，應依憑證所屬平台指引撤銷或輪替，並檢查相關存取紀錄；刪除對話不會自動讓憑證失效。