Договір як дані
Асистент сьогодні читає договір цілком, оцінює його і пропонує правки. Людина збирає контекст, перевіряє висновки і відповідає за результат. Чотири фільми проходять цей шлях на одному договорі поставки; ще три показують інструменти, які асистент викликає там, де потрібна точність.
- 1Що асистент бачить у договорі
- 2Контекст збирає людина
- 3Як асистент аналізує договір
- 4Людина перевіряє і відповідає
- 5Договір це поля
- 6Похідні поля рахує машина
- 7Хто ловить помилку
- 8Від пункту до дати
- 9Матеріали заняття
- 10Блоки роботи
Що асистент бачить у договорі
Асистент читає не файл, а текст, який із цього файла дістала програма. З документа Word текст виходить зі структурою, а разом із ним правки й коментарі, якщо їх не прибрали. З PDF із текстовим шаром виходить текст, але таблиці й колонки можуть переплутатись. Скан спершу розпізнає окрема програма, і помилки найчастіше трапляються в цифрах.
Фільм. Асистент читає не файл, а текст, який із цього файла дістала програма.
Контекст збирає людина
Сам договір це мало. Запит «перевір договір» без пояснень дає загальні зауваження для обох сторін одразу. Щоб аналіз стосувався вашої справи, асистентові потрібно знати, на чиєму ви боці, навіщо угода, що погодили в листуванні і які ваші позиції. Це збирає людина або асистент із наданим доступом, але що стосується справи і що правда, вирішує людина.
Фільм. Сам договір це мало.
Як асистент аналізує договір
Сучасний асистент читає договір цілком, складає його карту, шукає суперечності й прогалини, звіряє з вашими позиціями і пропонує правки. Там, де потрібна точність, він викликає інструменти: калькулятор строків, арифметику сум, перевірку коду в реєстрі. Набір інструментів людина може розширювати, і той самий набір працює для одного договору і для тисячі.
Фільм. Сучасний асистент читає договір цілком, складає його карту, шукає суперечності й прогалини, звіряє з вашими позиціями і пропонує правки.
Людина перевіряє і відповідає
Звіт асистента виглядає завершеним, і в цьому ризик: помилки в ньому написані тим самим упевненим тоном. Перечитувати все заново не потрібно. Перевіряють чотири речі: чи кожне твердження веде до пункту, чи цифри й дати порахував інструмент, чого асистент не бачив і чи збігається другий незалежний прохід. Рішення і відповідальність лишаються за людиною.
Фільм. Звіт асистента виглядає завершеним, і в цьому ризик: помилки в ньому написані тим самим упевненим тоном.
Глибше: інструменти, які викликає асистент
Три старіші фільми показують зсередини те, що в аналізі робить машина: поля і шаблони, перевірки за правилами, розрахунок строків.
Договір це поля
Договір поставки на чотири сторінки містить кілька десятків значень: назви сторін, коди ЄДРПОУ, рахунки, ціни, кількості, строки. Решта тексту однакова в кожному договорі за тим самим шаблоном. Тому договір можна описати як набір полів і шаблон, у який ці поля вставлено.
Поля бувають чотирьох видів. Змінне поле вводять для кожної угоди. Похідне поле обчислюють з інших полів. Фіксований текст однаковий завжди. Опція це вибір між готовими варіантами пункту.
Розклади значення на види
Десять фрагментів з одного договору. Для кожного обери вид поля, потім натисни «Перевірити».
Глибше: шаблон, бібліотека пунктів, плейбук
Коли договір розкладено на поля, кожен вид поля має своє місце зберігання. Фіксовані пункти живуть у бібліотеці пунктів з версіями: змінює їх правник, і кожна зміна має дату. Опції це готові варіанти одного пункту з правилом вибору: коли брати господарський суд, коли арбітраж. Такий набір правил називають плейбуком. Змінні поля заповнюють як анкету.
Тоді новий договір це заповнена анкета плюс вибрані опції, а текст збирає шаблон. Людина перевіряє значення полів і вибір опцій, а не перечитує весь текст щоразу.
Похідні поля рахує машина
Сума рядка, разом без ПДВ, ПДВ, загальна сума, аванс і всі суми прописом обчислюються з кількості, ціни і відсотка. Коли їх рахує шаблон, вони між собою не розходяться; хибна ціна чи відсоток на вході однаково повториться в усіх. Коли людина набирає їх руками, одна правка ціни лишає старе значення в трьох інших місцях, а сторінка виглядає так само охайно.
Зміни кількість або ціну в обох режимах і подивись на перевірку під договором.
Шаблон договору
Глибше: де рахувати похідні поля
Правило одне: кожне число вводиться один раз, решта посилається на нього. Це можна зробити в Word (поля і формули в таблиці), у таблиці, з якої збирається договір, або в генераторі документів.
Суми прописом генеруються з числа окремою функцією, а не набираються. Якщо договір уже прийшов від контрагента, перевір похідні поля в зворотному напрямку: перерахуй рядки, підсумки, ПДВ, аванс і порівняй цифри з прописом.
Хто ловить помилку
Помилки в договорі ловлять три способи перевірки, і кожен ловить своє. Алгоритм перевіряє те, що має формулу: контрольну цифру коду ЄДРПОУ, контрольну суму IBAN, арифметику таблиці, цифри проти пропису, існування дати. Реєстр відповідає, чи існує компанія і чи збігаються її назва й адреса. Людина звіряє частини договору між собою і перевіряє логіку умов.
Мовна модель допомагає на кожному кроці, якщо їй сказати, що саме звіряти. На запит «перевір договір» вона відповідає впевнено, незалежно від того, що перевірила насправді. Вигляд документа нічого не каже про його зміст, тому перевірка однакова для скану, файлу Word і охайного PDF.
Перевір код або рахунок
Встав код ЄДРПОУ (8 цифр) або IBAN (починається з UA). Перевірка працює в браузері, нічого не надсилає.
Сума прописом
Глибше: як працюють контрольні цифри і як просити ШІ перевіряти
Код ЄДРПОУ має вісім цифр. Перші сім множать на вагові коефіцієнти, суму ділять на 11, остача має дорівнювати восьмій цифрі. Переставлені або пропущені цифри майже завжди ламають цю рівність.
IBAN перевіряють так: перші чотири знаки переносять у кінець, літери замінюють числами, і все число ділять на 97. Остача має бути 1. Цифри 5-10 українського IBAN це код банку.
Обидві перевірки ловлять помилку набору, але не доводять, що компанія існує або що рахунок належить стороні. Це підтверджують реєстр і довідка банку.
Запит до ШІ на перевірку працює краще, коли в ньому є перелік полів, джерело для звірки і форма результату: «Випиши всі суми цифрами і прописом у таблицю: пункт, цифри, пропис, збігаються чи ні». Модель не звертається до реєстрів сама, якщо продукт не має такого інструмента.
Від пункту до дати
Після підписання договір стає переліком зобовʼязань. Кожне має пʼять полів: хто, що, тригер, строк і тип днів. Тригер це подія, від якої рахують строк: підписання, надходження оплати, поставка, отримання вимоги.
Частину дат можна порахувати одразу. Решта чекає на подію, дату якої ще ніхто не знає, і трекер має тримати саме «чекає на подію», а не вигадану дату. Деякі зобовʼязання умовні: вони виникають, лише якщо щось сталося.
Порахуй строк
Припущення цієї вправи: банківські й робочі дні рахуються як понеділок-пʼятниця, бо під час воєнного стану святкові й неробочі дні для працівників за загальним правилом не є вихідними. Банк або договір можуть рахувати інакше. День тригера не рахується. Перевір, як рахує строк твій договір.
Глибше: як закон рахує строки
Цивільний кодекс задає загальні правила. Строк починається з наступного дня після події, з якою повʼязаний його початок (ст. 253 ЦК). Якщо останній день строку припадає на вихідний, святковий або інший неробочий день, строк закінчується в перший за ним робочий день (ч. 5 ст. 254 ЦК). Калькулятор вище переносить строк лише із суботи й неділі.
Договір може встановити інший порядок: банківські дні, робочі дні, конкретну дату. Тому тип днів записують у трекер окремим полем, а не вгадують.
Під час воєнного стану святкові й неробочі дні не є вихідними для працівників за загальним правилом (ст. 73 КЗпП не застосовується). Чи переноситься через це цивільний строк зі святкової дати, закон прямо не визначає; для такого строку перевір судову практику на дату події.
Матеріали заняття
Три договори поставки на одному шаблоні. Вони потрапили до вас різними шляхами: скан підписаного паперу, файл Word від контрагента і PDF з верстки. Перевірте кожен повністю: числа, коди, дати, імена, звʼязки між пунктами.
- Аркуш завданьPDF · 1 сторінка
- Таблиці: поля і трекер зобовʼязаньXLSX · 2 аркуші
- Самоперевірка: поля і помилки кожного договоруза паролем
Усі договори навчальні, угоди вигадані. Назви і коди реальних компаній використано лише для вправи з перевірки реєстрів. Представники сторін, довіреності й рахунки вигадані.
Блоки роботи
Порядок, у якому зручно проходити практикум. Час на кожен блок залежить від групи.
- Життєвий цикл договоруЗапит, проєкт, погодження, підписання, виконання, продовження або закриття. Де компанія втрачає гроші або час.
- Анатомія: спершу руками, потім ШІВиписати всі поля трьох договорів, потім дати те саме завдання моделі: спершу простий запит, потім свій. Звірка у три колонки: знайшли ми, знайшов ШІ, не знайшов ніхто.
- Від документа до шаблонуРозкласти договір на змінні, похідні, фіксовані поля й опції. Записати правило перевірки для кожного поля. Зібрати договір для своєї вигаданої угоди.
- Після підписанняВиписати з підписаного договору всі зобовʼязання в трекер: хто, що, тригер, строк, тип днів, дата або «чекає на подію».
- Питання до практикаТри питання від команди до людини, яка веде договори у великій компанії: що перевіряють, де зберігають поля, як не пропускають строки, що не вдалося автоматизувати.
Поняття в Toolmap
Розбори понять, на які спирається заняття.