Почему ИИ нельзя внедрить как ERP, нельзя раздать как Office, и что тогда остаётся

1. Совещание в пятницу

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

Любой, кто пробовал развернуть модель у себя, знает, где предел, так что сенсации тут нет. Есть контракт.

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

Так в техническом задании на «внедрение системы искусственного интеллекта» появился один маленький пункт. Его вписали перед самым конкурсом, цену контракта не меняли. Аргумент был такой: ну это же просто, ИИ сейчас хорошо переводят.

ИИ действительно хорошо переводят. В облаке. Эти документы в облако отдавать нельзя. А то, что можно поставить в контур, переводит, как выяснилось, не сильно лучше ПРОМТа — и уж точно не так, чтобы пройти испытания, которые прописаны в том же ТЗ. Не пройдены испытания — не подписан акт. Не подписан акт по одному пункту — не закрыт контракт целиком, на десятки миллионов рублей. Дальше штраф и реальный шанс попасть в реестр недобросовестных поставщиков за пункт, который добавили «потому что просто».

Мы, честно говоря, довольно долго не понимали, как из этого выходить. К этому я вернусь в конце.

В двух предыдущих статьях я разбирал, что автоматизировать с помощью ИИ (https://habr.com/ru/articles/1079128/) и почему внедрения корпоративных систем идут по худшему сценарию (https://habr.com/ru/articles/1062146/). Эта — про третий вопрос, который стоит перед любой большой организацией и на который у неё нет готового ответа: как вообще вводить у себя ИИ. Сверху вниз, как ERP, или раздать на рабочие места, как когда‑то Office?

Короткий ответ: ни так, ни так. Длинный — ниже.

2. Две модели

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

Office даёт ценность на каждом рабочем месте отдельно. Один человек с Excel уже полезнее, чем он же без Excel, и ему не нужно, чтобы Excel был у соседа. Координация не требуется, поэтому и внедрения как проекта не было: ИТ поставили образ на все машины, а дальше каждый пользовался, как умел. Кто‑то писал макросы, кто‑то не выходил за пределы суммы по столбцу.

ИИ по единице ценности — Office. Аналитик с моделью полезнее аналитика без модели, и ему не нужно, чтобы модель была у соседа. Но закупают его как ERP, и на это есть три причины, каждая из которых по отдельности разумна.

Первая — безопасность. Модель нельзя купить как лицензию на рабочее место, если данные не должны покидать контур. Её нужно развернуть на своём железе, аттестовать, подключить к своим источникам. Это проект, а не поставка.

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

Третья — рынок. Вендору выгодно продавать платформу, потому что платформа — это контракт на сотни миллионов, а лицензия на рабочее место — нет. И вендор честно приносит платформу, а с ней ТЗ, дорожную карту и опытную эксплуатацию.

Три института толкают ИИ в ERP‑колею одновременно, и организация въезжает в неё не по глупости. Она въезжает в неё потому, что это единственная колея, которая у неё есть для слова «внедрение». Никто ведь не говорил «внедрить Excel».

3. Рассинхрон циклов

Теперь посмотрим, что происходит, когда по этой колее едут. Цикл внедрения корпоративной системы в большой организации выглядит так: инициатива и защита бюджета — от полугода до года; техническое задание и закупка, по 44-ФЗ, 223-ФЗ или по корпоративному регламенту, — ещё полгода; внедрение и опытная эксплуатация — год; перевод в промышленную — когда получится. Два года — оптимистичная оценка, три — нормальная. Я писал о проекте, который на третий год всё ещё придумывали, и он не был исключением.

Теперь то, что за это время происходит с моделями. ChatGPT вышел в ноябре 2022 года. Первая модель с режимом рассуждений, o1, — в сентябре 2024-го, через 22 месяца. Первые агенты, которые сами пишут, запускают и правят код, закрывая задачу из трекера целиком, — весна 2025-го, ещё полгода. Мультиагентные системы, в которых один агент планирует, другие исполняют, третий проверяет, — 2025–2026. От автодополнения строки кода до агента, которому отдают задачу и получают пул‑реквест, прошло около трёх лет, и каждый следующий шаг был короче предыдущего.

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

Возразят: 1С тоже обновляется, и ничего. Верно, и в этом разница. Ценность ERP от версии почти не зависит: учёт в 8.2 и в 8.3 ведётся одинаково. Ценность ИИ‑решения зависит от поколения модели радикально: задача, которая на прошлом поколении давала 80% релевантных ответов и считалась браком, на следующем проходит приёмку без изменений в постановке.

Хуже того: ТЗ фиксирует не только «что», но и «как». В частных технических заданиях, которые я читал в этом проекте, записана архитектура: векторное хранилище, нарезка документов на фрагменты, реранкер, ручной пайплайн проверки. Писали их в 2024-м. К 2026-му длинный контекст и агентный поиск делают половину этой архитектуры лишней. Но подрядчик обязан сдать то, что в ТЗ, а заказчик обязан это принять, потому что иначе контракт не закрывается. Обе стороны знают, что принимают вчерашнее. И тот пункт про перевод — из той же серии, только наоборот: там в ТЗ попало не вчерашнее, а завтрашнее, то, что модели умеют в облаке, но пока не умеют в контуре.

Формула: техническое задание на ИИ — это техническое задание на поколение модели, а поколение живёт год. Цикл внедрения — два‑три года. Рассинхрон не устраняется ускорением закупок: даже если ужать цикл вдвое, он останется длиннее поколения.

4. Что влезает в контур

Вернёмся к совещанию. Если ERP‑модель не работает из‑за рассинхрона, то, может быть, работает простая: поставить доверенную модель в контур один раз и дальше просто обновлять? Здесь и выясняется, что «просто обновлять» не получится, потому что в контур влезает не всё. Я проверил по открытым данным на сентябрь 2026 года; через полгода цифры будут другими, что само по себе часть аргумента.

Начнём с кода, потому что это самая требовательная задача, а потом вернёмся к переводу. Мерить будем по SWE‑bench Verified — тесту, где модель должна закрыть реальную задачу из реального репозитория.

Что	Модель	Что нужно, чтобы поставить у себя	SWE‑bench Verified
Закрытый фронтир (Anthropic, OpenAI)	—	Нельзя: только облако	88–96%
Лучшая открытая	DeepSeek V4-Pro, 1,6 трлн параметров	Кластер; авторы сами пишут «только облако»	80,6%
Большая открытая	GLM-5.2, 753 млрд	4 карты H200 в 4-битном сжатии, 8 для нормальной работы. Сервер с 8× H200 — около 57 млн ₽, с 8× H100 — около 26 млн ₽; аренда H100 в российских облаках — от 350 ₽/час за карту, 8 карт — порядка 2,5 млн ₽ в месяц	62% на более жёстком SWE‑bench Pro
Влезает в одну карту	Qwen3-Coder‑Next, Devstral 2	Одна карта на 96 ГБ (RTX PRO 6000), около 2,1 млн ₽, на одного разработчика	70–72%
Российская открытая	GigaChat 3.5 Ultra, 432 млрд	Нода из 8 карт по 80–96 ГБ — те же 14–57 млн ₽ в зависимости от карт	42,6% по собственным замерам Сбера

Источники по моделям: https://benchlm.ai/coding, https://www.digitalapplied.com/blog/best‑open‑weight‑coding‑models‑self‑host‑hardware‑match-2026, https://gpusmith.com/articles/en/glm-5-2-hardware‑requirements, https://digital‑razor.ru/media/news/software/sber‑gigachat‑ultra‑vram‑specs/. По ценам в рублях: прайс на серверы https://serverflow.ru/catalog/ai‑servers/gpu‑servery/8-gpu/ и на карту https://serverflow.ru/catalog/komplektuyushchie/videokarty/nvidia‑rtx‑pro-6000-blackwell‑workstation‑edition/, аренда по обзору российских GPU‑облаков https://ailist.ru/arenda‑gpu‑servera‑dlya‑nejrosetej‑v-rossii-2026/. Цифры разных строк получены на разных обвязках и в разное время, так что сравнивать их стоит с точностью до «сильно лучше — сильно хуже», не до процента, а цены — на момент написания.

Читается таблица так. То, что влезает в одну карту, отстаёт от фронтира примерно на год — это уровень закрытых лидеров прошлого лета. Это неплохо. Но одна карта — на одного разработчика, а на команду из пятидесяти нужна уже не карта. И заметьте масштаб: нода из восьми H200 стоит примерно столько же, сколько весь контракт, о котором шла речь в начале. Целиком, со всеми остальными пунктами ТЗ.

Теперь перевод, та самая задача из ТЗ. Она кажется проще, но выходит похоже. По WMT25, где качество оценивают люди, а не метрики, лучшая система — закрытая. Лучшая открытая, Qwen3.5 на 397 миллиардов параметров, отстаёт от закрытого лидера на треть, следующая открытая — вдвое. Данных отдельно по русскому языку в этих тестах нет, так что для нас это оценка сверху. А 397 миллиардов в четырёх битах — это 200 с лишним гигабайт, четыре карты по 80, то есть половина того самого сервера за 26 миллионов, ради перевода внутренних документов.

Но обратите внимание, что именно упирается в ресурсы. Не память — память для открытой модели среднего размера найти можно. Упирается режим работы. Простой перевод регламентного текста модель на одной карте сделает — примерно на уровне ПРОМТа с хорошо настроенным словарём, и ради этого менять систему незачем, испытания по ТЗ это не пройдёт. Заказчику нужен не перевод, а перевод, отредактированный и сверенный с глоссарием и принятой в ведомстве стилистикой, — то, ради чего он и хотел уйти с ПРОМТа. Это три‑пять проходов модели по тексту, с глоссарием и стайлгайдом в контексте, и токенов на один документ уходит в разы больше, чем на сам перевод. С кодом то же самое, только круче: агент с рассуждениями на одну задачу генерирует десятки тысяч токенов, мультиагентная система — кратно больше, и всё это на каждого пользователя одновременно. Карта, которая выдаёт двадцать токенов в секунду, потратит на такую задачу полчаса; облако решает её за три минуты, потому что там на ту же задачу работает не одна карта.

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

Из этого следует деление, но не то, которое напрашивается. Напрашивается делить по сложности задачи: простое — в контур, сложное — наружу. Граница по сложности движется каждый квартал, и делить по ней бессмысленно. Стоит на месте только одна граница — по классу данных. Получается матрица два на два: по одной оси данные, открытые или для служебного пользования, по другой задача, простая регулярная или агентная. Верхняя строка целиком — открытые данные и любая задача — уходит во внешнюю модель через шлюз. Нижняя левая клетка — закрытые данные и простая регулярная задача — модель в контуре, небольшая, на одной‑двух картах, а рядом с ней локальное хранилище внутренних документов, из которого нужные фрагменты подмешиваются в контекст, когда задаче нужен большой массив своей информации. Нижняя правая клетка — агентная задача целиком на закрытых данных — сегодня не закрывается ничем. Не закрытым контуром, потому что не хватит ресурсов, и не внешней моделью, потому что данные нельзя выносить. Честнее это признать, чем обещать, что «доверенная платформа» её закроет. Из этой клетки можно только выбраться — переформулировав задачу так, чтобы она попала в соседнюю. Как это выглядит на практике, покажу в конце на той самой задаче с переводом.

5. Снизу вверх — но что именно снизу

Если сверху не получается, остаётся снизу. Раздать разработчикам корпоративный ассистент для кода, аналитикам — чат с моделью, провести обучение. Это выглядит как модель Office, и здесь есть подвох, о котором стоит сказать прямо: Office не внедрялся снизу. Платформа была централизованной — один вендор, лицензии, образ на все машины. Индивидуальным было использование. Никто не устраивал анархию, но никто и не писал ТЗ на то, как бухгалтер будет пользоваться Excel.

Тогда вопрос: если платформа централизованная, а использование индивидуальное, что вообще меняется? С Excel произошло вот что: он изменил не инструмент, а границу ролей. Финансовые аналитики перестали ходить в ИТ за отчётом и стали строить модели сами. Никто не издавал об этом приказ. Просто в какой‑то момент выяснилось, что аналитик с Excel делает за день то, за что раньше ставил задачу отделу разработки на месяц, и отдел разработки перестали спрашивать.

С ИИ происходит то же самое, и единица изменения — та же: не инструмент на рабочем месте, а то, кто теперь имеет право произвести какой артефакт.

Возьмём разработчиков. Заставить их писать код через корпоративный ассистент нельзя, и дело даже не в мотивации. У сильного разработчика узкое место не в написании кода. Оно в чтении чужого легаси, в тестах, в миграциях, в документации, которую никто не хочет писать. Там модель ему полезна, и там он возьмёт её сам, если инструмент не хуже того, что он видел снаружи. Принудительное использование даст ровно то, что даёт любое принуждение в большой организации: отчёт «используем» на совещании и метрику «количество запросов к модели», за которой ничего не стоит. И ещё: ИИ сдвигает узкое место с написания кода на его проверку. Заставьте всех генерировать — вырастет очередь на ревью, а не выпуск.

Теперь аналитики, и это самая содержательная часть. В прошлой статье про внедрение я описывал совещание, где десять человек полтора часа обсуждали три поля в экранной форме, потому что до совещания в систему не заглянул никто. Дефект обошёлся в тридцать раз дороже, чем его исправление. Причина была не в людях, а в артефакте: заказчику показывали текст спецификации, а на текст ему нечего сказать. Форму он увидел через год.

Аналитик с моделью может собрать прототип. Не макет, а работающую форму с логикой, на тестовых данных, за день‑два. Функциональный заказчик смотрит на форму и реагирует сразу — так же, как реагировал на совещании, только на год раньше и без десяти человек. Утверждённый прототип идёт разработчику вместе со спецификацией. Вот это и есть изменение границы ролей: аналитик получает право принести код, а разработчик — право его выбросить.

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

6. Что остаётся

Соберём. Сверху вниз не работает из‑за рассинхрона циклов. Поставить всё в контур не получается из‑за ресурсов на агентный режим. Снизу вверх работает, но только если понимать, что снизу меняется не инструмент, а граница ролей. Что тогда делает организация, которая хочет «внедрить ИИ»?

Она делает четыре вещи, и ни одна из них не называется внедрением.

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

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

Третье — политики. Какие данные куда можно, какой артефакт кто имеет право принести, что считается приёмкой прототипа. Это документ на пять страниц, а не ТЗ на двести.

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

Всё это вместе — модель Office, доведённая до конца. Платформа централизованная: шлюз, хранилище, политики, память. Использование индивидуальное: аналитик делает прототип, разработчик решает, чем ему писать, переводчик сам решает, что отдать пайплайну. И ничего из этого не требует двухлетнего цикла, потому что ничего из этого не привязано к поколению модели.

Вернёмся к пункту ТЗ, с которого всё началось. «Перевести перевод внутренних документов с ПРОМТа на ИИ» — в такой формулировке задача не решается, и теперь понятно почему: она целиком сидит в пустой клетке. Конфиденциальные документы, а нужен не перевод, а редактура и сверка со стилистикой — агентный режим на закрытых данных. Ни контур, ни облако. И контракт на десятки миллионов зависит от клетки, которая пуста.

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

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

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

В логике ТЗ это провал: «система ИИ‑перевода» в том виде, в котором её вписали перед самым конкурсом, не внедрена. В логике матрицы это ответ: задача переформулирована так, чтобы попасть в клетку, которая закрывается. А испытания по тому же ТЗ идёт проходить пайплайн, а не модель, — и в этом вся разница.

Формула, которой я бы закончил: ИИ нельзя внедрить, его можно только легализовать. Организация не ставит систему. Она разрешает то, что сотрудники и так уже делают дома, и подставляет под это контур, в котором это можно делать с рабочими данными. Всё остальное — ERP‑колея, в которую организация съезжает по одному слову. Проверьте, есть ли это слово в вашем ТЗ.

Внедрить нельзя легализовать