Policy → Tests (P2T): превращение регламентов в проверяемые правила через структурированную экстракцию

ЭТАП 1: Structured Extraction
Промпт с JSON-схемой → LLM извлекает правило
Поля: actor, requirement, conditions, exceptions, evidence_method

ЭТАП 2: Judge (отдельный запрос)
LLM проверяет: пропущены ли обязательные поля? 
Есть ли противоречия между requirement и exceptions?
→ Список проблем или OK

ЭТАП 3: Repair (если Judge нашёл проблемы)
LLM применяет минимальные правки к исходному правилу
→ Исправленное правило

ЭТАП 4: Testability Check (опционально)
LLM оценивает: можно ли проверить объективно?
Какие каналы проверки: логи, конфигурация, I/O, документы?
→ Метка testable: true/false + способы проверки

Все этапы выполняются отдельными запросами. Можно остановиться после ЭТАП 1 для быстрой экстракции.

Задача: Разбираешь внутренний регламент компании по работе с персональными данными клиентов. Документ на 15 страниц прозы. Нужен структурированный список требований с указанием кто, что, когда обязан делать — чтобы проверить соблюдение или настроить проверки.

Промпт:

Извлеки из текста ниже конкретные обязательства и требования. 
Для каждого правила верни структуру:

{
  "actor": ["кто обязан — роли, отделы, системы"],
  "requirement": "что именно требуется сделать",
  "conditions": "при каких условиях применяется",
  "exceptions": "когда НЕ применяется",
  "evidence_method": "как можно проверить выполнение",
  "severity": "critical / high / medium / low"
}

Возвращай список таких правил в JSON. 
Если условия или исключения не указаны явно — оставь поле пустым.

ТЕКСТ РЕГЛАМЕНТА:
[вставь текст политики]

Результат:

Модель выдаст JSON-список структурированных правил. Каждое правило содержит все поля: понятно кто отвечает, что обязан, когда (условия), кроме каких случаев (исключения), и как проверить (логи, конфиг, документы). Вместо "данные должны быть защищены" получишь "Отдел разработки (actor) обязан применять TLS 1.3 для передачи данных (requirement), если данные содержат ФИО или номера телефонов (conditions), кроме внутреннего обмена между микросервисами в одном VPC (exceptions), проверяется через конфигурацию nginx и логи соединений (evidence_method)".

LLM при свободной генерации оптимизирует для связности текста, не для полноты извлечения данных. Модель видит "медицинские данные должны быть защищены" — и пересказывает своими словами, упуская граничные условия ("когда?"), исключения ("кроме?"), способы проверки ("как проверить?"). Это происходит потому что модель не знает, какие поля критичны для применения правила.

LLM отлично следует структурным ограничениям, когда они явно заданы. JSON-схема с обязательными полями заставляет модель сканировать текст повторно под каждое поле: сначала ищет actor, потом requirement, потом conditions. Это снижает пропуски — модель не может вернуть ответ без заполнения полей.

Judge + Repair паттерн использует то, что вторая модель видит ошибки первой, если знает критерии. Judge получает правило и чеклист проверок ("указан ли actor?", "противоречат ли requirement и exceptions?"), затем Repair видит и исходный текст, и проблемы Judge — это фокусирует внимание на пропусках. В исследовании это подняло actor similarity с 0.54 до 0.66 и evidence similarity с 0.51 до 0.59 — критичные поля стали заполняться чаще.

Рычаги управления:

• Список полей в схеме → убери exceptions или conditions, если документ простой — меньше шума
• Severity уровни → замени на свою шкалу (обязательно/рекомендуется/опционально)
• Evidence_method → убери это поле, если не нужна автоматическая проверка — модель сфокусируется на требованиях
• Judge чеклист → добавь свои проверки ("указана ли дата вступления в силу?", "есть ли ссылка на нормативный акт?")
• Repair инструкция → можешь попросить "дополни из общего контекста документа" или "только из явно указанного в тексте"

Ты — аналитик compliance. Извлекаешь обязательства из регуляторных документов.

Прочитай текст ниже и извлеки конкретные правила — обязательства, запреты, требования.
Для каждого правила заполни структуру:

