План выхода

План выхода — это задокументированное описание того, как организация прекратит пользоваться поставщиком: какие данные вернутся, в каком формате, за какой срок, кто делает работу, что заменит сервис и во что это обойдётся. Его пишут не потому, что ждут расставания, а потому, что именно возможность уйти держит коммерческие отношения честными, — и эта возможность тихо ветшает, если её никто не проверяет. Правильный момент написать план — до подписания, пока поставщик ещё борется за сделку. Форматы выгрузки, помощь при переходе, срок хранения данных после расторжения и право расторгнуть договор по своему усмотрению обсуждаемы именно тогда и почти необсуждаемы позже. Поставщик, не желающий говорить о выходе до старта контракта, сообщает вам полезную информацию о том, каким этот выход будет. Рабочий план покрывает четыре вещи. Что принадлежит вам — записи, документы, конфигурации, оценочные наборы, библиотеки промптов, модели, обученные на ваших данных, — и сказано ли это в договоре прямо. Как вы это получаете: документированная выгрузка, API, разовый экспорт — и, что критично, в структуре, которую можно куда-то загрузить, а не в проприетарном архиве и не в стопке отчётов. Сколько у вас времени после расторжения до удаления. И какая работа ложится на вашу сторону: пересобрать интеграции, заново реализовать процессы, переучить пользователей. Издержки обычно недооценивают, потому что видна только лицензия. Настоящий вес — это инженерное время на перекладку интеграций, период параллельной работы, когда платят за обе системы, переобучение и исторические данные, которые либо мигрируют, либо превращаются в архив, к которому никто не может обратиться с запросом. Достаточно один раз грубо их оценить, чтобы компромисс стал осязаемым, — и нередко этого хватает, чтобы изменить предмет переговоров при продлении. У ИИ-систем есть составляющие, которые типовые планы выхода упускают. Дообученные модели и их веса, если договор вообще разрешает их забрать. Оценочный набор с разметкой — это месяцы накопленных суждений о том, как выглядит хороший ответ. История промптов и конфигураций. Эмбеддинги, которые обычно приходится пересчитывать, а не переносить, потому что они привязаны к модели. И любые данные, выведенные поставщиком из ваших, — их часто регулирует другой пункт, чем тот, что относится к переданным вами данным. Наконец, непроверенный план — это вера. Дешёвый способ проверки: раз в год выполнять выгрузку, загружать результат в нейтральное место и убеждаться, что он полон и пригоден. Одна эта привычка находит сломанные экспорты, отсутствующие поля и недокументированные ограничения тогда, когда они неудобство, а не чрезвычайная ситуация.