Договір SaaS: ключові умови для IT-продукту

Чим SaaS-договір особливий

SaaS (software as a service) — це модель, за якою клієнт не отримує копію програми, а користується її функціоналом на інфраструктурі постачальника за підпискою. Звідси три принципові відмінності від класичної ліцензії на коробкове програмне забезпечення.

• Нічого не передається. Копія програми не встановлюється в клієнта, об’єкт не переходить у його володіння, а отже конструкції про «передання примірника» тут не працюють.
• Цінність — у безперервності. Для клієнта критично не «що він отримав», а чи працює сервіс щодня. Звідси центральна роль SLA, якої в ліцензійному договорі немає взагалі.
• Дані клієнта лежать у постачальника. Це створює окремий блок зобов’язань щодо захисту, обробки та повернення даних, якого в коробковому ПЗ теж не було.

Практичний наслідок: шаблон ліцензії на коробкове ПЗ для SaaS не підходить, і навпаки — SaaS-договір без SLA та без розділу про дані є неповним незалежно від того, наскільки добре в ньому описані права.

Структура, яка працює для B2B SaaS, зазвичай складається з рамкової угоди та додатків: основні умови (MSA або Terms of Service), замовлення (order form) з тарифом і обсягом, SLA, угода про обробку даних (DPA), політика конфіденційності та, за потреби, угода про нерозголошення. Такий поділ дозволяє змінювати комерційні умови, не переписуючи весь договір.

Окремо варто розрізняти B2B і B2C. У відносинах із фізичними особами-споживачами діє законодавство про захист прав споживачів і вимоги Закону «Про електронну комерцію» № 675-VIII, зокрема щодо мови, обсягу інформації та порядку укладення договору. Деталі — у матеріалі про вимоги електронної комерції.

Правова природа: послуга чи ліцензія

Це питання виглядає теоретичним рівно до першої податкової перевірки або до першого спору.

Українське право не має окремого поіменованого договору SaaS. На практиці використовують гібридну конструкцію: договір є симбіозом договору про надання послуг і ліцензійного договору, де оплата здійснюється за надання послуг з доступу, а обмежена невиключна ліцензія оформлює право користуватися програмою в межах сервісу.

Чому це важливо — через розмежування послуги та роялті, яке має прямі податкові наслідки. Орієнтир, яким керується практика:

Якщо клієнт не отримує права тиражувати, модифікувати чи розповсюджувати програму, а користується нею виключно для власних потреб, це ознаки послуги, а не роялті. Формулювання в договорі при цьому мають значення: назва платежу й опис обсягу прав читаються першими.

Практична порада: узгодьте кваліфікацію до підписання, а не після. Якщо ваш клієнт або постачальник — нерезидент, від кваліфікації залежить, чи виникає обов’язок утримати податок з доходу нерезидента, як застосовується конвенція про уникнення подвійного оподаткування і за якими правилами визначається місце постачання для ПДВ. Для цілей ПДВ перелік статті 186.3 Податкового кодексу охоплює, зокрема, надання майнових прав інтелектуальної власності, створення за замовленням і використання об’єктів права інтелектуальної власності, у тому числі за ліцензійними договорами, а також послуги з розроблення та тестування програмного забезпечення — для яких місцем постачання вважається місце реєстрації отримувача.

Оскільки SaaS як окрема категорія в цих нормах прямо не названий, кваліфікація кожного конкретного договору залежить від його змісту. Це той випадок, коли формулювання предмета варто погоджувати разом із податковим консультантом, а не лише з юристом.

Предмет і обсяг прав

Розділ, який визначає, що саме купує клієнт. Чим точніше він написаний, тим менше спорів про «це мало входити в тариф».

Що обов’язково має бути зафіксовано:

