Нейросеть для страховой: сверка полиса и заявления

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

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

Почему решение по выплате не принимает модель

Начнём с запрета, потому что он определяет форму всего остального.

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

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

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

Тот же принцип работает и в проверке договоров: модель находит и выписывает, но не оценивает — подробно это разобрано в материале про проверку договоров.

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

Это главный сценарий статьи.

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

Результат выглядит так — и это внутренний рабочий документ, а не письмо клиенту.

Четыре вещи, которые делают эту таблицу рабочей:

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

Почему каждая строка обязана ссылаться на пункт

Ссылка на номер пункта — не украшение отчёта, а единственное, что делает сверку проверяемой.

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

Практическое следствие для промпта: строка без номера пункта запрещена. Не нашла пункт — ставит статус «нет в договоре» и оставляет поле ссылки пустым, но не пересказывает «обычные условия по таким рискам».

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

Третье — выборочный контроль. Раз в неделю руководитель берёт десять случайных дел и проверяет ссылки. Доля строк с неверным пунктом — единственная метрика качества, которая здесь что-то значит.

Почему «модель сказала, что покрывается» — претензия к компании

Отдельный разбор, потому что именно здесь схема ломается чаще всего.

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

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

Отсюда три правила:

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

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

Что вытащить из входящего заявления

Сценарий попроще, но именно он даёт основной объём.

Заявление приходит сканом, фотографией, PDF или письмом, и первое, что с ним нужно сделать, — превратить в поля: номер полиса, страхователь, дата и обстоятельства события, перечень требований, приложенные документы, банковские реквизиты, контакты.

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

Две технические оговорки. Модель не читает PDF и скан сама по себе — сначала документ превращается в текст, и от качества этого шага зависит всё остальное: механика разобрана в материале про обработку PDF через API. И поля из документов извлекаются по заранее заданной схеме, а не «как получится», — общая техника описана в разборе нейросети для документов.

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

Как искать по правилам страхования

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

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

Специфика страхования — в отборе. Формулировки в правилах близкие, и обычный поиск по смыслу выдаёт соседние пункты вперемешку с нужным. Здесь помогает переранжирование: кандидаты сначала находятся широко, потом пересортировываются отдельной моделью. В каталоге такая позиция есть — nemotron-rerank-vl-1b-v2, и она бесплатная. Как это устроено, описано в разборе про эмбеддинги и rerank.

Обязательное условие: вместе с текстом пункта в запрос идёт его номер, иначе сослаться будет не на что.

Что делать с разными редакциями правил

Отдельная боль, которую легко не заметить.

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

Что с этим делать:

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

Такая сводка полезна сама по себе: она показывает, какие изменения правил на практике порождают больше всего спорных строк.

Какие данные из заявления не уходят наружу

Заявление на выплату — плотный набор персональных данных: ФИО, паспорт, адрес, телефон, банковские реквизиты, а в личном страховании ещё и сведения о здоровье, то есть данные специальной категории.

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

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

Сколько это стоит на потоке

Ставка у нас одинаковая на вход и на выход, поэтому цена считается умножением ставки на объём в миллионах токенов. Сценарий — 3 000 заявлений на выплату в месяц.

Ставки за миллион токенов на 16 сентября 2026 года у позиций, которые здесь уместны. Переранжирование nemotron-rerank-vl-1b-v2 считается не по токенам, а по запросам, и открывается после первого платного пополнения:

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

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

Пересчёт объёма в деньги для любой другой ставки — в отдельном материале.

Как запустить на одном виде страхования

1. Возьмите один вид и один тип события. Однородность документов важнее охвата: на разнородном потоке схема не настраивается.
2. Нарежьте действующую редакцию правил на пункты с сохранением нумерации. Это главная подготовительная работа, и без неё дальше идти незачем.
3. Зафиксируйте пять статусов строки и запретите всё остальное.
4. Прогоните сто закрытых дел, где решение уже известно. Сравнивать нужно не «похоже ли на правду», а совпал ли пункт.
5. Считайте два типа брака отдельно. Неверный номер пункта — критично. Неудачная формулировка описания — нет.
6. Держите результат внутри. Первые месяцы сверка вообще не должна доходить до текста, который видит клиент.

Каркас запроса с ролью, запретами и форматом пишется один раз, как разобрано в материале про системный промпт.

Чего мы не утверждаем

Мы не принимаем решений по выплатам и не толкуем условия покрытия. Ни мы, ни модель. Сверка — материал для специалиста, а не заключение.

Мы не оцениваем ущерб по фотографии. Часть позиций каталога работает с изображениями, но оценка повреждений — это экспертиза с ответственностью за результат, а не описание картинки.

Мы не сравнивали модели на страховых документах. Своих замеров по этому сценарию у нас нет: проверяйте на закрытых делах, где ответ уже известен.

Что нужно, чтобы попробовать

Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов и без зарубежной карты. Оплата российской картой в рублях, один ключ на весь каталог: на 16 сентября 2026 года это 53 позиции, из них 40 доступны, 42 текстовые и 11 генерируют изображения.

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

Ещё две позиции, gemini-3-6-flash и fable-5, сейчас в проверке: строить на них работу с делами пока рано.

Что держать в голове

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

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

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

Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Попробовать на своих делах: keydealer.ru/login.