Раскладка документов

Автоматизация Раскладка документов решает две связанные задачи: распознаёт тип файла и отправляет его в правильное место файлового хранилища. AI-агент запускается на каждый новый документ, который попадает во входящую папку или приходит вложением в почту. Работа идёт круглосуточно, без ручного триггера.

Что делает AI-агент

1. Получает файл из входящей папки файлового хранилища или почтового ящика — триггер срабатывает на событие «новый файл».
2. Извлекает текстовый слой: OCR для сканов и фотографий, парсинг для PDF и DOCX, текст как есть для TXT, RTF, EML.
3. Классифицирует документ по типу через LLM — договор, счёт, акт сверки, кадровый документ, коммерческое предложение, резюме, выписка из банка, доверенность.
4. Извлекает ключевые метаданные под тип документа: контрагент, дата, номер, сумма для финансовых; ФИО, должность, тип справки для кадровых.
5. Формирует понятное имя файла по шаблону — например, «2026-04-24_Договор_ООО-Ромашка_№142.pdf» или «2026-04-24_Счёт_Контур_№СФ-00128.pdf».
6. Перемещает файл в целевую папку по правилам, заданным при настройке: /Договоры/2026/Действующие/, /Счета/Входящие/, /Кадры/Документы-сотрудников/Иванов-И-И/.
7. Записывает событие в лог: кто инициатор, какой тип распознан, с какой уверенностью, куда перенесено, timestamp для аудита.
8. Уведомляет ответственного менеджера при низкой уверенности распознавания или когда тип документа не попал ни в одну из категорий — файл уходит в папку «На разбор».

Чего автоматизация не делает

• Не принимает юридические или финансовые решения по содержимому — только классифицирует и раскладывает, не подписывает, не согласовывает, не одобряет платёж.
• Не проверяет корректность реквизитов в документе: наличие подписи, печати, соответствие шаблону. Это остаётся работой бухгалтера, юриста или отдела качества.
• Не заменяет бизнес-процесс согласования входящего документа. Если договор должен пройти через юриста и финансового директора, маршрут согласования живёт в отдельной системе, а Раскладка лишь обеспечивает, что документ лежит там, где его найдут.

Раскладка документов строится на связке трёх слоёв: триггер на файловое хранилище, обработка файла через LLM-агент, запись результата обратно в хранилище. Low-code стек позволяет собрать пайплайн за несколько дней без написания отдельного backend-сервиса.

Технический поток

1. Триггер в low-code платформе или Zapier слушает входящую папку в Google Drive, Dropbox, OneDrive или S3. При появлении нового файла передаёт его содержимое в следующий шаг.
2. Шаг извлечения текста: для PDF используется text extraction, для сканов — OCR (Tesseract, Google Vision, AWS Textract), для офисных форматов — парсеры DOCX и XLSX.
3. Шаг классификации: текст файла передаётся в AI-модель с промптом, описывающим типы документов компании и ожидаемый JSON-ответ вида {type, confidence, metadata}.
4. Шаг валидации: если confidence ниже заданного порога, файл уходит в папку «На разбор» и создаётся задача в Slack или Notion.
5. Шаг именования: на основе извлечённых метаданных формируется новое имя файла по шаблону, заданному бизнесом.
6. Шаг перемещения: файл копируется в целевую папку, оригинал удаляется или переносится в архив «обработано».
7. Шаг логирования: запись в таблицу Airtable, Google Sheets или Notion для аудита — дата, тип, контрагент, путь, confidence.

Этапы внедрения

1. Неделя 1 — дискавери. Собираем список типов документов компании, текущую структуру папок, правила именования, текущих ответственных. Фиксируем ключевые типы, покрывающие основную массу входящего потока.
2. Неделя 2 — прототип. Разворачиваем оркестратор, подключаем файловое хранилище, пишем промпт для классификации, тестируем на репрезентативной выборке реальных документов.
3. Неделя 3 — настройка правил. Докручиваем шаблоны имён, маппинг «тип → папка», пороги confidence, обработку исключений (неопознанные документы, дубликаты, пустые файлы).
4. Неделя 4 — пилот и запуск. Запускаем на живой поток с параллельным ручным контролем в первые дни, фиксируем расхождения, итерируем промпт.

Компоненты решения

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

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

Данные и доступы

• Файловое хранилище с API — Google Drive, Dropbox, OneDrive или S3-совместимое. Доступ на чтение и запись к соответствующим папкам.
• Входящая папка, в которую попадают файлы — либо вручную от менеджеров, либо через интеграцию с почтой, либо выгрузкой из других систем.
• Список типов документов, которые реально встречаются в потоке, и правил их хранения — даже если это сейчас живёт в голове офис-менеджера.
• Образцы по каждому типу — несколько реальных файлов, чтобы настроить классификатор и проверить качество на этапе прототипа.
• API-ключ к LLM-провайдеру (Anthropic для AI-модели) и к OCR-сервису, если в потоке есть сканы.
• Аккаунт workflow-движка (self-hosted или cloud) или Zapier с достаточным лимитом операций под ожидаемый месячный объём.

Готовность команды

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

Таймлайн

• Формат weekend-проекта: 2-4 недели от старта до продакшена при одном инженере на частичной загрузке.
• Первая неделя — дискавери и сбор образцов, вторая — прототип, третья — настройка и тесты, четвёртая — пилот и запуск с параллельным ручным контролем.