ШІ для страхування: ліквідація збитків, екстракція документів, класифікація

Відділ ліквідації збитків, куди щодня надходять сотні заявок: фото пошкоджень, скани полісів, рахунки за ремонт, протоколи поліції, заяви, кошториси автосервісів. Хтось все це відкриває, переписує номери полісів і суми в систему, сортує за типом збитку та направляє до відповідного ліквідатора. Це не робота, яка потребує експертної оцінки — це переписування та сортування. І саме тут ШІ має реальний сенс. Проблема починається, коли хтось обіцяє «автоматичну ліквідацію без людини»: це інша розмова, що зачіпає права споживача, RODO та AI Act. Нижче розділяємо одне від іншого, без обіцянок, яких у страхуванні неможливо дотриматися.

Заявка на відшкодування збитку — це файл різноманітних документів у різних форматах: PDF, фото з телефону, скани, іноді нерозбірливі рукописні нотатки. Перший реальний напрямок — перетворення цієї купи на структуровані дані. OCR зчитує текст із зображення, а мовна модель витягує з нього конкретні поля: номер поліса, дату події, суму з рахунку, дані транспортного засобу, місце збитку.

Тут потрібно бути чесним щодо точності. На чистих, типових документах (рахунки, кошториси автосервісів, стандартні бланки) добре налаштована екстракція даних зазвичай досягає високої точності на рівні полів — часто понад 90%, на стандартизованих формах ще вище. Але на рукописних документах, поганих сканах чи нетипових макетах точність падає і буває непередбачуваною. Тому не можна припускати, що зчитана сума є істиною — для полів, що впливають на виплату, людина підтверджує, а система показує джерело (фрагмент документа), з якого взято значення.

Умовою успіху є порядок у даних на стороні компанії. Як організувати документи та метадані, щоб ШІ мала з чого працювати, описуємо в підготовці корпоративних даних під ШІ.

Другий напрямок — спрямування заявки туди, куди вона має потрапити, перш ніж хтось прочитає її вручну. Класифікатор розпізнає тип збитку (транспортний, майновий, особистий, ОС, АС), терміновість, повноту документів і призначає справу до відповідної черги або ліквідатора. Та сама заявка може також отримати мітку «брак документів» і автоматично викликати запит на доповнення.

Шаблон тут ідентичний, як в обслуговуванні клієнтів: ШІ фільтрує та сортує, людина вирішує в граничних випадках. Механіку цього процесу розбираємо на складові в класифікації та маршрутизації заявок ШІ. Користь вимірювана: скорочується час від надходження заявки до першого контакту з відповідальною особою, а прості, повні справи не чекають в одній черзі з складними. Той самий двигун маршрутизації, до речі, працює і за межами страхування — аналогічно ми його будуємо в ШІ для логістики та складу.

Межа проста: класифікація спрямовує справу, але не вирішує вимогу. Мітка «ймовірно тотальна шкода» — це підказка для ліквідатора, а не рішення про виплату.

Це напрямок, в якому найлегше зловживати мовою — і завдати реальної шкоди клієнту. Скажемо прямо: ШІ не «виявляє шахраїв». ШІ виявляє патерни та відхилення, які в історичних даних корелювали зі спірними справами або підтвердженими зловживаннями — і піднімає прапорець для перевірки людиною.

Різниця не косметична. Сигнал шахрайства — це: нетипова частота збитків за полісом, розбіжність між описом і фото, той самий автосервіс у багатьох підозрілих справах, дата події одразу після укладення поліса. Кожен із цих сигналів має невинне пояснення. Тому прапорець означає «придивись уважніше», а не «відмов у виплаті». Рішення про відмову чи направлення на розслідування приймає людина, яка несе за нього юридичну відповідальність — модель її не несе.

Це також напрямок, прямо зачеплений AI Act: система, що оцінює ризик, пов'язаний з клієнтом, або впливає на доступ до виплати, може бути системою високого ризику, з обов'язками прозорості, людського нагляду та документації. Автоматична відмова у виплаті виключно на основі моделі, без реальної можливості втручання людини, — це сценарій, якого ми не рекомендуємо — і юридично, і етично.

Четвертий напрямок — обробка запитань клієнта про статус збитку, покриття поліса чи необхідні документи. Агент, заснований на знаннях з полісів та правил, відповідає на типові запитання («які документи потрібно додати», «на якому етапі моя справа»), звільняючи консультантів від повторюваних запитів.

