Как сделать ИИ-агента для обработки входящих документов

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

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

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

1. файл попадает в папку `incoming_documents` или приходит на email/webhook;
2. n8n создает запись в `document_queue`;
3. оригинал копируется в `archive`;
4. текст извлекается из PDF, DOCX, изображения или email-вложения;
5. агент определяет тип документа;
6. найденные поля записываются в `extracted_fields`;
7. правила из `validation_rules` проверяют обязательные поля;
8. спорные документы уходят в `review_queue`;
9. уверенные документы попадают в нужный маршрут;
10. ошибки пишутся в `error_log`;
11. все действия сохраняются в `audit_log`;
12. тестовый набор проверяет, что новые prompt и правила не ломают обработку.

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

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

• n8n Cloud или self-hosted n8n.
• Google Drive, SharePoint или S3-совместимое хранилище.
• Google Sheets для очередей, правил и логов.
• OCR/PDF parser: Google Cloud Vision, Docling, Unstructured или другой инструмент.
• LLM API для классификации и извлечения полей.
• 30-50 тестовых документов разных типов.
• Ответственные по маршрутам: бухгалтерия, юристы, продажи, HR, поддержка.
• Человек для ручной проверки спорных документов.

Шаг 1. Ограничьте первый сценарий

Не начинайте с “обрабатывать все документы компании”.

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

обработка входящих документов из общей почты и папки загрузки

Типы документов в первом запуске:

• счет;
• акт;
• договор;
• письмо от клиента;
• заявка;
• претензия;
• резюме;
• прочее.

Что не входит:

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

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

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

В Google Drive, SharePoint или S3 создайте:

Incoming documents AI agent
  incoming_documents
  archive
  extracted_text
  needs_review
  routed_documents
  rejected_documents
  test_documents

Правило:

оригинал всегда копируется в archive
рабочие копии перемещаются по статусам
из incoming_documents файл уходит только после успешной регистрации в очереди

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

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

Создайте Google Sheet:

Incoming document AI agent

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

document_queue
document_types
extraction_schema
extracted_fields
validation_rules
review_queue
routing_rules
route_log
audit_log
error_log
test_cases
settings

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

Шаг 4. Настройте document_queue

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

document_id
created_at
source_channel
source_file_url
archive_file_url
sender
subject
file_name
file_type
document_type
status
confidence
assigned_route
current_owner
review_reason
final_result
last_error
updated_at

Статусы:

new
registered
extracting_text
classifying
extracting_fields
validating
needs_review
routed
rejected
error
done

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

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

В `document_types` создайте справочник.

Колонки:

document_type
name
description
examples
default_route
min_confidence
requires_review
is_active

Первый набор:

invoice | счет | бухгалтерия | 0.80 | yes
act | акт | бухгалтерия | 0.80 | yes
contract | договор | юристы | 0.85 | yes
client_letter | письмо клиента | продажи или поддержка | 0.70 | no
claim | претензия | юристы и поддержка | 0.85 | yes
resume | резюме | HR | 0.75 | no
request | заявка | поддержка | 0.70 | no
unknown | неизвестный документ | ручная проверка | 1.00 | yes

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

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

`extraction_schema` говорит агенту, какие поля нужны для каждого типа документа.

Колонки:

document_type
field_name
field_label
field_type
required
validation_hint
example

Пример для счета:

invoice | supplier_name | Поставщик | string | yes | найти юрлицо или ИП | ООО Пример
invoice | inn | ИНН | string | yes | 10 или 12 цифр | 7700000000
invoice | invoice_number | Номер счета | string | yes | номер рядом со словом счет | 15
invoice | invoice_date | Дата счета | date | yes | дата документа | 2026-05-22
invoice | amount | Сумма | money | yes | итог к оплате | 150000
invoice | vat | НДС | money | no | если указан | 25000

Пример для договора:

contract | counterparty | Контрагент | string | yes | сторона договора | ООО Пример
contract | subject | Предмет | text | yes | предмет договора | оказание услуг
contract | start_date | Дата начала | date | no | срок действия | 2026-06-01
contract | amount | Сумма | money | no | цена договора | 300000
contract | signatories | Подписанты | list | no | ФИО и должности | Иванов И.И.

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

Шаг 7. Создайте validation_rules

В `validation_rules` добавьте правила проверки.

Колонки:

rule_id
document_type
field_name
rule_type
rule_value
severity
message
is_active

Первый набор:

inn_format | invoice | inn | regex | ^[0-9]{10}([0-9]{2})?$ | high | ИНН должен быть 10 или 12 цифр
amount_required | invoice | amount | required | true | high | Не найдена сумма
date_required | invoice | invoice_date | required | true | high | Не найдена дата счета
contract_subject_required | contract | subject | required | true | high | Не найден предмет договора
claim_route | claim | document_type | route_review | legal | high | Претензия всегда идет на review
unknown_review | unknown | document_type | route_review | manual | high | Неизвестный документ требует ручной проверки

