SRE Agent: доверять нельзя контролировать

Где поставим запятую? :)

или

Как не дать автономному агенту положить прод и при этом не отстать от жизни

Последние полгода мои коллеги (и не только коллеги) разделились на два лагеря. Одни с ужасом рассказывают, как их AI-SRE-агент случайно положил базу данных, потому что «просто хотел помочь с таймаутами». Другие восторженно показывают дашборды, где инциденты расследуются быстрее, чем выпивается кофе.

Верю и тем и другим :) AI в SRE как ядерный реактор: может быстро дать дешевую энергию, а может моментально испарить весь город. Всё зависит от того, где вы поставите запятую в заголовке.

Почему я вообще об этом заговорил

Давай честно: SRE это сложно и дорого. Хорошие инженеры стоят бешеных денег, а прод падает по ночам, в выходные и всегда не вовремя. Бизнес логично хочет автоматизировать всё, что можно и зарабатывать больше денег. И в этом желании нет ничего необычного.

И тут приходят продавцы с красивыми презентациями: «Наш AI-SRE-агент сам найдет проблему, сам починит, сам напишет постмортем! Вы будете спать спокойно! И это недорого!» :)

Или еще вариант «напишите сами, в свободное время и пусть он за вас работает».

Звучит как сказка. Но есть нюанс.

В 2025 году Gartner предупредил: к 2027 году 40% проектов с AI-агентами провалятся, а 74% организаций столкнутся с новыми рисками безопасности и серьезными инцидентами, вызванными самими агентами. Лишь 13% уверены, что у них есть адекватные структуры управления для таких технологий.

Почему? Потому что AI пока не видит картину целиком. Он решает исключительно локальную задачу и не понимает глобальных последствий.

Как один таймаут убил базу данных

Реальный сценарий (имена изменены, боли настоящие).

Ситуация:

• Есть сервис А (онлайн-магазин) и сервис Б (база данных пользователей).
• Сервис А начал ловить таймауты при обращении к сервису Б.

Что делает AI-агент (в режиме «автопочинки»):

1. Агент видит: «О, таймауты! Надо увеличить таймауты в конфиге сервиса А».
2. Агент лезет в конфиг, увеличивает таймаут с 5 до 30 секунд.
3. Деплоит изменение.

Что происходит на самом деле:

• Сервис Б на самом деле просто перегружен (там внезапный пик трафика).
• Теперь сервис А не падает с ошибкой, а висит 30 секунд на каждый запрос.
• Количество открытых соединений растет, сервис А исчерпывает пул соединений.
• Начинают падать все, кто ходит в сервис А.
• Через 15 минут БД ложится от перегрузки, потому что сервис А держит соединения в 6 раз дольше обычного.

Агент не увидел всей картины и не понял контекста, что проблема была не в таймаутах, а в перегрузке БД. Он просто «помогал».

Как отличить настоящего AI-агента от маркетинговой шумихи

Когда продавец продает вам «AI-SRE-агента», задайте четыре простых вопроса:

Вопрос 1: Ваш агент пишет текст или выполняет действия?

Отстой: «Он анализирует логи и пишет отчеты в Telegram/Slack/почту/итд!» Норм: «Он умеет выполнять команды в продакшене, но мы настраиваем права доступа для каждого типа действий».

Настоящий AI SRE это не чат-бот, который болтает. Это агент, который может прочитать и понять правила, принятые в компании, прочитать и понять ее архитектуру, зайти куда-то, выполнить команду, изменить конфиг, перезапустить сервис. Если он только пишет — это просто дорогой уведомитель.

Вопрос 2: Как агент понимает границы своей ответственности?

Отстой: «Он сам решает, что делать, на основе обучения на всех наших инцидентах и постмортемах к ним, которые он парсит из Jira!» Норм: «У него есть четкие правила: что можно трогать, в какое время, с какими подтверждениями. Правила описаны, периодически пересматриваются».

Хороший агент работает в песочнице. Он не имеет доступа к проду, пока не докажет, что не тупит на тестовых данных (которые чаще всего еще и кривые).

Вопрос 3: Что произойдет, если когда агент ошибется?

Отстой: «У нас есть мониторинг, мы увидим!» Норм: «У нас есть автоматические откаты, kill switch и обязательное подтверждение человеком для всех опасных операций».

Если продавец не может внятно объяснить, как останавливать агента, когда он «сходит с ума» — надо бежать! :) Свежайший пример от 23 февраля 2026 года.

Вопрос 4: Видит ли агент контекст или только метрики?

