Сверка с новым законом об ИИ

Сверяет новый закон или разъяснение об ИИ с вашей текущей практикой и составляет план устранения разрывов с владельцами и сроками.

СкиллAnthropicClaudeApache-2.0Нужен терминалПроверка не требуется

Скачать на русскомОригинал на английском (архив)Источник ↗

Что делает: Сверяет новый закон или разъяснение об ИИ с вашей текущей практикой и составляет план устранения разрывов с владельцами и сроками.
Когда брать: Когда вышел или изменился закон об ИИ (например, EU AI Act) и нужно понять, что компании придётся поменять и в каком порядке.
Когда не брать: Если норма вас не касается (другая юрисдикция, ниже порога, другая роль): скилл так и скажет одной строкой. Постоянного мониторинга он не ведёт, и сами исправления не вносит.
Пример запроса: Только что вышли положения EU AI Act о системах высокого риска: сделай анализ разрывов по нашей практике.
Нужно подключить: доступ к файлам (папка настроек плагина)
Работает лучше с: инструмент юридического поиска (Westlaw, EUR-Lex)

Входит в плагин ai-governance-legal. В Cowork и Claude Code можно поставить плагин целиком.

Как включить

Скачайте архив и распакуйте его.
Положите папку reg-gap-analysis в ~/.claude/skills/.
Откройте Claude Code и опишите задачу своими словами: Claude подхватит скилл по описанию.

Текст

---
name: reg-gap-analysis
description: >
  Сверь новое регулирование ИИ или разъяснение с текущим состоянием вашего
  управления ИИ: выяви разрывы, приоритеты и план устранения с ответственными
  и сроками. Используй, когда норма об ИИ меняется (или ты узнаёшь о той,
  которую пропустили), либо когда пользователь говорит «только что вышла новая
  норма», «касается ли нас [норма]», «анализ разрывов по EU AI Act», «проверка
  соответствия [закону или разъяснению об ИИ]» или вставляет текст
  нормативного акта.
argument-hint: "[regulation name, or paste regulatory text, or attach a document]"
---

/reg-gap-analysis

Прочитай ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md. Убедись, что регуляторный охват и реестр сценариев заполнены.
Используй рамку ниже.
Определи область: применима ли эта норма? (Юрисдикция, порог, разработчик/эксплуатант, отрасль.) Если нет, одна строка, и готово.
Извлеки требования. Сверь с текущим состоянием в ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md.
Расставь приоритеты разрывов. Результат: план устранения с разделами «обязательно / желательно / уже соответствует / принятые разрывы».
Сохрани как markdown-документ с датой для дела.

/ai-governance-legal:reg-gap-analysis "положения EU AI Act о системах высокого риска"

Назначение

EU AI Act вступает в действие. Колорадо принимает закон об ИИ. CFPB выпускает руководство по риску моделей. FTC публикует политику правоприменения в сфере ИИ. Что-то меняется, и теперь нужно понять, что, если вообще что-то, вам придётся изменить.

Этот скилл сверяет новое требование с текущим состоянием вашего управления ИИ (по ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md: реестр сценариев, позиции по поставщикам, практики оценки воздействия и обязательства ИИ-политики) и выдаёт список разрывов с планом устранения.

Регуляторная картина по ИИ сейчас меняется быстрее, чем в любой другой области права. Когда норма действительно неоднозначна, так и скажи. Не замазывай неопределённость: юридическим командам нужно знать, когда они стоят на твёрдой почве, а когда принимают решение на основе суждения.

Загрузи текущее состояние

Прочитай ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md:

## Regulatory footprint — что уже применимо
## Use case registry — какой ИИ вы реально запускаете и на каких условиях
## AI policy commitments — что вы пообещали публично или по договору
## Vendor AI governance — какие позиции по поставщикам действуют
## Impact assessment house style — какие практики оценки существуют

Если норма явно не применима (не та юрисдикция, ниже порога, не та отрасль, различие между разработчиком и эксплуатантом выводит вас из области), скажи прямо: «Не применима. Вот почему: [причина]. Действий не требуется».

Сначала исследование, потом рабочий процесс

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

Область — кого касается (поставщик/разработчик, эксплуатант, дистрибьютор, пользователь; отраслевые исключения).
Пороги применимости — выручка, число пользователей, численность, вычислительная мощность, категория модели, размер затрагиваемой группы людей.
Определения уровней риска — как режим различает уровни (запрещённый / высокий риск / ограниченный риск / минимальный), что входит в каждый.
Содержательные обязанности — прозрачность, документация, человеческий надзор, тестирование на смещение, регистрация, сообщение об инцидентах, передача требований по цепочке поставщиков.
Механизм правоприменения — какой регулятор, какие санкции, есть ли частное право на иск.
Даты вступления в силу — многие законы об ИИ вводят обязанности поэтапно в течение 2–4 лет; отметь, какие обязанности уже действуют, а какие предстоят.

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

Строй анализ разрывов на изученных требованиях, а не на жёстко заданных справочных таблицах.

Рабочий процесс

Шаг 1: Определи область нормы

Прежде чем сверять, ответь:

Применима ли она? Юрисдикция, порог, отраслевые исключения, различие между разработчиком и эксплуатантом. Изучи конкретные правила об области действия в самой норме, не предполагай.

*Здесь очень важно различие между разработчиком и эксплуатантом.* Многие режимы ИИ накладывают разные обязанности на того, кто разрабатывает/предоставляет ИИ-систему, и на того, кто её внедряет/использует. Выясни, какую роль компания занимает по определениям каждого режима. Сначала область; не делай анализ разрывов по закону, который не применяется.

