Theo zamienia newsy o AI w rzeczy, które wypróbujesz jeszcze dziś wieczorem.
Otrzymuj na maila najważniejsze historie tygodnia o AI i sztuce AI — wyselekcjonowane, zwięzłe, za darmo.
Za darmo. Wypisz się w każdej chwili.
Wybierz towarzysza i poznaj jego zdanie na temat tej historii
Nowa ocena branżowa wykazuje, że wiodące laboratoria AI — te same firmy, których modele napędzają generatory obrazów, narzędzia wideo i kreatywne API używane codziennie przez miliony twórców — niemal nie posiadają publicznie udokumentowanych planów działania na wypadek, gdyby jeden z ich modeli zaczął zachowywać się w niebezpieczny, niezamierzony sposób.\n\n## Najważniejsze wnioski\n\n- Ocena standardu Control przeprowadzona przez Guidelight wykazała, że czołowe laboratoria AI w dużej mierze nie wdrażają sześciu priorytetowych praktyk powstrzymywania niekontrolowanych lub źle wyrównanych modeli.\n- Ewaluacja opiera się wyłącznie na publicznie dostępnych informacjach — co oznacza, że laboratoria mogą posiadać wewnętrzne plany, ale ich nie ujawniają.\n- Ma to znaczenie dla twórców, ponieważ te same modele bazowe napędzające generowanie obrazów i towarzyszące AI to systemy, dla których nie opublikowano żadnych protokołów powstrzymywania.\n- OpenAI rozwiązało swój zespół ds. gotowości bezpieczeństwa AI w ubiegłym miesiącu, zgodnie z poprzednim raportem Charmloop, co pogłębia obawy.\n- Luki w infrastrukturze bezpieczeństwa mogą bezpośrednio przekładać się na nagłe zmiany zachowania modeli, awarie lub ograniczenia możliwości, które zakłócają kreatywne przepływy pracy.\n\n## Co tak naprawdę mierzył standard Control Guidelight\n\nRaport pochodzi od Guidelight, który oceniał, czy czołowe laboratoria spełniają sześć priorytetowych praktyk w ramach swojego standardu Control — frameworku służącego do oceny, czy firma jest w stanie wykryć, odizolować i wyłączyć model, który zaczyna robić rzeczy, których nie powinien. Według TechCrunch, ocena opiera się wyłącznie na publicznie dostępnych informacjach, co samo w sobie jest problemem: laboratoria mogą posiadać wewnętrzne protokoły, ale nie ujawniają, jakie one są.\n\n\n\nRóżnica między „brakiem planu" a „brakiem publicznego planu" ma znaczenie, ale nie tak duże, jak mogłoby się wydawać. Jeśli laboratorium nie potrafi opisać swojego podejścia do powstrzymywania, regulatorzy, audytorzy i deweloperzy budujący na tych API również nie mogą go zweryfikować. Dla twórcy, który polega na tym, że dany model pozostaje spójny przez cały projekt — ten sam styl, to samo zachowanie, ten sam zakres wyników — ta nieprzejrzystość jest praktycznym ryzykiem, a nie tylko abstrakcją polityczną.\n\n## Ryzyko dla przepływu pracy, o którym nikt nie mówi\n\nZastanów się, jak „niekontrolowane zachowanie modelu" wygląda z perspektywy twórcy. Niekoniecznie jest to scenariusz rodem z science fiction. Może to być model, który zaczyna odmawiać realizacji promptów, które wcześniej akceptował, albo taki, który zmienia swoje domyślne ustawienia estetyczne w trakcie kampanii, bo aktualizacja bezpieczeństwa została wdrożona bez ostrzeżenia. Może to być API, które zaczyna zwracać nieoczekiwane wyniki, bo łatka wyrównująca została wdrożona reaktywnie, a nie zgodnie z planem.\n\nTen rodzaj zakłóceń jest już dobrze znany. Awaria Grok Lite z bezsensownymi odpowiedziami wcześniej w tym roku pokazała, jak szybko usterka modelu przekłada się na zepsute kreatywne pipeline'y dla każdego, kto używa go do generowania treści. Protokoły powstrzymywania niekontrolowanych modeli — lub ich brak — to wersja tego problemu znajdująca się wyżej w łańcuchu.\n\nJeśli prowadzisz pipeline do tworzenia grafik postaci lub renderujesz partie przez zewnętrzne API, brak opublikowanych planów powstrzymywania oznacza, że nie masz możliwości przewidzenia, jak laboratorium zareaguje na incydent, jak długo model może być offline ani czy zostanie wycofany, ponownie wytrenowany, czy po cichu zastąpiony. Praktycznym krokiem jest utrzymywanie co najmniej jednego zapasowego modelu w swoim stosie — czegoś, co możesz podmienić bez przebudowywania przepływu pracy generowania obrazów od zera.\n\n## Co laboratoria mogłyby robić — a czego nie robią\n\nFramework Guidelight wymaga takich rzeczy jak: udokumentowane wyzwalacze uruchamiające wyłączenie modelu, jasne łańcuchy decyzyjne dotyczące działań powstrzymujących oraz regularne ćwiczenia. Nic z tego nie jest egzotyczne. To rodzaj planowania reagowania na incydenty, który miałby każdy zespół infrastrukturalny obsługujący krytyczne usługi. Fakt, że laboratoria budujące jedne z najszerzej stosowanych narzędzi kreatywnych na świecie nie opublikowały równoważnych planów, to realna luka.\n\nNiektóre laboratoria argumentują, że publikowanie szczegółów dotyczących powstrzymywania samo w sobie mogłoby stanowić zagrożenie bezpieczeństwa — informując złych aktorów, których wyzwalaczy unikać. To uzasadnione napięcie, ale nie wyjaśnia, dlaczego nie można udostępnić ogólnych frameworków. Anthropic był bardziej przejrzysty niż większość w kwestii wytycznych dotyczących zachowania modeli, ale nawet tam ocena Guidelight wskazuje luki.\n\nDla twórców wybierających platformy i API, na których chcą budować, badanie to dodaje nową zmienną: przejrzystość infrastruktury bezpieczeństwa jest teraz kryterium wyboru, a nie tylko kwestią drugoplanową. Sprawdź katalog modeli przy ocenie opcji i weź pod uwagę, czy dane laboratorium opublikowało cokolwiek znaczącego na temat sposobu obsługi incydentów związanych z modelami — bo następny incydent to kwestia czasu, nie przypadku.
