Александр Стародубцев, сооснователь корпорации ITG, — о том, почему точечные ИИ-решения и самостоятельная сборка на открытом коде не масштабируются, и как платформенный подход, на примере GenAI-платформ, позволяет перевести генеративный ИИ из разряда экспериментов в управляемую корпоративную инфраструктуру
Александр Стародубцев
Cооснователь корпорации ITG
Введение
Компании по всему миру и в частности российские снова и снова наступают на одни и те же грабли при внедрении ИИ — и причина, как правило, одна: ИИ начинают внедрять как набор отдельных «функций», а не как управляемую корпоративную способность, которая должна масштабироваться, обновляться, контролироваться и измеряться так же дисциплинированно, как кибербезопасность, финансы или DevOps.
Это хорошо видно по тому, как рынок развивался последние годы. ИИ действительно стал повсеместным, но масштабирование до устойчивого бизнес-эффекта остается узким горлышком: многие организации застревают между пилотами и промышленной эксплуатацией. Именно этот разрыв — «от пилота к масштабу» — McKinsey фиксирует как устойчивую проблему: инструменты ИИ используются широко, но глубоко встроить их в процессы и получить материальный эффект на уровне компании удается далеко не всем.
Параллельно растет давление со стороны рисков и регулирования. Нужно не только «чтобы работало», но и чтобы было безопасно, объяснимо, наблюдаемо, управляемо по доступам и стоимости. В Европе, например, для систем ИИ высокого риска прямо закрепляются требования к автоматическому журналированию и прослеживаемости. На стороне лучших практик появляются управленческие стандарты и рамки — NIST AI RMF и профиль для генеративного ИИ, а также ISO/IEC 42001 как стандарт системы менеджмента ИИ.
Платформенный подход — это способ перестать «внедрять ИИ» как разрозненные эксперименты и начать управлять ИИ как корпоративной инфраструктурой — с понятными правилами, SLA, безопасностью, метриками и тиражированием практик.
Проблема первая: «зоопарк» точечных решений
Как это выглядит
Точечное решение — это отдельный ИИ-продукт под один сценарий или одну команду:
бот для подбора и адаптации персонала,
чат-бот для клиентской поддержки,
генератор маркетинговых текстов,
«помощник юриста» для работы с договорами,
встроенный помощник для разработчиков.
У каждого такого решения, как правило, свой вендор или контур, свой набор моделей и настроек, своя схема доступа, логирования и хранения данных, свой жизненный цикл изменений.
Почему это кажется удобным на старте
Точечные решения выигрывают по двум причинам: быстрое время до демонстрации (внутренний «вау-эффект» за 2–6 недель) и локальная оптимизация — каждое подразделение покупает то, что «болит у него» прямо сейчас. На уровне одного департамента это выглядит рационально. На уровне компании — это начало архитектурного долга.
К чему это приводит
Плохая адаптация и зависимость от вендора. Точечные продукты часто хорошо решают типовой сценарий, но плохо выдерживают реальную сложность корпоративных процессов: исключения, регламенты, согласования, разнородные источники данных, корпоративные роли доступа. Когда начинается доработка, она превращается в цепочку закрытых запросов вендору, ограниченную конфигурацию без контроля над «внутренностями» и зависимость от дорожной карты внешней компании.
Невозможность перенести успешные практики между отделами. Если служба поддержки нашла удачный набор промптов, систему оценок качества, метрики и защитные правила — HR не может просто «переиспользовать» это: другие контуры, другой инструмент, другая модель, другой способ журналирования. Возникает парадокс: компания учится, но знания не тиражируются.
Отсутствие единого управления безопасностью, потреблением и логированием. Это главный риск для зрелой организации. В мире генеративного ИИ речь идет не только о классической информационной безопасности, но и о специфических угрозах: внедрение вредоносных инструкций через промпт, утечки контекста, неконтролируемые интеграции с внешними данными и инструментами. Исследования показывают, что уязвимости и сценарии атак через промпт масштабируются на самые разные приложения и домены, а успешные атаки могут приводить к утечкам и несанкционированным действиям. С точки зрения управления, Gartner описывает направление AI TRiSM (Trust, Risk, Security Management) как набор практик и технологий для управления доверенностью, рисками, безопасностью и контролем ИИ-развертываний — то есть, по сути, как «надстройку управления» над ИИ в масштабе предприятия.
Нестандартизированные процессы на уровне компании. Когда ИИ внедряется точечно, компания не формирует единый «скелет» процессов: как выбирать модель и где она разрешена, как классифицировать данные и что нельзя отправлять во внешние API, как проводить оценку качества и рисков, как расследовать инциденты, как считать экономику. В результате масштабирование стопорится не на «умности моделей», а на управляемости.
Проблема вторая: решения с открытым кодом — хороши для прототипов, опасны в промышленной эксплуатации
Сразу важная оговорка: открытый код сам по себе не «плох». Многие критически важные компоненты современной ИТ-инфраструктуры — это проекты с открытым кодом. Риск возникает, когда организация воспринимает его как «бесплатную платформу без последствий», особенно в ландшафте генеративного ИИ, где скорость изменений и поверхность атак выше обычного.
Почему открытый код привлекателен на этапе пилота
Он выигрывает на старте за счет скорости (можно собрать прототип из готовых библиотек и примеров), прозрачности (видно, как устроена система), гибкости (можно модифицировать код) и отсутствия лицензии «за пользователя» — хотя появляются другие издержки.
Скрытые издержки при масштабировании
Отклонение от основной ветки. Как только компания начинает «допиливать под себя» — появляются изменения, которые не входят в основной проект. Дальше приходится выбирать: внести доработки в основной проект (сложно организационно, но стратегически полезно) или поддерживать собственную ветку, которая становится внутренней «платформой-одиночкой». Linux Foundation описывает эту развилку как ключевое решение, отмечая, что частная поддержка несет реальные долгосрочные издержки. Эмпирические исследования показывают, что в экосистемах формируются целые «семейства» расходящихся вариантов, и практики сопровождения таких ветвящихся семейств становятся отдельной сложной задачей.
Растущие затраты на доработку и сопровождение. Даже без отклонения от основной ветки ИИ-системы склонны накапливать скрытый технический долг. Классическая работа Google (Sculley и др.) показывает, что быстрые победы машинного обучения часто создают долг в виде связностей, зависимостей и вспомогательных компонентов, а итоговая стоимость сопровождения может стать «массовой и постоянной». В генеративном ИИ этот эффект усиливается: меняются модели, токенизация и цены, контекстные окна, политики безопасности, появляются новые типы атак — и «просто обновить библиотеку» становится нетривиальной задачей.
Снижение стабильности системы. В промышленной эксплуатации важны SLA, регрессионные тесты, наблюдаемость, повторяемость поведения. Стек на открытом коде в пилоте обычно живет без строгих оценок качества на репрезентативных данных, без формализованных «красных линий» безопасности и без дисциплинированного управления изменениями. В результате «оно работало на демо» превращается в «оно ведет себя иначе на реальных данных».
Сложность возврата в основную ветку. Чем больше расхождение, тем дороже «вернуться в мейнстрим»: объединение веток, перепроверка совместимости, пересборка тестов и интеграций. И это уже не единичная задача — это постоянная работа.
Безопасность цепочки поставок и уязвимости библиотек. Открытый код требует дисциплины в части безопасности цепочки поставок: ведение реестра компонентов (SBOM), контроль зависимостей, безопасная сборка, мониторинг уязвимостей. NIST в рамках SSDF фиксирует необходимость внедрения практик безопасной разработки как универсальный минимум. Отчеты по цепочке поставок показывают рост угроз и вредоносных пакетов в популярных экосистемах, что делает управление зависимостями не факультативом, а обязанностью.
Для экосистемы больших языковых моделей характерно и то, что уязвимости могут быть «логическими»: например, CVE-2024-8309 описывает случай, где внедрение вредоносных инструкций через промпт в компоненте LangChain приводило к SQL-инъекции. Это не аргумент не использовать открытый код, но в промышленной эксплуатации он требует платформенной дисциплины, иначе риск и стоимость растут нелинейно.
Решение: платформенный подход
Платформа для корпоративного ИИ — это единый слой инфраструктуры и управления, который позволяет разным командам быстро собирать ИИ-сценарии, но при этом использовать общие политики безопасности и доступа, иметь единое журналирование и прослеживаемость, управлять стоимостью и лимитами, тиражировать практики и компоненты, обновляться без «ломки» существующих доработок.
Интуитивно это похоже на то, как компании в свое время переходили от разрозненных скриптов к DevOps-платформам, от «серверов под проект» к облачной платформе и FinOps, от ручных прав доступа к централизованному управлению учетными записями и единому входу (IAM/SSO).
С точки зрения крупных консалтинговых подходов это тоже укладывается в «платформенную логику»: BCG описывает платформенную операционную модель как переход к общим, переиспользуемым возможностям уровня предприятия, которые ускоряют и удешевляют создание ценности в разных бизнес-подразделениях. А в свежих материалах BCG про масштабирование ИИ подчеркивается идея агентной платформы как общего слоя — память, оркестрация, реестры инструментов, управление — поверх которого строятся конкретные продукты и агенты.
Когда платформенный подход оправдан
Платформенный подход почти всегда оправдан, если у компании есть хотя бы три из семи условий:
больше 3–5 подразделений хотят внедрять генеративный ИИ параллельно;
есть чувствительные данные или регуляторные требования;
нужны единые политики доступа и аудит;
ожидается рост расходов на токены и вычислительные ресурсы, и нужно распределение затрат;
есть риск теневого использования ИИ;
нужны агенты и интеграции с корпоративными системами (а значит — управляемые инструменты и вызовы);
компания планирует обновлять модели и провайдеров без больших проектов.
Гибкость и масштаб
Хорошая корпоративная платформа должна закрывать два типа задач одновременно. Первый — типовые сценарии, где важны скорость и стандартизация: корпоративный чат и поиск по базе знаний (RAG), резюме встреч и переписки, генерация черновиков документов, ассистенты для службы поддержки, помощники для разработчиков. Второй — специфические сценарии, где важна интеграция и управляемость: процессы с регламентами и согласованиями, сценарии с чувствительными данными, системы в «серой» регуляторной зоне, агентные сценарии с инструментами, где модель может инициировать действия.
Практически это означает модульную архитектуру: шлюз моделей и маршрутизация (какая модель, где, на каких данных, какие лимиты), коннекторы к данным с разграничением доступа, оценка качества, тесты и мониторинг, библиотека компонентов (промпты, шаблоны, политики, защитные правила), оркестрация рабочих процессов и агентов с контролируемыми инструментами.
Здесь полезно вспомнить выводы практик MLOps: реальная сложность — не «обучить модель», а построить воспроизводимую систему поставки, развертывания и мониторинга. Google в материалах по MLOps описывает уровни зрелости и подчеркивает необходимость непрерывной интеграции, доставки и дообучения, а также автоматизации конвейеров для надежной эксплуатации ML/AI в промышленной среде.
Обновления без боли
Платформа позволяет делать доработку через штатные расширения, а не через ответвления и «заплатки». Ключевая идея: вы не меняете ядро, а добавляете плагины, политики, шаблоны и интеграции через поддерживаемые интерфейсы. Обновления платформы при этом не превращаются в проект «перепройти все заново».
Почему это важно — подтверждается исследованиями про расходящиеся ветки и основной проект: как только вы уходите в частное сопровождение, вы берете на себя реальную стоимость поддержания расходящейся ветки.
Практический критерий «платформенности» здесь простой: если ваша доработка живет только в виде разницы к исходникам — это не доработка, это будущий долг.
Централизованное управление безопасностью
Это пункт, где платформенный подход дает максимальную совокупную выгоду, потому что безопасность в генеративном ИИ — это одновременно:
безопасность данных,
безопасность действий (инструменты и вызовы),
безопасность цепочки поставок,
контроль доступа и аудит,
мониторинг нежелательных выходов и инцидентов.
Единый контроль доступа. Платформа должна интегрироваться с корпоративной системой управления учетными записями (SSO, ролевая и атрибутивная модели доступа), чтобы сотрудники видели только разрешенные данные и функции, доступ к моделям и инструментам был управляемым, а роли и политики — едиными.
Маршрутизация запросов: внутренние и внешние сети. В реальности у компании часто смешанный контур: часть задач можно отправлять во внешние API, часть должна обрабатываться внутри периметра, часть — только в конкретной географии или облаке. Это особенно актуально на фоне требований к трансграничной передаче данных и соответствию нормативам.
Полное журналирование и прослеживаемость действий нейросетей. Это уже не опция, а необходимость. В регулировании это становится прямым требованием: EU AI Act для систем высокого риска закрепляет необходимость автоматического журналирования событий на протяжении жизненного цикла, чтобы обеспечивать прослеживаемость и мониторинг после вывода на рынок. Со стороны управления рисками NIST AI RMF и профиль для генеративного ИИ описывают практики по всему жизненному циклу, где наблюдаемость и контроль — базовые элементы.
Быстрое расследование инцидентов. Платформа должна давать расследованию то, что обычно нужно информационной безопасности и подразделению комплаенса: кто и когда сделал запрос, какой контекст и данные использовались, какая модель отвечала и с какими настройками, какие инструменты и интеграции были вызваны, какие политики сработали (разрешение, запрет, маскирование).
Отдельно полезно, что крупные корпоративные поставщики добавляют инструменты соответствия требованиям и аудита — например, API и интеграции для электронного раскрытия информации, предотвращения утечек данных и аудита рабочих пространств.
Управление потреблением и эффективностью
ИИ в масштабе компании быстро упирается в вопрос: кто и сколько сжигает ресурсов — и какой эффект это дает.
В генеративном ИИ экономика часто выражается в токенах (а также профилях вычислительных ресурсов для вывода, извлечении данных, агентных циклах). Поэтому платформа должна обеспечивать лимиты и квоты (на пользователя, команду, сценарий), распределение затрат по подразделениям, а также аналитику «стоимость → результат» — например, стоимость решения одного обращения, стоимость обработки документа, стоимость привлечения потенциального клиента.
В практике управления ИТ-затратами это нормальная зрелость: распределение затрат — отдельная способность, которую нужно согласовать с финансовыми моделями и центрами затрат. Для генеративного ИИ появляется дополнительная специфика: единица потребления — токены, и именно это подчеркивается в материалах по управлению затратами на Azure OpenAI: нужны механизмы видимости, распределения и расчета удельной экономики в терминах токенов.
Тиражирование лучших практик
Платформа превращает опыт отдельных команд в актив компании через общие артефакты: библиотеки промптов и шаблонов с версионированием и владельцами, стандартизированные защитные правила (маскирование, фильтры безопасности, проверки на соответствие политикам), единые подходы к оценке качества (метрики, тестовые наборы, регрессионные проверки) и реестр инструментов и интеграций для агентных сценариев.
Именно это ломает «локальную оптимизацию», где каждая команда изобретает свой велосипед, и переводит компанию к модели, где успешный паттерн становится масштабируемым. Это соответствует логике общих возможностей уровня предприятия, которую BCG описывает как ядро платформенной операционной модели.
Вытеснение теневых инструментов
Запреты сами по себе не работают, потому что люди оптимизируют свою эффективность. Если официального инструмента нет или он неудобен — появится «теневой».
Для генеративного ИИ это уже измеряемая реальность. По данным Cyberhaven, объем корпоративных данных, вводимых сотрудниками в ИИ-инструменты, вырос на 485% за год (с марта 2023 по март 2024), что усиливает риск утечек и нарушений. Gartner предупреждает, что к 2030 году 40% предприятий столкнутся с нарушениями безопасности или соответствия требованиям из-за неконтролируемого использования ИИ. Harmonic Security фиксировала, что 8,5% промптов уже содержит чувствительные данные, причем риск усиливается тем, что функции ИИ «встраиваются» в облачные приложения и обходят привычные контуры контроля.
Платформа дает удобный официальный инструмент, встраивает его в рабочий контекст, обеспечивает защиту данных и аудит по умолчанию — без постоянного ручного контроля. И главное — переводит организацию из режима «борьба с пользователями» в режим «управляемое использование».
Как выбрать подход
Ниже — сравнительная таблица, обобщающая основные различия. В реальной жизни часто бывает гибрид: например, платформа как базовый слой плюс два-три точечных продукта, если они действительно уникальны и интегрируются через платформенные политики.
Сравнение: точечные решения, открытый код, корпоративная платформа
Критерий | Точечные решения | Открытый код (самостоятельная сборка) | Корпоративная платформа |
Время до пилота | Очень быстро | Быстро | Быстро/средне (зависит от внедрения) |
Масштабирование на всю компанию | Сложно из-за фрагментации | Теоретически возможно, но требует сильной команды и дисциплины | Заложено в модель (единый слой) |
Адаптация под сложные процессы | Ограничена рамками продукта | Высокая, но часто через изменения ядра | Высокая, но через расширения и конфигурацию |
Обновления и совместимость | Зависите от вендора, но обновления чаще «приезжают сами» | Риск расхождения веток и трудоемкого объединения | Обратная совместимость как часть обещания платформы |
Долгосрочная совокупная стоимость владения | Часто растет из-за «зоопарка» | Растет из-за сопровождения и технического долга | Предсказуемее за счет централизации |
Единая безопасность и управление | Обычно нет | Можно, но нужно строить самому + безопасность цепочки поставок | Встроено (управление доступом, политики, аудит) |
Журналирование, прослеживаемость, аудит | Фрагментировано | Делается вручную | Единый стандарт, проще соответствовать требованиям |
Управление стоимостью (лимиты, распределение затрат) | Разрозненно | Делается вручную | Централизовано, проще управлять экономикой токенов |
Тиражирование практик (промпты, оценка качества, защитные правила) | Плохо | Возможно, но требует дисциплины | Сильная сторона платформы |
Риск теневого использования ИИ | Высокий (люди уходят в удобные внешние сервисы) | Средний (если платформа удобна) | Снижается, т.к. появляется «официальный удобный путь» |
Требования к внутренней экспертизе | Низкие/средние | Высокие (архитектура, безопасность, сопровождение) | Средние (нужна команда платформы, но меньше «самодеятельности») |
Резюме
Платформенный подход не сводится к выбору наиболее продвинутой модели ИИ. Его задача — сделать применение ИИ в компании управляемым, масштабируемым и устойчивым: обеспечить безопасность, аудит и соответствие требованиям; перевести решения от пилотных проектов к корпоративному стандарту; обеспечить регулярные обновления без нарушения работы существующих процессов.
На уровне стратегии это совпадает с тем, что наблюдают и исследуют крупные игроки: проблема масштабирования чаще упирается не в алгоритмы, а в встраивание в процессы, операционную модель, контроль рисков и управляемость.
Описанные в статье принципы — централизованное управление моделями, единое журналирование, оркестрация агентных сценариев, защитные правила «по умолчанию» — составляют архитектурную основу GenAI-платформы SimpleOne. О том, как ИИ становится полноценным участником бизнес-процессов через визуальный конструктор и готовые ИИ-действия, — читайте в блоге.