• опис сервісу і перелік функціональних модулів, із посиланням на документацію як на невід’ємну частину договору;
• обсяг ліцензії: невиключна, така, що не підлягає передачі та субліцензуванню, обмежена строком підписки й територією, виключно для внутрішніх потреб клієнта;
• метрики обсягу: кількість користувачів або робочих місць, кількість транзакцій, обсяг сховища, ліміти запитів до API — і що відбувається при їх перевищенні (автоматичне донарахування, блокування, перехід на вищий тариф);
• заборонені дії: реверс-інжиніринг у межах, дозволених законом, обхід технічних обмежень, перепродаж доступу, використання для створення конкурентного продукту, навантажувальне тестування без погодження;
• право на зміну функціоналу: постачальник зазвичай залишає за собою право розвивати продукт, але для клієнта важливо обмежити істотне погіршення або вилучення функцій, за які він платить, і передбачити попередження за розумний строк;
• права на результати: хто володіє конфігураціями, кастомізаціями, інтеграціями, створеними в межах проєкту, і чи переходять права на доопрацювання, оплачені клієнтом;
• зворотний зв’язок: застереження, що пропозиції клієнта щодо покращення продукту можуть використовуватися постачальником без додаткової винагороди — стандартна й справедлива умова, яку варто прописувати прямо;
• гарантії щодо прав третіх осіб і зобов’язання захистити клієнта від претензій про порушення інтелектуальної власності.

Останній пункт — одна з небагатьох позицій, де клієнт обґрунтовано вимагає необмеженої відповідальності постачальника. Логіка проста: клієнт не може перевірити чистоту прав на продукт, тому ризик має нести той, хто його створив. Що саме перевіряють у цьому контексті — у матеріалі про захист коду та IP в IT.

Рівень сервісу (SLA)

SLA — єдиний розділ, який перетворює обіцянку «сервіс працює» на вимірюване зобов’язання. Без нього клієнт у разі простою не має чого вимагати, крім загальних норм про неналежне виконання.

Що має містити робочий SLA:

1. Гарантований рівень доступності у відсотках за розрахунковий період. Орієнтири: 99,5 % — близько 3,6 години простою на місяць; 99,9 % — близько 43 хвилин; 99,95 % — близько 22 хвилин. Відсоток без зазначення періоду та методики вимірювання не означає нічого.
2. Методика вимірювання: що вважається простоєм, хто і чим його фіксує, чи враховується часткова недоступність окремих функцій, який інтервал перевірки.
3. Класифікація інцидентів за критичністю з часом реакції та часом відновлення для кожного рівня. Важливо розрізняти ці два показники: гарантований час реакції без зобов’язання щодо відновлення захищає слабко.
4. Планові роботи: максимальна тривалість, часові вікна, строк попередження, чи виключаються вони з розрахунку доступності.
5. Канали підтримки і графік їх роботи, зокрема чи є підтримка в неробочий час і в яких випадках.
6. Сервісні кредити — компенсація за недотримання рівня, зазвичай у вигляді відсотка місячної плати, що зростає зі зростанням простою.
7. Виключення: форс-мажор, збої на боці клієнта, проблеми провайдерів, дії самого клієнта, атаки. Перелік має бути закритим і прозорим, інакше він з’їдає всю гарантію.

Два питання, які вирішують цінність SLA для клієнта.

Чи є сервісні кредити єдиним засобом захисту. Постачальники зазвичай пишуть, що кредити є виключним засобом захисту (sole remedy). Клієнту варто домогтися винятку: при систематичному порушенні рівня доступності протягом кількох періодів поспіль має виникати право на дострокове розірвання без штрафу і з поверненням передоплати.

Як кредити отримуються. Якщо вони нараховуються лише за письмовою заявою клієнта у короткий строк після інциденту, на практиці їх майже ніхто не отримує. Автоматичне нарахування за даними моніторингу — значно чесніший механізм.

Для українських реалій у SLA доцільно окремо врегулювати відключення електроенергії та зв’язку: чи є вони форс-мажором, які резервні потужності забезпечує постачальник, як це впливає на розрахунок доступності.

Обмеження відповідальності

Найбільш переговорний розділ будь-якого SaaS-договору і місце, де найчастіше припускаються помилки обидві сторони.

Головне правило: повністю зняти відповідальність не вийде. Частина 3 статті 614 Цивільного кодексу визнає нікчемним правочин, яким скасовується чи обмежується відповідальність за умисне порушення зобов’язання. У відносинах зі споживачами додатково діють обмеження законодавства про захист прав споживачів. Тому формулювання «постачальник не несе жодної відповідальності» не працює і лише псує позицію в суді.

Ринковий стандарт виглядає так:

