IT-договор: Как избежать штрафов и защитить права на продукт

IT-договор: Как избежать штрафов и защитить права на продукт

В INTEKEY мы изучили IT-договоры со всех сторон — от идеального сценария до полного провала. Вместе с нашими партнерами из юридической компании «Зарцын и Партнеры» и основателем Людмилой Харитоновой мы собрали практические решения, которые превратят любой договор в реальный инструмент управления проектами.

Особенно важно сейчас: новые требования 2025 года ужесточили правила игры. Изменения в 152-ФЗ о персональных данных и новые критерии для реестра отечественного ПО значительно повысили риски. В этой статье покажем, как адаптировать договоры к этим вызовам.

Почему стандартные договоры не работают в IT

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

Типичная история: недели на выбор подрядчика, обсуждение технических деталей, согласование бюджета. Кажется, всё готово — и тут договор попадает к юристам. Начинается то, что мы называем «правовой комой». И самое болезненное в ней - последствия:

• Простой команды разработки (от 500 тыс. рублей)
• Упущенные рыночные возможности
• Демотивация команды
• Удар по репутации

Всё дело в разных целях: бизнес хочет быстрее запустить проект, юристы — перестраховаться от всех рисков. В итоге получаются документы, которые защищают на бумаге, но мешают в работе.

Ключевые риски в IT-договорах: на что смотреть в первую очередь

Мы выделили самые опасные зоны, где ошибки в договоре стоят особенно дорого.

Риск №1: Права на интеллектуальную собственность и продукт

Ситуация: вы вложили миллионы в разработку продукта, запустили его, начали получать прибыль — и вдруг получаете иск от настоящего правообладателя. Оказывается, ваш подрядчик использовал чужой код, нелицензионные компоненты или привлек фрилансеров без должного оформления прав на продукт. Результат — многомиллионные убытки, судебные разбирательства и полный запрет на использование продукта.

Это не страшилка, а реальная ситуация, которая случается с компаниями, которые доверяют красивым документам вместо тщательной проверки

Людмила Харитонова, юрист: "Наличие у контрагента свидетельства о регистрации программы в качестве ЭВМ из Роспатента не спасение. При регистрации Роспатент, к сожалению, не проверяет, принадлежат ли права на продукт тому, кто регистрирует программу. Компания, у которой есть красивое свидетельство, по сути, может вообще не владеть правами на программу."

Не надейтесь на документы — проверяйте сами. Вот чек-лист, который спасёт от проблем:

Не надейтесь на документы — проверяйте сами. Вот чек-лист, который спасёт от проблем:

Для штатных разработчиков:

• Работающее «Положение о служебных произведениях»
• Доказательства, что разработчики с ним ознакомлены
• Чёткое описание трудовой функции в договорах
• Процедура проверки лицензий Open Source

Для внешних исполнителей:

• Договоры именно о переходе прав (не лицензия!)
• Конкретное описание объекта в приложениях
• Прописанная стоимость отчуждения прав

Простой тест: попросите показать всю цепочку прав от авторов. Если подрядчик мямлит или предлагает ограничиться свидетельством Роспатента — это тревожный звоночек.

Людмила Харитонова, юрист: "Заказчик заключил договор на доработку и интеграцию продукта. По договору все права к заказчику переходили при подписании акта. Но спустя время к заказчику пришло ООО «Ромашка». Оказалось, что именно эта компания была субподрядчиком на проекте и делала большой блок работ. А вот за это не была получена оплата, и по условиям договора ООО «Ромашка» не передала исключительные права. По сути заказчик, который формально выполнил необходимые условия, оказался нарушителем исключительных прав. В итоге, чтобы не потерять продукт и уже вложенные деньги, заказчик был вынужден заплатить подрядчику и организовать подписание необходимых бумаг."

Что прописать в договоре для защиты:

• Запрет на привлечение субподрядчиков без вашего согласия
• Обязательство подрядчика урегулировать все правовые вопросы перед сдачей продукта
• Реальные финансовые гарантии выполнения этих обязательств

Людмила Харитонова, юрист: "Заказчик, получив права на продукт, начал подготовку к внесению в реестр отечественного ПО. В ходе проверки выяснилось, что значительная часть кода использовала Open Source-библиотеки, запрещенные для включения в реестр. Результат — срочное переписывание кода, многомиллионные затраты и потерянные месяцы."

Дополнительные меры безопасности:

• Требование раскрывать все сторонние компоненты
• Обязательство проверять совместимость лицензий с требованиями Минцифры

Риск №2: Работа с персональными данными и штрафы по 152-ФЗ

Можно сделать технически безупречный продукт — и получить штраф за неправильное обращение с персональными данными.

Помните: отвечать будете вы, а не подрядчик. Именно вы — оператор персональных данных.

