AI-андеррайтинг у страхуванні: де процес ламається зараз
У типовому процесі заявка потрапляє до андеррайтера цілком: він відкриває кілька систем, звіряє дані за договором, вручну рахує ризик і лише потім ухвалює рішення. Один розбір займає від пів години до кількох днів, і весь цей час клієнт чекає. Строки видачі рішення визначаються завантаженістю конкретного фахівця, а не складністю ризику.
Дані при цьому розрізнені: відомості за договорами лежать в обліковій системі, історія виплат — в іншому сховищі, результати оглядів і зовнішні перевірки надходять файлами.
Ключі не збігаються, один і той самий клієнт зустрічається під різними написаннями, частина полів заповнена вручну. Перш ніж оцінювати ризик, фахівець витрачає час на звірку — і все одно спирається на неповну картину.
Головна втрата тут не швидкість, а відтворюваність. Логіка оцінки живе в голові андеррайтера: пороги, винятки й негласні правила ніде не зафіксовані.
Два фахівці на однаковому профілі видають різні рішення, а пояснити заднім числом, чому договір ухвалено на особливих умовах, не може ніхто. Для внутрішнього аудиту й наглядових перевірок це прямий ризик.
Автоматизація оцінки ризику починається не з моделі, а з того, що правила виносять з голів у явний, перевірюваний вигляд, а дані за договорами зводять до єдиного профілю клієнта.
Тоді AI-андеррайтинг у страхуванні перестає бути експериментом і стає керованим процесом із прогнозованим строком рішення. Нижче розбираємо, як це закривається.
Ефект для страхового портфеля: строки, якість, відмови
До запуску типове рішення за полісом авто або майна займає в андеррайтера десятки хвилин: звірка заяви з документами огляду, перевірка історії, пошук розбіжностей між джерелами.
Після запуску такі заявки закриваються за хвилини, а час фахівця йде туди, де рішення справді неочевидне.
Перші тижні: ручний розбір стискається до винятків
Частка заявок, що йдуть на ручний розбір, падає з більшої частини потоку до вузького сегмента — нестандартні ризики, великі суми, суперечливі документи.
Система віддає рішення разом з обґрунтуванням за кожним значущим полем, тому перевірка займає менше часу, ніж розбір з нуля: андеррайтер підтверджує або відхиляє висновок, а не збирає його.
Перший квартал: однорідність рішень і чистота даних
Розкид рішень між фахівцями скорочується — однакова заявка отримує один і той самий клас ризику незалежно від того, хто її відкрив і в яку зміну.
Робота з якістю даних щодо клієнта змінює картину портфеля: обов’язкові поля заповнюються на вході, розбіжності між джерелами позначаються одразу, і клас помилок «рішення ухвалено на неповних даних» перестає поповнюватися.
Обмін даними відбувається за галузевими стандартами ACORD, тому структура заявки залишається передбачуваною і при зміні джерела.
До кінця кварталу
Управління ризиком портфеля стає вимірюваним: видно, які сегменти йдуть у мінус за збитковістю, де накопичується концентрація і які правила пора переглядати. Рішення ухвалюються за зведенням, а не за пам’яттю про минулі угоди.
Варіанти побудови: ручний розбір, правила, модель
Вибір підходу тут — функція від обсягу потоку, однорідності даних і ціни помилки на одну заявку. На практиці варіанти рідко конкурують: вони надбудовуються один над одним у міру зростання портфеля й накопичення статистики.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручний розбір за чек-лістом | Невеликий потік, нові продукти, нестандартні ризики | Рішення слабо відтворювані, швидкість упирається в людей, погано масштабується |
| Таблиці правил і довідники | Потік однорідний, логіка формалізується, потрібна пояснюваність кожної відмови | Розростаються до сотень умов, правила конфліктують, ламаються на рідкісних випадках |
| Бальна модель ризику | Є історія рішень і статистика збитків | Потребує чистих даних і періодичного перенавчання, слабо пояснює окремий випадок |
| Гібридний режим оцінки | Висока ціна помилки, потрібен контроль на граничних заявках | Модель рахує бал, фахівець підтверджує — частина виграшу за часом втрачається |
| Зовнішні джерела перевірки відомостей | Потрібно ловити розбіжності в даних заявника | Залежність від доступності сервісів, затримки відгуку, неповне покриття |
Зазвичай ми збираємо не один варіант, а зв’язку: довідники закривають часті випадки, бальна модель оцінює середину потоку, фахівцю йдуть лише граничні заявки з розбіжностями із зовнішніх перевірок.
Перехід між режимами робиться поетапно — правила, довідники й бали живуть в одній схемі, тому ручний розбір можна звужувати без втрати вже накопиченої логіки та з можливістю повернутися до нього на спірних сегментах.
Етапи впровадження: від аудиту даних до передачі моделі
Роботи йдуть послідовно: кожен наступний етап спирається на артефакти попереднього, і ми не починаємо налаштування контуру, поки не погоджена логіка рішення. Нижче — маршрут упровадження AI-системи для страхового андеррайтингу.
-
Аудит та опис історичних даних. Зводимо джерела заявок в єдиний опис: анкети, історію виплат, зовнішні та скорингові дані. Дивимося глибину періоду, частку пропусків, розбіжності між системами й поля, невідомі на момент подання, — такі ознаки в модель не потрапляють.
-
Розмітка заявок і логіка рішення. Відновлюємо цільову мітку: що вважаємо збитковою подією і на якому горизонті. Пограничні та спірні випадки розбираємо разом з андеррайтерами, щоб модель навчалася на тій самій логіці, що й люди.
-
Схема ознак. Погоджуємо, які поля беруть участь у розрахунку, звідки беруться і як часто оновлюються. Фіксуємо правила обробки пропусків і викидів — інакше на нових даних поведінка розійдеться.
-
Налаштування контуру оцінки. Збираємо сервіс, який за заявкою повертає ймовірність, а не «так/ні». Налаштовуємо версіонування моделей, журналювання входів і виходів, тіньовий режим: система рахує паралельно з андеррайтером і не впливає на рішення.
-
Перевірка на контрольній вибірці. Оцінюємо якість на заявках, що не брали участі в навчанні, з розбивкою за періодами й сегментами. Дивимося не лише точність, а й калібрування: група з оцінкою близько 0,2 має давати близьку частку збитків.
-
Приймання. Погоджуємо пороги, звіт з метриками й розбором помилок, регламент перенавчання та умови, за яких заявка йде на ручну перевірку.
-
Передача та супровід. Віддаємо документацію, схеми, доступи й навчання команди замовника. Далі стежимо за дрейфом даних і оновлюємо модель за погодженим регламентом.
Артефакти передачі: правила рішень і регламенти розбору
Передача рішення — це не доступ до моделі. Модель без правил навколо неї йде в спірну заявку або у відмову при зміні вхідних даних, тому разом з контуром команда замовника отримує набір документів, за якими систему можна експлуатувати, правити й захищати перед перевіряльниками.
- Конфігурація контуру — середовища, параметри запуску, схема резервного копіювання та порядок відкату до попередньої версії моделі при зростанні частки відхилень.
- Схема ознак і джерел даних — які поля подаються на вхід, звідки беруться, як часто оновлюються і що робити при недоступності джерела.
- Правила рішень і пороги спрацювання — які поєднання ознак дають автоматичне погодження, які йдуть на ручний розбір, як змінювалися пороги і чому.
- Регламент розбору спірних випадків — хто розбирає, у який строк, як фіксується підсумок і як він повертається в донавчання.
- Матриця доступу фахівців — ролі андеррайтера, аналітика й адміністратора: хто бачить персональні дані, хто змінює пороги, хто вивантажує історію рішень.
- Документація щодо моделі — версія, набір ознак, метрики на контрольній вибірці, відомі обмеження та випадки, де модель не застосовується.
- Порядок оновлення моделі — з якою періодичністю перенавчаємо, хто затверджує нову версію, за якими метриками ухвалюється рішення про заміну.
Кожен пункт погоджується із замовником до кінця впровадження: після передачі питання «чому модель так вирішила» закриваються всередині команди, без нас.
Кейс: як скоротили ручний розбір заявок
До впровадження потік заявок тримався на невеликій групі андеррайтерів: типове рішення займало 40-60 хвилин, а близько третини заявок ішло на ручний розбір — нестандартні види, розбіжності в даних про клієнта, об’єкти з історією збитків.
Досвідчені фахівці за однією і тією самою заявкою давали різні рішення приблизно в кожному четвертому випадку, і розбіжність спливала вже при супроводі договору, коли щось міняти пізно.
Метрики до і після
| Метрика | До впровадження | Після |
|---|---|---|
| Час рішення за заявкою | 40-60 хвилин | 3-5 хвилин |
| Частка заявок на ручному розборі | близько третини | 12-15% |
| Розбіжність рішень між фахівцями | ~25% | 4-6% |
| Ризики за неперевіреними відомостями | знаходили при врегулюванні | відсікаються на вході |
Змінили три речі: правила андеррайтингу перевели в явні ознаки замість «на розсуд фахівця», перевірку відомостей про клієнта й об’єкт винесли перед ухваленням рішення, а спірні випадки модель позначає й передає людині разом з вижимкою щодо ризику.
Перевірка йде через Єдиний профіль клієнта, тому розбіжність між заявленими та фактичними даними видно до підписання, а не після.
Повторюваність стала вимірюваною: один і той самий набір ознак дає один і той самий висновок незалежно від того, хто дивиться заявку. Зник цілий клас помилок — прийняття ризику за неперевіреними відомостями; саме він раніше спливав на виплатах.
Правила змінюються в конфігурації, тому при новому продукті метрики не деградують: частина заявок на ручному розборі переглядається після кожного оновлення довідників ризиків.
Чим гібридний режим відрізняється від повністю автоматичного?
Різниця між режимами не в моделі, а в тому, хто підписує підсумкове рішення. Повністю автоматичне рішення означає, що результат іде в справу без участі людини: модель його порахувала, система його зафіксувала.
У гібридному режимі модель рахує завжди, але частина випадків обов’язково проходить через підтвердження фахівця.
Межу задає поріг підтвердження — формальний набір умов, а не «на розсуд». До нього входять впевненість моделі у власному висновку, повнота й свіжість вхідних даних, вага факторів ризику, що спрацювали.
Поки значення всередині заданого коридору, рішення йде автоматично; щойно хоча б одне виходить за межу — випадок потрапляє в чергу на розбір.
Зона відповідальності фахівця описана явно: він не переперевіряє потік цілком, а працює з тими випадками, де ціна помилки вища, і бачить, які ознаки вплинули на висновок. Його правка не розчиняється — вона повертається в накопичену статистику разом з вихідними даними.
Перемикання режимів — це налаштування, а не переписування системи. Пороги й допустима частка автоматичних рішень задаються окремо за продуктами й каналами надходження заявок, тому один контур може працювати строго на одному напрямі й м’яко на іншому. Якщо частка розбіжностей зростає, поріг піднімають і потік автоматики звужується.
У міру накопичення статистики межу рухають за розбором розбіжностей: дивляться, де модель і фахівець розійшлися і чия оцінка підтвердилася за фактом. Так частка рішень, що проходять без людини, зростає не за рахунок зниження вимог, а за рахунок того, що пороги стають точнішими.
Часті сумніви: дані, точність, відповідальність
Сумніви щодо такого проєкту майже завжди одні й ті самі: чи вистачить історії, хто відповідає за помилку моделі, що з персональними даними і чи не доведеться зупиняти поточний андеррайтинг на час впровадження. Нижче — як ми закриваємо кожне з цих питань.
Історичних даних мало і вони різнорідні. Модель узагалі навчиться?
Навчаємо не з нуля. Базова модель уже налаштована на схожих портфелях, а ваші дані використовуються для калібрування на вашій шкалі ризику.
На старті до неї додаються правила андеррайтерів і ознаки з анкет та вже доступних вам джерел, тому навіть кілька тисяч закритих договорів дають робочу розділяючу здатність.
У міру накопичення своєї статистики модель донавчається, і частка рішень, ухвалених без правок, зростає від місяця до місяця.
Як ви контролюєте якість уже після запуску?
Вважаємо не одну метрику, а стабільність за когортами: продукт, канал, регіон, місяць. Відстежуємо зсув вхідних розподілів — якщо портрет заявника змінюється, модель повідомляє про це раніше, ніж це помітять за збитковістю. Перенавчання йде за регламентом і за тригером, а не «колись потім».
Як розбираються помилки конкретного рішення?
Кожна розбіжність із вердиктом андеррайтера потрапляє в чергу розбору з повним слідом: які ознаки вплинули і з яким внеском. Андеррайтер позначає причину, мітка йде в навчальний набір.
Раз на місяць ви бачите частку розбіжностей та їхню структуру — зрозуміло, де модель недонавчилася, а де спірна сама методика.
Що з відомостями про клієнтів?
Дані не покидають ваш контур: навчання й розрахунки йдуть на вашій інфраструктурі або у виділеному контурі під вашим контролем. Персональні поля знеособлюються до подання в модель, доступ розмежовано за ролями, усі звернення до даних журналюються. Вивантаження назовні не передбачено конструкцією рішення.
Чи можна запустити це, не зупиняючи поточний процес?
Так, запуск поетапний. Спочатку модель працює в тіньовому режимі й лише рекомендує, рішення залишається за андеррайтером. Потім автоматизація вмикається на вузькому сегменті — наприклад, на одному продукті або каналі — і розширюється в міру підтвердженої точності.
Відкат до попереднього порядку за будь-яким сегментом повертається перемиканням налаштування, без перебудови процесу.
Обговоримо задачу й повернемося з планом впровадження
Щоб повернутися з оцінкою та планом впровадження, а не із загальними міркуваннями, нам потрібен мінімальний набір ввідних. Оцінка будується на ваших даних: без вибірки закритих заявок і правил, за якими ризик рахується зараз, будь-яка цифра буде вгадуванням. Нижче — що обговорити на першій зустрічі й що попросимо передати до старту робіт.
- Опис процесу оцінки ризику: які фактори впливають на рішення, де проходять ручні перевірки і яка частка заявок іде на доопрацювання.
- Знеособлена вибірка заявок за період — з ознаками, рішенням андеррайтера й фактичним результатом договору. На ній перевіряємо, чи відтворюється ваша логіка на даних.
- Перелік зовнішніх джерел відомостей: бюро, реєстри, телеметрія, скани документів — з форматом відповіді й обмеженнями за частотою звернень.
- Контактні особи з суміжних систем: полісний облік, документообіг, канал приймання заяв — щоб погодити обмін даними без посередників.
- Обмеження за строками й режимом запуску: чи допустимий тіньовий режим поруч із поточним процесом або рішення одразу впливає на видачу.
- Критерії приймання: яку частку рішень допустимо автоматизувати і за якого рівня збитковості результат вважається робочим.
Із цим набором ми повертаємося з оцінкою та планом впровадження: етапи, склад робіт, точки контролю якості моделі та порядок виведення в продуктив. Опишіть задачу — уточнимо те, чого бракує, і назвемо строки.