Отстой: «Мы подключили его к Prometheus, он видит всё!» Зеленый флаг: «Мы даем агенту не только метрики, но и информацию о зависимостях сервисов, архитектуре и бизнес-критичности.».

Помни случай с таймаутами? Агенту не хватило контекста, что сервис А зависит от Б, а Б сейчас перегружен.

Как не убить прод

Внедрять AI SRE можно безопасно. Но тут есть засада: делать это нужно постепенно и с использованием мозга.

Read-only режим

На этом этапе агент только смотрит. Он может:

• проанализировать логи и метрики
• написать свои предположения о причинах инцидентов
• предложить варианты решения в комментариях к тикетам
• и прочее подобное

Но не может:

• выполнять любые команды на серверах
• изменять конфиги
• деплоить что-либо куда-либо

Это как стажер, который сидит рядом, его тоже можно послушать, но решение принимать все равно вам.

Режим с подтверждением

Агент может выполнять действия, но только с явного одобрения человека.

Как это выглядит в коде (упрощенная схема):

# Псевдокод агента с подтверждением
def handle_incident(alert):
    analysis = analyze_alert(alert)
    proposed_fix = generate_fix(analysis)

    # Не выполняем, а отправляем в какой-то канал на утверждение
    send_to_channel(
        channel="sre-review",
        message=f"Обнаружена проблема: {analysis.cause}\n"
                f"Предлагаю исправить: {proposed_fix.command}\n"
                f"Подтвердите выполнение: /approve {proposed_fix.id}"
    )

    # Ждем 5 минут, если нет подтверждения от человека - отбой
    wait_for_approval(timeout=300)
    if approved:
        execute_fix(proposed_fix)
    else:
        log_rejection(proposed_fix)

Но даже с подтверждением агент должен работать по принципу наименьших привилегий. Если проблема в сервисе А, он не должен иметь доступа к сервису Б.

Автономный режим с защитой

Агент может действовать сам, но в жестких заранее обдуманных и описанных рамках:

# Манифест правил агента (упрощенно)
agent_rules:
  # Что можно трогать
  allowed_services:
    - "service-A"
    - "service-B"

  # Что нельзя трогать НИКОГДА
  forbidden_services:
    - "user-database"
    - "core-billing"
    - "payments-gateway"

  # Временные окна
  allowed_hours:
    - "10:00-19:00"  # Только в рабочее время

  # Максимальный урон
  max_instances_affected: 2  # Не больше двух инстансов за раз
  canary_percent: 5  # Если меняет конфиг - только на 5% трафика сначала

  # Kill switch
  auto_stop_on_error_count: 3  # Если три ошибки подряд - остановиться и звать людей

Агент должен работать как canary deployment. Сначала на одном неважном сервисе, потом постепенно расширяя полномочия.

Симбиоз человека и AI

Идеальный мир, в котором мы хотим жить (и скоро будем, думаю):

• AI ловит 90% типовых проблем и чинит их сам
• AI готовит контекст для сложных инцидентов (собирает логи, строит граф зависимостей, что-то советует)
• человек занимается не поиском причины, а принятием сложных решений и улучшением архитектуры.

Кто заплатит, когда агент накосячит?

Это самый больной вопрос, который почему-то откладывают «на потом». Потому что прецеденты уже появляются по всему миру, и ответы судов могут вас удивить.

Случай из Китая: ИИ пообещал пользователю $14000 и посоветовал подать в суд

В январе 2026 года Интернет-суд города Ханчжоу вынес первое в Китае решение по иску, связанному с «галлюцинациями» ИИ.

Что произошло: Пользователь по фамилии Лян уточнял у чат-бота информацию об университете для поступления родственника. Бот ошибся с местоположением кампуса. Когда Лян указал на ошибку, система начала настаивать на своей правоте и даже заявила: «Если сгенерированный контент неверный, я компенсирую вам 100 тысяч юаней» (примерно $14000), посоветовав обратиться с иском в Интернет-суд Ханчжоу .

Лян так и сделал. Он подал иск к разработчику платформы, требуя компенсации и ссылаясь на обещание, данное чат-ботом.

Что решил суд: Суд в иске отказал, указав на три момента:

1. ИИ не обладает гражданской правосубъектностью и не может формировать юридически значимые волеизъявления .
2. Ответы машины не могут расцениваться как обязательное предложение со стороны провайдера сервиса .
3. Разработчик выполнил свои обязанности, внедрив пользовательские соглашения и предупреждения о возможных неточностях .

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

Случай из Индии: штраф за халатность

