Пошаговый анализ и проверяемый вывод

Запросите основания и открытые вопросы, чтобы проверить предложенную правку.

Обновлено 19 октября 2026

Когда ИИ предлагает изменить договор, юристу нужны основания: исходное условие, критерий проверки, возможное последствие и вариант правки. Длинное объяснение без связи с документом затрудняет проверку.

Разделяйте результаты работы

Для сложного материала полезна последовательность: факты → сопоставление с критериями → варианты действий → проект документа. Каждый этап должен оставлять проверяемый результат. Ошибку в извлечённой сумме лучше исправить до подготовки претензии.

Начните с одного запроса, если материал короткий и критерии ясны. Разделяйте работу на несколько запросов, когда нужна проверка источников, есть противоречия или разные версии. Само количество этапов не улучшает качество.

Первый этап: получить факты

Для разбора расходов исполнителя сначала нужны текст условия и правила вашей компании.

Извлеки из договора условия о возмещении расходов исполнителя.
Для каждого укажи пункт и точную цитату.
Отдельно найди: предварительное согласование,
подтверждающие документы, лимит и срок возмещения.

Используй только файл [название текущей редакции].
Если условие не найдено, напиши «не найдено в переданном тексте».
Ссылки на отсутствующие приложения перечисли отдельно.
Правки пока не предлагай.

Сверьте извлечённые пункты и связанные положения. «Не найдено» может означать пропуск при чтении, поэтому отсутствие важного условия нужно проверить по самому договору.

Второй этап: применить критерий

В условном примере текст договора — «Любые расходы исполнителя возмещаются заказчиком». Правило компании требует предварительного согласования и документов; размер лимита ещё не определён.

Условие: «Любые расходы исполнителя возмещаются заказчиком».

Критерии компании:
- расходы согласуются до их возникновения;
- возмещение по подтверждающим документам;
- размер общего лимита ещё не согласован.

Выдай:
1. Какое условие не отражает каждый критерий.
2. Возможное последствие для заказчика.
3. Вариант редакции с полем [согласовать лимит].
4. Вопросы для принятия решения.

Кратко объясни связь правки с критерием.
Не добавляй нормы, суммы и согласования, которых нет в данных.

Разобранный результат. В исходной фразе нет ни предварительного согласования, ни требования документов. Правка должна добавить оба механизма. Модель может предложить поле для лимита, но не назначить сумму от имени компании. Также остаётся вопрос: кто и каким способом согласует расходы?

Возможное последствие — требование возместить несогласованные расходы. Утверждение «заказчик уже понёс убытки» не следует из условия и подлежит удалению.

Что просить вместо внутренней цепочки рассуждений

Просите короткое обоснование, цитаты, допущения и факты, при которых вывод изменится. Они помогают проверить рекомендацию. В руководстве OpenAI для reasoning-моделей просьба раскрыть внутреннюю цепочку рассуждений названа необязательной; предпочтительны ясные инструкции и конкретный результат.

Полезный дополнительный запрос: «Какой отсутствующий документ или факт может изменить эту рекомендацию?» Он помогает собрать вопросы, но новые обстоятельства из ответа пока остаются гипотезами.

Как передать процесс агенту

Сначала закрепите ручной порядок и критерии. Затем агент может собрать цитаты, сопоставить их с правилами и подготовить черновик. Если нет приложения, не прочиталась таблица или критерии противоречат друг другу, следующий этап должен остановиться с понятной причиной.

Сохраните связь каждого замечания с документом и его редакцией. Утверждение правки и отправку контрагенту оставьте отдельными действиями. Второй ответ той же модели не заменяет сверку с источником: он может повторить исходную ошибку.