AI Due Diligence: де ручний розбір угод ламається
Угода зупиняється не на переговорах, а на столі з документами: статути, виписки, договори, судові рішення, звітність — сотні сторінок у сканах і таблицях без єдиної структури.
Кожен аналітик читає свій блок, і до середини пакета увага падає: юрособу з виписки вже не звіряють із підписантом у договорі.
Ручний розбір документів масштабується лише людьми. Другий юрист подвоює трудовитрати, але не скорочує вдвічі строк підготовки висновку — зростає час на зведення версій, усунення розбіжностей і узгодження висновків між учасниками.
Пропущені ризики майже ніколи не лежать в одному файлі.
Вони на стику: ланцюжок володіння, який через третю юрособу виходить на контрагента зі списку неблагонадійних; застава, що спливає в одному договорі й не згадана в іншому; арбітраж, де відповідач — не компанія, яку перевіряють, а її керівна структура. Очима такі зв’язки збирають вибірково, а отже, випадково.
AI Due Diligence закриває саме цей розрив: документи розбираються повністю, сутності та зв’язки між ними зводяться в граф, а висновок збирається з перевірюваних фактів, а не з пам’яті аналітика.
Нижче — як це влаштовано в автоматизації перевірки контрагентів і що реально змінюється в терміні угоди.
Що змінюється після впровадження автоматичного розбору
Перший ефект видно на вході: конвеєр розбору приймає весь пакет документів, а не вибірку за регламентом. Скани, таблиці й додатки до договорів ідуть у той самий потік, що й текстові файли — вилучення побудовано на Apache Tika з розпізнаванням копій без текстового шару.
Повнота покриття зростає з частини пакета до практично повної, і пропущений документ перестає бути справою везіння.
Швидкість підготовки висновку визначає не темп читання, а час на зведення даних. Поля нормалізуються в єдину схему — суми, дати, сторони, строки, умови розірвання, — і аналітик отримує чернетку з готовими таблицями замість стопки файлів.
Строк підготовки стискається з днів до годин, а кожен висновок підкріплено посиланням на сторінку та абзац першоджерела: перевіряльник дивиться точку, звідки взято значення, а не перечитує документ повністю.
Зникає й клас помилок ручного перенесення — одруки в сумах, загублені додатки, невірно зіставлені дати. Крос-перевірки в конвеєрі звіряють одне значення в договорі, додатку та виписці й позначають розбіжність до того, як вона потрапить у висновок.
Повторні проходи теж змінюють природу: розбір версіонується, і під час оновлення пакета заново обробляються лише змінені документи — команда закриває дельту замість звірки з нуля.
Якість даних стає вимірюваною: частка полів, вилучених і звірених без ручної правки, показує, де ще потрібне налаштування.
Сценарії розбору: суцільний, вибірковий і гібридний
Під час перевірки перед угодою режим вибирають не за розміром угоди, а за обсягом корпусу документів і ціною пропущеного пункту.
Те саме вилучення сутностей і посилань працює в трьох режимах — різниця в тому, скільки документів проходить повний розбір і на якому етапі до роботи долучається людина.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Суцільна перевірка | Корпус уміщується у вікно угоди або пропуск одного пункту неприпустимий: запевнення, умови зміни контролю, відступні | Час зростає лінійно з обсягом, а в масиві з’являється частка однотипних документів, де розбирати нічого |
| Вибіркова перевірка | Потрібна карта ризиків за масивом із сотень договорів: важлива щільність відхилень, а не кожен аркуш | Нетиповий пункт у невибраному документі залишається поза звітом; вибірка потребує обґрунтування — стратифікація за типом, датою, контрагентом |
| Гібридний режим | Корпус змішаний: основний том, додатки, листування, скани | Потребує калібрування порогу впевненості та правил маршрутизації, інакше експерт або тоне в потоці, або бачить лише очевидне |
Роль експерта та перемикання режимів
Модель розмічає та вилучає, але значущість пункту затверджує юрист або аналітик — на цьому й будується гібридний режим.
Перший прохід іде по всьому корпусу без винятків, другий — лише по документах, де спрацював тригер або впевненість нижча за поріг, і кожне відхилення приходить із посиланням на сторінку та пункт.
Режими сумісні між собою: розмітка, посилання та історія правок спільні, змінюється лише глибина проходу. Тому корпус можна почати вибірково, а в міру наближення до закриття угоди розширити до суцільного розбору, не перезбираючи результат з нуля.
Як відбувається впровадження: від аудиту даних до передачі
Впровадження йде короткими циклами: на кожному кроці з’являється артефакт, який можна перевірити, — карта корпусу, схема вилучення, звіт про якість. Прогрес видно не за презентаціями, а за тим, яку частку пунктів система закриває сама, без ручної правки.
- Аудит корпусу документів. Розбираємо, що реально прийде на вхід: формати, скани без текстового шару, дублікати, мови, типові шаблони. На виході — карта корпусу та оцінка частки документів, придатних до автоматичного розбору.
- Схема вилучення сутностей. Узгоджуємо перелік сутностей і зв’язків, потрібних для висновків: сторони, частки, дати, зобов’язання, умови розірвання. Схема фіксується до налаштування — переробка на пізніших кроках дорожча.
- Розмітка еталона. На контрольній вибірці документів вручну розмічаємо правильні відповіді — це еталон для вимірювань. Поверх налаштовуємо правила звірки та пороги, за яких система зобов’язана передати пункт юристу.
- Приймання на контрольній вибірці. Рахуємо повноту й точність вилучення та частку пунктів, закритих без ручної правки. Приймання йде за заздалегідь узгодженим набором документів, а не за показовою демонстрацією.
- Пілот на реальному потоці. Запускаємо на потоці угод із паралельною ручною перевіркою: розбіжності розбираємо, правила уточнюємо. Мета — стабільні метрики на документах, яких система раніше не бачила.
- Передача рішення та навчання команди. Віддаємо документацію, регламенти, доступи та інструкції з оновлення правил, навчаємо аналітиків і юристів. Після передачі команда змінює пороги та додає сутності самостійно.
Моделі, правила вилучення та шаблони звітів Due Diligence
Проєкт з автоматизації Due Diligence має сенс, якщо після здачі контур залишається керованим без нас. Тому моделі, правила й шаблони живуть не в коді, а в конфігурації та окремих файлах: аналітик або юрист править формулювання сам, без перезбирання рішення.
Кожен артефакт версіонується — при спірному висновку видно, яке правило спрацювало і на якому документі.
Що саме залишається в замовника:
- Правила вилучення — набір правил і підказок за кожним полем: що вважати датою реєстрації, як розбирати адресу, які формулювання вважати ознакою пов’язаності. Змінюються в конфігурації, застосовуються без участі розробника.
- Довідник контрагентів — нормалізований реєстр з ідентифікаторами, попередніми найменуваннями та зв’язками між компаніями й особами. Основа для зіставлення сутностей із різних джерел.
- Шаблон висновку — редагований шаблон звіту: розділи, порядок висновків, обов’язкове посилання на джерело під кожним твердженням, поле для ручного коментаря.
- Моделі та пороги впевненості — налаштовані моделі вилучення й перевірки з порогами, за яких висновок іде на ручну валідацію, а не потрапляє у звіт.
- Документація рішення — схема обробки від завантаження пакета документів до готового висновку, словник полів, перелік джерел і правила їх пріоритету.
- Регламент супроводу — інструкція з розбору відмов: що робити при низькій впевненості, як додати поле, як коректно відкотити зміну правил.
Окремо фіксуємо передачу артефактів: репозиторій з історією змін, доступи й ролі, сесія з командою замовника щодо правки правил і шаблонів.
Кейс: автоматичний розбір портфеля з 300+ компаній
До: вибіркова перевірка замість суцільної
Портфель — 300+ компаній, від 30 до 200 документів на кожну: установчі, виписки, договори, протоколи зборів. Ручний розбір займав близько п’яти тижнів і тримався на вибірці: аналітики встигали відкрити приблизно 2% файлів, решту закривалося зі слів контрагента.
Зв’язки між компаніями — спільні адреси, директори, частки участі — спливали вже після закриття угоди, коли перебудовувати структуру пізно.
Після: суцільний розбір і граф зв’язків
Ми зібрали конвеєр: вилучення реквізитів і сутностей зі сканів і таблиць, нормалізація назв і адрес, звірка із зовнішніми реєстрами та базами Dow Jones Risk & Compliance.
Поверх — граф, де ребро означає підтверджений збіг реквізиту, а не схожість рядка, тому перевірка афілійованості йде за формальною ознакою. Кожен висновок приходить із посиланням на сторінку та фрагмент вихідного документа.
Метрики після запуску: підготовка вижимки по всьому портфелю — два дні замість п’яти тижнів, суцільна перевірка — 100% файлів замість 2%, частка виявлених зв’язків між контрагентами зросла втричі.
Хибні спрацювання на схожих назвах знизилися завдяки нормалізації — спірні випадки йдуть у чергу ручної перевірки з пріоритетом за ризиком, а повторний прогін після оновлення реєстрів дає зіставний результат.
Чим відрізняється автоматичний розбір від ручної вибірки?
Ручна вибірка спирається на те, що експерт встиг відкрити. Він читає документи, поки не вичерпано бюджет часу, і зупиняється на досягнутій картині. Покриття корпусу при цьому рідко сягає десятої частини, а склад вибірки задають первинні гіпотези, а не структура даних.
Пропуск не видно: непрочитаний договір з умовою про зміну контролю не залишає у звіті жодного сліду.
Автоматичний розбір проходить корпус повністю — з вкладеннями, сканами та листуванням. Система вилучає сутності, зв’язки, дати, умови розірвання й обтяження, по кожному факту зберігаючи посилання на джерело.
Покриття корпусу стає вимірюваним: частка оброблених документів і частка полів, де знайшлося підтвердження, видні у звіті, а не оцінюються на око.
Відтворюваність результату — друга відмінність. Повторний прогін на тому самому наборі документів дає той самий висновок: версія моделі та правила розбору зафіксовані, проміжні рішення записані в журнал.
Ручна вибірка такої властивості не має — при зміні виконавця змінюються вибірка, трактування й підсумок, а пояснити розбіжність заднім числом майже неможливо.
Автоматичний розбір при цьому не скасовує участі експерта. Людина залишається в контурі в трьох точках: задати критерії суттєвості під конкретну угоду, розібрати суперечності між джерелами та винести судження щодо висновків, позначених як неоднозначні. Система знімає рутину й робить пропуски видимими — трактування, як і раніше, тримає експерт.
Обмеження автоматизації та типові помилки впровадження
Доцільніше одразу назвати межі: автоматизація впевнено закриває типовий потік — договори, виписки, установчі документи, звітність стандартних форматів.
Ламається вона на копіях третього-четвертого покоління, де текст «пливе», на рукописних додатках, на саморобних таблицях і на документах рідкісних мов, де мало навчальних даних. Помилка тут дорожча за ручну перевірку: хибне вилучення йде у звіт і змінює висновок.
Ми не видаємо невизначеність за результат. У кожного поля є поріг впевненості; якщо його не пройдено, значення не підставляється, а документ позначається як такий, що потребує перевірки — експерт отримує сторінку та фрагмент, який система не розібрала. Обмеження автоматизації залишаються видимими, а не розчиняються в середній точності.
Як ви працюєте з поганою якістю сканів?
Перед розпізнаванням іде підготовка: вирівнювання, придушення шуму, корекція контрасту, розбиття розворотів. Далі — перевірка за контрольними полями: якщо ключові реквізити не читаються, документ іде на ручну верифікацію, а не в загальний потік. Частку таких документів ми показуємо до старту, а не після.
Що відбувається з нестандартними документами та винятками в правилах?
Правило описується разом із винятками: яка умова, що робимо при відхиленні, хто підтверджує. Набір правил версіонується, до нього додано еталонний набір документів — після правки проганяємо його повністю й порівнюємо з попередньою версією. Відкат займає хвилини, а не переробку всього процесу.
Типові помилки впровадження — спроба автоматизувати весь потік у першому релізі, правила без прописаних винятків і оцінка за середньою точністю замість критичних полів. Ми починаємо з вузької ділянки, вимірюємо частку документів, закритих без людини, і лише потім розширюємо охоплення. Нижче — технічні сумніви, які найчастіше розбираємо з командами замовника.Обговоримо задачу та повернемося з оцінкою і планом
Щоб оцінка спиралася на реальний обсяг роботи, а не на усереднену вилку, починаємо з ввідних по корпусу: типи документів (скани, текстові шари, таблиці, пошта), мови, приблизний обсяг у тисячах сторінок і те, який результат вважається правильним — повне вилучення умов угоди або вибірка ризикових пунктів із зазначенням джерела. Чим точніші ввідні, тим менше припущень у плані й тим реалістичніші строки.
З вашого боку достатньо:
- 15–30 обезличених документів, включно з нетиповими й погано читаними примірниками;
- де фізично лежить корпус: файлове сховище, електронний архів, скани із зовнішніх джерел;
- приклади полів і умов, які потрібно витягувати, з парою еталонних відповідей;
- як сьогодні перевіряють результат і хто виступає приймальником;
- вимоги до контуру: внутрішній сервер, закрита хмара або гібрид;
- обмеження щодо доступів і роботи з персональними даними;
- бажаний горизонт впровадження і те, що вважаєте першою корисною ділянкою.
У відповідь надсилаємо склад робіт за етапами, схему обробки, вимоги до інфраструктури, оцінку строків і порядок приймання. Формат розмітки та метрика якості узгоджуються до старту — інакше суперечка про точність іде в нескінченність. Опишіть задачу у вільній формі: повернемося з оцінкою і планом робіт.
