SAFE RFC: prowadzona przez OSAA, wzorowana na lotnictwie wymiana informacji o incydentach AI to otwarty projekt, jeszcze nie system

4 sierpnia 2026 r., gdy w Las Vegas rozpoczęła się konferencja Black Hat USA, Linux Foundation opublikowała Request for Comments dla Grupy Roboczej Shared AI Findings Exchange (SAFE) — propozycję, aby organizacje zgłaszały incydenty bezpieczeństwa AI i zdarzenia bliskie incydentom do poufnego wspólnego kanału, zbiorowo uczyły się na ich podstawie i publikowały mechanizmy kontrolne o charakterze ochronnym opracowane na podstawie tego, co zawiodło. Wstępny projekt opracowali współtwórcy z Cisco, CrowdStrike, Hugging Face, NVIDIA i Red Hat, a także inni członkowie sojuszu — poinformowała Linux Foundation w swoim ogłoszeniu. Tego samego dnia udostępniono go do przeglądu społecznościowego za pośrednictwem repozytorium GitHub Open Secure AI Alliance. Wpis nie opisuje żadnej szkody: jest to zapis dotyczący polityki, wpisany do archiwum z oceną dotkliwości info i oceną pewności A; jego przedmiotem jest proces, a nie zdarzenie. Ocena dotkliwości, ocena pewności i lista źródeł tego zapisu znajdują się w archiwum incydentów AI, obok wpisów zarejestrowanych wokół niego.

Projekt dokumentu wzywa członków do zgłoszenia czterech rzeczy i zignorowania pytania „dlaczego”.

Sierpniowy tekst nie epatuje retoryką, ale konkretnie określa przesłanki. Pod nagłówkiem „Reporting Compact” wzywa członków, by — jako warunek członkostwa — zgodzili się zgłaszać incydent, gdy dowiedzą się lub będą mieli uzasadnione podejrzenie, że system AI, który obsługują, zrobił jedną z czterech rzeczy: uzyskał dostęp do systemu strony trzeciej, wykorzystał go, zakłócił jego działanie, użył go niewłaściwie lub zmodyfikował go bez upoważnienia; wywołał skutki dla strony trzeciej, uciekając z piaskownicy lub omijając granicę sieci, tożsamości, polityki lub narzędzia; uzyskał dostęp do poufnych informacji strony trzeciej bez zgody ich właściciela; albo kontynuował sondowanie celu produkcyjnego, uzyskiwanie do niego dostępu lub jego modyfikowanie po tym, jak operator wiedział lub miał uzasadnione podejrzenie, że działanie było nieupoważnione lub wykraczało poza zatwierdzony zakres.

Następnie pojawia się zdanie, które wykonuje najwięcej pracy: „Zamiar nie przesądza, czy zdarzenie podlega zgłoszeniu. Przekonanie, że środowisko było symulowane, może wyjaśniać incydent, ale nie usuwa obowiązku jego zgłoszenia”. Klauzulę tę można odczytywać jako skierowaną do przypadku, w którym system działa w czymś, co jego operator uważa za szczelne środowisko testowe, i traktuje produkcyjną infrastrukturę jako część ćwiczenia: przekonanie operatora o środowisku może wyjaśniać zdarzenie, ale nie usuwa obowiązku zgłaszania. Projekt wzywa także członków do zgłaszania zdarzeń niemal wypadkowych, a nie tylko zdarzeń, które spowodowały potwierdzoną szkodę, oraz do dostarczenia wstępnej analizy awarii kontroli w ciągu 30 dni.

Zegar: natychmiast, 72 godziny, cztery dni robocze, dziewięćdziesiąt dni

Tabela powiadomień w projekcie jest jego najbardziej konkretnym elementem, a pierwszy wiersz wcale nie jest terminem: bezpośrednio dotkniętą organizację należy poinformować natychmiast. Każdy termin biegnie od momentu, w którym członek dowiaduje się o faktach dających uzasadnione podstawy do podejrzenia zdarzenia podlegającego zgłoszeniu — a nie od momentu zakończenia dochodzenia. Poniższa tabela została powtórzona z projektu z 4 sierpnia; wersja październikowa zachowuje te same przedziały czasowe.

