«Агенты» без риска: контур контроля для AI в проде

«AI-агент сам отправил клиенту скидку 90%. Менеджер увидел это утром понедельника.» Это не страшилка из будущего – такое реально произошло в одной компании, которая очень уж поторопилась с «полной автономией». Агенты – штука мощная, спору нет. Но мощность без тормозов – это не скорость, это авария.

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

Почему «просто запустить агента» – плохая идея

Знаете, чем агент отличается от обычного чат-бота? Бот отвечает на вопросы. Агент – действует. Создаёт задачи, отправляет письма, меняет данные в CRM, согласовывает скидки. И каждое такое действие – это потенциальная точка, где всё может пойти не так.

Представьте три сценария, от которых у любого руководителя волосы встанут дыбом:

Сценарий первый: агент не понял. Клиент написал «отмените последний заказ». Агент решил, что «последний» – это значит «все последние». И отменил заказы за весь месяц. Технически он сделал то, что просили, верно?

Сценарий второй: агент получил слишком много власти. Кто-то дал ему полный доступ к API. А потом кто-то хитрый вставил в письмо prompt injection. И вот агент уже делает то, что хочет злоумышленник, а не то, что нужно вашей компании.

Сценарий третий: эффект домино. Агент случайно изменил одну цену. Это запустило пересчёт всех коммерческих предложений. Которые автоматически ушли клиентам. С совершенно неправильными суммами. Репутационный ущерб? Колоссальный.

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

Границы автономности: что агент может делать сам

Первый вопрос, который нужно решить перед запуском: что агент делает сам, а где притормаживает и спрашивает? Ответ простой – всё зависит от цены ошибки.

Я делю все действия агента на четыре уровня. Представьте это как светофор, только с дополнительным цветом:

Зелёный свет – безопасные действия. Агент читает данные, создаёт черновики, делает внутренние заметки. Если он тут ошибётся – ничего страшного, легко исправить, никто даже не заметит. Пусть работает самостоятельно.

Жёлтый свет – обратимые действия. Создание задачи, смена статуса сделки, назначение менеджера. Если что-то пойдёт не так – придётся потратить время на исправление, но мир не рухнет. Агент может работать автономно, но каждое действие записываем в журнал.

Оранжевый свет – заметные действия. Это всё, что видит клиент или партнёр: отправка письма, изменение коммерческого предложения, комментарий в чате. Здесь нужен «мягкий» контроль: агент предупреждает «собираюсь сделать вот это», и если за 5 минут никто не крикнул «стоп!» – делает.

Красный свет – критические действия. Скидка больше 10%, удаление данных, отмена заказа, всё что касается денег или юридических вопросов. Тут агент полностью останавливается и ждёт, пока живой человек скажет «да, действуй».

Как понять, к какому уровню отнести конкретное действие? Задайте себе три вопроса. Первый: можно ли это отменить? Если да – уровень понижается. Второй: увидит ли это клиент? Если да – уровень повышается. Третий: есть ли финансовый эффект? Если да – это автоматически красный свет.

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

Система approvals: когда нужен человек

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

Мягкое одобрение – для тех случаев, когда скорость важна. Работает так: агент отправляет вам сообщение «Собираюсь отправить клиенту вот это письмо. Если через 5 минут не скажешь «стоп» – отправлю». Вы занимаетесь своими делами, и только если видите что-то странное – реагируете. Удобно для рутинных, но заметных действий.

Технически это выглядит просто: агент создаёт запись в очереди с таймером, вам прилетает уведомление в Telegram или Slack, и если вы не отменили за отведённое время – действие выполняется автоматически.

Жёсткое одобрение – для всего серьёзного. Тут агент встаёт как вкопанный и ждёт, пока кто-то живой явно нажмёт «Да». Никаких таймаутов, никакой автоматики. Хотите дать скидку 15%? Ждём одобрения. Хотите удалить данные? Ждём одобрения. Менеджер ушёл на обед и не отвечает? Тогда запрос автоматически эскалируется на следующий уровень – руководителю отдела, например.

Но сам по себе запрос на одобрение бесполезен, если непонятно, что одобрять. Хороший запрос – это когда вы можете принять решение за 10 секунд, не открывая CRM и не вспоминая контекст. Поэтому в запрос должно входить всё необходимое: кто клиент, какая сделка, что именно хочет сделать агент, почему он это предлагает, и что будет, если отказать.

Покажу на примере, как это выглядит в жизни:

Видите? Вся картина перед глазами. Можно ткнуть «Одобрить» и вернуться к своим делам. Или нажать «Изменить» и скорректировать скидку до 10%. Никакого погружения в дебри CRM не требуется.

Журналирование: ваш чёрный ящик

