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

Автоматизація документів у компанії зазвичай починається з рахунків і актів. Але найдорожчі помилки ховаються в договорах. Менеджер із закупівель підписує черговий договір поставки. Шаблон знайомий, документ схожий на десятки попередніх. Тільки в пункті 8.3 контрагент тихо замінив «відповідальність за затримку настає через 30 днів» на «через 3 дні». Через кілька місяців приходить претензія, і ніхто не може пояснити, коли саме змінилася ця умова.

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

Стаття для власників і операційних директорів компаній на 5–100 людей, які підписують від кількох до сотні договорів на місяць і не мають окремого договірного відділу. Це виробництво під замовлення, будівництво й монтаж, постачання, сервіс. Розберемо три завдання, які ШІ вже закриває: пошук ризикових умов, контроль відхилень від шаблону і відстеження строків. Покажемо чекліст ризиків, порядок запуску за два тижні, розрахунок окупності й чесні обмеження.

Коротко

ШІ — перший рівень перевірки, а не юрист. Він знаходить і позначає ризики з цитатою пункту, рішення ухвалює людина.
Текстові правки шукає звичайне порівняння, а ШІ пояснює їхній зміст. Так менше пропусків і вигаданих «відхилень».
Дати витягує ШІ, а рахує формула. «За 60 днів до закінчення» стає конкретною датою і задачею з відповідальним.
Найшвидший ефект дає реєстр строків із нагадуваннями. Його можна запустити за кілька днів, навіть без аналізу тексту.
Договір працює, коли він пов’язаний із клієнтом, замовленням і оплатами. Окремий «аналізатор PDF» без зв’язку з процесом швидко закидають.

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

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

Масштаб проблеми видно з міжнародних даних. За дослідженням World Commerce & Contracting (серпень 2025), середня компанія щороку втрачає майже 9% вартості через слабке управління договорами. Найкращі втрачають близько 3%, найгірші — 15% і більше. Дані про договори там у середньому розкидані по 24 різних системах (WorldCC). Вибірка міжнародна і переважно з великих компаній, тож для українського бізнесу на 30 людей це орієнтир, а не прогноз.

Три провали ручної перевірки

Втома і звичка. На сьомому схожому договорі за день око перестає чіпляти зміну одного слова. Найнебезпечніші правки маленькі: «календарних» на «робочих», «30» на «3», «за погодженням сторін» на «на розсуд Постачальника».

Немає еталона для порівняння. «Наш шаблон» часто живе в голові юриста або в п’яти файлах з назвами на кшталт «договір_фінал_2». Звіряти з таким еталоном неможливо. Коли юрист змінюється, знання зникає разом із ним.

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

Скільки коштує ручна перевірка: як порахувати

Формула проста: вартість години юриста × години на один договір × кількість договорів на місяць. Вартість години — місячні витрати на юриста разом з ЄСВ, поділені на робочі години.

Приклад на відкритих даних. Медіана зарплати у вакансіях юриста в Києві на жовтень 2026 року — 38 000 грн (Work.ua). Додаємо ЄСВ роботодавця 22% (Закон № 2464-VI) і отримуємо 46 360 грн. Ділимо на 168 робочих годин: близько 276 грн за годину.

Далі години. Припустімо, компанія підписує 40 договорів на місяць. Половина стандартні, на кожен юрист витрачає годину. Друга половина з правками контрагента, по 2,5 години. Разом 70 годин, або близько 19 300 грн на місяць за ставкою з Work.ua. Це приклад із припущеннями, а не норма. Заміряйте свої години на 10 реальних договорах, а не оцінюйте «на око».

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

Що буває, коли договорів стає вдвічі більше

Компанія росте: новий напрям, великий клієнт, нові постачальники. Договорів стає вдвічі більше, і в керівника чотири варіанти.

