Kiteworks ostrzega: 80% organizacji doświadczyło incydentów bezpieczeństwa lub AI, podczas gdy zarządzanie pozostaje w tyle

Kiteworks trafił do Google News z mocnym twierdzeniem: 80% organizacji doświadczyło incydentu bezpieczeństwa lub AI, podczas gdy gotowość w zakresie zarządzania pozostawała krytycznie niska. Liczba przyciąga uwagę, ale głębszy konflikt dotyczy rozbieżności między zapisanymi politykami a mechanizmami kontroli działającymi podczas rzeczywistego korzystania z AI.

Nagłówek opublikowany przez Cybersecurity Insiders pojawia się w momencie, gdy firmy zapewniają systemom AI dostęp do prywatnych dokumentów, aplikacji biznesowych i wewnętrznych procesów pracy. Takie połączenia zwiększają konsekwencje słabych uprawnień, niekompletnych dzienników i nieznanego przepływu danych.

Kiteworks ma interes komercyjny w tej dyskusji, ponieważ sprzedaje technologie zabezpieczania prywatnych danych i zarządzania nimi. Jego ustalenia zasługują więc na analizę, a nie automatyczną akceptację. Mimo to kilka wspierających danych wskazuje na problem z zarządzaniem, który wykracza poza perspektywę jednego dostawcy.

Co faktycznie zmienia raport Kiteworks

Raport przekształca zarządzanie AI z debaty o politykach w problem reagowania na incydenty.

Informacja w Google News przedstawia wskaźnik 80% jako główne ustalenie. Sam nagłówek nie wyjaśnia jednak, czy odsetek ten łączy potwierdzone naruszenia, podejrzewane zdarzenia, naruszenia polityk czy awarie specyficzne dla AI.

To rozróżnienie ma znaczenie. Tradycyjne naruszenie danych, przesłanie przez pracownika poufnego tekstu do niezatwierdzonego chatbota oraz niezamierzone działanie autonomicznego agenta to różne zdarzenia. Wymagają odmiennych mechanizmów kontroli i powodują różny poziom szkód.

Czytelnicy powinni zatem traktować ten odsetek z nagłówka jako wynik ankiety raportowany przez dostawcę. Nie jest to miara niezależnie zweryfikowanych naruszeń w całej gospodarce. Publicznie dostępne materiały Kiteworks potwierdzają szersze obawy dotyczące zarządzania, ale nie czynią wszystkich kategorii incydentów wzajemnie zamiennymi.

Wcześniejsze globalne badanie Kiteworks objęło 461 organizacji z Ameryki Północnej, Europy, regionu Azji i Pacyfiku oraz Bliskiego Wschodu. Relacje z tego badania wykazały, że zaledwie 17% respondentów w pełni wdrożyło techniczne ramy zarządzania AI.

To bardziej użyteczny punkt odniesienia. Techniczne zarządzanie AI oznacza egzekwowalne mechanizmy kontroli obejmujące dostęp do danych, użycie modeli, monitorowanie, retencję oraz obsługę incydentów. Dokument polityki bez takich mechanizmów nie może powstrzymać pracownika, aplikacji ani agenta przed ujawnieniem chronionych informacji.

To samo badanie powiązało ograniczoną widoczność ze słabszymi wynikami. Według niezależnego raportu, 46% organizacji, które nie znały liczby swoich podmiotów trzecich, nie potrafiło również określić częstotliwości naruszeń.

Wśród organizacji niepewnych co do naruszeń 42% nie miało również pewności co do czasu ich wykrywania. Według relacji kolejne 48% nie potrafiło oszacować kosztów sporów sądowych.

Te zależności nie dowodzą, że słaba widoczność spowodowała każde naruszenie. Pokazują jednak, że organizacje niezdolne do zinwentaryzowania systemów i partnerów mają również trudności z mierzeniem konsekwencji.

Analiza sektora technologicznego Kiteworks z 2026 roku przedstawia kolejną perspektywę. Objęła ona 225 liderów ds. bezpieczeństwa, IT, zgodności i ryzyka z 10 branż oraz ośmiu regionów. Trzydziestu dwóch respondentów reprezentowało organizacje technologiczne, a 97% wszystkich uczestników pracowało w organizacjach zatrudniających co najmniej 1000 osób.

