BI в эпоху ИИ: BI больше не нужен? Да здравствует BI

В последнее время мы все чаще слышим тезис: «Классический BI больше не нужен». Ведь сегодня можно открыть чат, попросить нейронку нарисовать красивый дэшборд с фильтрами и графиками, а потом спросить, что происходит с условной выручкой. Нейронка быстро соберет интерфейс, ответит на вопрос, а в следующий раз можно вообще не использовать старый дэшборд, а просто сделать новый.

Звучит так, будто привычная модель использования BI действительно начинает терять смысл. Но что именно устаревает - необходимость анализировать данные или наше представление о том, как должна работать аналитическая система?

В этой статье попробуем разобраться.

Мы уже проходили это с движками

 Прежде чем говорить про LLM, вспомним историю, которую обсуждали в мире российского BI еще несколько лет назад. Тогда шла очень похожая дискуссия, только вместо моделей были вычислительные движки.

Часть BI-вендоров делала ставку на собственный вычислительный движок: свой, заточенный под задачи аналитики, оптимизированный и быстрый. Звучало убедительно - собственная технология давала ощущение контроля и дополнительного конкурентного преимущества.

Мы, как вендор платформы бизнес-аналитики Luxms BI, пошли другим путем и использовали СУБД для вычислений (direct query) . Логика была простой: создатьи годами развивать движок, который по производительности и надежности мог бы конкурировать со специализированными решениями вроде ClickHouse, - задача, на наш взгляд, несопоставимая с ресурсами российской BI-компании. Зачем пытаться охватить всю технологическую цепочку, если можно сосредоточиться на том, что делаешь лучше всего?

Показательно, что со временем часть вендоров, изначально выбравших собственный движок, тоже отказалась от этой разработки и перешла на использование СУБД. В итоге закрепилась более четкая специализация: команды, которые годами занимаются вычислительными движками, развивают их как отдельный класс технологий, а BI-вендоры сосредотачиваются на своей области - интерфейсах, визуализации, правах доступа, работе с данными и удобстве для бизнес-пользователя.

Сегодня мы видим похожую логику уже в истории с LLM. Вместо собственного вычислительного движка предлагается собственная «умная» модель, дообученная на формулах, терминологии и особенностях конкретного BI-продукта. Звучит это тоже убедительно и хорошо воспринимается заказчиком.

Но здесь есть важное отличие от той истории: LLM развиваются гораздо быстрее, чем вычислительные движки несколько лет назад.

Модель становится расходным материалом

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

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

Модели в этом смысле «обновляются» как и версии приложений. И если архитектура продукта жестко привязана к конкретной модели, такая привязка довольно быстро превращается в вендор-лок и ограничивает возможности заказчика.

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

Поэтому наша позиция довольно простая - любая LLM на выбор заказчика, в облаке или on-premise, платная или бесплатная, зарубежная или локальная. Мы принципиально не занимаемся разработкой собственных языковых моделей, потому что не имеем необходимых для этого ресурсов и компетенций, и не дообучаем языковые модели, потому что затраченные на это ресурсы “обнуляются” с выходом новых версий LLM.

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

Тут, наверное, возникает вопрос: если LLM - расходник, то кто обеспечивает стабильность, а главное, предсказуемость поведения системы? Как настроить модель так, чтобы она и её новые версии работали именно так, как нам нужно?

Что остается, когда меняются модели

 Ответ - harness, или обвязка. Это совокупность системных инструкций, инструментов, навыков, памяти и правил, которая помещает универсальную языковую модель в конкретную рабочую среду и позволяет использовать ее для определенной предметной области.

Если сильно упростить, агент можно представить как модель, помещенную в заданную рабочую среду: с инструментами, контекстом, правилами, правами и доступом к данным. Модель при этом остается заменяемым компонентом, а прикладной слой вокруг нее обеспечивает устойчивость конкретного сценария.

Можно сравнить LLM с выпускниками вуза. Два одногруппника, которые плюс-минус учили одни и те же вещи и знают примерно одно и то же, могут после университета попасть в совершенно разные условия.

Один пойдет работать на нефтеперерабатывающий завод, где будет вникать в регламент, строгую систему безопасности, особенности терминологии и жаргона, привыкнет мыслить категориями скважин, технологических процессов и производственных показателей. Второй уйдет в консалтинг, будет разбираться в разных бизнес-моделях, учиться разговаривать с заказчиками на одном языке, работать с KPI, строить гипотезы и быстро переключаться между отраслями и задачами.

Через несколько лет это уже будут два очень разных специалиста. Хотя «мозги», то есть базовые знания, полученные в вузе, у них изначально были примерно одинаковые.

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

Из чего на самом деле состоит обвязка

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

Навыки - это устойчивые последовательности действий для типовых сценариев: найти данные, проверить период, построить расчет, сравнить с прошлым значением.

Память - инструмент, с помощью которого агент может запоминать факты, оставлять подсказки и заметки, которые помогают выполнять работу. При этом сама память требует контроля сроков хранения и состав данных.

