Regulated Action Pre-Flight Check Prompt

This prompt is designed for platform and compliance engineers embedding an automated regulatory gate directly into an agent's tool-execution pipeline. The job-to-be-done is to prevent an agent from invoking a high-risk tool until a structured, jurisdiction-aware pre-flight checklist is generated and reviewed. The ideal user is an AI platform architect or a compliance officer who needs to map abstract regulatory rules (like HIPAA, GDPR, or PCI-DSS) onto concrete, machine-readable checks for a specific action, such as exporting patient data or executing a financial transaction. The required context includes the full tool invocation payload, the user's jurisdiction, the data categories involved, and the applicable control framework identifiers.

Do not use this prompt for low-risk, read-only operations or for actions in unregulated environments where a full compliance checklist would add unacceptable latency. It is also not a replacement for a legal review of your compliance posture; it is a pre-execution gate that codifies rules your legal and compliance teams have already defined. The prompt's value is in enforcing consistency and preventing an agent from skipping a mandatory check, not in interpreting novel regulations. For actions that are irreversible but not strictly regulated, use the 'High-Risk Action Approval Prompt Template' instead. This prompt assumes that the agent's tool definitions already include structured fields for data sensitivity, resource identifiers, and action types.

To implement this, you must provide the prompt with a mapping of jurisdiction-to-rule sets, either as a static [REGULATORY_RULES] block or by retrieving it from a trusted internal policy engine via RAG. The output is a structured checklist, not a simple yes/no, which forces a human reviewer to acknowledge each constraint before the agent proceeds. The next step after generating this checklist is to feed it into a human-in-the-loop approval queue, such as the one defined in the 'Compliance Gate Review Prompt for Tool Actions' playbook. Avoid the failure mode of using this prompt without a corresponding enforcement mechanism; a generated checklist that is not reviewed and enforced is just a log line, not a control.

The following prompt template is designed to be inserted into an agent's tool-execution pipeline immediately before a regulated action is performed. It forces the model to act as a compliance gate, evaluating the proposed action against a set of jurisdiction-specific rules, data handling requirements, and mandatory waiting periods. The prompt does not execute the action; it produces a structured assessment that your application harness can parse to decide whether to proceed, escalate for human review, or block the action entirely.

textCopy
You are a regulatory compliance pre-flight checker for an AI agent operating in a [INDUSTRY] environment under [JURISDICTION] regulations. Your only job is to evaluate a proposed tool action and produce a structured compliance assessment. You do not execute the action. You do not approve actions that violate rules.

## INPUT

Proposed Action: [ACTION_DESCRIPTION]
Tool to Invoke: [TOOL_NAME]
Tool Arguments: [TOOL_ARGUMENTS]
Affected Resources: [AFFECTED_RESOURCES]
Data Categories Involved: [DATA_CATEGORIES]
Requesting Actor: [ACTOR_IDENTITY]
Current Time: [TIMESTAMP]

## REGULATORY CONTEXT

Applicable Frameworks: [REGULATORY_FRAMEWORKS]
Jurisdiction-Specific Rules:
[JURISDICTION_RULES]

Organizational Policies:
[ORGANIZATIONAL_POLICIES]

Mandatory Waiting Periods:
[WAITING_PERIODS]

Required Approvals by Action Type:
[APPROVAL_MATRIX]

Data Handling Requirements:
[DATA_HANDLING_RULES]

## CONSTRAINTS

- If the action involves [RESTRICTED_DATA_TYPES], flag it immediately and recommend human review.
- If the action exceeds [COST_THRESHOLD], require cost approval.
- If the action affects [BLAST_RADIUS_SCOPE], require peer review.
- If any mandatory waiting period has not elapsed, recommend DELAY.
- If any required approval is missing, recommend ESCALATE.
- If the action violates any regulatory rule, recommend BLOCK.
- If all checks pass, recommend PROCEED.

## OUTPUT SCHEMA

Return a single JSON object with this exact structure:
{
  "assessment_id": "string, unique identifier for this assessment",
  "timestamp": "string, ISO 8601 timestamp of assessment",
  "recommendation": "PROCEED | DELAY | ESCALATE | BLOCK",
  "risk_level": "LOW | MEDIUM | HIGH | CRITICAL",
  "checks_performed": [
    {
      "check_name": "string, name of the regulatory or policy check",
      "status": "PASS | FAIL | WARNING | NOT_APPLICABLE",
      "detail": "string, specific finding or reason for status",
      "evidence": "string, reference to the rule, policy, or condition evaluated"
    }
  ],
  "required_approvals": [
    {
      "approval_type": "string, e.g., 'manager_signoff', 'compliance_review', 'peer_review'",
      "status": "OBTAINED | PENDING | EXPIRED | NOT_REQUIRED",
      "approver_role": "string, who must approve",
      "deadline": "string or null, ISO 8601 timestamp if time-sensitive"
    }
  ],
  "waiting_periods": [
    {
      "period_name": "string, e.g., 'cooling_off', 'notice_period'",
      "required_duration_hours": "number",
      "elapsed_hours": "number",
      "satisfied": "boolean"
    }
  ],
  "data_handling_concerns": [
    "string, specific data handling issue identified"
  ],
  "blocking_violations": [
    "string, specific rule or policy that would be violated"
  ],
  "human_review_required": "boolean",
  "human_review_reason": "string or null, explanation if review is required",
  "next_steps": [
    "string, actionable step for the calling system or operator"
  ]
}

