Как сделать ИИ-агента для договоров и согласования правок

Что получится в результате

Соберем ИИ-агента, который принимает договор, сравнивает его с шаблоном компании, выделяет изменения, находит рискованные пункты, готовит вопросы юристу и ведет понятную очередь согласования.

Первая рабочая версия будет делать так:

1. новый договор попадает в папку `incoming_contracts`;
2. n8n создает запись в `contract_queue`;
3. агент извлекает текст, стороны, даты, сумму, сроки, реквизиты и номера пунктов;
4. агент определяет тип документа: NDA, поставка, услуги, SaaS, ДПА, допсоглашение или акт;
5. документ сравнивается с нужным шаблоном из `contract_templates`;
6. отличия записываются в `redline_log`;
7. рискованные условия проверяются по `risk_rules`;
8. спорные пункты попадают в `approval_queue`;
9. юрист, финансы или sales получают конкретные вопросы;
10. после решения статус меняется в `contract_queue`;
11. финальная версия сохраняется в `approved_contracts`;
12. история решений остается в `audit_log`.

В первой версии агент не утверждает договор, не подписывает его, не отправляет контрагенту финальный текст и не заменяет юриста. Его задача - подготовить разбор, список правок и маршрут согласования.

Что понадобится

• n8n Cloud или self-hosted n8n.
• Google Drive, SharePoint или другой файловый архив.
• Google Sheets для очередей и журналов.
• Google Docs или Microsoft Word для просмотра правок человеком.
• LLM API для извлечения условий и подготовки комментариев.
• 5-10 типовых шаблонов договоров компании.
• 10 тестовых договоров: нормальные, спорные и заведомо проблемные.
• Юрист или ответственный за договоры, который подтвердит правила риска.

Шаг 1. Зафиксируйте один сценарий

Не начинайте со всех договоров компании сразу.

Для первого прототипа выберите сценарий:

проверка входящего договора услуг от контрагента перед согласованием

Входит в сценарий:

• договор в PDF, DOCX или Google Docs;
• один контрагент;
• один внутренний владелец сделки;
• сравнение с шаблоном компании;
• список рисков;
• список вопросов;
• решение: принять, вернуть на правки или отправить юристу.

Не входит в сценарий:

• автоматическая подпись;
• отправка договора контрагенту;
• массовая замена юридических формулировок;
• принятие финансовых условий без владельца сделки;
• работа с судебными документами;
• хранение персональных данных без правил доступа.

Проверка: вы можете одной фразой описать вход, действие и результат агента.

Шаг 2. Создайте структуру папок

В Google Drive или SharePoint создайте папку:

Contract AI agent
  incoming_contracts
  contract_templates
  extracted_text
  needs_review
  approved_contracts
  rejected_contracts
  archive

Правило:

оригинал договора всегда копируется в archive
рабочие версии не перезаписывают исходный файл
финальная версия появляется только после approval

Проверка: у вас есть отдельные папки для входящих документов, шаблонов, спорных договоров и финальных версий.

Шаг 3. Создайте таблицу проекта

Создайте Google Sheet:

Contract review AI agent

Добавьте листы:

contract_queue
contract_templates
clause_map
risk_rules
redline_log
approval_queue
comment_drafts
audit_log
error_log
test_cases
settings

Проверка: n8n имеет доступ к таблице на чтение и запись.

Шаг 4. Сделайте лист contract_queue

В `contract_queue` добавьте колонки:

contract_id
created_at
source_file_url
original_file_url
contract_type
counterparty
internal_owner
deal_or_project
amount
currency
start_date
end_date
status
risk_level
current_approver
final_file_url
last_error
updated_at

Статусы:

new
extracting
parsed
compare_template
risk_check
needs_legal_review
needs_business_review
needs_finance_review
approved
rejected
error

Проверка: один тестовый договор можно добавить в таблицу вручную со статусом `new`.

Шаг 5. Заполните contract_templates

В `contract_templates` создайте колонки:

template_id
contract_type
template_name
template_file_url
version
owner
required_clauses
forbidden_clauses
approval_rules
is_active
updated_at

Пример:

template_id: services_v1
contract_type: services
template_name: Договор оказания услуг
required_clauses: предмет, цена, срок, приемка, ответственность, конфиденциальность, персональные данные, расторжение, реквизиты
forbidden_clauses: бессрочное автопродление, неограниченная ответственность, одностороннее изменение цены контрагентом
approval_rules: legal если risk_level=high; finance если amount>300000

Проверка: для выбранного типа договора есть активный шаблон.

Шаг 6. Создайте clause_map

`clause_map` нужен, чтобы агент не пересказывал договор общими словами, а ссылался на конкретные пункты.

Колонки:

contract_id
clause_id
clause_number
clause_title
clause_text
clause_type
page_or_section
source_quote
confidence
created_at

