Что показывает каталог из 1352 кейсов внедрения ИИ в России
В кейсах российских компаний, дошедших до продакшена и до измеримой цифры, качество модели почти никогда не оказывается решающим фактором. Решает обвязка вокруг неё: семантический слой, пороги уверенности, детерминированный код и человек на границе. Модель в такой системе не принимает решение, а оформляет его.
Обвязка - это всё, что стоит между вопросом пользователя и действием в системе. Семантический слой описывает метрики и измерения так, чтобы модель не выдумывала их сама. Пороги уверенности задают, где она продолжает работу, а где случай уходит на ручную проверку. Детерминированный код выполняет операции, результат которых нельзя «уточнить» языком: расчёты, запись в базу, выдачу прав. Человек на границе подтверждает критичные шаги. LLM хорошо работает с языком и плохо даёт гарантии, поэтому ответственность за решение отделяют от генерации.
База наблюдений - каталог кейсов внедрения искусственного интеллекта, который ведёт АНО «Цифровые платформы». В нём 1352 проекта российских компаний и госорганов, среди них антифрод Сбера и распознавание сорняков с дронов у «Русагро». Кейсы добавляют сами компании и команда каталога; подробности собраны в описании каталога.
Оговорка, без которой цифры дальше читаются неверно: все суммы называют сами компании, независимой проверки эффекта нет, а значительная часть внедрений - пока пилоты.
Почему модель не принимает решение, а оформляет его
Разница видна на простом контрасте. Систему просят оценить контрагента, и модель отвечает «скорее да, риски умеренные». Для бизнеса этот текст не значит ничего, пока рядом нет числа и правила: score выше 0,9 проходит автоматически, ниже 0,5 уходит в отказ, между порогами подключается человек. Модель сформулировала оценку, решение приняла арифметика и регламент.
Тот же принцип работает в любом процессе. Модель пишет текст письма, но отправляет его детерминированный сервис после проверки шаблона. Модель предлагает строку отчёта, но подставляет её конструктор запроса. Там, где нужна гарантия, языковая модель подходит плохо по своей природе: один и тот же вход даёт разные выходы. Гарантию даёт код вокруг.
Как читать цифры из каталога: что подтверждено, а что нет
Кейсы распадаются на три неравные группы. Первая - проекты с названным рублёвым эффектом: 270 млн рублей в год, 61 млн и 75 млн называют ЕвроХим, Нижнекамскнефтехим и ВТБ. Вторая - платформы с большим охватом и без раскрытой цифры, например система на 34 тысячи сотрудников. Третья и самая массовая - пилоты, где есть описание технологии и охвата, но нет измеримого результата.
Суммы из первой группы - заявления компаний. Независимого аудита этих цифр нет, методику расчёта компании раскрывают редко, а привязку отдельных сумм к конкретным организациям стоит сверять по их собственным публикациям. Сами проекты от этого не исчезают, но вес слова «подтверждено» меняется: подтверждено компанией, а не внешней проверкой.
Обвязка в реальных кейсах: как это выглядит в продакшене
Пять проектов ниже показывают не модели, а решения вокруг них. В каждом случае интересно, что именно вынесли из зоны ответственности LLM.
Первая Грузовая Компания: семантический слой вместо SQL от модели
ИИ-агент операционной аналитики отвечает логистам на вопросы про выгрузку вагонов и выполнение плана. Модель не пишет SQL: между ней и хранилищем стоит семантический слой с описанными метриками и измерениями, а параметризованный запрос собирает конструктор. У агента нет прав на запись, испортить данные он не может даже теоретически. Сводка по 150 объектам собирается за минуты вместо часа.
Модель здесь работает интерфейсом к семантическому слою, а не генератором запросов. Начни она писать SQL напрямую, ошибка в имени таблицы или соединении дала бы либо пустой отчёт, либо неверную цифру, которую никто не заметит.
Яндекс: робот-документатор витрин данных и вторая модель-проверяющий
Робот-документатор витрин данных на LLM описал 15 000 таблиц за полгода против 500 за предыдущий год. Дело не в модели: сначала робот собирает объективный контекст (схемы, глоссарий, связанные таблицы через граф), и LLM только дописывает описание поверх него. Вторая модель проверяет результат независимо. Итог - 92 процента семантического совпадения с проверкой человека и экономия около пяти человеко-лет аналитиков.
Схема «модель генерирует, вторая модель проверяет, человек ставит финальную оценку» даёт больше, чем переход на модель следующего поколения. Контекст и перекрёстная проверка закрывают там, где одна модель уверенно выдумывает.
Альфа-Банк: локальная Qwen 3.6-35B и детерминированные сервисы на Go
Автономный агент на локальной Qwen 3.6-35B стал предсказуемым после того, как всю детерминированную обработку данных вынесли в отдельные сервисы на Go, а модели оставили потребление готового результата. Локальная модель здесь выбрана осознанно: контроль над данными и воспроизводимость важнее пары дополнительных процентов на бенчмарке.
Тем, кто подбирает локальную модель под свой стек, пригодится разбор про Qwen, GLM и условия запуска в 2026 году: там про контекстное окно, KV-cache и стоимость инференса.
ДОМ.РФ: классический ML на классификации, LLM только для свободной формы
Платформа интеллектуальной обработки документов на LLM и RAG держит классический ML на классификации и извлечении сущностей, а LLM включает там, где нужен ответ в свободной форме. Гибридная архитектура снижает стоимость инференса и повышает предсказуемость: типовые поля разбирает обученный классификатор, языковая модель подключается к запросам, где жёсткая схема ломается.
X5: CV-модерация 10 млн фотоотчётов в месяц на 4 vCPU
Система CV-модерации фотоотчётов «Иваныч» проверяет 10 млн фотоотчётов в месяц из 27 тысяч магазинов «Пятёрочки» и «Перекрёстка». В сети из 27 тысяч магазинов 26 моделей обрабатывают 10 млн фото в месяц на 4 vCPU.
Цифра в 4 vCPU важнее названий моделей. Такой объём не вытянуть одной большой моделью: работает оркестрация 26 узкоспециализированных моделей и распределение нагрузки. Одна модель «на всё» здесь не прошла бы по ресурсам.
Общее у всех пяти кейсов одно: модель вынесена на периферию принятия решения. Где-то за это отвечает семантический слой, где-то вторая модель-проверяющий, где-то сервисы на Go или классический ML.
Граница надёжности агентных цепочек: что показал тест на 15 шагов
Понимание обвязки объясняет, почему длинные автономные агенты пока не держат продакшен. В тесте трём моделям, включая топовую облачную, дали задачу на 15 шагов. Из 27 запусков не было ни одного полного успеха. Хуже другое: все три модели рапортовали о завершении, которого не было (описание каталога).
Почему модели рапортуют о завершении, которого не было
Модель оптимизирует правдоподобие ответа, а не фактическое состояние задачи. Есть в контексте ожидание финала, она его сгенерирует и напишет «задача выполнена», даже если нужный шаг пропущен. Так ведёт себя любая LLM: у неё нет доступа к реальному состоянию процесса.
Родственная проблема - способность модели отличать тест от реальной работы, из-за которой метрики в карточках моделей завышаются. Расхождение между заявленным и фактическим поведением разобрано в материале про evaluation awareness и расхождение safety-баллов между бенчем и продом.
Защита от ложных отчётов одна: внешняя проверка состояния задачи вместо доверия тексту модели. Пока система не убедилась, что нужный артефакт создан, шаг не считается пройденным, каким бы уверенным ни был отчёт.
Практическое правило: шесть вызовов инструментов и человек на границе
Ориентир из разбора со ссылкой на VK Tech - надёжная работа примерно до шести последовательных вызовов инструментов. Независимого подтверждения конкретно этой оценки в доступных источниках нет, но она согласуется с результатом теста на 15 шагов: чем длиннее цепочка, тем выше шанс, что модель потеряет состояние и придумает финал.
Практический вывод: длинные задачи режут на короткие цепочки, между ними ставят проверки, критичные шаги оставляют человеку. Это не догма, а измеренная граница для текущего поколения моделей. Появляются агентные бенчмарки вроде The Struggle Bench, где агент должен выжить, оплачивая аренду и электричество, но такой тест проверяет один сценарий и не заменяет измерение своей задачи.
Кейсы с подтверждённым рублём и кейсы с большим охватом без цифры
Экономика внедрения делит проекты резко. С одной стороны ЕвроХим с 270 млн рублей в год с одного цеха, Нижнекамскнефтехим с 61 млн и ВТБ с 75 млн. С другой платформа на 34 тысячи сотрудников, которая пока не даёт ни одной цифры. В описании каталога один цех и 270 млн рублей в год упомянуты рядом, а платформа на 34 тысячи сотрудников оставлена без цифры (описание каталога).
Поправка на происхождение данных важна: суммы называют сами компании, независимого аудита нет, методику расчёта каждая выбирает сама. Сравнивать эти цифры между собой напрямую некорректно.
Почему один цех даёт 270 млн рублей, а платформа на 34 тысячи сотрудников - нет
В узкой задаче понятны метрика, граница ответственности модели и точка измерения эффекта. Экономия считается по конкретному процессу: расход реагента, время простоя, доля брака, стоимость часа сотрудника. В широкой платформе метрика размывается по десяткам процессов, и эффект не приписывается ни одному из них. Один цех даёт 270 млн рублей в год, потому что результат виден в цифрах производства, а не в числе пользователей.
Практическое правило: начинать с задачи, где эффект считается в рублях или в конкретной метрике процесса, и только потом расширять охват. Широкая платформа без узкого якоря рискует остаться набором функций, которые «все используют» и никто не измеряет.
Пилоты, которые не дошли до цифры: как их распознать
Признаки пилота без продакшена: нет раскрытой финансовой метрики, нет объёма обработанных операций, есть только описание технологии и охвата. Признаки продакшена: конкретная сумма, конкретный процесс, конкретный период. Разница видна в формулировках: «ассистент для 34 тысяч сотрудников» против «простои на линии сократились на N часов в месяц, это N млн рублей в год».
Значительная часть кейсов в каталоге - пока пилоты, и это нормальный этап. Ошибка начинается там, где пилот подают как результат: охват в тысячи пользователей сам по себе об эффекте не говорит.
Почему пилот на 100 инженерах в Авито не сдвинул метрики
Пилот ИИ-ассистента на 100 инженерах, о котором говорят в связи с Авито, не сдвинул ни одну метрику разработки. Привязку к компании стоит проверять по первоисточникам, но сам факт показателен. Вопрос не в том, плох ли ассистент, а в том, почему инструмент не превращается в результат автоматически.
Причин обычно три, и они складываются:
- ассистент встроен в процесс, который не перестроен под него: те же ревью, те же ожидания по срокам, та же очередь задач;
- нет метрик, которые он мог бы сдвинуть: скорость написания кода не влияет на время до релиза, если узкое место в согласованиях;
- нет обвязки, превращающей генерацию в проверяемый артефакт: код ассистента всё равно проходит ручную проверку, и экономии не возникает.
Узкая задача против широкой агентной разработки
Сравните два подхода. Узкая задача с измеримой метрикой (документирование витрин в Яндексе, модерация фото в X5) даёт видимый и атрибутируемый эффект. Широкая агентная разработка на 100 инженерах размывается по всему процессу, и вычленить вклад инструмента из общего результата почти невозможно.
Критерий выбора простой: у задачи должна быть метрика, которую можно измерить до и после, и граница, за которой модель не принимает решение. Если метрику назвать нельзя, измерять пока нечего.
Что спрашивать у вендора вместо «какая у вас модель»
Вопрос про модель на встрече с поставщиком почти ничего не решает: одну и ту же LLM можно завернуть в обвязку, которая даст продакшен, или в демо, которое рассыпется на второй неделе. Спрашивать стоит про обвязку. Помогает и отдельный навык - сравнивать новые модели без смены стека на каждый релиз.
Семь вопросов, которые отделяют продакшен от демо
- Как устроен семантический слой и кто его поддерживает? Просите описать метрики и измерения, а не таблицы. Если модель пишет SQL сама, уточните, что мешает ей выдать неверную цифру. Ориентир - Первая Грузовая Компания, где запрос собирает конструктор.
- Какие пороги уверенности и что происходит ниже порога? Нужен сценарий: куда уходит случай с низкой уверенностью и кто его разбирает.
- Есть ли человек на границе и на каких шагах? Автоматизация критичных действий без подтверждения - источник инцидентов.
- Как проверяется состояние задачи, а не отчёт модели? Просите показать, чем система отличает «модель написала, что готово» от «готово на самом деле». Это прямой урок теста на 15 шагов.
- Какова максимальная длина агентной цепочки в продакшене? Обещание десятков автономных шагов подкрепляйте измерениями; ориентир - около шести последовательных вызовов инструментов.
- Какие метрики эффекта и как они измеряются? Публичные лидерборды не отвечают, подойдёт ли модель под вашу задачу; про это отдельный материал о прикладном бенчмарке для честной оценки LLM. Вам нужны метрики процесса: время, ошибки, стоимость операции.
- Что происходит при сбое шага: откат, повтор, эскалация? Нужен описанный сценарий отказа, а не обещание, что всё заработает.
Практические выводы: как применять это в своём проекте
Последовательность, которая повторяется во всех разобранных кейсах:
- Выберите узкую задачу с метрикой, которую реально измерить до и после. Один цех с прозрачной экономикой полезнее платформы на всю компанию.
- Определите, где модель только оформляет решение, а где решает детерминированная система. Пороги, правила и расчёты держите в коде.
- Спроектируйте обвязку: семантический слой с описанными метриками, пороги уверенности, внешние проверки, человек на критичных шагах.
- Ограничьте длину агентных цепочек и поставьте контроль между шагами. Ложный отчёт о завершении опаснее явной ошибки.
- Измеряйте эффект в рублях или в метриках процесса: время, доля ошибок, простои, стоимость операции.
- Не путайте пилот с продакшеном. Охват в тысячи пользователей без раскрытой цифры - это ещё не результат.
И последняя оговорка, которую стоит держать в голове по всему тексту: данные каталога - заявления компаний, независимой проверки эффекта нет, а часть кейсов остаётся пилотами. Обвязка - это работа команды, а не покупка модели. Именно поэтому смена LLM на новую не решает задачу, если вокруг неё пусто.