Ostrzeżenie Bonfy dotyczące Shady AI ujawnia kolejny problem z zarządzaniem bezpieczeństwem

Prezes Bonfy, Gidi Cohen, wskazał niepokojącą lukę w zarządzaniu zatwierdzonymi systemami AI w przedsiębiorstwach. Legalny dostęp nie gwarantuje już właściwego rezultatu.

Cohen nazywa ten problem „shady AI”. Termin opisuje zatwierdzoną AI, która wykorzystuje autoryzowane dane w sposób sprzeczny z intencją biznesową, zasadami lub oczekiwaniami klientów. W odróżnieniu od shadow AI sam system nie jest ukryty przed zespołami bezpieczeństwa.

Ostrzeżenie dotarło do szerszego grona odbiorców dzięki publikacjom na temat bezpieczeństwa i Google News. Najważniejsza historia nie dotyczy jednak kolejnej chwytliwej etykiety cyberbezpieczeństwa. Chodzi o załamanie znanego założenia: zatwierdzona technologia działająca z ważnymi uprawnieniami jest technologią zarządzaną.

To założenie sprawdzało się lepiej, gdy oprogramowanie wykonywało przewidywalne instrukcje. Pracownik otwierał rekord, zmieniał pole albo eksportował dokument. Zespoły bezpieczeństwa mogły powiązać działanie z osobą, uprawnieniem, aplikacją i znacznikiem czasu.

AI zmienia tę relację. System może pobrać tysiące autoryzowanych rekordów, wywnioskować powiązania między nimi i wygenerować rezultat, o który nikt bezpośrednio nie prosił. Każdy pojedynczy dostęp może być dozwolony, podczas gdy łączny wynik przekracza granicę.

Ten konflikt stawia zespoły bezpieczeństwa przedsiębiorstw przed dwoma niezadowalającymi wyborami. Mogą spowolnić wdrażanie AI poprzez ścisłe kontrole albo dopuścić szybkie wdrożenie bez rozumienia każdego dalszego wykorzystania danych firmy.

Żaden z tych wyborów nie rozwiązuje kluczowego problemu. Organizacje potrzebują kontroli oceniających, dlaczego dane są wykorzystywane, a nie tylko czy aplikacja może do nich dotrzeć.

Shady AI przenosi ryzyko do wnętrza zatwierdzonych systemów

Shady AI zmienia zatwierdzony przepływ pracy w problem zarządzania, nie wymagając przy tym nieuczciwego pracownika, nieznanej aplikacji ani skradzionych poświadczeń.

Cohen wprowadził ten termin, omawiając sposób, w jaki AI odróżnia istotność od stosowności. Jego argument dotyczy systemów działających w zatwierdzonych platformach i celowo zaprojektowanych przepływach pracy.

Użytkownik może mieć właściwą rolę. Aplikacja mogła przejść przegląd bezpieczeństwa. Wszystkie bazowe rekordy mogą być dostępne za pośrednictwem legalnych uprawnień.

Wynikające z tego działanie może mimo to naruszać zasady. Asystent AI może połączyć komunikację z klientami, szczegóły umów i historię wsparcia, aby stworzyć nieautoryzowany profil ryzyka. Każde źródło wydaje się istotne, lecz ich łączne użycie zmienia cel wykorzystania danych.

Rozróżnienie Cohena ma znaczenie, ponieważ programy bezpieczeństwa zwykle traktują zatwierdzenie jako istotną granicę kontrolną. Gdy dostawca, aplikacja, integracja i tożsamość przejdą weryfikację, monitoring często koncentruje się na nieautoryzowanym dostępie lub podejrzanym zachowaniu.

Opis tej koncepcji przedstawiony przez Bonfy wskazuje, że system AI może pobierać dozwolone informacje, a mimo to tworzyć rezultat sprzeczny z oczekiwaniami klientów. Firma opisuje to jako zatwierdzoną AI wychodzącą poza zamierzone granice w swoim omówieniu koncepcji shady AI.

Nadal jest to ujęcie promowane przez dostawcę, a nie uznana kategoria regulacyjna. Żaden niezależny organ nie ustanowił „shady AI” standardowym terminem ani mierzalną klasą incydentów.