Когда? Дата вступления в силу. Дата начала правоприменения (часто другая). Переходные периоды для отдельных положений. Проверяй актуальность.

Что действительно ново? Некоторые «новые» законы об ИИ в основном повторяют существующие правовые принципы (защита потребителей, недопущение дискриминации, отраслевое управление рисками), применяя их к ИИ. Другие действительно вводят новые обязанности. Определи разницу с тем, что вы уже делаете, а не полный текст закона.

Шаг 2: Извлеки требования

Прочитай норму, разъяснение или резюме. Перечисли каждое содержательное требование:

№	Требование	Ссылка	Категория
1	[требование]	[раздел]	[см. категории ниже]

Категории:

Прозрачность — раскрытие пользователям, сотрудникам или затронутым сторонам информации о применении ИИ
Оценка воздействия — обязательная документация до внедрения
Человеческий надзор — обязательная проверка человеком, возможность переопределить или механизмы обжалования
Точность / тестирование — тестирование на смещение, документирование точности, валидация
Управление — регистрация, ведение записей, назначенные ответственные лица
Передача по цепочке поставщиков — обязанности, которые нужно передать ИИ-поставщикам или принять от них
Запрещённые практики — прямые запреты на отдельные возможности или применения ИИ
Права — что затронутые стороны могут запросить или на что сослаться

Шаг 3: Сверь с текущим состоянием

По каждому требованию:

### [Требование №N]: [краткое название]

**Норма говорит:** [требование, цитатой или пересказом]

**Мы сейчас:** [что показывают `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md` / ИИ-политика / реестр сценариев / практика
оценки]

**Разрыв:** [Нет | Частичный | Полный]

**Если частичный/полный — чего не хватает:** [конкретно: не «больше документации», а
«для [категория сценария] не задокументирован шаг проверки человеком»]

**Усилия по устранению:** [Только обновление политики | Изменение процесса | Изменение продукта/системы |
Нужна новая оценка | Пересмотр договора с поставщиком | Регистрация / подача документов]

**Риск несоответствия:** [диапазон санкций, вероятность правоприменения, репутационные последствия]

Шаг 4: Расставь приоритеты

Не все разрывы одинаковы. Сортируй по:

Жёсткий срок с последствиями — дата вступления в силу + активное правоприменение + реальные санкции
Запрещённая практика — если разрыв касается запрета, а не требования к процессу, это первый приоритет независимо от даты правоприменения
Соотношение усилий и эффекта — обновить формулировки политики дёшево; добавить человеческий надзор в уже внедрённую систему нет
Пересечение сценариев — разрывы, затрагивающие несколько сценариев в реестре, приоритетнее разрывов по одному сценарию

Шаг 5: План устранения

