Gen BI Maturity Index: семь уровней зрелости генеративной аналитики

Шкала Gen BI родилась не из теории, а из практического проекта. Мы делали образовательные мероприятия и стратегические сессии для одной из крупнейших IT-компаний России — компании, продуктами которой пользуются более 70% россиян. Одной из ключевых тем было определение стратегии по внедрению искусственного интеллекта в работу с данными. После нескольких подобных сессий в разных организациях пришло понимание: многие компании смотрят в направлении Gen BI, но при этом воспринимают ИИ как волшебную чёрную коробку — куда можно задать любой вопрос, и она сама найдёт ответ.

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

Я приверженец вертикальной декомпозиции и поступательной разработки, поэтому разбил техническое задание проекта на фазы — от простых запросов к сложным, от выгрузки одной таблицы до прогнозной аналитики. Эта структуризация ТЗ и легла в основу Gen BI Maturity Index — индекса зрелости генеративной аналитики. Оказалось, что такая шкала удобна не только для одного проекта: она позволяет быстро оценить необходимые инвестиции, определить скоуп внутренней разработки для поддерживающего ПО и инфраструктуры данных, и более эффективно планировать деятельность организации в стратегическом цикле.

Gen BI Maturity Index — это не замена шкале автономности процессов, а её специализированный продолжатель для одной конкретной области — работы с данными. У меня есть ещё пара таких специализированных шкал для других функций, но Gen BI — самая востребованная, потому что работа с данными есть в каждой большой компании.

В этой статье — полное описание Gen BI Maturity Index. Если вы работаете в data-команде, BI-подразделении или отвечаете за аналитику в банке или корпорации и думаете, как внедрить LLM в работу с данными, — это для вас. Каждый уровень шкалы принципиально отличается от предыдущего — и по архитектуре, и по требованиям к инфраструктуре. Например, уровень 3 (комбинация источников) — это когда агент обращается к нескольким разрозненным API: проект-трекер, бухгалтерия, геолокационные данные. А уровень 4 (JOIN) — это работа внутри одной базы данных со сложными связями между таблицами. Разные уровни — разные технические задачи, и из этой шкалы ни одного уровня не выкинешь.

Откуда берётся семь уровней

Когда я структурировал ТЗ того первого Gen BI-проекта, экспериментировал с разным числом уровней. Пробовал пять — получилось слишком крупно, потерял важные различия между джойном и агрегацией. Пробовал десять — получилось слишком мелко, стало невозможно объяснить совету директоров за одну минуту.

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

Вот как выглядит полная шкала. Это — тот же слайд, который я показываю в корпоративных программах и на банковских воркшопах, но в текстовом виде.

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

Уровень 1 — Выгрузка таблиц

Самый базовый уровень. Пользователь — неважно, топ-менеджер или аналитик — пишет в чат «покажи мне таблицу клиентов за январь». Система формирует простой SELECT, идёт в одну базу, возвращает таблицу. Всё. Никаких сложных преобразований, никакого объединения, никакой фильтрации в две стадии. Одна таблица — одна выборка.

Этот уровень часто недооценивают, потому что он «тривиальный». Но попробуйте построить его для совета директоров банка с учётом безопасности. Нужно управление правами (кто может смотреть какие таблицы), аудит запросов (кто что спросил), защита от случайных тяжёлых запросов (лимит по объёму), и всё это под контролем комплаенса. Технически — это уже не «тривиально».

В моей практике Уровень 1 есть у большинства банков в форме классического BI-инструмента (Power BI, Qlik, Tableau) с подключением к корпоративному хранилищу. Gen BI-часть — в том, что интерфейсом становится не drag-and-drop меню, а чат на русском языке. Это снижает порог для пользователя и, как следствие, расширяет круг тех, кто умеет спрашивать данные. Это важная социальная деталь, а не только техническая.

Уровень 2 — Фильтрация данных

На Уровне 2 агент умеет применять условия. «Покажи клиентов из Москвы со средним чеком выше 50 тысяч». Это SELECT с WHERE, и снаружи он выглядит так же просто, как Уровень 1, но внутри — принципиально другой. Потому что теперь агенту нужно понять, что такое «клиенты из Москвы» (какое поле, какие значения), и что такое «средний чек» (из какой таблицы, как считать).

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

Банки, с которыми я работал, обычно останавливаются именно на Уровне 2 в массовом применении. Это уровень, на котором корпоративные дашборды уже работают, и добавление естественно-языкового интерфейса — это улучшение UX, но не революция. Всё, что выше, требует серьёзных архитектурных решений.

Уровень 3 — Комбинация источников

Здесь происходит первый серьёзный скачок. Агент одновременно идёт в несколько систем — CRM, ERP, риск-движок, БД звонков — и на своей стороне агрегирует результаты. Например: «покажи мне зависимость фрод-инцидентов от региона клиента за последний квартал». Агент должен пойти в систему фрода, в CRM за клиентской атрибуцией, возможно, в геолокационный справочник, и сложить всё вместе.

