Как менеджеру держать IT-проект и заказчика под контролем: от договора до сдачи без конфликтов

Белявский Сергей Чеславович
Директор юридической компании «Экономические споры», рекомендованный арбитр Международного арбитражного суда при БелТПП, медиатор, более 10 лет стажа работы судьёй экономического суда

Цифры, которые должны вас убедить

Давайте начнём с фактов. Судебная коллегия по делам интеллектуальной собственности Верховного Суда Республики Беларусь (СКИС) за 9 месяцев 2025 года рассмотрела 78 дел, из которых по 55 (70,5%) вынесены решения по существу. В 2023 году рассмотрела 148 дел. Из них 61,5% завершились решениями по существу. В рекордном 2020 году было 224 дела.

Дела, которые рассматривает СКИС в IT-сфере — это не абстрактные конфликты, а вполне конкретные ситуации:

• расторжение договора на разработку ПО (CRM, ERP, сайтов);
• взыскание долга и неустойки по договорам на разработку и продвижение;
• споры о качестве — заказчик не доволен, подрядчик настаивает на оплате;
• споры о правах на исходный код, дизайн, документацию;
• споры по лицензионным договорам на ПО;
• споры по SMM, SEO, хостингу, рекламе в интернете.

За каждым из этих дел — реальный IT-проект, где что-то пошло не так. И практически в каждом из них ключевую роль сыграли либо правильно оформленные документы, либо их отсутствие.

Именно об этом наша статья. Не о том, как стать юристом — а о том, как менеджеру работать так, чтобы документы были вашим активом, а не проблемой.

1. Договор в IT-проекте: что важно менеджеру до подписи

1.1. Какой это договор по своей природе?

Когда вы подписываете договор на разработку программного обеспечения, сайта, CRM или мобильного приложения — вы имеете дело с документом, к которому одновременно применяется несколько блоков законодательства. Это так называемый смешанный договор (ст. 391 ГК Республики Беларусь).

Верховный Суд в своей практике прямо квалифицирует такой договор как содержащий:

• обязательства по оказанию услуг по проектированию, разработке и реализации информационных систем ПО;
• обязательства по уступке исключительного права на результат интеллектуальной деятельности;
• элементы лицензионного договора на использование объектов интеллектуальной собственности.

К нему применяются нормы ГК о подряде (§ 1 гл. 37 ГК), возмездном оказании услуг (гл. 39 ГК), а также нормы об интеллектуальной собственности (раздел V ГК), Закон Республики Беларусь «Об авторском праве и смежных правах» от 17 мая 2011 г. № 262-З (в ред. изменений, вступивших в силу 19 ноября 2024 г.), Декрет Президента № 8 от 21 декабря 2017 г. «О развитии цифровой экономики».

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

1.2. Существенные условия: три блока, без которых договора нет

Это самое важное, что менеджер должен запомнить про договор. Если в нём не согласованы существенные условия — суд признаёт договор незаключённым. А это значит: всё, что вы сделали и получили, подлежит возврату как неосновательное обогащение (ст. 971–972 ГК).

Вот три блока существенных условий для IT-договора:

Предмет, объём и результат работ (ст. 656 ГК — договор подряда).
Должно быть написано: что именно создаётся, какой у этого состав (функциональные модули, интеграции, документация), каков критерий готовности. «Разработка системы управления» без детализации — это не предмет договора. Это повод для спора.

Срок выполнения работ (ст. 656 ГК).
Начальный и конечный сроки — обязательны. При поэтапной разработке — сроки каждого этапа. Без сроков договор подряда считается незаключённым.

Для лицензионного договора: способы использования, срок лицензии, размер вознаграждения (ст. 985 ГК в ред. 2024 г.).
Важная новелла: с 19 ноября 2024 года вступили в силу изменения в раздел V ГК РБ, касающиеся интеллектуальной собственности. Теперь: если договор содержит элементы уступки исключительного права и лицензионного договора одновременно — применяются правила лицензионного договора. Если в договоре прямо не написано об отчуждении исключительного права — он считается лицензионным.

Практический пример: В деле №1ИГИП2386 при несогласовании существенных условий по объёму и содержанию работ (отсутствовало надлежащее техническое задание) суд признал договор незаключённым. Аванс, перечисленный заказчиком, был взыскан как неосновательное обогащение. Расторгнуть такой договор нельзя — нечего расторгать.

1.3. Пять формулировок «двойного понимания», которые убивают проекты

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

«Разработка системы в соответствии с пожеланиями заказчика»— это не предмет. «Пожелания» не фиксируют результат, не дают критериев приёмки и не могут быть проверены экспертом.

«Работа должна отвечать ожиданиям заказчика»— аналогично. «Ожидания» — субъективный критерий. Если он не переведён в объективные показатели ТЗ, заказчик всегда сможет сказать, что ожидал большего.

«Исполнитель вправе привлекать субподрядчиков без ограничений»— без уточнения ответственности за субподрядчика это означает, что при провале со стороны субподрядчика вы будете доказывать, что сделали всё правильно.

«Оплата производится по факту выполнения»— без процедуры фиксации факта выполнения (акт, срок подписания, последствия молчания) это бесконечный спор о том, выполнено или нет.

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

Рекомендованная формулировка для предмета договора:

«Предметом настоящего договора является разработка программного обеспечения "___" (далее — ПО) в соответствии с Техническим заданием (Приложение № 1), являющимся неотъемлемой частью настоящего договора. Результатом работ является передача Исполнителем Заказчику: (1) исходного кода ПО; (2) исполняемого кода ПО; (3) технической документации; (4) исключительного права на ПО в полном объёме. Передача результата осуществляется путём размещения кода в репозитории Заказчика и подписания акта приёма-передачи».

2. Техническое задание и критерии результата: «понятно и проверяемо»

2.1. ТЗ — это ваш главный документ в суде

Вся судебная экспертиза по IT-спорам о качестве строится вокруг одного вопроса: что было написано в техническом задании? Именно ТЗ — это мера качества, которую суд использует при проведении судебной компьютерно-технической экспертизы.

В деле №1ИГИП23103 суд проводил осмотр работоспособности программного обеспечения прямо в судебном заседании с участием эксперта — и функционал сверялся с требованиями ТЗ пункт за пунктом.

Если ТЗ написано расплывчато — у эксперта нет ориентира. У суда нет мерила. У вас нет шанса защититься ни как подрядчик, ни как заказчик.

2.2. Три уровня требований, которые нужно различать

Чтобы ТЗ работало как защитный инструмент, в нём нужно разграничить три уровня:

Уровень 1 — обязательные функциональные требования. То, что система обязана делать. Проверяется тестовыми сценариями. Формат: «Система обязана выполнять функцию X при условии Y с результатом Z».

Уровень 2 — нефункциональные требования. Производительность, безопасность, совместимость. Должны быть измеримы: «Время загрузки главной страницы не более 3 секунд при нагрузке до 1000 одновременных пользователей».

Уровень 3 — перечень исключений. Что система не делает. Это защищает от ситуации, когда заказчик называет «дефектом» функцию, которая никогда не была предусмотрена.

2.3. Входные данные от заказчика: фиксируем получение и задержки

Это один из ключевых защитных механизмов для подрядчика при спорах о просрочке. По ст. 670 ГК подрядчик вправе отказаться от договора или приостановить работы при непригодности или недостаточности предоставленных заказчиком исходных данных. Но только при условии, что он письменно уведомил заказчика об этом.

В деле №1ИГИП2289 суд учёл вину заказчика в несвоевременном предоставлении исходных данных при оценке ответственности за просрочку. Подрядчику удалось частично снять с себя ответственность именно потому, что в переписке были задокументированы соответствующие запросы.

В деле №1ИГИП2224 всё было наоборот: подрядчик не зафиксировал запросы в срок — и понёс полную ответственность за просрочку.

Практическое правило: каждый раз, когда вы ждёте от заказчика данные (доступы, макеты, описания бизнес-процессов, согласования), отправляйте по электронной почте формальный запрос: что нужно, в каком формате, к какому сроку, и как задержка повлияет на сроки проекта. Сохраняйте подтверждения доставки.

Рекомендованная формулировка для договора (входные данные):

«Заказчик обязан предоставить Исполнителю исходные данные, указанные в Приложении № ___, не позднее ___. Задержка предоставления исходных данных по вине Заказчика на срок более ___ рабочих дней является основанием для соразмерного переноса сроков выполнения работ без применения к Исполнителю мер ответственности за просрочку».

3. Коммуникации и фиксация договорённостей

3.1. Переписка в мессенджерах — не замена договору

Это самый болезненный и самый распространённый риск в IT-проектах. Стороны договариваются в Telegram, Viber, Slack: согласовывают объём, дают «добро» на изменения, обещают «разберёмся». Потом одна из сторон говорит: «Я этого не согласовывал» — и в суде начинается дорогостоящая экспертиза.

Белорусские суды принимают электронные доказательства, но с серьёзными условиями. Чтобы переписка имела силу, нужно доказать:

• кому принадлежит аккаунт или номер телефона (справка оператора связи);
• были ли у этого лица полномочия принимать решения (должностная инструкция, штатное расписание, доверенность);
• подлинность переписки (заключение специалиста, нотариальный протокол осмотра).

Главное правило, многократно подтверждённое практикой Судебной коллегии Верховного суда по делам интеллектуальной собственности: переписка в мессенджерах не заменяет подписание договора и дополнительных соглашений к нему. Она может подтвердить факты, но не изменить условия письменного договора.

3.2. Доктрина эстоппель в белорусском праве: что это для менеджера

С 19 ноября 2024 года в ГК введена норма ст. 401-1: сторона, которая приняла от другой стороны исполнение по предпринимательскому договору и при этом сама свои обязательства не выполнила, не вправе требовать признания такого договора незаключённым или недействительным.

Для менеджера это означает: если вы принимаете результаты работ, используете систему, не выдвигаете возражений — суд может расценить это как согласие с условиями. Это — эстоппель (estoppel). Именно поэтому важно реагировать письменно на каждый шаг: принял — подпиши акт, не принял — направь мотивированный отказ.

3.3. «Одно окно» — уполномоченный представитель заказчика

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

Защита простая: в договоре пропишите конкретное уполномоченное лицо по имени/должности и его контактный email.

Рекомендованная формулировка:

«Уполномоченным представителем Заказчика для целей согласований, приёмки и оформления изменений в рамках настоящего договора является __________ (должность, ФИО). Электронная почта уполномоченного представителя: @. Согласования, принятые иными лицами, считаются действительными только после подтверждения уполномоченным представителем Заказчика в письменной форме. Уведомление о прочтении электронного письма считается подтверждением получения и ознакомления».

3.4. Нотариальное обеспечение доказательств: когда и как

Если есть риск того, что переписка в мессенджере или содержимое сайта будут удалены или изменены — нотариус может составить протокол осмотра (ст. 111–113 Закона Республики Беларусь «О нотариате»). Этот протокол является официальным доказательством для суда.

4. Изменения по ходу проекта: как реагировать на «сделайте ещё вот это»

4.1. «Scope creep»: почему маленькие правки стоят дорого

Каждый менеджер знает этот сценарий: заказчик в процессе проекта говорит «ну это же просто маленькая правка» — и вы из вежливости соглашаетесь. Потом ещё одна «маленькая правка». Потом ещё. В итоге объём вырос на 40%, сроки сорваны, а в договоре по-прежнему указан первоначальный объём.

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

По ст. 420 ГК изменение условий договора (объёма, сроков, цены) допустимо только по соглашению сторон, если иное не предусмотрено договором. Устная договорённость о расширении объёма — это не соглашение об изменении договора.

4.2. Процедура управления изменениями: четыре шага

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

Шаг 1. Запрос. Заказчик направляет описание желаемого изменения в письменном виде (e-mail, тикет в системе управления задачами). Без письменного запроса — работы не начинаются.

Шаг 2. Оценка. Исполнитель оценивает трудозатраты и влияние на сроки и стоимость. Направляет ответ в течение согласованного срока (оптимально — 3–5 рабочих дней).

Шаг 3. Согласование. Стороны подписывают дополнительное соглашение к договору с новым объёмом, ценой и сроком.

Шаг 4. Запуск. Работы начинаются только после вступления допсоглашения в силу.

Рекомендованная формулировка:

«Любые изменения объёма работ, сроков или стоимости оформляются письменным дополнительным соглашением, подписанным уполномоченными представителями обеих сторон. Работы по изменённому объёму начинаются только после вступления дополнительного соглашения в силу. Выполнение Исполнителем работ, не предусмотренных договором и дополнительными соглашениями к нему, не порождает обязанности Заказчика по их оплате вне зависимости от наличия иных договорённостей».

4.3. Дефект vs. новая функциональность: главный спор в IT

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

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

В деле №1ИГИП2372 суд прямо указал: дополнительные пожелания заказчика ≠ мотивированные возражения по качеству. Попытка заказчика переквалифицировать новое пожелание как замечание по качеству была отклонена судом.

Когда заказчик говорит «это дефект» — задавайте вопрос: «В каком конкретном пункте ТЗ это требование зафиксировано?» Если ответа нет — это не дефект. Это изменение объёма.

5. Приёмка результата и закрытие этапов

5.1. Акт приёмки: документ, который решает всё

Акт сдачи-приёмки выполненных работ — центральный документ в любом споре по оплате или качеству. Именно он фиксирует: работы выполнены, заказчик принял, претензий нет (или: принято с конкретными замечаниями). Без этого документа или при его отсутствии доказать факт выполнения работ и их принятие значительно сложнее.

Ключевые правила из судебной практики СКИС:

Подписание акта без замечаний = признание качества(ст. 673 ГК). После этого заказчик лишается права ссылаться на явные недостатки.

Отсутствие мотивированного отказа от подписания акта— подтверждает качество работ. Судьи на это смотрят. (дело №1ИГИП2238)

Оплата при неподписании актав совокупности с другими обстоятельствами свидетельствует о фактической приёмке.

Направление актов по электронной почтедопустимо, если они содержат «читаемые реквизиты, подписи, печати и читаемый смысл документов» — прямая цитата из практики СКИС.

5.2. Молчание заказчика — работает на вас, если правильно прописано

По умолчанию молчание — не согласие. Но если в договоре прописана процедура с конкретным сроком на возражения — молчание после истечения срока суд квалифицирует как приёмку. Это подтверждено практикой СКИС.

Рекомендованная формулировка:

«Заказчик обязан подписать акт сдачи-приёмки или направить письменный мотивированный отказ от подписания в течение 10 (десяти) рабочих дней с момента получения акта. Мотивированный отказ должен содержать конкретный перечень недостатков со ссылками на соответствующие пункты Технического задания. При отсутствии мотивированного отказа в указанный срок акт считается подписанным Заказчиком, а работы — принятыми без замечаний».

5.3. Бесконечное тестирование: как выйти

Некоторые заказчики сознательно затягивают приёмку: каждый раунд замечаний заменяется новым. Это злоупотребление правом (ст. 9 ГК). Защита — в договорных ограничениях: два раунда замечаний, после чего — либо приёмка, либо независимая экспертиза.

Рекомендованная формулировка:

«По результатам передачи результатов работ Заказчик в течение ___ рабочих дней направляет перечень замечаний (при их наличии). Исполнитель устраняет замечания в течение ___ рабочих дней. Повторное тестирование проводится однократно. Замечания, выявленные в ходе повторного тестирования и представляющие собой требования, не предусмотренные Техническим заданием, рассматриваются как запрос на изменение объёма работ и оформляются в соответствии с разделом ___ настоящего договора».

6. Деньги и ответственность

6.1. Что изменилось с 19 ноября 2024 года: важнейшая новелла ГК

Согласно статье 366 ГК: если договором или законом предусмотрена неустойка, то проценты за пользование чужими денежными средствами (ст. 366 ГК) не начисляются. Нужно выбрать одно из двух: либо взыскиваете договорную неустойку, либо проценты по ст. 366 ГК.

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

6.2. Рекомендованные формулировки по оплате и ответственности

Оплата — безусловная:

«Оплата выполненных работ производится в течение ___ рабочих дней с момента подписания акта сдачи-приёмки (или: признания его подписанным в силу условий п. ___ настоящего договора). Заказчик не вправе задерживать оплату в связи с наличием претензий по качеству сверх суммы, соразмерной стоимости спорных работ».

Неустойка за просрочку оплаты:

«За нарушение сроков оплаты Заказчик уплачивает Исполнителю пеню в размере 0,15% от суммы просроченного платежа за каждый день просрочки. Начисление процентов за пользование чужими денежными средствами по ст. 366 ГК Республики Беларусь при наличии договорной пени не производится».

Обеспечение оплаты через ограничение прав:

«Исполнитель вправе ограничить доступ Заказчика к ПО в случае просрочки оплаты более чем на ___ дней. Право использования ПО (лицензия) считается предоставленной Заказчику только после полной оплаты».

6.3. Что обнуляет позицию компании в суде: топ-5 ошибок в переписке

Из практики белорусских судов и МАС при БелТПП можно выделить типичные «самоподрывные» формулировки в переписке менеджеров:

• «Да, понимаем, наша вина, исправим»— признание вины без установления её реального характера.
• «Дадим скидку, только не судитесь»— может быть расценено как признание долга или нарушения.
• «Ну это и так должно было быть в системе»— признание расширенного объёма обязательств.
• «Мы постараемся сделать это бесплатно»— создание обязательства без договора.
• «Акт пока не нужен, разберёмся»— откладывание фиксации, которое потом оборачивается «а я ничего не принимал».

Правило: любые договорённости об изменении условий — только в письменном соглашении. В переписке — только факты и процессуальные шаги.

7. Разграничение ошибок и ответственности: разработка vs. внедрение vs. заказчик

7.1. Четыре категории проблем

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

Категория 1 — ошибка кода (разработка). Функционал не соответствует ТЗ, баг воспроизводится стабильно, источник — код исполнителя. Это зона ответственности исполнителя. Устраняется в гарантийный срок бесплатно.

Категория 2 — ошибка конфигурации (внедрение). Код правильный, но настроен неверно. Зависит от того, кто делал настройку — исполнитель или заказчик. Требует установления факта.

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

Категория 4 — ограничения сторонних систем (внешний фактор). API партнёра изменился, облачный сервис недоступен, интеграция с системой заказчика работает некорректно из-за изменений на стороне этой системы. Это внешний фактор, который исполнитель обязан зафиксировать письменно в момент выявления.

В деле СКИС №1ИГИП2289 суд учёл вину заказчика в несвоевременном предоставлении данных и замечаний при распределении ответственности за нарушение сроков. Факты были задокументированы в переписке сторон.

7.2. Протоколирование: сначала факты, потом слова

Золотое правило: когда заказчик сообщает о проблеме — сначала собираем факты, потом говорим о вине и сроках.

Минимальный протокол фиксации:

• логи системы с датой и временем;
• скриншоты с отображением ошибки;
• шаги воспроизведения (пошаговый сценарий);
• версия ПО, браузер, ОС, данные, на которых проявилась ошибка;
• контрольные примеры — что ожидалось, что получено.

Без этого набора любое обещание «исправим в течение суток» — это признание без понимания сути. А в суде это может быть квалифицировано как признание дефекта.

Рекомендованная формулировка для гарантийного раздела договора:

«В течение гарантийного срока ___ месяцев Исполнитель устраняет дефекты ПО, подтверждённые актом о выявленном дефекте, составленным совместно сторонами (или: направленным Заказчиком с приложением логов, скриншотов и шагов воспроизведения). Дефектами не признаются: (1) последствия действий Заказчика, противоречащих технической документации; (2) ошибки, вызванные изменениями сторонних систем или инфраструктуры Заказчика; (3) функциональность, не предусмотренная Техническим заданием».

8. Интеллектуальная собственность и права на результат

8.1. Главное заблуждение: «мы заплатили — значит, всё наше»

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

По ст. 993 ГК компьютерная программа является объектом авторского права. Авторское право возникает у автора (разработчика) в момент создания произведения — автоматически, без регистрации. Именно поэтому в ГК прямо прописан специальный порядок передачи исключительных прав на заказные произведения.

С 19 ноября 2024 года действует новая редакция раздела V ГК (изменения внесены Законом № 312-З от 13 ноября 2023 г.). Ключевые новеллы для IT:

Определён момент перехода результата интеллектуальной деятельности к заказчикупо договору о создании и использовании результата ИД (ст. 988 ГК в новой ред.). Это устраняло прежнюю неопределённость.

Установлены два варианта распоряжения правамипо заказу: (1) отчуждение (уступка) исключительного права; (2) предоставление права использования (лицензия). Выбор — в договоре.

Правило толкования:если в договоре прямо не написано об уступке (отчуждении) исключительного права — суд считает его лицензионным договором (ч. 4 п. 2 ст. 985 ГК).

Риск случайной невозможности исполнениядоговора о создании ИД по умолчанию возлагается на заказчика, если иное не предусмотрено договором.

Практический вывод: если вы хотите передать заказчику полные исключительные права — в договоре должна быть прямая и недвусмысленная формулировка об уступке (отчуждении) этих прав.

8.2. Состав результата: что именно передаётся

В IT-проекте «результат работ» — это не просто «программа». Менеджер должен чётко понимать состав передаваемого.

Элемент результата	Правовой режим	Нюанс
Исходный код (source code)	Объект авторского права	Охраняется с момента создания
Объектный код (compiled)	Объект авторского права	Часть той же программы
Дизайн-макеты, UI	Объект авторского права	Отдельные произведения
Техдокументация	Объект авторского права	Охраняется отдельно
Настройки и конфигурации	Зависит от оригинальности	Могут не охраняться
Open source компоненты	Чужое авторское право	Нельзя передать в «исключительном» порядке
Базы данных	Смежные права / авторское право	Требуют отдельного урегулирования

Важно: оплата за передачу исключительных прав на ПО ≠ оплата за выполненные работы. Это два разных обязательства. В практике СКИС встречались случаи, когда суд взыскивал оплату за работы, но отдельно анализировал состоялась ли передача прав — и делал вывод, что нет, поскольку не было надлежащей передачи носителя (код в репозитории, по накладной и т.п.).

8.3. Open source: скрытая правовая мина

Большинство современных IT-продуктов строятся на открытых библиотеках и фреймворках. Это нормально, но только при условии, что лицензии этих компонентов учтены в договоре с заказчиком.

Три основных типа open source лицензий:

MIT, Apache 2.0, BSD— разрешительные. Можно включать в коммерческий продукт, передавать в исключительном порядке свои части кода.

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

GPL v2/v3— строгие. Любой продукт, включающий GPL-код, должен распространяться под GPL с открытием всего исходного кода. Передать такой код «в исключительном порядке» невозможно.

Если вы используете GPL-компоненты и обещаете заказчику «полные исключительные права на всё» — вы создаёте невыполнимое обязательство. В суде это будет или оспаривание объёма прав, или требование о взыскании убытков.

Рекомендованная формулировка:

«Результаты работ могут включать компоненты с открытым исходным кодом (open source), перечень которых указан в Приложении № ___. Права на указанные компоненты регулируются соответствующими открытыми лицензиями и не могут быть переданы Заказчику в исключительном порядке. Исполнитель гарантирует, что использование open source компонентов не нарушает условия применяемых лицензий и не ограничивает право Заказчика использовать результаты работ в коммерческих целях».

8.4. Регистрация ПО в НЦИС: добровольно, но полезно

Национальный центр интеллектуальной собственности (НЦИС) осуществляет добровольную регистрацию компьютерных программ. Регистрация не является основанием возникновения авторского права, но создаёт дополнительное доказательство авторства и даты существования программы.

Статистика: в 2023 году зарегистрировано 91 программа, в 2024-м — 130, 2025 – 118, 2026 – уже 19.

По результатам: выдаётся Свидетельство о регистрации, программа вносится в реестр НЦИС, производится депонирование и хранение материалов. Особенно актуально для собственных продуктов компании.

Рекомендованная формулировка (механизм обеспечения оплаты через права):

«Исключительное право на ПО переходит к Заказчику после одновременного выполнения следующих условий: (1) подписания акта приёма-передачи; (2) передачи исходного кода в репозиторий Заказчика / на носителе; (3) полной оплаты стоимости работ по договору. До момента выполнения всех указанных условий использование ПО Заказчиком допускается исключительно в тестовом режиме без права модификации и передачи третьим лицам».

9. Спорные ситуации и досудебное урегулирование

9.1. Алгоритм менеджера при возникновении конфликта

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

Вот алгоритм действий менеджера при первых признаках конфликта:

• Фиксируем проблему— письменно, конкретно, без эмоций: что произошло, когда, какие это создаёт последствия для проекта.
• Собираем факты— все договорные документы, переписку, акты, технические отчёты, логи. Всё, что подтверждает вашу позицию.
• Предлагаем варианты— не ждём ультиматума. Предлагаем 2–3 конкретных варианта с реалистичными сроками.
• Согласуем срок ответа— не «когда сможете», а «прошу ответить до [дата]».
• Эскалируем юристу— если переговоры зашли в тупик. Юрист, а не менеджер, ведёт официальную претензионную переписку.

9.2. Медиация: быстро, дёшево, без публичности

Медиация регулируется Законом Республики Беларусь «О медиации» от 12 июля 2013 г. № 58-З. Результат — медиативное соглашение, имеющее силу гражданско-правового договора.

Почему это работает для IT:

• Сохраняет деловые отношения (иногда заказчик ценен как партнёр, а не как ответчик).
• Занимает 1–3 сессии, а не месяцы суда.
• Конфиденциально — информация не становится публичной.
• Стоимость существенно ниже судебного разбирательства.

Рекомендованная медиативная оговорка:

«В случае возникновения спора стороны обязуются до обращения в суд в течение 30 (тридцати) дней с момента получения предложения о медиации предпринять попытку урегулирования спора путём медиации. Медиатор определяется по соглашению сторон. Расходы на медиацию несут стороны поровну, если иное не будет согласовано».

10. Конфиденциальность, персональные данные, частые риски

10.1. Конфиденциальность на практике: три зоны риска

Почти все IT-договоры содержат раздел о конфиденциальности или NDA. Но на практике именно менеджер, а не юрист — первый барьер защиты конфиденциальной информации.

Зона риска 1 — разглашение через переписку. Менеджер в письме партнёру называет имя крупного клиента, раскрывает технические детали системы или условия договора. Формально — нарушение NDA.

Зона риска 2 — субподрядчики без своего NDA. Привлекаете фрилансера или небольшую студию как субподрядчика? Их сотрудники получают доступ к конфиденциальным данным заказчика. Если с субподрядчиком не подписано своё соглашение о конфиденциальности — вы несёте ответственность за утечку.

Зона риска 3 — уходящий сотрудник. Разработчик, который уходит и «уносит» знание об архитектуре системы заказчика. Без NDA с работником (или соответствующих условий в трудовом договоре) защита крайне ограничена.

Рекомендованная формулировка:

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

10.2. Персональные данные: отдельный правовой пласт

Закон Республики Беларусь «О защите персональных данных» от 7 мая 2021 г. № 99-З вступил в полную силу 15 ноября 2023 г. (с учётом переходных положений). Это принципиально важно для IT-компаний, которые разрабатывают или обслуживают системы, работающие с данными физических лиц.

Две роли в обработке ПД:

Оператор— организация, которая определяет цели и способы обработки персональных данных.

Уполномоченное лицо— организация, которая обрабатывает ПД по поручению оператора (например, IT-компания, разрабатывающая и обслуживающая CRM-систему для заказчика).

Если ваша IT-компания получает доступ к персональным данным клиентов заказчика (даже в ходе тестирования или поддержки) — вы действуете как уполномоченное лицо и несёте самостоятельную ответственность за надлежащую обработку и защиту этих данных.

Что нужно прописать в договоре:

• перечень категорий ПД, к которым имеет доступ исполнитель;
• цели обработки (только для целей исполнения договора);
• меры технической и организационной защиты;
• обязанность удалить ПД после окончания договора;
• порядок действий при инцидентах (утечках).

Рекомендованная формулировка:

«Исполнитель получает доступ к персональным данным, указанным в Приложении № ___, исключительно в целях исполнения настоящего договора и действует как уполномоченное лицо в понимании Закона Республики Беларусь «О защите персональных данных». Исполнитель обязуется обрабатывать ПД только по письменному поручению Заказчика, соблюдать требования к защите ПД, уведомить Заказчика о любом инциденте в течение 24 часов, удалить ПД в течение 10 рабочих дней по окончании договора».

10.3. Закон об ограничении исключительных прав: что нужно знать

С 3 января 2023 года в Беларуси действует Закон № 241-З «Об ограничении исключительных прав на объекты интеллектуальной собственности» (в ред. изменений по состоянию на 2 декабря 2024 г.).

Он допускает использование ряда объектов ИС, в том числе компьютерных программ, правообладателями которых являются лица, включённые в специальный перечень — без согласия правообладателя. Это связано с санкционным давлением и уходом иностранного ПО с белорусского рынка.

Для IT-компании это означает: если вы или ваш заказчик заменяете зарубежное ПО (Microsoft, SAP, Oracle и др.) белорусскими аналогами — правовая база для такой замены есть. Но при этом договор с заказчиком должен учитывать риски смены ПО и соответствующие изменения в объёме работ.

Судебная практика СКИС и СКЭД: краткий дайджест для менеджера и юриста

Ниже — обзор ключевых позиций белорусских судов по IT-спорам, на которые стоит ориентироваться в работе:

По заключённости договора:

Дело №1ИГИП2386— при отсутствии надлежащего ТЗ договор незаключён, аванс = неосновательное обогащение.

Дело №1ИГИП22112 — суд учитывает фактическое поведение сторон при исполнении договора при оценке его заключённости. Принцип: начали исполнять — значит, договорились.

По срокам:

Дело №1ИГИП2224 — подрядчик не запрашивал данные в срок, понёс полную ответственность за просрочку.

Дело №1ИГИП2289 — учтена вина заказчика в задержке исходных данных, ответственность подрядчика снижена.

По качеству:

Дело №1ИГИП23103 — осмотр ПО в судебном заседании с экспертом по критериям ТЗ.

Дело №1ИГИП2372 — дополнительные пожелания ≠ мотивированные возражения по качеству; заказчик проиграл спор.

Дело №1ИГИП2238 — отсутствие мотивированного отказа от подписания акта подтверждает качество; несвоевременные замечания суд не принял.

По оплате:

Дело №1ИГИП2353 — при расторжении лицензионного договора в связи с введением санкций и невозможностью использования ПО лицензионная плата возвращена пропорционально неиспользованному периоду.

Дело № 155ЭИП232111 — зачёт разнородных требований (долг и проценты) признан недействительным.

Дело № 156ЭИП21360 — доводы о неподсудности нужно приводить в начале рассмотрения дела, не в апелляции; вовремя не заявленная позиция осложняет защиту.

Три главных урока: резюме для менеджера

