Выход-стратегия: что останется у заказчика, если подрядчик по ИИ исчезнет завтра

Выход-стратегия ИИ-проекта — это заранее согласованный набор прав, артефактов и процедур, который позволяет заказчику продолжить работу, если подрядчик по искусственному интеллекту исчез, обанкротился или отказался от сопровождения. Без неё в руках остаётся «чёрный ящик»: модель крутится, но кода, весов, ключей и инструкций нет.

Материал подготовлен командой Роботок для руководителей, ИБ, юристов и ИТ, которые внедряют ИИ в контуре компании. Ниже — что прописать в договоре, какие технические артефакты забирать, как устроить эскроу, runbook и 90-дневный план перехода. Связанные темы: чек-лист готовности к внедрению и закрытый контур AI.

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

Риски аутсорсинга AI включают потерю контроля над данными, интеллектуальной собственностью и качеством решения. Минимизация — через SLA, передачу артефактов, эскроу, ответственность сторон и отрепетированный план перехода к новому исполнителю или in-house.

Договор на разработку и внедрение ИИ должен закрывать не только «сделать бота», но и обратимость: что происходит при расторжении, простое SLA и исчезновении подрядчика.

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

Чётко пропишите, кому принадлежат код, модели, веса, промпты, датасеты и производные от них артефакты. По умолчанию для заказчика разумно закрепить исключительное право на финальное использование решения в своём контуре и право передать сопровождение другому подрядчику. Лицензии «только пока платите» без офлайн-копии артефактов — прямой vendor lock-in.

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

• перечень хранимых объектов (приложение, модели, IaC, CI/CD, документация);
• условия и срок открытия доступа;
• обязательство регулярно обновлять депозит (мажорные и минорные релизы);
• формат поставки (git-зеркало, контейнерные образы, чексуммы).

В российском праве используется термин «условное депонирование» — такие положения законно включать в контракт.

Опишите основания расторжения для каждой стороны, срок уведомления, порядок расчётов и дорожную карту передачи. Технические детали: в какое хранилище уходят данные и модели, сколько они доступны, как подрядчик уничтожает копии у себя, возможна ли прямая передача новому исполнителю без простоя. Желательно ограничить досрочный выход подрядчика (например, только при длительной неуплате) и запретить «молчаливое» удержание ключей.

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

Минимальный комплект для ИИ-системы:

• исходный код и скрипты — репозиторий с историей, инструкции сборки и деплоя;
• модели и веса — файлы, контейнеры inference, версии в model registry;
• данные обучения и фичи — с анонимизацией ПДн, описание схемы и происхождения;
• конфигурации среды — Docker/Kubernetes, Infrastructure-as-Code;
• CI/CD — пайплайны сборки, тестов и выката;
• метаданные экспериментов — гиперпараметры, метрики, датасеты;
• документация и runbook — архитектура, эксплуатация, откат, контакты;
• доступы и ключи — с ротацией после передачи.

Код и документация восстанавливаются относительно быстро; данные и ключи — самые критичные. Поэтому в контракте требуйте полную передачу комплекта или его эскроу.

Для проектов в периметре компании это совпадает с логикой on-prem / air-gapped: артефакты и секреты изначально живут у заказчика, а не «в аккаунте вендора».

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

Runbook — рабочая инструкция на инциденты и ручные операции. Минимальный набор разделов:

• краткое описание сервиса и зависимостей;
• основные метрики и логи для мониторинга;
• типовые инциденты и алгоритмы решения;
• процедуры отката;
• ограничения ручных операций и эскалация.

Зафиксируйте, что покрывает контракт (приложение, БД, очереди, хостинг, внешние API), кто принимает решения в критических ситуациях, какие SLO отслеживаются (ошибки, latency, доступность). Поддержка исполняет инструкции и эскалирует; разработка отвечает за правки и апгрейды. Обучение команды заказчика — отдельные сессии передачи знаний, а не «документация в конце письма».

Данные и модели (как производные от данных) защищают шифрованием и контролем доступа: AES-256 / TLS на хранении и передаче, секреты — в Vault/KMS с ротацией. В договоре указывают, где обрабатываются персональные данные и кто отвечает за уведомление об утечке.