Что проверять в первую очередь:

• Наличие в реестре Роскомнадзора
• Соответствие процессов заявленным целям
• Нужные документы на сайте компании

Что стало критически важно с 2025 года по закону 152-ФЗ:

• Данные должны храниться в России
• Обязательное шифрование и регулярный аудит
• Чёткие сроки хранения данных у подрядчика
• Ваше право проверять, как хранятся данные

Простой вопрос, который многое прояснит: «Где физически находятся ваши серверы?». Если в ответ — невнятные формулировки, это повод насторожиться.

Людмила Харитонова, юрист: "Клиент заказал мобильное приложение с регистрацией по email. Оказалось, что подрядчик хранил пароли в открытом виде. Штраф за персональные данные — 300 000 рублей.” Или: “Компания внедрила CRM, которая «на временной основе» передавала данные клиентов на тестовый сервер в другой стране. Нарушение 152-ФЗ — 500 000 рублей."

Что должно быть в договоре:

• Понятная схема обработки данных
• Чёткие обязательства по защите информации
• Ваше право проводить аудиты
• Ответственность подрядчика за штрафы по его вине
• Требование хранить данные россиян в России

Риск №3: Проблемы с Open Source и реестром отечественного ПО

Ужесточение требований к реестру отечественного ПО создало новые сложности. Если ваш продукт использует Open Source с «запрещёнными» лицензиями — дорога в реестр для него закрыта.

Как защититься:

• Требуйте полный список всех Open Source компонентов
• Проверяйте соответствие лицензий требованиям

Людмила Харитонова, юрист: "Заказчик, получив исключительные права на продукт, решил внести его в реестр отечественного ПО. Каково же было его удивление, когда на стадии подготовки выяснилось, что основная часть кода написана с применением Open Source решений, запрещенных для включения в реестр. В итоге пришлось срочно переписывать продукт и потерять еще много миллионов и времени."

Пропишите в договоре:

• Обязательство вести учёт всех используемых компонентов
• Требование проверять лицензионную совместимость

Для облачных решений дополнительно:

• Подтверждение, где физически находятся серверы
• Наличие аттестатов ФСТЭК
• Регулярный аудит безопасности

Что ещё важно учесть? Пункты ниже для некоторых могут показаться очевидными, но мы всё равно о них расскажем — чтобы у вас сложилась полная картина.

Риск №4: Качество технического задания

Знаменитое «нет ТЗ — нет результата» в IT работает без сбоев. Но проблема глубже: даже наличие технического задания не гарантирует успеха, если оно составлено формально, без понимания бизнес-сути проекта.

Типичная ситуация: заказчик мысленно видит одно, исполнитель понимает задачу по-своему, а в результате получается продукт, который технически соответствует документации, но абсолютно бесполезен для бизнеса. Особенно обидно, когда красиво написанный код не решает реальных задач компании.

Часто стороны подписывают ТЗ, не вникая в детали. А когда возникает конфликт, оказывается, что формулировки допускают двойное толкование. Исправить эту ошибку постфактум бывает невозможно.

Что делать на практике:

Для небольших проектов используйте работающую формулировку: «Исполнитель подтверждает, что Техническое задание является исполнимым, не содержит внутренних противоречий и соответствует целям Заказчика». Это перекладывает ответственность за качество ТЗ на подрядчика.

Для сложных проектов не экономьте на фундаменте — выделите разработку детального ТЗ в отдельный оплачиваемый этап. Это не дополнительные расходы, а инвестиция в успех всего проекта. Помните: сэкономите на ТЗ — многократно переплатите на доработках.

Риск №5: Контроль бюджета и сроков

Размывание бюджета — классическая головная боль IT-проектов. Вы заключаете договор на определенную сумму, а через месяц получаете счет с непонятными доплатами. Знакомо?

Где обычно теряются деньги:

• Доработки «на лету» без формального согласования
• Часы работы по тарифам, которых нет в договоре
• Внезапные лицензионные платежи за сторонние компоненты
• Интеграции, которые оказались сложнее, чем предполагалось

Людмила Харитнова, юрист: "Особенно болезненны ситуации, когда заказчик устно просит внести изменения, а потом отказывается их оплачивать. Без письменного подтверждения доказать что-либо практически невозможно."

Как сохранить бюджет под контролем:

Перед началом проекта детально проработайте архитектуру решения и выявите все возможные лицензионные платежи. Закрепите в приложении к договору почасовые ставки всех специалистов — от junior-разработчика до ведущего архитектора. И обязательно заложите бюджетный резерв 10-15% на непредвиденные доработки — они возникают в 90% проектов.

В самом договоре пропишите:

