Vendor lock-in в ИТ-аутсорсинге: как не попасть в зависимость от подрядчика и сохранить контроль над инфраструктурой

Зависимость от поставщика в российском ИТ давно перестала быть теоретическим риском. По докладу Центра компетенций по импортозамещению в сфере ИКТ, который ЦКИТ представил в мае 2026 года, не меньше 30% крупных компаний продолжают работать на зарубежном корпоративном ПО, купленном до 2022 года, без поддержки и обновлений безопасности. По почте доля доходит до 50%, по виртуализации VMware держится около 40% против примерно 80% до 2022 года. Уйти дорого, остаться опасно, и это и есть lock-in в чистом виде.

Зависимость от ИТ-подрядчика устроена похоже, но заметить её гораздо труднее: она живёт не в лицензии, а в документации, доступах, правах на скрипты и в том, кто внутри компании вообще понимает, как всё работает. Ниже — из чего она складывается, как проверить себя до того, как придётся менять подрядчика, что для этого нужно в договоре и какие роли нельзя отдавать наружу ни при каком разделении.

Чем зависимость от подрядчика отличается от классического lock-in

Классический vendor lock-in привязывает компанию к продукту: форматы данных, лицензионная политика, экосистема вокруг платформы. Он виден в счёте и в условиях продления, поэтому его хотя бы обсуждают на бюджетном комитете. Чем он заканчивается, российский рынок уже посмотрел: в марте 2024 года Microsoft отключил российским юридическим лицам больше пятидесяти облачных сервисов, и у компаний, построивших на них процессы, вариантов в тот момент не было.

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

Дальше включается простая механика. Чем сложнее представить себе смену подрядчика, тем слабее ваша позиция на переговорах о цене и объёме работ, причём никто этим даже не пользуется специально. Достаточно того, что обе стороны понимают расстановку.

Стоимость выхода при этом недооценивают. В ГК Softline приводят оценку, по которой переход на нового подрядчика в среднем обходится втрое дороже той экономии, ради которой выбирали предыдущего, а адаптация команд к новой модели работы занимает до полутора лет.

Из чего складывается зависимость

Зависимость почти никогда не бывает одной. Обычно это пять слоёв, которые нарастают постепенно и каждый сам по себе выглядит безобидно.

Знания и документация

Схема сети, перечень активов, история изменений, причины, по которым пять лет назад сделали именно так. Если документацию ведёт подрядчик у себя, вы теряете её вместе с договором, а новой команде придётся восстанавливать картину по живой инфраструктуре.

Коварность этого слоя в том, что на старте всё обычно в порядке: передача ИТ наружу начинается с инвентаризации, и первая версия документации у заказчика есть. Расходиться она начинает со второго-третьего месяца, когда изменения идут потоком, а обязанности обновлять описание у подрядчика в договоре нет.

Инструменты подрядчика

Мониторинг, система заявок, средства удалённого управления, скрипты автоматизации. Работать на инструментах подрядчика удобно и обычно дешевле: он уже купил лицензии и настроил сценарии. Но вместе с договором уходят история инцидентов, пороги срабатывания и вся автоматизация, а отключение его агентов с ваших машин становится отдельным проектом.

Права на то, что для вас сделали

Самый недооценённый слой. По статье 1297 Гражданского кодекса исключительное право на программу или базу данных, созданную при выполнении договора подряда, который прямо не предусматривал её создание, принадлежит подрядчику. Заказчик получает только простую неисключительную лицензию на использование в целях договора.

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

Коммерческое оформление

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

Отдельная история — оборудование в аренде у подрядчика. Межсетевой экран или сервер, которые уедут вместе с ним, стоит знать заранее.

Управление подрядчиком

Самый тихий слой. Договор подписан, отчёты приходят раз в месяц и никем не читаются, SLA не проверяется, перечень объектов обслуживания не актуализировался два года. Формально подрядчик управляется, фактически решения принимает он, потому что только он знает состояние дел.

Как проверить, насколько вы зависимы

Проверка занимает один рабочий день и не требует участия подрядчика. По каждому пункту отвечайте «да» только если можете показать это прямо сейчас, не спрашивая никого снаружи.

Главная проверка не в таблице. Возьмите один критичный сервис и опишите на бумаге, что конкретно нужно сделать, чтобы его обслуживал кто-то другой: какие артефакты запросить, сколько времени займёт передача, что в этот период будет работать хуже. Если описание не складывается, зависимость уже есть, независимо от того, что написано в договоре.

Что об этом говорит регулятор

В банковском секторе управление зависимостью от подрядчика перестало быть вопросом зрелости и стало требованием. С 1 октября 2025 года в Положении Банка России № 716-П действует глава 8.1 об управлении риском аутсорсинга, и она довольно подробно описывает, как это устроено.

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

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

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

Чем закрыть зависимость в договоре

Про документацию, доступы и переходный период при расторжении сейчас пишут довольно часто. Пункты ниже встречаются реже, а стоят дороже всего.

Права на результаты работ

Общая формулировка про конфиденциальность здесь не помогает. Нужна прямая запись о том, что исключительное право на конфигурации, скрипты, шаблоны и документацию, созданные в рамках договора, принадлежит заказчику, иначе действует общее правило статьи 1297 ГК РФ. Для критичных самописных решений в ГК Softline рекомендуют эскроу-соглашения: исходный код и критическая документация передаются на хранение третьей стороне и становятся доступны заказчику при наступлении оговорённых событий.

Условия замены инструментов подрядчика

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

План выхода как приложение

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

О чём спросить до подписания

Четыре вопроса на этапе выбора показывают отношение подрядчика к зависимости лучше, чем любая презентация.

Первый: в чьей системе будет вестись документация и как она передаётся. Второй: что из инструментов обслуживания принадлежит подрядчику и на каких условиях остаётся у заказчика при расторжении. Третий: кому по договору принадлежат права на созданные конфигурации и скрипты. Четвёртый: есть ли у подрядчика типовой план выхода и готов ли он показать его до подписания.

Нормальный ответ на все четыре вопроса существует, и он не требует от подрядчика жертв. Если же вопросы вызывают раздражение или обещание «разберёмся по ходу», это и есть ответ.

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

Как не потерять экспертизу внутри компании

Вторая половина вопроса важнее первой. Договор защищает от резкого обрыва, но от медленной потери понимания собственной инфраструктуры он не защищает. Это делается организационно.

Роли, которые остаются внутри

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

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

Механика передачи знаний

Знания передаются через участие, и отчёты эту работу не делают. Работающие механики простые: ваш инженер присутствует на разборе крупных инцидентов, а не получает резюме; письменный разбор причин по критичным сбоям входит в состав услуги и принимается как результат; статьи базы знаний по типовым операциям пишет подрядчик, но хранятся они у вас и проверяются вашим человеком на читаемость.

Отдельно стоит договориться о доступе ваших сотрудников к системе заявок подрядчика на чтение. Это дешёвая мера, которая даёт ответ на вопрос, что в инфраструктуре ломается чаще всего, без запроса отчёта.

Чего не стоит делать

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

Если зависимость уже есть

Разбирается она в том же порядке, в котором нарастала, и обычно не быстро.

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

В исследовании B1 за 2026 год утечку корпоративных данных и недостаточную квалификацию исполнителей называют главными рисками аутсорсинга, по 53% каждый. Зависимость в этот список не попала, хотя именно она превращает остальные риски в неустранимые: предъявить требования подрядчику, которого нельзя заменить, довольно сложно.

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

С чего начать

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

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

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