Policy Change Risk Assessment Prompt

This prompt is designed for AI safety engineers, platform architects, and release managers who need to assess the risk of a proposed change to a system prompt or behavioral policy before it reaches production. The core job-to-be-done is structured risk evaluation: given a concrete diff or description of the proposed change, the current policy text, and context about the assistant's deployment environment, the prompt produces a risk register that identifies failure modes, safety implications, edge case exposure, and confidence levels. Use this during change review meetings, as a gate in your CI/CD pipeline for prompt updates, or as part of a pre-mortem before a major policy migration. It assumes you have the actual change artifact—not just a vague intent—and enough deployment context to reason about blast radius.

This is not a prompt for generating new policies or writing system instructions from scratch. It is specifically for evaluating the risk of changing existing, live policies. Do not use it when you lack a concrete diff, when the deployment environment is undefined, or when the change is purely cosmetic with no behavioral surface area. The prompt works best when paired with a versioned system prompt artifact and a known set of behavioral contracts that the assistant must maintain. For high-stakes domains—such as healthcare, finance, or safety-critical systems—always route the output through human review before accepting the risk assessment as actionable. The prompt can flag risks but cannot replace domain-expert judgment about acceptable residual risk.

After running this prompt, you should have a structured risk register with severity ratings, confidence estimates, and mitigation recommendations. Use the output to inform go/no-go decisions, to prioritize additional testing, or to document risk acceptance for audit trails. If the prompt identifies high-severity risks with low confidence, that is a signal to invest in targeted adversarial testing or canary deployment before full rollout. Pair this prompt with the Behavioral Change Test Prompt and the System Prompt Diff Analysis Prompt for a complete pre-release evaluation pipeline. Avoid treating the risk register as a one-time artifact; re-run the assessment when deployment context changes or when new edge cases are discovered post-deployment.

This template is designed to be used by AI safety engineers and platform operators before a system prompt or behavioral policy update is deployed. It forces the model to act as a skeptical reviewer, systematically identifying failure modes, safety implications, and edge-case exposure that a straightforward 'summarize the change' prompt would miss. The output is a structured risk register that can be directly fed into a release gate or human approval workflow.

codeCopy
You are an AI safety reviewer. Your task is to evaluate a proposed change to a production system prompt or behavioral policy and produce a structured risk register.

## PROPOSED POLICY CHANGE
[POLICY_CHANGE_DESCRIPTION]

## CURRENT SYSTEM INSTRUCTIONS (for context)
[CURRENT_SYSTEM_PROMPT]

## DEPLOYMENT CONTEXT
- Environment: [DEPLOYMENT_ENVIRONMENT]
- User base: [USER_BASE_DESCRIPTION]
- Regulated domain: [YES/NO]
- High-stakes actions: [LIST_HIGH_STAKES_ACTIONS]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "change_summary": "One-sentence summary of the proposed change",
  "risk_register": [
    {
      "risk_id": "RISK-001",
      "category": "SAFETY | RELIABILITY | COMPLIANCE | USER_EXPERIENCE | SECURITY",
      "description": "Concrete description of what could go wrong",
      "trigger_condition": "Specific input or scenario that activates this risk",
      "severity": "CRITICAL | HIGH | MEDIUM | LOW",
      "likelihood": "HIGH | MEDIUM | LOW",
      "affected_behaviors": ["List of assistant behaviors that could degrade"],
      "detection_method": "How this failure would be observed in production",
      "mitigation_recommendation": "Concrete step to reduce likelihood or impact"
    }
  ],
  "edge_case_exposure": [
    {
      "scenario": "Description of an edge case that stresses this policy change",
      "expected_behavior_old": "How the assistant would have responded before the change",
      "expected_behavior_new": "How the assistant might respond after the change",
      "risk_of_regression": "HIGH | MEDIUM | LOW"
    }
  ],
  "confidence_assessment": {
    "overall_confidence": "HIGH | MEDIUM | LOW",
    "key_uncertainties": ["List of factors that reduce confidence"],
    "recommended_testing": ["Specific test scenarios to increase confidence"]
  },
  "approval_recommendation": {
    "recommendation": "APPROVE | APPROVE_WITH_CONDITIONS | REJECT",
    "conditions": ["List of conditions that must be met before deployment"],
    "required_approvers": ["Roles that must sign off"]
  }
}

## CONSTRAINTS
- Do not minimize risks. Err on the side of over-identifying potential failures.
- For each risk, provide a concrete trigger condition, not a vague category.
- If the change affects refusal behavior, explicitly test adversarial rephrasing scenarios.
- If the change affects tool-use authorization, explicitly test boundary conditions.
- Flag any risk that could cause silent failures (no error message, but wrong behavior).
- If confidence is LOW, recommend specific additional testing before deployment.

To adapt this template, replace the square-bracket placeholders with your specific context. The [POLICY_CHANGE_DESCRIPTION] should include the exact diff or a precise description of what is changing and why. The [CURRENT_SYSTEM_PROMPT] must be the full, unredacted system instructions so the model can reason about interactions between existing rules and the proposed change. For [DEPLOYMENT_ENVIRONMENT], specify whether this is production, staging, or a canary deployment. The [LIST_HIGH_STAKES_ACTIONS] field is critical: include any assistant capabilities that could cause harm if misapplied, such as sending emails, modifying database records, or making financial transactions. If your domain is regulated, set [YES/NO] to YES and expect the model to produce additional compliance-category risks. After receiving the output, validate the JSON structure before feeding it into your release gate. For high-severity risks, require human review of the specific risk entries before accepting the approval recommendation.

The Policy Change Risk Assessment prompt is not a one-off query; it is a gating step in a policy change management pipeline. Wire it into your CI/CD or release workflow so that every proposed system instruction diff triggers a risk assessment before it reaches staging. The prompt expects a structured diff of the proposed policy change, the current system prompt, and any relevant behavioral test results. The output is a risk register with severity ratings, failure mode descriptions, and mitigation recommendations. This output should be parsed as structured JSON and fed into a downstream approval or rejection decision.

Implement a validation layer that checks the model's output against the expected [OUTPUT_SCHEMA] before accepting it. If the JSON is malformed, missing required fields like risk_items or overall_risk_level, or contains severity values outside the allowed enum, trigger a retry with the error message injected into the [CONSTRAINTS] field. Limit retries to three attempts, then escalate to a human reviewer. Log every assessment attempt, including the prompt version, model used, raw output, validation errors, and final accepted output. For high-risk domains, require a human to sign off on any assessment where overall_risk_level is high or critical before the policy change can proceed.

Choose a model with strong instruction-following and structured output capabilities for this task. The prompt relies on the model correctly interpreting a diff, reasoning about behavioral implications, and producing a consistent JSON schema. If your pipeline supports tool use, provide a submit_risk_assessment function with the exact output schema as the tool's parameters to enforce structural compliance at the API level. Do not use this prompt as a replacement for actual behavioral regression tests; it is a pre-flight analysis that complements, not substitutes, empirical testing. The next step after a passing risk assessment is always a canary deployment with production monitoring.