За останній рік я почув від замовників фразу «хочемо застосунок зі штучним інтелектом» приблизно стільки ж разів, скільки до цього чув про «ще одне Uber для X». Запит за частотою став уже фоновим, а от готовність бізнесу пройти через усю реальну розробку такого продукту майже не змінилась.

У моїй практиці з п'яти бізнесів, які приходять із запитом «потрібен застосунок з AI», троє за фактом не дозрівали до фази розробки на момент першої розмови. Їм був потрібен ще один цикл Discovery, щоб переконатись, що AI взагалі вирішує їхнє завдання. Це я кажу не для того, щоб когось образити, а щоб одразу зняти ілюзію, що «давайте швидко зробимо MVP» — це план.

У цій статті я розкажу про проєкт AI Legal Mind — мобільний застосунок, у якому ШІ-агент консультує користувачів з юридичних питань, генерує договори та прогнозує ймовірність виграшу справи в суді. На прикладі цього кейсу буде видно, що за фасадом «застосунка з AI» ховається не одна, а одразу три проблемні зони, на які замовник майже ніколи не дивиться на старті: unit-економіка моделі, регуляторика та операційні ризики.

Це не презентація продукту, а інженерно-бізнесовий розбір рішень: де ми обирали між якістю й вартістю, де довелося перепроєктовувати, і які запитання я порадив би поставити будь-якому виконавцю ще до старту співпраці.

Три проблемні зони ШІ-продукту, які закладаються у бюджет ще до старту розробки: unit-економіка, регуляторика, операційні ризики.

Запит, з якого все починалось

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

Запит замовника звучав так: потрібен продукт, який зробить базову юридичну допомогу доступною масово — миттєво, цілодобово і за порядком ціни, на який погодиться фізособа.

Чому мобільний застосунок, а не вебсервіс. Тут логіка проста і добре відома кожному, хто рахував Retention у двох продуктах паралельно. Юридичне питання у користувача з’являється «тут і зараз» — у дорозі, перед підписанням, перед розмовою з контрагентом. Мобільний формат дає доступ у потрібну секунду, плюс пуш-нотифікації, плюс знайому користувачам модель підписки через App Store / Google Play. Веб таке поведінкове ядро відтворити не вміє.

Чому ШІ, а не звичайний чат-бот з LLM. На цьому місці зазвичай починаються найдорожчі помилки. Між «чат-ботом, який звертається до ChatGPT» та «AI-агентом, спеціалізованим під юридичний домен» лежить різниця в порядок величини за якістю відповідей і два порядки за вартістю розробки. Замовнику потрібен був саме другий варіант: інструмент, якому користувач може довіряти у питанні, де ціна неправильної поради — реальна, а не «не так пораду до email-листа написали».

Коли AI у продукті не потрібен. Це питання я ставлю замовнику першим, і добра половина рішень про доцільність AI приймається ще на ньому. Якщо запит користувача варіативний, контекстний, важко описується правилами, — AI працює. Якщо ж усе зводиться до десятка сценаріїв із чіткою логікою «якщо X — тоді Y», AI просто додасть рахунок від провайдера моделі без вимірюваної цінності для користувача.
Зріла команда виконавців у такій ситуації скаже прямо: «вам потрібна автоматизація, а не AI», і це коштуватиме у рази дешевше. Якщо у відповідь на бриф ви чуєте лише «так, давайте AI» без жодного уточнювального запитання, — це сигнал шукати далі.

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

Повний цикл розробки: від Discovery до релізу

Повний цикл розробки AI Legal Mind: MVP-ядро, три екосистеми, логіка AI-агента та технологічний стек.

Discovery і скоуп MVP

Перше, що команда розробки зафіксувала на Discovery, — це межі MVP. Не «що ми робимо», а «чого ми свідомо не робимо» в перші чотири місяці. Цей список зазвичай важливіший за перший: він знімає 80 % ризику, що проєкт перетвориться на нескінченне додавання фіч до моменту, коли в замовника закінчиться запал.

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

