VTB explicó por qué los pilotos de AI se atascan antes de llegar a producción y cómo la arquitectura puede corregirlo
En Data Fusion, VTB reconoció públicamente un problema conocido en el mercado: los pilotos de AI suelen funcionar en demos, pero fallan al escalar. El autor del

8–9 апреля на конференции Data Fusion ВТБ публично признал проблему, знакомую почти каждому корпоративному заказчику ИИ: пилоты выглядят убедительно, но до реального продакшена доезжают немногие. В центре разбора — не качество отдельной модели, а сама архитектура внедрения.
Почему пилоты ломаются
Ключевая мысль проста: пилот обычно проверяет один шаг в контролируемых условиях, а в производстве появляется целая цепочка действий, где ошибки накапливаются. Если восемь звеньев работают с точностью 85%, итоговая надёжность цепочки падает до 27%. На презентации такая система всё ещё выглядит «почти хорошей», но в реальном процессе три результата из четырёх оказываются неверными, и самое опасное — заранее неясно, какие именно.
Поэтому проблема проявляется не как разовый баг, а как системный распад качества при масштабировании. Из этого вытекает и более неприятный вывод: рынок часто оптимизирует ИИ не под точность, а под автономность. Метрика «какой процент задач выполнен без человека» удобна для маркетинга и отчётов, но она плохо показывает, насколько система остаётся связанной с реальностью на длинной дистанции.
В статье это связывают с automation bias и deskilling: люди всё чаще доверяют неверным подсказкам и одновременно теряют навык принимать решения без машины. В итоге компания получает не только хрупкий пайплайн, но и постепенную эрозию собственной экспертизы.
Архитектура с человеком
Вместо полной автономии предлагается низкоэнтропийная схема, где человек встроен в систему как обязательный элемент, а не как аварийная кнопка. Она делит работу на четыре уровня: от полевого оператора рядом с объектом до доменного эксперта, который проверяет рекомендации модели и возвращает корректировки обратно в обучение. Логика в том, чтобы «сбрасывать» неопределённость на каждом уровне, а не позволять ей бесконтрольно ползти вверх по цепочке.
- Уровень 0 — оператор или специалист на месте, который видит реальный объект и валидирует входные данные.
- Уровень 1 — узкие модели для конкретных сигналов: температуры, влажности, дефектов, снимков или других физических параметров.
- Уровень 2 — координатор, который собирает результаты моделей, рассуждает и формирует рекомендацию для человека.
- Уровень 3 — доменный эксперт, который подтверждает или исправляет вывод и тем самым даёт системе обучающий сигнал. В такой конструкции задача ИИ — не заменить специалиста, а увеличить его зону действия и производительность. Автор приводит пример цифрового двойника лесной экосистемы на площади более 180 тысяч гектаров: при росте охвата с 2 до 50 тысяч гектаров капитальные расходы выросли в 2,1 раза, операционные — в 2,2 раза, а команда увеличилась лишь с четырёх до восьми человек. При традиционном подходе, по оценке автора, потребовалось бы в разы больше полевых сотрудников.
Почему API недостаточно Отдельный тезис касается стека.
В статье утверждается, что такую схему трудно построить поверх публичных API одних только крупных моделей, потому что доменная экспертиза должна жить не в промптах и не только в RAG, а в весах локально контролируемой модели. Для этого предлагаются LoRA- или QLoRA-адаптеры, которые дообучаются на проверенных парах ответов и предпочтений экспертов. После рабочего дня логи проходят валидацию человеком, ночью запускается дообучение, а утром система выходит уже с обновлённым знанием домена.
«Промпт забывается в конце контекстного окна.
Адаптер — никогда». Эта логика делает ставку на собственную инфраструктуру. Ориентир по железу в материале — примерно 900 тысяч — 1,2 млн рублей: сервер с RTX 4090 или 5090 для координатора и ночного обучения, несколько Raspberry Pi для узких моделей на объекте и отдельное хранилище логов. Главный аргумент не в том, что облачные модели бесполезны, а в том, что их лучше использовать как внешний исследовательский инструмент, а не как слой принятия решений в критичном производственном контуре.
Что это значит
Для рынка это важный разворот: вопрос уже не в том, сколько людей можно убрать из процесса, а в том, как удержать качество при масштабировании ИИ. Если эта логика приживётся, корпоративные внедрения будут всё чаще строиться вокруг локальных моделей, постоянной верификации и человеко-машинных контуров, а не вокруг обещаний полной автономии.