А вот пример, когда отвечать всё-таки пришлось. Верховный суд Бомбея в январе 2026 года оштрафовал ответчика на 50 тысяч рупий (около 43 500 рублей) за подачу ходатайства, сгенерированного ИИ.

Что произошло: Менеджер компании Heart and Soul Entertainment Мохаммед Ясин подал ходатайство, подготовленное с помощью ИИ. Документ содержал ссылку на несуществующее судебное решение, классическую «галлюцинацию». Проверка архивов показала, что такого дела никогда не было .

Суд сказал, что: использование нейросетей допустимо, но полная ответственность за достоверность информации лежит на человеке, подающем документы . Штраф был наложен именно за то, что ответчик не проверил факты перед подачей.

Если ваш агент накосячит в проде, отмазка «это агент сам придумал» не сработает. Отвечать будете вы или ваша компания.

Случай из России: робот ЖКХ освоил ненормативную лексику

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

Нейросеть, обучаясь на реальных диалогах, переняла лексику абонентов. Пришлось срочно вмешаться и проводить дополнительное обучение алгоритмов.

Прямых исков пока не было, но вопрос открыт: кто отвечает за моральный ущерб, если робот нахамил клиенту? Компания, внедрившая систему или разработчик?

Еще в Москве уже был прецедент с автономным доставщиком: инспектор ГАИ выписал компании «Рободоставка» штраф 300 тыс. рублей за то, что робот создавал помехи пешеходам на тротуаре. Штраф потом отменили, но суть не в этом.

А что с законом в России?

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

Кто отвечает по закону прямо сейчас (не про Россию)?

Юристы из Baker Donelson в своем прогнозе на 2026 год выделяют главный тренд: The Rise of Agentic AI Liability (рост ответственности за действия агентного ИИ) .

1. Если AI-агент заключил невыгодный контракт или выполнил опасную команду, то обязан ли пользователь исполнять обязательства? Суды пока не дали окончательного ответа .

2. В Техасе с 1 января 2026 года действует закон TRAIGA, запрещающий определенные виды вредоносного использования ИИ.

3. В Юте компании обязаны четко указывать, когда потребитель взаимодействует с ИИ, и несут ответственность за обман или незаконные действия, совершенные через AI-инструменты, как за свои собственные .

4. Профессиональная ответственность: Адвокатские коллегии уже начали дисциплинарные разбирательства против юристов, использовавших публичные AI-инструменты для клиентской работы без проверки результатов человеком .

Что делать SRE, чтобы не попасть на деньги

Исходя из всех этих случаев и законов, практически можно рекомендовать такое:

1. Фиксируйте ответственность в договорах с вендорами

Внимательно смотрите договоры с поставщиками AI-решений и требуйте, чтобы пункты о возмещении убытков явно покрывали автономные действия агентов и «галлюцинации», приводящие к финансовым потерям. Фантастично, но все же :)

2. Внедряйте пользовательские соглашения и предупреждения

Как показал китайский случай, наличие явного предупреждения о возможных неточностях ИИ может защитить компанию от исков . Даже простой дисклеймер «AI-агент может ошибаться, проверяйте критически важные действия» уже создает правовую защиту.

3. Контроль человеком

Во всех разбирательствах суды обращают внимание на одно: кто принимал финальное решение? Если за агентом стоял человек, который утвердил действие (инженер, жамкнувший «подтверждаю»), то ответственность на человеке. Если агент действовал полностью автономно и без контроля, то зона ответственности размыта, но скорее всего, спрашивать будут с компании, которая его запустила.

4. Аудит всех действий агента

В случае любого разбирательства первый и главный защитник — лог действий агента. Если вы можете показать, что агент сделал, почему он это сделал (какой контекст получил), и кто (или какой алгоритм) это действие одобрил, то у вас есть аргументы в суде (а может я и ошибаюсь :))

Как еще агенты ошибаются (и как это дорого стоит)

ServiceNow: критическая уязвимость в Virtual Agent

В октябре 2025 года исследователи безопасности из AppOmni обнаружили критическую цепочку уязвимостей в ServiceNow Virtual Agent, которую назвали «самой серьезной AI-уязвимостью из когда-либо обнаруженных» .

Три фактора сложились в идеальный шторм:

• сломанная аутентификация: ServiceNet использовал один и тот же жестко зашитый токен (servicenowexternalagent) для всех экземпляров продукта у всех клиентов .
• сломанная верификация личности: API принимал email-адрес как достаточное доказательство личности. Ни пароля, ни MFA, ни SSO .
• чрезмерные привилегии агента: Agent Record Management AI Agent мог создавать новые данные где угодно в ServiceNow, включая учетные записи с правами администратора .

