«Мы уже наняли команду, которая строит нам LegalTech-платформу — зачем нам ещё и архитектор?» Эти две роли часто путают, и это объяснимо: обе как будто отвечают за то, чтобы продукт заработал. На практике они решают разные задачи, и одна не подменяет другую.
Что делает разработчик LegalTech-платформы
Разработчик — или студия-интегратор — строит саму систему: интерфейс, серверную часть, интеграции с внешними сервисами, базу данных, инфраструктуру. Это инженерная работа: превратить техническое задание в работающий, стабильный и масштабируемый продукт. Хороший разработчик отвечает за качество кода и за то, чтобы платформа не падала под нагрузкой.
Что делает юридический архитектор
Юридический архитектор не пишет код и не строит платформу. Моя задача — определить, ещё до того как разработчик сядет за клавиатуру: какие решения продукт вправе принимать сам, где граница между «алгоритм отвечает» и «алгоритм обязан остановиться», какие критические риски нужно заложить как стоп-факторы. Я передаю разработчику готовую логику — деревья решений, матрицу Red Flags, спецификации, — а не техническое задание в вакууме, которое ему придётся додумывать самому, разбираясь в праве по ходу работы.
Где проходит граница: пример
Разница хорошо видна на сервисе автоматического взыскания небольших долгов:
- Архитектор заранее прописывает логику: при каких условиях сервис вправе сам направить претензию и предложить рассрочку, а когда обязан остановиться и передать дело юристу — например, если должник оспаривает сумму, если дело выходит за рамки приказного производства (долг свыше 500 000 ₽ по ст. 121 ГПК РФ и требует полноценного иска) или если есть признаки банкротства должника.
- Разработчик строит вокруг этой логики саму систему: личный кабинет должника, интеграцию с реестром исполнительных производств, платёжный шлюз, уведомления.
Без готовой логики разработчику приходится выбирать: либо зашить в код собственные — и юридически рискованные — предположения о том, когда можно автоматически давить на должника, либо останавливать процесс на каждом нестандартном случае и уточнять у юристов по ходу.
Почему архитектор — не альтернатива разработчику
Юридический архитектор не конкурирует с разработчиком или студией за бюджет — это последовательные, не взаимозаменяемые этапы. Без архитектуры разработчик либо сам додумывает юридические правила и берёт на себя риски, оценивать которые не обучен, либо процесс тормозится на каждом спорном случае. Без разработчика архитектура остаётся на бумаге — работающий продукт из одних документов не соберётся.
Иногда это выглядит как лишний подготовительный этап — будто старый waterfall вместо работы спринтами. На практике всё наоборот: без готовой матрицы Red Flags и триаж-логики Agile-команда упирается в тупик на каждом спорном сценарии («а что делать, если у пользователя ипотека?») и останавливает спринт, чтобы уточнить у юристов. Готовая архитектура убирает эти блокеры заранее, а не откладывает разработку.
На рынке есть студии, которые предлагают «архитектуру» как часть пакета разработки платформы под ключ. Это разумный формат для команд, которым нужен готовый продукт «от и до» у одного подрядчика. Но тогда юридическая логика проектируется тем же составом, что пишет код, — без независимой проверки со стороны специалиста, для которого право — основная специализация, а не сопутствующая компетенция внутри инженерной команды.
К похожему выводу пришёл и международный рынок: партнёрская сеть OpenAI для внедрения ИИ в юрфирмах нанимает не разработчиков, а бывших юристов на роль «юридических инженеров» — по сути, тот же принцип независимой правовой экспертизы, только в масштабе крупных международных команд.
Часто задаваемые вопросы
Мы уже наняли студию для разработки платформы — зачем ещё и архитектор отдельно? Студия умеет реализовать в коде любую логику, которую ей передадут, — вопрос не в квалификации, а в независимости взгляда. Даже если в штате студии есть юрист, его задача — чтобы проект был сдан в срок и без нареканий к самой студии. Задача независимого архитектора — защитить бизнес-модель заказчика, а не сроки сдачи конкретного проекта. Это разная оптика, даже при одинаковой квалификации специалиста.
Может ли сама студия-разработчик спроектировать юридическую логику как часть заказа? Да, некоторые предлагают это как часть пакета под ключ — и для некоторых команд это осознанно удобный формат. Компромисс в том, что логику в этом случае и придумывает, и реализует один и тот же подрядчик. На пальцах: это как нанять одну и ту же бригаду и для проектирования несущих стен дома, и для приёмки этой же работы, — бригаде выгоднее строить так, как проще заливать бетон, а не так, чтобы дом простоял полвека. Независимый архитектор нужен не для того, чтобы мешать строителям, а чтобы дом не сложился.
На этапе MVP разве не рано проектировать полную юридическую архитектуру? Отчасти да — если цена ошибки на MVP не выше стоимости доработки. Но в LegalTech и FinTech она может стоить дороже, чем в среднем e-commerce: автоматическая рассылка юридически необоснованных претензий или утечка персональных данных при первых ста пользователях — это уже риск жалобы регулятору или иска, а не просто недовольный отзыв. Объём архитектуры под MVP можно сократить до ключевых стоп-факторов, но полностью убирать её на регулируемом рынке рискованно.
С чего начать, если платформа уже строится, а юридической логики ещё нет? С формата Core Architecture & Triage Logic — я проектирую логику с нуля и передаю её в виде, который ваша текущая команда разработки сразу может взять в работу, не меняя подрядчика.
Строите LegalTech- или FinTech-продукт и уже выбрали команду разработки? Посмотрите, как устроена юридическая архитектура — форматы работы и что именно я передаю команде. А если непонятно, чем архитектор отличается от промпт-инженера — это разобрано отдельно.