Audit and Compliance

The audit log schema

Here is a complete audit log schema for an AI data privacy pipeline. Every field is designed to support compliance requirements without storing PII.

What to log:

{
  "event_id": "uuid-v4",
  "timestamp": "2026-03-15T14:23:45.123Z",
  "session_id": "session-uuid",
  "user_id": "employee-id-or-hash",
  "classification_level": 3,
  "classification_basis": "contains_pii_gdpr_applicable",

  "detection_summary": {
    "total_entities_detected": 4,
    "entity_types": {
      "PERSON": { "count": 2, "avg_confidence": 0.89 },
      "EMAIL": { "count": 1, "avg_confidence": 0.99 },
      "DATE": { "count": 1, "avg_confidence": 0.75 }
    },
    "detection_layers_used": ["regex", "ner_spacy"],
    "detection_latency_ms": 42
  },

  "redaction_summary": {
    "strategy": "pseudonymisation",
    "entities_redacted": 4,
    "entities_passed": 0,
    "entities_flagged_for_review": 0
  },

  "routing_decision": {
    "destination": "cloud_ai",
    "provider": "anthropic",
    "model": "claude-sonnet-4-20250514",
    "via_gateway": true,
    "rationale": "level_3_medium_complexity"
  },

  "response_summary": {
    "rehydration_applied": true,
    "response_pii_scan_result": "clean",
    "total_latency_ms": 3420
  }
}

What NOT to log:

• The actual text of the prompt (it may contain PII that was not detected)
• The actual PII values detected (this creates a secondary PII store)
• The pseudonymisation mapping (this enables re-identification of the audit trail)
• The AI response (it may contain generated PII or reflect the pseudonymised content)
• Any data that would allow reconstruction of the original prompt

Edge case: when you need to log content for debugging

Sometimes you need to debug a pipeline failure and the metadata alone is not sufficient. In these cases:

• Log the sanitised (post-redaction) content, never the raw content
• Place content logs in a separate, access-controlled store with short retention (24-48 hours)
• Require explicit authorisation to enable content logging (not a default setting)
• Automatically purge content logs after the debugging period

Data Protection Impact Assessment for AI systems

A DPIA (Data Protection Impact Assessment) is required under GDPR Article 35 for processing that is "likely to result in a high risk to the rights and freedoms of natural persons." If your AI system processes personal data of EU residents, you should conduct a DPIA — and even if a DPIA is not strictly required, it is a valuable exercise for documenting your privacy posture.

When a DPIA is required for AI systems:

The Article 29 Working Party (now the European Data Protection Board) identified nine criteria — if your processing meets two or more, a DPIA is required:

1. Evaluation or scoring (including profiling)
2. Automated decision-making with legal or significant effect
3. Systematic monitoring
4. Sensitive data or data of highly personal nature
5. Data processed on a large scale
6. Matching or combining datasets
7. Data concerning vulnerable subjects
8. Innovative use of technology (AI qualifies)
9. Processing that prevents data subjects from exercising a right

Most enterprise AI systems meet at least criteria 8 (innovative technology) and one or more others. In practice, if you are processing personal data through AI, do the DPIA.

What a DPIA must contain (Article 35(7)):

1. Systematic description of the processing operations and their purposes. For an AI system: what data enters the system, how it is processed (cloud AI, local inference, gateway pattern), what outputs are generated, and what decisions are informed by those outputs.

2. Assessment of necessity and proportionality. Why is AI processing necessary for this purpose? Could the purpose be achieved with less data or less invasive processing? Does the volume of data processed match the purpose, or is there over-collection?

3. Assessment of risks to data subjects' rights and freedoms. What happens if PII leaks through the pipeline? What is the severity and likelihood of harm? Consider both privacy risks (identity theft, discrimination) and autonomy risks (opaque automated decisions).

4. Measures to address the risks. This is where your privacy architecture maps to the DPIA. Your detection pipeline, redaction strategy, gateway pattern, local inference for high-sensitivity data, audit logging, and incident response plan are all risk mitigation measures.

Practical DPIA for an AI data privacy pipeline:

Document each pipeline stage and its privacy implications:

• Ingestion: what data sources, what consent or lawful basis
• Classification: how data sensitivity is determined, who defined the classification rules
• Detection: what PII types are detected, accuracy metrics, what happens to undetected PII
• Redaction: technique used, whether data is truly anonymised or only pseudonymised
• Routing: where data is sent, what legal mechanism covers the transfer (SCCs, adequacy decision, etc.)
• Audit: what is logged, retention period, access controls
• Incident response: what happens when the pipeline fails to catch PII