[ШАПКА РАБОЧЕГО МАТЕРИАЛА — по разделу плагина ## Outputs — отличается по ролям; см. `## Who's using this`]

## План устранения: [Название нормы]

**Дата вступления в силу:** [дата]
**Правоприменение начинается:** [дата, если отличается]
**Применяется к нам как:** [Разработчик (Builder) / Эксплуатант (Deployer) / Оба (Both)]

### Обязательно до начала правоприменения

| Разрыв | Исправление | Ответственный | Срок | Статус |
|---|---|---|---|---|
| [разрыв] | [конкретное исправление] | [имя] | [дата] | [ ] |

### Желательно (важно, но не блокирует правоприменение)

[та же таблица]

### Уже соответствует

[перечень требований, где разрыв = Нет: полезный контекст для юридической/управленческой
сводки о том, где вы на самом деле находитесь]

### Принятые разрывы (риск принят, не исправляем)

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

Изучи норму, прежде чем строить анализ разрывов

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

Какие обязанности применимы к роли компании (поставщик/разработчик, эксплуатант, импортёр, дистрибьютор)?
В какой уровень попадает система по собственной классификации режима (запрещённая / высокого риска / ограниченного риска / минимального риска или эквивалент режима)?
Каковы даты действия и поэтапного ввода для каждой обязанности?
Есть ли делегированные акты, имплементационные акты или разъяснения регуляторов, влияющие на толкование?
Для контекстов разработчика: есть ли обязанности на уровне модели (техническая документация, прозрачность обучающих данных, соблюдение авторских прав, тестирование системного риска)?
Для категорий запрещённых практик: проверь все сценарии в реестре, которые могут их затрагивать, и отметь как критические независимо от даты правоприменения.

Цитируй первоисточники с точными ссылками. Отмечай неоднозначность для суждения юриста.

Никаких тихих дополнений. Если запрос к настроенному инструменту юридического поиска (Westlaw, EUR-Lex, сайты регуляторов или платформа фирмы) возвращает мало результатов или не возвращает ничего по тексту режима, делегированному акту или разъяснению, сообщи, что нашлось, и остановись. НЕ заполняй пробел веб-поиском или знаниями модели без вопроса. Скажи: «Поиск вернул [N] результатов из [инструмент]. Покрытие по [режим / тема], похоже, скудное. Варианты: (1) расширить поисковый запрос, (2) попробовать другой инструмент, (3) поискать в вебе: результаты получат пометку [веб-поиск — проверить], и их нужно сверить с издавшим органом, прежде чем полагаться на них, или (4) пометить как непроверенное и остановиться. Что выберете?» Принимать ли источники с меньшей достоверностью, решает юрист. Градация источников. Помечай каждую ссылку в анализе разрывов её источником. Для ссылок по знаниям модели используй одну из трёх градаций вместо единой общей пометки «проверить»: - [общеизвестно] — устойчивые, хорошо известные ссылки на законы и нормативные акты, которые вряд ли изменились (например, GDPR ст. 22, существование Регламента (ЕС) 2024/1689 как EU AI Act, Colorado AI Act как C.R.S. § 6-1-1701 и последующие). Перед подачей всё равно проверить, но с меньшим приоритетом. - [проверить] — ссылки по знаниям модели, которые реальны, но требуют проверки: конкретные делегированные и имплементационные акты, разъяснения регуляторов, стандарты, меры принуждения, правовые позиции судов, пороги, даты вступления в силу, положения о поэтапном вводе, ссылки на гармонизированные стандарты. - [проверить-пункт] — точные ссылки (конкретные номера статей, ссылки на приложения, буквы подпунктов, номера абзацев, ссылки на пункты стандартов) несут наибольший риск выдумки, и их НУЖНО ВСЕГДА сверять с первоисточником. Номера статей EU AI Act особенно сдвинулись при консолидации; каждую точную ссылку на Акт сверяй с текстом Официального журнала. Ссылки, полученные через инструмент, сохраняют пометку источника ([Westlaw], [EUR-Lex], [regulator site] или имя MCP-инструмента); ссылки из веб-поиска остаются [веб-поиск — проверить]; ссылки от пользователя остаются [от пользователя]. Градация показывает, где действительно нужна проверка: читатель, который проверяет всё, не проверяет ничего. Никогда не убирай и не склеивай пометки. Для пользователей, не юристов, неуверенные даты, пороги и положения о поэтапном вводе идут в список для подтверждения, а не в текст. Пометка [проверить] у фразы «вступает в силу 1 февраля 2026 года» читается как «вступает в силу 1 февраля 2026 года» для не юриста, который не знает, что значит пометка. Прочитай ## Who's using this в ~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md. Если роль — Non-lawyer (не юрист) и утверждение о дате, сроке, поэтапном вводе, пороге или дате вступления в силу неуверенно (при вставке в текст получило бы [проверить] или [проверить-пункт]), замени его в тексте на «дата вступления в силу: уточните у юриста» (или «порог: уточните у юриста») и собери все неуверенные пункты в заключительном разделе анализа разрывов под названием: «В чём я не уверен: попросите юриста подтвердить, прежде чем полагаться на это:» с перечнем каждого пункта (что я сказал, что неуверенно, почему это важно для разрыва). Пользователи с ролью юриста получают пометки [проверить] прямо в тексте.

Связь с другими скиллами

Из aia-generation: AIA отмечают регуляторные обязанности для конкретных систем → они попадают сюда, когда норма новая или покрытие неясно.

Из use case triage: недавно отобранные сценарии, подпадающие под регуляторные триггеры → анализ разрывов запускается по конкретному требованию для этого типа сценария.

К плагину regulatory-legal, если он установлен: этот скилл — ручная версия. Плагин-монитор следит за лентами и запускает этот анализ автоматически, когда меняется что-то важное.

Результат

Сохрани как markdown-документ с датой. Таблица плана устранения становится трекером: обновляй статус по мере закрытия пунктов.

Если анализ разрывов приходит к выводу «разрывов нет, мы соответствуем», всё равно составь документ. Это полезное свидетельство, что вы смотрели, и полезная точка отсчёта на случай изменения нормы.

Проверка ссылок перед использованием. Ссылки здесь создала модель ИИ, и они не сверены с первоисточниками. Прежде чем полагаться на любую ссылку (закон, нормативный акт, делегированный акт, разъяснение или судебное дело), проведи проверку по инструменту юридического поиска (Westlaw, CourtListener или платформе вашей фирмы) на точность, актуальность и дальнейшую историю. Выдуманные или неверно процитированные ссылки в поданных материалах приводили к санкциям. Пометки источника у каждой ссылки (например, [EUR-Lex], [веб-поиск — проверить]) показывают, откуда она взята; пометки проверить несут больший риск выдумки, и проверять их нужно в первую очередь.

Закончи деревом следующих шагов

Заверши деревом следующих шагов по разделу CLAUDE.md ## Outputs. Подгони варианты под то, что этот скилл только что выдал: пять веток по умолчанию (подготовить X, эскалировать, собрать больше фактов, наблюдать и ждать, что-то другое) — отправная точка, а не жёсткое правило. Дерево и есть результат; выбирает юрист.

Чего этот скилл не делает

Он не толкует неоднозначные нормативные формулировки с авторитетом. В EU AI Act особенно много значимых вопросов толкования, которые ещё не решены. Когда норма действительно неоднозначна: скажи об этом, назови консервативное прочтение и отметь для внешнего юриста, если вопрос существенный.
Он не отслеживает регуляторные изменения заранее. Он запускается, когда ты указываешь на изменение. Для упреждающего мониторинга см. плагин regulatory-legal, если он установлен.
Он не внедряет исправления. Он их планирует.
Он не заменяет отраслевого юриста там, где нужны специальные знания (ИИ в здравоохранении, управление модельным риском в финансовых услугах и т. д.).

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/claude-for-legal/tree/main/ai-governance-legal/skills/reg-gap-analysis, лицензия Apache-2.0. Изменения: перевод на русский язык.

Оригинал на английском

---
name: reg-gap-analysis
description: >
Diff a new AI regulation or guidance against your current governance posture —
surfaces gaps, priorities, and a remediation plan with owners and deadlines.
Use when an AI regulation moves (or you learn about one you missed), or when
user says "new reg just dropped", "does [regulation] affect us", "gap analysis
for EU AI Act", "compliance check against [AI law or guidance]", or pastes
regulatory text.
argument-hint: "[regulation name, or paste regulatory text, or attach a document]"
---

# /reg-gap-analysis

1. Read `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md`. Confirm regulatory footprint and use case registry are populated.
2. Use the framework below.
3. Scope: does this regulation apply? (Jurisdiction, threshold, builder/deployer, sector.) If not, one line and done.
4. Extract requirements. Diff against current state in `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md`.
5. Prioritize gaps. Output: remediation plan with must-do / should-do / already compliant / accepted gaps.
6. Save as dated markdown doc for the file.

```
/ai-governance-legal:reg-gap-analysis "EU AI Act high-risk provisions"
```

---

## Purpose

The EU AI Act goes live. Colorado passes an AI law. The CFPB issues model risk
guidance. The FTC publishes an AI enforcement policy. Something moves — and now
you need to know what, if anything, you have to change.

This skill diffs the new requirement against your current AI governance posture
(per `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md` — use case registry, vendor positions, impact assessment practices,
and AI policy commitments) and produces a gap list with a remediation plan.

The AI regulatory landscape is moving faster than any other area of law right now.
When a regulation is genuinely ambiguous, say so. Don't paper over uncertainty —
legal teams need to know when they're on solid ground versus when they're making a
judgment call.

## Load current state

Read `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md`:
- `## Regulatory footprint` — what already applies
- `## Use case registry` — what AI you're actually running, and under what conditions
- `## AI policy commitments` — what you've publicly or contractually committed to
- `## Vendor AI governance` — what vendor positions are in place
- `## Impact assessment house style` — what assessment practices exist

If the regulation clearly doesn't apply (wrong jurisdiction, below threshold,
wrong sector, builder/deployer distinction eliminates you from scope), say so
directly: "Doesn't apply. Here's why: [reason]. No action needed."