Ta próba jest istotna dla ryzyka dużych przedsiębiorstw, ale nie reprezentuje każdego biznesu. Podzbiór technologiczny jest szczególnie mały. Różnice procentowe w obrębie tych 32 odpowiedzi należy interpretować jako wyniki kierunkowe, a nie precyzyjne szacunki branżowe.

Nawet przy tych ograniczeniach raport wskazuje na spójny problem. Organizacje inwestowały w widoczne praktyki zarządzania, lecz podstawowe mechanizmy kontroli pozostają niekompletne.

To właśnie się zmieniło. Incydenty bezpieczeństwa AI nie są już hipotetycznymi przypadkami brzegowymi związanymi z przyszłymi systemami autonomicznymi. Firmy zgłaszają incydenty, podczas gdy kluczowe możliwości inwentaryzacji, ustalania pochodzenia i egzekwowania zasad wciąż nie są ukończone.

Dlaczego Google News nagłaśnia teraz lukę w zarządzaniu

Wdrażanie AI przeniosło się z odizolowanych sesji czatowych do systemów, które mogą pobierać dane, wywoływać narzędzia i działać w procesach biznesowych.

Chatbot odpowiadający na ogólne pytanie ma ograniczony dostęp. Agent AI połączony z pocztą e-mail, pamięcią masową w chmurze, danymi klientów, kodem źródłowym lub systemami finansowymi działa na znacznie większej powierzchni ataku.

Agentowa AI odnosi się do oprogramowania, które może planować i wykonywać wiele działań w kierunku celu. Jej ryzyko zależy mniej od płynności rozmowy, a bardziej od tożsamości, uprawnień, dostępnych narzędzi i danych, do których może dotrzeć.

Stwarza to kilka dróg do incydentu. Agent może otrzymać nadmierne uprawnienia, wykonać złośliwe instrukcje osadzone w dokumencie, ujawnić pobrane informacje lub uruchomić działanie poza zamierzonym celem.

Pracownicy również zwiększają ekspozycję poprzez shadow AI, czyli narzędzia AI używane bez formalnego zatwierdzenia lub monitorowania. Ryzyko rośnie, gdy narzędzia te przechowują prompty, trenują na przesyłanych treściach lub łączą się z kontami organizacji.

Tradycyjne programy bezpieczeństwa już zarządzają tożsamościami, punktami końcowymi, aplikacjami i ruchem sieciowym. AI dodaje warstwę rozumowania, która może łączyć informacje i inicjować działania z szybkością maszyny.

Nie oznacza to, że każdy system AI jest nieprzewidywalny. Oznacza jednak, że statyczne zatwierdzenie przy wdrożeniu nie może zastąpić ciągłej obserwacji po wdrożeniu.

Termin ten odzwierciedla również presję regulacyjną. Akt w sprawie AI Unii Europejskiej wszedł w życie w 2024 roku, a jego obowiązki są wdrażane etapowo. Wymogi dotyczące modeli AI ogólnego przeznaczenia zaczęły obowiązywać w sierpniu 2025 roku.

Harmonogram wdrażania Komisji Europejskiej pokazuje, że różne przepisy i przejściowe terminy obowiązują w różnych momentach. Organizacje muszą określić, które systemy, role dostawców i przypadki użycia podlegają poszczególnym obowiązkom.

Ten zmieniający się harmonogram komplikuje planowanie zgodności, ale nie eliminuje potrzeby inwentaryzacji. Firma nie może sklasyfikować systemu AI, udokumentować jego ryzyk ani zastosować właściwych mechanizmów kontroli, jeśli nikt nie wie o jego istnieniu.

Regulacje są tylko jednym źródłem presji. Klienci coraz częściej pytają dostawców, w jaki sposób AI przetwarza informacje poufne. Ubezpieczyciele, audytorzy, zarządy i zespoły zakupowe również chcą dowodów, że mechanizmy kontroli działają zgodnie z opisem.

Wymóg dowodowy zmienia znaczenie gotowości. Firma nie jest gotowa dlatego, że kierownictwo zatwierdziło politykę AI. Jest gotowa, gdy zespoły potrafią wykazać, kto uzyskał dostęp do danych, który model je otrzymał, co zrobił system i jak zareagowała organizacja.

