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

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

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

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

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

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

Что такое контракт действия

Для каждого действия нужен один владелец из бизнеса и один технический ответственный. Владелец объясняет смысл операции, а технический ответственный связывает её с доступным API, коннектором или другим надёжным интерфейсом. Если у процесса нет владельца, агенту нельзя поручать выполнение — можно разрешить только подготовку информации для человека.

Пять обязательных полей

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

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

Где применять агентные действия

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

Функция	Разумное первое действие	Граница автономии	Когда нужен человек
Продажи	Обновить карточку лида, добавить следующую задачу и подготовить черновик follow-up	Не менять цену, скидку, условия договора и стадию без правила	Нестандартные условия, спорный статус или высокий приоритет клиента
Маркетинг	Сегментировать подписчиков по явным признакам и собрать бриф для редактора	Не отправлять коммуникацию тем, кто исключён из рассылки	Сомнительное согласие, чувствительная тема или новый сегмент
HR	Ответить на вопрос по открытому регламенту и создать задачу на адаптацию	Не принимать кадровые решения и не выгружать лишние персональные данные	Индивидуальная ситуация, конфликт или запрос о конфиденциальной информации
Финансы	Сверить обязательные реквизиты счёта и запросить отсутствующий документ	Не подтверждать платёж и не менять банковские данные	Расхождение в сумме, контрагенте или платёжных условиях
Поддержка	Классифицировать обращение, найти подходящий материал и создать обращение в helpdesk	Не обещать компенсацию и не закрывать сложный инцидент	Недостаточно контекста, негативная реакция или риск для сервиса

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

Как запустить управляемый контур

1. Составить карту действий

Соберите представителей продаж, маркетинга, HR, финансов и поддержки на короткую инвентаризацию. Записывайте не названия отделов, а глаголы: создать, обновить, запросить, классифицировать, подготовить, передать. Для каждого глагола укажите систему, в которой появляется результат, и человека, который несёт ответственность.

2. Описать контракты простым языком

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

3. Выдать минимальные права

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

4. Проверить поведение до продакшена

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

5. Запустить с наблюдаемостью

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

Архитектура без новой рутины

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

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

Для связки разных отделов полезно определить общий словарь. Например, «квалифицированный лид», «открытое обращение» и «подтверждённый документ» должны означать одно и то же во всех контрактах. Это снижает число ручных передач и делает результат понятным для владельца процесса. Подробнее о переходе от консультаций к действиям можно прочитать в материале о подключении AI-агента к бизнес-системам, а подход к ограничению доступа раскрыт в статье о контроле доступа к коммерческим документам.

Отдельно, по практике Unlim Group, наиболее устойчивые внедрения начинаются не с демонстрации широкой автономии, а с небольшого набора хорошо описанных операций. Когда команда видит полный след действия и знает, где находится человек в контуре, доверие к агенту растёт быстрее, чем при запуске «чёрного ящика».

РФ и СНГ: что учесть до пилота

Для российских компаний и команд из СНГ важно заранее определить, где хранятся и обрабатываются данные, какие сведения нельзя передавать внешнему сервису и как будет работать резервный маршрут. При работе с персональными данными учитывайте требования 152-ФЗ, договоры с обработчиками, внутренние политики безопасности и применимые требования стран присутствия. Это не отдельный этап после выбора модели, а часть проектирования контрактов.

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

Какие метрики смотреть

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

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

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

Чек-лист перед запуском

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

FAQ