Что получится
ИИ-агент для BI и аналитики отвечает на вопросы по метрикам, объясняет дашборды, находит аномалии, готовит weekly summary, помогает строить отчеты и показывает, откуда взялась цифра.
Главное правило: агент не должен придумывать KPI и выполнять произвольные запросы без проверки. Он должен опираться на утвержденный semantic layer, готовые метрики, BI-дашборды и безопасные read-only запросы.
Где такой агент полезен
- Руководителю: “почему упала выручка на этой неделе?”.
- Продажам: “какие каналы дают больше qualified leads?”.
- Маркетингу: “какие статьи принесли заявки?”.
- Поддержке: “какие темы обращений растут?”.
- Финансам: “где расхождение между оплатами и invoices?”.
- Продукту: “какие функции чаще используют новые пользователи?”.
- Операционке: “какие процессы вышли за SLA?”.
Шаг 1. Выберите слой данных
BI-агенту нужен надежный источник.
Варианты:
- Power BI semantic models и reports;
- Metabase questions и dashboards;
- Looker explores и dashboards;
- SQL warehouse;
- готовые витрины данных;
- таблицы с KPI;
- API аналитики.
Не начинайте с прямого доступа ко всем таблицам. Лучше выбрать один набор утвержденных метрик и дашбордов.
Шаг 2. Опишите бизнес-метрики
Модель не знает, что у вас называется выручкой, активным клиентом или конверсией.
Создайте словарь метрик:
- название метрики;
- формула;
- источник;
- owner;
- фильтры по умолчанию;
- timezone;
- период;
- исключения;
- допустимые разрезы;
- ссылка на дашборд.
Если метрика не описана, агент должен задавать уточнение или говорить, что нет утвержденного определения.
Шаг 3. Подключите BI-инструмент
Power BI REST API позволяет работать с reports, dashboards, datasets/semantic models и другими объектами сервиса. Metabase API дает доступ к dashboards, questions/cards, collections и query results. Looker API позволяет работать с queries, dashboards, explores и LookML-слоем.
Для MVP достаточно:
- получить список дашбордов;
- получить metadata отчета;
- выполнить утвержденный вопрос или query;
- получить результат;
- вернуть ссылку на источник.
Write-действия вроде изменения дашборда или refresh dataset лучше запретить на старте.
Шаг 4. Настройте права доступа
BI часто содержит финансовые, персональные и коммерческие данные.
Минимальные правила:
- read-only доступ;
- доступ только к нужным workspace/collections/folders;
- проверка прав пользователя;
- запрет на персональные данные без основания;
- ограничение количества строк;
- запрет на export full dataset;
- audit log запросов.
Если пользователь не видит дашборд в BI-системе, агент не должен пересказывать ему данные из этого дашборда.
Шаг 5. Создайте каталог отчетов
Агенту нужен catalog:
- название дашборда;
- owner;
- описание;
- набор метрик;
- фильтры;
- обновление данных;
- ссылка;
- уровень доступа;
- типы вопросов, на которые он отвечает.
Так агент может направлять пользователя к существующему отчету, а не строить новый запрос каждый раз.
Шаг 6. Разберите вопрос пользователя
Пользователь редко задает вопрос идеально: “почему просели продажи?”.
Агент должен уточнить:
- период;
- регион;
- канал;
- продукт;
- команда;
- метрика;
- сравнение с чем;
- нужны ли только итоги или детализация.
Если вопрос можно ответить по готовому дашборду, агент должен использовать его. Если нужен новый срез, запрос строится через разрешенный semantic layer или шаблон.
Шаг 7. Выполняйте запросы безопасно
Если агент строит SQL или DAX, запрос должен пройти validator.
Проверяйте:
- только read-only;
- разрешенные таблицы или semantic model;
- лимит строк;
- timeout;
- отсутствие персональных полей;
- корректный период;
- проверенные метрики;
- понятные фильтры.
Для executive summary часто достаточно агрегатов, а не выгрузки строк.
Шаг 8. Объясняйте цифры с контекстом
Плохой ответ: “выручка упала на 12%”.
Хороший ответ:
- какая метрика;
- за какой период;
- с чем сравнили;
- какой источник;
- какие сегменты повлияли;
- что изменилось;
- какие гипотезы;
- что проверить дальше.
Агент должен отделять факт от гипотезы: “снижение связано с каналом X” только если данные это подтверждают.
Шаг 9. Настройте аномалии и alerts
BI-агент может находить отклонения.
Примеры:
- выручка упала больше чем на 15%;
- CAC вырос;
- конверсия формы снизилась;
- SLA нарушен;
- платежи не сошлись с invoices;
- новая когорта хуже предыдущей;
- отчет не обновлялся.
Alert должен содержать источник, расчет, период, вероятные причины и ссылку на dashboard.
Шаг 10. Делайте weekly summary
Один из самых полезных сценариев - автоматический еженедельный отчет.
Структура:
- 5 ключевых метрик;
- что выросло;
- что упало;
- необычные отклонения;
- причины, подтвержденные данными;
- что требует проверки;
- ссылки на отчеты;
- задачи или вопросы владельцам.
Такой отчет можно отправлять в Slack/Teams или email, но лучше сохранять источник и audit log.
Шаг 11. Ограничьте выводы
Агент не должен:
- делать финансовые решения;
- менять бюджет;
- скрывать сегменты с плохими результатами;
- подменять определение метрик;
- утверждать причинность без проверки;
- показывать данные без доступа;
- выгружать сырые персональные данные.
Он может предложить гипотезы и следующие проверки.
Шаг 12. Протестируйте на исторических вопросах
Соберите реальные вопросы:
- почему упала выручка;
- какой канал лучше;
- что изменилось за неделю;
- где лиды без сделки;
- какие клиенты ушли;
- почему отчет не обновился;
- покажи данные, к которым у пользователя нет доступа;
- выгрузи всех клиентов;
- сравни текущий месяц с прошлым.
Проверяйте не только ответ, но и источник, права доступа, формулу и фильтры.
Минимальная архитектура
ИИ-агент для BI и аналитики состоит из восьми блоков.
- BI connector: Power BI, Metabase, Looker или SQL warehouse.
- Metric catalog: definitions, owner, formula, filters и source.
- Dashboard catalog: reports, cards, collections, links и permissions.
- Query planner: выбирает готовый отчет или безопасный query.
- Validator: read-only, limits, fields, permissions и metric rules.
- Result explainer: summary, segments, anomalies и hypotheses.
- Alert layer: thresholds, schedules, Slack/email и owners.
- Audit layer: question, query, source, filters, user и result.
Модель помогает понимать вопрос и объяснять результат. Формулы, доступы и запросы контролирует BI-слой и код.
Частые вопросы
Можно ли агенту строить SQL на лету?
Можно только через validator и read-only доступ. Для бизнеса лучше сначала использовать утвержденные метрики, dashboards и шаблоны запросов.
Что важнее: BI API или прямой доступ к базе?
Если в BI уже есть semantic layer и утвержденные метрики, лучше начинать с BI API. Прямой SQL дает гибкость, но повышает риск неверных формул и доступа к лишним данным.
Можно ли агенту делать выводы о причинах?
Да, но аккуратно. Он должен отделять подтвержденный факт от гипотезы. “Канал X просел” - факт, если видно в данных. “Причина в новой рекламной кампании” - гипотеза, если нет прямой проверки.
Как защитить персональные данные?
Используйте агрегаты, ACL, запрет на персональные поля, лимиты строк и audit log. Если пользователь не имеет доступа к дашборду или dataset, агент не должен показывать данные.
Что автоматизировать первым?
Каталог метрик, ответы по готовым дашбордам и weekly summary. Генерацию новых запросов добавляйте после настройки validator и словаря метрик.