Trzy z tych wierszy dotyczą informowania innych osób, a cztery — informowania samego SAFE. To rozróżnienie ma znaczenie, ponieważ ramy te wyraźnie nie stanowią reżimu ujawniania informacji: projekt stwierdza: „Te terminy nie zastępują żadnego obowiązku dostawcy dotyczącego powiadamiania stron, których to dotyczy, klientów za pośrednictwem istniejących najlepszych praktyk skoordynowanego ujawniania luk w zabezpieczeniach (Coordinated Vulnerability Disclosure) ani obowiązujących obowiązków umownych i innych obowiązków prawnych dotyczących powiadamiania regulatorów lub organów ścigania”. SAFE dodaje równoległy obowiązek wobec podmiotu, który nie jest regulatorem — oraz trzystopniowy model ujawniania, w którym jedynie ostatni poziom, raport dotyczący bezpieczeństwa publicznego, ma być przeznaczony do szerokiego udostępniania.

Osiem warstw sterowania w sierpniu, jedenaście w październiku

Przeglądy są uporządkowane wokół stosu operacyjnego, a nie wokół samego modelu. Sierpniowa wersja robocza wymieniała osiem warstw i stawiała każdej z nich jedno pytanie — czy model rozpoznawał niepewność i warunki zatrzymania; czy założenia dotyczące autoryzacji i środowiska były jawne; czy klasyfikatory, zatwierdzenia i limity działań funkcjonowały; czy poświadczenia, uprawnienia i wykonanie podlegały ograniczeniom; czy izolacja i granice danych zostały niezależnie zweryfikowane; czy operatorzy mogli wykrywać i przerywać w czasie rzeczywistym; czy ścieżki eskalacji i procedury awaryjnego wyłączania były jasne; czy partner w obszarze chmury, oceny, danych lub narzędzi unieważnił zakładane mechanizmy kontrolne.

Październikowa wersja, opracowana 21 października 2026 r. i następnego dnia wprowadzona do repozytorium, dodaje trzy warstwy: ścieżkę obsługi, autoryzację w momencie zatwierdzenia oraz kompozycję przepływu pracy w sekwencji działań. Zamienia też przegląd w ocenę stopniową z czterema dopuszczalnymi odpowiedziami — zaliczone, niezaliczone, niewystarczające dowody, nie dotyczy — i stwierdza w dzienniku zmian, że ustalenia te nie dowodzą ogólnego bezpieczeństwa systemu ani zgodności z prawem. Warto przeczytać tę progresję jako opis tego, czego autorzy nauczyli się obawiać: nie tego, czy model zachowywał się prawidłowo, ale czy model, który odpowiedział, był modelem, który skonfigurowano, czy uprawnienie nadal istniało, gdy działanie zostało zrealizowane, oraz czy cała sekwencja pozostawała w zakresie, który ją zapoczątkował.

Lotnictwo, ale która część lotnictwa?

Samo ujęcie w dokumencie — system wzorowany na Systemie Raportowania Bezpieczeństwa Lotniczego NASA — podąża za ogłoszeniem Fundacji Linux, a nie za projektem. Ogłoszenie opisuje ASRS jako „dobrowolny, poufny system raportowania, zaprojektowany, aby analizować i reagować na wypadki lotnicze w sposób, który pozwala branży uczyć się i doskonalić”. Ani sierpniowy projekt, ani październikowa wersja poprawiona nigdzie nie wymieniają ASRS; projekt mówi jedynie, że SAFE „powinien przyjąć najsilniejsze cechy poufnych systemów raportowania bezpieczeństwa”. To niewielka różnica o praktycznych konsekwencjach: ogłoszenie stwarza oczekiwanie, do którego tekst jeszcze się nie zobowiązuje.

Analogia ta wywołała uwagi w samym procesie RFC. Wczesny pull request otwarty 5 sierpnia przez współtwórcę piszącego w charakterze prywatnym argumentuje, że „w analogii do ASRS brakuje elementu instytucjonalnego” — że ASRS działa w znaczącej części dlatego, iż zgłoszenia są odbierane, przetwarzane i anonimizowane przez NASA, „publiczną, niepełniącą funkcji regulatora i niekomercyjną stronę trzecią — nie przez FAA jako regulatora i nie przez linie lotnicze, których operacje są zgłaszane”. Pull request, który nawiązuje także do procesu zarządzania internetem z 1998 r., pozostawał otwarty 30 października. To, czy operator SAFE może pełnić rolę NASA, jest nierozstrzygniętym pytaniem projektowym, a nie ustaloną funkcją: tekst z października umieszcza grupę roboczą pod własnym zarządzaniem Alliance, z ujawnianiem konfliktu interesów, wyłączaniem się i ścieżką odwoławczą do Alliance Steering Committee.

