В последнее время я часто слышу от разных клиентов одно и то же: они добавили уровень ИИ в свою среду, ожидали, что все станет лучше, но пока не заметили особых изменений.

На практике то, что я вижу в первую очередь, обычно находится на верхнем уровне — будь то copilot, уровень корреляции AIOps или агент, способный рассуждать с использованием различных инструментов. Эта часть помогает быстрее создавать черновики, классифицировать данные и давать рекомендации. Перевод этой работы в промышленную эксплуатацию по-прежнему происходит на другом уровне, и он обычно выглядит так же, как и до внедрения ИИ, с теми же передачами задач, очередями и согласованиями. В обзоре Red Hat «ИИ против автоматизации: в чем разница?» описывается это же разделение. Одна сторона интерпретирует и рекомендует; другая выполняет предопределенную работу последовательно и под контролем. В полевых условиях я обращаю внимание на то, проектируют ли команды путь к промышленной эксплуатации с тем же умыслом, что и работу с ИИ на верхнем уровне, или оставляют существующие процессы без изменений.

Я часто объясняю это с помощью аналогии с водопроводом. Если подавать больше воды в здание без достаточного количества труб, клапанов и стоков, вы получите не лучший поток, а потоп. ИИ увеличивает давление в верхней части стека. Он не строит трубы, клапаны и стоки, необходимые для безопасного управления возросшим потоком.

Когда команды считают эти уровни одинаковыми возможностями, в работе с клиентами возникает та же путаница.

Три путаницы, с которыми я сталкиваюсь при работе с клиентами

Грань между помощью ИИ и истинной автоматизацией быстро стирается. Когда copilots генерируют плейбуки, AIOps диагностирует инциденты, а инструменты получают ярлык «агентных», команды предполагают, что продакшен работает сам по себе только потому, что объем ручного ввода текста уменьшился. С точки зрения архитектора автоматизации, это ощущение обычно сводится к 3 заблуждениям:

Инсайт против выполнения: легко принять результат работы верхнего уровня за завершенную работу, но продакшн по-прежнему требует регулируемого выполнения, которое можно отследить, и смешение этих двух понятий и есть ошибка. Пример с наблюдаемостью (observability) и AIOps — частый случай. Путь от наблюдаемости к автоматизации AIOps показывает, как аналитика и триаж связаны с регулируемым выполнением на платформе автоматизации, а не ограничиваются лишь инсайтами.
Создание контента против среды выполнения: сгенерированные плейбуки и роли по-прежнему нуждаются в проверке, тестировании и продвижении, прежде чем они станут доверенной автоматизацией. Создание черновика контента — это не то же самое, что его выполнение в соответствии с политикой.
Агент как автоматизация: предоставление агенту широкого доступа к продакшну для исправления проблем выглядит как прогресс, но часто заменяет ручную передачу задач неаудируемыми, неповторяемыми изменениями, где модель становится уровнем интеграции, и каждый запуск может выглядеть по-разному.

Как только эти понятия сливаются в одну идею под названием «ИИ», команды упускают из виду сложные вопросы: кто может действовать, на каких системах, при каком одобрении и с какими доказательствами в случае сбоя?

Чего стоит эта путаница

Когда ИИ путают с автоматизацией, программы терпят неудачу предсказуемым образом.

Инсайт без завершения: рекомендации попадают в чат, электронную почту или комментарии к тикетам, в то время как AIOps или наблюдаемость могут одновременно улучшить триаж. Объем запросов и уверенность в дашбордах растут, но работа по-прежнему закрывается через те же этапы передачи, а инциденты часто решаются не быстрее и с тем же объемом ручных усилий.
Скорость без управления: команды дают агенту учетные данные, чтобы заполнить этот пробел. Агент «исправляет» инциденты быстрее, пока что-то не ломается и никто не может восстановить масштаб, личность или историю изменений. Откат изменений остается неопределенным.
Автоматизация не того, что нужно: команды кодируют сегодняшние обходные пути в плейбуки или сгенерированный контент, а затем просят ИИ оптимизировать их. Пропускная способность растет, но лежащий в основе процесс не улучшается.

Я видел сокращенную версию этого паттерна в недавнем проекте. Стек наблюдаемости и уровень AIOps выполняли реальную работу: меньше дублирующихся алертов, лучшая группировка и более четкая степень серьезности повторяющихся сбоев инфраструктуры. Руководство видело «помощь ИИ для операций», но инциденты с теми же типами сбоев по-прежнему занимали столько же времени на решение и требовали такого же количества ручных изменений в продакшене. Аналитики по-прежнему открывали тикеты, вставляли предлагаемые исправления и ждали ручного одобрения для запуска исправлений.

