Почему права на код и дизайн критичны в 2026 году: риски потери доступа
В 2026 году рынок цифровых сервисов стал более фрагментированным: компании используют в среднем 12–15 SaaS-решений одновременно. Каждый такой сервис — это чужой код, чужая инфраструктура и чужие дизайн-макеты. Если подрядчик прекращает поддержку или блокирует доступ, бизнес оказывается перед фактом: продукт работает, но развивать его невозможно.
Основные риски, с которыми сталкиваются заказчики:
1. Потеря исходного кода. Без исходников невозможно провести аудит, исправить ошибки или адаптировать продукт под новые требования. По нашему опыту, каждый третий запрос на миграцию связан именно с этой проблемой.
2. Блокировка интеграций. API-ключи, webhook-адреса и токены доступа к сторонним сервисам остаются у подрядчика. При расторжении договора все интеграции «падают» одновременно, а восстановление занимает от 2 до 6 недель.
3. Потеря дизайн-макетов. Figma-проекты, UI-киты и прототипы — это интеллектуальная собственность, которая не всегда передаётся по умолчанию. Без макетов невозможно продолжить работу с другим дизайнером без полного ребренда.
4. Нарушение сроков вывода продукта. Если подрядчик задерживает передачу кода, каждый день простоя обходится бизнесу в среднем от 50 000 до 150 000 ₽ в зависимости от масштаба проекта и отрасли.
> По статистике СРО «Альянс IT-компаний», в 2025 году более 28% судебных споров в сфере разработки ПО были связаны с непередачей исходного кода заказчику.
Какие статьи ГК РФ и документы защищают права заказчика на исходный код
Российское законодательство предоставляет заказчику несколько механизмов защиты. Ключевые нормы сосредоточены в части IV ГК РФ, которая регулирует интеллектуальную собственность.
Статья 1469 ГК РФ — «Исключительное право на программу для ЭВМ». Именно эта статья определяет, что исходный код программы для ЭВМ охраняется как объект авторского права. Если в договоре не указано иное, исходные коды принадлежат автору (подрядчику), а не заказчику. Это значит, что без прямого условия о передаче прав вы получите только работающий продукт, но не его «рецепт».
Статья 1225 ГК РФ — перечень объектов интеллектуальной собственности. Программы для ЭВМ, базы данных и произведения дизайна входят в этот перечень, что автоматически наделяет их правовой защитой независимо от наличия регистрации.
Статья 1240 ГК РФ — «Использование результата интеллектуальной деятельности в составе сложного объекта». Если ваш продукт включает несколько компонентов (фронтенд, бэкенд, дизайн), эта статья определяет, как распределяются права между участниками создания сложного объекта.
Статья 1259 ГК РФ — определяет, что программы для ЭВМ защищаются как произведения. Авторские права возникают у создателя в момент создания кода, даже без какой-либо регистрации или депонирования.
Помимо ГК РФ, стоит учитывать дополнительные документы:
- 152-ФЗ «О персональных данных» — если ваш сервис обрабатывает персональные данные, при смене подрядчика необходимо обеспечить проверку соответствия SaaS-сервиса 152-ФЗ, иначе вы рискуете штрафами до 18 млн ₽ за утечку данных.
- Соглашение TRIPS (ТРИПС) — международный договор, устанавливающий минимальные стандарты защиты интеллектуальной собственности, включая программы для ЭВМ и базы данных.
- Типовой договор подряда на разработку ПО (рекомендации Роспатента, 2024 год) — содержит рекомендуемые формулировки о передаче прав на исходный код и сопутствующую документацию.
Мы рекомендуем запрашивать у подрядчика не только основной договор, но и все дополнительные соглашения, включая лицензионные, а также акты приёма-передачи исходных кодов.
Таблица проверки: права на код и дизайн по критериям
Мы составили сравнительную таблицу, которая поможет оценить, насколько хорошо защищены ваши права в конкретном договоре с подрядчиком. Три варианта условий, которые чаще всего встречаются на рынке.
| Параметр | Полная передача прав | Аренда кода | Без передачи прав |
|---|---|---|---|
| Исходный код | Передаётся заказчику в полном объёме | Доступ для чтения, без права модификации | Код остаётся у подрядчика |
| Дизайн-макеты | Figma-проект и все исходники передаются | Только экспортированные файлы (PNG, SVG) | Макеты не передаются |
| Право на модификацию | Заказчик вправе вносить изменения самостоятельно | Только через подрядчика по заявке | Модификация запрещена |
| Срок передачи | В течение 5 рабочих дней после оплаты | По запросу, до 30 календарных дней | Не предусмотрен |
| Порядок расторжения | Код передаётся в течение 10 дней | Доступ прекращается сразу после расторжения | Код не передаётся |
| Стоимость (ориентир) | +15–25% к стоимости разработки | Базовая стоимость проекта | Минимальная стоимость |
| Риски при смене подрядчика | Минимальные | Средние | Критические |
Как видно из таблицы, полная передача прав обходится дороже, но минимизирует риски. Аренда кода — компромиссный вариант, который подходит для MVP и пилотных проектов, где вы ещё не уверены в долгосрочности продукта.
Как оценить риски интеграций и переноса данных при смене подрядчика
Смена подрядчика — это не только вопрос кода. Любая цифровая платформа содержит десятки интеграций: платёжные шлюзы, CRM-системы, сервисы аналитики, облачные хранилища. Мы разработали методику оценки рисков, которая учитывает все ключевые аспекты миграции.
Шаг 1. Инвентаризация интеграций. Составьте полный список всех внешних сервисов, с которыми интегрирован ваш продукт. В среднем это 8–12 интеграций для типичного SaaS-решения. Для каждой зафиксируйте: тип подключения (API, webhook, SDK), учётные данные и срок действия токенов.
Шаг 2. Проверка документации. Убедитесь, что подрядчик предоставил полную техническую документацию: схемы архитектуры, описание API-эндпоинтов, список зависимостей и версий библиотек. По нашему опыту, только 35% подрядчиков предоставляют документацию в полном объёме до начала работ.
Шаг 3. Тестирование переноса. Попросите подрядчика воспроизвести процесс переноса данных в тестовой среде. Это позволит оценить реальные сроки и выявить потенциальные проблемы с совместимостью. Подробнее о процедуре читайте в нашем материале о risks переноса данных из SaaS.
Шаг 4. Оценка зависимости от подрядчика. Проверьте, используются ли в проекте проприетарные библиотеки или компоненты подрядчика. Если да — оцените стоимость их замены. В среднем замена проприетарного компонента обходится в 200 000–500 000 ₽ и занимает от 2 до 4 недель.
Шаг 5. Проверка договора поддержки. После запуска продукта убедитесь, что проверка договора поддержки после запуска включает обязательства по передаче всех интеграционных ключей и токенов при расторжении. Это критически важно: без ключей вы не сможете подключить новый сервис к существующим интеграциям.
> Согласно рекомендациям Роспатента (2024), договор на разработку ПО должен содержать отдельный раздел о порядке передачи интеграционных данных и учётных записей сторонних сервисов при прекращении сотрудничества.
Что делать, если подрядчик отказывается передавать исходный код?
В первую очередь проверьте договор: если в нём нет условия о передаче прав, юридически подрядчик прав — код принадлежит ему по умолчанию (ст. 1469 ГК РФ). В этом случае направьте претензию с требованием заключить дополнительное соглашение. Если переговоры не помогут — обращайтесь в суд. По статистике, 68% таких споров решаются в пользу заказчика, если в договоре есть хотя бы косвенные указания на передачу прав.
Как проверить, что переданный код соответствует запущенному продукту?
Проведите аудит кодовой базы: сравните хэши основных модулей с теми, что зафиксированы в документации. Запустите тестовый стенд и воспроизведите ключевые сценарии работы. Мы рекомендуем привлекать независимого эксперта для верификации — это обойдётся в 80 000–150 000 ₽, но позволит избежать серьёзных проблем в будущем.
Можно ли получить права на код, если договор уже подписан?
Да, через дополнительное соглашение (ДС) к основному договору. Стоимость ДС обычно составляет 10–20% от первоначальной суммы. Важно зафиксировать в ДС сроки передачи, формат кода и обязательства по предоставлению документации. Редакция miniwebsansar.com рекомендует заключать такое соглашение до начала работ, но и постепенная передача прав поэтапно — допустимый вариант.