Более 2 000 дел о галлюцинациях ИИ в судах: что строить

Судебных решений о галлюцинациях ИИ уже более 2 000. Почему одного RAG оказалось мало и какие паттерны проектирования дала моя работа над ИИ для договоров.

По состоянию на 14 сентября 2026 года база AI Hallucination Cases Дамьена Шарлотена (Damien Charlotin) содержит 2 041 решение судов и трибуналов, связанное с контентом, выдуманным ИИ. В большинстве из них суд установил или косвенно указал, что сторона опиралась на такой контент; в виде исключения база включает и некоторые решения, где использование ИИ утверждалось, но не было подтверждено. Один только поиск по источникам проблему не решает: три ведущих инструмента для юридических исследований, протестированные в 2024 году в работе под руководством Стэнфорда, галлюцинировали каждый в 17–33% случаев. Строить нужно другое: структуру, при которой результат можно проверить, человека, который принимает решение, и набор для оценки, созданный раньше всего остального.

Я работал инженером по ИИ в проекте Kartez Contract. Ниже — что из этого опыта я бы сохранил и что сделал бы в первую очередь.

Что база дел о галлюцинациях ИИ говорит разработчикам, а о чём молчит

Число решений в базе Шарлотена превысило 2 000. Прежде чем приводить это число в питче или в записке о рисках, важно понимать три вещи.

База считает решения, а не ошибки. Она «не отслеживает (неизбежно более широкую) совокупность всех фиктивных ссылок или случаев использования ИИ в процессуальных документах». Это реестр сбоев, дошедших до судьи, а не частота галлюцинаций.

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

Категории важнее общего числа. В базе Шарлотена 1 690 решений помечены тегом Fabricated (выдуманное), 854 — тегом Misrepresented (искажённое) и 548 — тегом False Quotes (ложные цитаты), причём у одного решения может быть несколько тегов. Проверка того, что процитированный источник существует, способна отловить большую часть ошибок первого вида — выдуманные источники права. Два других вида она пропускает всякий раз, когда источник настоящий, но цитата выдумана или источник истолкован неверно. Инструмент для работы с договорами может допустить обе ошибки, ссылаясь при этом на пункт, который действительно существует.

Кроме того, Шарлотен насчитывает 1 174 решения, в которых ИИ использовала сторона pro se (человек, представлявший в суде себя сам), и 811 решений, где это был юрист, поэтому юридический ИИ-инструмент не может исходить ни из того, что в процессе участвует юрист, ни из того, что юрист заметит его ошибки. Самая крупная правовая область в его базе — Contract (договорное право): 449 решений. Речь о договорных спорах, в которых фигурировал контент, выдуманный ИИ, а не о договорах, составленных ИИ.

Предотвращает ли RAG галлюцинации юридического ИИ?

Нет. Стэнфордское исследование, о котором речь пойдёт ниже, приходит к выводу, что юридический RAG (retrieval-augmented generation, генерация с опорой на результаты поиска) «может снижать число галлюцинаций по сравнению с ИИ-системами общего назначения (в данном случае GPT-4), но галлюцинации остаются существенными, разнообразными и потенциально коварными». «Коварные» — точное слово: ответ с неверной опорой на источник приходит вместе с настоящим источником. Общая схема защиты описана в статье Гардрейлы против галлюцинаций в RAG.

Исследование под руководством Стэнфорда: 17–33%

В статье, размещённой на arXiv 30 мая 2024 года, учёные из Стэнфорда и Йеля представили «первую предварительно зарегистрированную эмпирическую оценку инструментов для юридических исследований на основе ИИ». Предварительная регистрация означает, что исследование и его набор из более чем 200 юридических запросов были зарегистрированы до проведения оценки: это защищает от подбора запросов под нужный результат. Некоторые поставщики продвигали поиск по источникам как средство, которое «устраняет» галлюцинации или позволяет их «избегать». Исследование показало, что Lexis+ AI, Westlaw AI-Assisted Research и Ask Practical Law AI галлюцинировали каждый в 17–33% случаев и что «заявления поставщиков преувеличены».

