Перед стартом: что проверяем
Не начинайте с команды «проверь договор целиком». Это слишком широкая задача: разные люди под проверкой понимают суммы, сроки, ответственность, реквизиты или соответствие внутреннему шаблону. Запишите цель в одном предложении: например, найти условия, отличающиеся от согласованной формы закупки. Назначьте человека, который примет результат. Подготовьте действующую версию договора, приложения и внутренний чек-лист; старые редакции сохраните отдельно. Если документ содержит сведения, которые нельзя передавать выбранному сервису, используйте разрешённый контур или обезличенный пример. ИИ-вывод не является юридическим заключением.
Шаг 1. Разметьте документы
Составьте таблицу из четырёх колонок: файл, дата, статус и связь с основным договором. Отдельно отметьте, какие приложения подписаны, какие находятся на согласовании и какое письмо лишь обсуждало изменение. Скан без читаемого текста предварительно проверьте вручную: ошибка распознавания номера, валюты или отрицания меняет смысл пункта. Назовите файлы так, чтобы версия была видна без открытия. Сохраните копию оригинала; в рабочем пакете допустимо добавить номера страниц и пометки, но исходник должен оставаться неизменным. Этот этап скучный, зато защищает от самого распространённого провала: уверенного ответа по неправильной версии.
Шаг 2. Запросите карту, а не вердикт
Первый запрос к модели должен извлекать условия: стороны, предмет, сроки, цену, порядок изменения, ответственность, расторжение, применимые приложения. Попросите для каждого пункта указать точную цитату и место в файле. Запретите домысливать отсутствующее: если условие не найдено, ответ должен содержать «не найдено в переданных документах». Не просите оценивать выгодность. После получения карты человек открывает указанные страницы и сверяет ключевые числа. Ошибочная карта делает любой последующий анализ бесполезным, даже если он звучит профессионально.
Шаг 3. Сравните с вашим эталоном
Теперь приложите внутренний шаблон или согласованный список обязательных условий. Попросите показать только различия и разделить их на три группы: факт в договоре, факт в эталоне и вопрос для ответственного сотрудника. У каждой строки должны быть ссылки на оба основания. Не позволяйте модели помечать любое отличие как нарушение: допустимое отклонение может быть согласовано коммерческой командой. Для сложной формулировки, например лимита ответственности, полезнее получить два дословных фрагмента рядом, чем короткий автоматический «риск высокий».
Шаг 4. Проверьте спорные места
Составьте отдельный список пунктов, где встречаются числа, сроки, исключения и условия «если». Проверьте, распространяется ли оговорка из приложения на основной текст. Возьмите два пограничных вопроса: что происходит при задержке поставки и какой документ действует при противоречии. Если модель не может показать основание, не исправляйте ответ незаметно; зафиксируйте ошибку в протоколе. Юрист или владелец договора принимает решение по существу, а ИИ только помогает не потерять материал. При изменении условий вернитесь к карте и повторите сравнение.
Шаг 5. Сформируйте пакет на согласование
Хороший итог — не переписанный «улучшенный договор», а компактная ведомость: пункт, точная цитата, отличие от стандарта, вопрос, ответственный и статус решения. Приложите ссылки на файлы в разрешённом хранилище. Не отправляйте партнёру автоматически сгенерированные правки: сперва человек должен подтвердить смысл и полномочия. Сохраните версии ведомости, чтобы после переговоров было видно, какие замечания сняли и почему. Проверка завершается только тогда, когда ответственный подтвердил итог, а не когда модель написала заключительный абзац.
Как измерить пользу и где остановиться
Проведите пять тестов на старых договорах с известными замечаниями. Считайте найденные важные расхождения, ложные тревоги, пропуски и время человека до готовой ведомости. Сравните с обычным процессом без ИИ. Если модель регулярно путает редакции или выдумывает ссылки, пилот останавливают, даже когда тексты выглядят аккуратно. Полезна также проверка вторым сотрудником: может ли он воспроизвести результат по сохранённым файлам и инструкции? Для следующего этапа посмотрите новость о длинном контексте и практику проверки выводов по таблице. Частый вопрос: можно ли принять ответ без юриста? Для значимых условий — нет; роль модели вспомогательная.
Мини-чек-лист перед отправкой на согласование
Пройдите итоговую ведомость снизу вверх: у каждого замечания должен быть номер пункта, исходный фрагмент, эталон или причина вопроса, имя ответственного и статус. Пустая графа «основание» означает, что тезис нельзя отправлять как факт. Затем откройте все ссылки на страницы и убедитесь, что они ведут к подписанной версии, а не к раннему черновику. Сравните числовые значения в таблицах с основным текстом, отдельно проверьте валюту и даты. Если модель пометила условие как риск, попросите сотрудника объяснить, какое действие требуется и кому принадлежит решение. Наконец, сохраните первоначальный документ, рабочую ведомость и утвержденный вариант отдельно. Такой порядок позволяет воспроизвести работу после паузы и не выдать автоматически составленное предположение за юридическую позицию компании.
Проверка после переговоров
После согласования условий сравните финальный документ с ведомостью замечаний: не все принятые изменения обязательно попали в подписываемую версию. Проверьте перекрестные ссылки, номера приложений, дату и валюту. Отдельно отметьте, какие предложения были отклонены и кем. Не просите модель задним числом считать молчание согласием: статус каждого вопроса подтверждает участник переговоров. Если пришла новая редакция, повторите извлечение ключевых пунктов на ней, а не переносите выводы старого файла автоматически.