Agent AI w obsłudze roszczeń ubezpieczeniowych: triage, dokumenty i kontrolowany workflow

W obsłudze roszczeń ubezpieczeniowych agent AI ma sens, ale nie w wersji marketingowej: "wrzuć zdjęcia, model wyliczy szkodę, system sam wypłaci pieniądze". Taki opis pomija najważniejsze pytania: kto podejmuje decyzję wobec klienta, na jakiej podstawie, z jakim prawem do interwencji człowieka, w jakim rejestrze logów i pod jaką retencją danych.

Bezpieczniejszy punkt startu jest mniej efektowny, ale bardziej przydatny operacyjnie. Agent może przyjmować zgłoszenie, rozpoznawać typ sprawy, sprawdzać kompletność dokumentów, pobierać status polisy z systemu źródłowego, przygotowywać podsumowanie dla likwidatora, proponować następny krok i eskalować przypadki ryzykowne. Może też wygenerować projekt wiadomości do klienta albo checklistę braków. To jest triage i wsparcie procesu. To nie jest samodzielna decyzja o uznaniu, odmowie ani wysokości świadczenia.

W 2026 roku to rozróżnienie jest kluczowe. Ubezpieczyciel działa w środowisku danych osobowych, sporów kontraktowych, nadzoru finansowego, RODO i nadchodzących obowiązków z AI Act. Automatyzacja może skrócić czas obsługi, ale tylko wtedy, gdy jest ograniczona do dobrze opisanych kroków i nie ukrywa odpowiedzialności za decyzję.

Triage to nie decyzja

W roszczeniach trzeba rozdzielić trzy warstwy pracy:

• przyjęcie i uporządkowanie sprawy: kanał zgłoszenia, dane polisy, dokumenty, opis zdarzenia, zdjęcia, faktury, historia kontaktu,
• kwalifikacja operacyjna: typ szkody, kompletność, proste braki, priorytet, ryzyko eskalacji, właściwa kolejka,
• decyzja merytoryczna: odpowiedzialność ubezpieczyciela, zakres ochrony, wysokość świadczenia, odmowa, redukcja, wypłata, ugoda lub odwołanie.

Agent AI dobrze pasuje do dwóch pierwszych warstw. W trzeciej może przygotować materiał, ale nie powinien samodzielnie rozstrzygać sprawy bez osobnej klasyfikacji prawnej, reguł nadzoru i zatwierdzonego procesu po stronie zakładu ubezpieczeń.

To nie jest semantyczna ostrożność. Decyzja o odmowie wypłaty, obniżeniu kwoty albo zamknięciu sprawy może istotnie wpłynąć na sytuację klienta. RODO ogranicza decyzje oparte wyłącznie na automatycznym przetwarzaniu, jeżeli wywołują skutki prawne lub podobnie istotnie wpływają na osobę. AI Act dodatkowo wskazuje wybrane zastosowania wysokiego ryzyka, w tym systemy używane do oceny ryzyka i pricingu wobec osób fizycznych w ubezpieczeniach na życie i zdrowotnych. Zwykły triage szkody komunikacyjnej nie staje się automatycznie takim samym przypadkiem, ale nie zwalnia to z governance, dokumentacji, nadzoru człowieka i oceny ryzyka.

Praktyczna zasada brzmi: agent może przyspieszać przygotowanie sprawy, a decyzja dotykająca prawa klienta powinna mieć właściciela, ślad i możliwość kontroli.

Gdzie naprawdę znika czas

Wąskie gardła w obsłudze roszczeń rzadko wynikają z jednego wolnego kliknięcia. Częściej składają się z wielu małych opóźnień:

• zgłoszenie trafia do niewłaściwej kolejki,
• dokumenty są niekompletne albo mają niejednoznaczne nazwy,
• zdjęcia, faktury i opisy zdarzenia są w różnych kanałach,
• likwidator musi ręcznie sprawdzić dane polisy i historię klienta,
• klient dostaje ogólną prośbę o "uzupełnienie dokumentów", zamiast konkretnej listy braków,
• status sprawy jest aktualny w jednym systemie, ale nie w komunikacji z klientem,
• proste sprawy czekają razem ze sporami, fraudem, szkodami osobowymi i odwołaniami.

