W contact center ubezpieczyciela klient czeka na linii, a konsultant przeszukuje w tym czasie OWU, taryfy, procedury i kilka różnych systemów. Odpowiedź gdzieś jest, tylko trudno ją szybko znaleźć i mieć pewność, że jest aktualna. Dla dyrektora obsługi oznacza to jedno: wiedza istnieje w organizacji, ale nie trafia na czas do rozmowy z klientem. Właśnie tę lukę zamyka asystent AI w ubezpieczeniach, oparty na połączeniu RAG i modelu językowego.
Z naszego doświadczenia najtrudniejsze nie jest uruchomienie modelu, lecz osadzenie go w realnym procesie obsługi i w źródłach prawdy firmy. Dla UNIQA, jednego z największych ubezpieczycieli w Polsce, zbudowaliśmy asystenta AI dla contact center opartego na modelu PLLuM, który podpowiada konsultantom gotowe odpowiedzi i streszcza zapisy do języka korzyści, działając na środowisku on-prem.
Dlaczego konsultanci tracą czas na szukanie odpowiedzi?
Problem rzadko leży po stronie ludzi. Wiedza w ubezpieczeniach jest rozproszona, obszerna i zmienna: OWU różnią się między produktami i rocznikami, taryfy się aktualizują, a procedury żyją w osobnych dokumentach. Konsultant, zamiast rozmawiać z klientem, przeskakuje między zakładkami i składa odpowiedź z kilku miejsc naraz.
Skutki są dobrze znane każdemu, kto zarządza obsługą: wydłuża się czas obsługi, rośnie ryzyko niespójnych odpowiedzi, a nowi pracownicy długo wchodzą w rolę. Ta sama sprawa potrafi zakończyć się różną odpowiedzią w zależności od tego, kto ją obsłużył. To nie jest problem motywacji, tylko dostępu do wiedzy w momencie rozmowy.
Czym jest asystent AI (RAG + LLM) w ubezpieczeniach?
To rozwiązanie, które łączy wyszukiwanie we własnych dokumentach firmy (RAG) z generowaniem odpowiedzi przez model językowy (LLM). Sam LLM pisze pięknie, ale nie zna Twoich OWU i potrafi zmyślać. RAG rozwiązuje to, podając modelowi konkretne fragmenty prawdziwych dokumentów, na których ma oprzeć odpowiedź.
W praktyce pytanie konsultanta (albo treść sprawy klienta) uruchamia wyszukanie najbardziej trafnych fragmentów w bazie OWU, taryf i procedur, a model formułuje odpowiedź osadzoną w tych źródłach. Konsultant dostaje więc nie ogólną gadkę, tylko odpowiedź opartą na dokumencie, który można wskazać. Dla UNIQA zbudowaliśmy to na modelu PLLuM, dopasowanym do polskiego języka obsługi ubezpieczeniowej.
Jak działa retrieval z OWU i taryf osadzony w źródłach?
Żeby asystent był wiarygodny, liczy się jakość warstwy retrievalu, a nie sam model. Dokumenty trzeba przygotować tak, aby model sięgał po właściwy fragment, a nie po przypadkowy akapit:
- podział dokumentów na sensowne fragmenty (OWU, taryfy, procedury), tak by zachować kontekst,
- indeksowanie wektorowe, które pozwala znaleźć treść po znaczeniu, nie po słowie kluczowym,
- osadzenie odpowiedzi w źródłach, czyli powiązanie wygenerowanej treści z konkretnym dokumentem,
- aktualizacja bazy wiedzy, gdy zmieniają się taryfy czy warunki, bez przebudowy całości.
Dzięki temu asystent odpowiada na podstawie aktualnej dokumentacji, a zespół ma pewność, skąd pochodzi odpowiedź. To właśnie ta warstwa decyduje, czy rozwiązanie jest demem, czy narzędziem produkcyjnym.
Jak wpiąć asystenta w CRM i kanały obsługi (omnichannel)?
Asystent nabiera wartości dopiero wtedy, gdy żyje tam, gdzie pracuje konsultant, a nie w osobnym oknie. Dlatego projektujemy go jako element istniejącego środowiska obsługi:
- AI Suggestions Panel z gotowymi odpowiedziami bezpośrednio w interfejsie konsultanta,
- automatyczne streszczenia zapisów do języka korzyści, zrozumiałego dla klienta,
- integracja z CRM i call center, aby asystent widział kontekst sprawy,
- jedno „źródło prawdy” w modelu omnichannel, spójne niezależnie od kanału kontaktu.
W projekcie dla UNIQA spięliśmy asystenta z CRM i systemem call center tak, by stał się wspólnym punktem odniesienia dla różnych kanałów. Konsultant nie szuka już odpowiedzi w kilku miejscach, tylko dostaje ją w kontekście sprawy.
Jak zadbać o bezpieczeństwo danych i środowisko (on-prem / private cloud)?
W ubezpieczeniach dane są wrażliwe, a wymogi regulacyjne wysokie, więc architektura musi to uwzględniać od pierwszego dnia. Asystenta uruchamiamy tam, gdzie dane firmy pozostają pod jej kontrolą: on-premises lub w chmurze prywatnej, bez wysyłania treści spraw do publicznych API modeli.
Takie podejście daje organizacji dwie rzeczy naraz: dane klientów nie opuszczają kontrolowanego środowiska, co upraszcza rozmowy z bezpieczeństwem i compliance, a firma zachowuje kontrolę nad modelem i bazą wiedzy. Dla UNIQA uruchomiliśmy asystenta właśnie w modelu on-prem / private cloud, co było warunkiem wejścia na produkcję.
Dlaczego człowiek w pętli jest kluczowy?
Bo celem nie jest zastąpienie konsultanta, tylko odciążenie go z żmudnego szukania. Asystent przygotowuje propozycję odpowiedzi i streszcza sprawę, ale to człowiek decyduje, co wysłać do klienta, łącząc szybkość maszyny z oceną i empatią pracownika.
Dla dyrektora obsługi ma to też wymiar praktyczny: człowiek w pętli chroni przed błędem i buduje zaufanie zespołu do narzędzia. Konsultanci szybciej adoptują asystenta, gdy widzą, że wspiera ich decyzje, a nie ocenia czy wypiera. Wiedza najlepszych pracowników staje się wtedy dostępna dla całego zespołu, zamiast zostawać w kilku głowach.
Jak mierzymy efekt wdrożenia (AHT, spójność)?
Wdrożenie asystenta AI to projekt biznesowy, więc mierzymy go liczbami. Najważniejsze kierunki, na które patrzymy razem z zespołem obsługi:
- AHT (średni czas obsługi) jako główny wskaźnik efektywności,
- koszt obsługi zgłoszenia, który spada, gdy konsultant szybciej domyka sprawy,
- spójność odpowiedzi, czyli ta sama, poprawna odpowiedź niezależnie od konsultanta,
- czas wdrożenia nowego pracownika, bo wiedza jest dostępna od pierwszego dnia.
Celem wdrożenia dla UNIQA była redukcja AHT i kosztu obsługi przy utrzymaniu jakości, dlatego metryki ustawiamy na starcie, a nie dokładamy na końcu. Tak najłatwiej pokazać zwrot z inwestycji osobom decyzyjnym.
Jakie kompetencje dostarczamy do projektu AI w ubezpieczeniach?
Takie wdrożenie wymaga zespołu, który rozumie model, obsługę i integracje naraz. Skład dobieramy pod konkretny zakres, a nie „na zapas”:
- inżynierowie LLM/RAG odpowiedzialni za model, warstwę retrievalu i jakość odpowiedzi,
- specjaliści MLOps utrzymujący rozwiązanie na produkcji (wdrożenia, monitoring, aktualizacje),
- integratorzy spinający asystenta z CRM, call center i bazą dokumentów,
- architekci danych i bezpieczeństwa dbający o środowisko on-prem / private cloud.
Nasza kompetencja AI/Data jest realna, a projekty GenAI, RAG i LLM realizujemy produkcyjnie, nie tylko w formie demo. To różnica między pokazem a rozwiązaniem, które codziennie wspiera realne rozmowy z klientami.
Jak robimy to w RITS?
Robimy to jako partner, który doprowadza AI do produkcji, a nie zatrzymuje się na proof of concept. Pokazuje to nasz projekt dla jednego z największych ubezpieczycieli w Polsce:
- dla UNIQA zbudowaliśmy asystenta AI dla contact center na modelu PLLuM (RAG + LLM), z AI Suggestions Panel w interfejsie konsultanta,
- dodaliśmy automatyczne streszczenia zapisów do języka korzyści i spięliśmy całość w omnichannelowe „źródło prawdy” zintegrowane z CRM i call center,
- uruchomiliśmy rozwiązanie on-prem / w chmurze prywatnej, tak by dane klientów pozostały pod kontrolą firmy,
- przeszliśmy od pilota w 8 tygodni do skali całej organizacji, z celem redukcji AHT i kosztu obsługi.
Najczęściej jest to wdrożenie AI wspierające istniejące procesy obsługi, a tam gdzie trzeba szybko uzupełnić kompetencje, dokładamy nasz zespół w wybranym modelu współpracy.
Od czego zacząć wdrożenie asystenta AI?
Zacznij od jednego, konkretnego scenariusza obsługi (np. najczęstsze pytania o zakres polisy) i od pytania, jakie dokumenty muszą zasilić bazę wiedzy. To wyznacza zakres pilota, wymagania wobec środowiska i metryki, po których poznasz efekt, zanim zainwestujesz w skalę. Różnice między modelami współpracy opisaliśmy w artykule o modelach współpracy IT.
Chcesz wdrożyć asystenta AI (RAG + LLM) w swoim contact center? Porozmawiajmy, dobierzemy zakres pilota i architekturę pod Twoją organizację.