Что проверить в архитектуре, данных и условиях передачи проекта до подписания договора

Автор: VOSHOD

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

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

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

Разберите зависимость на части

Фраза «мы используем другую модель» может означать замену лишь одного элемента. В готовой системе есть несколько разных зависимостей:

Модель и её программный интерфейс.
Платформа, которая хранит задания и запускает обработку.
Поисковый индекс и хранилище документов.
Интеграции с корпоративными системами.
Инструкции, правила согласования и проверки.
Журналы, метрики и испытательные наборы.
Учётные записи, права и договоры с исполнителями.

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

Сначала выясните, можно ли пользоваться сервисом

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

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

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

Что должно остаться у компании

Представим помощника, который готовит ответы по сервисным обращениям. Для переноса потребуются не только обращения и ответы.

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

Попросите исполнителя подготовить перечень передаваемых материалов с форматом и способом проверки. Фраза «все данные принадлежат заказчику» без описания экспорта оставляет практические вопросы открытыми.

Для каждого типа данных проверьте:

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

Не переносите секреты как обычные настройки

Инструкции и схемы работы удобно хранить в контролируемом репозитории или другом доступном компании хранилище. Ключи доступа и пароли требуют отдельного защищённого обращения.

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

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

Стандартный интерфейс помогает, но не делает системы одинаковыми

Промежуточный слой между бизнес-процессом и моделью может упростить замену провайдера. Он позволяет отделить прикладные правила от особенностей конкретного API.

Однако две модели могут по-разному понимать инструкцию, выбирать инструменты, работать с длинными документами и оформлять ответы. Одинаковая форма запроса не гарантирует одинакового результата.

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

В проекте полезно разделить то, что можно переносить почти механически, и то, что нужно заново проверять: инструкции, поведение инструментов, поиск, лимиты, права и качество результата.

Проверяйте выход небольшой репетицией

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

Заранее задайте вопросы проверки:

Все ли нужные данные доступны.
Сохранились ли связи и права.
Можно ли воспроизвести обычную задачу.
Какие элементы пришлось восстановить вручную.
Какие функции отсутствуют у альтернативы.
Как меняются время проверки сотрудником и качество результата.

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

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

Учитывайте жизненный цикл модели

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

Назначьте ответственного, который получает такие уведомления и знает, какие процессы затронуты. Время на миграцию включает не только изменение настройки, но и повторную проверку, устранение несовместимости и выпуск в рабочий контур.

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

Резервный путь может быть ручным

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

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

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

Что обсудить перед договором

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

Хороший вопрос для финальной встречи: «Если через год мы решим сменить платформу или команду, что именно придётся сделать и что останется доступно нам?»

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

Материал подготовлен VOSHOD. Сайт проекта · Telegram-бот.

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

Как внедрить ИИ и не оказаться привязанным к одному поставщику