Сейчас в Legal AI доминирует наивная идея: если большая языковая модель (LLM) умеет писать юридический текст, достаточно дать ей корпус решений, прикрутить чат — и получится «цифровой юрист». Словно право — это просто очень длинный prompt.
Суд — это не текст, а система
Проблема в том, что суд — не текстовый жанр. Это система. Как только вы выходите за рамки задач вроде «суммаризируй решение» или «набросай ходатайство», выясняется: LLM отлично работает как интерфейс, но плохо подходит на роль архитектуры. Она умеет объяснять, но не заменяет процессную модель, вероятностный движок или систему проверки ограничений.
Это особенно критично в судебной аналитике: где дело может застрять, на каком этапе ломается траектория, где процесс ветвится. Здесь ключевыми становятся не тексты, а расчёты. И внезапно оказывается, что самые полезные идеи лежат не в современном AI-маркетинге, а в работах 1960–1970-х годов.
Ранние попытки моделирования судебных систем
Еще в 1968 году исследователи моделировали движение уголовных дел в судах округа Колумбия. В 1973 году появилась работа An algebraic method for simulating legal systems, где описывался алгебраический подход к симуляции правовых систем. С инженерной точки зрения это не исторический курьёз, а попытка честно ответить: что именно мы автоматизируем — текст, решение или саму систему?
Почему LLM-обёртка быстро упирается в потолок
Когда говорят «автоматизировать юриста», часто подменяют задачу. Вместо моделирования процесса пытаются имитировать мышление специалиста: как он читает дело, оценивает перспективы. На практике это приводит к тому, что модель имитирует стиль рассуждений, но не структуру процесса.
Для договоров это ещё терпимо. Для суда — нет. В судебной системе есть как минимум пять разных сущностей, которые часто сваливают в одну кучу:
- Текст.
- Процессуальная траектория.
- Ограничения и сроки.
- Вероятностные переходы между стадиями.
- Объяснение результата человеку.
LLM подходит в основном для последнего пункта и частично — для первого. Остальное она может только маскировать. Именно здесь старые court simulations оказываются неожиданно актуальными.
Урок первый: сначала модель процесса, потом «умный юрист»
Ранние симуляции строились на простой идее: суд — это система обработки потока дел, а не магия отдельных участников. Это инженерная честность.
GPSS — General Purpose Simulation System, использовавшийся в тех моделях, — создавался для дискретных процессов, где важны события, очереди, ресурсы и переходы между состояниями. Это почти идеальная метафора для суда: поступление дела, распределение, ожидание, ходатайство, перенос, апелляция, выход.
Отсюда болезненный вывод для Legal AI: прежде чем заставлять модель «думать как судья», нужно хотя бы описать, что происходит с делом в системе. Prompt не важнее process graph. Тонкость формулировки не важнее topology.
Поэтому плохой Legal AI — это один огромный вызов LLM с просьбой «оцени шансы». Хороший — это конвейер, где языковая модель не трогает то, что можно описать правилами, графом или статистикой.
Урок второй: право нелинейно — и это нормально
Судебное дело почти никогда не идёт по прямой. Есть возвраты, переносы, апелляции, новые доказательства, процессуальные петли. Дело может быть «тем же самым», но в другой конфигурации.
Именно поэтому работа 1973 года до сих пор актуальна: авторы использовали алгебраический метод в логике system theory. Они думали не о текстах, а о структуре переходов. Это сигнал: юридический процесс удобнее мыслить как граф состояний с вероятностными переходами, а не как цепочку абзацев.
Многие современные AI-продукты пытаются решить задачу workflow engine с помощью chat completion API. Вместо моделирования системы берут модель, которая хорошо продолжает текст, и просят её быть процессуалистом, аналитиком, маршрутизатором и калькулятором вероятностей.
Работает ли это на демо? Да. Ломается ли на реальных данных? Тоже да.
Урок третий: юристу нужна не «оценка», а карта доверия
Самая опасная ошибка в Legal AI — думать, что пользователю нужен просто прогноз. Юристу мало услышать: «вероятность удовлетворения иска — 63%». Нужно понимать, какие факторы повлияли на вывод, где модель уверена, а где — нет, что взято из данных, а что является интерпретацией.
Вот почему explainable AI в праве — не декоративная надстройка, а необходимость. Чтобы ошибку можно было обнаружить, оспорить, а не просто восхищаться гладкостью ответа.
С инженерной стороны это значит: результат должен приходить не как «чёрный ящик с уверенным тоном», а как интерфейс. Где видны допущения, маршрут дела, ключевые признаки, зоны неопределённости.
Короче: не просто answer, а observability.
Как бы я проектировал Legal AI-систему сегодня
Без учёта AI-магии архитектура судебной аналитики может выглядеть так:
- Слой данных: судебные акты, карточки дел, процессуальные документы, метаданные.
- Слой нормализации: выделение сущностей, стадий, событий, сроков, участников.
- Процессная модель: граф движения дела, допустимые переходы, исключения, циклы.
- Вероятностный слой: частоты, калибровка, confidence, интервалы — не просто «да/нет».
- Правила и валидация: проверка на противоречия, пропуски, процессуальные ограничения.
- LLM-слой: объяснение результата, работа с вопросами, генерация текста.
- UI-слой: визуализация маршрута, факторов, сценариев, зон неопределённости.
LLM здесь не исчезает. Но она перестаёт быть богом системы. Она становится переводчиком между машинной моделью процесса и человеком.
Это более реалистичная роль. LLM хороша в интерпретации, резюмировании, классификации. Но когда её заставляют быть одновременно движком процесса, статистическим аппаратом и источником истины — начинаются галлюцинации. А в праве они особенно токсичны.
Текстовая генерация, прогноз, объяснение, маршрутизация и проверка консистентности — это разные задачи. Если их смешать, система будет звучать умно, но лишится инженерной опоры. Если разделить — появятся воспроизводимость, дебаг, измеримость качества и защита от красивой ерунды.
Сентенция
Самая дорогая ошибка в Legal AI — автоматизировать не тот уровень системы.
Если моделировать юриста, получится обаятельный интерфейс. Если моделировать суд как систему, появляется шанс построить рабочий инструмент. И вот это уже не маркетинг, а архитектура.