Автоматизація договорів і документів з ШІ-шаблонами: гібридний підхід

Чому AI-генерація документів ламається на реальних договорах

AI-генерація документів упевнено працює на однорідному потоці й розсипається, коли в теку потрапляє другий контрагент зі своєю структурою.

Пункти перейменовано, нумерацію збито, додатки винесено в окремі файли — правило, яке шукало «Предмет договору» за заголовком, більше не знаходить нічого. Автоматизація договорів починається не із шаблону, а з різнобою форматів, і саме він з'їдає перший місяць роботи.

Окрема лінія відмов — скани без текстового шару. Документи надходять фотографіями та PDF після друку й підпису, а вилучення реквізитів зі сканів критичне до кожного знака: розпізнавання плутає схожі цифри, втрачає пробіли в номері рахунку, розриває ІПН і БІК. Помилка в одному символі означає платіж не туди й повернення комплекту на нове коло погодження.

Шаблони живуть своїм життям. Юрист править формулювання під конкретну угоду, правка залишається у файлі, і за місяць у роботі п'ять майже однакових версій, а еталонна — невідомо яка.

Ручна правка шаблонів перетворюється на постійну, бо кожну нову умову доводиться вписувати заново й знову звіряти очима.

Накопичений ефект — зрив строків погодження. Документ іде ланцюжком, на кожному кроці хтось переперевіряє реквізити вручну, версії розходяться між відділами, а відповідальність за помилку розмивається.

Розбираємо, як це закривається: схема вилучення даних, контроль якості розпізнавання й керування версіями шаблонів.

Що змінюється після впровадження: строки, помилки, обсяг

Строк підготовки пакета скорочується не за рахунок прискорення набору тексту, а за рахунок зникнення передач між людьми.

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

Клас помилок перенесення даних зникає разом із ручним копіюванням: друкарські помилки в реквізитах, переплутані суми й дати, розходження нумерації додатків більше не доживають до фінального файлу.

Кожне значення береться з джерела один раз, а перевірки повноти й арифметики спрацьовують до надсилання, а не на підписанні. Залишаються помилки самого джерела — їх відсікає валідація на вході.

Обсяг обробки зростає без набору штату: типові договори йдуть за шаблоном майже без участі людини, а фахівець підключається там, де є відхилення від правил. Черга регулюється правилами маршрутизації, тому пікове навантаження не перетворюється на аврал.

Контроль версій документа стає вивантажуваним, а не відновлюваним із пам'яті: видно, яку редакцію шаблону застосовано, хто й коли змінив поле, чим відрізнялася попередня версія.

Частка ручних операцій падає — звірка, пересилання й пошук актуального файлу перестають бути окремою роботою, а аудит за ISO 9001 проходить за журналом, а не за відновленням подій.

Режими роботи: шаблон, мовна модель, гібрид

Вибір режиму — це вибір між передбачуваністю та гнучкістю, і на живому потоці документів він майже ніколи не один.

Типові угоди дешевше збирати підстановкою в жорсткий шаблон договору, вільна генерація моделлю виручає на нетипових розділах, а змінну частину — суми, строки, реквізити — безпечніше тримати під перевіркою. Нижче — чим ці три режими відрізняються на практиці.

У гібридному підході до генерації каркас, нумерація розділів і реквізити приходять із шаблону й довідників, а модель заповнює лише ті блоки, де потрібне формулювання під ситуацію.

Детермінований вивід забезпечується не моделлю, а правилами перевірки полів: обов'язковість, допустимий формат, звірка з обліковою системою та цілісність посилань додатків.

Якщо правило не виконано, документ не йде на підпис, а повертається на крок збирання із зазначенням конкретного поля.

Порядок робіт: від розбору масиву до здачі

Порядок фіксований, бо кожен наступний етап спирається на перевірюваний артефакт попереднього. Так на будь-якому кроці видно, де саме помилка — у правилах розбору, у моделі чи у вихідних даних, — а не «на виході щось не те».

