От экспериментов к инфраструктуре: почему корпоративный ИИ требует платформы, а не набора инструментов

Александр Стародубцев, сооснователь корпорации ITG, — о том, почему точечные ИИ-решения и самостоятельная сборка на открытом коде не масштабируются, и как платформенный подход, на примере GenAI-платформ ^[1], позволяет перевести генеративный ИИ из разряда экспериментов в управляемую корпоративную инфраструктуру

Введение

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

Это хорошо видно по тому, как рынок развивался последние годы. ИИ действительно стал повсеместным, но масштабирование до устойчивого бизнес-эффекта остается узким горлышком: многие организации застревают между пилотами и промышленной эксплуатацией. Именно этот разрыв — «от пилота к масштабу» — McKinsey фиксирует как устойчивую проблему ^[2]: инструменты ИИ используются широко, но глубоко встроить их в процессы и получить материальный эффект на уровне компании удается далеко не всем.

Параллельно растет давление со стороны рисков и регулирования. Нужно не только «чтобы работало», но и чтобы было безопасно, объяснимо, наблюдаемо, управляемо по доступам и стоимости. В Европе, например, для систем ИИ высокого риска прямо закрепляются требования ^[3] к автоматическому журналированию и прослеживаемости. На стороне лучших практик появляются управленческие стандарты и рамки — NIST AI RMF ^[4] и профиль для генеративного ИИ, а также ISO/IEC 42001 как стандарт системы менеджмента ИИ.

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

Проблема первая: «зоопарк» точечных решений

Как это выглядит

Точечное решение — это отдельный ИИ-продукт под один сценарий или одну команду: 

• бот для подбора и адаптации персонала, 

• чат-бот для клиентской поддержки, 

• генератор маркетинговых текстов, 

• «помощник юриста» для работы с договорами, 

• встроенный помощник для разработчиков.

У каждого такого решения, как правило, свой вендор или контур, свой набор моделей и настроек, своя схема доступа, логирования и хранения данных, свой жизненный цикл изменений.

Почему это кажется удобным на старте

Точечные решения выигрывают по двум причинам: быстрое время до демонстрации (внутренний «вау-эффект» за 2–6 недель) и локальная оптимизация — каждое подразделение покупает то, что «болит у него» прямо сейчас. На уровне одного департамента это выглядит рационально. На уровне компании — это начало архитектурного долга.

К чему это приводит

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

Невозможность перенести успешные практики между отделами. Если служба поддержки нашла удачный набор промптов, систему оценок качества, метрики и защитные правила — HR не может просто «переиспользовать» это: другие контуры, другой инструмент, другая модель, другой способ журналирования. Возникает парадокс ^[5]: компания учится, но знания не тиражируются.

Отсутствие единого управления безопасностью, потреблением и логированием. Это главный риск для зрелой организации. В мире генеративного ИИ речь идет не только о классической информационной безопасности, но и о специфических угрозах: внедрение вредоносных инструкций через промпт, утечки контекста, неконтролируемые интеграции с внешними данными и инструментами. Исследования показывают ^[6], что уязвимости и сценарии атак через промпт масштабируются на самые разные приложения и домены, а успешные атаки могут приводить к утечкам и несанкционированным действиям. С точки зрения ^[7] управления, Gartner описывает ^[8] направление AI TRiSM (Trust, Risk, Security Management) как набор практик и технологий для управления доверенностью, рисками, безопасностью и контролем ИИ-развертываний — то есть, по сути, как «надстройку управления» над ИИ в масштабе предприятия.

Нестандартизированные процессы на уровне компании. Когда ИИ внедряется точечно, компания не формирует единый «скелет» процессов: как выбирать модель и где она разрешена, как классифицировать данные и что нельзя отправлять во внешние API, как проводить оценку качества и рисков, как расследовать инциденты, как считать экономику. В результате масштабирование стопорится не на «умности моделей», а на управляемости.

Проблема вторая: решения с открытым кодом — хороши для прототипов, опасны в промышленной эксплуатации

Сразу важная оговорка: открытый код сам по себе не «плох». Многие критически важные компоненты современной ИТ-инфраструктуры — это проекты с открытым кодом. Риск возникает, когда организация воспринимает его как «бесплатную платформу без последствий», особенно в ландшафте генеративного ИИ, где скорость изменений и поверхность атак выше обычного.

Почему открытый код привлекателен на этапе пилота

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

Скрытые издержки при масштабировании

Отклонение от основной ветки. Как только компания начинает «допиливать под себя» — появляются изменения, которые не входят в основной проект. Дальше приходится выбирать: внести доработки в основной проект (сложно организационно, но стратегически полезно) или поддерживать собственную ветку, которая становится внутренней «платформой-одиночкой». Linux Foundation описывает ^[9] эту развилку как ключевое решение, отмечая, что частная поддержка несет реальные долгосрочные издержки. Эмпирические исследования показывают ^[10], что в экосистемах формируются целые «семейства» расходящихся вариантов, и практики сопровождения таких ветвящихся семейств становятся отдельной сложной задачей.