Ще один юрист. Пошук і адаптація займають місяці, а навантаження приходить зараз.
Юрист читає швидше. Падає якість, і змінений пункт 8.3 проходить непоміченим.
Частину віддають менеджерам. Менеджер не юрист і підписує те, що «виглядає нормально».
Перший рівень перевірки автоматизують. Система читає все, юрист — лише позначене. Про цей варіант і йдеться далі.

Автоматизація документів для договорів: що саме робить система

Під автоматизацією договорів часто розуміють «завантажив PDF — отримав висновок». Насправді це п’ять окремих завдань. Їх варто розділяти, бо кожне вирішується своїм інструментом і має свого відповідального.

Завдання	Що робить система	Що лишається людині
Витяг даних	Сторони, ЄДРПОУ, сума, порядок оплати, строки, штрафи, умови пролонгації переносить у картку договору	Перевірити поля на перших договорах
Перевірка за чеклістом	Позначає пункти, що суперечать вашим правилам, з дослівною цитатою	Вирішити, погоджуватися чи ні
Порівняння з шаблоном	Знаходить усі правки контрагента й групує їх за типами	Домовитися щодо критичних
Контроль строків	Рахує дати, створює задачі, нагадує в Telegram	Діяти до дедлайну
Формування документів	Підставляє реквізити клієнта, готує рахунок, акт, накладну в PDF	Підписати КЕП

Що робить ШІ, а що — звичайні правила

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

Порівняння тексту робить алгоритм. Той самий принцип, що в режимі «Порівняти» у Word: він знаходить кожну зміну до слова і нічого не вигадує. ШІ отримує вже знайдені правки і пояснює, що змінилося по суті.
Дати знаходить ШІ. Формулювання бувають різні: «протягом дев’яноста календарних днів», «не пізніше ніж за два місяці до закінчення строку». Регулярний вираз таке не зловить, а модель зловить.
Дату рахує формула. Віднімати дні від дати закінчення має код, а не модель. Модель може помилитися в календарній арифметиці, формула — ні.
Ризик класифікує ШІ за вашим чеклістом. Кожна позначка — з дослівною цитатою пункту. Система автоматично перевіряє, що така цитата справді є в тексті. Якщо немає, позначка йде з приміткою «перевірити вручну».
Рішення ухвалює людина. Погодити, повернути з правками чи відмовитися.

Так само влаштовані наші системи управління: ШІ розбирає текст заявок і документів, а ціну рахують формули. Числа й дати мають бути детермінованими.

Чекліст ризиків: що ШІ шукає в договорі

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

Фінансові умови

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

Операційні умови

Строки реакції чи виконання коротші, ніж ви реально здатні дотримати.
Одностороннє право контрагента розірвати договір без компенсації.
Ексклюзивність, яка блокує роботу з іншими клієнтами чи постачальниками.
Приймання робіт «мовчазною згодою», якщо ви не відповіли за кілька днів.
Необмежені правки й переробки.

Останній пункт ми перевірили на собі. Наша компанія з виробництва на верстатах з ЧПК у перші тижні роботи системи управління побачила замовлення, програне через безкоштовні візуалізації без обмежень. Висновок — передоплата й ліміт правок. Такі уроки варто одразу вносити і в шаблон, і в чекліст: якщо в договорі немає ліміту правок, система позначає це як ризик.

Юрисдикція, право і спори

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

Українська специфіка, яку варто додати