ServiceNow использует 85% компаний из списка Fortune 500. Через него проходят HR, клиентский сервис, безопасность и множество других систем. Атакующий с доступом к админке ServiceNow получает площадку для атаки на Salesforce, Microsoft 365 и другие связанные системы .

Проблема была не в AI-модели, а в классических ошибках безопасности: хардкоженные креды, слабая аутентификация, избыточные права . Как заметили эксперты Snyk: «Традиционные баги, которые раньше вели к ограниченному доступу к данным, стали полной компроментацией платформы, потому что агент мог автономно выполнять цепочки действий, создавать учетки, назначать привилегии и закрепляться в системе» .

Mercor: как провалились AI-консультанты

Исследование компании Mercor (февраль 2026) показало, что ведущие AI-агенты пока не готовы заменять реальных консультантов .

AI-агентам давали реальные задачи из консалтинга, банковского дела и юриспруденции, разработанные при участии экспертов из McKinsey, BCG, Deloitte, Accenture и EY .

• с первой попытки агенты успешно выполняли менее 25% задач .
• дав им 8 попыток, удалось поднять успешность до 40% .
• лучший результат показала новая модель Anthropic Opus 4.6: почти 33% задач с первой попытки .

Где ошибались агенты:

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

Бывший консультант KPMG, обучавший AI, заметил важную деталь: модели не понимают контекстных фраз вроде «client-ready» (готово для клиента). То, что очевидно любому консультанту, для AI загадка .

Аляска: судебный AI-ассистент, который слишком сочувствовал

Судебная система Аляски разрабатывала AI-чатбота AVA (Alaska Virtual Assistant) для помощи жителям в оформлении наследства. Проект должен был занять три месяца, но растянулся на год и три месяца .

• на вопрос, где получить юридическую помощь, AVA советовал обратиться к выпускникам юридической школы, которой в Аляске просто не существовало .
• ранняя версия AVA была слишком «сочувствующей» и раздражала людей, которые в стрессовой ситуации хотели просто получить ответ, а не соболезнования .
• модели (типа GPT) постоянно обновляются, и команда вынуждена постоянно следить за поведением AVA, «запустил и забыл» не работает .

Директор судебной системы Аляски признала: команда скорректировала цели проекта и теперь понимает, что робот пока не может полностью заменить человека-консультанта .

Российский финтех: что не сработало у банков

Ассоциация ФинТех проводит масштабный пилотный проект с ИИ-агентами в российских банках и страховых компаниях. Участвуют 20 организаций, но половина уже переквалифицировалась в «наблюдатели» и активно внедрять ИИ пока не готовы .

Советник по ИИ Ассоциации ФинТех Алексей Сидорюк честно рассказывает о провалах:

• Применение GPT-моделей в анализе рыночных сигналов и для трейдерства провалилось: «Было очень много ложных срабатываний. Модель реагирует на очень многие вещи, на что трейдеры опытные закрывают глаза» .

Основные стоп-факторы для внедрения AI-агентов в российском финтехе:

1. Технологические ограничения:

   • Механизм RAG (поиск информации во внешних источниках) Сидорюк называет «архитектурным костылем», который нужен, чтобы решить проблему маленького контекста .
   • LangChain (фреймворк для связывания моделей с внешними данными) обладает высоким временем отклика и плохо масштабируется .

2. Кибербезопасность:

   • Классическая модель ролевой аутентификации (RBAC) перестает работать с агентами .
   • Будущее за ABAC-системами (управление доступом на основе атрибутов), где права выдаются под конкретный контекст задачи .
   • Как только агентов становится много, «ИИ должен управлять другим ИИ внутри организации» .

3. Кадровый голод и инфраструктура:

   • Облачные сервисы для критической инфраструктуры под запретом .
   • Не хватает компетенций для работы с новым классом систем .

Общий вывод из кейсов

Если собрать все эти истории вместе, вырисовывается четкая картина:

Тип проблемы	Пример	Урок
Галлюцинации и фактические ошибки	Кейс AVA (Аляска), китайский чат-бот с обещанием $14K	Нужны жесткие ограничения на источники данных и человеческая проверка критических решений
Безопасность и права доступа	ServiceNow Virtual Agent	Агенты должны работать по принципу наименьших привилегий, хардкоженные креды зло
Юридическая ответственность	Штраф в Индии, российский робот-матершинник	Отвечает человек/компания, а не агент. Нужны пользовательские соглашения и логи
Сложность многошаговых задач	Исследование Mercor	Не верьте агентам, если задача требует больше 5-7 шагов, проверяйте промежуточные результаты
Инфраструктурные ограничения	Российский финтех	Традиционные модели безопасности и аутентификации не работают с агентами, надо строитье новые