Стек і чому саме він

Опишу стек так, як його варто пояснювати замовнику — не «модно», а через ціну рішення.

  • Flutter для клієнтського застосунку. Один кодбейз під iOS і Android — це не лише економія приблизно 35–45% бюджету на мобільну частину, як порівняти з нативною розробкою двох окремих застосунків, а й значно простіша підтримка. Для продукту, де основна цінність — у бекенді й AI-агенті, а не у вишуканій нативній анімації, це очевидний вибір.
  • Nest.js для бекенду. Модульний фреймворк із сильним типуванням, який дає чисту структуру коду й передбачуваний onboarding нових інженерів. Для продукту, який житиме й розвиватиметься роками, це критично.
  • LangGraph для оркестрації AI-агента. Це не «обгортка над OpenAI», а граф станів, у якому ми розбиваємо запит користувача на кроки: класифікація галузі права → витяг сутностей із запиту → виклик профільного промпта → перевірка результату → формування відповіді з дисклеймерами. Така архітектура дозволяє контролювати якість на кожному вузлі, а не покладатися на «модель сама розбереться».
  • MongoDB і Redis. Mongo — для гнучкої схеми (юридичні документи та історії діалогів складно вкласти в реляційну модель без болю). Redis — для кешування відповідей моделі та коротких сесій діалогу. Кеш у LLM-проєктах — це не оптимізація швидкості, це інструмент управління OPEX. Про це нижче окремо.
  • AWS, Coolify, GitHub Actions, Firebase. Інфраструктурна частина зібрана з компромісів між «дешево підтримувати» і «гнучко масштабувати». Coolify закриває self-hosted частину сервісів, AWS — там, де потрібна керована масштабованість, GitHub Actions — CI/CD без додаткових ліцензій.
  • Langsmith. Окремий інструмент, без якого AI-проєкт жити не може довше за перший реліз: він дає трасування запитів до моделі, evaluation-метрики й можливість порівнювати версії промптів між собою. Якщо у виконавця цього (або аналогу) немає, питайте, як саме він міряє, що сьогодні модель відповідає краще, ніж тиждень тому.
  • RevenueCat, Brevo, OpenAI. Підписки, нотифікації й сам провайдер моделі. RevenueCat закриває головний біль мобільних білінгів і дозволяє не писати власну логіку синхронізації покупок між сторами — це місяці роботи в обмін на відсоток.

Три екосистеми в одному проєкті

З погляду менеджменту проєкту важливо розуміти: AI Legal Mind — це не «застосунок», а три окремі продукти в одному кейсі: мобільний клієнт, адмін-панель для керування AI-агентами, користувачами та статистикою, і лендинг. Кожне із цих трьох має власний цикл планування, дизайну, розробки й тестування, і всі три мають рухатися синхронно. Замовник, який цього не закладає у бюджет і терміни, в середині проєкту з подивом дізнається, що адмін-панель «забули» і її треба робити окремо.

Спеціалізація AI-агента під юриспруденцію

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

Замість того, щоб подавати запит «as is» у модель, агент проводить його через ланцюг: класифікація галузі (цивільне право, трудове, господарське, кримінальне) → вибір спеціалізованого system-промпта під цю галузь → накладання обмежень на тон і формат відповіді → фінальний фільтр, який додає обов’язкові дисклеймери. Це та сама архітектура, яку зараз називають «agentic», але без хайпу — це просто інженерна дисципліна.

