Углублённая оценка рисков функции

Разбирает риски отдельной функции продукта: что может пойти не так, как вероятно и тяжело, что смягчает. Заканчивает вариантами и рекомендацией.

СкиллAnthropicClaudeApache-2.0Загрузить архив в ClaudeПроверка не требуется

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

Что делает: Разбирает риски отдельной функции продукта: что может пойти не так, как вероятно и тяжело, что смягчает. Заканчивает вариантами и рекомендацией.
Когда брать: Когда проверка запуска нашла новую или серьёзную проблему, а регулятор или руководство ждут больше, чем строку в таблице.
Когда не брать: Если у запуска обычные риски: хватает проверки запуска (launch-review), отдельный документ не нужен.
Пример запроса: Сделай подробную оценку рисков для новой функции ИИ-рекомендаций в нашем приложении.
Работает лучше с: инструмент правовых исследований (Westlaw, CourtListener), файлы настроек плагина

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

Как включить

Нажмите «Скачать на русском» и сохраните архив.
В Claude откройте Настройки → Capabilities → Skills → Upload skill и выберите архив.
Включите скилл переключателем.

Для терминала

Распакуйте архив и положите папку feature-risk-assessment в ~/.claude/skills/. Файл SKILL.md должен лежать внутри этой папки.

Текст

---
name: feature-risk-assessment
description: >
  Углублённая оценка рисков для отдельной функции или продуктовой области,
  когда проверка запуска выявила нечто, что требует большего, чем строка в
  списке. Структурированный разбор: что может пойти не так, насколько это
  вероятно, насколько тяжело и что снижает риск. Используй, когда пользователь
  говорит «разбери этот риск подробно», «оценка рисков для [функции]», «что
  может пойти не так с», или когда launch-review отметил новую проблему.
---

Оценка рисков функции

Контекст дела

Контекст дела. Проверь раздел ## Matter workspaces в CLAUDE.md уровня практики. Если Enabled равно ✗ (так по умолчанию для штатных юристов компании), пропусти остаток этого абзаца: скиллы работают с контекстом уровня практики, а механизм дел остаётся невидимым. Если пространства дел включены, а активного дела нет, спроси: «Для какого дела это нужно? Запустите /product-legal:matter-workspace switch <slug> или скажите practice-level». Загрузи matter.md активного дела: в нём контекст и переопределения для этого дела. Записывай результаты в папку дела ~/.claude/plugins/config/claude-for-legal/product-legal/matters/<matter-slug>/. Никогда не читай файлы другого дела, если Cross-matter context не равно on.

Назначение

Проверка запуска широкая. Эта оценка глубокая. Когда одной проблеме нужно больше, чем строка таблицы (новая функция на основе ИИ, продукт для детей, область, на которую прямо сейчас смотрит регулятор), скилл готовит отдельную самостоятельную оценку.

Нужна она не каждому запуску. Большинству не нужна. Она для тех 10% случаев, когда «оценка воздействия на приватность сделана, выпустили» — недостаточный уровень внимания.

Когда запускать

Проверка запуска нашла шаблон, которого нет в таблице калибровки (новый случай)
Проверка запуска нашла нечто из категории «обычно блокирует»
Главный юрист (GC) или руководство спросили «в чём тут риск» и хотят большего, чем ответ в одну строку
Функция находится в области, на которую сейчас обращает внимание регулятор (ИИ, дети, биометрия, здоровье)
Кто-то вне юридического отдела обеспокоен, и структурированный ответ помог бы

Если ничего из перечисленного нет, проверки запуска достаточно. Не плоди бумаги ради бумаг.

Структура

1. Что мы оцениваем

Один абзац. Что делает функция, что в ней нового, почему её передали на полную оценку.

2. Риски

Для каждого отдельного риска (старайся уложиться в 2–5, а не в 15):

### Риск [N]: [Короткое название]

**Сценарий:** [Что должно произойти, чтобы всё пошло не так. Будь конкретен:
не «утечка данных», а «алгоритм рекомендаций показывает интерес пользователя
к чувствительной категории тому, кому его видеть нельзя, потому что X».]

**Кто пострадает:** [Пользователи? Компания? Третья сторона? Конкретно.]

**Насколько вероятно:** [Низкая / Средняя / Высокая — с обоснованием. «Низкая:
для этого одновременно должны отказать X и Y». Не просто оценка «на глаз».]

**Насколько тяжело, если случится:** [Низкая / Средняя / Высокая — с обоснованием.
«Высокая: штраф регулятора + риск коллективного иска + реакция прессы» против
«Низкая: один злой твит, реального вреда нет».]

