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

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

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

1. Витягує структуровані дані з неструктурованого тексту: строк дії NDA, визначення конфіденційної інформації, юрисдикція та застосовне право, тип угоди (односторонній або взаємний), винятки з конфіденційності, умови injunctive relief, обмеження на non-solicitation.
2. Звіряє з внутрішнім playbook компанії — зведенням правил, які визначають прийнятні та неприйнятні положення. Playbook веде юрист і оновлює в міру появи нових кейсів.
3. Класифікує документ за трьома категоріями: green lane (відповідає playbook — авто-схвалення), yellow lane (незначні відхилення — пропонує redlines), red lane (суттєві ризики — ескалація юристу).
4. Генерує summary з підсвічуванням відхилень: що в NDA суперечить playbook, яка редакція пропонується натомість, на що юрист має звернути увагу при фінальній перевірці.
5. Маршрутизує документ за результатом тріажу: надсилає в канал Slack для фінального review, повертає контрагенту email із запропонованими правками або поміщає в папку «ready to sign» на Google Drive або Dropbox.

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

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

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

Solo / Boutique (1-5 осіб)

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

SMB (6-30 осіб)

Для компанії, що зростає, де різні відділи отримують різні типи NDA: sales — з клієнтами, procurement — з вендорами, partnerships — з партнерами. Агент працює з 3-4 playbook variants, розпізнає контекст і застосовує правильний playbook. Green lane авто-схвалюється і одразу іде на підпис, yellow lane — у Slack-канал #legal-review, red lane — персонально юристу. Інтеграції: DocuSign або Dropbox Sign, Slack, файлове сховище. Це базовий preset для більшості SaaS і професійних сервісних компаній.

Enterprise (30+ осіб)

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

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

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

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

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

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

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

LLM-агент (мовна модель) проходить по тексту і заповнює структуровану схему: визначення Confidential Information, duration of obligations, survival period, jurisdiction clause, mutual або unilateral, permitted disclosures (regulators, advisors, affiliates), carve-outs (publicly known, independently developed), residual clause, injunctive relief, non-solicitation, return або destruction of materials.

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

Крок 4: Порівняння з playbook

Playbook — це структурований документ (YAML або JSON-подібний формат), де для кожного поля задано: acceptable values (автоматично OK), edge cases (вимагає уваги), red flags (автоматично escalate). Наприклад: duration acceptable — до 5 років, edge — 5-7 років, red — 7+ років або perpetual.

Агент проходить по кожному полю, порівнює витягнуте значення з playbook і формує deviation list. Для кожного відхилення генерується suggested redline — конкретне формулювання, якому компанія надає перевагу. Ці redlines зберігаються в playbook як approved language patterns, що забезпечує consistency між різними NDA.

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

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

1. Green lane (auto-approve). Документ переміщується до папки «Ready to sign», сповіщення відправляється ініціатору угоди (sales, partnerships) з summary із 3-5 bullet points.
2. Yellow lane (counter-proposal). Генерується draft email для контрагента із запропонованими правками. Draft відправляється юристу на review у Slack — схвалення одним кліком, і email іде.
3. Red lane (escalation). Юрист отримує персональне сповіщення з повним summary, списком відхилень і посиланням на документ. Агент не пропонує правок — ситуація вимагає юридичного аналізу.

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

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

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

Безпека та compliance

NDA містять чутливі комерційні дані. Базове налаштування включає: обробку документів у ізольованому середовищі без збереження контенту поза audit log, шифрування at-rest у файловому сховищі, access control на рівні playbook (хто може змінювати правила). Для компаній під GDPR або SOC 2 додається: data residency в EU або US регіоні, логування всіх операцій агента з timestamp, retention policy на вихідні документи та проміжні представлення. Якщо контрагент — державна структура або регульована галузь (фінанси, охорона здоров'я), red lane включає обов'язкову ескалацію незалежно від змісту. Вміст NDA не використовується для навчання моделей.

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

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

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

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

• Playbook у голові юриста, а не в документі. Найчастіша помилка — спроба запустити агента без формалізованого playbook. Без явних правил агент генерує правдоподібні рішення, які розходяться з реальною практикою компанії. Перед впровадженням закладайте 2-3 дні на виписування правил у структурований формат.
• Тестування лише на синтетичних NDA. Реальні NDA від контрагентів містять нестандартні формулювання, друкарські помилки, custom clauses. Якщо валідувати агента лише на чистих шаблонах, у production він буде помилятися на реальних кейсах. Мінімум 20 реальних NDA у тестовому наборі перед запуском.
• Green lane занадто широкий. Спокуса авто-схвалювати максимум документів заради швидкості призводить до пропуску рідкісних, але критичних ризиків (perpetual confidentiality, нестандартний jurisdiction). Починайте з вузького green lane — лише NDA від наявних known-good контрагентів — і розширюйте в міру накопичення статистики рішень.
• Відсутність audit trail. Для compliance-перевірок потрібно бачити, які рішення агент прийняв за останні 6-12 місяців і чому. Без логування агента не можна пройти SOC 2 або внутрішній юридичний аудит.
• Playbook не оновлюється. Legal landscape змінюється — нова судова практика, нові регуляторні вимоги. Playbook потребує квартального review юристом, інакше рішення агента застарівають, а агент починає схвалювати положення, які компанія вже не хоче приймати.