Разработка AI-системы для страхового андеррайтинга

AI страховой андеррайтинг: где ломается процесс сейчас

В типовом процессе заявка попадает к андеррайтеру целиком: он открывает несколько систем, сверяет данные по договору, вручную считает риск и только потом выносит решение. Один разбор занимает от получаса до нескольких дней, и всё это время клиент ждёт. Сроки выдачи решения определяются загрузкой конкретного специалиста, а не сложностью риска.

Данные при этом разрознены: сведения по договорам лежат в учётной системе, история выплат — в другом хранилище, результаты осмотров и внешние проверки приходят файлами. Ключи не сходятся, один и тот же клиент встречается под разными написаниями, часть полей заполнена вручную. Прежде чем оценивать риск, специалист тратит время на сверку — и всё равно опирается на неполную картину.

Главная потеря здесь не скорость, а воспроизводимость. Логика оценки живёт в голове андеррайтера: пороги, исключения и негласные правила нигде не зафиксированы. Два специалиста на одинаковом профиле выдают разные решения, а объяснить задним числом, почему договор принят на особых условиях, не может никто. Для внутреннего аудита и надзорных проверок это прямой риск.

Автоматизация оценки риска начинается не с модели, а с того, что правила выносят из голов в явный, проверяемый вид, а данные по договорам сводят к единому профилю клиента. Тогда AI страховой андеррайтинг перестаёт быть экспериментом и становится управляемым процессом с прогнозируемым сроком решения. Ниже разбираем, как это закрывается.

Эффект для страхового портфеля: сроки, качество, отказы

До запуска типовое решение по полису авто или имущества занимает у андеррайтера десятки минут: сверка заявления с документами осмотра, проверка истории, поиск расхождений между источниками. После запуска такие заявки закрываются за минуты, а время специалиста уходит туда, где решение действительно неочевидно.

Первые недели: ручной разбор сжимается до исключений

Доля заявок, уходящих на ручной разбор, падает с большей части потока до узкого сегмента — нестандартные риски, крупные суммы, противоречивые документы. Система отдаёт решение вместе с обоснованием по каждому значимому полю, поэтому проверка занимает меньше времени, чем разбор с нуля: андеррайтер подтверждает или отклоняет вывод, а не собирает его.

Первый квартал: однородность решений и чистота данных

Разброс решений между специалистами сокращается — одинаковая заявка получает один и тот же класс риска независимо от того, кто её открыл и в какую смену. Работа с качеством данных по клиенту меняет картину портфеля: обязательные поля заполняются на входе, расхождения между источниками помечаются сразу, и класс ошибок «решение принято на неполных данных» перестаёт пополняться. Обмен данными идёт по отраслевым стандартам ACORD, поэтому структура заявки остаётся предсказуемой и при смене источника.

К концу квартала

Управление риском портфеля становится измеримым: видно, какие сегменты уходят в минус по убыточности, где накапливается концентрация и какие правила пора пересматривать. Решения принимаются по сводке, а не по памяти о прошлых сделках.

Варианты построения: ручной разбор, правила, модель

Выбор подхода здесь — функция от объёма потока, однородности данных и цены ошибки на одну заявку. На практике варианты редко конкурируют: они надстраиваются друг над другом по мере роста портфеля и накопления статистики.

Обычно мы собираем не один вариант, а связку: справочники закрывают частые случаи, балльная модель оценивает середину потока, специалисту уходят только граничные заявки с расхождениями из внешних проверок. Переход между режимами делается поэтапно — правила, справочники и баллы живут в одной схеме, поэтому ручной разбор можно сужать без потери уже накопленной логики и с возможностью вернуться к нему на спорных сегментах.

Этапы внедрения: от аудита данных до передачи модели

Работы идут последовательно: каждый следующий этап опирается на артефакты предыдущего, и мы не начинаем настройку контура, пока не согласована логика решения. Ниже — маршрут внедрения AI-системы для страхового андеррайтинга.

1. Аудит и опись исторических данных. Сводим источники заявок в единую опись: анкеты, историю выплат, внешние и скоринговые данные. Смотрим глубину периода, долю пропусков, расхождения между системами и поля, неизвестные на момент подачи, — такие признаки в модель не попадают.

