Генеративні інструменти перестали бути експериментом і перетворилися на звичайну частину робочого процесу: автодоповнення коду, генерація тестів, рефакторинг, документація, переклад інтерфейсів.
Продуктивність зростає, а разом із нею — набір юридичних питань, які більшість команд відкладає «на потім». Розберімо ті з них, що реально впливають на бізнес.
Кому належать права на згенерований код
Класичне авторське право виходить із того, що твір створює людина. Результат роботи алгоритму, отриманий без творчого внеску людини, у багатьох правопорядках не отримує повноцінної охорони як об’єкт авторського права. На практиці це означає ризик: фрагмент продукту, повністю згенерований інструментом, може виявитися таким, що не належить нікому виключно — а отже, ви не зможете заборонити його використання іншим.
Для більшості команд це не привід відмовлятися від інструментів, але привід розуміти межу. Що більший творчий внесок розробника — постановка задачі, доопрацювання, архітектурні рішення, — то надійніша позиція компанії щодо прав на кінцевий результат.
Ліцензійна чистота: непомітний ризик
Моделі навчалися на великих масивах відкритого коду, зокрема під копілефт-ліцензіями. Якщо в продукт потрапляє фрагмент, що відтворює код під такою ліцензією, у вас з’являється зобов’язання, про яке ніхто не здогадується — аж до розкриття вихідного коду похідного твору. Виявляється це зазвичай під час технічного аудиту перед інвестиційним раундом або продажем компанії.
Практичне рішення — автоматизована перевірка залежностей і згенерованих фрагментів на відповідність ліцензіям, включена в конвеєр збірки, а не разова перевірка перед релізом.
Дані клієнтів у зовнішніх сервісах
Найчастіша й найнедооціненіша помилка — передавання конфіденційної інформації у сторонній сервіс. Уривок клієнтського коду, база тестових даних із реальними записами, внутрішня документація, вставлені у вікно чату, — це передання даних третій стороні. Якщо в договорі із замовником є NDA, а в політиці обробки персональних даних — перелік субпідрядників, таке передання може бути прямим порушенням.
- Визначте письмово, які категорії даних узагалі не можна передавати у зовнішні інструменти.
- Перевірте умови сервісу щодо використання введених даних для донавчання моделей.
- Узгодьте застосування таких інструментів із замовником, якщо працюєте з його даними.
- Зафіксуйте правила у внутрішній політиці, а не в усних домовленостях.
Що писати в договорі із замовником
Дедалі частіше корпоративні клієнти прямо запитують, чи використовує підрядник генеративні інструменти під час розробки. Замовчування тут — гірша стратегія: якщо факт з’ясується згодом, це стане підставою для претензій щодо порушення умов конфіденційності. Розумніший підхід — прописати допустимі сценарії використання, категорії даних, які не передаються назовні, і підтвердження того, що виконавець забезпечує передання замовнику прав на результат незалежно від способу його створення.
Відповідальність за результат
Помилка, внесена інструментом, юридично залишається вашою помилкою. Перед замовником відповідає виконавець, а не постачальник моделі. Тому положення договору про гарантії якості, тестування й порядок виправлення дефектів набувають додаткової ваги: посилатися на «так згенерував алгоритм» не вийде.
Що варто зробити командам уже зараз
Мінімальний набір: внутрішня політика використання AI-інструментів, положення в договорах із розробниками про належність прав на всі результати роботи, перевірка ліцензій у конвеєрі збірки та узгодження з клієнтами допустимих інструментів. Це кілька документів, які потім помітно спрощують due diligence.
Практику з цих питань регулярно розбирає Kondratiev Legal — від договорів із розробниками до підготовки продукту до технічного аудиту. Загальні підходи ЄС до регулювання систем штучного інтелекту опубліковані на порталі цифрової стратегії Європейської Комісії, і українським компаніям з європейськими клієнтами варто орієнтуватися саме на ці вимоги.
