Источники данных
Основной источник — публично доступные правила страхования, которые сами страховые компании публикуют как действующие редакции по конкретным страховым продуктам (КАСКО, ОСАГО, имущественное страхование, страхование путешествий). Никаких внутренних или конфиденциальных версий правил мы не используем — только то, что страховщик официально опубликовал и применяет.
Каждый набор правил фиксируется в системе как самостоятельная единица с тремя ключевыми параметрами:
- версия — обозначение редакции, как её маркирует сам страховщик;
- дата вступления в силу — официальная дата, с которой эта редакция начинает применяться;
- техническая отметка идентичности — контрольная сумма исходного текста, позволяющая гарантировать, что разбор построен ровно по той редакции, которая сейчас опубликована, а не по её более ранней или поздней версии.
У каждого страховщика по каждому продукту в любой момент времени активной считается только одна редакция правил — именно она используется как основа для всех публикуемых разборов. Если страховая выпускает новую редакцию, предыдущая снимается с активного статуса, а соответствующие разборы помечаются как устаревшие (см. раздел «Актуальность разбора и stale-detection» ниже).
Процесс анализа
Разбор формируется заранее, до того как пользователь откроет страницу. Это принципиальная архитектурная особенность: пользователь не запускает анализ в момент клика — он видит уже готовый, заранее собранный и проверенный отчёт.
Внутренний pipeline состоит из двух последовательных стадий.
Первая стадия — структурирование текста правил. Длинный юридический документ приводится к нормализованному виду: выделяются страховые случаи, исключения, ограничения, формальные требования к страхователю, специальные оговорки. Цель — превратить разрозненный документ объёмом в десятки тысяч слов в машинно-читаемое представление, по которому дальше можно строить аналитику.
Вторая стадия — генерация секций разбора по событийной модели. Polis Helper смотрит на правила сквозь призму конкретных страховых событий («отказ в выплате», «полная гибель», «угон», «повреждение по вине третьих лиц» и подобных). Для каждого такого события собираются разделы итогового отчёта:
- блок ключевых рисков — что в правилах может работать против выплаты;
- блок формальных требований к страхователю — сроки уведомления, перечень документов, порядок действий;
- блок исключений и ограничений ответственности;
- блок сценарного анализа — как формальные нормы соединяются в типовых жизненных ситуациях.
Контекст конкретного полиса (страховщик, период действия, ключевые параметры договора) и юридический дисклеймер о границах продукта добавляются из шаблонов в момент показа.
Результат каждой стадии фиксируется как «playbook» — детерминированный набор готовых секций, привязанных к конкретной редакции правил и конкретному страховому событию. Именно эти playbook'и читаются на стороне пользователя, а не пересобираются заново.
Admin-time и user-time: где работает LLM, а где нет
Для YMYL-продукта в категории «деньги и финансовые риски» это центральный вопрос, поэтому даём прямой ответ.
На стороне команды (admin-time) при сборке playbook'ов мы используем большую языковую модель (LLM) как инструмент нормализации длинного юридического текста. LLM помогает превратить многостраничные правила в структурированное представление и сформулировать аналитические блоки на русском языке. Результат каждого запуска проходит методологический контроль и фиксируется в виде неизменяемого playbook'а с привязкой к конкретной редакции правил.
На стороне пользователя (user-time) LLM не работает. Когда читатель открывает страницу разбора или загружает свой полис, никакой генеративной модели в цепочке нет. Финальный отчёт собирается детерминированным шаблонным движком: берётся уже готовый playbook, в него подставляются параметры конкретного полиса (для персонального разбора) или нейтральные шаблонные данные (для канонического разбора без полиса), и результат отдаётся пользователю.
Из этого следует важное практическое свойство: для одного и того же полиса в рамках одной редакции правил отчёт будет идентичным при каждом открытии. Никаких случайных вариаций, никакой «креативности модели», никаких различий между двумя визитами. Это технический инвариант, а не маркетинговое обещание — он защищён архитектурно и проверяется автоматическими тестами на каждом релизе.
Актуальность разбора и stale-detection
Каждый опубликованный разбор жёстко привязан к конкретной редакции правил страховщика. Если страховая выпускает новую редакцию, ранее собранный playbook автоматически помечается как устаревший (stale) и снимается с публикации до того, как он будет пересобран на актуальной версии правил.
Это не отдельная процедура по запросу и не задача в очереди — это технический инвариант: разбор по неактуальным правилам не может быть выдан пользователю в качестве актуального. Если редакция правил сменилась, а новый playbook ещё не готов, пользователь увидит явное указание на это, а не молчаливо устаревший отчёт.
Дата актуализации всегда видна рядом с разбором — пользователь может самостоятельно убедиться, насколько свежей является версия правил, по которой собран отчёт.
Границы продукта
Polis Helper — аналитический инструмент. Чтобы у пользователя не возникало завышенных ожиданий, явно фиксируем границы того, чем сервис не является:
- не юридическая консультация и не замена работы с практикующим юристом;
- не страховой агент и не страховой брокер — мы не продаём полисы и не получаем комиссию от страховщиков;
- не real-time помощник в момент инцидента — мы не сопровождаем урегулирование убытка в режиме «здесь и сейчас»;
- не оценка законности действий страховщика — мы не выносим юридических выводов о том, что страховая «обязана» или «не имеет права»;
- не пошаговая инструкция вида «сделайте 1, 2, 3» под конкретную ситуацию;
- не прогноз решения страховой, суда или вероятности выплаты — мы не называем процентов, сумм и сроков.
Что мы делаем взамен: предоставляем структурированную read-only аналитику формальных рисков и требований из правил страхования, чтобы пользователь самостоятельно сформировал информированную позицию и при необходимости пришёл к юристу или к страховщику с уже понятной картой того, что написано в его правилах.
Приватность и обработка данных
User-time сборка разбора детерминирована и не использует LLM — это технический инвариант, описанный выше. Никакие данные полиса не попадают в генеративные модели в момент его загрузки или показа результата.
Сам полис обрабатывается строго в тех рамках, на которые пользователь даёт согласие на этапе загрузки. Состав извлекаемых полей, сроки и порядок хранения, условия удаления — описаны в «Политике конфиденциальности» (она же содержит положения о согласии на обработку ПД по 152-ФЗ). На этой странице мы не вводим новых обещаний и не дублируем юридические формулировки — актуальная версия лежит по ссылке.
Нормативная рамка — Федеральный закон № 152-ФЗ «О персональных данных». Оператор обработки персональных данных — ООО «ХЭЛПЕР».
Версионирование разбора и сообщения об ошибках
На каждой странице разбора рядом с заголовком видна дата актуализации и указание редакции правил, по которой собран отчёт. Это позволяет пользователю в любой момент сопоставить разбор с тем, что официально публикует страховщик.
Если читатель видит расхождение с фактическим текстом правил, неточность в формулировке риска или нерелевантный для свежей редакции тезис — на каждой странице разбора доступна кнопка «Сообщить об ошибке». Она открывает письмо на red@polishelper.ru с автоматически проставленными URL разбора, версией правил и датой актуализации, чтобы команде не пришлось восстанавливать контекст вручную.
Цель механизма — оперативно выявлять и устранять расхождения с новыми редакциями правил или фактические неточности. Фиксированных сроков ответа мы не обещаем: обращения обрабатываются командой методологически — разбор, на который поступило подтверждённое замечание, пересобирается на актуальной версии правил, а результат публикуется как новая версия playbook'а с обновлённой датой актуализации.
Методолог проекта
Методолог отвечает за корректность аналитической рамки разборов, фильтрацию content safety (запрет на юридические выводы, прогнозы выплат и пошаговые инструкции — см. раздел «Границы продукта») и ревью изменений во внутреннем prompt-паке, которым собираются playbook'и на admin-time. Любое расширение событийной модели, добавление нового страхового продукта или содержательное изменение структуры отчёта проходит через методологический ревью.
Методолог проекта
Над методологией Polis Helper работает Григорий Грачев.
12+ лет опыта в страховании, в том числе руководящий опыт в компании со страховой брокерской лицензией Банка России. Кандидат экономических наук, магистр экономики — Санкт-Петербургский государственный университет.
Контакт по методологическим вопросам: red@polishelper.ru