ИИ-агент вызывает API: кто и как проверяет бизнес-правила в 2026

Разбор новинки простыми словами: что это, кому нужно и брать ли.

Разработчикам и SMB-интеграторам агентов пора переносить контроль обязательных этапов из промпта в код: серверное состояние, политики и запись согласования, иначе агент обходит регламент.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Агент оформил подрядчика: создал карточку исполнителя, собрал договор, отправил на подпись. Три успешных ответа API, в логах чисто. И только потом выясняется, что по регламенту отправлять документ можно было лишь после проверки статуса контрагента. Агент шаг пропустил. Сервер не возразил.

Этот условный пример технический директор Workday Гейб Монрой разбирает в колонке для VentureBeat (перевод — в блоге SpeShu.AI). Сюжет не про то, что модель «ошиблась». Сюжет про то, что никто в архитектуре не был обязан её останавливать.

Проверка на диагноз занимает минуту, ещё до подключения агента: отправьте тот же запрос обычным API-клиентом. Если он проходит без обязательных этапов, проблема не в ИИ. Проблема в том, что вы называете регламентом, а система называет рекомендацией.

Что предлагают вместо доверия к промпту

Идея простая до обидного: контроль обязательного шага должен жить в коде, который исполняет вызов, а не в контексте модели, которая этот вызов придумала. Модель возвращает имя инструмента и аргументы. Исполняет его приложение. Вот на этой границе и ставят заслон.

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

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

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

Переданный агентом параметр checks_passed: true не годится в качестве доказательства. Сервису нужна запись в системе, которая отвечает за эту проверку.

Роли в схеме расходятся так:

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

Чем это отличается от того, как агентов собирали раньше

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

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

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

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

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

Кому это нужно и с чего начать

В первую очередь тем, кто уже выкатил агента в контур, где есть деньги, документы или доступы: подрядчики, счета, отгрузки, права в админке. Если агент пока только ищет информацию и готовит черновики, у вас есть время. Если у него есть кнопка «отправить», «подписать», «оплатить», время закончилось.

1. Выпишите обязательные этапы по одному процессу. Не «проверка контрагента», а «статус проверен и записан в такую-то систему с таким-то идентификатором».
2. Проверьте каждый вызов API обычным клиентом в обход агента. Прошло — значит правило живёт в промпте, а не в коде.
3. Перенесите проверку в сервис, который владеет объектом. Для договора — в сервис договоров, для платежа — в платёжный сервис.
4. Привяжите разрешение к версии объекта. Согласовали редакцию договора — отправлять можно только её.
5. Закройте альтернативные пути: массовые методы, админские ручки, скрипты поддержки.
6. Пишите в аудит основание решения: кто подтвердил, что именно, по какому объекту и с какими параметрами.

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

Где схема ломается

Разрешение стареет. Агент получил добро, сотрудник отозвал согласование, агент пошёл дальше по заранее составленному плану. Класс ошибок TOCTOU (CWE-367): состояние изменилось между проверкой и действием. Сократить паузу между ними проблему не снимает.

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

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

Один успешный ответ ещё ничего не значит. Успешный ответ API подтверждает только результат в пределах реализованных проверок, а не соблюдение всего регламента. Это предложение стоит повторить в чек-листе перед приёмкой любой агентской интеграции.

Брать или подождать: вердикт за 30 секунд

Брать, если у агента есть право менять статусы, отправлять документы или платить. Переносите проверки в сервер, привязывайте разрешения к версии объекта, закрывайте обходные ручки. Работать это будет и без ИИ, что и есть главный признак качества.

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

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

FAQ

Промпт совсем не нужен?

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

Мы маленькая компания, у нас нет службы политик

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

Чем это отличается от обычной проверки ролей?

Роль отвечает на вопрос «кому можно». Проверка состояния отвечает на вопрос «можно ли сейчас именно этот объект в именно этой версии». Для обязательных этапов нужны обе.

Что сделать на этой неделе

Возьмите одного агента и один процесс с реальными последствиями. Отправьте его ключевые вызовы вручную, в обход модели. Каждый вызов, который прошёл без обязательного этапа, — это место, где ваш регламент держится на вежливости. Дальше выбирайте: переносить проверку в сервис-владелец объекта или хотя бы убирать обходную ручку из доступа агента.