Mimo to podstawowe zachowanie jest wystarczająco realne, by je przeanalizować. Systemy generatywne mogą syntetyzować dane z różnych repozytoriów, wnioskować o wrażliwych atrybutach i inicjować działania za pośrednictwem połączonych narzędzi. Te możliwości rozszerzają znaczenie autoryzowanego dostępu.

Rozważmy asystenta w miejscu pracy połączonego z pocztą e-mail, dokumentami, kalendarzami i rekordami klientów. Menedżer prosi go o wskazanie kont, które prawdopodobnie zrezygnują w danym kwartale.

Asystent mógłby wywnioskować trudności finansowe ze sporów dotyczących rozliczeń. Mógłby wydobyć niezadowolenie z prywatnych rozmów ze wsparciem. Mógłby też połączyć te ustalenia z datami odnowienia umów i komentarzami pracowników.

Każde źródło mogłoby znajdować się w ramach technicznych uprawnień menedżera. Organizacja mogła jednak nigdy nie zatwierdzić takiego połączonego celu profilowania. Może również nie mieć zapisu czynników, które wpłynęły na rekomendację.

To różni się od zwykłego shadow AI. Shadow AI zwykle odnosi się do pracowników korzystających z niezatwierdzonych modeli, prywatnych kont chatbotów, rozszerzeń przeglądarki lub nieusankcjonowanych agentów.

W takich przypadkach problem bezpieczeństwa zaczyna się od widoczności. Zespoły muszą odkryć, które narzędzia są aktywne, ustalić, jakie dane do nich trafiły, oraz zdecydować, czy zablokować ich użycie, czy nim zarządzać.

The Hacker News opisał inną wersję tego ryzyka wewnątrz zatwierdzonego oprogramowania. Funkcje AI mogą pojawić się w istniejących systemach help desk, systemach dokumentowych i platformach klienckich po pierwotnej weryfikacji dostawcy.

Jego omówienie ryzyk shadow AI wskazuje, że wcześniejsza weryfikacja oprogramowania nie zapewnia zarządzania każdą funkcją AI włączoną później. To spostrzeżenie zmniejsza dystans między shadow AI a nowszym ujęciem Cohena.

Obie koncepcje nadal opisują jednak różne niepowodzenia kontroli.

Shadow AI pyta, czy organizacja wie o istnieniu narzędzia lub funkcji. Shady AI pyta, czy zachowanie zatwierdzonego systemu pozostaje właściwe dla konkretnego użytkownika, celu i relacji.

Google News może umieszczać obie historie pod tym samym szerokim tematem bezpieczeństwa AI. Obrońcy przedsiębiorstw nie mogą sobie pozwolić na traktowanie ich jako tego samego problemu operacyjnego.

Narzędzia do wykrywania mogą ujawnić nieznany chatbot. Nie potrafią jednak automatycznie zdecydować, czy zatwierdzony asystent powinien wykorzystywać wrażliwą rozmowę z klientem do wpływania na decyzję sprzedażową.

Taka decyzja wymaga kontekstu. Wymaga również zasad, które oprogramowanie może ocenić przed pobraniem danych, generowaniem odpowiedzi lub podjęciem działania.

Dlaczego kontrole tożsamości i dostępu już nie wystarczają

Kontrole tożsamości odpowiadają na pytanie, kto może dotrzeć do danych, lecz shady AI zmusza organizacje do określenia, które relacje i cele sprawiają, że ten dostęp jest właściwy.

Tradycyjna kontrola dostępu przyznaje uprawnienia za pośrednictwem ról, grup, własności zasobów i reguł polityki. Menedżer wsparcia klienta może odczytywać wszystkie sprawy przypisane do regionu. Analityk finansowy może przeglądać każdą fakturę dla jednostki biznesowej.

Te kontrole nadal są niezbędne. Powstrzymują wielu nieautoryzowanych użytkowników i aplikacje przed dostępem do wrażliwych systemów. Tworzą również zapisy, które śledczy mogą przeanalizować po incydencie.

Szerokie uprawnienia często istnieją jednak dlatego, że ludzie potrzebują elastyczności. Doświadczony pracownik może mieć dostęp do tysięcy dokumentów, wykorzystując jedynie niewielki ich podzbiór w każdym zadaniu.

Ludzka ocena stanowi nieformalną drugą warstwę. Pracownicy zwykle rozumieją, że dostęp do rekordu klienta nie upoważnia do każdego możliwego wykorzystania jego treści.