---

## Research first, then workflow

Before running the gap analysis, research the currently operative AI regulatory regimes for the jurisdictions in the user's footprint. For each regime identify:

- **Scope** — who's covered (provider/builder vs. deployer vs. distributor vs. user; sectoral carve-outs).
- **Applicability thresholds** — revenue, user count, headcount, compute, model category, affected-population size.
- **Risk-tier definitions** — how the regime distinguishes tiers (prohibited / high-risk / limited-risk / minimal), what's in each.
- **Substantive obligations** — transparency, documentation, human oversight, bias testing, registration, incident reporting, vendor flow-down.
- **Enforcement mechanism** — which regulator, what penalties, any private right of action.
- **Effective dates** — many AI laws phase in obligations over 2-4 years; note which obligations are live vs. upcoming.

Cite the regulatory text with pinpoint references. Flag provisions subject to ongoing interpretation, delegated acts, or pending rulemaking. The AI regulatory landscape changes quickly — verify currency before advising.

Build the gap analysis from the researched requirements, not from hardcoded reference tables.

## Workflow

### Step 1: Scope the regulation

Before diffing, answer:

- **Does it apply?** Jurisdiction, threshold, sector carve-outs, builder vs. deployer distinction. Research the specific scoping rules in the regulation — don't assume.

*Builder/deployer matters a lot here.* Many AI regimes impose different obligations on the entity that develops/provides the AI system versus the entity that deploys/uses it. Research which role the company occupies under each regime's definitions. Scope first; don't gap-analyze a law that doesn't apply.

- **When?** Effective date. Enforcement date (often different). Phase-in periods for specific provisions. Verify currency.

- **What's actually new?** Some "new" AI laws largely restate existing legal principles (consumer protection, anti-discrimination, sectoral risk management) applied to AI. Others are genuinely new obligations. Identify the delta from what you already do, not the full text of the law.

### Step 2: Extract requirements

Read the regulation, guidance, or summary. List every substantive requirement:

| # | Requirement | Citation | Category |
|---|---|---|---|
| 1 | [requirement] | [section] | [see categories below] |

**Categories:**
- **Transparency** — disclosures to users, employees, or affected parties about AI use
- **Impact assessment** — required documentation before deployment
- **Human oversight** — mandatory human review, override, or appeals mechanisms
- **Accuracy / testing** — bias testing, accuracy documentation, validation
- **Governance** — registration, record-keeping, designated responsible persons
- **Vendor flow-down** — obligations to pass down to AI vendors or pass up from AI vendors
- **Prohibited practices** — outright bans on specific AI capabilities or uses
- **Rights** — what affected parties can request or invoke

### Step 3: Diff against current state

For each requirement:

```markdown
### [Requirement #N]: [short name]

**Regulation says:** [requirement, quoted or paraphrased]

**We currently:** [what `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md` / AI policy / use case registry / assessment
practice shows]

**Gap:** [None | Partial | Full]

**If partial/full — what's missing:** [specific — not "more documentation" but
"no human review step is documented for [use case category]"]

**Risk of non-compliance:** [penalty range, enforcement likelihood, reputational]
```

### Step 4: Prioritize

Not every gap is equal. Sort by:

1. **Hard deadline with teeth** — effective date + active enforcement + real penalties
2. **Prohibited practice** — if the gap is a prohibition, not a process requirement,
that's the first priority regardless of enforcement date
3. **Effort-to-impact ratio** — updating policy language is cheap; adding human
oversight to a deployed system is not
4. **Use case overlap** — gaps that affect multiple use cases in the registry are
higher priority than single-use-case gaps

### Step 5: Remediation plan