Поворотным моментом стало не обновление стека ИИ, а подключение надежных сигналов к правилам Event-Driven Ansible. Эти правила запускали проверенные шаблоны заданий и рабочие процессы для сбора фактов, обогащения тикетов, применения известных исправлений или эскалации. Это была точно такая же утвержденная автоматизация, которую оператор запускал бы вручную, проводя четкую границу там, где ИИ останавливается и начинается регулируемое выполнение.

Общая черта заключается вовсе не в ИИ. Дело в отсутствующем «водопроводе» между решениями на базе ИИ и изменениями, вносимыми в производственные системы.

Паттерн, который работает

Паттерн, который работает, состоит из 2 уровней, соединенных намеренно. ИИ верхнего уровня обнаруживает и принимает решения. Он классифицирует, сопоставляет и дает рекомендации. Нисходящая автоматизация выполняется под контролем, которому ваши операторы уже доверяют. Сигнал или рекомендация поступают на вход; на выходе получается контролируемое изменение; история заданий и утверждения показывают, что продакшн закрыт. Это операционный цикл, который я оцениваю при проверках.

Для ИТ-операций я рекомендую клиентам Red Hat Ansible Automation Platform, когда им нужно сделать этот паттерн явным. При проверке проектов я добавляю 3 ограничения, которые команды часто упускают из вида, когда сначала фокусируются на стеке верхнего уровня:

Единый словарь утвержденных действий: выполняются одни и тем же шаблон задания и рабочий процесс независимо от того, кто их инициирует — человек, Event-Driven Ansible или агент. Триггер меняется; управляемый контент и журнал аудита — нет.
Создание контента — это не среда выполнения: генеративные помощники могут помочь составить плейбуки и рекомендации, но в продакшене запускается проверенный контент автоматизации, продвигаемый как любое другое изменение, а не черновик прямо из промпта.
Агенты попадают в продакшн через платформу, а не в обход нее: сервер протокола контекста модели (MCP) на Ansible Automation Platform предоставляет инструменты проверки и запуска, привязанные к токену реального пользователя и управлению доступом на основе ролей (RBAC). Агент не имеет прямых учетных данных для управляемой инфраструктуры; он вызывает ту же контролируемую поверхность, которую используют все остальные. Мы обсуждаем этот паттерн на стороне выполнения в материале «Путь от наблюдаемости к автоматизации AIOps», наряду с наблюдаемостью и AIOps.

Event-Driven Ansible обычно служит мостом от наблюдаемости или AIOps в этот цикл: сигналы сопоставляются с правилами, правила запускают утвержденные задания, и существуют ограничения на параллельные запуски и шлюзы утверждения, когда сигнал недостаточно четок для самостоятельных действий. На выходе рабочий процесс по-прежнему может вызывать ИИ верхнего уровня, когда плейбуку требуется экспертная оценка. В обоих направлениях цикл замыкают только утвержденный контент автоматизации или оператор.

ИИ помогает масштабировать любой имеющийся у вас уровень выполнения, но эти ограничения позволяют укрепить этот уровень, а не обходить его.

Заключительные мысли

В обзорах я не начинаю с выбора модели ИИ. Я прошу показать продакшн-задачу, выполненную через путь ИИ, с доказательствами, которые можно проверить. Если этот след слаб, причиной обычно является упомянутая выше размытость, а не то, какую модель ИИ они используют.

Вам нужны ИИ и автоматизация, но для разных задач. Выберите 1 путь, который должен быть пройден в соответствии с регламентом и считаться «выполненным» в производственных терминах: успешное задание, обновленный тикет и запись в журнале аудита. Внедрите аналитику на верхнем уровне там, где это помогает, настройте выполнение через утвержденную автоматизацию на нижнем уровне, а затем оцените, улучшились ли результаты.

И если ваша организация все еще описывает неформальные процессы и ужесточает управление ИИ, вы можете делать это параллельно. Это не заменяет уровень выполнения, но делает масштабирование цикла более безопасным.

Когда вы будете готовы закрепить этот цикл на платформе, Ansible Automation Platform станет тем местом, где шаблоны заданий, рабочие процессы, утверждения и история заданий могут существовать и работать вместе. Если вы хотите внедрить агентный ИИ, начните с сервера MCP на Ansible Automation Platform, чтобы проверка и запуск оставались в рамках той же среды с поддержкой RBAC, что и все остальное.