Agent nie musi rozstrzygać szkody, żeby usunąć część tych opóźnień. Jeżeli poprawnie sprawdzi kompletność, przypisze sprawę do właściwego koszyka, wyśle precyzyjną prośbę o brakujący dokument i przygotuje likwidatorowi streszczenie, proces jest krótszy bez oddawania decyzji modelowi.

Warto też pamiętać o jakości pracy zespołu. Likwidator nie powinien tracić czasu na szukanie załączników i przepisywanie danych, ale powinien mieć czas na ocenę odpowiedzialności, wyjątki, komunikację w trudnych sprawach i kontrolę decyzji. Agent jest najbardziej użyteczny tam, gdzie przejmuje pracę administracyjną i porządkującą.

Co agent może robić w roszczeniu

Dobry zakres na start to zadania, które mają jasne wejście, jasne wyjście i ograniczone konsekwencje błędu.

Przyjęcie zgłoszenia

Agent może zebrać podstawowe dane: numer polisy, dane kontaktowe, datę zdarzenia, lokalizację, typ szkody, opis, preferowany kanał kontaktu i listę załączników. Może też poprosić klienta o informacje w kolejności wynikającej z procesu, zamiast prowadzić swobodną rozmowę.

Ważne ograniczenie: agent nie powinien wymuszać danych, które nie są potrzebne do danego kroku. Jeżeli sprawa dotyczy prostej szkody rzeczowej, nie ma powodu zbierać nadmiarowych danych zdrowotnych, rodzinnych lub finansowych tylko dlatego, że model "może się przydać".

Kompletność dokumentów

To jeden z najbezpieczniejszych obszarów automatyzacji. System może sprawdzić, czy zgłoszenie zawiera wymagane elementy dla danego typu sprawy: zdjęcia, fakturę, notatkę policyjną, protokół, numer rachunku, oświadczenie sprawcy, kosztorys albo dokument własności.

Różnica między dobrym a złym agentem jest prosta. Zły agent pisze: "brakuje dokumentów". Dobry agent wskazuje, którego dokumentu brakuje, dlaczego jest potrzebny, jak go dosłać i co stanie się ze sprawą do czasu uzupełnienia.

Odczyt statusu i danych polisy

Agent może mieć uprawnienie tylko do odczytu w systemie polisowym: czy polisa istnieje, czy była aktywna w dniu zdarzenia, jaki jest produkt, wariant, suma ubezpieczenia, udział własny, podstawowe wyłączenia i aktualny status sprawy.

Ten odczyt powinien być logowany. Jeżeli agent pobrał dane, system powinien wiedzieć kiedy, na czyje zgłoszenie, z jakiego źródła i jaką wersję informacji przekazał dalej. W ubezpieczeniach "model powiedział" nie jest wystarczającym wyjaśnieniem.

Podsumowanie dla likwidatora

Streszczenie jest użyteczne, jeżeli nie zastępuje dokumentów. Agent może przygotować krótką notatkę:

• co klient zgłosił,
• jakie dokumenty dostarczył,
• jakie braki wykryto,
• które dane polisy sprawdzono,
• czy sprawa pasuje do standardowej ścieżki,
• dlaczego wymaga eskalacji.

Likwidator powinien widzieć źródła: linki do dokumentów, fragmenty OWU, wynik odczytu z systemu, historię komunikacji i powód klasyfikacji. Samo streszczenie bez źródeł zwiększa ryzyko błędu, bo brzmi wiarygodnie nawet wtedy, gdy pomija istotny szczegół.

Komunikacja statusowa

Agent może odpowiadać na pytania o status, jeżeli opiera się na systemie źródłowym i nie obiecuje terminu bez podstawy. Bezpieczna odpowiedź mówi, na jakim etapie jest sprawa, czego brakuje, kto ma następny krok i jak klient może uzupełnić dane.

