
Локальный ИИ в страховании: как страховые компании внедряют LLM без передачи данных в облако
Подберём сервер под задачи
Ответьте на несколько вопросов — подготовим предложение
Локальный ИИ позволяет страховой компании обрабатывать документы, обращения и данные клиентов внутри собственного контура, не передавая их внешнему облачному сервису. Это особенно важно при работе с персональными и медицинскими данными, но само по себе не отменяет требований 152-ФЗ.
В статье разберём, какие страховые процессы имеет смысл переводить на локальные модели, какие требования учитывать при работе с данными и как подобрать GPU-инфраструктуру для пилота и промышленной эксплуатации.
Зачем страховщикам локальный ИИ, а не облачный
Облачный API удобен для быстрого тестирования, но запросы и ответы обрабатываются на инфраструктуре внешнего поставщика. Для страховой компании это создаёт дополнительный контур передачи данных, который необходимо учитывать в модели угроз, договорах и внутренних регламентах.
Такая система работает на серверах страховщика или в выделенной инфраструктуре под его управлением. Такой подход упрощает контроль над движением данных, но не отменяет требования законодательства и не гарантирует безопасность системы сам по себе.
Риски передачи персональных и медицинских данных клиентов в облако
В страховых процессах используются анкеты, договоры, фотографии имущества и автомобилей, сведения о выплатах и история обращений. В ДМС к ним добавляются данные о состоянии здоровья, которые относятся к специальным категориям персональных данных согласно статье 10 закона № 152-ФЗ.
Если сотрудник отправляет такой документ во внешний чат-бот или LLM-сервис, данные покидают внутреннюю информационную систему. Страховщику необходимо заранее определить:
- какие сведения разрешено передавать поставщику;
- где и как долго хранятся запросы и ответы;
- используются ли они для обучения модели;
- кто получает доступ к журналам операций;
- можно ли гарантированно удалить переданные сведения;
- происходит ли трансграничная передача данных.
Локальное развёртывание ИИ позволяет оставить документы и результаты инференса в контролируемом контуре. Перед обработкой информацию можно обезличивать, а доступ к модели — разграничивать по ролям. Запросы сотрудников и ответы системы с персональными данными необходимо учитывать в общей системе журналирования. Статья 19 закона № 152-ФЗ требует принимать необходимые правовые, организационные и технические меры для защиты персональных данных. Какие события нужно фиксировать и какие действия пользователей контролировать, зависит от требований безопасности конкретной информационной системы.
Контроль над инфраструктурой и доступностью сервиса
При использовании внешнего сервиса страховщик зависит от его доступности, тарифов, ограничений API и порядка обновления моделей. Изменение версии может повлиять на качество классификации обращений или извлечения данных из документов.
В собственном контуре ИТ-служба управляет версией модели, вычислительными ресурсами и расписанием обновлений. Это позволяет:
- установить собственные показатели доступности и времени ответа;
- не зависеть от лимитов внешнего API;
- тестировать обновления до переноса в продуктивную среду;
- хранить журналы запросов внутри компании;
- интегрировать модель с внутренними базами без передачи данных во внешний контур;
- отключить системе прямой доступ к внешним ресурсам.
Недостаток локального развёртывания — ответственность за оборудование, резервирование, информационную безопасность и сопровождение остаётся у самой компании. Поэтому локальный контур оправдан прежде всего для постоянной обработки чувствительных данных. Для обезличенных и нерегулярных задач может подойти гибридное развёртывание: защищённая информация обрабатывается внутри компании, а внешние сервисы используются только для данных, которые разрешено передавать.
Где ИИ применяется в страховании уже сегодня
ИИ в страховании не ограничивается генерацией текста. Машинное обучение, компьютерное зрение и языковые модели используются на разных этапах: от расчёта тарифа до проверки заявления о страховом случае.
| Задача | Где применяется | Тип данных | Что учесть при работе с данными |
|---|---|---|---|
| Оценка рисков | Андеррайтинг, расчёт тарифа, сегментация клиентов | Анкеты, история страхования, телематика | Закрытый контур предпочтителен при работе с персональными данными |
| Урегулирование убытков | Проверка документов, оценка повреждений, расчёт выплаты | Заявления, фотографии, медицинские документы | Персональные и медицинские сведения требуют защищённой обработки |
| Антифрод | Поиск связей, аномалий и повторяющихся схем | Выплаты, договоры, обращения, сведения об участниках | Модель обычно интегрируется с внутренними базами страховщика |
| Клиентский сервис | Чат-бот, классификация обращений, подготовка ответов | Переписка, договоры, записи разговоров | Открытые вопросы можно обрабатывать отдельно от конфиденциальных данных |
Оценка рисков и персонализированное ценообразование
Модель может анализировать параметры клиента и объекта страхования, историю убытков и статистику по похожим договорам. В КАСКО к этим данным добавляются характеристики автомобиля, регион эксплуатации и телематика, если её сбор предусмотрен продуктом.
Результат используется как подсказка андеррайтеру или как один из факторов расчёта тарифа. Полностью передавать принятие решения модели рискованно: необходимо контролировать качество данных, объяснимость результата и возможную дискриминацию отдельных групп клиентов.
Локальное развёртывание особенно полезно, когда модель должна обращаться к внутренней истории договоров и выплат. Исходные сведения остаются в инфраструктуре страховой компании, а ни анкета клиента, ни рассчитанный профиль риска не передаются во внешние сервисы.
Урегулирование убытков и автоматизация выплат
ИИ извлекает сведения из заявлений, сопоставляет их с условиями договора, проверяет комплектность документов и оценивает повреждения по фотографиям. Простые случаи можно направлять по ускоренному маршруту, а спорные — передавать специалисту.
Страховые компании Сбера используют ИИ для ускорения выплат. В СберСтраховании жизни ИИ-агент анализирует документы и самостоятельно принимает решение по части случаев кредитного страхования жизни; такие выплаты могут занимать около пяти минут. В СберСтраховании почти каждый третий клиент, обращающийся из-за травмы через мобильное приложение, получает компенсацию автоматически.
Другой пример — автокаско. В мае 2025 года «Ингосстрах» сообщал, что более 15% обращений по автокаско в онлайн-каналах проходили по сценариям максимально оперативного автоматического решения. Алгоритм обрабатывал обращение по заданным параметрам и формировал направление на ремонт; процесс занимал меньше минуты.
Борьба со страховым мошенничеством
Антифрод-модель ищет нетипичные сочетания признаков: повторное использование документов и фотографий, связи между участниками разных страховых случаев, необычную последовательность действий или отклонение суммы требования от статистики.
Обнаруженная аномалия не доказывает мошенничество. Система присваивает заявке риск-оценку и направляет её сотруднику службы безопасности. Окончательный вывод требует проверки исходных материалов.
Такой сценарий особенно подходит для локального инференса: модели нужен доступ к внутренним договорам, выплатам и результатам предыдущих расследований. Передача этого массива внешнему сервису расширяет число систем, в которых приходится контролировать персональные данные.
Чат-боты и обработка обращений клиентов
Языковая модель может определить тему обращения, найти нужный пункт правил страхования, подготовить краткое резюме переписки или предложить оператору проект ответа. Чат-бот также способен объяснить порядок подачи заявления и проверить наличие обязательных документов. Отдельно мы разбирали, как устроены ИИ-чат-боты и как интегрировать в них LLM: от выбора модели до подключения к внешним системам и развёртывания.
В апреле 2026 года «Билайн бизнес» сообщил о первой фазе внедрения LLM-агента на горячей линии «Ренессанс страхование». Решение на базе платформы targetai интегрировали с телефонией, CRM и каналами уведомлений, чтобы автоматизировать часть клиентских обращений и сократить время обслуживания.
Для сценариев, где ответы должны соответствовать внутренним правилам и документам компании, модель стоит привязать к корпоративной базе знаний и определить допустимые источники. Юридически значимые решения, отказ в выплате и нестандартные случаи следует оставлять специалисту, а действия системы — записывать в журнал.
Выберите GPU-сервер для нейросетей
Готовые решения для работы с большими массивами данных
Регуляторные требования к ИИ и данным в страховании в России
Специального регулирования применения ИИ именно страховыми компаниями нет. С 1 сентября 2026 года действует основная часть Федерального закона № 243-ФЗ о поддержке развития технологий искусственного интеллекта. Закон регулирует разработку, внедрение и применение больших фундаментальных моделей ИИ; отдельные его положения вступают в силу позднее. Страховщикам также необходимо учитывать требования 152-ФЗ, страхового законодательства и документы Банка России.
152-ФЗ и обработка персональных и специальных категорий данных
Страховщик выступает оператором персональных данных и обязан определить цель обработки, правовое основание, состав сведений и срок их хранения. Перед внедрением модели необходимо проверить, охватывают ли действующие согласия и внутренние документы новый способ обработки.
Особого внимания требуют:
- сведения о здоровье клиентов ДМС и страхования жизни;
- фотографии, видеозаписи и документы по страховым случаям;
- записи разговоров и переписка с поддержкой;
- данные телематики и сведения о местоположении;
- результаты профилирования и оценки рисков.
ИИ не создаёт отдельного правового основания для обработки сведений о здоровье. Для таких данных необходимо соблюдать условия статьи 10 закона № 152-ФЗ; среди предусмотренных ею случаев прямо указана обработка в соответствии со страховым законодательством.
При сборе персональных данных граждан РФ запись, систематизация, накопление, хранение, уточнение и извлечение не допускаются с использованием баз данных, находящихся за пределами России, кроме прямо предусмотренных законом исключений. Это установлено частью 5 статьи 18 закона № 152-ФЗ.
Отдельное ограничение касается решений, которые затрагивают права и законные интересы клиента. Статья 16 закона № 152-ФЗ запрещает принимать их исключительно на основании автоматизированной обработки, кроме случаев, предусмотренных законом или письменным согласием. Поэтому отказ в выплате или изменение существенных условий договора нельзя без дополнительной правовой проверки полностью передавать модели.
Рекомендации Банка России по безопасному использованию ИИ
Страховые организации относятся к некредитным финансовым организациям, поэтому на них распространяется сфера применения документов ЦБ РФ для участников финансового рынка.
В июле 2025 года Банк России опубликовал Кодекс этики в сфере разработки и применения ИИ. Документ носит рекомендательный характер и выделяет пять принципов:
- человекоцентричность;
- справедливость;
- прозрачность;
- безопасность, надёжность и эффективность;
- ответственное управление рисками.
Регулятор рекомендует сообщать клиенту о применении ИИ, предусматривать возможность обращения к сотруднику и пересмотра автоматизированного решения человеком. Также организациям предлагается проверять качество данных и моделей, вести их централизованный учёт, назначать ответственных и регистрировать связанные с ИИ риск-события.
В июне 2026 года ЦБ РФ выпустил отдельные методические рекомендации по информационной безопасности при использовании ИИ. Банк России рекомендует финансовым организациям разработать собственную модель угроз и политику информационной безопасности для ИИ-систем. Если ИИ автоматически выполняет операции в критически важных процессах и риск информационной безопасности ИИ оценён как высокий, Банк России рекомендует проверять результат человеком с возможностью его изменить.
Почему локальное on-premise развёртывание снижает регуляторные риски
Локальное размещение сокращает число внешних систем, через которые проходят данные, и упрощает разграничение доступа, журналирование и аудит. Но оно не отменяет требований 152-ФЗ и мер информационной безопасности: до запуска нужно определить правовые основания обработки, модель угроз, права доступа и порядок контроля решений ИИ.
Российские LLM для локального развёртывания в страховой компании
Выбор модели начинается не с рейтинга, а с требований конкретного процесса. Для поиска по внутренним документам важны точность ответов и работа с длинным контекстом, для чат-бота — скорость инференса, а для анализа заявлений — поддержка изображений и структурированного вывода.
До внедрения каждую модель нужно проверить на обезличенной выборке документов страховщика. Общие тесты не показывают, насколько точно система интерпретирует правила страхования, медицинские термины или описания повреждений.
GigaChat Enterprise: локальный контур для крупного бизнеса
GigaChat Enterprise, также представленный как «ГигаЧат Бизнес», — корпоративная платформа Сбера для создания и управления ИИ-агентами. Это не только языковая модель, но и набор инструментов для подключения корпоративных документов, разграничения доступа, мониторинга и интеграции с внутренними системами.
Платформа предлагается в трёх вариантах:
- локальная версия в виде программно-аппаратного комплекса;
- облачный сервис;
- гибридный вариант в приватном облаке, при котором данные хранятся на серверах предприятия.
Локальную версию можно развернуть внутри периметра организации. По информации Сбера, она предназначена для компаний с жёсткими требованиями к безопасности, включая объекты критической информационной инфраструктуры. Платформа поддерживает ролевую модель доступа, журналирование и подключение к корпоративным системам управления учётными записями.
Для страховщика на такой платформе можно создать несколько специализированных агентов: помощника оператора контакт-центра, поиск по правилам страхования, проверку комплектности заявления или подготовку резюме страхового случая. Перед запуском нужно отдельно согласовать состав поставки, требования к оборудованию, лицензирование и порядок обновления моделей.
Выберите GPU-сервер под свои задачи
Готовые конфигурации для инференса, машинного обучения и вычислений
Другие открытые и коммерческие модели для in-house-инференса
Альтернатива готовой корпоративной платформе — модели с доступными весами, которые страховая компания разворачивает и обслуживает самостоятельно. Для работы с русским языком можно тестировать семейства Qwen, Mistral, Llama и их специализированные дообученные версии. Доступность конкретной модели для коммерческого применения зависит от её лицензии: термин «открытые веса» не всегда означает отсутствие ограничений.
Подробнее о вариантах для собственного контура мы рассказывали в материале о том, какие модели ИИ можно развернуть на своём ПК или сервере.
Такой подход даёт больше контроля над программным стеком. Команда может выбирать движок инференса, применять квантование, подключать собственную систему поиска по документам и обновлять отдельные компоненты независимо. Обратная сторона — необходимость самостоятельно отвечать за безопасность, мониторинг, качество и совместимость версий.
При выборе модели следует проверить:
- качество русского языка и отраслевой терминологии;
- точность ответов на внутренних документах;
- размер контекстного окна;
- поддержку текста, таблиц и изображений;
- возможность структурированного вывода;
- требования к видеопамяти;
- лицензию и допустимые способы коммерческого использования;
- совместимость с выбранным ПО для инференса.
Для многих прикладных задач не нужно обучать LLM с нуля. RAG-система добавляет в контекст запроса релевантные фрагменты корпоративной базы знаний, а модель формирует ответ с их учётом. Дообучение стоит рассматривать отдельно, если требуется устойчиво закрепить формат или поведение модели.
Независимо от происхождения модели следует предусмотреть проверку ответов и фильтрацию входных данных. Для действий, влияющих на клиента или внутренние системы, необходимо заранее определить, какие операции модель может выполнять автоматически, а какие требуют подтверждения сотрудника.
Какая GPU-инфраструктура нужна для локального ИИ в страховании
Конфигурацию нельзя выбирать только по числу параметров модели. Требования к видеопамяти определяют прежде всего размер модели, формат весов и квантование, длина контекста, KV-кэш и число параллельных запросов. Размер RAG-базы в первую очередь влияет на объём накопителей и оперативной памяти, а не напрямую на видеопамять.
Если нужно сначала подобрать сам ускоритель, смотри наш рейтинг видеокарт для нейросетей, где отдельно разобраны требования к видеопамяти для обучения и инференса.
Для предварительного расчёта нужно определить:
- какую модель планируется запускать;
- сколько пользователей будут обращаться к ней одновременно;
- какое время ответа считается допустимым;
- какие документы и в каком объёме поступают на обработку;
- требуется ли компьютерное зрение;
- будет ли система только выполнять инференс или также дообучать модели;
- какой уровень резервирования нужен для продуктивного сервиса.
От пилота на рабочей станции до продуктивного GPU-сервера
Для проверки гипотезы часто достаточно одной рабочей станции с профессиональной или потребительской видеокартой. На ней можно развернуть квантованную модель, подключить тестовую базу знаний и измерить качество ответов на документах компании.
Рабочая станция подходит для:
- разработки прототипа чат-бота;
- тестирования RAG по правилам страхования;
- классификации обращений;
- извлечения полей из документов;
- работы небольшой команды разработчиков.
Подобрать такую систему можно в разделе рабочих станций для локальных LLM DigitalRazor. При выборе важно учитывать не только объём памяти GPU, но и охлаждение, питание, оперативную память и возможность дальнейшего расширения.
Для постоянного корпоративного сервиса чаще выбирают GPU-сервер. Он лучше подходит для длительной нагрузки, удалённого доступа, нескольких ускорителей и стоечного размещения. В каталоге GPU-серверов DigitalRazor представлены системы с поддержкой до восьми видеокарт.
| Сценарий | Платформа | Почему подходит | Что проверить |
|---|---|---|---|
| Пилот одного сценария | Рабочая станция с одной GPU | Проще развернуть и использовать для разработки | Помещается ли модель в память, хватает ли скорости |
| Пилот крупной модели | Станция с несколькими GPU | Позволяет распределить модель между ускорителями | Поддержку многокарточного инференса выбранным ПО |
| Сервис небольшой команды | RackStation AI | Стоечное или напольное размещение, несколько GPU | Параллельность запросов и резервирование |
| Продуктивный сервис | Scale или HPC-система | Масштабирование до нескольких ускорителей и узлов | Питание, охлаждение, сеть и отказоустойчивость |
Как выбрать конфигурацию под задачу
Выбор между RackStation AI, Scale и HPC зависит от размера модели, параллельности запросов и необходимости масштабирования на несколько ускорителей или узлов. Помимо GPU, в конфигурации нужно учитывать накопители для моделей и индексов, объём RAM, сеть, мониторинг, резервное копирование и отказоустойчивость.
Часто задаваемые вопросы
Вывод: как начать внедрение локального ИИ
Начинать следует не с закупки оборудования, а с одного измеримого сценария. Подходящей задачей для пилота может стать поиск по правилам страхования, классификация обращений или проверка комплектности документов. Автоматический отказ в выплате для первого проекта не подходит: цена ошибки и требования к контролю здесь значительно выше.
Последовательность внедрения:
- Выбрать процесс и определить ожидаемый результат: сокращение времени обработки, снижение нагрузки на операторов или повышение точности классификации.
- Описать используемые данные, правовые основания их обработки и требования к защите.
- Подготовить обезличенную тестовую выборку с правильными ответами специалистов.
- Сравнить несколько моделей и конфигураций по качеству, скорости и потреблению памяти.
- Запустить пилот на рабочей станции без прямого влияния на решения по клиентам.
- После проверки качества перенести систему на GPU-сервер, настроить мониторинг, журналирование и резервирование.
На пилотном этапе достаточно ограниченной группы сотрудников и ручной проверки каждого результата. Переходить к продуктивной эксплуатации можно после того, как зафиксированы метрики качества, границы применения модели и порядок действий при ошибке или недоступности системы.
Собственный ИИ-контур даёт страховщику больше контроля над данными и инфраструктурой, но требует собственной технической и организационной компетенции. Если нагрузка меняется или часть информации можно обрабатывать вне закрытого контура, локальную систему можно дополнить облачными инструментами. Такое гибридное развёртывание позволяет разделить чувствительные и общедоступные задачи.
Для пилота можно подобрать рабочую станцию для локальных LLM, а для корпоративного сервиса чаще выбирают GPU-сервер с нужным количеством ускорителей: он лучше подходит для длительной нагрузки, удалённого доступа, нескольких ускорителей и стоечного размещения. Если параметры модели и будущая нагрузка пока неизвестны, специалисты DigitalRazor помогут рассчитать конфигурацию и предусмотреть её дальнейшее масштабирование.