```markdown
[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

## Remediation Plan: [Regulation name]

**Effective date:** [date]
**Enforcement begins:** [date if different]
**Applies to us as:** [Builder / Deployer / Both]

### Must-do before enforcement

| Gap | Fix | Owner | Due | Status |
|---|---|---|---|---|
| [gap] | [specific fix] | [name] | [date] | [ ] |

### Should-do (important but not blocking enforcement)

[same table]

### Already compliant

[list of requirements where gap = None — useful context for the legal/executive
summary of where you actually stand]

### Accepted gaps (risk accepted, not fixing)

[if any — with documented rationale and who accepted the risk. Documenting accepted
risk is better governance than leaving it unaddressed silently.]
```

---

## Research the regulation before building the gap analysis

Do not rely on hardcoded reference tables for specific regimes. For each regulation in scope, research the currently operative text:

- Which obligations apply to the company's role (provider/builder, deployer, importer, distributor)?
- Which tier does the system fall into under the regime's own classification (prohibited / high-risk / limited-risk / minimal, or the regime's equivalent)?
- What are the live vs. phase-in dates for each obligation?
- Are there delegated acts, implementing acts, or regulator guidance that affect interpretation?
- For builder contexts: are there model-level obligations (technical documentation, training data transparency, copyright compliance, systemic-risk testing)?
- For prohibited-practice categories: check any use case in the registry that might touch them and flag as critical regardless of enforcement date.

Cite primary sources with pinpoint references. Flag ambiguity for attorney judgment.

> **No silent supplement.** If a research query to the configured legal research tool (Westlaw, EUR-Lex, regulator sites, or firm platform) returns few or no results for a regime's text, delegated act, or guidance, report what was found and stop. Do NOT fill the gap from web search or model knowledge without asking. Say: "The search returned [N] results from [tool]. Coverage appears thin for [regime / topic]. Options: (1) broaden the search query, (2) try a different research tool, (3) search the web — results will be tagged `[web search — verify]` and should be checked against the issuing authority before relying, or (4) flag as unverified and stop. Which would you like?" A lawyer decides whether to accept lower-confidence sources.
>
> **Source attribution tiering.** Tag every citation in the gap analysis with its source. For model-knowledge citations, use one of three tiers rather than a single blanket "verify" tag:
>
> - `[settled]` — stable, well-known statutory and regulatory references unlikely to have changed (e.g., GDPR Art. 22, the existence of Regulation (EU) 2024/1689 as the EU AI Act, Colorado AI Act as C.R.S. § 6-1-1701 et seq.). Still verify before filing, but lower priority.
> - `[verify]` — model-knowledge citations that are real but should be verified: specific delegated / implementing acts, regulator guidance, standards, enforcement actions, case holdings, thresholds, effective dates, phase-in provisions, harmonized-standards references.
> - `[verify-pinpoint]` — pinpoint citations (specific article numbers, annex references, subsection letters, paragraph numbers, standard-clause references) carry the highest fabrication risk and should ALWAYS be verified against a primary source. EU AI Act article numbers in particular shifted during consolidation; every pinpoint cite to the Act should be verified against the Official Journal text.
>
> Tool-retrieved citations keep their source tag (`[Westlaw]`, `[EUR-Lex]`, `[regulator site]`, or the MCP tool name); web-search citations remain `[web search — verify]`; user-supplied citations remain `[user provided]`. The tiering surfaces the real verification work — a reader who verifies everything verifies nothing. Never strip or collapse the tags.
>
> **For non-lawyer users, uncertain dates, thresholds, and phase-in provisions go in a confirm-list, not inline.** A `[verify]` tag on "effective February 1, 2026" reads as "effective February 1, 2026" to a non-lawyer who doesn't know what the tag means. Read `## Who's using this` in `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md`. If Role is **Non-lawyer** and a date, deadline, phase-in, threshold, or effective-date assertion is uncertain (would carry `[verify]` or `[verify-pinpoint]` if inline), replace the inline assertion with "effective date: confirm with counsel" (or "threshold: confirm with counsel") and collect all uncertain items in a final gap-analysis section titled: "**Things I'm not certain about — ask your attorney to confirm before relying on this:**" with each item listed (what I said, what's uncertain, why it matters to the gap). Lawyer-role users keep the inline `[verify]` treatment.

---

## Integration with other skills

**From aia-generation:** AIAs flag regulatory obligations for specific
systems → those feed here when a regulation is new or coverage is uncertain.

**From use case triage:** Newly triaged use cases that hit regulatory triggers →
gap analysis runs on the specific requirement for that use case type.

**To regulatory-legal plugin, if the plugin is installed:** This skill is the manual
version. The monitor plugin watches feeds and triggers this analysis automatically
when something relevant changes.

---

## Output

Save as a dated markdown doc. The remediation plan table becomes a tracker — update
status as items close.

If the gap analysis concludes "no gaps, we're compliant," still write the doc. It's
useful evidence that you looked, and useful baseline when the regulation is amended.

**Cite check before relying on this.** Citations here were generated by an AI model and have not been verified against primary sources. Before relying on any citation — statute, regulation, delegated act, guidance, or case — run a verification pass against a legal research tool (Westlaw, CourtListener, or your firm's platform) for accuracy, currency, and subsequent history. Fabricated or misquoted citations in filed materials have resulted in sanctions. Source tags on each citation (e.g., `[EUR-Lex]`, `[web search — verify]`) show where it came from; `verify` tags carry higher fabrication risk and should be checked first.

---

## Close with the next-steps decision tree

End with the next-steps decision tree per CLAUDE.md `## Outputs`. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.

