Wytyczne Ivanti dotyczące bezpieczeństwa AI skróciły pracę o godziny, ale jego umiejętność Claude wymyślała szczegóły

Ivanti ujawniło, że jego oparta na Claude umiejętność do analizy poprawek wymyślała szczegóły, mimo że skróciła powtarzalny proces z godzin do minut. System wytycznych Ivanti dotyczących bezpieczeństwa AI mylił edycje Microsoft Office i wielokrotnie błędnie interpretował cykl wydawniczy Adobe podczas prac rozwojowych.

To przyznanie się ma znaczenie, ponieważ wyniki pomagają zespołom bezpieczeństwa ustalać priorytety podatności po comiesięcznym Patch Tuesday firmy Microsoft. Wiarygodnie brzmiąca konfabulacja może zniekształcić decyzję o tym, które systemy otrzymają uwagę w pierwszej kolejności, nawet jeśli każda cytowana podatność jest prawdziwa.

Ivanti odpowiedziało, wprowadzając bramkę zatwierdzaną przez człowieka, i publicznie wskazało rolę Claude’a na wykresie z czerwca. CrowdStrike i Palo Alto Networks również angażują ludzi w istotną automatyzację bezpieczeństwa, lecz żadna z firm nie opisała publicznie wykrycia porównywalnej konfabulacji.

Ta historia jest zatem większa niż błędy jednego modelu. To sprawdzian tego, czy dostawcy ujawnią, jak AI kształtuje wytyczne operacyjne, co ich recenzenci rzeczywiście weryfikują oraz które błędy pozostają niewidoczne.

Wytyczne Ivanti dotyczące bezpieczeństwa AI trafiły do produkcji po miesiącach poprawek

Ivanti wdrożyło swoją umiejętność Claude do produkcji dopiero wtedy, gdy jego programiści wielokrotnie wychwycili sfabrykowane lub połączone błędnie szczegóły podczas szkolenia.

Chris Goettl, wiceprezes Ivanti ds. zarządzania produktami w obszarze bezpieczeństwa endpointów, zbudował tę umiejętność wokół procesu, który wykonywał ręcznie przez około dekadę. Pobiera ona opublikowane biuletyny dostawców i własne arkusze kalkulacyjne Ivanti, a następnie stosuje metodę firmy dotyczącą priorytetyzacji ryzyka zagrożeń.

Umiejętność w tym kontekście to zestaw instrukcji, źródeł i zasad przepływu pracy wielokrotnego użytku, przekazywanych modelowi AI. Nie oznacza to, że model samodzielnie rozumie system ujawniania informacji każdego dostawcy.

Goettl szkolił system, pracując kolejno z każdym dostawcą. Microsoft był pierwszy, ponieważ jego arkusze do pobrania zapewniały stosunkowo ustrukturyzowane dane wejściowe. Adobe wymagało innego podejścia, gdyż model musiał interpretować pojedyncze strony i ich zmieniające się układy.

Ta różnica ujawniła istotną słabość. Umiejętność wielokrotnie podawała niewłaściwy cykl wydań Adobe. Łączyła też ze sobą edycje Microsoft Office, które Microsoft rozdziela na kilka rodzin produktów.

Nie były to błędy stylistyczne. Cykl wydań i tożsamość produktu wpływają na sposób, w jaki analitycy interpretują nietypową aktywność, dotknięte oprogramowanie i pilność instalacji poprawek. Dopracowane podsumowanie z niewłaściwym wzorcem nadal może skierować zespół w złym kierunku.

Goettl opisał konfrontację z systemem, gdy odpowiedź wydawała się wyraźnie niepoparta źródłami. Według jego relacji w pipeline wspomaganym przez AI Claude przyznał, że wymyślony materiał nie miał podstawy, do której można było się odwołać.

Ivanti twierdzi, że umiejętność korzysta wyłącznie z publicznych biuletynów dostawców i arkuszy kalkulacyjnych kontrolowanych przez firmę. Nie przetwarza danych klientów, a każdy wygenerowany wynik pozostaje szkicem, dopóki nie zatwierdzi go człowiek.

Starszy menedżer produktu Todd Schell odtworzył działanie systemu na dwóch miesiącach briefingów wcześniej przygotowanych ręcznie. Ivanti zgłosiło 98-procentową zgodność, jednocześnie przyznając, że pozostały przypadki brzegowe.

