Як створити юридичного AI-асистента: продуктова логіка AI Lawyer

Якщо ви питаєте, як створити юридичного AI-асистента, почніть із межі: що продукту дозволено робити і що він має залишити кваліфікованому юристу. Ми побудували AI Lawyer навколо цієї лінії. Він не замінює юриста. Ніщо в цій нотатці не є юридичною консультацією, і вона не робить заяв про результати для користувачів.

Спокусливо почати розробку юридичного AI-асистента з моделі. Модель — легка частина. Натомість ця нотатка описує продуктову логіку: де AI допомагає в юридичній роботі, де він має зупинитися і що дає змогу безпечно вести такий продукт.

AI Lawyer — продукт для юридичних робочих процесів з підтримкою AI, розроблений Logics7. Він побудований навколо чотирьох робочих процесів:

• →Аналіз документів: договори, угоди та інші юридичні тексти, прочитані на предмет ризиків і відкритих питань.
• →Структуровані підказки: запитання людини, перетворене на варіанти й наступний крок.
• →Відстеження регуляцій: правила, релевантні для бізнесу чи регіону.
• →Впорядкування спорів: спір, розкладений на кроки, строки й документи.

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

Чим він не є: юристом. AI Lawyer не замінює юриста і не надає юридичних консультацій. Він готує ґрунт для рішення, яке ухвалює кваліфікований фахівець. Юридичний AI-асистент — це не юридичний чатбот із дисклеймером унизу сторінки.

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

AI-перевірка договорів і аналіз документів

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

Прийом звернень: від ситуації до структурованої підказки

Людина рідко приходить із чітко сформульованим юридичним запитанням. Вона приходить із ситуацією. Прийом звернення (client intake) означає перетворити цю ситуацію на структуроване запитання, варіанти й наступний крок. У спорі це означає чіткий набір кроків, строків і документів замість розрізненої розповіді про події.

Відстеження регуляцій і юридичні дослідження

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

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

Межа консультації

Межа — це не дисклеймер, доданий наприкінці. Вона визначає, що продукту взагалі дозволено казати. Пояснити, що означає пункт або які варіанти існують, — у межах лінії. Вирішити, який варіант людині обрати в її справі, — поза нею. У США перетин цієї лінії розглядають як незаконну юридичну практику (unauthorised practice of law); інші юрисдикції проводять її інакше. Це ще одна причина, чому юрисдикція належить до продуктової логіки, а не до дрібного шрифту.

Впевнені помилки й вигадані посилання

Мовні моделі можуть створювати текст, який звучить авторитетно і водночас є хибним, зокрема з посиланнями на справи чи норми, яких не існує. У юридичній роботі вигадане посилання — не друкарська помилка. Це хибне твердження, на основі якого людина може діяти. Юридичного AI-асистента треба проєктувати на момент, коли він не впевнений: сказати про це, показати джерело, яке людина може перевірити, і зупинитися. Перевірка посилань — частина продукту, а не завдання, залишене читачеві.

Передача кваліфікованому юристу

Останній крок належить людині. Для юристів професійні обов’язки не зупиняються, коли залучено AI: висновок ABA Formal Opinion 512 пояснює, як обов’язки на кшталт компетентності й конфіденційності застосовуються до інструментів генеративного AI. Для продукту правило просте. Система готує, структурує й пояснює; рішення лишається за кваліфікованим фахівцем. «Людина в контурі» — не функція, яку додають пізніше. Це форма самого робочого процесу.

Складна частина такого продукту — не модель. Це все, що навколо неї. Генерація з доповненням пошуком (RAG) за перевіреним набором юридичних документів — поширений патерн у розробці юридичних AI-застосунків: модель відповідає на основі знайдених джерел, які часто зберігаються у векторній базі даних, а не з пам’яті. Це звужує проблему. Але не усуває її. Хай якою є архітектура, чотири питання вирішують, чи можна вести продукт:

• →Документи: як обробляються і зберігаються чутливі документи. Юридичні документи містять конфіденційні й персональні дані, а деякі — привілейовані консультації юриста, тож конфіденційність, адвокатська таємниця та законодавство про захист даних, як-от GDPR, — проєктні обмеження з першої версії.
• →Невпевненість: як система поводиться, коли не впевнена.
• →Юрисдикція: як юрисдикція змінює відповідь. Той самий пункт може означати різне в різних правових системах.
• →Перевірка релізів: як кожен реліз перевіряють на реальних юридичних текстах, перш ніж він дійде до користувачів.

Аудиторський слід належить до того самого списку для будь-якого юридичного AI-асистента: що система прочитала, що видала і хто діяв на основі цього. Без нього ніхто не зможе постфактум відповісти за результат.

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

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

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

Logics7 будує їх як продукти, які потім веде, а не як демо. Ми не починаємо з коду. Ми починаємо з перевірки, чи має продукт ринок, користувача, готового платити, логіку монетизації і шлях до запуску. Для нового самостійного продукту це маршрут Product Partnership.

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