Когда просишь ChatGPT «напиши исковое заявление про поставку» — получаешь стену текста. Красивую, шаблонную, часто с выдуманными номерами дел. Один раз использовал — забыл. Уточнить «а поменяй ответчика на ООО Ромашка» — и модель либо перепишет всё заново, либо аккуратно потеряет половину аргументов. В LexBridge иск — это не текст. Это объект. У него шесть табов, реестр документов, чек-лист проблем и история. Я расскажу, зачем это.
Проблема простыни
Юрист, который хоть раз готовил серьёзный иск через универсальный чат, знает эту боль. Ты описал ситуацию — получил документ. Через час клиент прислал недостающий акт — надо переделать. Ты копируешь старую версию в новый чат, добавляешь «плюс акт от 15.07» и снова получаешь простыню, где часть прежних ссылок пропала, а цена иска сместилась на три копейки — потому что модель пересчитала сама, по-своему.
Дальше — ответчик прислал возражения. Ты снова открываешь чат, снова копируешь простыню, снова просишь «учти возражения». К третьей итерации это уже не документ, а франкенштейн. И главное — ты не помнишь, где какая версия, что уже подано в суд, а что только черновик.
Мы построили конструктор иска по другому принципу. Иск — это карточка с полями. Модель не переписывает документ, а правит поля. Как в CRM. Только полями рулит ИИ, а не человек.
Шесть табов, а не один документ
Карточка иска в LexBridge разложена на шесть вкладок:
- Стороны — истец, ответчик, третьи лица; реквизиты, ИНН, представители.
- Существо — предмет спора, требования, цена иска, госпошлина.
- Стратегия — правовая позиция, применимые нормы, ключевая практика ВС.
- Тактика — ходатайства, обеспечительные меры, риски снижения по ст. 333 ГК.
- Документы — реестр всей первички со статусами.
- Чат — диалог с ИИ по этому конкретному делу.
Каждый таб редактируется отдельно. Поменял реквизиты ответчика во вкладке «Стороны» — в шапке иска они обновились сами. Пересчитал цену иска в «Существе» — госпошлина по ст. 333.19 или 333.21 НК пересчиталась мгновенно, детерминированно, без «три копейки в сторону». Считает не модель, а код.
Языковую модель нельзя пускать к калькулятору. Она умеет писать, но не умеет считать. Госпошлина, проценты по ст. 395 ГК, неустойка — всё делает наш код с актуальной ключевой ставкой ЦБ, автоматическим исключением моратория 2022 года и разбивкой по периодам смены ставок.
Реестр документов из восьми типов и семи статусов
Вкладка «Документы» — это не список файлов на диске. Это реестр всей первички по делу с восемью типовыми ролями: договор, дополнительное соглашение, накладная, акт, счёт-фактура, претензия, ответ на претензию, прочее. У каждой строки — семь возможных статусов: есть, приложен, отсутствует, запрошен у клиента, направлен ответчику, спорный, не требуется.
Отсутствующая накладная — тоже строка. Со статусом «отсутствует» и автоматически созданным issue-тикетом «запросить у клиента». Не бывает такого, что юрист забыл про эту накладную — она в чек-листе, красная, до тех пор пока не появится или явно не помечена «не требуется».
Actions-протокол: ИИ правит поля сам, а не выдаёт простыню
Здесь начинается самое интересное. В чате дела юрист пишет: «Забыл сказать, есть ещё дополнительное соглашение от 12.03.2024 к договору поставки, увеличили сумму на 500 тысяч». Модель отвечает не новой простынёй иска. Она возвращает служебный блок с действиями (мы называем это «actions-протокол»), в котором прямо указано: добавить в реестр документ «доп. соглашение от 12.03.2024» со статусом «есть, приложить», изменить цену иска на плюс 500 тысяч, пересчитать неустойку от новой суммы, добавить issue «уточнить у клиента: есть ли акт о поставке дополнительной партии».
Всё это применяется к карточке автоматически. Двенадцать типов операций: setStatus, setField, issue.add, issue.delete, setClaimAmount и так далее. Юрист видит diff карточки, а не новый текст, в котором надо искать глазами, что изменилось.
Issues — чек-лист проблем с приоритетами
Отдельная сущность — issues. У каждой три уровня приоритета: критично, внимание, к сведению. Пример из реального дела: «В договоре не указан срок исполнения — риск отказа в неустойке, ст. 314 ГК даёт разумный срок» — уровень «критично». «Претензия направлена почтой без описи вложения — ответчик может оспорить факт получения» — уровень «внимание».
На каждой issue — свой чат. Не засоряя общий диалог по делу, юрист может отдельно с ИИ обсудить, как обосновать разумный срок по ст. 314. Ответ приходит с цитатой Пленума и ссылками на конкретные определения ВС.
Семь видов документа из одной карточки
Одна и та же карточка иска — источник для семи разных процессуальных документов: собственно иск, отзыв (когда роли поменялись и мы защищаемся), ходатайства, контррасчёт, сверка расчётов, апелляционная жалоба, прочее. Выгрузка — в процессуальный DOCX: Times New Roman 14, шапка справа, выравнивание по ширине. Не надо править форматирование в Word перед отправкой в суд.
Три режима переанализа
Клиент прислал новый документ — ответ ответчика на претензию. Что делать? В LexBridge три режима переанализа:
- Один документ (single) — модель разбирает только новый файл, обновляет карточку по тем полям, которые он затрагивает. Дёшево, быстро.
- Пакет (package) — ИИ смотрит на новый документ вместе с выбранной папкой (например, «переписка с ответчиком»), выявляет противоречия, обновляет тактику.
- Всё дело (all) — полный переанализ на случай, когда переменились обстоятельства. Дороже, но не пересборка с нуля: сохраняется история версий карточки.
Юрист сам выбирает глубину. Не платит за пересборку с нуля каждый раз, когда клиент прислал очередной листок.
Реальный тест: дело на 162,8 млн ₽
Когда мы доделали конструктор, обкатывали его на настоящем деле: спор о поставке между компанией «ДОРФ» и АО «КСП Светлогорское», цена иска 162,8 млн рублей. Загрузили сорок семь документов первички (в том числе сканы, включая один PDF на двести страниц). Конструктор собрал карточку иска, включил поиск практики по статье о неустойке, вытянул три ключевых определения экономколлегии ВС РФ с кликабельными ссылками, сформировал реестр из тридцати одной строки со статусами.
Пять issues уровня «критично» — включая нашу ошибку в первом расчёте неустойки, где мы не учли период моратория. Не конкурент указал, не судья на заседании. ИИ при первом же анализе.
Итог: сорок минут работы юриста от загрузки первички до выгружаемого в DOCX иска, готового к правке. Без конструктора такое дело собиралось бы два-три полных рабочих дня.
Что это меняет
Иск как объект вместо иска как текста — это не косметическое улучшение. Это другой рабочий процесс. Ты не пишешь документ. Ты ведёшь дело: правишь стороны, добавляешь документы в реестр, обсуждаешь issues с ИИ, разгружаешь готовые версии в суд по мере необходимости. Все версии — в истории карточки. Все расчёты — детерминированные. Все ссылки на практику — кликабельные и проверяемые.
ChatGPT в чате — это как готовить иск в Notepad. LexBridge — как готовить его в специализированной юридической IDE. Разницу видно на первом же деле.