Dlatego ustalenia Kiteworks dotyczące zarządzania AI rezonują poza bazą klientów dostawcy. Opisują one lukę operacyjną widoczną już w przeglądach bezpieczeństwa i procesach zakupowych przedsiębiorstw.

Google News wzmacnia statystykę dotyczącą incydentów w momencie, gdy kadra zarządzająca dostrzega problem, ale nie ma spójnych dowodów. Nagłówek przyciąga uwagę, ponieważ wdrażanie wyprzedziło systemy potrzebne do jego obserwowania.

Obietnice dotyczące zarządzania wyprzedzają techniczną kontrolę

Główny konflikt nie dotyczy wdrażania AI kontra ostrożności; dotyczy zarządzania obiecanego na papierze kontra zarządzania egzekwowanego w środowisku produkcyjnym.

Opracowanie Kiteworks dla sektora technologicznego ilustruje ten podział. Organizacje technologiczne przewodziły globalnej próbie w kilku formalnych obszarach zarządzania.

Sektor zgłosił stosowanie technik chroniących prywatność na poziomie 56%, wobec globalnego wyniku 33%. Taksonomie incydentów AI i podręczniki reagowania osiągnęły 50%, wobec 27% globalnie.

Respondenci z sektora technologicznego zgłosili również oceny wpływu AI na poziomie 53%, audyty stronniczości na poziomie 47% oraz dokumentację wyjaśnialności modeli na poziomie 41%. Każdy wynik przewyższał odpowiadającą mu wartość globalną.

Są to znaczące inwestycje. Oceny wpływu mogą identyfikować grupy dotknięte działaniem systemu i przewidywalne szkody. Podręczniki reagowania na incydenty zapewniają zespołom z góry określone obowiązki, gdy model zachowuje się nieoczekiwanie.

Jednak to samo opracowanie dla sektora technologicznego wykazało słabsze wyniki w mniej widocznej infrastrukturze.

Tylko 22% respondentów z sektora technologicznego zgłosiło odizolowane środowiska szkoleniowe, wobec 26% globalnie. Izolacja rozdziela zasoby rozwoju, szkolenia i produkcji, aby dane nie mogły przemieszczać się między nimi bez kontroli.

Tylko 19% zgłosiło możliwości ustalania pochodzenia i śledzenia danych, wobec globalnego wyniku 23%. Pochodzenie danych rejestruje, skąd informacje pochodzą, jak się zmieniły oraz które modele lub procesy z nich korzystały.

Tworzy to praktyczną sprzeczność. Firma może wykryć nietypowe zachowanie i posiadać dokument reagowania, a mimo to nie być w stanie prześledzić dotkniętego wyniku do danych źródłowych.

Może również utrzymywać kontrolę dostępu w środowisku produkcyjnym, jednocześnie pozostawiając środowiska rozwoju modeli zbyt szeroko połączone. Ta luka zwiększa ryzyko nieautoryzowanego dostępu, zanieczyszczonych materiałów szkoleniowych lub niezamierzonego przepływu danych.

Respondenci z sektora technologicznego osiągnęli lepsze wyniki w zakresie niezmiennych ścieżek audytu, monitorowania dryfu i podręczników reagowania na incydenty. Te mechanizmy pomagają zespołom dostrzec, że coś się zmieniło.

Słabe śledzenie pochodzenia utrudnia wyjaśnienie, dlaczego to się zmieniło. Może opóźniać analizę przyczyn źródłowych i utrudniać zapobieganie nawrotom problemu.

Raport wykazał również, że 53% respondentów z sektora technologicznego stwierdziło, iż zarządy priorytetowo traktowały zarządzanie AI. Jednak tylko 47% zgłosiło uwagę zarządów poświęcaną ogólnej postawie w zakresie ryzyka cybernetycznego, o siedem punktów procentowych mniej niż wynik globalny.

Ten wynik nie dowodzi, że zarządy porzuciły cyberbezpieczeństwo. Sugeruje, że uwaga kierownictwa może przesuwać się w stronę widocznych inicjatyw AI, podczas gdy podstawowe bezpieczeństwo konkuruje o ten sam czas i budżet.

