Чем отличается настоящий аналитический агент от генератора SQL, почему семантический слой важнее размера языковой модели и почему локальная LLM ещё не означает технологическую независимость?
В 2026 году AI‑ассистент или AI‑агент появился едва ли не у каждого российского BI‑вендора. Проблема в том, что одинаковая наклейка «AI» скрывает совершенно разные механизмы: где‑то это чат к данным, где‑то генератор SQL, где‑то помощник разработчика дашбордов, а где‑то — мультиагентная система с оркестратором, отдельными ролями и проверкой результата.
Сравнивать такие продукты по принципу «у кого есть агент» бессмысленно. Поэтому мы решили посмотреть, что именно умеет каждый из них, как устроена архитектура, насколько можно доверять ответам и где заканчивается реальный функционал и начинается маркетинг.

Как мы исследовали AI‑агентов
Исследование «AI в BI‑круг Громова 2026» проходило с февраля по июнь 2026 года. В нашу выборку вошло 11 российских решений с подтверждёнными коммерческими внедрениями AI‑агентов для бизнес‑аналитики. Вендоры заполняли анкету по 55 критериям, показывали работу агента в демо или давали доступ к демо‑стенду. Затем шла менее парадная часть: документация, тестовые вопросы и активное сжигание токенов российских и зарубежных языковых моделей.
Что проверяли? В первую очередь точность и достоверность ответов — результат сверяли с источниками. Затем сценарную пригодность, архитектуру, работу с семантическим слоем, юридические риски и попытались оценить бизнес‑ценность. С последним оказалось сложнее: красивый AI‑диалог ещё не означает измеримый эффект для бизнеса.
Сразу про ограничения
AI‑продукты меняются быстрее, чем успеваешь дописать исследование. Мы зафиксировали состояние рынка на июнь 2026 года: в начале работы у одного продукта, например, не было прослеживаемости до источника, а к финалу она уже появилась. И так — по многим критериям. В какой‑то момент пришлось просто поставить точку, иначе исследование продолжалось бы бесконечно. Ещё одна оговорка: часть функций мы видели на демо‑стендах, а не в промышленной эксплуатации. И только в середине проекта стало понятно, что местами мы сравниваем не столько разработчиков BI‑агентов, сколько качество подключённых к ним языковых моделей. Но методологию на ходу уже не переворачивали.
Вендоры получили возможность проверить результаты — и пользовались ею не один раз. Мы старались отделять показанный функционал от обещаний и не засчитывать желаемое за действительное.

Что мы называем AI‑агентом в BI
Сам по себе вопрос к данным на естественном языке уже дано не выглядит агентностью. Поэтому мы разложили решения по шести уровням зрелости — от простого преобразования запроса пользователя до автономной аналитики с планированием, проверкой и действиями.

В нашем исследовании встретились решения уровней 1–4. До уровня 5 российский рынок на момент фиксации результатов пока не дошёл.


Зоопарк архитектур: кто здесь кто
В статье позволим себе чуть менее академичный подход, чем в исследовании. Мы сопоставили решения с животными. Это не рейтинг и не оценка «хороший/плохой», а способ наглядно показать различия между продуктами по тем же характеристикам, которые мы проверяли в исследовании.
Медведь — Yandex AI Studio
Медведь хорошо чувствует себя на собственной территории: инфраструктура, ресурсы и правила игры — свои. У Yandex AI Studio похожая модель «закрытого сада»: YandexGPT, собственные ЦОД и сертификация для работы с персональными данными находятся внутри одной экосистемы.
Масштаб тоже вполне медвежий. Внутри Яндекса Yandex AI Studio ежемесячно используют более 60 тысяч сотрудников. За пределами компании — около 5 тысяч организаций, а каждый пятый пользователь DataLens применяет AI‑агента в ежедневной работе.
Развитие идёт без резких разворотов: 4–6 крупных обновлений в год. От простых помощников в сентябре 2025 года продукт дошёл до агентских сценариев в мае 2026-го. Для корпоративного заказчика это скорее история про последовательную эволюцию, чем про еженедельные эксперименты.

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