Вы же знаете, зачем в самолётах чёрные ящики? Чтобы после инцидента можно было понять, что произошло. С AI-агентами ровно та же история. Если агент что-то сделал – это должно быть записано. Без журнала вы будете как следователь без улик: что-то пошло не так, а понять что – невозможно.

Что именно записывать? Давайте по порядку.

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

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

Само действие – какой API вызван, с какими параметрами. Конкретика: не «отправил письмо», а «вызвал /api/email/send с таким-то телом».

Результат – что вернула система, были ли ошибки, какие побочные эффекты случились. Успешно или нет – и если нет, то почему.

Человеческие решения – кто одобрил или отклонил запрос, когда, с каким комментарием. Это важно для аудита: мало ли, потом придётся объяснять, кто разрешил дать скидку 30%.

Как долго всё это хранить? Тут простое правило: чем серьёзнее действие, тем дольше храним. Всё, что связано с деньгами или удалением данных – 3-5 лет (это требования регуляторов). Обычные действия – полгода-год, этого хватит для анализа. Рассуждения агента можно хранить 1-3 месяца – они нужны в основном для отладки и занимают много места.

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

Права доступа: дайте агенту ровно столько, сколько нужно

Представьте, что вы наняли нового сотрудника. Дадите ему сразу ключи от всех кабинетов, пароль от банковского счёта компании и доступ ко всем клиентским данным? Конечно нет. Сначала он получит доступ только к тому, что нужно для его работы. С агентом – ровно та же логика.

Это называется «принцип минимальных привилегий», и для AI-агентов он критически важен. Почему? Потому что если агент взбесится (или его взломают через prompt injection) – ущерб будет ограничен тем, к чему у него есть доступ.

Ограничивайте на трёх уровнях.

Первый уровень – данные. Агент видит только сделки своего направления, а не всю CRM. Он не видит паспортные данные и банковские реквизиты – они ему не нужны. Он работает только с активными клиентами и не лезет в архив. Зачем ему знать про клиента, который ушёл три года назад?

Второй уровень – действия. Агент может создавать задачи, но удалять – нет. Может предложить скидку до 10%, но если клиент просит больше – агент идёт за одобрением. Может отправлять сообщения, но менять контактные данные клиента – это уже за гранью его полномочий.

Третий уровень – объём. Это защита от ситуации, когда агент «сходит с ума» и начинает делать что-то в промышленных масштабах. Не более 100 действий в час. Не более 10 000 тенге скидок в день без эскалации. Не более 50 писем за сессию. Если лимит превышен – агент останавливается и зовёт человека.

Как это реализовать технически? Есть несколько проверенных подходов. Поставьте API Gateway с rate limiting между агентом и вашими системами – он будет контролировать все лимиты. Создайте для агента отдельный сервисный аккаунт с ограниченными правами – пусть работает под ним, а не под админом. И настройте фильтрацию на уровне запросов, чтобы ORM автоматически добавлял условия вроде «WHERE department = 'sales'».

Есть простое правило: если вы не можете за 10 секунд объяснить, зачем агенту доступ к чему-то – не давайте этот доступ. Потом, если понадобится, добавите. А вот отнять доступ после инцидента будет куда болезненнее.

Кнопка паники: когда нужно остановить всё

Окей, у вас настроены границы, одобрения, логи, права. Но что если всё равно что-то пошло не так? Что если агент начал творить что-то странное, и нужно его остановить прямо сейчас?

Для этого нужен circuit breaker – механизм аварийного отключения. Как рубильник на электрощитке: дёрнул – и всё остановилось.

Первый способ – автоматический. Система сама замечает, что что-то не так, и бьёт по тормозам. Какие сигналы должны её насторожить? Резкий рост активности – агент вдруг стал делать в три раза больше действий, чем обычно. Повторяющиеся ошибки – пять одинаковых сбоев за минуту. Безумные значения – скидка 99% или сумма в миллиарды тенге. Любой из этих признаков – и агент автоматически останавливается.

Второй способ – ручной. Менеджер видит что-то странное и жмёт «Стоп». Важно: это должно работать мгновенно, без всяких «введите пароль» и «подтвердите действие». Большая красная кнопка в интерфейсе CRM. Команда /stop_agent в Telegram-боте. Горячая линия на крайний случай. Время реакции – секунды, не минуты.

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

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

И последнее: тестируйте кнопку паники регулярно. Как пожарную сигнализацию. Раз в месяц имитируйте аномалию и проверяйте, что система реагирует правильно. Лучше обнаружить, что рубильник не работает, во время учебной тревоги, а не во время реального пожара.

Перед запуском: проверьте себя

Окей, вот вам финальный чек-лист. Пройдитесь по нему перед тем, как выпускать агента в production. Если хоть один пункт вызывает сомнения – лучше остановиться и доработать.

Про границы: У вас есть чёткое понимание, что агент делает сам, а где останавливается и спрашивает? Все действия распределены по уровням – от безопасных до критических? Руководство в курсе и согласовало список того, что агент никогда не делает без одобрения?

