Почему бизнес не даёт ИИ-агентам делать что-то важное

По данным опроса разработчиков Stack Overflow за 2024 год, ИИ-инструментами в работе пользуется большинство участников, но доверие к их результату остаётся низким: значительная доля респондентов прямо говорит, что не доверяет точности выдачи. С агентами — программами, которые не просто отвечают, а сами совершают действия: пишут в базу, отправляют письма, вызывают API — разрыв ещё заметнее. Компания покупает агента, дающего экономию на рутине, и почти сразу окружает его согласованиями, при которых экономия исчезает. Разберём, из чего складывается это недоверие и что с ним делают на практике.

Чем агент отличается от чат-бота и почему это меняет ставки

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

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

Галлюцинации, которые становятся действиями

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

Непредсказуемость на длинной цепочке

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

Пять барьеров, которые называет сам бизнес

• Необратимость. Отправленное письмо клиенту или проведённый платёж не отменить. Действия делятся на обратимые и нет, и доверие к необратимым близко к нулю.
• Непрозрачность решения. Агент сделал X, но объяснить, почему именно X, часто нельзя воспроизводимо. Для аудита и разбора инцидентов это проблема.
• Ответственность. Если агент нарушил договор с контрагентом, отвечает компания, а не поставщик модели. Юридически риск целиком на бизнесе.
• Доступ к данным. Чтобы быть полезным, агент должен видеть почту, CRM, документы. Это же делает его лакомой мишенью и точкой утечки.
• Prompt injection. Вредоносная инструкция, спрятанная во входных данных — например, в тексте письма, которое агент читает, — может перехватить его поведение. Это относительно новый класс атак, для которого пока нет надёжной защиты.

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

Как компании выстраивают доверие постепенно

Практика сложилась вокруг идеи уровней автономии: агенту дают ровно столько власти, сколько подтверждено его поведением, и повышают планку по мере накопления статистики.

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

Практические приёмы, которые реально применяют

1. Разделить обратимое и необратимое. Обратимые действия (черновик, тег, заметка) отдают агенту сразу. Необратимые (платёж, отправка внешнему адресату, удаление) держат за подтверждением человека.
2. Ввести лимиты и пороги. Агент проводит платежи до определённой суммы автоматически, всё выше — на согласование. Так же с числом операций в час.
3. Логировать всё. Каждое действие агента — с входными данными и обоснованием — пишется в журнал, который можно поднять при разборе.
4. Ограничить права доступа. Агент получает не полный доступ к почте, а только к нужной папке; не всю CRM, а конкретные поля. Принцип минимальных привилегий работает и здесь.
5. Тестировать на теневом трафике. Агент неделями «принимает решения» параллельно людям, но его действия не исполняются — сравнивают расхождения, прежде чем дать реальные полномочия.

Где доверие уже отдают, а где нет

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

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

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