Ostrzeżenie Roberta M. Lee dotyczące AI: infrastruktura krytyczna wdraża AI szybciej, niż dostrzega związane z nim zagrożenia
Robert M. Lee wystosował ostrzeżenie dotyczące AI po tym, jak Dragos ustalił, że jedynie 30% sieci technologii operacyjnych zapewniało wgląd w ich środowiska. Ostrzeżenie Roberta M. Lee dotyczące AI wskazuje na narastający konflikt w przedsiębiorstwach użyteczności publicznej, fabrykach, centrach danych i systemach energetycznych. Operatorzy wdrażają autonomiczne oprogramowanie, zanim wielu z nich potrafi niezawodnie obserwować istniejące urządzenia.
Lee, CEO i współzałożyciel Dragos, twierdzi, że wdrażanie AI postępuje szybciej niż monitorowanie bezpieczeństwa w obszarze technologii operacyjnych. Technologia operacyjna, czyli OT, obejmuje sprzęt i oprogramowanie sterujące procesami fizycznymi. W przeciwieństwie do typowej aplikacji biurowej awaria OT może zakłócić dostawy energii elektrycznej lub wody, produkcję, transport albo inną podstawową usługę.
Nie jest to po prostu kolejne ostrzeżenie o przestępcach wykorzystujących AI. Trudniejszy problem wynika z umieszczania AI w środowiskach, które już zawierają starszy sprzęt, niepełne inwentaryzacje i słaby monitoring. AI może poprawiać prognozowanie i efektywność, ale może też zacierać przyczyny zmian w procesie fizycznym.
Ten kompromis stawia operatorów infrastruktury między presją na szybszą automatyzację a dyscypliną inżynierską wymaganą do bezpiecznej eksploatacji. Atakujący również coraz dokładniej badają systemy sterowania. Wyścig nie toczy się więc między wdrażaniem AI a oporem wobec technologii. Chodzi o szybką automatyzację kontra widoczność operacyjna.
Ostrzeżenie Lee przenosi debatę o AI do świata operacji fizycznych
Istotna zmiana polega na tym, że AI przechodzi od narzędzi doradczych do systemów mogących wpływać na procesy fizyczne.
Lee przedstawił swoje stanowisko w opublikowanej 11 września 2026 r. przez World Economic Forum analizie infrastruktury. Opisał zastosowania AI wchodzące do zakładów produkcyjnych, sieci elektroenergetycznych, centrów danych, farm bateryjnych, obiektów energii odnawialnej i działalności górniczej.
Niektóre wdrożenia nadal pomagają ludziom analizować dane lub przewidywać potrzeby konserwacyjne. Inne zbliżają się do pętli sterowania, czyli procesu sprzężenia zwrotnego łączącego czujniki, decyzje i fizyczne urządzenia. Ta zmiana modyfikuje możliwe konsekwencje błędu.
Błędną rekomendację na pulpicie można przeanalizować, zanim ktokolwiek podejmie działanie. Zautomatyzowany kontroler może zmienić zachowanie urządzeń, zanim operator zrozumie uzasadnienie. Większa autonomia skraca drogę między wynikiem modelu a skutkiem fizycznym.
Zarządy i kadra kierownicza mają istotne powody, by wdrażać takie systemy. AI może pomagać prognozować popyt, optymalizować zużycie energii, wykrywać nietypowe zachowanie urządzeń i ustalać priorytety konserwacji. Operatorzy infrastruktury mierzą się także z niedoborami personelu, starzejącym się sprzętem i wymaganiami dotyczącymi większej efektywności.
Korzyści te tworzą presję na skracanie harmonogramów walidacji. Lee ostrzega, że ta sama presja może ograniczać kontrolę nad nowymi dostawcami i zwiększać złożoność systemów. Organizacja zyskuje kolejną warstwę decyzyjną, podczas gdy jej zespół bezpieczeństwa może nadal nie mieć pełnej inwentaryzacji zasobów.
Podstawowe systemy przeszły już kilka transformacji technologicznych. Sterowanie mechaniczne przekształciło się w systemy cyfrowe. Odizolowane sieci przemysłowe uzyskały połączenia z sieciami biznesowymi, usługami zdalnymi i urządzeniami korzystającymi z protokołu internetowego.
Każda transformacja przyniosła użyteczne możliwości i nowe zależności. Wiele organizacji nie osiągnęło pełnej widoczności, zanim nadeszła kolejna zmiana. AI wkracza teraz w to niedokończone środowisko.
Ryzyko nie ogranicza się do sytuacji, w której model wygeneruje nieprawidłową odpowiedź. Model może zależeć od danych zewnętrznych, usług chmurowych, interfejsów programowania aplikacji lub aktualizacji dostawcy. Każda zależność tworzy kolejną ścieżkę awarii, którą operatorzy muszą rozumieć.
Usługa AI może zniknąć podczas awarii dostawcy lub korekty rynkowej. Aktualizacja modelu może zmienić zachowanie wcześniej testowane przez inżynierów. Naruszone dane mogą zniekształcać rekomendacje, nie powodując oczywistego błędu oprogramowania.
Infrastruktura krytyczna nie może traktować takich możliwości jak zwykłego przestoju aplikacji. Operatorzy muszą zachować bezpieczne stany, procedury ręczne i wiarygodne dowody na potrzeby dochodzeń po incydentach. Ostrzeżenie Roberta M. Lee dotyczące AI czyni te wymogi operacyjne centrum debaty.
Lee nie postuluje, by właściciele infrastruktury odrzucili AI. Twierdzi, że zarządzanie, widoczność i planowanie awaryjne muszą pojawić się przed wdrożeniem głębszej autonomii. W przeciwnym razie wdrożenie może zwiększyć niepewność w systemach, w których już teraz ma ona konsekwencje fizyczne.
Ryzyko AI dla infrastruktury według Dragos zaczyna się od braku widoczności
AI nie tworzy każdej słabości infrastruktury, ale może zwielokrotniać skutki słabości, których obrońcy nie widzą.
Ustalenia dotyczące zagrożeń z 2026 r., na których Lee opiera swój argument, opisują poważną lukę w widoczności. Dragos podaje, że tylko 30% ocenianych sieci OT miało wystarczający wgląd w swoje środowiska. Firma informuje również, że 56% nie potrafiło uzyskać widoczności poniżej granicy między IT a OT.
Według firmy 88% miało trudności z wykrywaniem i reagowaniem. Liczby te pochodzą od Dragos, dostawcy zabezpieczeń OT, a nie z niezależnego rządowego spisu. Należy je traktować jako ustalenia wynikające z klientów, dochodzeń i telemetrii firmy.
Mimo tego ograniczenia wzorzec ma znaczenie. Organizacja nie może chronić zasobów, których nie zidentyfikowała. Nie może też badać podejrzanej aktywności, jeśli ruch sieciowy, zmiany w kontrolerach i działania inżynierskie nigdy nie zostały zarejestrowane.
Tworzy to odrębne ryzyko AI dla infrastruktury według Dragos. Nowe systemy AI mogą dodawać przepływy danych, komponenty oprogramowania, poświadczenia i połączenia zewnętrzne. Mogą również podejmować decyzje dotyczące urządzeń wykorzystujących wyspecjalizowane protokoły przemysłowe.
Tradycyjny monitoring IT nie zawsze interpretuje te protokoły ani procesy fizyczne. Zespół bezpieczeństwa korporacyjnego może wykryć nietypowe logowanie, nie rozumiejąc, czy zmieniło ono działanie pompy, przekaźnika, turbiny czy linii produkcyjnej. Monitoring natywny dla OT łączy aktywność cybernetyczną z oczekiwanym zachowaniem urządzeń.
Dragos podaje, że organizacje z kompleksową widocznością OT wykrywały i opanowywały incydenty ransomware średnio w ciągu pięciu dni. Lee porównał tę liczbę ze średnią dla całej branży wynoszącą 42 dni. Porównanie sugeruje, że widoczność może istotnie skrócić czas działania atakującego.
Nie dowodzi jednak, że sam monitoring spowodował tę różnicę. Organizacje o szerszej widoczności mogą także mieć lepsze obsadę kadrową, segmentację, plany reagowania na incydenty i wsparcie kierownictwa. Dane pokazują związek zasługujący na uwagę, a nie uniwersalną gwarancję wydajności.
Problem widoczności staje się trudniejszy, gdy AI wprowadza decyzje probabilistyczne zamiast deterministycznych. Tradycyjna logika sterowania zwykle opiera się na zdefiniowanych regułach, które inżynierowie mogą sprawdzić. System uczenia maszynowego może reagować inaczej, gdy zmieniają się jego dane wejściowe, model lub otaczający kontekst.
Ta zmienność nie czyni AI automatycznie niebezpieczną. Zwiększa jednak wymagania dotyczące testowania i dokumentacji. Operatorzy potrzebują zapisów wskazujących, która wersja modelu działała, jakie dane otrzymała, jakie działanie zarekomendowała i czy zatwierdził je człowiek.
Muszą też odróżniać zachowanie modelu od złośliwej ingerencji. Nieoczekiwane działanie może wynikać z uszkodzonych danych, przejętego konta, niebezpiecznej instrukcji, błędu oprogramowania lub zwykłej zmienności modelu. Bez wystarczającego logowania te scenariusze mogą wyglądać identycznie.
Organizacje infrastrukturalne powinny zatem zmapować każdą zależność AI, zanim przyznają jej uprawnienia operacyjne. Mapa ta obejmuje dane treningowe i operacyjne, dostawców modeli, usługi chmurowe, integracje, użytkowników, poświadczenia, kanały aktualizacji i dotknięte zasoby fizyczne.
Praca ta przypomina budowanie przeszukiwalnej technicznej bazy wiedzy, lecz wymagania są bardziej rygorystyczne. Zespoły potrzebują kontrolowanych zapisów, jasnej odpowiedzialności i przetestowanych procedur odzyskiwania. Szersza inżynierska baza wiedzy może wspierać dokumentację, ale nie zastępuje monitoringu bezpieczeństwa OT.
Widoczność ma również wymiar ludzki. Operatorzy muszą wiedzieć, kiedy automatyzacja jest aktywna i jakie ma uprawnienia. Zespoły bezpieczeństwa potrzebują wystarczającej wiedzy o procesach, by rozpoznać, kiedy technicznie poprawne polecenie tworzy niebezpieczny stan fizyczny.
Celem nie jest rejestrowanie większej ilości danych bez określonego celu. Chodzi o zachowanie wystarczającego kontekstu na potrzeby wykrywania, interwencji i analizy przyczyn źródłowych. Bezpieczeństwo AI w infrastrukturze krytycznej zależy od tych dowodów przez cały cykl eksploatacji systemu.
Atakujący mapują te same pętle sterowania, do których wejdzie AI
Operatorzy infrastruktury dodają inteligencję do środowisk sterowania, podczas gdy przeciwnicy uczą się, jak działają te środowiska.
Dragos informuje, że w swoim cyklu raportowym za 2026 r. śledził 26 grup zagrożeń OT. Firma twierdzi, że przeciwnicy wyszli poza podstawowy dostęp i zaczęli mapować pętle sterowania. Działania te obejmowały identyfikowanie stacji roboczych inżynierów oraz gromadzenie plików konfiguracyjnych lub danych alarmowych.
Plik konfiguracyjny może ujawnić, jak komunikuje się sprzęt przemysłowy i jakie limity regulują dany proces. Dane alarmowe mogą pokazać, co operatorzy uznają za stan nieprawidłowy. Stacje robocze inżynierów często zapewniają uprzywilejowany dostęp do kontrolerów i innych wrażliwych zasobów.
To rozpoznanie ma znaczenie, ponieważ zakłócenie procesu fizycznego wymaga czegoś więcej niż wejścia do sieci. Atakujący muszą rozumieć urządzenia, harmonogramy, mechanizmy bezpieczeństwa i zależności operacyjne. Szczegółowe mapowanie obniża tę barierę wiedzy.
Lee wskazał ELECTRUM i KAMACITE jako przykłady grup dążących do głębszego zrozumienia tych systemów. Powiedział, że KAMACITE przez miesiące mapował pętle sterowania w infrastrukturze Stanów Zjednoczonych. ELECTRUM wcześniej atakował ukraińską sieć energetyczną i nadal rozwijał możliwości wymierzone w systemy energetyczne.
Według Lee ELECTRUM zaatakował rozproszone zasoby energetyczne w Polsce w grudniu 2025 r. Zasoby te obejmowały systemy zarządzania energią odnawialną. Przypominają środowiska, w których operatorzy coraz częściej chcą, aby AI optymalizowała produkcję i magazynowanie energii.
Nie oznacza to, że AI spowodowała ten incydent. Pokazuje to, że podstawowe środowiska sterowania już przyciągają zdolnych przeciwników. Dodanie źle zarządzanej automatyzacji mogłoby zwiększyć liczbę komponentów, które atakujący mogą badać lub manipulować nimi.
AI zmienia również ekonomikę działań ofensywnych. Modele mogą pomagać w analizie kodu, rozpoznaniu, tłumaczeniu, przeglądzie dokumentacji i tworzeniu skryptów. Mogą pomóc mniej doświadczonym atakującym szybciej zrozumieć nieznany sprzęt.
Najnowsze doniesienia sugerują, że AI często przyspiesza istniejące techniki, zamiast tworzyć całkowicie nowe. Atakujący nadal korzystają z wystawionych urządzeń, domyślnych poświadczeń, słabej segmentacji i opóźnionego łatania. AI może pomóc im szybciej znajdować i wykorzystywać te znane słabości.
To rozróżnienie zapobiega przesuwaniu się narracji w stronę science fiction. Przedsiębiorstwo użyteczności publicznej nie musi mierzyć się z w pełni autonomiczną superinteligencją, aby doświadczyć zagrożenia związanego z AI. Grupa kierowana przez ludzi, wykorzystująca AI do skalowania rutynowego rozpoznania, może wywołać natychmiastową presję.
Defensywna szansa jest równie realna. AI może pomóc zespołom bezpieczeństwa priorytetyzować alerty, analizować duże zbiory danych, identyfikować nietypowe sekwencje i pozyskiwać kontekst techniczny. Zastosowania te mogą być wartościowe, gdy wykwalifikowani ludzie zachowują uprawnienia do podejmowania istotnych działań.
Konflikt pojawia się, gdy organizacje traktują defensywną AI jako substytut podstawowych zabezpieczeń. Model alertowy nie zrekompensuje niezarządzanego zdalnego dostępu. Automatyczna analiza nie odzyska logów, których organizacja nigdy nie zebrała.
Zasady bezpieczeństwa OT CISA, opisane w OT security principles, podkreślają decyzje, które zapewniają bezpieczne i chronione środowiska operacyjne. Wytyczne powstały przed tym konkretnym ostrzeżeniem, ale ich priorytety pozostają aktualne.
Właściciele infrastruktury nadal potrzebują dokładnych wykazów zasobów, bezpiecznych konfiguracji, segmentacji sieci, kontrolowanego zdalnego dostępu oraz przetestowanych procedur reagowania na incydenty. AI powinna działać w ramach tych zabezpieczeń. Nie powinna stać się drogą na skróty, która je omija.
Najsilniejszy model wdrożenia przydziela AI wąskie, obserwowalne obowiązki. Model może klasyfikować przypadki serwisowe bez bezpośredniej zmiany ustawień urządzeń. Może przygotować podsumowanie dochodzenia, podczas gdy analitycy weryfikują przedstawione dowody.
Systemy o wyższym ryzyku wymagają silniejszych granic. Operatorzy mogą ograniczać polecenia, egzekwować deterministyczne limity bezpieczeństwa, wymagać ludzkiego zatwierdzenia oraz izolować funkcje krytyczne. Mogą również testować zachowanie systemu, gdy dane stają się niedostępne lub wprowadzające w błąd.
Takie podejście traktuje AI jako jeden z elementów systemu bezpieczeństwa, a nie jako niekwestionowanego operatora tego systemu. Zachowuje korzyści wynikające z szybszej analizy, jednocześnie ograniczając drogę od awarii modelu do fizycznego zakłócenia.
Ostrzeżenie Roberta M. Lee dotyczące AI ujawnia kompromis związany z automatyzacją
Kluczowy wybór nie dotyczy tego, czy używać AI, lecz tego, czy automatyzacja pozostanie obserwowalna, odwracalna i podporządkowana zabezpieczeniom.
Ostrzeżenie Roberta M. Lee dotyczące AI opisuje kompromis, który może zostać przesłonięty przez typowe wdrożenia korporacyjne. Większa autonomia może zmniejszyć obciążenie pracą i skrócić czas reakcji. Może jednak również skrócić czas, w którym człowiek może zakwestionować niebezpieczną decyzję.
Operatorzy infrastruktury od dawna zarządzają automatyzacją poprzez przeglądy inżynieryjne, kontrolę zmian, redundancję i projektowanie odporne na awarie. AI nie unieważnia tych praktyk. Zwiększa potrzebę ich starannego stosowania.
Wdrożenie powinno zaczynać się od jasno zdefiniowanego problemu operacyjnego. Zespoły muszą określić, do czego model ma dostęp, co może rekomendować i co może zmieniać. Powinny także wskazać działania, których model nigdy nie może podejmować.
Te granice muszą być egzekwowane technicznie. Dokument polityki nie powstrzyma integracji z nadmiernymi uprawnieniami przed wydawaniem poleceń. Kontrole dostępu, architektura sieci i systemy bezpieczeństwa muszą ograniczać rzeczywiste uprawnienia modelu.
Testy muszą obejmować więcej niż przeciętną dokładność. Operatorzy potrzebują scenariuszy uwzględniających brakujące sensory, uszkodzone dane wejściowe, sprzeczne instrukcje, niedostępne usługi chmurowe i nieoczekiwane stany urządzeń. Muszą testować odzyskiwanie sprawności po awarii komponentu AI.
AI risk framework NIST porządkuje pracę nad ryzykiem wokół zarządzania, mapowania, pomiaru i kontroli. W kwietniu 2026 roku NIST ogłosił również prace nad profilem infrastruktury krytycznej dla tego frameworku.
Profil ten ma pomóc operatorom infrastruktury przełożyć zasady godnej zaufania AI na praktyki specyficzne dla poszczególnych sektorów. Jego opracowanie sygnalizuje, że ogólne polityki AI nie wystarczą w operacjach fizycznych. Energetyka, gospodarka wodna, transport i produkcja przemysłowa mają odmienne konsekwencje oraz ograniczenia.
NIST uznaje również bezpieczeństwo i odporność za kluczowe cechy godnej zaufania AI. Odporność oznacza, że system może wytrzymać problemy i odzyskać sprawność bez niedopuszczalnych szkód. W przypadku wdrożenia przemysłowego obejmuje to bezpieczne działanie, gdy model jest niedostępny.
Ręczna obsługa pozostaje więc istotnym testem. Zespoły powinny wiedzieć, czy personel może kontynuować świadczenie kluczowych usług po utracie dostawcy AI, punktu końcowego modelu lub wspierającego zbioru danych. Potrzebują również realistycznych szacunków, jak długo może trwać takie rozwiązanie awaryjne.
Ręczne rozwiązanie awaryjne, które istnieje wyłącznie w dokumentacji, może zawieść podczas kryzysu. Operatorzy muszą ćwiczyć je w kontrolowanych warunkach. Rotacja personelu, zmiany sprzętu i rosnąca automatyzacja mogą po cichu sprawić, że stare procedury staną się bezużyteczne.
Ciągłość działania dostawcy rodzi kolejne obawy. Operator infrastruktury może zależeć od startupu, zastrzeżonego modelu lub integracji chmurowej, która szybko się zmienia. Zapewnienia kontraktowe nie zastąpią technicznych planów wyjścia.
Organizacje powinny zachować dane i konfigurację potrzebne do przejścia na rozwiązanie innego dostawcy. Powinny rozumieć, które funkcje przestają działać, gdy usługa znika. Potrzebują także kontroli nad aktualizacjami, które mogą zmienić zweryfikowane zachowanie systemu.
Zarządzanie danymi powinno należeć do tego samego planu operacyjnego. Narzędzia AI mogą ujawniać wrażliwe szczegóły sieci, dokumentację urządzeń lub informacje o incydentach, gdy zespoły przekazują materiały do usług zewnętrznych. Niekontrolowane prompty mogą stać się kolejną ścieżką eksfiltracji danych.
Uregulowany information workflow może pomóc zespołom organizować zatwierdzone materiały i ograniczać rozproszone przetwarzanie. Operatorzy infrastruktury krytycznej nadal potrzebują jednak kontroli specyficznych dla sektora, regulujących klasyfikację, retencję, dostęp i przetwarzanie zewnętrzne.
Sceptyczne pytanie brzmi, czy dostawcy i operatorzy mogą walidować szybko zmieniające się modele z rygorem oczekiwanym wobec długo eksploatowanego sprzętu przemysłowego. Modele mogą być aktualizowane co miesiąc, podczas gdy systemy sterowania pozostają wdrożone przez dekady. Te harmonogramy nie są naturalnie zgodne.
Żaden framework nie wyeliminuje tej rozbieżności. Operatorzy muszą zarządzać nią poprzez kontrolę wersji, powtarzalne testy, etapowe wdrożenia, monitorowanie i możliwość wycofania zmian. Powinni zakładać, że zachowanie modelu i warunki zagrożeń będą się zmieniać.
Bezpieczeństwo AI w infrastrukturze krytycznej zależy zatem od ograniczania niespodzianek. Zespoły nie mogą przewidzieć każdej awarii, ale mogą zachować dowody, granice uprawnień i bezpieczne ścieżki odzyskiwania sprawności. Te możliwości decydują o tym, czy anomalia stanie się możliwym do opanowania incydentem, czy niewyjaśnioną awarią.
Regulacje się rozwijają, ale operatorzy nie mogą czekać na idealny zbiór zasad
Wytyczne rządowe coraz częściej dostrzegają ryzyko, lecz odpowiedzialność nadal spoczywa na operatorach podejmujących dziś decyzje wdrożeniowe.
AI security roadmap CISA wprost odnosi się do wdrażania AI w infrastrukturze krytycznej. Agencja stwierdziła, że wdrożenia mogą zwiększać narażenie na awarie, ataki fizyczne i cyberataki.
Mapa drogowa wezwała do stosowania praktyk secure-by-design, red teamingu, zarządzania podatnościami oraz współpracy z interesariuszami infrastruktury. Cele te wyznaczyły kierunek. Nie stworzyły wiążących wymagań technicznych dla każdego sektora ani wdrożenia.
Regulacje dotyczące infrastruktury krytycznej są rozproszone, ponieważ sektory znacząco się różnią. Sieć elektroenergetyczna, zakład wodociągowy, szpital, rurociąg i sieć transportowa nie korzystają z identycznych technologii ani modeli ryzyka. Różnią się także własność i uprawnienia regulacyjne.
Takie rozproszenie może prowadzić do nierównego zarządzania AI. Duży operator może stworzyć wyspecjalizowany program oceny. Mniejsze przedsiębiorstwo komunalne może polegać na zapewnieniach dostawcy, ponieważ nie dysponuje specjalistyczną wiedzą w zakresie bezpieczeństwa AI.
W tym miejscu ostrzeżenie Roberta M. Lee dotyczące AI wywiera presję na zarządy i zespoły zakupowe. Nie mogą zakładać, że regulatorzy lub dostawcy modeli rozwiązali już każde ryzyko operacyjne. Decyzje zakupowe stają się decyzjami dotyczącymi architektury bezpieczeństwa.
Umowy powinny wymagać dokumentacji zależności modelu, procesów aktualizacji, incydentów bezpieczeństwa, przetwarzania danych i obowiązków wsparcia. Operatorzy potrzebują również prawa do testowania systemów i otrzymywania informacji o istotnych zmianach.
Niezależna ocena może pomóc, ale oceniający musi rozumieć OT. Ogólna ocena aplikacji może pominąć bezpieczeństwo procesu, zachowanie sterowników lub odzyskiwanie sprawności operacyjnej. Bezpieczeństwo infrastruktury wymaga współpracy specjalistów ds. cyberbezpieczeństwa, inżynierów, dostawców i operatorów pierwszej linii.
Regulatorzy mogą poprawić spójność, definiując minimalny zakres dowodów wymaganych dla wdrożeń o wyższym ryzyku. Dowody te mogą obejmować modele zagrożeń, wyniki walidacji, wymagania dotyczące kontroli przez człowieka, raportowanie incydentów i wykazane procedury awaryjne.
Mimo to zgodność z przepisami nie powinna stać się jedynym celem. System może spełniać wymagania listy kontrolnej, a jednocześnie pozostawiać ważne zależności fizyczne bez analizy. Istotne pytanie brzmi, czy organizacja może utrzymać bezpieczne operacje podczas ataku, błędu lub utraty usługi.
Wyzwanie ekonomiczne pozostaje znaczące. Wiele organizacji infrastrukturalnych ma ograniczoną liczbę pracowników i starzejący się sprzęt. Nowe nakazy bez finansowania lub wsparcia wdrożeniowego mogą tworzyć biurokrację bez znaczącego ograniczenia ryzyka.
Dlatego podstawowe zabezpieczenia mają znaczenie. Performance goals CISA priorytetyzują praktyki o szerokiej wartości w ograniczaniu ryzyka. Obejmują one zabezpieczenia zarówno dla technologii informacyjnej, jak i technologii operacyjnej.
Operatorzy powinni ustanowić te podstawy, zanim przyznają AI szersze uprawnienia. Silne uwierzytelnianie, bezpieczny zdalny dostęp, segmentacja, kopie zapasowe, logowanie i plany reagowania chronią systemy niezależnie od tego, czy incydent dotyczy AI.
Polityka powinna także rozróżniać kategorie ryzyka AI. Atakujący mogą wykorzystywać AI przeciwko infrastrukturze. Przeciwnicy mogą atakować system AI lub jego dane. Wdrożenie AI może również zawieść bez udziału atakującego.
Kategorie te wymagają różnych zabezpieczeń. Dane o zagrożeniach pomagają w przypadku złośliwej aktywności. Ocena modelu dotyczy wydajności i trybów awarii. Zarządzanie określa, kto może zatwierdzać, monitorować, modyfikować lub wyłączać system.
Traktowanie każdego problemu jako „cyberataku AI” ukrywa te różnice. Może też zachęcać do kosztownych zakupów, które nie rozwiązują rzeczywistej słabości. Jasna klasyfikacja incydentów będzie stawać się coraz ważniejsza wraz ze wzrostem liczby wdrożeń.
Test regulacyjny polega na tym, czy wytyczne zmienią zachowanie operacyjne, zanim poważna awaria wymusi działanie. Opublikowanie kolejnego frameworku nie wystarczy. Przeglądy wdrożeń, wymagania zakupowe, ćwiczenia i ujawnienia incydentów pokażą, czy zarządzanie staje się realne.
Trzy sygnały pokażą, czy widoczność nadąża
Kolejnym testem będzie to, czy właściciele infrastruktury zbudują mierzalne zabezpieczenia, zanim AI otrzyma szerszą kontrolę nad systemami fizycznymi.
Pierwszym sygnałem będzie profil infrastruktury krytycznej dla AI Risk Management Framework NIST. Jego zalecenia powinny przełożyć ogólne zasady na działania, które operatorzy mogą testować. Konkretne wytyczne dotyczące zmian modeli, logowania OT, operacji awaryjnych i zależności od dostawców wzmocniłyby argumentację Lee.
Nieprecyzyjny profil pozostawiłby organizacjom różne interpretacje ryzyka. Szczegółowy profil, zwłaszcza przyjęty przez regulatorów sektorowych i nabywców, stworzyłby wspólną podstawę. Ograniczyłoby to przestrzeń dla pospiesznych wdrożeń opartych wyłącznie na deklaracjach dostawców.
Drugim sygnałem będą zmiany w metrykach widoczności OT. Dragos obecnie informuje, że widoczność ma jedynie 30% sieci OT, podczas gdy 56% nie widzi nic poniżej granicy IT i OT. Przyszłe raporty powinny pokazać, czy wskaźniki te poprawiają się wraz z rozwojem wdrożeń AI.
Poprawa sugerowałaby, że organizacje budują monitoring przed przyznaniem większej autonomii. Utrzymująca się słaba widoczność przy szybkim wdrażaniu wzmocniłaby ryzyko AI dla infrastruktury wskazywane przez Dragos. Oznaczałoby to, że złożoność rośnie szybciej niż zdolność obrońców do jej obserwowania.
Trzecim sygnałem jest pierwsza fala ujawnionych incydentów OT związanych z AI. Raporty muszą rozróżniać złośliwe wykorzystanie, ataki na modele, niebezpieczne integracje oraz zwykłe awarie oprogramowania. Bez tych szczegółów organizacje nie są w stanie ustalić, które mechanizmy kontroli zawiodły.
Przejrzysty rejestr incydentów pomógłby operatorom wyciągać wnioski, zanim doświadczą tego samego problemu. Pozwoliłby także sprawdzić, czy obecne logowanie wspiera rzetelną analizę przyczyn źródłowych. Powtarzające się, niewyjaśnione incydenty potwierdziłyby obawy Lee dotyczące rosnących martwych punktów.
Liderzy odpowiedzialni za infrastrukturę nie powinni czekać na wszystkie trzy sygnały. Już teraz mogą sporządzić inwentaryzację wdrożeń AI, wskazać procesy fizyczne, których dotyczą, oraz zweryfikować, kto ma uprawnienia do ich wyłączenia. Mogą również testować operacje bez modelu lub jego usług zewnętrznych.
Deweloperzy powinni wymagać jasnych interfejsów, ograniczonych uprawnień, wersjonowanego zachowania i pełnych ścieżek audytu. Nabywcy korporacyjni powinni żądać od dostawców dowodów, a nie ogólnych deklaracji bezpieczeństwa. Pracownicy umysłowi powinni unikać przekazywania wrażliwych informacji o infrastrukturze do niezatwierdzonych narzędzi.
Ostrzeżenie Roberta M. Lee dotyczące AI prowadzi ostatecznie do praktycznej zasady decyzyjnej. Automatyzacja nie powinna zyskiwać uprawnień operacyjnych szybciej, niż organizacja zdobywa widoczność, kontrolę i zdolność do odzyskiwania sprawności.
AI nadal może usprawniać usługi krytyczne. Wdrożenie musi jednak pozostać na tyle zrozumiałe, by można było je zbadać, i na tyle ograniczone, by można było je zatrzymać. Przed zatwierdzeniem kolejnej integracji zadaj jedno pytanie: jeśli jutro zadziała nieprawidłowo, czy Twój zespół będzie w stanie zobaczyć dlaczego i bezpiecznie przywrócić działanie?