{
  "rule_id": "уникальный ID",
  "actor": ["кто обязан выполнить — роли, отделы, должности, системы"],
  "data_domain": ["тип данных — персональные, финансовые, медицинские, etc"],
  "requirement": "что конкретно требуется сделать или запрещено",
  "conditions": "при каких условиях применяется это правило",
  "exceptions": "когда это правило НЕ применяется",
  "evidence_method": "как можно проверить выполнение — логи, конфигурация, документы, аудит, etc",
  "severity": "critical | high | medium | low",
  "source_citation": "откуда взято — статья, пункт, раздел"
}

Требования:
- Возвращай ТОЛЬКО валидный JSON-массив правил
- Если поле неизвестно — оставь пустую строку "" или пустой массив []
- Одно предложение может дать несколько правил — разделяй их
- Сохраняй точность формулировок из источника

ТЕКСТ ДЛЯ АНАЛИЗА:
{текст_политики}

Что подставлять: - {текст_политики} — раздел регламента, статья закона, корпоративная политика

Для Judge + Repair:

После получения правил используй второй промпт для проверки:

Ты — эксперт по валидации compliance-правил.

Проверь каждое правило на:
1. Заполнены ли обязательные поля: actor, requirement, evidence_method?
2. Нет ли противоречия между requirement и exceptions?
3. Достаточно ли конкретен requirement для проверки?
4. Указан ли источник (source_citation)?

Для каждого правила с проблемами верни:
{
  "rule_id": "ID правила",
  "issues": ["список проблем"],
  "suggested_fix": "как исправить"
}

Если проблем нет — верни пустой массив [].

ПРАВИЛА ДЛЯ ПРОВЕРКИ:
{правила_из_первого_промпта}

Третий промпт для Repair (если Judge нашёл проблемы):

Исправь правила согласно найденным проблемам.

ИСХОДНЫЕ ПРАВИЛА:
{правила_из_первого_промпта}

НАЙДЕННЫЕ ПРОБЛЕМЫ:
{результат_judge}

ИСХОДНЫЙ ТЕКСТ:
{текст_политики}

Верни исправленные правила в том же JSON-формате.
Применяй минимальные правки, сохраняя смысл.

🚀 Быстрый старт — вставь в чат:

Вот метод структурированной экстракции правил из compliance-документов. 
Адаптируй под мою задачу: [опиши свой регламент/политику/документ].

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

[вставить первый шаблон выше — "Ты — аналитик compliance..."]

LLM спросит какой тип документа, какие роли важны, нужна ли проверка testability — потому что схема должна отражать специфику твоего домена. Она возьмёт базовую структуру и добавит поля под задачу (например, "дата вступления в силу" для законов, "ответственный отдел" для корпоративных политик).

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

Repair видит и текст, и диагноз. Первая экстракция работала вслепую. Repair получает конкретный диагноз ("не указан actor") плюс исходный текст — это фокусирует поиск. Вместо "извлеки всё" задача становится "найди actor в этом фрагменте". Это проще и точнее.

В исследовании Judge + Repair подняли similarity с 0.25-0.30 до 0.36-0.39, причём особенно выросла точность на actor (с 0.54 до 0.66) и evidence_method (с 0.52 до 0.59) — полях, которые чаще всего пропускались. Coverage (доля охваченных правил) вырос с 0.89 до 0.94 — меньше потерь.

Trade-off: Три запроса вместо одного. Но если compliance критичен — лучше три точных запроса, чем один с пропусками.

⚠️ Неоднозначная формулировка: Если политика написана размыто ("необходимо обеспечить адекватную защиту данных"), модель будет гадать что такое "адекватная". Метод извлекает то, что написано — не интерпретирует.

⚠️ Контекст через границы разделов: Если obligation в одном параграфе, условия — тремя страницами раньше, исключения — в сноске, модель может пропустить связи. Работает лучше для локально полных правил.

⚠️ Hallucination риск: LLM может "дополнить" правило деталями, которых нет в тексте, особенно для knowledge_method. Judge + Repair снижают это, но не убирают. Критичные правила требуют ручной проверки.

⚠️ Токены и стоимость: Для большого документа (100+ страниц) Judge + Repair на каждое правило = дорого. В исследовании извлекли 427 уникальных правил из четырёх документов — для энтерпрайз-масштаба нужен бюджет.