Zarządzanie AI nie może funkcjonować obok cyberbezpieczeństwa jako odizolowany projekt zgodności. Zależy ono od zarządzania tożsamością, szyfrowania, klasyfikacji danych, bezpieczeństwa oprogramowania, nadzoru nad podmiotami trzecimi i reagowania na incydenty.

Amerykański National Institute of Standards and Technology odzwierciedla to podejście oparte na cyklu życia. Jego dobrowolne ramy zarządzania ryzykiem AI organizują pracę wokół czterech funkcji: Govern, Map, Measure i Manage.

Zarządzanie ustanawia odpowiedzialności i polityki. Mapowanie identyfikuje kontekst i strony, których to dotyczy. Pomiar ocenia ryzyko, natomiast zarządzanie nim ustala priorytety i podejmuje działania.

Firma, która zatrzymuje się na zarządzaniu, ukończyła jedynie część tego cyklu. Polityki muszą łączyć się z obserwacjami technicznymi, wynikami testów i decyzjami dotyczącymi reagowania.

To jest kluczowe odwrócenie stojące za nagłówkiem. Organizacje mogą wyglądać na przygotowane, ponieważ mają komitety, standardy i zatwierdzone narzędzia. Incydenty bezpieczeństwa AI ujawniają, czy te przygotowania docierają do systemów obsługujących rzeczywiste dane.

Incydenty bezpieczeństwa AI ujawniają problem z inwentaryzacją

Organizacje nie mogą kontrolować przepływów danych AI, których nie potrafią zidentyfikować, sklasyfikować i odtworzyć.

Inwentaryzacja brzmi podstawowo, ale AI ją komplikuje. Pojedynczy proces biznesowy może obejmować pracownika, aplikację, zewnętrznego dostawcę modeli, infrastrukturę wyszukiwania oraz kilka repozytoriów danych.

Firma może posiadać tylko część tego łańcucha. Platforma obsługi klienta może dodawać funkcje generatywne za pośrednictwem modelu dostarczanego przez stronę trzecią. Deweloper może połączyć asystenta programistycznego z prywatnymi repozytoriami.

Inny zespół może zbudować wewnętrznego agenta, który pobiera dokumenty ze współdzielonej pamięci. Każde wdrożenie może tworzyć odmienne warunki dotyczące retencji, uprawnień i logowania.

Przydatna inwentaryzacja musi zatem obejmować więcej niż nazwy produktów. Powinna wskazywać właścicieli systemów, zamierzone cele, dostawców modeli, podłączone dane, dostępne narzędzia, grupy użytkowników oraz lokalizacje geograficzne przetwarzania.

Musi również uwzględniać, czy system może podejmować działania. Asystent, który przygotowuje szkic wiadomości e-mail, stwarza jeden poziom ryzyka. Agent upoważniony do wysłania tej wiadomości lub zmodyfikowania konta stwarza inny.

Ustalenia Kiteworks dotyczące widoczności podmiotów trzecich wpisują się w ten problem. Nieznani dostawcy i integracje mogą ukrywać ścieżki, którymi przemieszczają się prywatne dane.

Organizacja mogła zatwierdzić widoczną aplikację, ale nie rozumieć wszystkich podmiotów przetwarzających dane działających pod nią. Staje się to istotne, gdy zmienia się dostawca modelu, wtyczka lub usługa danych.

Ten sam problem występuje w przypadku suwerenności danych. Badanie Kiteworks z 2026 roku wykazało, że około czterech na pięciu respondentów uważało się za dobrze poinformowanych o wymogach dotyczących suwerenności. Jednak około jedna trzecia zgłosiła incydent związany z suwerennością w poprzednim roku.

Suwerenność danych dotyczy prawnej i operacyjnej kontroli nad miejscem przechowywania informacji oraz jurysdykcją, która je reguluje. AI komplikuje tę kwestię, gdy prompty, embeddingi, logi i wyniki modeli przekraczają granice regionów.