Правила - ограничения, наложенные системой, допустимые операции, лимиты и условия, которые настраивают систему под задачу, например, доступ в интернет, к определённым ресурсам.

Самое главное, что при смене модели значительная часть этой обвязки может остаться прежней. Это та самая стабильная прослойка, которая объясняет новой модели, «как у нас тут все устроено», практически обучает «новенького» после вуза особенностям и правилам работы на новом месте.

Если завтра заказчик переходит с одной модели на другую, не нужно заново перестраивать весь прикладной слой. Модель может поменяться, а знания о том, что такое Luxms BI, как устроены его данные, какие функции есть в LPE, как создаются отчеты и какие правила действуют в конкретной системе, остаются в окружающей модель инфраструктуре.

Получается довольно удобное разделение ответственности: модели развиваются своим темпом, а продукт не обязан каждый раз перестраиваться вслед за очередной новой версией LLM.

На практике мы строим эту прослойку именно так.

AI в Luxms работает непосредственно внутри BI-системы. Он понимает структуру аналитической модели, может обращаться к каталогу, метрикам, источникам и другим объектам BI, создавать и изменять дэшборды, выбирать показатели и визуализации, а затем анализировать полученный результат.

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

Скорость против устойчивости

А теперь вернемся к тезису, с которого и началась наша статья: зачем нужен BI, если можно открыть чат и попросить его собрать дэшборд?

Современная модель способна буквально на лету собрать интерактивную страницу с фильтрами и графиками - такой «одноразовый дэшборд», созданный без единого программиста специально под конкретный вопрос бизнеса.

И это не проблема. Наоборот, это отличная возможность. Нужно быстро проверить гипотезу? Отлично. Нужно построить график из Excel-файла? Легко. Нужно за пять минут сделать мини-приложение для конкретной задачи? Пожалуйста.

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

С одноразовым дэшбордом примерно то же самое. Если нужно один раз посмотреть на данные, проверить гипотезу или быстро решить локальную задачу, нет смысла превращать это в большой проект. Дэшборд можно собрать за несколько минут, использовать и забыть.

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

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

В корпоративном BI это особенно заметно. Иногда решение приходится разрабатывать еще до того, как становятся доступны реальные данные: доступ к production-среде может быть ограничен требованиями безопасности, а заказчик еще не сформировал окончательный пул данных. Поэтому решение собирается на синтетических данных, а с реальными неожиданностями приходится сталкиваться уже после запуска.

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

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

Безопасность: а что может пойти не так?

Отдельного разговора заслуживает информационная безопасность. Возможности ИИ агентов действительно поражают, бизнес, впечатленный демонстрациями, конечно же, хочет внедрить и у себя новомодную и полезную новинку.

Но когда модель получает возможность самостоятельно искать информацию, вызывать инструменты, писать код и выполнять последовательность действий, она становится уже не просто интерфейсом для пользователя.

В июле 2026 года OpenAI и Hugging Face сообщили об инциденте, который хорошо показывает, что именно здесь может пойти не так. Во время внутренней оценки кибервозможностей модели OpenAI, работавшие в изолированной среде ExploitGym, самостоятельно нашли способ получить доступ в интернет, выявив и использовав ранее неизвестную уязвимость в прокси-кеше реестра пакетов.

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

То есть да, в данном случае ИИ действительно сам взломал систему. Причем важно именно слово «сам»: люди не ставили такой задачи и не подсказывали модели каждый следующий шаг атаки. Она сама искала путь к цели, находила новые возможности и связывала их в цепочку. OpenAI отдельно отмечает, что модели были полностью сосредоточены на достижении поставленной цели оценки и шли на крайние меры ради ее выполнения.

При этом это был специальный тестовый сценарий с ослабленными защитными механизмами, а не обычное пользовательское развертывание. OpenAI прямо указывает, что защитные меры были намеренно отключены, поскольку целью оценки было измерить базовые кибервозможности моделей. Но именно поэтому пример и интересен: он показывает не фантазию о том, что когда-нибудь сможет сделать агент, а уже наблюдаемую способность автономной системы искать и использовать новые пути для достижения поставленной цели.

И это не единственный подобный сигнал. В августе OpenAI отдельно описала еще несколько инцидентов во время независимых кибероценок, когда из-за особенностей тестовой среды модели получили доступ к открытому интернету и вышли за предусмотренные границы. В одном из случаев модель использовала оставленный в открытом доступе токен GitHub и обращалась к внешним сервисам, которые не входили в область задания.

А теперь перенесем эту логику из тестового полигона в корпоративную систему.

Что если модель, исключительно из лучших побуждений, чтобы выполнить какую-то задачу, пойдет в корпоративные и чувствительные данные? А потом поделится ими, например, со своей «коллегой»-моделью, чтобы получить помощь?

Здесь напрашивается очевидный шаг - максимально ограничить модель, запретить «ходить туда-то, делать то-то». Но проблема в том, что если запретить LLM все потенциально опасное, она станет бесполезной, а если ничем не ограничивать- риски будут очень высокими.

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

