ШІ для аналізу документів: контракти, звіти, due diligence

Канцелярія отримує замовлення на перегляд пакету договорів у межах угоди M&A. П'ять осіб протягом трьох днів переглядають 400 документів. Шукають положення про заборону конкуренції, терміни розірвання, положення про change-of-control та індемніфікацію. Більшість часу витрачається не на мислення, а на читання та пошук.

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

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

Шар 1: інгест та OCR. Документи надходять у форматах PDF, DOCX, XLSX, скани, а іноді як фото з телефону. OCR перетворює скани та фото на текст. Для цифрових документів (PDF з текстом) цей крок тривіальний. Для сканів низької якості це один з основних ризиків: неправильно прочитана цифра в пункті про штрафні санкції має наслідки.

Шар 2: чанкінг та індексація. Текст ділиться на фрагменти (чанки) та перетворюється на ембедінги моделлю, такою як BGE-M3. Фрагменти потрапляють до векторної бази даних. Ключове рішення: якого розміру мають бути чанки та чи зберігають вони контекст абзацу, розділу та документа. Замалі чанки втрачають контекст; завеликі знижують точність пошуку.

Шар 3: пошук та реранкінг. Запит користувача (наприклад, «знайти всі положення про зміну контролю») перетворюється на ембедінг та порівнюється з фрагментами в базі. Hybrid search поєднує векторний пошук із повнотекстовим, що забезпечує вищий recall для точних юридичних термінів. Reranking сортує результати за релевантністю перед передачею їх моделі.

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

Шар 5: structured output. Для екстракції даних (таблиці з договорів, KPI зі звітів) модель повертає structured output у форматі JSON, готовому до імпорту. Валідація схеми відбувається перед передачею даних далі.

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

Що ШІ виявляє ефективно:

• Положення з конкретним змістом: заборона конкуренції, штрафні санкції, терміни розірвання, умови гарантії, положення про конфіденційність. Семантичний пошук знаходить положення навіть якщо вони використовують інші формулювання, ніж запит.
• Невідповідності між документами: одна й та сама сторона договору має різні контактні дані в двох місцях, термін оплати в преамбулі не збігається з текстом пункту. ШІ порівнює фрагменти з різних місць документа або з набору документів.
• Відсутні елементи: шаблон повного договору певного типу містить 12 обов'язкових розділів. Система позначає документи, яким бракує одного чи кількох.
• Стандартні vs. нестандартні положення: якщо у вас є база власних шаблонів договорів, система порівнює положення з документа з шаблоном і повідомляє про відхилення та його масштаб.

Чого ШІ не замінює:

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

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

Фінансові звіти — другий основний випадок використання. Аналітик переглядає квартальні звіти 15 портфельних компаній. З кожного витягує ті самі 20 показників: доходи, EBITDA, чистий борг, капітальні витрати, кількість працівників. Вручну це займає кілька годин при кожному циклі звітності.

ШІ скорочує цей процес до валідації замість екстракції:

1. Система зчитує документ (PDF звіту, XLSX, CSV).
2. Ідентифікує таблиці та наративні розділи, що містять показники.
3. Відображає показники на стандартизовану схему та повертає JSON з значеннями, одиницями виміру та номером сторінки.
4. Аналітик перевіряє позиції, які система позначила низькою впевненістю або де значення відхиляється від попереднього періоду більше ніж на визначений поріг.

Ключові проблеми при екстракції звітів:

• Різні формати між емітентами. EBITDA в одному звіті — це рядок у таблиці, в іншому — лише в наративному розділі. Система має підтримувати обидва шаблони.
• Облікові перетворення. Звіт подає EBITDA adjusted. Щоб обчислити EBITDA з сирих даних, потрібно виконати кілька кроків. Це вимагає або заздалегідь визначених правил екстракції, або моделі з верифікованим ланцюжком міркувань.
• Валюти та одиниці виміру. Один звіт подає суми в тисячах PLN, інший — у мільйонах EUR. Нормалізація має бути прозорою та аудитованою.

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

Due diligence юридично-фінансова — це аналіз часто кількох сотень документів у стислі терміни. Класична проблема: багато матеріалу для читання, мало часу, висока ціна помилки.

ШІ не проводить due diligence замість юриста чи консультанта. Він служить як перший фільтр, який:

• Класифікує документи за категоріями (договори, ліцензії, адміністративні рішення, корпоративні документи) та призначає їх відповідним фахівцям.
• Позначає положення високого ризику в категоріях: зміна контролю, штрафні санкції вище порогу, неринкові положення, позабалансові зобов'язання.
• Генерує список питань до продавця на основі відсутніх документів або виявлених невідповідностей.
• Створює тематичні підсумки з цитуваннями: «Договори з положенням change-of-control: 14 документів, список нижче з номерами сторінок».