Nie można zakładać, że AI podziela to rozumienie. Model optymalizuje odpowiedź, wykorzystując dostępny kontekst, instrukcje i wyuczone wzorce. Nie zna z natury niepisanych granic organizacji.

Powstaje w ten sposób problem celu. Dane zebrane na potrzeby obsługi klienta mogą być technicznie dostępne dla asystenta sprzedażowego. Ta dostępność niekoniecznie upoważnia jednak do wykorzystywania emocjonalnego języka z rozmów ze wsparciem w celu dostosowania traktowania handlowego.

Powstaje też problem relacji. Klinicysta, prawnik, menedżer zasobów ludzkich i administrator systemu mogą uzyskiwać dostęp do tego samego rekordu w ramach różnych obowiązków zawodowych.

Konwencjonalne uprawnienie może reprezentować zasób i użytkownika. Rzadko jednak obejmuje pełną relację towarzyszącą każdemu wnioskowi, którego może dokonać AI.

Agenci dodatkowo podnoszą stawkę. Agent AI to oprogramowanie, które wybiera i wykonuje działania za pośrednictwem połączonych narzędzi, zamiast jedynie generować tekst.

Zatwierdzony agent może czytać e-maile, wysyłać zapytania do bazy danych, aktualizować rekord klienta i wysyłać wiadomość. Jego uprawnienia mogą być poprawne na każdym etapie.

Łączna sekwencja nadal może być niebezpieczna. Niezaufana instrukcja ukryta w e-mailu może przekierować zachowanie agenta. Szeroko określony cel może również zachęcać do nadmiernego pobierania danych lub niepotrzebnych działań.

OWASP opisuje prompt injection jako instrukcje manipulujące modelem poprzez bezpośrednie dane wejściowe lub treści, które model przetwarza później. Według jego wytycznych dotyczących prompt injection wpływ zależy w dużej mierze od dostępnych narzędzi i uprawnień systemu.

To zagrożenie łączy exploity bezpieczeństwa z niepowodzeniami w zarządzaniu. Złośliwa instrukcja może spowodować niewłaściwe działanie, ale niejasne zasady mogą prowadzić do podobnego rezultatu bez udziału atakującego.

OWASP osobno ostrzega przed nadmierną autonomią, gdy system AI ma więcej funkcji, uprawnień lub samodzielności, niż potrzebuje. Jego przykład obejmuje złośliwy e-mail nakazujący agentowi przeszukać skrzynkę odbiorczą i przekazać dalej wrażliwe informacje.

Zasada najmniejszych uprawnień pozostaje częścią odpowiedzi. Asystent nie może niewłaściwie wykorzystać danych ani funkcji, do których nie ma dostępu.

Samo ograniczanie uprawnień ma jednak swoje granice. Organizacje często wdrażają AI właśnie dlatego, że może ona łączyć informacje między systemami. Usunięcie każdej funkcji między systemami może wyeliminować wartość biznesową, która uzasadniała wdrożenie.

Trudniejszym zadaniem jest zwiększenie precyzji autoryzacji. Decyzja powinna uwzględniać tożsamość osoby składającej żądanie, cel biznesowy, relację z danymi, działanie, odbiorcę i bieżący kontekst.

Na przykład asystent obsługi klienta może podsumować skargę dla przypisanej sprawy. Ten sam asystent nie powinien dodawać informacji zdrowotnych z tej skargi do profilu marketingowego.

Oba działania dotyczą tej samej tożsamości i danych bazowych. Różnica leży w celu, odbiorcach i oczekiwanym wykorzystaniu.

Dlatego shady AI jest zasadniczo wyzwaniem związanym z zarządzaniem. Zespoły bezpieczeństwa mogą definiować granice techniczne, lecz właściciele obszarów prawnych, prywatności, zgodności, produktu i biznesu muszą definiować właściwe zachowanie.

Ta współodpowiedzialność jest niewygodna. Organizacje bezpieczeństwa preferują egzekwowalne reguły, podczas gdy zespoły odpowiedzialne za polityki często formułują zasady zależne od ludzkiej interpretacji.

Systemy AI ujawniają lukę między tymi podejściami. Polityka stwierdzająca, że dane klientów muszą być wykorzystywane „właściwie”, zapewnia niewielką ochronę, jeśli organizacja nie przekształci tego słowa w testowalne kontrole.

Google News sygnalizuje przejście od dostępu do intencji

Szersza dyskusja o bezpieczeństwie przesuwa się od odkrywania narzędzi AI ku zarządzaniu tym, co zatwierdzone modele i agenci robią z legalnym dostępem.

Pojawienie się shady AI w Google News odzwierciedla szerszą zmianę w relacjonowaniu bezpieczeństwa przedsiębiorstw. Pierwsza fala obaw koncentrowała się na pracownikach wklejających wrażliwe dane do publicznych chatbotów.

To ryzyko nie zniknęło. Prywatne konta, niezatwierdzone aplikacje i wbudowane funkcje AI nadal powodują problemy z widocznością i utratą danych.

Zatwierdzone wdrożenia korporacyjne stawiają jednak obecnie bardziej złożone pytanie. Organizacje łączą asystentów i agentów z wartościowymi systemami, ponieważ odizolowane interfejsy czatowe zapewniają ograniczoną wartość operacyjną.

Te połączenia tworzą kontekst. Tworzą również uprawnienia.

Model połączony z firmową bazą wiedzy może lokalizować wewnętrzne informacje. Agent połączony z oprogramowaniem operacyjnym może działać na podstawie tych informacji. Zarządzanie musi więc obejmować zarówno interpretację, jak i wykonanie.

Badania IBM dotyczące naruszeń z 2025 roku wykazały znaczącą lukę w nadzorze nad korporacyjną AI. W oficjalnym komunikacie firma podała, że 13 procent badanych organizacji zgłosiło naruszenia związane z modelami lub aplikacjami AI.

Wśród tych organizacji 97 procent nie miało odpowiednich mechanizmów kontroli dostępu do AI. IBM podał również, że 63 procent badanych organizacji nie posiadało polityk zarządzania AI lub nadal je opracowywało.

Dane te pochodzą z badań sponsorowanych przez dostawcę i nie powinny definiować poziomu ryzyka w każdej organizacji. Pokazują jednak, dlaczego bezpieczeństwo AI wykracza już poza hipotetyczne ataki na modele.

Wyniki IBM dotyczące naruszeń opisują sytuację, w której wdrażanie wyprzedza zarządzanie. Shady AI wskazuje jeden z możliwych skutków tej nierównowagi wewnątrz zatwierdzonych systemów.

Istniejące ramy zapewniają użyteczne podstawy. Ramy NIST dla AI porządkują zarządzanie ryzykiem AI wokół zarządzania, mapowania, mierzenia i kontrolowania ryzyka.

NIST opublikował również profil generatywnej AI, który dostosowuje te ramy do ryzyk specyficznych dla modeli. Podkreśla on udokumentowane obowiązki, testowanie, procesy obsługi incydentów oraz ciągłe pomiary.

Praktyki te pomagają organizacjom wyjść poza jednorazową akceptację. Zachęcają zespoły do traktowania wdrożonej AI jako zmiennego systemu wymagającego stałego nadzoru.

Same ramy nie mogą jednak dostarczyć reguł biznesowych dla każdej firmy. Bank, szpital, dostawca oprogramowania i uniwersytet inaczej zdefiniują właściwe wykorzystanie danych.

Regulacje dodają kolejną warstwę. Przepisy Unii Europejskiej nakładają obowiązki na dostawców i podmioty wdrażające w zależności od roli systemu AI oraz jego klasyfikacji ryzyka.

Komisja Europejska podaje, że obowiązki dotyczące modeli ogólnego przeznaczenia zaczęły obowiązywać 2 sierpnia 2025 r. Obejmują one wymogi dotyczące dokumentacji i przejrzystości, a także dodatkowe obowiązki dla modeli sklasyfikowanych jako stwarzające ryzyko systemowe.

Reguły te koncentrują się przede wszystkim na dostawcach i określonych przypadkach użycia. Nie rozstrzygają automatycznie każdej decyzji kontekstowej podejmowanej przez asystenta korporacyjnego korzystającego z autoryzowanych danych wewnętrznych.

Organizacja może spełniać wymogi dotyczące dokumentacji dostawcy, a mimo to wdrożyć asystenta o słabo zdefiniowanych celach wewnętrznych. Zgodność prawna i adekwatność operacyjna częściowo się pokrywają, lecz nie są tym samym.