Проверка: обязательные поля и критичные типы документов не проходят мимо review.

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

В `routing_rules` задайте, куда отправлять документы.

Колонки:

route_id
document_type
condition
target_team
target_owner
target_system
action
requires_approval
is_active

Пример:

invoice_default | invoice | confidence>=0.80 | accounting | accountant@company.ru | accounting_queue | create_task | yes
contract_default | contract | any | legal | lawyer@company.ru | legal_queue | create_task | yes
resume_default | resume | confidence>=0.75 | hr | recruiter@company.ru | hr_queue | create_task | no
unknown_default | unknown | any | operations | ops@company.ru | review_queue | create_review | yes

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

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

Создайте workflow:

Incoming document intake

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

1. `Google Drive Trigger`, `IMAP Email Trigger` или `Webhook`;
2. `Get file metadata`;
3. `Generate document_id`;
4. `Copy original to archive`;
5. `Append row to document_queue`;
6. `Set status = registered`.

Формат `document_id`:

DOC-2026-000001

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

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

Создайте workflow:

Incoming document text extraction

Правила:

• PDF с текстовым слоем - извлекать текст напрямую;
• скан PDF - отправлять в OCR;
• изображение - OCR;
• DOCX - извлекать текст и заголовки;
• email - сохранять тело письма и вложения отдельно;
• архивы ZIP - в первой версии отправлять в review.

Сохраняйте текст в `extracted_text`:

DOC-2026-000001.txt

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

Шаг 11. Оцените качество распознавания

Добавьте поля качества:

ocr_confidence
text_length
has_tables
has_stamp_or_signature
language
quality_status

Статусы:

good
medium
bad
empty

Правило:

bad или empty -> status = needs_review

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

Шаг 12. Классифицируйте документ

Создайте LLM-узел `Classify document`.

Prompt:

Определи тип входящего документа.
Верни только JSON.
Не извлекай поля на этом шаге.

Допустимые типы:
invoice, act, contract, client_letter, claim, resume, request, unknown.

Формат:
{
  "document_type": "",
  "confidence": 0.0,
  "reason": "",
  "signals": [],
  "needs_review": true|false
}

Проверка: договор не классифицируется как письмо только потому, что пришел по email.

Шаг 13. Обновите document_queue после классификации

Запишите:

document_type
confidence
status = extracting_fields
review_reason
updated_at

Если:

document_type = unknown
confidence < min_confidence
quality_status = bad

ставьте:

status = needs_review
review_reason = low_confidence_or_bad_quality

Проверка: слабая классификация уходит человеку, а не в автоматический маршрут.

Шаг 14. Извлеките поля по схеме

Получите строки из `extraction_schema` для найденного `document_type`.

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

Prompt:

Извлеки поля из документа по схеме.
Верни только JSON array.
Если поле не найдено, value=null.
Не придумывай значения.

Каждый объект:
{
  "field_name": "",
  "value": null,
  "source_quote": "",
  "confidence": 0.0
}

Передайте в prompt:

• текст документа;
• тип документа;
• список полей из `extraction_schema`;
• правило: “цитата обязательна для найденного значения”.

Проверка: каждое найденное поле имеет цитату из документа.

Шаг 15. Запишите extracted_fields

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

document_id
document_type
field_name
value
source_quote
confidence
validation_status
created_at

Статусы валидации:

not_checked
valid
warning
invalid
missing

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

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

Создайте workflow-узел проверки правил.

Для каждого правила:

• найдите поле;
• проверьте required;
• проверьте regex;
• проверьте тип даты;
• проверьте сумму;
• проверьте route_review.

Если правило high не выполнено:

status = needs_review
review_reason = validation_failed

Проверка: счет без суммы или ИНН не уходит в бухгалтерию как готовый.

Шаг 17. Создайте review_queue

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

review_id
document_id
document_type
reason
risk_level
assigned_team
assigned_owner
question
source_file_url
status
decision
decision_comment
created_at
closed_at

Причины:

unknown_type
low_confidence
bad_ocr
missing_required_field
validation_failed
claim_or_legal_risk
personal_data_detected
duplicate_document

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

Шаг 18. Настройте маршрутизацию

После успешной валидации примените `routing_rules`.

Для первой версии действие лучше делать мягким:

создать задачу
отправить уведомление
положить ссылку в очередь

Не делайте сразу:

проводку в 1С
платеж
отправку клиенту
подписание
удаление файла

