В облачной среде обнаружились 34 ресурса: VPC, подсети, экземпляр RDS и балансировщик нагрузки, который давно не видел полезного трафика. Если эту инфраструктуру развернул ИИ-агент, вопрос владения облачными ресурсами перестаёт быть бюрократией: непонятно, кто оплатит счёт, устранит уязвимость и нажмёт кнопку удаления. Для российских команд, активно автоматизирующих DevOps и FinOps, это следующий неприятный побочный эффект агентного ИИ.
Как сообщает The New Stack, типичная картина выглядит не как авария, а как обычная уборка в облаке: инженеры видят десятки объектов, но не могут быстро связать каждый из них с сервисом, командой и владельцем бюджета. VPC, subnet, база данных и load balancer сами по себе не выглядят экзотикой. Проблема возникает, когда их создал агент по задаче в чате, в пайплайне или по сигналу системы, а после выполнения запроса не осталось понятного человека или команды, отвечающих за результат.
В классической модели у ресурса обычно есть хотя бы один след: аккаунт разработчика, репозиторий Terraform, тикет, тег cost center или имя команды в облачном аккаунте. Агентная автоматизация способна разорвать эту цепочку. Агент действует от имени пользователя, использует сервисные учётные данные, вызывает API и может создать инфраструктуру быстрее, чем владелец запроса успеет открыть консоль облачного провайдера. Формально действие совершила техническая учётная запись. Фактически его мог инициировать разработчик, продуктовая команда или вовсе другой автоматический процесс.
Отсюда появляются сразу три вида долга. Первый — финансовый: забытые ресурсы продолжают потреблять бюджет. Второй — операционный: никто не следит за сроками сертификатов, бэкапами, обновлениями и лимитами. Третий — риск безопасности: открытая сеть, лишние права доступа или база с данными могут существовать дольше, чем эксперимент, ради которого их создали. Ресурс без владельца — это не «ничейная» инфраструктура, а актив с неопределённой ответственностью.
Платформенные команды уже умеют решать похожую задачу через infrastructure as code, policy as code и обязательные теги. Но ИИ-агенты требуют сделать эти правила более жёсткими и машиночитаемыми. Недостаточно попросить разработчиков указывать owner в описании задачи: агент должен не иметь возможности создать ресурс без обязательных метаданных. Минимальный набор — владелец, команда, продукт или проект, среда, срок жизни и центр затрат. Если часть полей неизвестна, разумнее отправить запрос на согласование, а не создавать очередную «временную» базу.
Полезен и принцип ограниченного радиуса поражения. Агенту не обязательно выдавать доступ администратора ко всему облачному аккаунту ради тестового окружения. Более безопасная схема — отдельные песочницы, заранее одобренные шаблоны и лимиты на типы ресурсов. Например, агент может создавать инфраструктуру только в выделенном аккаунте, только из каталогов, проверенных платформенной командой, и только с автоматическим временем удаления. Это несколько замедляет магию формата «сделай мне стенд», зато не превращает облако в склад технических артефактов с неизвестным происхождением.
Для FinOps задача тоже меняется. Раньше достаточно было распределить расходы между командами и найти аномалии в счетах. Теперь потребуется различать ресурсы, созданные человеком, пайплайном и агентом, а также хранить контекст решения: кто поставил задачу, какой агент её выполнил, по каким правилам и на какой срок. Иначе ежемесячный отчёт покажет лишние затраты, но не ответит, кому адресовать вопрос. Владение облачными ресурсами должно фиксироваться в момент создания, а не восстанавливаться детективным методом после закрытия квартала.
Разработчикам это не означает запрет на агентов. Напротив, агентные сценарии могут снять рутину с SRE и DevOps-инженеров: подготовить окружение, собрать диагностику, создать тестовые компоненты. Но автономность должна идти вместе с наблюдаемостью. Логи вызовов, идентификатор задачи, исходный запрос, применённый шаблон и история изменений нужны не только для расследований. Они позволяют понять, полезна ли автоматизация вообще: сколько ресурсов агент создал, сколько затем удалил, сколько потребовали ручного вмешательства и какие правила он чаще всего нарушал.
Главный вопрос здесь не в том, сможет ли ИИ-агент создать VPC или RDS: с облачными API это уже технически тривиально. Вопрос в том, смогут ли компании встроить в этот процесс ответственность так же надёжно, как права доступа и лимиты. Чем больше действий агенты будут выполнять в production-подобных средах, тем важнее станет владение облачными ресурсами — не как поле в таблице, а как обязательная часть архитектуры автоматизации.