Najpóźniej 10 listopada 2026 część użytkowników Notion dostała mail „Important security notice about the Fireworks AI incident that may impact your Notion workspace”. Sprawa Notion i Fireworks AI w skrócie: u Fireworks AI, firmy, u której Notion uruchamiał część modeli i klasyfikował rozmowy dla funkcji Insights, włamywacze dostali się do zbiorów danych, a według Notion był wśród nich zbiór z rozmowami z Notion AI. Notion szacuje, że incydent mógł dotyczyć mniej niż 1% workspace'ów. Zebrałem, co piszą o tym Notion i Fireworks, czego jeszcze nie podali i co sprawdzić w swoim workspace'ie dziś.

Ten tekst dotyczy samego incydentu. Co dzieje się z danymi w Notion AI na co dzień, czyli retencję, trenowanie, modele i umowę powierzenia, opisuję w artykule Notion AI a RODO w polskiej firmie.

W skrócie: 5 odpowiedzi

  • Czy mail jest prawdziwy? Incydent jest prawdziwy, Notion opisał go na stronie pomocy i w Security advisories. Nie potwierdza to jednak, że konkretny mail pochodzi od Notion, więc do szczegółów wchodzisz przez aplikację (pierwszy krok niżej).
  • Co wyciekło? Według Notion transkrypcje rozmów z Notion AI użytych do funkcji Insights, bez wyników wywołań narzędzi, np. treści stron. Według wpisu w Security advisories w zdecydowanej większości dotkniętych workspace'ów rozmowy nie były oznaczone autorem ani workspace'em. Same wiadomości i odpowiedzi AI mogły jednak zawierać dane identyfikujące i informacje ze stron.
  • Kogo dotyczy? Notion szacuje, że incydent mógł dotyczyć mniej niż 1% workspace'ów. Brak powiadomienia oznacza według wpisu w Security advisories, że Notion nie zidentyfikował dotąd Twojego workspace'u jako dotkniętego. Dochodzenie trwa.
  • Czy Notion trenował na tych rozmowach modele? Ujawniony zbiór Notion wiąże z funkcją Insights. Osobno pisze, że w przeszłości używał u Fireworks danych z dobrowolnego programu LEAP do eksperymentów z trenowaniem modeli, a teraz wstrzymał wszystkie treningi.
  • Co zrobić? Wejść do informacji o incydencie przez aplikację, przejrzeć ujawnione rozmowy, zmienić wklejone do czatu hasła i klucze, sprawdzić jeden przełącznik i ustalić w zespole, czego nie wpisujecie do AI.

Co sprawdzić teraz

  1. Wejdź przez aplikację, nie przez link z maila

    Właściciel workspace'u otwiera informacje o incydencie w aplikacji: „workspace sidebar → ? → Security incident review”. Notion zaznacza, że trzeba użyć aplikacji na komputerze albo przeglądarki, bo na telefonie te dane nie są dostępne.

  2. Przejrzyj ujawnione rozmowy

    W planie Enterprise właściciel dostaje plik CSV z danymi workspace'u, o ile workspace ma „managed members”. W pozostałych planach dostaje stronę z linkiem, który przekazuje członkom, a każdy członek widzi „a CSV of only the member's own data affected by the incident”. Szukaj w tych plikach haseł, kluczy API, danych klientów i pracowników. W pliku z adnotacjami z planu Enterprise pola dopisane przez Notion są oznaczone __metadata albo __analysis i według Notion nie były częścią wycieku („These added annotations and metadata were not exposed as part of the incident”), więc na przykład imię w takim polu nie dowodzi, że wyciekło. Moja rekomendacja: nie wrzucaj całego pliku do kolejnego czatu AI ani do analizatora w sieci i ogranicz dostęp do niego. Notion zaleca: „We recommend that you treat this data as if it were exposed.”

  3. Zmień hasła i klucze wklejone do Notion AI

    Jeśli ktoś w zespole wkleił do czatu hasło, klucz API albo inne dane logowania, Notion zaleca je zmienić od razu („rotating them right away”). Moja rekomendacja: unieważnij je albo wymień u wystawcy i przejrzyj logi ich użycia, bo samo usunięcie z rozmowy nie wystarczy.

  4. Sprawdź przełącznik „Share data to improve Notion AI”

    Settings → Notion AI albo Settings → Workspace → General. Moja rekomendacja: wyłącz go, jeśli w workspace'ie są dane klientów. To ogranicza udostępnianie danych w programie LEAP. W sprawdzonych komunikatach Notion nie wyjaśnił, czy ustawienie miało wpływ na zbieranie rozmów dla Insights.

  5. Ustal w zespole, czego nie wpisujesz do AI

    Moja rekomendacja: żadnych haseł i kluczy, a o klientach w czacie numerem zamiast nazwy, jeśli wystarczy. To ogranicza skutki każdego następnego incydentu, u Notion albo u innego dostawcy.

