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