**Существующие меры:** [Что уже снижает вероятность или тяжесть]

**Пробел:** [Чего не хватает, если не хватает]

**Остаточный риск:** [После существующих мер: он приемлем или нужны ещё меры?]

3. Регуляторная картина (если уместно)

Включай только если регулятор действительно проявляет интерес к этой области. Тогда:

Какой регулятор, что он говорил или делал в последнее время
Как эта функция будет выглядеть в его глазах
Предпочли бы мы, чтобы он узнал о ней от нас или из заголовка в новостях

4. Прецеденты (если есть)

Делала ли другая компания что-то похожее? Чем это закончилось?

Если ничего плохого не случилось — это полезно, но не решает дело
Если случилось плохое — чем отличалась их ситуация, применимо ли это здесь

Не переоценивай прецеденты. Регуляторы меняют приоритеты; то, что одной компании что-то сошло с рук, не значит, что сойдёт и следующей.

5. Варианты

Предложи 2–3 реалистичных пути:

| Вариант | Описание | Снижение риска | Цена |
|---|---|---|---|
| A: Выпустить как задумано | [текущий план] | Нет | Нет |
| B: Выпустить с [мерой] | [изменение] | [насколько] | [трудозатраты разработки, сроки, влияние на UX] |
| C: Не выпускать [компонент] | [сокращение объёма] | [насколько] | [влияние на продукт] |

6. Рекомендация

Выбери один вариант. Объясни почему. Признай, чем ты за это платишь.

**Рекомендуется: вариант [X]**

[Почему. Какой риск остаётся. Почему он приемлем. Кто его принимает.]

**Если ответ «это не мне решать»:** [Кто решает, что ему нужно знать]

Проверка калибровки

Прежде чем завершить, сверься с ~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md → Risk calibration:

Оценка риска откалибрована под *эту компанию* или она общая?
Риск, который «высокий» в компании под соглашением с регулятором (consent decree), может быть «средним» в компании без такого соглашения
Оценка должна отражать реальное отношение регуляторов, историю споров и готовность к риску, зафиксированные в профиле практики

Передача дальше

В управление ИИ: если глубокий разбор вызвала функция с ИИ (так часто и бывает), запусти /ai-governance-legal:aia-generation [функция] параллельно или сразу после. Оценка рисков функции обрамляет решение; оценка воздействия ИИ (AIA) документирует именно систему ИИ в формате, который нужен управлению ИИ. Это не дубликаты: оценка рисков функции — документ для продуктово-юридического решения, а AIA — запись для управления ИИ.
В приватность: если функция связана со сбором или обработкой новых данных, запусти /privacy-legal:pia-generation [функция]. Раздел рисков в оценке функции, скорее всего, пересечётся с оценкой воздействия на приватность (PIA): отметь это пересечение, чтобы работа не дублировалась, но оба документа должны существовать.
В проверку ИИ-поставщиков: если функция использует нового ИИ-поставщика, запусти /ai-governance-legal:vendor-ai-review [договор с поставщиком], если это ещё не сделано при проверке запуска.

Формат результата

Самостоятельный документ на 2–4 страницы. Поставь в начало шапку рабочих материалов юриста (work-product header) из ~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md ## Outputs (она зависит от роли пользователя — см. ## Who's using this).

Не презентация и не служебная записка в архив, а документ для решения: его читают, а потом принимают решение.

Сохрани там, где ~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md → Launch review process велит хранить документы проверок. Если документ уйдёт кому-то за пределами круга, защищённого привилегией (например, его выложат в общедоступный тикет), убирай шапку рабочих материалов юриста только из этой внешней копии, а оригинал с привилегией оставь в файле дела.

Проверка цитат

Если в оценке приводятся дела, законы, подзаконные акты или принудительные меры регулятора — особенно в разделах «Регуляторная картина» и «Прецеденты», — эти ссылки сгенерированы моделью ИИ и не сверены с первоисточником. Прежде чем документ попадёт к тому, кто принимает решение, сверь каждую ссылку в инструменте правовых исследований (Westlaw, CourtListener или платформа вашей фирмы): точность, актуальность нормы и нынешнюю практику регулятора. Оценка рисков, построенная на выдуманной принудительной мере, хуже, чем отсутствие оценки.

