ИИ-агент с доступом к CRM или почте способен не только подготовить текст, но и вызвать подключённый инструмент. Поэтому до разработки нужно решить, какие действия ему доступны, при каких условиях workflow разрешает вызов и когда процесс останавливается.
Главный принцип: модель предлагает действие, а обычная логика workflow проверяет его до обращения к внешней системе. Промпт помогает направить модель, но не заменяет технические ограничения. Stop And Error и workflow обработки ошибок тоже решают отдельные задачи и сами по себе не образуют систему контроля полномочий.
Начните не с промпта, а с полномочий агента
В n8n к узлу AI Agent подключают модель чата и один или несколько инструментов. Согласно актуальной документации n8n, агент выбирает, какой инструмент вызвать для выполнения задачи. Инструменты позволяют получать сведения и выполнять действия через внешние системы и API.
Здесь важно разделить три уровня:
- Решение модели — какое действие агент считает подходящим.
- Техническая возможность — какой инструмент и какая операция действительно доступны в workflow.
- Бизнес-разрешение — допустимо ли выполнять эту операцию для конкретного объекта и состояния процесса.
Например, модель может предложить изменить сумму сделки. Но это не означает, что ей нужно предоставлять инструмент изменения суммы. Даже доступную операцию записи workflow должен разрешать только после проверки параметров и состояния объекта.
Документация AI Agent подтверждает подключение инструментов и их выбор агентом. Она не утверждает, что узел сам знает полномочия сотрудников, правила конкретной компании или допустимые изменения в CRM. Эти границы нужно спроектировать и проверить отдельно.
Составьте реестр инструментов и операций
Начните с одного процесса и перечислите не системы вообще, а отдельные операции. Чтение письма, создание записи, изменение поля, отправка сообщения и удаление записи — разные полномочия.
Используйте такой шаблон:
| Система и инструмент | Операция | Разрешённые входные данные | Допустимое состояние | Ожидаемый результат | Запрещённые изменения | Техническая проверка |
|---|---|---|---|---|---|---|
| Почта: чтение сообщения | Прочитать письмо по идентификатору | Идентификатор из текущего события | Письмо доступно процессу | Получены тема, отправитель и текст | Отправка, удаление, смена папки | Идентификатор относится к текущему событию |
| CRM: поиск карточки | Найти клиента | Проверенный адрес или телефон | Доступно чтение нужного раздела | Получен список совпадений | Создание и изменение карточки | Результат содержит один, несколько или ни одного объекта |
| CRM: запись заметки | Добавить подготовленную заметку | Идентификатор карточки и структурированный текст | Найдена одна допустимая карточка | Система вернула подтверждение операции | Сумма, стадия и владелец сделки не меняются | Название операции, поля и состояние прошли проверку |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Это проектный шаблон, а не описание встроенной политики n8n. Где позволяет интеграция, исключите лишние операции и доступы на её уровне. Затем отдельно поставьте проверки в workflow. Не рассчитывайте, что общий доступ к CRM автоматически превратится в минимально необходимые полномочия.
Разделите самостоятельные действия, черновики и исключения
Для рабочего обсуждения удобно распределить действия по трём группам. Это не универсальный стандарт: состав групп зависит от обратимости операции, полноты данных и ответственности сотрудника.
| Группа | Что происходит | Пример для CRM или почты |
|---|---|---|
| Самостоятельное действие | Workflow выполняет операцию только при проверяемых условиях | Прочитать письмо или найти карточку по разрешённому признаку |
| Черновик | Агент готовит результат без внешнего изменения | Составить текст заметки или ответа, но не отправлять его |
| Исключение | Вызов блокируется, контекст передаётся сотруднику | Несколько карточек, противоречивые сведения, изменение суммы сделки |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Одно и то же действие в разных процессах может попасть в разные группы. Отправка типового внутреннего уведомления иногда допустима автоматически, а письмо клиенту с условиями сделки может требовать отдельного решения сотрудника.
Здесь мы определяем границу самостоятельных полномочий. Интерфейс подтверждения, очередь согласований и продолжение после решения человека — отдельная задача.
Поставьте техническую проверку перед вызовом инструмента
Безопасную границу лучше строить вне свободного решения модели. Агент формирует намерение и структурированные параметры, затем обычные узлы workflow проверяют их и только после этого передают данные узкому исполнителю.
Последовательность для проектирования:
- Агент предлагает название операции и параметры.
- Workflow сверяет операцию со списком разрешённых.
- Workflow проверяет обязательные поля и состояние объекта.
- Узкий исполнитель вызывает только разрешённое действие.
Если проверка не пройдена, проверяемый вызов узкого исполнителя не выполняется. Процесс формирует исключение с причиной остановки и доступным контекстом.
Например, исполнитель записи заметки не должен принимать произвольное название операции. Он получает только идентификатор карточки и текст заметки после того, как workflow подтвердил единственное совпадение и наличие обязательных полей. Попытка передать update_deal_amount вместо разрешённого create_note должна завершиться до обращения к CRM.
Это архитектурное требование к будущему решению, а не встроенная гарантия AI Agent. Текстовая инструкция модели остаётся полезной, но не должна быть единственным барьером перед внешним действием.
Определите условия остановки и состав передачи сотруднику
Заранее перечислите причины, при которых агент не продолжает самостоятельный путь:
- отсутствуют обязательные данные;
- найдено несколько подходящих объектов;
- сведения из источников противоречат друг другу;
- запрошена запрещённая операция;
- результат инструмента нельзя однозначно подтвердить;
- решение по правилам процесса принадлежит сотруднику.
Для каждого исключения передавайте не только сообщение «не удалось», но и контекст, достаточный для разбора:
- исходный запрос или идентификатор события;
- предложенную операцию;
- структурированные параметры;
- данные, на которых основано предложение;
- известное состояние объекта;
- причину остановки.
Не задавайте общий порог уверенности только потому, что он выглядит точным. Условие должно проверяться на данных процесса: например, «найдена ровно одна карточка с совпадающим проверенным адресом», а не «агент уверен на 90%» без метода измерения.
Отделите управляемую остановку от технической ошибки
Документация n8n описывает узел Stop And Error: он может завершить выполнение с ошибкой при заданном условии и передать собственное сообщение или объект ошибки. Его можно поставить после проваленной проверки допуска.
Например, workflow обнаружил операцию, которой нет в разрешённом списке. Ветка не вызывает CRM, формирует объект с названием операции и причиной отказа, затем Stop And Error намеренно завершает выполнение.
Но Stop And Error только создаёт отказ выполнения. Он сам не определяет:
- какие операции разрешены;
- какие сведения нужно сохранить;
- было ли внешнее действие выполнено раньше;
- кому и как передать исключение;
- можно ли повторять попытку.
Различайте три ситуации:
| Ситуация | Пример | Что важно зафиксировать |
|---|---|---|
| Отказ бизнес-проверки | Запрошено изменение суммы сделки | Правило запрета, предложенная операция и параметры |
| Сбой внешнего сервиса | CRM вернула ошибку или не ответила | Идентификатор операции и известное состояние CRM |
| Непредвиденная ошибка workflow | Узел не смог обработать входные данные | Место сбоя, входной контекст и сведения об исполнении |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Так сотрудник увидит, что именно произошло: агенту отказали по правилу или выполнение оборвалось из-за технической проблемы.
Настройте аварийный маршрут без слепого повтора
В настройках каждого workflow n8n можно назначить отдельный workflow обработки ошибок. Он запускается при отказе выполнения и должен начинаться с Error Trigger. Stop And Error позволяет намеренно вызвать такой маршрут при выбранном разработчиком условии.
Аварийный workflow может использовать полученные сведения для уведомления и разбора. Но он не решает автоматически, безопасно ли повторять операцию. Это особенно важно, если сбой возник после обращения к внешней системе: CRM могла выполнить запись, даже если workflow не получил или не обработал ответ.
Сохраняйте для разбора:
- идентификатор исходного события и операции;
- запрошенное действие и параметры;
- известное состояние внешней системы до вызова;
- доступный ответ системы;
- последний завершённый этап;
- причину сбоя;
- признак повторного запуска, если он известен.
Перед повтором проверьте результат предыдущей попытки по правилам конкретной системы. Не превращайте автоматический retry в ответ на любую ошибку. Error workflow — механизм реакции на отказ, а не маршрут ручного согласования и не доказательство того, что повтор безопасен.
Проверьте технические границы на сценариях процесса
Ниже — синтетический учебный пример требований. Это не клиентский кейс, не выполненный тест и не утверждение о встроенной защите n8n.
Агент разбирает входящее письмо потенциального клиента. Самостоятельно он может прочитать письмо, найти существующую карточку и подготовить структурированный черновик заметки. Записать заметку может отдельный узкий исполнитель: перед его вызовом обычная логика workflow проверяет название операции, обязательные поля и состояние найденной карточки. Изменение суммы сделки, удаление записи, массовое обновление и самостоятельная отправка письма не входят в полномочия агента: соответствующие инструменты не предоставляются либо вызов блокируется до внешнего действия.
Паспорт этого учебного сценария:
| Элемент | Требование |
|---|---|
| Разрешённое чтение | Прочитать текущее письмо и найти карточку по согласованному признаку |
| Разрешённая подготовка | Сформировать черновик заметки из сведений письма |
| Условие записи | Найдена одна допустимая карточка, обязательные поля заполнены, операция называется create_note |
| Запрещённые действия | Менять сумму, удалять запись, массово обновлять CRM, отправлять письмо |
| Остановка | Нет карточки, несколько карточек, противоречие данных, запрещённая операция или неоднозначный ответ |
| Передаваемый контекст | Письмо, предложенная операция, параметры, найденные объекты, известное состояние и причина остановки |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Проверочные сценарии нужно записать до реализации:
| Сценарий | Ожидаемое состояние CRM или почты | Запись об исполнении и уведомление |
|---|---|---|
| Разрешённое чтение | Данные не изменены | Зафиксированы запрос и результат поиска |
| Подготовка черновика | Письмо не отправлено, CRM не изменена | Сохранён черновик и исходные данные |
| Запрещённый или отсутствующий инструмент | Внешнего изменения нет | Причина: операция не входит в полномочия |
| Подмена названия операции | Внешний вызов заблокирован | Сохранены полученное имя и правило отказа |
| Неполные данные | Запись не создаётся | Перечислены отсутствующие поля |
| Найдено несколько карточек | Карточки не изменены | Переданы найденные варианты и причина неоднозначности |
| CRM отказала до подтверждённого действия | Успех не объявляется | Сохранены запрос, ответ или факт отсутствия ответа |
| Ошибка после внешнего действия | Состояние считается неизвестным до проверки CRM | Уведомление требует сверить результат перед повтором |
| Повторный запуск | Новое действие выполняется только по согласованному правилу | Зафиксированы связь с первой попыткой и результат проверки |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Во время приёмки сравнивайте ожидаемое и фактическое состояние внешней системы, запись об исполнении, причину остановки и состав уведомления. Руководства по приёмке автоматизации, восстановлению после ошибок n8n, доступам и данным и мониторингу агента помогут проверить соседние части решения.
Решение сотрудника и продолжение после ручного согласования остаются за границами этой проверки.
Что передать исполнителю до разработки
До начала разработки соберите пакет по одному процессу:
- схему пути от входного события до результата;
- реестр инструментов и отдельных операций;
- перечень самостоятельных полномочий;
- список запрещённых вызовов;
- проверки перед каждым внешним действием;
- причины остановки;
- состав контекста для сотрудника;
- требования к журналу действий;
- сценарии приёмки, включая сбой после внешнего действия и повторный запуск;
- операции, для которых отдельно потребуется спроектировать ручное согласование.
Этого достаточно, чтобы обсуждать не абстрактно «безопасного агента», а конкретные технические границы. При этом ИИ-агент остаётся решением, которое выбирает следующий шаг среди доступных инструментов. Чат-бот ведёт диалог, а обычная интеграция выполняет заранее заданную последовательность. Для процесса с фиксированными шагами агент может вообще не понадобиться.
Switch On AI разрабатывает ИИ-агентов под рабочие процессы. На первом разборе можно взять один процесс, список систем и разделить действия на чтение, подготовку, самостоятельное выполнение и исключения. Затем готовятся ТЗ и коммерческое предложение, а ключевой сценарий можно проверить на бесплатном прототипе. Прототип не равен полноценному внедрению; рабочие подключения, эксплуатация и объём разработки согласуются отдельно.
Чтобы обсудить задачу, принесите описание процесса, перечень систем и примеры действий, которые агент должен читать, предлагать или выполнять. Расскажите о процессе — вместе составим карту полномочий и проверки ограниченного прототипа.
Вопросы по этой задаче
Можно ли ограничить ИИ-агента только инструкцией в промпте?
Нет. Промпт помогает описать желаемое поведение, но перед внешним действием нужны технические ограничения: узкий набор инструментов, список разрешённых операций и проверки параметров обычной логикой workflow.
Чем ограничение полномочий отличается от ручного согласования?
Ограничение полномочий определяет, что агент вправе делать самостоятельно и какие вызовы система блокирует. Ручное согласование организует решение сотрудника по отдельным операциям; его интерфейс и маршрут проектируются отдельно.
Как не допустить вызов запрещённого инструмента?
Не предоставлять лишний инструмент, где это возможно, и проверять название операции, обязательные параметры и состояние объекта вне модели. Узкий исполнитель вызывается только после успешной проверки.
Когда остановка считается бизнес-исключением, а когда технической ошибкой?
Бизнес-исключение возникает по правилу процесса: например, найдены две карточки или запрошено изменение суммы. Техническая ошибка означает сбой workflow либо внешнего сервиса. Эти причины нужно фиксировать раздельно.
Как проверить, что повторный запуск не выполнит действие ещё раз?
Сохранить идентификатор операции и известное состояние внешней системы, а перед повтором проверить результат предыдущего вызова по согласованному правилу. Автоматический повтор без такой проверки может продублировать внешнее действие.