Underwriting przez lata opierał się na doświadczeniu, tabelach taryfowych i arkuszach, które znał tylko ich autor. Dziś decyzja o przyjęciu ryzyka i jego wycenie powstaje szybciej, na większej liczbie danych i pod rosnącą presją regulatora, który pyta, dlaczego polisa dostała taką, a nie inną cenę. Dla dyrektora underwritingu, ryzyka czy aktuariatu oznacza to jedno: ocena ryzyka staje się produktem cyfrowym, a jej jakość zależy od oprogramowania tak samo jak od wiedzy ekspertów.
Z naszego doświadczenia najtrudniejsze nie jest wymyślenie modelu scoringu, lecz spięcie go z procesem decyzyjnym, danymi i ludźmi, którzy podejmują decyzje. Nie mamy w tym obszarze gotowego case study, które moglibyśmy tu pokazać, więc powiemy wprost: dostarczamy przede wszystkim kompetencje i ludzi, którzy to budują, w modelu wzmocnienia zespołu lub zespołu dedykowanego, z realnym zapleczem data i ML w Grupie RITS.
Po co ubezpieczycielowi cyfrowy underwriting?
Bo rośnie liczba decyzji, a maleje czas na każdą z nich. Underwriter nie ma już komfortu analizowania wniosku przez kilka dni, a jednocześnie musi być w stanie obronić każdą decyzję przed audytem i regulatorem. Cyfrowy underwriting przesuwa rutynę do systemu, a ekspertowi zostawia to, co wymaga osądu.
W praktyce zależy nam na trzech efektach: szybszej i powtarzalnej decyzji, spójnej wycenie ryzyka niezależnej od tego, kto akurat prowadzi wniosek, oraz pełnej ścieżce audytowej, w której widać, jakie dane i reguły zadecydowały o wyniku. To nie jest zastąpienie underwritera, tylko wyposażenie go w narzędzie, które liczy szybciej i nic nie zapomina.
Jak zbudować modele scoringu ryzyka i wyceny?
Model scoringu to nie jeden algorytm, lecz łańcuch: od danych wejściowych, przez cechy, po wynik, który trafia do procesu. Budujemy go tak, żeby dało się go utrzymywać i tłumaczyć, a nie tylko uruchomić raz na prezentacji.
- trenowanie na danych historycznych portfela, szkodowości i źródłach zewnętrznych, z kontrolą jakości i wersjonowaniem danych,
- udostępnienie modelu przez API, żeby scoring był wołany z systemu polisowego, portalu agenta czy procesu zakupowego w czasie rzeczywistym,
- wyjaśnialność wyniku (feature importance, reason codes), bo decyzja musi być zrozumiała dla underwritera, klienta i audytora,
- monitoring dryfu modelu i reguły jego wycofania, zanim zacznie mylić się na nowych danych.
Modele data i ML opieramy o kompetencje Grupy RITS, w tym nasze zespoły AI, LLM i danych, gdzie realizowaliśmy projekty z obszaru LLM, RAG i uczenia maszynowego. To realne doświadczenie w danych, choć nie udajemy, że pochodzi ono z wdrożenia u konkretnego ubezpieczyciela.
Jak zaprojektować stanowisko pracy underwritera (workbench)?
Workbench to miejsce, w którym underwriter spędza cały dzień, więc liczy się każdy klik. Dobre stanowisko zbiera dane w jednym widoku zamiast zmuszać do przeskakiwania między systemami, i prowadzi przez decyzję, zamiast ją tylko rejestrować.
- agregacja danych o ryzyku z systemu polisowego, źródeł zewnętrznych i wyniku modelu w jednym ekranie,
- reguły akceptacji i wyjątków, które automatycznie przepuszczają proste przypadki, a trudne kierują do człowieka,
- kolejka decyzji z priorytetami, SLA i jasnym statusem każdego wniosku,
- ślad decyzji zapisywany automatycznie, z komentarzem underwritera i wartościami, na których oparł wynik.
Projektujemy workbench pod realny rytm pracy zespołu, a nie pod schemat z prezentacji. Najwięcej wartości daje tu zwykle automatyzacja prostych decyzji, która uwalnia czas ekspertów na przypadki naprawdę wymagające osądu.
Jak wykrywać nadużycia w procesie ubezpieczeniowym?
Wykrywanie nadużyć działa najlepiej, gdy łączy dwa podejścia. Reguły wychwytują to, co już znamy, a modele anomalii to, czego jeszcze nie opisaliśmy regułą.
- warstwa reguł oparta na znanych schematach wyłudzeń i czerwonych flagach, czytelna dla zespołu antyfraudowego,
- modele wykrywania anomalii, które wskazują nietypowe wzorce we wnioskach, szkodach i powiązaniach między podmiotami,
- scoring ryzyka nadużycia dołączany do wniosku, tak żeby underwriter widział sygnał od razu, a nie po wypłacie,
- pętla zwrotna z potwierdzonych przypadków, która douczanie modeli opiera na realnych decyzjach zespołu.
Celem nie jest blokowanie klientów, lecz kierowanie uwagi tam, gdzie prawdopodobieństwo nadużycia jest realne, przy minimalnej liczbie fałszywych alarmów.
Jak raportować ekspozycję portfela ryzyk?
Pojedyncza decyzja to jedno, ale dyrektor ryzyka patrzy na całość. Raportowanie ekspozycji łączy decyzje underwritingowe w obraz portfela: rozkład ryzyk, kumulacje, limity i ich wykorzystanie. Budujemy warstwę raportową tak, żeby odpowiadała na pytania zarządu i regulatora bez ręcznego sklejania danych z kilku systemów. Kluczowe jest tu, by liczby pochodziły z tego samego źródła co decyzje, więc raport i operacja opierają się na spójnym modelu danych, a nie na dwóch różnych prawdach.
Jak wymieniać dane z reasekuracją?
Reasekuracja żyje danymi, które dostaje od cedenta, więc wymiana musi być ustrukturyzowana i powtarzalna. Automatyzujemy przygotowanie bordero, raportów ekspozycji i danych szkodowych w formatach uzgodnionych z reasekuratorem, spinamy to z harmonogramem raportowania i dbamy o kontrolę kompletności, zanim dane wyjdą na zewnątrz. Dobrze zaprojektowana wymiana skraca czas zamknięcia okresu i ogranicza spory wynikające z rozjechanych liczb.
Jak utrzymać człowieka w pętli decyzyjnej?
Model podpowiada, ale odpowiedzialność za ryzyko nosi człowiek, i tak powinno zostać. Projektujemy proces tak, żeby underwriter mógł przyjąć, odrzucić lub nadpisać rekomendację modelu, zawsze z uzasadnieniem, które zostaje w systemie. Takie nadpisania są potem cennym materiałem: pokazują, gdzie model się myli i co warto poprawić. Człowiek w pętli to nie formalność na potrzeby zgodności, tylko mechanizm, który chroni przed ślepym zaufaniem do automatu i jednocześnie uczy system.
Jakie kompetencje dostarczamy do projektów underwritingowych?
Obsadzamy role pod konkretny etap projektu, a nie „na zapas”. W zależności od potrzeby zespół może objąć:
- inżynierów danych i ML, którzy budują i utrzymują modele scoringu oraz wykrywania anomalii,
- programistów backendu i integracji, spinających modele, systemy polisowe i API,
- specjalistów od frontendu i UX, projektujących workbench underwritera,
- architektów i DevOps, odpowiadających za skalowanie, bezpieczeństwo danych i wdrożenia.
Nasze kompetencje data i ML są realne (Grupa RITS, w tym nasze zespoły AI, LLM i danych, z projektami GenAI, RAG i uczenia maszynowego), a doświadczenie w wymagających projektach przemysłowych przekłada się na dyscyplinę inżynierską, której wymaga środowisko regulowane.
Jak robimy to w RITS?
Działamy jako partner nearshore z Polski, który wzmacnia zespół ubezpieczyciela kompetencjami, a nie sprzedaje gotowego pudełka. Zaczynamy od Twojego procesu i danych, dobieramy skład pod specyfikę projektu, a kompetencje weryfikujemy przed startem. Pracujemy w zbliżonej strefie czasowej, więc nasi ludzie wchodzą w przeglądy kodu, spotkania i rytm pracy bez długiego rozruchu. Najczęściej robimy to jako dedykowane oprogramowanie budowane przez nasz zespół albo w modelu wzmocnienia zespołu, gdy trzeba szybko uzupełnić brakujące kompetencje data, ML lub inżynierskie.
Od czego zacząć wsparcie underwritingu?
Zacznij od jednej decyzji, która boli najbardziej: najdłużej trwa, najczęściej się myli albo najtrudniej ją uzasadnić. Wokół niej opisz dane, reguły i role, a potem zdecyduj, czy potrzebujesz modelu, lepszego workbenchu, czy obu naraz. Taki pierwszy wycinek daje mierzalny efekt i wyznacza architekturę dla reszty. Różnice między modelami współpracy opisaliśmy w artykule o modelach współpracy IT.
Chcesz wesprzeć underwriting i ocenę ryzyka? Porozmawiajmy, dobierzemy zespół i kompetencje pod Twój proces.