Niebezpieczna odpowiedź obiecuje wypłatę, uznanie roszczenia albo konkretną kwotę, zanim decyzja została zatwierdzona przez właściwy proces.

Sprawy dobre na pilotaż

Pilotaż powinien zaczynać się od wąskiego typu roszczeń, a nie od całego portfela. Dobre kandydaty mają powtarzalne dokumenty, mało wyjątków i niski koszt błędu operacyjnego.

Przykłady zakresów, które zwykle nadają się do ostrożnego pilotażu:

• szkody szybowe jako przyjęcie zgłoszenia, kompletność dokumentów i routing do ścieżki naprawy,
• assistance jako kwalifikacja zdarzenia, zebranie danych i przekazanie do operatora,
• proste zwroty kosztów na podstawie faktury, gdy agent przygotowuje paczkę do akceptacji,
• statusy szkód i przypomnienia o brakach,
• klasyfikacja przychodzących maili oraz załączników do właściwej sprawy.

W tych przypadkach agent może przygotować sprawę do szybszego zatwierdzenia. To nadal nie znaczy, że powinien samodzielnie wydać decyzję wobec klienta. Nawet w prostych procesach warto zacząć od trybu "draft and approve": agent proponuje kolejny krok, człowiek zatwierdza, a dopiero po pomiarze jakości część niskiego ryzyka można przenieść do reguł automatycznych.

Sprawy, które powinny trafiać do człowieka

Niektóre kategorie wymagają człowieka od razu, nawet jeśli dokumenty wyglądają kompletne:

• szkody osobowe, zdrowotne, śmierć, trwały uszczerbek i sprawy wymagające empatii,
• odmowa lub redukcja świadczenia,
• spór o zakres ochrony, wyłączenia, winę lub interpretację OWU,
• podejrzenie wyłudzenia, konflikt danych albo nietypowy wzorzec zachowania,
• szkody wielostronne, regres, odwołania i sprawy z pełnomocnikiem,
• klient w trudnej sytuacji życiowej albo podwyższone ryzyko skargi,
• sprawy, w których dane są niejednoznaczne albo źródła sobie przeczą,
• jakiekolwiek działanie, które wymaga zmiany uprawnień, wypłaty środków lub formalnego zamknięcia sprawy.

Eskalacja nie jest porażką automatyzacji. Jest warunkiem jej użycia. Dobrze zaprojektowany agent wie, kiedy przestać odpowiadać i przekazać sprawę z pełnym kontekstem.

Architektura kontrolowanego przepływu pracy

Agent do roszczeń nie powinien być jednym dużym czatem podpiętym do wszystkich systemów. Bezpieczniejsza architektura dzieli proces na warstwy.

Źródła i RAG

RAG może pomóc wyszukiwać aktualne fragmenty OWU, instrukcji likwidacyjnych, wzorów komunikacji i procedur. Nie jest jednak gwarancją prawdy. Jeżeli indeks zawiera stare wersje dokumentów albo nie rozróżnia produktów, model może podać poprawnie brzmiącą, ale błędną odpowiedź.

W projekcie trzeba ustalić:

• które dokumenty są źródłem prawdy,
• kto jest właścicielem każdej kategorii treści,
• jak oznaczane są wersje i daty obowiązywania,
• czy agent może cytować tylko zatwierdzone fragmenty,
• co dzieje się, gdy źródła są sprzeczne,
• jak szybko zmiana OWU lub procedury trafia do indeksu.

Przy roszczeniach szczególnie ważne jest odróżnienie dokumentów publicznych od instrukcji wewnętrznych. Agent może użyć obu warstw do przygotowania sprawy, ale komunikat do klienta powinien powstać na podstawie treści, które wolno ujawnić.

Orkiestracja i punkty zatrzymania

