В первых двух статьях я рассказывал, как мы в команде ИИ-автоматизации строили внутреннюю платформу для клиентской поддержки. Запускали модели, подключали внутренние системы, создавали помощников для инженеров и постепенно закрывали самые очевидные сценарии.
За несколько месяцев у нас появилась автоматическая классификация обращений, суммаризация переписки, маршрутизация тикетов и полноценные сценарии, в которых агенты самостоятельно решают часть задач клиентов.
Все это работало и приносило пользу.
Но в какой-то момент прогресс практически остановился. Почти все «низко висящие фрукты» были собраны, а каждый следующий сценарий требовал все больше времени и усилий.
Сначала я думал, что проблема в моделях, качестве промптов или архитектуре агентов. Но причина оказалась совсем в другом: мы пытались автоматизировать работу людей там, где менять нужно было сам подход к автоматизации.
Именно это в итоге и заставило нас полностью пересмотреть архитектуру решений автоматизации. Сейчас расскажу, как это было.
Инженерная поддержка облака — это не классический саппорт
Когда говорят о технической поддержке, многие представляют кол-центр с операторами за перегородками, которые отвечают по заранее подготовленным инструкциям. В Cloud.ru все устроено иначе.
Мы развиваем несколько облачных платформ, в которые входят более 200 сервисов. Каждый день наши инженеры помогают клиентам разбираться с Kubernetes, сетевой связанностью, сервисами для работы с ИИ, GPU-инфраструктурой, инференсом моделей, PostgreSQL, Kafka, балансировщиками нагрузки, объектными хранилищами и десятками других технологий.
По сути, это уже не классическая поддержка, а полноценная инженерная работа.
Чтобы понять, почему деградировал инференс или перестал отвечать Kubernetes API, недостаточно открыть документацию и найти нужный абзац. Инженер смотрит графики и логи, работает с внутренними инструментами, запускает диагностические утилиты и последовательно проверяет гипотезы.
При этом решение конкретной проблемы зависит не только от инструкций, но и от опыта специалиста: какие симптомы он уже видел, где в первую очередь ищет причину и в каком порядке проверяет компоненты системы.
Поэтому эту аналитику ситуации нельзя отдать одному простому агенту. Но и мультиагентная система справится не всегда: способов решить одну и ту же проблему может быть несколько, а набор доступных агентам инструментов все равно ограничен.
Почему классическая автоматизация перестала масштабироваться
Первый подход к автоматизации казался вполне логичным. Я вместе с командой ИИ-автоматизации приходил в продуктовые команды, наблюдал за работой инженеров, описывал их действия и пытался превратить их в ИИ-сценарии.
Диалог почти всегда строился одинаково:
— Расскажите, как вы решаете эту задачу, а мы попробуем научить этому агента.
Довольно быстро я понял, что такой подход практически не работает.
Чтобы автоматизировать диагностику одного сервиса, специалисту из команды ИИ-автоматизации приходилось самому погружаться в этот сервис почти на уровне профильного инженера: разбираться в архитектуре, изучать внутренние API и runbook’и, понимать связи между компонентами и выяснять, почему Grafana, Kibana и внутренние диагностические утилиты открываются именно в такой последовательности.
На погружение в один сервис могли уходить недели. А сервисов, напомню, у нас больше 200.
Тогда я понял: бутылочное горлышко — это не LLM. Главным ограничением стали знания инженеров, которые невозможно быстро передать команде ИИ-автоматизации.
К каким выводам мы пришли
Пока я вместе с командой разбирался с этой проблемой внутри компании, похожие ситуации начали появляться и в отраслевых исследованиях.
В Microsoft Work Trend Index 2026 используется понятие Human Agency. Авторы описывают переход от модели, в которой ИИ выполняет отдельные задачи, к модели, где человек управляет несколькими специализированными агентами и отвечает за итоговый результат.
При таком подходе главным ограничением становится уже не качество моделей, а способность компании изменить привычные процессы.
К похожим мыслям приходит Boston Consulting Group в исследовании AI at Work 2026. Компании, которые просто внедряют отдельные ИИ-инструменты, получают меньший эффект, чем те, кто меняет сами процессы и дает сотрудникам возможность перестраивать свою работу.
Для нас отсюда следовал важный вывод.
Задача команды ИИ-автоматизации не в том, чтобы самостоятельно написать тысячу агентов. Наша задача — создать условия, в которых эту тысячу агентов смогут написать сами инженеры, используя свою доменную экспертность.
Именно это полностью изменило наш дальнейший подход к работе с командами.
Вместо рыбы решили раздать удочки
Мы перестали спрашивать команды:
— Что вам автоматизировать?
И начали задавать другой вопрос:
— Что мешает вам автоматизировать это самостоятельно?
Ответы были довольно предсказуемыми:
нет удобного доступа к моделям;
не хватает готовых инструментов;
нет безопасной среды с понятными правилами и ограничениями;
инфраструктуру приходится собирать самостоятельно;
не с кем обсудить идею или проверить гипотезу.
Эти ответы убедили нас в том, что, вместо того чтобы разрабатывать отдельных агентов, нужно убирать барьеры, которые мешали инженерам делать это самим.
Сначала появились евангелисты
Мы не стали спускать сверху KPI на внедрение ИИ. Вместо этого я начал искать людей в клиентской поддержке, которые уже интересовались технологией и пробовали применять ее в работе. Смотрел, кто сам приходил за API-ключами, просил доступ к моделям, экспериментировал с промптами или писал небольшие внутренние утилиты.
Постепенно почти в каждой инженерной команде появился человек, которому было интересно развивать это направление. Вокруг этих людей и сформировалось первое внутреннее инженерное ИИ-сообщество.
Затем мы убрали технические барьеры
Следующей задачей для нашей команды было убрать технический порог входа. Инженер не должен тратить неделю на настройку инфраструктуры, прежде чем написать своего первого агента.
Для этого мы развернули локальные модели, настроили Guardrails (писали про это тут), подготовили безопасную среду и помогли собрать первые MCP-серверы.
Все это объединили в одном инструменте, добавили инструкции и передали инженерным командам.
В результате специалист мог сосредоточиться на своей задаче, а не разбираться с развертыванием моделей, доступами и базовой инфраструктурой.
И произошло то, чего мы не ожидали
Почти сразу начали появляться сценарии, которые команда ИИ-автоматизации вряд ли придумала бы сама.
Кто-то создал агента, который автоматически проходит диагностический runbook. Кто-то подключил внутренние API и научил модель разбирать алерты. Кто-то избавился от ручного grep по логам. Еще один инженер собрал помощника, который проверяет конфигурацию Kubernetes перед обновлением.
Почти все эти сценарии решали локальные, но конкретные задачи. И именно поэтому они оказались настолько ценными.
Агентов создавали инженеры, которые каждый день работают с конкретным сервисом, знают его архитектуру, типичные проблемы и неочевидные особенности. Им не нужно было несколько недель погружаться в предметную область: все необходимые знания у них уже были.
Мы в команде ИИ-автоматизации могли бы месяцами проводить интервью, описывать процессы и собирать таких агентов сами. Инженеры делали это быстрее, потому что точно знали, какую часть своей работы хотят убрать.
Но одних инструментов недостаточно
Мы собрали сообщество инженеров, которые делятся опытом, показывают свои решения и помогают коллегам внедрять ИИ в работу. Проект получил название «ИИ Авангард».
Но одной платформы для этого было недостаточно. Любая внутренняя инициатива быстро затухает, если участники не видят результатов своей работы и не понимают, зачем продолжать.
Поэтому параллельно мы собрали систему нематериальной мотивации — добавили лидерборды, внутреннюю валюту и ачивки. Сейчас баллы можно получить за создание агентных сценариев, разработку MCP-серверов и переиспользуемых Tool’ов и помощь другим командам.
Самые интересные сценарии и результаты мы регулярно показываем внутри компании. Так разработки не остаются внутри одной команды, а инженеры видят, что уже сделали коллеги и что можно переиспользовать у себя. А для самого сообщества мы создали общий чат и пространство в Confluence, придумали нейминг, визуальный стиль и внутренние механики.
Для меня ценность проекта «ИИ Авангард» не только в мотивации. Он делает инженерные практики заметными, помогает быстрее находить готовые решения и показывает, к кому можно прийти за консультацией.
Как масштабировать новую инженерную практику на 100 человек
Следующим вопросом стало масштабирование.
Можно написать подробную документацию, но практика показывает, что большую ее часть никто не прочитает.
Можно провести обучение, но через неделю половина участников забудет материал.
Можно записать видеокурс, но его будут смотреть на скорости 2х, пока не появится кнопка «Пройти тест».
Можно назначить ИИ-чемпионов, но тогда есть риск, что именно они и останутся единственной группой, которая занимается агентами, а остальные инженеры продолжат приносить им задачи на автоматизацию.
Нас такой вариант не устраивал.
Мы хотели, чтобы уже через два дня десятки инженеров использовали собственных агентов в ежедневной работе. Не просто послушали лекцию, посмотрели демонстрацию или прочитали документацию, а сами прошли весь путь — от рабочей задачи до готового сценария.
В итоге решили действовать по-другому и разработали подход, который действительно работает не только на евангелистах, но и на всех остальных сотрудниках.
Об этом расскажу в следующей статье.