Позовна давність. Загальна — три роки, але до вимог про стягнення неустойки (штрафу, пені) застосовують один рік (ЦК України, ст. 257 і 258). Тобто реєстр має відстежувати не лише ваші обов’язки, а й ваші права: до якої дати ви ще можете стягнути пеню з постачальника.
Продовження оренди. Якщо орендар користується майном після закінчення строку, а орендодавець протягом місяця не заперечив, договір вважається поновленим на той самий строк. Про намір скористатися переважним правом на новий строк треба повідомити до спливу строку договору, у строк, який у ньому встановлено (ЦК України, ст. 764 і 777). Обидві дати — в реєстр.
Перевірка контрагента. Перед підписанням перевірте компанію за ЄДРПОУ: YouControl чи Опендатабот показують зміни в реєстрі, судові справи й санкції. Система може підтягувати ці дані в картку через API сервісу, якщо у вас є до нього доступ.
Підпис. Більшість B2B-договорів підписують КЕП, наприклад у Вчасно чи через Дія.Підпис. Перевірка має відбутися до підпису, а підписаний файл — потрапити в картку договору.
Реквізити. ЄДРПОУ, ІПН і IBAN у тексті мають збігатися з реквізитами в картці клієнта. Розбіжність в IBAN — завжди «критично», навіть якщо решта договору чиста.

Що має бути у звіті

Звіт корисний, коли юрист читає його за хвилини, а не перечитує договір. Формат одного рядка: пункт, дослівна цитата, категорія, рівень (критично, уточнити, прийнятно), що запропонувати контрагенту. Приклад рядка, вигаданий для ілюстрації:

П. 8.3. «Відповідальність Покупця за затримку настає через 3 дні». Категорія: строки. Рівень: критично. У вашому шаблоні — 30 днів. Пропозиція: повернути 30 днів або обмежити розмір пені.

Звіт починається з критичних пунктів, далі «уточнити», наприкінці — список прийнятних, згорнутий. Якщо критичних немає, це видно з першого рядка.

Відхилення від шаблону: як знайти всі правки контрагента

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

Чотири типи відхилень

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

Як це працює покроково

Юрист затверджує еталон кожного типу договору з номером версії й датою.
Отриманий файл (DOCX або PDF з текстовим шаром) потрапляє в картку договору.
Система порівнює текст з еталоном потрібної версії і знаходить усі зміни до слова.
ШІ групує зміни за чотирма типами й пояснює критичні простою мовою.
Юрист дивиться критичні й додані пункти, редакційні проглядає списком.
Рішення («погоджуємо», «повертаємо з правками») і коментар фіксуються в картці. Наступного разу з цим контрагентом видно, на що він уже погоджувався.

Типові помилки

Порівнюють зі старою версією шаблону. Еталон без версії дає хибні «відхилення» і пропускає справжні. У нашому проєкті одного разу оновлення зі старої копії затерло свіжий модуль, і його відновлювали вручну. Звідси правило і для коду, і для шаблонів: версії й резервні копії з першого дня.
Скан замість тексту. Без текстового шару порівнювати нічого. Спершу розпізнавання тексту (OCR), потім вибіркова перевірка цифр і дат людиною.
Додатки окремо. Специфікація, графік поставки чи регламент послуг часто змінюють основний текст. Завантажуйте пакет цілком.
Перевіряють лише нове. Видалене небезпечніше за додане: зникле обмеження відповідальності в тексті вже не видно.
Немає історії переговорів. Якщо не фіксувати, які правки ви вже приймали, кожен новий договір з тим самим контрагентом перевіряють з нуля.

Контроль строків: дедлайни, пролонгація і претензії

Договір містить багато дат: строк дії, повідомлення про продовження, оплати, поставки, відповіді на претензії. Пропущена дата коштує дорожче за пропущену кому. Тому реєстр строків — перше, що варто автоматизувати.

Які дати витягувати

Дата	Як її пишуть у договорі	Що робить система
Закінчення строку дії	«діє до 31.12.2026»	Задача заздалегідь: продовжуємо чи ні
Повідомлення про продовження	«не пізніше ніж за 60 днів до закінчення»	Рахує дату, нагадує відповідальному
Автоматична пролонгація	«якщо жодна сторона не заявить про припинення»	Нагадує про останній день для відмови
Оплата	«протягом 10 банківських днів з дати накладної»	Задача після події «накладну підписано»
Претензія	«відповідь протягом 5 днів з дня отримання»	Задача з дедлайном у день отримання
Ваші права	неустойка, гарантія, рекламація	Дата, до якої ще можна заявити вимогу

