Договор возвращается от второй стороны с правками, и на него смотрят по диагонали в конце дня. Юрист занят, срок горит, а изменений на восемнадцати страницах вроде бы немного — вон, три места подсвечены.
Здесь нейросеть даёт настоящий выигрыш. Не потому, что разбирается в праве — она в нём не разбирается, — а потому, что не устаёт на четырнадцатой странице и не пропускает пункт, который тихо вернули в прежнюю редакцию.
Сразу о границе: всё, что ниже, — это способ быстрее и точнее посмотреть, чтобы принести юристу конкретные вопросы вместо папки. Правовой вывод делает человек, который за него отвечает. Модель формулирует юридические утверждения особенно убедительно и особенно ненадёжно — это её худшая сторона.
Почему «проверь этот договор» не работает
Такая просьба даёт общий пересказ, десяток очевидных советов и ни одного приоритета. Модель не знает, кто вы в этой сделке, чего опасаетесь и что для вас существенно, — и отвечает вообще.
Работают три другие задачи, каждая со своей постановкой.
Задача первая: найти условия, невыгодные вам
Ключевое — назвать сторону. Один и тот же пункт для заказчика и для исполнителя выглядит по-разному, и без указания роли модель балансирует между ними.
Ты — юрист по подрядным договорам. Ниже текст договора без реквизитов
и наименований сторон. Я выступаю заказчиком.
Найди условия, ухудшающие моё положение по сравнению с обычной практикой.
Формат: таблица «пункт — в чём риск — последствие в деньгах или сроках —
предлагаемая формулировка». Отсортируй по существенности риска.
Если пункт неоднозначен — так и напиши, не додумывай.
Ничего не выдумывай: разбирай только то, что есть в тексте.
Три вещи в этом промте делают работу: названа роль и сторона, задан формат с последствиями, а не с оценками, и есть разрешение сказать «неоднозначно» вместо уверенной выдумки.
Что вы получите: список мест, на которые стоит посмотреть. Не приговор, а карта. Дальше вы читаете сами — и половину пунктов отбрасываете, потому что знаете контекст, которого у модели нет.
Задача вторая: сверить две редакции
Самая полезная и самая недооценённая. Контрагент вернул договор с правками и сопроводительным письмом «внесли небольшие уточнения». Вопрос не в том, что он изменил, а в том, что из ваших замечаний он на самом деле учёл.
Ниже две редакции одного договора без реквизитов и наименований сторон,
а также список моих замечаний к первой редакции.
По каждому замечанию определи, что сделала вторая сторона: исправила
полностью, исправила частично или не исправила. Цитируй, как стало.
Отдельно перечисли изменения, которых в моих замечаниях не было, —
их внесли по своей инициативе, и я должен о них знать.
Формат: таблица «замечание — статус — что именно изменилось —
на что это влияет». Если формулировка неоднозначна — так и напиши.
Второй абзац здесь важнее первого. Правки, которых вы не просили, — самое интересное в вернувшемся документе: там появляются продлённые сроки оплаты, смягчённая ответственность и оговорки, меняющие смысл гарантии.
Типичная картина после такой сверки: часть замечаний учтена полностью, часть — формально (слова поменялись, суть осталась), часть тихо проигнорирована, и обнаруживается два-три изменения, о которых в сопроводительном письме не было ни слова. Ровно это вы и несёте юристу — с номерами пунктов, а не с папкой.
Реальный прогон: полезная находка и ошибка в одной таблице
Мы проверили запрос на локальной Qwen3 14B. В первой редакции оплата была через 10 дней, заказчик просил 15, а контрагент вернул 20. Срок устранения недостатков просили сократить с пяти дней до трёх — это было сделано. Без отдельного замечания срок договора изменился с конца 2026-го на конец 2027 года.
Открыть полный разбор результата →
Модель сделала полезное: заметила незапрошенное продление договора и точно процитировала новую формулировку. Одновременно она назвала 20 дней «частичным» выполнением просьбы о 15 днях. Для точного требования это статус «не учтено». Получилась идеальная иллюстрация границы метода: таблица ускоряет просмотр, но её оценки не становятся верными только потому, что хорошо оформлены.
Прогон выполнен 8 сентября 2026 года полностью локально через Ollama. Все стороны, пункты и сроки вымышлены; это упражнение на чтение различий, а не юридическое заключение.
Задача третья: перевести на человеческий
Объясни своими словами, что означает этот пункт и к чему он обязывает
каждую из сторон. Без юридических формулировок, как объяснил бы коллеге.
Отдельно скажи, что произойдёт, если обязательство не выполнить.
Полезно не только для себя. Когда вы объясняете условие смежному отделу — снабжению, производству, бухгалтерии — им нужен именно такой перевод, а не цитата из документа.
Что обязательно проверить в ответе
Номера пунктов. Модель уверенно ссылается на «п. 7.3», которого в договоре нет, или путает нумерацию. Каждую ссылку сверяйте с текстом — это тридцать секунд и первое, что рассыпается.
Цитаты. Если модель приводит формулировку как цитату — найдите её в документе. Пересказ своими словами, выданный за цитату, меняет смысл чаще, чем кажется.
Ссылки на нормы. «Согласно статье такой-то» — самое опасное место. Проверяется отдельно и всерьёз, а лучше просто выносится из документа: правовые основания приводит человек, который за них отвечает.
То, чего модель не сказала. Она не знает ваших договорённостей, истории отношений с этим контрагентом и того, что в прошлый раз вам уже уступили по этому пункту. Отсутствие замечания не означает, что там всё в порядке.
Про данные
Договор целиком — красная зона. Реквизиты, наименования сторон, суммы, фамилии подписантов не отдаются в чат.
Практический выход тот же, что во всей линейке: обезличить перед отправкой. Убрать шапку с реквизитами, заменить наименования на «заказчик» и «исполнитель», суммы — на условные, если они не влияют на разбор. Структура договора и формулировки условий при этом сохраняются полностью — а именно они и разбираются.
Если обезличить невозможно — например, разбирается конкретная сумма в связке с конкретным контрагентом, — задача остаётся человеку или переносится в контур, разрешённый вашей организацией. Никакая экономия времени не стоит утечки договора.
И отдельно: не превращайте разбор в переписку с приложенными файлами. Один документ, обезличенный, в одном разговоре — и не забывайте, что модель видит весь разговор целиком, включая то, что вы упомянули в соседнем сообщении.
Что это меняет на практике
Раньше сверка двух редакций была работой на час с риском пропустить пункт. Теперь это десять минут на подготовку и разбор плюс ваше внимательное чтение того, что модель подсветила.
Но главное изменение не в скорости. Оно в том, что к юристу приходят не с «посмотрите договор», а со списком: вот эти три пункта нас не устраивают, вот эти два изменили без предупреждения, вот здесь формулировка неоднозначна. Разговор с этого начинается, а не заканчивается.
А юридическую оценку по-прежнему даёт юрист. Модель читает быстро и не устаёт — это всё, что она умеет в этой задаче. Этого, впрочем, достаточно, чтобы пункт, тихо вернувшийся в прежнюю редакцию, перестал уезжать в подписанный документ.