• сукупна межа відповідальності — сума платежів за визначений період, зазвичай за 12 місяців, що передували події;
• виключення непрямих збитків: упущена вигода, втрата даних як така, репутаційні втрати, втрата можливостей;
• винятки з обмеження, на які межа не поширюється: порушення конфіденційності, порушення прав інтелектуальної власності третіх осіб, умисел і груба необережність, порушення зобов’язань щодо персональних даних, несплата клієнтом платежів.

Для клієнта ключове питання — чи співмірна межа з реальним ризиком. Якщо підписка коштує тисячу доларів на рік, а зупинка сервісу означає зупинку виробництва, межа в розмірі річної підписки не покриває нічого. Варіанти: підвищена межа за окрему плату, окремий ліміт для критичних порушень, страхування відповідальності постачальника, або технічні заходи — резервні процеси на боці клієнта.

Для постачальника ключове — не залишити межу відкритою і прямо виключити непрямі збитки, бо саме вони становлять основну частину вимог.

Окремо про indemnity — зобов’язання захистити іншу сторону від претензій третіх осіб і компенсувати витрати. Класичний розподіл: постачальник захищає клієнта від претензій про порушення прав інтелектуальної власності, клієнт захищає постачальника від претензій, пов’язаних із контентом і даними, які він завантажує. Для резидентів Дія.City у цьому розділі доступні додаткові конструкції: запевнення щодо договору за статтею 650-1 ЦК і компенсація як заздалегідь оцінені збитки за статтею 25 Закону № 1667-IX.

Дані, DPA і конфіденційність

Базове правило, яке має бути прямо записане: дані клієнта залишаються даними клієнта. Постачальник отримує лише обмежене право обробляти їх для надання сервісу, і будь-яке інше використання — аналітика, навчання моделей, знеособлена статистика — потребує окремої згоди.

Якщо серед даних є персональні, застосовується окремий шар регулювання. У типовій конструкції клієнт є контролером, а постачальник — оператором (processor), і їхні відносини оформлюються угодою про обробку даних (DPA) відповідно до статті 28 GDPR, якщо дані стосуються осіб у ЄС.

Що має містити DPA:

• предмет, тривалість, характер і мету обробки, категорії даних і суб’єктів;
• заборону обробки поза документованими інструкціями контролера;
• зобов’язання конфіденційності персоналу;
• технічні та організаційні заходи безпеки за статтею 32 GDPR;
• правила залучення субпроцесорів: попередня згода або повідомлення з правом заперечення, перелік чинних субпроцесорів;
• сприяння контролеру у відповідях на запити суб’єктів даних і в оцінках впливу;
• повідомлення про інциденти без неналежної затримки — на практиці договори встановлюють жорсткіші строки, ніж GDPR, нерідко 24 години;
• повернення або видалення даних після завершення обробки;
• право на аудит і надання підтверджень відповідності;
• механізм транскордонної передачі — стандартні договірні положення або інша підстава.

Окремо варто визначити локацію зберігання даних і те, чи може вона змінюватися без згоди клієнта: для частини замовників це умова допуску постачальника взагалі.

Конфіденційність оформлюється або окремою угодою, або розділом договору. Робочі елементи: визначення конфіденційної інформації з винятками, строк дії зобов’язань після припинення договору, порядок розкриття на вимогу закону з попереднім повідомленням іншої сторони, обов’язок повернути або знищити інформацію. Для резидентів Дія.City доступна окрема конструкція договору про нерозголошення за статтею 26 Закону № 1667-IX.

І практичне: у SaaS-договорі має бути зрозуміло, що саме відбувається з даними при інциденті безпеки — хто кого повідомляє, у який строк і в якій формі. Повна механіка реагування розібрана в матеріалі про кібербезпеку та витік персональних даних.

Припинення та повернення даних

Розділ, який пишуть останнім і про який згадують у найгірший момент. Його цінність у тому, що він визначає, чи зможе клієнт піти, не втративши накопичене.

Підстави припинення, які варто розвести:

• закінчення строку підписки без продовження — з чітким порядком автопродовження і строком попередження про відмову;
• розірвання за згодою сторін;
• одностороннє розірвання за зручності (for convenience) — чи доступне воно клієнту, з яким строком попередження і чи повертається передоплата;
• розірвання за порушення (for cause) — із строком на усунення порушення;
• призупинення доступу за несплату — з обов’язковим попередженням і пільговим строком, а не миттєво.

