тріаж NDA і автоматичне погодження

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

Grow2.ai розгортає агента на базі LLM, який читає PDF або DOCX файл NDA, витягує юридично значущі пункти і приймає одне з трьох рішень: схвалити для підпису, повернути контрагенту із запропонованими правками або ескалювати юристу.

Що агент робить

1. Витягує структуровані дані з неструктурованого тексту: строк дії NDA, визначення конфіденційної інформації, юрисдикція та застосовне право, тип угоди (односторонній або взаємний), винятки з конфіденційності, умови судової заборони, обмеження на заборону переманювання.
2. Звіряє з внутрішнім регламентом компанії — зведенням правил, які визначають прийнятні та неприйнятні положення. Регламент веде юрист і оновлює в міру появи нових кейсів.
3. Класифікує документ за трьома категоріями: зелений коридор (відповідає регламенту — авто-схвалення), жовтий коридор (незначні відхилення — пропонує правки), червоний коридор (суттєві ризики — ескалація юристу).
4. Формує зведення з підсвічуванням відхилень: що в NDA суперечить регламенту, яка редакція пропонується натомість, на що юрист має звернути увагу при фінальній перевірці.
5. Маршрутизує документ за результатом тріажу: надсилає в канал Slack для фінальної перевірки, повертає контрагенту email із запропонованими правками або поміщає в папку «готово до підпису» на Google Drive або Dropbox.

Що агент НЕ робить

Агент не підписує NDA за юриста — фінальний підпис завжди за людиною. Агент не веде переговори з контрагентом напряму — він готує лише чернетку відповіді. Агент не обробляє складні NDA з нестандартними положеннями (NDA у складі M&A-угоди, спільного підприємства, стратегічного партнерства) — такі документи автоматично ескалюються. Агент не замінює CLM-систему — він працює на етапі тріажу до потрапляння документа в контрактне управління.

Типові варіанти налаштування

Індивідуально / Бутик (1-5 осіб)

Для юридичного бутику або приватного практика з обмеженим потоком NDA. Агент працює з одним універсальним регламентом, ключові відхилення йдуть в email юристу. Інтеграція мінімальна: вхідна пошта або Google Drive як джерело, email як канал відповіді. Фінальне рішення приймає юрист — агент готує лише зведення та чернетку відповіді. Запуск за 2-3 дні, основні витрати — час юриста на складання регламенту. Підходить для консалтингових компаній, де NDA йдуть через одного партнера або невелику команду.

SMB (6-30 осіб)

Для компанії, що зростає, де різні відділи отримують різні типи NDA: продажі — з клієнтами, закупівлі — з вендорами, партнерства — з партнерами. Агент працює з 3-4 варіантами регламенту, розпізнає контекст і застосовує правильний регламент. Зелений коридор авто-схвалюється і одразу іде на підпис, жовтий коридор — у Slack-канал #legal-review, червоний коридор — персонально юристу. Інтеграції: DocuSign або Dropbox Sign, Slack, файлове сховище. Це базова конфігурація для більшості SaaS і професійних сервісних компаній.

Корпоративний сегмент (30+ осіб)

Для організації з великим обсягом NDA та виділеною юридичною командою. Агент інтегрується з наявною CLM системою (Ironclad, Icertis, LinkSquares), застосовує маршрутизацію за SLA (критичні угоди — у пріоритетну чергу), веде аналітичний дашборд: середній час тріажу, відсоток автоматично схвалених, топ порушуваних положень регламенту. Підключається журнал аудиту — всі рішення агента логуються для перевірки відповідності вимогам. Може обробляти NDA на 2-3 мовах паралельно. Потребує серйознішої конфігурації та інтеграції з внутрішніми системами — це не проект вихідного дня.

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

Крок 1: Приймання документа

Вхідний NDA потрапляє в систему одним із трьох способів: надходить на виділений поштовий псевдонім (nda@company.com), завантажується у виділену папку в Google Drive, Dropbox або SharePoint, або прикріплюється до заявки у службі підтримки. Система підтримує PDF (включно зі сканованими), DOCX, Google Docs. Файл копіюється до робочого сховища, метадані (відправник, час, розмір) логуються.

Крок 2: Витягнення тексту та структури

Для сканованих PDF запускається OCR через вбудовані засоби вертикальної SaaS-платформи. Для DOCX — парсинг структури зі збереженням таблиць, нумерації пунктів, підзаголовків. На виході — чистий текст із розміткою розділів. На цьому ж етапі агент визначає мову документа та його довжину — якщо NDA виходить за межі очікуваного (20+ сторінок замість стандартних 3-5), документ позначається як нестандартний і іде в червоний коридор.

Крок 3: Витягнення юридично значущих полів

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

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

Крок 4: Порівняння з регламентом

Регламент — це структурований документ (YAML або JSON-подібний формат), де для кожного поля задано: прийнятні значення (автоматично OK), граничні випадки (вимагає уваги), червоні прапорці (автоматично ескалювати). Наприклад: прийнятний строк дії — до 5 років, граничний — 5-7 років, червоний — 7+ років або безстроковий.

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