Raport dotyczący suwerenności przedstawia tę lukę jako różnicę między świadomością a możliwą do udowodnienia kontrolą. Organizacje mogą rozumieć zasady, lecz nie mieć zautomatyzowanego egzekwowania ani dowodów gotowych do audytu.

Ten kontrast jest bardziej uzasadniony niż traktowanie każdego zgłoszonego zdarzenia jako tego samego rodzaju incydentu AI. Wskazuje też na konkretny test.

Czy po zdarzeniu związanym z AI organizacja potrafi zidentyfikować dane, których dotyczyło, zaangażowany model, tożsamość inicjującą, wykonane działania oraz odbiorców dalszego przetwarzania? Jeśli nie, zarządzanie pozostaje niepełne niezależnie od jakości polityk.

Pracownicy wiedzy mają swoją rolę w tym systemie. Decydują, które pliki trafiają do promptów, którym wygenerowanym odpowiedziom zaufać oraz które narzędzia AI stają się częścią codziennej pracy.

Organizacje mogą ograniczać przypadkowe ujawnienia, zapewniając pracownikom zatwierdzone sposoby wyszukiwania i syntezy własnych informacji. Prywatna baza wiedzy AI może ograniczyć niepotrzebne kopiowanie między niepowiązanymi usługami, gdy jej granice są jasno określone.

Takie podejście nadal wymaga zarządzania. Lokalna lub prywatna pamięć masowa nie rozwiązuje automatycznie problemów nadmiernego dostępu, niedokładnych wyników, słabego uwierzytelniania ani obowiązków retencyjnych.

Celem nie jest zakazywanie przydatnych procesów pracy. Chodzi o zapewnienie użytkownikom zatwierdzonej ścieżki, której przepływ danych można zrozumieć i zweryfikować.

Inwentaryzacja wymaga również zarządzania zmianą. Aplikacja, która zaczynała jako asystent pisania, może zyskać funkcje wyszukiwania, automatyzacji lub agenta w wyniku aktualizacji.

Zespoły bezpieczeństwa powinny oceniać nowe możliwości zgodnie ze zmienionym dostępem i działaniami, a nie tylko na podstawie znajomej nazwy produktu. Narzędzie wcześniej uznawane za niskiego ryzyka może istotnie się zmienić po otrzymaniu nowych uprawnień.

W tym miejscu incydenty bezpieczeństwa AI stają się cennymi sygnałami. Każde zdarzenie powinno aktualizować inwentaryzację, model zagrożeń, projekt mechanizmów kontroli oraz wytyczne dla pracowników.

Sama liczba incydentów nie pokazuje, czy organizacje wyciągnęły z tych zdarzeń wnioski. Jakość procesu naprawczego ma większe znaczenie niż nagłówkowa liczba.

Czego liczba 80% nie dowodzi

Nagłówek sygnalizuje szeroką ekspozycję, ale nie ustala uniwersalnego wskaźnika naruszeń ani nie dowodzi, że AI spowodowała każdy zgłoszony incydent.

Badania ankietowe dostawców mogą ujawniać użyteczne wzorce, zwłaszcza gdy publikują wielkość próby i metodologię. Mają też nieuniknione ograniczenia.

Respondenci mogą różnie interpretować pojęcie „incydentu”. Liderzy bezpieczeństwa mogą pod tą samą etykietą uwzględniać próby ataków, potwierdzone naruszenia, naruszenia polityk, zdarzenia dotyczące prywatności i awarie operacyjne.

Wyniki zgłaszane przez samych respondentów zależą również od widoczności. Dojrzała organizacja z rozbudowanym monitoringiem może zgłaszać więcej incydentów, ponieważ wykrywa więcej zdarzeń.

Mniej przygotowana organizacja może wydawać się bezpieczniejsza tylko dlatego, że nie potrafi dostrzec błędów. Własne badania Kiteworks ostrzegają przed tym efektem widoczności.

Znaczenie mają również populacje objęte ankietą. Brief technologiczny Kiteworks w przeważającej mierze reprezentuje duże organizacje: 97% respondentów pracuje w przedsiębiorstwach zatrudniających co najmniej 1 000 osób.

Duże firmy mają więcej systemów, użytkowników, dostawców i obowiązków regulacyjnych. Ich doświadczeń nie należy bezpośrednio przenosić na małe firmy.

