От дашбордов к действиям: как строить ИИ‑агентов, которые реально работают — VogueTech

Что появилось / что изменилось

Бруно Азиза, Group Vice President по данным, BI и AI‑стратегии в IBM, предлагает довольно приземлённый взгляд на ИИ‑агентов. Не про «магических ассистентов», а про конкретную инфраструктуру и процессы.

Главные сдвиги, о которых он говорит:

Переход от «дашбордов ради дашбордов» к системам, которые приводят к действию. Пример: компания сделала 20 000 дашбордов за год, и у 18 000 из них было меньше восьми пользователей.
Появление команд, где наряду с людьми работают десятки и сотни ИИ‑агентов. Один из клиентов Азизы описывает свой штат так: 200 сотрудников, из них 50 людей и 150 агентов.
Фреймворк из двух уровней для работы с агентами:
- Agent Minus — фундамент: правила, инструменты, рабочие процессы, единые данные.
- Agent Plus — оркестрация сотен агентов от разных вендоров и команд разработки.
Чёткое разделение двух психологических ловушек при запуске ИИ‑инициатив:
- FOMO (Fear of Missing Out) — делать ИИ «чтобы не отстать».
- FOMU (Fear of Messing Up) — бояться ошибиться до паралича.

Фокус смещается с «какую модель взять» на «как строить систему, которая выдержит смену моделей, провайдеров и задач».

Как это работает

Азиза предлагает смотреть на ИИ‑агентов не как на отдельный продукт, а как на надстройку над уже существующей архитектурой.

Agent Minus: фундамент под агентами

Под Agent Minus он понимает всё, что идёт до агента:

правила бизнеса (кто что может делать, какие решения допустимы);
инструменты (CRM, ERP, системы поддержки, BI);
рабочие процессы (как проходит сделка, поставка, онбординг клиента);
единая схема данных.

Пример Heineken: прежде чем запускать агентов, компания привела в порядок 100 000 элементов данных. Только после этого они начали добавлять ИИ‑слой. Логика простая: если процесс полезен — его стоит автоматизировать, если нет — лучше убрать, а не ускорять его с помощью ИИ.

Agent Plus: оркестрация

Когда фундамент готов и в компании появляется много агентов, начинается этап Agent Plus:

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

Главная проблема здесь — оркестрация:

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

Отдельный принцип Азизы — строить архитектуру так, чтобы можно было быстро «перемешивать» компоненты: менять провайдера, размер модели, инструменты, не переписывая всё с нуля.

Что это значит для вас

Если вы отвечаете за ИИ‑инициативы, BI или продукт:

Пересчитайте свои «дашборды». Сколько отчётов и панелей реально используют? Если картина похожа на пример с 20 000 дашбордов и 18 000 почти пустых — у вас не аналитика, а музей графиков.
- Всё, что не приводит к действию, можно смело отправлять в архив.
Не запускайте агентов на мусорных процессах.
- Сначала спросите: этот процесс вообще нужен?
- Если да — стандартизируйте данные и шаги.
- Если нет — не тратьте бюджет на его автоматизацию.
Проверьте себя на FOMO и FOMU.
- FOMO: вы делаете пилот «потому что у конкурентов есть агент»? Это плохое основание.
- FOMU: каждый тестовый проект закапывается в согласованиях? Вы не узнаете, что реально работает.
Стройте Agent Minus до Agent Plus.
- Начните с инвентаризации правил, инструментов и процессов.
- Пример Heineken с 100 000 элементов данных — хороший ориентир масштаба работ, если у вас глобальный бизнес.
Готовьтесь к миру «50 людей и 150 агентов».
- Это уже не фантастика, а текущие кейсы.
- Подумайте, какие роли в вашей команде первыми превратятся в связку «человек + несколько специализированных агентов».

Если ваш бизнес работает из России, к самим идеям Agent Minus/Plus и фреймворкам Азизы это не привязано: это подход к архитектуре и процессам, а не конкретный западный SaaS. Реализовать можно на локальных платформах и своих моделях.

Место на рынке

Азиза говорит не о конкретном продукте IBM или отдельной модели, а о подходе к внедрению ИИ‑агентов в крупных компаниях.

По сути, он конкурирует не с GPT‑4o или Claude 3 по скорости или цене, а с хаотичным способом внедрения ИИ:

вместо «сделаем чат‑бота на модной модели» — фокус на том, какие процессы и данные лежат под ним;
вместо одиночных пилотов — картина, где в компании живут сотни агентов и их нужно согласованно управлять.

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

Кому это полезно:

CDO, CPO, CTO и лидерам продуктовых и данных команд в крупных компаниях;
тем, кто уже наделал десятки пилотов и не видит отдачи;
тем, кто только планирует агентов и хочет избежать ловушек FOMO и FOMU.

Кому вряд ли зайдёт:

небольшим командам, которым пока рано думать про оркестрацию сотен агентов;
тем, кто ждёт готовый «волшебный» продукт, а не работу с процессами и архитектурой.