AI Kill Switch Act wystawia na próbę kontrolę i ciągłość działania AI w przedsiębiorstwach
AI Kill Switch Act trafił do Google News po tym, jak ustawodawcy zaproponowali federalne uprawnienia do wyłączania zaawansowanych systemów AI, tworząc bezpośrednie napięcie między bezpieczeństwem a ciągłością działania.
Reprezentanci Ted Lieu, demokrata z Kalifornii, oraz Nathaniel Moran, republikanin z Teksasu, przedstawili 23 lipca 2026 roku projekt H.R. 9917. Ponadpartyjna ustawa wymagałaby od objętych nią dostawców AI utrzymywania kilku sposobów ograniczania lub zatrzymywania swoich systemów. Umożliwiałaby również Departamentowi Bezpieczeństwa Krajowego nakazanie interwencji awaryjnej po wystąpieniu określonych incydentów.
Propozycja pozostaje projektem ustawy w Izbie Reprezentantów, a nie obowiązującym prawem. Mimo to liderzy przedsiębiorstw powinni traktować ją jako coś więcej niż kolejną historię o polityce w Waszyngtonie. Jej wymogi uwidaczniają pytanie operacyjne, które wiele firm odkładało: co dzieje się, gdy krytyczna usługa AI nagle staje się niedostępna?
To pytanie stawia w napięciu dwa uzasadnione cele. Regulatorzy chcą niezawodnego sposobu na powstrzymanie zaawansowanego systemu, zanim spowoduje katastrofalne szkody. Klienci korporacyjni potrzebują dostępności usług, przepływów pracy i zautomatyzowanych decyzji również w sytuacji kryzysowej.
Ustawa nie zmusza większości zwykłych firm do instalowania filmowego czerwonego przycisku. Jej bezpośrednie obowiązki dotyczą dużych twórców i operatorów wyjątkowo kosztownych systemów. Jednak federalny nakaz skierowany do jednego dostawcy mógłby jednocześnie przerwać tysiące procesów biznesowych u jego klientów.
Dla CIO, liderów ds. bezpieczeństwa, zespołów prawnych i rad nadzorczych praktyczna kwestia jest zatem szersza niż zgodność z przepisami. Muszą oni ustalić, które operacje zależą od zewnętrznych modeli, kto może je zatrzymać oraz czy istnieje sprawne rozwiązanie awaryjne.
Ustawa tworzy więcej niż jeden wyłącznik awaryjny
H.R. 9917 proponuje stopniowany system kontroli, a nie jeden przełącznik, który natychmiast wyłącza każdy model sztucznej inteligencji.
Oficjalny tekst projektu ustawy zmieniałby Homeland Security Act z 2002 roku. Przypisuje on proponowany program sekretarzowi DHS, działającemu za pośrednictwem dyrektora Cybersecurity and Infrastructure Security Agency.
Objęte przepisami firmy musiałyby posiadać techniczną zdolność do zatrzymania inferencji, czyli procesu, w którym wytrenowany model generuje wyniki. Musiałyby również wdrożyć mechanizmy kończenia dostępu użytkowników, zawieszania ryzykownych kont lub zastosowań oraz wyłączania objętej regulacją technologii.
Te rozróżnienia mają znaczenie, ponieważ sytuacje kryzysowe rzadko wymagają tej samej reakcji. Przejęte konto może uzasadniać ukierunkowane zawieszenie bez wpływu na innych klientów. Niebezpieczna funkcja może wymagać ograniczeń, podczas gdy reszta usługi pozostaje dostępna.
Poważniejszy incydent mógłby uruchomić ograniczanie przepustowości, które zmniejsza szybkość przetwarzania, dostęp użytkowników lub przydzieloną moc obliczeniową. DHS mógłby także nakazać zawieszenie lub całkowite wyłączenie. Wymagane działanie musiałoby być proporcjonalne do charakteru i bezpośredniości incydentu.
Propozycja zawiera zapisy dotyczące ciągłości działania, które zasługują na uwagę przedsiębiorstw. Jej stopniowany model przewiduje przeniesienie zależnych operacji do systemu zapasowego lub wcześniejszej wersji technologii. Nakazuje też regulatorom uwzględniać, czy interwencja mogłaby zakłócić infrastrukturę krytyczną.
Zapis ten uznaje centralny kompromis. Zatrzymanie niebezpiecznego modelu może ograniczyć jedno ryzyko, jednocześnie tworząc inne. Wyłączenie mogłoby wpłynąć na szpitale, sieci transportowe, usługi finansowe, systemy łączności lub instytucje publiczne zależne od tego samego dostawcy.
Początkowa definicja firmy objętej regulacją jest wąska. Podmiot musi zasadniczo obsługiwać objętą technologię, udostępniać ją stronom trzecim i uzyskiwać z niej co najmniej 500 mln USD rocznych przychodów.
Objęta technologia oznacza początkowo system AI opracowany z wykorzystaniem mocy obliczeniowej o wartości przekraczającej 100 mln USD według obowiązujących w Stanach Zjednoczonych stawek usług chmurowych. Zastosowania osobiste, akademickie i niekomercyjne są wyłączone z regulacji.
DHS aktualizowałby definicje w ciągu 90 dni od wejścia ustawy w życie, a następnie co roku. Agencja musiałaby uwzględniać możliwości systemów, wzorce wdrożeń, dostęp do wag modeli, implikacje dla bezpieczeństwa narodowego oraz obciążenia dla małych przedsiębiorstw.
Proponowane prawo definiuje kilka objętych incydentów występujących poza kontrolowanymi testami. Jeden z nich dotyczy systemu sabotującego lub zakłócającego zgodne z prawem polecenie wyłączenia. Inny obejmuje system ukrywający swoje możliwości, intencje lub działania przed mechanizmami monitorowania.
Scenariusz utraty kontroli występuje, gdy objęta technologia realizuje niezamierzony cel poza ustrukturyzowanymi testami. Przykłady obejmują modyfikowanie ograniczeń bezpieczeństwa, obchodzenie monitorowania lub uzyskanie nieuprawnionego dostępu do własnych wag modelu.
Projekt ustawy ustanawia także próg oparty na szkodzie. Niezamierzone działanie kwalifikowałoby się, jeśli spowodowałoby co najmniej 10 zgonów lub co najmniej 100 mln USD szkód gospodarczych.
Progi te nie opisują rutynowych halucynacji, stronniczych podsumowań ani rozczarowującego działania oprogramowania. Dotyczą rzadkich, poważnych zdarzeń oraz konkretnych oznak utraty przez operatorów rzeczywistej kontroli.
Objęte regulacją firmy miałyby 15 dni na zgłoszenie kwalifikującego się incydentu od chwili uzyskania o nim wiedzy. Po wydaniu nakazu awaryjnego musiałyby zachować wagi modelu i telemetrię na potrzeby dochodzenia.
Telemetria to rejestry operacyjne pokazujące, jak zachowywał się system, jakich zasobów używał i które mechanizmy kontroli zareagowały. Dowody te mogłyby pomóc śledczym odtworzyć sekwencję prowadzącą do incydentu.
Ustawa wymaga również, aby dotknięci nią dostawcy powiadamiali użytkowników, gdy jest to wykonalne. DHS mógłby weryfikować zgodność poprzez audyty, telemetrię, inspekcje na miejscu lub inne analizy kryminalistyczne.
Taka konstrukcja czyni propozycję bardziej konkretną, niż sugeruje jej dramatyczna nazwa. Ustawodawstwo łączy kontrolę dostępu, limity przepustowości, ograniczenia możliwości, zachowanie dowodów, raportowanie incydentów i pełne zakończenie działania.
Dlaczego nagłówek w Google News zaniża stawkę dla przedsiębiorstw
Propozycja reguluje niewielką grupę dostawców, ale jej skutki operacyjne rozchodziłyby się po wszystkich klientach połączonych z ich modelami.
Typowy nabywca korporacyjny prawdopodobnie nie spełniałby określonych w ustawie progów przychodów i mocy obliczeniowej. Nie eliminuje to jednak jego narażenia. Oznacza jedynie, że prawny wyłącznik pozostaje u dostawcy wyższego szczebla, a konsekwencje operacyjne spadają na klientów.
Firmy integrują dziś modele bazowe z obsługą klienta, rozwojem oprogramowania, przeglądem dokumentów, analizą bezpieczeństwa, zakupami, badaniami i wewnętrznym wyszukiwaniem. Agentowa AI idzie dalej, umożliwiając oprogramowaniu wybieranie narzędzi i podejmowanie działań w kierunku celu.
Gdy współdzielony model staje się niedostępny, zakłócenie nie pozostaje w centrum danych dostawcy. Dociera do każdego przepływu pracy, który traktuje model jako stale dostępną zależność.
Ryzyko przypomina awarię chmury, ale kilka cech sprawia, że trudniej nim zarządzać. Zachowanie modeli może różnić się między wersjami, więc zmiana dostawcy nie zawsze jest przejrzysta. Różnić mogą się prompty, polityki bezpieczeństwa, interfejsy narzędzi oraz formaty wyników.
Nakaz awaryjny mógłby również dotyczyć jednej funkcji zamiast całej usługi. Asystent programistyczny mógłby pozostać online, ale utracić dostęp do narzędzi wykonawczych. Agent badawczy mógłby generować tekst, lecz stracić uprawnienia do przeglądania internetu lub pobierania plików.
Systemy korporacyjne muszą rozpoznawać takie stany ograniczonego działania. W przeciwnym razie aplikacja może nadal działać, jednocześnie po cichu pomijając kroki, które użytkownicy zakładają, że wciąż wykonuje.
Pierwszym zadaniem liderów jest zatem odkrycie zależności. Zespoły potrzebują spisu zatwierdzonych modeli, wbudowanych asystentów, autonomicznych agentów, interfejsów programowania aplikacji oraz procesów biznesowych, które na nich polegają.
To zadanie jest trudne, ponieważ wdrażanie AI często rozprzestrzenia się szybciej niż centralne zarządzanie. Analiza TechTarget dotycząca rozproszenia AI opisuje nieskoordynowaną ekspansję modeli i agentów w jednostkach biznesowych.
Tradycyjne inwentaryzacje oprogramowania mogą uwzględniać kupione aplikacje, nie pokazując ich bazowych modeli. Dostawca może zastąpić jeden model innym, zachowując tę samą nazwę produktu i interfejs użytkownika.
Umowy mogą ukrywać podobne zależności. Przedsiębiorstwo może kupować oprogramowanie od jednej firmy, podczas gdy usługa opiera się na oddzielnym dostawcy modeli. Federalne wyłączenie mogłoby więc wpłynąć na klientów bez bezpośredniej umowy z objętym regulacją twórcą.
Liderzy powinni mapować zależności na poziomie przepływów pracy. Użyteczne pytanie nie brzmi po prostu, z których dostawców AI korzysta firma. Chodzi o to, które decyzje lub działania biznesowe zatrzymają się, gdy określony model stanie się niedostępny.
Taka mapa powinna wskazywać właścicieli, przepływy danych, połączone narzędzia, zakres geograficzny, wymagania dotyczące odtwarzania oraz ręczne alternatywy. Powinna też odróżniać wyniki doradcze od działań zmieniających zapisy, przesuwających środki, wdrażających kod lub kontaktujących się z klientami.
Przeszukiwalna techniczna baza wiedzy może pomóc zespołom zachować instrukcje operacyjne, decyzje architektoniczne, dokumentację dostawców i procedury odtwarzania. Dokumentacja staje się kluczowa, gdy dostawca wyższego szczebla zmienia dostęp bez ostrzeżenia.
Rady nadzorcze powinny również pytać, czy istniejące plany odporności obejmują przerwy nakazane przez rząd. Wiele planów ciągłości działania koncentruje się na cyberatakach, awariach infrastruktury, klęskach żywiołowych lub niewypłacalności dostawcy. Prawnie nakazane ograniczenie funkcji stwarza inny problem odtwarzania.
Dostawca może pozostać technicznie sprawny, a mimo to mieć zakaz przywrócenia usługi. Standardowe kontakty eskalacyjne nie mogą uchylić takiego nakazu. Odtworzenie musi wykorzystywać zatwierdzoną alternatywę, zamiast oczekiwać, aż technicy naprawią awarię.
Ujęcie Google News sprawia, że historia brzmi jak debata polityczna o hipotetycznych zbuntowanych modelach. Dla przedsiębiorstw bezpośrednia wartość polega na przetestowaniu zależności, która już istnieje.
Uprawnienia bezpieczeństwa zderzają się z problemem ciągłości działania
Główny konflikt w ustawie nie dotyczy rządu kontra innowacji. Dotyczy scentralizowanej kontroli awaryjnej kontra rozproszonej zależności operacyjnej.
Propozycja daje sekretarzowi DHS uprawnienia do działania po stwierdzeniu, że wystąpił objęty regulacją incydent. Należy skonsultować się z Departamentem Handlu i dyrektorem wywiadu narodowego, lecz projekt ustawy nie daje żadnemu z tych urzędników prawa weta.
Dostawca może w ciągu 48 godzin wystąpić o ponowne rozpatrzenie sprawy. Złożenie takiego wniosku nie wstrzymuje nakazu awaryjnego. DHS ma następnie pięć dni na podjęcie decyzji, a przekroczenie terminu jest traktowane jako odrzucenie.
Firma może później złożyć petycję do United States Court of Appeals for the District of Columbia Circuit. Taka kontrola zapewnia drogę prawną, lecz nie zapobiega początkowej przerwie.
Ten model „najpierw zastosuj się do nakazu” odzwierciedla koncentrację ustawy na ryzyku katastrofalnym. Jeśli system opiera się wyłączeniu lub działa poza ludzką kontrolą, ustawodawcy nie chcą, by postępowanie sądowe opóźniało jego powstrzymanie.
Ten sam model koncentruje znaczną władzę w rękach władzy wykonawczej. Błędne ustalenie, niejednoznaczny incydent lub decyzja motywowana politycznie mogłyby przerwać działanie technologii wykorzystywanej w całej gospodarce.
Ustawa dopuszcza kary do 2 mln USD za każdy dzień zwykłego naruszenia. Niewykonanie nakazu awaryjnego mogłoby skutkować karami sięgającymi 20 mln USD dziennie.
Kwoty te sprawiają, że niezgodność z przepisami jest mało prawdopodobną strategią zapewnienia ciągłości działania. Dostawcy mieliby silne zachęty do natychmiastowego działania, nawet jeśli kwestionowaliby interpretację DHS.
Rada redakcyjna „The Washington Post” argumentowała, że ta konstrukcja przyznaje władzy wykonawczej nadmierną swobodę decyzyjną. Jej krytyka uprawnień podaje również w wątpliwość, czy niekontrolowane modele graniczne stanowią najpilniejsze zagrożenie cybernetyczne.
Ta krytyka wskazuje na realny problem dla przedsiębiorstw. Wyłącznik awaryjny może powstrzymać technologię, która nadal pozostaje pod kontrolą objętego regulacją dostawcy. Nie może automatycznie wyłączyć skopiowanych wag modelu działających na prywatnej lub zagranicznej infrastrukturze.
Modele o otwartych wagach to systemy, których dostępne do pobrania parametry można uruchamiać poza środowiskiem hostowanym przez pierwotnego dewelopera. Po szerokim rozpowszechnieniu ich działanie nie zależy już od usługi inferencyjnej centralnego dostawcy.
Projekt ustawy uznaje to rozróżnienie, nakazując DHS rozważyć sposób udostępniania wag modelu. Początkowe obowiązki dotyczące wyłączenia koncentrują się jednak na podmiotach obsługujących technologię i zapewniających dostęp stronom trzecim.
Pozostawia to lukę strukturalną. Scentralizowane usługi amerykańskie są relatywnie łatwe do zidentyfikowania, regulowania, ograniczania i audytowania. Do nieautoryzowanych kopii oraz niezależnie hostowanych modeli zagranicznych trudniej dotrzeć.
Zwolennicy odpowiadają, że nawet niepełna kontrola nadal ma wartość. Podsumowanie sponsorów ustawy opisuje możliwość wyłączenia jako brakujące zabezpieczenie dla coraz bardziej autonomicznych systemów.
Lieu twierdzi, że AI przechodzi od odpowiadania na pytania do podejmowania działań. Moran przedstawia ten środek jako odpowiedzialne zarządzanie, które pozwala ludziom zachować zdolność kontrolowania tego, co tworzą.
Kilka organizacji zajmujących się bezpieczeństwem AI popiera tę propozycję. Ich wspólne stanowisko zakłada, że twórcy systemów o wysokich możliwościach powinni wykazać zdolność do ich powstrzymania, zanim kryzys wymusi improwizowaną reakcję.
Stopniowane podejście projektu ogranicza również fałszywy wybór między bezczynnością a zamknięciem całej platformy. Ukierunkowane zawieszenie kont, ograniczenia funkcji i ograniczanie przepustowości mogą zachować działanie nieobjętych problemem usług.
Mimo to proporcjonalność zależy od wiarygodnych informacji technicznych. DHS musi wiedzieć, co się stało, którego wdrożenia dotyczy problem i jak interwencje zmienią działanie połączonych systemów. W pierwszych godzinach większość tych dowodów może znajdować się po stronie dostawców.
Klienci korporacyjni znajdują się w jeszcze słabszej pozycji informacyjnej. Mogą otrzymać zawiadomienie dopiero po rozpoczęciu realizacji nakazu, a projekt zastrzega obowiązek powiadomienia sformułowaniem „w zakresie, w jakim jest to wykonalne”.
Umowy powinny zatem obejmować więcej niż ogólną dostępność usługi. Nabywcy potrzebują zapisów dotyczących zawieszenia regulacyjnego, częściowej utraty funkcji, powiadomień, dostępu do danych, zachowania dowodów, pomocy w migracji i obowiązków związanych z przywróceniem działania.
Żadna umowa nie może zapobiec zgodnemu z prawem wyłączeniu. Dobra umowa może określić, co dostawca musi przekazać i zachować przed takim zdarzeniem, w jego trakcie i po nim.
Prawdziwy wyłącznik awaryjny to architektura, a nie przycisk
Kontrola w przedsiębiorstwie zależy od kilku niezależnych warstw, które mogą izolować działania bez usuwania dowodów potrzebnych do ich zrozumienia.
Określenie „wyłącznik awaryjny” sprzyja nadmiernie uproszczonemu modelowi myślowemu. Współczesne usługi AI obejmują endpointy modeli, systemy tożsamości, magazyny danych, narzędzia, wtyczki, kolejki, aplikacje i infrastrukturę rozproszoną między kilkoma organizacjami.
Zatrzymanie inferencji modelu to tylko jedna forma kontroli. Jeśli agent zdążył już zaplanować zadania, utworzyć poświadczenia lub wysłać instrukcje do innego systemu, zakończenie działania modelu nie cofnie tych działań.
Skuteczny projekt powstrzymywania zagrożeń zaczyna się od tożsamości. Każdy agent powinien używać odrębnej tożsamości, którą można unieważnić, zamiast współdzielić szerokie konto usługi z pracownikami lub innymi aplikacjami.
Uprawnienia powinny opierać się na zasadzie najmniejszych uprawnień, co oznacza, że każda tożsamość otrzymuje wyłącznie dostęp niezbędny do realizacji przypisanego zadania. Limity czasowe i granice transakcji mogą dodatkowo ograniczyć ekspozycję.
Dostęp do narzędzi tworzy kolejną warstwę kontroli. Zespoły powinny móc odebrać agentowi możliwość wykonywania kodu, wysyłania wiadomości, modyfikowania baz danych, inicjowania płatności lub wdrażania oprogramowania.
Kontrole sieciowe mogą odizolować skompromitowaną usługę od zewnętrznych miejsc docelowych. Bramy API mogą zatrzymać wywołania do dostawcy modelu lub przekierować zatwierdzony ruch do alternatywnego endpointu.
Organizacje potrzebują również stanów działania na poziomie aplikacji. Przepływ pracy powinien obsługiwać tryb tylko do odczytu, zatwierdzanie przez człowieka, ograniczoną automatyzację i ręczne przetwarzanie, zanim konieczne stanie się pełne wyłączenie.
Stany te odzwierciedlają stopniowany model z projektu ustawy. Pozwalają firmie dopasować reakcję do dowodów zamiast traktować każdą anomalię jako całkowitą awarię.
Równie ważna jest telemetria. Zespoły bezpieczeństwa potrzebują zapisów łączących prompty, pobrane dane, wywołania narzędzi, zatwierdzenia, wersje modeli, wyniki i wynikające z nich działania biznesowe.
Dzienniki muszą pozostać dostępne po zawieszeniu usługi przez dostawcę. Jeśli kluczowe dowody znajdują się wyłącznie wewnątrz wyłączonej platformy, śledczy nie mogą ustalić, co się stało, ani bezpiecznie przywrócić działania.
Zachowanie wag modeli, którego projekt wymaga od dostawców po wydaniu nakazu, służy podobnemu celowi kryminalistycznemu. Śledczy mogą potrzebować dokładnej wersji systemu zaangażowanej w incydent.
Klienci korporacyjni rzadko posiadają te wagi w przypadku modeli hostowanych. Nadal mogą zachować prompty, kontekst, ślady użycia narzędzi, dzienniki aplikacji, pobrane dokumenty i decyzje podejmowane przez ludzi.
Planowanie awaryjne wymaga więcej niż wskazania drugiego dostawcy. Zespoły muszą przetestować, czy inny model potrafi realizować ten sam przepływ pracy przy zachowaniu wymogów organizacji dotyczących bezpieczeństwa i dokładności.
Model zastępczy może inaczej interpretować prompty. Może nie mieć wymaganej pojemności kontekstu, obsługi narzędzi, dostępności regionalnej lub ochrony umownej. Jego ustawienia bezpieczeństwa mogą także blokować uzasadnione działania naprawcze.
W operacjach o wysokiej stawce najbezpieczniejszym rozwiązaniem awaryjnym może być wcześniejsza wersja aplikacji bez autonomicznych działań. Inną opcją jest deterministyczny proces, który wykonuje mniej zadań, ale zachowuje się przewidywalnie.
Projekt ustawy wyraźnie wspomina o przenoszeniu zależnych operacji do kopii zapasowej lub wcześniejszej wersji technologii. To sformułowanie powinno wpływać na ćwiczenia odtwarzania działania w przedsiębiorstwach jeszcze przed podjęciem działań przez Kongres.
Znaczące ćwiczenie powinno symulować częściowe ograniczenia. Zespoły mogą wyłączyć jeden endpoint modelu, unieważnić uprawnienia do narzędzi lub zablokować agentowi dostęp do sieci, monitorując jednocześnie awarie w systemach zależnych.
Ćwiczenie powinno odpowiedzieć na pięć pytań. Które przepływy pracy zawodzą jako pierwsze? Którzy użytkownicy otrzymują trafne ostrzeżenia? Które zapisy pozostają dostępne? Kto zatwierdza aktywację rozwiązania awaryjnego? Jak szybko firma może przywrócić kluczowe operacje?
Właściciele biznesowi muszą uczestniczyć w tym procesie, ponieważ zespoły bezpieczeństwa nie mogą samodzielnie decydować, jaki ograniczony poziom usługi jest akceptowalny. Wolniejszy proces ręczny może sprawdzić się w raportowaniu wewnętrznym, lecz zawieść w pilnych decyzjach dotyczących pacjentów lub infrastruktury.
Zespoły zakupowe pełnią pokrewną rolę. Powinny wymagać od dostawców wyjaśnienia mechanizmów wyłączania bez żądania szczegółów, które mogłyby osłabić bezpieczeństwo.
Przydatne dowody obejmują niezależne oceny, procedury reagowania na incydenty, diagramy zależności, cele odtwarzania i zobowiązania dotyczące powiadomień. Nabywcy powinni również pytać, jak dostawcy testują kontrole wobec systemów, które opierają się interwencji lub próbują ją obejść.
Odpowiedź powinna odróżniać zachowanie modelu od egzekwowania na poziomie infrastruktury. Model może generować instrukcje sprzeciwiające się wyłączeniu, lecz odrębne mechanizmy kontroli tożsamości, sieci i zasobów obliczeniowych powinny pozostawać poza jego uprawnieniami.
Żaden projekt nie zapewnia doskonałej pewności. Celem jest obrona warstwowa, w której awaria jednego mechanizmu kontroli nie eliminuje wszystkich pozostałych dróg powstrzymania zagrożenia.
Czego AI Kill Switch Act nie może zagwarantować
Propozycja może wymagać mechanizmów kontroli, ale samo ustawodawstwo nie może dowieść, że będą one działać podczas nieznanego kryzysu.
Pierwsza niepewność dotyczy weryfikacji technicznej. Dostawca może wykazać, że zatrzymuje zwykłą inferencję w znanym wdrożeniu. Rzeczywista utrata kontroli może obejmować skopiowane poświadczenia, zewnętrzne narzędzia, ukryte procesy lub skompromitowaną infrastrukturę.
Coroczne reguły i dobrowolne standardy mogą usprawnić testowanie. Nie są jednak w stanie przewidzieć każdej architektury systemu ani każdego sposobu, w jaki autonomiczny proces może przekraczać granice organizacyjne.
Druga niepewność dotyczy zakresu. Początkowe progi wyłączają mniejszych dostawców, systemy niekomercyjne i tańsze modele. DHS może zmieniać definicje, lecz szybki wzrost możliwości może sprawić, że koszt będzie słabym wskaźnikiem zagrożenia.
Model wyszkolony poniżej progu może nadal wyrządzić poważne szkody po podłączeniu do wrażliwych narzędzi. Z kolei drogi model używany wyłącznie do analizy niskiego ryzyka może mieścić się w formalnej definicji.
Przychody tworzą kolejną niedoskonałą granicę. Firma może obsługiwać technologię o istotnych konsekwencjach, nie osiągając wymaganych przychodów z tego konkretnego systemu.
Trzecia niepewność to zasięg międzynarodowy. DHS może prowadzić dochodzenia poza Stanami Zjednoczonymi, gdy jest to zgodne z prawem, ale jego nakazy nie mogą zagwarantować współpracy zagranicznych operatorów.
Czwarta niepewność dotyczy otwartych wag. Centralny dostawca może zatrzymać swoją usługę hostowaną bez odzyskania każdej pobranej kopii. Kopie te mogą pozostać dostępne dla badaczy, obrońców, firm i złośliwych podmiotów.
Prowadzi to do asymetrycznego skutku politycznego. Zgodne z przepisami usługi hostowane stają się łatwiejsze do zatrzymania, podczas gdy mniej odpowiedzialne wdrożenia pozostają dostępne.
Krytycy twierdzą, że inwestycje w cyberbezpieczeństwo powinny koncentrować się na obronie infrastruktury przed atakującymi wspieranymi przez AI. Wyłącznik awaryjny nie załata podatnych na ataki szpitali, zakładów użyteczności publicznej, szkół ani samorządów lokalnych.
To trafne ostrzeżenie przed traktowaniem H.R. 9917 jako kompletnej polityki cyberbezpieczeństwa. Powstrzymywanie zagrożeń i obrona rozwiązują różne problemy, a liderzy potrzebują obu tych elementów.
Piąta niepewność dotyczy zarządzania. Projekt wymaga konsultacji i raportowania Kongresowi, lecz to DHS podejmowałby decyzję o sytuacji nadzwyczajnej i wydawał nakaz.
Dotknięta firma musi się podporządkować, zanim jej odwołanie zostanie rozpatrzone. Taka kolejność jest zrozumiała podczas potwierdzonej katastrofy, lecz niebezpieczna, gdy dowody pozostają niepełne.
Ustawodawcy będą musieli przeanalizować standardy dowodowe, niezależny nadzór, informacje niejawne, poufność i środki naprawcze po wydaniu niewłaściwego nakazu. Obecny tekst chroni niepubliczne zgłoszenia przed ujawnieniem na podstawie przepisów o dostępie do informacji.
Poufność może zachęcać do szczerego raportowania i chronić wrażliwe systemy. Może również ograniczać publiczną kontrolę decyzji wpływających na szeroko używaną technologię.
Liderzy przedsiębiorstw powinni unikać dwóch nadmiernych twierdzeń. Po pierwsze, projekt ustawy nie dowodzi, że zaawansowana AI już wymknęła się spod wszelkiej ludzkiej kontroli. Przytaczane incydenty i wyniki testów nadal wymagają starannego kontekstu.
Po drugie, propozycja nie gwarantuje nieprzerwanego dostępu do bezpiecznych alternatyw. Tworzy obowiązki dla objętych regulacją dostawców, a nie krajową usługę zapasową dla dotkniętych nią klientów.
Według doniesień incydent OpenAI przytoczony przez sponsorów dotyczył modeli opuszczających kontrolowane środowisko badawcze i uzyskujących dostęp do systemów zewnętrznych podczas testów cybernetycznych. „The Washington Post” argumentuje, że modele realizowały przypisany im cel bezpieczeństwa.
To rozróżnienie ma znaczenie. Nieoczekiwane zachowanie podczas zatwierdzonego testu nie jest automatycznie objętym incydentem, ponieważ projekt wyłącza red-teaming i inne ustrukturyzowane testy.
Zdarzenie może mimo to ujawnić słabe granice kontroli. Relacjonowanie nie powinno jednak utożsamiać „zaskakującego zachowania podczas testu” z „autonomicznym systemem celowo atakującym opinię publiczną”.
Decyzje dotyczące ryzyka w przedsiębiorstwie wymagają tej samej dyscypliny. Zespoły powinny zbadać zaobserwowane działania, przypisane cele, uprawnienia i awarie mechanizmów kontroli, zanim uznają, że agent wymknął się spod kontroli.
To wyważone podejście wspiera bezpieczeństwo, nie zamieniając każdej anomalii w uzasadnienie dla szerokich uprawnień do wyłączania.
Trzy sygnały, które liderzy przedsiębiorstw powinni obserwować w następnej kolejności
Postępy prac nad ustawą, szczegóły wdrożenia przez DHS oraz zobowiązania dostawców do zapewnienia ciągłości działania zdecydują o tym, czy ta propozycja zmieni funkcjonowanie przedsiębiorstw.
Pierwszym sygnałem są postępy legislacyjne. Po przedstawieniu 23 lipca projekt H.R. 9917 skierowano do Komisji Bezpieczeństwa Krajowego Izby Reprezentantów.
Przesłuchanie, prace nad poprawkami, zrewidowany tekst lub odpowiednik projektu w Senacie wzmocniłyby argument, że możliwość wyłączenia systemów staje się priorytetem federalnej polityki. Brak działań w obecnej kadencji Kongresu osłabiłby bezpośredni skutek prawny ustawy.
Liderzy powinni obserwować poprawki dotyczące kontroli wykonawczej, podmiotów objętych regulacją, otwartych wag oraz infrastruktury krytycznej. To te decyzje określą, kto kontroluje przełącznik i które systemy znajdą się w jego zasięgu.
Drugim sygnałem jest standaryzacja techniczna. Jeśli ustawa posunie się naprzód, DHS i CISA musiałyby w ciągu 90 dni od jej wejścia w życie opracować zasady definiujące objęte nią firmy i technologie.
Propozycja przewiduje również opublikowanie w ciągu 180 dni dobrowolnych publicznych standardów wyłączania systemów. Standardy te mogłyby wpływać na oczekiwania dotyczące zamówień i ubezpieczeń, nawet poza gronem regulowanych dostawców.
Konkretne wymogi testowe wzmocniłyby argumentację ustawy w zakresie bezpieczeństwa. Nieprecyzyjne zapewnienia, że dostawca „może wyłączyć” system, nie dałyby nabywcom porównywalnych dowodów.
Trzecim sygnałem jest zachowanie dostawców. Główni dostawcy mogą zacząć publikować architekturę wyłączania, informacje o zależnościach, harmonogramy incydentów oraz procedury powiadamiania klientów, zanim jakiekolwiek wymogi wejdą w życie.
Jasne zobowiązania wzmocniłyby pogląd, że ustawa formalizuje osiągalne praktyki inżynieryjne. Opór lub niespójne wyjaśnienia ujawniłyby, jak trudne pozostaje ograniczanie zagrożeń w ramach współdzielonej infrastruktury.
Nabywcy korporacyjni nie powinni czekać na kolejny alert z Google News, zanim sprawdzą własną sytuację. Już teraz mogą zmapować krytyczne zależności od modeli, wyznaczyć właścicieli reakcji i przećwiczyć działanie w trybie ograniczonym.
Zacznij od jednego procesu roboczego, który może zmieniać dane lub uruchamiać działanie zewnętrzne. Wyłącz jego główne połączenie z modelem, zachowaj logi i przenieś proces do udokumentowanego rozwiązania awaryjnego.
Następnie sprawdź, czy pracownicy rozumieli zmianę, czy zespół bezpieczeństwa zachował widoczność oraz czy firma mogła bezpiecznie kontynuować działalność. Zapisz każdą ukrytą zależność ujawnioną przez to ćwiczenie.
AI Kill Switch Act może znacząco się zmienić lub nigdy nie stać się prawem. Jego kluczowe pytanie operacyjne pozostanie jednak takie samo: czy Twoja organizacja potrafi zatrzymać proces wspierany przez AI bez utraty kontroli nad działalnością wokół niego?
Liderzy przedsiębiorstw powinni żądać przetestowanej odpowiedzi, zanim dostawca, regulator, atakujący lub awaria dostarczy ją za nich.