Повернення даних — найважливіша частина. Мають бути зафіксовані: строк, протягом якого дані доступні для вивантаження після припинення (типово 30–90 днів), формат вивантаження (машинозчитуваний, придатний для імпорту в інші системи, а не PDF-звіти), спосіб (самостійний експорт чи сприяння постачальника), вартість сприяння, якщо воно платне, і строк остаточного видалення даних із систем та резервних копій.

Умова «після припинення договору доступ блокується негайно» без вікна на вивантаження фактично означає втрату даних — і для клієнта це неприйнятно незалежно від ціни підписки.

Варто також передбачити перехідний період (transition assistance) для критичних сервісів: зобов’язання постачальника протягом визначеного строку надавати доступ і технічне сприяння при міграції на інше рішення, за окрему плату або в межах останнього тарифу.

Окремий блок — наслідки припинення: які положення переживають договір (конфіденційність, обмеження відповідальності, положення про право та вирішення спорів), чи підлягає поверненню невикористана передоплата і що відбувається з кастомізаціями та інтеграціями, створеними для клієнта.

І практична деталь, яку клієнти часто пропускають: умови договору, що розміщуються на сайті постачальника й можуть змінюватися в односторонньому порядку. Для B2B варто або зафіксувати редакцію на дату підписання, або домовитися про попередження про зміни з правом розірвати договір, якщо зміни істотні й неприйнятні.

Комерційні й податкові питання

Останній блок, який визначає економіку відносин і найчастіше викликає спори вже після запуску.

Ціноутворення і зміна ціни. Тариф, одиниця тарифікації, порядок перерахунку при зміні кількості користувачів у середині періоду, умови підвищення ціни на наступний період і строк попередження. Для багаторічних договорів варто обмежити річне підвищення формулою або стелею.

Валюта і курс. Для українських постачальників із закордонними клієнтами — валюта розрахунків, курс і момент його визначення, розподіл банківських комісій. Для українських клієнтів із закордонними постачальниками — хто несе валютні ризики та комісії.

Податкові застереження. Хто несе обов’язок щодо непрямих податків, чи включений податок у ціну (gross-up), як діють сторони, якщо законодавство вимагає утримання податку з доходу нерезидента, обов’язок надати документи для застосування конвенції про уникнення подвійного оподаткування — зокрема довідку про податкове резидентство.

Форма договору. Для експорту послуг поширена спрощена форма — виставлення інвойсу, але для складних IT-проєктів доцільний двомовний рамковий договір із замовленнями. Тут варто враховувати вимоги валютного нагляду до розрахунків за зовнішньоекономічними операціями, які періодично змінюються, тому актуальні правила і строки перевіряють на момент укладення договору.

Право і вирішення спорів. Вибір права та форуму — не формальність: від них залежить реальна вартість захисту. Для українських постачальників із клієнтами в ЄС і США типовий компроміс — право однієї сторони плюс арбітраж у нейтральній юрисдикції, із застереженням про досудові переговори та ескалацію. Для резидентів Дія.City частина 7 статті 7 Закону № 2275-VIII дозволяє обрати право для корпоративних домовленостей, але для самого SaaS-договору діють загальні правила міжнародного приватного права.

Короткий чек-лист перед підписанням SaaS-договору:

• предмет і обсяг ліцензії описані точно, документація є частиною договору;
• метрики обсягу і наслідки їх перевищення зрозумілі;
• є SLA з методикою вимірювання, часом реакції й відновлення та сервісними кредитами;
• при систематичному порушенні SLA є право розірвати договір;
• межа відповідальності співмірна ризику, винятки з неї перелічені;
• є DPA з правилами щодо субпроцесорів, інцидентів і локації даних;
• зафіксовані строк, формат і порядок повернення даних після припинення;
• узгоджено, хто володіє кастомізаціями та інтеграціями;
• зрозуміла кваліфікація платежу для податкових цілей;
• зафіксована редакція умов або передбачено попередження про зміни.

ІТ-юристи практики IT-права LEGIUS готують і перевіряють SaaS-договори, SLA та угоди про обробку даних для продуктових компаній і їхніх клієнтів. Щоб адаптувати шаблон під ваш продукт і ринок, запишіться на консультацію.