ИИ-агенты внутри ваших систем: что агент может делать сам, что должен одобрить человек и как начать, не потеряв контроль

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

Что такое ИИ-агент простыми словами?

Языковая модель — ИИ того же типа, что стоит за ChatGPT, — выдаёт текст. Агент — это языковая модель, подключённая к функциям в ваших системах, поэтому результатом её работы может быть не только ответ, но и действие.

Документация Anthropic по моделям Claude гласит: «Использование инструментов (tool use, также называемое function calling) позволяет Claude вызывать функции, которые определяете вы или которые предоставляет Anthropic». Для функций, которые определяете вы, модель «возвращает структурированный вызов, который выполняет ваше приложение». Она пишет запрос, а ваш софт выполняет его или отказывается выполнять. Все источники в этой статье открывались 2 ноября 2026 года.

Агент повторяет это в цикле. Он вызывает функцию, читает результат и выбирает следующий шаг, пока задача не будет выполнена. В посте 2024 года в инженерном блоге Anthropic агенты описаны как «обычно просто LLM, которые в цикле используют инструменты, опираясь на обратную связь от среды». LLM — сокращение от large language model, то есть большая языковая модель, а инструменты — это функции, которые она может вызывать.

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

Почему важно, читает агент данные или меняет их?

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

Запись меняет что-то за пределами модели: возврат выплачен или письмо дошло до клиента. Некоторые такие изменения нельзя отменить.

Руководство OpenAI по созданию агентов предлагает оценивать каждую функцию как функцию низкого, среднего или высокого риска «на основе таких факторов, как доступ только на чтение или на запись, обратимость, требуемые права учётной записи и финансовые последствия». Чтение остаётся низким риском только до тех пор, пока агент не может никуда отправить прочитанное. Почему — показывает раздел о prompt injection, уловке, при которой инструкции подбрасывают в письмо или документ.

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

Распределите все функции по трём группам:

• Агент самостоятельно: чтение данных, поиск по документам, проставление тегов и черновики, которые остаются внутри ваших систем, пока ими кто-нибудь не воспользуется
• Агент предлагает, человек одобряет: всё, что перемещает деньги, меняет запись или статус клиента либо отправляет сообщение за пределы компании
• Никогда: изменение прав доступа, лимитов или банковских реквизитов и решения, которые, по ожиданиям регулятора, должен принимать конкретный человек

Для большинства функций группу определяют четыре вопроса:

• Можно ли отменить действие и кто может это сделать?
• Перемещает ли функция деньги или меняет сумму, которую должен клиент?
• Увидит ли результат клиент, партнёр или регулятор?
• Требует ли закон, условие лицензии или ваша собственная политика, чтобы решение принимал человек?

Руководство OpenAI даёт тот же совет для средней группы: «Действия, которые являются чувствительными, необратимыми или связаны с высокими ставками, должны запускать человеческий контроль, пока не вырастет уверенность в надёжности агента». Среди его примеров — «отмена заказов пользователей, одобрение крупных возвратов или проведение платежей».

OWASP Top 10 for LLM Applications 2025 — список рисков, который публикует проект по безопасности OWASP, — содержит пункт excessive agency (избыточные полномочия). Он описывает ущерб, который может причинить агент, когда у него больше функций, прав или свободы, чем нужно для задачи. Одна из перечисленных в нём мер — «требовать, чтобы человек одобрял действия с серьёзными последствиями до их выполнения».

Как это выглядит в поддержке, онбординге, платежах и отчётности?

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

• Поддержка: агент проставляет теги тикетам и готовит черновики ответов. Поначалу человек одобряет каждый ответ, а возвраты и отмена комиссий всегда требуют одобрения. Агент никогда не меняет адрес электронной почты или номер телефона клиента, потому что тот, кто их контролирует, может сбросить данные для входа клиента
• Онбординг: агент проверяет документы на незаполненные поля и кратко излагает их для аналитика. Изменение уровня риска ждёт одобрения, а решение о приёме клиента остаётся за человеком
• Платежи: агент сопоставляет строки банковской выписки со счетами и помечает расхождения. Разблокировка задержанного платежа ждёт одобрения, а банковские реквизиты получателя агент не меняет никогда
• Отчётность: агент готовит черновик ежемесячного отчёта с источником каждой цифры. Всё, что отправляется клиенту, совету директоров или регулятору, одобряет человек

