Хабр, привет!

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

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

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

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

Вспомните типичный сценарий: месяц уходит на выбор подрядчика, обсуждение технических деталей, согласование бюджета. И когда кажется, что все сложности позади, договор отправляется юристам... и проект погружается в то, что мы называем "правовой комой". А у этой комы есть вполне конкретная цена:

• Простой команды разработки (от 500 тыс. рублей)

• Упущенные рыночные возможности, которые не вернешь

• Демотивация специалистов, которых держат в неопределенности

• Репутационные потери — клиент теряет доверие

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

Подводные камни, которые превращают договор в мину замедленного действия:

За годы работы мы выработали системный подход к оценке подрядчиков. Вот три ключевых капкана, которые должны стать вашим чек-листом при выборе исполнителя. Спойлер: если он не проходит эту проверку — бегите. Потому что завтра может быть уже поздно.

Камень №1(даже булыжник): Права на продукт - штраф до 5 млн руб + запрет на использование

Это самый опасный участок. Вы платите миллионы за продукт, а через год выясняется, что он написан на украденном коде или использует «запрещенный» Open Source.

Но как вообще такое возможно? Казалось бы, нужно просто запросить свидетельство о регистрации программы из Роспатента. Однако это — опасное заблуждение, которое создает ложное чувство безопасности.

Почему свидетельство из Роспатента не работает:

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

Что же делать в такой ситуации? Не доверяйте красивым бумагам — проводите собственную проверку. Вот простой чек-лист, который займет всего 5 минут, но спасет вас от миллионов убытков:

Сценарий А: Штатные разработчики

• Есть ли в компании «Положение о служебных произведениях»?

• Все ли разработчики ознакомлены с ним под роспись?

• Есть ли в трудовых договорах пункт о том, что написание кода — трудовая функция?

• Проверяются ли лицензии Open Source?

Сценарий Б: Фрилансеры/подрядчики

• Есть ли договоры с пунктом о ПЕРЕХОДЕ прав (не лицензия)?

• Идентифицирован ли объект в Приложении?

• Выделена ли стоимость отчуждения прав?

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

Чем это грозит на самом деле? 

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

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

Чтобы избежать подобных ситуаций, мы рекомендуем включать в договор следующие пункты:

• Запрет на привлечение субподрядчиков без письменного согласования с заказчиком (или как минимум — обязательное уведомление).

• Обязательство исполнителя за свой счет «очистить» все права перед передачей продукта заказчику — то есть урегулировать все взаимоотношения с авторами и правообладателями. Это положение должно быть подкреплено реальными финансовыми гарантиями.

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

Что прописать в договоре, чтобы избежать подобного:

• Требование к исполнителю раскрывать полный перечень всех используемых сторонних компонентов (включая Open Source) и вести их учет

• Обязательство исполнителя проверять лицензии на совместимость с требованиями реестра Минцифры — особенно если вы планируете или не исключаете такую возможность в будущем

Чем грозит отсутствие выстроенной цепочки прав:

• Иск со стороны действительного правообладателя (репутационный удар + судебные издержки)

• Штрафы до 5 000 000 рублей по требованию регулятора

• Самое критичное — запрет на использование продукта. В этом случае все вложения в разработку становятся бессмысленными.

Камень №2: Персональные данные — как не получить штраф вместо IT-решения

С персональными данными в IT-проектах история особая: можно сделать хороший продукт, но получить штраф за то, что данные «не там хранились» или «не так передавались».

Кто несет ответственность в конечном счете? Отвечать будете вы, а не подрядчик — по закону оператором персональных данных являетесь именно вы. Нарушения могут быть как внутри продукта, так и у самого подрядчика.

С чего начать проверку? Вот что нужно проверять с учетом новых требований 152-ФЗ:

• Наличие в реестре Роскомнадзора в качестве оператора

• Соответствие собираемых данных заявленным в реестре

• Наличие на сайте компании согласий на обработку ПДн и политики обработки

Но это только первый шаг. Новые требования 2025 года ужесточили правила игры. Вот что стало критически важным:

• Персональные данные должны быть локализованы на территории РФ

• Обязательства по защите — шифрование, регулярный аудит безопасности

• Четкие сроки хранения данных у подрядчика

• Права на проверку — вы должны иметь возможность проконтролировать, как хранятся данные

Как перевести эти требования в практическую плоскость? Задайте конкретный вопрос: "Где физически ваши серверы?" Если в ответ звучат размытые формулировки — это повод насторожиться.