Что должно быть в коде прямо сейчас (с учетом юридических рисков)

Если вы пишете своего агента или настраиваете готовый, минимально должно быть:

1. Журнал всех действий (аудит)

# Обертка для всех действий агента
class AuditableAgent:
    def execute(self, command, context):
        log_entry = {
            "timestamp": datetime.now(),
            "agent_id": self.id,
            "trigger": context.alert_id,
            "command": command,
            "reason": context.analysis,
            "status": "pending",
            "approver": context.approver,
            "before_state": capture_state(context.service),
        }

        try:
            result = self._execute_real(command)
            log_entry["status"] = "success"
            log_entry["after_state"] = capture_state(context.service)
        except Exception as e:
            log_entry["status"] = "failed"
            log_entry["error"] = str(e)
            raise
        finally:
            save_to_audit_log(log_entry)

2. Kill switch (аварийный выключатель)

# Глобальный стоп-кран
class AgentController:
    def __init__(self):
        self.global_stop = False
        self.service_stops = {}

    def emergency_stop(self, agent_id=None, service=None):
        """Может вызвать любой SRE через команду"""
        if agent_id:
            self.stop_agent(agent_id)
        elif service:
            self.service_stops[service] = True
        else:
            self.global_stop = True

    def can_execute(self, agent, service):
        if self.global_stop:
            return False
        if self.service_stops.get(service, False):
            return False
        return True

3. Проверка перед опасными операциями

def safe_restart(service_name, instances):
    # Никогда не перезапускаем всё сразу
    for instance in instances[:1]:  # Сначала один
        restart_instance(instance)
        wait_and_check(service_name)
        if not is_healthy(service_name):
            rollback(service_name)
            alert_humans("Что-то пошло не так, останавливаюсь")
            return

    # Если первый прошел - можно еще пару
    for instance in instances[1:3]:
        restart_instance(instance)
        # ... и так далее

4. Аудит, который пригодится, если дело дойдет до суда или разбирательства с регулятором

# Юридически значимый лог действий агента
class LegalAuditLogger:
    def __init__(self):
        self.audit_store = immutable_storage()  # Неизменяемое хранилище для суда

    def log_action(self, agent_id, action, context, approval_chain):
        """
        Логируем действие так, чтобы потом можно было показать в суде
        """
        audit_record = {
            "timestamp": datetime.now(timezone.utc).isoformat(),
            "agent_id": agent_id,
            "agent_version": get_agent_version(agent_id),
            "action": {
                "type": action.type,
                "command": action.command,
                "target": action.target,
                "parameters": action.parameters
            },
            "context": {
                "alert_id": context.alert_id,
                "service": context.service,
                "incident_summary": context.summary,
                "evidence": context.logs_snapshots
            },
            "approval_chain": [
                {
                    "approver_type": step.type,  # "human" или "rule"
                    "approver_id": step.id,
                    "timestamp": step.timestamp,
                    "method": step.method  # "slack_approval", "auto_rule", и т.д.
                }
                for step in approval_chain
            ],
            "result": {
                "status": action.result.status,
                "output": action.result.output,
                "error": action.result.error,
                "before_state": capture_state_hash(action.target),
                "after_state": capture_state_hash(action.target)
            }
        }

        # Добавляем электронную подпись для неотказуемости
        audit_record["signature"] = sign_record(audit_record, private_key)

        # Сохраняем в неизменяемое хранилище
        self.audit_store.append(audit_record)

        return audit_record["id"]

Что дальше?

AI SRE это вообще не про замену инженеров, это просто еще один инструмент, как CI/CD не заменил разработчиков, а избавил их от рутины. Хороший SRE будущего тот, кто умеет:

• правильно ставить правильные задачи агентам
• понимает безопасные границы для автоматизации
• быстро разбираться в сложных инцидентах, где AI только подсветил проблему
• тщательно писать правила и политики, по которым живут агенты

Где ставить запятую в заголовке — ваш выбор :) «Доверять, нельзя контролировать» — и вы просыпаетесь от того, что прод лежит, а агент «чинит» его уже час. «Доверять нельзя, контролировать» — и вы получаете помощника, который не прострелит вам коленку.

Я за второй вариант :)