LangGraph lub podobny orkiestrator ma sens wtedy, gdy proces ma stan, etapy, warunki i przerwania. Zamiast prosić model, żeby "obsłużył roszczenie", projektuje się graf: przyjęcie, walidacja, odczyt polisy, kompletność, klasyfikacja, projekt wiadomości, przegląd człowieka, zapis wyniku.

Punkty zatrzymania są ważniejsze niż sam model. W miejscach ryzykownych workflow powinien pauzować i czekać na człowieka: przed wysłaniem formalnej wiadomości, przed zmianą statusu, przed uruchomieniem płatności, przed odmową albo przed eskalacją do fraudu. Dokumentacja LangGraph opisuje interrupt jako mechanizm pozwalający zatrzymać graf, pokazać stan człowiekowi i wznowić po decyzji lub edycji.

n8n może być użyteczne przy prostszych integracjach: utworzenie zadania, powiadomienie w Slacku lub Teams, zapis do CRM, pobranie danych z API, wysłanie prośby o zatwierdzenie. Jego dokumentacja human-in-the-loop pozwala wymagać akceptacji człowieka przed wykonaniem konkretnego narzędzia przez agenta. To dobry wzorzec dla działań takich jak wysłanie maila, modyfikacja rekordu albo uruchomienie procesu po stronie systemu operacyjnego.

Uprawnienia

Agent powinien mieć najmniejsze możliwe uprawnienia:

• odczyt danych polisy zamiast zapisu,
• możliwość przygotowania draftu zamiast wysyłki bez akceptacji,
• możliwość utworzenia zadania zamiast zmiany decyzji,
• osobne konto techniczne z limitami,
• brak dostępu do danych poza zakresem sprawy,
• blokadę narzędzi wysokiego ryzyka bez zatwierdzenia.

Jeżeli agent ma dostęp do systemów wewnętrznych, trzeba logować nie tylko odpowiedzi modelu, ale też wywołania narzędzi: kto, kiedy, z jakimi parametrami, na jakiej sprawie i z jakim wynikiem.

Obserwowalność i audyt

W roszczeniach ślad audytowy musi być projektowany od początku. Minimum obejmuje:

• identyfikator sprawy i wersję workflow,
• wejście użytkownika oraz załączniki objęte analizą,
• dokumenty pobrane przez RAG i ich wersje,
• wywołania systemów źródłowych,
• klasyfikację sprawy i powód klasyfikacji,
• reguły eskalacji, które zadziałały,
• drafty wygenerowane przez model,
• decyzje człowieka: zatwierdzenie, edycja, odmowa, przekazanie,
• błędy integracji i działania naprawcze.

AI Act wymaga automatycznych logów dla systemów wysokiego ryzyka, a EIOPA w podejściu do AI w ubezpieczeniach podkreśla m.in. data governance, dokumentację, record-keeping, explainability i human oversight. Nawet gdy konkretny agent triage nie zostanie zakwalifikowany jako high-risk, te same elementy są praktyczne: bez nich nie da się wyjaśnić klientowi, likwidatorowi, compliance ani audytowi, co system zrobił.

RODO: dane, retencja i decyzje automatyczne

Roszczenie ubezpieczeniowe prawie zawsze zawiera dane osobowe. Często zawiera też dane wrażliwe albo informacje pozwalające wnioskować o stanie zdrowia, sytuacji rodzinnej, miejscu pobytu, majątku lub relacjach z innymi osobami. Dlatego projekt agenta powinien mieć osobną mapę danych.

Przed startem trzeba odpowiedzieć na pytania:

• jakie dane trafiają do modelu, RAG, logów, ticketingu i narzędzi integracyjnych,
• które dane są maskowane albo pomijane,
• czy dostawca modelu, hostingu lub narzędzi jest procesorem lub podprocesorem,
• gdzie fizycznie i prawnie odbywa się przetwarzanie,
• czy dane są używane do trenowania modeli,
• kto ma dostęp do transkrypcji i wyników analizy,
• jak długo przechowywane są rozmowy, logi techniczne, dokumenty szkody i wersje draftów,
• jak obsługiwane są żądania dostępu, sprostowania, usunięcia i ograniczenia przetwarzania.