Технически это требует пулов соединений, кэша, унификации схем и лимитов объёмов. Потому что если агент начнёт каждый запрос гнать в прод одновременно без кэша, он положит всю BI-инфраструктуру за один вечер.

С Уровня 3 начинается серьёзный разговор о инфраструктуре. Это не просто «добавим LLM-интерфейс», это архитектурная работа по объединению источников. В моей практике работы с одним из крупнейших российских банков на программе аналитики данных и ИИ мы специально разбирали, как строить data category map — авторскую карту категорий данных, без которой Уровень 3 не строится. На сессии выясняется, что в компании несколько определений одной и той же сущности, и команда впервые явно этот факт проговаривает.

Уровень 4 — Объединение сущностей через JOIN

Уровень 4 — это уровень, на котором агент понимает семантические связи между сущностями. Не просто «возьми таблицу А и таблицу Б и объедини по ключу», а «что такое клиент в контексте этого запроса, и где он живёт в наших данных».

Пример: «покажи корреляцию между размером портфеля клиента и числом его обращений в контакт-центр за последний год». Агент должен понять, что «клиент» — это связанная сущность в нескольких таблицах (клиентская атрибуция, портфель, обращения), построить JOIN по ключам, правильно обработать дубликаты и пропуски, вернуть результат.

Это уже уровень, на котором вам нужен семантический слой или NLQ-движок — специальная прослойка между естественным языком и BI-данными, которая знает онтологию компании. Без неё агент каждый раз изобретает JOIN заново, и половина результатов оказывается неправильной.

Для банков и страховых этот уровень — главная точка приложения усилий в 2026 году. Все крупные игроки пилотируют что-то похожее, никто пока не довёл до промышленной эксплуатации. Если вы запускаете такой проект — это примерно L3 по шкале автономности процессов, и вся дисциплина, которую я описываю в статье про дорожную карту внедрения ИИ, применима полностью.

💡 Пытаетесь понять, на каком уровне Gen BI ваши data-команды? Я провожу корпоративный интенсив «Аналитика данных и ИИ» для data-команд банков и корпораций. Формат — 2–3 дня, включает разбор Gen BI Maturity Index для ваших конкретных процессов, проработку архитектуры семантического слоя и построение дорожной карты. Обсудить программу →

Уровень 5 — Каскадная логика и вложенные запросы

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

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

На этом уровне Gen BI начинает выглядеть как полноценный аналитический агент. Он уже не просто отвечает на вопросы, он расследует. Это опасный и мощный инструмент одновременно: опасный — потому что легко получить неверный каскад, и от неправильного ответа совет директоров может принять неправильное решение; мощный — потому что один аналитический вопрос, на который команда бы тратила неделю, отвечается за минуты.

Уровень 6 — Сводные отчёты и pivot-аналитика

Уровень 6 — это умение работать с многомерностью. Pivot, OLAP-срезы, группировки по нескольким измерениям одновременно. «Покажи доходность по сегментам клиентов, разбитым по региону, каналу привлечения и продукту, за последние 12 месяцев с разбивкой по кварталам». Это классическая задача корпоративной аналитики, но в Gen BI она впервые становится доступной через чат, без необходимости разбираться в BI-инструменте.

Технически это требует OLAP-движка или BI-семантики, которая умеет быстро строить агрегаты. Без заранее построенных кубов и агрегатов каждый такой запрос превращается в тяжёлое вычисление по исходным данным, и Gen BI оказывается неприемлемо медленным для реального пользования.

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

Уровень 7 — Прогноз и ML

Уровень 7 — это когда агент строит прогнозы, ищет аномалии, моделирует сценарии «what-if». «Если мы поднимем ставку на 1 процент, как изменится отток клиентов в следующем квартале?». Это уже не просто запрос данных, это запрос к ML-модели, которая должна быть обучена, валидирована и встроена в контур Gen BI.

Требования: ML-окружение, фичестор, циклы обучения и валидации, MRM-контур для комплаенса. На этом уровне Gen BI стыкуется с вашим MRM-процессом, и это стыковка — одна из самых сложных в банковском контексте. Потому что любая модель, которая участвует в принятии решений, должна быть валидирована по BCBS 239 и SR 11-7, а GenAI — плохо укладывается в эти классические фреймворки. Про это я пишу подробно в отдельной заметке «MRM для GenAI».

Уровень 7 — это, в моей практике, точка, где Gen BI перестаёт быть задачей data-команды и становится задачей всей компании. Потому что вы запускаете систему, которая напрямую влияет на бизнес-решения, и это должно пройти через риск-комитет, комплаенс, внутренний аудит и так далее.

Как определить ваш текущий уровень

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