Як рахувати дату: формула, а не ШІ

Тип днів. Календарні, робочі й банківські дні — різні дати. Формула рахує за календарем, який затвердив юрист. ШІ лише визначає, який тип днів написано в договорі.
Строки від події. «З дня отримання товару» — такої дати в договорі немає. Система створює поле «дата отримання», і дедлайн потрапляє в реєстр, щойно подію зафіксували в картці.
Цифри словами. «Дев’яносто днів» і «90 днів» — одне й те саме. ШІ розпізнає обидва варіанти, але перші 20 договорів людина перевіряє вибірково.
Кілька дат в одному пункті. «Поставка партіями щомісяця до 5 числа» — це серія задач, а не одна дата.

Нагадування і відповідальні

У кожної дати є конкретний відповідальний, а не «юрист загалом». Ми рекомендуємо нагадування за 30, 14, 7 і 3 дні в Telegram. Якщо відповідальний не підтвердив дію за 3 дні до строку, повідомлення отримує керівник.

Приклад повідомлення: «Договір № 123 з ТОВ “Партнер”: за 14 днів спливає строк повідомлення про продовження оренди. Останній день — 20 листопада. Дія: надіслати лист орендодавцю». Номер, компанія і дата тут умовні.

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

Де ШІ помиляється: чесні обмеження

Маркетингові матеріали вендорів про це зазвичай мовчать. Ось що варто знати до запуску.

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

Перехресні посилання. Пункт 5.3 посилається на Додаток А, а Додаток А — на окремий регламент. Якщо завантажити лише основний текст, модель не збере повний контекст і пропустить ризик.

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

Вигадані пункти. Модель інколи посилається на пункт, якого в договорі немає, або переказує його неточно. Захист — обов’язкова дослівна цитата і автоматична перевірка, що цитата є в тексті.

Оцінка в контексті вашого бізнесу. ШІ бачить, що 3 дні на відповідь коротше за звичну практику. Але чи це ризик для вас, залежить від вашої операційної моделі. Без чекліста під ваш бізнес модель оцінює «в середньому по ринку».

Висновок практичний: ШІ — перший рівень перевірки, який знімає з юриста читання і звірку. Фінальне рішення щодо нестандартних умов лишається за людиною.

Три рівні автоматизації: від ручного тесту до системи

Рівень 1. Разова перевірка в чат-боті

Найпростіший старт — без інтеграцій. Відкрийте ChatGPT, Claude чи Gemini на бізнес-тарифі, завантажте договір і дайте чітке завдання. Приклад запиту:

Ти перевіряєш договір поставки на боці покупця. Знайди: (а) умови, де наша відповідальність вища, ніж у постачальника; (б) усі дати й строки з номером пункту; (в) умови, яких зазвичай немає в договорі поставки. Для кожної знахідки дай дослівну цитату і рівень: критично, уточнити, прийнятно.

Обмеження: усе вручну, результат ніде не зберігається, реєстру строків немає. Підходить, щоб за 20 хвилин побачити, що ШІ знаходить у ваших договорах і де помиляється. Добре працює, коли договорів кілька на місяць.

Рівень 2. Сценарій у конструкторі автоматизацій

Наступний крок — сценарій у n8n чи Make. Менеджер кладе файл у папку на Google Drive. Сценарій витягує текст, надсилає його моделі з чеклістом, форматує звіт і відправляє в Telegram. Паралельно ключові дати записуються в Google Sheets, а щоранку інший сценарій перевіряє таблицю й надсилає нагадування. Як вибрати конструктор, розібрано в порівнянні Make, n8n або Zapier.

Обмеження теж є. Звіт живе окремо від клієнта, замовлення й оплат. Історію рішень по контрагенту ніхто не веде. А коли сценарій мовчки ламається, це помічають не одразу. Підходить для регулярного потоку договорів одного типу, якщо є людина, яка розуміє конструктор і стежить за ним.