RODO wymaga m.in. minimalizacji danych i ograniczenia przechowywania. W praktyce oznacza to, że logi nie powinny stawać się wiecznym magazynem wszystkiego, co klient napisał. Inny okres retencji może dotyczyć dokumentów szkodowych, historii formalnej decyzji, logów technicznych, danych treningowych do ewaluacji i tymczasowych śladów debugowania.

Najbardziej wrażliwy temat to decyzje automatyczne. Jeżeli system miałby samodzielnie odmówić wypłaty, obniżyć świadczenie, zamknąć sprawę albo ustalić kwotę w sposób wiążący dla klienta, nie jest to już zwykła automatyzacja administracyjna. Taki zakres wymaga osobnej analizy RODO, oceny skutków dla ochrony danych, procedury interwencji człowieka, możliwości zakwestionowania decyzji i jasnej podstawy prawnej.

AI Act i ubezpieczenia

AI Act nie mówi, że każdy agent w ubezpieczeniach jest systemem wysokiego ryzyka. Klasyfikacja zależy od przeznaczenia systemu. Załącznik III wskazuje między innymi systemy używane do oceny ryzyka i ustalania cen wobec osób fizycznych w ubezpieczeniach na życie i zdrowotnych.

Agent do triage szkody komunikacyjnej, który segreguje dokumenty i przygotowuje sprawę dla człowieka, to inny profil ryzyka niż system ustalający cenę polisy zdrowotnej albo automatycznie odmawiający świadczenia. Mimo to ubezpieczyciel nie powinien kończyć analizy na zdaniu "to tylko asystent". Trzeba opisać przeznaczenie, użytkowników, dane, wpływ na klienta, stopień autonomii, możliwość nadużycia, nadzór człowieka i ślad działania.

W projektach planowanych na 2026 rok praktyczne są cztery pytania:

1. Czy system wpływa na decyzję dotyczącą naturalnej osoby, czy tylko przygotowuje materiał?
2. Czy jego wynik może prowadzić do odmowy, ograniczenia świadczenia, pricingu lub innego istotnego skutku?
3. Czy człowiek ma realną możliwość zrozumienia, zakwestionowania, zmiany i zatrzymania wyniku?
4. Czy po miesiącu da się odtworzyć, z jakich danych, źródeł i reguł powstał wynik?

Jeżeli odpowiedzi są niejasne, zakres agenta trzeba zawęzić przed pilotażem.

Narzędzia: gdzie pasują, czego nie obiecują

Nazwy narzędzi pomagają w rozmowie technicznej, ale nie zastępują projektu procesu.

W produkcyjnym roszczeniu najważniejszy nie jest wybór logo. Najważniejsze są granice: co agent może przeczytać, co może zaproponować, co może zapisać, co wymaga akceptacji i czego nie wolno mu zrobić.

Jak zaprojektować pilotaż

Pilotaż powinien być mały, mierzalny i odwracalny. Dobry pierwszy zakres to jeden typ roszczenia albo jeden fragment procesu, np. kompletność dokumentów i routing.

Plan pilotażu:

1. Wybierz typ sprawy o powtarzalnych dokumentach.
2. Opisz, które kroki są automatyczne, które są draftem, a które wymagają człowieka.
3. Zbierz zestaw historycznych spraw do testów, w tym wyjątki i błędy.
4. Zdefiniuj reguły eskalacji: kwota, typ szkody, sprzeczne dane, brak źródła, fraud, szkoda osobowa, odwołanie.
5. Ustal właściciela źródeł wiedzy i procedur.
6. Skonfiguruj logi, retencję i dostęp do danych przed startem.
7. Mierz jakość na próbce spraw, nie tylko szybkość.
8. Zatrzymaj automatyzację tam, gdzie system generuje niepewne lub niepełne wyniki.

Metryki powinny obejmować:

• poprawność klasyfikacji sprawy,
• poprawność wykrywania braków,
• liczbę niepotrzebnych eskalacji i brakujących eskalacji,
• czas do pierwszej kompletnej informacji dla klienta,
• jakość streszczeń ocenianą przez likwidatorów,
• liczbę draftów wymagających istotnej edycji,
• błędy źródeł RAG i wersjonowania dokumentów,
• przypadki, w których agent próbował wyjść poza zakres.

Nie warto obiecywać uniwersalnego ROI. Zwrot zależy od wolumenu spraw, jakości danych, stopnia integracji, kosztu pracy, liczby kanałów, udziału wyjątków i tego, czy proces jest już opisany. Ubezpieczyciel z uporządkowanym systemem szkodowym i jasnymi procedurami zobaczy efekt szybciej niż organizacja, w której dokumenty, decyzje i statusy są rozproszone po mailach.

Kiedy agent nie ma sensu

Agent AI nie jest pierwszym krokiem, jeżeli:

• proces likwidacji nie jest spisany,
• systemy źródłowe nie mają stabilnych danych,
• nikt nie odpowiada za aktualność OWU i procedur,
• zespół nie ma czasu na przegląd wyników pilotażu,
• compliance ma być dopisane po wdrożeniu,
• sukces ma być mierzony wyłącznie liczbą "zamkniętych" spraw,
• firma oczekuje automatycznych decyzji bez analizy RODO, AI Act i nadzoru.

W takiej sytuacji lepiej zacząć od mniej ryzykownych elementów: klasyfikacji maili, listy braków, statusów, lepszego formularza zgłoszeniowego, dashboardu kolejek albo uporządkowania źródeł wiedzy. Często największa poprawa pochodzi nie z modelu, tylko z usunięcia chaosu w wejściu procesu.

Wniosek

Agent AI w obsłudze roszczeń może być wartościowy, jeżeli jest traktowany jako kontrolowany workflow, a nie autonomiczny likwidator. Najpierw powinien porządkować zgłoszenia, sprawdzać kompletność, przygotowywać kontekst, wykrywać ryzyka i pomagać człowiekowi podjąć decyzję szybciej oraz lepiej udokumentować sprawę.

Automatyzacja decyzji to osobny temat. Wymaga klasyfikacji regulacyjnej, oceny skutków, nadzoru człowieka, audytu, retencji i procedury zakwestionowania wyniku. Jeżeli tych elementów nie ma, agent powinien zatrzymać się przed decyzją.

Najlepszy pilotaż nie zaczyna się od obietnicy "roszczenia w 24 godziny". Zaczyna się od pytania: które kroki można bezpiecznie przyspieszyć, które źródła są wiarygodne, kto zatwierdza wynik i czy po czasie da się odtworzyć całą ścieżkę sprawy.

Źródła i punkty kontrolne

• AI Act, Annex III - systemy wysokiego ryzyka
• AI Act, art. 12 - record-keeping
• AI Act, art. 14 - human oversight
• AI Act, art. 50 - transparentność interakcji z AI
• AI Act, art. 72 - post-market monitoring
• AI Act Service Desk - harmonogram stosowania
• Komisja Europejska - ograniczenia automatycznego podejmowania decyzji w RODO
• Komisja Europejska - minimalizacja danych w RODO
• EIOPA - Opinion on Artificial Intelligence governance and risk management
• LangGraph - interrupts i human-in-the-loop
• n8n - human-in-the-loop for AI tool calls
• n8n - execution data i pruning
• OpenClaw - chat channels and Gateway
• Hermes Agent - dokumentacja Nous Research

---

Chcesz sprawdzić, gdzie agent AI ma sens w Twoim procesie roszczeń? Umów bezpłatny skan procesów. To 30 minut z inżynierem i pisemne podsumowanie w 2 dni robocze. Przejdziemy przez typy spraw, dane, granice decyzji, eskalacje i ślad audytowy przed rozmową o wdrożeniu.

---

Powiązane artykuły:

• Voicebot AI dla firm ubezpieczeniowych
• Syntalith
• Agent AI do monitorowania compliance w finansach