Claude для договоров: вычитка по пунктам и светофор рисков

Вычитка договора с Claude работает только в одном режиме: документ режется на пункты, и по каждому пункту модель обязана выдать дословную цитату, перевод на человеческий язык, сторону, в чью пользу написан пункт, и уровень риска по светофору. Запрос «прочитай договор и скажи, что не так» даёт красивый пересказ и пропускает половину. И сразу о границе: весь разбор нужен затем, чтобы прийти к юристу с готовыми вопросами, при этом подпись и ответственность за неё в любом случае остаются на человеке.

Каждый день в закрытом канале ИИмперии выкладываю, что нового происходит в работе с ИИ: разборы, готовые промпты и связки, шаблоны ролей цифровых сотрудников. Если статья зайдёт, там продолжение в ежедневном режиме.

Что Claude реально умеет в договоре?

Модель хорошо видит то, что написано: несимметричные обязательства, размытые формулировки, отсылки на несуществующие приложения, штрафы без потолка. С пустотами сложнее - отсутствующий пункт для неё просто не существует, судебной практики по твоей ситуации она тоже не знает. Отсюда и разделение ролей: механическая часть работы, то есть пройти документ целиком и разметить каждый пункт, достаётся Claude, а по любой спорной строке решение дальше принимает человек.

Работа с договором отличается от обычного «суммаризируй текст» тем, что цена пропуска высокая и несимметричная. Пропущенная удачная формулировка не стоит ничего, а право контрагента выйти из договора без уведомления всплывёт через полгода, когда контракт уже закончился и ты узнаёшь об этом последним.

Что модель делает уверенно:

• Переводит юридический язык на человеческий. «Заказчик вправе в одностороннем внесудебном порядке отказаться от исполнения» превращается в «он может выйти в любой момент, а ты нет».
• Ловит асимметрию. Считает, сколько прав у каждой стороны, и показывает перекос. Это самая полезная механика: перекос виден сразу, даже неспециалисту.
• Находит внутренние противоречия. В пункте 4.2 срок считается рабочими днями, дальше по тексту тот же срок оказывается календарным. Глазами такое расхождение ловится хорошо если с третьего прочтения, а построчный разбор вытаскивает его на первом.
• Проверяет ссылочную целостность. Пункт ссылается на Приложение №3, а приложений всего два.
• Считает сроки и деньги на словах. Сколько дней от подписания акта до оплаты, какая максимальная неустойка при просрочке в месяц.

Границы, за которые заходить бессмысленно:

• судебная практика твоего региона по конкретной формулировке ей неизвестна;
• договорённости «на словах» с контрагентом она не видит, пока ты их сам не перескажешь;
• переговорная сила в оценку не входит: плохой пункт иногда подписывают осознанно, потому что клиент того стоит;
• ответственности за совет она не несёт, поэтому последней инстанцией быть не может.

Если ты только присматриваешься к инструменту, полезно сначала понять что за модель Claude и чем она отличается по характеру, а потом уже грузить в неё контракт. Сравнивать модели тут имеет смысл по двум вещам: аккуратность с цитатами и длина контекста. По этим двум критериям выбор между Claude и ChatGPT обычно решается в пользу первого.

Почему разбор по пунктам даёт другой результат?

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

Формат ниже я собрал сам и обкатал на своих договорах подряда, оказания услуг и поставки. Вся его ценность держится на жёсткой форме вывода, которая гонит модель по документу целиком; на красоте формулировок в самом промпте итог почти не сказывается.

Механика простая. Ты задаёшь таблицу вывода, где каждая строка соответствует пункту договора. Модель физически не может проскочить пункт 5.4, не оставив пустую строку, а пустая строка видна глазом. Это тот же принцип, что и в работе с числами: когда просишь разобрать таблицу и формулы, результат резко улучшается от того, что ты задаёшь структуру ответа заранее.

Вместе со структурой появляется проверяемость. Фраза «есть риски по ответственности» в пересказе не даёт зацепиться: непонятно даже, о каком пункте речь, тогда как строка таблицы несёт цитату, которую ты за десять секунд находишь в исходнике поиском. Пустой результат поиска означает, что строку можно вычёркивать и заодно перепроверять весь блок вокруг неё.

Дальше начинает работать накопление. Один и тот же формат вывода на десяти договорах даёт сравнимые между собой результаты. Ты замечаешь, что пункт про порядок приёмки пропадает у тебя из раза в раз, и разговор смещается с конкретной сделки на твой процесс работы с документами.

