Що прописати в договорі на розробку AI-агента

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

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

Чому модель, на якій працює ваш агент, має дату зняття?

Постачальники моделей описують цей розклад публічно. Anthropic ділить моделі на чотири стани: active — повна підтримка; legacy — оновлень більше не буде; deprecated — модель ще працює, але їй уже призначено дату зняття і рекомендовано заміну; retired — запити падають з помилкою.

Про зняття публічно випущеної моделі Anthropic попереджає щонайменше за 60 днів тих клієнтів, у кого вона працює в проді. OpenAI веде такий самий публічний список застарілих моделей із датами відключення. Окремо в документації зазначено, що партнерські платформи, Amazon Bedrock і Google Cloud, призначають власні дати. Статус тієї самої моделі в хмарі, де крутиться ваш агент, може відрізнятися від статусу в API постачальника, і дізнаєтесь ви про це в найгірший момент.

Друге, що варто знати до підписання: перехід на нову версію коштує роботи, і зазвичай не тієї, яку закладає замовник. У себе ми поміряли так. У квітні 2026 року Auspex перевів шість власних агентів з Claude Opus 4.6 на 4.7: дванадцять переписаних системних промптів і чотири баги в обгортці навколо моделі, які попередня, повільніша версія успішно маскувала. Окремо довелось правити власні API-конфіги: фіксований бюджет на роздуми у новій версії поступився адаптивному.

Жодна з цих робіт не виглядає як «поміняти рядок з назвою моделі». І жодна не описана в типовому SOW.

Блок 1. Чому промпти — це продукт і їм місце в deliverables?

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

Що має потрапити в перелік:

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

Найцінніший рядок тут третій. Evaluation-набір — це те, чим ви через півроку доведете, що після оновлення моделі агент поводиться інакше. Без нього обидві сторони описуватимуть якість словами, а слова в суперечці не важать нічого. Складання такого набору — окрема робота на кілька днів, і вона має бути або в обсязі робіт, або чесно винесена за нього з окремим цінником.

Приймання варто прив'язати до того самого набору. У шаблонах, з якими працює Auspex, замовник має десять робочих днів на письмове прийняття або обґрунтовану відмову, а мовчання зараховується як прийняття. Для агента десять днів «подивитися очима» майже нічого не дають: приймання має означати прогін evaluation-набору і зафіксований результат по кожному сценарію.

Блок 2. Чим ліцензія на промпти відрізняється від власності на них?

Розділ про інтелектуальну власність у типовому IT-договорі влаштований так. Кожна сторона лишає за собою те, що мала до початку робіт або створила незалежно від них, — це background IP. А на результати робіт замовник отримує ліцензію: після повної оплати, всесвітню, безстрокову.

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

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

Розмежовувати треба за вмістом. Специфічним для замовника варто вважати те, що містить його термінологію, назви етапів угод, правила знижок, скрипти відділу продажів, перелік винятків із політики. Загальним — архітектуру рішення і шаблони, з яких усе перелічене вирізано. Цю межу краще описати двома-трьома прикладами прямо в SOW: в абстрактному формулюванні вона розповзається за перший же місяць роботи.

Блок 3. Як прописати процедуру міграції моделі?

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

Тригер тут — публікація постачальником дати зняття або переведення моделі в deprecated. Далі описується, хто що робить:

• хто відстежує оголошення постачальника і в який строк повідомляє другу сторону
• скільки часу відводиться на аналіз впливу з моменту оголошення
• прогін evaluation-набору на новій моделі до перемикання, з письмовим звітом про розбіжності
• чи буде вікно паралельної роботи старої і нової версій, і хто його оплачує

Гроші — там, де найчастіше дірка. Слово «підтримка» в договорі зазвичай не має визначення, і кожна сторона розуміє його на свою користь. Розділяти варто так: прогін набору і звіт про розбіжності входять у підтримку, а переписування промптів понад узгоджений обсяг годин іде окремим change order за ставкою з договору. Кількість годин ставите свою, з огляду на розмір агента, тільки не лишайте її неназваною.

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

Блок 4. Що вважати невдалою міграцією?

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

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

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

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

Чого договір усе одно не гарантує?

Окремий «договір на AI» для цього не потрібен: усі чотири блоки лягають у наявні розділи рамкового договору та SOW. Але межа є, і про неї краще сказати вголос до підписання.

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

З чого почати цього тижня?

• відкрийте діючий договір і пошукайте в переліку результатів робіт слово «промпт» — якщо його там немає, це перша правка
• спитайте підрядника, чи існує evaluation-набір для вашого агента і де він зберігається
• перевірте в документації постачальника, який статус має модель, на якій ви працюєте зараз

Третій пункт займає п'ять хвилин і регулярно виявляється найнеприємнішим: модель, на якій запускались півроку тому, вже стоїть у списку deprecated із призначеною датою.

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

І дрібниця, яка чомусь ніколи не потрапляє в договір, а потім коштує тижня: у кого лежать ключі API і на чиє юридичне ім'я оформлено акаунт у постачальника моделі. Перевірте це принагідно.