2. Разметка заявок и логика решения. Восстанавливаем целевую метку: что считаем убыточным событием и на каком горизонте. Пограничные и спорные случаи разбираем вместе с андеррайтерами, чтобы модель училась на той же логике, что и люди.

3. Схема признаков. Согласуем, какие поля участвуют в расчёте, откуда берутся и как часто обновляются. Фиксируем правила обработки пропусков и выбросов — иначе на новых данных поведение разъедется.

4. Настройка контура оценки. Собираем сервис, который по заявке возвращает вероятность, а не «да/нет». Настраиваем версионирование моделей, журналирование входов и выходов, теневой режим: система считает параллельно с андеррайтером и не влияет на решения.

5. Проверка на контрольной выборке. Оцениваем качество на заявках, не участвовавших в обучении, с разбивкой по периодам и сегментам. Смотрим не только точность, но и калибровку: группа с оценкой около 0,2 должна давать близкую долю убытков.

6. Приёмка. Согласуем пороги, отчёт с метриками и разбором ошибок, регламент переобучения и условия, при которых заявка уходит на ручную проверку.

7. Передача и сопровождение. Отдаём документацию, схемы, доступы и обучение команды заказчика. Дальше следим за дрейфом данных и обновляем модель по согласованному регламенту.

Артефакты передачи: правила решений и регламенты разбора

Передача решения — это не доступ к модели. Модель без правил вокруг неё уходит в спорную заявку или в отказ при смене входных данных, поэтому вместе с контуром команда заказчика получает набор документов, по которым систему можно эксплуатировать, править и защищать перед проверяющими.

• Конфигурация контура — окружения, параметры запуска, схема резервного копирования и порядок отката на предыдущую версию модели при росте доли отклонений.
• Схема признаков и источников данных — какие поля подаются на вход, откуда берутся, как часто обновляются и что делать при недоступности источника.
• Правила решений и пороги срабатывания — какие сочетания признаков дают автоматическое согласование, какие уходят на ручной разбор, как менялись пороги и почему.
• Регламент разбора спорных случаев — кто разбирает, в какой срок, как фиксируется итог и как он возвращается в дообучение.
• Матрица доступа специалистов — роли андеррайтера, аналитика и администратора: кто видит персональные данные, кто меняет пороги, кто выгружает историю решений.
• Документация по модели — версия, набор признаков, метрики на контрольной выборке, известные ограничения и случаи, где модель не применяется.
• Порядок обновления модели — с какой периодичностью переобучаем, кто утверждает новую версию, по каким метрикам принимается решение о замене.

Каждый пункт согласуется с заказчиком до конца внедрения: после передачи вопросы «почему модель так решила» закрываются внутри команды, без нас.

Кейс: как сократили ручной разбор заявок

До внедрения поток заявок держался на небольшой группе андеррайтеров: типовое решение занимало 40-60 минут, а около трети заявок уходило на ручной разбор — нестандартные виды, расхождения в данных о клиенте, объекты с историей убытков. Опытные специалисты по одной и той же заявке давали разные решения примерно в каждом четвёртом случае, и расхождение всплывало уже при сопровождении договора, когда менять что-то поздно.

Метрики до и после

Изменили три вещи: правила андеррайтинга перевели в явные признаки вместо «на усмотрение специалиста», проверку сведений о клиенте и объекте вынесли перед вынесением решения, а спорные случаи модель помечает и передаёт человеку вместе с выжимкой по риску. Проверка идёт через Единый профиль клиента, поэтому расхождение между заявленными и фактическими данными видно до подписания, а не после.

Повторяемость стала измеримой: один и тот же набор признаков даёт один и тот же вывод независимо от того, кто смотрит заявку. Исчез целый класс ошибок — приём риска по непроверенным сведениям; именно он раньше всплывал на выплатах. Правила меняются в конфигурации, поэтому при новом продукте метрики не деградируют: часть заявок на ручном разборе пересматривается после каждого обновления справочников рисков.

Чем гибридный режим отличается от полностью автоматического?

Разница между режимами не в модели, а в том, кто подписывает итоговое решение. Полностью автоматическое решение означает, что результат уходит в дело без участия человека: модель его посчитала, система его зафиксировала. В гибридном режиме модель считает всегда, но часть случаев обязательно проходит через подтверждение специалиста.

