Data Residency and Sovereignty Risk Assessment Prompt

Use this prompt at the ingress layer of any AI pipeline that ingests, processes, or stores unstructured text across geographic regions. Its primary job is to classify content for data residency and sovereignty risk before that content enters downstream processing, storage, or cross-border transfer systems. Cloud architects, compliance officers, and platform engineers deploy this prompt to determine which jurisdiction's laws likely govern a piece of content, whether transfer restrictions apply, and what processing locality constraints must be enforced. This is a classification and routing control, not a legal advice generator. It reduces the risk of misrouted sensitive data creating regulatory exposure by ensuring that content with potential residency requirements is flagged and handled according to its jurisdictional profile before any model inference, storage commit, or cross-region transfer occurs.

This prompt is appropriate when you need an automated, deterministic first pass over multi-region customer data, employee records, or regulated content. It works best when paired with a defined taxonomy of jurisdictions, data types, and transfer restriction triggers that your organization has already mapped to specific handling policies. For example, you might configure the prompt to classify whether a support ticket contains EU personal data subject to GDPR transfer restrictions, or whether an internal document references Canadian provincial health data that must remain within provincial boundaries. The prompt outputs structured jurisdiction determinations and processing locality constraints that your application layer can enforce. It is not designed for real-time legal interpretation of novel regulatory scenarios, nor should it be the sole decision-maker for high-risk cross-border transfers. Always route high-confidence sovereignty flags to a human review queue and maintain audit logs of every classification decision for compliance evidence.

Do not use this prompt as a replacement for formal jurisdictional analysis by qualified counsel. It will not interpret nuanced legal tests like the 'Schrems II' transfer impact assessment or determine whether standard contractual clauses provide adequate safeguards for a specific data flow. It is a classification tool that maps content signals to your predefined risk taxonomy. If your organization lacks a clear data residency policy or jurisdiction taxonomy, deploy this prompt only after those definitions are in place. For high-risk regulated domains such as healthcare, defense, or financial services, always pair automated classification with human review and evidence grounding. The next section provides the copy-ready prompt template you can adapt to your jurisdiction taxonomy and processing constraints.

This template is designed to be pasted directly into your system instructions for a classification step that runs before any downstream processing or storage. It forces the model to reason about jurisdiction, data type, and regulatory triggers, then output a structured determination that your application can use to enforce processing locality. Replace every square-bracket placeholder with your organization's specific taxonomies, supported regions, and routing rules before deployment. The prompt is built to be used in a zero-shot manner, but you should add few-shot examples in the [EXAMPLES] section for any edge cases specific to your data.

textCopy
You are a data residency and sovereignty classification engine. Your task is to analyze the provided content and determine which jurisdictions' data protection and sovereignty laws are triggered. You must output a structured JSON object that downstream systems will use to enforce processing locality, block transfers, or route data to region-specific infrastructure.

## INPUT
[INPUT]

## TAXONOMY
Use the following taxonomy to classify the content:
- Data Subject Residency Indicators: [RESIDENCY_INDICATORS]
- Regulated Data Types: [REGULATED_DATA_TYPES]
- Sovereignty-Sensitive Contexts: [SOVEREIGNTY_CONTEXTS]

## SUPPORTED JURISDICTIONS
[JURISDICTIONS]

## CONSTRAINTS
- Do not infer residency from IP addresses or metadata unless explicitly stated in the content.
- If the content contains mixed jurisdictions, list all that apply.
- If no residency or sovereignty trigger is detected, output an empty array for `triggered_jurisdictions`.
- Do not output any text outside the JSON object.