Сильный сценарий: массовое распространение аналитики через мессенджеры и быстрый доступ к данным для широкого круга сотрудников.
Ограничение: многошаговые автономные цепочки находятся в разработке; при использовании иностранных LLM нужно учитывать риски передачи данных за рубеж.
Дельфин — PIX BI AI‑ассистент
Дельфин — быстрый, дружелюбный и не требует долгого приручения. PIX BI AI‑ассистент можно попробовать практически без входного билета: сам инструмент бесплатный, пользователь оплачивает только токены выбранной языковой модели. Технически это браузерное расширение.
Ассистент понимает русский язык, опечатки и сокращения и позволяет выбирать разные LLM. Поэтому это удобный способ быстро проверить саму гипотезу AI‑аналитики: будут ли сотрудники задавать вопросы данным и получать от этого пользу.
Но область применения довольно чёткая. Для быстрых ответов и экспериментов — хорошо. Для длинных автономных цепочек в сложном корпоративном контуре — уже нет: отсутствуют встроенная прослеживаемость, техническая поддержка и проактивные сценарии. Для госсектора также важны ограничения по сертификации и реестру ПО.
Архитектурный профиль: помощник в интерфейсе, браузерное расширение / чат‑виджет.

Сокол — DataForge AI Analyst Agent
Сокол здесь — не столько про скорость, сколько про контроль. Архитектура DataForge построена вокруг цикла «планирование → действие → проверка» и использует MCP.
На тесте из 250 вопросов средняя точность ответов с OpenAI составила 8,4 из 10, с локальной моделью — 7,2 из 10. Для нас это оказался полезный пример того, насколько сильно итоговое качество агента зависит не только от его собственной архитектуры, но и от выбранной LLM.
Сильная сторона — прослеживаемость. Через SQL‑запросы и Панель выполнения можно увидеть действия агента, сформированные запросы и использованные показатели. В систему встроено 18 аналитических навыков: прогнозирование, корреляционный анализ, RFM, когортный анализ, кластеризация и другие сценарии.
Поддерживаются разные совместимые языковые модели.



