# Совершенство против зрелости: как в 2026 году внедряют корпоративный ИИ > От автора. Я работаю с внедрениями корпоративного ИИ и имею отношение к платформе Ainergy, о которой пойдёт речь в последней трети текста. Пишу об этом сразу, чтобы дальше можно было читать спокойно и делить на нужный коэффициент. Все цифры в статье — из внешних источников со ссылками. --- Есть один разговор, который за последние полтора года случался почти в каждой компании крупнее тысячи человек. Выглядит он примерно так. Директор по ИТ приходит на правление с планом внедрения искусственного интеллекта. Слайды хорошие: дорожная карта, пилот в трёх подразделениях, бюджет на следующий год. На четвёртой минуте кто-то из коммерческого блока поднимает руку и говорит, что у них уже всё внедрено. Полгода как. Коммерческие предложения пишет нейросеть, договоры она же вычитывает, а на прошлой неделе с её помощью подготовили аналитику по конкурентам — очень, кстати, толковую. Дальше следует пауза, во время которой директор по ИТ проделывает в уме нехитрую арифметику. Через какой именно интерфейс, спрашивает он. Через обычный, отвечают ему. Через сайт. Вот этот момент — когда выясняется, что ИИ в компании давно работает, просто никто не знает где, — и есть настоящая точка отсчёта корпоративного ИИ в 2026 году. Всё остальное происходит после неё. ## Неприятная статистика, которая портит любую презентацию Начнём с цифры, которая летом 2025-го испортила настроение примерно всем. Исследовательская группа NANDA при MIT посмотрела на 300 публичных внедрений генеративного ИИ, провела полторы сотни интервью с руководителями и опросила 350 сотрудников. Вывод: 95% пилотов не дают измеримого эффекта в отчёте о прибылях и убытках (Fortune, август 2025). Здесь важна деталь, которую в пересказах обычно теряют. Причина провалов, по формулировке авторов, — не качество моделей. Модели отличные. Причина — разрыв в обучении: инструменты не умеют накапливать контекст конкретной компании, а организации не умеют перестраивать процессы под инструменты. Ещё одна деталь оттуда же: внедрения, где решение покупали у поставщика, оказывались успешными вдвое чаще, чем собственная разработка. 67% против 33%. Второй заход с другой стороны. IBM в отчёте о стоимости утечек данных за 2025 год приводит набор чисел, которые лучше читать сидя (пресс-релиз IBM, 30.07.2025): - 13% организаций сообщили об утечках, связанных с ИИ-моделями или приложениями. Ещё 8% честно ответили, что не знают, были у них такие утечки или нет. - Из тех, у кого утечка была, 97% не имели никакого контроля доступа к ИИ. Ни ролевой модели, ни журналирования, ничего. - Каждая пятая организация пострадала от утечки, связанной с теневым ИИ. Там, где теневого ИИ много, утечка обходилась в среднем на 670 тысяч долларов дороже. - Политику управления теневым ИИ имеют 37% компаний. Регулярный аудит неcанкционированных ИИ-инструментов проводят 34%. - 63% организаций либо не имеют политики управления ИИ вообще, либо как раз её разрабатывают. Формулировка «разрабатываем политику» в корпоративном фольклоре означает примерно то же, что «планируем начать бегать по утрам». И третий заход, уже с управленческой стороны. McKinsey в марте 2026 года опросил около пятисот организаций и обнаружил, что зрелого контроля над агентными системами достигли примерно 30%, а две трети называют вопросы безопасности главным препятствием для масштабирования (McKinsey, 25.03.2026). В более раннем их же замере получилось совсем изящно: ИИ хотя бы в одной функции используют 78% организаций, а зрелыми себя считает 1%. Сложите эти три сюжета. Инструменты работают. Сотрудники ими пользуются. Эффекта в отчётности нет, зато есть утечки. Российская картина, кстати, ту же логику подтверждает с другого конца: по данным сплошного статнаблюдения ИСИЭЗ ВШЭ, производственное применение ИИ есть примерно у каждой двадцатой крупной и средней организации, при том что рынок ИИ в стране за 2025 год вырос почти на 30% и дошёл до 316 миллиардов рублей. Деньги тратятся быстрее, чем внедряется. ## Почему совет «просто возьмите модель получше» не работает Соблазн понятен. Лучшие модели мира доступны по подписке за сумму, которая в бюджете крупной компании неотличима от нуля. Интерфейс осваивается за минуту. Качество — то самое, о котором пишут в новостях. Проблема в том, что при таком способе потребления компания получает результат, но не получает ничего из того, ради чего вообще затевается автоматизация. Знания текут наружу и не остаются внутри. Сотрудник за полгода выработал десяток отличных промптов, разобрался, как заставить модель писать нормальные технические задания, приноровился к её манере. Всё это живёт в его личном аккаунте и в его голове. Он уходит — уходит и это. Компания на протяжении полугода оплачивала обучение, результаты которого ей не принадлежат. В прошлом веке такое называлось «унёс наработки с собой», и с этим хотя бы боролись. Юридический контур в лучшем случае мутный. Персональные данные клиентов в промпте — это обработка персональных данных, причём с трансграничной передачей, если сервис зарубежный. Коммерческая тайна в промпте — это раскрытие сведений, составляющих коммерческую тайну, третьему лицу. Вопрос не в том, случится ли когда-нибудь проверка. Вопрос в том, сможете ли вы к ней предъявить хотя бы список того, что и куда уходило. У 97% пострадавших компаний из отчёта IBM такого списка не было. Управлять этим невозможно, потому что этого не видно. Нет журналов — нет расследования инцидента. Нет квот — нет предсказуемого счёта. Нет ролевой модели — значит, стажёр и финансовый директор имеют одинаковый доступ к одному и тому же инструменту, только один из них загружает туда учебные материалы, а второй — управленческую отчётность. Отдельно стоит сказать про версионность, потому что этот пункт обычно всплывает позже всех и больнее всех. Модель за облачным API обновляется тогда, когда решит поставщик. В понедельник ваш процесс классификации обращений работал с точностью 92%, во вторник поставщик выкатил новую версию, и стало 87%. Или 95%. Вы этого не узнаете, пока кто-нибудь не пожалуется. Воспроизвести прошлый результат вы тоже не сможете. Для маркетингового текста это неважно. Для процесса, где решение влияет на деньги или на человека, это дисквалифицирующее свойство. ## Ловушка совершенства Здесь мы подходим к теме, вынесенной в заголовок. Ловушка выглядит так: организация начинает выбирать модель. Сравнивает бенчмарки, читает лидерборды, спорит про контекстное окно, ждёт следующего релиза, потому что до него всего два месяца, а он обещает быть заметно лучше. Проходит квартал. Модели действительно стали лучше. Список кандидатов обновился полностью. Выбор начинается заново. Тем временем бизнес-процесс, ради которого всё затевалось, живёт своей жизнью и меняться не собирается. Согласование договора будет выглядеть примерно так же и через пять лет. Обработка входящего обращения — тоже. Горизонт жизни процесса измеряется годами, горизонт жизни конкретной модели — месяцами. Отсюда следует довольно простой архитектурный принцип, который почему-то приходится проговаривать вслух. Модель — расходный материал. Она встраивается в процесс, отрабатывает свой цикл и заменяется на следующую. Всё, что вокруг неё — база знаний, регламент, права доступа, интеграции, метрики качества, — живёт дольше и стоит дороже. Проектировать систему нужно вокруг долгоживущего, а привязываться к короткоживущему довольно опрометчиво. Зрелость в этом сюжете — это не смирение и не отказ от лучших моделей. Это способность поменять модель под капотом за неделю и не заметить этого на уровне процесса. ## Признаки зрелого внедрения Их четыре, и они проверяются вопросами, на которые можно ответить да или нет. Экономика применения известна до начала стройки. Не «внедрим ИИ и повысим эффективность», а «на этом участке мы обрабатываем 14 тысяч документов в месяц, тратим на это столько-то человеко-часов, автоматизация закроет такую-то долю, стоимость владения будет такой». Если этих чисел нет, обсуждать архитектуру рано. Знания накапливаются внутри и являются активом. Промпты, регламенты, размеченные примеры, база знаний, история удачных и неудачных решений — всё это лежит в контуре компании, версионируется и переживает увольнения. Контур управляем и аудируем. На любой запрос можно ответить, кто, когда, какую модель вызвал, что отправил и что получил. Не потому что кто-то параноик, а потому что без этого невозможны ни расследование инцидента, ни оптимизация затрат, ни разговор с регулятором. Модель заменяема. Смена базовой модели — это конфигурационная операция, а не проект на квартал. ## Начинать надо не с платформы Вот здесь я, как человек с очевидным коммерческим интересом, должен был бы написать «и поэтому вам нужна платформа». Но нет. Самая дорогая ошибка в корпоративном ИИ — не выбор неправильной технологии. Самая дорогая ошибка — построить хорошую, безопасную, аудируемую систему для процесса, автоматизация которого экономически бессмысленна. Такое случается регулярно и выглядит особенно обидно, потому что технически всё сделано прекрасно. Поэтому последовательность работ должна быть примерно обратной привычной. Сначала стратегирование. Инвентаризация процессов, где когнитивная работа занимает существенную долю: разбор документов, классификация обращений, подготовка типовых текстов, поиск по внутренним знаниям, контроль качества, первичный анализ данных. По каждому — объём в единицах и в часах, стоимость ошибки, требования к конфиденциальности. Получается длинный список, из которого две трети отпадёт. Потом серия открытых экспериментов. Открытых в двух смыслах: с открытым результатом и на открытых моделях, чтобы не платить за право проверить гипотезу. Формат, который обычно работает: шесть-восемь недель, десять-пятнадцать гипотез, по каждой быстрый прототип и честная метрика. Критерий продолжения жёсткий и один — снижение стоимости единицы результата при сопоставимом качестве. Не «сотрудникам понравилось». Не «выглядит перспективно». Стоимость обработки одного документа была столько-то, стала столько-то, качество проверено на отложенной выборке. Из десяти-пятнадцати гипотез выживают две-три. Это нормальный выход, и именно эти две-три оправдывают всё остальное. И только потом архитектура. Причём сразу в трёх слоях, потому что технический без остальных двух не взлетает: - техническая — где живут модели, как они вызываются, где хранятся знания, как это интегрировано с ERP, CRM и ITSM; - организационная — кто владелец процесса, кто отвечает за качество ответов, как устроен цикл улучшения, где живут промпты и регламенты; - юридическая — что можно отправлять в модель, что нельзя, как это технически ограничено, что попадает в журналы, как выполняются требования 152-ФЗ и внутренних режимов. Замечу, что регуляторный ландшафт в России в 2026 году складывается скорее в пользу тех, кто строит собственный контур. Мартовский федеральный закон о поддержке развития ИИ сократил число регулируемых категорий с двадцати одной до тринадцати и одновременно ввёл отдельные требования к высокорисковым системам. Логика законодателя читается: развивайте, но отвечайте за то, что развиваете. Отвечать удобнее за то, что стоит у вас. ## Из чего собирается технический слой Теперь про платформы — и да, дальше идёт та часть, ради которой я эту статью и пишу. Когда точки ценности найдены и экономика посчитана, техническая архитектура собирается из довольно понятного набора компонентов. Их удобно представлять тремя уровнями. Уровень инфраструктуры. Репозиторий моделей, их развёртывание и обновление, распределение вычислительных ресурсов. Здесь живут открытые модели, которые вы поставили в свой контур, — и здесь же решается вопрос, что делать, когда через полгода выйдет модель поинтереснее. Уровень управления потреблением. Самый недооценённый и самый полезный слой. Маршрутизация запросов между моделями (тяжёлая задача — большой модели, простая классификация — маленькой и в двадцать раз более дешёвой), ролевая модель доступа, квоты по подразделениям, журналирование всех обращений, фильтры безопасности. Отдельно — фильтр персональных данных, который перехватывает ПДн до того, как они уйдут в модель. Именно этого слоя не было у тех 97% компаний из отчёта IBM. Уровень потребления. То, с чем работает бизнес: векторные базы знаний с поиском по внутренним документам, ассистенты, специализированные агенты под конкретный процесс, интеллектуальные формы для разбора документов. Платформа Ainergy устроена ровно по этой трёхслойной схеме. Разворачивается в изолированном контуре на собственной инфраструктуре без выхода в интернет, в российском облаке для быстрого старта или в гибридном варианте. Есть готовый программно-аппаратный комплекс с серверами и ускорителями — вариант для тех, кому нужно закрыть вопрос целиком, включая железо. Что она делает содержательно: - Оркестрирует модели. Любые открытые модели в вашем контуре, маршрутизация между ними, замена без переписывания процессов. Свободный выбор моделей — здесь принципиальный пункт: платформа не привязывает вас к конкретному поставщику когнитивности. - Управляет потреблением. Доступы, квоты, логирование, фильтры соответствия, отдельный фильтр PII, интеграция с системами сбора журналов. То есть даёт ровно те артефакты, которые спросят и служба безопасности, и внутренний аудит. - Хранит и векторизует корпоративные знания. RAG поверх внутренних документов, с разграничением доступа: сотрудник получает ответ по тем документам, которые ему и так положено видеть. - Собирает агентов и ассистентов под процессы в логике low-code и no-code, с возможностью спуститься в pro-code там, где нужно. Это важнее, чем кажется: цикл «гипотеза — прототип — метрика» должен занимать дни, иначе описанная выше серия экспериментов растянется на год. - Интегрируется с тем, что уже стоит — ERP, CRM, ITSM, телефония — через открытый API. Типовые сценарии, которые собираются на этом быстрее всего: извлечение данных из документов произвольной сложности, разбор и классификация обращений в поддержку с автопополнением базы знаний, анализ разговоров с заполнением полей CRM, поиск проверенных ответов по внутренним знаниям, обработка встреч с постановкой задач, помощь разработчикам. Отдельно про лицензирование, потому что это редко обсуждают, а зря. Модель лицензирования Ainergy не привязана к объёму потребления. Разница с подписочной моделью проявляется на горизонте второго-третьего года: при почасовой или потокенной оплате успешное масштабирование удорожает эксплуатацию линейно, и в какой-то момент экономика внедрения начинает работать против вас. Здесь этого не происходит, и планировать бюджет можно на несколько лет вперёд. ## Что из этого получается в деньгах Ценность собственного контура складывается из четырёх слагаемых, и ни одно из них не сводится к «нейросеть пишет тексты». Заменяемость моделей. Стоимость перехода на следующее поколение падает с проектной до конфигурационной. Учитывая темп обновления моделей, за пять лет это происходит раз шесть. Знания как накапливаемый актив. Промпты, размеченные примеры, база знаний, история решений остаются в компании и с каждым месяцем работают лучше. Это ровно тот learning gap, который MIT назвал главной причиной провала пилотов. Аудируемость. Журналы всех обращений превращают ИИ из зоны неопределённости в обычную ИТ-систему, про которую можно ответить на вопрос проверяющего. Разница между «мы не знаем» и «вот выгрузка» — это и есть 670 тысяч долларов из отчёта IBM, в среднем по больнице. Скорость цикла. Возможность собрать прототип агента за дни определяет, сколько гипотез вы успеете проверить за квартал. А поскольку выживает примерно каждая пятая, пропускная способность воронки экспериментов прямо конвертируется в число работающих внедрений. ## Возвращаясь к тому совещанию Директор по ИТ из начала статьи в итоге сделал вещь, которая сначала выглядела странно. Вместо того чтобы запретить сотрудникам пользоваться внешними сервисами (запрет, как известно, приводит к тому, что люди начинают делать то же самое с личного телефона), он попросил всех, кто уже что-то освоил, за две недели описать свои сценарии. Получилось около сорока описаний. Из них восемь оказались процессами, где считалась внятная экономика. Три из восьми дошли до продуктива. Одно из трёх — разбор входящих документов — окупило годовой бюджет всей затеи. Мораль тут неожиданно оптимистичная. Теневой ИИ, который службы безопасности справедливо считают проблемой, одновременно является лучшим в мире бесплатным исследованием применимости. Сотрудники за свой счёт и в своё время уже проверили десятки гипотез и точно знают, где инструмент помогает, а где мешает. Остаётся выслушать их, посчитать деньги и построить контур, в котором всё это будет работать легально и накапливаться. Пять вопросов, на которые стоит уметь ответить прежде, чем покупать что бы то ни было: 1. Какие три процесса дают наибольший эффект, и сколько это в рублях за год? 1. Что происходит с вашими сценариями, когда через полгода вы меняете базовую модель? 1. Кто и как узнает, что качество ответов упало? 1. Где физически лежат ваши промпты, размеченные примеры и база знаний? 1. Что вы покажете проверяющему, если он спросит, какие персональные данные и куда уходили за последний квартал? Если на все пять есть ответы, платформа вам, вероятно, и правда нужна. Если ответов нет — начинайте с них, это дешевле. --- Материал подготовлен командой платформы Ainergy. Обсудить сценарии применения и посчитать экономику конкретного внедрения: ainergy.ru, info@ainergy.ru --- ## Примечания для размещения (не часть статьи) Объём. ~18 000 знаков с пробелами, около 9–10 минут чтения — верхняя граница комфортного лонгрида для Хабра и vc.ru. Маркировка и площадки. - Хабр — размещать только в корпоративном блоге компании. Публикация с явным коммерческим интересом из личного аккаунта без раскрытия нарушает правила и практически гарантированно ловится комментаторами. Дисклеймер в начале оставить, он снимает основные претензии. - vc.ru — раздел компании либо личный блог с указанием аффилиации. - Computerra — согласовать формат экспертной колонки, дисклеймер сохранить. - Требования к маркировке рекламы (ФЗ «О рекламе», регистрация креатива и передача данных в ЕРИР) применяются, если размещение оплачивается площадке. Согласовать с юристами до публикации — это делается один раз и закрывает риск. Что можно докрутить перед публикацией. - Заменить обобщённую историю из начала и конца на реальный обезличенный кейс с настоящими цифрами. Наличие живого кейса поднимает конверсию сильнее любых стилистических правок; сейчас там намеренно типовая ситуация без выдуманной конкретики. - Добавить одну схему трёхслойной архитектуры — на Хабре материалы со схемой читают заметно дольше. - Уточнить у продуктовой команды формулировки в разделе про Ainergy: описание собрано из публичных материалов, портал базы знаний закрыт от индексации и был недоступен. - Если нужен вариант под Computerra — там уместнее сместить акцент с архитектуры на регуляторную часть и сократить перечисление функций платформы примерно вдвое.