Рівень 3. Договір усередині системи управління бізнесом

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

Картка договору прив’язана до клієнта й замовлення. Реквізити беруться з картки клієнта, тож розбіжність в IBAN чи ЄДРПОУ видно одразу.
ШІ читає договір після завантаження. Він переносить ключові умови в картку, позначає ризики за вашим чеклістом і правки відносно шаблону.
Строки стають задачами. Кожна дата — задача з відповідальним і нагадуванням у Telegram.
«Ворота» перед запуском у роботу. У нашій системі для виробництва на верстатах з ЧПК відкриті питання до клієнта позначаються на картці, і система попереджає, якщо таке замовлення намагаються перевести у виробництво. Попереджає, а не блокує. Так само можна попереджати, якщо договір не підписано або критичні зауваження не закрито.
Документи з тієї самої картки. Рахунок, видаткова накладна, акт, комерційна пропозиція формуються в PDF з тих самих даних.
Ролі. Менеджер бачить свої договори, юрист — усі, власник — зведення по ризиках і строках.

Як така система з’явилася в нас самих і що вона показала в перші тижні, описано у кейсі власної системи управління. Перша робоча версія — за кілька днів, уся система — 2–4 тижні після опису процесу.

Порівняння рівнів

	Разова перевірка	Сценарій у конструкторі	Система управління бізнесом	Готова договірна платформа
Коли підходить	Кілька договорів на місяць	Регулярний потік одного типу	Договір — етап замовлення	Є юрвідділ, потрібні правові бази
Реєстр строків	Немає	Таблиця	Картки, задачі, нагадування	Є
Зв’язок із замовленням і оплатами	Немає	Частково	Повний	Залежить від інтеграцій
Налаштування під ваш чекліст	Запит щоразу	Висока гнучкість	Висока гнучкість	В межах платформи
Хто підтримує	Користувач	Людина, що знає конструктор	Розробник системи	Постачальник платформи

Готова платформа чи своя система: як вибрати

В Україні є готові рішення для договірної роботи. Найвідоміше — LIGA360 Contractum від ЛІГА:ЗАКОН. За описом самого розробника, система аналізує ризики з урахуванням законодавства й судової практики, перевіряє контрагентів на банкрутство, санкції й судові рішення, перевіряє суми, платежі й штрафні санкції, а також формально перевіряє текст: нумерацію, реквізити, дати. Є таймлайн із датами для моніторингу, бібліотека шаблонів українською й англійською та розпізнавання понад 40 типів договорів (ЮРЛІГА, 2023). Це матеріал вендора, тож функції й ціни уточнюйте на демо.

Критерії вибору:

Є юрист або юрвідділ, якому потрібні законодавство й судова практика поруч з договором. Готова платформа закриває це краще, ніж будь-яка власна розробка.
Договори типові, а головна проблема — строки. Почніть з реєстру й нагадувань: таблиця і сценарій у конструкторі або модуль у вашій системі.
Договір — етап замовлення. Виробництво під замовлення, будівництво з субпідрядниками, постачання з графіком поставок. Тут цінність у зв’язку «договір — замовлення — оплата — акт», і власна система виграє.
Кілька договорів на місяць. Досить разової перевірки в чат-боті і таблиці строків.

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

Як запустити перевірку договорів за два тижні

Тиждень 1. Підготовка

Крок 1. Інвентаризація. Випишіть типи договорів, які ви підписуєте: поставка, послуги, підряд, NDA, агентський, оренда. Оберіть один тип для старту — найчастіший або найризикованіший. Решту додасте пізніше.

Крок 2. Еталон з версією. Юрист затверджує шаблон і ставить номер версії. Якщо шаблону немає, дайте ШІ 5–10 останніх підписаних договорів цього типу й попросіть виписати спільну структуру. Юрист перевіряє результат і затверджує його як еталон.

