Raport IBM o naruszeniach z 2026 roku wskazuje na 92-procentową lukę w kontroli dostępu do AI

Raport IBM o naruszeniach z 2026 roku trafił do Google News z alarmującą informacją: 92% organizacji zaatakowanych za pośrednictwem systemów AI miało rzekomo niewłaściwe mechanizmy kontroli dostępu.

Ta liczba ma znaczenie, ponieważ przedsiębiorstwa nie wykorzystują już AI wyłącznie do tworzenia tekstów czy podsumowywania dokumentów. Modele i agenci coraz częściej łączą się z danymi firmowymi, usługami chmurowymi, narzędziami programistycznymi i procesami produkcyjnymi. Błędy w dostępie mogą więc ujawnić informacje lub autoryzować działania w kilku systemach.

Nagłówek pokazuje również szersze odwrócenie tendencji w korporacyjnym wykorzystaniu AI. Firmy wdrażały AI, by zwiększyć produktywność i wzmocnić bezpieczeństwo, jednak wiele z nich zrobiło to bez zabezpieczeń tożsamości rutynowo wymaganych od pracowników i tradycyjnych aplikacji. Ustalenia IBM sugerują, że atakujący zauważyli tę lukę.

Nagłówek IBM w Google News wskazuje na szerszą zmianę w bezpieczeństwie AI

Statystyka dotycząca kontroli dostępu jest alarmująca, lecz szersze ustalenia IBM pokazują, że AI wpływa obecnie na obie strony naruszenia danych.

IBM opublikował raport 2026 Cost of a Data Breach Report 29 lipca. Badanie przeprowadził Ponemon Institute, a następnie zostało ono sfinansowane i przeanalizowane przez IBM. Objęło naruszenia, których doświadczyły 602 organizacje z 17 branż między marcem 2025 a lutym 2026 roku.

Podawana wartość 92% dotyczy organizacji, które doświadczyły ataków związanych z ich modelami lub aplikacjami AI. W praktyce organizacje te nie miały mechanizmów pozwalających wiarygodnie ograniczać dostęp do dotkniętych incydentami systemów AI — zarówno osobom, jak i innym podmiotom.

Kontrola dostępu określa, czy osoba, aplikacja lub tożsamość maszyny może uzyskać dostęp do zasobu. Definiuje też działania, które taka tożsamość może wykonywać. W przypadku agenta AI uprawnienia te mogą obejmować odczytywanie danych klientów, wywoływanie interfejsu programowania aplikacji, modyfikowanie zgłoszenia lub uruchamianie zautomatyzowanego przepływu pracy.

Statystyki tej nie należy interpretować jako dowodu, że 92% wszystkich przedsiębiorstw nie ma mechanizmów kontroli dostępu do AI. IBM badał organizacje, które doświadczyły naruszeń, a wskaźnik dotyczy węższej grupy z incydentami związanymi z AI. To istotne rozróżnienie przy ocenie skali problemu.

Nawet w tej węższej grupie ustalenie to opisuje poważną porażkę w zakresie zabezpieczeń. Ponad 20% organizacji z próby IBM zgłosiło naruszenie wymierzone w modele lub aplikacje AI. Naruszone API, aplikacje lub wtyczki stanowiły 27% wskazywanych przyczyn. Kolejne 27% przypisano błędnym konfiguracjom chmury wpływającym na obciążenia AI.

Ustalenia te odwracają uwagę od dramatycznych scenariuszy, w których model samodzielnie pokonuje zabezpieczenia. Bardziej bezpośrednie słabości często znajdują się wokół modelu. Atakujący mogą wykorzystywać wystawione interfejsy, konta usługowe z nadmiernymi uprawnieniami, podatne wtyczki i nieprawidłowo skonfigurowane zasoby chmurowe.

Raport IBM o naruszeniach z 2026 roku przedstawia także finansową stawkę w odpowiednim kontekście. Średni globalny koszt naruszenia osiągnął 4,99 mln dolarów, co oznacza wzrost o 12% rok do roku. IBM określił tę wartość jako rekordowo wysoką.

Incydenty związane z AI dodatkowo zmieniły tę ekonomikę. IBM podał, że jedno na cztery złośliwe naruszenia było wspierane przez AI, co oznacza wzrost o 56% względem poprzedniego roku. Incydenty te kosztowały organizacje średnio 6 mln dolarów, czyli około 1 mln dolarów więcej niż średnia globalna.

Nie oznacza to, że każdy atak wspierany przez AI był bezpośrednio wymierzony w model AI. IBM używa tej kategorii także w odniesieniu do ataków, w których sprawcy wykorzystywali AI, w tym podszywanie się z użyciem deepfake’ów oraz złośliwe oprogramowanie wspomagane przez AI. To rozróżnienie oddziela ataki wykorzystujące AI od ataków na systemy AI.