Архитектурный профиль: внешний агент, цикл с MCP‑шлюзом.
Сильный сценарий: компании с DWH на PostgreSQL / ClickHouse, которым важны точность и объяснимость ответа.
Ограничение: нет проактивного мониторинга и анализа дашборда целиком.
Волк — Visiology Cortex
У Visiology Cortex не один агент, а целая стая на LangGraph. Роли разделены: один агент анализирует дашборды, другой генерирует DAX и запускает цикл проверки и исправления, третий ищет по документации, четвёртый работает с SQL, отдельный агент занимается оформлением виджетов.
В роли «вожака» используется VisiologyGPT на базе Qwen — российская разработка. При этом архитектура не привязана к единственной LLM: модель можно менять.
Архитектурный профиль: внешний агент, LangGraph, MCP‑сервер.
Сильный сценарий: сложная аналитика, генерация формул и работа с документацией через RAG.
Ограничение: многошаговый диалог для аналитика пока нестабилен; управляемого бизнес‑глоссария нет; проактивность отсутствует.
Слон — Навигатор BI, Сбер
Слон — крупная автономная система со своей инфраструктурой и жёстко контролируемым контуром. У Навигатора BI собственная языковая модель GigaChat, многоагентная схема с оркестратором, классификатором и верификатором, учёт ролей и глоссарий.
С точки зрения технологической независимости подход максимально последовательный: реестр ПО, 152-ФЗ, локализация, отсутствие зависимости от внешних API. Обратная сторона той же архитектуры — смена языковой модели не поддерживается.
Развитие тяжёлых enterprise‑систем обычно не похоже на спринт стартапа. Проактивность и анализ корневых причин заявлены к концу 2026 года; гибкость выбора компонентов сейчас ограничена.
Архитектурный профиль: встроенный AI, многоагентная система на.NET Core.
Сильный сценарий: крупные госкорпорации и госсектор, где на первом месте стабильность и безопасность.
Ограничение: невысокая гибкость в выборе языковой модели и более медленный темп развития функциональности.
Хамелеон — Glarus AI
Хамелеон хорош тем, что подстраивается под окружение. MCP‑сервер и мультиагентная архитектура позволяют выбирать LLM — Claude, GPT, DeepSeek, YandexGPT, GigaChat — и подключать разные MCP‑клиенты.
Но гибкость сама по себе не отменяет зависимостей. Модель по умолчанию — зарубежная, а значит, для российского заказчика остаются санкционные риски и риск ограничения доступа. В госсекторе это почти наверняка потребует перехода на российскую LLM; в коммерческом контуре такая архитектура, наоборот, удобна для экспериментов.
Сильный сценарий: компании, которые строят собственный AI‑стек поверх корпоративных данных и ценят свободу выбора компонентов.
Ограничение: зарубежная LLM по умолчанию, санкционные риски; проактивность пока в планах.
Барсук — ТЕРН ИИ Ассистент
Барсук живёт в своей норе — и в данном случае это преимущество. ТЕРН ИИ Ассистент рассчитан на изолированный контур без доступа в интернет, использует локальную Qwen 3.5 14B, а данные не покидают инфраструктуру заказчика.
Цена такой изоляции — функциональные ограничения. По текстовому запросу строятся таблицы, но не графики; нет анализа дашбордов и анализа корневых причин. Это осознанный компромисс: максимум контроля и минимум внешних зависимостей. Семантический слой задаётся в JSON и ограничивает пространство, в котором работает агент.
Архитектурный профиль: ассистент на семантическом слое, локальная языковая модель, работа на серверах заказчика.
Сильный сценарий: КИИ и полностью изолированные контуры, где безопасность важнее широты функциональности.
Ограничение: только табличная форма ответа, нет анализа дашбордов и анализа корневых причин.
Осьминог — Insight Solaris AI
У осьминога много рук, у Insight Solaris AI — много агентов. Мультиагентность и визуальное создание новых агентов позволяют довольно быстро собирать специализированные сценарии для HR, продаж, логистики и других функций.
Важная техническая деталь: числовые ответы считает SQL‑движок, а не сама языковая модель. Это уменьшает риск арифметических галлюцинаций, хотя ошибка всё равно возможна на этапе интерпретации запроса. Управляемый глоссарий использует гибридный поиск — векторный и нечёткий, с учётом русской морфологии — чтобы лучше сопоставлять пользовательские формулировки с бизнес‑терминами.
Архитектурный профиль: встроенный AI, SQL‑движок, каталог данных, MCP‑сервер.
Сильный сценарий: компании, которым критична точность числовых ответов и нужна кастомизация агентов.
Ограничение: анализ дашборда целиком пока в планах, работа с неструктурированными данными — в разработке, проактивных сценариев нет.
Конь — Luxms AI
Конь — рабочая система полного цикла: от подключения источника до готового отчёта и аналитического вывода.
У Luxms AI есть сертификат ФСТЭК, что расширяет применимость в чувствительных контурах. Из менее типичных для BI‑агентов возможностей — встроенное прогнозирование на базе линейной регрессии и экспоненциального сглаживания, а также запись данных обратно в источники.
Ограничения тоже вполне практические: анализ корневых причин и предписывающая аналитика находятся в разработке, систему метрик ещё нужно усиливать. Санкционные риски зависят от выбранной LLM. В итоге это скорее «рабочая лошадка» для автоматизации широкого аналитического цикла, чем экспериментальный AI‑конструктор.
Сильный сценарий: автоматизация полного цикла аналитики, запись данных обратно в источники и встроенное прогнозирование.
Ограничение: анализ корневых причин и предписывающая аналитика — в разработке; система метрик требует улучшения.
Сова — Polyanalyst
Сова специализируется на том, что не всегда удобно укладывается в строки и столбцы. Polyanalyst давно работает с анализом текстов, интеллектуальным анализом данных и RAG, поэтому его сильная сторона — извлечение смысла из неструктурированной информации и поиск скрытых связей.
Диалоговый режим хранит контекст пяти вопросов, система умеет выявлять проблемы с данными и глубоко разбирать тексты. Для задач, где документы и текст важнее очередного SQL к витрине, это заметное отличие от большинства участников.
При этом построение графиков по тексту пока неполное: сложные визуализации не поддерживаются. Анализ дашборда может давать ошибки, а смена языковой модели была протестирована только на одной модели.
Сильный сценарий: текстовая аналитика, работа с неструктурированными документами и RAG.
Ограничение: неполное построение графиков по тексту, ошибки при анализе дашборда и отсутствие прослеживаемости.
Что стало понятно после 11 продуктов и 55 критериев
Когда смотришь на отдельные демо, рынок кажется почти агентным: система понимает вопрос, пишет SQL, строит график и иногда довольно убедительно объясняет, что произошло. Но сводная матрица из исследования отрезвляет. Российские AI‑BI уже неплохо научились давать доступ к данным на естественном языке и строить визуализации, а вот подготовка данных, прогнозирование и особенно проактивная наблюдаемость заметно отстают. Иными словами, разговор с данными уже работает. Самостоятельный аналитический цикл — пока не везде.
Если разложить агента не по маркетинговому названию, а по шести функциональным слоям, картина выглядит так:

