Розробка юридичного порталу: MVP, безпека та LegalTech

Чому юридичний портал ламається на інтеграціях і ролях

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

Ламається вона зазвичай не на відображенні сторінок, а на стиках: погодження договору проходить через п’ять учасників і три системи, і на кожному переході стан документа розходиться з тим, що реально лежить у файлі.

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

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

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

Окрема категорія — помилки в правах доступу: роль копіюють разом із зайвими повноваженнями, права видають «на час» і не відкликають, журнал дій не ведеться, і підрядник іззовні бачить те, що бачити не повинен.

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

Що змінюється після впровадження: строки, ризики, навантаження на юристів

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

• Швидкість погодження договорів. Типові договори збираються з затверджених блоків — реквізити й умови підставляються самі. Юрист перевіряє відхилення, а не верстку, і погодження не чекає пересилання між відділами.
• Єдиний реєстр правових документів. У кожної версії — автор, дата, статус і зв’язок із заявкою, пошук іде за текстом і реквізитами. «Остання версія в когось у пошті» зникає як клас.
• Зменшення ручних операцій. Реквізити, повноваження підписанта й строки дії перевіряються правилами до надсилання. Підпис через КриптоПро закриває цикл без роздрукування й сканування.
• Прозорість статусів заявок. Ініціатор бачить крок документа й того, хто тримає його в себе, а ескалація за строком спрацьовує сама. Питання «ну як там» перестають доходити до юриста.
• Зниклий клас відмов. Прострочена довіреність, застарілий шаблон, загублений додаток — типові причини повернення на доопрацювання закриваються перевірками на вході.

Три-чотири метрики фіксуємо в прийманні, решту залишаємо орієнтирами: якщо після запуску ефекту немає, перезбираємо процес, а не переписуємо портал.

Архітектура юридичного порталу: модулі, ролі, інтеграції

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

Ролі та права користувачів описуємо матрицею доступу до сутностей — партнер, юрист, помічник, клієнт, зовнішній аудитор — а не набором перевірок в інтерфейсі.

Права підтверджуються на стороні сервісу, а відкриття картки справи потрапляє до незмінного журналу: під час спору видно, хто і коли переглядав документ.

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

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

Зовнішній контур доступу відокремлений від внутрішнього — збій у кабінеті не відкриває службові розділи.

Етапи розробки: від аудиту процесів до передачі в експлуатацію

Юридичний портал — не набір сторінок, а реєстр пов’язаних сутностей: клієнтів, справ, документів із версіями, доручень і прав доступу до них.

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

1. Аудит правових процесів — інтерв’ю з юристами й керівником практики, карта ролей, реєстр сценаріїв: де заводиться справа, як погоджуються документи, хто і що бачить. На виході — вузькі місця та сценарії з найбільшою цінністю.
2. Проєктування схеми даних — сутності та зв’язки, правила версіонування документів, журнал дій. Окремо вирішуємо, що зберігається незмінно: історія правок і доступів має відновлюватися.
3. Налаштування ролей і доступів — матриця «роль × сутність × дія» з розмежуванням на рівні запису, а не лише розділу. Доступ до чужих справ закритий за замовчуванням.
4. Складання першої робочої версії — картка справи, завантаження й версіонування документів, пошук за реєстром, потім ітерації з перевіркою в юристів на кожному кроці.
5. Приймальні перевірки — прогін реальних сценаріїв на реальних даних: права ролей, пошук, навантаження, відновлення з резервної копії. Розбіжності фіксуються дефектами.
6. Передача в експлуатацію — регламент випуску, середовища, резервне копіювання, моніторинг, документація, навчання юристів. Передаємо разом із вихідним кодом і правами на нього.
7. План розвитку — черга завдань з оцінкою за кожним, щоб після запуску було зрозуміло, що робимо далі й у якому порядку.

Що ви отримуєте на руки: документація, доступи, регламенти

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

• Технічна документація — архітектура порталу, модель даних за справами, документами й сторонами, точки розширення під нові типи послуг.
• Схема інтеграцій — які зовнішні системи підключено (реєстри, платіжний шлюз, підпис), у якому напрямку йдуть дані та як портал поводиться за недоступності кожної з них.
• Матриця доступу — ролі юристів, адміністраторів і клієнтів, права на розділи й операції, порядок видавання та відкликання доступу під час зміни співробітника на проєкті.
• Конфігурації середовищ — змінні, секрети й параметри розгортання тестового та робочого контуру, щоб стенд піднімався з нуля.
• Регламенти супроводу — резервне копіювання з перевіркою відновлення, оновлення залежностей, порядок випуску змін і відкату.
• Інструкції для користувачів — окремі для юристів і для клієнтів порталу: типові операції, права ролі та розбір частих помилок.
• Журнал інженерних рішень — обґрунтування вибраних сервісів, враховані обмеження та черга розвитку порталу.

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

Кейс: як прискорили погодження договорів без втрати контролю

Що було до впровадження

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

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

Окремий клас відмов — «підписали не те»: фінальний файл підписувався без звірки з останньою правкою, і розбіжність виявлялася вже в бухгалтерії.

Що змінили і що отримали

Ми зібрали портал, де договір — це картка з версіонуванням, маршрутом погодження за типом і сумою та незмінним журналом статусів.

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

Строк погодження скоротився з дев’яти робочих днів до трьох: маршрут будується за правилами, нагадування надходять за таймером статусу, а не з пам’яті секретаря.

Частка заявок, прострочених щодо внутрішнього регламенту, впала з 34% до 7%, а заявки, загублені в листуванні, зникли як клас — у кожної є власник, дедлайн і поточний погоджувач.

Відмови «підписали не ту версію» більше не відтворюються: підпис не з’явиться, якщо документ змінився після погодження.

Окремо закрили питання простежуваності — спір «хто і коли погодив» вирішується за журналом за хвилину. Юристи перестали бути диспетчерами листування й повернулися до правової роботи.

Чим відрізняється власний модуль від доопрацювання чужої системи?

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

Щойно з’являються різні ролі, доступ до справ за матрицею прав і фіксація кожної дії з документом, чужа модель даних починає чинити опір.

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

На 1С-Битрикс і подібних платформах це лікується відмовою від оновлень, і з часом підтримка перетворюється на окремий напрям.

Власний модуль проєктується від процесів: схема даних під ваші сутності, ролі та права як частина моделі, журнал дій на рівні ядра, а не надбудова. Розвиток іде своїм релізним циклом — нова роль або звіт не ламає сусідній сценарій. На старті це більше роботи, зате рішення не впирається в чужі обмеження.

Сумніви щодо безпеки, доступів і строків упровадження

Юридичний портал тримає персональні дані клієнтів, листування у справах і документи з обмеженим доступом. Тому заперечення перед стартом частіше технічні: як розмежовано доступ, що станеться за недоступності зовнішнього сервісу й хто відповідає за систему після запуску.

Як захищено персональні дані?

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

Що якщо зовнішній сервіс недоступний?

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

Які строки розробки і що після запуску?

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

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

Обговоримо задачу: що надіслати і що отримаєте у відповідь

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

Чим точніше на старті описано ролі та сценарії, тим менше переробок у момент, коли прототип уже зібрано й погоджено.

Щоб повернутися з оцінкою та планом, достатньо надіслати:

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

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

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

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