Logging AI interactions without creating a new personal database

Artificial intelligence (AI) systems collect millions of text, voice or visual exchanges every day. Logging them supports traceability, drift detection and regulatory compliance. Poorly designed logs, however, can become a database of personally identifiable information (PII), creating legal and security risks. Pseudonymisation, encryption and differentially private aggregation can help limit those risks.

Introduction

Imagine a major bank deploying a virtual assistant capable of answering customer queries 24/7. Every dialogue is potentially rich in personal information: names, account numbers, transaction history, or even biometric data from voice recognition. The legal department demands audit trails to prove the bot does not commit an error (e.g., disseminating incorrect information). Consequently, the DevSecOps team configures the inference server logs and quickly discovers that each log entry contains the entirety of the user request, effectively creating a rapidly growing database of personal data.

This scenario, now common among companies integrating generative models (ChatGPT, Claude, Gemini) or decision-making AI, raises two fundamental questions:

• How can the traceability and auditability of AI interactions be guaranteed?
• **How can we prevent the logging system from creating a new source of personal data subject to the requirements of GDPR, French data protection law, or other frameworks (CCPA, HIPAA...)?

Effective logging combines three elements: a clear legal and governance framework, data minimisation and anonymisation, and a secure observability architecture.

1 Context: The explosion of AI interactions and the necessity of logging

Without reliable logging, the company is exposed to:

• Non-compliance risks – penalties of up to 4% of annual global turnover under GDPR.
• Loss of trust – customers may abandon a service perceived as opaque.
• Security incidents – a lack of audit trails complicates the response to compromises.

2 Why does AI logging differ from traditional logging?

• Data volume and diversity – Prompts, conversation contexts (previous messages), and metadata (session IDs, timestamps, latency) form a continuous, often unstructured stream.
• Intrinsic sensitivity – Even an innocuous phrase ("I want to change my address") can reveal multiple personal attributes when correlated with other logs.
• Model lifecycle – Models evolve (fine-tuning, updates); logs must remain intelligible despite these changes.
• Explainability requirements – To comply with access or rectification requests (Art. 15 GDPR), it must be possible to reconstruct the decision-making context without exposing raw data.

These specificities necessitate a 'privacy-by-design' logging approach, which does not merely store traces but transforms them to eliminate or mask PII upon ingestion.

3 Risks associated with the creation of personal databases via logs

These risks justify the adoption of technical protection mechanisms from the point of entry of the log stream.

4 Technical principles for logging without creating PII

4.1 Minimisation and filtering at source

• Field whitelisting – Retain only indispensable metadata (timestamp, anonymised session ID, error code).
• Pattern matching – Use regular expressions or detection patterns (e.g., ANSSI PII-Regex) to eliminate names, card numbers, and email addresses before persistence.

4.2 Pseudonymisation & tokenisation

• Single-use pseudonyms – Generate a random identifier (UUID v4) linked to the session; the actual mapping is stored separately in a vault (e.g., HashiCorp Vault).
• Reversible tokenisation only for legal requirements (e.g., right of access); otherwise, apply non-reversible tokenisation.

4.3 Encryption at rest and in transit

• AES-256-GCM symmetric encryption at the disk or stored object level (S3 SSE-KMS, Azure Blob encryption).
• TLS 1.3 mandatory for all log flows (OpenTelemetry collector → backend).

4.4 Differentially private aggregation

• Differential Privacy (DP) – Add calibrated noise to aggregated metrics (e.g., error counts by category) before storage in an analytical data lake.
• Reference libraries: Google DP, OpenDP.

4.5 Immutability and hash chains

• Immutable log – Use append-only systems such as Amazon QLDB, Azure Confidential Ledger or an Elasticsearch cluster with read-only indices after validation.
• Hash-chain – Each entry includes the hash of the previous entry, ensuring integrity and non-repudiation.

4.6 Lifecycle Management (retention)

• Policy-as-Code (e.g., Open Policy Agent) to automate purging after X days based on the legal purpose.
• Encrypted Archiving – Move logs beyond the active period to cold storage (Glacier, Azure Archive) using a separate encryption key.

5 Possible Architectures

5.1 'Immutable Log Store + Secure Processing' Architecture (example)

Read the diagram notation

flowchart LR
    A[Application IA] -->|Prompt & Réponse| B[OpenTelemetry Collector]
    B -->|Export TLS| C["(Kafka Topic – encrypted)"]
    C --> D["Log Immuable Service (QLDB / Ledger)"]
    D --> E["SIEM / Observabilité (Splunk, Elastic, Grafana Loki)"]
    D --> F["Data Lake Analytique (S3 + DP aggregation)"]
    subgraph Secure Vault
        G[HashiCorp Vault] -- Mapping PII → UUID --> B
    end
    style A fill:#f9f,stroke:#333,stroke-width:2px
    style D fill:#bbf,stroke:#333,stroke-width:2px

• OpenTelemetry Collector acts as the entry point where PII filters are applied.
• Kafka ensures resilience and decoupling; each message is encrypted with a rotating key.
• QLDB / Confidential Ledger guarantees immutability via a journal signed by AWS KMS.
• SIEM consumes only anonymised metadata for anomaly detection.
• Data Lake receives differentially private aggregates for business reporting.

5.2 'Serverless + Cloud-Native Logging' Variant

This approach minimises the attack surface (no persistent server) but requires strict governance of serverless functions.

6 Regulatory Framework and Compliance Requirements

In practice, each organisation must conduct a Data Protection Impact Assessment (DPIA) upon the deployment of generative AI to identify sensitive data flows and validate that the aforementioned mechanisms comply with legal requirements.

7 Operational implementation: from code to observability

Integrating these steps into the CI/CD pipeline (GitLab CI, GitHub Actions) allows each modification to the logging code to be validated with unit tests and compliance scans (e.g., Checkov, tfsec for infrastructure).

8 Use case: customer service chatbot logging

Context

An insurance company deploys a virtual assistant capable of:

• Answering questions regarding coverage.
• Initiating a claim (uploading a photo, description).

Each interaction is subject both to GDPR requirements (right of access) and the need to detect erroneous responses that could lead to disputes.

Implemented architecture

• Input – The bot receives text via an HTTPS endpoint protected by OAuth 2.0.
• PII Filtering – A Node.js middleware applies ANSSI regex and replaces policy numbers ([0-9]{10}) with ##########.
• Session UUID – Generation of a UUID v4, stored in an HttpOnly cookie; the actual mapping (contract number ↔ UUID) is recorded in Vault with an “only‑read‑by‑DPO” policy.
• Log Export – OpenTelemetry Collector sends logs to an encrypted Kafka topic.
• Immutable Store – The topic feeds Amazon QLDB, with each entry containing the hash of the previous one (hash‑chain).
• SIEM – Elastic Stack consumes only anonymised fields (session_id, response_code, latency).
• DP Analysis – A Spark job reads logs from QLDB, aggregates the number of responses by error category, and adds Laplacian noise (ε = 0.5) before publishing a PowerBI dashboard accessible to managers.

Results obtained

| GDPR Compliance | Estimated fine risk of €150k | DPIA validated, no findings