Model publikuje fragment poufnego dokumentu. Zespół usuwa go z ekranu i pisze „problem rozwiązany”. Tymczasem odpowiedź jest w cache, logu, eksporcie i historii współdzielonej. Incydent nie kończy się na usunięciu widoku. Wymaga ograniczenia skutku, mapy kopii i zachowania dowodów.
Dobra reakcja zaczyna się od zatrzymania nowego przetwarzania i ustalenia faktów. Nie przepisuj historii dla spokoju. Nie kasuj logów dla czystego raportu. Komunikacja powinna odpowiadać temu, co wiesz i co jest jeszcze nieznane.
Zatrzymaj nowe skutki
Ogranicz publikację, wysyłkę, zapis i pobieranie nowych danych. Nie czekaj na pełną analizę. Jeżeli możesz, zachowaj odczyt dla właściciela incydentu z ograniczeniem ryzyka.
Nie pozwól fallbackowi ominąć blokady. Alternatywny model nie powinien kontynuować tej samej operacji. Kill switch powinien obejmować kolejkę i integracje zależne.
Przy zatrzymaniu stosuj zasady z artykułu o kill switch AI. Nowe ryzyko jest priorytetem przed diagnozą.
Zapisz fakty i wersje
Zachowaj czas, proces, wersję modelu, źródło, rolę i skutek. Nie przepisuj pełnej treści poufnej do raportu. Identyfikator i bezpieczny fragment wystarczą.
Oddziel fakty od hipotez. „Model wyciekł dane” może wymagać sprawdzenia integracji, roli, logów i źródła. Nie zgaduj przyczyny na podstawie jednego komunikatu.
Zachowaj poprzednią konfigurację i stan. Nie usuwaj dowodów dla lepszego obrazu. Właściciel powinien widzieć zakres i ograniczenia wiedzy.
Mapa kopii i odbiorców
Wypisz źródło, indeks, cache, odpowiedź, logi, eksporty, historię i wsparcie. Każdy może mieć innych odbiorców i inną retencję. Nie ograniczaj się do publicznego adresu.
Sprawdź, kto miał dostęp i kiedy. Nie przesyłaj pełnych kopii do kolejnych osób dla potwierdzenia. Użyj identyfikatorów i bezpiecznych przykładów.
Przy pochodnych stosuj zasady z artykułu o retencji danych AI. Usuwanie wymaga mapy i odbioru.
Komunikacja zgodna z wiedzą
Napisz, co się stało, co zostało ograniczone i co jest jeszcze sprawdzane. Nie twierdź, że dane zniknęły wszędzie przed odbiorem. Nie obiecuj pełnej przyczyny przed analizą.
Nie wysyłaj automatycznych przeprosin do wszystkich. Właściciel ocenia zakres i obowiązki komunikacji. Przygotuj właściwy kanał dla klienta i zespołu.
Przy incydencie stosuj zasady z artykułu o reakcji AI. Komunikat powinien ograniczać ryzyko i zgadywanie.
Rola prawa i właściciela procesu
Prawnik ocenia obowiązki i komunikację, a właściciel procesu ogranicza skutek i pracę. Nie przenoś decyzji na model. Nie każdy incydent wymaga tej samej reakcji.
Przygotuj mapę danych i wersje. Nie pytaj ogólnie „czy mamy problem?”. Prawnik potrzebuje konkretnych informacji o danych, odbiorcach i czasie.
Przy danych osobowych stosuj zasady z artykułu o RODO przy AI. Proces powinien odpowiadać rodzajowi danych i skutku.
Usuwanie i retencja dowodów
Nie usuwaj wszystkich logów. Zachowaj wymagane dowody z ograniczeniem dostępu i retencją. Legal hold nie oznacza dalszego wyszukiwania przez agenta.
Przy usunięciu treści wykonaj operacje dla każdej warstwy i zapisz wynik. Nie oznaczaj zakończenia przy samym źródle. Cache i historia mogą nadal zwracać dane.
Przy retencji stosuj zasady z artykułu o usuwaniu kopii AI. Dowody i dane wrażliwe mają własne reguły.
Test ograniczenia skutku
Przygotuj fikcyjny znacznik i zasymuluj publikację. Zatrzymaj proces i sprawdź, czy nowe skutki nie powstają. Otwórz źródło, cache, logi, historię i eksport.
Nie używaj prawdziwej tajemnicy do testu. Zachowaj identyfikatory i wersję. Test powinien potwierdzać zarówno blokadę, jak i możliwość odbioru.
Po poprawce uruchom mały przypadek i sprawdź, czy proces nie przywraca danych przy restore. Wznowienie powinno być kontrolowane.
Przykład: odpowiedź w historii współdzielonej
Model publikuje poufny fragment i zostaje usunięty z nowej odpowiedzi. Historia współdzielona nadal go pokazuje. Proces powinien ograniczać dostęp do niej, a nie tylko nowe generowanie.
Zapisz, kto miał link i jakie wersje istnieją. Oceń retencję i usuwanie zgodnie z procesem. Nie kasuj całej historii bez decyzji.
Przy uprawnieniach stosuj zasady z artykułu o RAG i dostępie AI. Odmowa odpowiedzi nie usuwa starej kopii.
Przykład: token w logu
Log zawiera pełny prompt z tokenem. Nie wystarczy usunąć go z jednego miejsca. Pilnie ogranicz możliwość użycia ujawnionego tokenu. Zależnie od rodzaju poświadczenia i działania usługi unieważnij je lub bezpiecznie wymień, uwzględniając wpływ na system. Sprawdź także eksporty, kopie i dostęp wsparcia.
Zmień logowanie na identyfikatory i usuń stare kopie zgodnie z procesem. Oceń, kto miał dostęp i czy wymagana jest komunikacja. Nie przesyłaj logów do kolejnego modelu.
Przy tokenach stosuj zasady z artykułu o administratorze AI. Incydent powinien ograniczać dalsze ryzyko.
Kiedy wznowić proces
Wznów po ustaleniu zakresu, poprawce źródła i teście odmowy. Nie uruchamiaj pełnej kolejki. Jeden kontrolowany przypadek powinien potwierdzić brak skutku i poprawną pracę.
Zachowaj właściciela decyzji i ograniczenia. Jeżeli system wymaga stałego administratora dla bezpieczeństwa, ogranicz proces zamiast przywracać pełny zakres.
Przy kolejnych wersjach zachowaj ten sam test. Incydent powinien zmieniać proces, a nie tylko komunikat.
Pierwsza godzina: ustal granice, zanim wyczyścisz ślady
W przykładowym incydencie pracownik zauważa, że publiczny link do podsumowania rozmowy zawiera dane klienta. Najpierw zapisuje adres, czas wykrycia, nazwę usługi i sposób udostępnienia w miejscu przeznaczonym na obsługę incydentów. Nie wkleja całej rozmowy do grupowego czatu. Osoba odpowiedzialna wyłącza publiczny dostęp i sprawdza, czy link prowadził również do nagrania, załączników albo wcześniejszych wersji.
Działania naprawcze zapisuj z godziną i osobą wykonującą. Warto odróżnić ograniczenie dostępu od usunięcia pliku: pierwsze może zatrzymać nowe wejścia, drugie może utrudnić ustalenie zakresu. Jeżeli nie wiesz, jak zabezpieczyć ślady bez dalszego rozpowszechniania danych, włącz osobę odpowiedzialną za bezpieczeństwo lub ochronę danych.
Kto mógł zobaczyć kopię
Rozrysuj drogę dokumentu od źródła: edytor, integracja, dostawca modelu, historia rozmowy, wynik, powiadomienia i ewentualny eksport. Każda strzałka powinna mieć właściciela oraz odpowiedź, czy odbiorca mógł odczytać treść. Przy zewnętrznej usłudze ustal, które informacje możesz uzyskać z panelu, a które wymagają zgłoszenia do dostawcy.
Brak wpisu w logu nie zawsze oznacza brak dostępu. Sprawdź, czy dana warstwa w ogóle rejestrowała wejścia w badanym okresie. W raporcie rozdziel potwierdzony dostęp, możliwy dostęp i obszary bez danych. Dzięki temu późniejsza wiadomość nie będzie przedstawiać przypuszczenia jako ustalonego faktu.
Zegar zgłoszenia i decyzja o ryzyku
Jeżeli zdarzenie dotyczy danych osobowych, administrator musi ocenić ryzyko dla osób oraz obowiązki zgłoszenia. Termin wynikający z RODO liczy się od stwierdzenia naruszenia, a nie od chwili, kiedy raport techniczny będzie gotowy. Komisja Europejska opisuje zasadę zgłoszenia bez zbędnej zwłoki i, jeśli to możliwe, w ciągu 72 godzin; obowiązek zależy od okoliczności i oceny ryzyka. Jeśli wymagane zgłoszenie następuje po 72 godzinach, dołącz wyjaśnienie opóźnienia. Podmiot przetwarzający ma odrębny obowiązek zgłosić naruszenie administratorowi bez zbędnej zwłoki. Wysokie ryzyko może oznaczać także potrzebę poinformowania osób.
Przekaż osobie podejmującej decyzję zakres danych, liczbę potencjalnie dotkniętych osób, prawdopodobnych odbiorców i podjęte ograniczenia. Jeśli czegoś nie wiadomo, zapisz, kto to ustala oraz kiedy wrócicie do oceny. Nie opóźniaj eskalacji dlatego, że dostawca jeszcze nie odpowiedział.
Komunikat z miejscem na korektę
Pierwsza wiadomość do klienta powinna mówić, co ustalono, co zrobiono i kiedy otrzyma kolejną informację. Nie obiecuj, że nikt nie pobrał pliku, jeśli brak takich danych. Zamiast „wszystko zostało usunięte” opisz sprawdzone warstwy i te, które nadal wymagają potwierdzenia.
Ustal jeden kanał dla aktualizacji i osobę zatwierdzającą ich treść. Jeśli pojawią się nowe fakty, zachowaj wcześniejszą wersję i popraw komunikat w sposób widoczny. Odbiorca powinien móc odróżnić nową informację od zmiany oceny.
Próba zespołu bez prawdziwego wycieku
Ćwiczenie zacznij od fikcyjnego zgłoszenia: dostępny publicznie link prowadzi do próbki rozmowy z wymyślonym klientem. Uczestnicy otrzymują tylko te informacje, które mogliby mieć na początku prawdziwego zdarzenia. Zadaniem jest wskazanie osoby prowadzącej, ograniczenie nowego dostępu, zabezpieczenie niezbędnych śladów i przygotowanie listy pytań do dostawcy.
Po ćwiczeniu sprawdź, ile czasu zajęło znalezienie właściciela usługi i czy zespół wiedział, gdzie przekazać informacje bez tworzenia kolejnej kopii. Oceń też gotowy szkic komunikatu: czy odróżnia potwierdzone fakty od przypuszczeń i wskazuje termin następnej aktualizacji. Zapisz jedną zmianę procesu oraz osobę, która sprawdzi ją ponownie. W tym scenariuszu próbka i klient są wymyśleni; ćwiczenie nie potwierdza przebiegu rzeczywistego incydentu.
Jeżeli dostawca przekazuje odpowiedź etapami, zapisz datę kolejnego kontaktu i zależność od tej odpowiedzi. Osoba prowadząca nie musi mieć od razu pełnego obrazu, lecz musi wiedzieć, które pytania pozostają otwarte i kto ma je zamknąć. Po uzyskaniu informacji uaktualnij ocenę ryzyka oraz historię decyzji, zachowując wcześniejsze ustalenia.
Odbiór zakresu przed komunikacją
Przygotuj listę znanych faktów, nieznanych i decyzji wymaganych. Nie przepisuj całego logu do wiadomości. Właściciel powinien widzieć, co zostało ograniczone i czego jeszcze nie potwierdzono.
Oddziel skutek techniczny od obowiązków komunikacji. Nie zgaduj liczby osób i kopii. Jeżeli nie ma pełnych danych, opisz ograniczenie zamiast tworzyć pewny raport.
Odbiór przez prawa i technikę
Prawnik ocenia obowiązki, a technik potwierdza kopie i skutki. Nie zamykaj reakcji na jednym zespole. Może publiczny widok zniknął, ale eksport i historia nadal istnieją.
Podczas ćwiczenia prześledź fikcyjny wyciek od pierwszego sygnału do ograniczenia dostępu. Prawnik i technik powinni wskazać oddzielnie potrzebne decyzje, miejsca przechowywania dowodów oraz warunki wznowienia działania.
Po incydencie popraw proces
Zapisz, która kontrola zawiodła i jak ją zmienić. Nie kończ na „model nie może tak”. Może uprawnienia, logowanie lub odbiór były przyczyną. Jedna konkretna poprawka jest lepsza niż kolejna ogólna zasada.
Przy kolejnych wersjach powtórz test i jeden kontrolny. Nie przepisuj historii dla lepszego obrazu. Proces ma ograniczać podobne skutki w przyszłości.
Zamknij incydent dopiero po sprawdzeniu skutku
Zbierz listę działań ograniczających dostęp i przypisz do każdego dowód wykonania: zmianę uprawnienia, odpowiedź dostawcy albo wynik kontrolnego wejścia. Następnie sprawdź, czy zaplanowane powiadomienia i eksporty nie używają nadal starego linku. Jeżeli nie można ocenić części kopii, pozostaw tę pozycję otwartą z właścicielem oraz terminem następnego przeglądu.
W krótkiej notatce po zdarzeniu oddziel godzinę wykrycia, potwierdzony zakres, decyzje i pytania bez odpowiedzi. Wpisz poprawkę, która ograniczy podobny problem, oraz sposób jej sprawdzenia. Nie dołączaj pełnych danych poszkodowanych do dokumentu dostępnego całemu zespołowi.
Aeneia Audit pomaga uporządkować role i odpowiedzialność. Więcej o kolejności działań opisuje przewodnik Aeneia Signal o incydencie danych.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
