Два десятилетия junior-специалисты в SecOps, SRE и NetOps набивали руку на рутине: разбирали ложные срабатывания, ночами читали логи и искали контекст по дашбордам. Теперь агентный ИИ забирает именно эту работу, а вместе с ней и неформальную «школу» для будущих сильных инженеров. Для русскоязычных IT-команд это не абстрактная дискуссия про автоматизацию, а вполне прикладной вопрос: кто через три-пять лет будет объяснять аудитору, почему система приняла конкретное решение, и кто возьмет на себя инцидент, когда автоматика ошибется.
Об этом в партнерском материале Splunk сообщает VentureBeat. Тезис неприятный, но точный: компании ускоряют IT- и security-операции с помощью агентных систем, однако одновременно вымывают слой практики, на котором раньше росли опытные операторы. Автор колонки Камал Хати, старший вице-президент и генеральный менеджер Splunk, описывает проблему без романтики про «людей заменит ИИ». По его версии, дело не в замене, а в том, что рынок рискует получить более быстрые процессы сегодня и более тонкий кадровый резерв завтра.
Сама логика здесь понятна любому, кто видел работу SOC, NOC или SRE-команды изнутри. Та самая «грязная» операционка, которую бизнес годами хотел автоматизировать, действительно утомляет: бесконечный triage, дежурства, ложные алерты, ручная корреляция событий. Но именно она учила специалистов отличать случайный шум от паттерна атаки, понимать нормальное поведение инфраструктуры и замечать отклонения до того, как они превращаются в аварию. Это знание редко живет в курсах и почти никогда не помещается в runbook. Оно собирается из повторения, ошибок, эскалаций и тысяч мелких наблюдений. Агентный ИИ, если внедрять его агрессивно, вырезает из цепочки не только рутину, но и этот накопительный механизм обучения.
Отдельный риск возникает в регулируемых отраслях, и здесь статья попадает в нерв. Хати напоминает про SOX, PCI DSS, HIPAA и NIS2: все эти рамки опираются не только на наличие контроля, но и на цепочку человеческих суждений за ним. Аудиторы не спрашивают модель, почему она сочла событие безопасным, почему заблокировала доступ или по какой причине не эскалировала инцидент. Они спрашивают людей, которые должны восстановить ход решения, показать логику, обозначить ограничения и подтвердить, что контроль вообще был уместен. Пока автоматизация работает, проблема незаметна: дашборд зеленый, тикеты закрываются, SLA вроде бы соблюдается. Но организационная память в этот момент может уже истончаться. И когда понадобится объяснение, а не просто результат, выяснится, что объяснять особенно некому.
Это переводит разговор из плоскости «какой Copilot купить» в плоскость архитектуры и кадрового дизайна. Если раньше вопрос звучал так: какие процессы отдать автоматике, чтобы снизить toil и выгорание, то теперь он звучит жестче: как построить систему, в которой люди не деградируют до роли пассивных наблюдателей за агентами. В статье прямо сказано, что проблема workforce design и проблема architecture design теперь фактически совпали. Если человек должен управлять все более автономной системой, ему нужна не просто кнопка override, а среда, где он способен понять, когда этой кнопкой пользоваться. Для CTO, CISO и руководителей платформенных команд это плохая новость в том смысле, что «срезать расходы на первую линию и оставить одного-двух сеньоров» может оказаться красивой схемой только на квартальном слайде.
Splunk формулирует четыре свойства, без которых агентные системы будут ускорять работу, но не выращивать компетенцию. Первое: агент должен показывать ход рассуждений и происхождение данных, а не только финальный вывод. Если инженер видит, на чем основана рекомендация, у него развивается собственное суждение; если ему показывают лишь кнопку approve, он быстро теряет контекст. Второе: полномочия нужно делить по уровню уверенности и радиусу поражения. Повторяющиеся и низкорисковые сценарии можно закрывать автономно, а все, что несет заметный blast radius или связано с новизной, должно эскалироваться по умолчанию. Третье: несогласие человека с агентом должно становиться обучающим сигналом, а не просто записью в логе. Если опытный инженер отменил действие, важно сохранить не только факт отмены, но и причину: хрупкая зависимость, странность конкретной среды, неочевидное бизнес-ограничение. И четвертое: разбор инцидента должен переживать тикет и передаваться между доменами. Сетевая аномалия может оказаться проблемой ITOps, а security-инцидент может высветить бизнес-узкое место. Если это знание умирает в закрытой заявке, следующая команда опять начинает с нуля.
Для разработчиков и инфраструктурных инженеров из этого следует довольно приземленный вывод. Агентный ИИ стоит оценивать не только по метрикам скорости, числа закрытых тикетов или снижению нагрузки на первую линию. Не менее важный вопрос: становится ли команда после внедрения сильнее как система принятия решений. Видят ли инженеры reasoning, есть ли понятные границы автономии, фиксируются ли корректировки со стороны человека, превращаются ли разборы в повторно используемое знание. Если нет, компания покупает не устойчивость, а краткосрочную аренду экспертизы у небольшой группы старших специалистов, которые еще помнят, как все устроено под капотом. Как только эти люди уходят, отпуск берут не они, а вся организационная память.
Для бизнеса тезис не менее неприятный. Автоматизация действительно убирает дорогую и выматывающую рутину, и тормозить ее никто не предлагает. Но экономия на apprenticeship-слое может вернуться в виде более дорогих инцидентов, сложных аудитов и управленческой зависимости от узкого круга экспертов. Российским и русскоязычным компаниям этот сюжет особенно понятен: рынок и без того живет в условиях дефицита сильных security- и platform-инженеров, а значит, потеря канала выращивания специалистов бьет сильнее, чем в среде, где можно легко закрыть пробел наймом. В таком контексте разговор про explainability, эскалации и захват знаний перестает быть академическим. Это уже часть операционной устойчивости.
Главный вопрос на ближайшие годы звучит не так уж эффектно, зато честно: смогут ли компании сделать так, чтобы агентный ИИ ускорял операции и одновременно выращивал людей, а не выжигал почву под следующей волной экспертов. Победят, похоже, не те, кто автоматизирует больше всех, а те, кто сумеет оставить в контуре достаточно человеческого понимания, чтобы этой автоматизацией управлять.