Где должен стоять шаг одобрения?

Встраивайте одобрение в софт, который выполняет функцию, а не только в промпт — набор инструкций, которые получает модель. Модель может проигнорировать строку в промпте, или её можно от этой строки отговорить. Функцию возврата, которая не запустится без клика проверяющего, ни от чего отговорить нельзя.

Рекомендации OWASP с этим согласны: «Реализуйте авторизацию в нижестоящих системах, а не полагайтесь на то, что LLM решит, разрешено действие или нет».

Полезный экран одобрения показывает проверяющему:

• Действие, запись, которую оно меняет, и сумма
• Запись до и после изменения
• Данные, на которые опирался агент, например тикет или строка выписки
• Обязательное указание причины каждый раз, когда проверяющий отклоняет предложение

Если каждое предложение одобряется за секунды, значит, люди перестали проверять. В Регламенте ЕС об ИИ (AI Act) для этого есть название — предвзятость автоматизации (automation bias). Его статья о человеческом надзоре говорит, что люди, надзирающие за системой высокого риска, должны иметь возможность сохранять понимание «возможной склонности автоматически полагаться или чрезмерно полагаться на результат». Каждую неделю перепроверяйте выборку одобренных действий.

Какие права должны быть у учётной записи агента?

Учётная запись агента должна разрешать функции из его списка и ничего больше. Дайте каждому агенту собственную учётную запись в каждой системе, с которой он работает, — никогда не учётную запись администратора и не логин сотрудника. Задавайте эти права в самой системе, где модель не может их изменить. Пароли и ключи остаются в вашем софте, вне поля зрения модели.

Пример OWASP — агент, который рекомендует товары и которому «может понадобиться только доступ на чтение к таблице „products“». OWASP также предостерегает от функций без чётких границ, например выполнения любой команды на сервере, и предпочитает узкие функции, каждая из которых делает что-то одно.

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

Что такое prompt injection и почему для агентов это важнее?

Prompt injection — это подбрасывание инструкций в текст, который читает агент, например в письмо, тикет или загруженный документ. Модель может выполнить их так, будто они пришли от вас. Инструкции можно спрятать от человека, который читает текст, а в случае агента они могут превратиться в действия. OWASP ставит prompt injection на первое место в своём списке 2025 года и говорит, что «неясно, существуют ли стопроцентно надёжные методы предотвращения prompt injection».

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

Меры OWASP начинаются с функции, которая может только читать почту, и доступа к почтовому ящику только на чтение. Кроме того, человек должен «вручную проверять каждое письмо, составленное LLM-расширением, и сам нажимать „отправить“». Поскольку prompt injection исключить нельзя, исходите из того, что агента обманут, и держите ущерб, который он может причинить, небольшим.

Что логировать и как отменить ошибочное действие?

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

OWASP отмечает, что логирование и лимиты частоты не предотвратят избыточные полномочия, «но могут ограничить масштаб причинённого ущерба». Лимит частоты ограничивает, сколько действий одного вида агент может выполнить за определённое время, поэтому серия ошибочных действий останавливается рано.

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

Требует ли закон одобрения человека?

В ЕС Регламент об ИИ (AI Act) устанавливает правила человеческого надзора за системами ИИ, которые он относит к системам высокого риска. Эти правила содержатся в статье 14, а приложение III перечисляет виды использования высокого риска. В этот перечень входят оценка кредитоспособности физических лиц и установление их кредитного рейтинга, хотя системы, выявляющие финансовое мошенничество, из него исключены. В него входят также оценка рисков и ценообразование для физических лиц в страховании жизни и здоровья. Служба AI Act Service Desk Европейской комиссии называет 2 декабря 2027 года датой, с которой применяются правила для систем высокого риска из приложения III. Эта дата отражает изменения, внесённые пакетом Digital Omnibus on AI. Такие даты могут сдвигаться, поэтому, прежде чем строить на них планы, проверьте актуальный график.