Как устроен светофор рисков?

Светофор снимает расплывчатое «обратите внимание»: по каждому пункту приходится выбрать один из трёх уровней. Красным помечается пункт, который может стоить денег или контроля, и подписывать его без правки нельзя. Жёлтый достаётся управляемому перекосу - с таким пунктом реально жить, хотя поторговаться о нём стоит. Обычные рыночные формулировки остаются зелёными. Правило одно: критерий для каждого цвета ты описываешь заранее и дальше держишься за него, насколько бы страшно ни звучала формулировка.

Уровень	Критерий	Что делаешь
🔴 Красный	Пункт даёт одной стороне право менять условия, выходить из договора или взыскивать без потолка, а второй стороне такого права не даёт. Либо ставит под угрозу деньги, права на результат или данные	Не подписываешь. Готовишь встречную формулировку и несёшь юристу
🟡 Жёлтый	Формулировка размытая, срок не указан, ответственность есть, но несимметричная. Риск управляемый	Выносишь в переговоры. Если контрагент упёрся, решаешь осознанно, с открытыми глазами
🟢 Зелёный	Обычная рыночная формулировка, обе стороны в равных условиях	Пропускаешь
⚪ Серый	Пункта нет вообще, хотя для такого типа договора он нужен	Отдельный список «чего не хватает», второй проход

Серый уровень я добавил специально: это самая частая дыра. Модель разбирает выданный ей текст, и пустое место в документе для неё не существует, пока о нём не спросишь прямо.

Критерии в промпте приходится описывать словами. Если просто написать «оцени риск по светофору», модель будет ставить красный там, где ей кажется страшным, и разброс между двумя запусками окажется большим. Когда критерий проговорён, оценки становятся устойчивыми, и что важнее - ты можешь с ними спорить.

Ещё до промпта договорись сам с собой, на чьей ты стороне. Риск в договоре всегда чей-то: стопроцентная предоплата у исполнителя проходит зелёной строкой, тогда как заказчик в том же месте отдаёт деньги вперёд и ставит жёлтый. Поэтому первая строка промпта всегда одна и та же: «я выступаю исполнителем».

Эта статья закрывает один вопрос: как вычитать конкретный документ и ничего не пропустить. В общей картине вычитка договоров - это один участок работы, рядом стоят коммерческие предложения, счета, регламенты, переписка с клиентами, и каждый участок собирается по тому же принципу. Если хочешь увидеть картину целиком и разобрать её по шагам, можно забрать бесплатное обучение.

Как подготовить документ перед разбором?

Половина провалов случается до первого промпта. Модель получает кривой текст: съехавшую нумерацию после конвертации, потерянные приложения, скан с ошибками распознавания. На таком входе разбор выглядит уверенно и при этом врёт. Пять минут на подготовку окупаются полностью, потому что дальше проверять приходится только сам разбор - исходник к этому моменту уже приведён в порядок.

Что проверить перед загрузкой:

1. Формат. DOCX и текстовый PDF читаются нормально. Скан или фотография требуют распознавания, и после него текст нужно пролистать глазами: OCR любит терять запятые в суммах и путать 3 с 8. Ошибка в цифре ломает весь вывод по деньгам.
2. Комплектность. Договор без приложений - это половина договора. Смета, техзадание, регламент SLA, форма акта чаще всего лежат отдельными файлами, и именно там прячется самое интересное. Грузи всё вместе.
3. Нумерация. Проверь, что пункты пронумерованы сквозной структурой и нумерация не сбилась. Если в документе два раза встречается «4.2», модель начнёт их склеивать.
4. Допсоглашения. Если это не первый договор с контрагентом, действующая редакция может отличаться от исходной. Собери актуальную версию до разбора, иначе разберёшь неактуальное.
5. Обезличивание. Реальные ФИО, паспорта, счета и адреса для оценки рисков не нужны. Замени на роли. Об этом отдельно ниже, но делать это надо на этом шаге.

Технический момент для тех, кто работает из России: доступ к Claude требует отдельной настройки, и это решается один раз. Порядок действий разобран в материале про доступ к Claude из России, там же про то, какие варианты работают стабильно, а какие отваливаются через неделю.

Ещё одна вещь, которую полезно сделать заранее: собрать свой список стоп-правил. Это пять-десять формулировок, которые ты не подписываешь никогда, потому что уже обжигался. Список кладётся в проект вместе с твоим типовым договором, и модель сверяет входящий документ сразу с двумя эталонами - общей логикой и твоими личными запретами. Как оформить такой набор материалов, чтобы модель им реально пользовалась, описано в разборе про базу знаний для нейросети.