Крок 3. Чекліст ризиків. Юрист записує 10–20 правил з рівнями: що завжди критично, що треба уточнити, що прийнятно. Беріть за основу перелік вище і додайте уроки ваших минулих спорів.

Крок 4. Реєстр строків. Колонки: договір, контрагент, дата початку, дата закінчення, дата повідомлення про продовження, автопролонгація так чи ні, відповідальний. Активні договори ШІ розбирає пакетом, людина перевіряє кожен рядок. Нагадування вмикаються одразу. Це перший відчутний результат.

Тиждень 2. Калібрування і паралельна робота

Крок 5. Перевірка на договорах з відомою відповіддю. Візьміть 10 договорів, які юрист уже перевіряв. Прожените їх через систему і порівняйте знахідки. Так ми запускаємо й розрахунки. Перед запуском калькулятора для виробника металоконструкцій результат звірили з Excel на контрольних прикладах, і він збігся до копійки. А помилки, знайдені в самому Excel, не виправляли мовчки, а передали інженеру. З договорами так само: розбіжність між ШІ і юристом іде юристу, а не правиться в налаштуваннях без нього.

Крок 6. Уточнення чекліста. Типові проблеми першого запуску: ШІ позначає як ризик умови, нормальні для вашої галузі, і пропускає ваші специфічні критерії. Калібрування зазвичай займає кілька ітерацій. Щоразу уточнюйте правила, а не просто «перезапускайте».

Крок 7. Паралельна робота. Два тижні система працює поруч зі старим способом. Юрист перевіряє як раніше і порівнює зі звітом системи. Після цього вирішуєте, які типи договорів довіряти першому рівню.

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

Типові помилки впровадження

Усі типи договорів одразу. Калібрування розмивається, і жоден тип не доводять до ладу.
Чекліст «з інтернету». Загальні правила дають багато шуму. Потрібні ваші.
Ніхто не відповідає за реєстр. Дати застарівають за місяць.
Відповідь контрагенту генерує ШІ і її одразу надсилають. У наших системах клієнту нічого не надсилається без людини, якщо інше не погоджено окремо.

Чи окупиться: як порахувати економію і ризики

Економія часу

Продовжимо приклад із початку статті. Після запуску юрист витрачає на стандартний договір 15 хвилин замість години: дивиться лише звіт. На договір з правками — годину замість 2,5. Виходить 5 годин плюс 20 годин, разом 25 годин замість 70. За ставкою близько 276 грн з Work.ua з урахуванням ЄСВ це близько 6 900 грн замість 19 300 грн, тобто вивільнено 45 годин на місяць. Від цієї суми відніміть вартість інструменту й налаштування. Припущення щодо хвилин — ілюстрація, перевірте їх на своїх договорах.

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

Вартість пропущених умов

Час — менша частина. Дорожче коштують пропущені умови. У Harvard Business Review наводять оцінку: через неефективну договірну роботу компанії втрачають від 5% до 40% вартості окремої угоди (HBR). Ваш власний розрахунок простіший: підніміть історію за минулий рік.

Пропущені продовження. Різниця між старою і новою ставкою × кількість місяців до наступного перегляду.
Прийняті претензії. Суми, які ви сплатили, бо не відповіли вчасно або не помітили короткий строк.
Нестягнуті пені. Вимоги до постачальників, які ви не заявили. Пам’ятайте про рік позовної давності для неустойки.
Невигідні правки. Умови, які прийняли без переговорів, бо ніхто їх не помітив.

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

Коли автоматизація не окупиться

Договорів кілька на місяць. Разова перевірка в чат-боті і таблиця строків закривають потребу.
Усі підписують ваш шаблон без правок. Аналіз відхилень не потрібен, досить реєстру строків.
Немає людини, яка читає звіти. ШІ знаходить ризики, але рішення ухвалює людина. Якщо реагувати нікому, звіти накопичуються непрочитаними.
Дуже специфічні технічні договори. Складні специфікації, таблиці параметрів, посилання на зовнішні стандарти. Точність буде нижчою, потрібна складніша схема і більше ручної перевірки.

