Ответственность за инцидент с ИИ остается у человека

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

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

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

Ответственность не следует за авторством

Ответственный владелец, это человек с правом принимать решения по инциденту, а не тот, кто создал проблемные строки. В разработке ПО авторство всегда отделяли от операционной ответственности. Автор библиотеки не руководит каждым сбоем с участием этой библиотеки, а младший инженер, написавший неудачную миграцию, не должен автоматически управлять восстановлением всей компании.

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

Четыре обозначения помогают прекратить обычный спор:

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

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

Не используйте матрицу RACI как систему командования в момент инцидента. RACI помогает распределить обязанности заранее, но пять человек с пометкой «ответственный» означают, что никто не может разрешить спор об откате. Во время инцидента укажите одно имя. После него расширенная карта ответственности объяснит, кому нужно исправить правила ревью, тесты, доступ или обучение.

Руководитель управляет реагированием, а не терминалом

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

Руководство Google Site Reliability Engineering разделяет роли Incident Commander, Operations Lead и Communications Lead. В нем также сказано, что руководитель отвечает за каждую роль, которую еще не передал другому. Последний пункт особенно важен для стартапа из пяти человек: не нужны три сотрудника, которые ждут работы в отдельных ячейках, но нужно понимать, кто выполняет непереданную обязанность.

Руководителю следует записать пять фактов вверху канала или документа инцидента:

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

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

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

Разделите работу на четыре управляемых направления

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

Расследование

Руководитель расследования формирует и ранжирует гипотезы. Он сопоставляет diff изменения от агента с телеметрией, предыдущими развертываниями, флагами функций, изменениями зависимостей и сообщениями пользователей. Агент может искать в логах, связывать временные метки, суммировать diff или составлять запросы. Он должен возвращать доказательства и степень неопределенности, а не уверенное предложение о корневой причине.

Просите агента дать опровержимый результат: «Перечисли три измененных коммитом X пути кода, которые могут повлиять на задержку при оформлении заказа. Для каждого укажи поле лога или метрику, которые опровергнут его причастность». Такой запрос дает материал для проверки человеком. Фраза «найди корневую причину» побуждает модель слишком рано отбросить неоднозначность.

Снижение ущерба и откат

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

Выбирайте наименьшее действие, которое сокращает ущерб для клиентов: отключите новый путь, перенаправьте трафик, откатите развертывание, приостановите обработчик очереди или точечно исправьте данные. Корневая причина подождет. Большой рефакторинг, созданный во время сбоя, не снижает ущерб, даже если его объяснение звучит убедительно.

Коммуникация

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

Последующая работа

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

В небольшой команде расследование можно объединить с последующей работой, а коммуникацию поручить руководителю инцидента. По возможности отделяйте снижение ущерба от командования. Цель не в бюрократии. У каждого действия в продакшене должен быть один исполнитель, а у каждого публичного сообщения один редактор-человек.

Агенты выполняют задачи, но не получают полномочия

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

Для каждой задачи агента во время инцидента задавайте контур действий:

task_id: INC-482-investigate-03
requested_by: maya
approved_by: leon
mode: read_only
systems:
  - checkout-api
allowed_tools:
  - logs.query
  - git.diff
expires_at: 2026-07-27T15:30:00Z
output:
  channel: incident-482
  include:
    - commands_run
    - evidence
    - uncertainty
stop_conditions:
  - request_requires_production_write
  - query_scope_exceeds_checkout-api
  - credentials_or_personal_data_appear

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

Для записи измените mode, укажите точный ресурс, добавьте утвержденную команду или операцию API, ожидаемый эффект и тайм-аут. Потребуйте новое подтверждение. Не позволяйте подтверждению расследования незаметно разрешать предложенное им исправление.

Документация GitHub по развертыванию различает запуск и подтверждение развертывания. Защищенные окружения могут требовать ревьюеров и запрещать автору запуска подтверждать свое действие. То же разделение нужно применять, когда изменение создает агент: ни агент, ни человек, запустивший его сессию, не должен в одиночку утверждать продакшен для сервиса с высоким риском.

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

Подтверждение связывает человека с одним точным действием

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

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

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

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

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

Многие интерфейсы агентов предлагают человеку разрешить категорию инструментов, например оболочку или облачный доступ, а не итоговую операцию. Это делает работу удобнее, но не усиливает контроль. Такой подход допустим для разработки с низким риском в изолированном окружении. Для продакшена он плох, потому что get deployment status и delete deployment могут проходить через один инструмент.

В продакшене применяйте правила за пределами сессии модели. Прокси политик, система развертывания, брокер облачных ролей или специальный исполнитель должны проверять подписанный запрос, область ресурса, срок и текущее состояние инцидента. Агент может запросить разрешение, но не может выдать его себе или выбрать более мощные учетные данные.

Аварийный доступ требует той же дисциплины. Путь break-glass должен указывать открывшего его человека, оповещать другого владельца, автоматически истекать и создавать полный журнал действий. Общий аварийный токен в менеджере паролей не дает ответственности. Общие учетные данные стирают личность именно тогда, когда инциденту нужна ясная цепочка решений.

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

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

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

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

Доказательства должны пережить сессию агента

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

