Сбербанк страхование жизни: трансформация данных - к выплатам за 5 минут, Максим Чернухин

Максим Чернухин, СТО клиентского сервиса, СберСтрахование. "Искусственный интеллект и большие данные: от экспериментов к эффекту", конференция TAdviser.

Опыт цифровой трансформации компании и перестройки архитектуры данных на профильном мероприятии по развитию ИТ в финансовом секторе.

Борьба с операционной неэффективностью

В страховании жизни исторически наблюдалось значительное отставание от банковских стандартов скорости обслуживания, которое, по мнению автора, составляет около 10 лет. Ранее процесс рассмотрения заявления о выплате (например, в случае травмы, когда пользователь «ногу поломало») занимал в среднем 15 дней. В сравнении с современным банкингом, где перевод денег со счета на счет происходит за секунды, такие сроки выглядят недопустимыми. При этом компания не могла точно определить, на каком этапе происходят основные задержки из-за отсутствия прозрачной аналитики и единого понимания процессов.

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

После пересборки процессов срок сократился до 5 дней, а затем, благодаря технологическому рывку в прошлом году, был достигнут показатель в 5 минут (и зачастую даже меньше), когда деньги отправляются прямо на счет пользователя. «В России этого не было, в Европе не было, в Америке не было», — отмечает автор, подчеркивая уникальность достижения для рынка страхования жизни, при этом добавляя, что по китайскому рынку судить сложно из-за его масштабности.

Интеграция LLM в бизнес-процессы

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

Процесс выглядит следующим образом: сначала компьютерное зрение распознает документ, а затем LLM извлекает из него диагноз. Автор подчеркивает, что с точки зрения традиционного распарсинга вытащить диагноз «вообще нереально», тогда как LLM делает это мгновенно и коротко по запросу. Эти структурированные данные передаются в обычную обученную ML-модель, которая принимает решение о выплате на основе определенных весов. В итоге 50% заявлений по убыткам теперь обрабатываются за минимальное время. При этом финальный контроль остается за человеком: если система решает не платить, сотрудник должен посмотреть данные и обосновать отказ.

Проблема «информационного хаоса» и Excel

До внедрения новой системы аналитика опиралась на таблицы Excel, что создавало ситуацию, когда каждый отдел имел свою интерпретацию статусов прохождения заявки. Это приводило к тому, что один сотрудник считал задачу завершенной сегодня, а другой — что процесс еще даже не начался или будет закончен через два дня. В таких условиях определение общей длительности бизнес-процессов в компании требовало колоссальных усилий.

Такой подход делал создание любой новой метрики или отчета крайне трудозатратным процессом, так как каждая «путеводная звезда» для аналитики требовала тяжелого ручного труда. Автор утверждает: «пока компания не пройдет Data-driven, ничего AI-native не получится». Без единого источника истины и качественной работы с данными любые попытки внедрить продвинутый ИИ будут иметь ограниченный эффект, так как прежде необходимо научиться работать с самими данными.

Создание единой системы трейсинга

Для решения проблемы разрозненности данных в разных системах был разработан подход Global Business ID. Это уникальный идентификатор, который присваивается объекту (заявлению) в момент его генерации и сопровождает его через все этапы жизненного цикла: от момента подачи заявления пользователем до проведения платежа в 1С.

Это позволило перейти от «фотографий разного качества» к своего рода «онлайн-трансляции» бизнес-процесса, которая работает в реальном времени. Теперь компания точно знает, где именно застревает объект, кто был инициатором изменений и какой статус имеет сущность, не обращаясь в сторонние системы, где данные могли уже исчезнуть. Такой подход исключает необходимость экстраполяции данных и вычисления медианных значений, позволяя видеть реальную картину. Это решает проблему дороговизна интеграций в классических ДВХ, где доработка АЛАП при добавлении новых данных растет экспоненциально, а обновление информации могло занимать от часа до недели.

Техническая реализация Data Lake

Для обеспечения качества данных была выстроена архитектура с использованием Kafka и механизмов строгой валидации. Чтобы Data Lake не превратилось в «болото», для каждого бизнес-объекта была проработана схема, описывающая данные и правила их проверки. Если приходящие данные не соответствуют правилам (например, содержат дубликаты или логические ошибки, когда дата начала позже даты окончания), они отправляются в Dead Letter Queue.

Система-источник, которая «закинула фигню», обязана самостоятельно разобрать ошибки из этой очереди и догрузить корректные данные. Только валидные события попадают в Data Lake. Это превращает хранилище в качественный фундамент, на котором можно быстро строить витрины данных или использовать AI-агентов. Благодаря детальному описанию каждого поля и объекта, агент может самостоятельно сконструировать SQL-запрос к данным (например, для расчета среднего времени закрытия счетов) и выдать ответ без участия программиста.

Принципы масштабирования и выводы

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

Особое внимание уделили борьбе с избыточностью: аналитиков приучают сохранять только те данные, которые действительно нужны для текущего бизнес-процесса. Автор критикует подход сохранения данных «на будущее», утверждая, что мастер системы не должен хранить лишнее. Несмотря на рост объемов данных до терабайтов, использование холодного хранилища (например, S3) делает этот процесс экономически целесообразным.

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

Оптимизация клиентского пути через радикальное сокращение сроков

Переход от среднего срока обработки заявления в 15 дней к выплате за 5 минут стал возможен благодаря пересборке процессов и внедрению LLM. Искусственный интеллект используется не как самоцель, а для решения конкретных узких мест: например, компьютерное зрение распознает документы, а LLM извлекает сложный медицинский диагноз, который затем передается в классическую ML-модель для принятия решения о выплате.

Приоритет Data-driven подхода перед внедрением AI-native инструментов

Попытки построить AI-native компанию бессмысленны без предварительного этания Data-driven трансформации. Опыт Сбербанк страхования жизни показал, что использование Excel в аналитике приводит к разной интерпретации статусов разными отделами и отсутствию единого «места правды», что делает невозможным точный расчет длительности бизнес-процессов.

Внедрение Global Business ID для сквозного трейсинга процессов

Для борьбы с фрагментацией данных в разных системах (от фронт-офиса до 1С) введен единый идентификатор объекта, который присваивается в момент создания заявления. Это позволяет выстроить полную цепочку событий, точно определить этапы задержек и уйти от экстраполяции медианных значений к реальному мониторингу каждого шага процесса.

Архитектура чистого Data Lake с механизмом валидации

Чтобы хранилище данных не превратилось в «болото», внедрена строгая схема валидации входящих событий через Kafka. Данные, не соответствующие бизнес-правилам (например, дата начала позже даты окончания), автоматически направляются в Dead Letter Queue для исправления системой-источником, что гарантирует высокое качество данных для последующей работы AI-агентов.

Кейс Сбербанк страхования жизни демонстрирует эталонный путь перехода от legacy-процессов к современной архитектуре данных. Главная ценность решения заключается не в самом использовании LLM, а в создании инфраструктуры (Global Business ID, проверка через Kafka), которая делает данные качественным и доступным первоисточником.

Результатом стало беспрецедентное для рынка сокращение времени обслуживания клиентов и создание базы для полноценного внедрения AI-агентов в аналитику. Опыт компании подтверждает: технологический стек вторичен по отношению к дисциплине управления данными (Data Governance).