• РФ: ФЗ-152 — согласие, меры защиты, предпочтение обезличивания; штрафы ниже европейских, но претензии регулятора и репутационный ущерб реальны.
• ЕС (если применимо): GDPR — усиленная защита, право на переносимость, уведомление об инциденте за 72 часа; штрафы до 20 млн евро или 4% оборота.

Заложите регулярные аудиты и право заказчика на отчётность по мерам безопасности. Если ПДн нельзя выносить — сразу выбирайте персональное решение в контуре заказчика, а не облачный API «для пилота».

Даже при идеальном договоре нужна пошаговая процедура. Типовой аварийный сценарий:

1. Инвентаризация (1–2 дня) — что есть в эскроу, бэкапах и у заказчика: код, модели, данные, ключи.
2. Решение о замене — новый вендор или in-house; быстрый контракт на переход.
3. Развёртывание окружения (1–2 недели) — инфраструктура из IaC, контейнеры прежних версий.
4. Перенос данных — БД и датасеты, ротация ключей, проверка целостности.
5. Тестирование и приёмка — контрольные сценарии, evaluation harness без остановки бизнеса.
6. Передача знаний — актуальные runbook, обучение новой команды, Go-Live.

Приоритизируйте бизнес-функции: для сервиса с SLA 24/7 сначала поднимают прод и мониторинг, вспомогательные модули — позже. Практика показывает: репетиция перехода (тестовое отключение доступа подрядчика) ускоряет восстановление сильнее, чем толстый документ без учений. Ориентир рынка — готовить переход по 90-дневному сценарию с заранее оценёнными инструментами проверки качества.

Универсальных «ИИ-шаблонов» мало — их собирают из практики IT-аутсорсинга и AIaaS. Ниже — блоки, которые стоит включить в договор и приложения.

• Описание услуг и SLA — объём, цели, метрики (время обработки, точность на эталоне, доступность), пересмотр уровня качества раз в 6–12 месяцев, штрафы и скидки при нарушении.
• Права на ИС — кому принадлежат код, модели, данные; возможность передачи при смене подрядчика.
• Эскроу — кто хранит, что входит, когда открывается доступ, как часто обновляется депозит.
• Документация и знания — обязанность вести документацию «по ходу работ», runbook и обучение команды заказчика.
• Конфиденциальность и ИБ — NDA, шифрование, контроль доступа, уведомления об утечках, 152-ФЗ / GDPR.
• Передача данных при расторжении — канал (S3/SCP/контур заказчика), сроки, удаление копий у подрядчика, опция прямой передачи новому исполнителю.
• Расторжение и обратимость — основания, уведомление, резервные копии, финальный акт, расчёты.

• Есть SLA с KPI и штрафами.
• Прописаны права на ИС и эскроу исходников / моделей.
• Полный список артефактов к передаче: код, модели, данные, конфиги, ключи.
• Гарантии безопасности и соответствия 152-ФЗ (и GDPR при необходимости).
• Процедуры расторжения и обратимости.
• Обучение персонала и актуальные runbook.
• Понятно, где физически живут данные и модели (в т.ч. on-prem).

1. Заключите NDA и ограничения на использование данных.
2. Определите владельца кода, данных и результатов ИИ.
3. Оформите SLA с метриками и штрафами.
4. Включите эскроу критичных артефактов.
5. Зафиксируйте полный перечень передаваемых артефактов.
6. Согласуйте процедуру передачи при расторжении.
7. Подготовьте runbook и обучение внутренней команды.
8. Обеспечьте шифрование, управление секретами и план уведомлений об утечках.
9. Запланируйте и при возможности отрепетируйте резервный план (например, 90 дней).

Эти меры сохраняют контроль над AI-решением и позволяют продолжить работу при внезапном уходе подрядчика — без остановки закупок, поддержки или протоколов, которые уже завязаны на модель.

Роботок проектирует внедрения так, чтобы контур заказчика оставался управляемым: локальное развёртывание, передача артефактов, интеграции с 1С/CRM/мессенджерами и сопровождение с понятным SLA. Готовые продукты — в каталоге решений; уникальный процесс — персональное ИИ под ключ. Обсудить exit-условия до старта пилота можно на странице контактов.