Data Subject Access Request Trace Audit Prompt

This prompt is designed for compliance officers and privacy engineers who must respond to a formal Data Subject Access Request (DSAR) by locating every instance of a specific individual's data within an AI system's production traces. The core job-to-be-done is not real-time redaction or data deletion, but forensic discovery: producing a comprehensive, auditable inventory of trace spans that contain the subject's information. The ideal user has access to a pre-extracted, structured dataset of trace spans—typically exported from an observability platform—and needs to map those spans to data categories, processing purposes, and retention statuses to demonstrate regulatory compliance.

You should use this prompt when you have already isolated a set of candidate trace spans for a given data subject identifier (such as a user ID, email, or device fingerprint) and need to classify the data within them. The prompt assumes the input is a well-formed list of trace spans, each with a unique ID, timestamp, and raw content. It is not a search engine; do not use it to scan unstructured log files or to perform the initial identifier matching. The output is a structured inventory that can be directly attached to a DSAR response package or fed into a governance, risk, and compliance (GRC) tool. This workflow is high-stakes, so every output must be treated as a draft requiring human review before it is shared externally.

Do not use this prompt as a substitute for a proper data catalog, a real-time data redaction pipeline, or an automated deletion mechanism. It will not catch data that exists outside the provided trace spans, such as information in application databases, backup snapshots, or third-party sub-processor logs. If the trace data is incomplete or the subject identifier matching was flawed, the audit will be incomplete. Always pair this prompt with a rigorous upstream data extraction process and a downstream human-in-the-loop review step to verify findings, especially for data categories classified as 'sensitive' or 'restricted'.

This template is designed to be pasted directly into your orchestration layer. It instructs the model to act as a privacy compliance auditor, searching a provided set of production trace spans for any information related to a specific data subject. The prompt uses square-bracket placeholders for all dynamic inputs, such as the subject's identifiers, the trace data itself, and the required output format. This ensures the instruction logic remains stable while the data changes with each DSAR request.

textCopy
You are a meticulous privacy compliance auditor. Your task is to search the provided production trace data for all occurrences of information related to a specific data subject, in response to a Data Subject Access Request (DSAR).

You must identify the subject using the following identifiers:
[SUBJECT_IDENTIFIERS]

Analyze the trace spans provided below. For each span that contains a match, extract the required details and format your entire response as a single JSON object conforming to the specified schema.

[TRACE_DATA]

[OUTPUT_SCHEMA]

Follow these constraints strictly:
[CONSTRAINTS]

Here are a few examples of correct input-output pairs:
[EXAMPLES]

Before producing the final output, use the following tools for validation:
[TOOLS]

This task is classified as [RISK_LEVEL] risk. Ensure your analysis is thorough and your output is strictly validated.

To adapt this template, replace each bracketed placeholder with concrete values for your system. [SUBJECT_IDENTIFIERS] should be a structured list of known IDs, emails, and device fingerprints. [TRACE_DATA] is the raw JSON or text of the trace spans to audit. [OUTPUT_SCHEMA] must be a strict JSON Schema defining the inventory fields (e.g., data category, processing purpose, retention status). [CONSTRAINTS] should include rules like 'do not include spans with no match' or 'redact PII in the output log'. [EXAMPLES] and [TOOLS] are optional but critical for improving accuracy. For high-risk DSARs, always set [RISK_LEVEL] to 'high' and ensure a human reviews the final inventory before it is sent to the data subject.

This prompt is not a standalone chat interaction. It is a batch processing step inside a larger Data Subject Access Request (DSAR) fulfillment pipeline. The harness must feed the prompt structured trace data, enforce output schema compliance, and package results for a human compliance officer who will make the final disclosure decision. Treat the model as an evidence collector and organizer, not as the final authority on what gets released to the data subject.

The implementation loop follows a clear pattern: fetch traces → assemble prompt → validate output → human review → package report. Start by querying your observability platform (LangSmith, Arize, Datadog LLM, or custom trace store) for all spans matching the subject identifier across user IDs, emails, and device fingerprints. De-duplicate and sort spans by timestamp before injecting them into the [TRACE_SPANS] placeholder. The prompt expects each span to include span_id, timestamp, operation, input_summary, output_summary, data_categories_observed, retrieval_sources, and tool_calls. If your trace schema differs, add a pre-processing step that normalizes fields before prompt assembly. Run the prompt with a low-temperature model (0.0–0.2) to maximize deterministic inventory behavior. After generation, validate the JSON output against the expected schema: every entry must have data_subject_identifier, span_id, data_categories, processing_purpose, retention_status, and disclosure_recommendation. Reject and retry any response that fails schema validation or contains unresolved placeholders. Log every run with the trace batch ID, model version, prompt version, and validation result for auditability.

Human review is mandatory before any data is disclosed to the data subject. Route validated outputs to a review queue where a compliance officer can inspect each trace-span entry, override the disclosure_recommendation field, and add notes. The review interface should highlight spans where data_categories includes sensitive or third-party-shared, and flag any span where retention_status is unknown or past-policy. Only after human sign-off should the inventory be assembled into the final DSAR response package. Never automate disclosure directly from model output. For high-volume DSAR operations, consider caching trace inventories per subject identifier with a TTL that matches your regulatory response window, and re-run the prompt only when new traces appear. Avoid running this prompt on raw, unsanitized trace data that includes full message bodies—pre-summarize inputs and outputs to minimize the risk of exposing one data subject's information to the model in the context of another subject's request.