Compliance Zone Model Router Prompt

This prompt is for security engineers and AI infrastructure teams who must route user requests to model deployment zones that comply with data residency, sovereignty, and regulatory requirements. Use it when your system operates across multiple geographic regions, each with distinct compliance boundaries, and you need a deterministic, auditable routing decision before any model invocation. The prompt classifies input sensitivity, maps it to a compliance zone, and selects an approved model deployment. The core job-to-be-done is preventing legal exposure by ensuring that regulated data never touches an unapproved compute environment, not optimizing for cost or latency.

Do not use this prompt for general cost or latency routing; it is purpose-built for regulatory compliance routing where misrouting creates legal exposure. The ideal user has a defined set of compliance zones (e.g., US-EAST-PCI, EU-GDPR, APAC-SOVEREIGN) and a pre-approved mapping of model deployments to those zones. The prompt requires a clear [INPUT] containing the user request and metadata, a [COMPLIANCE_ZONES] definition, and a [MODEL_CATALOG] of approved deployments per zone. If your routing logic is based on token pricing, model capability benchmarks, or simple geographic proximity, use the Cost-Optimized Model Selection Prompt or Latency-Budget Model Routing Prompt instead.

Before implementing, ensure you have a mechanism to pass the prompt's structured output to your actual model invocation layer. The prompt produces a routing decision, not the model response itself. Misusing this prompt as a direct answer generator bypasses the entire compliance boundary it is designed to enforce. If you cannot programmatically enforce that the selected model_deployment_id is used for the subsequent inference call, the prompt provides a false sense of security. Pair this prompt with a hard-coded routing proxy that reads the decision and blocks non-compliant execution paths.

This prompt is designed to be the core decision engine in your routing middleware. It takes a user request and its associated metadata, analyzes it against your defined compliance zones, and outputs a structured routing decision. The template uses square-bracket placeholders for all dynamic inputs, making it ready to be populated by your application logic before being sent to a fast, cost-effective classifier model. The primary goal is to prevent regulated data from ever touching a model deployed in a non-compliant geographic or jurisdictional zone.

textCopy
You are a Compliance Zone Model Router. Your only job is to analyze the provided [INPUT_TEXT] and [INPUT_METADATA] against the defined [COMPLIANCE_ZONES] and select the correct deployment target.

INPUT_TEXT:
"""
[INPUT_TEXT]
"""

INPUT_METADATA:
- Data Subject Jurisdiction: [DATA_SUBJECT_JURISDICTION]
- Request Origin IP Region: [REQUEST_ORIGIN_REGION]
- Authentication Tenant ID: [TENANT_ID]

COMPLIANCE ZONES:
[COMPLIANCE_ZONES]
<!-- Example Zone Definition:
ZONE_ID: zone-eu
DEPLOYMENT_REGION: eu-west-1
ALLOWED_JURISDICTIONS: ["EU", "EEA"]
ALLOWED_TENANT_IDS: ["tenant-eu-*"]
MODEL_ENDPOINT: https://models.eu.example.com/v1
RISK_LEVEL: standard

ZONE_ID: zone-us-highrisk
DEPLOYMENT_REGION: us-east-1
ALLOWED_JURISDICTIONS: ["US"]
ALLOWED_TENANT_IDS: ["tenant-us-finance"]
MODEL_ENDPOINT: https://models.us-highrisk.example.com/v1
RISK_LEVEL: high
-->

[ROUTING_CONSTRAINTS]
<!-- Example Constraints:
- If PII or PHI is detected in INPUT_TEXT, only zones with RISK_LEVEL="high" are permitted.
- If no zone matches, route to ZONE_ID="zone-fallback-review".
- If multiple zones match, select the one with the most specific ALLOWED_TENANT_IDS match.
-->

Based on the INPUT_TEXT, INPUT_METADATA, and COMPLIANCE_ZONES, select the single correct zone. You must output a valid JSON object conforming to the [OUTPUT_SCHEMA].

OUTPUT_SCHEMA:
{
  "selected_zone_id": "string",
  "model_endpoint": "string",
  "routing_reason": "string",
  "detected_regulatory_concerns": ["string"],
  "confidence_score": 0.0
}

To adapt this template, your application must first assemble the [INPUT_TEXT], [INPUT_METADATA], and [COMPLIANCE_ZONES] placeholders. The [COMPLIANCE_ZONES] block is critical; it should be generated dynamically from your infrastructure configuration to ensure the prompt always reflects the current state of your deployment topology. The [ROUTING_CONSTRAINTS] section allows you to inject business logic, such as forcing all inputs containing personally identifiable information (PII) to a high-risk zone. Before deploying any change to this prompt, run it against a golden dataset of inputs with known jurisdictions and PII content to validate that the selected_zone_id and model_endpoint are correct and that no cross-zone data leakage occurs.

This prompt is designed to sit in your request ingress pipeline, before any model invocation that processes user data. Its job is to inspect the raw input, classify its regulatory sensitivity, and return a routing decision that maps the request to a compliant model deployment zone. The prompt does not process the user's request—it only decides where processing can legally occur. This means the prompt must execute with extremely low latency and high reliability, as it is a synchronous gate on every inbound request.

Wire the prompt as a pre-processing middleware function. The application should extract the user's raw input and any available metadata (such as IP geolocation, authentication tenant region, or data residency tags) and inject them into the prompt's [USER_INPUT] and [REQUEST_METADATA] placeholders. The model's response must be parsed as a strict JSON object containing at minimum a routing_decision field (e.g., "US", "EU", "restricted", "block") and a confidence score. Implement a post-processing validator that rejects any response that does not conform to this schema or where the routing_decision is not in your pre-defined set of allowed zones. If validation fails, retry once with a stricter system instruction; if it fails again, route the request to a hardcoded "restricted" quarantine zone and log the failure for immediate review.

For high-assurance deployments, do not rely solely on the model's confidence score. Implement a secondary deterministic check: maintain a list of known PII patterns, regulated data markers (e.g., HIPAA-covered terms, GDPR data subject indicators), and blocklisted phrases. If the model routes a request to a permissive zone but the deterministic scanner flags a high-risk token, override the routing decision to the most restrictive zone and log the discrepancy as a potential model bypass. This defense-in-depth pattern prevents a prompt injection or model error from sending regulated data to an unapproved region. All routing decisions, overrides, and the original prompt-response pair should be logged to an immutable audit store, not just application logs, to satisfy compliance evidence requirements.

Model choice matters here. Use a fast, instruction-tuned model (such as GPT-4o-mini or Claude 3 Haiku) for the routing decision itself. The routing prompt is a classification task, not a generation task, so a smaller model reduces latency and cost without sacrificing accuracy on a well-defined taxonomy. However, you must run a weekly evaluation suite that sends a golden dataset of borderline cases—inputs that mix public and regulated content, non-English regulated data, or obfuscated PII—through the router and compares the decisions against expected labels. Track the rate of restricted-to-unrestricted misroutes as your primary safety metric; any increase above 0.1% should trigger a prompt rollback and investigation.

The next step is to integrate the routing decision into your model dispatch layer. The routing_decision value should map directly to a specific model deployment endpoint or a queue that feeds a compliant processing cluster. Do not pass the routing label as a plain string through untrusted application layers; use a server-side enum or capability token that downstream services verify. Avoid the temptation to add more zones than you can operationally support—each additional zone requires a maintained model endpoint, a documented compliance justification, and a monitoring dashboard. Start with three zones (unrestricted, restricted, block) and expand only when audit and operational maturity permit.