Анализ

Искусственный интеллект в страховании — от экспериментов к прагматичному внедрению Муковозова Анна Михайловна Независимый эксперт по AI, Data Science и автоматизации в страховании

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

16 июня 2026 года на конференции по инновациям и технологиям в страховании InnoIns-2026 прозвучала формулировка, которая, на мой взгляд, очень точно описывает текущий момент: страховой рынок уже вышел из фазы экспериментов с искусственным интеллектом и переходит к прагматичному внедрению — туда, где технология даёт быстрый и измеримый эффект. Звучит как очевидность, но за этой фразой стоит важный сдвиг.

Ещё пару лет назад главным вопросом на совещаниях было «надо ли нам вообще заниматься ИИ». Сейчас этот вопрос закрыт — заниматься надо, и это понимают все. Маркетплейсы и крупные экосистемы подняли планку клиентского опыта так высоко, что страховщик, который не успевает за технологиями, рискует потерять не отдельную сделку, а целый канал продаж. Поэтому теперь вопрос формулируется иначе: что именно внедрять, в каком порядке и как сделать так, чтобы проект не превратился в списание бюджета. И почти все топ-страховщики поделились успешными проектами чат-ботов, голосовых помощников, систем поддержки принятия решений при урегулировании, фрод-моделей. Но всё же внедрение происходит не так быстро, как хотелось гендиректорам, а все (по крайней мере — публичные) такие примеры относятся к 10-15 крупнейшим компаниям. А где же остальной рынок? Что мешает тому стремительному распространению ИИ, которого все ждали?

Публичные ИИ-проекты российских страховщиков по типам задач. По публичным источникам 2022–2026.

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

Три ограничения, о которых не любят говорить вендоры

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

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

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

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

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

Третье ограничение — данные, которых нет в нужном виде. Это, пожалуй, главная и самая недооценённая ловушка. Классические модели машинного обучения — а в страховании именно они, решают большинство реальных задач — учатся на размеченных исторических данных. Чтобы модель научилась, например, отличать обоснованный убыток от сомнительного, ей нужны тысячи исторических случаев, где эксперт уже проставил правильную оценку. И вот тут выясняется, что у большинства страховщиков таких размеченных данных нет. Есть записи в учётной системе, но это не то же самое, что размеченный для обучения датасет. А разметка — это работа живых экспертов, недели и месяцы кропотливого (квалифицированного и дорогого) труда. По опыту, на подготовку и разметку данных уходит от трети до половины бюджета проекта. Именно этот пункт вендоры скромно опускают в пресейле — потому что эта работа ложится на плечи заказчика, и она невидима, пока не упрёшься в неё лбом.

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

Сколько всё это стоит

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

Полезно представлять себе разные классы решений как ступени по росту сложности и стоимости внедрения — от самого доступного к самому затратному.

Четыре уровня решений по стоимости и сложности внедрения. У каждого — своя структура затрат.

Самое дешёвое — рабочий процесс на программной роботизации, вообще без всякого ИИ. Робот действует по чётким правилам. Вы платите за разработку и за лицензию платформы, а дальше эксплуатация почти ничего не стоит. Если задача решается на этом уровне — она и должна решаться здесь, без ИИ-усложнения.

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

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

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

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

Не всё нужно автоматизировать

Теперь тезис, который звучит странно из уст человека, который давно занимается автоматизацией. Часть процессов автоматизировать не нужно. Совсем.

Это прямое следствие принципа Парето: примерно двадцать процентов процессов функции дают восемьдесят процентов нагрузки и потенциала для оптимизации. А остальные восемьдесят процентов процессов суммарно влияют на результат гораздо меньше — и вкладываться в их автоматизацию означает распылять ресурс (как минимум — на первых этапах).

Какие процессы попадают в эти «лишние» восемьдесят? Я бы выделила два класса.

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

Второй класс хитрее — это процессы, где проблема вообще не в технологии, и ИИ там лечит симптом, а не причину. Приведу три примера, которые встречаются повсеместно.

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

Другой пример — гарантийные письма в клиники. Кажется, что это огромный ручной труд, который просится под автоматизацию. Но если разобрать процесс, выясняется, что само письмо давно формируется из системы почти автоматически, на основе заполненной карты обращения. Ручной осталась «последняя миля» — отправка письма по электронной почте и регистрация ответа. И нужен тут не искусственный интеллект, а простая роботизация отправки или, в идеале, единая площадка обмена с клиниками. Применять здесь ИИ — всё равно что забивать гвоздь микроскопом.

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

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

Грязные данные против роботов

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

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

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

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

Лестница нормализации: от дешёвого fuzzymatching к локальной языковой модели, и только потом — робот на чистых данных (на примере обработки наименований услуг).

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

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

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

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

Как выбрать первый процесс

Если свести всё сказанное в практическую логику, то выбор процесса для первого ИИ-проекта зависит от ответов на три вопроса, которые стоит задать прежде, чем приступать.

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

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

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

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

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

Прагматизм — это умение сказать «нет»

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

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

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

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