When PII leaks through the pipeline

Your pipeline will not be perfect. At some point, PII will pass through detection undetected and reach a cloud AI service. When this happens, you need an incident response plan specific to AI data privacy incidents.

Detection of the incident:

AI PII leaks are typically discovered through:

• Post-hoc audit analysis (periodic review of a sample of sanitised prompts reveals missed PII)
• User reports ("I think my SSN was in that document I sent through the AI tool")
• Automated monitoring (a secondary detection pass on a sample of gateway-forwarded prompts)
• External notification (the AI provider's trust and safety team identifies PII in your traffic)

Incident response steps:

1. Contain. If the leak is ongoing (a detection rule gap), deploy an emergency fix — temporarily increase detection thresholds or route affected data to local inference while you fix the gap.

2. Assess scope. How many requests were affected? What PII types were exposed? What classification levels? What AI providers received the data? Use your audit logs (which record detection results per request) to bound the scope.

3. Notify the provider. Contact the AI provider's security team and request deletion of the affected data. For providers with zero-retention agreements, the data should already be deleted. For providers with 30-day retention, request expedited deletion. Document the request and the provider's response.

4. Regulatory notification. Under GDPR Article 33, you must notify your supervisory authority within 72 hours of becoming aware of a personal data breach that is likely to result in a risk to individuals' rights. Under HIPAA, breaches of unsecured PHI affecting 500+ individuals must be reported to HHS within 60 days. Assess whether your incident meets reporting thresholds.

5. Data subject notification. Under GDPR Article 34, if the breach is likely to result in a high risk to individuals, you must notify the affected data subjects "without undue delay." Under HIPAA, individual notification is required for breaches of unsecured PHI.

6. Root cause analysis. Why did the detection pipeline miss the PII? Was it a new PII format, a language the pipeline does not support, contextual PII that only the LLM layer would catch, or a configuration error?

7. Remediation. Fix the detection gap, update the red-team test suite to include the missed case, and verify the fix against the red-team tests before returning to normal operations.

The top 10 questions your auditor will ask

When auditors evaluate your AI data handling, they follow the same methodology they use for any data processing system: understand the data flows, verify the controls, test the effectiveness, and check the documentation. Here are the questions you should be prepared to answer.

1. "Can you show me a diagram of how data flows through your AI systems — from user input to AI processing to response?" Have your pipeline architecture documented with data flow arrows. Mark where data is classified, where PII detection occurs, where redaction happens, where data leaves your environment, and where it is stored (even temporarily).

2. "What data classification scheme do you use for AI workloads, and how are classification decisions made?" Present your AI-specific classification framework (Module 2). Demonstrate that classification is systematic (decision tree or automated), not ad hoc.

3. "What types of PII does your detection system identify, and what is its accuracy?" Present your red-team test results showing recall and precision per entity type. Auditors want to see evidence of testing, not just claims of capability.

4. "What happens to data that your detection system does not flag as PII?" Explain your classification-based routing: Level 1-2 data may not need detection; Level 3+ data goes through detection. Acknowledge that no detection system is perfect and describe your mitigation (layered detection, periodic post-hoc review).

5. "Where is data stored, and for how long?" Map every data store: user's device, gateway processing memory (transient), cloud AI provider (retention period per DPA), audit logs (retention period), pseudonymisation mapping (destroyed after re-hydration).

6. "Who has access to the audit logs, and how is access controlled?" Document RBAC (Role-Based Access Control) for audit log access. Demonstrate that audit logs do not contain PII.

7. "What is your incident response plan for a PII leak through the AI pipeline?" Present the documented plan from the previous section. Auditors want to see that the plan exists, that roles are assigned, and that it has been tested.

8. "How do you evaluate the data handling practices of your AI vendors?" Present your vendor risk assessment questionnaire (Module 10). Show the DPAs you have in place, the SOC 2 reports you have reviewed, and the vendor assessment records.

9. "Have you conducted a Data Protection Impact Assessment for this AI system?" Present your DPIA. If you have not done one, explain why you determined one was not required (and be prepared for the auditor to disagree).

10. "How do you train employees on AI data handling policies, and how do you measure compliance?" Present your training programme (Module 11). Show completion rates, policy acknowledgment records, and any metrics on shadow AI reduction.