Łącznie kategorie te opisują ryzyko o dwóch stronach. Atakujący mogą używać AI, aby zwiększać szybkość lub skalę sprawdzonych taktyk. Mogą również atakować modele, agentów, magazyny danych i interfejsy, które firmy szybko dodają do swojej infrastruktury.

Dlatego ujęcie tematu przez Google News nie powinno zostać sprowadzone do jednego sensacyjnego odsetka. Wydarzeniem leżącym u podstaw jest zmiana powierzchni ataku w przedsiębiorstwach: AI staje się zarówno narzędziem atakującego, jak i celem.

Rzeczywisty słaby punkt znajduje się wokół modelu

Dane IBM wskazują, że zwykłe problemy z tożsamością, API i chmurą pozostają kluczowe w rzekomo nowych naruszeniach związanych z AI.

Dyskusje o bezpieczeństwie AI często koncentrują się na zachowaniu modelu, takim jak halucynacje, szkodliwe odpowiedzi czy prompt injection. Ryzyka te pozostają istotne, ale dane IBM wskazują na mniej egzotyczny problem. Organizacje łączą AI z cennymi zasobami bez konsekwentnego stosowania sprawdzonych zabezpieczeń.

Sam model zazwyczaj nie może uzyskać dostępu do bazy danych klientów ani wdrożyć oprogramowania. Zyskuje taki zasięg dzięki otaczającym go komponentom. Należą do nich wtyczki, dane uwierzytelniające API, systemy wyszukiwania informacji, role chmurowe, konta usługowe i warstwy orkiestracji agentów.

Każde połączenie zwiększa liczbę decyzji, którymi organizacja musi zarządzać. Które dokumenty system może pobierać? Czy może przeglądać rekordy wszystkich klientów? Czy może wywołać usługę zewnętrzną? Czy może zapisywać dane, czy tylko je odczytywać? Czy jego dostęp wygasa po zakończeniu zadania?

Tożsamość agentowa to tożsamość cyfrowa przypisana agentowi AI, który działa w połączonych systemach. Tradycyjne programy zarządzania tożsamością zwykle koncentrują się na pracownikach, wykonawcach, urządzeniach i obciążeniach programowych. Agenci wprowadzają kolejną kategorię, która może podejmować decyzje i wywoływać narzędzia przy ograniczonym udziale człowieka.

IBM zaleca dla tych agentów dynamiczne mechanizmy kontroli oparte na tożsamości. Wzywa również do ściśle ograniczonych uprawnień, egzekwowania zasad w czasie działania, przypisania działań do ludzi oraz audytowalnej aktywności. Egzekwowanie zasad w czasie działania oznacza sprawdzanie uprawnień podczas pracy agenta, a nie jednorazowe zatwierdzanie szerokiego dostępu przy wdrożeniu.

Podejście to rozwiązuje kluczową niezgodność. Pracownik zazwyczaj uwierzytelnia się za pomocą znanego konta, podczas gdy agent może działać przez kilka współdzielonych poświadczeń. Jeżeli logi rejestrują tylko współdzielone konto usługowe, osoby prowadzące dochodzenie mogą mieć trudności z ustaleniem, który agent zainicjował działanie lub który pracownik o nie poprosił.

Skutkiem jest luka w rozliczalności. Firma może wiedzieć, że token API uzyskał dostęp do wrażliwych danych, nie wiedząc, który model, przepływ pracy lub użytkownik spowodował żądanie. Utrudnia to zatrzymanie niewłaściwej aktywności i późniejsze odtworzenie przebiegu naruszenia.

Dobrze znaną odpowiedzią jest zasada najmniejszych uprawnień. Przyznaje ona każdej tożsamości tylko dostęp niezbędny do wykonania zdefiniowanego zadania. Jej zastosowanie wobec AI może jednak być trudne, ponieważ agenci często wykonują zmienną, wieloetapową pracę.

Szerokie uprawnienia czynią agenta bardziej użytecznym w większej liczbie sytuacji. Zwiększają też potencjalne szkody wynikające z zmanipulowanego promptu, skradzionych poświadczeń, błędnej decyzji lub przejętej integracji. Ten sam dostęp, który umożliwia automatyzację, może zwiększać zasięg szkód po naruszeniu.

Weźmy pod uwagę wewnętrznego asystenta badawczego połączonego z dokumentami, pocztą e-mail, danymi klientów i systemami projektowymi. Wąska konfiguracja może pozwalać mu pobierać zatwierdzone pliki dla jednego zespołu. Szeroka konfiguracja mogłaby ujawnić informacje z repozytoriów działów prawnego, finansowego, inżynieryjnego i sprzedaży.

Różnica w bezpieczeństwie nie polega na zdolności modelu do pisania. Polega na jakości granicy tożsamości otaczającej jego dane i narzędzia.