Крок 5: Маршрутизація та відповідь

За підсумковою класифікацією документ іде по одному з трьох маршрутів:

1. Зелений коридор (авто-схвалення). Документ переміщується до папки «Ready to sign», сповіщення відправляється ініціатору угоди (продажі, партнерства) із зведенням з 3-5 пунктів.
2. Жовтий коридор (зустрічна пропозиція). Формується чернетка email для контрагента із запропонованими правками. Чернетка відправляється юристу на перевірку у Slack — схвалення одним кліком, і email іде.
3. Червоний коридор (ескалація). Юрист отримує персональне сповіщення з повним зведенням, списком відхилень і посиланням на документ. Агент не пропонує правок — ситуація вимагає юридичного аналізу.

Альтернативні підходи

Порівняємо три способи вирішення задачі тріажу NDA у SMB:

Ручна перевірка залишається необхідною для нестандартних документів — агент не замінює юриста, а знімає рутинний первинний тріаж. No-code-робочий процес через Zapier або low-code платформу можна зібрати за день, але такі рішення не витягують сенс із тексту — вони лише маршрутизують файли за метаданими. AI-агент дорожчий на старті (потрібен регламент, тести на реальних NDA, налаштування інтеграцій), але на довгій дистанції окупається: навантаження з NDA знижується на 50%, як показав кейс Safehold.

Безпека та відповідність вимогам

NDA містять чутливі комерційні дані. Базове налаштування включає: обробку документів у ізольованому середовищі без збереження контенту поза журналом аудиту, шифрування у стані спокою у файловому сховищі, контроль доступу на рівні регламенту (хто може змінювати правила). Для компаній під GDPR або SOC 2 додається: резидентність даних в EU або US регіоні, логування всіх операцій агента з міткою часу, політика зберігання вихідних документів та проміжних представлень. Якщо контрагент — державна структура або регульована галузь (фінанси, охорона здоров'я), red lane включає обов'язкову ескалацію незалежно від змісту. Вміст NDA не використовується для навчання моделей.

Для запуску тріажу NDA достатньо вихідних роботи, якщо дотримані чотири умови.

1. NDA-регламент існує у вигляді документа. Регламент — це звід правил, які компанія застосовує при перевірці NDA: прийнятні строки, бажані формулювання обсягу конфіденційності, застереження про юрисдикцію, які ви підписуєте і які ні. Якщо регламент не формалізований, агенту нема чому слідувати. Мінімальний регламент — 1-2 сторінки на типовий NDA.
2. Історичний набір NDA — мінімум 20-30 документів з реальних угод. Потрібен для тестування агента: проганяється через систему, порівнюється рішення агента з рішенням юриста, знаходяться розбіжності, правиться регламент. Синтетичних шаблонів недостатньо — лише реальні документи від контрагентів дають адекватну вибірку.
3. Файлове сховище з доступом через API: Google Drive, Dropbox, OneDrive або SharePoint. Агент читає вхідні файли та зберігає проміжні результати в окрему папку з контрольованим доступом.
4. Канал для комунікації з юристом: Slack workspace або Microsoft Teams. Використовується для жовтого коридору (запити на перевірку) та червоного коридору (ескалації).

Опціональні інтеграції: DocuSign або Dropbox Sign для зеленого коридору (авто-відправка на підпис), CLM-платформа (Ironclad, LinkSquares) для корпоративного варіанту, поштовий шлюз для автоматичної відповіді контрагенту.

Можливі підводні камені

• Регламент у голові юриста, а не в документі. Найчастіша помилка — спроба запустити агента без формалізованого регламенту. Без явних правил агент генерує правдоподібні рішення, які розходяться з реальною практикою компанії. Перед впровадженням закладайте 2-3 дні на виписування правил у структурований формат.
• Тестування лише на синтетичних NDA. Реальні NDA від контрагентів містять нестандартні формулювання, друкарські помилки, нестандартні положення. Якщо валідувати агента лише на чистих шаблонах, у продакшн він буде помилятися на реальних кейсах. Мінімум 20 реальних NDA у тестовому наборі перед запуском.
• Зелений коридор занадто широкий. Спокуса авто-схвалювати максимум документів заради швидкості призводить до пропуску рідкісних, але критичних ризиків (безстрокова конфіденційність, нестандартна юрисдикція). Починайте з вузького зеленого коридору — лише NDA від наявних перевірених контрагентів — і розширюйте в міру накопичення статистики рішень.
• Відсутність журналу аудиту. Для перевірки відповідності вимогам потрібно бачити, які рішення агент прийняв за останні 6-12 місяців і чому. Без логування агента не можна пройти SOC 2 або внутрішній юридичний аудит.
• Регламент не оновлюється. Правовий ландшафт змінюється — нова судова практика, нові регуляторні вимоги. Регламент потребує щоквартальної перевірки юристом, інакше рішення агента застарівають, а агент починає схвалювати положення, які компанія вже не хоче приймати.