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

Автоматизація Розкладка документів вирішує два пов'язані завдання: розпізнає тип файлу та надсилає його у правильне місце файлового сховища. 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 тижні від старту до продакшену при одному інженері на частковому завантаженні.
• Перший тиждень — дискавері та збір зразків, другий — прототип, третій — налаштування та тести, четвертий — пілот і запуск з паралельним ручним контролем.