Агент действительно способен собрать сведения из нескольких систем, сверить условия и подготовить следующий шаг. Одновременно он переносит ошибку модели внутрь рабочего контура. Длинной цепочке действий нужны технические запреты, подробный журнал и заранее проверенная аварийная остановка.
Что именно делает агент
Языковая модель отвечает на входной запрос. Помощник поддерживает диалог и может предложить действие. Обычная автоматизация следует заранее заданной последовательности. Агент отличается тем, что способен выбрать следующий шаг из разрешённого набора, вызвать инструмент, прочитать результат и продолжить задачу до заданной точки.
Например, помощник может написать черновик письма по вставленному тексту. Агент получает номер обращения, открывает карточку клиента, находит нужную инструкцию, формирует резюме и создаёт черновик ответа в очереди сотрудника. Если ему дополнительно разрешить нажать «Отправить», риск резко меняется, хотя интерфейс для пользователя выглядит почти так же.
Минимальная архитектура включает модель, список инструментов, состояние задачи, политику прав, журнал действий и контрольную точку человека. Память должна быть ограничена целью и сроком: бессрочное накопление всей переписки создаёт больше риска, чем пользы. Промпт объясняет желаемое поведение, но не является защитой. Запрещённое действие должно блокироваться правами или интерфейсом, даже если модель попросит его выполнить.
Права важнее интеллекта модели
Удобно разделить действия на три класса. Первый — чтение утверждённых источников и анализ без изменения данных. Второй — создание обратимого черновика, который явно помечен и попадает в рабочую очередь. Третий — внешнее или необратимое действие: отправка сообщения, изменение цены, удаление записи, платёж, публикация или решение, влияющее на человека.
Первый класс можно тестировать автоматически в ограниченном контуре. Второй требует понятного владельца и выборочной проверки. Третий для первого пилота должен подтверждаться человеком каждый раз. Даже позднее разрешение автономного действия оправдано только для узкого сценария с лимитами, журналом, восстановлением и доказанной частотой ошибок.
Создайте отдельную служебную учётную запись. Она получает доступ только к нужным папкам, таблицам и операциям, а не наследует права руководителя или администратора. Секреты хранятся вне промпта и выдаются конкретному инструменту во время вызова. Это уменьшает ущерб от ошибочного плана, утечки контекста или попытки использовать агент не по назначению.
Журнал должен позволять восстановить задачу без догадок: кто её запустил, какие источники были прочитаны, какие версии инструкций использованы, какие инструменты вызваны, что предложено, что изменено и кто подтвердил действие. Текстовый ответ модели без истории вызовов для производственного аудита недостаточен.
Как выбрать безопасный первый сценарий
Хороший сценарий имеет один тип входа, понятный результат и невысокую цену ошибки. Подходят ежедневное резюме статусов из утверждённых систем, классификация внутренних заявок, подготовка карточки задачи, поиск ответа в базе знаний и черновик сообщения сотруднику. Выход сначала не покидает внутреннюю очередь.
Представим агент для обработки заявок поставщиков. Он читает письмо и вложение, извлекает номер заказа, сверяет его со справочником, отмечает недостающие поля и создаёт черновик задачи. Сотрудник видит исходное письмо, найденную запись и объяснение каждого поля. Агент не меняет платёжные реквизиты и не отвечает поставщику самостоятельно.
До пилота команда собирает исторические примеры: обычные заявки, дубли, неверные номера, вложения плохого качества, смену языка и попытки передать новые банковские данные. Последний случай должен немедленно уходить специалисту, потому что цена ошибки слишком высока. Так тест проверяет не только среднее качество, но и способность остановиться на опасном входе.
Не подходят автономные платежи, изменение условий договора, блокировка пользователя, кадровый отбор и массовая коммуникация. В таких задачах недостаточно «попросить агента быть осторожным». Требуются отдельные правовые, процессные и технические меры, а иногда автоматизация решения вообще неуместна.
Как провести пилот и измерить результат
Начните с исторических задач в тестовой среде. Сравните результат агента с уже известным правильным исходом и сгруппируйте ошибки: неверный источник, пропущенное условие, лишнее действие, выдуманный факт, нарушение формата или попытка выйти за права. Только после исправления повторяющихся причин переходите в параллельный режим на новых задачах.
В параллельном режиме агент предлагает план и черновик, а сотрудник выполняет работу привычным способом. Это позволяет измерить полезность без внешнего риска. Если человек постоянно перепроверяет все источники с нуля, агент не снял работу, а лишь добавил новый объект контроля.
Считайте долю задач, принятых без правок, среднее число вмешательств, время полного цикла, стоимость одной принятой задачи и число выходов за границы. Критические ошибки учитываются отдельно: одна попытка отправить письмо неверному адресату важнее десятка стилистических правок. Для длинных цепочек полезно измерять, на каком шаге чаще всего требуется человек.
Пример расчёта должен включать всю работу. Если агент сокращает подготовку карточки с 12 до 3 минут, но проверка занимает ещё 6, экономия составляет 3 минуты. К ней добавляются стоимость вызовов, мониторинг и обслуживание интеграции. Высокая скорость интерфейса не равна снижению полной стоимости процесса.
Остановка, восстановление и изменения системы
Кнопка «остановить» должна отзывать активные ключи, прекращать новые вызовы и оставлять понятное состояние очереди. Команда заранее решает, что делать с частично созданными черновиками и незавершёнными изменениями. Если остановка существует только в презентации, её нельзя считать мерой контроля.
Проверьте восстановление до реального запуска: отключите учётную запись, имитируйте недоступность одного источника и верните задачу сотруднику. Агент должен явно сообщать о неполном результате, а не продолжать на догадках. После обновления модели, инструмента, промпта или базы знаний ключевую тестовую выборку запускают заново.
NIST AI RMF и профиль рисков генеративного ИИ помогают построить процесс управления, но не сертифицируют конкретного агента. EU AI Act использует риск-ориентированный подход, а точная применимость зависит от назначения, пользователей и контекста. Для кадровых, финансовых, биометрических и других чувствительных задач нужна профильная оценка.
Решение после пилота
Расширять права можно только по одному классу действий за раз. Сначала агент читает и готовит черновики, затем получает ограниченную обратимую операцию, например создание внутренней метки. После каждого изменения команда повторяет тест и наблюдает реальную эксплуатацию. Переход от «предложить» к «выполнить» не должен происходить автоматически из-за хорошего среднего показателя.
Если агент полезен лишь в части случаев, маршрутизируйте к нему только понятные входы. Неопределённые, конфликтующие и чувствительные задачи сразу передавайте человеку. Такой дизайн часто эффективнее попытки построить универсального цифрового сотрудника.
Красные флаги до запуска
Если агент работает из личной учётной записи сотрудника, видит больше данных, чем нужно задаче, или умеет отправлять сообщения без подтверждения, пилот уже начался с неправильной архитектуры. Ещё один тревожный признак — журнал, в котором сохранился только финальный текст. Без истории источников и вызовов невозможно понять, где возникла ошибка.
Отдельно проверьте аварийный сценарий. Кто отзывает ключ? Что произойдёт с незавершёнными задачами? Можно ли вернуть очередь человеку за несколько минут? Пока команда не ответила на эти вопросы действием, а не слайдом, агенту рано давать внешние права.
Практический порог прост: сначала агент читает и предлагает. Право выполнить даже небольшую операцию он получает позже, по одной операции за раз и только после повторного теста.
Источники
- AI Risk Management FrameworkNIST · проверено 20 июля 2026 г.
- Generative AI Profile NIST AI 600-1NIST · проверено 20 июля 2026 г.
- AI RMF CoreNIST AIRC · проверено 20 июля 2026 г.
- OECD AI PrinciplesOECD · проверено 20 июля 2026 г.
- Regulation (EU) 2024/1689 — AI ActEUR-Lex · проверено 20 июля 2026 г.