Ta wartość wymaga ostrożnej interpretacji. VentureBeat nie przeprowadził niezależnego audytu danych źródłowych, metody punktacji, taksonomii błędów ani wyników odtworzenia. Zgodność nie dowodzi również, że każda istotna podatność pojawiła się w wygenerowanym wyniku.

Pierwsze uruchomienie produkcyjne miało miejsce w sierpniu 2026 roku, gdy Goettl był na urlopie. Arkusz kalkulacyjny, który wcześniej wymagał około czterech godzin pracy od każdego z dwóch pracowników, miał zostać przetworzony w mniej niż 30 minut.

Szerszy miesięczny proces pochłaniał łącznie około 48 godzin wokół każdego Patch Tuesday. Ivanti oszacowało, że wysiłek ten stanowił co najmniej 5 procent łącznego czasu pracy Goettla i Schella.

Korzyść operacyjna jest łatwa do zrozumienia. Maszyna może zbierać, normalizować i sortować duże wydanie szybciej, niż dwóch specjalistów może ręcznie kopiować pola między arkuszami kalkulacyjnymi.

Ivanti nie usunęło jednak specjalisty z procesu. Firma zmieniła jego zadanie z tworzenia każdego wiersza na przeglądanie szkicu stworzonego przez maszynę.

To rozróżnienie definiuje centralny konflikt. Automatyzacja oszczędza czas, ograniczając ręczne przygotowywanie materiału, podczas gdy wiarygodne wytyczne bezpieczeństwa nadal zależą od ludzkiego osądu i weryfikacji na poziomie źródeł.

Ivanti pozostawiło również widoczne ujawnienie informacji, zanim pojawiła się szersza historia. Wpis June Patch Tuesday wskazywał, że wykres został wygenerowany z użyciem Claude’a, na podstawie promptów zaprojektowanych przez autora i zbioru danych Goettla.

Żadne przepisy nie wymagały takiego podpisu. Żaden powszechny standard branżowy nie narzucał jego brzmienia. Ujawnienie pozostawało publicznie dostępne przez około trzy miesiące, zanim spotkało się z szerszą analizą.

Ten dyskretny podpis zyskał znaczenie, gdy znane stały się błędy rozwojowe. Połączył artefakt wygenerowany przez AI z nazwanym modelem, ludzkim autorem, datą i określonym zbiorem danych.

To większa przejrzystość niż ogólna etykieta „wspomagane przez AI”. Nadal nie ujawnia jednak, które wiersze sprawdzono, jak mierzono kompletność ani czy opublikowane poziomy ryzyka otrzymały niezależną walidację.

Problem danych Patch Tuesday sprawił, że automatyzacja stała się atrakcyjna

Bezpośrednia presja wynikała z procesu Patch Tuesday, który stał się większy, mniej ustandaryzowany i bardziej zależny od interpretacji każdego dostawcy.

8 września 2026 roku Microsoft opublikował to, co kilku badaczy bezpieczeństwa opisało jako jego największy Patch Tuesday. Mimo to opublikowane sumy znacząco różniły się między organizacjami analizującymi to samo wydanie.

Tenable naliczył 964 podatności, w tym 104 ocenione jako krytyczne i 860 jako ważne. Jego analiza wrześniowa wskazała również dwie podatności wykorzystywane w rzeczywistych atakach, zanim poprawki stały się dostępne.

Ivanti naliczyło 973. Senserva naliczyła 1 169, ponieważ mapowała podatności względem artykułów bazy wiedzy, zamiast stosować tę samą metodę skoncentrowaną na biuletynach co inni trackerzy.

Różnica między sumami Tenable i Senserva wyniosła 205 podatności. Ta luka przekroczyła poprzedni rekord Patch Tuesday przywoływany przez Ivanti, który wynosił 175 podatności w październiku 2025 roku.

Różnice te nie dowodzą, że model AI popełnił błąd. Mogą wynikać z uzasadnionych decyzji dotyczących zakresu, zduplikowanych wpisów, wariantów produktów, granic biuletynów i mapowań bazy wiedzy.

Pokazują jednak, dlaczego pojedynczej miesięcznej sumy nie można traktować jako neutralnego faktu. Każda opublikowana liczba odzwierciedla obecnie metodę parsowania i definicję tego, co należy do zbioru.