Типы пунктов:

parties
subject
price
payment
term
acceptance
liability
confidentiality
personal_data
ip_rights
termination
jurisdiction
force_majeure
requisites
other

Проверка: после обработки договора в `clause_map` появляются не менее 8-10 ключевых пунктов с номерами.

Шаг 7. Сделайте risk_rules

В `risk_rules` добавьте правила, по которым агент будет поднимать флаги.

Колонки:

rule_id
contract_type
risk_name
risk_level
trigger
why_it_matters
recommended_owner
recommended_action
is_active

Первый набор правил:

unlimited_liability | high | неограниченная ответственность | legal | заменить на лимит
auto_renewal | medium | автоматическое продление без уведомления | business | согласовать с владельцем
one_sided_penalty | high | штраф только для нашей стороны | legal | запросить симметричную формулировку
long_payment_delay | medium | отсрочка платежа больше 30 дней | finance | подтвердить условия оплаты
foreign_jurisdiction | high | иностранное право или суд | legal | проверить применимость
personal_data_without_dpa | high | есть персональные данные без DPA | legal | запросить приложение по данным
ip_transfer | high | передача исключительных прав | legal | проверить объем передачи
no_acceptance_procedure | medium | нет порядка приемки | business | добавить процедуру приемки

Проверка: каждое правило имеет владельца и действие, а не просто абстрактную метку риска.

Шаг 8. Создайте approval_queue

В `approval_queue` будут попадать решения, которые нельзя доверять агенту.

Колонки:

approval_id
contract_id
question
clause_number
source_quote
risk_level
owner_role
owner_name
status
decision
decision_comment
decided_at
created_at

Статусы:

open
approved
rejected
need_more_info
delegated
closed

Проверка: у каждого спорного пункта есть владелец решения.

Шаг 9. Настройте входящий trigger в n8n

Создайте workflow:

Contract review intake

Минимальные узлы:

1. `Google Drive Trigger` или `Webhook`;
2. `Get file metadata`;
3. `Copy original to archive`;
4. `Google Sheets: append row to contract_queue`;
5. `Set status = extracting`.

Записывайте `contract_id` в формате:

CTR-2026-0001

Проверка: загрузка файла в `incoming_contracts` создает строку в `contract_queue`.

Шаг 10. Извлеките текст договора

Создайте workflow:

Contract text extraction

Для DOCX или Google Docs забирайте текст напрямую.

Для PDF используйте OCR, если текст не извлекается.

Результат сохраняйте в `extracted_text`:

CTR-2026-0001.txt

В `contract_queue` обновляйте:

status = parsed

Проверка: для тестового договора есть текстовый файл, где видны номера пунктов и реквизиты.

Шаг 11. Попросите LLM вернуть строгий JSON

Создайте LLM-узел `Extract contract facts`.

Prompt:

Ты извлекаешь данные из договора. Верни только JSON.
Не давай юридических советов. Не исправляй договор.
Если поле не найдено, поставь null.

Нужна структура:
{
  "contract_type": "services|nda|supply|saas|dpa|addendum|act|unknown",
  "counterparty": "",
  "our_party": "",
  "amount": null,
  "currency": null,
  "start_date": null,
  "end_date": null,
  "payment_terms": "",
  "acceptance_terms": "",
  "liability_limit": "",
  "termination_terms": "",
  "jurisdiction": "",
  "personal_data": "yes|no|unclear",
  "signatories": [],
  "missing_fields": [],
  "summary": ""
}

Проверка: узел возвращает валидный JSON без вступления и пояснений.

Шаг 12. Обновите contract_queue извлеченными данными

После LLM-узла добавьте `Code` или `Set` node.

Запишите в `contract_queue`:

contract_type
counterparty
amount
currency
start_date
end_date
status = compare_template
updated_at

Если `contract_type = unknown`, ставьте:

status = needs_legal_review
risk_level = medium

Проверка: карточка договора в таблице уже понятна без открытия файла.

Шаг 13. Разбейте договор на пункты

Создайте LLM-узел `Extract clauses`.

Prompt:

Разбей договор на юридически значимые пункты.
Верни JSON array.
Каждый объект:
{
  "clause_number": "",
  "clause_title": "",
  "clause_type": "",
  "clause_text": "",
  "source_quote": "",
  "confidence": 0.0
}

Используй clause_type только из списка:
parties, subject, price, payment, term, acceptance, liability,
confidentiality, personal_data, ip_rights, termination,
jurisdiction, force_majeure, requisites, other.

Запишите результат в `clause_map`.

Проверка: в `clause_map` есть ссылки на конкретные пункты, а не общий пересказ договора.

Шаг 14. Сравните договор с шаблоном

Найдите активный шаблон по `contract_type`.

