Cross-Border Data Transfer Exposure Audit Prompt

This prompt is designed for compliance teams, privacy engineers, and data protection officers who need to audit production AI traces for cross-border data transfers that may violate data residency policies. It assumes your observability pipeline captures trace spans with geo-IP or region metadata, and that you have defined residency policies specifying which data categories are permitted in which regions. The prompt analyzes a batch of trace spans, identifies transfers where data moved from an origin region to a destination region, and produces a structured transfer event with data categories, regions, and the applicable transfer mechanism. Use this prompt when you need to generate audit evidence for regulatory reviews, detect misconfigured infrastructure that routes data through unapproved regions, or monitor ongoing compliance with binding corporate rules or standard contractual clauses.

This is not a real-time enforcement tool; it is a post-hoc audit prompt for periodic or event-driven compliance reviews. Do not use this prompt to block requests in the hot path of a production application—latency and the risk of false positives make it unsuitable for inline gating. The prompt requires that your trace spans already contain origin_region and destination_region fields populated from geo-IP or cloud region metadata. If your observability pipeline does not capture this metadata, you must instrument it before this prompt becomes useful. The prompt also expects a [RESIDENCY_POLICY] document that defines allowed and prohibited transfer patterns per data category. Without a clear policy, the model cannot distinguish between compliant and non-compliant transfers.

Before running this prompt at scale, validate its performance on a labeled set of 50–100 trace spans where you know the ground-truth transfer classifications. Measure precision and recall on the transfer_detected flag, and manually review any false positives where the model flagged a transfer that stayed within an approved region. Common failure modes include misinterpreting region codes (e.g., treating eu-west-1 as a single region rather than a sub-region of the EU), missing transfers where data passed through an intermediate service, and over-flagging transfers that use approved adequacy mechanisms. If your residency policy includes complex conditions such as 'data may transit through region X only if encrypted at rest,' you may need to supplement this prompt with a second verification step that checks encryption metadata in the trace spans.

Use this prompt as part of a scheduled compliance review cadence—weekly for high-volume systems, monthly for lower-risk workloads—and store the structured output in an audit log that your governance team can query. Pair it with the 'GDPR Article 30 Record Trace Verification Prompt' if you need to reconcile observed transfers against your formal record of processing activities. If you detect a pattern of violations, escalate to infrastructure engineering to review routing configurations, CDN settings, or multi-region failover policies that may be causing unintended data movement.

The prompt below is designed to analyze a single production trace span or a set of related spans and identify any cross-border data transfer events. It requires that your trace data includes geographic metadata—such as origin and destination region tags, IP geolocation data, or cloud region identifiers—attached to each span. Without this metadata, the prompt cannot perform a meaningful audit. The template uses square-bracket placeholders for all variable inputs, including the trace data, your organization's residency policy, and the expected output schema. Replace each placeholder with concrete data before sending the prompt to the model.

codeCopy
You are a data residency compliance auditor. Your task is to review the provided production trace data and identify any cross-border data transfer events that may violate the organization's data residency policy.

## INPUT DATA

### Trace Spans
[TARGET_TRACE_SPANS]

### Data Residency Policy
[RESIDENCY_POLICY_RULES]

### Known Transfer Mechanisms
[APPROVED_TRANSFER_MECHANISMS]

## INSTRUCTIONS

1. For each span in the trace, extract the origin region and destination region from the span's geographic metadata. If a span does not contain both an origin and a destination region, note it as "INSUFFICIENT_METADATA" and exclude it from further analysis.
2. Compare each origin-destination pair against the residency policy rules. A transfer event occurs when data moves from a region with a residency restriction to a region outside the permitted boundary.
3. For each transfer event, identify the data categories present in the span payload (e.g., PII, PHI, credentials, financial data, internal documents).
4. Determine whether the transfer used an approved transfer mechanism from the provided list. If no mechanism is identifiable, flag the mechanism as "UNKNOWN".
5. Assign a risk level to each transfer event: HIGH (restricted data crossed a prohibited boundary with no approved mechanism), MEDIUM (restricted data crossed a prohibited boundary with an approved mechanism, or non-restricted data crossed without a mechanism), LOW (non-restricted data crossed with an approved mechanism).
6. Do not invent transfer events. If no cross-border transfer is detected, return an empty findings array.
7. Do not include spans that lack both origin and destination metadata in the output.

## OUTPUT SCHEMA

Return a valid JSON object with this exact structure:

{
  "audit_id": "string, unique identifier for this audit run",
  "trace_id": "string, the trace identifier from the input",
  "findings": [
    {
      "finding_id": "string, unique per finding",
      "span_id": "string, the span where the transfer was detected",
      "origin_region": "string, e.g., 'eu-west-1' or 'Frankfurt'",
      "destination_region": "string, e.g., 'us-east-1' or 'Virginia'",
      "data_categories": ["string, e.g., 'PII', 'PHI', 'credentials'"],
      "transfer_mechanism": "string or null, e.g., 'Standard Contractual Clauses', 'Binding Corporate Rules', 'UNKNOWN'",
      "mechanism_approved": "boolean, true if the mechanism is in the approved list",
      "policy_rule_violated": "string or null, the specific policy rule that was violated",
      "risk_level": "string, one of 'HIGH', 'MEDIUM', 'LOW'",
      "evidence": "string, brief description of what data was observed crossing the boundary"
    }
  ],
  "summary": {
    "total_spans_reviewed": "integer",
    "spans_with_insufficient_metadata": "integer",
    "total_transfer_events": "integer",
    "high_risk_count": "integer",
    "medium_risk_count": "integer",
    "low_risk_count": "integer"
  }
}

## CONSTRAINTS

- Only flag transfers where both origin and destination metadata are present and differ.
- Do not flag intra-region data movement as a cross-border transfer.
- If the residency policy permits a specific cross-border flow, do not flag it as a violation.
- If data categories cannot be determined from the span payload, use "UNKNOWN" as the category.
- Return only the JSON object. No additional commentary.

After copying the template, replace [TARGET_TRACE_SPANS] with the actual span data from your observability platform. This data must include geographic metadata fields such as origin_region, destination_region, or equivalent IP-geolocation tags. Replace [RESIDENCY_POLICY_RULES] with a structured description of your organization's data residency constraints—for example, "PII collected in the EU must not be processed or stored outside the EEA unless Standard Contractual Clauses are in place." Replace [APPROVED_TRANSFER_MECHANISMS] with a list of your organization's sanctioned transfer safeguards, such as "Standard Contractual Clauses, Binding Corporate Rules, EU-US Data Privacy Framework." If your trace spans use different field names for geographic metadata, adjust the instructions in step 1 to match your schema before running the prompt. The output schema is designed to be machine-readable so you can pipe findings directly into a compliance dashboard or ticketing system. Always validate the JSON output against the schema before ingesting it downstream, and flag any finding with a risk level of HIGH for immediate human review.

This prompt is designed to operate as a batch trace analysis step within a privacy compliance pipeline, not as a real-time user-facing feature. The harness must feed the prompt structured trace spans that already contain geo-IP or region metadata. Without this metadata, the prompt cannot determine data origin or destination and will produce unreliable results. The typical integration point is a scheduled job that queries your observability backend (e.g., Datadog, Grafana, or an internal trace store) for spans matching a time window, enriches them with region tags, and then invokes the LLM with this prompt for each candidate span that crossed a region boundary.

Validation and retry logic is critical because the output schema defines a compliance artifact. Implement a post-generation validator that checks: (1) the transfer_event object is present and non-null, (2) data_categories is a non-empty array of strings matching your internal taxonomy, (3) origin_region and destination_region are valid ISO 3166-2 or cloud region codes, (4) transfer_mechanism is one of the enumerated values you define in [CONSTRAINTS], and (5) applicable_safeguard is populated when the mechanism is 'SCCs' or 'BCRs'. If validation fails, retry once with the validation error message appended to the prompt as additional context. If the retry also fails, log the raw span and the failed output to a human review queue rather than silently dropping the event. For high-risk transfers involving [RISK_LEVEL] = 'critical' data categories (e.g., government ID, health data), always route to human review regardless of validation success.

Model choice and grounding: Use a model with strong structured output capabilities and a large context window (e.g., Claude 3.5 Sonnet or GPT-4o) because trace spans can be verbose. Set temperature=0 to maximize schema adherence. The prompt does not require tool use or RAG because all evidence must come from the provided trace span; external retrieval would introduce stale or irrelevant policy data. However, you should inject your organization's current data residency policy and approved transfer mechanism list into [CONSTRAINTS] at invocation time from a configuration store, not hard-coded into the prompt template. This keeps the prompt policy-agnostic and auditable. Log every invocation with trace_id, span_id, model_version, prompt_version, and the full output for audit trail purposes. Next, integrate the validated transfer events into your compliance dashboard and set an alert threshold: if the count of 'unauthorized' transfer events exceeds zero in any 24-hour window, trigger a notification to the privacy engineering team.