Microsoft pogłębił ten problem, gdy przestał prezentować jedną skonsolidowaną miesięczną listę CVE w swoim Security Update Guide. Rapid7 udokumentował tę zmianę podczas przygotowywania swojego lipcowego przeglądu poprawek.

Każdy dostawca zabezpieczeń musi teraz odtworzyć wydanie na podstawie dostępnych danych Microsoftu. Taka rekonstrukcja może obejmować deterministyczny kod, analizę ręczną, model AI lub połączenie wszystkich trzech.

Deterministyczny parser stosuje wyraźne reguły i daje ten sam wynik przy identycznych danych wejściowych. Duży model językowy może bardziej elastycznie interpretować niespójne strony, ale może również generować niepoparte powiązania.

Ten kompromis nabiera szczególnego znaczenia, gdy wynik nie jest jedynie liczbą. Zespoły bezpieczeństwa potrzebują priorytetyzacji opartej na aktywnym wykorzystywaniu, publicznym ujawnieniu, wadze problemu, ekspozycji aktywów i znaczeniu biznesowym.

Nieprawidłowa liczba może wprowadzić zamieszanie w raportowaniu. Nieprawidłowy priorytet może odciągnąć ograniczone zasoby na instalowanie poprawek od zagrożenia, które atakujący już wykorzystują.

Briefing webinarowy Ivanti ma podobno docierać każdego miesiąca do 500–700 uczestników. Uczestnicy ci niekoniecznie kopiują każde zalecenie bezpośrednio do środowiska produkcyjnego, ale skala odbiorców nadaje każdej decyzji priorytetyzacyjnej istotny zasięg.

Presja czasu jest również realna. Zespoły bezpieczeństwa nie mogą spokojnie analizować niemal tysiąca wpisów, zanim zaczną działać atakujący.

CrowdStrike podał, że 88 procent zaobserwowanego wykorzystywania podatności z udziałem publicznego proof of concept rozpoczęło się w ciągu 48 godzin. Proof of concept to publicznie dostępny kod lub dokumentacja techniczna pokazująca, w jaki sposób można wykorzystać podatność.

Wymogi federalne mogą być jeszcze bardziej rygorystyczne. Binding Operational Directive 26-04 CISA ustanowiła trzydniowy termin usunięcia podatności o najwyższym ryzyku w federalnych agencjach cywilnych.

W takich warunkach dostawcy mają silną motywację do automatyzowania gromadzenia danych i wstępnej klasyfikacji. Czekanie na doskonały ręczny przegląd samo w sobie może tworzyć ryzyko.

Problem nie polega na tym, czy organizacje powinny używać AI. Polega na tym, czy potrafią udowodnić, że przyspieszenie nie pominęło krytycznych podatności, nie zniekształciło mapowań produktów ani nie podniosło rangi słabych sygnałów.

Doświadczenie Ivanti pokazuje, dlaczego taki dowód nie może wynikać z płynności językowej. Niepoprawny wynik modelu wyglądał wystarczająco przekonująco, by wymagać rozpoznania przez eksperta i bezpośredniej konfrontacji.

Kupujący rozwiązania bezpieczeństwa są więc pod presją z obu stron. Potrzebują szybszych wytycznych, ale nie mogą zakładać, że szybszy, dobrze napisany briefing zawiera kompletny lub prawidłowo uszeregowany zestaw.

Prawdziwą zmianą jest ujawnienie informacji, nie konfabulacja

Zaskakujące nie jest to, że Claude wymyślał szczegóły; zaskakujące jest to, że Ivanti opisało te błędy i zachowało widoczną bramkę z udziałem człowieka.

Duże modele językowe generują tekst, przewidując prawdopodobne sekwencje na podstawie szkolenia i dostarczonego kontekstu. Nie gwarantują z natury, że każde stwierdzenie jest powiązane z przekazanym źródłem.

Konfabulacja, często nazywana halucynacją, występuje wtedy, gdy model przedstawia niepoparte informacje tak, jakby były ugruntowane w źródłach. W tym przepływie pracy błąd przejawiał się jako niepoprawne wzorce dostawców i połączone ze sobą rodziny oprogramowania.

Te słabości są już znane w systemach AI ogólnego przeznaczenia. Stawkę zmienia ich umieszczenie w potoku tworzącym zalecenia dotyczące bezpieczeństwa.