Статья 14 говорит, что меры надзора «должны быть соразмерны рискам, уровню автономности и контексту использования» системы. Люди, которые за ней надзирают, должны иметь возможность «в любой конкретной ситуации принять решение не использовать систему ИИ высокого риска или иным образом проигнорировать, переопределить или отменить её результат». Они также должны иметь возможность остановить её с помощью «кнопки „стоп“ или аналогичной процедуры».

Эти правила применяются только к системам высокого риска, перечисленным в Регламенте, и многие агенты в поддержке и операционной работе к ним не относятся. Для таких агентов те же меры контроля всё равно имеют смысл. Подпадает ли ваша система под эти правила — вопрос к вашим юристам. Эта статья — не юридическая консультация и рассматривает только правила ЕС.

Как начать, не потеряв контроль?

Начните с вопроса, нужен ли для задачи агент вообще. Инженерный пост Anthropic рекомендует «искать максимально простое решение и повышать сложность только при необходимости» и добавляет: «Это может означать, что агентные системы вообще не нужно строить». Для многих задач достаточно одного запроса к модели или фиксированной последовательности шагов. К тому же фиксированная последовательность ведёт себя предсказуемее, чем агент, который сам выбирает шаги.

Выберите один процесс с большим числом случаев в неделю, понятными правилами и ошибками, которые дёшево исправить, например сортировку тикетов поддержки и подготовку черновиков ответов. Затем двигайтесь поэтапно:

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

Заранее договоритесь, какие цифры переводят агента на следующий этап и кто принимает решение. Руководство OpenAI заканчивается словами: «Начинайте с малого, проверяйте на реальных пользователях и со временем расширяйте возможности». Пост Anthropic рекомендует «обширное тестирование в изолированных средах», то есть в копии ваших систем, где ошибки ничего не стоят.

Что проверить до запуска агента?

• Каждая функция относится к одной из трёх групп, и у неё есть конкретный ответственный на вашей стороне
• Кто-то попробовал выполнить запрещённое действие из учётной записи агента в каждой системе и убедился, что оно не прошло
• Тикеты и документы с подброшенными инструкциями прошли через агента, и ничего сверх того, что разрешают группы, не произошло
• По любому клиенту лог показывает, что сделал агент и кто это одобрил
• Новая версия модели запускается в работу только после повторного прогона тех же тестов

Кому принадлежат код, промпты и логи?

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

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

Что спросить у компании, которая будет это строить?

• Можем ли мы увидеть каждую функцию, которую будет вызывать агент, с указанием группы, к которой она относится?
• Где именно действует требование одобрения: в наших системах, в вашем коде или только в промпте?
• Какую учётную запись агент использует в каждой системе и как вы проверили, что он не может сделать больше?
• Как вы тестируете защиту от prompt injection и что происходит, если тестовая атака удалась?
• Сможет ли наша служба комплаенса читать лог без вашей помощи?
• Как отменяется каждое действие и как быстро можно отключить агента?
• Чем мы будем владеть в конце: кодом, промптами, описаниями функций, тестовыми сценариями и логами?

Где здесь место amBrain?

amBrain использует агентов в собственном продукте. Строка об этом продукте гласит: «Наш собственный продукт shyash.ai работает на ИИ-агентах, которые исследуют, пишут, проверяют и измеряют на основе единой общей памяти о фактах компании. Человек одобряет всё, что уходит наружу».

Единственный клиентский проект с языковой моделью, который amBrain описывает публично, таков: «Мы вывели интеграцию LLM в прод внутри FinTech-периметра клиента: извлечение и нормализация неструктурированных уведомлений брокеров и торговых площадок — о корпоративных действиях, изменениях по инструментам и марже — в структурированные записи, которые потребляет торговая система».

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

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

amBrain делает софт с 2019 года. Компания работает в трёх форматах: полная разработка, выделенная команда или инженеры внутри вашей команды. О владении у неё такая строка: «Клиент сохраняет полное владение продуктом и кодом, кроме наших переиспользуемых компонентов». Вопросы выше относятся к любой компании, которую вы рассматриваете.