5 реальных юридических рисков в IT-проектах: как теряют деньги разработчики и интеграторы
В 2024–2025 годах резко выросло количество споров в сфере IT: от срывов сроков разработки до недобросовестных заказчиков, не оплачивающих внедрение. Ниже — 5 типовых ситуаций, в которых компании теряли миллионы рублей из‑за юридических ошибок.
❌ 1. Нет акта — нет оплаты. И суд тут ни при чём
Кейс:
ООО «АйТех Групп» поставило заказчику CRM, внедрило интеграции и провело обучение. Сумма — 3,4 млн рублей. Клиент отказался подписывать акт, сославшись на "неполную реализацию" и потребовал доработки. Компания подала иск.
Решение:
Суд (дело № А40-282749/2023) отказал: нет подписанного акта или акта с разногласиями — нет основания для взыскания.
Вывод:
Если заказчик «морозит» акт — сразу направляйте его по почте + зафиксируйте сдачу в ЭДО. Или включайте в договор: акт считается подписанным, если не возвращён с мотивированными возражениями в течение 5 дней.
❌ 2. Техническое задание «на словах» — это путь к проигрышу
Кейс:
Разработчик внедрил кастомную ERP-систему для крупного дистрибьютора. Стороны устно согласовали правки, но в договоре — только общие формулировки. После конфликта клиент заявил: «Не то сделали — платить не будем».
Суд:
АП Санкт-Петербурга (дело № А56-81012/2023) признал, что отсутствие чётко зафиксированного ТЗ не позволяет установить объём работ и обязанность по оплате.
Вывод:
Даже если работа Agile или спринтами — ТЗ/требования должны быть оформлены письменно и подписаны сторонами. Минимум — зафиксировать структуру работ и ключевые результаты.
❌ 3. Программа передана, а права — нет
Кейс:
В договоре купли-продажи ПО между двумя ООО было указано: «Передаётся право использования программы». Но нигде не указано, кому принадлежат исключительные права.
Суд:
АС Москвы (дело № А40-267032/2022) признал сделку недействительной. Передавать можно только то, на что есть права. Без формулировки «исключительные права» + Роспатент/реестр — лицензия ничтожна.
Вывод:
Передача ПО = передача прав по ст. 1225 ГК РФ. Проверяй и регистрируй. В договоре пиши: «исключительное право на программу ___ передаётся заказчику на условиях…» и указывай реестр Роспатента или РКИП.
❌ 4. SaaS без SLA = претензии без защиты
Кейс:
Компания оплачивала 1С:Облако, но при сбое сервера потеряла часть отчётности. Поставщик сослался на "форс-мажор", но договор не содержал гарантий по доступности.
Суд:
АС Урала (дело № А60-385920/2023) признал претензию законной — клиент доказал убытки, а договор был «молчаливым» в части SLA.
Вывод:
SLA — не формальность. Прописывайте:
- % аптайма (например, 99,5%)
- сроки восстановления
- ответственность
- порядок уведомления
❌ 5. Удалили доступ — теперь отвечаете по 272 УК РФ
Кейс:
Бывший подрядчик по IT-поддержке заблокировал клиенту административный доступ к сайту после спора по оплате. Клиент подал не только в суд, но и в полицию.
Итог:
Помимо гражданского дела (А56-120312/2024), возбуждено уголовное дело по ч. 2 ст. 272 УК РФ — неправомерный доступ к информации.
Вывод:
После спора — не трогайте доступы. Всё только через претензию и суд. Любое удаление доступа без решения суда = риск быть признанным виновным в киберпреступлении.
⚖️ Юридические рекомендации от ARMALEX:
- Всегда оформляйте акт, ТЗ, подписанный объём — даже если «всё понятно»
- Указывайте передачу исключительных прав, если речь о ПО
- В SaaS-договорах закрепляйте SLA, сроки, ответственность
- Встраивайте правила взаимодействия при конфликте: порядок урегулирования, сроки ответа
- Проверяйте контрагента в реестрах: много ИТ-шараг открываются «на один проект»
SaaS без SLA: как потерять клиента, деньги и проиграть суд
Сегодня многие IT-компании продают SaaS как подписку: облачный доступ, автопродление, удалённая поддержка. Но большинство не оформляет ключевое — SLA (Service Level Agreement). А без него любые сбои, простои и даже лаги — это ваша ответственность. Ниже — реальные кейсы и чёткие рекомендации от юристов.
⚖️ Что такое SLA
SLA — это юридически обязательный регламент качества SaaS-услуги, включающий:
- % доступности (аптайм)
- максимальное время простоя
- сроки реакции на инциденты
- компенсации за нарушение
- порядок фиксации инцидентов
Это не просто маркетинг — это инструмент защиты в суде по ст. 309, 314, 723 ГК РФ.
❌ Судебная практика: SaaS без SLA = риск
Дело № А40-119548/2024 (АС г. Москвы)
Клиент арендовал доступ к облачной системе документооборота. В договоре — ни слова о SLA. Сервис лежал 2 дня — клиент потребовал компенсацию. Поставщик сослался на «форс-мажор» и «техническую особенность сервиса».
Решение:
Суд встал на сторону клиента: отсутствие SLA не освобождает от ответственности. Нарушение доступности = некачественное оказание услуги.
✅ Как правильно оформлять SLA
Структура SLA-документа:
- Аптайм:
«Гарантированный уровень доступности — 99,5% в месяц»
- Регламент реакции:
«Реакция на критический инцидент — 2 часа, восстановление — 6 часов»
- Компенсация:
«За каждые полные 2 часа простоя — продление подписки на 1 день»
- Фиксация инцидента:
«Факт сбоя подтверждается логами, доступными обеим сторонам»
- Исключения:
Плановые обновления, действия третьих лиц, аварии дата-центров
- Предел ответственности:
«Максимальная сумма убытков ограничена месячной стоимостью подписки»
📌 Где SLA должен быть закреплён?
- В теле договора (если короткий проект)
- Как Приложение к лицензионному или SaaS-договору
- Ссылка на публичную оферту (если массовый сервис)