To samo rozróżnienie występuje w prawie o prywatności. Zgoda lub inna podstawa prawna może upoważniać do przetwarzania danych na wysokim poziomie. Nowe wnioskowanie lub połączenie zbiorów danych może jednak nadal prowadzić do nieoczekiwanych konsekwencji.

W tym miejscu użyteczne staje się stwierdzenie „istotność nie oznacza uprawnienia”. Informacja może poprawić odpowiedź modelu, nie będąc jednocześnie właściwą dla danej decyzji.

Wyszukiwarki i Google News zwykle premiują proste kategorie, takie jak shadow AI, agenci AI i wycieki danych. Shady AI nie wpisuje się jednoznacznie w żadną z nich.

Obejmuje zarządzanie dostępem, prywatność, zachowanie modeli, zarządzanie danymi i projektowanie procesów biznesowych. To nakładanie się obszarów utrudnia przypisanie odpowiedzialności i sprzyja przeoczeniom.

Organizacją znajdującą się pod presją nie jest więc wyłącznie centrum operacji bezpieczeństwa. Dyrektorzy ds. bezpieczeństwa informacji, liderzy ds. prywatności, zespoły prawne, właściciele danych i menedżerowie aplikacji wszyscy przejmują część tego problemu.

Potrzebują jednego egzekwowalnego obrazu dozwolonego zachowania. Bez niego każdy zespół może sądzić, że za ryzyko odpowiada inna grupa.

Najtrudniejsze jest przekształcenie polityki w decyzje podejmowane w czasie działania systemu

Wiarygodna odpowiedź musi egzekwować kontekst podczas pobierania danych i wykonywania działań, a nie jedynie publikować kolejną politykę dopuszczalnego użycia.

Wiele organizacji rozpoczęło zarządzanie AI od list. Jedna wymienia zatwierdzone narzędzia. Druga wskazuje dane zakazane. Trzecia przypisuje właścicieli aplikacji i daty przeglądów.

Takie rejestry są niezbędne, zwłaszcza do wykrywania shadow AI. Nie rozwiązują jednak w pełni problemu zatwierdzonego systemu, który tworzy nieodpowiedni wynik na podstawie dozwolonych zasobów.

Shady AI wymaga kontroli bliższych momentowi działania systemu. Oznacza to chwilę, w której AI otrzymuje żądanie, pobiera informacje, generuje wynik lub wywołuje połączone narzędzie.

W tym momencie system ma więcej kontekstu niż statyczny proces zatwierdzania. Zna użytkownika, żądanie, wybrane dane, zamierzone miejsce docelowe i proponowane działanie.

Warstwa zarządzania może ocenić te czynniki, zanim pozwoli na kontynuowanie przepływu pracy. Może odmówić dostępu, usunąć wrażliwy kontekst, zażądać zatwierdzenia lub ograniczyć dostępne działanie.

Polityka musi być wystarczająco konkretna, aby dało się ją egzekwować. „Chroń zaufanie klientów” to ważna zasada, lecz oprogramowanie potrzebuje bardziej precyzyjnej reguły.

Jedna reguła może zabraniać asystentowi wykorzystywania rozmów z pomocą techniczną do ustalania rabatów. Inna może ograniczać podsumowywanie informacji medycznych pracowników poza autoryzowanym procesem obsługi świadczeń.

Organizacje potrzebują również informacji o pochodzeniu danych, które rejestrują, skąd odpowiedź AI uzyskała informacje. Pomaga to osobom dokonującym przeglądu zrozumieć, które źródła wpłynęły na odpowiedź lub działanie.

Rejestrowanie wyłącznie końcowego promptu i odpowiedzi nie wystarcza w wielu agentowych przepływach pracy. Osoby badające incydent mogą potrzebować pobranych dokumentów, wywołań narzędzi, ocen polityk, wersji modelu i historii zatwierdzeń.

Taki zapis wspiera audyty i reakcję na incydenty. Może też ujawnić reguły polityk, które blokują nieszkodliwą pracę albo dopuszczają ryzykowne kombinacje.

Testowanie musi odzwierciedlać rzeczywiste relacje biznesowe. Ogólne benchmarki modeli nie są w stanie określić, czy konkretna wiadomość klienta powinna znaleźć się w rekomendacji dotyczącej odnowienia umowy.

