Создать небольшого агента сегодня можно быстрее, чем оформить его запуск по корпоративным правилам. На прототип уходит час, на согласование описание доступов и владельцев — несколько дней.
Отсюда и начинается агентный хаос: с момента, когда скорость создания цифровых помощников становится выше скорости назначения ответственности и правил. В результате вокруг бизнеса вырастает слой маленьких автоматизаций, о которых знают только их авторы.
Разберем, почему это опасно — и какой контур управления нужен, чтобы в компании не появилась теневая инфраструктура.
Почему хаос создают маленькие решения
Крупный ИТ-проект невозможно запустить так, чтобы никто этого не заметил. У него есть команда, бюджет, документация, владельцы и поддержка. С небольшим агентом дела обстоят совсем по-другому — это может быть бот с ежедневным отчетом или скрипт интеграции сервисов. Собрать его можно быстрее, чем пройти стандартную процедуру запуска — и ее начинают игнорировать.
Отсюда и появляется хаос: автоматизация уже работает с корпоративными данными и выполняет действия, но о ней могут не знать DevOps, финансы или команда поддержки. Не определено, кто устранит сбой, во сколько обходится решение — и что случится, если создатель такого решения вдруг станет недоступен.
Полный процесс запуска большого проекта здесь избыточен, но полностью обходить контроль нельзя. Его надо облегчить: зарегистрировать решение, описать доступы, стоимость, поддержку и условия отключения.
В заложниках автоматизации
Создатель цифрового помощника нередко остается единственным человеком, знающим, что он существует и как он устроен. Пока все работает, это незаметно. Затем меняется шаблон файла или ломается интеграция — и автоматизация возвращается к своему автору.
Мы и сами как-то столкнулись с похожим эффектом: небольшие внутренние решения начали периодически «дергать» создателя обратно. Например, агент каждую неделю отправляет в канал маркетинга отчеты, а тут вдруг не прислал — надо разбираться. Сломалась автоматизация, связанная с рекрутингом — команда ждет, когда автор придет и все починит. Если инструмент уже встроен в важный процесс, создавший его специалист остается единственной точкой знания.
Отсюда полезное разделение: человек, который понимает бизнес-проблему и придумал агента, не обязан годами обслуживать его. Создание требует одной экспертизы, эксплуатация — другой.
Владельца мало, но кто еще нужен?
Если одного только создателя автоматизации недостаточно, значит, нужен еще специалист, который возьмет на себя другую ответственность. Для корпоративного агента полезно разделять минимум две роли:
- Бизнес-владелец — отвечает за то, зачем инструмент существует, какую пользу приносит и когда его пора отключить.
- Технический владелец — отвечает за работоспособность, инфраструктуру, обновления и инциденты.
Финансы могут следить за оплатой сервисов, DevOps — за инфраструктурой, профильное подразделение — за экономическим эффектом. Так решение перестает быть намертво привязанным к автору.
Когда агент становится частью теневой инфраструктуры
Риск появляется, когда у цифрового помощника появляется доступ к данным и право что-то менять, а в компании при этом не знают, кто за него отвечает.
Для реальной работы ему нужны полномочия: читать документы, отправлять сообщения, менять записи, создавать файлы. Чем больше таких решений существует вне общего контура, тем труднее понять, куда передается информация и какие действия выполняются от имени сотрудников.
Ограничения лучше задавать не только в инструкции. Если действие технически доступно, одного запрета «не делай этого» маловато. Для чувствительных операций права можно урезать через промежуточный сервис, который разрешает только нужные вызовы.
Минимальный паспорт автоматизации вместо бюрократии
Для небольших агентов достаточно облегченного «паспорта». Так, перед выходом из личной песочницы должно быть понятно:
- какую бизнес-проблему решает автоматизация и по какому показателю будет понятна ее польза;
- кто отвечает за ценность, а кто — за техническую часть;
- какими данными она пользуется;
- какие действия ей разрешены и где требуется подтверждение человека;
- сколько она стоит и кто ее поддерживает;
- от каких сервисов зависит;
- когда ее пересмотреть и при каких условиях отключить.
Последние два пункта особенно важны. Агент может долго быть полезным, а потом утратить актуальность. Если никто не отвечает за пересмотр, он продолжит использовать токены, ключи и серверные ресурсы.
Так среди помощников появляются «зомби-агенты». Бизнес уже забыл, зачем они нужны — а расходы и доступы никуда не делись.
Пять одинаковых агентов — тоже хаос
Представьте, что специалист автоматизировал какой-то процесс. Спустя пару месяцев второй сотрудник решил эту же задачу, но другим способом, а чуть позже третий сделал свой вариант, даже не подозревая о первых двух.
Кроме того, есть другой, более опасный вариант, когда несколько автоматизаций управляют одним объектом. Например, один агент обновил карточку в CRM, второй в тот же день сделал это снова, но по своим правилам
В итоге компания несколько раз платит временем за создание одной и той же функции — и, более того, продолжает поддерживать несколько реализаций. Чтобы этого не произошло, нужен хотя бы самый простой каталог, где расписано, какие агенты уже существуют, для чего и кто владелец. Перед созданием решения стоит удостовериться, нет ли уже рабочего аналога — а для критичных объектов заранее определить, какая автоматизация имеет право их менять.
Само количество агентов при этом мало о чем говорит: пять полезных и управляемых сервисов могут быть лучше пятидесяти экспериментов. Важнее бизнес-эффект при понятной полной стоимости и уровне риска.
«Сделано за час» — еще не значит «дешево»
Агент продолжает потреблять ресурсы после запуска: токены, серверные мощности, подписки и время поддержки. По отдельности суммы малы — но десяток автоматизаций, например, уже превращается в постоянную и заметную статью расходов.
Считать нужно полную стоимость владения. Прежде чем создать агента, надо подумать: а кто будет чинить сбои и обновлять интеграции? Кто заметит, что расходы вдруг существенно выросли? Есть ли вообще в компании ответственный, который регулярно отслеживает, сколько денег уходит на все подобные инициативы?
Если не учитывать этот важный момент, «быстро и дешево собрали» легко превратится в «дорого и незаметно поддерживаем».
Не всем агентам нужен одинаковый контроль
Персональный помощник и корпоративный — это разные классы риска. К примеру, если ИИ помогает специалисту собрать данные или подготовить отчет, а человек сам проверяет работу и отправляет результат, достаточно легкого контроля.
Совсем другое дело — автоматизация, которая переносит данные между сервисами, пишет в общие каналы или меняет записи без ручной проверки. Здесь необходимы владельцы, мониторинг и понятные права доступа.
Критичность тоже различается. Если внутренний бот для маркетинга не прислал еженедельный отчет, бизнес это переживет. А вот если остановился инструмент, от которого зависят продажи или рекрутинг, задержка может обойтись компании недешево. Для таких сервисов нужны SLA, резервный ответственный и порядок восстановления.
Дело не в сотом агенте
Количество агентов само по себе мало о чем говорит. Проблема начинается, когда компания уже не может быстро понять, кто отвечает за конкретную автоматизацию, к каким данным у нее есть доступ, сколько она стоит и нужна ли вообще.
Возвращать для каждого небольшого агента полный процесс запуска крупного ИТ-проекта нет смысла. Достаточно обязательного минимума: реестр, бизнес- и технический владельцы, понятные доступы, стоимость, поддержка и условия отключения. Такой облегченный порядок позволяет не тормозить эксперименты и при этом делает автоматизации видимыми и управляемыми.
Бизнес-владелец отвечает за ценность решения, технический — за его работу и восстановление после сбоев. И даже полезного агента нужно периодически пересматривать: задача может исчезнуть, а расходы на токены, инфраструктуру и поддержку останутся.
Поэтому запуск агента — не конец задачи. После него появляется новый корпоративный актив, который нужно сопровождать и контролировать.
