Risk-Adjusted Autonomy Level Prompt

This prompt is designed for risk managers, platform engineers, and AI governance leads who need to dynamically adjust an AI system's autonomy based on the risk profile of a specific action. The core job-to-be-done is translating a risk assessment into a concrete, auditable autonomy decision—deciding whether the AI can proceed automatically, requires human approval, or must be blocked entirely. It is ideal for systems where the cost of an autonomous error varies significantly by action type, such as financial operations, healthcare documentation, infrastructure management, or customer data handling. The ideal user has a defined risk taxonomy and a clear understanding of the organization's risk tolerance, but needs a repeatable, programmatic way to enforce it.

You should use this prompt when you have a pre-computed or model-assessed risk score for a pending action and need to map it to a specific autonomy tier. The prompt requires several concrete inputs to function reliably: a structured [ACTION_DESCRIPTION] with its parameters, a [RISK_SCORE] and its calculation methodology, the organization's [AUTONOMY_POLICY] defining risk bands and corresponding authority levels, and any relevant [OVERRIDE_CONDITIONS] such as regulatory flags or executive mandates. Do not use this prompt as a general-purpose risk calculator; it assumes the risk score is already determined. It is also not a replacement for a full policy document but rather an operationalization layer that enforces existing policy rules. For high-stakes domains, the output must be treated as a recommendation that is logged for audit, not as an irrevocable execution signal.

The primary failure mode this prompt prevents is misclassification, where a high-risk action is incorrectly routed to a low-autonomy path due to ambiguous risk descriptions or policy gaps. The prompt includes explicit validation steps to check that the assigned autonomy level does not violate a hard ceiling for the calculated risk band. After using this prompt, the next step is to integrate its structured output into your execution harness, where the autonomy decision is enforced before any API call or state change occurs. Always pair this with a logging mechanism that records the prompt's input, output, and the final human decision if an override is applied, creating a complete audit trail for governance reviews.

This prompt template is designed to be integrated into an AI orchestration layer that evaluates a proposed action's risk profile and determines the maximum permissible autonomy level. It forces the model to reason about risk bands, required approvals, and override conditions rather than producing a generic risk score. The template uses square-bracket placeholders for all dynamic inputs, making it ready for string interpolation in your application code before each inference call.

textCopy
You are an autonomy policy engine. Your task is to evaluate a proposed action and assign a risk-adjusted autonomy level based on the provided risk calculation inputs, autonomy policy, and action context.

## ACTION TO EVALUATE
[ACTION_DESCRIPTION]

## RISK CALCULATION INPUTS
- Data Sensitivity: [DATA_SENSITIVITY_LEVEL]
- Financial Exposure: [FINANCIAL_EXPOSURE_USD]
- User Impact Scope: [USER_IMPACT_COUNT]
- Reversibility: [REVERSIBILITY_ASSESSMENT]
- Regulatory Surface: [APPLICABLE_REGULATIONS]
- Operational Criticality: [OPERATIONAL_CRITICALITY_TIER]

## AUTONOMY POLICY
[AUTONOMY_POLICY_DOCUMENT]

## OUTPUT SCHEMA
Return a valid JSON object with the following structure:
{
  "risk_score": <float 0.0-1.0>,
  "risk_band": "LOW" | "MEDIUM" | "HIGH" | "CRITICAL",
  "max_autonomy_level": "FULL_AUTO" | "AUTO_WITH_AUDIT" | "HUMAN_APPROVAL_REQUIRED" | "BLOCKED",
  "required_approvals": [<list of role strings>],
  "override_conditions": [<list of condition strings that would escalate or de-escalate>],
  "reasoning": <string explaining the mapping from risk inputs to autonomy decision>,
  "misclassification_check": <boolean indicating whether the action could be misclassified to bypass review>
}

## CONSTRAINTS
1. If risk_band is "CRITICAL" or "HIGH", max_autonomy_level MUST be "HUMAN_APPROVAL_REQUIRED" or "BLOCKED".
2. If the action involves [REGULATED_DATA_TYPES], required_approvals MUST include "compliance_officer".
3. If Financial Exposure exceeds [FINANCIAL_THRESHOLD_USD], required_approvals MUST include "finance_approver".
4. misclassification_check must be true if the action description could be interpreted as a lower-risk category than the inputs indicate.
5. Do not invent risk factors not present in the inputs.
6. If any required input is missing or ambiguous, set max_autonomy_level to "BLOCKED" and explain why in reasoning.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

To adapt this template, replace each square-bracket placeholder with values from your application's risk assessment pipeline. The [AUTONOMY_POLICY_DOCUMENT] placeholder should contain your organization's full staged autonomy policy, including stage definitions, gate criteria, and role-based approval rules. The [FEW_SHOT_EXAMPLES] placeholder should include 2-3 worked examples showing correct risk-to-autonomy mappings, including at least one edge case where the action description could be misclassified. Before deploying, validate that the output JSON conforms to the schema using a JSON Schema validator, and log every autonomy decision with the full input context for auditability. For high-risk domains, route all decisions where max_autonomy_level is "HUMAN_APPROVAL_REQUIRED" or "BLOCKED" to a human review queue before any action is taken.

This prompt is designed to sit inside a decision service that runs before any autonomous action is executed. The application should call this prompt with the proposed action's computed risk score, the current operational context, and the existing autonomy policy. The prompt returns a structured mapping that determines whether the action proceeds automatically, requires human approval, or is blocked entirely. Treat this prompt as a policy enforcement point, not a one-off advisory call.

Wire the prompt into a pre-action middleware layer. Before the AI agent or automation system executes a write operation, data deletion, financial commitment, or configuration change, call this prompt with the action's risk profile. Parse the JSON output and enforce the autonomy_level field: full_autonomy proceeds without interruption, human_review queues the action for approval with the generated review_package, and blocked prevents execution and logs the reason. Implement a strict validator that rejects any output where a high-risk action maps to full_autonomy without an explicit override justification. If the output fails validation, retry once with the validation errors appended to the prompt context. If the retry also fails, default to human_review and flag the incident for prompt debugging.

Log every decision with the full input risk profile, the prompt version, the raw model output, the validated autonomy level, and the final action taken. This audit trail is essential for governance reviews and for tuning the risk-to-autonomy mapping over time. For high-stakes domains such as finance or healthcare, require a second human reviewer to confirm any override that grants autonomy above the risk band's ceiling. Never allow the model's output to bypass the application-layer enforcement of autonomy ceilings—the code must reject misclassifications even if the prompt produces them. Start with a conservative risk band mapping and tighten thresholds based on production review data, not model confidence alone.