Zespoły powinny budować scenariusze wokół własnych danych, ról, przepływów pracy i zakazanych rezultatów. Testy powinny obejmować zarówno złośliwe prompty, jak i zwykłe żądania o niejednoznacznym celu.

Zatwierdzenie przez człowieka może ograniczyć ryzyko w przypadku działań o dużym wpływie. Jest najbardziej użyteczne, gdy osoba oceniająca otrzymuje istotny kontekst i zrozumiały powód alertu.

Przycisk oznaczony „zatwierdź” niewiele daje, jeśli osoba oceniająca nie widzi, które wrażliwe źródła ukształtowały działanie. Zmęczenie zatwierdzaniem może również przekształcić formalną kontrolę w automatyczne kliknięcie.

Organizacje powinny zatem rezerwować ocenę człowieka dla istotnych granic. Przepływy pracy o niższym ryzyku mogą wykorzystywać automatyczne ograniczenia, próbkowanie i monitorowanie retrospektywne.

Minimalizacja danych to kolejna praktyczna kontrola. Asystent powinien otrzymywać wyłącznie informacje wymagane do bieżącego zadania, nawet jeśli jego konto usługi może dotrzeć do większej liczby danych.

Systemy pobierania danych mogą egzekwować to ograniczenie, zanim treść trafi do kontekstu modelu. Bramy narzędziowe mogą podobnie ograniczać operacje, które agent może wykonać.

Dla pracowników wiedzy lokalny kontekst może ograniczyć niepotrzebne transfery do szeroko dostępnych usług zewnętrznych. Dobrze zaprojektowana osobista baza wiedzy może zachować wyraźniejsze granice między informacjami osobistymi a wspólnymi informacjami organizacyjnymi.

Sama architektura nie gwarantuje jednak właściwego użycia. Przetwarzanie lokalne może ograniczyć ekspozycję, a jednocześnie nadal prowadzić do niesprawiedliwego, naruszającego prywatność lub nieautoryzowanego wnioskowania.

To ważny sceptyczny punkt. Dostawcy rozwiązań bezpieczeństwa mogą przedstawiać egzekwowanie kontekstu jako pełną odpowiedź, lecz interpretacja polityk pozostaje trudna.

Język naturalny jest niejednoznaczny. Relacje biznesowe się zmieniają. Reguła działająca w jednym dziale może utrudniać pracę innemu zespołowi lub nie wykryć subtelnego nadużycia.

Fałszywie pozytywne wyniki mogą skłaniać pracowników do obchodzenia zasad. Fałszywie negatywne wyniki mogą tworzyć nieuzasadnioną pewność co do zautomatyzowanej warstwy zarządzania.

Zachowanie modelu zmienia się także po aktualizacjach. Prompt, strategia pobierania danych lub test polityki, które działały z jedną wersją, mogą zachowywać się inaczej z kolejną.

Organizacje powinny traktować kontrole kontekstowe jako element programu warstwowego. Tożsamość, zasada najmniejszych uprawnień, klasyfikacja danych, filtrowanie pobierania, ograniczenia narzędzi, ocena i nadzór człowieka pozostają niezbędne.

Żadna pojedyncza kontrola nie potwierdza, że każdy wynik jest właściwy. Celem jest uczynienie naruszeń polityk widocznymi, testowalnymi i trudniejszymi do wykonania z prędkością maszyny.

Trzy sygnały pokażą, czy Shady AI stanie się rzeczywistą kategorią bezpieczeństwa

Shady AI będzie miało znaczenie tylko wtedy, gdy organizacje będą mogły je mierzyć, egzekwować znaczące kontrole i łączyć niepowodzenia z rozliczalnymi właścicielami.

Pierwszym sygnałem będzie to, czy główne ramy bezpieczeństwa rozróżnią niewłaściwe autoryzowane użycie od zwykłego nieautoryzowanego AI. NIST, OWASP i grupy branżowe już zajmują się powiązanymi elementami.

Prompt injection obejmuje zmanipulowane zachowanie modelu. Nadmierna sprawczość obejmuje niebezpieczną autonomię. Shadow AI obejmuje nieznane lub niezatwierdzone systemy.

Żadna z tych etykiet nie opisuje idealnie zatwierdzonego systemu podejmującego bez udziału atakującego decyzję niedopuszczalną w danym kontekście. Jaśniejsza taksonomia pomogłaby zespołom spójnie raportować incydenty.

