Страховые предложения обычно сравнивают по цене, хотя главное спрятано в лимитах, франшизах и исключениях, разбросанных по разным документам. Казахстанская команда Polis делает для брокеров и сотрудников компаний рабочее пространство, где AI собирает условия в одну таблицу, показывает расхождения и называет страницу документа, на которую опирается вывод.
Проект участвовал в AI Hackathon Zubr Capital Young 19 сентября в Алматы и привлёк внимание редакции Bluescreen. Мы расспросили команду о том, что работает сейчас, как проверяются ответы ИИ и как выглядит экономика, и получили редкие для стартапа ответы: демо построено на вымышленных данных, точности на реальных документах пока нет, а «четыре клиента до окупаемости» считаются без зарплат.
Polis находится на стадии прототипа. Коммерческие и финансовые показатели из презентации команда называет расчётами и целями.
Мы искали задачу, для которой можно сделать полезный продукт небольшой командой и продавать его конкретным специалистам. В страховании нас заинтересовало сравнение предложений: цена обычно видна сразу, а ограничения, исключения и франшизы приходится искать в разных частях документов. Более дешёвое предложение может существенно отличаться по условиям, и эти различия нужно объяснить клиенту.
Поэтому мы выбрали конкретный сценарий — работу с документами по страхованию имущества бизнеса. У него понятный результат: собрать условия в сравнение, показать спорные места и дать специалисту возможность проверить источник. Начать с такого сценария нам кажется практичнее, чем сразу делать универсальную платформу для любых документов. Полезность этого подхода мы хотим проверить вместе с брокерами.
На хакатоне Zubr Capital мы показали рабочий проект Polis. Для тестирования использовали мок-данные — специально подготовленные вымышленные документы и условия. Такой показ позволяет продемонстрировать сценарий работы продукта без использования клиентских документов.
При этом демонстрацию прототипа мы отделяем от проверки на реальном страховом процессе. После технического показа следующий шаг — проверить, насколько продукт полезен специалисту на его задачах и документах.
Демонстрация в презентации действительно построена на вымышленных компаниях и специально подготовленных документах. Она показывает работу интерфейса и сценарий проверки. В учебном режиме ответы подготовлены заранее; такой показ сам по себе не подтверждает качество модели на документах реальных страховщиков.
В коде есть отдельный режим анализа загруженных PDF через AI. Следующий этап, который мы описывали в презентации, — согласовать доступ к документам для пилота и сравнить результат с ручной работой специалиста. Сначала нужно договориться об использовании данных и критериях проверки. Дату первого теста можно назвать после согласования с партнёром.
Вместе с выводом мы просим модель вернуть файл, физический номер страницы PDF и цитату. Программа проверяет, что ссылка относится к допустимому документу и существующей странице. В сравнении это должен быть актуальный файл соответствующего предложения; в чате — документ текущей заявки. По ссылке специалист открывает PDF и сверяет формулировку с оригиналом. Сама проверка файла и страницы ещё не доказывает, что модель верно процитировала или истолковала текст.
Например, в учебном предложении «Вектор Полис» на второй странице указано: «Франшиза: 1% страховой суммы». Страховая сумма в этом примере — 80 млн тенге. На вопрос о размере франшизы ожидаемый ответ — 800 тысяч тенге, с расчётом и ссылкой на документ. Если клиент просил не более 100 тысяч, это расхождение нужно проверить и обсудить. Пример вымышленный; он объясняет механику проверки, а не доказывает точность AI.
Подтверждённый процент точности на реальных страховых документах мы пока не приводим. В проекте есть программные проверки формата ответа, ссылок и порядка работы с результатом, но они не заменяют оценку качества извлечения условий. Демо с заранее известными ответами тоже не является такой оценкой.
Для проверки нужен набор документов, который страховой специалист разметит вручную. Отдельно будем сопоставлять суммы и валюты, базу расчёта франшизы, лимиты, исключения и ссылки. Ошибка в сумме и пропущенное исключение имеют разные последствия, поэтому одной общей цифры недостаточно. Важно также измерять, умеет ли система обозначать неопределённость. Публиковать результат имеет смысл вместе с размером выборки, типами документов и перечнем найденных ошибок.
«Орбита», «Вектор» и «Сфера» — вымышленные страховщики. Цены, документы и условия созданы для демонстрации, поэтому их нельзя использовать как сравнение реальных продуктов на рынке.
Мы специально заложили в пример несколько различий: где-то исключены товарные запасы, где-то франшиза выше запроса клиента, где-то указан отдельный лимит по затоплению. Так можно показать, зачем сопоставлять условия и проверять документы, даже когда одно из предложений выглядит привлекательнее по цене.
Доля 20–30% и SAM в 150–250 организаций — наши первоначальные допущения, а не результат опроса компаний о готовности платить. В качестве исходного ориентира мы использовали данные БНС за 2025 год о 4 129 отчитавшихся крупных и средних предприятиях с численностью более 100 человек. Это статистическая база, которая сама по себе не говорит, сколько организаций регулярно сравнивают страховые документы.
Мы предположили, что такой сценарий может быть актуален для части предприятий, и отдельно рассматривали брокеров. Но называть получившийся диапазон подтверждённым рынком было бы преждевременно. Следующий шаг — составить список конкретных организаций, выяснить частоту задачи, объём документов, ответственного за покупку и бюджет. SAM должен опираться на эту проверку. Готовность платить подтверждается платным пилотом и продлением; сейчас презентация этого не доказывает.
Источник: БНС Казахстана, данные о предприятиях за 2025 год.
Четыре клиента в презентации — это порог покрытия ограниченного набора денежных расходов. При подписке 99 тысяч тенге и предполагаемых расходах 15 тысяч на клиента остаётся 84 тысячи. Если постоянные расходы составляют 275 тысяч в месяц, четырёх клиентов достаточно для их покрытия. Все эти значения пока плановые.
Для полной картины нужно добавить оплату труда. Например, при совокупном бюджете на труд команды в 600 тысяч тенге в месяц постоянные расходы вырастут до 875 тысяч. Тогда потребуется минимум 11 клиентов. При фонде в 1 млн тенге — минимум 16. Это иллюстративные сценарии, а не утверждённые зарплаты нашей команды. Они ещё не учитывают начисления на оплату труда, налоги и расходы, не вошедшие в исходную модель. Поэтому четыре клиента нельзя представлять как полную окупаемость бизнеса или возврат вложенных денег.
Сейчас ведём разговоры о финансировании. Шесть миллионов тенге в презентации — плановая потребность на 12 месяцев; разговоры о деньгах ещё не означают закрытый раунд. В бюджете 1,2 млн заложено на AI-инструменты разработки, 1,8 млн — на AI внутри продукта, 600 тысяч — на инфраструктуру, 1,2 млн — на продажи, 300 тысяч — на администрирование и 900 тысяч — в резерв. Оплата труда команды туда не включена. Например, фонд 600 тысяч в месяц увеличит годовую потребность до 13,2 млн тенге до учёта начислений и возможной выручки. Этот годовой бюджет также включает разработку и резерв, поэтому его нельзя приравнивать к упрощённой модели месячных расходов из ответа про четыре клиента.
Если доступна только часть суммы, предлагаем начать с проверки одной задачи у нескольких клиентов и выделять деньги по этапам. Вариант первого этапа — 1–1,5 млн тенге на три месяца в рамках общего бюджета, с лимитами на AI и адресными продажами. Масштабировать расходы стоит после подтверждения пользы и оплаты. При отсутствии финансирования придётся сократить объём и темп работ; обещать прежний годовой план без ресурсов было бы неправильно.
В плане 3–5 платящих пилотов были ориентиром к концу первых трёх месяцев, а не гарантированным результатом сразу после интервью. Между разговором и оплатой есть несколько проверяемых шагов. Сначала нужно найти повторяющуюся задачу и понять, сколько времени специалист тратит на неё сегодня. Затем согласовать документы для теста и сравнить работу с Polis с ручным процессом, включая время на исправление ошибок AI.
После этого предлагаем ограниченный пилот: понятный объём документов, срок, стоимость, поддержка и критерии успеха. Клиенту нужен полезный результат в его работе, поэтому важны время проверки, качество сравнения и желание использовать продукт снова. Если это не подтверждается, нужно дорабатывать сценарий и переносить цель по продажам.
Основатель Polis — Низами Динмухамед. За планирование и маркетинг отвечают Турганбек Амир и Кабатова Александра Дмитриевна. Бэкенд разрабатывают Кошевой Константин и Бауыржан Тамерлан. Это текущий состав команды.
