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