Warto obserwować nowe wytyczne ram, które dotyczą celu, relacji i wnioskowania. Takie wytyczne wzmocniłyby argument Cohena, że konwencjonalne kontrole dostępu pozostawiają istotną lukę.

Ocena ta osłabłaby, gdyby istniejące kategorie już obejmowały te incydenty bez niejasności operacyjnych. Nowa terminologia ma niewielką wartość, gdy jedynie zmienia nazwę utrwalonych rodzajów awarii.

Drugim sygnałem będzie pojawienie się mierzalnych kontroli działania systemu. Dostawcy będą obiecywać zarządzanie kontekstowe, lecz nabywcy powinni szukać dowodów wykraczających poza pulpity polityk.

Przydatne dowody obejmują egzekwowalne ograniczenia celu, dzienniki decyzji, kontrole na poziomie pobierania danych, zatwierdzanie wywołań narzędzi oraz powtarzalne testy. Produkty powinny również wyjaśniać, dlaczego polityka zezwoliła na działanie lub go odmówiła.

Niezależne oceny byłyby szczególnie wartościowe. Dostawca nie powinien być jedyną stroną definiującą ryzyko, mierzącą własny produkt i ogłaszającą skuteczność kontroli.

Nabywcy powinni testować realistyczne scenariusze przed szerokim wdrożeniem. Powinni pytać, czy system zatrzymuje niewłaściwe kombinacje danych, a nie tylko znane złośliwe prompty.

Powinni także badać tryby awarii. Kontrola, która zbyt często blokuje legalne przepływy pracy, straci poparcie, nawet jeśli jej logika bezpieczeństwa wydaje się poprawna.

Trzecim sygnałem jest odpowiedzialność organizacyjna. Shady AI przekracza zakres odpowiedzialności za bezpieczeństwo, prywatność, kwestie prawne, dane i produkt.

Komitet ds. zarządzania może koordynować te zespoły, ale komitety często tworzą wytyczne bez odpowiedzialności operacyjnej. Każdy wdrożony system nadal potrzebuje osoby odpowiedzialnej za decyzje.

Taki właściciel powinien zatwierdzać zamierzone cele, akceptowalne relacje między danymi, zakazane rezultaty i zasady eskalacji. Zespoły bezpieczeństwa mogą następnie przełożyć te decyzje na kontrole techniczne i testy.

Raportowanie incydentów pokaże, czy ten model działa. Organizacje powinny umieć rozróżnić nieznane narzędzie, przejętego agenta, awarię uprawnień i niewłaściwe autoryzowane działanie.

Kategorie te prowadzą do różnych środków zaradczych. Zablokowanie domeny może rozwiązać problem niezatwierdzonego chatbota, ale nie może zarządzać zatwierdzonym modelem już osadzonym w aplikacji biznesowej.

Obecność w Google News przyciągnie więcej uwagi do shady AI, lecz sama uwaga nie ustanowi tego terminu. Dowody z wdrożonych systemów muszą wykazać powtarzającą się awarię, którą istniejące kontrole konsekwentnie pomijają.

Liderzy bezpieczeństwa powinni zacząć od wąskiego spisu zatwierdzonych przepływów pracy AI, które dotyczą wrażliwych danych lub decyzji o istotnych konsekwencjach. Dla każdego przepływu powinni zadać cztery pytania.

Jakie informacje system może pobierać? Jakie cele uzasadniają to pobieranie? Jakie działania może podejmować? Kto może wyjaśnić i zatrzymać niewłaściwy wynik?

Jeśli te pytania prowadzą do niejasnych odpowiedzi, luka w zarządzaniu już istnieje. Zespoły nie muszą czekać na naruszenie, regulację ani nową kategorię produktu, aby ją zbadać.

Praktycznym kolejnym krokiem jest wybranie jednego przepływu pracy o dużym wpływie i prześledzenie go od żądania do rezultatu. Należy zarejestrować tożsamości, pobrane dane, polityki, decyzje modelu, wywołania narzędzi i zatwierdzenia przez ludzi.

Następnie należy przetestować żądania, które są technicznie dozwolone, lecz nieprawidłowe w danym kontekście. To ćwiczenie pokaże, czy „zatwierdzone” rzeczywiście oznacza zarządzane, czy jedynie połączone i obdarzone zaufaniem.