Договор на разработку ИИ: что должно быть записано

Договор на разработку ИИ-решения отличается от обычного договора на софт одним принципиальным обстоятельством:

> Результат работы вероятностной системы нельзя описать как «работает или не работает». Он описывается долей правильных ответов на согласованном наборе случаев.

Из этого следует всё остальное: критерии приёмки, порядок разрешения споров, распределение ответственности.

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

Главное: критерии приёмки

Самая частая причина конфликтов — приёмка не описана, и спор идёт о том, «хорошо ли работает».

Что должно быть зафиксировано:

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

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

Методика — «Тестирование модели на своей задаче».

Что не гарантируется — отдельным разделом

Раздел, который защищает обе стороны и которого обычно нет.

Что разумно перечислить явно:

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

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

Точки выхода

Этапы с правом прекращения — то, что превращает большой риск в управляемый.

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

Что это даёт подрядчику: он не берёт на себя обязательство по достижимости, которую нельзя проверить заранее.

Подробнее — «Когда остановить ИИ-проект».

Права и передача

Что стоит определить явно:

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

Проверочный набор. Тоже заказчику: он понадобится при любых изменениях и при следующем подрядчике.

Промпты и настройки. Часть решения, и они должны передаваться.

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

Учётные записи и ключи доступа к внешним сервисам оформляются на заказчика. Кажется формальностью до момента смены подрядчика.

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

Разделение ответственности

Раздел, который стоит проговорить до подписания, а не после инцидента.

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

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

Вне зон обеих сторон: вероятностный характер модели, изменение условий поставщика.

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

Разбор — «Кто отвечает за ошибку ИИ».

Эксплуатация и сопровождение

Отдельный раздел или отдельный договор, но не умолчание.

Что зафиксировать:

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

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

Обработка данных

Если в системе обрабатываются персональные данные или сведения ограниченного доступа:

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

Это зона юриста, и подрядчик должен предоставить техническое описание, на основании которого юрист сделает выводы — «Можно ли передавать персональные данные в нейросеть».

Чего в договоре быть не должно

Гарантии безошибочной работы. Невыполнима, и её наличие делает договор непригодным для разрешения спора.

Приёмка «по факту работоспособности» без критериев. Гарантированный конфликт.

Оплата одной суммой без этапов. Лишает точек выхода обе стороны.

Обещание конкретной экономии или окупаемости. Зависит от решений заказчика после запуска, а не от подрядчика.

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

Частые вопросы

Чем договор на ИИ-разработку отличается от обычного?

Критериями приёмки. Результат вероятностной системы нельзя описать как «работает или нет» — он описывается долей верных результатов на согласованном наборе реальных случаев. Из этого следуют и порядок приёмки, и распределение ответственности.

Как описать приёмку?

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

Нужен ли раздел «что не гарантируется»?

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

Что такое точки выхода и зачем они?

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

Что должно остаться у заказчика?

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

Можно ли записать в договор гарантию окупаемости?

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

Что дальше

Что спросить до подписания — «10 вопросов подрядчику» и «Как не переплатить». Кто будет делать работу — «Штат или подрядчик». Как устроены точки выхода — «Когда остановить ИИ-проект». Разделение ответственности — «Кто отвечает за ошибку ИИ».

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