Есть и более приземленная, но не менее реальная проблема.

Дайте агенту доступ к 40 тысячам таблиц и попросите его посчитать выручку. Какую именно выручку? Какая из таблиц хранит итоги расчётов? Что означает поле со значением 90 - зарплату, остаток на счете или вообще температуру?

Самый опасный SQL-запрос - не тот, который упал с ошибкой, а тот, который успешно выполнился и вернул неверный, но абсолютно правдоподобно выглядящий ответ.

Схема данных объясняет агенту, как данные устроены. А показать, что эти данные означают по существу, - уже задача Data Governance, то есть агенту нужна не только структура, но и семантика данных.

Data Governance особенно важен в эпоху ИИ

Data Governance в этом контексте - не абстрактный термин, а конкретная инфраструктура правил и метаданных, которая теперь должна описывать не только базы данных и отчеты, но и модели, агентов и правила их взаимодействия с корпоративными данными.

Реалистичная задача сегодня - не гарантировать отсутствие инцидентов. Для сложной системы это практически невозможно. Гораздо важнее дать возможность обнаружить и расследовать то, что произошло.

А чтобы расследовать, нужны следы.

Какие промпты отправлялись? Какие данные и файлы обрабатывались? Какие инструменты вызывались? Какие решения принимались от имени пользователя? Какие действия выполнялись? Сколько ресурсов было потрачено?

Именно поэтому мы «обкладываем» модели, которые выбрал заказчик, слоем телеметрии и логирования. Модель может быть любой, но вокруг нее должна оставаться среда, в которой можно контролировать ее действия.

BI уже давно работает с тем, что для бизнеса означают данные: с моделями, показателями, справочниками, правилами доступа, визуализациями, связями между сущностями и контекстом. С приходом агентов этот слой становится еще важнее.

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

BI не исчезает. Меняется способ работы с ним

BI действительно может измениться очень сильно. Но не исчезнуть.

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

«Каждый день в 10 утра проверяй показатели продаж. Если отклонение больше заданного порога, найди причины, подготовь краткий отчет и отправь его ответственному сотруднику».

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

И это, пожалуй, одно из главных изменений.

Меняется не сама функция аналитика или руководителя. Меняется способ коммуникации с программным обеспечением. А BI остается той системой, в которой находятся данные, модели данных, визуализации, правила доступа и бизнес-контекст. Просто часть действий теперь можно не выполнять самому, а поручать цифровому помощнику.

Он может быть встроен в BI или находиться за его пределами, работать по запросу, по расписанию или по условию. То есть вместо «я сам сделаю это в BI» появляется «я поручаю агенту сделать это за меня».

Когда агентов станет много, понадобится еще больше дэшбордов

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

Они получают задания, обращаются к данным, запускают процессы, взаимодействуют друг с другом и с корпоративными системами.

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

То есть визуализация все еще необходима, только теперь мы визуализируем не только бизнес, но и работу самих цифровых сотрудников.

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

И здесь классическая задача BI приобретает новое содержание.

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

Просто теперь среди потребителей и производителей этой информации появляются агенты.

Не исчезновение BI, а смена роли

Смена инструмента разработки не отменяет сложности самих задач.

Если компании нужно управлять продажами, данные о продажах никуда не исчезли. Если нужно контролировать производство, производство не перестало генерировать данные. Если нужно предоставить сотрудникам информацию, ее все равно нужно собрать, посчитать, проверить и доставить нужным людям.

ИИ резко сокращает стоимость создания некоторых видов софта, но он не отменяет необходимость в данных, инфраструктуре, правилах, безопасности и управлении.

И, возможно, именно поэтому мысль «BI или ИИ» вообще не совсем правильная.

У одноразового ИИ-софта будет огромная область применения, но он не становится корпоративной системой только потому, что работает. Для корпоративного продукта нужны другие свойства - предсказуемость, контроль, безопасность, единые правила, масштабируемость, повторяемость и возможность понять, что происходило внутри системы.

Поэтому мы не думаем, что «ИИ убьет BI». Скорее, он уберет часть той работы, которую раньше приходилось делать руками:

• дэшборды будут создаваться быстрее;

• запросы будут формулироваться естественным языком;

• часть аналитики будет выполняться автоматически;

• некоторые действия можно будет делегировать агентам;

• отдельные приложения можно будет создавать под конкретную задачу и использовать ровно столько, сколько они нужны.

А BI постепенно станет не столько инструментом, в котором человек что-то делает мышкой, сколько информационной средой, с которой человек и цифровые агенты взаимодействуют на естественном языке.

Модель при этом может меняться хоть каждый месяц, инструменты разработки тоже будут меняться, а интерфейсы, вероятно, будут меняться еще быстрее. А вот необходимость иметь достоверные данные, единое информационное пространство, понятные правила доступа и возможность проконтролировать происходящее никуда не денется.