Analiza technologiczna obejmowała jedynie 32 respondentów z sektorów branżowych. Różnica kilku odpowiedzi może istotnie zmienić odsetek w tej podgrupie.

Twierdzenie o 80% wymaga więc dodatkowych szczegółów, zanim czytelnicy będą mogli porównać je z innym badaniem incydentów. Niezbędne informacje obejmują treść pytania, opcje odpowiedzi, okres obserwacji oraz sposób traktowania podejrzewanych zdarzeń.

Pomocne byłoby również oddzielenie tradycyjnych incydentów cyberbezpieczeństwa od zdarzeń mających źródło w AI. Atakujący wykorzystujący AI do ulepszania phishingu to coś innego niż model przedsiębiorstwa ujawniający pobrane dane.

Trzecia kategoria obejmuje konwencjonalne ataki na infrastrukturę AI, takie jak kradzież poświadczeń lub podatne oprogramowanie. Nazywanie wszystkich trzech „incydentami AI” zaciera obraz tego, kto kontrolował system, który zawiódł.

Kiteworks sprzedaje również produkty przeznaczone do rozwiązywania problemów zarządzania prywatnymi danymi. Ta pozycja komercyjna nie unieważnia jego danych, lecz stwarza zachętę do podkreślania ryzyk, którymi zajmuje się jego platforma.

Niezależne odtworzenie wyników wzmocniłoby nagłówkowe twierdzenie. Pomogłoby także opublikowanie zanonimizowanych podziałów według rodzaju incydentu, wielkości organizacji, regionu i dojrzałości zarządzania.

Najbardziej wiarygodna lekcja płynąca z raportu nie wymaga przyjęcia uniwersalnego wskaźnika 80%. Wiele badań Kiteworks pokazuje, że formalna gotowość i operacyjne egzekwowanie często się rozchodzą.

Brief technologiczny wskazuje luki w izolacji treningu i pochodzeniu danych. Wcześniejsza ankieta wykazała ograniczone wdrażanie technicznego zarządzania. Badanie dotyczące suwerenności pokazuje wysoką świadomość przy jednoczesnym utrzymywaniu się incydentów.

Razem te ustalenia wspierają węższy wniosek. Wiele dużych organizacji rozpoczęło zarządzanie AI, ale stosunkowo niewiele potrafi wykazać kompleksową kontrolę techniczną nad całym cyklem życia danych.

To poważny problem, ale bez sensacyjnego tonu. Daje też nabywcom lepsze ramy do oceny produktów do zarządzania.

Dostawca powinien wyjaśnić, które przepływy danych obserwuje, jakie polityki egzekwuje i które działania może blokować. Powinien także ujawniać ograniczenia i zależności integracyjne.

Nabywcy powinni zachować ostrożność, gdy produkt traktuje zarządzanie wyłącznie jako pulpit. Widoczność jest konieczna, ale egzekwowanie, testowanie, reagowanie i odzyskiwanie uzupełniają cykl operacyjny.

Powinni również unikać założenia, że jedna brama kontroluje każdą ścieżkę. Pracownicy, wbudowane funkcje AI, bezpośrednie interfejsy programowania aplikacji i autonomiczni agenci mogą tworzyć odrębne trasy.

Nagłówek Google News zasługuje na uwagę, ponieważ stojące za nim ryzyko jest realne. Dokładny odsetek powinien pozostać przypisany raportowi, dopóki pełna metodologia nie wyjaśni, co obejmuje ta liczba.

Trzy sygnały, które sprawdzą ostrzeżenie Kiteworks

Kolejne dowody powinny pokazać, czy przedsiębiorstwa budują egzekwowalne zarządzanie, czy jedynie dodają kolejną warstwę dokumentacji.

Pierwszym sygnałem jest lepsze ujawnianie informacji o incydentach. Przyszłe badania powinny oddzielać potwierdzone naruszenia, podejrzewane zdarzenia, naruszenia polityk i niezamierzone działania AI.

Powinny także rozróżniać incydenty spowodowane przez AI od ataków wymierzonych w systemy AI. Taka taksonomia uczyniłaby porównania rok do roku bardziej znaczącymi.