Растущие затраты на доработку и сопровождение. Даже без отклонения от основной ветки ИИ-системы склонны накапливать скрытый технический долг. Классическая работа Google ^[11] (Sculley и др.) показывает, что быстрые победы машинного обучения ^[12] часто создают долг в виде связностей, зависимостей и вспомогательных компонентов, а итоговая стоимость сопровождения может стать «массовой и постоянной». В генеративном ИИ этот эффект усиливается: меняются модели, токенизация и цены, контекстные окна, политики безопасности, появляются новые типы атак — и «просто обновить библиотеку» становится нетривиальной задачей.

Снижение стабильности системы. В промышленной эксплуатации важны SLA, регрессионные тесты, наблюдаемость, повторяемость поведения ^[13]. Стек на открытом коде в пилоте обычно живет без строгих оценок качества на репрезентативных данных, без формализованных «красных линий» безопасности и без дисциплинированного управления изменениями. В результате «оно работало на демо» превращается в «оно ведет себя иначе на реальных данных».

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

Безопасность цепочки поставок и уязвимости библиотек. Открытый код требует дисциплины в части безопасности цепочки поставок: ведение реестра компонентов (SBOM), контроль зависимостей, безопасная сборка, мониторинг уязвимостей. NIST в рамках SSDF фиксирует ^[14] необходимость внедрения практик безопасной разработки как универсальный минимум. Отчеты по цепочке поставок ^[15] показывают рост угроз и вредоносных пакетов в популярных экосистемах, что делает управление зависимостями не факультативом, а обязанностью.

Для экосистемы больших языковых моделей характерно и то, что уязвимости могут быть «логическими»: например, CVE-2024-8309 описывает случай ^[16], где внедрение вредоносных инструкций через промпт в компоненте LangChain приводило к SQL-инъекции. Это не аргумент не использовать открытый код, но в промышленной эксплуатации он требует платформенной дисциплины, иначе риск и стоимость растут нелинейно.

Решение: платформенный подход

Платформа для корпоративного ИИ ^[17] — это единый слой инфраструктуры и управления, который позволяет разным командам быстро собирать ИИ-сценарии, но при этом использовать общие политики безопасности и доступа, иметь единое журналирование и прослеживаемость, управлять стоимостью и лимитами, тиражировать практики и компоненты, обновляться без «ломки» существующих доработок.

Интуитивно это похоже на то, как компании в свое время переходили от разрозненных скриптов к DevOps-платформам, от «серверов под проект» к облачной платформе и FinOps, от ручных прав доступа к централизованному управлению учетными записями и единому входу (IAM/SSO).

С точки зрения крупных консалтинговых подходов это тоже укладывается в «платформенную логику»: BCG описывает ^[18] платформенную операционную модель как переход к общим, переиспользуемым возможностям уровня предприятия, которые ускоряют и удешевляют создание ценности в разных бизнес-подразделениях. А в свежих материалах BCG ^[19] про масштабирование ИИ подчеркивается идея агентной платформы как общего слоя — память ^[20], оркестрация, реестры инструментов, управление — поверх которого строятся конкретные продукты и агенты.

Когда платформенный подход оправдан

Платформенный подход почти всегда оправдан, если у компании есть хотя бы три из семи условий: 

1. больше 3–5 подразделений хотят внедрять генеративный ИИ параллельно; 

2. есть чувствительные данные или регуляторные требования; 

3. нужны единые политики доступа и аудит; 

4. ожидается рост расходов на токены и вычислительные ресурсы, и нужно распределение затрат; 

5. есть риск теневого использования ИИ; 

6. нужны агенты и интеграции с корпоративными системами (а значит — управляемые инструменты и вызовы); 

7. компания планирует обновлять модели и провайдеров без больших проектов.

Гибкость и масштаб

Хорошая корпоративная платформа должна закрывать два типа задач одновременно. Первый — типовые сценарии, где важны скорость и стандартизация: корпоративный чат и поиск по базе знаний (RAG), резюме встреч и переписки, генерация черновиков документов, ассистенты для службы поддержки, помощники для разработчиков. Второй — специфические сценарии, где важна интеграция и управляемость: процессы с регламентами и согласованиями, сценарии с чувствительными данными, системы в «серой» регуляторной зоне, агентные сценарии с инструментами, где модель может инициировать действия.

Практически это означает модульную архитектуру: шлюз моделей и маршрутизация (какая модель, где, на каких данных, какие лимиты), коннекторы к данным с разграничением доступа, оценка качества, тесты и мониторинг, библиотека компонентов (промпты, шаблоны, политики, защитные правила), оркестрация рабочих ^[21] процессов и агентов с контролируемыми инструментами.

Здесь полезно вспомнить выводы практик MLOps: реальная сложность — не «обучить модель», а построить воспроизводимую систему поставки, развертывания и мониторинга. Google в материалах по MLOps ^[22] описывает уровни зрелости и подчеркивает необходимость непрерывной интеграции, доставки и дообучения, а также автоматизации конвейеров для надежной эксплуатации ML/AI в промышленной среде.

