88% ИИ-пилотов не доходят до продакшена. Когда у модели появляются руки, начинается настоящая проблема

Подготовлено RD media

Представим обычную задачу для AI-агента: исправить баг в корпоративном приложении. Агент находит нужный файл, пишет исправление, запускает тесты — ошибка. Пробует ещё раз. Снова ошибка. Меняет подход. Запускает тесты. Ещё одна попытка.

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

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

Здесь проблема не в качестве промпта. Как только модель получает инструменты, память и право что-то менять в реальной системе, вокруг неё появляется отдельный инженерный слой. Его всё чаще называют harness.

От prompt engineering к agent engineering

За последние три года фокус индустрии заметно сместился. Сначала компании учились правильно формулировать запросы модели. Затем — правильно управлять контекстом: что дать модели, что сохранить, а что убрать.

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

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


Что такое harness

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

Удобная метафора: модель — двигатель, harness — автомобиль. Двигатель создаёт мощность. Но у двигателя самого по себе нет тормозов, руля, ремней безопасности и ограничителя скорости. С LLM примерно то же самое.

Модель может прекрасно сгенерировать команду для удаления файла. Но вопрос «имеет ли агент право её выполнить?» должен решаться другим уровнем системы.

Откуда взялись 88%

Здесь есть важная оговорка. Цифра 88% относится не к AI-агентам, а к корпоративным AI-пилотам в целом. IDC и Lenovo в исследовании 2025 года приводили оценку, согласно которой из 33 AI proof-of-concepts в среднем только четыре доходят до стадии production. Иными словами, примерно 88% не переходят от пилота к реальному внедрению.

Авторы сформулировали это очень точно: проблема не только в capability — возможностях технологии. Она в readiness — готовности организации. И это особенно важно для агентов. Потому что между «модель умеет это делать» и «модели можно разрешить это делать» лежит целый инженерный слой.

Семь вопросов, которые нужно задать агенту до production

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

1. Что агенту разрешено делать?

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

2. Кто проверяет результат?

Агент, который написал код, не обязательно должен сам решать, что код правильный. То же относится к аналитике, документам, SQL-запросам и инфраструктурным изменениям. Паттерн Maker–Checker здесь особенно полезен: один компонент выполняет работу, другой проверяет результат.

Причина проста: LLM-as-a-judge тоже может ошибаться и демонстрировать систематические bias. Исследование JudgeBiasBench, опубликованное в 2026 году, показало, что оценки LLM могут зависеть от нерелевантных характеристик ответа — например, его длины, позиции или стиля. Поэтому «агент сам себя проверил» — это не то же самое, что независимая верификация.

3. Что агент помнит?

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

Нужно понимать: что находится в текущем контексте, что хранится между шагами, что сохраняется между сессиями, что можно удалить, что нельзя потерять.

4. Что агенту запрещено?

Запрет не должен сводиться к фразе «не удалять production». Нужна техническая политика: какие файлы запрещены, какие API недоступны, какие базы данных только для чтения, какие команды никогда нельзя выполнять автоматически. Запрет должен существовать на уровне системы, а не только в тексте промпта. Потому что текст может содержать prompt injection.

5. Можно ли восстановить действия агента?

Если агент вызвал пять инструментов, изменил три объекта и получил ошибку — это должно быть видно. Логировать нужно не только финальный ответ, но и существенные действия: какой инструмент → с какими параметрами → с какими правами → какой результат → что произошло дальше. Без этого расследование инцидента превращается в попытку восстановить события по памяти.

6. Какая модель нужна для конкретной задачи?

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

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

7. Учится ли система на собственных ошибках?

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

Claude Code показал проблему на практике

Это не только теоретическая конструкция. В апреле 2026 года Anthropic опубликовала постмортем проблем с качеством Claude Code. При этом сама модель не была единственной причиной.

В течение нескольких недель качество ухудшалось из-за изменений именно в том слое, который находится вокруг модели. 4 марта команда снизила уровень reasoning с high до medium, чтобы уменьшить задержку интерфейса. 26 марта ошибка в механизме очистки кэша привела к тому, что история рассуждений удалялась на каждом шаге вместо предусмотренного более редкого интервала. 16 апреля изменение системного промпта, направленное на снижение избыточной детализации ответов, также повлияло на качество выполнения задач. Проблемы были исправлены к 20 апреля.

Модель была не единственной переменной. Изменения в обвязке меняли поведение конечного AI-продукта. И это, пожалуй, самый важный урок. При работе с Claude Code, ChatGPT или корпоративным агентом пользователь не взаимодействует с «чистой моделью». Он взаимодействует с системой.

Регулятор — не главная причина строить harness

Есть соблазн объяснять необходимость guardrails будущими штрафами. Но этот аргумент сейчас лучше использовать осторожно.

Например, в Колорадо первоначальный AI Act был отменён ещё до вступления в силу и заменён новым регулированием, которое начнёт действовать в 2027 году. В ЕС ситуация тоже сложнее, чем часто пишут в презентациях: разные требования AI Act начинают применяться в разные сроки, а отдельные обязательства для high-risk систем относятся к 2027 и 2028 годам.

Тезис о том, что «строить harness нужно из-за приближающегося регулирования», слишком упрощён. Есть причина гораздо проще. Если агент имеет доступ к банковским данным, персональным данным или production-инфраструктуре, контроль нужен независимо от даты следующего regulatory deadline. Регулятор может изменить дату. Право агента удалить вашу базу данных от этого безопаснее не становится.

Но harness тоже можно переинженерить

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

Безопасность должна соответствовать риску. Для агента, который сортирует внутренние документы, и агента, который меняет данные в production, не нужен одинаковый уровень контроля.

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

И вот здесь меняется главный вопрос

В эпоху чат-ботов мы спрашивали: «Какая модель умнее?»

В эпоху AI-агентов важнее понимать — какая система вокруг модели позволяет ей действовать безопасно, предсказуемо и экономически оправданно?

Модель важна, но она не является всей системой. Harness — это именно то, что делает доверие возможным. Поэтому переход от AI-пилота к production — это не выбор более умной модели. Это переход от model engineering к system engineering. Потому что дать агенту доступ к корпоративной базе — технически просто. Сложнее доказать, что ему действительно можно доверить этот доступ.

Источники:

• IDC / Lenovo — исследование корпоративного AI adoption и показатель 88% AI proof-of-concepts, не доходящих до production.

• Anthropic — постмортем проблем качества Claude Code, апрель 2026.

• Zhou et al. — JudgeBiasBench, исследование систематических bias LLM-as-a-judge, 2026.

• Colorado SB 26-189 — отмена и замена первоначального Colorado AI Act.

• European Commission — актуальные сроки применения EU AI Act.

REAL DIGITAL

#ИИ #AIAgents #AIEngineering #Кибербез #ЦифровойКазахстан