Предмет договора: процесс и цифра приёмки
Предмет описывают процессом и результатом, а не списком функций. «Разработать чат-бота с базой знаний» сдаётся актом в день, когда бот впервые ответил. «Довести долю обращений, закрытых без человека, до порога к оговорённому месяцу» сдаётся только цифрой. Такую метрику мы записываем в договор на внедрении ИИ.
Спорят потом обычно об определении метрики. Запишите, что считается успехом в одном случае, какой период сравнивается, откуда данные и что исключено. В кейсе розничной сети обращение считалось закрытым без человека, если диалог закончился ответом бота и клиент не написал повторно по той же теме в течение суток. Первую неделю настройки из расчёта убрали.
Решите заранее, что будет, если порог не взят: доработка без доплаты, пересмотр объёма или выход. И перечислите, чего в предмете нет. Иначе пилот на одном процессе тихо расползётся на пять.
Оплата частями, с приёмкой каждой
Платить одной суммой за итог опасно: на старте никто не знает, окупится ли процесс. Проект режут на этапы. У каждого свой результат на руках и точка, где можно остановиться, а платёж привязан к приёмке этапа.
Первой обычно идёт диагностика. У нас она стоит 60 000 – 90 000 ₽, занимает 3–5 дней и засчитывается в стоимость следующего этапа, остальные вилки на странице цен.
Данные и соглашение о неразглашении
Соглашение о неразглашении (NDA) подписывают до первой выгрузки, а не вместе с основным договором: данные нужны подрядчику уже для оценки. Мы делаем так же. Это написано рядом с каждой формой заявки. В договоре или приложении к нему перечислите:
- Какие данные вы передаёте и для каких задач их можно использовать.
- Куда уходит каждый запрос к модели: российское облако, ваш контур или внешний сервис.
- Запрет обучать на ваших данных чужие модели, в том числе модели поставщика.
- Сроки хранения, возврат и удаление данных после работ, с письменным подтверждением.
- Кто с вашей стороны и к какому дню выдаёт доступы.
Последний пункт защищает обе стороны: согласование доступа через службу безопасности подрядчик не контролирует, и задержка из-за него не должна считаться его просрочкой. Если в выгрузке есть персональные данные, их обработку подрядчиком оформляют по закону о персональных данных. Какой нужен документ и можно ли отправлять такие данные в облако, решает ваш юрист.
SLA на ИИ-решение после запуска
Обычное SLA следит за доступностью: сервер отвечает, сбой чинят за оговорённые часы. ИИ-решение может работать без сбоев и при этом отвечать хуже, чем месяц назад, например после обновления модели у поставщика. Поэтому в соглашение пишут ещё и способ мерить качество ответов.
Его меряют выборкой: человек, знающий предмет, регулярно проверяет случайные ответы. Запишите размер выборки, частоту, кто проверяет и при каком значении начинается разбор. В страховой компании вопрос считался закрытым, только если ответ подтвердил методолог при еженедельной проверке пятидесяти случайных ответов. Как устроить такую проверку своими силами, разобрано в статье о качестве чат-бота.
Второе, без чего соглашение не работает: классы ошибок.
Сроки ставьте цифрами, отдельно для рабочего и нерабочего времени. Раз в месяц подрядчик показывает, сколько раз уложился в срок. Раздел об ответственности покажите юристу.
Права на код, промпты, базу знаний и веса
Как передать права на код или дать на него лицензию, юрист знает. С остальным сложнее: промпты (инструкции для модели), разметку базы знаний и дообученные веса, то есть файлы модели после настройки на ваших данных, в типовом договоре на разработку легко пропустить. Правовую природу каждого из них оценит юрист. Ваша задача: назвать всё поимённо и записать, что вы вправе с этим делать после окончания договора.
Вопрос не теоретический: дообученная модель бывает главным результатом проекта. В кейсе юридической фирмы открытую модель дообучали в периметре заказчика, и после проекта у фирмы остались сервер, модель и все материалы.
Базовая модель почти всегда чужая и живёт по своей лицензии. Подрядчик не передаст больше прав, чем получил сам.
Передача ML-артефактов по описи
ML-артефактами (ML значит машинное обучение) называют всё, без чего систему не пересобрать после настройки под ваш процесс. Передача ML-артефактов идёт по описи: фразы «всё лежит в репозитории» мало.
Что бывает без описи, видно по кейсу с чужим внедрением. От прежнего подрядчика остались схема в презентации и переписка в мессенджере, а инструкции модели правили прямо в рабочей системе. Первый месяц ушёл на то, чтобы понять систему, улучшения начались со второго. В описи должно быть:
- Код и схема интеграций с учётными записями.
- Промпты с историей версий и проверочные вопросы с ожидаемыми ответами.
- База знаний в исходном виде и инструкция, как пересобрать поисковый индекс.
- Настройки, журналы и данные панели качества.
- Веса и описание, на каких данных их дообучали.
- Инструкция администратора и разбор типовых сбоев.
Проверка простая: пусть ваш инженер развернёт систему из комплекта на чистом окружении. Понадобился звонок подрядчику, значит опись неполная.
Выход-стратегия: к другому подрядчику или в штат
Выход-стратегия ИИ-проекта нужна не для ссоры. Подрядчик может закрыться или сменить команду, а вы можете решить вести систему сами.
Наш ответ на вопрос «Что будет, когда вы уйдёте?» стоит в своде вопросов: доступы, инструкция, панель качества, две недели в паре. С любым подрядчиком закрепите:
- Срок уведомления и период, когда прежняя команда отвечает на вопросы новой.
- Выгрузку данных, журналов и истории диалогов в читаемом формате.
- Отзыв доступов подрядчика вашими силами, без его участия.
- Кто платит за передачу сверх оговорённого объёма.
- Как отключить сопровождение и без каких штрафов.
Если систему забирают в штат, впишите, кто у вас будет смотреть в панель качества и править базу знаний и сколько недель подрядчик работает с этим сотрудником в паре.
Эскроу: код и модель у третьей стороны
Эскроу, или депонирование: исходный код хранится у независимой третьей стороны и переходит к вам при условиях из договора, например если подрядчик прекратил работу. Эскроу кода модели нужен, когда часть решения остаётся у подрядчика: платформа, общая библиотека, слой работы с моделями. Если весь код и артефакты уже у вас по описи, депонировать нечего. Если нужен, договоритесь о четырёх вещах:
- Что кладут на хранение: код, инструкцию по сборке, промпты, настройки, веса.
- Как часто обновляют копию: после каждого выпуска, иначе через полгода на хранении окажется старая версия.
- Кто проверяет, что из копии система собирается.
- При каких условиях и за какой срок копию выдают вам.
Условия выдачи и выбор хранителя целиком работа юриста. Иногда проще бессрочная лицензия на компонент подрядчика с правом менять его после ухода. Что надёжнее в вашем случае, тоже решит юрист.
Коротко
- Предмет: процесс и цифра, с определением, порогом и планом на случай, если порог не взят.
- Оплата по этапам, у каждого результат на руках и точка выхода.
- NDA до первой выгрузки, в договоре данные, маршрут запросов и запрет обучать чужие модели.
- После запуска: классы ошибок, сроки цифрами, качество по выборке.
- Код, промпты, базу знаний и веса назвать поимённо и передать по описи.
- Выход записать заранее, эскроу нужен, только если часть решения остаётся у подрядчика.
Дальше по теме: этапы проекта от диагностики до надзора и что после каждого остаётся у вас на руках. методология студии→
