Суть. Классический договор на программное обеспечение не покрывает решения на моделях: там результат вероятностный, поставщик меняет базовую модель без согласования, а данные заказчика могут стать частью обучения. Появился отдельный набор пунктов, который теперь обсуждается в каждой такой сделке.
Пункты, которые обсуждаются
| Пункт | Что фиксируется | Почему это важно |
|---|---|---|
| Использование данных | Данные заказчика не идут в обучение общих моделей | Обратно из модели их не извлечь |
| Место обработки | Где физически обрабатываются запросы | Хранение локально не равно обработке локально |
| Смена версии модели | Уведомление и право проверить качество до перехода | Поведение меняется без вашего участия |
| Качество | Измеримый критерий и что происходит при недостижении | «Работает корректно» неприменимо к вероятностному ответу |
| Ответственность за вывод | Кто отвечает, если по ответу приняли неверное решение | Обычно перекладывается на заказчика — это нужно видеть |
| Права на результат | Кому принадлежит созданное с помощью системы | Влияет на дальнейшее использование |
| Выход | Возврат данных и что остаётся у поставщика | Настройки и накопленный контекст тоже актив |
Как этим пользоваться в сделке
Для поставщика это возможность выиграть без спора о цене: заказчик с зрелой юридической службой оценивает готовность отвечать на эти вопросы выше, чем скидку. Для покупателя это чек-лист, по которому видно, продумал ли поставщик эксплуатацию или продаёт демонстрацию.
Чем отличается от обычного договора на ПО
Классический договор описывает функциональность и доступность. В договоре на решение с моделями появляются три темы, которых там не было: чьи данные и что с ними происходит, кто отвечает за неверный ответ и что будет при смене модели поставщиком.
Семь пунктов, которые нужно закрыть
| Пункт | Что должно быть написано |
|---|---|
| Использование данных | Прямой запрет на обучение на ваших данных или явное согласие с условиями |
| Размещение обработки | Страна и площадка; для регулируемых отраслей — обязательный пункт |
| Хранение запросов | Срок хранения и возможность его обнулить |
| Смена модели | Уведомление заранее и право проверить качество на своём наборе задач |
| Качество | Метрика и способ замера; «наилучшие усилия» без цифры не работает |
| Ответственность за результат | Кто отвечает за ущерб от неверного ответа и в каком объёме |
| Выход | Возврат данных в машиночитаемом виде и срок удаления копий |
Четвёртый пункт недооценивают чаще остальных. Поставщик меняет модель под капотом — и качество на ваших задачах меняется без предупреждения, а формально всё в порядке.
Что спросить до подписания
- На чьей инфраструктуре выполняется обработка и можно ли это проверить?
- Что происходит с запросами, содержащими персональные данные?
- Как вы уведомляете об изменении модели и её версии?
- Какие показатели качества вы готовы зафиксировать и как их мерить?
- Что мы получаем при расторжении и в каком формате?
- Кто отвечает, если система выдала неверный ответ и на его основании принято решение?
Отсутствие внятного ответа на шестой вопрос — не повод отказываться от сделки, но повод оставить человека в контуре проверки.
Где ломается
Пункты берут из шаблона на обычное ПО. Тогда специфика решения не покрыта, и спор возникает при первом же неверном ответе.
Обещают точность в процентах. Без описанного набора проверок такое обещание невыполнимо и опасно.
Не описывают выход. Через два года смена поставщика оказывается дороже, чем терпеть.
- Договор берут типовой на ПО. Все три специфические темы остаются неурегулированными.
- Проверка качества не описана. Спорить о «плохих ответах» без согласованного набора задач невозможно.
- Не учтены субподрядчики поставщика. Данные могут уходить дальше, чем предполагает заказчик.
- Нет плана выхода. Через год выясняется, что накопленные материалы невозможно забрать.