Błąd konsumenckiego chatbota może zmarnować czas czytelnika. Brakujący wiersz podatności w wytycznych operacyjnych może opóźnić usunięcie problemu w narażonym systemie.

Ujawnienie Ivanti nie wyeliminowało tego ryzyka. Uczyniło je możliwym do zbadania.

Firma przypisała nazwę modelu i ludzką odpowiedzialność co najmniej jednej opublikowanej grafice. Goettl wyjaśnił również, jakie problemy pojawiły się podczas szkolenia i dlaczego bramka przeglądu pozostała konieczna.

Ten poziom szczegółowości pomaga klientom zadawać lepsze pytania. Mogą odróżnić zbieranie danych wspomagane przez model od autonomicznej priorytetyzacji oraz zapytać, który etap otrzymuje ludzką weryfikację.

To przyznanie się komplikuje również konwencjonalne komunikaty dotyczące zaufania. Dostawcy zwykle podkreślają wzrost dokładności, szybkość przetwarzania lub produktywność analityków, gdy ogłaszają funkcje AI.

Błędy rozwojowe rzadko otrzymują równie dużo uwagi. Ta nierównowaga zachęca kupujących do oceniania przepływu pracy na podstawie jego najlepszego benchmarku, a nie znanych trybów awarii.

Zgłoszona przez Ivanti 98-procentowa zgodność ilustruje zagrożenie. Liczba brzmi uspokajająco, ale jej praktyczne znaczenie zależy od tego, co znalazło się w pozostałej różnicy.

Nieistotna rozbieżność formatowania i pominięta aktywnie wykorzystywana podatność nie powinny mieć takiej samej wagi. Użyteczna ocena musi klasyfikować błędy według ich konsekwencji operacyjnych.

Kompletność zasługuje na odrębne omówienie niż poprawność. Recenzent może wykryć błędną wagę problemu lub wadliwy opis w widocznym wierszu, ale niełatwo zauważy brakujący wiersz.

To najpoważniejsze wyzwanie dla narracji o kontroli człowieka. Czytanie wygenerowanego wyniku nie jest tym samym co uzgadnianie go z wiarygodnym wykazem źródeł.

Kayne McGladrey, niezależny wirtualny dyrektor ds. bezpieczeństwa informacji i starszy członek IEEE, argumentował, że klienci potrzebują pisemnego opisu procesu. Stwierdził, że dostawcy powinni wyjaśniać, gdzie działa model, jak analizowane są CVE, kto sprawdza wyniki i jaka ich część przechodzi weryfikację źródłową.

Jego krytyka wykraczała poza żądanie ludzkiego podpisu. Porównanie z poprzednimi miesiącami opracowanymi przez ludzi może mierzyć podobieństwo, nie dowodząc jednak poprawności w bieżącym miesiącu.

Ludzki recenzent może również dzielić martwy punkt modelu. Jeśli obaj skupiają się na widocznych wpisach, żaden nie odkryje elementu, który zniknął, zanim rozpoczął się przegląd.

Właściwym standardem jest zatem śledzalność. Każda opublikowana rekomendacja powinna być powiązana z autorytatywnym materiałem wejściowym, a każdy taki materiał powinien mieć odnotowane rozstrzygnięcie.

Ten drugi kierunek ma największe znaczenie. Zmienia przegląd z pytania „Czy ten szkic wygląda rozsądnie?” w pytanie „Czy można rozliczyć każdy element źródłowy?”.

To właśnie tutaj zdyscyplinowane łączenie wiedzy staje się istotne poza samym zarządzaniem poprawkami. Łączenie źródeł jest użyteczne tylko wtedy, gdy proces zachowuje pochodzenie informacji i ujawnia konflikty, zamiast je wygładzać.

Ujawnienie Ivanti stanowi punkt wyjścia, a nie gotowy standard. Informuje kupujących, że AI uczestniczyła w procesie oraz że znane konfabulacje wpłynęły na sposób prowadzenia kontroli.

Nie ustanawia jednak publicznie śledzenia pochodzenia na poziomie wiersza, niezależnego testowania poziomów ryzyka, wskaźników fałszywie ujemnych wyników ani odsetka materiału źródłowego uzgadnianego automatycznie.

