Плохой промпт — это когда юрист вставляет договор целиком с фразой "проверь риски" и получает общий пересказ содержания. Хороший промпт превращает ИИ в структурированного ассистента, который выдаёт конкретную карту рисков с указанием пунктов. Разница — не в модели, а в том, как сформулирована задача.
Из чего состоит рабочий промпт для анализа договора
Рабочий промпт для анализа договора строится из четырёх элементов: роль и контекст, конкретная задача, формат вывода и ограничения. Без этих четырёх частей модель либо даёт слишком общий ответ, либо додумывает то, чего в договоре нет.
Роль и контекст задают модели рамку: кто анализирует документ и зачем. Например: "Ты — юрист, проверяющий договор поставки перед подписанием со стороны покупателя". Это не формальность — модель по-разному расставляет приоритеты рисков в зависимости от того, чью сторону она представляет.
Конкретная задача — это не "проверь договор", а точный список того, что нужно найти:
- Дисбаланс ответственности между сторонами
- Отклонения от стандартных условий поставки
- Пункты об одностороннем расторжении и штрафах
- Сроки и условия оплаты, отличающиеся от рыночных
Формат вывода экономит время на постобработке ответа. Просите таблицу или структуру "пункт договора → риск → рекомендация", а не сплошной текст — так результат сразу можно передать клиенту или занести в трекер рисков.
Ограничения — это явное указание модели не выдумывать нормы права, которых она не уверена, и помечать спорные места как требующие проверки. Без этого ограничения модель иногда убедительно ссылается на несуществующую или устаревшую норму.
Хороший промпт для юридической задачи почти всегда длиннее, чем кажется интуитивно правильным, — потому что каждая деталь контекста снижает шанс, что модель додумает то, чего в документе нет.
Пошаговый пример — от загрузки документа до итогового заключения
Разберём это на реальном сценарии: юрист получил договор поставки на 15 страниц и должен за час дать заключение о рисках перед встречей с руководством.
Шаг 1 — загрузка документа. Загружаете файл целиком, не вырезая отдельные пункты, — модели нужен полный контекст, чтобы видеть противоречия между разделами.
Шаг 2 — первый промпт: карта документа. Прежде чем просить анализ рисков, попросите структуру: "Составь карту документа: где сроки, где условия оплаты, где ответственность сторон, где основания для расторжения. Формат — таблица с номером пункта и кратким содержанием." Это даёт быструю навигацию по документу и сразу показывает, если что-то важное (например, форс-мажор) вообще отсутствует.
Шаг 3 — промпт на анализ рисков. Дальше даёте детальный запрос: "Ты — юрист, проверяющий договор поставки со стороны покупателя. Проанализируй пункты 4, 7 и 12 (ответственность, оплата, расторжение) на предмет дисбаланса в пользу поставщика. Для каждого найденного риска укажи: номер пункта, в чём риск, рекомендуемую формулировку правки. Если для вывода нужна ссылка на норму права, укажи её отдельно и пометь как 'требует проверки по первоисточнику'."
Шаг 4 — уточняющий промпт по спорным пунктам. Если модель отметила пункт как неоднозначный, просите развернуть: "Объясни, почему пункт 7 может трактоваться неоднозначно, и предложи два варианта формулировки — более выгодный для покупателя и нейтральный."
Шаг 5 — фактчекинг. Каждую ссылку на норму права или судебную практику, которую дала модель, проверяете по первоисточнику — базе нормативных актов или системе типа КонсультантПлюс. Это не опциональный шаг, а обязательная часть процесса.
Шаг 6 — итоговое заключение. На основе проверенных данных формируете финальный документ для руководства — уже своими словами, с пометкой, какие риски подтверждены, а какие требуют дополнительной консультации.
Весь цикл от загрузки договора до готового заключения занимает существенно меньше времени, чем ручное построчное чтение, — но экономия времени идёт именно за счёт структуры промптов, а не за счёт пропуска шага проверки.
Читайте по теме:
Частые ошибки при промптинге в юридических задачах
Самая частая ошибка — расплывчатый запрос вроде "проверь этот договор на риски". Модель в ответ даёт общий пересказ содержания без конкретики, потому что не понимает, с чьей стороны смотреть на риски и что считать существенным.
Вторая ошибка — не указывать роль и сторону, которую представляет юрист. Без этого модель нейтрально описывает условия договора вместо того, чтобы явно указать, какие пункты невыгодны именно вашей стороне.
Третья ошибка — принимать ссылки на нормы права без проверки. Модель может уверенно сослаться на статью закона, которая не соответствует действительности, звучит это при этом так же уверенно, как верная ссылка, — отличить на глаз невозможно, только через первоисточник.
Четвёртая ошибка — просить всё сразу одним промптом на 20 строк. Более надёжный подход — разбить задачу на этапы: сначала карта документа, потом анализ конкретных пунктов, потом уточнения по спорным местам. Так проще контролировать качество на каждом шаге.
- Расплывчатая формулировка задачи без конкретного списка того, что искать
- Отсутствие указания роли и стороны договора
- Слепое доверие ссылкам на нормы права без сверки с первоисточником
- Попытка получить полный анализ одним огромным промптом вместо пошагового процесса
Как проверять результат — обязательный фактчекинг
Проверка результата строится на одном правиле: любая ссылка на норму права, судебную практику или конкретную цифру (срок, процент, сумма) должна быть сверена с первоисточником прежде, чем попадёт в финальный документ. Модель хорошо структурирует и находит паттерны в тексте договора — но не гарантирует точность фактов, которые сама же приводит.
Практический чек-лист перед тем, как передать заключение дальше:
- Все ссылки на нормы права сверены с актуальной редакцией
- Спорные пункты, помеченные моделью как неоднозначные, дополнительно проверены вручную
- Контекст дела (юрисдикция, вид договора, сторона) зафиксирован и не менялся между промптами
- Итоговый документ переписан своими словами, а не скопирован дословно из ответа модели
ИИ в юриспруденции — анализ договоров
Частые вопросы
Существенно — за счёт того, что первичная карта документа и разметка рисков занимают минуты вместо часов построчного чтения. Но экономия идёт только на этапе первичного анализа, фактчекинг всё равно требует времени юриста.
В рамках одного диалога — нет, контекст сохраняется. Но при новом договоре или новой задаче роль и сторону нужно задавать заново — модель не переносит контекст из прошлой сессии автоматически.
Если в промпте нет конкретного списка того, что искать (какие пункты, чей риск, в каком формате вывод) — он слишком расплывчатый. Хороший тест: показать промпт коллеге и спросить, понятно ли ему без пояснений, что должно получиться на выходе.
Помечать такой пункт как непроверенный и не включать в финальное заключение до сверки. Лучше отдать клиенту заключение с пометкой "требует уточнения", чем ссылку, которая окажется неточной.
Структуру (роль → задача → формат → ограничения) — да. Но конкретный список того, что искать (пункты, риски, формулировки), нужно адаптировать под тип договора — поставка, аренда, оказание услуг требуют разных акцентов.
Как черновик — да, как готовый юридический текст — нет. Предложенные моделью формулировки нужно проверять на соответствие законодательству и адаптировать под конкретную ситуацию, прежде чем включать в документ.
На курсе «Claude для работы и бизнеса» разбираем промпт-инжиниринг на реальных документах.
Получить консультацию →