Какие выводы мы сделали?
-
Семантический слой оказался важнее размера LLM
Даже сильная языковая модель может дать неправильный бизнес‑ответ, если не понимает, что компания называет «активным клиентом», какую дату использует для выручки и что включает в маржу. Без управляемых мер, терминов, синонимов, календарей и lineage агент вынужден угадывать.
Полноценный управляемый глоссарий есть лишь у части решений; другие используют описания полей, промпты или собственные механизмы сопоставления терминов с мерами. Полноценного графа знаний для бизнес‑семантики мы в выборке не увидели. Похоже, следующий этап конкуренции AI‑BI будет идти не только вокруг LLM, но и вокруг качества контекста, который ей предоставляют.
-
Точность рождается в архитектуре, а не в красноречии модели
В корпоративной аналитике мало получить убедительный текст — нужно понимать, откуда взялось число. Поэтому наиболее надёжные подходы разделяют роли: SQL‑движок считает, семантический слой связывает бизнес‑термины с показателями, а LLM интерпретирует запрос и формулирует ответ. Отсюда ценность lineage: чем длиннее агентная цепочка, тем важнее видеть SQL, меры, фильтры и шаги выполнения.
-
BYOM ещё не означает независимость от вендора
Возможность подключить свою LLM закрывает только один слой зависимости. Остаются API агента, формат семантического слоя, скилы, RLS/CLS, глоссарии, оркестрация и лицензирование. На практике заменить модель часто проще, чем весь контекст и инструменты вокруг неё.
Поэтому стоит спрашивать не только «можно ли подключить GigaChat или локальную Qwen», но и можно ли самостоятельно управлять агентом через API, выгружать глоссарий, работать без облака вендора и менять LLM без покупки новой лицензии.
-
Локальная LLM — ещё не технологический суверенитет
Локальное развёртывание модели само по себе не делает решение полностью независимым. Важно смотреть на всю цепочку: где работает оркестратор, куда уходят метаданные, нужны ли внешние API для эмбеддингов, можно ли эксплуатировать систему без связи с вендором, входит ли AI‑компонент в реестр и есть ли необходимая сертификация. Один и тот же продукт может заметно менять свой санкционный профиль в зависимости от выбранной LLM и схемы развёртывания.
-
Максимальная автономия нужна не всегда
В нашей шкале уровни автономии идут от 0 до 5, но больше — не обязательно лучше. Для простого запроса вроде «покажи продажи прошлого квартала по регионам» вполне уместен уровень 3: агент сам выбрал источник и вернул результат. Для финансовой аналитики, очистки данных или причинного анализа безопаснее уровень 2, когда AI предлагает действие, а человек его подтверждает. Human‑in‑the‑loop здесь — нормальный механизм управления риском.
-
Единого «лучшего AI‑BI» нет — и это не дипломатическая оговорка
Разные архитектуры решают разные задачи. Госсектору и КИИ нужны локальный контур, реестр и сертификация. Крупной коммерции могут быть важнее MCP, точность и возможность менять LLM. Кому‑то нужны writeback и прогнозирование, кому‑то — RAG по документам, а кому‑то достаточно недорогого помощника поверх дашборда. Поэтому выбирать стоит не «лучшего зверя» из нашего зоопарка, а решение под конкретный сценарий и нужный уровень автономии.
И ещё один практический совет: пилотируйте AI‑BI не на красивых демо‑вопросах. Возьмите 30–50 реальных запросов руководителей, добавьте неоднозначные бизнес‑термины, неявные временные фильтры, плохие данные и несколько случаев, где правильный ответ — «я не знаю». Разница между чат‑ботом, хорошим ассистентом и настоящим аналитическим агентом проявится довольно быстро.
Автор: GromovBI


