Marta Kowalska

Задача

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

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

Що реалізовано

• завантаження PDF, DOCX і сканованих документів;
• розпізнавання тексту та розбиття на логічні фрагменти;
• індексація документів у векторному сховищі;
• пошук релевантних уривків перед кожним запитом;
• передавання контексту до Claude;
• посилання на конкретний документ і сторінку;
• окремі режими «коротка відповідь», «ризики» та «порівняння вимог»;
• журнал запитів і відповідей;
• обмеження доступу до документів за командами.

Контроль якості

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

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

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

Операторам не потрібен був бот, який відповідає замість них. Їм потрібен був помічник, який скорочує час підготовки якісної відповіді.

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

Я підключила Claude до helpdesk-системи так, щоб модель не відправляла повідомлення клієнту самостійно. Вона аналізувала звернення, визначала тему, знаходила релевантні інструкції та готувала чернетку відповіді для оператора.

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

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

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

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

ДО

Юристи отримували договори у різних форматах і вручну перевіряли їх за внутрішнім чеклістом:

«сторони» · «строки» · «відповідальність» · «оплата» · «розірвання» · «конфіденційність»

Процес був передбачуваним, але займав багато часу.

ПІСЛЯ

Створено внутрішній інструмент, який:

1. приймає документ;
2. виділяє текст і структуру;
3. визначає тип договору;
4. запускає відповідний набір перевірок;
5. формує структурований JSON-результат;
6. показує потенційні ризики юристу;
7. зберігає коментарі та фінальне рішення.

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

Особливі правила

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

Для команди підготувала шаблони промптів, тестовий набір договорів і журнал помилок. Це дозволило не просто запустити AI-інструмент, а поступово покращувати його на реальних прикладах.

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