Границу задаёт порог подтверждения — формальный набор условий, а не «на усмотрение». В него входят уверенность модели в собственном выводе, полнота и свежесть входных данных, вес сработавших факторов риска. Пока значения внутри заданного коридора, решение уходит автоматически; как только хотя бы одно выходит за границу — случай попадает в очередь на разбор.

Зона ответственности специалиста описана явно: он не перепроверяет поток целиком, а работает с теми случаями, где цена ошибки выше, и видит, какие признаки повлияли на вывод. Его правка не растворяется — она возвращается в накопленную статистику вместе с исходными данными.

Переключение режимов — это настройка, а не переписывание системы. Пороги и допустимая доля автоматических решений задаются отдельно по продуктам и каналам прихода заявок, поэтому один контур может работать строго на одном направлении и мягко на другом. Если доля расхождений растёт, порог поднимают и поток автоматики сужается.

По мере накопления статистики границу двигают по разбору расхождений: смотрят, где модель и специалист разошлись и чья оценка подтвердилась по факту. Так доля решений, проходящих без человека, растёт не за счёт снижения требований, а за счёт того, что пороги становятся точнее.

Частые сомнения: данные, точность, ответственность

Сомнения по такому проекту почти всегда одни и те же: хватит ли истории, кто отвечает за ошибку модели, что с персональными данными и не придётся ли останавливать текущий андеррайтинг на время внедрения. Ниже — как мы закрываем каждый из этих вопросов.

Как вы контролируете качество уже после запуска?

Считаем не одну метрику, а стабильность по когортам: продукт, канал, регион, месяц. Отслеживаем сдвиг входных распределений — если портрет заявителя меняется, модель об этом сообщает раньше, чем это заметят по убыточности. Переобучение идёт по регламенту и по триггеру, а не «когда-нибудь потом».

Как разбираются ошибки конкретного решения?

Каждое расхождение с вердиктом андеррайтера попадает в очередь разбора с полным следом: какие признаки повлияли и с каким вкладом. Андеррайтер помечает причину, метка уходит в обучающий набор. Раз в месяц вы видите долю расхождений и их структуру — понятно, где модель недоучилась, а где спорна сама методика.

Что со сведениями о клиентах?

Данные не покидают ваш контур: обучение и расчёты идут на вашей инфраструктуре или в выделенном контуре под вашим контролем. Персональные поля обезличиваются до подачи в модель, доступ разграничен по ролям, все обращения к данным журналируются. Выгрузка наружу не предусмотрена конструкцией решения.

Можно ли запустить это, не останавливая текущий процесс?

Да, запуск поэтапный. Сначала модель работает в теневом режиме и только рекомендует, решение остаётся за андеррайтером. Затем автоматизация включается на узком сегменте — например, на одном продукте или канале — и расширяется по мере подтверждённой точности. Откат к прежнему порядку по любому сегменту возвращается переключением настройки, без перестройки процесса.

Обсудим задачу и вернёмся с планом внедрения

Чтобы вернуться с оценкой и планом внедрения, а не с общими соображениями, нам нужен минимальный набор вводных. Оценка строится на ваших данных: без выборки закрытых заявок и правил, по которым риск считается сейчас, любая цифра будет угадыванием. Ниже — что обсудить на первой встрече и что попросим передать до старта работ.

• Описание процесса оценки риска: какие факторы влияют на решение, где проходят ручные проверки и какая доля заявок уходит на доработку.
• Обезличенная выборка заявок за период — с признаками, решением андеррайтера и фактическим исходом договора. На ней проверяем, воспроизводится ли ваша логика на данных.
• Перечень внешних источников сведений: бюро, реестры, телеметрия, сканы документов — с форматом ответа и ограничениями по частоте обращений.
• Контактные лица по смежным системам: полисный учёт, документооборот, канал приёма заявлений — чтобы согласовать обмен данными без посредников.
• Ограничения по срокам и режиму запуска: допустим ли теневой режим рядом с текущим процессом или решение сразу влияет на выдачу.
• Критерии приёмки: какую долю решений допустимо автоматизировать и при каком уровне убыточности результат считается рабочим.

С этим набором мы возвращаемся с оценкой и планом внедрения: этапы, состав работ, точки контроля качества модели и порядок вывода в продуктив. Опишите задачу — уточним недостающее и назовём сроки.