## What this skill does not do

- It doesn't interpret ambiguous regulatory language authoritatively. The EU AI Act
in particular has significant interpretive questions that aren't resolved yet.
When the reg is genuinely ambiguous: say so, state the conservative read, and
flag for outside counsel if the issue is material.
- It doesn't track regulatory changes proactively. It runs when you point it at a
change. For proactive monitoring, see the `regulatory-legal` plugin, if the plugin is installed.
- It doesn't implement fixes. It plans them.
- It doesn't substitute for sector-specific legal counsel where specialized knowledge
is required (healthcare AI, financial services model risk management, etc.).

Источник: anthropics/claude-for-legal / ai-governance-legal / reg-gap-analysis ↗. Ссылка проверена 2026-10-10.

---
name: reg-gap-analysis
description: >
  Сверь новое регулирование ИИ или разъяснение с текущим состоянием вашего
  управления ИИ: выяви разрывы, приоритеты и план устранения с ответственными
  и сроками. Используй, когда норма об ИИ меняется (или ты узнаёшь о той,
  которую пропустили), либо когда пользователь говорит «только что вышла новая
  норма», «касается ли нас [норма]», «анализ разрывов по EU AI Act», «проверка
  соответствия [закону или разъяснению об ИИ]» или вставляет текст
  нормативного акта.
argument-hint: "[regulation name, or paste regulatory text, or attach a document]"
---

# /reg-gap-analysis

1. Прочитай `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md`. Убедись, что регуляторный охват и реестр сценариев заполнены.
2. Используй рамку ниже.
3. Определи область: применима ли эта норма? (Юрисдикция, порог, разработчик/эксплуатант, отрасль.) Если нет, одна строка, и готово.
4. Извлеки требования. Сверь с текущим состоянием в `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md`.
5. Расставь приоритеты разрывов. Результат: план устранения с разделами «обязательно / желательно / уже соответствует / принятые разрывы».
6. Сохрани как markdown-документ с датой для дела.

```
/ai-governance-legal:reg-gap-analysis "положения EU AI Act о системах высокого риска"
```

---

## Назначение

EU AI Act вступает в действие. Колорадо принимает закон об ИИ. CFPB выпускает руководство по риску моделей. FTC публикует политику правоприменения в сфере ИИ. Что-то меняется, и теперь нужно понять, что, если вообще что-то, вам придётся изменить.

Этот скилл сверяет новое требование с текущим состоянием вашего управления ИИ (по `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md`: реестр сценариев, позиции по поставщикам, практики оценки воздействия и обязательства ИИ-политики) и выдаёт список разрывов с планом устранения.

Регуляторная картина по ИИ сейчас меняется быстрее, чем в любой другой области права. Когда норма действительно неоднозначна, так и скажи. Не замазывай неопределённость: юридическим командам нужно знать, когда они стоят на твёрдой почве, а когда принимают решение на основе суждения.

## Загрузи текущее состояние

Прочитай `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md`:
- `## Regulatory footprint` — что уже применимо
- `## Use case registry` — какой ИИ вы реально запускаете и на каких условиях
- `## AI policy commitments` — что вы пообещали публично или по договору
- `## Vendor AI governance` — какие позиции по поставщикам действуют
- `## Impact assessment house style` — какие практики оценки существуют

Если норма явно не применима (не та юрисдикция, ниже порога, не та отрасль, различие между разработчиком и эксплуатантом выводит вас из области), скажи прямо: «Не применима. Вот почему: [причина]. Действий не требуется».

---

## Сначала исследование, потом рабочий процесс

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

- **Область** — кого касается (поставщик/разработчик, эксплуатант, дистрибьютор, пользователь; отраслевые исключения).
- **Пороги применимости** — выручка, число пользователей, численность, вычислительная мощность, категория модели, размер затрагиваемой группы людей.
- **Определения уровней риска** — как режим различает уровни (запрещённый / высокий риск / ограниченный риск / минимальный), что входит в каждый.
- **Содержательные обязанности** — прозрачность, документация, человеческий надзор, тестирование на смещение, регистрация, сообщение об инцидентах, передача требований по цепочке поставщиков.
- **Механизм правоприменения** — какой регулятор, какие санкции, есть ли частное право на иск.
- **Даты вступления в силу** — многие законы об ИИ вводят обязанности поэтапно в течение 2–4 лет; отметь, какие обязанности уже действуют, а какие предстоят.

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

Строй анализ разрывов на изученных требованиях, а не на жёстко заданных справочных таблицах.

## Рабочий процесс

### Шаг 1: Определи область нормы

Прежде чем сверять, ответь:

- **Применима ли она?** Юрисдикция, порог, отраслевые исключения, различие между разработчиком и эксплуатантом. Изучи конкретные правила об области действия в самой норме, не предполагай.

  *Здесь очень важно различие между разработчиком и эксплуатантом.* Многие режимы ИИ накладывают разные обязанности на того, кто разрабатывает/предоставляет ИИ-систему, и на того, кто её внедряет/использует. Выясни, какую роль компания занимает по определениям каждого режима. Сначала область; не делай анализ разрывов по закону, который не применяется.

- **Когда?** Дата вступления в силу. Дата начала правоприменения (часто другая). Переходные периоды для отдельных положений. Проверяй актуальность.

- **Что действительно ново?** Некоторые «новые» законы об ИИ в основном повторяют существующие правовые принципы (защита потребителей, недопущение дискриминации, отраслевое управление рисками), применяя их к ИИ. Другие действительно вводят новые обязанности. Определи разницу с тем, что вы уже делаете, а не полный текст закона.