Якісну різницю ми відстежували через evaluation-датасет: набір реальних типових запитів з очікуваною структурою відповіді, який проганяється після кожної зміни промпта. Без такого датасета будь-яка зміна в AI-частині — це «бачить око, та зуб неймет»: ви не знаєте, покращили ви якість чи зламали. Якщо чесно, головний урок цього стеку особисто для мене був саме тут — у момент, коли Langsmith ще не був вкручений. Перші тижні після релізу evaluation тримався «в головах команди»: «здається, краще», «здається, гірше». Закінчилося це передбачувано — ми викотили версію промпта, яка на пробних запитах виглядала чудово, а на реальному трафіку почала «галюцинувати» помітно частіше за попередню. Після цього інженерну дисципліну поставили на місце: жодна зміна агента не йде у прод без прогону через тестовий датасет. Це не «best practice з блогу» — це урок, за який платять живими користувачами.

Технічні та юридичні труднощі

Три виклики у роботі з держреєстрами та чутливими даними і три інженерні відповіді: захист даних, стабільність API, AI-якість.

Інтеграція з Дією та державними реєстрами

Це блок, у якому всі терміни треба було перерахувати щонайменше двічі. Робота з державними сервісами — це не звичайна інтеграція через REST API, а одразу три окремі проблеми, що накладаються.

Юридичні бар’єри доступу. Не до всіх реєстрів можна звернутися «просто з продукту». Деякі вимагають окремих угод про обробку даних, окремої верифікації запитувача, окремих юридичних підстав для конкретного типу запиту. Це не інженерна задача, це юридична робота, яку замовник часто хоче закласти у терміни розробки і яка реально займає окремий, паралельний пайплайн на тижні-місяці.

Захист персональних даних. Усе, що проходить через продукт і дотикається держреєстрів, — це чутливі дані за визначенням. Це означає шифрування в спокої й у транзиті, контрольовану ротацію ключів, обмеження логів (включно з логами для дебагу), окремі ролі доступу всередині команди, окрему процедуру обробки запитів користувачів на видалення даних. Цей шар треба проєктувати в перший тиждень, а не «прикрутити перед релізом».

Стабільність державних API. Це окрема дисципліна: ви не можете розраховувати на ті ж SLA, що від комерційних провайдерів. Архітектурно це закладається через черги, ретраї з експоненційним бекофом, дегрейдешн до кешованих даних, окрему сторінку статусу інтеграцій для команди підтримки. Замовнику, який каже «ну це ж стандартна інтеграція», варто показати реальну статистику доступності цих сервісів за останні півроку — і це швидко знімає питання, чому «стандартна» інтеграція коштує стільки.

Галюцинації AI у домені, де помилка дорога

Модель, що «вигадує» статтю закону, якої не існує, або плутає редакції, — це не баг, це характеристика технології. Уникнути на 100 % неможливо; завдання — знизити ймовірність і зробити так, щоб користувач у будь-якому випадку розумів, що перед ним AI-довідка, а не консультація адвоката. І тут я свідомо не погоджуся з популярною думкою, що галюцинації «вирішаться самі з наступним поколінням моделей».

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

Інструменти, які реально працюють:

  1. Спеціалізований агент з вузьким system-промптом замість «загальної» моделі.
  2. Двоступенева перевірка: модель сама формулює відповідь, окремий валідаторний промпт перевіряє наявність обов’язкових елементів (посилання на норму, дисклеймер, обмеження сфери).
  3. Постійний моніторинг через Langsmith — видно, де модель частіше «з’їжджає», і точково підкручуються промпти.
  4. UI-шар: чіткі дисклеймери у форматі, який не можна пропустити очима. Це не юридична формальність, це елемент продукту.

Відповідальність: де AI закінчується, а юрист починається

У продукті закладено простий принцип: AI Legal Mind не замінює юриста, а зменшує кількість випадків, у яких користувач взагалі не звернеться по консультацію. Це лінія, за якою будуються і UI, і tone of voice, і навіть структура відповідей. У кінці кожної серйозної відповіді з’являється рекомендація звернутися до спеціаліста для конкретної ситуації.

Це не «розмивання відповідальності», а чесне продуктове рішення: AI у юридичному домені — це інструмент для розуміння й рішення, чи потрібен юрист, а не його заміна.

