Halucynacje AI: jak ograniczyć je w firmie w 2026

Model językowy może podać datę, nazwisko albo przepis, który brzmi wiarygodnie i nie istnieje. Wewnętrzny szkic łatwo poprawić. Fałszywa cena wysłana klientowi, nieistniejący zapis umowy albo błędna liczba w raporcie mają już realny koszt.

Dlatego nie pytaj wyłącznie, jak często model się myli. Najpierw ustal, co stanie się po błędnej odpowiedzi.

Zacznij od skutku błędu

Podziel zastosowania na trzy grupy:

Nie każdy szkic potrzebuje rozbudowanego systemu kontroli. Ale im większy skutek, tym mniej miejsca na swobodną odpowiedź modelu.

Pięć praktycznych zabezpieczeń

Odpowiedź z podanym źródłem

System najpierw wyszukuje właściwy dokument, a potem odpowiada na jego podstawie i pokazuje użyty fragment. Brak podstawy powinien zakończyć się odmową odpowiedzi.

RAG pomaga tylko wtedy, gdy dokumenty są aktualne i mają właścicieli. Nieaktualny cennik nadal da nieaktualną odpowiedź, nawet jeśli system zacytuje go bezbłędnie.

Zamknięty format wyniku

Klasyfikacja do jednej z pięciu kategorii jest łatwiejsza do sprawdzenia niż długi komentarz. Przy odczycie faktury model może zwrócić numer, datę i kwotę w ustalonym formacie. Kod sprawdzi typy pól, zakres kwoty oraz zgodność sum.

Im mniej swobodnej prozy potrzeba, tym mniej miejsc na dopowiedzenia.

Pokazanie zmiany zamiast streszczenia z pamięci

Przy monitorowaniu dokumentu system powinien wskazać poprzedni i nowy fragment. Przy raporcie powinien podać liczbę ze źródła oraz zastosowane obliczenie. Człowiek widzi materiał, na którym oparto wniosek.

Zgoda przed skutkiem

Wiadomość do klienta, oferta cenowa, zmiana rekordu i decyzja dotycząca osoby powinny czekać na zatwierdzenie. Model przygotowuje propozycję. Człowiek widzi źródło oraz planowaną akcję i bierze odpowiedzialność za wykonanie.

Próg zatrzymania

Brak dokumentu, sprzeczne źródła, niepełne dane albo wynik poza rozsądnym zakresem powinny zatrzymać proces. Nie chodzi o magiczny procent "pewności" podany przez model. Próg może wynikać z rzeczy sprawdzalnych: brak identyfikatora klienta, różne kwoty na fakturze i zamówieniu, przeterminowany dokument.

Liczby bierz z systemów

Kwoty, salda, statusy i terminy powinny pochodzić z bazy, API albo zatwierdzonego pliku. Model może je opisać, ale nie powinien odtwarzać ich z pamięci.

System raportowania dla zarządu powinien więc pobrać liczby z systemów i dopiero potem przygotować komentarz. Pod każdą ważną wartością potrzebny jest odsyłacz do źródła albo obliczenie, które można powtórzyć.

Podobna zasada działa przy zmianach w dokumentach. Agent do monitorowania konkurencji powinien pokazać konkretny zmieniony fragment i jego adres. Sam komunikat o zmianie oferty to za mało.

Testy muszą zawierać brak odpowiedzi

Zestaw testowy złożony wyłącznie z łatwych pytań mierzy niewiele. Dodaj:

• pytania bez odpowiedzi w źródłach,
• stare i nowe wersje tego samego dokumentu,
• sprzeczne ceny,
• błędne nazwiska i numery spraw,
• polecenia próbujące wymusić odpowiedź bez źródła,
• dokumenty z ukrytą instrukcją dla modelu.

Ostatni przypadek dotyczy prompt injection. Fałszywa odpowiedź i przejęcie polecenia to inne problemy, ale oba sprawdzają, czy system umie odmówić i czy narzędzia są ograniczone.

Kiedy wystarczy człowiek

Pomysły, szkice i wewnętrzne podsumowanie dokumentu, który użytkownik zaraz przeczyta, mogą działać z prostszymi zabezpieczeniami. Wystarczy oznaczyć wynik jako roboczy i zablokować automatyczne działania na jego podstawie.

Pełna kontrola ma sens tam, gdzie odpowiedź dotyka klienta, pieniędzy, prawa albo danych w systemie. W pozostałych miejscach rozbudowane zabezpieczenia mogą kosztować więcej niż sam błąd.

Co dzieje się przy braku podstawy

Wersja demonstracyjna wyceny zapytań ofertowych obejmuje 60 pozycji przygotowanych do testu. Jedna cena pochodzi z precedensu, druga z zatwierdzonej reguły, a pozycja bez podstawy trafia do technologa bez ceny. System zatrzymuje się zamiast wymyślać brakującą odpowiedź.

To pokaz mechanizmu na danych testowych. Nie opisuje wyniku klienta. Podobną kontrolę można zaprojektować podczas audytu procesu pod AI, a następnie zbudować jako aplikację AI.

Na bezpłatny skan procesu przynieś pięć poprawnych przypadków i pięć takich, przy których system powinien powiedzieć "nie wiem", wskazać brakujące dane albo przekazać sprawę człowiekowi.