Вилучення даних з договорів: де ламається ручна перевірка
Пакет із трьохсот договорів від контрагента виглядає як завдання на вечір. Насправді ручний розбір договорів — це читання кожного документа повністю: потрібні умови розкидані по тексту та додатках, а частина змінюється від редакції до редакції. Увага закінчується раніше, ніж папка.
Звідси типові помилки в реквізитах договору: переплутаний номер, дата у форматі контрагента, ІНН або банківські реквізити з попередньої версії.
Нестандартні умови — штраф за прострочення повідомлення, автопролонгація, право на односторонню відмову — не потрапляють до зведення, бо виглядають як звичайний абзац.
Ціна — не лише термін перевірки пакета договорів, розтягнутий на тижні. Зведення по масиву зібрати нічим: дані лежать у тексті, а не в таблиці, і кожне уточнення до договору вимагає повторного читання.
Гірше, що перевірка не відтворюється — наступний юрист пройде той самий шлях заново й отримає іншу вибірку. Підсумок — пропущений платіж або згасле вікно на заперечення.
Вилучення даних з договорів закриває саме цю точку. Поля видобуваються з документа за фіксованою схемою, значення звіряються між розділами, а результат лягає в таблицю, за якою видно весь масив. Що бере на себе система, а що залишається за юристом, — розбираємо нижче.
Що дає система: терміни, повнота, усунені помилки
Ефект автоматизації розбору видно не на презентації, а в потоці: поки договори розбирають вручну, погодження стоїть на юристах, а не на контрагенті. Нижче — за якими величинами ми вимірюємо результат і що перевіряємо на прийманні.
- Термін перевірки договору. Один документ — хвилини замість десятків хвилин ручного перенесення реквізитів; пакет із кількох десятків договорів проходить за зміну, а не за тиждень.
- Повнота вилучених реквізитів. Сторони, предмет, суми, терміни, порядок оплати та склад додатків заповнюються автоматично більш ніж у дев'яти випадках із десяти; залишок іде в чергу на уточнення, а не губиться.
- Усунені класи помилок. Пропущені додаткові угоди та додатки, переплутані дати набрання чинності, посилання на застарілу редакцію, нечитабельні скани — кожен клас закривається окремим правилом і перевіркою.
- Вартість простою юридичного відділу. Простій вимірюється не годинами юриста, а зупиненими погодженнями та оплатами, які чекають на розбір; коли розбір перестає бути вузьким місцем, це очікування йде з критичного шляху.
- Перевірюваність. Кожне значення приходить із посиланням на сторінку та фрагмент вихідного файлу — юрист підтверджує або відхиляє за секунди, а при низькій впевненості поле позначається на ручну перевірку.
Підсумок: потік договорів розбирається за зміну, повнота підтверджується вибіркою, спірне бачить людина. Скани та нестандартні редакції обробляємо на вході, персональні дані в договорах — у рамках 152-ФЗ.
Варіанти побудови: хмарний сервіс, закритий контур, гібрид
Для юридичного департаменту питання «де зберігаються документи» вирішується раніше, ніж вибір моделі вилучення.
Від відповіді залежить, чи залишають тексти договорів периметр замовника, хто відповідає за збереження і як швидко схему можна змінити при посиленні вимог служби безпеки.
На практиці працюють три схеми: хмарний сервіс розбору договорів на наших ресурсах, закритий контур обробки даних на інфраструктурі замовника і гібридна схема інтеграції з вибірковою передачею.
Точність вилучення в них однакова — правила розбору та довідники типових умов одні й ті самі. Відрізняються місце обробки, маршрут документа, зона відповідальності за доступи та термін запуску.
| Схема | Коли підходить | Обмеження |
|---|---|---|
| Хмарний сервіс на наших ресурсах | Пілот, невеликий потік, немає заборони на зовнішню обробку | Текст договору йде за периметр; потрібен регламент обезособлення |
| Закритий контур у замовника | Чутливий корпус, вимога зберігати все всередині | Потрібні ресурси під розгортання та оновлення на вашому боці |
| Гібрид із вибірковою передачею | Основний корпус всередині, частина типових задач — назовні | Складніша маршрутизація та контроль: потрібне правило, що куди йде |
Як схема змінюється з часом
Починати майже завжди розумно з хмарного контуру на обмеженому корпусі: він перевіряє якість розбору на реальних договорах без вкладень в інфраструктуру.
Потім схему переносять — правила вилучення та довідники умов переїжджають у закритий контур без перенавчання, бо логіка розбору від місця не залежить. Гібрид беруть, коли типові поставки з публічними умовами та конфіденційні угоди не можна тримати в одному сховищі.
Як проходить впровадження: від аудиту масиву до передачі
Впровадження йде ітераціями, а не одним розбором: спочатку дивимося, що реально лежить у договірному масиві, потім описуємо сутності і тільки потім налаштовуємо правила.
Зворотний порядок дає правила під зручні приклади — система спотикається на першому ж нетиповому додатку або додатковій угоді.
- Аудит договірного масиву. Вивантажуємо представницьку вибірку та класифікуємо за видами: поставка, підряд, послуги, ліцензія, оренда. Фіксуємо, які поля потрібні юристам у роботі. На виході — карта типів і частот, вона задає пріоритети.
- Схема сутностей. Описуємо поля, типи, обов'язковість, зв'язки між договором і додатками. Заводимо довідники контрагентів і видів договорів, щоб значення не розповзалися дублями.
- Налаштування правил розбору. Шаблонні блоки закриваємо правилами, нестандартні формулювання — моделлю. Кожне значення отримує посилання на фрагмент тексту: юрист бачить підставу, а не готову відповідь.
- Перевірка на контрольній вибірці договорів. Проганяємо документи, яких не було в налаштуванні, і рахуємо точність окремо за кожним полем. Поля нижче узгодженого порогу повертаються на доопрацювання, а не розчиняються в загальній метриці.
- Донавчання моделі на правках. Правки юристів стають розміткою: спірні формулювання замовника потрапляють у навчання, і точність зростає на його шаблонах, а не на абстрактному наборі.
- Передача регламентів. Віддаємо інструкції для юристів, опис полів і порогів, порядок оновлення правил і розбору помилок. Супроводжуємо перші прогони на живому потоці.
Далі цикл повторюється тільки на нових типах договорів — звичні йдуть без ручної правки.
Що юрист отримує на руки: реєстр договорів і правила розбору
Після впровадження ви отримуєте не «працюючий сервіс», а комплект, за яким команда юристів та ІТ живе далі без нас. Кожен артефакт прив'язаний до процесу: що робити щоденно, що змінювати при правках шаблонів, кого кликати на спірному полі.
- Реєстр договорів — таблиця або база з пов'язаними сутностями: контрагент, предмет, термін, порядок оплати, пролонгація, відповідальний юрист. У кожного значення посилання на вихідний файл і сторінку.
- Набір правил розбору — які типи документів і поля обробляються автоматично, де правило спирається на формулювання, де на структуру розділу, що робити при зміні шаблону контрагента.
- Схема інтеграції з обліковою системою — куди йдуть погоджені дані, при якій події, що відбувається при розбіжності з уже наявною карткою.
- Інструкція для юристів — на 2-3 сторінки: як внести договір, як подивитися джерело значення, як позначити помилку і куди вона йде далі.
- Порядок ручної перевірки — при якій впевненості моделі поле йде людині, хто розбирає спірний випадок, як фіксується рішення і чи потрапляє воно в правила.
- Документація з розбору — типові помилки та як їх зняти правкою правил, а не перенавчанням моделі.
- Тестовий набір — обезособлені договори з еталонною розміткою, щоб після правки правил прогнати регрес і побачити, що старе не зламалося.
Кейс: як скоротили ручний розбір масиву угод
Як було
Юридичний відділ виробничої компанії накопичив близько 4 000 угод: основні договори, додаткові угоди та додатки, частина — скани різної якості.
Юристи відкривали кожен документ і переносили в таблицю сторони, терміни, порядок оплати, штрафні застереження та умови розірвання — 20–40 хвилин на документ, з паузами на поточні завдання.
Умова в додатку нерідко змінювала пункт основного тексту, і в таблицю потрапляв варіант, якого в договорі немає.
Що змінили і що стало
Зібрали конвеєр: розпізнавання сканів (складні — через ABBYY з окремою перевіркою), розмітка за типами документів, вилучення полів за узгодженою схемою.
Для кожного значення зберігається посилання на фрагмент-джерело — юрист відкриває сторінку і бачить, звідки взято поле, замість того щоб вірити таблиці на слово.
Якщо впевненість нижче порогу, поле йде в ручне звіряння, а не «додумується»; реквізити сторін додатково звіряються з довідником, тому розбіжності в написанні назв випливають одразу.
Перевірка документа скоротилася до 2–3 хвилин: юрист підтверджує вилучене, а не шукає його. Частка полів, прийнятих без правок, — 92%, пропущених пов'язаних застережень — менше 1% проти 6–8% при ручному розборі.
Масив розібрали за три тижні замість чотирьох місяців, а вибірка за умовами розірвання будується за хвилини замість дня.
Звільнений час пішов на спірні договори та претензійну роботу — це і є зниження ручної роботи, при якому люди займаються сенсом, а не перенесенням однакових полів.
Що робити, якщо договори вже розкладені по різних системах?
Розкладені по різних системах договори — не виняток, а штатний випадок: частина лежить у мережевих папках за роками та контрагентами, частина приходить вкладенням на поштову скриньку відділу закупівель, частина прикріплена до угоди в обліковій системі.
Зводити все в одне сховище заздалегідь не потрібно: переїзд рве посилання всередині облікової системи і втрачає історію версій.
Ми підключаємося до кожного джерела окремим підключенням і зводимо їх в єдиний потік обробки.
Файлове сховище обходимо інкрементально за міткою зміни, поштову скриньку опитуємо за правилом фільтрації вкладень, облікову систему читаємо через її програмний інтерфейс і повідомлення про зміни. Далі документ стає в загальну чергу незалежно від джерела.
Повторний обхід не плодить дублів: документ розпізнається за вмістом та ідентифікатором джерела, а нова версія файлу приходить як правка вже відомого договору. Пересканування папки або повторна синхронізація не перетворюються в потік копій з різними датами.
Зв'язок з джерелом зберігається: у кожного вилученого поля залишається посилання на вихідний файл та його розташування, права успадковуються з тієї системи, звідки документ прийшов, — юрист бачить рівно те, що йому й так відкрито.
Якщо сховище недоступне, завдання чекає в черзі і повторюється, а обробка продовжується з того самого місця.
Підсумок: єдиний потік збирається поверх існуючих місць зберігання, без міграції даних і втрати історії. Підключення нового сховища — це ще одне підключення до джерела, а не перезбирання схеми. Перед стартом фіксуємо перелік джерел, правила доступу та порядок оновлення.
Часті технічні сумніви перед стартом
Більшість питань перед стартом — інженерні, а не юридичні.
Нижче — ті, що найчастіше випливають на технічних зустрічах: як система поводиться на поганих сканах, що робить з нестандартними додатками, чи враховує правки юристів, як перевіряється якість до запуску і хто має доступ до документів.
Договори приходять сканами поганої якості — що з ними буде?
Спочатку йде попередня обробка сторінки: вирівнювання кутів, придушення шуму, підвищення контрасту, при перекосі — повторне розпізнавання з поворотом.
Для кожного файлу рахується оцінка якості розпізнавання, і документ нижче порогу не йде в автоматичний розбір, а потрапляє в чергу на ручну перевірку. Так помилка розпізнавання не перетворюється в помилку вилучення реквізитів.
А нестандартні додатки, таблиці, додаткові угоди?
Тіло договору та додатки обробляються окремими проходами, щоб структура одного не ламала розбір іншого. Схема полів описується декларативно: нове поле або новий тип додатка додається налаштуванням, без переписування логіки розбору.
Розділи, які не вдалося розібрати впевнено, позначаються як непокриті — юрист бачить, що залишилося поза автоматизацією.
Система враховує правки юристів в інтерфейсі?
Так, кожна правка — це розмічений приклад. Вони накопичуються і періодично йдуть у донавчання, пріоритет отримують поля з найбільшою часткою розбіжностей між версією моделі та рішенням юриста.
Перед випуском нової версії проганяється той самий контрольний набір перевірок, що й для початкової.
Як перевіряється якість до запуску і хто бачить документи?
До запуску система проходить контрольний набір розмічених договорів: точність і повнота рахуються за кожним полем окремо, а не «середнім по системі», помилки розбираються за типами — де плутаються схожі формулювання, де губиться структура.
Доступ обмежується ролями на рівні типів документів і полів, звернення до кожного файлу фіксуються в журналі. Розгортання можливе у вашому контурі — документи не виходять за периметр.
Обговоримо задачу і повернемося з оцінкою та планом
Розкажіть, які договори і в якому обсязі доведеться розбирати, — від цього залежать і схема вилучення, і порядок робіт. На дзвінку розберемо задачу, а назад повернемося з оцінкою обсягу робіт і планом етапів впровадження.
Що корисно надіслати на старті й уточнити разом:
- 2-3 обезособлені договори різних типів — за ними видно структуру, розкид формулювань і те, які поля реально потрібно видобувати;
- перелік полів: сторони, терміни, предмет, суми, умови розірвання, штрафи — з позначкою, де припустиме ручне підтвердження;
- приблизний обсяг корпусу та частоту надходження нових файлів;
- джерела: пошта, мережева папка, скани, файли з електронним підписом, суміжні системи;
- поточний процес перевірки і те, які помилки критичні, а які припустимі;
- вимоги до доступів, зберігання та розмежування прав співробітників.
За складом вихідних даних ми оцінюємо обсяг робіт і збираємо план етапів впровадження з орієнтирами за термінами — від першої розмітки та налаштування правил до контролю якості на потоці та передачі системи вашій команді.
Опишіть задачу розбору договорів — повернемося з оцінкою та планом: що робимо, в якому порядку і що потрібно з вашого боку.
