Александр Костин – Юрист без рутины: ИИ-инструменты для документов и споров (страница 7)

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

– могут быть сторонние лицензии;

– исходники могут быть коммерческой ценностью исполнителя;

– по некоторым услугам результат – это не объект авторского права, а процесс и консультация.

В договоре должно быть четко:

– что именно является результатом и объектом прав;

– переходит ли исключительное право или предоставляется лицензия;

– на какой срок, территорию, способы использования;

– что остается у исполнителя;

– что с портфолио и упоминанием клиента;

– что с материалами заказчика.

Это место не терпит «слепого» шаблона.

Пятая «дыра»: подсудность, претензионный порядок, уведомления

Договор может быть идеальным по сути и при этом провалиться процедурно. Если спор возник, важны:

– какой суд рассматривает;

– обязателен ли претензионный порядок;

– как направлять уведомления, чтобы потом доказать факт направления;

– какие адреса считаются юридически значимыми;

– что считается «получено» (дата доставки, дата отправки, подтверждение).

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

Проверка сборки: как не выпускать договор с противоречиями

Когда вы собираете договор из модулей, появляется новая угроза – внутренние противоречия. Например:

– в одном разделе написано «услуги», в другом «работы»;

– приемка по акту, но акт нигде не упомянут в документообороте;

– срок оплаты 5 дней в одном месте и 10 в другом;

– неустойка «за каждый день» без указания базы расчета;

– одновременно указана подсудность и арбитражная оговорка;

– права на результат «переходят после оплаты», но результат передается до оплаты без оговорок.

Чтобы это ловить, нужен финальный чек-лист сборки:

Единые термины и определения.

Согласованность сроков (сроки работ, сроки оплаты, сроки приемки, сроки уведомлений).

Согласованность документов (акт, отчет, ТЗ, заявки).

Согласованность ответственности (неустойка, лимит, исключения).

Согласованность прав на результат (момент перехода/лицензии).

Согласованность процедур (уведомления, адреса, каналы).

Соответствие экономике сделки (цена, этапы, риски).

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

Как правильно использовать ИИ при подготовке договора: рабочий алгоритм

Шаг 1. Сформировать ТЗ на договор.

Предмет, результат, приемка, оплата, сроки, права, риски, стратегия (жесткий/мягкий договор), контрагент (крупный/мелкий), критические ограничения.

Шаг 2. Выбрать каркас и модули.

Не генерировать договор целиком, а собрать: базовый каркас + модули предмета + модули приемки + оплаты + ответственности + расторжения + ИС + данных.

Шаг 3. Сгенерировать варианты спорных разделов.

ИИ особенно полезен там, где есть варианты: приемка, ответственность, права на результат, расторжение. Просите 2–3 версии с рисками каждой.

Шаг 4. Собрать черновик и запустить проверку противоречий.

Проверка по чек-листу сборки и по системе валидации из предыдущей главы.

Шаг 5. Адаптировать под переговорную реальность.

Некоторые формулировки могут быть юридически выгодны, но непроходимы в переговорах. Тогда вы делаете компромисс: сохраняете управляемость рисков, но смягчаете подачу.

Шаг 6. Финальная юридическая и фактическая верификация.

Особенно: приемка, сроки, ответственность, подсудность, ИС, данные.

Итоги

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

Глава 5 Претензии, письма, фиксация позиции: как писать с ИИ и не ухудшить себе доказательства

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

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

Письмо как доказательство: что суд и оппонент читают между строк

Суд и оппонент в переписке ищут не «красоту», а юридические маркеры:

– признание факта или долга;

– признание нарушения;

– согласование изменений договора;

– подтверждение получения результата;

– отказ от права;

– согласие на отсрочку/рассрочку;

– изменение цены;

– согласование сроков;