شرح Habr AI لماذا يُعد استخدام Zero Shot لاستخراج المتطلبات من القوانين واللوائح التنظيمية أمرًا خطيرًا

На Habr AI вышел разбор о том, почему попытка вытянуть требования к ИТ-системе из закона одним zero-shot-запросом почти всегда даёт ложную уверенность. Автор утверждает, что проблема не в способности модели читать НПА, а в том, что между нормой и системным требованием лежит целая цепочка аналитических решений.

Почему закон не ТЗ

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

Перевести всё это в проектные требования одним шагом нельзя без потери смысла. Для аналитика это лишь сырой материал, а не готовая постановка задачи для команды разработки. Автор показывает, что Zero Shot слишком рано делает вид, будто работа уже закончена.

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

Где возникают потери Главная претензия к подходу — не просто неточность, а потеря управляемости.

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

• В ответе могут исчезнуть исключения и условия применения нормы Ограничения легко превращаются в функции Определения маскируются под полноценные требования Теряется субъект действия: кто инициирует, проверяет и фиксирует результат Пропадает трассировка от конкретной нормы к проектному выводу Из-за этого красивый ответ оказывается недоказуемым. Если кто-то в команде спросит, откуда взялся конкретный пункт, ссылки на статью закона будет недостаточно. Нужна трассировка: какой фрагмент нормы породил какой вывод и почему. Без неё любое требование уязвимо на обсуждении с юристами, аналитиками и разработкой, особенно если речь идёт о сложных сценариях, аудитах или регуляторных проверках. И чем строже регуляторная среда, тем дороже обходится такая непрозрачность.

Где Zero Shot полезен При этом автор не предлагает отказаться от LLM в работе с законодательством.

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

«Zero Shot можно использовать, чтобы начать работу с законом.

Но не стоит использовать его, чтобы считать эту работу законченной». Рабочая альтернатива выглядит менее эффектно, зато надёжнее: сначала определить, для какой роли и какого объекта автоматизации собираются требования, затем разложить текст на типы материала, восстановить субъектность, проверить полноту и только после этого превращать выводы в проектные артефакты. ИИ в такой схеме остаётся полезным помощником, но уже не подменяет саму аналитическую логику. Именно в таком режиме модель ускоряет работу, а не подменяет экспертизу.

Что это значит

Для команд, которые хотят ускорить legal analysis с помощью LLM, вывод простой: один красивый prompt не заменяет системный разбор НПА. Zero Shot годится для первого прохода и черновиков, но не для защищаемых требований, от которых зависят продуктовые решения, архитектура и соответствие закону. Иначе скорость на входе оборачивается ошибками уже на этапе реальных проектирования и согласований, а не только в теории.