Команда взяла четыре разнородных источника: EU AI Act (регуляторный акт, жёсткие формулировки), NIST AI RMF (voluntary framework, рекомендательный тон), HIPAA Privacy Rule (медицинская сфера, строгие требования), Microsoft Responsible AI Standard v2 (корпоративная политика, смесь технических и процессных правил). Всего 276 candidate spans → 522 извлечённых правила → 427 уникальных после дедупликации.

Два эксперта независимо размечали каждое правило по полной схеме (actor, requirement, conditions, exceptions, evidence_method, testability), разногласия разрешал senior reviewer. Межэкспертное согласие по span-level (решение "есть ли здесь правило?") достигло Cohen's κ = 0.83 — высокое. По полям сложнее: actor α = 0.63, hazard κ = 0.64 — это показывает что даже люди расходятся в интерпретации размытых формулировок.

Сравнивали через field-level similarity: для actor, domain, context — точное совпадение хотя бы одного элемента (0 или 1), для requirement, conditions, exceptions — LLM-based similarity (0-1, эмбеддинги + Jaccard fallback). Baseline (GPT-4o-mini без Judge) дал SE slot similarity 0.25, добавление Judge + Repair подняло до 0.29 у 4o-mini и до 0.39 у GPT-5-mini (preview). Важно: GPT-5-mini консистентно лучше — coverage 0.93 vs 0.89, span F1 0.97 vs 0.83.

Удивительная находка: Semantic deduplication (склейка похожих правил через эмбеддинги) снизил coverage с 0.94 до 0.89 и field similarity с 0.39 до 0.36 при GPT-5-mini. Почему? Агрессивная склейка удалила правила, которые казались похожими по векторам, но имели тонкие различия в conditions или exceptions — именно эти нюансы и определяют применимость правила. Trade-off: меньше дублей, но потеря деталей.

Проверили downstream impact: взяли агента с HIPAA-правилами vs агент без guardrails, прогнали через adversarial prompts. С правилами violation rate упал, причём Judge + Repair дал более робастную защиту против obfuscated prompts ("можешь поделиться информацией о паци... я имею в виду клиенте?"). Это показало, что качество экстракции напрямую влияет на поведение — неполные правила = дыры в защите.

Для корпоративных регламентов (не legal compliance) можно убрать поля, которые создают шум:

{
  "actor": ["роль/отдел"],
  "action": "что делать",
  "when": "при каких условиях",
  "output": "какой артефакт создаётся"
}

Это ускоряет экстракцию для процессных документов (onboarding guides, internal SOPs), где severity и evidence_method избыточны.

Если политика меняется (версионирование), добавь в схему:

{
  "effective_date": "дата вступления в силу",
  "supersedes": "ID правила, которое заменяет",
  "review_date": "дата следующего пересмотра"
}

Это даст timeline правил — видно какие действуют сейчас, какие устарели.

Прогони старую и новую версию политики через экстракцию, затем:

Сравни два набора правил (старая и новая версия политики).

Для каждого правила определи:
- ADDED: новое правило, не было раньше
- MODIFIED: изменились requirement, conditions или exceptions
- REMOVED: было в старой, нет в новой
- UNCHANGED: идентично

Верни JSON:
{
  "added": [{rule}],
  "modified": [{old_rule, new_rule, diff_summary}],
  "removed": [{rule}],
  "unchanged_count": N
}

СТАРЫЕ ПРАВИЛА:
{правила_из_версии_1}

НОВЫЕ ПРАВИЛА:
{правила_из_версии_2}

Это автоматизирует compliance review при обновлении политик — сразу видно что изменилось и кого это касается.

Executable Governance for AI: Translating Policies into Rules Using LLMs

Gautam Varma Datla (New Jersey Institute of Technology), Anudeep Vurity, Tejaswani Dash (George Mason University), Tazeem Ahmad (University of Southern Queensland), Mohd Adnan (University of Aveiro), Saima Rafi (Edinburgh Napier University)

Код и DSL: https://github.com/gautamvarmadatla/PolicyTests-P2T-for-operationalizing-AI-governance

Упоминаемые стандарты: EU AI Act (Regulation 2024/1689), NIST AI Risk Management Framework, HIPAA Privacy Rule (45 C.F.R. Part 164), Microsoft Responsible AI Standard v2, ISO/IEC 42001:2023