Половина энтерпрайза добровольно подписывает себе смертный приговор, закупая заказную ML-разработку как черный ящик. Вы уже обожглись на уходе западных вендоров АСУ ТП, плакали над превратившимися в кирпичи контроллерами Siemens и в спешке выкачивали данные из отключаемых облачных инфраструктур. И чему это вас научило? Ничему. Теперь бизнес с энтузиазмом заносит бюджеты локальным ИИ-подрядчикам, которые накидывают на шею новый поводок — «ML-платформу как сервис». Vendor lock-in в ИИ-проекте: 9 точек, где вас тихо привязывают, и как вшить право на выход в ТЗ и архитектуру — это не юридическая казуистика про права на интеллектуальную собственность. Это суровая техническая реальность. Если вы не можете запустить инференс локально из консоли за пять минут при выдернутом сетевом кабеле, вы ничем не владеете.
Сравним два подхода: «Подписка на магию» против «Инженерного отчуждения». В первом случае подрядчик продает вам красивые метрики на дашборде и API-эндпоинт. Вы встраиваете вызовы в свой production, а когда p99 latency улетает за 800 миллисекунд или вендор поднимает прайс в пять раз, вы оказываетесь в заложниках — переписать логику не на что. Во втором случае вы покупаете детерминированный процесс. У вас есть веса, исходный код, данные и уверенность, что система запустится на bare-metal сервере в вашем дата-центре без пингов наружу. Зависимость от ИИ-вендора закладывается на уровне базовой архитектуры. Разберем 9 узлов, на которых вас держат крепче всего.
1. Проприетарная модель/API без open-weights-аналога. Вы строите всю бизнес-логику вокруг закрытой модели подрядчика или обертки над SaaS-LLM. Промпты, пайплайны RAG, системные инструкции — всё заточено под один блэкбокс. Когда компания-вендор закроется или радикально изменит политику, ваши наработки превратятся в тыкву. Правильная архитектура требует использования open-weights моделей (Llama-3, Qwen, Mistral) как базового fallback-варианта. Вы должны знать точный бюджет VRAM для запуска и держать локальный инференс наготове.
2. Данные и эмбеддинги в закрытом формате чужого облака. Вы скормили корпоративную базу знаний в SaaS-векторную БД вроде управляемого Qdrant или Pinecone, развернутого на стороне вендора. При попытке забрать данные вы получаете обфусцированные бинарные блобы или урезанный JSON, непригодный для миграции. Exit-стратегия ИИ-проекта требует, чтобы сырые тексты, чанки и сами векторные представления дублировались в вашем внутреннем S3/MinIO хранилище в формате Parquet, с жесткой фиксацией хэша модели эмбеддингов, которой они были сгенерированы.
3. Закрытый пайплайн обучения без передачи кода. Вам отдают финальный артефакт — бинарный файл с весами. Отлично, модель крутится в проде. Через три месяца распределение входящих данных меняется из-за сезонности (data drift), метрики пробивают дно. Вы просите переобучить модель, а вендор выставляет счет на сотни тысяч, потому что код подготовки данных и обучения — это «наше ноу-хау». Отчуждаться должен не артефакт, а сам конвейер: скрипты подготовки датасета, пайплайн аугментации, функции потерь. Иначе вы покупаете одноразовую батарейку.
4. Разметка и golden set у подрядчика. Данные — это топливо, но разметка — это двигатель. Вы отправили терабайты телеметрии и изображений с камер на дефектоскопию. Подрядчик разметил их в своем внутреннем туле. Самое страшное — у него остался golden set (эталонный тестовый датасет), по которому меряется итоговое качество. Кто владеет тестовой выборкой, тот и рисует вам accuracy 99% на презентациях. Золотой датасет обязан лежать в вашем репозитории с первого дня.
5. Жёсткая привязка к одному вендору железа (CUDA-only). Сейчас вы гоняете обучение и инференс на арендованных A100. Завтра дефицит GPU на рынке вынуждает перенести вычисления на периферию (edge-устройства) — промышленные ПК с NPU от Hailo, Rockchip или на дешевые инстансы AMD. И тут выясняется, что код намертво прибит гвоздями к проприетарным библиотекам NVIDIA и TensorRT-плагинам. Переносимость ML-решения между аппаратными платформами достигается обязательным экспортом графа вычислений в ONNX Runtime или OpenVINO, где железо — это просто сменяемый backend-провайдер.
6. Недокументированные интеграции с 1С/ERP. Дата-саентист вендора, чтобы ускорить демо, набросал прямо в Jupyter-ноутбуке SQL-скрипт с прямым доступом к read-реплике вашей 1C. Завтра ваши DBA меняют тип поля в таблице транзакций, и весь ML-инференс падает с ошибкой 500, ломая смежный бизнес-процесс. Никаких прямых обращений скриптов к СУБД. Только строгие API-контракты (gRPC/REST) или потоковое чтение из изолированного Datalake через брокеры сообщений.
7. Юридический мираж: нет прав на дообученные веса в договоре. Юристы проверили контракт: права на результаты интеллектуальной деятельности принадлежат вам. Технически вендор дообучил LLM методом LoRA и торжественно передает вам файл адаптера весом 150 мегабайт. При этом базовой нейросетью, поверх которой он работает, является закрытая собственная разработка вендора. Ваш адаптер без их базы — это математический мусор. Право на выход означает, что и базовые веса, и сам адаптер физически могут крутиться на ваших собственных серверах без лицензионных ключей.
8. MLOps на зарубежном SaaS под санкционным риском. Выстраивать трекинг экспериментов в Weights & Biases или заказывать разметку в Scale AI — это индустриальный стандарт комфорта. Ровно до того дня, пока ваш корпоративный аккаунт не отрубят по гео-признаку с заглушкой 403 Forbidden. Вы теряете всю историю экспериментов, версионирование моделей и логи обучения за год. Единственный жизнеспособный сценарий для highload и enterprise — self-hosted решения внутри контура: MLflow, ClearML и CVAT, развернутые на железе заказчика.
9. Нет воспроизводимости — модель нельзя пересобрать без подрядчика. Самый грязный секрет заказной разработки. Даже если вам выгрузили код, данные и веса в архиве, локальный запуск выдает точность 60% вместо заявленных на сдаче проекта 95%. Причина тривиальна: не зафиксированы random seeds, используются разные версии CUDA-компиляторов, часть данных фильтровалась руками мимо скриптов. Миграция «вслепую» всегда равняется переобучению с нуля, что выливается в 6–12 месяцев потери времени и дублирование бюджета. Спасение — полностью детерминированный графовый пайплайн, проверяемый CI/CD раннером.
stages:
data_prep:
cmd: python src/prepare.py --config conf/data.yaml
deps:
- src/prepare.py
- data/raw/
outs:
- data/processed/dataset.parquet:
cache: true
train_model:
cmd: python src/train.py --epochs 100 --seed 42
deps:
- src/train.py
- data/processed/dataset.parquet
outs:
- models/weights.onnx:
cache: true
metrics:
- metrics/eval.json:
cache: falseVendor lock-in ИИ: как избежать зависимости и вшить exit-стратегию в архитектуру
Бумажный договор с печатями не скомпилирует вам инференс. Чтобы в любой момент сменить вендора или перевести систему на внутреннюю in-house команду, ваша ИИ-инфраструктура должна строиться по принципу отчуждаемости с первого коммита.
- Открытые базовые модели: в архитектуре жестко зафиксировано использование open-weights сетей, допускающих коммерческое использование на собственных серверах.
- Локализация данных и метрик: golden set, сырые чанки и эмбеддинги лежат в корпоративном хранилище, а не в облаке подрядчика.
- Абсолютная воспроизводимость: пайплайн пересобирается одной shell-командой, выдавая детерминированный результат бит в бит.
- Hardware-агностика: инференс работает через ONNX/OpenVINO, что позволяет мигрировать между NVIDIA, AMD и edge-периферией.
- Изолированный MLOps: весь инструментарий от трекинга метрик до оркестрации разворачивается on-premise.
Миграция ML-решений обходится в миллионы не из-за сложной математики, а из-за лени и наивности при проектировании. Построение независимого воспроизводимого MLOps-контура в услуге mlops-production-ml — это суровая инженерия, отсекающая любые технические щупальца вендора. Либо вы физически контролируете графы вычислений, потоки данных и железо, либо вы просто оплачиваете чужой R&D-отдел, ошибочно считая обученную нейросеть своим активом.