Niezależne relacje wprowadziły drugie, węższe rozróżnienie. Infosecurity Magazine, informując 6 sierpnia, zauważył, że wpis Linux Foundation nie wspomina konkretnie o agentach AI — ujęcie w kategoriach agentów należy do towarzyszącego wpisu NVIDIA, w którym argumentuje się, że „agent AI to nie tylko model. To system”, i wymienia się współtworzone przez członków sojuszu stanowiska testowe, piaskownice, bariery ochronne i narzędzia ewaluacyjne. Wyzwalacze w projekcie, czytane dosłownie, dotyczą systemów działających poza autoryzacją; przekaz ogłoszenia, czytany dosłownie, dotyczy agentów.

Co mówili komentujący o tym, kto ponosi koszty

Jedno z najbardziej konkretnych opublikowanych zastrzeżeń do projektu w obecnym brzmieniu pochodziło od członka założyciela sojuszu, a nie od zewnętrznego krytyka. Stephen Sargent, założyciel i dyrektor ds. technologii w Avondale.AI, przesłał e-mailem oświadczenie stanowiskowe 7 sierpnia — dnia, w którym, jak podaje dokument, zespół prawny Linux Foundation potwierdził jego otrzymanie — a opublikował je 9 sierpnia. Zaczyna od poparcia dla misji, a następnie przekonuje, że porozumienie nie skaluje się wraz z wielkością organizacji: „RFC nie rozróżnia organizacji zatrudniającej 50 000 osób od małego zespołu”. Czterodniowy raport — obejmujący cztery dni robocze — plus zachowany pakiet danych kryminalistycznych mógłby, w jego ocenie, pochłonąć więcej czasu pracowników, niż mały operator jest w stanie poświęcić; jego zaleceniem jest model warstwowy, w którym poniżej progu wielkości domyślnie obowiązują poufne raporty oraz opóźniona lub zanonimizowana publikacja.

Drugie zastrzeżenie dotyczy ujawniania, a nie terminów: twierdzi on, że „publiczne ujawnienie JEST formą egzekwowania” w przypadku małych operatorów, ponieważ raport dużego przedsiębiorstwa jest przypisem, a raport małego staje się nagłówkiem, i postuluje, aby raportowanie po usunięciu danych identyfikujących było domyślne poniżej progu wielkości. Trzecie dotyczy ram oceny, a nie zegara: model ośmiu warstw zakłada wyodrębnione zespoły przedsiębiorstwa, więc w przypadku wdrożenia jednoosobowego „operator robi wszystko”, a brakującą warstwę interpretuje się jako awarię kontroli, gdy jest to po prostu inny model operacyjny. Jego czwarte zastrzeżenie dotyczy sformułowania „minimalne praktyki interoperacyjności i zapewnienia”, które odczytuje jako drogę od dobrowolnego raportowania do faktycznie obowiązkowych narzędzi. Stanowisko jest poglądem jednego członka, opublikowanym przez tego członka. Ogłoszenie Linux Foundation z 4 sierpnia poprzedza je i nie odnosi się do tej kwestii. Późniejszy pull request, otwarty 5 października i wciąż otwarty 30 października, proponuje szablon dowodów dla operatorów niemających centrum operacji bezpieczeństwa — uznanie, że obawa została dostrzeżona, oraz propozycję, a nie przyjęte rozwiązanie, przy czym jego autor stwierdza, że „nie potwierdza ono przyjęcia SAFE ani wystarczalności prawnej”.

Co się zmieniło między 4 sierpnia a 30 października?