• Четкий регламент согласования дополнительных работ
• Прозрачную систему приемки с дедлайнами для обеих сторон
• Разделение понятий «исправление ошибки» и «новая функциональность»

Риск №6: Эффективный процесс приемки

Типичная ловушка: в договоре прописано, что «работы считаются принятыми, если в течение 5 дней Заказчик не предоставил мотивированный отказ». На практике это приводит к тому, что вы не успеваете все проверить и вынуждены либо подписывать сырой продукт, либо рисковать срывом сроков.

Решение — итеративный подход:

1. Предварительное тестирование — исполнитель передает версию продукта и чек-лист для проверки
2. Формирование реестра замечаний — заказчик фиксирует все недочеты в единой системе
3. Исправление — исполнитель устраняет замечания по согласованному реестру
4. Финальная приемка — после устранения критических замечаний подписывается акт

Такой подход избавляет от ситуации «все плохо, подписывать не буду» и дает четкий механизм движения к качественному результату. Помните: правильная приемка — это не формальность, а последний рубеж контроля качества перед запуском проекта.

Как выстраивать договорные отношения

Наш главный принцип: прежде чем погружаться в юридические детали, просто поговорите с подрядчиком. Честно обсудите ключевой вопрос: «Какую бизнес-задачу мы на самом деле решаем?». Этот диалог помогает перейти от формальных ролей к настоящему партнерству.

Что обсудить на старте:

Начните с главного — соответствия продукта вашим бизнес-потребностям. Технически безупречный продукт, не решающий конкретных задач, становится просто дорогой игрушкой.

Объясните, как сроки связаны с вашими процессами. Когда исполнитель понимает логику ваших дедлайнов, он становится союзником в их соблюдении.

Спросите прямо: «Откуда могут взяться дополнительные 50% к бюджету?» Обсудите возможные доработки, скрытые платежи, сложности интеграции — все, что может повлиять на стоимость.

Убедитесь в чистоте правовой базы продукта. Это особенно важно, если планируете подавать в реестр отечественного ПО.

Проговорите, как будете защищаться от штрафов, в том числе по 152-ФЗ. Определите зоны ответственности и процедуры реагирования на изменения законодательства.

Такой разговор перед заключением договора помогает найти взаимовыгодные решения и заложить основу долгосрочного сотрудничества. В конечном счете договор — не поле битвы, а инструмент для общего успеха.

Учитывайте интересы подрядчика

Договор — улица с двусторонним движением. И подрядчик тоже рискует:

• Теряет деньги из-за простоев
• Страдает от нечётких требований
• Работает в минус из-за неоплаченных доработок

Эффективная стратегия переговоров:

• Ищите взаимовыгодные решения
• Детализируйте этапы работы
• Чётко определяйте условия поддержки
• Заранее обсуждайте интеграционные нюансы
• Устанавливайте процедуры соблюдения нормативов

Ключевые выводы: как сделать договор работающим инструментом

Финализируем ключевые принципы, которые помогут превратить договор из формальности в реальный инструмент управления проектом:

1. Права на интеллектуальную собственность — убедитесь, что подрядчик обладает всеми правами на передаваемые технологии и код. Проверяйте цепочку прав от всех авторов, не ограничиваясь формальными свидетельствами из Роспатента.
2. Соответствие требованиям по персональным данным — помните, что ответственность за нарушения 152-ФЗ лежит на вас как на операторе данных. Требуйте от подрядчика прозрачности в вопросах локализации и защиты информации.
3. Чистота Open Source компонентов — особенно критично при планах внесения в реестр отечественного ПО. Требуйте полный реестр используемых библиотек с проверкой лицензионной совместимости.
4. Качество технического задания — инвестируйте в детальное ТЗ, чтобы избежать фатальных ошибок в договоре. Сэкономив на этом этапе, вы многократно переплатите на доработках.
5. Контроль бюджета и сроков — избегайте размытых формулировок. Каждый пункт договора должен быть измеримым и привязанным к конкретным результатам.
6. Эффективный процесс приемки — детализируйте процессы приемки работ, прописывая не только «что», но и «как» будет организована работа.

Помните: вложения в проработку договора на старте — это не дополнительные расходы, а страховка от многомиллионных убытков и репутационных потерь. Правильно составленный договор сэкономит вам не только деньги, но и нервы, и время всей команды.

Ну и не менее важное: перестаньте воспринимать юриста как «отдел по запретам». Когда вы предоставляете четкий бриф с картой рисков, ТЗ и пониманием бизнес-целей, юридический специалист превращается в ценного советника, который помогает не просто избежать проблем, а выстроить работающую правовую архитектуру проекта.

Такой подход меняет всё: вместо борьбы с формулировками вы получаете договор, который действительно работает на ваш бизнес и защищает ваши интересы на всех этапах сотрудничества.