AI lock-in из абстрактной страшилки для презентаций быстро превращается в рабочую проблему для крупных компаний. Глава Palantir Алекс Карп и CEO Mistral Артур Менш почти одновременно сформулировали один и тот же тезис: предприятия, которые слишком глубоко завяжут AI на одного поставщика, потом будут дорого расплачиваться за удобство первых месяцев.
Об этом сообщает The New Stack, пересказывая недавнее выступление Карпа в эфире CNBC Squawk Box и позицию Менша по корпоративному рынку AI. Поводом для разговора стало новое партнерство Palantir с Nvidia: компании усиливают ставку на корпоративные внедрения, где вопрос уже не в том, запускать ли генеративный AI, а в том, на каких условиях он войдет в ИТ-ландшафт компании и кто потом будет контролировать цену, архитектуру и скорость изменений.
Сигнал здесь интересен не только из-за имен. Palantir исторически играет в длинную игру с крупными заказчиками, где стек быстро превращается в часть операционной модели бизнеса. Mistral, наоборот, регулярно подается как один из европейских аргументов в пользу большей технологической автономии. Когда руководители компаний с настолько разной рыночной оптикой сходятся в одном тезисе, это уже не спор о философии open source против закрытых платформ. Это разговор о том, как будет устроен корпоративный рынок AI в ближайшие годы.
Под AI lock-in в этом контексте понимается не только зависимость от одной модели. Для предприятия ловушка обычно многослойная: API одного вендора, его инструменты оркестрации, собственные механизмы безопасности, привязка к конкретным GPU-конфигурациям, закрытые агенты, внутренняя телеметрия и набор SDK, на который потом опираются команды разработки. Снаружи это выглядит как аккуратно собранная платформа. Внутри это может оказаться дорогим и плохо переносимым монолитом, который трудно заменить даже частично, не ломая бизнес-процессы.
В этом и состоит главный неприятный вывод для ИТ-директоров и продуктовых команд. На старте почти любой enterprise AI-проект продается как ускорение: меньше времени на пилот, меньше интеграционной боли, готовые guardrails, понятный SLA, одна поддержка вместо пяти подрядчиков. Но чем успешнее пилот, тем выше цена выхода. Если в компанию уже встроены пайплайны, политики доступа, внутренние ассистенты, поиск по корпоративным документам и прикладные агенты под одного поставщика, разговор о миграции быстро перестает быть техническим. Он становится финансовым и организационным.
Для разработчиков эта история тоже вполне земная. Зависимость от вендора редко возникает в момент, когда команда сознательно подписывает себе архитектурный приговор. Обычно все начинается с безобидных решений: взять проприетарный eval-стек, использовать специфичную схему function calling, завязать промпт-хранилище и observability на один сервис, а потом прикрутить к этому встроенный RAG и корпоративную IAM-интеграцию. Через полгода выясняется, что формально модель можно заменить, а фактически вместе с ней нужно переписывать значительную часть обвязки. Именно поэтому предупреждение про AI lock-in звучит сейчас особенно громко: рынок еще на этапе бурного строительства, а бетон уже заливают.
У Palantir здесь своя логика. Компания давно зарабатывает на сложных, глубоко встроенных системах для крупных организаций, где ценность возникает не из самой модели, а из того, как она соединена с данными, разрешениями, операционными контурами и прикладными сценариями. Партнерство с Nvidia только подчеркивает, что борьба идет не за красивый чат-интерфейс, а за полный маршрут: от вычислительной инфраструктуры до слоя принятия решений. Если этот маршрут собран одним альянсом поставщиков, заказчик получает скорость. Но одновременно получает и очень жесткую колею, из которой потом трудно вырулить без потерь.
Позиция Артура Менша читается как предупреждение с другой стороны баррикад. Для компаний вроде Mistral разговор о рисках lock-in еще и рыночный шанс: если заказчики боятся полной зависимости от американских гиперскейлеров и закрытых AI-платформ, то спрос смещается в сторону более открытых и переносимых решений. Не обязательно полностью open source в идеологическом смысле, но хотя бы таких, где предприятие сохраняет пространство для маневра: может менять модель, смешивать поставщиков, переносить нагрузку между облаком и своим контуром, не переписывая все приложение заново.
Для российского и в целом русскоязычного ИТ-рынка этот сюжет понятен без перевода на корпоративный. Многие команды уже проходили через похожие циклы с облаками, CI/CD-платформами, ERP, базами данных и системами аналитики. В AI этот сценарий только ускорился. Если раньше на архитектурный lock-in уходили годы, то теперь его можно собрать за квартал: взять managed-модель, к ней managed-vector storage, managed-agents, managed-evals и заодно биллинг, который красиво растет вместе с нагрузкой. На демо все выглядит отлично. На этапе масштабирования начинаются вопросы, на которые презентация обычно не отвечает.
Практический вывод довольно приземленный. Enterprise-командам уже сейчас имеет смысл проектировать не только первый запуск, но и возможный выход: где у вас действительно стандартный интерфейс к модели, как отделены бизнес-правила от vendor-specific функций, можно ли заменить inference-слой без тотальной переделки, кто контролирует данные для обучения и дообучения, как экспортируются логи, эмбеддинги и артефакты eval. Если таких ответов нет, то это не «гибкая AI-стратегия», а просто быстрый путь в зависимость с хорошим маркетингом.
На ближайшем этапе рынок вряд ли откажется от больших интегрированных стеков: они слишком удобны, а бизнесу нужен результат, а не идеологическая чистота архитектуры. Но чем громче руководители уровня Карпа и Менша говорят про AI lock-in, тем яснее становится развилка для предприятий: либо они сознательно покупают скорость ценой будущей зависимости, либо начинают требовать от AI-платформ нормальной переносимости не на слайде, а в контракте и архитектуре.