Mimo to przyznanie się wywiera presję na konkurentów. Dostawca, który promuje wspomagane przez AI wskazówki bezpieczeństwa bez opisu łańcucha walidacji, przekazuje obecnie klientom mniej informacji niż Ivanti.

To odwrócenie jest niewygodne, lecz konstruktywne. Publiczne przyznanie modelowi błędów może stać się dowodem dojrzałości procesu, podczas gdy milczenie może skrywać zarówno znakomite mechanizmy kontroli, jak i ich całkowity brak.

Kontrola człowieka działa tylko wtedy, gdy może znaleźć brakujące dowody

Recenzent wnosi wartość tylko wtedy, gdy projekt kontroli jest ukierunkowany na pominięcia, niepoparte twierdzenia i błędy klasyfikacji o dużym wpływie.

Proces Ivanti utrzymuje człowieka między szkicem Claude’a a opublikowanym biuletynem. Jest to bezpieczniejsze niż pozwolenie modelowi na automatyczne publikowanie priorytetów.

Jednak „człowiek w pętli” to opis projektu, a nie miara jakości. Jego skuteczność zależy od tego, co dana osoba widzi, sprawdza i może zatrzymać.

Recenzent analizujący tekst może rozpoznać nietypowe sformułowania, znany produkt przypisany do niewłaściwej rodziny albo nieprawdopodobny schemat wydań. Wiedza Goettla najwyraźniej pozwoliła wychwycić te widoczne anomalie podczas szkolenia.

Trudniejszą awarią jest ciche wykluczenie. Jeśli parser lub model nigdy nie utworzy wiersza dla podatności, recenzent sprawdzający wyłącznie końcowy arkusz kalkulacyjny nie otrzyma oczywistego ostrzeżenia.

Silniejszy system wymaga mechanizmów uzgadniania poza modelem językowym. Deterministyczne kontrole mogą porównywać identyfikatory źródłowe, oznaczać niedopasowane rekordy, wykrywać zduplikowane CVE i liczyć oczekiwane elementy według dostawcy.

Model może następnie realizować zadania wymagające interpretacji. Może podsumowywać biuletyny, normalizować niespójne opisy lub proponować kategorie ryzyka do zatwierdzenia przez ekspertów.

Taki podział przypisuje maszynom różne obowiązki. Kod chroni kompletność i powtarzalność, podczas gdy model pomaga w pracy z niejednoznacznym językiem i kontekstem priorytetyzacji.

Tworzy on także wyraźniejsze sygnały awarii. Niezgodność w uzgodnieniu może wstrzymać publikację, nawet gdy wygenerowana narracja wygląda dopracowanie.

Walidacja poziomów ryzyka wymaga podobnej rygorystyczności. System powinien rejestrować, dlaczego dany element otrzymał określoną rangę, które fakty źródłowe wsparły tę decyzję oraz co zmieniło się po kontroli człowieka.

Bez takiego zapisu końcowe zatwierdzenie ustanawia odpowiedzialność, lecz dostarcza ograniczonych dowodów jakości. Nie może wykazać, czy recenzent zbadał każdą rekomendację, czy jedynie wybrał próbkę wierszy o najwyższym ryzyku.

Ivanti twierdzi, że sygnały dotyczące znanych exploitów, publicznych ujawnień i nietypowego wolumenu uruchamiają eskalację. To rozsądny zestaw reguł, lecz publiczne raportowanie nie weryfikuje niezależnie jego stosowania.

Błędy dotyczące Adobe i Office pokazują również, dlaczego testy specyficzne dla dostawcy mają znaczenie. Proces działający dobrze na arkuszach Microsoft może zawieść, gdy inny wydawca korzysta ze stron internetowych, odmiennych konwencji nazewnictwa lub nieregularnych harmonogramów wydań.

Ocena musi zatem obejmować każde źródło danych i każdy etap transformacji. Średnia łączona może ukryć słabe połączenie z jednym dostawcą pod silnymi wynikami Microsoft.

CrowdStrike opisał inny wzorzec kontroli podczas Fal.Con 2026. Jego podejście „human on the loop” ma podobno polegać na tym, że analityk równolegle z agentem obsługuje to samo wykrycie, a następnie porównuje werdykty.

Praca równoległa może ujawnić rozbieżności, których nie dostrzega przegląd sekwencyjny. Zachowuje też większy udział pracy człowieka niż proces, w którym jedna osoba sprawdza już ukończony szkic.