Определение важнее диапазона. Ответ считается галлюцинацией, «если он либо неверен, либо имеет неверную опору на источник» (misgrounded), а неверная опора означает, что ключевые утверждения «снабжены ссылкой, но неверно истолковывают источник или ссылаются на неприменимый источник». Инструменты тестировались в 2024 году и на задачах юридических исследований, а не на договорах, поэтому этот диапазон не характеризует юридический ИИ сегодня. Сама же категория переносится: в договоре ответ с неверной опорой на источник звучит правильно, но указывает не на тот пункт.

Вывод Google о достаточном контексте: больше контекста — меньше отказов от ответа

Статья «Sufficient Context» разграничивает ошибки, при которых модель неправильно использует хороший контекст, и ошибки, при которых контекста изначально не хватало для ответа. Более крупные из протестированных в ней моделей — от Google, OpenAI и Anthropic — при недостаточном контексте «часто выдают неверные ответы вместо того, чтобы воздержаться».

В обзоре этой работы в блоге Google Research (14 мая 2025 года) сказано, что RAG «как правило, повышает общее качество», но при этом «парадоксальным образом снижает способность модели воздерживаться от ответа, когда это уместно». В примере Google модель Gemma давала неверные ответы на 10,2% вопросов без контекста и на 66,1% — при недостаточном контексте.

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

Проверка договоров с помощью ИИ: какие сбои действительно важны

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

Паттерны проектирования ИИ для договоров: опыт Kartez Contract

С ноября 2025 по июль 2026 года я работал инженером по ИИ в проекте Kartez Contract — трёхъязычном рабочем пространстве для договоров с поддержкой письма справа налево, в котором были мастер составления, сценарий проверки и студия договоров. Я переработал и расширил ИИ-движок, на котором работают эти сценарии, взяв за отправную точку первые базовые ИИ-цепочки заказчика, и создал копилот, который классифицирует каждый запрос, находит релевантные пункты и планирует правки по всему договору.

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

Ответы только по пунктам, которые отобрал копилот

Договор пользователя разбивался по его собственной структуре, включая статьи, пункты и примечания (ماده، بند، تبصره), которые в персидских договорах нумеруются по-своему. Для ответа на вопрос использовались только релевантные ему разделы, а копилот получил инструкцию сообщать, когда нужны разделы, которых ему не показали.

Пункт — единица, с которой юрист и так работает, поэтому результат поиска, составленный из пунктов, асессор может разметить и проверить. Инструкция даёт модели альтернативу угадыванию, но это не принудительный шлюз, поэтому в наборе для оценки нужны вопросы, на которые отобранные пункты ответить не позволяют. У поиска по персидским текстам свои ловушки; для другой системы они разобраны в статье Гибридный поиск для персидского RAG.

Исправления, дословно цитирующие договор

Каждое предлагаемое исправление должно было дословно цитировать текущую формулировку, чтобы её можно было найти и заменить, и сопровождалось готовым текстом замены. Именно это требование делает возможной проверку дословной цитаты (exact-quote validation): программа может убедиться, что процитированный текст существует, до того как исправление будет применено.

Удачна ли переформулировка — вопрос юридической оценки. Существует ли предложение, которое она заменяет, — вопрос сравнения строк. Рекомендации OWASP по риску недостоверной информации в LLM формулируют общий принцип: «автоматически проверять ключевые выходные данные, особенно в средах с высокой ценой ошибки». Если бы я строил такую систему заново, я бы отбрасывал любое исправление, цитата из которого не найдена, никогда не применял бы его приблизительно, а число отброшенных исправлений отслеживал бы как ранний сигнал проблем.

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

Фиксированные схемы вывода и никакого сырого ответа на экране

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

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

Низкая случайность при составлении текста

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

Пошаговые сценарии, а не одно окно чата на все задачи

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

Anthropic в статье «Building effective agents» употребляет слово workflow — то, что здесь названо сценарием, — в смысле оркестрации: «системы, в которых LLM и инструменты оркестрируются по заранее заданным путям в коде». Там же сказано, что такие сценарии «обеспечивают предсказуемость и единообразие при чётко определённых задачах». У каждого фиксированного шага известная форма входных и выходных данных, которую можно проверить. Пустое окно чата принимает что угодно и возвращает что угодно.

Выделенные правки, которые пользователь принимает или отклоняет

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

Пользователю не нужно перечитывать документ: он оценивает отмеченные изменения. Переименование выделено везде, где оно применилось, и не всплывает позже как несоответствие.

Другая система: шлюзы в ассистенте этого сайта

Ничего из описанного в этом разделе не было частью Kartez Contract. Ассистент этого сайта, который я создал и поддерживаю, отвечает только на основе контента самого сайта и защищён детерминированными шлюзами.

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

• Диапазон ссылок. Каждый маркер ссылки указывает на источник, переданный модели.

• Обязательная ссылка. В каждом содержательном предложении есть маркер.

• Подтверждение значений. Каждое число, URL и адрес электронной почты присутствует в источнике, на который ссылается предложение.

• Грамматическое лицо. Ни в одном предложении нет местоимений первого лица, например I, me или we.

Одно предложение, не прошедшее проверку, останавливает ответ, и само это предложение никогда не показывается. Маркеры ссылок сначала проверяются, а затем удаляются, поэтому читатели их не видят.

Механизм описан в статье Гардрейлы для стриминга LLM. Демо «RAG против без RAG» выводит потоком настоящий ответ с опорой на источники рядом с колонкой без поиска, которая намеренно остаётся пустой; спросите о том, что не касается меня и чего на сайте нет, и запуск остановится, не дойдя до модели. Если бы я строил инструмент для договоров, я бы добавил такую же проверку для сумм, дат и наименований сторон, требуя, чтобы каждое значение дословно совпадало с источником.

Как оценивать юридический ИИ: сначала набор для оценки

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

1. Архитектурное ограничение — это гипотеза. «Исправления должны дословно цитировать договор» — это правило. Как часто модель его нарушает — это число, и получить его можно только с помощью набора для оценки.

2. Каждому изменению нужна регрессионная проверка. Без фиксированного набора любое изменение модели, промпта или поиска оценивается на глаз.

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

Что произошло с Kartez Contract

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

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

Набор для оценки на первую неделю: ИИ для договоров

Это рекомендация, а не описание того, что было в Kartez Contract. Каждая проверка бинарна: пройдена или не пройдена.

• Вопросы, на которые договор отвечает, с разметкой нужного пункта. Ответ должен быть верным и опираться на этот пункт.

• Вопросы, на которые договор ответить не может. Ожидаемый результат — «мне нужен раздел X» или «в договоре об этом не сказано», а не ответ.

• Запросы на правку. Каждый процитированный фрагмент в предложенном исправлении должен совпадать с исходным документом при сравнении строк.

• Правки всего договора. Переименование стороны должно изменить каждое вхождение и больше ничего.

• Значения, которые не должны меняться. Суммы, даты, сроки уведомления и наименования сторон, дословно сверенные до и после каждой переформулировки.

• Сломанный вывод. Оборванные и некорректно сформированные ответы никогда не должны попадать на экран в сыром виде, а восстановленный после обрыва ответ никогда не должен показываться как полный.

• Персидская структура. Нумерация по ماده, بند и تبصره, строки со смешанным направлением письма и персидские цифры.

• Обе стороны сделки. Один и тот же договор, проверенный с позиции каждой из сторон.

Сроки EU AI Act после Digital Omnibus: взгляд инженера

• Европарламент принял окончательный текст 16 июня 2026 года, Совет ЕС — 29 июня 2026 года.

• Маркировку контента, созданного ИИ, для систем, выведенных на рынок до 2 августа 2026 года, нужно обеспечить не позднее 2 декабря 2026 года.

• Остальные обязанности по прозрачности из статьи 50, например сообщать пользователям, что они имеют дело с ИИ-системой, применяются со 2 августа 2026 года.

• Обязательства для самостоятельных систем высокого риска из приложения III (Annex III) переносятся на 2 декабря 2027 года. Для ИИ, встроенного в продукты, на которые распространяется законодательство о безопасности из приложения I (Annex I), срок — 2 августа 2028 года.

Применимость регламента — вопрос к юристам. Ни один из паттернов выше не является мерой по обеспечению соответствия требованиям.

Чек-лист: разработка или покупка юридического ИИ

• На что опирается каждый ответ? На пункт или раздел, а не на «документ».

• Можно ли найти место каждой правки? Каждое изменение цитирует заменяемый текст, и цитата сверяется с документом.

• Может ли система сказать, что ответа нет? Попросите это продемонстрировать.

• Проверяется ли вывод перед показом? Сломанные ответы восстанавливаются или не показываются.

• Меняется ли что-нибудь без подтверждения? Не должно меняться ничего.

• Есть ли отдельный сценарий для каждой задачи? Составление, проверка и редактирование не должны делить одно окно чата.

• Сверяются ли значения дословно? Суммы, даты и наименования сторон — с источником.

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

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

Частые вопросы

Сколько дел о галлюцинациях ИИ дошло до судов?

По состоянию на 14 сентября 2026 года база AI Hallucination Cases Дамьена Шарлотена содержит 2 041 решение судов и трибуналов, связанное с контентом, выдуманным ИИ. В большинстве из них суд установил или косвенно указал, что сторона опиралась на такой контент; в виде исключения в базу включены и некоторые решения, где использование ИИ утверждалось, но не было подтверждено. База фиксирует решения, а не каждую фиктивную ссылку или каждый случай использования ИИ в процессуальных документах.

Снижает ли RAG галлюцинации юридического ИИ?

Снижает, но не устраняет. В предварительно зарегистрированной работе под руководством Стэнфорда три инструмента для юридических исследований, построенные на поиске по источникам, галлюцинировали реже GPT-4, но при тестировании в 2024 году каждый из них всё равно галлюцинировал в 17–33% случаев. Исследование Google о достаточном контексте показало, что более крупные модели, когда найденного контекста не хватает, часто отвечают неверно вместо того, чтобы воздержаться от ответа.

Может ли ИИ надёжно проверять договоры?

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

Что такое проверка дословной цитаты?

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

Почему для Kartez Contract нет показателя точности?

Заказчик остановил проект за месяц до завершения по причинам финансирования, связанным с войной, — до того, как был создан формальный набор для оценки. Этот сайт не называет примерных цифр там, где ничего не измерялось. Именно из-за этого пробела статья и настаивает на том, чтобы набор для оценки создавался первым.

Источники

• Дамьен Шарлотен (Damien Charlotin), AI Hallucination Cases Database, последнее обновление 14 сентября 2026 года, проверено 17 сентября 2026 года (CC BY 4.0).

• Varun Magesh, Faiz Surani, Matthew Dahl, Mirac Suzgun, Christopher D. Manning и Daniel E. Ho, «Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools» (2024).

• Hailey Joren, Jianyi Zhang, Chun-Sung Ferng, Da-Cheng Juan, Ankur Taly и Cyrus Rashtchian, «Sufficient Context: A New Lens on Retrieval Augmented Generation Systems» (2024).

• Google Research, «Deeper insights into retrieval augmented generation: The role of sufficient context» (14 мая 2025 года).

• OWASP GenAI Security Project, «LLM09:2025 Misinformation».

• Anthropic, «Building effective agents» (19 декабря 2024 года).

• Freshfields, «EU AI Act unpacked #34: The final Digital Omnibus on AI» (10 июля 2026 года).

• Кейс Kartez Contract на этом сайте.