Создайте LLM-узел `Compare with template`.

Prompt:

Сравни входящий договор с шаблоном компании.
Верни только JSON array.
Ищи только существенные отличия.

Каждый объект:
{
  "change_type": "missing_required|changed_clause|new_clause|forbidden_clause|unclear",
  "clause_type": "",
  "incoming_clause_number": "",
  "template_clause_reference": "",
  "what_changed": "",
  "business_effect": "",
  "risk_level": "low|medium|high",
  "recommended_owner": "legal|finance|business|sales",
  "recommended_question": ""
}

Проверка: результат объясняет бизнес-смысл правки, а не просто пишет "пункт изменен".

Шаг 15. Заполните redline_log

В `redline_log` создайте колонки:

redline_id
contract_id
change_type
clause_type
incoming_clause_number
template_clause_reference
what_changed
business_effect
risk_level
recommended_owner
recommended_question
status
created_at

Статусы:

new
sent_to_approval
accepted
rejected
resolved

Проверка: каждое отличие от шаблона стало отдельной строкой.

Шаг 16. Проверьте risk_rules

Создайте цикл по строкам `risk_rules`, где `is_active = true`.

Для каждого правила передайте агенту:

• текст договора;
• `clause_map`;
• trigger правила;
• описание риска.

Prompt:

Проверь, срабатывает ли правило риска.
Верни JSON:
{
  "matched": true,
  "clause_number": "",
  "source_quote": "",
  "reason": "",
  "risk_level": "",
  "recommended_action": "",
  "confidence": 0.0
}

Если точного основания нет, matched=false.
Не выдумывай пункт.

Проверка: риск появляется только при наличии цитаты из договора.

Шаг 17. Рассчитайте общий risk_level

Добавьте правило:

high: есть хотя бы один high риск
medium: есть medium риск или contract_type unknown
low: рисков нет, но договор не финализирован

Обновите `contract_queue.risk_level`.

Проверка: договор с неограниченной ответственностью получает `high`.

Шаг 18. Сформируйте approval_queue

Для каждого high и medium риска создавайте строку в `approval_queue`.

Пример вопроса:

Пункт 7.2 ограничивает ответственность только контрагента, а для нашей стороны лимита нет. Можно ли вернуть правку с лимитом ответственности в размере стоимости договора?

Назначение:

legal: юридический смысл, ответственность, право, персональные данные
finance: цена, отсрочка, штрафы, валюта, налоги
business: срок, приемка, SLA, состав работ
sales: коммерческие уступки и отношения с клиентом

Проверка: у каждого вопроса есть `owner_role`, цитата и номер пункта.

Шаг 19. Подготовьте черновик комментариев

В `comment_drafts` добавьте колонки:

comment_id
contract_id
clause_number
comment_type
draft_text
status
approved_by
created_at

Prompt для черновика:

Подготовь короткий комментарий к договору для внутреннего согласования.
Не пиши финальную юридическую позицию.
Стиль: спокойно, конкретно, без давления.

Дано:
- пункт договора
- риск
- желаемое действие

Верни:
1. краткое объяснение риска;
2. вопрос владельцу;
3. нейтральную формулировку возможной правки.

Проверка: комментарий можно отправить юристу без переписывания с нуля.

Шаг 20. Сделайте уведомление ответственному

В n8n добавьте отправку в Slack, Telegram, email или задачу в CRM.

Сообщение:

Договор CTR-2026-0001 требует согласования.
Контрагент: ООО Пример
Тип: services
Риск: high
Вопросов: 4
Открой approval_queue и прими решение.

Не отправляйте полный текст договора в мессенджер, если там могут быть персональные, коммерческие или конфиденциальные данные.

Проверка: ответственный получает ссылку на строку или карточку, а не простыню текста.

Шаг 21. Добавьте ручное решение

Для первой версии решение можно принимать прямо в `approval_queue`.

Поля:

status
decision
decision_comment
decided_at

Примеры решений:

approved: принимаем риск
rejected: не принимаем, вернуть на правку
need_more_info: запросить уточнение у владельца сделки
delegated: передать другому владельцу

Проверка: после решения строка больше не висит как открытая.

Шаг 22. Соберите итоговый отчет по договору

Создайте LLM-узел `Build review report`.

Структура отчета:

1. Краткое резюме договора
2. Ключевые условия
3. Отличия от шаблона
4. Риски high
5. Риски medium
6. Открытые вопросы
7. Решения владельцев
8. Рекомендованный следующий статус

Формат:

Markdown или Google Docs

Проверка: юрист может открыть отчет и понять, что проверял агент.

Шаг 23. Обновите статус договора

Когда все строки в `approval_queue` закрыты, обновляйте `contract_queue`.

Правила:

есть rejected -> status = rejected
есть need_more_info -> status = needs_business_review
все approved и нет high unresolved -> status = approved
есть открытые high -> status = needs_legal_review

Проверка: статус договора меняется на основе решений, а не на основе самоуверенности модели.

Шаг 24. Подготовьте финальную папку

Если договор approved:

1. скопируйте файл в `approved_contracts`;
2. приложите отчет;
3. добавьте ссылку на `final_file_url`;
4. оставьте ссылку на audit trail;
5. уведомите владельца сделки.

Если rejected:

1. переместите копию в `rejected_contracts`;
2. приложите список правок;
3. отправьте владельцу сделки причину.

Проверка: по одному `contract_id` можно найти оригинал, отчет, решения и финальную версию.

Шаг 25. Ведите audit_log

В `audit_log` добавьте колонки:

event_id
contract_id
event_type
actor
source
details
created_at

Логируйте:

• загрузку договора;
• копирование оригинала;
• извлечение текста;
• запуск LLM;
• срабатывание риска;
• создание approval;
• решение человека;
• изменение статуса;
• ошибку workflow.

Проверка: можно восстановить путь договора от загрузки до решения.

Шаг 26. Настройте error_log

В `error_log` создайте колонки:

error_id
contract_id
workflow_name
node_name
error_type
error_message
input_snapshot
status
owner
created_at

Типовые ошибки:

file_not_readable
ocr_failed
llm_json_invalid
template_not_found
missing_required_field
approval_owner_not_found
permission_denied

Проверка: при сбое workflow не молчит, а оставляет понятную строку для разбора.

Шаг 27. Сделайте тестовый набор

В `test_cases` добавьте договоры:

normal_services_contract
unlimited_liability
missing_acceptance
foreign_jurisdiction
long_payment_delay
personal_data_without_dpa
auto_renewal
unknown_contract_type
bad_scan_pdf
empty_file

Для каждого заполните:

test_id
file_url
expected_contract_type
expected_risk_level
expected_status
expected_flags
last_run_at
last_result

Проверка: изменение prompt или правила можно прогнать на старых кейсах.

Шаг 28. Проверьте прототип на одном договоре

Возьмите тестовый договор услуг и прогоните полный путь:

1. загрузите файл в `incoming_contracts`;
2. проверьте строку в `contract_queue`;
3. проверьте `clause_map`;
4. проверьте `redline_log`;
5. проверьте `approval_queue`;
6. примите одно решение человеком;
7. сформируйте отчет;
8. переведите договор в `approved` или `rejected`;
9. проверьте `audit_log`.

Проверка: от загрузки файла до итогового статуса не нужно вручную копировать данные между таблицами.

Минимальная проверка результата

Прототип работает, если выполняются все пункты:

• новый файл создает строку в `contract_queue`;
• оригинал сохраняется в `archive`;
• текст договора извлекается;
• тип договора определяется;
• ключевые пункты попадают в `clause_map`;
• отличия от шаблона пишутся в `redline_log`;
• риски создают строки в `approval_queue`;
• человек может принять решение по каждому риску;
• итоговый отчет собирается в одном файле;
• статус договора меняется по правилам;
• ошибки пишутся в `error_log`;
• история действий видна в `audit_log`.

Что нельзя автоматизировать в первой версии

• юридическое утверждение договора;
• подписание договора;
• отправку финальной версии контрагенту;
• удаление исходных документов;
• принятие high-risk условий без человека;
• изменение формулировок в договоре без review;
• обход прав доступа к документам;
• хранение секретов и персональных данных в prompt;
• выдачу окончательной юридической консультации от имени компании.

Частые вопросы

Можно ли сделать агента без юриста?

Нет, если договоры реально влияют на деньги, ответственность и права компании. Агент может подготовить разбор, подсветить риски и ускорить согласование, но финальное решение должен принимать ответственный человек.

Можно ли сразу подключить DocuSign или другой сервис подписи?

Можно, но в первой версии лучше использовать только чтение статусов и подготовку пакета. Отправку на подпись включайте после approval и тестов, чтобы агент не отправил неутвержденную версию договора.

Что делать, если агент не понимает тип договора?

Ставьте `contract_type = unknown`, `risk_level = medium` и отправляйте документ в `needs_legal_review`. Не заставляйте модель угадывать тип, если от этого зависит шаблон проверки.

Как хранить конфиденциальные договоры?

Доступ к папкам должен соответствовать ролям: агент читает только нужные документы, а таблицы не должны содержать полный текст договора, если достаточно ссылок, цитат и номеров пунктов.

Какой минимум нужен для запуска?

`contract_queue`, `contract_templates`, `clause_map`, `risk_rules`, `redline_log`, `approval_queue`, `audit_log`, n8n workflow, один шаблон договора и 5-10 тестовых документов.