Palo Alto Networks wprowadziło Cortex XSIAM AgentiX w lutym 2026 roku, z gotowymi agentami i bramkami zatwierdzania dla działań o dużym wpływie. Jego agentowy projekt SOC podobnie zachowuje kontrolę człowieka tam, gdzie zautomatyzowane decyzje niosą poważniejsze konsekwencje.

Żaden z tych projektów nie rozwiązuje automatycznie problemu brakujących danych wejściowych. Człowiek i agent mogą obaj rozumować na podstawie niepełnego źródła, a bramka zatwierdzania może autoryzować działanie na podstawie błędnych dowodów.

Porównanie ujawnia jednak kształtujący się konsensus. Główni dostawcy nie traktują nieograniczonej autonomii jako akceptowalnego domyślnego rozwiązania dla operacji bezpieczeństwa o dużym wpływie.

Ten konsensus ma znaczenie, ponieważ język branżowy często zaciera różnicę między wsparciem a autonomią. System tworzący szkic biuletynu istotnie różni się od systemu wdrażającego poprawkę, izolującego urządzenie lub zamykającego incydent.

Kupujący powinni przypisać każdemu działaniu AI jego odwracalność i potencjalną szkodę. Podsumowania o niskim wpływie mogą tolerować lżejsze mechanizmy kontroli niż decyzje zmieniające systemy produkcyjne.

Powinni również żądać dowodów z rzeczywistych przypadków awarii. Test porównawczy raportujący wyłącznie zgodność ukrywa, czy błędy dotyczyły sformułowań, zakresu, wagi problemu czy pominięć.

Znane przypadki konfabulacji wykryte przez Ivanti dostarczają bardziej użytecznych informacji niż samo twierdzenie o dokładności. Wskazują konkretne warunki, w których system stał się niewiarygodny.

Nierozstrzygnięte pozostaje pytanie, czy kontrole produkcyjne wykrywają nowe tryby awarii, a nie tylko te odkryte podczas szkolenia. Strony dostawców się zmieniają, taksonomie ewoluują, a nietypowe wydania mogą unieważnić wczorajsze założenia dotyczące parsowania.

Kontrola człowieka pozostaje konieczna, ale powinna działać w ramach mierzalnego systemu kontroli. W przeciwnym razie to sformułowanie może stać się uspokojeniem bez wykazania, że najgroźniejsze błędy są wykrywalne.

Przyznanie się Ivanti podnosi standard dla każdego dostawcy zabezpieczeń

Dostawcy zabezpieczeń stają obecnie pod presją, by ujawniać nie tylko to, że używają AI, lecz dokładnie to, jak AI wpływa na priorytety przedstawiane klientom.

Ivanti nie jest jedyną firmą automatyzującą analizę bezpieczeństwa. CrowdStrike, Palo Alto Networks i inni dostawcy wdrażają modele oraz agentów do procesów wykrywania, badania, triage’u i reagowania.

Różnicą konkurencyjną ujawnioną tutaj jest przejrzystość. Ivanti wskazało model, opisało dane wejściowe, zidentyfikowało znane wzorce konfabulacji i wyjaśniło, że publikacja wymaga zatwierdzenia przez człowieka.

VentureBeat poinformował, że nie znalazł porównywalnego publicznego ujawnienia konfabulacji ze strony CrowdStrike ani Palo Alto Networks. Ten brak nie dowodzi, że ich systemy zawiodły ani że ich mechanizmy kontroli są słabsze.

Oznacza to, że klienci nie mają porównywalnych informacji. Jeden dostawca ujawnił część historii swoich błędów, podczas gdy inni opisują głównie architekturę i zabezpieczenia.

Publiczne ujawnianie tworzy trudny problem bodźców. Firma zgłaszająca błędy może wyglądać na mniej niezawodną niż konkurent publikujący wyłącznie udane oceny.

Zakupy rozwiązań bezpieczeństwa mogą odwrócić ten bodziec, nagradzając dowody. Kupujący mogą zadawać każdemu dostawcy te same pytania i traktować brak odpowiedzi jako nierozwiązaną lukę w kontroli.

Po pierwsze, klienci powinni pytać, które artefakty są generowane przez AI. Odpowiedź powinna rozróżniać gromadzenie danych, parsowanie, podsumowywanie, ocenę punktową, rekomendacje i zautomatyzowane działanie.

