AI и ML
Договор на внедрение ИИ: KPI по точности, ответственность за ошибки и права на модель
Договор, скопированный с обычной разработки ПО, не отвечает на вопросы, которые возникают именно с ИИ: что считать ошибкой модели и кто отвечает, если агент дал неверный ответ клиенту.
Коротко
Типовой договор на разработку ПО не покрывает три специфических для ИИ-проекта вопроса: как измеряется и что считается приемлемым порогом точности ответов, кто несёт ответственность, если ошибка модели привела к убытку или неверной информации для клиента, и кому принадлежат дообученная модель, промпты и база знаний после завершения работ. Каждый из этих пунктов стоит прописывать явно и заранее — по умолчанию закон и обычные шаблоны договоров не дают однозначного ответа ни на один из них.
Почему обычный шаблон здесь не работает
Договор на разработку сайта или приложения строится вокруг понятного критерия приёмки: функция либо работает по техническому заданию, либо нет. ИИ-система устроена иначе — она не даёт стабильно одинаковый результат на одинаковый запрос, и «работает правильно» — вероятностная, а не бинарная характеристика. Договор, не учитывающий эту разницу, оставляет обе стороны без чёткого критерия, что вообще считается выполненной работой.
Три пункта, которые нужно прописать отдельно
| Пункт | Что фиксирует |
|---|---|
| KPI по точности | Метрика точности, методика измерения и приемлемый порог, привязанный к оплате финального этапа |
| Ответственность за ошибки | Кто отвечает за убыток от неверного ответа модели: подрядчик, заказчик или разделённая ответственность по типу ошибки |
| Права на модель и данные | Кому принадлежат дообученная модель, промпты, база знаний и конфигурация после завершения проекта |
Как измерять точность так, чтобы это было проверяемо
Точность ответов ИИ-системы измеряется на заранее согласованном тестовом наборе реалистичных вопросов с известными правильными ответами, а не субъективным ощущением «выглядит неплохо» на нескольких примерах во время демонстрации. Договор должен фиксировать: кто составляет тестовый набор (лучше — обе стороны совместно, чтобы избежать предвзятости), какой процент правильных ответов считается приемлемым порогом, и что происходит, если порог не достигнут — доработка за счёт подрядчика, а не автоматическая оплата как за завершённый этап.
Ответственность за ошибки: разделение по типу, а не общая формулировка
Общая формулировка «подрядчик не несёт ответственности за результаты работы ИИ-системы» — красный флаг, а не стандартная практика: она перекладывает весь риск на заказчика, включая случаи, когда ошибка вызвана объективно плохой архитектурой или недостаточным тестированием со стороны подрядчика. Рабочий подход — разделение ответственности по типу ошибки: подрядчик отвечает за системные сбои и ошибки, выявляемые на согласованном тестовом наборе; заказчик — за качество и полноту исходных данных, которые он предоставил для обучения или настройки системы.
Права на модель: что именно нужно назвать явно
По умолчанию, если договор молчит на этот счёт, права на дообученную модель, промпты и базу знаний могут остаться неоднозначными или де-факто у подрядчика — особенно если вся система развёрнута на его собственной инфраструктуре. Заказчику стоит явно прописать: право на получение копии всех промптов, конфигураций и базы знаний в переносимом формате, и, если применимо, право на дообученные веса модели — до подписания договора, а не в момент, когда решение сменить подрядчика уже принято и стало срочным.
Частые вопросы
Почему обычный договор на разработку ПО не подходит для ИИ-проекта?
Потому что он строится вокруг бинарного критерия приёмки («работает или нет»), тогда как ИИ-система даёт вероятностный, не всегда одинаковый результат. Без отдельно прописанных KPI по точности, ответственности за ошибки и прав на модель обе стороны остаются без чёткого критерия завершённости работы.
Как правильно измерять точность ИИ-системы в договоре?
На заранее согласованном тестовом наборе реалистичных вопросов с известными правильными ответами, а не по субъективному впечатлению от демо. Договор должен фиксировать, кто составляет тестовый набор, какой процент правильных ответов приемлем, и что происходит при недостижении порога.
Что должно насторожить в пункте об ответственности за ошибки?
Общая формулировка о полном отсутствии ответственности подрядчика за результаты работы ИИ-системы — это красный флаг, перекладывающий весь риск на заказчика. Рабочий подход — разделение ответственности по типу ошибки: подрядчик отвечает за системные сбои, заказчик — за качество предоставленных исходных данных.
Кому принадлежит обученная модель, если в договоре об этом ничего не сказано?
По умолчанию это может остаться неоднозначным или де-факто перейти подрядчику, особенно если система развёрнута на его инфраструктуре. Права на промпты, базу знаний и конфигурацию в переносимом формате стоит прописывать явно до подписания договора, а не постфактум при смене подрядчика.
Нужна помощь с этой задачей?
Мы делаем это на практике, а не только пишем об этом. Опишите задачу — разберём и пришлём смету по этапам.
Услуги по теме
- AI-стратегия для бизнесаБольшинство компаний уже запустили хотя бы один пилот с ИИ. Меньшинство довело хоть один пилот до устойчивой эксплуатации. Разница обычно не в модели, а в том, выбрали ли процесс с измеримым эффектом и посчитали ли реальную стоимость эксплуатации до старта. Мы помогаем выбрать правильную точку входа и не потратить бюджет на демо, которое так и останется демо.
- IT-консалтинг и продуктовый аудитСамые дорогие ошибки в разработке делаются до первой строчки кода: неверно понятая задача, стек, выбранный по привычке подрядчика, и ТЗ, которого нет. Консалтинг нужен, чтобы разобраться до того, как начнётся счётчик разработки: что именно строить, из чего, за сколько и в каком порядке. Результат — документ, а не мнение на созвоне.
- Разработка AI и ML-решенийМы делаем AI, который решает конкретную задачу и окупается, а не демо ради демо. Классификаторы, рекомендации, обработка текста и документов, ассистенты на LLM, интеграция моделей в существующий продукт.
Читать дальше
- Как отличить разработку ИИ-агента от обёртки над чужим APIВнешне готовый бот на чужом API и полноценная кастомная разработка выглядят одинаково на демонстрации. Разница видна только в вопросах, которые мало кто задаёт.
- Как выбрать подрядчика на разработку: чек-лист вопросов и красные флагиПрактическое руководство по выбору подрядчика: кому подходит фрилансер, а кому интегратор, какие 25 вопросов задать на первом созвоне, как проверить кейсы в портфолио и что обязательно должно быть в договоре.
- Технический due diligence перед инвестициями или покупкой бизнесаRed flag в кодовой базе не всегда убивает сделку — чаще он меняет цену, эскроу или обязательства после закрытия. Разбираем, что проверяется и почему спешка под давлением сроков сделки вредит именно находкам.