Александр Костин – Юрист без рутины: ИИ-инструменты для документов и споров (страница 5)
Четыре типичных класса ошибок ИИ в праве и как их ловить
Первый класс: выдуманные ссылки и «точные» формулировки норм.
Ловится запретом на конкретные номера статей без подтверждения и обязательной сверкой по первоисточнику.
Второй класс: пропуск условий и исключений.
Ловится вопросом: «при каких условиях это применимо?» и «какие исключения?». В проверке это отдельный пункт.
Третий класс: неверная процедура.
Ловится отдельной проверкой процедур: форма уведомления, сроки, доказательство доставки, претензионный порядок.
Четвертый класс: неверная квалификация отношений.
Ловится первичной диагностикой: что это за договор, какие элементы, нет ли переквалификации, нет ли специальных режимов.
Если вы системно ловите эти четыре класса ошибок, риск резко снижается.
Алгоритм проверки в 9 шагов: практическая последовательность
Шаг 1. Разметка утверждений.
Вы берете текст ИИ и помечаете все «категоричные» фразы: обязан, имеет право, незаконно, подлежит, должен, нельзя, допускается, срок, штраф, ответственность, подсудность. Это точки риска.
Шаг 2. Разделение на факты и право.
Каждое утверждение маркируется: это факт или правовой вывод. Факты должны иметь доказательства. Правовые выводы должны иметь основания и условия применимости.
Шаг 3. Проверка фактов по первичным документам.
Договор, переписка, акты, счета, платежи. Не по памяти, а по документу.
Шаг 4. Проверка терминов и определений.
Если в договоре есть определения «Работы», «Услуги», «Результат», «Срок», «Рабочий день», текст должен соответствовать этим определениям. ИИ часто использует термины в бытовом смысле.
Шаг 5. Проверка процедурных требований.
Как направлять, куда, в какие сроки, в какой форме. Если это претензия – убедитесь, что порядок соответствует договору и закону.
Шаг 6. Верификация права по первоисточникам.
Проверяете актуальную редакцию норм. Если вы в компании – используете ваш привычный источник (СПС, официальные публикации, внутренние базы). Если вы предприниматель – минимум сверка по официальным источникам и краткое подтверждение в надежной системе.
Шаг 7. Проверка на исключения и альтернативы.
Задаете контрольный вопрос: «что может сделать этот вывод неверным?» и включаете это в оценку рисков.
Шаг 8. Проверка на вредные формулировки.
Убираете признания, эмоции, криминализацию, двусмысленность, лишние обещания.
Шаг 9. Финальная сверка цели и стратегии.
Текст должен быть «про вашу цель»: либо мирное урегулирование, либо фиксация нарушения, либо подготовка к суду. Все лишнее удаляется.
Эти девять шагов – минимум. На практике это занимает меньше времени, чем кажется, потому что вы работаете по шаблону и быстро находите слабые места.
Система уровней доверия: как маркировать фрагменты текста для контроля
Чтобы не утонуть в проверке, полезно вводить уровни доверия к фрагментам.
Уровень A: подтверждено документом или договором (можно использовать).
Уровень B: правовой вывод вероятен, но требует сверки норм (использовать только после проверки).
Уровень C: гипотеза/вариант/предположение (не выпускать наружу как утверждение).
Уровень D: рискованная формулировка (признание/двусмысленность/провокация) – удалить или переписать.
Маркировка может быть даже внутри вашего рабочего файла. Это дисциплинирует: вы четко понимаете, что уже проверено, а что еще нет.
Проверка «двумя парами глаз»: когда она обязательна
Есть ситуации, где одного проверяющего недостаточно, потому что цена ошибки высока или ошибка трудно выявляется. Это:
подсудность и арбитражные оговорки; крупные суммы и лимиты ответственности; расторжение и односторонний отказ; персональные данные и конфиденциальность; интеллектуальная собственность; штрафы и неустойки; гарантийные обязательства и заверения; налоговые последствия и переквалификация.
В таких случаях правило простое: документ, подготовленный с участием ИИ, проходит вторую проверку другим человеком или тем же человеком через паузу с повторным прочтением по чек-листу. Это дешевле, чем спор.
Итоги
Валидация ответов ИИ в праве – это не «перестраховка», а обязательная часть процесса. Проверка должна быть двухслойной: факты и право. Внутри проверки есть три линии контроля: фактическая точность, юридическая применимость и документальная пригодность. Критические ошибки ИИ чаще всего в четырех местах: ссылки и нормы, условия применимости, процедура, квалификация отношений. Используйте алгоритм из девяти шагов и систему уровней доверия, и тогда ИИ станет ускорителем, а не источником скрытых юридических мин.
Глава 4 Договоры с ИИ: как собирать шаблоны, не плодя «юридические дыры»
Когда люди впервые начинают делать договоры через ИИ, они обычно получают два типа результата. Первый – короткий, «красивый» текст на две страницы, который выглядит аккуратно, но почти ничего не защищает. Второй – длинный «комбайн» на двадцать страниц, где есть все подряд, но половина пунктов либо конфликтует между собой, либо не подходит под конкретную сделку, либо вставлена как чужеродный стандарт без понимания последствий. Оба варианта опасны. Первый – потому что оставляет спорные зоны без регулирования. Второй – потому что создает ложное чувство защищенности и подбрасывает контрагенту точки атаки: противоречия, неопределенность, двусмысленные формулировки, несогласованные термины, неподходящие процедуры.
Эта глава про практическую архитектуру: как использовать ИИ для подготовки договоров так, чтобы он ускорял работу, но не генерировал «юридические дыры». Мы не говорим о «идеальном договоре на все случаи». Мы говорим о системе: библиотека модулей, регламент сборки, чек-листы проверок, правила формулировок и контроль того, что в договоре действительно управляет риском, а не просто занимает место.
Главная мысль: договор – это не текст, а механизм управления конфликтом
В нормальной сделке все идет гладко и без договора: люди договорились, выполнили, оплатили, разошлись. Договор нужен не для «хорошего сценария», а для плохого. Когда сроки сорваны, результат спорный, оплаты нет, контрагент исчез, меняет условия, требует лишнее, угрожает, не подписывает акты – именно тогда договор начинает «работать». Поэтому оценивать договор нужно по вопросу: что произойдет, если стороны поссорятся? Кто что должен доказать? Какие сроки и процедуры включатся? Какие права появятся? Какие ограничения сработают?
ИИ часто пишет договор «как красивый текст». Юрист должен заставить его писать договор как механизм: четкие триггеры, понятные процедуры, доказуемые факты, минимизация серых зон.
Почему ИИ плодит «дыры»: типовые причины
Первая причина – отсутствие ТЗ на договор. Пользователь просит «сделай договор оказания услуг», но не задает, что это за услуги, как измеряется результат, как принимается, как оплачивается, что считается нарушением, как расторгать, какие риски нужно закрыть. Модель вынуждена выдать средний шаблон.
Вторая причина – смешение разных типов договоров. В одном документе появляются элементы подряда, услуг, агентирования, лицензионного договора, трудовых отношений. Это дает противоречия и риски переквалификации.
Третья причина – вставка «стандартных» пунктов без привязки. Например, форс-мажор, конфиденциальность, персональные данные, интеллектуальная собственность, штрафы, подсудность – все есть, но написано так, что либо не применимо, либо конфликтует с предметом, либо не исполнимо, либо ухудшает вашу позицию.
Четвертая причина – отсутствие определения терминов. ИИ использует слова «услуги», «работы», «результат», «срок», «качество» в бытовом смысле. В споре это превращается в неопределенность.
Пятая причина – «много текста, мало процедуры». То есть есть красивые декларации («исполнитель обязуется обеспечить качество»), но нет механики: как измеряем качество, как принимаем, как фиксируем замечания, что если не ответили, что если отказались подписать акт, какие сроки на исправление.
Договор как конструктор: модульная библиотека вместо одного «универсального шаблона»
Самая практичная модель работы с ИИ – не генерировать каждый раз договор с нуля, а собрать библиотеку модулей и собирать договоры как конструктор под конкретную сделку.
В библиотеке должны быть:
Базовый каркас (универсальная структура договора).
Модули предмета (услуги, подряд, поставка, лицензия, агентирование – отдельно).
Модули приемки и результата (несколько вариантов под разные типы работ).
Модули оплаты (предоплата, постоплата, этапы, абонентка, ретейнер, смешанные схемы).
Модули ответственности (лимиты, исключения, штрафы, порядок начисления).
Модули расторжения (по соглашению, односторонний отказ, существенное нарушение, форс-мажор).
Модули прав на результаты и ИС (кому принадлежит результат, что можно использовать в портфолио, лицензии).