«Агенты» без риска: минимальный контур контроля, чтобы AI не…
  • AI & Безопасность
  • Автор: Команда CrmAI
  • Опубликовано:
Контур контроля AI-агентов в production — approvals, логи и права доступа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Матрица автономности AI-агента — четыре уровня действий и режимы контроля

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

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

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

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

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

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

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

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

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

Агент запрашивает одобрение

Клиент: ТОО «Алматы Строй» — постоянный партнёр, 3 заказа за год на 25 млн ₸

Текущая сделка: Поставка 500 единиц на 8 750 000 ₸

Что хочу сделать: Дать скидку 12% (минус 1 050 000 ₸ для клиента)

Почему: Клиент попросил скидку за оптовый объём

Моя рекомендация: Одобрить. Клиент лояльный, даже с этой скидкой маржа 18% — выше нашего порога.

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

Хотите внедрить AI-агентов безопасно?

Мы поможем настроить контур контроля под ваши процессы — без рисков и с полной прозрачностью.

Обсудить внедрение

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

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

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

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

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

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

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

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

Структура журнала действий AI-агента — входные данные, рассуждения, действия, результаты

Как долго всё это хранить? Тут простое правило: чем серьёзнее действие, тем дольше храним. Всё, что связано с деньгами или удалением данных — 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? И если что-то пойдёт не так — можно быстро отозвать все права?

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

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

Нужна помощь с настройкой контура контроля?

Мы проведём аудит вашей системы и поможем настроить безопасную работу AI-агентов.

Заказать аудит

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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