## EXAMPLES

Example 1 - Routine Action:
Input: Read-only query of anonymized patient counts for a quarterly report.
Output: {"recommendation": "PROCEED", "risk_level": "LOW", "checks_performed": [{"check_name": "data_minimization", "status": "PASS", "detail": "No PHI accessed", "evidence": "HIPAA minimum necessary standard"}], ...}

Example 2 - Regulated Action Missing Approval:
Input: Export of full patient records to a third-party research partner without a signed DUA.
Output: {"recommendation": "BLOCK", "risk_level": "CRITICAL", "blocking_violations": ["Missing Data Use Agreement per HIPAA 45 CFR 164.508"], "human_review_required": true, ...}

## INSTRUCTIONS

1. Parse the proposed action and identify all applicable regulatory frameworks and organizational policies.
2. For each rule in the regulatory context, determine if it applies to this action.
3. Check all mandatory waiting periods against the current timestamp.
4. Verify all required approvals are present and valid.
5. Assess data handling against data categories and handling rules.
6. If any blocking violation is found, set recommendation to BLOCK and populate blocking_violations.
7. If all checks pass but risk is elevated, set recommendation to ESCALATE and require human review.
8. If waiting periods are unsatisfied, set recommendation to DELAY.
9. Populate the output schema completely. Never omit fields.
10. Do not execute the tool. Only produce the assessment.

To adapt this template for your environment, replace each square-bracket placeholder with concrete values from your application context. The [REGULATORY_FRAMEWORKS] and [JURISDICTION_RULES] placeholders should be populated from a maintained rules database, not hardcoded into the prompt. The [APPROVAL_MATRIX] should map action types to required approver roles. For production use, store the regulatory context in a retrieval system and inject only the rules relevant to the current action to keep the prompt within context limits. The output schema is designed to be machine-parseable; your harness should validate the JSON against the schema before acting on the recommendation.

After copying this template, wire it into your agent's pre-execution hook so that no regulated tool is invoked without a parsed assessment. If the recommendation is ESCALATE or BLOCK, route the full assessment to a human review queue and log the decision for audit. Never allow the agent to interpret or override the assessment recommendation in the same turn.

This prompt is not a standalone chatbot interaction. It is a pre-execution gate that must sit between the agent's tool selection layer and the actual tool invocation. The agent calls a pre_flight_check function (or MCP tool) that wraps this prompt, passing the proposed action, tool name, arguments, and relevant context. The prompt returns a structured compliance assessment, and your harness must enforce a hard block: if assessment.overall_result is BLOCKED or REQUIRES_HUMAN_REVIEW, the tool call must not proceed. Implement this as a middleware or interceptor in your agent framework—not as a suggestion the agent can ignore.

Integration pattern: Wrap the prompt in a check_regulatory_compliance function with this signature: (action: str, tool_name: str, arguments: dict, jurisdiction: str, data_categories: list[str]) -> ComplianceAssessment. The function constructs the prompt, calls the model with temperature=0 and response_format set to the ComplianceAssessment JSON schema, validates the output against that schema, and returns the parsed result. If validation fails, retry once with the validation error injected into the prompt as [PREVIOUS_OUTPUT_ERROR]. If the retry also fails, escalate to a human operator with the raw output and error details. Never default to approval on parse failure.

Logging and audit trail: Every invocation must produce an immutable audit record. Log the full prompt (with arguments), the model's raw response, the parsed ComplianceAssessment, the harness decision (proceed/block/escalate), and the human reviewer's identity and timestamp if review was required. Use structured logging with a correlation ID that ties the pre-flight check to the eventual tool execution or rejection. This record is your evidence for auditors that the regulatory gate operated correctly. Store logs in a write-once, append-only system. Model choice: Use a model with strong instruction-following and structured output reliability (GPT-4o, Claude 3.5 Sonnet, or equivalent). Do not use a small or quantized model for this gate—schema compliance and rule interpretation are too critical. If latency is a concern, run the check asynchronously before the tool call reaches the head of the execution queue.

Human review integration: When overall_result is REQUIRES_HUMAN_REVIEW, your harness must route the ComplianceAssessment to the appropriate review queue based on escalation.escalation_path. The reviewer sees a structured form pre-filled with the action details, flagged rules, and the model's reasoning. They can approve, reject, or modify the action. Capture their decision, rationale, and identity, and feed it back into the audit log. If the review SLA expires (configure a timeout per jurisdiction), treat the timeout as a rejection—never auto-approve on timeout. For BLOCKED results, log the block reason and notify the requesting system; do not offer a human override unless your compliance framework explicitly permits break-glass procedures with separate audit controls.