Представьте: агент подготовил правильное письмо клиенту и собирается нажать «Отправить». Кто подтверждает этот шаг — менеджер, правило или сам агент? Именно здесь заканчивается разговор о красивом ответе и начинается проектирование ответственности. В этой статье вы получите контракт одного действия, схему доступов, набор проверок и ворота безопасного поэтапного расширения. Честная граница: универсальной «безопасной автономности» нет; предел зависит от конкретного действия, данных и цены ошибки.
1. Короткий ответ: агент, помощник, чат-бот и сценарий по правилам
Название на лендинге не определяет архитектуру. Чат-бот прежде всего ведёт диалог. Помощник готовит результат для человека — например, резюме встречи или черновик письма. Workflow — сценарий по правилам — выполняет известную последовательность правил. AI-агент управляет многошаговой работой: оценивает состояние, выбирает следующий шаг, вызывает разрешённый инструмент и продолжает до результата, остановки или эскалации.
Практическая проверка проста: спросите, может ли система изменить что-то вне чата. Если нет, риск ограничен качеством ответа. Если да, нужно описать не «цифрового менеджера», а каждое право: что читать, что предложить, что записать, кто подтвердит и как отменить. Агент — это не должность. Это ограниченное право совершать действия.
| Формат | Что делает | Где решение | Типичный контроль |
|---|---|---|---|
| Чат-бот | Отвечает в диалоге | В сценарии или модели | Проверка ответа |
| Помощник | Готовит черновик | У человека | Ручное принятие |
| Сценарий по правилам | Идёт по заданным правилам | В коде процесса | Тесты веток |
| AI-агент | Выбирает шаг и инструмент | У модели в заданных пределах | Права, подтверждения, проверки, журнал |
2. Из чего состоит управляемый AI-агент
Модель понимает задачу и предлагает следующий шаг, но одна модель агентом не является. Инструменты дают ей контролируемый выход во внешний мир: поиск в базе знаний, чтение карточки CRM, создание задачи или вызов API. Контекст хранит состояние текущей работы. Выбор следующего шага иногда называют планировщиком, хотя это не обязательно отдельный компонент.
Вокруг рабочего цикла нужен контур управления: политики определяют разрешённое и запрещённое, защитные проверки проверяют входы и вызовы, правила подтверждения передают ответственность человеку, а трассировка показывает путь решения. Модель может сформировать структурированный вызов инструмента, но приложение обязано проверить параметры, авторизовать операцию, выполнить её и вернуть фактический результат.
3. Какие сценарии подходят для первого пилота
Начинайте не с отдела, а с атомарного действия. «Агент для продаж» невозможно безопасно оценить. «Прочитать новый лид, найти сведения в базе, предложить ответ и создать черновик задачи после подтверждения менеджера» — уже рабочая граница. У неё есть триггер, вход, выход, владелец и понятный внешний эффект.
Хороший первый сценарий сочетает четыре свойства:
- повторяется достаточно часто, чтобы пилот имел смысл;
- требует разбора неоднозначного текста или выбора следующего шага;
- результат можно проверить до существенного внешнего эффекта;
- ошибку можно остановить, исправить или передать человеку.
Подойдут подготовка ответа по данным CRM и базы знаний, классификация обращения с предложением маршрута, сбор контекста для внутренней заявки. Плохие кандидаты для старта — платёж, удаление записей, массовая рассылка и юридически значимое решение без владельца. Общую методику выбора процесса мы отдельно разбираем в статье об AI-автоматизации бизнеса; здесь фокус уже уже: контракт конкретного действия.
4. Контракт действия агента: главный артефакт пилота
Контракт действия соединяет бизнес-задачу и технические ограничения на одной странице. Его можно приложить к техническому заданию, проверке поставщика и решению о продолжении или остановке. Если поле нельзя заполнить, это не мелочь для будущей разработки, а неизвестный риск.
Контракт действия агента
Цель и владелец: зачем действие нужно и кто отвечает за результат.
Триггер: какое событие запускает выполнение и как исключить дубликат.
Разрешённые данные: источники, сущности, поля и срок хранения.
Инструмент и область прав: отдельно чтение, создание, изменение и удаление.
Запреты: данные и операции, к которым агент не приближается.
Подтверждение: кто подтверждает, что видит и сколько решение действует.
Отказ и эскалация: когда агент обязан остановиться.
Лимиты: шаги, повторы, время, стоимость и объём внешних действий.
Событие аудита: что сохраняется для воспроизведения решения.
Откат и аварийное отключение: как отменить эффект и остановить систему.
Проверка поставщика: попросите показать не только успешное демо, а журнал одного ошибочного действия. Что модель увидела? Какой инструмент выбрала? Какие аргументы прошли проверку? Кто подтвердил шаг? Что действительно ответила CRM? Если цепочку нельзя восстановить, контроль пока существует только на словах.
До договора полезно провести ещё одну проверку: взять одно намеренно неудобное обращение и пройти весь путь вместе с исполнителем. Пусть в карточке не хватает обязательного поля, база знаний содержит устаревшую инструкцию, а пользователь просит действие за пределами своей роли. Зрелая система не «догадывается», как скрыть противоречие. Она показывает, какое правило сработало, отказывается от запрещённого шага и передаёт задачу названному владельцу. В договоре при этом должны быть разделены качество ответа модели и надёжность внешней операции: красивый текст не компенсирует неверную запись.
Зафиксируйте также, кто может менять инструкции, набор инструментов и правила подтверждения после запуска. Такое изменение фактически создаёт новую версию поведения, даже если интерфейс остался прежним. Для неё нужны журнал изменений, повторная проверка критических сценариев и возможность быстро вернуть предыдущую конфигурацию. Иначе предел автономности способен расшириться незаметно для владельца процесса — например, когда к чтению карточки добавили изменение полей, но не пересмотрели правила подтверждения.
5. Лестница автономности и правила подтверждения
Автономность полезно повышать не по впечатлению от модели, а по цене действия. На нижнем уровне агент отвечает или рекомендует. Затем готовит черновик внешнего действия. Дальше получает право на узкое обратимое изменение. Деньги, массовая отправка и удаление находятся наверху шкалы последствий и требуют явного подтверждения либо запрета.
Автоматическая защитная проверка и подтверждение — разные вещи. Проверка контролирует правило: допустимы ли тип данных, поле и лимит. Подтверждение останавливает выполнение до решения человека или утверждённой политики. Для опасного действия нужны оба слоя. Человек должен видеть не абстрактное «агент просит доступ», а операцию, объект, значения, источник и ожидаемый эффект.
6. Доступы, области прав, секреты и изоляция данных
«Подключить CRM» — опасно широкая формулировка. Разделите чтение, создание, изменение и удаление. Например, агент может читать карточки только выбранного отдела, создавать черновик задачи и не иметь права экспортировать базу, менять сумму сделки или удалять контакт. Область прав OAuth ограничивает токен, но сервер всё равно проверяет пользователя, tenant, объект и бизнес-правило.
Секрет не кладут в инструкцию, память или файл задания. Инфраструктура выдаёт его конкретному инструменту на нужный срок; доступ можно отозвать и отследить. Токен должен быть предназначен целевому ресурсу, а не передаваться по цепочке во все сервисы. Управляемые моделью код и файлы лучше изолировать в отдельной среде, а авторизацию, правила подтверждения, журнал и состояние восстановления держать снаружи.
7. Проверки: оцениваем путь, а не красоту ответа
Обычное «потыкали демо — выглядит хорошо» не проверяет агента. Соберите набор сценариев из реальных, граничных и запрещённых задач. Для каждого примера заранее задайте ожидаемый результат и допустимый путь. После изменения модели, инструкции, инструментов или правил этот набор запускают снова: иначе улучшение одной ветки может незаметно сломать другую.
Минимум нужно оценивать отдельно:
- task success: достигнута ли бизнес-цель, а не просто создан убедительный текст;
- выбор инструмента: выбран ли правильный инструмент;
- аргументы: верны ли объект, поля и значения;
- классы ошибок: как система ведёт себя при пустых, конфликтующих и устаревших данных;
- refusal: остановилась ли перед запрещённым действием;
- эскалация: передала ли человеку задачу, которую нельзя надёжно завершить;
- loops: не повторяет ли вызов после таймаута или неоднозначного ответа.
Универсального проходного процента нет: порог выводится из цены конкретной ошибки. LLM-grader может помогать сортировать результаты, но критическое действие нельзя отдавать только на оценку другой модели. Нужны детерминированные проверки, сверка внешнего эффекта и выборочный human review.
8. Журналирование, трассировка и воспроизводимость
Трассировка нужна разработчику, чтобы увидеть обращения к модели, инструменты, результаты, передачи между исполнителями и защитные проверки. Но бизнес-аудит требует большего: идентификатор операции, версию агента, инициатора, объект, проверенные параметры, решение о подтверждении и фактический ответ внешней системы. Иначе трассировка покажет намерение «обновить CRM», но не докажет, что записалось в CRM.
Представьте инцидент: клиент получил два одинаковых письма. Команде мало знать, что модель дважды выбрала инструмент. Нужно понять, был ли повторный запуск, истёк ли срок ожидания, увидело ли приложение первый успех и сработал ли idempotency key. Поэтому журнал проектируют вместе с действием, а не добавляют после первой ошибки. Сам журнал содержит чувствительные данные: ограничьте доступ, срок хранения и содержимое.
9. Цена действия, лимиты, откат и аварийное отключение
Лимит — это не только бюджет токенов. Ограничьте число шагов, повторов, внешних вызовов, объектов за один запуск и общий объём действия. Для повторяемых операций нужен ключ идемпотентности: повторный запрос не должен создать вторую задачу или отправить второе письмо. Для обратимых изменений опишите rollback, а для необратимых — компенсацию и обязательное подтверждение.
Аварийное отключение — не декоративная красная кнопка. Проверенный маршрут должен остановить новые задания, прервать активные запуски, отключить опасный инструмент, отозвать учётные данные, вернуть прежнюю версию и передать незавершённые операции человеку. Владелец обязан знать, кто имеет право на остановку и как убедиться, что внешний эффект действительно прекратился.
10. Архитектура пилота с CRM и базой знаний
Безопасный маршрут выглядит скучно — и это хороший признак. Событие «новый лид» запускает выполнение. Агент читает только разрешённые поля, ищет релевантный контекст в базе знаний и готовит предложение: текст ответа, следующую стадию и основание. Проверка правил контролирует область прав и данные. Менеджер видит список изменений и подтверждает или исправляет. Только после этого сервис выполняет один вызов CRM и пишет результат в журнал аудита.
Здесь модель не получает общий токен CRM и не решает сама, что скрыть от журнала. Если база знаний противоречит карточке, агент не угадывает источник истины, а эскалирует. Если CRM не ответила, система проверяет статус операции до повтора. Расширять можно отдельно: сначала аудиторию, затем данные, затем новый инструмент и только потом уровень автономности.
11. Что подтверждают AI-кейсы 13FOX — и чего не подтверждают
В портфолио 13FOX есть AI-функции с разными типами взаимодействия. В Epicure AI представлены сценарии распознавания по фото и персональных рекомендаций. В LightWeightFit показаны анализ питания, прогресс и AI-тренер; на главной странице проекта доступны ссылки на магазины. Эти интерфейсы полезны как proof работы с мультимодальным вводом, контекстом и понятной подачей результата.
«Психея» показывает голосовое взаимодействие, память контекста и важную продуктовую границу: сервис не заменяет профессиональную психотерапию. Psyhology AI сочетает заметки и AI-анализ. Публичные страницы не доказывают автономные действия этих продуктов во внешних системах, автономное внедрение агента, клинический эффект или бизнес-метрики. Поэтому мы используем их только как подтверждение опыта с AI-функциями, персонализацией, UX и границами результата.
Для вашей задачи переносится не обещание чужого результата, а метод: сделать действие видимым, объяснить его пользователю, оставить точку контроля и честно обозначить предел системы. Экономику человеко-машинного процесса можно дополнительно разобрать по сценарной модели из статьи о расходах на персонал и AI; её цифры не являются гарантией экономии конкретного клиента.
12. Когда AI-агент не нужен
Если событие «оплата получена» всегда ведёт к одинаковым шагам — изменить статус, сформировать чек, отправить шаблонное уведомление — используйте детерминированный сценарий по правилам. Он проще тестируется, объясняется и восстанавливается. Агент оправдан, когда следующий шаг зависит от неоднозначного контекста или правил, которые трудно поддерживать обычными ветками.
Иногда достаточно поиска по базе знаний, классификатора или помощника, который готовит черновик без права записи. Это не «урезанный агент», а более подходящая архитектура с меньшей ценой контроля. Предпроектный разбор должен иметь право закончиться выводом: полноценный агент сейчас не нужен.
13. Решение о продолжении или остановке и поэтапное расширение
Переход открывается не по календарю и не после эффектного демо. Перед боевым запуском команда должна показать контракт действия, минимальные области прав, набор запрещённых операций, повторяемые проверки, корректные отказы и эскалации, защиту от дублей, воспроизводимый журнал, рабочий rollback и проверенный путь остановки. Владелец процесса принимает остаточный риск осознанно.
No-go нужен, если агент выполняет запрещённое, не объясняет источник данных, теряет связь между подтверждением и фактической операцией, повторяет внешний эффект или не отключается. Это не провал пилота: конкретный класс ошибки возвращается в набор сценариев, причина исправляется, проверка повторяется. Права расширяются только после нового решения.
Решение о расширении лучше оформлять по четырём независимым осям. Первая — аудитория: от тестовой команды к ограниченной группе пользователей. Вторая — данные: от обезличенных примеров к рабочим записям строго нужного подразделения. Третья — инструменты: от чтения к подготовке, затем к отдельной операции записи. Четвёртая — самостоятельность: от рекомендации к выполнению в заранее разрешённом коридоре. Если открыть всё одновременно, при инциденте будет трудно понять, какое изменение увеличило риск. Последовательное расширение оставляет понятную точку возврата.
14. Что сделать завтра: чек-лист пилота
- Выберите одно внешнее действие, а не «агента для отдела».
- Назначьте владельца результата и человека для исключений.
- Заполните контракт действия агента без формулировок «доступ ко всему».
- Разделите чтение, создание, изменение и удаление; лишнее запретите.
- Опишите интерфейс подтверждения и последствия, которые увидит проверяющий.
- Соберите реальные, граничные и запрещённые проверочные сценарии.
- Определите событие журнала, защиту от дублей, откат и аварийное отключение.
- Зафиксируйте решение о продолжении или остановке до подключения рабочих данных.
Эту восьмишаговую проверку можно отправить владельцу процесса и подрядчику до первой встречи. Если ответы расходятся, спор возник не о модели, а о праве и ответственности — его дешевле решить до интеграции.
Источники и границы актуальности
Технические выводы проверены 30 июля 2026 года по официальным документам. API, протоколы и настройки платформ меняются; перед реализацией закрепите версии и повторно проверьте требования поставщика.
- OpenAI: Agents SDK — агентский цикл и инструменты.
- OpenAI: использование инструментов — типы инструментов и модель вызова.
- OpenAI: защитные проверки и участие человека — проверки и подтверждения.
- OpenAI: оценка агентских процессов — наборы сценариев и повторяемые проверки.
- OpenAI: оценка трассировки — оценка полного пути выполнения.
- Спецификация авторизации MCP — области прав и привязка токенов к ресурсу.
- Ядро NIST AI RMF — надзор, отключение, реакция на инциденты и восстановление.
FAQ
Чем AI-агент отличается от чат-бота и обычной автоматизации?
Чат-бот в основном ведёт диалог, а детерминированная автоматизация выполняет заранее заданную последовательность. AI-агент управляет многошаговой работой: анализирует состояние, выбирает следующий шаг и вызывает разрешённые инструменты до результата, остановки или передачи человеку. Название продукта само по себе ничего не доказывает — смотрите на его наблюдаемое поведение.
С какого сценария лучше начать пилот AI-агента?
Подходит узкое, повторяемое и обратимое действие с понятным владельцем: например, прочитать новый лид, найти контекст, подготовить ответ и создать черновик задачи после подтверждения менеджера. Не начинайте с платежей, удаления данных, массовых отправок или решения, за которое никто не отвечает.
Можно ли подключить AI-агента к CRM?
Да, если разделить права чтения и записи, ограничить сущности и поля, проверять аргументы каждого вызова, требовать подтверждение перед существенным изменением и сохранять фактический ответ CRM. Формулировка «доступ к CRM» слишком широка: безопасный проект перечисляет разрешённые операции поштучно.
Когда действие AI-агента должен подтверждать человек?
Человеческое подтверждение нужно перед чувствительным, дорогим, внешним или трудно обратимым эффектом: отправкой сообщения, изменением существенных данных, возвратом денег, платежом или удалением. Проверяющий должен видеть объект, параметры, источник данных и ожидаемое последствие, а не только кнопку «Разрешить».
Как понять, что AI-агент готов к боевому запуску?
Готовность доказывают повторяемые проверки и пилот в узкой области прав: агент достигает цели, выбирает правильный инструмент и аргументы, отказывается от запрещённого, эскалирует исключения, не дублирует действия, укладывается в лимиты, оставляет воспроизводимый журнал и останавливается проверенным аварийным отключением. Красивого демо для этого недостаточно.
Сколько стоит и сколько длится разработка AI-агента?
Без описания действия честной фиксированной оценки нет. На объём влияют число систем и операций, качество данных, модель прав, правила подтверждения, требования к среде, набор проверок, наблюдаемость и обработка сбоев. Сначала фиксируют контракт действия агента и архитектуру пилота; после этого можно оценивать реализацию и сопровождение.
Всегда ли бизнесу нужен именно AI-агент?
Нет. Если маршрут полностью известен, входные данные структурированы, а исключения выражаются правилами, обычный сценарий по правилам проще тестировать и контролировать. Иногда достаточно поиска по базе знаний или ассистента, который готовит черновик без внешнего действия. Хороший предпроектный разбор может закончиться рекомендацией не разрабатывать агента.
Спроектируем право на одно действие — до боевого подключения
Приходите с одним процессом, примером входных данных, списком систем и владельцем результата. На предпроектном разборе разложим действие на инструменты и области прав, определим правила подтверждения, запреты, набор проверок, журнал, лимиты и безопасную архитектуру пилота. На выходе останется контракт действия агента и список условий продолжения или остановки. Если задачу надёжнее решить сценарием по правилам или помощником без автономности, скажем об этом до большой разработки.