Про одобрения: Работает мягкое одобрение с таймаутом для рутинных вещей? Работает жёсткое одобрение с эскалацией для серьёзных решений? Уведомления приходят туда, где вы их точно увидите – в Telegram, Slack, куда угодно, но не в почту, которую проверяете раз в день? И главное – в уведомлении достаточно информации, чтобы принять решение за 10 секунд?

Про логи: Записывается всё – что агент увидел, как думал, что сделал, что получилось? Понятно, сколько хранить какие логи? Есть нормальный интерфейс, чтобы искать и смотреть эти логи, а не лезть в сырую базу? На критические события приходят алерты?

Про права: Агент работает под отдельным аккаунтом, а не под админом? Доступ ограничен до минимума – и по данным, и по действиям, и по объёму? Есть rate limits на API? И если что-то пойдёт не так – можно быстро отозвать все права?

Про аварийку: Есть автоматический тормоз на случай аномального поведения? Есть кнопка паники для ручной остановки? Понятно, что происходит после остановки и как перезапустить? И вы это всё хоть раз тестировали?

Если на какой-то вопрос ответ «нет» или «не уверен» – это не значит, что всё плохо. Это значит, что есть конкретная задача, которую нужно закрыть перед запуском. Лучше потратить день на доработку, чем потом разгребать последствия.

Как контроль будет меняться со временем

Контур контроля – это не бетонная стена, которую построили и забыли. Это живая система, которая будет меняться по мере того, как агент доказывает свою надёжность.

Первый месяц – режим параноика. Вы только что запустили агента, и вы ему пока не доверяете. И это правильно. Все внешние действия – только через жёсткое одобрение. Логируется вообще всё, включая каждую мысль агента. Каждый день садитесь с командой и разбираете логи: что агент делал, где ошибался, что можно улучшить. Лимиты на действия – минимальные. Да, это занимает время. Но это инвестиция в будущее спокойствие.

Второй-третий месяц – калибровка. Теперь у вас есть данные. Смотрите на статистику одобрений. Какие запросы вы всегда одобряете, не глядя? Их можно перевести в мягкое одобрение с таймаутом. Какие мягкие одобрения вы никогда не отклоняли? Может, агент может делать это автономно. Лимиты можно потихоньку поднимать – не на глазок, а на основе реальных данных. Логирование рассуждений для рутинных операций можно сократить – они уже не нужны в таком объёме.

После трёх месяцев – зрелая работа. Агент доказал, что ему можно доверять. Одобрения остаются только для реально критических вещей. Логирование настроено по уровням важности – рутина пишется кратко, серьёзные действия – подробно. Мониторинг можно проводить раз в неделю, а не каждый день. И можно начинать расширять функции агента на новые области – он заработал это право.

Главное правило: расширяйте автономию на основе данных, а не ощущений. «Мне кажется, агент справляется» – это не аргумент. «За последний месяц 847 одобрений в категории X, 0 отклонений» – вот это аргумент. Цифры не врут, а интуиция в таких вопросах подводит.

Подведём итоги

AI-агенты – это мощно. Но мощность без контроля – это не преимущество, это риск. Разница между «агент помогает бизнесу» и «агент устроил катастрофу» – это правильно настроенный контур контроля.

Что входит в минимальный контур? Четыре вещи.

Границы автономности – чёткое понимание, что агент делает сам, а где останавливается и спрашивает. Светофор из четырёх цветов: зелёный для безопасного, жёлтый для обратимого, оранжевый для заметного, красный для критичного.

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

Журналирование – чёрный ящик для агента. Всё записывается: что увидел, как думал, что сделал, что получилось. Критичное хранится годами. Менее важное – месяцами. Но в первое время – пишите вообще всё.

Права доступа – ровно столько, сколько нужно для работы, и ни граммом больше. Ограничения по данным, по действиям, по объёму. Отдельный аккаунт. Rate limits. И возможность мгновенно всё отозвать.

Плюс кнопка паники – автоматическая для аномалий, ручная для всего остального. Чтобы в случае чего можно было дёрнуть рубильник и остановить всё за секунды.

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

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

Что почитать дальше

Если хотите глубже разобраться в безопасности AI-агентов, вот несколько статей по теме:

Tool calling и агенты: как дать LLM доступ к CRM без катастрофы – про архитектуру безопасного взаимодействия агента с вашими бизнес-системами. Как устроить API так, чтобы агент мог работать, но не мог навредить.

RBAC для бота CRM: как ограничить контекст – детальный разбор прав доступа специально для AI-систем. Как сделать так, чтобы агент видел только то, что ему положено видеть.

AI governance в компании: политики и ответственность – как выстроить процессы управления AI на уровне всей организации. Кто за что отвечает, какие политики нужны, как не превратить это в бюрократию.