Обновить

Акт подписан, но система не работает:  суд вернул 185 млн 

В IT-проектах бытует мнение: если промежуточный акт подписан, деньги за этап не надо возвращать. Арбитражное дело, дошедшее до Верховного суда России, показало обратное.

Заказчик оплатил первый этап работ на 185,9 млн рублей, но программное обеспечение (ПО)  так  и не заработала в нужных режимах. Суд расторг контракт и взыскал всю сумму с Исполнителя, указав на отсутствие потребительской ценности результата. Разбираем, почему подписанные промежуточные акты не гарантируют оплату и какие выводы должны сделать заказчики и исполнители, чтобы не повторить эту историю.

Суть дела

Между Заказчиком и Исполнителем был заключён контракт на создание сложной информационной системы. За первый этап работ Заказчик оплатил Исполнителю 185,9 млн руб. Однако в ходе дальнейшей реализации проекта выяснилось, что система не обеспечивает требуемый функционал и не может использоваться по назначению.

Проблема

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

Решение суда

Апелляционный суд расторг  контракт и взыскал с Исполнителя 185,9 млн руб. неосновательного обогащения и почти 4 млн руб. неустойки. Кассационный суд  и Верховный Суд РФ поддержали этот вывод. Суды указали на отсутствие для Заказчика потребительской ценности результата работ и недоказанность полноценного встречного предоставления на перечисленную сумму.

Что делать, чтобы не повторилась ситуация

Для Заказчика:

· Включайте в контракт условие о потребительской ценности как критерии приёмки: не просто «акт подписан», а «система работает в заданных режимах, согласно ТЗ».

· Прописывайте право не подписывать финальный акт до подтверждения работоспособности системы в реальных условиях.

· Фиксируйте в договоре конкретные сценарии использования и метрики, по которым будет проверяться результат.

· Проводите независимую экспертизу до подписания итогового акта.

 

Для Исполнителя:

· Не полагайтесь на подписанные промежуточные акты как на гарантию оплаты — суд смотрит на итоговый результат.

· Перед сдачей этапа убеждайтесь, что функционал соответствует технической документации и может быть проверен Заказчиком.

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

· Включайте в договор ограничение ответственности по объёму и срокам, если это возможно.

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

Провожу анализ ситуации на стыке IT, права и финансов.

Пишите @RRSadykov

 

 

Теги:
0
Комментарии0

Я перестал пользоваться самыми умными ИИ‑моделями. Программировать стало быстрее и дешевле

В отпуске есть время подумать и исследовать. Я натолкнулся на несколько вещей и открытий для себя. Оказалось, что мне как программисту перестали быть нужны самые умные и дорогие ИИ‑модели. Оказывается, есть такой параметр «Cost per Task», и по этому параметру на первое место вырвалась модель GPT-5.6 Luna (max).

При этом, если вы пользуетесь Codex, она самая тупая в списке моделей. Artificial Analysis Intelligence Index у нее всего 38. Для сравнения, у самой умной GPT-6 Astra (max) этот индекс равен 53. В итоге цена выполненной Luna задачи составляет $0.18 против $3.26 у Astra. Разница почти в 20 раз.

Как я понимаю, бенчмарк «Cost per Task» высчитывается так: когда ставится нормальная, грамотно описанная задача, замеряется, сколько токенов было потрачено на ее выполнение. То есть не в формате «из ХЗ сделаю ТЗ», а в формате, когда в хорошо заданном вопросе уже содержится половина ответа.

Я сначала не поверил, что так и есть, и стал работать, используя самую тупую модель Luna в линейке. И знаете, какие меня ожидали результаты?

Я перестал пользоваться самыми умными ИИ‑моделями. Программировать стало быстрее и дешевле

Публикации