Master Service Agreement на IT-послуги: ключові умови
Співпраця між IT-компанією та замовником рідко обмежується одним завданням. Сьогодні це може бути розробка нового функціоналу, а надалі сторони вирішують співпрацювати щодо тестування, технічної підтримки, дизайну чи залучення окремої команди спеціалістів. Укладати окремий повний договір під кожен проєкт не завжди зручно, особливо якщо сторони планують довгострокові відносини.
Саме для таких випадків використовується Master Service Agreement, або MSA, який є рамковим договором, у якому сторони один раз погоджують загальні правила співпраці: порядок замовлення та оплати послуг, передачу прав інтелектуальної власності, конфіденційність, відповідальність, строк дії та процедуру розірвання.
При цьому сам MSA зазвичай не містить детального опису кожного завдання. Конкретні умови окремого проєкту сторони фіксують у Statement of Work, Service Order, технічному завданні або іншому додатку.
Тож пропонуємо розібратися, які положення мають бути в Master Service Agreement на IT-послуги, у супутніх документах до нього та на що слід звертати увагу під час перевірки шаблону контрагента.
MSA та Statement of Work: як розподілити умови?
Головна особливість генерального договору полягає у його рамковому характері. Він визначає правила, що застосовуються до всієї співпраці сторін, тоді як SOW встановлює умови конкретного проєкту або етапу.
| Master Service Agreement | Statement of Work |
| Загальний предмет договору | Конкретний перелік послуг, строки надання, етапи |
| Порядок визначення вартості, оплати та виставлення інвойсів | Конкретна вартість послуг, погодинні ставки, вартість за проєкт/етап тощо |
| Правовий режим інтелектуальної власності | Перелік результатів, порядок/строки передання та прийняття |
| Конфіденційність, непереманювання, неконкуренція | Конкретний склад команди залучених спеціалістів, якщо актуально |
| Відповідальність, строк дії і розірвання | Строк дії SOW |
У договорі важливо прямо визначити, який документ має перевагу у разі суперечності. Наприклад, сторони можуть погодити, що спеціальні умови SOW мають пріоритет над договором про надання ІТ-послуг лише щодо конкретного проєкту. Якщо ж ієрархію документів не встановлено, одна й та сама домовленість може тлумачитися по-різному.
Також необхідно визначити, як відбувається погодження та підписання SOW, з якого моменту він вважається чинним. Для IT-проєктів це особливо актуально, оскільки частина домовленостей часто фіксується через email, таск-менеджери або месенджери, тож SOW може додатково деталізуватися в комунікації окремо.
Як визначити предмет договору та модель співпраці?
Починати перевірку Master Service Agreement слід із простого питання: чи відповідає текст договору фактичним домовленостям сторін? Ще до підписання контракту замовник та виконавець зазвичай погоджують види послуг, строки, формат взаємодії, бюджет і порядок розрахунків. Саме ці умови мають коректно відображатися в договорі та додатках до нього.
Предмет рамкового договору не повинен бути настільки вузьким, щоб кожна нова послуга вимагала перепідписання всього договору. Водночас формулювання на кшталт «виконавець надає будь-які послуги на запит замовника» також створює ризики, оскільки не дає змоги визначити реальний обсяг зобов’язань.
Окрему увагу слід приділити моделі співпраці. Для Time & Materials необхідно погодити вартість години надання послуг, порядок обліку часу, timesheets та ліміти годин. Для Fixed Price — чіткий обсяг робіт, строки, milestones і процедуру зміни ТЗ. Для Dedicated Team або outstaff — склад команди, порядок заміни спеціалістів, мінімальне завантаження та строки повідомлення про скорочення команди.
На практиці дедалі поширенішою є Agile-модель, за якою розробка поділяється на окремі ітерації або спринти, а завдання можуть змінюватися протягом проєкту. У такому випадку MSA має встановлювати не кожну технічну деталь, а зрозумілий механізм погодження backlog, пріоритетів, строків і вартості робіт.
Вартість послуг, інвойси та приймання результатів: на що варто звернути увагу?
Фінансові умови — один із найбільш чутливих блоків Master Service Agreement. Сторонам слід визначити валюту, ставки, строки виставлення та оплати інвойсів, порядок компенсації витрат, банківські комісії та можливість перегляду вартості послуг.
Якщо застосовується погодинна оплата, договір має передбачати порядок відстежування та погодження витраченого часу. Для захисту замовника може встановлюватися максимальна кількість годин або бюджет, перевищення якого допускається лише за окремою згодою. Для виконавця важливо передбачити строк для оскарження інвойсу та право призупинити послуги у випадку прострочення оплати.
Не менш важливо врегулювати приймання результатів. У договорі слід визначити:
- що саме вважається результатом послуг;
- у який спосіб він передається замовнику;
- скільки часу замовник має на перевірку;
- якими мають бути зауваження;
- що відбувається, якщо замовник не надав відповіді;
- як відрізнити дефект від нової вимоги.
Радимо уникати формулювань, за якими результат має просто «повністю задовольняти замовника». Критерії приймання мають бути об’єктивними та пов’язаними із SOW, технічним завданням або погодженими стандартами.
Окремо варто перевірити, чи не містяться штрафи або інші фінансові наслідки у менш очевидних положеннях: наприклад, у розділах про строки, звітність, оплату, NDA або розірвання.
Інтелектуальна власність, open source та штучний інтелект
Для MSA на IT-послуги розділ про інтелектуальну власність є одним із ключових. Насамперед сторони мають розмежувати результати, створені спеціально для замовника, та попередні напрацювання виконавця.
До Background IP можуть належати внутрішні бібліотеки, шаблони, фреймворки, інструменти, методики та know-how, які існували до початку проєкту або використовуються в роботі з різними клієнтами. Якщо не встановити окремий режим для таких об’єктів, широке формулювання про передачу «всіх прав на все створене та використане» може фактично позбавити виконавця права використовувати власні інструменти в інших проєктах.
MSA також має визначати, коли саме права переходять до замовника: з моменту створення, передачі результату чи після повної оплати. На практиці для виконавця безпечнішою є передача прав після отримання оплати за відповідні послуги.
Сучасний договір також складно уявити без положень про open source та AI. Щодо open source, варто прямо визначити, чи дозволене його використання, які ліцензії є допустимими, чи потрібне попереднє погодження замовника та хто відповідає за порушення ліцензійних умов.
Умови щодо AI мають відповідати реальній практиці команди. Якщо розробники використовують генеративні інструменти для написання коду, тестування, дизайну або текстового контенту, договір має визначати межі такого використання. Зокрема, чи можна завантажувати до AI-сервісів код, персональні дані або конфіденційну інформацію, чи допускається включення AI-generated content до результатів та хто здійснює human review.
Простий дозвіл на використання ШІ не вирішує всіх питань. Доцільно також передбачити обов’язок перевіряти результат, тестувати його та гарантувати, що він не порушує права третіх сторін.
А що з конфіденційністю та безпекою даних у IT-контракті?
MSA зазвичай містить окремий розділ про конфіденційність або посилається на NDA. У ньому необхідно визначити, яка інформація є конфіденційною, з якою метою її можна використовувати, хто може отримувати до неї доступ та скільки часу діють відповідні обмеження.
Для IT-послуг цього часто недостатньо. Якщо виконавець має доступ до персональних даних, систем або інфраструктури замовника, можуть знадобитися DPA та окремі security requirements. Сторонам варто погодити порядок повідомлення про інциденти, правила доступу субпідрядників, повернення або видалення даних після завершення співпраці.
Якщо замовник вимагає дотримання ISO чи інших стандартів, у договорі слід чітко ідентифікувати конкретний стандарт, межі його застосування та спосіб перевірки відповідності. Загальний обов’язок «дотримуватися всіх застосовних стандартів» може бути недостатнім, розмитим або, навпаки, надто обтяжливим для виконавця.
Як прописати відповідальність та обмежити ризики?
Контрагенти часто прагнуть максимально детально врегулювати відповідальність іншої сторони, включно зі штрафами, компенсаціями та indemnity. Тому під час формулювання умов MSA важливо оцінювати не лише розмір відповідальності, а й підстави для її застосування.
У договорі доцільно встановити загальний liability cap, наприклад, у розмірі суми, сплаченої за певний період або за відповідний SOW. Окремо сторони можуть погодити винятки з ліміту, наприклад, для порушення конфіденційності, IP або захисту даних. Однак такі винятки не повинні автоматично перетворювати всю відповідальність виконавця на необмежену.
Також слід перевірити:
- чи виключені непрямі збитки та упущена вигода;
- чи не стягуються одночасно штраф, збитки та indemnity за одне порушення;
- чи має сторона право контролювати захист від претензій третіх осіб;
- чи обмежений строк для пред’явлення вимог;
- чи є відповідальність взаємною та збалансованою.
Необхідно враховувати і законодавство обраної юрисдикції, адже допустимість штрафів, non-compete та окремих обмежень відповідальності може суттєво відрізнятися. Детально про умови дійсності положень про неконкуренцію ми розповідали в цій статті.
Строк дії та розірвання MSA: як вийти зі співпраці?
В IT-галузі питання тривалості проєкту та можливості завершити співпрацю мають практичне значення для обох сторін. Компанія повинна розуміти, як швидко замовник може відмовитися від послуг, чи будуть оплачені вже виконані роботи та що станеться із зарезервованою командою.
MSA має визначати строк дії, порядок автоматичного продовження, розірвання з певних підстав (termination for cause) чи в односторонньому порядку за бажанням сторони (termination for convenience). Для порушень зазвичай передбачається cure period, тобто строк, протягом якого сторона може усунути порушення до розірвання договору.
Важливо також розмежувати припинення окремого SOW та всього MSA. Завершення одного проєкту не завжди має автоматично припиняти рамковий договір і всі інші активні замовлення.
При формулюванні умов чи аналізі проєкту контрагента варто звернути увагу на наслідки розірвання:
- оплату фактично наданих послуг;
- передачу готових і незавершених результатів;
- повернення обладнання та доступів;
- видалення або повернення конфіденційної інформації;
- перехідну підтримку;
- положення, які продовжують діяти після завершення договору.
Можливість негайного або спрощеного виходу контрагента може бути прихована не лише в розділі про розірвання, а й в окремому SOW, SLA чи положеннях щодо порушення строків. А на які моменти ще слід звертати увагу при перевірці договору із IT-компанією юристи Legal IT Group розповідали в цій статті.
Отже, підсумовуючи, перед підписанням Master Service Agreement радимо звертати увагу, зокрема, на наступне:
- Чи відповідає договір фактичним комерційним домовленостям?
- Чи зрозуміло, як укладаються та змінюються SOW?
- Який документ має перевагу у випадку суперечності?
- Чи правильно визначено модель оплати та порядок погодження годин?
- Чи є об’єктивні критерії приймання результатів?
- Коли переходять права інтелектуальної власності?
- Чи захищений Background IP виконавця?
- Як врегульовано використання AI та open source?
- Чи встановлений розумний ліміт відповідальності?
- Чи збалансовані умови розірвання та його наслідки?
- Чи відповідає договір законодавству обраної юрисдикції?
Отже, Master Service Agreement — це не просто універсальний шаблон для всіх майбутніх проєктів. Якісний MSA має створювати стабільну юридичну основу співпраці, але водночас залишати сторонам достатню гнучкість для погодження окремих завдань, бюджетів і строків.
Саме тому при підготовці або перевірці договору важливо аналізувати не лише його окремі положення, а й всю систему документів: MSA, SOW, SLA, DPA, технічні завдання та погоджену комунікацію сторін. Такий підхід допомагає мінімізувати юридичні й фінансові ризики та зробити співпрацю більш передбачуваною для обох сторін.
Якщо ви бажаєте отримати професійну допомогу при підготовці власного драфту чи погодженні проєкту договору з контрагентом звертайтесь до Legal IT Group.
Юристи Legal IT Group допоможуть на всіх етапах договірної роботи IT-компанії, врахують ризики та запропонують варіанти для максимального забезпечення інтересів компанії.