Чем рискуете в реальности? 

Людмила Харитонова, юрист:

• “Клиент заказал мобильное приложение с регистрацией по email. Оказалось, что подрядчик хранил пароли в открытом виде. Штраф — 300 000 рублей.

• Компания внедрила CRM, которая «на временной основе» передавала данные клиентов на тестовый сервер в другой стране. Нарушение 152-ФЗ — 500 000 рублей.”

Что должно быть в договоре и в логике IT продукта с учетом последних изменений законодательства:

• Прозрачная схема обработки данных — где, как и кто имеет доступ

• Обязательства по защите — шифрование, регулярный аудит безопасности

• Права на проверку — вы должны иметь возможность проконтролировать, как хранятся данные

• Ответственность подрядчика — кто платит штрафы, если нарушение по его вине

• Условия о локализации баз данных российских граждан на территории РФ

Камень №3: Open Source ловушки — проблемы с реестром отечественного ПО

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

Как защититься от таких сюрпризов? Требуйте от подрядчика полной прозрачности: "Предоставьте список всех Open Source компонентов". Не ограничивайтесь общими фразами — нужен детализированный перечень с указанием версий и лицензий.

Что происходит на практике? 

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

Как закрепить это в договоре? Пропишите конкретные обязательства:

• Включите в договор требование сообщать об используемых элементах и вести их учет

• Добавьте обязательства исполнителя проверять лицензии на используемые продукты и их совместимость с реестром отечественного ПО

Особый случай — облачные решения:
Если подрядчик предлагает "облако", уточните:

• Физическое расположение серверов (для 242-ФЗ)

• Имеются ли FSTEC-аттестаты

• Проводится ли регулярный аудит безопасности

Разобравшись с юридической чистотой ПО и защитой персональных данных, вы устранили главные риски, способные привести к многомиллионным штрафам и полной остановке бизнеса. Именно эти два пункта требуют максимального внимания при проверке подрядчика.

Остальные разделы договора — хотя и не менее важные — обычно более очевидны для заказчиков. Но для полноты картины обозначим и их, чтобы вы ничего не упустили при согласовании документов.

Камень 4: ТЗ — фундамент проекта

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

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

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

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

Камень 5: Бюджет и сроки — почему итоговая сумма всегда больше

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

Где теряются деньги:

• Доработки "на лету" без формального согласования

• Часы по тарифам, которых нет в договоре

• Внезапные лицензионные платежи за сторонние компоненты

• Интеграции, которые оказались сложнее, чем предполагалось

Поэтому перед началом любого проекта советуем:

• Детально проработайте архитектуру решения и выявите все возможные лицензионные платежи

• Зафиксируйте в приложении к договору почасовые ставки всех специалистов

• Заложите бюджетный резерв 10-15% на непредвиденные доработки

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

• Четкий регламент согласования допработ — любое изменение требует формального подтверждения

• Прозрачную систему приемки работ с дедлайнами для обеих сторон

• Разделение понятий "исправление ошибки" и "новая функциональность"

Камень 6: Приемка работ — как не застрять в цикле

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

Решение — итеративный процесс:

1. Предварительное тестирование — исполнитель передает версию и чек-лист

2. Формирование реестра замечаний — заказчик фиксирует ошибки в трекере

3. Исправление и повторная подача — исполнитель исправляет по реестру

4. Финальная приемка — после устранения критических замечаний

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

Что на самом деле должно волновать в договоре

Мы для себя определили одну простую вещь, которая изменила подход к договорам: прежде чем нести документ юристам, отложите эту стопку бумаг и просто сядьте поговорить с подрядчиком. Без формальностей, без оглядки на юридические тонкости. По-человечески спросите: "Какую бизнес-проблему мы на самом деле решаем?"

Этот разговор почти всегда вскрывает важные моменты. Вот 5 ключевых вопросов, которые стоит задать до того, как позовете юристов:

1. Что будет, если технически безупречный продукт окажется бесполезным для бизнеса?

Представьте: код блестящий, архитектура продумана, но... WMS не заточена под ваши воронки продаж, а складская система не понимает сезонность. Бизнес-проблема не решена, хотя формально все сделано правильно.

2. Как сроки проекта связаны с реальными бизнес-процессами?

Каждый день просрочки — это не просто цифра в графике. Это упущенные деньги, возможности, а иногда — демотивированная команда. Причем промежуточные этапы часто важнее финального дедлайна.