Dostęp do wiedzy również zasługuje na szczególną uwagę. Organizacje chcą, aby asystenci znajdowali właściwy kontekst bez ujawniania każdemu użytkownikowi każdego źródła. Starannie zaprojektowana baza wiedzy AI powinna zachowywać uprawnienia źródłowe, zamiast tworzyć nową ścieżkę ich obejścia.

Ten sam problem pojawia się w autonomicznych przepływach pracy. Agent obsługujący zgłoszenia wsparcia może potrzebować odczytać profil klienta i zaproponować odpowiedź. Nie potrzebuje automatycznie uprawnień do eksportowania bazy danych klientów, zmieniania danych rozliczeniowych ani wyłączania ustawień bezpieczeństwa.

AI może zacierać te granice, ponieważ użyteczny kontekst jest często traktowany jako jedna wspólna pula. Gdy uprawnienia znikają podczas indeksowania, wyszukiwania lub wykonywania zadań przez agenta, system może ujawnić informacje, do których użytkownik składający żądanie nie miałby bezpośredniego dostępu.

Zatruwanie kontekstu stwarza kolejne ryzyko. Dzieje się tak, gdy mylące lub złośliwe informacje trafiają do materiałów, których AI używa do podejmowania decyzji. Atakujący może umieścić instrukcje w dokumencie, który agent później pobierze.

Tradycyjne filtrowanie wyników nie rozwiązuje w pełni tego scenariusza. Organizacja musi kontrolować, którym źródłom agent ufa, jakie narzędzia może wywoływać oraz czy wrażliwe działania wymagają zatwierdzenia. Logi muszą również zachowywać wystarczający kontekst, by wyjaśnić podjętą decyzję.

Zabezpieczenia modelu i mechanizmy kontroli dostępu w przedsiębiorstwie służą różnym celom. Zabezpieczenia mogą wpływać na treść tworzoną przez model. Kontrola dostępu określa, czy może on uzyskać dostęp do systemu płacowego, repozytorium kodu źródłowego lub konsoli produkcyjnej.

Mylenie tych dwóch kwestii może tworzyć fałszywe poczucie bezpieczeństwa. Dobrze zachowujący się model z nadmiernymi uprawnieniami nadal jest niebezpieczny, jeśli jego poświadczenia zostaną skradzione lub dane wejściowe zmanipulowane. Z kolei ściśle ograniczony dostęp może ograniczyć szkody nawet wtedy, gdy model zachowuje się nieprzewidywalnie.

Raport IBM podważa zatem pogląd, że bezpieczeństwo AI wymaga całkowicie odrębnego świata zabezpieczeń. Wiele awarii nadal dotyczy wykrywania zasobów, zarządzania poświadczeniami, konfiguracji chmury, monitorowania i reagowania na incydenty. Nowa trudność polega na stosowaniu tych mechanizmów do systemów działających z większą autonomią.

Wdrożenie AI obiecywało szybkość, lecz zespoły bezpieczeństwa odziedziczyły ryzyko

Główny konflikt zachodzi między szybkim wdrażaniem AI a wolniejszą pracą nad definiowaniem tożsamości, uprawnień, odpowiedzialności i dowodów.

Zespoły przedsiębiorstw mają silne bodźce, by szybko wdrażać AI. Pracownicy już korzystają z konsumenckich asystentów, rozszerzeń przeglądarek, usług transkrypcji i funkcji AI wbudowanych w oprogramowanie biznesowe. Jednostki biznesowe często mogą aktywować te usługi, zanim zespoły bezpieczeństwa zdążą je zinwentaryzować.

Takie zachowanie prowadzi do shadow AI, czyli narzędzi lub modeli AI używanych bez formalnej akceptacji lub nadzoru. Przypomina to shadow IT, lecz ekspozycja może wykraczać poza przechowywanie danych lub zakup oprogramowania. Nieautoryzowany model może przetwarzać wrażliwe dane, zachowywać prompty, wywoływać narzędzia lub wpływać na decyzje biznesowe.

Badania IBM z 2025 roku ustanowiły ważny punkt odniesienia. Wówczas 13% badanych organizacji zgłosiło naruszenia związane z modelami lub aplikacjami AI. Wśród tych organizacji 97% stwierdziło, że nie dysponowało właściwymi mechanizmami kontroli dostępu do AI.

Ustalenia z 2025 roku wykazały również, że 63% organizacji dotkniętych naruszeniami nie miało polityki zarządzania AI lub nadal ją opracowywało. Tylko 34% organizacji posiadających taką politykę regularnie przeprowadzało audyty pod kątem nieautoryzowanego AI.

Jedna na pięć organizacji w tym badaniu zgłosiła naruszenie związane z shadow AI. Organizacje o wysokim wykorzystaniu shadow AI ponosiły średnio koszty naruszeń o 670 000 dolarów wyższe niż podmioty o niskim wykorzystaniu shadow AI lub niekorzystające z niego wcale.