Проверка: документ уходит в нужную команду, но критичные действия требуют approval.

Шаг 19. Записывайте route_log

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

route_event_id
document_id
document_type
route_id
target_team
target_owner
target_system
action
status
created_at

Статусы:

created
sent
failed
confirmed

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

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

Сообщение в Slack, Telegram, email или задаче:

Новый входящий документ DOC-2026-000001
Тип: invoice
Поставщик: ООО Пример
Сумма: 150000
Статус: needs_review
Причина: не найден ИНН
Ссылка: ...

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

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

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

В `review_queue` человек выбирает:

approved
rejected
need_more_info
wrong_type
duplicate

После решения обновляйте `document_queue`:

approved -> routed
rejected -> rejected
wrong_type -> classifying или extracting_fields с новым типом
need_more_info -> needs_review
duplicate -> rejected

Проверка: ручное решение меняет общий статус документа.

Шаг 22. Проверьте дубли

Добавьте простую проверку дублей:

file hash
document_type + number + date + amount
sender + file_name

Если найден дубль:

status = needs_review
review_reason = duplicate_document

Проверка: один и тот же счет, присланный дважды, не превращается в две независимые задачи.

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

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

event_id
document_id
event_type
actor
source
details
created_at

Логируйте:

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

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

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

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

error_id
document_id
workflow_name
node_name
error_type
error_message
input_snapshot
status
owner
created_at

Типы ошибок:

file_not_found
permission_denied
unsupported_format
ocr_failed
empty_text
llm_json_invalid
schema_not_found
validation_failed
routing_rule_missing
notification_failed

Проверка: сбой workflow не теряется, а появляется как конкретная ошибка.

Шаг 25. Создайте test_cases

В `test_cases` добавьте тестовые файлы.

Колонки:

test_id
file_url
expected_document_type
expected_status
expected_route
must_extract_fields
must_review_reason
last_run_at
last_result

Первый набор:

normal_invoice
invoice_without_inn
bad_scan_invoice
simple_contract
client_claim
client_letter
resume_pdf
unknown_document
duplicate_invoice
zip_archive

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

Шаг 26. Прогоните полный путь на одном файле

Возьмите тестовый счет.

Порядок:

1. положите файл в `incoming_documents`;
2. проверьте строку в `document_queue`;
3. проверьте копию в `archive`;
4. проверьте текст в `extracted_text`;
5. проверьте тип документа;
6. проверьте `extracted_fields`;
7. проверьте `validation_rules`;
8. примите решение в `review_queue`, если нужно;
9. проверьте `route_log`;
10. проверьте `audit_log`;
11. проверьте отсутствие ошибок в `error_log`.

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

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

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

• новый файл создает строку в `document_queue`;
• оригинал сохраняется в `archive`;
• текст извлекается в `extracted_text`;
• тип документа определяется;
• поля записываются в `extracted_fields`;
• обязательные поля проверяются через `validation_rules`;
• слабая уверенность уходит в `review_queue`;
• дубли ловятся до маршрутизации;
• документ уходит в правильный маршрут;
• route событие пишется в `route_log`;
• решения человека меняют статус;
• ошибки пишутся в `error_log`;
• вся история видна в `audit_log`;
• `test_cases` проходят после изменения prompt.

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

• удаление оригиналов;
• платежи;
• подписание документов;
• юридическое утверждение;
• проведение документов в 1С или ERP без approval;
• обработку паспортов, медицинских документов и чувствительных персональных данных без отдельного процесса;
• отправку полного текста документов в открытые чаты;
• доверие к плохому OCR;
• обработку неизвестного типа как надежного;
• изменение маршрутов без ответственного владельца.

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

Можно ли начать только с email-вложений?

Да. Email trigger плюс папка `incoming_documents` - хороший старт. Главное сохранять оригинал, фиксировать отправителя, тему письма и отдельно обрабатывать каждое вложение.

Что делать с плохими сканами?

Ставить `quality_status = bad` и отправлять в `review_queue`. Плохой OCR нельзя использовать как надежную основу для извлечения суммы, ИНН, даты или юридически значимых условий.

Можно ли сразу записывать данные в 1С или CRM?

В первой версии лучше нет. Сначала создавайте задачу или черновик записи, а финальную запись делайте после approval. Так проще отловить ошибки классификации и извлечения.

Как обрабатывать неизвестный документ?

Ставить `document_type = unknown`, `status = needs_review` и назначать владельца ручной проверки. Не заставляйте модель угадывать тип, если уверенности не хватает.

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

`document_queue`, `document_types`, `extraction_schema`, `extracted_fields`, `validation_rules`, `review_queue`, `routing_rules`, `route_log`, `audit_log`, `error_log`, n8n workflow и 10 тестовых документов.