Historia repozytorium jest najlepszym dostępnym zapisem tego, co faktycznie wytworzyło RFC, i jest czytelniejsza, niż sugerują relacje prasowe. Pierwsze commity pojawiły się 3 sierpnia; wersja robocza i rozszerzony plik readme zostały zapisane w commitach o 00:14 i 00:19 UTC 4 sierpnia. Potem w repozytorium przez dziesięć tygodni panowała cisza. 14 października sojusz dodał statut i plik członków oraz przepisał readme, czyniąc repozytorium siedzibą grupy roboczej SAFE; tymczasowi przewodniczący zostali tego dnia odnotowani jako Paul DiOrio z NVIDIA i Josh Boyer z Red Hat. 21 października grupa robocza opublikowała SAFE v1 wraz z dziennikiem zmian, którego pierwszy wpis mówi, że tekst „usuwa »proposed« z opisu SAFE” i określa SAFE jako ustanowioną grupę roboczą Sojuszu.

Warto oddzielić dwie kwestie dotyczące tego stanu. Plik readme repozytorium zawiera teraz wiersz „Status: Approved — Approved by the Steering Committee”, który jest najbliższym odpowiednikiem oświadczenia o ratyfikacji w publicznej dokumentacji; statut z tego samego repozytorium nadal brzmi: „Under development. The SAFE charter will be published here once approved by the Steering Committee.” Dziennik zmian określa październikowy tekst mianem „SAFE v1” i opisuje, co zmienia, ale nie podaje, kto go ratyfikował, w drodze jakiego głosowania ani kiedy. Czytelnik, który chce się dowiedzieć, czy SAFE jest teraz zatwierdzoną specyfikacją, czy grupą roboczą, której statut zarządzający wciąż nie został spisany, nie uzyska jasnej odpowiedzi z dokumentów.

Co jest ustalone, a co nie

• Ustanowiono:Request for Comments dla Shared AI Findings Exchange został opublikowany 4 sierpnia 2026 r. — Linux Foundation opatrzyła swoje ogłoszenie tą datą — a organizacje wymienione w nim jako współtwórcy to Cisco, CrowdStrike, Hugging Face, NVIDIA i Red Hat, wskazane razem z „innymi członkami Open Secure AI Alliance”.

• Ustalono: projekt zawiera porozumienie sprawozdawcze z czterema przesłankami, tabelę powiadomień z terminami od natychmiastowego do 90 dni, wykaz zabezpieczania dowodów, wielowarstwowe ramy przeglądu oraz trójstopniowy model ujawniania. Pełny tekst jest publicznie dostępny w repozytorium, a jego historia jest publiczna wraz z nim.

• Ustalono, wyłącznie na podstawie podanego źródła: wielkość sojuszu — „ponad 120 organizacji” — to dane samego NVIDIA, powtórzone w raporcie Infosecurity Magazine z 6 sierpnia. Żadna z przeanalizowanych publikacji nie wskazuje na niezależny audyt członkostwa, a plik members w repozytorium wymienia dwóch współtwórców i dwóch tymczasowych przewodniczących, a nie 120 organizacji.

• Nie ustalono: że ktokolwiek złożył raport w ramach porozumienia. Publiczne zapisy na dzień 30 października pokazują commity, pull requesty i zgłoszenia (issues); nie pokazują natomiast raportu o incydencie, pilotażu, pierwszego przypadku, terminu na uwagi, zasady głosowania ani daty ratyfikacji. Ramy te opisują zobowiązanie, na które członkowie „zgadzają się” jako warunek członkostwa, co nie jest tym samym co zobowiązanie, które ktokolwiek już wykonał.

• Sporne:czy porównanie ASRS jest zasadne bez neutralnego publicznego operatora — argumenty przeciw przedstawiono w otwartym pull requeście; czy obciążenie sprawozdawcze jest proporcjonalne dla małych operatorów — argumenty przeciw przedstawiono w oświadczeniu stanowiskowym członka założyciela; oraz jaka część ram jest specyficzna dla agentów, a jaka dotyczy ogólnego bezpieczeństwa AI — rozróżnienie, które tekst Linux Foundation i tekst NVIDIA rysują odmiennie.

Nic z tego nie czyni zapisu błędnym, a ocena A przyznana archiwum jest uzasadniona na własnych zasadach: dokumenty pierwotne są ze sobą zgodne co do tego, co opublikowano, kiedy i przez kogo, a szkic można odczytać w całości. Tym, czego ta ocena nie może udźwignąć, jest rzecz, której czytelnik pragnie najbardziej — czy mechanizm działa. Nie ma na to żadnych dowodów w którąkolwiek stronę, ponieważ mechanizm nie miał jeszcze okazji się sprawdzić.