Какой промпт дать на первый проход?

Первый промпт задаёт роль, сторону, формат вывода и критерии светофора. Слова вроде «проанализируй профессионально» можно выбросить: модель и так старается, а вытягивает результат конкретика - что именно стоит в каждой ячейке таблицы и что делать с непонятным пунктом. Чем подробнее описан формат, тем меньше модель досочиняет от себя.

Вот рабочая заготовка, её можно копировать и править под себя:

Ты помогаешь мне подготовиться к разговору с юристом. Ты не даёшь
юридическую консультацию и не заменяешь юриста.

Контекст:
- Я выступаю [исполнителем / заказчиком].
- Тип договора: [оказание услуг / подряд / поставка].
- Сумма: [диапазон], срок: [сколько].
- Что для меня критично: [например, права на результат и сроки оплаты].

Задача: разобрать договор по пунктам. Для КАЖДОГО пункта дай строку
таблицы:

| Пункт | Цитата (дословно, до 25 слов) | Что это значит простыми словами |
В чью пользу | Риск | Почему такой риск | Предлагаемая правка |

Критерии риска:
- КРАСНЫЙ: пункт даёт другой стороне право менять условия, выходить
  из договора или взыскивать без ограничения суммы, а мне такого
  права не даёт. Либо ставит под угрозу оплату, права на результат
  или мои данные.
- ЖЁЛТЫЙ: формулировка размытая, срок или сумма не определены,
  ответственность несимметрична, но риск управляемый.
- ЗЕЛЁНЫЙ: обычная рыночная формулировка, стороны в равных условиях.

Правила:
1. Цитата только дословная. Если процитировать дословно не получается -
   пиши «цитата недоступна» и ничего не досочиняй.
2. Пункты не пропускай. Если пункт нечитаемый - строка с пометкой
   «не распознан».
3. Не оценивай судебную перспективу и не ссылайся на статьи законов,
   если не уверен в номере.
4. Разбирай блоками по 12 пунктов, в конце блока спрашивай, продолжать
   ли дальше.

Начни с пункта 1.

Разберу, зачем здесь каждое правило. Дословная цитата нужна для того, чтобы разбор можно было проверить поиском, а запрет на пропуск включает режим полного прохода. Блоки по двенадцать пунктов держат качество: когда модель гонит сорок строк подряд, к тридцатой строке цитаты становятся приблизительными, а формулировки шаблонными. Запрет на ссылки на статьи закона - защита от самой опасной галлюцинации: номер статьи выглядит убедительно и проверяется дольше всего.

Отдельно пропиши, что делать с пунктами-отсылками. Формулировка вида «в части, не урегулированной настоящим договором, стороны руководствуются Регламентом, размещённым на сайте Заказчика» выглядит технической деталью, при этом она означает, что вторая сторона может переписать условия в любой момент без твоего согласия. Такие пункты полезно сразу помечать красным на уровне правил промпта, иначе модель пройдёт мимо них.

Вывод удобно попросить сразу отдельным документом. Тогда таблицу можно листать, сортировать и отдавать юристу целиком; в ленте чата длинная таблица теряется уже через пару сообщений. Как это устроено технически, показано в материале про артефакты в Claude - там же про то, когда ответ имеет смысл превращать в файл, а когда это лишнее.

Как запустить второй проход и найти то, чего в договоре нет?

Первый проход разбирает написанное, и дыры при этом остаются невидимыми: отсутствующий порядок приёмки, неуказанный срок оплаты, молчание про права на результат. Под них нужен отдельный запрос со своим чек-листом, потому что работа здесь устроена как сверка с эталоном, а эталон ты приносишь свой - готового списка под твой тип сделки у модели нет.

Промпт второго прохода:

Теперь другая задача. Разбирать уже написанные пункты не нужно.
Проверь, каких пунктов в договоре НЕТ, хотя для договора [тип] они
обычно нужны.

Пройди по списку и по каждому ответь: есть / нет / есть, но неполно.

1. Предмет: описан конкретно или «услуги по согласованию сторон»?
2. Сроки: начало, окончание, промежуточные этапы.
3. Порядок приёмки: кто подписывает акт, за сколько дней, что если
   молчит.