Szczegółowe ujawnienia mogłyby wzmocnić ostrzeżenie Kiteworks, jeśli wysokie wskaźniki utrzymałyby się w jasno zdefiniowanych kategoriach. Mogłyby osłabić nagłówek, jeśli liczba 80% łączy wiele zdarzeń o niskiej wadze lub luźno powiązanych.

Drugim sygnałem jest mierzalny postęp w mechanizmach kontroli technicznej. Brief technologiczny z 2026 roku zapewnia punkty odniesienia dla izolowanych środowisk treningowych, pochodzenia danych, procedur reagowania na incydenty i nadzoru zarządu.

Ankieta uzupełniająca powinna wykorzystać te same pytania i podejście do doboru próby. Rosnące wdrażanie śledzenia pochodzenia i izolacji środowisk pokazałoby, że organizacje zamykają lukę w egzekwowaniu.

Stabilne lub spadające wyniki potwierdziłyby główną obawę raportu. Wskazywałyby, że wydatki nadal koncentrują się na ocenach i politykach zamiast na podstawowych mechanizmach kontroli.

Trzecim sygnałem są dowody regulacyjne. Europejskie działania egzekucyjne, audyty i wytyczne wdrożeniowe powinny ujawnić, które błędy w zarządzaniu powodują największą praktyczną ekspozycję.

Warto obserwować sprawy dotyczące brakującej dokumentacji, niewystarczającego monitoringu, nieujawnionej interakcji z AI lub słabo kontrolowanego przepływu danych. Te przykłady pomogą organizacjom ustalić priorytety inwestycji.

Działania regulacyjne mogłyby wzmocnić tezę raportu, gdyby organy wielokrotnie stwierdzały rozbieżności między deklarowanymi politykami a zachowaniem systemów. Jasna zgodność przy niewielu awariach operacyjnych osłabiłaby jej pilność.

Nabywcy korporacyjni nie muszą czekać na te sygnały, zanim podejmą działania. Mogą sprawdzić gotowość za pomocą prostego ćwiczenia opartego na jednym produkcyjnym procesie AI.

Zacznij od systemu, który uzyskuje dostęp do informacji wrażliwych. Poproś właściciela o wskazanie każdego źródła danych, dostawcy modelu, podłączonego narzędzia, uprawnienia, reguły retencji i osoby odpowiedzialnej za decyzje.

Następnie zasymuluj przejęte konto, złośliwy dokument lub niezamierzone działanie. Ustal, czy organizacja potrafi zatrzymać system, prześledzić jego aktywność, zidentyfikować ujawnione informacje i zabezpieczyć dowody.

Ćwiczenie powinno obejmować dział prawny, bezpieczeństwo, prywatność, IT oraz zespół biznesowy korzystający z systemu. Zarządzanie AI zawodzi, gdy odpowiedzialność znika pomiędzy tymi grupami.

Zespoły powinny przechowywać decyzje i wnioski z incydentów w systemie umożliwiającym wyszukiwanie, zamiast rozpraszać je po spotkaniach i dokumentach. Ustrukturyzowany proces pracy z wiedzą może pomóc właścicielom utrzymywać dowody w miarę zmian systemów.

Dokumentacja nadal nie może zastąpić egzekwowania. Jej wartość polega na łączeniu wskazanych właścicieli, obserwowanego zachowania, zatwierdzonych wyjątków i działań naprawczych.

Zgłoszoną przez Kiteworks liczbę 80% incydentów najlepiej odczytywać jako ostrzeżenie zasługujące na weryfikację. Szersze badania firmy już pokazują wystarczające dowody słabej widoczności, ograniczonego zarządzania technicznego i niepełnego pochodzenia danych.

Prawdziwe pytanie nie brzmi już, czy organizacja ma politykę AI. Brzmi ono: czy potrafi ona odtworzyć działania systemu AI po tym, jak coś pójdzie nie tak.

Google News może nagłośnić dramatyczny odsetek, ale liderzy bezpieczeństwa potrzebują mechanizmów kontroli, które się pod nim kryją. Powinni zinwentaryzować jeden działający proces AI, przetestować jego ścieżkę awarii i udokumentować to, co pozostaje niewidoczne.