3. Где в бюджете могут появиться дополнительные 50%?

Это вечная головная боль: доработки "на лету" без изменения цены, часы по непонятным тарифам, вечные споры — "это баг или новая фича?". Бюджет размывается, а понятных механизмов контроля нет.

4. Кто ответит за чужой код?

Что будет, если через полгода после запуска продукт заблокируют из-за лицензионных проблем? Кто ответит за Open Source с "интересными" лицензиями, кодами фрилансеров без подходящих прав и, главное, за плачевные последствия - штрафы, суды, полную остановку бизнеса?

5. Что защитит от штрафов в миллионы?

Нарушения в области персональных данных, несоответствие требованиям к отечественному ПО — это не только финансовые санкции. За нарушения 152-ФЗ штрафы для юрлиц достигают 6 млн рублей, а по 187-ФЗ — до 1 млн рублей за несоответствие критериям отечественного ПО.

Win-win подход: проблемы и шерифа и индейцев

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

Сроки: команда под проект выделена, ресурсы подсчитаны — каждый день простоя из-за задержек с согласованием это прямые убытки.

Бюджет и размывание задач: миф о том, что исполнитель всегда хочет надуть бюджет, не соответствует действительности. Чаще наоборот: когда заказчик бесконечно тянет с согласованием, требует доработок без изменения сроков, проект уходит в минус.

Размытое ТЗ — это уже общий враг, который бьет по обеим сторонам. Без четких границ страдают все: заказчик не получает нужный продукт, исполнитель — нормальную оплату.

Как превратить разговор в конструктивное русло

Чтобы обсуждение не превратилось в торги, где каждый тянет одеяло на себя, предлагаем простой подход: сформулируйте эти вопросы не как претензии, а как поиск взаимовыгодных решений. Например: "Давайте вместе подумаем, как нам построить процесс, чтобы ваша команда не простаивала, а мы получали качественный продукт вовремя".

Прежде чем передавать договор юристам, сядьте с подрядчиком и обсудите по пунктам:

• Промежуточные сроки по этапам работ — какие вехи действительно важны для бизнеса, а какие можно скорректировать

• Конечный срок сдачи проекта — что он включает: только разработку или также тестирование и запуск

• Условия технической поддержки после внедрения — кто, как и сколько отвечает, как быстро реагирует на проблемы

• Возможность интеграции продукта с вашими системами — технические нюансы, которые лучше обсудить "на берегу"

• Конфиденциальность передаваемых данных — что можно передавать, что нельзя, в каком виде

• Чистота прав на продукт со стороны исполнителя — какие гарантии он может предоставить

• Отечественное происхождение ПО (при необходимости) — какие документы это подтверждают

• Соблюдение законодательства о персональных данных — какие процедуры обеспечат защиту.

Итоги: Договор, который работает на вас

Договор в IT — это не пыльная формальность для юристов, а ваш главный инструмент управления проектом. Правильно составленный, он не создает бюрократии, а расчищает путь к результату.

Короткий план действий, который сэкономит вам нервы и деньги:

1. Начните с сути, а не с шаблонов. Прежде чем нести документ юристам, сядьте с подрядчиком за один стол. Обсудите не пункты договора, а ваш чек-лист ключевых рисков.

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

3. Избегайте размытых формулировок. Сроки, стоимость, обязанности — всё должно быть измеримо и привязано к конкретным пунктам.

4. Не верьте на слово, проверяйте права. Для серьезных проектов не ограничивайтесь свидетельством из Роспатента. Проведите Due Diligence — убедитесь, что не покупаете «кота в мешке» с проблемным кодом.

5. Пропишите не только «что», но и «как». Четкий регламент — лучшая профилактика конфликтов. Как вносить правки в ТЗ? Как заказывать допработки? Как проходит приемка?

Потратив несколько дополнительных дней на проработку договора на старте, вы делаете не рутину, а выгодную инвестицию. Вы покупаете страховой полис от многомиллионных убытков и проваленных дедлайнов.

P.S. Ваш юрист — не цензор, а партнер. Но ему нужен бриф: карта рисков, ТЗ и понимание бизнес-целей. С таким подходом он станет вашим стратегическим советником, а не "отделом по запретам".

А у вас были случаи, когда «невинная» формулировка в договоре оборачивалась большой проблемой? И наоборот — когда вовремя прописанный пункт спасал проект? Делитесь в комментариях, обсудим.