4. Мотивированный отказ от приёмки: в какой форме, в какой срок.
5. Порядок оплаты: сумма, этапы, срок от какого события.
6. Что считается моментом оплаты: списание со счёта плательщика или
   зачисление на мой.
7. Налоговый статус сторон, НДС, кто платит какие налоги.
8. Ответственность за просрочку: с обеих сторон, с потолком или без.
9. Ограничение общей ответственности суммой договора.
10. Порядок изменения условий.
11. Расторжение: основания, уведомление, срок, последствия.
12. Автопролонгация и как из неё выйти.
13. Конфиденциальность: что считается тайной, сколько действует.
14. Права на результат: когда переходят, в каком объёме, что если
    оплата не прошла.
15. Право на портфолио и упоминание клиента.
16. Форс-мажор: симметричен ли.
17. Досудебный порядок и срок ответа на претензию.
18. Подсудность: чей город.
19. Уведомления: какие адреса и каналы считаются надлежащими.
20. Приоритет документов, если договор и приложение противоречат.

Формат ответа: номер, название, статус, что это значит для меня,
уровень риска по светофору.

Список правится под твой бизнес. Дизайнеру важнее всего права на результат и возможность показать работу в портфолио. В поставке на первое место выходит момент перехода риска случайной гибели товара и приёмка по количеству, а агентству приходится отдельно прописывать ответственность за действия субподрядчиков.

Серый уровень светофора живёт именно здесь. Пункт про мотивированный отказ от приёмки пропадает из договоров услуг чаще остальных, и без него заказчик может тянуть подписание акта сколько угодно. В первом проходе этой строки не будет никогда, потому что разбирать нечего.

Как это выглядит на практике. Договор оказания услуг на десять страниц, первый проход даёт две красные строки и шесть жёлтых, картина на вид рабочая. Второй проход добавляет к ним три серые: срок подписания акта не назван вообще, момент перехода прав на результат привязан к «завершению работ» без определения этого завершения, последствия молчания заказчика после сдачи не описаны. Три дыры вместе дают заказчику возможность пользоваться результатом и не платить, формально ничего не нарушая, хотя по отдельности каждая звучит скучно. Опасность здесь собирается из пустот между пунктами, поэтому при обычном чтении её и не видно.

Какие пункты чаще всего проскакивают мимо глаз?

Мимо внимания проскакивает самое скучное и стоящее в конце документа. Разделы про уведомления, приоритет документов и порядок изменения условий читаются по диагонали, а именно там прячутся механизмы, которые срабатывают через полгода. Такие пункты полезно гонять отдельным проходом, уже зная, что конкретно ищешь.

Пункт	Как выглядит безобидно	Чем оборачивается
Одностороннее изменение условий	«Заказчик вправе изменить объём работ, уведомив Исполнителя»	Объём вырос вдвое, цена та же
Момент оплаты	«Обязательство считается исполненным с момента списания средств со счёта Плательщика»	Деньги зависли в банке, формально он уже заплатил
Уведомления	Указан один e-mail, без почтового адреса	Письмо ушло на несуществующий ящик, уведомление считается надлежащим
Автопролонгация	«Договор продлевается, если ни одна из сторон не заявит об отказе за 30 дней»	Забыл про срок - ещё год обязательств
Приоритет документов	«В случае противоречий применяется Приложение №1»	Приложение написано контрагентом и отменяет твои условия
Права на результат	Про переход прав сказано, про условие оплаты не сказано	Результат используют, деньги не пришли
Потолок ответственности	Потолка нет вообще	Неустойка 0,5% в день без ограничения превращается в сумму больше договора
Подсудность	«Споры рассматриваются по месту нахождения Заказчика»	Суд в другом городе, и судиться дороже, чем простить
Гарантийный период	Срок есть, объём гарантии размыт	Бесплатные доработки без конца
Субподряд	«Исполнитель не вправе привлекать третьих лиц»	Половина твоей схемы работы вне закона по договору

Эта таблица хорошо работает как дополнительный вход в промпт. Отдаёшь её модели целиком и просишь проверить договор конкретно по этим десяти сюжетам, отдельно от общего прохода. Совпадения находятся быстро, а формулировка «чем оборачивается» помогает модели не проглотить пункт как стандартный.

Отдельно про суммы. Проси считать вслух: «при просрочке на 45 дней неустойка составит столько-то рублей, что равно стольким-то процентам от суммы договора». Абстрактные «0,5% за каждый день» перестают быть абстракцией ровно в тот момент, когда превращаются в число. Тот же приём работает в любой аналитике: правильные вопросы к цифрам разобраны в материале про ИИ для бизнес-аналитики.

