От контракта до спора: как IT-бизнесу выстраивать сделки и урегулировать конфликты — интервью с экспертами REVERA Kazakhstan
- Повестка мероприятия:
- Почему стандартный договор на услуги не подходит для IT-разработки?
- Как описывать ТЗ, если проект живет по Agile и постоянно меняется?
- Что должно быть в change management: каналы, люди и последствия молчания
- Приемка: почему нельзя ждать финального акта
- Исходный код, права и open source: код сам по себе еще не означает право
- SaaS, SLA и подписки: споры возникают не только в заказной разработке
- Чем IT-споры отличаются от обычных коммерческих споров?
- Какие доказательства работают в IT-спорах?
- Что закладывать в dispute management до конфликта?
IT-проект редко заканчивается ровно в той конфигурации, в которой его описали на старте.
Меняется бизнес-задача, появляются новые интеграции, подключаются сторонние сервисы, обновляется технологический стек, а вместе с этим меняется и юридическая картина проекта.
|
На офлайн-встрече эксперты REVERA Kazakhstan обсудили, почему в IT недостаточно шаблонного договора на услуги, как фиксировать изменения по проекту и какие доказательства становятся решающими, когда договор превращается в спор. |
Повестка мероприятия:
- Почему IT-контракты не укладываются в классические договорные конструкции.
- Смешанная природа IT-договора: услуги, подряд, лицензии, авторские права, персональные данные и инфраструктура.
- Техническое задание, Agile/Waterfall, спринты и фиксация изменений.
- Change management: каналы коммуникации, уполномоченные лица, сроки ответа, follow-up и цифровые подтверждения.
- Приемка работ: промежуточные этапы, тестирование, АВР, digital space и сохранение цифрового следа.
- Права на ПО: исходный код, исключительные права, background/foreground IP, служебные произведения, подрядчики и open source.
- SaaS и SLA: доступность сервиса, время реакции, внешние сбои, B2B/B2C-оферты и подписки.
- Особенности IT-споров: нематериальность результата, сложная экспертиза, участие технической команды и перевод технического языка для суда.
- Доказательства в IT-спорах: подписанные документы, переписка, Jira, мессенджеры, публичные источники, цифровые следы и киберинциденты.
- Досудебное урегулирование и dispute management: техническая экспертиза, комиссия, независимый эксперт, продолжение поддержки при vendor lock и стоимость судебного/арбитражного спора.
- Отдельные вопросы аудитории: смарт-договоры, иностранные суды и арбитраж, ответственность за системы искусственного интеллекта.
Разговор получился практическим: от структуры технического задания и приемки работ до исходного кода, open source-компонентов, SaaS, мессенджеров, технических экспертиз и досудебных комиссий.
Ниже — редакционная версия обсуждения в формате интервью.
Почему стандартный договор на услуги не подходит для IT-разработки?
Модератор мероприятия: В IT многие до сих пор пытаются работать по короткому договору на услуги.
Почему такая конструкция не всегда выдерживает практику?
Дискуссия экспертов мероприятия:
— Классические договорные конструкции формировались под более традиционные задачи. IT-разработка устроена иначе: программное обеспечение создается под конкретную отраслевую задачу, а значит, в каждом проекте нужно учитывать не только общие условия договора, но и специфику бизнеса, для которого продукт разрабатывается. В IT-контракте всегда много технических элементов, и если их не описать, потом придется доказывать то, что можно было заранее закрепить в тексте договора.
— Главное отличие IT-договора — многослойность и динамичность. Помимо заказчика и подрядчика, в проект часто вовлечены третьи лица: например, лицензиар CRM-системы или иной поставщик технологии. Если лицензия будет отозвана или внешний сервис перестанет работать, заказчик может предъявлять претензии подрядчику, хотя причина сбоя находится не полностью в зоне его контроля.
— Договор разработки IT-продукта — это смешанная конструкция. Внутри могут быть элементы подряда, услуг, лицензирования, авторского права, регулирования персональных данных и других блоков. Поэтому простое решение вроде “возьмем договор на услуги и назовем его IT-договором” работает только до первого серьезного конфликта.
— Проблема еще и в том, что бизнес-процесс на старте часто выглядит красиво и масштабно, но юрист должен превратить его в конкретный предмет договора. И именно на этом этапе становится видно, насколько сложно описать будущий продукт так, чтобы потом не спорить о том, что именно стороны имели в виду.
Как описывать ТЗ, если проект живет по Agile и постоянно меняется?
Модератор мероприятия: Один из самых частых источников споров — техническое задание.
Как его фиксировать, если в ходе проекта оно неизбежно меняется?
Дискуссия экспертов мероприятия:
— Есть два риска. Либо стороны постоянно дорабатывают большое ТЗ, либо оставляют его неизменным и в конце получают продукт, который уже не соответствует исходному документу. Более рабочий подход — разделить регулирование на два уровня: в договоре закрепить рамку и цель проекта, а конкретные технические задания, спринты, этапы и приемку выносить в отдельные документы, которые согласуются по мере движения проекта.
— Важно заранее выстроить change management. Если в процессе разработки появляется новая интеграция, меняется объем работ или заказчик отходит от первоначального ТЗ, это должно фиксироваться: через дополнительное соглашение, приложение, протокол технической встречи или другой заранее согласованный инструмент. Нужна хронология событий, из которой потом будет видно, что именно изменилось, кто это согласовал и как это повлияло на сроки или бюджет.
— Чем понятнее и структурированнее ТЗ, тем меньше пространство для будущего спора. Но IT-практика не всегда выдерживает классический waterfall: в проектах появляются Jira, спринты, переписки и договоренности “по ходу”. Проблема начинается, когда в контракте нет ни слова о том, что Jira является рабочим каналом фиксации задач, а в споре стороны пытаются доказать, что именно там согласовали существенные изменения.
Что должно быть в change management: каналы, люди и последствия молчания
Модератор мероприятия: Как сделать управление изменениями не бюрократичным, но доказуемым?
Дискуссия экспертов мероприятия:
— Не все изменения нужно оформлять дополнительными соглашениями. Но существенные изменения — предмет, цена, ключевые сроки — лучше фиксировать письменно. Технические вопросы можно выносить в Jira, Asana, электронную почту или другие project management-инструменты, если в договоре прямо указано, что это согласованный канал коммуникации.
|
Эксперты отдельно выделили три элемента: определить уполномоченных лиц, закрепить каналы коммуникации и установить сроки ответа. При этом лучше указывать не только конкретных людей, но и должности или корпоративные домены: люди уходят, меняются команды, а проект продолжается. |
Возвращаемся к дискуссии экспертов:
— С цифровыми подтверждениями нужно быть осторожными. Push-уведомление или кнопка “подтвердить” может быть удобным инструментом, но это микродействие не всегда воспринимается сотрудником как юридически значимое решение. Если такая кнопка по договору означает согласование изменения, для заказчика это может стать серьезным риском.
|
Из практики участников прозвучал и более простой механизм: после встречи направлять follow-up с записью, ссылкой, протоколом договоренностей и сроком для возражений. Если стороны заранее договорились, что отсутствие ответа считается согласием, такой инструмент помогает фиксировать проектную историю без постоянных дополнительных соглашений. |
Приемка: почему нельзя ждать финального акта
Модератор мероприятия: Как связаны change management и приемка?
Дискуссия экспертов мероприятия:
— Приемку нельзя откладывать до момента, когда проект полностью завершен. Нужно заранее закрепить понятные стадии приемки, фиксировать промежуточные результаты, определять уполномоченных лиц и сохранять результаты тестирования. Если позже возникнет спор, промежуточная приемка позволит “отмотать назад” и понять, на каком этапе стороны еще были на одной странице.
В IT не каждый тестовый, демонстрационный или промежуточный результат должен закрываться классическим актом выполненных работ. Но цифровая фиксация должна быть корректной, понятной и сохраненной. Для этого эксперты предложили использовать единое digital space проекта — пространство, где хранятся промежуточные результаты, тесты, протоколы, доступы и иные следы исполнения.
Модератор мероприятия: В этом вопросе важна и бухгалтерия. Если проект разбит на этапы, часть результатов можно закрывать первичными документами, а промежуточные технические результаты — фиксировать иначе.
Но эту механику должны понимать не только юристы и разработчики, но и бухгалтеры обеих сторон.
Исходный код, права и open source: код сам по себе еще не означает право
Модератор мероприятия: В IT-спорах часто возникает вопрос: если заказчик получил результат разработки,
может ли он требовать исходный код?
|
Эксперты сошлись в том, что этот вопрос нужно прямо решать в договоре. Если передача исходного кода не прописана, заказчику будет сложно настаивать на его передаче. Но даже передача исходного кода не означает автоматическую передачу исключительных прав: можно получить код, но не получить права на его использование и распоряжение. |
Дискуссия экспертов мероприятия:
— Важно различать background IP и foreground IP. Background IP — это фреймворки, библиотеки и инструменты разработчика, которые он использует из проекта в проект и не хочет передавать заказчику. На них можно дать широкую лицензию.
Foreground IP — это то, что создается специально для заказчика; именно здесь у заказчика должны появляться исключительные права, если стороны так договорились.
Отдельный риск — цепочка прав. Если продукт создается внутренней командой, нужно оформлять служебные произведения: трудовой договор, должностную инструкцию, конкретное задание работодателя, акт приемки результата. Если привлекаются подрядчики — нужны корректные IP-оговорки в договорах. Если используется open source — нужно проверять чистоту компонентов. Иначе проблема может обнаружиться не на приемке, а через несколько лет, например при инвестиционном due diligence.
Для заказчика также важно заранее закреплять инфраструктурные вопросы: кому принадлежит GitHub-репозиторий, на чей аккаунт покупается сервер, где хранятся доступы и кто контролирует среду. Иначе даже наличие исходного кода может не дать возможности передать проект другой команде без дополнительных затрат.
SaaS, SLA и подписки: споры возникают не только в заказной разработке
Модератор мероприятия: Если продукт не разрабатывается под заказчика, а предоставляется как SaaS, рисков меньше?
|
Эксперты отметили, что SaaS снижает часть рисков, но создает другие. В длительных отношениях нужно заранее определять SLA: время доступности, время отклика, порядок реагирования на инциденты, каналы обращения в поддержку, последствия выхода за согласованные показатели и разделение причин сбоя. |
Если проблема возникла из-за провайдера, магистральной сети, банка-эквайера или другого внешнего участника, это одна зона ответственности. Если сбой связан с разработчиками или инфраструктурой самого поставщика SaaS — другая.
Поэтому SLA должен не просто обещать “работоспособность”, а разделять, за что отвечает поставщик, а что относится к внешним факторам.
В публичных B2C- и B2B-офертах эксперты рекомендовали смотреть не только на бизнес-модель, но и на применимое регулирование. Важно понимать, что продает сервис: услугу или доступ к услуге. От этого может зависеть логика возврата денег за подписку, особенно если пользователь не отменил подписку или утверждает, что сервисом фактически не пользовался.
Чем IT-споры отличаются от обычных коммерческих споров?
Модератор мероприятия: Чем IT-споры принципиально отличаются от обычных коммерческих споров?
Дискуссия экспертов мероприятия:
— Во-первых, это динамичные контракты.
В долгосрочном проекте по ходу реализации могут появиться технологии, которых на момент подписания договора еще не было.
Во-вторых, IT-сделка часто не двусторонняя: в ней могут быть третьи и четвертые стороны, владеющие технологиями или лицензиями, без которых продукт не работает.
В-третьих, результат IT-разработки нельзя “пощупать” — его нужно измерять специальными инструментами, фиксировать цифровой след и объяснять техническую картину суду обычным языком.
— В IT-спорах почти гарантированно возникает техническая экспертиза. Это споры с большим объемом доказательств и сложным процессом доказывания, особенно когда судья не является IT-специалистом.
— В отличие от поставки товара, здесь сложно определить, насколько качественно был сделан результат. К моменту экспертизы продукт может измениться, доступ к CRM может быть утрачен, лицензия может быть отозвана. В итоге эксперт уже не всегда видит тот же продукт, который передавался заказчику.
|
Эксперты также подчеркнули, что в IT-споре юристы не могут работать отдельно от команды клиента. Нужны разработчики, технические специалисты, project-менеджеры — люди, которые могут объяснить, на каком этапе возникла неполадка, кто принимал решение и что фактически было сделано. |
Какие доказательства работают в IT-спорах?
Модератор мероприятия: Если убрать очевидные документы, что еще может стать доказательством?
Мнение модератора мероприятия:
Первое, во что все равно упирается спор, — официальный подписанный документ: договор, акт, письмо, протокол, входящий номер. Суд, даже рассматривая сложный IT-конфликт, часто начинает с привычных вопросов: где акт, где переписка, направлялось ли письмо, кто и когда его получил.
Но IT-споры требуют более широкой доказательственной базы. В одном из кейсов работа была доказана через публичную презентацию продукта: формальный финальный акт передачи отсутствовал, но продукт был представлен публично, отражен в СМИ и сопоставлен с перепиской и фактическим внешним видом разработанного решения.
В другом кейсе обсуждался киберинцидент на платформе, которую планировали приобрести. Нужно было установить, где именно в цепочке передачи сигнала произошла проблема: в исходном коде, на серверах, у партнеров платформы или на другом участке. В итоге ключевым стало установление технической причины инцидента и связь этой причины с дефектом исходного кода.
Отдельная сложность — мессенджеры. WhatsApp или Telegram могут быть частью доказательной базы, если в договоре заранее предусмотрено, что такой канал коммуникации является надлежащим. Но Telegram как официальный канал принятия решений вызывает риски: сложно персонализировать участников, часть сообщений может быть удалена, а целостность переписки потом становится предметом спора.
Что закладывать в dispute management до конфликта?
Модератор мероприятия: Какие механизмы разрешения споров нужно предусматривать еще на этапе договора?
Дискуссия экспертов мероприятия:
— В договор можно включить техническую экспертизу как один из этапов до суда: заранее определить, кем она проводится и какие вопросы помогает прояснить. Такая экспертиза переводит спор с технического языка на более понятный для суда и сторон.
— Важно иметь протоколы, которые фиксируют, кто вносит изменения, кто имеет доступ к паролям, кто отслеживает цифровые следы. Это не только вопрос кибербезопасности, но и вопрос невмешательства, сохранения доказательств и возможности установить техническую причину спора. Досудебный порядок должен позволять зафиксировать “точку спора” еще до того, как каждая сторона начнет строить свою правовую аргументацию.
|
Эксперты обсудили и комиссионный механизм: в договоре можно предусмотреть досудебную комиссию с представителями обеих сторон и, при необходимости, независимым техническим экспертом. Такой эксперт может фиксировать состояние системы, а комиссия — рассматривать ситуацию на основании этой фиксации. |
Один из экспертов мероприятия обратил внимание на vendor lock: если заказчик технически зависим от вендора, спор не должен автоматически останавливать поддержку работающей системы. В контракте можно предусмотреть, что даже при конфликте вендор продолжает поддержку, а заказчик продолжает оплачивать ее в согласованном порядке.
Финальный вывод обсуждения: хороший контракт не гарантирует, что стороны никогда не поссорятся.
Его задача — создать понятную платформу: как фиксировать проект, как управлять изменениями, как принимать результат, как сохранять доказательства и как выходить из конфликта без потери контроля над продуктом.
По вопросам сотрудничества и предложений — PR _revera@revera.legal.
Для получения консультации — kazakhstan@revera.legal.