Урок первый: документируйте всё.
Не потому, что вы не доверяете заказчику, а потому что память — ненадёжный источник в споре. E-mail помнит точнее, чем человек. Акт не врёт. ТЗ не меняет показаний. Каждый важный разговор должен заканчиваться письмом-резюме. Каждое принятое решение — зафиксированным документом.

Урок второй: изменения — только через соглашение.
«Маленькие правки» по договорённости в чате — это путь к большому конфликту. Каждое изменение объёма, срока или цены — дополнительное соглашение. Не исключение, а правило. Без исключений.

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

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

---

 

Решение Верховного Суда Республики Беларусь по делу № 1ИГИП2386 от 03.10.2023. Режим доступа: https://court.gov.by/ru/internet/3ce1937f67c841bb.html. Дата доступа: 06.03.2026

Решение Верховного Суда Республики Беларусь по делу № 1ИГИП23103 от 28.12.2023. Режим доступа: https://court.gov.by/ru/internet/128e753b8dc14f24.html. Дата доступа: 06.03.2026

Решение Верховного Суда Республики Беларусь по делу № 1ИГИП2289 от 13.09.2022. Режим доступа: https://court.gov.by/ru/internet/767f4582a7484328.html. Дата доступа: 06.03.2026

Решение Верховного Суда Республики Беларусь по делу № 1ИГИП2224 от 16.05.2022. Режим доступа: https://court.gov.by/ru/internet/70780632024c476c.html. Дата доступа: 06.03.2026

Решение Верховного Суда Республики Беларусь по делу № 1ИГИП2372 от 27.09.2023. Режим доступа: https://court.gov.by/ru/internet/0cd82c62f55e407c.html. Дата доступа: 06.03.2026

Решение Верховного Суда Республики Беларусь по делу № 1ИГИП2238 от 06.06.2022. Режим доступа: https://court.gov.by/ru/internet/40fbeabfa7fa4415.html. Дата доступа: 06.03.2026

Решение Верховного Суда Республики Беларусь по делу № 1ИГИП2289 от 13.09.2022. Режим доступа: https://court.gov.by/ru/internet/767f4582a7484328.html. Дата доступа: 06.03.2026

Решение Верховного Суда Республики Беларусь по делу № 1ИГИП2386 от 03.10.2023. Режим доступа: https://court.gov.by/ru/internet/3ce1937f67c841bb.html. Дата доступа: 06.03.2026

Решение Верховного Суда Республики Беларусь по делу № 1ИГИП22112 от 28.12.2022. Режим доступа: https://court.gov.by/ru/justice_rb/praktice/intell/comp/26518721e5c74366.html. Дата доступа: 06.03.2026

Решение Верховного Суда Республики Беларусь по делу № 1ИГИП2224 от 16.05.2022. Режим доступа: https://court.gov.by/ru/internet/70780632024c476c.html. Дата доступа: 06.03.2026

 Решение Верховного Суда Республики Беларусь по делу № 1ИГИП2289 от 13.09.2022. Режим доступа: https://court.gov.by/ru/internet/767f4582a7484328.html. Дата доступа: 06.03.2026

Решение Верховного Суда Республики Беларусь по делу № 1ИГИП23103 от 28.12.2023.

Режим доступа: https://court.gov.by/ru/internet/128e753b8dc14f24.html. Дата доступа: 06.03.2026

Решение Верховного Суда Республики Беларусь по делу № 1ИГИП2372 от 27.09.2023.

Режим доступа: https://court.gov.by/ru/internet/0cd82c62f55e407c.html. Дата доступа: 06.03.2026

Решение Верховного Суда Республики Беларусь по делу № 1ИГИП2238 от 06.06.2022. Режим доступа: https://court.gov.by/ru/internet/40fbeabfa7fa4415.html. Дата доступа: 06.03.2026

 Решение Верховного Суда Республики Беларусь по делу № 1ИГИП2353 от 20.12.2023. Режим доступа: https://court.gov.by/ru/justice_rb/praktice/intell/comp/c296171fd48149ed.html. Дата доступа: 06.03.2026

 Постановление судебной коллегии по экономическим делам Верховного Суда Республики Беларусь от 03.10.2023 по делу № 155ЭИП232111. Режим доступа: https://court.gov.by/ru/justice_rb/praktice/acts_vs/economics/5e5f131cac6a4eb6.html. Дата доступа: 06.03.2026

 Постановление судебной коллегии по экономическим делам Верховного Суда Республики Беларусь от 22.09.2021 по делу № 156ЭИП21360. Режим доступа: https://court.gov.by/ru/justice_rb/praktice/acts_vs/economics/9e60427291194996.html. Дата доступа: 06.03.2026