1. Аудит документопотоку. Дивимося, які типи договорів і супутніх паперів реально ходять у компанії, у яких форматах, скільки серед них сканів і таблиць. На виході — карта типів із частками та перелік полів, які потрібно вилучати.
2. Проєктування схеми обробки. Розкладаємо кожен тип за маршрутом: де розбір іде правилами й словниками, де підключається модель, у якій точці документ іде на ручну перевірку. Фіксуємо, що вважається успішним розбором.
3. Налаштування вилучення полів. Заводимо довідники контрагентів, шаблони реквізитів і правила нормалізації дат, сум і нумерації. Для кожного поля задаємо поріг упевненості: нижче — документ не проходить далі без людини.
4. Збирання шаблонів генерації. Типові документи збираються з перевірених блоків із підстановкою полів із картки, а неприпустимі поєднання умов відсікаються до вивантаження.
5. Валідація на історичних прикладах. Прогоняємо масив минулих договорів і звіряємо результат із тим, що колись заповнювала людина. Розходження розбираємо й закриваємо правилами або коригуємо пороги.
6. Передача в експлуатацію. Віддаємо регламенти обробки, опис черги перевірки, налаштований моніторинг якості та навчання співробітників. Далі супровід іде за метриками: частка розібраних без правок, типові помилки, обсяг ручної черги.

Комплект постачання: шаблони, правила, регламенти

Комплект постачання — це не тека із шаблонами, а робоча система, яку можна передати іншій команді без усних пояснень. Кожен артефакт має версію, власника та порядок зміни, тому нові типи угод додаються правкою налаштувань, а не переписуванням логіки.

• Бібліотека шаблонів договорів — розбита за типами угод, поля розмічені як обов'язкові, умовні та опціональні. Версія шаблону фіксується у випущеному документі, тому завжди видно, за якою редакцією він зібраний.
• Правила вилучення та валідації полів — описано, що вважається значенням, які формати дат, сум і реквізитів допустимі, з чим звіряється результат. Поріг спрацьовування та строгість перевірки налаштовуються без правки коду.
• Схема проходження документа — маршрут від завантаження чернетки до випуску: вилучення даних, перевірка, погодження, підпис. На схемі відмічені точки, де підключається людина і які дані вона бачить.
• Регламент обробки винятків — що робити, коли поле не розпізнано або умови конфліктують: черга, відповідальний, строк реакції, фіксація рішення. Розібраний випадок стає новим правилом, а не разовою правкою.
• Інструкції для співробітників — ролі, типові сценарії, дії при розходженні з реєстром контрагентів. Написані так, щоб нова людина виходила на самостійну роботу без супроводу.
• Журнал рішень і метрики — частка документів, що пройшли без ручної правки, час циклу, топ причин відхилень. За ними видно, де вузьке місце і чи варто розширювати автоматизацію.
• Порядок оновлення комплекту — хто погоджує нову редакцію шаблону або правила, як перевірити зміну на історичних документах і як відкотитися до попередньої версії.

Обговоримо вашу задачу — повернемося з оцінкою та планом.

Кейс: підготовка договорів до та після впровадження

До впровадження пакет договорів збирали вручну: тексти жили в копіях-файлах, і кожна правка розкочувалася по них окремо. На пакет із 60 документів ішло 3-4 робочі дні, а в кінці кварталу, коли заявок надходило вдвічі більше, черга розтягувалася до тижня.

Що показували заміри до

• Повернення на доопрацювання: близько третини шаблонів ішло на друге коло — розходження в реквізитах і роз'їхалися формулювання.
• Пікове навантаження: кінець місяця відділ закривав перепрацюваннями, до 40% часу йшло на звірку копій, а не на правову роботу.
• Єдиної точки правок не було: зміна пункту вимагала ручної синхронізації по всьому набору документів.

Що змінили і що це дало

Шаблони перевели до спільної бібліотеки: версії, умовні блоки під тип угоди та обов'язкові поля стали єдиними. Чернетка збирається генерацією на OpenAI і потім проходить перевірку за структурою та реквізитами — модель заповнює змінні, правила відсікають те, що не проходить.

Збирання пакета займає 3-4 години замість 3-4 днів. Повернення на доопрацювання впали з третини до 8%: розходження в шаблонах більше не виникає — правка вноситься в одному місці й успадковується всіма. Пікове навантаження відділ проходить без перепрацювань, черга зростає лінійно.

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