### Шаг 2: Извлеки требования

Прочитай норму, разъяснение или резюме. Перечисли каждое содержательное требование:

| № | Требование | Ссылка | Категория |
|---|---|---|---|
| 1 | [требование] | [раздел] | [см. категории ниже] |

**Категории:**
- **Прозрачность** — раскрытие пользователям, сотрудникам или затронутым сторонам информации о применении ИИ
- **Оценка воздействия** — обязательная документация до внедрения
- **Человеческий надзор** — обязательная проверка человеком, возможность переопределить или механизмы обжалования
- **Точность / тестирование** — тестирование на смещение, документирование точности, валидация
- **Управление** — регистрация, ведение записей, назначенные ответственные лица
- **Передача по цепочке поставщиков** — обязанности, которые нужно передать ИИ-поставщикам или принять от них
- **Запрещённые практики** — прямые запреты на отдельные возможности или применения ИИ
- **Права** — что затронутые стороны могут запросить или на что сослаться

### Шаг 3: Сверь с текущим состоянием

По каждому требованию:

```markdown
### [Требование №N]: [краткое название]

**Норма говорит:** [требование, цитатой или пересказом]

**Мы сейчас:** [что показывают `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md` / ИИ-политика / реестр сценариев / практика
оценки]

**Разрыв:** [Нет | Частичный | Полный]

**Если частичный/полный — чего не хватает:** [конкретно: не «больше документации», а
«для [категория сценария] не задокументирован шаг проверки человеком»]

**Усилия по устранению:** [Только обновление политики | Изменение процесса | Изменение продукта/системы |
Нужна новая оценка | Пересмотр договора с поставщиком | Регистрация / подача документов]

**Риск несоответствия:** [диапазон санкций, вероятность правоприменения, репутационные последствия]
```

### Шаг 4: Расставь приоритеты

Не все разрывы одинаковы. Сортируй по:

1. **Жёсткий срок с последствиями** — дата вступления в силу + активное правоприменение + реальные санкции
2. **Запрещённая практика** — если разрыв касается запрета, а не требования к процессу,
   это первый приоритет независимо от даты правоприменения
3. **Соотношение усилий и эффекта** — обновить формулировки политики дёшево; добавить человеческий
   надзор в уже внедрённую систему нет
4. **Пересечение сценариев** — разрывы, затрагивающие несколько сценариев в реестре,
   приоритетнее разрывов по одному сценарию

### Шаг 5: План устранения

```markdown
[ШАПКА РАБОЧЕГО МАТЕРИАЛА — по разделу плагина ## Outputs — отличается по ролям; см. `## Who's using this`]

## План устранения: [Название нормы]

**Дата вступления в силу:** [дата]
**Правоприменение начинается:** [дата, если отличается]
**Применяется к нам как:** [Разработчик (Builder) / Эксплуатант (Deployer) / Оба (Both)]

### Обязательно до начала правоприменения

| Разрыв | Исправление | Ответственный | Срок | Статус |
|---|---|---|---|---|
| [разрыв] | [конкретное исправление] | [имя] | [дата] | [ ] |

### Желательно (важно, но не блокирует правоприменение)

[та же таблица]

### Уже соответствует

[перечень требований, где разрыв = Нет: полезный контекст для юридической/управленческой
сводки о том, где вы на самом деле находитесь]

### Принятые разрывы (риск принят, не исправляем)