Как проверить, что модель ничего не выдумала?

Проверка занимает меньше времени, чем кажется, и без неё вся схема бессмысленна. Три действия: сверить цитаты поиском по документу, пересчитать количество строк против количества пунктов, перепроверить все красные строки вручную. Всё остальное можно доверить. Делается это один раз, до того как разбор уйдёт юристу или контрагенту.

Порядок такой:

1. Поиск по цитате. Берёшь строку таблицы, копируешь цитату, ищешь в исходном файле. Дословное совпадение подтверждает, что пункт существует. При пустом результате строка вычёркивается с пометкой, что модель поплыла. Достаточно проверить все красные и выборочно треть жёлтых.
2. Счёт строк. В договоре 47 пунктов, в таблице 41 строка. Шесть пунктов пропущены, и надо выяснить какие. Занимает эта проверка полминуты, а ловит больше всего.
3. Ручное чтение красной зоны. Красных строк обычно три-семь. Их ты читаешь в оригинале сам, целиком, вместе с соседними пунктами. Контекст соседних пунктов меняет смысл чаще, чем хотелось бы.
4. Контрольный запуск. Тот же документ, тот же промпт, новый чат. Совпадение красных пунктов говорит, что оценка устойчивая. Если красные разъехались по разным местам документа, значит, критерии описаны слабо и их надо ужесточать.
5. Проверка ссылок на закон. Если модель всё-таки назвала номер статьи, проверяешь его в справочной системе. Номера статей - самое частое место, где генерация выглядит достоверно и при этом не соответствует действительности.

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

Частое возражение: если всё равно приходится всё перепроверять, в чём выигрыш. Считать надо по объёму работы. Чтение сорока семи незнакомых пунктов с нуля, с удержанием связей между ними в голове, забирает час-полтора концентрации. На проверку цитат по готовой разметке, пересчёт строк и вдумчивое чтение пяти красных пунктов уходит минут двадцать, причём работа эта механическая и спокойно делается в конце дня. Плюс проверка направленная: ты знаешь, что именно ищешь, и не рискуешь пропустить то, на что никогда не обратил бы внимания.

Правки для контрагента: как собрать список?

Разметка рисков сама по себе ничего не меняет. Дальше нужен документ, который уйдёт второй стороне: перечень правок с формулировками и коротким обоснованием. Черновик такой таблицы Claude собирает хорошо, потом формулировки уходят на проверку юристу, и уже после этого ты определяешь, за что торгуешься. Без этого шага разбор остаётся файлом, который никто не открывает.

Промпт для этого шага:

На основе разбора собери таблицу правок для контрагента.

Колонки: пункт, текущая редакция (цитата), предлагаемая редакция
(готовый текст), обоснование одной фразой на нейтральном языке,
приоритет (принципиально / желательно / опционально).

Тон обоснований: деловой, без обвинений. Формулировки вида
«предлагаем уточнить для однозначности толкования».

Принципиальными делай только красные пункты, их должно быть не
больше пяти.

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

Дальше начинается человеческая часть, которую нельзя делегировать. Ты решаешь, какие пункты действительно принципиальны для этой сделки, а какие можно отдать. Модель не знает, что этот клиент приведёт ещё троих, а другой платит с задержкой в два месяца и потолок ответственности с ним нужен любой ценой. Оценка контрагента, история отношений и цена срыва сделки - зона, где решение принимаешь ты сам.

Готовую таблицу правок несёшь юристу. Разговор при этом меняется: приходишь с размеченным документом и конкретными вопросами по пяти пунктам, и специалист сразу занимается оценкой, потому что первое чтение уже проделано до него.

Что нельзя загружать в чат и почему это не паранойя?

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

Что убрать:

• ФИО физлиц, паспортные данные, адреса регистрации;
• номера счетов, карт, реквизиты банков;
• коммерческие условия, которые сами по себе тайна: конкретные скидки, себестоимость, эксклюзивные условия;
• данные третьих лиц, которых в этом договоре вообще нет.

Оставить в тексте обязательно:

• структуру пунктов и нумерацию;
• сроки, проценты, порядок расчётов в относительном виде;
• тип договора и роли сторон.

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

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

Где эта схема ломается?

