Agent AI prawie nigdy sam z siebie nie powie „nie wiem”. Powie za to rzeczy nieprawdziwe tonem, jakim główny księgowy referuje bilans. NIST nazywa to zjawisko konfabulacją: model tworzy treść przekonującą i fałszywą jednocześnie. Kolejne wersje modeli ograniczają część takich błędów, ale nie liczyłbym, że problem zniknie. Traktuję go jak warunek pogodowy. Nie obrażam się na deszcz, biorę parasol.
Najgroźniejsza wersja tego zjawiska ma dopisek „zrobione”. Błąd przestaje wtedy wyglądać jak hipoteza i zaczyna krążyć po organizacji jako fakt, na podstawie którego ktoś podejmie decyzję. A takie błędy kumulują się po cichu i wychodzą na jaw w najgorszym momencie.
Parasol wygląda tak. Cztery reguły, które stosuję codziennie, w projektach IT i w zwykłej pracy biurowej.
Reguła 1. Status wymaga dowodu
Kiedy agent raportuje „działa, wszystkie testy przechodzą”, nie przyjmuję zdania. Przyjmuję dowód: konkretną komendę i jej wynik, link, fragment pliku, log. Brzmi upierdliwie? Możliwe. Ale „zrobione” bez dowodu to w praktyce „wygenerowałem zdanie, które zwykle występuje na końcu zadania”. Status powinien wynikać z wcześniej ustalonego testu, a nie z narracji wykonawcy. Ludzkiego czy cyfrowego, bez różnicy.
Reguła 2. Pomiar to migawka, nie stan
Jeżeli agent sprawdził coś o 14:30 i działało, to wiem tyle, że działało o 14:30. Zanim orzeknę „system działa”, chcę historii: logów, liczników, znaczników czasu. Jedno spojrzenie na termometr nie mówi, czy pacjent zdrowieje. Pojedyncza migawka wystarcza do odbioru pojedynczego zadania, ale nie do wniosku o stabilności procesu. To dwa różne poziomy i trzeba je nazywać osobno.
Reguła 3. Znalezisko „przy okazji” to hipoteza
Agent w trakcie jednego zadania potrafi rzucić mimochodem: „a tak w ogóle zauważyłem, że moduł X jest zepsuty”. To zdanie brzmi jak spostrzegawczość i dlatego jest najniebezpieczniejsze. Powstało poza głównym nurtem pracy i nikt go nie weryfikował. U mnie dostaje status hipotezy i osobne sprawdzenie. Ta sama zasada obowiązuje zresztą ludzi: uwaga nie staje się ustaleniem tylko dlatego, że brzmi fachowo.
Reguła 4. Niejasność wraca jako pytanie albo luka
Wolę, żeby maszyna dopytała, niż żeby zgadła moją intencję i wykonała z rozmachem nie to zadanie. Zgadywanie intencji to najdroższy rodzaj pracowitości. Nie każda niejasność musi zatrzymywać pracę, ale każda musi być obsłużona świadomie: pytaniem, wariantami do wyboru albo wpisem do rejestru luk. Przy budowie macierzy wymagań regulacyjnych ta zasada przestała być nawykiem, a stała się mechanizmem: niedostępny dokument techniczny trafił do rejestru z listą zależnych wymagań, zamiast zostać po cichu „uzupełniony” domysłem.
Prosty model wiarygodności
Każde ważne twierdzenie powinno mieć cztery elementy: treść, status, dowód i datę. „Funkcja działa” to treść. „Potwierdzone w zakresie testów A do C” to status. Wyniki testów to dowód. Znacznik czasu mówi, kiedy wniosek był aktualny.
I teraz rzecz, dla której to wszystko piszę. W firmach dyskusja o ryzyku AI kręci się wokół pytania „czy model halucynuje”. Złe pytanie. Będzie halucynował, to pewne jak deszcz jesienią. Prawdziwe pytanie brzmi: czy Twoja organizacja ma procedurę, która to wyłapie, zanim treść trafi do klienta, do urzędu albo do zarządu jako podstawa decyzji. Ludzie od jakości znają tę logikę od dekad. Nie eliminujesz błędu. Budujesz proces, który go łapie.
Zaufanie do AI buduje się dokładnie tak, jak zaufanie do nowego pracownika: przez weryfikowalność pracy, nie przez wiarę w CV. Nowemu człowiekowi nie dajesz w pierwszym tygodniu dostępu do przelewów. Maszynie, która nigdy nie mówi „nie wiem”, tym bardziej.
