Антон Аракчеев Маркетинговые агенты

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

READ — только чтение

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

ANALYZE — обработка и анализ

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

WRITE — создание данных

Агент может создавать новые записи в системе: добавлять контакты в CRM, создавать задачи, обновлять справочники. При этом он не может удалять или изменять существующие критичные данные. Например: агент добавляет нового лида в CRM, но не может удалить существующего клиента.

EXECUTE — изменение состояния системы

Агент может изменять состояние системы: останавливать рекламные кампании, менять ставки, отправлять рассылки, публиковать контент. Это уровень, на котором агент уже существенно влияет на бизнес-процессы. Каждое такое действие должно быть либо подтверждено человеком (для начала), либо ограничено жёсткими правилами.

TRANSACT — финансовые и высокорисковые действия

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

Уровень

Примеры действий

Риск

READ

Чтение CRM, статистики, отзывов

Низкий

ANALYZE

Расчёт метрик, формирование отчётов

Низкий

WRITE

Создание задач, добавление лидов, заметки

Средний

EXECUTE

Остановка кампаний, отправка рассылок

Высокий

TRANSACT

Изменение бюджетов, возвраты, списания

Очень высокий

Принцип постепенного увеличения прав — не формальность, а основа безопасной эксплуатации агентов. Когда агент только запускается, мы не знаем, как он поведёт себя в реальных условиях. Дать ему сразу права EXECUTE — это дать ключи от машины водителю без прав. Правильная последовательность: сначала агент работает в режиме READ, мы смотрим, какие выводы он делает, насколько они корректны. Если всё хорошо — повышаем до ANALYZE и проверяем качество отчётов. Если отчёты полезны — даём WRITE и проверяем, что и как он обновляет. Только после нескольких циклов успешной работы на уровне WRITE можно переходить к EXECUTE — и то с подтверждением каждого действия. TRANSACT — финальная стадия, до которой большинство агентов не доходят никогда.

Эта последовательность не ускоряет, а замедляет внедрение — но именно это замедление и делает систему безопасной. Каждая стадия даёт команде уверенность, что агент ведёт себя предсказуемо. И если что-то идёт не так — проблема обнаруживается на ранней стадии, когда её легко исправить, а не после того, как агент отправил письмо 50 000 клиентам или потратил миллион рублей на неэффективную кампанию.

Для каждого агента должна быть явно задана матрица прав доступа к каждому инструменту. Это не формальный документ, а работающее правило, которое контролируется системой. Матрица строится по двум осям: инструменты (строки) и уровни прав (столбцы).

Инструмент

READ

ANALYZE

WRITE

EXECUTE

TRANSACT

CRM (контакты)

✓

✓

✓

—

—

CRM (финансы)

—

—

—

—

—

Рекламный кабинет

✓

✓

—

✓*

—

Аналитика

✓

✓

—

—

—

Рассылки

✓

✓

✓*

✓*

—

CMS

✓

—

✓*

✓*

—

База знаний

✓

✓

—

—

—

Знак ✓ означает разрешённое действие, ✓* — разрешённое, но с подтверждением человека, — — запрещено. Эта матрица — основа работы системы: при попытке агента выполнить действие система проверяет, есть ли у него права, и если нет — блокирует действие и логирует попытку. Без такой матрицы любые разговоры о безопасности агента остаются разговорами.

Сквозной кейс: «МетрикаПро» — матрица прав Sales-агента

Sales-агент в B2B-сервисе аналитики для маркетплейсов. Задача — квалификация входящих лидов, подготовка контекста для менеджеров, ведение сделок до демо.

Права: READ — все поля в CRM кроме финансовых; ANALYZE — данные из аналитики по действиям пользователя в системе; WRITE — создание задач менеджеру, добавление заметок в карточку лида; EXECUTE — отправка templated-писем из набора одобренных; TRANSACT — нет.

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

Подтверждение: все EXECUTE-действия логируются и ежедневно проверяются руководителем продаж. За первые 3 месяца работы агента не было ни одного инцидента, потребовавшего отката.

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

Базовые правила: ключи никогда не хранятся в коде (только в переменных окружения или в секретном хранилище); каждый агент имеет свой набор ключей (не один общий); ключи имеют минимально необходимые права; ключи ротируются раз в 90 дней или чаще; доступ к ключам логируется. Эти правила — не формальность, а основа безопасности. Утечка API-ключа от рекламного кабинета может стоить миллионы; утечка ключа от CRM — подорвать доверие клиентов.

Инструменты меняются. API обновляются: добавляются новые методы, удаляются старые, меняются форматы ответов. Это не редкость, а норма жизни. Агент должен быть устойчив к таким изменениям. Минимальные меры: явная версия API в коде (не «последняя», а «версия 5.2 от октября»); обработка ошибок API с разными стратегиями (повтор, эскалация, fallback); мониторинг изменений в API (подписка на changelog'и). Без этого агент будет работать до первого изменения API, а потом молча ломаться.

Особенно чувствительны к изменениям рекламные API: Яндекс Директ, VK Реклама, Telegram Ads обновляются регулярно, иногда с коротким notice. Если агент критичен для бизнеса, имеет смысл заложить в архитектуру «graceful degradation»: если один инструмент недоступен или изменён, агент должен понять это, сообщить, и продолжить работу с теми инструментами, что доступны. Это сложнее в разработке, но значительно повышает надёжность системы в реальном мире.