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

Бенчмарк Spider 2.0, опубликованный на ICLR 2025, собрали из 632 реальных корпоративных задач: базы BigQuery и Snowflake, часто свыше 1 000 колонок, решения длиной больше ста строк SQL. Агентная схема на базе o1-preview решила 21,3% таких задач против 91,2% на более «чистом» Spider 1.0. У GPT-4o падение резче: 10,1% против 86,6%.

Обещания вендоров живут отдельно от этой реальности. В маркетинговых материалах заявляют 85–90% точности text-to-SQL; на продакшен-схемах заказчиков получается 10–31%.

Почему точность падает так глубоко? На аккуратной схеме слово «маржа» означает одну конкретную колонку. Внутри реальной компании оно означает договорённость между людьми. Если три подразделения считают маржу по-разному, модель честно выдаст три разных числа, и ни одно из них не будет ошибкой. Ошибкой будет решение, принятое по любому из них без проверки.

Вывод для ассистента руководителя уже, чем кажется на первый взгляд. Сложная часть — не сгенерировать SQL. Сложная часть — договориться, что компания называет каждым показателем, и уметь показать, откуда взялось число.

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

В ПланЭксперте это встроено в саму структуру ответа: текстовый вывод, графики, таблицы, промежуточная аналитика как валидация шагов и ссылка на документ или конкретную страницу с переходом к оригиналу. На практике на вопрос «почему упала маржа в Q1» ассистент отвечает: маржа −4,2% из-за роста себестоимости на 12%, основной драйвер — логистика. И показывает источник: файл финотчёта за Q1 со ссылкой в 1С: Аналитика затрат.

Разница структурная. Первый вариант — «ИИ выдал цифру, верьте или нет». Второй — «вот число, вот откуда оно взято, проверьте за две минуты».

Схема ПланЭксперта состоит из четырёх ступеней: данные, онтология бизнеса, агенты, диалог.

Первая ступень — единый источник данных. Коннекторы ведут к ERP, CRM и API заказчика, к ClickHouse, к PostgreSQL и Postgres Pro. Файлы попадают в систему перетаскиванием и индексируются автоматически. Вторая ступень — автоматическая онтология: связывание разрозненных систем в одну модель бизнеса.

Именно этой ступени не было в первой волне зарубежных внедрений, и именно её отсутствие приводило к уверенным и неверным числам. Разрыв, который показал Spider 2.0, возникает не на уровне модели, а на уровне смыслов: аккуратная схема против 1 000 колонок и регламентов, которые нигде не записаны явно.

Мы не проектировали эту логику, наблюдая чужой провал. Платформа построена вокруг неё с самого начала.

Платформа разворачивается полностью на инфраструктуре заказчика. Языковые модели работают на ваших GPU. Ни один запрос не уходит во внешний сервис. Внешних API и облаков третьих сторон нет.

Стек построен на открытых технологиях, без привязки к одному вендору. Продукт включён в реестр российского ПО, что важно для объектов КИИ и регулируемых отраслей. Для таких заказчиков развёртывание на своей инфраструктуре — не преимущество. Это пропуск на вход: облачные ассистенты отсекаются на этапе согласования, и их список возможностей становится неважен.

Пилот ПланЭксперта рассчитан на 2 месяца при фиксированной стоимости 5 млн рублей. Внутри: развёртывание платформы на серверах заказчика, подключение до двух корпоративных систем, адаптация под бизнес-логику и тестирование на ваших реальных данных.

Сроки разложены на пять этапов. Анализ ИТ-инфраструктуры и источников данных — 1–2 недели. Интеграция и настройка коннекторов — 2–3 недели. Сам пилот с проверкой точности метрик и качества ответов — 2–3 недели. Запуск с обучением пользователей — от 1 недели. Поддержка, SLA и расширение источников — постоянно.

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

Честный разговор начинается с условий на стороне заказчика. Их четыре, и каждое проверяется на первом же этапе пилота.

Если метрики не определены. Платформа адаптируется под вашу бизнес-логику и словарь метрик, но адаптироваться можно только к тому, что существует. Если в компании нет согласованного ответа на вопрос «что мы называем маржой и за какой период», система не сможет дать однозначный ответ. Правильный первый шаг — внутренний разговор об определениях, а не пилот. Эта же причина стоит за 21,3% в бенчмарке: там, где смысл показателя не зафиксирован явно, любая система отвечает наугад.

Если нет машинного доступа к источникам. Коннекторы есть к PostgreSQL, Postgres Pro, ClickHouse, ERP-системам, включая 1С, к CRM-платформам и REST API заказчика. Если нужные данные лежат в системе, к которой такого доступа нет, и выгружаются только руками раз в месяц, качество ответов будет ограничено частотой выгрузки, а не возможностями платформы.

Если ждут ответа там, где его не может быть. Ассистент собирает и объясняет то, что есть в ваших источниках. Он не заменяет решение руководителя и не снимает ответственность за него. Там, где вопрос требует управленческого выбора, а не расчёта, система даст данные для выбора и не даст сам выбор.

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

Вопрос ИТ-директора: чем это отличается от BI-системы, которую мы уже внедрили и которой никто не пользуется?

BI отвечает на вопрос, который заранее заложил аналитик, через собранный заранее дашборд. Здесь вопрос задаётся словами, а ответ собирается из источников в момент запроса, с показом промежуточных шагов и ссылкой на исходные данные. Дашборды не отменяются. Отменяется очередь к аналитику за каждым новым срезом.

Вопрос финансового директора: могу ли я доверять цифре, которую выдала система?

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

Вопрос директора по цифровизации: что происходит с нашими данными?

Ничего, что выходит за пределы вашей инфраструктуры. Платформа разворачивается на ваших серверах, модели работают на ваших GPU. Соответствие требованиям к КИИ заявлено, продукт в реестре российского ПО.

Вопрос операционного директора: сколько это занимает и сколько стоит?

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

Вопрос собственника: а если пилот покажет, что у нас всё плохо с данными?

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

Прежде чем обсуждать развёртывание, честно ответьте на один вопрос: сколько времени сейчас проходит между вопросом руководителя и готовым ответом? Если честный ответ — «от двух дней до двух недель», у вас тот самый разрыв, который во всём мире пробовали закрыть подключением языковой модели к хранилищу и получили 21% правильных ответов.

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