Co się stało: Notion i Fireworks AI

Fireworks AI to amerykańska firma, która udostępnia innym firmom infrastrukturę do uruchamiania modeli AI. Notion korzystał z niej przede wszystkim do dwóch zadań: „for classification jobs to help customers understand their own AI usage through a feature in Notion called Insights, and … as a general inference provider to serve open-weight models inside our product” (strona incydentu, Notion). U Fireworks włamywacze dostali się do zbiorów danych, a według Notion był wśród nich zbiór z rozmowami z Notion AI użytymi do funkcji Insights. Według Notion incydent mógł dotyczyć „<1% of Notion workspaces” („may have been affected”). Strona pomocy dodaje: „No other Notion data from your workspace is affected, and we continue to monitor this incident.” W przeszłości Notion używał Fireworks także do eksperymentów z trenowaniem modeli, o czym niżej.

Notion opisał incydent na własnej stronie pomocy i w Security advisories, więc treść maila sprawdzisz u źródła.

Dwie drogi rozmów z Notion AI do Fireworks

Schemat: rozmowy z Notion AI mogły trafiać do Fireworks dwiema drogami. Obsługa zapytań przez model open-weight działała domyślnie bez przechowywania danych i Fireworks nie wykrył tam dotąd wpływu włamania. Rozmowy użyte do funkcji Insights leżały w zbiorze danych w systemie Fireworks, który według Notion został naruszony.
Schemat: rozmowy z Notion AI mogły trafiać do Fireworks dwiema drogami. Obsługa zapytań przez model open-weight działała domyślnie bez przechowywania danych i Fireworks nie wykrył tam dotąd wpływu włamania. Rozmowy użyte do funkcji Insights leżały w zbiorze danych w systemie Fireworks, który według Notion został naruszony.

Rozmowy z Notion AI mogły trafiać do Fireworks dwiema drogami. Pierwsza to odpowiedź modelu open-weight, który Notion uruchamiał u Fireworks (pozostałe modele obsługują inni dostawcy). Takim modelem był Kimi K3, o którym Notion pisał w lipcu, że jest „Hosted by Fireworks, a US-based provider” (wpis z 27 lipca 2026). Na tej drodze Fireworks nie wykrył dotąd skutków włamania: „We have not detected any impact to Inference, Training SDK and Nexus, which are all zero data retention (ZDR) by default” (biuletyn Fireworks z 9 listopada). Fireworks zastrzega: „Our investigation is ongoing and may reveal additional information.”

Druga droga to klasyfikacja rozmów dla Insights. Naruszone zostały właśnie przechowywane dane: „for certain customers, a subset of incomplete model weights and datasets were accessed”. Notion pisze, że ujawniony zbiór zawierał rozmowy użyte do Insights, a Fireworks pisze o dostępie do zbiorów danych. Wniosek, który zostaje na dłużej: zerowa retencja przy obsłudze zapytania nie przesądza, że rozmowa nie zostanie osobno zapisana na potrzeby innej funkcji. W tym incydencie naruszony został właśnie taki osobno przechowywany zbiór. Notion pisze, że 3 listopada „deleted all data in the Fireworks system”, a dziś także: „we are no longer serving open-weight models through Fireworks”.