Обновления без боли

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

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

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

Централизованное управление безопасностью

Это пункт, где платформенный подход дает максимальную совокупную выгоду, потому что безопасность в генеративном ИИ — это одновременно:

• безопасность данных, 

• безопасность действий (инструменты и вызовы), 

• безопасность цепочки поставок, 

• контроль доступа и аудит, 

• мониторинг нежелательных выходов и инцидентов.

Единый контроль доступа. Платформа должна интегрироваться с корпоративной системой управления учетными записями (SSO, ролевая и атрибутивная модели доступа), чтобы сотрудники видели только разрешенные данные и функции, доступ к моделям и инструментам был управляемым, а роли и политики — едиными.

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

Полное журналирование и прослеживаемость действий нейросетей. Это уже не опция, а необходимость. В регулировании это становится прямым требованием: EU AI Act ^[3] для систем высокого риска закрепляет необходимость автоматического журналирования событий на протяжении жизненного цикла, чтобы обеспечивать прослеживаемость и мониторинг после вывода на рынок. Со стороны управления рисками NIST AI RMF ^[4] и профиль для генеративного ИИ описывают практики по всему жизненному циклу, где наблюдаемость и контроль — базовые элементы.

Быстрое расследование инцидентов. Платформа должна давать расследованию то, что обычно нужно информационной безопасности и подразделению комплаенса: кто и когда сделал запрос, какой контекст и данные использовались, какая модель отвечала и с какими настройками, какие инструменты и интеграции были вызваны, какие политики сработали (разрешение, запрет, маскирование).

Отдельно полезно, что крупные корпоративные поставщики добавляют инструменты ^[23] соответствия требованиям и аудита — например, API и интеграции для электронного раскрытия информации, предотвращения утечек данных и аудита рабочих пространств.

Управление потреблением и эффективностью

ИИ в масштабе компании быстро упирается в вопрос: кто и сколько сжигает ресурсов — и какой эффект это дает.

В генеративном ИИ экономика часто выражается в токенах (а также профилях вычислительных ресурсов для вывода, извлечении данных, агентных циклах). Поэтому платформа должна обеспечивать лимиты и квоты (на пользователя, команду, сценарий), распределение затрат по подразделениям, а также аналитику «стоимость → результат» — например, стоимость решения одного обращения, стоимость обработки документа, стоимость привлечения потенциального клиента.

В практике управления ИТ-затратами это нормальная зрелость: распределение затрат — отдельная способность, которую нужно согласовать с финансовыми моделями и центрами затрат. Для генеративного ИИ появляется дополнительная специфика: единица потребления — токены, и именно это подчеркивается в материалах по управлению затратами ^[24] на Azure OpenAI: нужны механизмы видимости, распределения и расчета удельной экономики в терминах токенов.

Тиражирование лучших практик

Платформа превращает опыт ^[25] отдельных команд в актив компании через общие артефакты: библиотеки промптов и шаблонов с версионированием и владельцами, стандартизированные защитные правила (маскирование, фильтры безопасности, проверки на соответствие политикам), единые подходы к оценке качества (метрики, тестовые наборы, регрессионные проверки) и реестр инструментов и интеграций для агентных сценариев.

Именно это ломает «локальную оптимизацию», где каждая команда изобретает свой велосипед, и переводит компанию к модели, где успешный паттерн становится масштабируемым. Это соответствует логике ^[26] общих возможностей уровня предприятия, которую BCG описывает ^[18] как ядро платформенной операционной модели.

Вытеснение теневых инструментов

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

Для генеративного ИИ это уже измеряемая реальность. По данным Cyberhaven ^[27], объем корпоративных данных, вводимых сотрудниками в ИИ-инструменты, вырос на 485% за год (с марта 2023 по март 2024), что усиливает риск утечек и нарушений. Gartner предупреждает ^[28], что к 2030 году 40% предприятий столкнутся с нарушениями безопасности или соответствия требованиям из-за неконтролируемого использования ИИ. Harmonic Security фиксировала ^[29], что 8,5% промптов уже содержит чувствительные данные, причем риск усиливается тем, что функции ИИ «встраиваются» в облачные приложения и обходят привычные контуры контроля.

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

Как выбрать подход

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

Сравнение: точечные решения, открытый код, корпоративная платформа

Резюме

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

На уровне стратегии это совпадает с тем, что наблюдают и исследуют крупные игроки: проблема масштабирования чаще упирается не в алгоритмы, а в встраивание в процессы, операционную модель, контроль рисков и управляемость.

Описанные в статье принципы — централизованное управление моделями, единое журналирование, оркестрация агентных сценариев, защитные правила «по умолчанию» — составляют архитектурную основу GenAI-платформы SimpleOne ^[1]. О том, как ИИ становится полноценным участником бизнес-процессов через визуальный конструктор и готовые ИИ-действия, — читайте в блоге ^[30].