SaaS-угоди минулих років несуть нові ризики через інтеграцію ШІ в оновлення

Інтеграція генеративного штучного інтелекту в повсякденні програмні продукти створює непередбачені юридичні та технічні ризики для організацій, які підписали стандартні SaaS-угоди багато років тому. Головні ризики здебільшого криються не у спеціальних додатках щодо ШІ, а у звичних застарілих пунктах, погоджених задовго до масового поширення LLM.

Оновлення сервісів без погодження з юристами

Типовий сценарій виникає, коли постачальник ПЗ (наприклад, CRM) розгортає власного або інтегрованого ШІ-асистента в межах звичайного продуктового оновлення. Інструмент автоматично отримує доступ до інформації на платформі, читає дані клієнтів і створює повідомлення без перегляду контракту з боку відділу закупівель чи юристів.

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

Розмитість категорій і обмеження поняття «No Training»

Традиційні контракти передбачали захист виключно для клієнтських даних (customer data). Сучасні угоди щодо ШІ дедалі частіше розбивають інформацію на окремі категорії:

• вхідні дані (inputs або prompts);
• вихідні дані (outputs);
• дані використання (usage data);
• сервісні дані (service data);
• агреговані або знеособлені дані (aggregated / de-identified data).

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

Поширене формулювання «заборона навчання» (no training) не закриває всіх потреб. Вендори використовують дані для різних процесів:

• навчання базових моделей (base-model training);
• точне налаштування (fine-tuning);
• оцінювання та перевірка безпеки;
• пошук інформації під час генерації (retrieval).

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

Знеособлені дані та правовий статус outputs

Пункти про використання деідентифікованих даних довгий час застосовувалися для базової аналітики та покращення продуктивності. Проте статус знеособлених даних рідко чітко визначає технічні стандарти такої процедури. Зазвичай ця категорія випадає з обов'язків вендора щодо видалення первинних даних або моделей, розроблених на їхній основі, а в окремих випадках постачальник може отримати повне право власності на цей датасет.

Окрему невизначеність створюють вихідні дані (outputs). Вони можуть не бути унікальними для різних клієнтів за схожих промптів, а деякі постачальники прямо відмовляються гарантувати їхній захист як об'єктів інтелектуальної власності. Водночас від замовників нерідко вимагають широких гарантій щодо будь-якої інформації, яку вони передають у системи ШІ, що створює договірну асиметрію зобов'язань.