Різниця між ШІ як фільтром та ШІ як аналізом: фільтр — це організація та вказівка на те, що потребує уваги. Аналіз — це оцінка значення та рекомендація. Перше ШІ робить добре. Друге вимагає людини.

На практиці пілот due diligence зазвичай починається з однієї категорії документів (наприклад, лише договори з основними постачальниками) та одного типу запитання (наприклад, положення про розірвання). Обсяг розширюється після перевірки якості результатів на цьому вузькому випадку.

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

Self-hosting моделі виправданий, коли документи підпадають під дію NDA, професійної таємниці або містять персональні дані сторін угоди. Дані PII мають бути замасковані перед відправкою до будь-якого зовнішнього API, навіть якщо постачальник декларує нульове зберігання. Детальніше про цей шаблон йдеться в статті анонімізація PII перед ШІ.

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

Дві технічні вимоги, які мають бути виконані перед запуском конвеєра:

PII masking перед індексацією. Персональні дані ідентифікуються та маскуються або токенізуються на етапі інгесту, перш ніж фрагменти потрапляють до векторної бази. Модель бачить «СТОРОНА_A» замість конкретного імені та прізвища. Відображення токенів на реальні дані зберігається окремо, поза індексом.

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

Для процесів due diligence з підвищеним ризиком (поглинання в регульованих секторах, конфіденційні дані) потрібна DPIA перед впровадженням. Систематичний аналіз документів за допомогою ШІ може кваліфікуватися як «обробка у великих масштабах» згідно з RODO. Детальний огляд регуляторних обов'язків містить стаття AI Act та RODO 2026.

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

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

• Recall критичних положень: який відсоток положень з попередньо позначеного тестового набору система правильно ідентифікувала. Мета: понад 95% для критичних положень (штрафи, терміни, зміна контролю). Recall нижче 90% означає проблему з чанкінгом або занадто вузький семантичний пошук.
• Точність цитування: який відсоток процитованих фрагментів дійсно походить з вказаної сторінки та абзацу. Помилкове цитування (модель вказує номер сторінки, але фрагмент походить з іншого місця) — це сигнал опосередкованої галюцинації. Мета: 100%.
• Показник ескалації: який відсоток запитів система передає на перевірку людині замість самостійної відповіді. Занадто низький показник (система відповідає на все) означає відсутність guardrails. Занадто високий (система ескалує все) означає, що система не надає цінності.

Моніторинг якості агента детальніше розглядає методологію вимірювання, оповіщень та дрейфу якості для систем ШІ, що працюють у промисловому режимі.

Опишіть тип документів, які аналізуєте, та що хочете з них витягувати, а модель вкаже, які архітектурні шари мають сенс для вашого випадку (playground: PII маскуються, нульове зберігання):

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

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

Безпека залежить від архітектури, а не від факту використання ШІ. Документи під дією NDA та професійної таємниці мають оброблятися локально (self-hosted модель) або з маскуванням PII перед відправкою до зовнішніх API. Кожен проект повинен мати ізольований індекс у векторній базі, щоб запити з однієї справи не мали доступу до документів іншої. Лог кожної операції (що система прочитала, що запропонувала, хто затвердив) має бути можливим для відтворення. Деталі технічних вимог розглядає стаття безпека агентів ШІ.

Пілот на одній категорії документів та одному типі запиту зазвичай триває 3-6 тижнів: тиждень на інгест та індексацію тестового набору, тиждень на конфігурацію та калібрування guardrails, 2-4 тижні на перевірку якості з реальними користувачами. Повне впровадження, що включає кілька категорій документів, інтеграцію з ERP або DMS та складні конвеєри екстракції, залежно від обсягу займає 2-4 місяці. Калькулятор ROI дозволяє оцінити термін окупності на основі реального обсягу документів та погодинної ставки фахівців.

Так, це один з найкорисніших шаблонів у due diligence. Агент з tool-use може виконувати багато запитів до векторної бази послідовно та порівнювати результати: «договір A містить положення X, договори B і C його не мають». Складні порівняння між великими наборами документів вимагають ретельного проектування конвеєра та чітких guardrails, що блокують відповіді, згенеровані без підстав у тексті. Агент ШІ vs чатбот розглядає різницю між простим асистентом та агентом, здатним до багатоетапного міркування над документами.