Insights to karta w ustawieniach Notion AI. Według pomocy otwierają ją właściciele i administratorzy w planach Business i Enterprise, a pokazywała, jak zespół używa AI („use cases and conversation counts”). Dziś strona pomocy mówi: „Insights is temporarily paused” (ustawienia Notion AI). W pomocy Notion nie znalazłem opisu przełącznika, którym administrator włączałby albo wyłączał Insights (sprawdziłem stronę ustawień Notion AI i FAQ Notion AI).

Co się stało, dzień po dniu

  1. 6 października

    Pierwszy incydent u Fireworks

    Fireworks wykrywa „unauthorized use of internal Fireworks credentials”. Napastnik dostał się do zmiennych środowiskowych zadań ewaluacyjnych części klientów, a u niektórych przechwycił klucze API zapisane jako sekrety. Dostępu do modeli, zbiorów danych ani ruchu zapytań klientów Fireworks wtedy nie wykrył.

  2. 23–24 października

    Drugie włamanie

    Włamanie u zewnętrznego dostawcy chmury, u którego Fireworks miał maszyny badawcze. Następnego dnia napastnik dociera przez nie do maszyn deweloperskich Fireworks. Fireworks wykrywa to tego samego dnia.

  3. 2 listopada

    Pierwsze zawiadomienie opisane przez Notion

    Fireworks informuje Notion o dostępie do „a small set of data”. Notion ocenia go wtedy jako „Notion AI synthetic testing data” bez danych klientów.

  4. 3 listopada

    Notion odcina Fireworks

    Notion odłącza swoje systemy od Fireworks i usuwa dane w systemie Fireworks.

  5. 6 i 8 listopada

    Nowy zbiór danych

    Fireworks zawiadamia o możliwym dostępie do danych klientów, a 8 listopada potwierdza nowy zbiór. Są w nim rozmowy z Notion AI użyte do Insights.

  6. 9–10 listopada

    Powiadomienia użytkowników

    Wpis w Security advisories, oznaczony jako zaktualizowany 9 listopada, pisze: „We have contacted our customers who were affected by the Fireworks incident.”

Daty z października podaje Fireworks (biuletyn 1, biuletyn 2), daty z listopada Notion. Notion w obu biuletynach Fireworks nie pada z nazwy.

Kto za tym stoi? Przy pierwszym incydencie Fireworks pisze w drugim biuletynie, że ślady prowadzą do grupy przestępczej nastawionej na zysk, której celem jest sprzedaż nieuprawnionego dostępu do dużych modeli językowych. Fireworks nazywa to zjawisko „LLMJacking”. W komunikatach Notion i Fireworks nie znalazłem informacji, czy ktoś wykorzystał albo opublikował rozmowy z Notion AI.

Co znaczy „unattributable”

Notion nazywa ujawnione rozmowy „unattributable” i wyjaśnia: „the chats weren't labeled with who wrote them or which workspace they came from. The transcripts also did not contain tool call results (e.g., Notion page content, or external data pulled in by Notion AI.)”. Ujawnione rozmowy nie zawierały więc wyników wywołań narzędzi, np. pobranej treści stron. Nie wyklucza to informacji ze stron, jeśli znalazły się w samych wiadomościach albo w odpowiedziach AI. Notion sam zaznacza: „Beyond what's in the chat transcript itself, there's no information tying the chat back to specific workspaces, users, or companies.” Jeśli w takiej rozmowie padła nazwa firmy, imię klienta albo hasło, mogło to zostać w ujawnionej transkrypcji, o ile ta rozmowa trafiła do zbioru.

Wpis w Security advisories zawęża to słowo: rozmowy „for the vast majority of impacted workspaces were unattributable”. Na stronie pomocy tego zastrzeżenia nie ma, a których workspace'ów nie dotyczy, Notion nie wyjaśnia.

Czy Notion trenował modele na rozmowach

