Розробка ШІ для комплаєнсу: де ламається ручний аудит
Нормативна база оновлюється швидше, ніж служба комплаєнсу встигає її прочитати. Поправка набуває чинності, а чек-лист перевірки — ні: аудитор іде за попередньою редакцією, бо нову ще не розібрали по пунктах.
Чим більше юрисдикцій і внутрішніх регламентів, тим ширший розрив, і людьми він не закривається — штат зростає лінійно, а обсяг вимог — швидше.
Ціна розриву видна у двох місцях. Перше — пропущені порушення: перевірку формально пройдено, невідповідність залишилася в документі й випливає вже на зовнішньому аудиті.
Друге — різні рішення за однакових випадків: два фахівці читають одну норму й тлумачать її по-різному, бо єдиного джерела правди немає, а попередні тлумачення ніде не зафіксовані.
Система на основі пошуку за змістом прибирає обидва перекоси. Нормативка нарізається на фрагменти з прив’язкою до номера пункту, кожен фрагмент отримує векторне представлення й метадані: редакція, дата набуття чинності, сфера застосування.
Під час оновлення документа переіндексується лише змінений розділ — відповідь завжди посилається на конкретний пункт чинної редакції, і аудитор бачить підставу рішення, а не переказ.
Окремий контур — контроль змін нормативів: джерела обходяться за розкладом, нова редакція порівнюється з попередньою, зміни потрапляють у чергу на переіндексацію, а застарілі фрагменти позначаються недійсними й залишаються в історії — правочини минулих періодів усе одно перевіряються за старими редакціями. Далі розбираємо, як це закривається.
Ефекти автоматизації: швидкість реакції та повнота перевірок
П’ять ефектів, які видно вже в перші місяці роботи системи, варто рахувати на історичних даних замовника: скільки часу йшло на розбір однієї зміни вимоги, яка частка документів реально доходила до експерта й як часто те саме питання вирішувалося по-різному.
- Вікно реакції на зміну вимоги — з тижнів до годин: система стежить за зовнішніми джерелами на кшталт КонсультантПлюс і внутрішніми регламентами, позначає зачеплені документи й віддає їх на перегляд.
- Повнота перевірок перестає залежати від запасу часу: у первинний розбір потрапляє весь масив документів, а не вибірка, яку встигли переглянути очима. Пункти, що випали, видно окремим звітом.
- Відтворюваність рішень: той самий вхід дає той самий висновок із посиланням на конкретний пункт вимоги. Спір «чому так» знімається цитатою з першоджерела, а не пам’яттю перевіряльника.
- Зменшення ручної роботи: звірку редакцій і розбір однотипних блоків забирає автоматика, експерту залишаються межові випадки й спірні тлумачення, де потрібна кваліфікація.
- Усунений клас відмов: перевірка за застарілою редакцією, пропущене оновлення норми, рішення без обґрунтування — ці збої перестають бути можливими на рівні процесу, а не пильності співробітника.
Кожен пункт рахуємо на тих самих даних, що були до впровадження, — інакше це враження, а не ефект. Якщо метрика не рухається, розбираємо причину й змінюємо правила відбору.
Режими роботи системи перевірки: порівняння підходів
Режим перевірки визначає, що саме потрапить у вердикт і як швидко система почне помилятися на нестандартному договорі. У роботі ми використовуємо три варіанти — вони не замінюють одне одного, а закривають різні класи дефектів.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Правила та ключові слова | Регламент формалізовано: терміни, реквізити, обов’язкові пункти, заборонені формулювання | Ламається на перефразуваннях; кожна нова вимога — окреме правило й повторний прогін усього набору перевірок |
| Пошук по базі знань з опорою на джерела | Потрібна перевірка змісту: обсяг відповідальності, запевнення, порядок оплати, умови розірвання | Працює рівно настільки, наскільки повно й розмічено зібрання внутрішніх регламентів і прецедентів |
| Гібридний підхід | Договір змішаний: жорсткі поля та смислові блоки в одному документі | Дорожче в налаштуванні: два контури перевірки й спільний шар, який зводить їхні вердикти без суперечностей |
Чому в робочому контурі частіше залишається гібрид
Правила відсікають формальні дефекти на першому проході, а пошук по базі знань розбирає смислові блоки — при цьому кожен висновок підкріплено посиланням на пункт регламенту або на прецедент. Перевірка договорів перестає залежати від того, чи пам’ятає юрист конкретну вимогу.
Обмеження підходу спільне для всіх трьох режимів: якість бази знань. Якщо регламенти не зібрані, не розбиті на фрагменти й не пов’язані з джерелами, система видає впевнені формулювання без опори — і такий вердикт небезпечніший, ніж його відсутність.
Етапи впровадження: від розбору норм до передачі в експлуатацію
Порядок робіт улаштовано так, щоб кожен крок спирався на перевірний артефакт попереднього — норму, розмічений приклад або метрику. Тому на будь-якому етапі видно, де якість зростає, а де впирається в повноту вихідних документів.
-
Розбір вимог. Збираємо регламенти, внутрішні політики та минулі приписи, розбираємо їх на перевірні твердження. Окремо позначаємо норми, які формалізуються правилом, і оцінні, де рішення залишається за людиною.
-
Розмітка корпусу документів. Формуємо еталонні пари «фрагмент — вердикт аудитора», включно з межовими випадками й розбіжностями тлумачень. Набір стає мірою якості рішення й базою для майбутніх перевірок.
-
Схема обробки. Визначаємо, як документ ділиться на смислові блоки зі збереженням нумерації пунктів, як шукається відповідь і як до кожного висновку додається посилання на норму та версію документа.
-
Налаштування перевірок. Правила, пороги впевненості й чергу на ручний розбір налаштовуємо під навантаження відділу: типові спрацювання закриваються автоматично, спірні йдуть аудитору з готовою вижимкою.
-
Приймання на історичних перевірках. Проганяємо систему по завершених справах і звіряємо з рішеннями аудиторів: повнота знахідок, частка хибних спрацювань, час на одну перевірку.
-
Передача та навчання. Віддаємо регламент оновлення корпусу, інструкції для аудиторів і порядок розбору помилок; команду замовника вчимо додавати нові норми й правила самостійно.
Що передаємо на руки: конфігурації, регламенти, документація
Систему не віддаємо як чорний ящик: разом із рішенням передаємо комплект документації, за яким ваша команда зможе експлуатувати й розвивати її без нас. Перелік фіксується в акті передачі — у кожного пункту є власник і точка входу в інтерфейсі.
- Конфігурації перевірок — правила звірки документів і операцій з вимогами регулятора: джерело норми, пріоритет спрацювання, порядок зміни.
- Схеми даних — які джерела підключено, які поля звідки беруться, як пов’язані сутності й де проходить межа відповідальності між системами.
- Правила доступу до даних — ролі та групи, розмежування за розділами бази знань, порядок надання й відкликання прав, режим роботи з чутливими фрагментами.
- Регламент оновлення бази знань — хто завантажує нові редакції, як фіксується дата актуальності, що відбувається зі старими версіями документів.
- Журналювання рішень — за кожною відповіддю зберігаються використані фрагменти, версія правил і час, щоб перевіряльник міг відновити хід міркування.
- Інструкції для команди — сценарії типових операцій: додавання джерела, розбір спірного спрацювання, відкат правила, передача збою на розбір.
- Карта системи та порядок супроводу — схема компонентів, точки контролю, відповідальні й план робіт після запуску.
Комплект ведеться як живий документ: правки конфігурацій і правил доступу проходять через ту саму процедуру погодження, що й зміни системи, тому описи не розходяться з фактичним станом.
Кейс: перевірка договорів і внутрішніх регламентів
Як виглядала робота до
Юридичний відділ погоджував партію з 400 договорів поставки. Три юристи читали тексти паралельно й звіряли кожен із внутрішніми регламентами та типовими умовами: на партію йшло близько трьох тижнів, а розбіжності між перевіряльниками сягали 18% зауважень.
Один фахівець пропускав пункт, інший його знаходив, сторони знову сперечалися про тлумачення, частина зауважень дублювалася, частина губилася в листуванні.
Що змінили
Зібрали базу знань із внутрішніх регламентів, типових формулювань і розібраних прецедентів.
Реєстр договорів став джерелом, на яке посилається кожна видача: система відповідає не вільним переказом, а фрагментом регламенту з номером пункту — перевіряльник бачить підставу зауваження, а не припущення.
Зверху поставили моніторинг змін: після нової редакції регламенту пошуковий індекс перебудовується, застарілі фрагменти позначаються як нечинні, посилання на скасований пункт у видачі не з’являється.
Що стало з метриками
Та сама партія з 400 договорів проходить перевірку за два дні замість трьох тижнів. Частка розбіжностей між перевіряльниками знизилася з 18% до 4%: спірні пункти позначаються однаково, а розбір іде лише за справді неоднозначними умовами.
Покриття — 100% пунктів замість ручної вибірки, при цьому юрист витрачає час на 10–15 спірних місць, а не на читання документа цілком.
Чим відрізняється пошук по базі знань від правил на ключових словах?
Правила на ключових словах передбачувані: спрацювання на відому формулювання відтворюється один в один, його легко пояснити перевіряльнику й захистити на аудиті.
Ламається все на варіативності мови: «ми зобов’язані зберігати й обробляти дані» та «інформація обробляється за згодою суб’єкта» — одна вимога, але жодне правило її не зловить, зате заперечення й омонімія дають хибні спрацювання.
Пошук по базі знань улаштований інакше: документ нарізається на фрагменти, кожен отримує векторне представлення, і запит зіставляється за змістом, а не за літерами. Так витягуються перефразування й синоніми з GDPR і внутрішніх регламентів.
Плата — ризик правдоподібної, але не підтвердженої відповіді, тому в аудиті обов’язкове повернення дослівної цитати й посилання на фрагмент.
| Механізм | Що знаходить | Де ламається |
|---|---|---|
| Правила на ключових словах | Відомі формулювання, точний збіг | Перефразування, заперечення, розриви фраз |
| Семантичний пошук за фрагментами | Смислові збіги, синоніми | Потрібен поріг впевненості й цитата |
| Гібрид: правила як фільтр + пошук | Перефразування всередині релевантного набору | Складніше налаштовувати пороги |
На практиці механізми комбінуються: правила звужують область пошуку, семантичний шар добирає перефразування, а кожна відповідь має містити дослівний фрагмент і його місце в документі.
Якщо цитата не підтверджується, відповідь не показується, а фрагмент іде на ручну перевірку — точність важливіша за повноту.
Технічні сумніви, які знімаємо до старту
Сумніви щодо таких систем передбачувані, і в розробці ШІ для комплаєнсу ми знімаємо їх до старту, а не в процесі впровадження. Нижче — те, що найчастіше перевіряють на етапі оцінки.
Система зможе працювати в закритому контурі?
Так, це штатний режим, а не доопрацювання під проєкт. Модель, пошуковий індекс і сховище ембеддингів залишаються всередині периметра, назовні йде лише телеметрія — на ваш вибір.
Доступи розмежовуємо за ролями, запити й видачу логуємо, тому безпека даних підтверджується журналом, а не обіцянкою.
Звідки гарантія, що система не вигадує норми?
Контроль якості відповідей будується на витягнутих фрагментах: кожен пункт супроводжується посиланням на джерело з датою редакції. Якщо близькість нижча за поріг, система повертає «немає даних», а не правдоподібну здогадку. Частку влучань у джерело й коректних відмов рахуємо на вашому корпусі.
Нормативка змінюється — що з індексом?
Переіндексація запускається за розкладом або за подією: нова редакція стає в базу, попередня зберігається як версія. Відповідь відтворюється на дату — саме це й перевіряє аудит.
Скільки даних потрібно для оцінки?
Для пілота достатньо одного тематичного блоку й 30–50 реальних питань з еталонними відповідями. Цього досить, щоб виміряти точність пошуку й зрозуміти, чи потрібне доналаштування моделі.
Що з відповідальністю після передачі?
Передаємо конфігурації, схему індексації, регламент оновлення й набір перевірок із документацією. Далі — супровід або підтримка вашої команди за погодженим регламентом.
Обговоримо задачу: що потрібно для оцінки та плану робіт
Чим конкретніші вихідні дані, тим менше припущень в оцінці проєкту й тим точніший план робіт. Нижче — мінімальний набір, який знімає 80% невизначеності й дозволяє рахувати терміни за реальним обсягом, а не за вилкою. Якщо частини пунктів немає — не страшно, зафіксуємо їх як припущення й перевіримо на першому етапі.
- Приклади документів — регламенти, політики, інструкції та заповнені чек-листи в тому вигляді, у якому вони живуть: скани, таблиці, листи, вивантаження із внутрішніх систем.
- Перелік вимог — внутрішні норми та зовнішні правила, яким зобов’язані відповідати, з позначкою, які з них жорсткі, а які допускають тлумачення.
- Поточний порядок перевірки — хто й на якому етапі звіряє документи, що фіксує, скільки часу йде і де найчастіше губляться невідповідності.
- Обмеження щодо контуру — де допустимо розміщувати дані, чи можна звертатися до зовнішніх сервісів, які вимоги до журналювання доступів і зберігання копій.
- Ролі перевіряльників — хто відповідає за тлумачення вимог, хто затверджує висновок, хто розбирає спірні випадки й як вирішується конфлікт між перевіряльником і власником процесу.
- Історія перевірок — повторювані зауваження за кілька періодів: вони показують, які ділянки дають основний обсяг ручної роботи.
- Системи-джерела — де лежать документи, як часто оновлюються й хто володіє кожним сховищем.
- Критерій готовності — що вважається успішним результатом, кому й у якому вигляді потрібен звіт і як швидко після зміни вимоги він має оновлюватися.
За цим набором ми повертаємося з оцінкою та планом: етапами, складом робіт, точками контролю й тим, що знадобиться від вашої сторони на кожному з них.
