Договір на впровадження AI: вісім пунктів, відсутніх у стандартному IT-договорі

Матеріал-посібник, написаний з перспективи виконавця. Описує типові рішення, не розглядає індивідуальні випадки. На передвпроваджувальних зустрічах у компаніях на 50–250 осіб регулярно звучить одна теза: для впровадження AI достатньо стандартного договору на впровадження IT плюс додатка про GDPR. Звучить розумно. Стандартний договір IT регулює строки, приймання, штрафи, право власності на код і обробку даних. Якщо чат-бот або автоматизація документів це просто «чергова система», то навіщо вигадувати нові пункти. Додатково сам AI Act не нав'язує окремої форми договору для систем низького ризику.

Найсильніший аргумент іншої сторони

Цей аргумент має солідне підґрунтя. У стандартному договорі IT зазвичай є графік приймання, договірні штрафи, передача майнових авторських прав на код, процедура повідомлення про помилки та договір про обробку даних за ст. 28 GDPR. Під час впровадження ERP чи платформи e-commerce цього зазвичай вистачало. Постачальники систем AI також пропонують шаблони із загальними положеннями про безпеку та заборону навчання на даних клієнта. Штрафи за GDPR сягають 4% річного обороту, тому наявність додатка про обробку даних часто вважають достатнім захистом. До того ж штрафи за AI Act, до 15 000 000 EUR або 3% глобального обороту, стосуються переважно постачальників систем високого ризику, а не компанії, яка впроваджує чат-бота для обслуговування замовлень.

AIЗображення згенероване AI.

Чого цей аргумент не охоплює

Стандартний договір IT не врегульовує чотирьох речей, які в AI визначають ризик. По-перше, промпт і конфігурація: чи є вони твором у розумінні закону про авторське право, залежить від їхнього творчого характеру, але шаблон зазвичай замовчує, кому належать майнові авторські права. У результаті після завершення договору постачальник може використати той самий шар промптів у конкурентів. По-друге, версіонування моделі: OpenAI та Anthropic виводять моделі з експлуатації з попередженням за кілька тижнів або місяців, що видно в документації депрекацій, а стандартний договір не дає клієнту права заблокувати автооновлення до приймальних тестувань. По-третє, експорт даних: логи розмов і векторні ембеддинги це не звичайні таблиці SQL, тому формулювання «постачальник поверне дані» часто залишається порожньою декларацією. По-четверте, галюцинації: відповідальність за «помилковий результат» вимагає порогу, інакше кожна некоректна відповідь стає суперечкою про якість. До цього додається розмежування ролей за AI Act: постачальник системи AI та суб'єкт впровадження мають різні обов'язки, а стандартний договір IT зазвичай їх не розділяє. З 2.08.2026 чат-боти зобов'язані інформувати про взаємодію з AI та маркувати згенерований контент.

Наша позиція

У нашій практиці договір на впровадження AI у промислову експлуатацію містить вісім застережень, яких немає у стандартному IT-договорі: права на промпти та конфігурацію (передача майнових авторських прав або безвідклична безстрокова ліцензія з правом модифікації та субліцензування), сповіщення за 60 днів про виведення моделі з експлуатації та заборона автоматичного оновлення без приймальних тестувань, експорт даних за 30 днів у форматах JSON/CSV/JSONL, видалення резервних копій за 60 днів, поріг галюцинацій ≤5% на тестовому наборі, ліміт відповідальності постачальника на рівні 12-місячних платежів, депонування промптів і коду в нотаріуса або ескроу та супровід після завершення співпраці протягом 3 місяців за стандартною ціною. У нас це виглядає так: під час впровадження поштового асистента на вибірці з 500 повідомлень ми спочатку отримали картку моделі з метриками, а версію визначили приймальні тестування на цій самій вибірці. Без цих пунктів клієнт залишається з робочою системою, але без шляху виходу та без порогу відповідальності за те, що відповідає система.

AIЗображення згенероване AI.

Що варто зробити в цьому кварталі

У цьому кварталі, ще до підписання, варто перевірити, чи погоджується постачальник на експорт даних за 30 днів та тест на галюцинації ≤5%. Відмова від обох умов не означає зриву проєкту, але чітко вказує, які ризики залишаються на боці клієнта. Ми б змінили позицію за однієї умови: якщо постачальник надасть локальний екземпляр моделі open source з перевіреною аудитом карткою моделі та повним доступом до вагів. Тоді застереження про виведення зовнішнього API з експлуатації втрачають значення. До того часу розглядаємо договір про впровадження AI як окремий документ, а не додаток до стандартного IT-шаблону.