Przejście z 97% w podgrupie organizacji dotkniętych naruszeniami w 2025 roku do zgłaszanego poziomu 92% w 2026 roku sugeruje ograniczoną poprawę, a nie rozwiązany problem. Próby i dokładne definicje incydentów mogą się różnić, dlatego odsetków tych nie należy traktować jako czystego pomiaru rok do roku.

Mimo to obie wartości wskazują ten sam kierunek. Niemal wszystkie dotknięte organizacje w odpowiednich grupach nie miały wystarczających mechanizmów kontroli dostępu do AI. Ta spójność jest bardziej znacząca niż pięciopunktowa różnica.

Zespoły bezpieczeństwa są jednocześnie pod presją z kilku stron. Muszą wykrywać zatwierdzone i niezatwierdzone użycie AI, przypisywać właścicieli, klasyfikować podłączone dane, zarządzać tożsamościami niebędącymi ludźmi, kontrolować wtyczki i monitorować działania w czasie rzeczywistym.

Jednocześnie zespoły produktowe rozszerzają możliwości agentów. Asystent, który jedynie przygotowuje teksty, ma ograniczone uprawnienia operacyjne. Agent, który aktualizuje dane klientów, scala kod, planuje płatności lub zmienia zasoby chmurowe, przechodzi do innej kategorii ryzyka.

Tworzy to opóźnienie w obszarze zarządzania. Dział zakupów może zatwierdzić oprogramowanie, podczas gdy zespoły ds. tożsamości nadal nie wiedzą o jego kontach usługowych. Deweloper może podłączyć agenta do danych produkcyjnych, zanim zespół ds. prywatności oceni przepływ danych.

Organizacja może ostatecznie dysponować kilkoma niepełnymi obrazami sytuacji. Bezpieczeństwo widzi ruch API, IT widzi licencje, dział prawny widzi umowy z dostawcami, a zespoły biznesowe widzą produktywność. Nikt nie posiada pełnego wykazu agenta, jego danych, poświadczeń i dozwolonych działań.

Same polityki nie są w stanie zamknąć tej luki. Dokument może zakazywać pracownikom przesyłania poufnych informacji do publicznych modeli. Nie zatrzyma jednak tego działania, jeśli firma nie potrafi wykryć narzędzia, sklasyfikować danych i egzekwować ograniczenia.

Same kontrole techniczne również nie wystarczą bez przypisanej odpowiedzialności. Platforma bezpieczeństwa może oznaczyć nietypowy dostęp, ale ktoś musi zdecydować, jak wygląda normalna aktywność dla każdego agenta. Właściciel musi wiedzieć, jakich narzędzi potrzebuje agent i które działania powinny wymagać zatwierdzenia przez człowieka.

Napięcie rośnie, gdy kadra zarządzająca oczekuje mierzalnego wdrażania AI. Zespoły mogą traktować liczbę aktywowanych licencji, zautomatyzowanych zadań lub użycie przez pracowników jako oznakę postępu. Takie wskaźniki nagradzają zasięg i szybkość, podczas gdy przeglądy uprawnień oraz przygotowanie do audytu wydają się spowalniać wdrożenie.

Badania IBM sugerują, że ukryty koszt pojawia się po wdrożeniu. Brak właściciela utrudnia powstrzymywanie incydentów. Współdzielone poświadczenia utrudniają przypisanie działań do konkretnych osób lub systemów. Nadmierny dostęp umożliwia jednemu przejętemu komponentowi dotarcie do większej ilości danych.

Do organizacji znajdujących się pod największą presją należą firmy z sektora usług finansowych i energetyki. IBM ustalił, że sektory infrastruktury krytycznej odpowiadały za 62% zgłoszonych ataków wykorzystujących AI. Średni koszt naruszeń w usługach finansowych wyniósł 6,3 mln USD, a w energetyce — 5,2 mln USD.

Sektory te obsługują połączone systemy, w których zakłócenia mogą wpływać na klientów, łańcuchy dostaw lub podstawowe usługi. Przechowują też cenne dane finansowe, dotyczące tożsamości, działalności operacyjnej i własności intelektualnej. Integracje AI mogą tworzyć nowe drogi dostępu do tych środowisk.

Deweloperzy również ponoszą praktyczne konsekwencje. Przeglądy bezpieczeństwa coraz częściej wymagają diagramów architektury, inwentaryzacji przepływów danych, dokumentacji modeli, informacji o własności poświadczeń i dowodów testowych. Zespół, który nie potrafi wyjaśnić dostępu agenta, będzie miał trudności z udowodnieniem, że wdrożenie jest ograniczone.