Без тихого дополнения. Если запрос к настроенному инструменту правовых исследований возвращает мало результатов или не возвращает их вовсе по режиму или прецеденту, нужному оценке, сообщи, что найдено, и остановись. НЕ заполняй пробел веб-поиском или знаниями модели, не спросив. Скажи: «Поиск вернул [N] результатов из [инструмент]. Покрытие по [режим / прецедент], похоже, слабое. Варианты: (1) расширить поисковый запрос, (2) попробовать другой инструмент исследования, (3) поискать в интернете: результаты будут помечены [web search — verify], и их нужно сверить с первоисточником, прежде чем полагаться, или (4) отметить как непроверенное и остановиться. Что выберете?» Решать, принимать ли менее надёжные источники, должен юрист. Указание источника. Помечай каждую цитату в разделах «Регуляторная картина» и «Прецеденты» тем, откуда она взята: [Westlaw], [CourtListener], [regulator site] или имя инструмента MCP для цитат, полученных из коннектора правовых исследований; [web search — verify] для цитат из веб-поиска; [model knowledge — verify] для цитат, вспомненных из обучающих данных; [user provided] для цитат от команды функции. Цитаты с пометкой verify несут повышенный риск выдумки, и проверять их нужно в первую очередь. Никогда не убирай и не склеивай эти пометки: тому, кто принимает решение, нужно видеть, какие цитаты проверять первыми.

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

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

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

Он не оценивает каждую функцию. Большинство функций получают проверку запуска, и на этом всё.
Он не принимает решение. Он обрамляет его. Вариант выбирает тот, у кого есть полномочия.
Он не строит количественные модели риска. Если в компании есть формальная система рисков с цифрами, пользуйся ею; здесь оценка качественная.

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

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

---
name: feature-risk-assessment
description: >
  Deeper risk assessment for a single feature or product area when the launch
  review found something that needs more than a line item. Structured analysis:
  what could go wrong, how likely, how bad, what mitigates it. Use when user
  says "deep dive on this risk", "risk assessment for [feature]", "what could
  go wrong with", or when launch-review flags a novel issue.
---

# Feature Risk Assessment

## Matter context

