Wdrożenie AI w taktycznym centrum operacyjnym przyspiesza szybciej niż ramy doktrynalne, które miałyby je regulować. Personel S3 i S6 na szczeblu brygady i batalionu odpowiada na pytania dowodzenia o to, które narzędzia AI są gotowe do wdrożenia, jednocześnie zarządzając ryzykiem, że system AI pewny swej błędnej odpowiedzi jest bardziej niebezpieczny niż brak jakiegokolwiek systemu AI. Niniejszy artykuł przedstawia pięć zweryfikowanych przypadków użycia, w których AI wyraźnie poprawia przepustowość TOC, wzorce integracji sprawdzające się w każdym z nich oraz tryby awarii ujawnione przez doświadczenie terenowe — w tym kilka, które pojawiają się wyłącznie w warunkach operacyjnych, a nie ćwiczebnych.
Podejście przez cały artykuł jest praktyczne. Nie brakuje briefingów dostawców zapewniających o transformacyjnym wpływie. Czego personel S3/S6 naprawdę potrzebuje, to jasna odpowiedź na pytania: co robi AI, co operator nadal musi robić, jak integruje się z tym, co już posiadamy, i co się psuje. Taka jest struktura, jaką artykuł stosuje dla każdego przypadku użycia.
Przypadek użycia 1: zarządzanie COP za pomocą języka naturalnego
Zarządzanie Common Operating Picture to najczęściej wykonywane ręczne zadanie w TOC. Umieszczanie markerów, aktualizacje śledzenia, tworzenie misji, subskrypcje kanałów — są one wykonywane dziesiątki razy na zmianę przez operatorów S2/S3 pracujących pod presją czasową i przy dużym obciążeniu poznawczym. Wkład AI nie polega tu na autonomicznym zarządzaniu COP, lecz na przyspieszeniu interfejsu: tłumaczeniu poleceń w języku naturalnym na sekwencje nawigacji po menu, które w przeciwnym razie wymagałyby czterech do siedmiu oddzielnych interakcji z interfejsem użytkownika na akcję.
Co robi AI. Interfejs oparty na LLM przyjmuje polecenia w stylu „umieść wrogi obserwacyjny punkt artyleryjski na 37T EK 44500 72300, znak wywoławczy ECHO-OP-1" i tłumaczy je na właściwe wywołanie TAK API — rozwiązując opis jednostki w języku naturalnym na odpowiedni ciąg znaków CoT MIL-STD-2525C, formatując współrzędne MGRS, wypełniając wszystkie wymagane pola i przesyłając marker do COP w ciągu dwóch do trzech sekund. Operator widzi kartę potwierdzenia pokazującą każde ustawione pole i status odpowiedzi API przed zatwierdzeniem markera.
Co operator nadal musi robić. Podawać dokładne siatki. AI nie może poprawić jakości współrzędnych — jeśli operator poda błędną siatkę, marker trafi w złe miejsce. Potwierdzać operacje destrukcyjne (usuwanie śladów, zamykanie misji) poprzez wyraźną bramkę zatwierdzenia. Monitorować kartę potwierdzenia, aby zweryfikować, czy model poprawnie rozwiązał niejednoznaczne opisy — „wrogi" jest jednoznaczny, ale „element wsparcia" może być interpretowany na wiele sposobów.
Podejście integracyjne. TAKpilot implementuje ten wzorzec jako interfejs czatu obok CloudTAK, wykorzystując wywołania funkcji LLM względem istniejącego HTTP API CloudTAK. Nie wymaga żadnych modyfikacji konfiguracji TAK Server i działa przez tę samą warstwę RBAC, która reguluje bezpośredni dostęp przez interfejs — operator nie może wykonać za pomocą AI żadnej akcji, której nie może wykonać ręcznie. Zapoznaj się z artykułem o kopilot AI dla aplikacji taktycznych, aby poznać pełną architekturę.
Czynniki ryzyka. Rozwiązywanie przez model niejednoznacznych opisów typów CoT może dawać błędne klasyfikacje MIL-STD-2525. Zawsze sprawdzaj, czy symbolika pokazana na karcie potwierdzenia odpowiada intencji operatora przed zatwierdzeniem. Nie polegaj na zarządzaniu COP przez AI podczas początkowego budowania COP, kiedy wolumen śladów jest wysoki i błędy mają maksymalny wpływ na dalsze działania — używaj go do bieżącej konserwacji i przyrostowych aktualizacji.
Przypadek użycia 2: przetwarzanie SITREP i ekstrakcja danych strukturalnych
Raporty sytuacyjne docierają do TOC w formatach, które nie zmieniły się od dziesięcioleci: wiadomości tekstowe przez radio lub aplikacje do przesyłania wiadomości, ręcznie wypełnione formularze sfotografowane telefonem, szablony PDF częściowo wypełnione przez element wysunięty z przerywaną łącznością. Ekstrakcja operacyjnie istotnych danych strukturalnych z tych raportów — referencje siatki, identyfikatory jednostek, status sprzętu, czas obserwacji — i zasilanie nimi COP to jeden z procesów ręcznych o najwyższym opóźnieniu w TOC. Ręczna integracja jednego złożonego SITREP może zająć cztery do ośmiu minut.
Co robi AI. Model zdolny do przetwarzania obrazu przetwarza obraz lub tekst SITREP i ekstrahuje encje jako strukturalny JSON: każdą referencję siatki wraz z opisaną jednostką lub obiektem, każdy znak wywoławczy, każdy wskaźnik statusu, każdą referencję czasową. Wynik jest prezentowany operatorowi jako lista potwierdzenia, zanim cokolwiek trafi na mapę — „Znaleziono 6 encji: 2 wrogie pozycje pojazdów, 1 przyjazny OP, 1 węzeł logistyczny, 1 linia fazowa, 1 strefa zakazu ognia. Oto proponowane rozmieszczenia." Operator przegląda i potwierdza w ciągu dziesięciu do piętnastu sekund. Łączny czas integracji dla SITREP z sześcioma encjami: poniżej dziewięćdziesięciu sekund, włącznie z przeglądem.
Co operator nadal musi robić. Przeglądać każdą wyekstrahowaną encję przed potwierdzeniem. Modele wizualne AI błędnie odczytują odręcznie napisane siatki — szczególnie pary cyfr wizualnie podobnych (1/7, 6/8, 3/8) — z częstotliwością, która jest operacyjnie niedopuszczalna, jeśli nie jest sprawdzana. Krok potwierdzenia nie jest opcjonalny. Dla encji wysokiej pewności (pewność ekstrakcji powyżej 0,90) przegląd jest szybki; dla oznaczonych encji niskiej pewności (poniżej 0,70) operator musi zweryfikować z dokumentem źródłowym przed potwierdzeniem.
Podejście integracyjne. SITREP-y w postaci obrazu przesyłane są przez interfejs czatu AI. SITREP-y tekstowe wklejane są bezpośrednio do czatu lub docierają przez integrację API z systemami przesyłania wiadomości. Potok ekstrakcji działa na modelu zdolnym do przetwarzania obrazu (model chmurowy dla HQ, model brzegowy dla pozycji wysuniętych), generuje strukturalny JSON i uruchamia ten sam łańcuch wywołań narzędzi COP co ręczne polecenia w języku naturalnym dla każdej potwierdzonej encji.
Kluczowy wniosek: Bramka potwierdzenia ekstrakcji SITREP to twarde wymaganie bezpieczeństwa, a nie wybór UX. Model wizualny, który błędnie odczytuje „37T EK 44500 72300" jako „37T EK 45500 72300", umieszcza kontakt 1 km od jego rzeczywistej pozycji. W scenariuszu wsparcia ogniowego taki błąd może być śmiertelny. Krok przeglądu przekształca potencjalnie błędne umieszczenie w wykryte i poprawione — jego koszt czasowy wynosi trzy sekundy na encję.
Przypadek użycia 3: sortowanie ISR i priorytyzacja zasilania czujników
TOC wspierające operacje na szczeblu brygady może jednocześnie odbierać zasilanie ze stałopłatowych platform ISR, śmigłowców, UAV, czujników naziemnych i raportów wywiadu ludzkiego. Żaden analityk nie jest w stanie przetworzyć ich wszystkich w szczytowym tempie. Efektem jest problem priorytyzacji: które zasilanie zawiera informacje najbardziej wrażliwe na czas, a które może poczekać bez wpływu na misję.
Co robi AI. Warstwa sortowania AI pobiera metadane z aktywnych zasilań czujników — pozycja platformy, obszar zainteresowania, historia kontaktów, czas, który upłynął od ostatniego znaczącego zdarzenia — i ocenia je pod kątem priorytetu za pomocą modelu wytrenowanego na organizacji zadań i bieżących parametrach operacyjnych. Oznacza zasilania wykazujące anomalne wzorce: nieoczekiwane sygnatury ruchu, obszar zainteresowania odchylający się od przypisanego sektora, przedłużone loitering sugerujące ślad kontaktu. Analityk widzi kolejkę zasilań z priorytetami wraz z widocznym rozumowaniem AI — „EAGLE-3 oznaczony: obszar zainteresowania przesunął się o 2,3 km na północny wschód od przypisanego sektora, czas trwania 14 minut" — a nie płaską listę aktywnych czujników.
Co operator nadal musi robić. Wszelka interpretacja oznaczonych zasilań pozostaje zadaniem analityka. AI oznacza anomalię; analityk określa, czy anomalia ma znaczenie taktyczne, czy odzwierciedla zmianę taskowań, która nie rozprzestrzeniła się do systemu sortowania, lub czy jest artefaktem czujnika. AI nie generuje oceny wywiadowczej — wskazuje, na co patrzeć w pierwszej kolejności.
Czynniki ryzyka. AI sortowania ISR wytrenowana na jednym kontekście operacyjnym może dawać słabą priorytyzację w innym. Jeśli organizacja zadań zmieni się, a parametry modelu nie zostaną zaktualizowane, ocena priorytetów degraduje się po cichu. Operatorzy powinni być poinformowani, aby traktować priorytyzację AI jako punkt wyjścia, a nie gwarancję, że zasilania zdepriorytetyzowane nic istotnego nie zawierają.
Przypadek użycia 4: widoczność logistyki i automatyczne śledzenie statusu
Oficerowie logistyki zarządzają statusem zaopatrzenia na podstawie raportów docierających przez radio, aplikacje do przesyłania wiadomości i e-mail w różnych formatach i nieregularnych odstępach czasu. Agregowanie bieżącego statusu paliwa, amunicji i wody we wszystkich podległych elementach wymaga ciągłego ręcznego uzgadniania. Wartość AI polega tu na automatyzacji warstwy ekstrakcji i agregacji, dzięki czemu S4 widzi aktualny obraz bez konieczności ręcznego aktualizowania arkusza kalkulacyjnego po każdym raporcie statusu.
Co robi AI. Raporty statusu logistycznego — niezależnie od tego, czy są to transkrypcje radiowe w wolnym tekście, sformatowane raporty statusu logistycznego (LOGSTAT) czy wiadomości z danymi strukturalnymi — są parsowane przez ten sam potok ekstrakcji, co SITREP-y. AI ekstrahuje towar, ilość, jednostkę i czas raportowania z każdej wiadomości i aktualizuje tablicę statusu logistycznego, która pokazuje bieżące zapasy, przewidywane niedobory na podstawie współczynnika zużycia oraz elementy, które nie złożyły raportu w wymaganym interwale raportowania.
Co operator nadal musi robić. Weryfikować anomalne wpisy statusu — raport pokazujący zerowe paliwo dla jednostki, która dwie godziny temu miała 60%, może odzwierciedlać zdarzenie zużycia, błąd raportowania lub awarię parsowania. Ustalać interwały raportowania i śledzić elementy nieraportujące; AI je oznacza, ale nie może wymusić raportu. Autoryzować wnioski o zaopatrzenie wymagające decyzji dowodzenia.
Podejście integracyjne. AI logistyki może działać jako samodzielny moduł pobierający raporty z istniejącej infrastruktury przesyłania wiadomości lub jako moduł w ramach szerszego systemu TOC wspomaganego przez AI, który współdzieli ten sam potok ekstrakcji co przetwarzanie SITREP. Struktury danych towarowych są wystarczająco standaryzowane, że jeden dobrze wytrenowany model ekstrakcji obsługuje większość operacyjnych formatów LOGSTAT bez konfiguracji per jednostka.
Kluczowy wniosek: Predykcyjne zaopatrzenie z modelowania zużycia przez AI wymaga co najmniej pięciu do siedmiu dni historycznych danych zużycia na poziomie jednostki, aby generować użyteczne prognozy. Wdrożenie AI logistyki na początku nowej operacji bez historycznego punktu odniesienia daje ogólne szacunki oparte na doktrynalnych wskaźnikach zużycia, a nie na zachowaniu konkretnej jednostki. Zaplanuj okres kalibracji przed poleganiem na prognozach AI dotyczących zaopatrzenia w krytyczne towary.
Przypadek użycia 5: wsparcie planowania — analiza map i ocena terenu
Opracowanie wariantów manewru wymaga analizy terenu, przykrycia, linii obserwacji, przydatności osi podejścia i ograniczeń sieci logistycznej. Wiele z tych analiz jest czasochłonnych, gdy są wykonywane od zera na podstawie obrazów i nakładek map. AI może skrócić harmonogram analityczny, automatyzując ekstrakcję elementów terenu z obrazów i generując ustrukturyzowane podsumowania oceny terenu, które planiści dopracowują, a nie tworzą od podstaw.
Co robi AI. Model wizualny przetwarza obrazy satelitarne lub wyciągi mapowe i identyfikuje elementy terenu istotne dla planowania: zmiany wysokości, gęstość roślinności, wskaźniki przejezdności, gęstość zabudowy, przeszkody wodne, sieć drogową i klasyfikacje nośności mostów tam, gdzie dane są dostępne. Dla danego obszaru siatki generuje ustrukturyzowane podsumowanie terenu — „sektor północno-zachodni: mieszany las, pokrycie baldachimem 60–80%, przejezdność ograniczona do pojazdów gąsienicowych, brak dróg utwardzonych, 3 potencjalne punkty obserwacyjne powyżej 250 m n.p.m." — co skraca czas spędzany przez planistę na podstawowej charakterystyce terenu.
Co operator nadal musi robić. Każda ocena terenu przez AI jest pierwszą wersją. Planiści muszą weryfikować na podstawie aktualnych obrazów (AI pracuje na tych obrazach, jakie mu się dostarczy; przestarzałe obrazy dają przestarzałe oceny), porównywać z HUMINT i ostatnimi raportami patroli oraz stosować osąd w kwestii implikacji taktycznych. Analiza terenu przez AI jest szczególnie zawodna w przypadku zmian w terenie miejskim — budynek, który został uszkodzony lub rozebrany, nie jest odróżnialny od nietkniętego budynku na starszych obrazach.
Czynniki ryzyka. Modele wsparcia planowania AI mogą generować wysoce pewne i głęboko błędne oceny terenu podczas pracy na zdegradowanych, niskoresoluujnych lub przestarzałych obrazach. Wskaźniki pewności wyników modeli wizualnych dla analizy terenu nie są dobrze skalibrowane w większości obecnych systemów — model, który mówi „wysoka pewność" na temat oceny przejezdności opartej na sześciomiesięcznych obrazach, jest mylący, a nie uspokajający.
Krytyczne pułapki: gdzie AI tworzy nowe ryzyko w TOC
Nadmierna zależność po dłuższym okresie dokładności. Systemy AI, które działają dobrze przez tygodnie lub miesiące, indukują zaufanie operatora, które nie jest rekalibrowane, gdy system napotyka przypadek graniczny, z którym radzi sobie słabo. To jest najniebezpieczniejszy tryb awarii we wdrożeniu AI w TOC: operator, który nauczył się ufać ekstrakcji SITREP przez AI bez przeglądu, nie wychwytuje błędu w dniu, gdy model napotka styl pisma odręcznego lub format siatki spoza swojej dystrybucji treningowej. Bieżące przeglądy biegłości i celowe ćwiczenia awarii to jedyne skuteczne środki zaradcze.
Halucynacja w kontekście taktycznym. Duże modele językowe mogą generować pewne, płynne i błędne wyniki. W kontekście konsumenckim jest to irytujące; w kontekście TOC może skutkować referencją siatki, która nie istnieje, identyfikatorem jednostki należącym do innego elementu lub oceną statusu sprzeczną z danymi źródłowymi. Każdy system AI generujący ustrukturyzowane dane taktyczne — referencje siatki, znaki wywoławcze, ilości, czasy — musi być wyposażony w narzędzia pokazujące dane źródłowe, z których wywnioskował wynik, aby operatorzy mogli sprawdzić derivację. Systemy prezentujące dane taktyczne generowane przez AI bez widocznej proweniencji nie nadają się do wdrożenia w TOC.
Zależność sieciowa. AI hostowane w chmurze tworzy zależność sieciową, która nie istnieje w przypadku tradycyjnego oprogramowania TOC. Jednostka, która polega na chmurowym AI do zarządzania COP i traci łączność SATCOM, nie może powrócić do operacji wspomaganych przez AI — musi natychmiast wrócić do ręcznego przepływu pracy. To przełączenie awaryjne musi być ćwiczone jako standardowe ćwiczenie, a nie traktowane jako ewentualność. Architektury hybrydowe z lokalnym modelem brzegowym jako przełączeniem awaryjnym łagodzą twardą zależność, ale nie eliminują operacyjnego wpływu zmniejszonej dokładności AI w trybie modelu brzegowego.
Opóźnienie przy wysokim tempie. Opóźnienie wnioskowania AI — zazwyczaj od jednej do trzech sekund dla modeli lokalnych, od dwóch do pięciu sekund dla modeli chmurowych — jest akceptowalne podczas rutynowych operacji, ale może kumulować się do operacyjnie istotnych opóźnień podczas okresów wysokiego tempa, gdy operator kolejkuje wiele jednoczesnych żądań. Profiluj opóźnienie przy oczekiwanej liczbie jednoczesnych żądań, a nie tylko podczas testów jednoosobowych. Opóźnienie p95 pod obciążeniem jest istotną metryką.
Poufność modelu i obsługa danych. Każdy system AI, który przesyła dane TOC do punktu końcowego API w chmurze, eksfiltruje informacje operacyjne do infrastruktury strony trzeciej. Poziom klasyfikacji przetwarzanych danych musi odpowiadać autoryzacji infrastruktury, która je przetwarza. W przypadku większości taktycznych aplikacji AI oznacza to albo ścisłe ograniczenie do danych niejawnych, albo wdrożenie na infrastrukturze samodzielnie hostowanej, izolowanej od sieci, z lokalnym wnioskowanym modelem. Nie ma dopuszczalnego kompromisu, w którym sklasyfikowane referencje siatki lub identyfikatory jednostek są przesyłane do komercyjnego chmurowego punktu końcowego AI.
Wymagania dotyczące człowieka w pętli dla AI w TOC
Każdy przypadek użycia AI opisany w tym artykule działa pod obowiązkowym wymogiem obecności człowieka w pętli dla działań konsekwentnych. Konkretna implementacja jest różna — karta potwierdzenia, bramka zatwierdzenia, krok przeglądu — ale zasada jest stała: AI generuje propozycję, człowiek autoryzuje działanie. Żaden opisany tutaj system AI nie zapisuje na COP, nie generuje wniosku o wsparcie ogniowe, nie autoryzuje zaopatrzenia ani nie generuje oceny wywiadowczej bez przeglądu i wyraźnego potwierdzenia operatora.
Nie jest to tymczasowe ograniczenie oczekujące na lepsze AI — to jest właściwa architektura dla systemów, w których błędy mają fizyczne konsekwencje. Wartość AI w TOC polega na skracaniu czasu spędzanego przez operatora na mechanicznych częściach każdego zadania, a nie na usuwaniu operatora z pętli decyzyjnej. AI podejmujące autonomiczne działania na COP jest zobowiązaniem, a nie aktywem, niezależnie od współczynnika dokładności — ponieważ współczynnik dokładności nigdy nie wynosi 100%, a konsekwencje błędów w tej domenie są asymetryczne.
Często zadawane pytania
+Które modele AI są odpowiednie dla sklasyfikowanych lub izolowanych od sieci środowisk TOC?
Dla środowisk sklasyfikowanych i izolowanych od sieci odpowiednie są wyłącznie modele open-weight wdrożone lokalnie — konkretnie takie, które można w pełni uruchomić na własnych zasobach obliczeniowych bez zewnętrznych wywołań API. Odpowiednie opcje to skwantyzowane warianty Llama 3 8B i 70B, Qwen 2.5 oraz Mistral 7B Instruct, działające na lokalnym sprzęcie GPU, takim jak NVIDIA Jetson AGX Orin lub taktyczne serwery z dedykowanym GPU. Modele te nigdy nie przesyłają danych poza sieć lokalną. Modele hostowane w chmurze (GPT-4, Claude, Gemini) nie są odpowiednie dla środowisk sklasyfikowanych, ponieważ żądania wnioskowania opuszczają sklasyfikowaną enklawę. Każdy system AI rozważany do użytku w środowiskach sklasyfikowanych powinien być oceniany pod kątem odpowiednich krajowych wymagań dotyczących obsługi klasyfikacji i szczegółowych zasad oznaczania danych, które mają zastosowanie do przetwarzanych przez niego informacji.
+Jak ocenić narzędzie AI przeznaczone do użytku w TOC?
Oceniaj według czterech osi: dokładność przy adversarialnych danych wejściowych (celowo podawaj niejednoznaczne, niekompletne lub sprzeczne SITREP-y i mierz sposób awarii), opóźnienie pod obciążeniem (szczytowe tempo TOC generuje wiele jednoczesnych żądań — mierz opóźnienie p95, nie średnią), zachowanie przy ludzkim nadpisaniu (czy każda akcja wygenerowana przez AI jest przeglądalna i możliwa do anulowania przed wykonaniem?) oraz przejrzystość trybu awarii (czy system degraduje się w sposób widoczny czy cichy?). Ponadto przetestuj zależność sieciową — odłącz go i sprawdź, czy zawodzi bezpiecznie, a nie czy produkuje nierzetelne wyniki. Każde narzędzie, które nie może wygenerować wskaźnika pewności lub sygnału niepewności obok swojego wyniku, nie nadaje się do użytku w TOC, ponieważ operatorzy nie mogą kalibrować swojego polegania na nim.
+Jakie szkolenie operatorów jest wymagane przed wdrożeniem AI w TOC?
Minimalne szkolenie obejmuje trzy obszary: zrozumienie tego, co AI może i nie może zrobić (kalibracja zakresu), rozpoznawanie sygnatur halucynacji w konkretnym wdrożonym systemie oraz ćwiczenie procesu nadpisywania przez człowieka do momentu, gdy stanie się odruchowy. Operatorzy, którzy rozumieją AI jako probabilistycznego asystenta, a nie autorytatywny system, podejmują lepsze decyzje o tym, kiedy niezależnie weryfikować jego wyniki. Szkolenie powinno obejmować celowe ćwiczenia awarii — sesje, w których AI jest zasilane zdegradowanymi lub błędnymi danymi wejściowymi, aby operatorzy mogli zapoznać się z trybami awarii przed napotkaniem ich pod presją operacyjną. Konieczne są bieżące przeglądy biegłości, ponieważ zaufanie operatorów ma tendencję do dryfu w kierunku nadmiernej zależności z upływem czasu, szczególnie po dłuższym okresie dokładnego działania AI.
+Jakie są ryzyka zależności sieciowej AI w TOC?
Systemy AI zależne od chmury tworzą twardą zależność od łączności sieciowej, która nie istnieje w przypadku tradycyjnego oprogramowania TOC. Jeśli zaplecze AI stanie się nieosiągalne — z powodu zagłuszania EW, uszkodzenia infrastruktury lub celowej degradacji sieci — operatorzy muszą natychmiast wrócić do procesów ręcznych. To przełączenie awaryjne musi być ćwiczone, a nie tylko zakładane. Systemy używające lokalnych modeli brzegowych eliminują to ryzyko, ale wprowadzają inne ograniczenie: dokładność lokalnego modelu jest niższa, a zasoby obliczeniowe są ograniczone. Architektura hybrydowa — model chmurowy przy połączeniu, model lokalny przy degradacji — jest najbardziej odpornym podejściem, pod warunkiem że operatorzy są przeszkoleni w zakresie różnic dokładności między dwoma trybami.
+W jaki sposób informacje taktyczne wygenerowane przez AI powinny być przypisywane w dzienniku audytu?
Każda akcja wygenerowana lub wspomagana przez AI umieszczona na COP powinna być przypisana w ścieżce audytu za pomocą trzech pól: tożsamość operatora (kto autoryzował akcję), identyfikator systemu AI (który model lub narzędzie wygenerowało sugestię) oraz dane źródłowe (jakie dane wejściowe przetwarzało AI). Pozwala to na przegląd po działaniu w celu odróżnienia akcji wspomaganych przez AI od bezpośrednich wpisów operatorów, identyfikacji wzorców błędów AI i odtworzenia łańcucha decyzji dla każdej znaczącej akcji. Systemy, które rejestrują akcje wspomagane przez AI identycznie jak akcje bezpośrednie operatorów, podważają wartość śledczą ścieżki audytu i uniemożliwiają prowadzenie znaczącej analizy post-incydentowej.