Чим відрізняється збирання за шаблоном від роботи моделі?

Шаблон — це детерміноване збирання: значення підставляються в заздалегідь розмічені поля, структура та формулювання залишаються незмінними. Результат передбачуваний до символу, а контроль якості зводиться до звірки вхідних даних, а не готового тексту.

Модель працює інакше: AI-генерація документів будує формулювання під контекст і витягує сенс із неструктурованих місць.

Це єдиний спосіб закрити документи, які не зводяться до фіксованих полів, але у гнучкості є ціна — результат перевіряє людина, і обсяг правок залежить від типу документа.

Вартість контролю якості — головний критерій вибору. Там, де формулювання має збігатися буквально (реквізити, дати, предмет договору), збирання за шаблоном дешевше: перевіряють дані, а не текст.

Там, де важлива мова й адаптація під ситуацію, перевірка людиною неминуча — її обсяг закладають заздалегідь, вибірково або за порогами впевненості.

Правило просте: якщо документ описується набором полів — це шаблон; якщо сенс тримається на тексті — модель; якщо структура стійка, а наповнення змінюється — гібрид.

Часті сумніви: точність, перевірка та обсяг документів

Заперечення щодо таких проєктів майже завжди технічні: як поводитиметься система на поганих сканах, чи не «попливуть» формулювання, хто бачить чернетки й хто відповідає за випуск.

Саме за цими межами й визначається, де AI-генерація документів доречна повністю, а де обов'язковий ручний крок.

Формулювання не почнуть «плавати» від документа до документа?

Текст збирається не вільним переказом моделі, а за затвердженим шаблоном із фіксованою структурою та словником формулювань. Шаблон версіонується, версія фіксується в картці документа — за будь-якою угодою видно, з якої редакції зібрано текст.

Хто бачить чернетки й як розмежовано доступ?

Чернетки залишаються всередині контуру замовника, назовні йдуть лише готові файли за явною дією. Доступ будується на ролях: автор бачить свої документи, погоджувач — лише надіслані йому, адміністратор — журнал дій. Кожне відкриття та правка записуються.

Хто відповідає за випущений документ?

Випуск завжди за людиною: система готує проєкт і підставляє дані, підпис і надсилання — за співробітником із потрібною роллю. У журналі залишається, хто і що змінив перед випуском, тому розбір спірної ситуації займає хвилини, а не дні.

Обговоримо задачу: що потрібно для оцінки строків

Щоб порахувати строки, мало опису задачі — на якість AI-генерації документів впливають не самі моделі, а шаблони, правила підстановки та те, де дозволено обробляти дані.

Надішліть матеріали зі списку нижче, розберемо їх і повернемося з оцінкою та планом робіт: етапами, складом перевірок і точками, де знадобиться участь вашої сторони.

• Зразки документів — 10-15 реальних файлів за кожним типом: із варіантами формулювань, додатками, виносками та ручними правками менеджерів. За ними видно, де шаблон тримає форму, а де потрібна генерація тексту.
• Карта шаблонів — які документи випускаються, які поля підставляються автоматично, а які заповнює людина, і що відбувається за нестандартних умов угоди.
• Джерела даних — звідки приходять значення полів (облікова система, реєстр, пошта), у якому вигляді та хто відповідає за їхню актуальність.
• Вимоги до контуру — де дозволено обробляти документи, чи потрібен ізольований контур, які відомості не повинні залишати вашу інфраструктуру.
• Ролі та доступи — хто ініціює генерацію, хто погоджує, хто підписує і які права потрібні кожній ролі.
• Обсяг і потік — скільки документів на місяць і як виглядає пік, щоб оцінити навантаження та запас за швидкістю.
• Критерії приймання — на якому наборі документів вважаємо результат коректним, хто проводить перевірку і яка частка правок після генерації допустима.

Якщо частини матеріалів немає під рукою — опишіть своїми словами, решту уточнимо в розмові. Після розбору повернемося з планом робіт і оцінкою за етапами.