Большинство компаний, приступающих к внедрению агентного ИИ, начинают с одного и того же вопроса: какую модель нам использовать? Это неверная отправная точка. На практике возможности модели редко определяют, будет ли программа успешной или нет. То, что это определяет, находится в самом основании — и большинство компаний еще не до конца это осознали.
Агентный ИИ в ИТ-операциях — это не скромное обновление того, что большинство организаций уже внедрили. Прогностические модели выдают рекомендации. Генеративный ИИ помогает людям писать черновики и обобщать информацию. Агентные системы делают нечто принципиально иное — они действуют. Они разрешают инциденты, реконфигурируют инфраструктуру, запускают последующие процессы. Часто не дожидаясь подтверждения от человека. Этот переход от рекомендаций к действиям полностью меняет уравнение готовности, и те риски, которые в более ранних внедрениях ИИ казались лишь неудобствами (разрозненные данные, отсутствие защитных механизмов, несвязанные рабочие процессы), превращаются в реальные операционные уязвимости.
Мы работали с компаниями, которые вложили значительные средства в выбор моделей, но уделили недостаточно внимания фундаментальным принципам, определяющим, можно ли вообще безопасно развернуть эти возможности. В результате получается агентный ИИ, который впечатляюще работает в песочнице, но испытывает серьезные трудности в рабочей среде. Чтобы сделать все правильно, нужно с самого начала иначе подойти к вопросу готовности.
Принцип первый: Единая телеметрия и качество данных
Если и есть что-то одно, что отличает компании, действительно готовые к автономным ИТ-операциям, от тех, которые не готовы, так это то, насколько осознанно они построили инфраструктуру для сбора и нормализации операционных данных. Это работа, от которой зависит все остальное.
Агентные системы используют телеметрию, чтобы понять состояние среды и принять решение о дальнейших действиях. Когда эта телеметрия противоречива или изолирована по разным командам, агент по сути делает выводы на основе искаженной картины реальности. Он может неверно истолковать сигналы, действовать на основе устаревших данных или — что опаснее — пропустить ранние признаки лавинообразного сбоя, потому что соответствующие логи находятся в системе, с которой он не может сопоставить данные. Человек-оператор привносит контекстное суждение в неоднозначные входные данные. Агентная система действует на основе того, что она получает.
Здесь стоит особо упомянуть OpenTelemetry. Будучи нейтральным к вендорам открытым стандартом для сбора и экспорта метрик, событий, логов и трасс в гетерогенных средах, он нормализует телеметрию на уровне конвейера, не требуя полной замены существующих агентов. Разница между автономной системой, анализирующей стандартизированную, коррелированную телеметрию, и системой, анализирующей нормализованные по принципу «как получится» разнородные форматы, не является незначительной. Это разница между надежной основой для автономных действий и фундаментом, который в конечном итоге приведет к досадным инцидентам.
Принцип второй: Управление и защитные механизмы
Во многих организациях инстинктивно воспринимают управление как ограничение — то, что замедляет работу агентного ИИ. Мы бы хотели напрямую возразить против такой постановки вопроса: управление — это то, что вообще делает автономность масштабируемой.
Агентная система без защитных механизмов не становится более функциональной. Она становится более опасной. В ИТ-операциях радиус поражения от некорректного автономного действия может быть значительным и быстро распространяющимся. Неправильно настроенный откат, ошибочный переход на резервное копирование, решение о пропускной способности, которое лавинообразно распространяется на зависимые сервисы до того, как кто-то заметил неладное. Вопрос никогда не заключается в том, нужно ли ограничивать агентные системы. Вопрос в том, как ограничить их разумно, чтобы автономность расширялась по мере завоевания доверия, а не тогда, когда риски незаметно накапливаются на заднем плане.
На практике это означает определение четких границ того, что системе разрешено делать без проверки человеком. Низкорисковые высокочастотные действия — перезапуск службы, подтверждение известного паттерна алерта — могут быть полностью автоматизированы относительно рано. Действия с серьезными последствиями, затрагивающие производственные базы данных или влияющие на выручку системы, должны сохранять шаг участия человека в контуре управления (human-in-the-loop), по крайней мере до тех пор, пока система не продемонстрирует стабильное принятие решений в течение значительного периода времени. Не недели. Не спринта. Достаточного времени для того, чтобы столкнуться с краевыми случаями.
Компании, которые заранее инвестируют в создание такой архитектуры управления, масштабируют свои агентные операции значительно быстрее тех, кто относится к этому как к проблеме более позднего этапа. Правильная таксономия действий, четкие рабочие процессы утверждения, наличие надежного механизма отката до того, как что-то пойдет не так — именно эта база позволяет автономности расширяться, не теряя доверия организации. Доверие, подорванное одним автономным действием, которое пошло не так в масштабах системы, восстанавливается очень долго. Мы видели, как программы застопоривались на месяцы после единичного инцидента, который при наличии лучших защитных механизмов был бы предотвращен до своего распространения.
Принцип третий: Интеграция рабочих процессов
Один из наших прошлогодних клиентов сделал почти все правильно. Чистый конвейер телеметрии, структура управления, которую действительно одобрил директор по информационной безопасности (CISO), модель, которая хорошо показала себя во всех сценариях инцидентов. Спустя три месяца после запуска в производство программа уперлась в потолок, которого никто не ожидал: агент мог компетентно диагностировать и устранять неполадки в своем собственном операционном домене, но значительная часть инцидентов требовала действий на стыке команд. Запуск отката развертывания означал вмешательство в CI/CD-конвейер, принадлежащий другой инженерной команде со своими собственными шлюзами утверждения. Масштабирование инфраструктуры означало прохождение через рабочий процесс управления емкостью, который был разработан с учетом квартальных циклов планирования, а не автономных решений в реальном времени. Агент продолжал приходить к правильному ответу, а затем останавливался у границы, для пересечения которой у него не было пути.
Это проблема интеграции рабочих процессов в конкретном выражении. Способный агентный ИИ, который не может действовать в рамках существующих рабочих процессов, на практике является дорогой рекомендательной системой. Никакой из других принципов не имеет значения в тот момент, когда принятие решений агентом неизменно упирается в организационную границу — эти точки трения накапливаются быстрее, чем ожидает большинство команд, и программа тихо теряет свой мандат.
Разрыв между демоверсией и продакшеном здесь наиболее велик, потому что демоверсии создаются в контролируемых средах с чистыми API и упрощенными потоками процессов. В производственных средах рабочие процессы разработаны для людей, ориентирующихся в организационных реалиях: шлюзы утверждения, границы команд, графики планирования, которые не имеют ничего общего со скоростью работы автономной системы. Интеграция в эту реальность требует работы с подключениями API, реального редизайна процессов и откровенного внутреннего разговора о том, нужно ли существующим рабочим процессам развиваться, чтобы приспособиться к новому типу операционного участника.
Большинство компаний еще не провели этот разговор. Те, кто начинает его раньше, чем это станет необходимым, находятся в значительно более выгодном положении.
Принцип четвертый: Выбор модели
Рекомендаций по этому поводу предостаточно. Бенчмарки, таблицы лидеров и аналитические обзоры рассматривают возможности моделей как главную переменную успеха в сфере ИИ. Это имеет значение. Просто оно значительно меньше, чем предполагает большинство предприятий, и усилия практически наверняка стоит направить в другую сторону.
В ИТ-операциях задачи, выполняемые агентными системами, достаточно четко определены, чтобы несколько способных моделей справлялись с ними должным образом. Разница редко заключается в том, способна ли модель хорошо рассуждать изолированно на бенчмарке. Она заключается в том, получает ли модель качественную телеметрию, работает ли в рамках соответствующих защитных барьеров и способна ли действовать через интегрированные рабочие процессы. Хорошо управляемая, отлично интегрированная агентная система, построенная на базе способной, но ничем не примечательной модели, стабильно превосходит ультрасовременную модель, которая опирается на фрагментированную основу данных, не имеет защитных барьеров и отличается слабой связностью рабочих процессов. Мы видели это на практике, и результаты несопоставимы.
Выбор модели — это еще и самое обратимое решение в стеке. Замена модели относительно проста, когда окружающая инфраструктура надежна. Перестройка основы данных или редизайн архитектуры управления — нет. Предприятия, которые начинают с выбора модели, как правило, возвращаются к более сложным вопросам позже — обычно после того, как что-то идет не так и разбор полетов оказывается неприятным.
Ракурс готовности, который меняет все
Самый сложный разговор с клиентами обычно происходит на самом раннем этапе — когда им говорят, что модель, которую они оценивали три месяца, — это, по сути, наименьшая из их проблем. Что уровень наблюдаемости, к которому они относились как к удобству отчетности, на самом деле является несущей инфраструктурой. Что их процесс управления изменениями в его нынешнем виде незаметно задушит любую автономию, которую им удастся развернуть.
Автономные ИТ-операции — это не ИИ-проект с сопутствующими инфраструктурными соображениями. Это операционная трансформация, и возможности ИИ хороши лишь настолько, насколько хороша основа под ним — базы данных, архитектура управления, интеграция рабочих процессов. Большинство предприятий еще не до конца создали эти элементы. Некоторые знают об этом и работают над этим. Другие узнают об этом на собственном горьком опыте — как правило, где-то между пилотным проектом и первым серьезным инцидентом в рабочей среде.
Организации, которые делают все правильно, не обязательно обладают самыми большими бюджетами на ИИ или самыми передовыми моделями. Это те, кто на раннем этапе честно признал наличие пробелов и направил свои усилия именно туда.