## OUTPUT SCHEMA
```json
{
  "content_summary": "string (max 200 chars)",
  "triggered_jurisdictions": [
    {
      "jurisdiction": "string",
      "trigger_reason": "string",
      "confidence": "float (0.0 to 1.0)",
      "required_action": "PROCESS_LOCALLY | BLOCK_TRANSFER | REVIEW_REQUIRED | NO_RESTRICTION"
    }
  ],
  "contains_pii": "boolean",
  "recommended_processing_region": "string | null"
}

EXAMPLES

[EXAMPLES]

RISK LEVEL

Current risk classification for this task: [RISK_LEVEL]

After pasting this template, the most critical adaptation step is defining your [JURISDICTIONS] and [REGULATED_DATA_TYPES] precisely. Vague categories like "health data" will produce inconsistent results; instead, map them to specific regulatory definitions such as "HIPAA PHI," "GDPR Article 9 special categories," or "Australian My Health Records Act data." For the [EXAMPLES] block, include at least one example that shows a false positive (e.g., a medical discussion that does not contain PHI) and one that shows a true positive with mixed jurisdictions. This teaches the model the boundary between general topic and regulated data. If your application operates in a high-risk environment, set [RISK_LEVEL] to high and add a human review step for any output where confidence is below 0.9 or required_action is BLOCK_TRANSFER. Validate the output against this schema in your application code before acting on it; a malformed JSON response should trigger a retry or escalation, never a silent default to unrestricted processing.

This prompt is designed to operate as a pre-processing classification gateway before any content enters a general-purpose model, vector database, or cross-region processing pipeline. The implementation harness must treat the prompt's output as a deterministic routing decision, not an advisory note. The JSON output—containing jurisdiction_determinations, transfer_restriction_triggers, and required_processing_locality—should be parsed by application code that enforces the constraints. If the prompt flags cross_border_transfer_restricted: true or identifies a regulated jurisdiction with data localization requirements (e.g., Russia's Federal Law No. 242-FZ, China's PIPL, EU GDPR adequacy decisions), the application must block the content from leaving the specified geographic boundary. This is not a soft recommendation; it is a hard enforcement point in your AI pipeline architecture.

Integration pattern: Deploy this prompt as a synchronous pre-check in your request path. The application should: (1) Accept the user input or document content. (2) Call the prompt with the content and any available metadata about the user's location, data subject residency, or processing region. (3) Parse the JSON response and validate it against an expected schema using a library like pydantic or zod. If the output fails schema validation, retry once with a stricter prompt variant that includes the validation error in the retry context. If the retry also fails, escalate to a human reviewer and block processing. (4) On successful parse, check the processing_locality_constraints field. If any constraint requires data_residency: local_only or cross_border_allowed: false, route the content to a region-locked inference endpoint, a local model deployment, or a human review queue. Log the full prompt input, output, and routing decision to an immutable audit trail for compliance evidence. (5) For content that clears all residency checks, attach the classification metadata to the request context so downstream systems can apply appropriate data handling policies.

Model selection and latency: Use a fast, instruction-following model for this classification task—GPT-4o-mini, Claude 3.5 Haiku, or a fine-tuned open-weight model deployed in-region. The prompt does not require deep reasoning; it requires precise schema adherence and low latency. Set a strict timeout (under 3 seconds) and implement a circuit breaker that routes to a conservative deny-and-escalate path if the model endpoint is unavailable. For high-throughput pipelines, batch these assessments asynchronously and cache jurisdiction determinations for known document types or data subject regions, but invalidate the cache when regulatory guidance changes. Do not use this prompt's output as the sole basis for legal compliance decisions—always maintain a human review path for ambiguous cases, especially when the prompt returns confidence_score below 0.85 or flags regulatory_ambiguity: true.

Testing and failure modes: Before production deployment, build an eval suite with golden examples covering: (a) clear EU personal data with GDPR triggers, (b) Russian citizen data with localization requirements, (c) US-only content with no cross-border restrictions, (d) ambiguous cases where jurisdiction is unclear, and (e) adversarial inputs attempting to hide residency signals. Measure precision and recall on restriction flagging, and pay special attention to false negatives—a missed residency restriction creates regulatory exposure. The most common production failure mode is the model failing to detect implicit residency signals (e.g., a local phone number format, a regional ID reference, or a non-English language variant that implies jurisdiction). Mitigate this by including a pre-processing step that extracts explicit location signals before the prompt runs, and by maintaining a deny-list of high-risk patterns that trigger automatic escalation regardless of model output.