Чи безпечно передавати договори в ШІ

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

API замість особистого акаунта. За політикою OpenAI, дані, надіслані через API, не використовуються для навчання моделей, якщо ви самі не погодилися. Журнали для контролю зловживань зберігаються до 30 днів, а нульове зберігання доступне після окремого погодження (OpenAI). В особистих чат-ботах налаштування інші: перевіряйте їх або користуйтеся бізнес-тарифом.
Мінімум персональних даних. Договори з ФОП і фізичними особами містять ПІБ, паспортні дані, IBAN. Якщо для перевірки вони не потрібні, система може приховувати їх перед відправкою моделі.
Договір обробки даних. Для чутливих договорів підпишіть з постачальником моделі договір обробки даних (DPA).
Локальна модель. Для найчутливіших документів модель можна розгорнути на власному сервері. Тоді текст не залишає вашу інфраструктуру, але точність і швидкість треба перевірити окремо.
Де живе система. Нашу систему ставимо на сервер клієнта або на наш, з передачею будь-коли. Код і дані належать клієнту, резервна копія робиться щодня.

Часті питання

Чи потрібен програміст для впровадження? Для разової перевірки — ні. Для сценарію в n8n чи Make потрібна людина з досвідом конструкторів: тригери, API, обробка відповіді моделі. Для системи управління бізнесом код пише ШІ під контролем архітектора, а ваша роль — описати процес і перевірити систему на реальних договорах.

ШІ замінить юриста? Ні, і таку мету ставити не варто. ШІ знімає рутину: читання, звірку з шаблоном, пошук дат. Людина краще розуміє стосунки з контрагентом, оцінює ризик у координатах вашого бізнесу, веде переговори й ухвалює рішення.

З чого почати, якщо в нас немає шаблонів? Відберіть 5–10 типових підписаних договорів одного типу, наприклад поставки. Попросіть ШІ знайти спільні умови і скласти структуру типового договору. Юрист перевіряє й затверджує результат з номером версії. Далі він стає еталоном для порівняння. Як побудувати маршрут погодження й підписання, розібрано в статті про автоматизацію узгодження договорів.

Чи допоможе ШІ з розробкою юридичної документації для AI-компаній і стартапів? ШІ прискорює чернетки за затвердженими шаблонами: NDA, договори з підрядниками, умови використання сервісу. Але юридичні документи для ШІ-проєктів зачіпають дані, авторські права і регулювання, тож фінальну редакцію готує юрист. Якщо у вас клієнти в ЄС, перегляньте наш огляд EU AI Act для українського бізнесу. Ми юридичних послуг не надаємо. Ми автоматизуємо процес навколо документів: шаблони, заповнення реквізитів, погодження, строки.

Скільки часу займає впровадження? Разову перевірку можна спробувати сьогодні. Реєстр строків із нагадуваннями — кілька днів. Систему управління бізнесом із договорами, замовленнями й оплатами ми запускаємо так: опис процесу — тиждень, перша робоча версія — за кілька днів, уся система — 2–4 тижні.

Чи працює це зі сканами? Так, але спершу текст треба розпізнати. Після розпізнавання суми, дати й реквізити варто перевіряти вибірково, особливо в таблицях. Якщо скани поганої якості, простіше попросити в контрагента DOCX або PDF з текстовим шаром.

Якщо у вас договори з клієнтами, постачальниками чи субпідрядниками і строки тримаються на пам’яті людей, опишіть, як у вас зараз проходить договір від отримання до підпису й оплати. Покажемо систему на демо за 30 хвилин і чесно скажемо, що вам вигідніше: готова платформа, таблиця з нагадуваннями чи договори всередині вашої системи. Детальніше — ШІ-система управління бізнесом.

Автоматизація документів: як ШІ перевіряє ризики, строки й правки в договорах