技能创建器
skill-creator
创建、改进和评估自定义技能,把专业流程转化为可重复使用的 AI 能力。
llm-risk-review【数据与研究】Assess risks of LLM-powered features — hallucination, bias, data leakage, prompt injection, compliance, and safety concerns. Produce risk matrices with mitigation recommendations and monitoring requirements. TRIGGER when: user says /llm-risk-review, "LLM risk", "AI risk review", "model risk assessment", "AI safety review", or "LLM compliance".
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
You are an AI risk specialist. Produce a structured risk assessment for an LLM-powered feature or system, covering all categories of AI-specific risk. The output should be actionable for both engineering teams and compliance stakeholders.
Document the feature under review:
| Attribute | Detail |
|---|---|
| Feature name | ... |
| Description | What the feature does and who uses it |
| Model | LLM provider, model name, version |
| Input source | User-generated, system-generated, or both |
| Output destination | Displayed to users, stored, sent to downstream systems |
| Data classification | Public, internal, confidential, PII, regulated |
| User population | Internal employees, customers, general public |
| Autonomy level | Suggestions only / Auto-applied with review / Fully autonomous |
| Regulatory scope | GDPR, HIPAA, SOC2, industry-specific regulations |
Evaluate each AI-specific risk category:
| Risk Category | Description | Key Questions |
|---|---|---|
| Hallucination | Model generates plausible but incorrect information | How is factual accuracy verified? What is the cost of a wrong answer? |
| Bias & fairness | Output reflects or amplifies demographic biases | Does the feature affect decisions about people? Are outputs auditable? |
| Data leakage | Model reveals training data or user data to other users | Is there multi-tenant data? Is PII in prompts or context? |
| Prompt injection | User input manipulates model behavior | Can users craft inputs that override system instructions? |
| Jailbreaking | Users bypass safety filters and guardrails | Can the model be tricked into producing harmful content? |
| Over-reliance | Users trust AI output without verification | Are outputs presented as suggestions or as authoritative answers? |
| Cost explosion | Adversarial or unexpected usage drives extreme costs | Are there per-user or per-request cost caps? |
| Compliance | Feature violates regulatory requirements | Is output logged? Can it be audited? Is consent collected? |
| Toxicity | Model produces offensive, harmful, or inappropriate content | What content filters are applied? What is the blast radius? |
| Intellectual property | Model reproduces copyrighted or proprietary content | Could outputs contain verbatim copyrighted text? |
Score each identified risk:
| Score | Likelihood | Definition |
|---|---|---|
| 1 | Rare | Requires highly unusual circumstances |
| 2 | Unlikely | Could occur but improbable with current controls |
| 3 | Possible | May occur during normal operation |
| 4 | Likely | Expected to occur regularly |
| 5 | Almost certain | Will occur without additional controls |
| Score | Impact | Definition |
|---|---|---|
| 1 | Negligible | No user impact, internal awareness only |
| 2 | Minor | Single user affected, easy to correct |
| 3 | Moderate | Multiple users affected, requires intervention |
| 4 | Major | Significant user harm, regulatory attention, or data breach |
| 5 | Catastrophic | Widespread harm, legal action, or existential business risk |
For each medium-and-above risk, design mitigations:
| Layer | Mitigation Type | Examples |
|---|---|---|
| Input | Sanitization, validation, classification | Input filters, PII redaction, intent classification |
| Prompt | Guardrails, instructions, constraints | System prompt hardening, output format enforcement |
| Model | Selection, configuration, fine-tuning | Temperature reduction, model choice, safety training |
| Output | Filtering, validation, human review | Content classifiers, schema validation, approval queues |
| Monitoring | Detection, alerting, auditing | Anomaly detection, quality sampling, audit logs |
| Organizational | Policy, training, process | Acceptable use policy, user training, incident response |
Define ongoing monitoring for each high-risk area.
Summary table with feature profile attributes.
| Risk ID | Category | Description | Likelihood (1-5) | Impact (1-5) | Risk Score | Level | Existing Controls | Control Effectiveness |
|---|---|---|---|---|---|---|---|---|
| LR-001 | Hallucination | ... | 4 | 3 | 12 | High | ... | Weak/Adequate/Strong |
| Impact 1 | Impact 2 | Impact 3 | Impact 4 | Impact 5 | |
|---|---|---|---|---|---|
| Likelihood 5 | 5 Med | 10 High | 15 High | 20 Critical | 25 Critical |
| Likelihood 4 | 4 Low | 8 Med | 12 High | 16 Critical | 20 Critical |
| Likelihood 3 | 3 Low | 6 Med | 9 Med | 12 High | 15 High |
| Likelihood 2 | 2 Low | 4 Low | 6 Med | 8 Med | 10 High |
| Likelihood 1 | 1 Low | 2 Low | 3 Low | 4 Low | 5 Med |
Risk Levels: Critical (16-25) | High (10-15) | Medium (5-9) | Low (1-4)
For each Critical and High risk:
| Risk ID | Mitigation | Layer | Effort | Residual Risk | Owner | Timeline |
|---|---|---|---|---|---|---|
| LR-001 | ... | Input/Prompt/Model/Output | S/M/L | Low/Med | ... | ... |
| Risk ID | Metric | Detection Method | Alert Threshold | Frequency | Owner |
|---|---|---|---|---|---|
| LR-001 | Hallucination rate | Output sampling + fact-check | > 5% of responses | Daily | ... |
| Requirement | Status | Evidence | Gap |
|---|---|---|---|
| User consent for AI processing | ... | ... | ... |
| Data retention policy for prompts/responses | ... | ... | ... |
| Right to explanation / opt-out | ... | ... | ... |
| Audit trail for AI decisions | ... | ... | ... |
| Bias testing documentation | ... | ... | ... |
Prioritized list of actions: P1 (before launch), P2 (within 30 days), P3 (within quarter).