Playbook к NIST AI Risk Management Framework рекомендует хранить истории и журналы аудита, по которым люди могут проверить возможные источники ошибки или уязвимости. Он также предлагает документировать контроль со стороны человека, переопределения, исключения из политик, эскалации и решения go или no-go. Это практическая гигиена инцидента, а не отвлеченный принцип ИИ.

Собирайте под идентификатором инцидента такие записи:

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

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

Компактный формат события позволяет позднее восстановить ход работы:

{"incident":"INC-482","time":"2026-07-27T14:11:08Z","actor_type":"agent","actor_id":"deploy-assistant","session":"sess-91f","action":"logs.query","target":"checkout-api","mode":"read","request_hash":"sha256:...","result":"success","evidence_ref":"evt-7721","approved_by":null}
{"incident":"INC-482","time":"2026-07-27T14:18:42Z","actor_type":"human","actor_id":"leon","action":"approve","target":"checkout-api/prod","mode":"rollback","request_hash":"sha256:...","result":"granted","evidence_ref":"evt-7754","approved_by":"leon"}

Хеш связывает подтверждение с точным запросом, не помещая чувствительные данные в общий канал инцидента. Ссылка на доказательство ведет к результату команды с управляемым доступом. Если команда меняется после подтверждения, хеш тоже изменится, и исполнитель обязан отклонить ее.

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

Откат должен существовать до выдачи доступа на запись

Не давайте агенту путь записи в продакшен, пока команда не проверила ограниченное обратное действие или способ сдерживания. Команда Git revert не составляет план отката, если развертывание также запустило миграцию базы данных, выпустило необратимые события или изменило контракт внешнего API.

До развертывания определите класс изменения:

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

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

Для созданной агентом миграции базы ревьюеру нужны diff схемы, оценка блокировок и длительности по тесту в похожей на продакшен среде, совместимость с работающим приложением, подтверждение резервного копирования или восстановления и план сдерживания. Если миграция удаляет или переписывает данные, синтаксически правильная обратная миграция дает ложное чувство безопасности. Руководителю нужны честные сроки восстановления и граница потерь.

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

В начале инцидента заморозьте несвязанные операции записи от агентов. Автоматизация может продолжать собирать доказательства, но параллельные автономные изменения портят временную шкалу и расширяют область поиска. Руководитель может намеренно снова открыть путь, если он помогает выбранному снижению ущерба.

Коммуникация с клиентами остается под контролем человека

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

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

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

customer_impact: Some checkout requests return errors.
started_at: 2026-07-27T13:52:00Z
current_action: Rolling back the latest checkout-api deployment.
customer_action: Retry failed requests after the next update.
next_update_at: 2026-07-27T14:40:00Z
approved_by: leon

Агент может превратить блок в текст, не добавляя отсутствующие корневую причину, обещание восстановления, долю или масштаб. Ответственный сверяет черновик с исходными полями. Это быстрее, чем просить агента суммировать весь шумный канал инцидента, и снижает риск утечки догадок.

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

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

Разбирайте сбой, не делая модель козлом отпущения

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

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

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

У этого сбоя несколько владельцев, хотя командование не делится. Руководитель инцидента отвечал за решения по реагированию. Операционный руководитель отвечал за очистку кеша и выполнение отката. Владелец сервиса отвечает за отсутствующий инвариант изоляции. Технический руководитель отвечает за ревью и правила развертывания, пропустившие сгенерированное изменение конкурентной логики со слабыми тестами. Агент ни за что не отвечает, но его промпт, результат, права и вызовы инструментов остаются доказательствами.

На разборе спросите:

1. Какой инвариант нарушило изменение и где его следовало проверить?
2. Какое решение человека допустило риск и какие доказательства у него были?
3. Какие права или автоматизация превратили принятое изменение в ущерб продакшену?
4. Почему первое снижение ущерба не сработало и какой сигнал это показал?
5. Какой контроль теперь предотвратит или сдержит тот же класс сбоев?

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

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

Ответственность проектируют до следующего развертывания

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

Задайте простую политику для каждого продакшен-сервиса:

service: checkout-api
human_owner: payments-oncall
incident_commander_rota: company-incident-command
agent_change_risk:
  read_only: autonomous
  reversible_write: human_approval
  data_or_identity_change: two_person_approval
  unknown: denied
incident_mode:
  default_agent_access: read_only
  production_writes: operations_lead_only
  external_updates: communications_owner_only

Названия должны указывать на актуальных людей и графики. Проверяйте их вне рабочего времени. Если payments-oncall ведет к пустому графику или руководитель не может отозвать токен агента, политика существует только для вида.

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

В oleg.is Team & AI Audit помогает сопоставить такие пробелы во владении и доступе с затратами на разработку, а затем распределить изменения в практичной операционной модели. Аудит не заменяет командование инцидентом, он помогает основателям создать его до того, как автоматизация увеличит скорость и радиус ошибки.

Ответственного человека нельзя вычислять по истории Git после того, как клиенты уже пострадали. Поместите одно имя человека в начало инцидента, подчините каждое действие агента этим полномочиям и сохраните достаточно доказательств, чтобы оспорить первое объяснение. Более быстрая генерация кода требует быстрее и яснее определять, кто может сказать «стоп».