Po drugie, powinni pytać, jak weryfikowana jest kompletność. Prawidłowa odpowiedź powinna uwzględniać brakujące wiersze, zduplikowane rekordy, zmiany źródeł i nieudane pobieranie danych.

Po trzecie, powinni pytać, kto sprawdza wynik i co obejmuje ten przegląd. Wskazana rola zatwierdzająca jest przydatna, ale udokumentowana lista kontrolna i ścieżka audytu zapewniają silniejsze gwarancje.

Po czwarte, powinni żądać kategorii błędów zamiast jednego wskaźnika dokładności. Kupujący muszą wiedzieć, czy awarie wpływają na gramatykę, przypisanie produktu, status exploita, wagę problemu czy uwzględnienie.

Te wymagania są proporcjonalne do stawki decyzji. Zespoły odpowiedzialne za poprawki korzystają z priorytetyzacji, ponieważ nie mogą jednocześnie usunąć każdego problemu.

Wrześniowe wydanie pokazuje skalę tego problemu. Tenable zidentyfikowało 964 CVE, Ivanti 973, a Senserva 1 169 przy zastosowaniu innego podejścia do liczenia.

Kupujący nie musi koniecznie oczekiwać, że każdy dostawca poda identyczną liczbę. Musi jednak wymagać, aby każdy dostawca wyjaśnił swój zakres i uzgodnił swoje rekomendacje z tym zakresem.

Ta sama logika dotyczy poziomów ryzyka. Dostawcy mogą zasadnie różnie ważyć możliwość wykorzystania, ekspozycję i kontekst biznesowy, lecz te oceny powinny pozostać śledzalne.

Przejrzystość chroni także dostawców przed niesprawiedliwymi porównaniami. Udokumentowana metodologia może wykazać, że dwie sumy różnią się z powodu zdefiniowanego zakresu, a nie dlatego, że jeden system po cichu utracił dane.

Problem wykracza poza cyberbezpieczeństwo. Każdy raport badawczy, zgodności, finansowy lub operacyjny wygenerowany przez AI może zawierać wiarygodnie brzmiące pominięcia, których kontrola powierzchowna nie wykryje.

Bezpieczeństwo czyni ten problem wyjątkowo widocznym, ponieważ CVE mają identyfikatory i autorytatywne biuletyny. Ta struktura daje dostawcom praktyczny sposób testowania kompletności.

Organizacje pracujące z mniej ustrukturyzowanymi dowodami stoją przed trudniejszym zadaniem. Nadal potrzebują pochodzenia informacji, wykrywania konfliktów i wyraźnego traktowania brakującego materiału.

Podejście Ivanti jest zatem godne uwagi, choć niewystarczające. Jego ujawnienie mówi klientom więcej niż milczenie, podczas gdy zgłoszone mechanizmy kontroli nadal pozostawiają ważne pytania weryfikacyjne bez odpowiedzi.

Kontekst wcześniejszych problemów bezpieczeństwa firmy sprawia, że taka kontrola jest szczególnie istotna. Klienci oceniający wskazówki dotyczące poprawek będą oceniać nie tylko wydajność modelu, ale również zdolność Ivanti do precyzyjnego komunikowania ryzyka.

Ta kontrola powinna pozostać oparta na dowodach. Omawiana tutaj umiejętność Claude’a analizowała publiczne dane o poprawkach i według doniesień nie uzyskała dostępu do środowisk klientów.

Nie był to autonomiczny agent usuwający problemy. Tworzył szkice cyklicznego biuletynu, za którego publikację odpowiadała osoba.

Łączenie tych kategorii przesadnie wyolbrzymiałoby to zdarzenie. Bagatelizowanie konfabulacji, ponieważ „człowiek to sprawdził”, zaniżałoby skalę wyzwania kontrolnego.

Wyważony wniosek znajduje się między tymi skrajnościami. Ivanti stworzyło istotnie szybszy proces, wykryło rzeczywiste błędy modelu, ujawniło udział AI i zachowało ekspercką kontrolę.

Nie wykazało publicznie, że jego proces wykrywa każdą brakującą podatność ani że niezależnie waliduje każdą decyzję priorytetyzacyjną. To standard, którego klienci powinni teraz wymagać od Ivanti i jego konkurentów.