Безпека чутливих даних користувача

Усе, що користувач пише в чат AI-юриста, потенційно містить деталі реальних кейсів — імена, номери документів, обставини конфлікту. Для цього шару продукту відповідь «у нас же HTTPS» не підходить. Закладені шифрування на рівні бази, окрема політика логування (логи AI-запитів зберігаються мінімально потрібний час і без чутливих полів), процедура обробки запитів на повне видалення даних користувача, окремий ізольований контур для тестових даних.

Висновок для бізнесу. У регульованих нішах юридичний і комплаєнс-шар треба проєктувати з першого дня. Спроба «спочатку зробимо продукт, потім приведемо у відповідність» у LegalTech / HealthTech / FinTech закінчується редизайном архітектури під готовий бекенд, а це інша вартість та інші терміни.

Картка проєкту з мокапами й тех-стеком публічно доступна тут.

Discovery-чекліст замовника: 8 запитань до виконавця ще до старту співпраці

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

  1. Економіка моделі. «Хто платить за токени OpenAI під реальним навантаженням? Який прогноз OPEX на 6 і 12 місяців?» Це запитання знімає головну ілюзію AI-проєктів, що бюджет — це лише розробка. Реальний рахунок від провайдера моделі — це OPEX, який зростає лінійно або швидше з активністю користувачів. Якщо виконавець не може дати порядкової оцінки цих витрат на старті, життєздатну юніт-економіку продукту ви не зробите.

    У моїй практиці був випадок: замовник з готовим бюджетом на розробку і без жодної цифри на OPEX. Через пів року місячний рахунок від провайдера моделі вийшов на рівень, який з’їдав значну частину їхнього маркетинг-бюджету. Доводилось терміново переписувати промпти під дешевшу модель і вкручувати агресивне кешування. Якщо у відповідь на це запитання ви чуєте: «Розберемося вже в процесі», це не відповідь, це червоний прапор.
  2. Якість AI. «Як ви міряєте якість відповідей до релізу й після? Покажіть evaluation pipeline». Без вимірюваної якості AI-частина проєкту некерована. Має існувати датасет тестових запитів і метрика, яка показує, що нова версія промпта або моделі краща за попередню. Якщо у відповідь ви чуєте: «Ну ми ж бачимо, що відповіді кращі», ставте велику жирну позначку.
  3. Галюцинації. «Що буде, якщо модель видасть некоректну юридичну пораду і користувач діятиме за нею? Хто несе відповідальність — продакт-овнер, команда виконавців, користувач?» Це питання не про юридичний бік (хоча і про нього теж), а про продуктову зрілість виконавця. Хто його чув уперше, тому ще рано довіряти AI-продукт у регульованій ніші.
  4. Право власності. «Кому належать промпти, конфіги агентів, датасети та fine-tune-результати після здачі проєкту?» Це типова сіра зона у домовленостях про AI-розробку. Промпти й конфіги — це не «вихідний код у класичному розумінні». І якщо це не зафіксовано окремо у домовленостях, ви ризикуєте опинитись у ситуації, де «застосунок ваш, а мозок його — не зовсім».
  5. GDPR і дані. «Як обробляються персональні дані у чатах? Чи передаються вони third-party-провайдеру моделі? Які залишаються логи?» У відповіді має фігурувати конкретика: яка політика провайдера моделі щодо тренування на ваших даних, яким opt-out користуєтесь, як логуються запити, скільки зберігаються. Якщо у відповідь чуєте загальне «у нас усе шифрується» без конкретних політик і термінів зберігання, це червоний прапор. Дорослий виконавець відповідає тут конкретними артефактами: політика логування, DPA з провайдером моделі, періметри зберігання.
  6. План B. «Що ми робимо, якщо постачальник моделі підніме ціни вдвічі, введе ліміти або змінить ToS? Чи закладена можливість міняти провайдера?» AI-ринок зараз — це ринок, на якому ціни змінюються кварталами. Архітектура має дозволяти підмінити модель без переписування половини бекенду. Якщо це не передбачено, ви будете заручником одного провайдера.
  7. Команда. «Хто конкретно відповідає за AI-частину окремо від мобільної розробки? Це одна людина чи окремі ролі з різним рівнем досвіду?» «Фулстек, який ще й AI вміє» — дуже часто це сигнал, що AI-частина буде зроблена за залишковим принципом. Спеціалізований інженер під оркестрацію агента, промпт-інжиніринг і evaluation — окрема роль.
  8. Терміни і чекпойнти. «Чому саме такий термін? Покажіть roadmap з вимірюваними чекпойнтами якості AI, а не загальне формулювання MVP за 3 місяці». Реальний roadmap має містити проміжні точки, у яких видно, що AI-частина рухається у бік цільової якості: % коректних класифікацій галузі права, частка відповідей з обов’язковими дисклеймерами, час відгуку, вартість одного діалогу.

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

