Юристы VS нейросеть: кто победит?
Месяц назад мы провели вебинар с громким названием «Юристы VS нейросеть» на котором юрист и сервис Noroots оценили договор на разработку программного продукта и дали свои комментарии.
Цель проверить – может ли нейросеть быть эффективной в работе и как юристам ее применять.
Сначала о договоре на разработку
Для проверки мы взяли договор на разработку программного продукта. В IT этот договор используется часто и умение его корректно анализировать важно как исполнителям, так и заказчикам.
Вот некоторые пункты, которые нужно иметь ввиду работая с таким договором:
A. Вид договора
При заключении договора на длительную, масштабную разработку рекомендуется заключать договор подряда. Положения главы 37 ГК РФ содержат наиболее детальное регулирование вопросов создания определенного результата по заданию заказчика. Общие положения о подряде вполне соответствуют специфике отношений, связанных с созданием программного обеспечения.
В судах сложилось три возможных варианта квалификации договоров на разработку ПО:
- договор возмездного оказания услуг;
- договор подряда;
- смешанный договор (который содержит элементы и договора подряда, и договора оказания услуг).
Обратите внимание! Часто квалификация в качестве договора оказания услуг связана с наименованием сторон и терминологией (которые присущи договору оказания услуг). Не допускайте одновременное использование терминов «работы» и «услуги».
В случае использования договора подряда используйте наименование сторон «Подрядчик» и «Заказчик».
В случае использования договора подряда используйте наименование сторон «Исполнитель» и «Заказчик».
С физическим лицом также возможно заключение договора авторского заказа.
B. Предмет договора
В договоре следует конкретизировать ключевые особенности разрабатываемого ПО.
Желательно описать функциональные и иные характеристики продукта, требования к программной совместимости в техническом задании (рекомендуется, чтобы техническое задание соответствовало ГОСТ).
При масштабной разработке разработку технического задания рекомендуется выделять в отдельный этап.
Необходимо указать его наименование и все значимые характеристики. Согласно Постановлению ФАС ЗАПАДНО - СИБИРСКОГО ОКРУГА от 13 мая 2009 г. N Ф04-2055/2009(3997-А70-38) отказывая в удовлетворении иска о расторжении муниципального контракта, арбитражный суд первой инстанции исходил из того, что контракт является незаключенным по причине отсутствия между сторонами соглашения о его предмете.
Суд пришел к выводу, что отсутствие проектно-сметной документации, содержащей перечень и объем работ, не позволяет определить предмет договора.
C. Требования к ПО
- техническое задание;
- порядок согласования дополнительных элементов;
- возможность использования Open Source. Укажите каким образом разработчик может использовать подобные решения. Рекомендуется составлять по итогам разработки полный перечень подобных элементов.
Вы можете скачать полный чек-лист для проверки своего договора здесь: скачать
А как проверяет договоры Noroots:
Даже из нескольких пунктов чек-листа становится понятно – проверка договора не всегда простая задача. В нем много нюансов (которые отличаются от того, на чьей стороне вы выступаете, какая разработка ведется и т.д.).
Noroots может проверить договор на соответствие законодательству, отраслевым стандартами (которые пополняются) и на правила, которые пользователь сам задаст системе.
Итак, что нашла система в договоре:
- выловила, что нет технического задания и нет порядка его согласования. Это вечная проблема: бизнес часто не хочет тратить время на «подготовительные работы» и писать сложные ТЗ. А дальше мы помним: нет ТЗ – результат ХЗ;
- обратила внимание на то, что порядок приемки не описан. В договоре было указано как подписывается акт, но опущен процесс непосредственной приемки результата работ. Это можно допустить в случае, когда разработка не существенная (тогда перед принятием акта заказчик все успеет проверить). Но если речь идет о масштабной разработке, то в договоре нужно описать порядок тестирования, исправления ошибок и т.д.;
- оценила как прописан раздел ответственности и дала рекомендации усилить ответственность исполнителя;
- напомнила нам, что в договоре не стоит смешивать «работы» и «услуги»;
- дала рекомендации о важности определения того, что считать недостатком. Вот так выглядят рекомендации.
Как проверяет договор юрист:
Кто-то работает по чек-листам и своим стандартам, а кто-то без них. Но у юристов (как и ИИ) есть свой алгоритм, который позволяет проверить договор.
1. Выясняем на чьей мы стороне;
2. Выясняем какой результат должен получиться и требования к нему;
3. Определяем свои риски (они как раз зависят от того – мы юристы заказчика или исполнителя);
4. Проверяем в договоре:
- корректно ли выбран вид договора;
- есть ли существенные условия;
- как сформулирован предмет (понятно ли к какому результату должны прийти стороны);
- как описаны требования к продукту;
- какие элементы (в том числе Open Source) могут быть использованы при разработке и каков порядок (условия);
- есть ли сроки на основные действия и ответственность за нарушение;
- как выстроен процесс оплаты? (есть ли ответственность за нарушение оплаты);
- кому и в каком объеме переходят исключительные права на продукт;
- как передается продукт заказчику и осуществляется приемка;
- что делать, если продукт не соответствует требованиям;
- как поступить, если сроки существенно нарушены или исполнитель отказался от проекта;
- как будет осуществляться техническая поддержка
Так кто круче?
Noroots проверила договор за 2 минут, у юриста уйдет минимум 40-60 мин на первичную проверку.
Но юрист лучше понимает бизнес-контекст и требования бизнес-заказчика.
При этом сократив время на первичную обработку договора у него останется больше времени на понимание насколько правки и договор вообще вписывается в этот бизнес-контекст.
Поэтому вывод простой – юрист и нейросеть могут стать отличной командой.
Еще больше кейсов для IT-юристов и фаундеров проектов в нашем ТГ канале: