На любой встрече про ИИ в анализе и проектировании довольно быстро возникает соблазнительный сценарий. Берём закон, вставляем его в модель и пишем:
Извлеки требования к системе.
Через минуту получаем аккуратный список формулировок в стиле «система должна». Выглядит убедительно. Кажется, что самая тяжёлая часть работы уже позади.
Но именно в этот момент обычно и появляется главная ошибка.
Потому что Zero Shot в такой задаче чаще всего выдаёт не требования, а правдоподобный текст, похожий на требования. Он может быть полезным как черновик. Может быстро дать первое приближение. Может помочь сориентироваться в документе. Но если воспринимать его как полноценный результат анализа законодательства, проект очень быстро начнёт платить за эту скорость потерей смысла, полноты и доказуемости.
Проблема не в том, что LLM «плохо понимают право». Проблема в том, что анализ законодательства для целей извлечения требований — это не одно действие, а цепочка разных аналитических переходов. И рекомендации по prompt engineering, и практики работы со сложными документами сходятся в одном: сложные многошаговые задачи лучше решать через декомпозицию, явные критерии качества и последовательные шаги, а не через один большой общий запрос.
Почему идея Zero Shot вообще кажется разумной
Логика у этого подхода очень понятная. Если упростить, она выглядит так:
закон уже содержит требования;
модель умеет читать текст;
модель умеет структурировать информацию;
значит, остаётся только правильно сформулировать запрос.
На уровне здравого смысла цепочка выглядит почти безупречно. Но в ней спрятана важная подмена: закон начинает восприниматься как почти готовое техническое задание, только написанное тяжёлым языком.
На практике закон устроен иначе. Он описывает не ваш сервис, а правовое поле. В нём живут роли, определения, условия, запреты, последствия, исключения и внешние отсылки. Даже в таких темах, которые кажутся очень близкими к цифровым продуктам, например в регулировании электронной подписи, базовые нормы сначала определяют правовой режим, а не экран, процесс или набор API. 63-ФЗ, например, определяет простую электронную подпись через коды, пароли и иные средства, а юридическую силу электронного документа связывает не просто с фактом подписи, а с условиями закона, НПА или соглашения между участниками взаимодействия. Это важная правовая основа, но это ещё не требования к конкретной системе.
Именно поэтому путь «закон → один запрос → готовые требования» выглядит гораздо короче, чем есть на самом деле.
Закон — это ещё не требования
Это первая вещь, которую полезно зафиксировать прямо.
В нормативном тексте обычно лежат по меньшей мере четыре разных типа материала:
определения объектов и статусов;
правила и действия участников;
условия, ограничения и исключения;
последствия и отсылки к другим нормам.
Для юриста такая смесь естественна. Для аналитика — нет. Проектной команде нужен уже другой результат: понимание того, что из этого относится к конкретному сервису, что должно лечь в процесс, что превратится в ограничение, а что вообще останется внешней нормативной рамкой.
Zero Shot эту разницу сглаживает. Он очень рано делает вид, что уже дошёл до «готовых требований», хотя на самом деле только переписал куски правового материала в более деловом стиле. Именно из-за этого в ответах модели так часто появляются красиво звучащие пункты, которые приятно читать, но очень трудно положить в архитектуру, бэклог или проверяемую спецификацию.
Первая большая ошибка: модель не выбирает, для кого строится результат
Закон почти всегда пишет сразу для нескольких ролей. В одном и том же акте могут фигурировать пользователь, организация, оператор системы, государственный орган, внешний контрагент, представитель, удостоверяющий контур и другие участники.
Но система почти никогда не строится «для всех сразу».
В реальном проекте всегда есть конкретный вопрос: для кого именно мы сейчас собираем требования? Для клиента? Для оператора системы? Для внутреннего контура компании? Для интеграционного модуля? Для интерфейса сотрудника?
Если этого вопроса нет, модель начинает делать то, что умеет лучше всего: добросовестно собирать всё, что похоже на значимое правило. В одном списке оказываются и обязанности организации, и действия пользователя, и внешние условия, и материал, который относится не к вашей системе, а к другому участнику процесса.
Отсюда возникает парадокс. Ответ выглядит «полным», но эта полнота относится не к проекту, а к домену в целом. То есть не к тому, что вам надо реализовать, а ко всему, что модель сумела заметить вокруг темы.
Вторая ошибка: Zero Shot смешивает определение, ограничение и действие
Юридический текст почти никогда не является линейным списком действий. В одной норме может одновременно жить определение объекта, условие его признания, правовое последствие и правило поведения.
Для аналитика это разные типы материала. Для Zero Shot — часто нет.
Поэтому модель регулярно делает одно из двух:
превращает определение в требование;
превращает ограничение в функцию.
На выходе получается формулировка, которая звучит серьёзно, но проектно ничего не решает. Это не требование, а перефразированная норма.
Проверить это довольно просто. Если после генерации вы не можете уверенно ответить на три вопроса — кто делает, что делает и где это живёт в системе, — то перед вами, скорее всего, ещё не требование, а промежуточный материал, который только выглядит законченно.
Третья ошибка: модель плохо работает с субъектом действия
Юридический язык очень любит пассивный залог: документ должен быть подписан, сведения должны быть предоставлены, доступ должен быть ограничен. Для права это нормально. Для проектирования — уже нет.
Системе нужна более жёсткая структура. Ей нужно понимать:
кто инициирует действие;
кто проверяет его допустимость;
кто фиксирует результат;
при каком условии правило вообще срабатывает.
Zero Shot часто либо сохраняет безличную конструкцию, либо молча подставляет субъекта сам. Первый вариант даёт красивую неопределённость. Второй — недоказуемую интерпретацию. Оба варианта опасны.
Именно поэтому юридически корректная фраза очень часто оказывается ещё сырым материалом для аналитика. Она может быть верна в правовом смысле, но недостаточна для процесса, интерфейса и системного поведения.
Четвёртая ошибка: всё слишком быстро превращается в «система должна»
Это один из самых коварных дефектов такого подхода.
Когда модель просят «извлечь требования», она почти неизбежно выравнивает результат под один жанр: список функций. На чтении это выглядит как плюс. Единый стиль, аккуратный формат, ощущение собранности.
Но закон порождает не только функции. Он порождает ещё и:
данные и статусы;
проверки и ограничения;
условия допустимости сценария;
ролевые правила;
журналирование и аудит;
внешние зависимости.
Если всё это насильно переписать в формате «система должна», получится очень плоский слой требований. Он будет выглядеть инженерно, но внутри окажется грубее и беднее исходного правового материала.
Именно так потом появляются системы, которые вроде бы «реализовали закон», но на самом деле не выдерживают ни юридической, ни процессной проверки.
Пятая ошибка: Zero Shot не показывает, что потерял по дороге
Это, пожалуй, главный инженерный риск.
Даже если список получился внешне аккуратным и разумным, по нему невозможно понять:
какие нормы вообще не попали в результат;
какие ограничения растворились в обобщённых формулировках;
какие исключения были проигнорированы;
какие роли исчезли по пути;
какие последствия утратили связь с исходной нормой.
То есть ответ есть, а карты потерь нет.
Для продуктового текста это не так страшно. Для анализа законодательства — критично. Здесь ошибка редко выглядит как стилистический дефект. Она выглядит как пропущенная проверка, неверная граница сценария, лишняя функция или неучтённый запрет.
И хуже всего то, что по самому ответу это почти не видно. Он может звучать очень уверенно и при этом быть неполным именно в самых дорогих местах.
Шестая ошибка: нет нормальной трассировки от нормы к требованию
В какой-то момент любая команда задаёт неудобный вопрос: откуда вообще взялся этот пункт?
Если на него нельзя ответить быстро и прозрачно, начинается типичный спор:
это прямое требование закона или интерпретация аналитика? это обязательная часть или просто разумное предположение? если убрать этот пункт, какой норме мы начнём противоречить?
Современные исследования traceability подчёркивают, что ценность требований определяется не только их формулировкой, но и связью с происхождением. До-требовательная трассировка нужна именно затем, чтобы понимать, из какого источника выросло требование и почему оно вообще появилось.
Zero Shot такую связь почти никогда не сохраняет. Он может сослаться на статью, но ссылка на статью — это ещё не полноценная трассировка. Трассировка — это когда можно показать, какой фрагмент нормы превратился в какой проектный вывод и почему.
Без этого список требований становится недоказуемым. Он может быть полезным, но он уязвим в любом серьёзном обсуждении.
Седьмая ошибка: один закон может породить несколько разных систем
Есть ещё одна вещь, которую Zero Shot очень любит скрывать. Он ведёт себя так, будто из закона автоматически следует одна очевидная система.
Но это не так.
Один и тот же нормативный материал может лечь в основу:
клиентского сервиса;
внутреннего контура компании;
интеграционного модуля;
слоя проверок;
журнала аудита;
ролевой модели;
или нескольких разных компонентов сразу.
То есть между законом и системными требованиями всегда стоит ещё один большой вопрос: что именно мы автоматизируем?
Пока не определены объект автоматизации и границы системы, разговор о «готовых требованиях к ИС» остаётся слишком ранним. Zero Shot этот архитектурный выбор не делает. Он создаёт видимость, будто он уже произошёл сам собой.
Почему это особенно плохо работает именно на законодательстве
Можно возразить, что всё сказанное относится вообще к любым сложным документам. Это верно только частично.
Юридические тексты дополнительно осложняют задачу своей длиной, плотностью терминов, множеством внешних отсылок и высокой ценой потери нюансов. Обзоры по legal information extraction отдельно отмечают, что для таких документов характерны длинный контекст, распределённость информации по разным частям текста и сложность извлечения структуры, а ошибки в извлечении здесь стоят особенно дорого.
На это накладывается и общая рекомендация по prompt engineering. И OpenAI, и Anthropic советуют использовать Zero Shot скорее как начальную точку, а не как финальную технику для сложного анализа. Для многошаговых задач они рекомендуют разбиение на последовательные шаги, уточнение критериев качества и добавление структурирующего контекста.
Именно поэтому правовой текст особенно плохо сочетается с надеждой на один красивый запрос.
Где Zero Shot всё-таки полезен
Было бы ошибкой после всего этого объявить Zero Shot бесполезным. У него есть своя нормальная область применения.
Он действительно полезен:
для быстрого входа в тему;
для первого обзора документа;
для черновой карты сущностей;
для гипотезы по сценариям;
для первичного понимания домена.
То есть Zero Shot хорош как стартовая разведка.
Но за пределами этой зоны начинается ответственность за полноту, применимость, границы системы и доказуемость результата. И там одного Zero Shot уже недостаточно.
Граница проходит довольно чётко: использовать его, чтобы начать разбираться в законе, — разумно. Использовать его как основание считать анализ завершённым — нет.
Что делать вместо этого
Ответ здесь не очень эффектный, зато рабочий: не пытаться заменить сложный аналитический процесс одним красивым запросом.
Надёжная альтернатива всегда включает несколько шагов. Нужно сначала понять, для кого и для какого объекта анализа строится результат. Потом разложить текст на разные типы материала. Затем отделить действия от определений и ограничений, восстановить субъектность, проверить применимость, оценить полноту и только после этого переходить к проектным артефактам и системным выводам.
ИИ в этом процессе полезен. Но полезен внутри шагов, а не вместо шагов. Он может ускорять разбор, помогать собирать черновики, подсвечивать проблемные места и поддерживать аналитику. Но не должен подменять собой саму логику анализа.
Вывод
Запрос «извлеки требования из закона» не бесполезен. Он просто решает гораздо более узкую задачу, чем кажется.
Он может дать:
первое приближение;
удобный черновик;
быстрый вход в домен;
список гипотез.
Но он не даёт автоматически:
выбранную роль;
честное разделение определения, ограничения и действия;
проектную атомарность;
проверку покрытия;
границы системы;
трассировку к источнику;
и защищаемый результат.
Поэтому самая короткая формулировка здесь такая:
Zero Shot можно использовать, чтобы начать работу с законом. Но не стоит использовать его, чтобы считать эту работу законченной.
Во второй статье я покажу уже практическую сторону: как выстраивать анализ так, чтобы ИИ действительно ускорял работу, а не производил убедительный, но недоказуемый текст.