[если есть: с документированным обоснованием и указанием, кто принял риск. Документировать принятый
риск — лучшее управление, чем молча оставлять его без внимания.]
```

---

## Изучи норму, прежде чем строить анализ разрывов

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

- Какие обязанности применимы к роли компании (поставщик/разработчик, эксплуатант, импортёр, дистрибьютор)?
- В какой уровень попадает система по собственной классификации режима (запрещённая / высокого риска / ограниченного риска / минимального риска или эквивалент режима)?
- Каковы даты действия и поэтапного ввода для каждой обязанности?
- Есть ли делегированные акты, имплементационные акты или разъяснения регуляторов, влияющие на толкование?
- Для контекстов разработчика: есть ли обязанности на уровне модели (техническая документация, прозрачность обучающих данных, соблюдение авторских прав, тестирование системного риска)?
- Для категорий запрещённых практик: проверь все сценарии в реестре, которые могут их затрагивать, и отметь как критические независимо от даты правоприменения.

Цитируй первоисточники с точными ссылками. Отмечай неоднозначность для суждения юриста.

> **Никаких тихих дополнений.** Если запрос к настроенному инструменту юридического поиска (Westlaw, EUR-Lex, сайты регуляторов или платформа фирмы) возвращает мало результатов или не возвращает ничего по тексту режима, делегированному акту или разъяснению, сообщи, что нашлось, и остановись. НЕ заполняй пробел веб-поиском или знаниями модели без вопроса. Скажи: «Поиск вернул [N] результатов из [инструмент]. Покрытие по [режим / тема], похоже, скудное. Варианты: (1) расширить поисковый запрос, (2) попробовать другой инструмент, (3) поискать в вебе: результаты получат пометку `[веб-поиск — проверить]`, и их нужно сверить с издавшим органом, прежде чем полагаться на них, или (4) пометить как непроверенное и остановиться. Что выберете?» Принимать ли источники с меньшей достоверностью, решает юрист.
>
> **Градация источников.** Помечай каждую ссылку в анализе разрывов её источником. Для ссылок по знаниям модели используй одну из трёх градаций вместо единой общей пометки «проверить»:
>
> - `[общеизвестно]` — устойчивые, хорошо известные ссылки на законы и нормативные акты, которые вряд ли изменились (например, GDPR ст. 22, существование Регламента (ЕС) 2024/1689 как EU AI Act, Colorado AI Act как C.R.S. § 6-1-1701 и последующие). Перед подачей всё равно проверить, но с меньшим приоритетом.
> - `[проверить]` — ссылки по знаниям модели, которые реальны, но требуют проверки: конкретные делегированные и имплементационные акты, разъяснения регуляторов, стандарты, меры принуждения, правовые позиции судов, пороги, даты вступления в силу, положения о поэтапном вводе, ссылки на гармонизированные стандарты.
> - `[проверить-пункт]` — точные ссылки (конкретные номера статей, ссылки на приложения, буквы подпунктов, номера абзацев, ссылки на пункты стандартов) несут наибольший риск выдумки, и их НУЖНО ВСЕГДА сверять с первоисточником. Номера статей EU AI Act особенно сдвинулись при консолидации; каждую точную ссылку на Акт сверяй с текстом Официального журнала.
>
> Ссылки, полученные через инструмент, сохраняют пометку источника (`[Westlaw]`, `[EUR-Lex]`, `[regulator site]` или имя MCP-инструмента); ссылки из веб-поиска остаются `[веб-поиск — проверить]`; ссылки от пользователя остаются `[от пользователя]`. Градация показывает, где действительно нужна проверка: читатель, который проверяет всё, не проверяет ничего. Никогда не убирай и не склеивай пометки.
>
> **Для пользователей, не юристов, неуверенные даты, пороги и положения о поэтапном вводе идут в список для подтверждения, а не в текст.** Пометка `[проверить]` у фразы «вступает в силу 1 февраля 2026 года» читается как «вступает в силу 1 февраля 2026 года» для не юриста, который не знает, что значит пометка. Прочитай `## Who's using this` в `~/.claude/plugins/config/claude-for-legal/ai-governance-legal/CLAUDE.md`. Если роль — **Non-lawyer** (не юрист) и утверждение о дате, сроке, поэтапном вводе, пороге или дате вступления в силу неуверенно (при вставке в текст получило бы `[проверить]` или `[проверить-пункт]`), замени его в тексте на «дата вступления в силу: уточните у юриста» (или «порог: уточните у юриста») и собери все неуверенные пункты в заключительном разделе анализа разрывов под названием: «**В чём я не уверен: попросите юриста подтвердить, прежде чем полагаться на это:**» с перечнем каждого пункта (что я сказал, что неуверенно, почему это важно для разрыва). Пользователи с ролью юриста получают пометки `[проверить]` прямо в тексте.

---

## Связь с другими скиллами

**Из aia-generation:** AIA отмечают регуляторные обязанности для конкретных
систем → они попадают сюда, когда норма новая или покрытие неясно.

**Из use case triage:** недавно отобранные сценарии, подпадающие под регуляторные триггеры →
анализ разрывов запускается по конкретному требованию для этого типа сценария.

**К плагину regulatory-legal, если он установлен:** этот скилл — ручная
версия. Плагин-монитор следит за лентами и запускает этот анализ автоматически,
когда меняется что-то важное.

---

## Результат

Сохрани как markdown-документ с датой. Таблица плана устранения становится трекером: обновляй
статус по мере закрытия пунктов.

Если анализ разрывов приходит к выводу «разрывов нет, мы соответствуем», всё равно составь документ. Это
полезное свидетельство, что вы смотрели, и полезная точка отсчёта на случай изменения нормы.

**Проверка ссылок перед использованием.** Ссылки здесь создала модель ИИ, и они не сверены с первоисточниками. Прежде чем полагаться на любую ссылку (закон, нормативный акт, делегированный акт, разъяснение или судебное дело), проведи проверку по инструменту юридического поиска (Westlaw, CourtListener или платформе вашей фирмы) на точность, актуальность и дальнейшую историю. Выдуманные или неверно процитированные ссылки в поданных материалах приводили к санкциям. Пометки источника у каждой ссылки (например, `[EUR-Lex]`, `[веб-поиск — проверить]`) показывают, откуда она взята; пометки `проверить` несут больший риск выдумки, и проверять их нужно в первую очередь.

---

## Закончи деревом следующих шагов

Заверши деревом следующих шагов по разделу CLAUDE.md `## Outputs`. Подгони варианты под то, что этот скилл только что выдал: пять веток по умолчанию (подготовить X, эскалировать, собрать больше фактов, наблюдать и ждать, что-то другое) — отправная точка, а не жёсткое правило. Дерево и есть результат; выбирает юрист.

## Чего этот скилл не делает

- Он не толкует неоднозначные нормативные формулировки с авторитетом. В EU AI Act
  особенно много значимых вопросов толкования, которые ещё не решены.
  Когда норма действительно неоднозначна: скажи об этом, назови консервативное прочтение и
  отметь для внешнего юриста, если вопрос существенный.
- Он не отслеживает регуляторные изменения заранее. Он запускается, когда ты указываешь на
  изменение. Для упреждающего мониторинга см. плагин `regulatory-legal`, если он установлен.
- Он не внедряет исправления. Он их планирует.
- Он не заменяет отраслевого юриста там, где нужны специальные знания
  (ИИ в здравоохранении, управление модельным риском в финансовых услугах и т. д.).

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/claude-for-legal/tree/main/ai-governance-legal/skills/reg-gap-analysis, лицензия Apache-2.0. Изменения: перевод на русский язык.