Kupujący korporacyjni powinni zatem patrzeć dalej niż na to, czy produkt oferuje pojedyncze logowanie. Muszą wiedzieć, czy zachowuje uprawnienia na poziomie źródła, obsługuje szczegółowe role, oddziela tenantów, rejestruje wywołania narzędzi i umożliwia szybkie unieważnianie poświadczeń.

Pole wyboru w procesie zakupowym może potwierdzić, że kontrola istnieje. Nie może jednak wykazać, że każdy agent korzysta z niej prawidłowo. Prawdziwym sprawdzianem jest to, czy organizacja może prześledzić jedno wrażliwe działanie od osoby zgłaszającej żądanie, przez model, aż do systemu docelowego.

AI Podnosi Koszty Naruszeń i Je Obniża

Kluczowy paradoks IBM polega na tym, że AI wzmacnia ataki, podczas gdy automatyzacja bezpieczeństwa może znacząco obniżyć wynikające z nich koszty.

Raport z 2026 roku nie przedstawia AI jako zjawiska wyłącznie szkodliwego. Organizacje, które szeroko wykorzystywały AI i automatyzację w operacjach bezpieczeństwa, zaoszczędziły średnio 1,93 mln USD w porównaniu z organizacjami, które nie używały żadnego z tych rozwiązań.

To ustalenie tworzy najważniejszy kompromis opisany w raporcie. Rezygnacja z AI nie eliminuje napastników wspieranych przez AI ani podatnych usług zewnętrznych. Jej nieostrożne wdrożenie może jednak dodać niezarządzane tożsamości i ścieżki danych.

IBM podaje, że ataki wykorzystujące AI wzrosły rok do roku o 56%. Podszywanie się przy użyciu deepfake’ów było najczęstszą kategorią w dodatkowych raportach, wskazywaną przez 45% respondentów. Malware i phishing wspierane przez AI również przyczyniły się do wzrostu.

Narzędzia te obniżają koszt tworzenia dopasowanych wiadomości, podszywania się pod zaufane osoby i modyfikowania złośliwego kodu. Nie eliminują potrzeby uzyskania punktu wejścia. Skradzione poświadczenia, wystawione usługi, podatne oprogramowanie i oszustwa wymierzone w ludzi nadal pozostają istotnymi elementami wielu ataków.

AI może również pomagać obrońcom sortować alerty, wykrywać nietypowe zachowania, korelować zdarzenia i powstrzymywać incydenty. Automatyzacja ma znaczenie, ponieważ koszty naruszeń rosną, gdy organizacjom zajmuje więcej czasu wykrycie i naprawienie przejętych systemów.

Dyrektorka IBM ds. bezpieczeństwa Suja Viswesan opisała problem jako nierównowagę ekonomiczną. Atakujący mogą uruchamiać działania szybciej i taniej, podczas gdy ofiary wydają miliony na wykrycie, powstrzymanie i usunięcie skutków naruszenia.

Jej rekomendacja koncentruje się na skróceniu opóźnienia między wykryciem a naprawą. Obejmuje to integrowanie poprawek z procesami tworzenia oprogramowania, zabezpieczanie tożsamości podczas działania oraz usuwanie słabości w tempie, w jakim wykorzystują je napastnicy.

Wdrożenie pozostaje nierównomierne. Jedna na cztery organizacje objęte badaniem IBM nie wprowadziła AI i automatyzacji do operacji bezpieczeństwa. Ponad połowa korzystała z agentów do wykrywania zagrożeń i powstrzymywania incydentów, ale tylko 18% stosowało ich w zarządzaniu podatnościami.

Ta luka ma znaczenie, ponieważ wykrywanie następuje po pojawieniu się podejrzanej aktywności. Zarządzanie podatnościami zajmuje się znanymi słabościami, zanim wykorzysta je atakujący. Szybkie wykrycie nie zrekompensuje wystawionych systemów, które pozostają niezałatane lub błędnie skonfigurowane.

Badanie IBM wykazało również, że 85% respondentów w dalszych badaniach planowało zwiększyć wydatki na bezpieczeństwo po zapoznaniu się z możliwościami zaawansowanych modeli granicznych. Tylko 64% planowało zwiększenie wydatków po doświadczeniu naruszenia w badaniu początkowym.

Wynik ten sugeruje, że organizacje zaczynają reagować na przewidywane możliwości, a nie wyłącznie na zakończone incydenty. Jednak zamiar wydawania pieniędzy nie przesądza, czy inwestycje poprawią kontrolę tożsamości, czy jedynie dodadzą więcej produktów do wykrywania zagrożeń.

Metodologia raportu również zasługuje na analizę. IBM i Ponemon badali organizacje, które doświadczyły naruszeń, a nie reprezentatywną próbę wszystkich firm. Szacunki kosztów łączą kilka kategorii, w tym wykrywanie, eskalację, utracony biznes, powiadomienia i działania po naruszeniu.