Висновки для бізнесу, який замислюється про власний ШІ-продукт

Чотири висновки, які варто винести з кейсу: керований процес, OPEX моделі, юридичний шар, AI-якість.

Якщо проєкт AI Legal Mind навчив чомусь у форматі, який можна забрати з собою, то ось ці чотири речі:

  1. ШІ-продукт — це не магія, а керований процес. Він підпорядковується тим самим законам економіки, інженерної дисципліни та продуктового мислення, що й будь-який інший. Щойно замовник перестає сприймати AI як «чорну скриньку», з якою треба «домовитись», розмова з виконавцем стає предметною.
  2. Економіка моделі — частина бюджету, а не його тінь. OPEX від провайдера моделі на 6–12 місяців експлуатації нерідко наближається до бюджету самої розробки. Це треба рахувати на старті, а не після релізу.
  3. У регульованих нішах юридичний шар має проєктуватися з нульового дня. Підхід «спочатку зробимо, потім приведемо у відповідність» у LegalTech закінчується дорого. Працюйте з юридичним консультантом паралельно з розробкою, а не послідовно.
  4. Якість AI — не «відчуття», а метрика. Якщо у проєкті не закладений evaluation-пайплайн із самого початку, ви не керуєте якістю AI — ви просто сподіваєтесь, що вона достатньо добра. Це різні стани продукту. Якщо подивитися на ці 4 пункти разом, помітна одна штука: жоден з них не про технологію. Усі — про процес, дисципліну й чесність із самим собою. AI як технологія сьогодні досить зріла, щоб не бути головним джерелом ризику в проєкті. Головне джерело ризику — це люди, які підходять до неї як до магії.

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

Знайти таких людей сьогодні нескладно: потрібно тільки приходити з правильним списком запитань. Серед фрилансерів-розробників на маркетплейсі шукати таких варто у вузьких категоріях — програмування та мобільна розробка, з фільтром за досвідом інтеграцій з AI-моделями.

Цей чекліст найкорисніший для одного типу замовника: того, хто вже визначився, що продукт з AI йому потрібен, і шукає не людину «на просто зробити», а виконавця, який допоможе закласти правильну архітектуру з першого дня. Особливо, у регульованих нішах на кшталт LegalTech, HealthTech чи FinTech. Якщо ви впізнали себе у цьому описі, хороша новина в тому, що правильна команда сьогодні шукається не довше, ніж два-три тижні предметних розмов з кандидатами за цими 8 запитаннями.

Автор: Дмитрій Лук’яненко — спеціалізується на розробці ШІ-продуктів у регульованих нішах (LegalTech, HealthTech, FinTech) і консультує власників бізнесу на етапі Discovery ШІ-проєктів: вибір архітектури, прогноз unit-економіки моделі, побудова evaluation-метрик. Картка проєкту AI Legal Mind — у портфоліо команди ProgGenius.