Na stronie incydentu Notion pisze: „Customers in the Learning and Early Access Program (LEAP) volunteer their data to help Notion test new AI technology. In the past, we used this volunteered data to experiment with training task-specific models on Fireworks.” W innym miejscu tej samej strony: „We have also halted all training runs.” Program LEAP to przełącznik „Share data to improve Notion AI” z czwartego kroku wyżej. Od 13 października w artykule Notion AI a RODO radzę wyłączyć go, jeśli trzymasz w Notion dane klientów. Ta rada zostaje, z jednym zastrzeżeniem: wyłączenie LEAP nie jest potwierdzonym sposobem wyłączenia Insights i nie mówi, czy wcześniejsze rozmowy trafiły do ujawnionego zbioru. Według FAQ programu po wyłączeniu „no new data from your workspace will be retained”, czyli przełącznik dotyczy nowych danych (AI LEAP, FAQ).

Tego samego dnia trust center Notion pisze: „User data is never used to train or influence Notion AI models. … Only synthetic data is used for training” (trust center). Jak Notion łączy oba zdania, nie wyjaśnił.

RODO: oceń naruszenie i obowiązek zgłoszenia bez zwłoki

Jeśli w rozmowach z Notion AI były dane osobowe Twoich klientów, pracowników albo kontrahentów, decyzja należy do Ciebie jako administratora. Według art. 33 RODO administrator zgłasza naruszenie organowi nadzorczemu, w Polsce UODO, „bez zbędnej zwłoki – w miarę możliwości, nie później niż w terminie 72 godzin po stwierdzeniu naruszenia”, „chyba że jest mało prawdopodobne, by naruszenie to skutkowało ryzykiem naruszenia praw lub wolności osób fizycznych”. Informacje można uzupełniać sukcesywnie (art. 33 ust. 4). Jeśli Twoja firma przetwarza te dane w imieniu klienta, czyli jest podmiotem przetwarzającym, zgłasza naruszenie administratorowi „bez zbędnej zwłoki” (art. 33 ust. 2). Jeżeli naruszenie może powodować wysokie ryzyko naruszenia praw lub wolności osób, administrator bez zbędnej zwłoki zawiadamia także osoby, których dane dotyczą (art. 34 ust. 1). Wyjątki, np. skuteczne szyfrowanie danych, wymienia art. 34 ust. 3. Niezależnie od decyzji „administrator dokumentuje wszelkie naruszenia ochrony danych osobowych” (art. 33 ust. 5), więc zapisz, co sprawdziłeś i dlaczego zgłaszasz albo nie. Na stronie pomocy o incydencie i we wpisie w Security advisories nie znalazłem słowa o RODO ani o organach nadzorczych. Szerzej o obowiązkach wobec danych klientów piszę w części o obowiązkach polskiej firmy artykułu o Notion AI i RODO.

Co piszą użytkownicy

Na r/Notion w wątku z treścią maila powtarza się kilka wątków. To relacje użytkowników, nie sprawdzałem ich.

  • Plan Enterprise. Dwie osoby piszą, że są w planie Enterprise i dostały ten sam mail (komentarz 1, komentarz 2). Pierwsza dodaje, że w eksporcie były obie strony rozmowy. Jeśli tak było, pasuje to do schematu dwóch dróg wyżej: zerowa retencja w Enterprise dotyczy dostawców modeli przy obsłudze zapytań, a z których planów pochodzą rozmowy w zbiorze dla Insights, Notion nie napisał.
  • Insights. Jedna osoba pyta, czy którykolwiek odbiorca maila w ogóle włączał Insights, bo ona tego nie robiła. Czy Insights wymagało włączenia, Notion nie podał.
  • Dane osobowe w rozmowach. Jedna osoba pisze, że w swoim pliku znalazła imię i numer studencki z treści prośby do AI.
  • Phishing. Sporo osób pyta, czy mail nie jest próbą wyłudzenia. Bezpieczna droga to wejście przez aplikację, opisane w pierwszym kroku.

W komentarzu w drugim wątku jedna osoba łączy incydent z lipcowym wpisem Notion o rzekomym wycieku. To inna sprawa: w komunikacie z lipca 2026 Notion opisał zarzuty z czerwca o sprzedaży zbioru danych Notion i uznał je za sfabrykowane („found the materials and actor behavior to be fabricated”, wpis Notion z lipca 2026).