Raport może wskazywać wzorce w swojej próbie. Nie może dowieść, że dodanie jednego produktu bezpieczeństwa przyniesie średnie oszczędności przytaczane dla każdej organizacji. Duże przedsiębiorstwa, sektory regulowane i złożone incydenty mogą mieć bardzo odmienne struktury kosztów.

Należy też uwzględniać motywacje dostawcy. IBM sprzedaje oprogramowanie i usługi bezpieczeństwa związane z tożsamością, ochroną danych, zarządzaniem chmurą i reagowaniem na incydenty. Jego raport może zawierać wartościowe badania, jednocześnie wspierając narrację komercyjną.

Nie unieważnia to danych. Oznacza to, że czytelnicy powinni oddzielać zmierzone ustalenia od twierdzeń o charakterze zalecającym. Próba wskazuje na związki między szeroką automatyzacją bezpieczeństwa a niższymi średnimi kosztami, ale do obu może przyczyniać się dojrzałość organizacyjna.

Dojrzały program bezpieczeństwa ma większe szanse skutecznie wdrożyć automatyzację. Może też dysponować lepszą inwentaryzacją, przeszkolonym personelem, przetestowanymi planami reagowania i wsparciem kadry zarządzającej. Czynniki te mogą obniżać koszty naruszeń niezależnie od używanych narzędzi.

Wskaźnik 92% dotyczący kontroli dostępu wymaga podobnej ostrożności. Ten odsetek nie dowodzi, że brak kontroli spowodował każdy incydent. Pokazuje silne nakładanie się naruszeń związanych z AI i niewystarczających kontroli w dotkniętej grupie.

Przejęte API i błędne konfiguracje chmury zapewniają wiarygodny mechanizm łączący słabe kontrole z incydentami. Jednak związek przyczynowy może się różnić. Atakujący może wykorzystać podatność oprogramowania nawet wtedy, gdy istnieją polityki tożsamości, lub ukraść poświadczenie z legalnie przyznanymi wysokimi uprawnieniami.

Niezależne omówienia podkreślają to samo podwójne zagrożenie. Analiza branżowa zauważyła, że przestępcy zarówno atakują systemy AI, jak i używają AI do przyspieszania utrwalonych metod ataku. Takie ujęcie lepiej oddaje raport niż proste twierdzenie, że modele powodują naruszenia.

Praktyczny wniosek nie polega na wyborze między AI a bezpieczeństwem. Przedsiębiorstwa muszą zarządzać wdrożeniami AI, jednocześnie korzystając z automatyzacji tam, gdzie poprawia ona obronę. Wynik zależy od tego, czy organizacje połączą możliwości z wąsko zdefiniowanymi uprawnieniami.

Czego Nie Dowodzi Wskaźnik 92%

Nagłówek wskazuje na kryzys kontroli, ale nie ujawnia jakości kontroli w każdej organizacji ani nie ustanawia uniwersalnego wskaźnika incydentów.

Procenty mogą rozchodzić się w Google News szybciej niż ich definicje. Czytelnicy mogą zetknąć się z liczbą 92%, nie widząc granic próby, okresu badawczego ani rozróżnienia między atakami wykorzystującymi AI a atakami wymierzonymi w AI.

Pierwsza niepewność dotyczy terminologii. „Odpowiednie kontrole dostępu do AI” mogą obejmować kilka praktyk, w tym uwierzytelnianie, projektowanie ról, rotację poświadczeń, uprawnienia źródłowe, polityki czasu działania i rejestrowanie audytowe. Miara binarna może ukrywać duże różnice w dojrzałości.

Jedna organizacja może nie mieć żadnych dedykowanych kontroli. Inna może korzystać z ugruntowanych systemów tożsamości, lecz nie stosować ich do jednej wtyczki. Obie mogą znaleźć się w tej samej kategorii niewystarczających kontroli, mimo że ich poziom bezpieczeństwa się różni.

Druga niepewność dotyczy wykrywania. Organizacje nie mogą zgłaszać incydentów, których nigdy nie wykryją. Firmy z silniejszym monitoringiem mogą identyfikować więcej aktywności związanej z AI niż organizacje o ograniczonej widoczności, tworząc pozorny wzrost, który częściowo odzwierciedla lepszą obserwację.

Osiem procent organizacji w badaniu IBM z 2025 roku stwierdziło, że nie wie, czy modele lub aplikacje AI zostały naruszone. Ta niepewność ilustruje problem inwentaryzacji. Firma nie może ocenić modelu, o którego istnieniu nie wie.

Trzecia niepewność dotyczy znaczenia naruszenia związanego z AI. Atakujący może zaatakować punkt końcowy modelu, ukraść dane treningowe, wykorzystać powiązane API lub użyć phishingu wygenerowanego przez AI przeciwko pracownikowi. Zdarzenia te mają różne mechanizmy i wymagają różnych zabezpieczeń.

