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

Первый серьёзный урок случился на выходных. Клиент попросил ИИ-агента разослать напоминание тем, кто не оплатил счёт. Агент так и сделал — только счёл «не оплатил» всех, у кого в карточке не стояла дата оплаты. Включая тех, кто платил наличными и у кого поле просто никто не заполнил. Ушёл понедельник на разгребание.

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

Почему одного системного промпта мало

Долгое время казалось: напиши в system prompt «не отправляй писем без подтверждения» — и всё будет хорошо. Не работает. Модель забывает, интерпретирует по-своему, обходит через инструмент. Особенно когда контекст длинный: за десять сообщений до этого клиент сказал «давай уже, отправляй, я тебе доверяю» — и агент решил, что запрет снят.

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

Что подсмотрели у Алисы и Claude Opus 5

В конце июля Anthropic выпустила Claude Opus 5, а до этого добавила в Claude write-инструменты для Microsoft 365 — черновики писем, календарь, OneDrive. Yandex запустил ИИ-агентов в Алисе: бронирование ресторанов, вызов такси, приём звонков. Разные продукты, но одна и та же архитектурная развилка: агенту дают выполнять действия, которые до этого делал только человек.

И вот тут интересно, как они это разруливают. ИИ-агент Claude в M365 сначала кладёт письмо в черновики, а не сразу в «исходящие». ИИ-агент Алисы для бронирования показывает пользователю карточку «давайте подтвердим» перед звонком в ресторан. Оба ставят между решением модели и внешним миром барьер, который снимает человек.

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

Правила, которые сейчас в кодексе

Их немного, но каждое стоит какого-то реального инцидента.

Действие с побочным эффектом требует human-in-the-loop. Читать может, писать — только через кнопку. Инструменты у нас поделены на два класса: read-only и mutation. Mutation в интерактивном режиме всегда сопровождается промежуточным ответом «готов сделать вот это, подтверждаете?».

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

Явный вызов лучше свободной формы. Модель, которой сказали «если нужно, позови функцию get_client_debt», позовёт её слишком широко. Модель, у которой инструмент требует обязательный параметр period_from и явный флаг include_pending — вынуждена думать конкретнее. Схема инструмента — тоже часть кодекса, а не только реализация.

Права наследуются от пользователя, а не от агента. Если менеджер не видит договоров другого филиала — агент, работающий от его имени, тоже не видит. Row Level Security на стороне базы, а не проверки в питоне. Про это у нас была отдельная история, повторяться не буду.

Каждое действие оставляет след. Что модель решила, какие инструменты позвала, что вернулось, что показали клиенту. Без этого разбор инцидента превращается в гадание.

MCP 2026-07-28 и авторизация как страховка

Двадцать восьмого июля вышла финальная спецификация Model Context Protocol версии 2026-07-28. Три вещи из неё легли на наш кодекс почти без переработки.

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

Второе — stateless core. Сервер больше не обязан помнить сессию агента между вызовами. С точки зрения кодекса это значит, что нельзя опираться на «мы же уже проверяли этого пользователя пять минут назад». Каждый вызов — самостоятельный, с полной проверкой прав. Раздражает при разработке, зато не даёт закрепиться дыре.

Третье — multi round-trip requests. Один логический вызов инструмента может потребовать нескольких обменов с клиентом: «нужно уточнение, задай пользователю такой-то вопрос». Раньше это приходилось эмулировать поверх стриминга. Теперь есть контракт, и правило «спроси перед действием» укладывается в него естественно.

Как поменялось использование ИИ-агентов у клиентов

Когда мы стали объяснять кодекс заказчикам, реакция была не всегда радостной. «Мы же для того и покупали, чтобы не подтверждать вручную». Понимаю. Но опыт показывает: без промежуточных подтверждений первые месяцы уходят на разгребание сюрпризов, а не на экономию времени.

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

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

Что в итоге

Правила кодекса — это не про недоверие к модели. Это про то, что рано или поздно модель ошибётся, а последствия останутся с клиентом. Хорошо спроектированный ИИ-агент — тот, у которого пространство для ошибки заранее ограничено инструментами и правами, а не только уговорами в промпте.

Каждый раз, когда мы сравниваем, как это устроено у публичных агентов вроде ИИ-агента Алисы или ИИ-агента Claude, находим для себя что-то полезное. Но перенимаем не архитектуру, а принципы. Использование ИИ-агентов в бизнесе начинается не с красивого сценария и не с выбора модели. Оно начинается с короткого документа, где написано, чего агент делать не будет никогда.

А какое правило вы бы добавили в свой кодекс первым?

Похожие статьи

• ИИ-агент для 1С под прицелом: чем атаки на автономных отличаются от атак на чат-бота
• ИИ-агент и ИИ-ассистент в разработке: где проходит граница, если ты сам делаешь ИИ-агентов для бизнеса
• Курс по ИИ-агентам для оператора: чему мы учим команду заказчика после запуска
• Один большой промпт превратился в систему ИИ-агентов: история, где мы перестали чинить и начали делить