Агент сдал экзамен.
К работе он не готов
К работе он не готов
Агент отлично прошёл тесты, вы запустили его в процесс – а через месяц процесс лихорадит: то операция проводится верно, то ошибается, и каждый сбой оборачивается инцидентом и потерей доверия команды. Это типовая ловушка 2026 года: высокий балл на тесте доказывает, что агент может решать задачу, но не гарантирует, что он будет делать это одинаково хорошо при каждом запуске в вашем процессе. А возврат инвестиций (ROI) и судьба пилота упираются именно во второе. Отдача от генеративного ИИ растёт (Omdia/Snowflake 2026: средний ROI – 49%), но многие агентные проекты не доживают до продакшена – и чаще всего их валит не слабая модель, а отсутствие проверки того, что агент ведёт процесс предсказуемо.
Почему мост в продакшен строится на проверке качества на ваших данных, а не на гонке за моделью?
По каким четырём признакам измерять готовность к продакшену?
Почему высокий балл на тесте и даже растущий ROI не гарантируют, что агент готов вести ваш процесс?
В этой статье:
Главная ценность – перестать принимать решения, опираясь на красивую цифру теста.
Способность – не надёжность
Тест отвечает на вопрос «может ли модель в принципе решить задачу». Прод задаёт другой: «решит ли она её одинаково каждый раз». Это не одно и то же – и исследование надёжности AI-агентов (arXiv, Towards a Science of AI Agent Reliability) показывает разрыв прямо: рост способностей почти не повышает надёжность, а на части задач надёжность с ростом тестового балла даже снижается. И это не беда одной лаборатории – за последние два года ведущие модели OpenAI, Google и Anthropic упёрлись в общее плато надёжности.
Как это выглядит на практике. Агент-помощник оператора верно классифицирует обращение и предлагает действие в девяти случаях из десяти на демонстрации, и именно десятый в проде уводит клиента не туда, оформляет не ту операцию, эскалирует не тому. Для демо достаточно «хотя бы раз». Для процесса, который идёт сотни раз в день, нужно «каждый раз», иначе агент – не помощник, а генератор инцидентов: чем выше его автономия, тем дороже каждый сбой.
Для технического читателя: это разрыв между pass@k (решил хотя бы раз за k попыток) и pass^k (решает верно во всех k попытках подряд); в том же исследовании корреляция точности и надёжности на бенчмарке GAIA – всего ≈0,46.
Как это выглядит на практике. Агент-помощник оператора верно классифицирует обращение и предлагает действие в девяти случаях из десяти на демонстрации, и именно десятый в проде уводит клиента не туда, оформляет не ту операцию, эскалирует не тому. Для демо достаточно «хотя бы раз». Для процесса, который идёт сотни раз в день, нужно «каждый раз», иначе агент – не помощник, а генератор инцидентов: чем выше его автономия, тем дороже каждый сбой.
Для технического читателя: это разрыв между pass@k (решил хотя бы раз за k попыток) и pass^k (решает верно во всех k попытках подряд); в том же исследовании корреляция точности и надёжности на бенчмарке GAIA – всего ≈0,46.
Почему рынок гонится не за тем
Если надёжность не растёт вместе с баллом, почему все обсуждают «чья модель умнее»? Потому что балл на тесте удобен: он публичный, сравнимый, его можно поставить на слайд и в пресс-релиз. А надёжность на вашем процессе невидима, требует работы и денег, и её не покажешь рынку. Вендоры оптимизируют то, что видно и продаётся, – бенчмарк; покупатели по той же причине выбирают «самую умную модель». Измерение собственной надёжности проигрывает в этой логике просто потому, что оно скучное и внутреннее.
Механика стимулов здесь проста. Балл на тесте виден: он попадает в пресс-релиз, в сравнительную таблицу закупки, в презентацию для совета директоров, и всё это конвертируется в контракты. Надёжность на вашем процессе не видна ни заказчику, ни рынку: её замечает только команда внедрения, и то обычно после инцидента. За неё платит только один участник цепочки – заказчик, и платит уже после запуска: инцидентами, ручными проверками, подорванным доверием команды.
Дальше замкнутый круг: закупка ориентируется на бенчмарк, критерии тендерного запроса (RFP) пишутся под то, что измеримо чужим тестом, и исполнителю рационально вкладываться именно туда. Каждый участник ведёт себя разумно, а суммой разумных решений становится агент, который блестит на тесте и лихорадит процесс.
Разорвать круг может только тот, кто за ненадёжность платит, то есть заказчик, и его рычаг лежит в закупке. Правило простое: смотреть надо не только на точность, но и на надёжность, при этом надёжность ставить подрядчику первым требованием. Показать точность на отдельном тесте, как показывает практика, дело нехитрое. Повторить результат на ваших сценариях десять раз подряд – уже нет. Сравнивать исполнителей стоит по второму, а не по первому: это меняет и выбор, и то, во что исполнителю рационально вкладываться.
На практике это укладывается в обычную дисциплину внедрения. Сначала MVP на заранее подготовленной выборке из 20–50 сценариев вашего процесса. Проверяется на ней не только точность, но и надёжность: те же сценарии проходят несколько прогонов подряд, а допустимый разброс между ними оговаривается заранее, а не «настраивается по ходу». Только после этого полноценная интеграция в процесс и смежные системы.
Отдельным пунктом стоит зафиксировать право остановиться: если MVP не оправдал ожиданий, проект не продолжают, и это нормальный исход, а не провал. Задача вне компетенции засчитывается агенту в плюс, только когда он отказался и передал её человеку: импровизация вне сценария считается провалом. Пороги, включая согласие модели-судьи с оценками людей, фиксируются до запуска, а сам набор задач растёт вместе с ценой ошибки: для процесса с регуляторными последствиями он кратно больше и живёт как актив, пополняясь разобранными инцидентами. Такая проверка дешевле любого пилота.
Цена подмены видна в цифрах. Capgemini называет корень проблемы: 52% руководителей не уверены, что вообще могут верифицировать вывод ИИ. И это бьёт по результату: связать ИИ с выручкой или снижением затрат удаётся меньшинству даже среди пилотов, дошедших до прода (Bain). Масса проектов измеряет способность («сработало на примере») и не измеряет ни надёжность, ни ценность, а потом удивляется, что эффект не доходит до финансового результата.
Механика стимулов здесь проста. Балл на тесте виден: он попадает в пресс-релиз, в сравнительную таблицу закупки, в презентацию для совета директоров, и всё это конвертируется в контракты. Надёжность на вашем процессе не видна ни заказчику, ни рынку: её замечает только команда внедрения, и то обычно после инцидента. За неё платит только один участник цепочки – заказчик, и платит уже после запуска: инцидентами, ручными проверками, подорванным доверием команды.
Дальше замкнутый круг: закупка ориентируется на бенчмарк, критерии тендерного запроса (RFP) пишутся под то, что измеримо чужим тестом, и исполнителю рационально вкладываться именно туда. Каждый участник ведёт себя разумно, а суммой разумных решений становится агент, который блестит на тесте и лихорадит процесс.
Разорвать круг может только тот, кто за ненадёжность платит, то есть заказчик, и его рычаг лежит в закупке. Правило простое: смотреть надо не только на точность, но и на надёжность, при этом надёжность ставить подрядчику первым требованием. Показать точность на отдельном тесте, как показывает практика, дело нехитрое. Повторить результат на ваших сценариях десять раз подряд – уже нет. Сравнивать исполнителей стоит по второму, а не по первому: это меняет и выбор, и то, во что исполнителю рационально вкладываться.
На практике это укладывается в обычную дисциплину внедрения. Сначала MVP на заранее подготовленной выборке из 20–50 сценариев вашего процесса. Проверяется на ней не только точность, но и надёжность: те же сценарии проходят несколько прогонов подряд, а допустимый разброс между ними оговаривается заранее, а не «настраивается по ходу». Только после этого полноценная интеграция в процесс и смежные системы.
Отдельным пунктом стоит зафиксировать право остановиться: если MVP не оправдал ожиданий, проект не продолжают, и это нормальный исход, а не провал. Задача вне компетенции засчитывается агенту в плюс, только когда он отказался и передал её человеку: импровизация вне сценария считается провалом. Пороги, включая согласие модели-судьи с оценками людей, фиксируются до запуска, а сам набор задач растёт вместе с ценой ошибки: для процесса с регуляторными последствиями он кратно больше и живёт как актив, пополняясь разобранными инцидентами. Такая проверка дешевле любого пилота.
Цена подмены видна в цифрах. Capgemini называет корень проблемы: 52% руководителей не уверены, что вообще могут верифицировать вывод ИИ. И это бьёт по результату: связать ИИ с выручкой или снижением затрат удаётся меньшинству даже среди пилотов, дошедших до прода (Bain). Масса проектов измеряет способность («сработало на примере») и не измеряет ни надёжность, ни ценность, а потом удивляется, что эффект не доходит до финансового результата.
Чем это оборачивается в проде
Цена ненадёжности зависит от контекста. Редкая ошибка терпима для черновика маркетингового письма и недопустима для промышленного кода, финансовой операции или медицинского решения. Малая доля сбоев звучит безобидно, пока это не тот самый платёж, не та заявка на кредит, не то направление к врачу. Бенчмарк усредняет – прод не прощает. Поэтому вопрос «какая модель самая умная» в корпоративной среде почти всегда менее важен, чем «как мы убедимся, что эта модель ведёт себя предсказуемо на нашем процессе, наших данных и ограничениях».
Дальше вопрос переходит в практическую плоскость: что именно измерять. Та же работа раскладывает надёжность на четыре метрики.
Дальше вопрос переходит в практическую плоскость: что именно измерять. Та же работа раскладывает надёжность на четыре метрики.
- Согласованность.Даёт ли система одинаковый результат на одинаковом входе, а не разный при перефразировании одного вопроса.
- Устойчивость.Держится ли качество на шуме и пограничных случаях, которых не было в демонстрации.
- Предсказуемость.Понятно ли заранее, где она сломается, или сбой всегда внезапен.
- Безопасность.Не делает ли недопустимого даже под давлением.
Это готовый каркас приёмки: вместо «нравится ли ответ» проверка по четырём осям, которую можно прописать в регламенте вывода агента в промышленную эксплуатацию и в контракте.
Путь в промышленную эксплуатацию строит проверка, а не модель
Отсюда практический вывод. Разрыв между «умеет на тесте» и «готов к проду» закрывается проверкой качества на вашей стороне – на ваших данных и сценариях. Приёма четыре, и каждый закрывает свою дыру.
- Модель-судья.Ответы агента оценивает отдельная модель по заданным критериям. По сути, это автотесты для нестрогого вывода: там, где обычный тест сравнивает результат с эталоном посимвольно, судья проверяет соответствие критерию. Ручное «нравится или нет» превращается в измеримую оценку, которую можно прогнать на тысячах случаев без просмотра глазами.01
- Пул моделей вместо одной.Задача идёт через несколько разных моделей, а результат сводит судья. Случайный провал одной гасится остальными, и общая надёжность растёт там, где одиночная модель упёрлась в плато.02
- Прогон на симуляциях и истории до прода.Поведение агента видно на сотнях прошлых случаев раньше, чем он коснётся живого клиента.03
- Постоянный мониторинг качества в эксплуатации.Он ловит дрейф, когда меняются данные, модель или поведение пользователей, и не даёт надёжности тихо просесть после запуска.04
У каждого из четырёх приёмов есть типовая ошибка внедрения, и у каждой ошибки – узнаваемый симптом. Поймать их на пилоте дешевле, чем разбирать последствия в проде.
Первая ошибка
Модель-судья без калибровки по людям. Судью запускают «из коробки», ни разу не сверив его оценки с решениями живых экспертов на одних и тех же кейсах. Симптом узнаваем: панель качества зелёная, а жалобы операторов и клиентов идут потоком – судья хвалит то, что человек бракует.
Отдельный случай той же ошибки – замкнутость на одного поставщика. Если оркестратор, судья и основные модели взяты у одного вендора, или судья принадлежит той же семье, что и оцениваемая модель, «независимая проверка» рискует оказаться фикцией: родственные модели разделяют слепые зоны и хвалят похожий на собственный стиль.
Вопрос закономерный: правда ли нельзя проверять модель родственной ей моделью. У нас есть собственный замер на этот счёт. Размечая задачи в другом проекте, мы прогнали одну выборку через модели трёх разных семейств и отдельно через одну и ту же модель дважды. Одна и та же модель согласилась сама с собой примерно в 73% случаев, а модели разных семейств между собой – только в 51–63%. То есть родственная проверка систематически показывает согласие выше настоящего: она измеряет не качество, а похожесть.
Отсюда рабочее правило, а не запрет: судья калибруется по людям и берётся из другого семейства, чем рабочая модель. Если так не получается, разрыв в согласии надо знать и держать в уме при чтении оценок.
Отдельный случай той же ошибки – замкнутость на одного поставщика. Если оркестратор, судья и основные модели взяты у одного вендора, или судья принадлежит той же семье, что и оцениваемая модель, «независимая проверка» рискует оказаться фикцией: родственные модели разделяют слепые зоны и хвалят похожий на собственный стиль.
Вопрос закономерный: правда ли нельзя проверять модель родственной ей моделью. У нас есть собственный замер на этот счёт. Размечая задачи в другом проекте, мы прогнали одну выборку через модели трёх разных семейств и отдельно через одну и ту же модель дважды. Одна и та же модель согласилась сама с собой примерно в 73% случаев, а модели разных семейств между собой – только в 51–63%. То есть родственная проверка систематически показывает согласие выше настоящего: она измеряет не качество, а похожесть.
Отсюда рабочее правило, а не запрет: судья калибруется по людям и берётся из другого семейства, чем рабочая модель. Если так не получается, разрыв в согласии надо знать и держать в уме при чтении оценок.
Вторая ошибка
Пул моделей с одинаковым профилем ошибок. В ансамбль собирают модели, обученные на схожих данных: они ошибаются на одних и тех же кейсах, и голосование лишь усиливает общий сбой. Три согласных голоса выглядят как независимая проверка, хотя это одна ошибка, повторённая трижды, и ложная уверенность здесь опаснее честного «не знаю».
Что с этим делать практически. Собирая пул, берите модели разных семейств и разных поставщиков, а затем измерьте, как часто они расходятся между собой. Слишком высокое согласие – не хорошая новость, а признак того, что ансамбль не добавляет проверки: вы платите за три мнения, получая одно. Ориентир из нашей практики: модели разных семейств на спорном материале расходятся в трети-половине случаев, и это нормально.
Что с этим делать практически. Собирая пул, берите модели разных семейств и разных поставщиков, а затем измерьте, как часто они расходятся между собой. Слишком высокое согласие – не хорошая новость, а признак того, что ансамбль не добавляет проверки: вы платите за три мнения, получая одно. Ориентир из нашей практики: модели разных семейств на спорном материале расходятся в трети-половине случаев, и это нормально.
Третья ошибка
Проверка на выходе без фиксации среды. Качество измеряют, не закрепив версию модели, запросы к ней (промпты), настройки и набор данных прогона. Симптом: повторный прогон на тех же кейсах даёт другие оценки, команда спорит о памяти вместо качества – результату, который не воспроизводится, нельзя верить.
Четвёртая ошибка
Порог эскалации без цены ошибки. Правило «когда передавать человеку» задают на глаз, не посчитав, во что обходится ложная тревога и во что – пропущенный сбой. Итог предсказуем: эскалируется либо всё подряд, и люди тонут в разборе, либо почти ничего, и первый серьёзный сбой доходит до клиента.
Общий знаменатель этих ошибок один: приём внедрён как формальность, без ответа на вопрос, какое решение он страхует и во что обходится его провал. Формальный приём создаёт худшее из состояний – уверенность в контроле, которого нет.
Почему это упирается в платформу. Всё описанное выше (калибровка судьи, пул разных моделей, прогон на истории, мониторинг в эксплуатации) держится на одном условии: эксперименты должны быть прозрачными и воспроизводимыми. Без этого каждый прогон становится разовым событием, о котором через месяц никто не вспомнит, а команда спорит о памяти вместо качества. Значит, нужна возможность измерять метрики постоянно, а не разово при закупке, логировать каждый запуск с версией модели, промптом и набором данных, и поднимать прошлый прогон, когда результат разошёлся с ожиданием. Организовать это на коленке можно, удержать при десятке агентов – нет: без такого слоя проект всегда рискует уйти не туда и потерять контроль незаметно для владельца. Как это устроено у нас, разберём отдельно: тема тянет на самостоятельный материал.
С чего начать
Заход не требует новой модели: нужны лишь точки, где дисциплина проверки окупится быстрее всего. Разумно начинать с одного процесса, где цена ошибки посчитана, а действие повторяется сотни раз в день: первичный разбор клиентской заявки подходит лучше, чем весь клиентский сервис разом.
Для такого процесса четыре признака надёжности превращаются в конкретную планку приёмки: одинаковая заявка ведёт к одинаковому решению; опечатки и нестандартные формулировки не ломают результат; заранее известно, на каких типах заявок агент пасует и передаёт человеку; операция выше лимита не подтверждается без проверки.
Дальше работает та же логика, что в закупке: агент проходит не один прогон, а сотни, на исторических заявках и в симуляции, – результат сверяется моделью-судьёй, и в прод выходит только то, что держит планку, под мониторингом, который ловит дрейф. Это дешевле одного публичного инцидента и честнее ставки на «самую умную модель»; решение о бюджете тогда опирается на пройденную планку, а не на красивое демо.
У состоявшейся приёмки есть материальный след: замороженный тестовый набор, на котором измеряли; версии модели и промптов на дату прогона; журнал, по которому решение о выводе в прод можно восстановить; правило отката с понятной ценой ошибки и ответственным за эскалацию. Если любого из этих следов нет, приёмка не состоялась, то перед вами не принятый агент, а черновик.
Для такого процесса четыре признака надёжности превращаются в конкретную планку приёмки: одинаковая заявка ведёт к одинаковому решению; опечатки и нестандартные формулировки не ломают результат; заранее известно, на каких типах заявок агент пасует и передаёт человеку; операция выше лимита не подтверждается без проверки.
Дальше работает та же логика, что в закупке: агент проходит не один прогон, а сотни, на исторических заявках и в симуляции, – результат сверяется моделью-судьёй, и в прод выходит только то, что держит планку, под мониторингом, который ловит дрейф. Это дешевле одного публичного инцидента и честнее ставки на «самую умную модель»; решение о бюджете тогда опирается на пройденную планку, а не на красивое демо.
У состоявшейся приёмки есть материальный след: замороженный тестовый набор, на котором измеряли; версии модели и промптов на дату прогона; журнал, по которому решение о выводе в прод можно восстановить; правило отката с понятной ценой ошибки и ответственным за эскалацию. Если любого из этих следов нет, приёмка не состоялась, то перед вами не принятый агент, а черновик.
Кто доходит до ROI, а кто нет
Соберём вместе то, с чего начали. Отдача от генеративного ИИ растёт, а значительная часть проектов не доходит до промышленной эксплуатации, и это два исхода одного и того же решения. Чтобы оказаться в первой группе, выбрать модель недостаточно: нужны процесс, порядок в данных и встроенная проверка качества.
Каждое из трёх условий проверяется одним вопросом.
Каждое из трёх условий проверяется одним вопросом.
- -1-ПроцессВыбран ли участок с измеримой ценой ошибки: разбор претензии, обработка заявки, сверка расчётов. Формулировка «внедрить ИИ вообще» таким участком не является.
- -2-Порядок в данныхВидит ли агент те же документы, регламенты и историю операций, что и человек на этой позиции, и с теми же правами доступа.
- -3-Встроенная проверкаИзмеряется ли качество на каждом релизе агента, как прогон тестов при сборке, или только один раз при закупке.
Ни один из трёх пунктов не требует новой модели: нужна дисциплина владельца процесса. Зато каждый пункт виден в бюджете и в регламенте: у процесса есть владелец и метрика, у данных – контур доступа, у проверки – место в цикле поставки. Средний возврат инвестиций 49% из отчёта Omdia для Snowflake – это температура по рынку; отдача концентрируется у тех, кто держит все три условия одновременно. Стоит убрать любое, и остаётся способный агент без процесса, процесс без данных или запуск без контроля, и ни один из этих вариантов до устойчивой отдачи не доживает.
Обратная сторона – закрытые пилоты: без понятной ценности, встроенного контроля качества и управляемого риска проект держится ровно до первого заметного инцидента. Что отделяет ROI от закрытого пилота – во многом способность измерять надёжность, а не балл на тесте.
Развилка портфеля агентных проектов проходит именно здесь. Отдача, та самая, что складывается в средние 49% по рынку, концентрируется у компаний, которые измеряют готовность собственной проверкой: по согласованности, устойчивости, предсказуемости и безопасности, на своих данных и задачах. Не потому, что их модели умнее, а потому, что решение о запуске у них опирается на поведение агента в собственном процессе – и такой результат воспроизводим от проекта к проекту. Ставка на чужой балл тоже иногда выигрывает, но повторить выигрыш не на чем: у него нет механизма. Путь, по которому отдача доходит до бизнеса, состоит из проверки, и прокладывать его разумно раньше, чем выбрана следующая модель.
Обратная сторона – закрытые пилоты: без понятной ценности, встроенного контроля качества и управляемого риска проект держится ровно до первого заметного инцидента. Что отделяет ROI от закрытого пилота – во многом способность измерять надёжность, а не балл на тесте.
Развилка портфеля агентных проектов проходит именно здесь. Отдача, та самая, что складывается в средние 49% по рынку, концентрируется у компаний, которые измеряют готовность собственной проверкой: по согласованности, устойчивости, предсказуемости и безопасности, на своих данных и задачах. Не потому, что их модели умнее, а потому, что решение о запуске у них опирается на поведение агента в собственном процессе – и такой результат воспроизводим от проекта к проекту. Ставка на чужой балл тоже иногда выигрывает, но повторить выигрыш не на чем: у него нет механизма. Путь, по которому отдача доходит до бизнеса, состоит из проверки, и прокладывать его разумно раньше, чем выбрана следующая модель.
Источники
– «Towards a Science of AI Agent Reliability», arXiv:2602.16666v3 [cs.AI], 2026. Четыре измерения надёжности; точность слабо предсказывает надёжность (на GAIA корреляция ≈ 0,46); плато надёжности длиной около 24 месяцев при растущих баллах на бенчмарках; различение pass@k и pass^k https://arxiv.org/abs/2602.16666
– «The ROI of Gen AI and Agents 2026», Snowflake, глобальное исследование; полевой этап выполнен Omdia by Informa TechTarget, 2 050 корпоративных специалистов, девять стран, шесть отраслей; публикация 10 марта 2026 года. Положительный возврат инвестиций подтверждают 92% ранних адоптеров, средний возврат 49%, активно используют агентов 19% https://www.snowflake.com/en/lp/radical-roi-generative-ai/
– «Executive Survey: AI Moves from Pilots to Production», Bain & Company, 24 ноября 2025 года. До промышленной эксплуатации доходят 40% пилотов, но лишь около 23% компаний связали ИИ с выручкой или затратами https://www.bain.com/insights/executive-survey-ai-moves-from-pilots-to-production/
– «Inside the C-Suite: How AI is quietly reshaping executive decisions», Capgemini Research Institute, январь 2026 года. Проверить вывод ИИ не могут 52% руководителей https://www.capgemini.com/wp-content/uploads/2026/01/Final-Web-Version-Research-Brief-Gen-AI-in-Decision-Making.pdf
– «The ROI of Gen AI and Agents 2026», Snowflake, глобальное исследование; полевой этап выполнен Omdia by Informa TechTarget, 2 050 корпоративных специалистов, девять стран, шесть отраслей; публикация 10 марта 2026 года. Положительный возврат инвестиций подтверждают 92% ранних адоптеров, средний возврат 49%, активно используют агентов 19% https://www.snowflake.com/en/lp/radical-roi-generative-ai/
– «Executive Survey: AI Moves from Pilots to Production», Bain & Company, 24 ноября 2025 года. До промышленной эксплуатации доходят 40% пилотов, но лишь около 23% компаний связали ИИ с выручкой или затратами https://www.bain.com/insights/executive-survey-ai-moves-from-pilots-to-production/
– «Inside the C-Suite: How AI is quietly reshaping executive decisions», Capgemini Research Institute, январь 2026 года. Проверить вывод ИИ не могут 52% руководителей https://www.capgemini.com/wp-content/uploads/2026/01/Final-Web-Version-Research-Brief-Gen-AI-in-Decision-Making.pdf
Другие новости