AI-агенты вышли в прод: зачем компании собирают governance-комитет

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

Чем агент отличается от чат-бота — и почему это меняет управление

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

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

Код спрашивают, что он делает. Агента приходится спрашивать, что он вправе сделать и кто это заметит, если он ошибётся.

Зачем нужен отдельный комитет, а не просто регламент

Регламент — это документ. Комитет — это процесс с людьми, которые принимают конкретные решения по конкретным агентам. Три причины, по которым одним документом не обойтись:

• Решения межфункциональные. Можно ли агенту тратить бюджет — вопрос не к разработчику. От чьего имени он пишет клиентам — не к безопасности. Кто отвечает за его ошибку перед клиентом — вопрос юридический. Ни один отдел не закрывает это в одиночку.
• Риск растёт быстрее правил. Между «пилот на одном отделе» и «агент в биллинге» — недели. Комитет даёт точку, где новый уровень доступа проходит осознанную проверку, а не проскакивает как обычный релиз.
• Нужна отзывчивость. Если агент повёл себя не так, кто-то должен уметь его быстро отключить и разобрать инцидент. Без назначенных ответственных «отключить» превращается в переписку на три дня.

Что комитет решает на практике

1. Допуск агента в продакшн: с какими правами, к каким системам, на какой бюджет действий.
2. Границы автономии: где агент действует сам, а где обязателен человек в контуре — подтверждение перед необратимым действием.
3. Логирование и аудит: что записывается по каждому действию и кто может это поднять.
4. Порядок отключения (kill switch): кто и по какому сигналу останавливает агента.
5. Разбор инцидентов и пересмотр прав по итогам.

Кто входит в комитет

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

В маленькой компании эти роли совмещают два-три человека, и это нормально. Плохо — когда какой-то из вопросов не задаёт вообще никто: обычно первым выпадает юридический («от чьего имени?») и приватность («какие данные он видит?»).

Кому это пригодится и кому нет

Комитет — это накладные расходы: собрания, документы, задержка релизов. Он оправдан не всегда.

Пригодится, если:

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

Скорее избыточно, если:

• Агент читает данные и предлагает варианты, но ничего не делает без нажатия кнопки человеком.
• Это внутренний ассистент в песочнице без доступа к боевым системам.
• Команда из пяти человек с одним агентом — тут хватит явно назначенного ответственного и лога действий, а комитет из тех же пяти человек будет ритуалом.

С чего начать без бюрократии

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

1. Составьте реестр агентов: что делает каждый, к чему имеет доступ, кто владелец.
2. Разметьте их по риску — «только читает», «действует с подтверждением человека», «действует сам и необратимо».
3. Через комитет пропускайте третий уровень и всё, что затрагивает деньги и персональные данные. Первые два — по упрощённой процедуре.
4. Договоритесь заранее, кто и как жмёт на стоп, и проверьте, что кнопка вообще работает.

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

¹ AI-агент — программа на базе языковой модели, которая получает цель и самостоятельно выбирает последовательность действий для её достижения: вызывает внешние инструменты и API, обращается к данным, при необходимости запускает другие агенты. В отличие от чат-бота, агент не только отвечает текстом, но и совершает действия с последствиями во внешних системах.