Inwersja modelu, na przykład, polega na próbie wywnioskowania wrażliwych informacji z wyników modelu. IBM podał średni globalny koszt 6 mln USD dla naruszeń obejmujących ten typ ataku. Scenariusz ten różni się od zasobnika pamięci masowej w chmurze wystawionego przez błędnie skonfigurowaną aplikację AI.

Podszywanie się za pomocą deepfake’ów różni się jeszcze bardziej. Wykorzystuje syntetyczne media do imitowania zaufanej osoby, często w celu zmanipulowania pracownika lub procesu biznesowego. Kontrole dostępu mogą ograniczyć wynikające z tego szkody, ale ważne są także weryfikacja tożsamości i kontrole procesowe.

Czwarta niepewność dotyczy porównań trendów. Raport IBM z 2025 roku objął 600 organizacji z naruszeniami z okresu od marca 2024 roku do lutego 2025 roku. Raport z 2026 roku objął 602 organizacje w kolejnych 12 miesiącach.

Próby o podobnej wielkości pozwalają na szerokie porównanie, ale uczestniczące organizacje i zestaw incydentów mogą się zmieniać. Czytelnicy nie powinni traktować każdej zmiany jako precyzyjnego pomiaru globalnego wskaźnika naruszeń.

Piąta niepewność dotyczy średnich kosztów. Niewielka liczba kosztownych incydentów może podnieść średnią. Branża, wielkość firmy, regulacje, zakłócenia operacyjne i czas odzyskiwania sprawności wpływają na końcową kwotę.

Globalna średnia IBM wzrosła z 4,44 mln USD w 2025 roku do 4,99 mln USD w 2026 roku. Wzrost jest znaczący, ale nie oznacza, że każda firma powinna oczekiwać, iż incydent będzie kosztował dokładnie tyle.

Bardziej użyteczne jest traktowanie tych ustaleń jako wskazówki co do kierunku. Systemy AI stają się istotnymi elementami infrastruktury przedsiębiorstw. Atakujący wchodzą w interakcje z tymi systemami, a wiele dotkniętych organizacji nie rozszerzyło na nie podstawowych mechanizmów kontroli.

Liderzy ds. bezpieczeństwa powinni sprawdzić, czy nagłówek przekłada się na ich własne środowisko. Czy potrafią wskazać każdy model i agenta? Czy mogą zidentyfikować właściciela? Czy widzą, do których źródeł danych dociera każdy system? Czy mogą cofnąć jego poświadczenia bez wyłączania całej platformy?

Powinni również zapytać, czy logi zachowują możliwość przypisania działań konkretnym osobom. Jeśli pracownik zleca agentowi aktualizację rekordu klienta, ślad audytowy powinien łączyć pracownika, agenta, poświadczenie, wywołanie narzędzia i końcową zmianę.

Ciągłe monitorowanie ma znaczenie, ponieważ zachowanie agenta może zmieniać się wraz z jego kontekstem. Nowe narzędzia, prompty, źródła danych i wersje modeli mogą zmienić jego działanie, nawet gdy jego formalne uprawnienia pozostają bez zmian.

Zewnętrzne analizy dotyczące bezpieczeństwa agentów podkreślają znaczenie tożsamości, ściśle kontrolowanego dostępu, audytowalnych działań, ścieżek eskalacji i wyłączników awaryjnych. Środki te traktują autonomię jako ryzyko operacyjne, a nie wyłącznie problem jakości modelu.

Wyłącznik awaryjny to mechanizm zatrzymujący agenta lub odbierający mu zdolność do działania. Powinien działać szybko i przewidywalnie, zwłaszcza gdy agent może uzyskać dostęp do systemów finansowych, produkcyjnych lub obsługi klienta.

Ludzka akceptacja pozostaje również przydatna przy działaniach o dużym wpływie. Agent może przygotować płatność, zmianę w kodzie lub modyfikację konta, nie otrzymując uprawnień do jej sfinalizowania. Taki podział zachowuje automatyzację, jednocześnie ograniczając nieodwracalne skutki.

Mechanizmy kontroli powinny odpowiadać poziomowi ryzyka. Asystent streszczający publiczne dokumenty potrzebuje mniej ograniczeń niż agent uzyskujący dostęp do informacji o pacjentach lub infrastruktury produkcyjnej. Stosowanie tej samej polityki wobec obu może powodować nadmierne utrudnienia albo niewystarczającą ochronę.

Wartość nagłówka polega więc na skłanianiu do zadawania konkretnych pytań. Jego ograniczeniem jest to, że nie może odpowiedzieć na te pytania za każdą organizację.

Trzy sygnały, które warto obserwować po raporcie IBM z 2026 roku

Kolejnym sprawdzianem będzie to, czy przedsiębiorstwa przełożą obawy na mierzalne mechanizmy kontroli tożsamości, usuwanie podatności i wyniki, które można niezależnie zweryfikować.

