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.

Jak sprawdzić odmowę przed wdrożeniem

Zbierz przykłady, w których odpowiedź ma podstawę, oraz takie, w których brakuje dokumentu, dane są sprzeczne albo kwota wykracza poza ustalony zakres. Dla każdego przypadku zapisz oczekiwany wynik: odpowiedź ze źródłem, prośbę o uzupełnienie albo przekazanie sprawy wskazanej osobie.

Test powinien obejmować także starą wersję dokumentu, powtórzone zapytanie i próbę wymuszenia odpowiedzi bez źródła. Mierz osobno poprawność odpowiedzi, prawidłowe zatrzymanie i czas pracy osoby, która przejmuje wyjątek. Taki zestaw pozwala ocenić mechanizm na danych firmy bez obietnicy bezbłędności.

Przy takim teście zespół widzi, czy system rozpoznaje brak podstawy, zatrzymuje sprawę i przekazuje ją właściwej osobie, zanim błędna odpowiedź trafi do klienta albo zmieni dane w firmowym systemie.

Sposób opisania źródeł i decyzji można zobaczyć przy wycenie zapytań ofertowych.

Na bezpłatny skan procesu przynieś pięć poprawnych przypadków i pięć takich, w których system powinien odmówić, wskazać brakujące dane albo przekazać sprawę człowiekowi. Podczas audytu procesu pod AI można ustalić reguły, a następnie zbudować je jako aplikację AI.