**Matter context.** Check `## Matter workspaces` in the practice-level CLAUDE.md. If `Enabled` is `✗` (the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run `/product-legal:matter-workspace switch <slug>` or say `practice-level`." Load the active matter's `matter.md` for matter-specific context and overrides. Write outputs to the matter folder at `~/.claude/plugins/config/claude-for-legal/product-legal/matters/<matter-slug>/`. Never read another matter's files unless `Cross-matter context` is `on`.

---

## Purpose

The launch review is broad. This is deep. When a single issue needs more than a table row — a novel AI feature, a children's product, something a regulator is actively looking at — this skill produces a standalone assessment.

Not every launch needs one. Most don't. This is for the 10% where "PIA done, shipped" isn't the right level of scrutiny.

## When to run this

- Launch review found a pattern that's **not in the calibration table** (novel)
- Launch review found something in the **"usually blocks"** category
- GC or leadership asked "what's the risk here" and wants more than a one-liner
- The feature is in an area with **active regulatory attention** (AI, children, biometric, health)
- Someone outside legal is worried and a structured answer would help

If none of the above, the launch review is enough. Don't generate paperwork for its own sake.

## Structure

### 1. What we're assessing

One paragraph. What the feature does, what's new about it, why it got escalated to a full assessment.

### 2. The risks

For each distinct risk (aim for 2-5, not 15):

```markdown
### Risk [N]: [Short name]

**Scenario:** [What would have to happen for this to go wrong. Be specific —
not "data breach" but "the recommendation algo surfaces a user's sensitive
category interest to someone who shouldn't see it because X."]

**Who gets hurt:** [Users? The company? A third party? Specific.]

**How likely:** [Low / Medium / High — with a reason. "Low — would require
both X and Y to fail simultaneously." Not just a vibes rating.]

**How bad if it happens:** [Low / Medium / High — with a reason. "High —
regulatory fine + class action exposure + press" vs. "Low — one angry
tweet, no actual harm."]

**Existing mitigations:** [What already reduces the likelihood or impact]

**Gap:** [What's missing, if anything]

**Residual risk:** [After existing mitigations — is this acceptable or does
it need more?]
```

### 3. Regulatory landscape (if relevant)

Only include if a regulator is actively interested in this space. If so:

- Which regulator, what they've said/done recently
- How this feature would look to them
- Whether we'd rather they hear about it from us or from a headline

### 4. Precedent (if any)

Has another company done something similar? What happened?

- If nothing bad happened → useful, not dispositive
- If something bad happened → what was different about their situation, does it apply here

Don't overweight precedent. Regulators change priorities; one company getting away with something doesn't mean the next one will.

### 5. Options

Present 2-3 realistic paths:

```markdown
| Option | Description | Risk reduction | Cost |
|---|---|---|---|
| A: Ship as designed | [current plan] | None | None |
| B: Ship with [mitigation] | [change] | [how much] | [eng effort, timeline, UX] |
| C: Don't ship [component] | [scope cut] | [how much] | [product impact] |
```

### 6. Recommendation

Pick one. Explain why. Acknowledge what you're trading off.

```markdown
**Recommended: Option [X]**

[Why. What risk remains. Why that's acceptable. Who accepts it.]

**If the answer is "not my call":** [Who decides, what they need to know]
```

## Calibration check

Before finalizing, check against `~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md` → Risk calibration:

- Is this risk assessment calibrated to *this company*, or is it generic?
- A risk that's "High" at a company under a consent decree might be "Medium" at one that isn't
- The assessment should reflect the actual regulatory posture, litigation history, and risk appetite captured in the practice profile

## Handoffs

- **To AI governance:** If the deep-dive was triggered by an AI feature — which
  it often is — run `/ai-governance-legal:aia-generation [feature]` in parallel or
  immediately after. The feature risk assessment frames the decision; the AIA
  documents the AI system specifically in the format AI governance needs. They're
  not duplicates: the FRA is a product-legal decision doc; the AIA is the
  governance record.
- **To privacy:** If the feature involves new data collection or processing,
  run `/privacy-legal:pia-generation [feature]`. The FRA's risk section
  will likely overlap with the PIA's — flag that overlap so work isn't duplicated,
  but both docs need to exist.
- **To AI governance vendor review:** If the feature uses a new AI vendor,
  run `/ai-governance-legal:vendor-ai-review [vendor agreement]` if not already done
  during the launch review.

## Output format

Standalone doc, 2-4 pages. Prepend the work-product header from `~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md` `## Outputs` (it differs by user role — see `## Who's using this`).

Not a slide deck, not a memo to file — a decision document someone reads and then decides.

Save where `~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md` → Launch review process says review docs go. If the doc is going to be shared with anyone outside the privileged loop (e.g., posted to a broadly-shared ticket), drop the work-product header only for that externally-facing copy and keep the privileged original in the matter file.

## Citation check

If the assessment cites cases, statutes, regulations, or enforcement actions — in the Regulatory landscape or Precedent sections especially — those citations were generated by an AI model and have not been verified against a primary source. Before the decision document goes to a decisionmaker, verify each citation against a legal research tool (Westlaw, CourtListener, or your firm's research platform) for accuracy, good law status, and current enforcement posture. A risk assessment built on a fabricated enforcement action is worse than no assessment.

> **No silent supplement.** If a research query to the configured legal research tool returns few or no results for the regime or precedent the assessment needs, 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 / precedent]. 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.** Tag every citation in the Regulatory landscape and Precedent sections with where it came from: `[Westlaw]`, `[CourtListener]`, `[regulator site]`, or the MCP tool name for citations retrieved from a legal research connector; `[web search — verify]` for web-search citations; `[model knowledge — verify]` for citations recalled from training data; `[user provided]` for citations from the feature team. Citations tagged `verify` carry higher fabrication risk and should be checked first. Never strip or collapse the tags — the decisionmaker needs to see which citations to verify 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 assess every feature. Most features get a launch review and that's it.
- It doesn't make the decision. It frames the decision. Someone with authority picks an option.
- It doesn't do quantitative risk modeling. If the company has a formal risk framework with numbers, use that — this is qualitative.

Источник: anthropics/claude-for-legal / product-legal / feature-risk-assessment ↗. Ссылка проверена 2026-10-10.

---
name: feature-risk-assessment
description: >
  Углублённая оценка рисков для отдельной функции или продуктовой области,
  когда проверка запуска выявила нечто, что требует большего, чем строка в
  списке. Структурированный разбор: что может пойти не так, насколько это
  вероятно, насколько тяжело и что снижает риск. Используй, когда пользователь
  говорит «разбери этот риск подробно», «оценка рисков для [функции]», «что
  может пойти не так с», или когда launch-review отметил новую проблему.
---

# Оценка рисков функции

## Контекст дела

**Контекст дела.** Проверь раздел `## Matter workspaces` в CLAUDE.md уровня практики. Если `Enabled` равно `✗` (так по умолчанию для штатных юристов компании), пропусти остаток этого абзаца: скиллы работают с контекстом уровня практики, а механизм дел остаётся невидимым. Если пространства дел включены, а активного дела нет, спроси: «Для какого дела это нужно? Запустите `/product-legal:matter-workspace switch <slug>` или скажите `practice-level`». Загрузи `matter.md` активного дела: в нём контекст и переопределения для этого дела. Записывай результаты в папку дела `~/.claude/plugins/config/claude-for-legal/product-legal/matters/<matter-slug>/`. Никогда не читай файлы другого дела, если `Cross-matter context` не равно `on`.

---

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

Проверка запуска широкая. Эта оценка глубокая. Когда одной проблеме нужно больше, чем строка таблицы (новая функция на основе ИИ, продукт для детей, область, на которую прямо сейчас смотрит регулятор), скилл готовит отдельную самостоятельную оценку.

Нужна она не каждому запуску. Большинству не нужна. Она для тех 10% случаев, когда «оценка воздействия на приватность сделана, выпустили» — недостаточный уровень внимания.

## Когда запускать

- Проверка запуска нашла шаблон, которого **нет в таблице калибровки** (новый случай)
- Проверка запуска нашла нечто из категории **«обычно блокирует»**
- Главный юрист (GC) или руководство спросили «в чём тут риск» и хотят большего, чем ответ в одну строку
- Функция находится в области, на которую **сейчас обращает внимание регулятор** (ИИ, дети, биометрия, здоровье)
- Кто-то вне юридического отдела обеспокоен, и структурированный ответ помог бы

Если ничего из перечисленного нет, проверки запуска достаточно. Не плоди бумаги ради бумаг.

## Структура

### 1. Что мы оцениваем

Один абзац. Что делает функция, что в ней нового, почему её передали на полную оценку.

### 2. Риски

Для каждого отдельного риска (старайся уложиться в 2–5, а не в 15):

```markdown
### Риск [N]: [Короткое название]

**Сценарий:** [Что должно произойти, чтобы всё пошло не так. Будь конкретен:
не «утечка данных», а «алгоритм рекомендаций показывает интерес пользователя
к чувствительной категории тому, кому его видеть нельзя, потому что X».]

**Кто пострадает:** [Пользователи? Компания? Третья сторона? Конкретно.]

**Насколько вероятно:** [Низкая / Средняя / Высокая — с обоснованием. «Низкая:
для этого одновременно должны отказать X и Y». Не просто оценка «на глаз».]

**Насколько тяжело, если случится:** [Низкая / Средняя / Высокая — с обоснованием.
«Высокая: штраф регулятора + риск коллективного иска + реакция прессы» против
«Низкая: один злой твит, реального вреда нет».]

**Существующие меры:** [Что уже снижает вероятность или тяжесть]

**Пробел:** [Чего не хватает, если не хватает]

**Остаточный риск:** [После существующих мер: он приемлем или нужны ещё меры?]
```

### 3. Регуляторная картина (если уместно)

Включай только если регулятор действительно проявляет интерес к этой области. Тогда:

- Какой регулятор, что он говорил или делал в последнее время
- Как эта функция будет выглядеть в его глазах
- Предпочли бы мы, чтобы он узнал о ней от нас или из заголовка в новостях

### 4. Прецеденты (если есть)

Делала ли другая компания что-то похожее? Чем это закончилось?

- Если ничего плохого не случилось — это полезно, но не решает дело
- Если случилось плохое — чем отличалась их ситуация, применимо ли это здесь

Не переоценивай прецеденты. Регуляторы меняют приоритеты; то, что одной компании что-то сошло с рук, не значит, что сойдёт и следующей.

### 5. Варианты

Предложи 2–3 реалистичных пути:

```markdown
| Вариант | Описание | Снижение риска | Цена |
|---|---|---|---|
| A: Выпустить как задумано | [текущий план] | Нет | Нет |
| B: Выпустить с [мерой] | [изменение] | [насколько] | [трудозатраты разработки, сроки, влияние на UX] |
| C: Не выпускать [компонент] | [сокращение объёма] | [насколько] | [влияние на продукт] |
```

### 6. Рекомендация

Выбери один вариант. Объясни почему. Признай, чем ты за это платишь.

```markdown
**Рекомендуется: вариант [X]**

[Почему. Какой риск остаётся. Почему он приемлем. Кто его принимает.]

**Если ответ «это не мне решать»:** [Кто решает, что ему нужно знать]
```

## Проверка калибровки

Прежде чем завершить, сверься с `~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md` → Risk calibration:

- Оценка риска откалибрована под *эту компанию* или она общая?
- Риск, который «высокий» в компании под соглашением с регулятором (consent decree), может быть «средним» в компании без такого соглашения
- Оценка должна отражать реальное отношение регуляторов, историю споров и готовность к риску, зафиксированные в профиле практики

## Передача дальше

- **В управление ИИ:** если глубокий разбор вызвала функция с ИИ (так часто и бывает), запусти `/ai-governance-legal:aia-generation [функция]` параллельно или сразу после. Оценка рисков функции обрамляет решение; оценка воздействия ИИ (AIA) документирует именно систему ИИ в формате, который нужен управлению ИИ. Это не дубликаты: оценка рисков функции — документ для продуктово-юридического решения, а AIA — запись для управления ИИ.
- **В приватность:** если функция связана со сбором или обработкой новых данных, запусти `/privacy-legal:pia-generation [функция]`. Раздел рисков в оценке функции, скорее всего, пересечётся с оценкой воздействия на приватность (PIA): отметь это пересечение, чтобы работа не дублировалась, но оба документа должны существовать.
- **В проверку ИИ-поставщиков:** если функция использует нового ИИ-поставщика, запусти `/ai-governance-legal:vendor-ai-review [договор с поставщиком]`, если это ещё не сделано при проверке запуска.

## Формат результата

Самостоятельный документ на 2–4 страницы. Поставь в начало шапку рабочих материалов юриста (work-product header) из `~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md` `## Outputs` (она зависит от роли пользователя — см. `## Who's using this`).

Не презентация и не служебная записка в архив, а документ для решения: его читают, а потом принимают решение.

Сохрани там, где `~/.claude/plugins/config/claude-for-legal/product-legal/CLAUDE.md` → Launch review process велит хранить документы проверок. Если документ уйдёт кому-то за пределами круга, защищённого привилегией (например, его выложат в общедоступный тикет), убирай шапку рабочих материалов юриста только из этой внешней копии, а оригинал с привилегией оставь в файле дела.

## Проверка цитат

Если в оценке приводятся дела, законы, подзаконные акты или принудительные меры регулятора — особенно в разделах «Регуляторная картина» и «Прецеденты», — эти ссылки сгенерированы моделью ИИ и не сверены с первоисточником. Прежде чем документ попадёт к тому, кто принимает решение, сверь каждую ссылку в инструменте правовых исследований (Westlaw, CourtListener или платформа вашей фирмы): точность, актуальность нормы и нынешнюю практику регулятора. Оценка рисков, построенная на выдуманной принудительной мере, хуже, чем отсутствие оценки.

> **Без тихого дополнения.** Если запрос к настроенному инструменту правовых исследований возвращает мало результатов или не возвращает их вовсе по режиму или прецеденту, нужному оценке, сообщи, что найдено, и остановись. НЕ заполняй пробел веб-поиском или знаниями модели, не спросив. Скажи: «Поиск вернул [N] результатов из [инструмент]. Покрытие по [режим / прецедент], похоже, слабое. Варианты: (1) расширить поисковый запрос, (2) попробовать другой инструмент исследования, (3) поискать в интернете: результаты будут помечены `[web search — verify]`, и их нужно сверить с первоисточником, прежде чем полагаться, или (4) отметить как непроверенное и остановиться. Что выберете?» Решать, принимать ли менее надёжные источники, должен юрист.
>
> **Указание источника.** Помечай каждую цитату в разделах «Регуляторная картина» и «Прецеденты» тем, откуда она взята: `[Westlaw]`, `[CourtListener]`, `[regulator site]` или имя инструмента MCP для цитат, полученных из коннектора правовых исследований; `[web search — verify]` для цитат из веб-поиска; `[model knowledge — verify]` для цитат, вспомненных из обучающих данных; `[user provided]` для цитат от команды функции. Цитаты с пометкой `verify` несут повышенный риск выдумки, и проверять их нужно в первую очередь. Никогда не убирай и не склеивай эти пометки: тому, кто принимает решение, нужно видеть, какие цитаты проверять первыми.

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

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

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

- Он не оценивает каждую функцию. Большинство функций получают проверку запуска, и на этом всё.
- Он не принимает решение. Он обрамляет его. Вариант выбирает тот, у кого есть полномочия.
- Он не строит количественные модели риска. Если в компании есть формальная система рисков с цифрами, пользуйся ею; здесь оценка качественная.

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