AI-система підготовки юридичних документів: договори, претензії, позови

Чому AI-система для юристів зривається на живих договорах

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

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

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

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

У довгому договорі це десятки точок ручного введення, і будь-яка пропущена — ризик оспорюваної умови вже після підписання.

AI-система для юристів перестає зриватися, коли працює не з формою, а з моделлю умов. Типовий шаблон залишається каркасом, а витягування умов з договору наповнює його значеннями із зазначенням джерела — звідки взято і чим підтверджено. Розбираємо, як це закривається.

Ефекти впровадження: швидкість, єдиний стандарт, менше правок

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

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

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

Раніше у відділі паралельно існували різні редакції одного й того самого пункту про підсудність або відповідальність; тепер розбіжність видно прямо під час збирання.

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

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

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

Способи впровадження: хмара, контур замовника, гібрид

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

У хмарному контурі старт швидший: оновлення моделей і правил витягування реквізитів надходять централізовано, власні потужності не потрібні.

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

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

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

Етапи робіт: від аудиту документів до передачі в експлуатацію

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

1. Аудит документів. Розбираємо корпус: типи договорів, претензій і позовів, частку шаблонних блоків, якість сканів. На виході — карта документів і розуміння, де потрібна попередня нормалізація.
2. Схема рішення. Фіксуємо, що система заповнює сама, що бере з ваших довідників, а де обов'язкова перевірка юриста; окремо — права доступу й журнал дій.
3. Розмітка еталонних відповідей. Юристи розмічають зразки: правильні формулювання, допустимі варіації, критичні помилки. Цей набір стає мірою якості замість «схоже на правду».
4. Інтеграція зі сховищем документів. Підключаємося до вашого контуру: папки, система електронного документообігу, ролі користувачів. Документи залишаються у вас і доступні системі за правами.
5. Впровадження генеративної системи. Збираємо сценарії під конкретні типи документів, налаштовуємо обов'язкові посилання на норми й перевірку на суперечності всередині тексту.
6. Перевірка на історичних справах. Прогонимо закриті справи і звіряємо з тим, що юристи готували вручну; розбіжності розбираємо й дообучаємо систему на слабких місцях.
7. Приймання результату й передача. Перевіряємо роботу за заздалегідь узгодженими критеріями на вашій вибірці. Ви отримуєте регламент роботи, документацію й навчання співробітників.

Що передаємо на руки: конфігурації, схеми, регламенти

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

• Конфігурації системи — профілі обробки за типами документів (договори, претензії, позови), набори правил перевірки, пороги спрацювання й довідники типових умов. Розгортаються зі сховища версій однією командою, відкат до попереднього набору можливий без перезбирання.
• Схема потоків документів — шлях файлу від завантаження до видачі: де витягуються реквізити, де відбувається звірка з внутрішніми базами, а де стоїть обов'язкове підтвердження юристом. Схема показує, у якій точці кожна роль втручається в процес.
• Ролі доступу — матриця «роль × дія»: хто готує чернетку, хто погоджує, хто бачить закриті розділи й персональні дані, хто має право правити бібліотеку шаблонів. Права видаються за принципом мінімальної достатності.
• Журнал дій — незмінний запис операцій: хто відкривав документ, що змінював, яка версія пішла контрагенту. Один і той самий журнал слугує і внутрішньому контролю, і доказом у спорі про правки.
• Бібліотека шаблонів — договори, претензії та позови з розміткою змінних полів і правилами підстановки. Кожна зміна версіонується й проходить перевірку до потрапляння в робочий контур.
• Регламент роботи відділу — як юристи ставлять завдання системі, що робити при розбіжності з шаблоном, хто і в який строк розбирає помилкові спрацювання. Регламент узгоджуємо з керівником напряму, а не пишемо за нього.
• Документація системи — опис архітектури й точок інтеграції, інструкції адміністратора й пам'ятка користувача. Новий співробітник виходить на самостійну роботу за нею, без окремого навчання в нас.

Усе це передається разом із вихідними матеріалами й залишається у вас — супровід не є умовою працездатності системи.

Кейс: підготовка претензій і позовів у виробничій компанії

Виробнича компанія з юридичним департаментом із трьох осіб: претензійна робота з дебіторкою, позовні заяви щодо порушень поставок і підрядних зобов'язань, до 400 документів на рік.

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

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

Претензійний порядок і строки позовної давності відстежували вручну — пропущена дата коштувала процесуальної переваги.

Що змінили

Зібрали реєстр договорів і зобов'язань як єдине джерело даних. Документ формується з шаблону, а змінні — реквізити, суми, дати, номери пунктів — підставляються з реєстру, а не набираються руками.

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

Метрики до і після

• Збирання претензії: 6–8 годин ручної роботи → 40–50 хвилин до готової чернетки на перевірку.
• Частка документів, що пішли на повторну правку: 6 із 10 → 1–2 із 10.
• Клас помилок із розбіжністю реквізитів, сум і номерів пунктів знято: за два квартали жодного повернення з цієї причини.
• Контроль строків: дати з реєстру потрапляють у календар юриста, пропусків немає.
• Потік зрослих претензійних справ департамент закриває тим самим складом.

Що робити, якщо юристи вже використовують генеративні помічники

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

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

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

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

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

Далі на цій базі налаштовуються перевірки обов'язкових застережень, підстановка реквізитів і журнал операцій.

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

Питання щодо даних, доступів і перевірки результату

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

Кожне звернення до картки документа потрапляє в журнал, тому на питання «хто відкривав цей договір і коли» є фактична відповідь.

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

Що робити зі сканами поганої якості?

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

Хто відповідає за фінальну редакцію?

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

Як перевіряються посилання на норми?

Кожне посилання звіряється з актуальною редакцією через КонсультантПлюс і отримує статус: діє, змінено, втратило чинність. Зміни та строки за ними фіксуються окремим списком у проєкті.

Що надіслати, щоб повернутися з оцінкою та планом робіт

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

• Приклади документів. 5–10 реальних файлів за кожним типом — договори, претензії, позови, — у знеособленому вигляді, разом із додатками й видимими правками, які юристи вносили руками. За ними видно структуру, обов'язкові реквізити й типові відхилення від шаблону.
• Обсяг потоку документів. Скільки одиниць на місяць, розподіл за типами, пікові періоди й частка нетипових випадків. Це визначає архітектуру: суцільна автоперевірка чи вибіркова з ручним розбором.
• Вимоги до контуру розміщення. Усередині вашого периметра чи в зовнішній хмарі, які правила зберігання текстів і хто отримує до них доступ. Якщо документи містять персональні дані, це змінює схему розгортання.
• Джерела опори. Шаблони, внутрішні регламенти, довідники, вивантаження судової практики — усе, на що система може посилатися під час підготовки чернетки.
• Порядок погодження. Хто редагує, хто погоджує, на якому кроці документ іде контрагенту або до суду, де саме потрібна зупинка на підтвердження юристом.
• Ролі та доступи. Скільки юристів працює із системою, чи потрібна ізоляція за відділами або проєктами, який журнал дій потрібен для внутрішнього контролю.
• Еталон якості. 10–20 документів, які ви вважаєте зразковими, і кілька невдалих. За цією парою ми налаштовуємо перевірки й розуміємо, що вважати помилкою.
• Обмеження. Чинні інтеграції, вимоги служби безпеки, строки першого робочого запуску й формат, у якому документ має виходити назовні.

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