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 юристом, иначе решения агента устаревают, а агент начинает одобрять положения, которые компания уже не хочет принимать.