Czego Notion jeszcze nie podał

  • Z jakiego okresu pochodzą ujawnione rozmowy. Notion pisze „during this timeframe”, ale okresu nie podaje.
  • Jak długo zbiór dla Insights leżał w systemie Fireworks i dlaczego był przechowywany.
  • Czy Insights wymagało zgody albo przełącznika i od kiedy zbierało rozmowy.
  • Z których planów pochodziły rozmowy.
  • Których workspace'ów nie dotyczy „unattributable” z wpisu w advisories.
  • Czy wyłączenie przełącznika LEAP miało jakikolwiek wpływ na zbieranie rozmów dla Insights.

Czego oczekiwać teraz od Notion

To moja opinia, nie fakt. Notion zrobił już kilka rzeczy w dobrą stronę: wyłączył Insights, odłączył Fireworks i usunął tam dane, wstrzymał treningi i dał właścicielom oraz członkom workspace'ów wgląd w ujawnione dane. We wpisie w advisories sam stawia sobie poprzeczkę: „We will raise the standard for how your data is protected.” Po czym poznam, czy pójdzie dalej: czy funkcje, które wysyłają rozmowy do dostawców, będą wymagały włączenia przez administratora, czy Notion opublikuje, który model działa u którego dostawcy, i czy odpowie publicznie na pytania z listy wyżej.

Dla porównania, jak reagowały inne firmy. Zoom w 2020 roku zamroził na 90 dni funkcje niezwiązane z prywatnością i bezpieczeństwem, a prezes nazwał to „just a first step” (Zoom, lipiec 2020). Microsoft w 2024 roku zapowiedział „prioritizing security above other things we do, such as releasing new features” (Microsoft, maj 2024). LastPass po włamaniu z 2022 roku odnotował według prezesa spadek wskaźnika odnowień o około 8% w pierwszym kwartale 2023 (Cybersecurity Dive, czerwiec 2023).

Czy mail od Notion o incydencie Fireworks AI jest prawdziwy?

Sam incydent jest prawdziwy: Notion opisał go na swojej stronie pomocy i w Security advisories. To nie potwierdza jednak, że konkretny mail pochodzi od Notion. Do informacji o incydencie dojdziesz bez klikania w link: właściciel workspace'u otwiera w aplikacji „workspace sidebar → ? → Security incident review”. Co zobaczy, zależy od planu (plik CSV w Enterprise, link dla członków w pozostałych).

Skąd mam wiedzieć, czy incydent dotyczy mojego workspace'u?

Notion pisze, że skontaktował się z właścicielami workspace'ów, których incydent dotyczy, więc jeśli nie jesteś właścicielem, zapytaj osobę, która nim jest. Strona pomocy pisze: „If neither you nor your workspace owner has heard from us, that means your workspace is not affected, and no action is needed right now.” Wpis w Security advisories jest ostrożniejszy: „we haven't identified your workspace as affected, and no action is needed right now. Our investigation is ongoing.”

Czy wyłączony przełącznik „Share data to improve Notion AI” chronił przed wyciekiem?

Tego Notion nie wyjaśnił. Przełącznik dotyczy programu LEAP, z którego dane Notion wykorzystywał w eksperymentach z trenowaniem. Ujawniony zbiór Notion wiąże z funkcją Insights, a w sprawdzonych komunikatach nie napisał, czy przełącznik miał wpływ na zbieranie rozmów dla Insights.

Czy rozmowy z planu Enterprise też mogły trafić do zbioru?

Notion nie podał, z których planów pochodzą ujawnione rozmowy. Strona pomocy opisuje jednak osobno, co dostaje właściciel workspace'u w planie Enterprise, a na r/Notion dwie osoby piszą, że są w Enterprise i dostały mail. Zerowa retencja w Enterprise dotyczy dostawców modeli przy obsłudze zapytań, a zbiór dla Insights był osobnym zbiorem danych.

Czy Notion nadal korzysta z Fireworks?

Według Notion 3 listopada odłączył swoje systemy od Fireworks i usunął tam dane, a modeli open-weight nie serwuje już przez Fireworks. Na liście podprocesorów w trust center Fireworks 10 listopada wciąż figuruje.

Jeśli chcesz przejrzeć ustawienia Notion AI w swojej firmie, napisz do mnie.