Pierwszym sygnałem jest wdrażanie mechanizmów kontroli tożsamości przeznaczonych dla agentów. Organizacje powinny wyjść poza współdzielone klucze API i przypisywać odrębne tożsamości agentom, obciążeniom roboczym i przepływom pracy.

Dowodem postępu byłyby krótkotrwałe poświadczenia, uprawnienia na poziomie zadań, możliwość przypisania działań ludziom oraz logi obejmujące każde wywołanie narzędzia. Dostawcy rozwiązań bezpieczeństwa prawdopodobnie rozwiną produkty w tym obszarze, lecz wskaźniki wdrożeń są ważniejsze niż zapowiedzi funkcji.

Jeśli organizacje będą w stanie zinwentaryzować tożsamości agentowe i cofać je indywidualnie, centralne ostrzeżenie IBM zacznie tracić na znaczeniu. Jeśli agenci nadal będą dziedziczyć szerokie konta usługowe, nagłówek o 92% pozostanie aktualny.

Drugim sygnałem jest to, czy zespoły bezpieczeństwa zastosują automatyzację w zarządzaniu podatnościami. IBM stwierdził, że ponad połowa organizacji korzystała z agentów do wykrywania i ograniczania zagrożeń, podczas gdy tylko 18% wykorzystywało ich do zarządzania podatnościami.

Ta nierównowaga faworyzuje reakcję zamiast zapobiegania. Postęp oznaczałby połączenie inwentaryzacji zasobów, danych o ekspozycji, odpowiedzialności za kod i przepływów pracy związanych z usuwaniem problemów, aby znane słabości szybko trafiały do odpowiedzialnego zespołu.

Wskaźnikiem wartym obserwowania nie jest liczba alertów AI. Jest nim czas między wykryciem podatności możliwej do wykorzystania a wdrożeniem zweryfikowanej poprawki. Krótszy czas usuwania problemów wspierałby argument IBM, że obrońcy mogą przeciwdziałać szybszym atakom dzięki automatyzacji.

Trzecim sygnałem są niezależne dane dotyczące częstotliwości naruszeń i ich kosztów. Coroczny raport IBM stanowi szeroko cytowany punkt odniesienia, ale nabywcy powinni porównywać go z ujawnieniami regulacyjnymi, danymi ubezpieczeniowymi, ustaleniami zespołów reagowania na incydenty oraz recenzowanymi badaniami naukowymi.

Spójne wyniki z tych źródeł wzmocniłyby wniosek, że słabe mechanizmy kontroli dostępu AI prowadzą do istotnych strat. Duże rozbieżności sugerowałyby, że część trendu wyjaśniają definicje, dobór próby lub praktyki wykrywania.

Firmy powinny również obserwować, jak zgłoszona wartość 92% zmieni się w kolejnym badaniu IBM. Znaczący spadek, połączony z lepszymi wynikami inwentaryzacji i audytów, wskazywałby, że zarządzanie nadąża za rozwojem technologii.

Niższy odsetek sam w sobie nie byłby wystarczający. Organizacje mogłyby po prostu wykrywać mniej incydentów albo redefiniować, co kwalifikuje się jako system AI. Wiarygodna poprawa wymaga dowodów, że mechanizmy kontroli są wdrożone, testowane i egzekwowane podczas działania.

Szersze pytanie brzmi, czy korporacyjna AI może dojrzeć od eksperymentów do rozliczalnej infrastruktury. Modele i agenci mają obecnie kontakt z dokumentami, danymi klientów, kodem, komunikacją i procesami biznesowymi. Bezpieczeństwo musi podążać za tymi połączeniami.

Google News może nagłośnić statystykę, ale zarządy i zespoły techniczne muszą przełożyć ją na pytania na poziomie systemu. Jakie tożsamości istnieją, do czego mają dostęp i kto pozostaje odpowiedzialny, gdy działa agent?

Ustalenia IBM są ostrzeżeniem, a nie ostatecznym werdyktem. Najbliższe trzy miesiące powinny pokazać, czy przedsiębiorstwa potraktują dostęp AI jako kluczowy problem tożsamości, czy jako kolejny dokument polityki oczekujący na wdrożenie.

Przejrzyj każdego agenta AI, który może uzyskać dostęp do wrażliwych danych lub wywołać działanie zewnętrzne. Nadaj mu wskazanego właściciela, odrębną tożsamość, ściśle ograniczone uprawnienia i audytowalną ścieżkę prowadzącą z powrotem do osoby zgłaszającej żądanie. Następnie sprawdź, czy organizacja potrafi szybko go zatrzymać.

Ta praca jest mniej spektakularna niż nagłówek w Google News. To jednak właśnie w tym miejscu najprawdopodobniej uda się zapobiec kolejnemu kosztownemu incydentowi związanemu z AI.