Тут діють два правила, які ми не обходимо. По-перше, асистент має бути ґрунтованим на реальних документах клієнта та компанії — модель без цієї опори може вигадати умову поліса, якої немає. По-друге, коли запитання стосується індивідуального рішення щодо вимоги, асистент передає справу людині, а не імпровізує. Як будуємо таку ґрунтовану систему на корпоративних знаннях, показуємо в корпоративному GPT на базі знань.

Запитання про статус працюють найкраще, коли асистент зчитує дані з системи (етап справи, відсутні документи), а не вгадує. Тоді відповідь конкретна та перевіряється, а клієнт отримує інформацію миттєво, у будь-який час.

Страхування — це регульований сектор, а дані про збитки часто є чутливими — у особистих збитках навіть дані про здоров'я. Тому архітектура даних тут не технічна деталь, а рішення на рівні проекту.

Три принципи, яких ми завжди дотримуємося:

• Людина вирішує про виплату та кваліфікацію. ШІ готує, класифікує та сигналізує; рішення про визнання, відмову чи розмір виплати приймає уповноважена особа. Це вимога і юридична, і операційна.
• Усвідомлений вибір щодо локалізації даних. Чутливі дані можуть залишатися в інфраструктурі компанії завдяки моделям, що запускаються локально або у постачальника з гарантією обробки в ЄС та договором доручення. Регуляторний контекст упорядковуємо в обов'язках компаній за AI Act та RODO у 2026 році.
• Прозорість для клієнта. Якщо рішення суттєво підтримане автоматизацією, клієнт має право це знати та право на оскарження до людини. Це не предмет для переговорів.

Системи суто адміністративні (екстракція рахунків у систему, маршрутизація заявок без вирішення) зазвичай не є високоризиковими. Але система, що оцінює ризик клієнта, впливає на доступ до виплати або автоматизує рішення — може такою бути. Класифікацію варто підтвердити для конкретного застосування, перш ніж щось потрапить у продакшн.

Чесний порядок менш ефектний, ніж обіцянки зі слайдів. Спочатку одна вузька проблема з вимірюваним витратами — зазвичай екстракція даних з одного типу документів або маршрутизація одного виду заявок. Потім перевірка, чи дані в стані, в якому ШІ має з чого працювати. Далі пілот поруч із поточним процесом: ШІ визначає та готує, ліквідатор все одно вирішує, а ми вимірюємо реальну точність, перш ніж щось почне працювати самостійно. Лише коли цифри збігаються — поступове розширення, зі збереженим наглядом там, де йдеться про гроші клієнта.

Це не шлях на коротку дистанцію. Але це шлях, який не закінчується системою, якій ніхто не довіряє, бо одного разу відмовила у виплаті на основі сигналу, який виявився хибною тривогою.

Не рекомендуємо цього, і в багатьох випадках закон цього не дозволяє. ШІ може прискорити обробку — витягти дані з документів, класифікувати заявку, підготувати проєкт рішення — але визнання вимоги, її розмір чи відмова — це рішення, яке приймає уповноважена особа. При суттєво автоматизованих рішеннях клієнт також має право на втручання людини, що випливає з RODO та AI Act.

Це залежить від якості документа. На чистих, типових документах (рахунки, стандартні бланки) добре налаштована екстракція даних зазвичай досягає високої точності на рівні полів — часто понад 90%. На поганих сканах, рукописних документах чи нетипових макетах точність падає і буває непередбачуваною, тому поля, що впливають на виплату, завжди підтверджує людина, а система показує джерело значення.

Ні. Модель виявляє сигнали та відхилення, які історично корелювали зі спірними справами, і піднімає прапорець для перевірки — це підказка, а не вердикт. Кожен сигнал має невинне пояснення, тому рішення про направлення на розслідування чи відмову приймає людина, яка несе за нього відповідальність. Автоматична відмова виключно на основі моделі — це сценарій, якого ми не рекомендуємо.

Це рішення, а не необхідність. Чутливі дані — в тому числі дані про здоров'я в особистих збитках — можуть залишатися в інфраструктурі компанії завдяки моделям, що запускаються локально або у постачальника з гарантією обробки в ЄС та договором доручення. У регульованому секторі варто прийняти це рішення усвідомлено на самому початку, бо воно визначає всю архітектуру проекту.

Іноді так. Система, що оцінює ризик, пов'язаний з клієнтом, або впливає на доступ до виплати, може бути системою високого ризику згідно з AI Act — з обов'язками прозорості, людського нагляду та документації. Системи суто адміністративні, як екстракція рахунків чи маршрутизація заявок без вирішення, зазвичай не потрапляють у цю категорію, але класифікацію варто підтвердити для конкретного застосування.