Trzy sygnały pokażą, czy wskazówki AI dotyczące poprawek zasłużą na zaufanie

Kolejnym testem będzie to, czy dostawcy przekształcą szeroki nadzór człowieka w widoczną, powtarzalną i kompletną pod względem źródeł walidację.

Pierwszy sygnał nadejdzie wraz z kolejnym Patch Tuesday, 13 października 2026 r. Analitycy powinni porównać opublikowane sumy, definicje zakresu, oznaczenia znanych exploitów oraz sposób traktowania nietypowych danych dostawców.

Jeśli materiały Ivanti pozostaną publikowane szybko, a jednocześnie będą wyraźnie uwzględniać rozbieżności między źródłami, wzmocni to argumenty za nadzorowaną automatyzacją. Niewyjaśnione pominięcie lub błąd mapowania osłabiłby te argumenty.

Drugi sygnał to bardziej szczegółowe ujawnienia ze strony Ivanti lub jego konkurentów. Przydatna dokumentacja wskazywałaby, gdzie działają modele, które deterministyczne mechanizmy kontrolne chronią kompletność oraz które decyzje wymagają zatwierdzenia przez człowieka.

Takie informacje wzmocniłyby argument, że przejrzystość może stać się standardem konkurencyjnym. Dalsze poleganie na ogólnikowych sformułowaniach typu „human in the loop” pozostawiłoby nierozwiązaną kluczową lukę w weryfikacji.

Trzeci sygnał to dowody pochodzące z ocen prowadzonych w środowisku produkcyjnym. Dostawcy powinni raportować kategorie błędów, pokrycie źródeł, korekty wprowadzane przez recenzentów oraz fałszywie negatywne wyniki o wysokim wpływie, bez ujawniania szczegółów klientów, które mogłyby zostać wykorzystane.

Takie dowody pokazałyby, czy systemy poprawiają się po zetknięciu z nowymi formatami i przypadkami brzegowymi. Sama zbiorcza zgodność nie odpowiedziałaby na to pytanie.

Raport CrowdStrike dotyczący szybkiego wykorzystywania luk wyjaśnia, dlaczego ta praca nie może całkowicie wrócić do ręcznego przetwarzania. Jego ustalenia dotyczące exploitacji pokazują, że obrońcy często działają w coraz krótszym oknie reakcji.

Właściwym celem nie jest zatem ograniczenie automatyzacji. Jest nim automatyzacja, której dowody można sprawdzić, zanim jej rekomendacje wpłyną na działania ludzi lub maszyn.

Dla liderów bezpieczeństwa praktyczną odpowiedzią jest sporządzenie inwentaryzacji każdego zewnętrznego źródła wytycznych wykorzystującego AI. Należy zapytać, czy model liczy, interpretuje, klasyfikuje czy działa, ponieważ każda z tych ról tworzy inną ścieżkę awarii.

Następnie warto sprawdzić deklarację dostawcy dotyczącą przeglądu, zadając jedno trudne pytanie: W jaki sposób proces wykryłby podatność, która nigdy nie pojawiła się w wygenerowanym szkicu?

Jeśli odpowiedź zależy od tego, że ktoś zauważy brakującą informację, mechanizm kontrolny jest niekompletny. Jeśli obejmuje uzgadnianie źródeł, obsługę wyjątków i rejestrowane decyzje podejmowane przez człowieka, przepływ pracy jest bardziej wiarygodny.

Wytyczne Ivanti dotyczące bezpieczeństwa AI stanowią obecnie publiczne studium przypadku dla tej dyskusji. Umiejętność Claude firmy Ivanti zaoszczędziła analitykom znaczną ilość czasu, generowała zmyślone szczegóły podczas prac rozwojowych i zmusiła firmę do zaprojektowania procesu z uwzględnieniem tych błędów.

To ujawnienie nie powinno automatycznie budzić zaufania, ale zasługuje na uwagę. Daje klientom konkretne słabości do zbadania, a konkurentom punkt odniesienia w zakresie przejrzystości, który mogą przewyższyć.

Przed poleganiem na kolejnym wspieranym przez AI briefingu bezpieczeństwa poproś o wskazanie roli modelu, kontroli kompletności źródeł oraz rzeczywistego zadania recenzenta. Odpowiedzi na te pytania powiedzą więcej niż jakikolwiek nagłówkowy wskaźnik dokładności.