Первый вопрос — что аналитик делает руками чаще всего? Если основное время уходит на копипаст данных между Excel-файлами, вы на уровне 1. Если — на сборку сложных запросов из нескольких источников, вы на уровне 3. Если — на моделирование сценариев, вы на уровне 7, но, скорее всего, без поддержки LLM, то есть готовы к переходу на Gen BI.

Второй вопрос — у вас есть единый семантический словарь компании? Если да — вы готовы к переходу на Уровень 4 и выше. Если нет — ваш текущий практический максимум Уровень 3, и переход выше требует сначала работы с архитектурой данных.

Третий вопрос — через кого проходят запросы к данным? Если только через data-команду — вы на Уровне 1-2 в терминах доступности. Если через самообслуживание с естественно-языковым интерфейсом — значит, вы реально запустили Уровень 2 или выше в промышленной эксплуатации.

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

Частые ошибки при работе с Gen BI

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

Ошибка первая — пропустить семантический словарь. Команда запускает Gen BI «с чата и LLM», без единого определения сущностей, и через месяц получает систему, которая на один и тот же вопрос даёт три разных ответа в зависимости от того, в какую таблицу агент забрёл первым. Лекарство: семантический словарь строится до Gen BI, а не параллельно.

Ошибка вторая — попытка сразу запустить Уровень 7. «Давайте сделаем прогнозную модель оттока на LLM». Нельзя. На Уровне 7 требования — ML-окружение, фичестор, валидация, MRM-контур. Это годовая работа, а команда хочет результата за месяц. В результате — ничего не работает, команда разочарована, все идеи про Gen BI откладываются.

Ошибка третья — недооценка нагрузки на источники. Gen BI на уровнях 3+ генерирует много запросов к продовым системам. Если кэш не настроен, продовая БД падает на первом же серьёзном применении. Лекарство: начинать с тестового контура, нагрузочное тестирование обязательно.

Ошибка четвёртая — отсутствие объяснимости ответа. Агент вернул график, но не объяснил, откуда данные, как построен JOIN, какая логика. Пользователь не понимает, доверять ответу или нет. Лекарство: обязательный элемент каждого Gen BI-ответа — источник и метод. «Взято из таблицы X, агрегация по Y, период Z». Без этого система не проходит аудит.

Ошибка пятая — игнорирование прав доступа. Gen BI запускается над всеми данными, и топ-менеджер, у которого нет доступа к HR-данным, через чат получает доступ к HR-данным. Это катастрофа для комплаенса. Лекарство: права доступа к данным через агент должны быть такими же, как через прямой доступ. Не менее и не более.

Где Gen BI Maturity Index применяется

Gen BI Maturity Index — сквозная методика в двух моих программах.

Корпоративный интенсив «Аналитика данных и ИИ» для банков и корпораций построен вокруг этой шкалы: мы с data-командой определяем текущий уровень, проектируем целевой на 12 месяцев, разрабатываем архитектуру семантического слоя. Это 2–3-дневный формат, в котором к концу программы у команды есть карта зрелости и план действий.

В мульти-локационной программе для крупного российского банка Gen BI Maturity Index — одна из ключевых частей обучающего контента. Мы разбираем конкретные процессы data-команд на 6 различных локациях и показываем, как разные процессы могут быть одновременно на разных уровнях — и это нормально.

Кроме этого, шкала работает как дополнительный инструмент в Audit зрелости — когда в компании выделяется отдельный трек по работе с данными, мы строим для него отдельную дорожную карту на базе Gen BI Maturity Index, а не общей шкалы автономности процессов.

Методика — часть моей третьей книги «Автономный Бизнес», которая выходит в декабре 2026 года в крупнейшем издательстве РФ. В книге — полный разбор всех семи уровней, примеры из практики и раздел о том, как Gen BI связан с корпоративным MRM.

Что делать дальше

Если ваша компания задумывается, как встроить LLM в работу с данными, у вас три пути.

Путь первый — разобраться самостоятельно. Используйте семь уровней как диагностическую рамку: возьмите 3–5 процессов работы с данными в вашей компании и по каждому определите, на каком уровне вы сейчас и куда хотели бы перейти. Это займёт несколько часов и даст вам первое понимание.

Путь второй — пригласить меня на диагностику. За 90-минутную Диагностику автономности за 150 тысяч мы вместе пройдём по вашим процессам работы с данными и определим уровни. На выходе — карта зрелости и три приоритизированные инициативы.

Путь третий — обучить всю data-команду. Корпоративный интенсив «Аналитика данных и ИИ» — это 2–3-дневная программа, в которой вся команда проходит через Gen BI Maturity Index совместно и выходит с общим пониманием целей и методов. Это дороже, чем диагностика, но окупается в первые два-три месяца за счёт того, что команда перестаёт тратить время на несогласованные архитектурные решения.

В любом из трёх случаев — следующий шаг один и тот же: сесть, посмотреть на свою аналитику честно и начать.

Обсудить Gen BI для вашей команды →