ШІ для внутрішньої юридичної команди: огляд договорів та RAG

Юридичний відділ середньої виробничої компанії отримує щомісяця від 40 до 120 договорів для перегляду: NDA, контракти з постачальниками, додатки, замовлення. Більшість — це стандартні документи, в яких юрист шукає відхилення від корпоративного зразка. Читання їх сторінка за сторінкою займає кілька десятків годин на місяць, які можна скоротити, якщо ШІ зробить перший прохід і позначить місця, що потребують уваги.

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

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

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

Після класифікації система порівнює кляузи з корпоративним зразком договору даного типу. Відхилення потрапляють до списку для перегляду з номером сторінки та оцінкою рівня ризику (низький / середній / високий за попередньо визначеними критеріями). Юрист бачить спочатку те, що дійсно відрізняє документ від стандарту, а не весь текст від початку.

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

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

Для внутрішнього відділу найціннішим є реєстр зобов'язань та термінів. Система після обробки портфеля договорів створює таблицю з датами закінчення, строками розірвання та циклічними зобов'язаннями (наприклад, обов'язок звітувати щокварталу). Сповіщення надходить до юриста або власника процесу за 30-60 днів до терміну.

Кілька застережень, які ми спостерігаємо в пілотах:

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

Юрист перевіряє екстракцію для кляуз, позначених як «низька впевненість», та затверджує реєстр перед внесенням даних до системи відстеження термінів.

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

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

Ключові технічні вимоги:

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

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

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

Ця таблиця описує патерн, який випливає з багаторазово повторюваного нами в пілотах проектування human-oversight. ШІ надає матеріал; людина вирішує всюди, де рішення має юридичне або фінансове значення.

Корпоративні договори містять персональні дані сторін: імена, посади, номери PESEL у трудових договорах або B2B, контактні дані, іноді інформацію про винагороду в додатках. Обробка цих даних системою ШІ потребує правової підстави та технічних заходів.

Дві вимоги, без яких ми не запускаємо пілот:

PII masking перед індексацією. Персональні дані, що ідентифікують фізичних осіб, маскуються або токенізуються до того, як фрагменти документів потрапляють до векторної бази. Модель бачить позначення «ОСОБА_ФІЗИЧНА_1» замість конкретного імені. Відображення токенів на реальні дані зберігається поза індексом, з контролем доступу та логом операцій.

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

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

Детальні регуляторні обов'язки для систем ШІ, що обробляють корпоративні документи, розглядає стаття AI Act та RODO 2026. Технічні патерни відповідності RODO при впровадженнях ШІ знайдете в governance даних для ШІ.

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

Хороша відправна точка — один тип документа з високою повторюваністю, наприклад, NDA від нових постачальників. Обсяг пілота: класифікація (чи це NDA), екстракція 5-7 полів (сторони, дата, термін дії, кляузи конфіденційності, юрисдикція), порівняння з корпоративним зразком NDA та виявлення відхилень.

Протягом перших 4-8 тижнів юрист перевіряє 100% результатів ШІ. Це дозволяє відкалібрувати пороги впевненості, знайти типи відхилень, які модель не виявляє, та створити golden set для оцінки якості.

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

При пілотах in-house варто заздалегідь узгодити з ІТ-відділом модель доступу: хто має доступ до індексу, як логуються операції та чи підписані договори доручення обробки з постачальниками інфраструктури. Патерн договорів доручення розглядає стаття договір доручення даних ШІ.

Ні. Затвердження договору — це юридичне та бізнес-рішення, яке належить людині. ШІ готує матеріал: класифікує документ, вилучає кляузи, вказує на відхилення від зразка та позначає ризик. Остаточне рішення про підписання або відхилення договору потребує оцінки контексту угоди, відносин зі стороною та пріоритетів компанії, чого ШІ не знає і не може оцінити.

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

Це ризик, який слід вимірювати як recall на попередньо анотованому тестовому наборі. Якщо recall для критичних кляуз (терміни, штрафні санкції) падає нижче 90-95%, проблема зазвичай полягає в способі поділу документа на фрагменти (chunking) або в тому, що кляуза використовує нестандартне формулювання. Рішення — розширення набору тренувальних прикладів для класифікатора або налаштування chunking під структуру ваших документів. Протягом усього часу роботи системи верифікація кляуз критичного значення має залишатися за юристом.

Це залежить від чутливості документів. Договори, що містять персональні дані або охоплені NDA та комерційною таємницею, мають оброблятися локально або з маскуванням PII перед відправкою до зовнішнього API. Для внутрішніх документів без персональних даних хмарне API допустиме, якщо постачальник підписав договір доручення обробки даних та декларує нульове збереження промптів. Рішення варто узгодити з DPO перед запуском.

Пілот для одного типу документів зазвичай займає 3-6 тижнів: тиждень на інжекцію та індексацію тестового набору (100-300 договорів), тиждень на налаштування guardrails та калібрування порогів впевненості, 2-4 тижні на верифікацію результатів з юристами. Розширення на наступні типи документів та інтеграцію з системою управління договорами (CLM або DMS) залежно від обсягу займає 2-3 місяці. Оцінку готовності процесу до автоматизації проводить інструмент оцінка готовності. }