Ломается она в четырёх местах: длинный документ, скан вместо текста, договор с кучей приложений и нетиповая конструкция сделки. Симптом во всех случаях одинаковый: вывод выглядит гладким, а проверка цитат показывает, что модель соскользнула в пересказ. Чем раньше поймаешь симптом, тем меньше придётся переделывать.

Длинный документ. На пятидесяти-шестидесяти пунктах качество проседает к концу: цитаты становятся приблизительными, риски однотипными. Лечится разбивкой на блоки по 12-15 пунктов с явной отсечкой. Каждый блок отправляй отдельным сообщением с указанием номеров пунктов, потому что короткое «продолжай» модель понимает слишком вольно.

Скан. Распознавание путает цифры, теряет структуру списков и склеивает пункты. Дальше модель честно разбирает то, что видит, и разбор получается про другой договор. Единственное лечение - вычитать распознанный текст глазами до загрузки, особенно все числа.

Приложения. Основной договор может быть безупречен, а вся кабала прописана в Приложении №2 про порядок приёмки. Если приложения не загружены, разбор бессмысленно оптимистичен. Проверяй комплектность до старта.

Нетиповая сделка. Инвестиционные соглашения, лицензионные договоры со сложной структурой роялти, корпоративные договоры - здесь модель уверенно говорит общие вещи и легко проскакивает именно ту конструкцию, ради которой договор и составлялся. В таких документах вычитка через ИИ годится максимум для того, чтобы понять, что здесь вообще написано; до оценки рисков её выводы не дотягивают.

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

Как встроить вычитку в постоянный процесс?

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

Порядок сборки:

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

Реестр стоит завести даже при трёх договорах в квартал. Через год в нём видно то, чего не видно внутри отдельной сделки: например, что потолок ответственности тебе сбивают в каждом втором договоре и ты каждый раз уступаешь, или что красные пункты почти всегда приходят от одного типа контрагентов. Дальше с этим можно работать заранее - переписать свой шаблон, поменять стартовую позицию в переговорах, добавить пункт в стоп-правила.

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

Кто за что отвечает в этой схеме?

Разгружается один этап - первый проход: незнакомый договор больше не приходится читать с нуля, ты запускаешь разбор и проверяешь выданное. Решения, ответственность и переговоры остаются на человеке в прежнем объёме. Дальше в таблице видно, какой этап кому достаётся и почему граница проходит именно там.

Этап	Кто делает	Почему так
Подготовка и обезличивание файла	Человек, потом по шаблону	Требует знания, что именно чувствительно в этом документе
Разбор по пунктам, светофор	Claude	Механическая полнота, где человек устаёт и проскакивает
Поиск отсутствующих пунктов	Claude по твоему чек-листу	Чек-лист составляешь ты, дальше модель идёт по нему подряд
Проверка цитат	Человек	Единственная защита от выдуманной строки
Оценка красной зоны	Человек + юрист	Правовая оценка и практика
Выбор, за что торговаться	Человек	Зависит от отношений с контрагентом и цены сделки
Черновик таблицы правок	Claude	Форма и формулировки, дальше проверка
Финальные формулировки и подпись	Юрист и ты	Ответственность не делегируется

Главное, что даёт такой заход, - полнота прохода. Скучный документ плюс дедлайн завтра означают, что человек читает договор один раз и по диагонали; у модели сороковой пункт получает столько же внимания, сколько первый, и к концу документа она не выдыхается. В праве она разбирается слабее юриста, и вся её польза держится именно на выносливости.

И ещё раз о границе, потому что это важнее всего остального в статье. Формулировки промпта здесь ничего не меняют: на выходе получается подготовительная работа для юриста, которая помогает прийти к специалисту с конкретными вопросами по пяти размеченным пунктам. Решение о подписании принимает человек, который за него отвечает, и подстраховка юристом на значимых суммах не отменяется ничем.

Источники

• Документация Anthropic - официальное руководство по работе с Claude: формулировка задачи, роль, структура вывода, загрузка файлов
• Справочный центр Claude - настройки аккаунта, проекты, работа с файлами
• Центр приватности Anthropic - что происходит с загруженными данными и как настроить хранение
• Гражданский кодекс РФ, часть первая (КонсультантПлюс) - общие положения о договоре, заключении, изменении и расторжении
• Федеральный закон № 152-ФЗ «О персональных данных» (КонсультантПлюс) - что считается персональными данными и почему документ стоит обезличивать
• Официальный интернет-портал правовой информации - первоисточник действующих редакций нормативных актов
• Гарант - справочная система для проверки номеров статей и действующих редакций