GDPR and Data Protection with OpenAI

AI and the GDPR: A Non-Negotiable Framework

The General Data Protection Regulation (GDPR) applies to any application processing personal data of European residents—including applications built on large language models (LLMs). There are no exceptions for artificial intelligence. This often confuses technical teams: they look for AI-specific regulations when the applicable text has existed for years and hasn’t changed. In 2026, enforcement actions increasingly target AI systems. Using OpenAI’s APIs in this context means less about learning new law and more about translating known legal requirements into a novel architecture.

Seven Principles, Translated for an LLM System

The GDPR rests on seven core principles, each taking on specific meaning when a language model enters the processing chain.

Two principles regularly catch teams off guard. First, accuracy: this turns hallucinations from a quality issue into a regulatory one. When a model generates false information about an identified person, that person has a right to rectification. Second, accountability: being compliant isn’t enough—you must be able to prove it. This transforms documentation from a best practice into a legal obligation.

Minimization: The Measure That Solves Most Problems

Of all available measures, pseudonymization before sending data offers the best balance between effort and risk reduction. The logic is simple: what never leaves your system can’t leak to a subprocessor, can’t raise questions during transfers outside the EU, and won’t complicate erasure requests.

The mechanism below replaces each piece of identifying data with a stable token, keeps the mapping in local memory, and restores original values in the response. The end user sees “Mr. Dupont,” the model sees only “[PERSON_1],” and the service function remains fully intact—the assistant can still draft its response because it never needed the actual surname.

The comment on names isn’t decorative: the pattern captures only forms preceded by a title. A bare name will slip through. In production, a named entity recognition (NER) model takes over, and having this warning explicitly in the code beats false confidence.

import re

class DataMinimizer:
    """Anonymizes personal data before sending to the API."""

    def __init__(self):
        self.mappings: dict[str, str] = {}
        self.counter = 0

    def anonymize(self, text: str) -> str:
        """Replaces personal data with placeholders."""
        # Emails
        text = re.sub(
            r"[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}",
            lambda m: self._replace(m.group(), "EMAIL"),
            text,
        )
        # French phone numbers
        text = re.sub(
            r"(?:0|\+33)[1-9](?:[\s.-]?\d{2}){4}",
            lambda m: self._replace(m.group(), "PHONE"),
            text,
        )
        # Names (simplified pattern—use NER in production)
        text = re.sub(
            r"\b(Mr\.|Ms\.|Dr\.)\s+[A-Z][a-zéèêë]+\s+[A-Z][a-zéèêë]+\b",
            lambda m: self._replace(m.group(), "PERSON"),
            text,
        )
        # IBAN
        text = re.sub(
            r"\b[A-Z]{2}\d{2}\s?\d{4}\s?\d{4}\s?\d{4}\s?\d{4}\s?\d{0,4}\b",
            lambda m: self._replace(m.group(), "IBAN"),
            text,
        )
        return text

    def _replace(self, value: str, type_: str) -> str:
        if value not in self.mappings:
            self.counter += 1
            self.mappings[value] = f"[{type_}_{self.counter}]"
        return self.mappings[value]

    def deanonymize(self, text: str) -> str:
        """Restores original data in the response."""
        reverse = {v: k for k, v in self.mappings.items()}
        for placeholder, original in reverse.items():
            text = text.replace(placeholder, original)
        return text

# Usage
minimizer = DataMinimizer()

original_message = "Mr. Dupont ([email protected], 06 12 34 56 78) requests a refund."
anonymized_message = minimizer.anonymize(original_message)
print(f"Sent to API: {anonymized_message}")
# "[PERSON_1] ([EMAIL_1], [PHONE_1]) requests a refund."

# After model response
model_response = "The file for [PERSON_1] has been processed. An email was sent to [EMAIL_1]."
final_response = minimizer.deanonymize(model_response)
print(f"Final response: {final_response}")

Configure the Service and Collect Consent

On the provider side, know this rule: data sent via the API is not used for training by default, contrary to what many assume by analogy with consumer interfaces. This doesn’t exempt you from checking your organization’s settings on the platform and documenting that verification.

from openai import OpenAI

# With the API, your data is NOT used for training by default
# But verify your organization settings on platform.openai.com

client = OpenAI()

# The Responses API endpoint respects the retention policy
response = client.chat.completions.create(
    model="gpt-5.6-sol",
    messages=[{"role": "user", "content": "Hello"}],
    # store=False disables storage on OpenAI's side if available
)

On the user side, consent is managed by purpose, not globally, which explains the structure here: a user can accept conversational assistance while refusing to have their exchanges used to improve the service. The policy version is recorded with the consent—a critical detail the day you update that policy. Without this trail, you won’t know who agreed to what. Finally, withdrawal triggers immediate deletion, because retaining data after withdrawal is exactly the scenario that turns a routine audit into an enforcement action.

class ConsentManager:
    """Manages user consent for AI processing."""

    def __init__(self):
        self.consent_records: dict[str, dict] = {}

    def record_consent(self, user_id: str, purposes: list[str]):
        """Records explicit user consent."""
        from datetime import datetime
        self.consent_records[user_id] = {
            "purposes": purposes,
            "date": datetime.now().isoformat(),
            "policy_version": "v2.1",
            "method": "explicit_checkbox",
        }

    def verify_consent(self, user_id: str, purpose: str) -> bool:
        """Checks if the user has consented to a specific purpose."""
        if user_id not in self.consent_records:
            return False
        return purpose in self.consent_records[user_id]["purposes"]

    def withdraw_consent(self, user_id: str):
        """Withdraws consent and triggers data deletion."""
        if user_id in self.consent_records:
            del self.consent_records[user_id]
            self._delete_data(user_id)

    def _delete_data(self, user_id: str):
        """Deletes all data associated with the user."""
        # Delete conversation history
        # Delete logs containing personal data
        # Notify subprocessors (OpenAI) if applicable
        print(f"Data deleted for {user_id}")

Responding to Data Subject Requests

Rights of access, erasure, and portability must be implemented before the first request arrives, because the one-month response window disappears fast when you’re still writing the code. The right of access demands more than raw data: you must provide purposes, the list of subprocessors, and retention periods—information you’re better off consolidating in advance.

The right to erasure requires careful code review. The response explicitly distinguishes local data, deleted immediately, from data sent to the API, which falls under the provider’s retention policy. This honesty is mandatory: promising total, instant deletion while a copy remains with a subprocessor exposes you more than clearly documenting both regimes.

class DataSubjectRights:
    """Implements GDPR rights for users."""

    def right_of_access(self, user_id: str) -> dict:
        """Returns all data held on the user."""
        return {
            "personal_data": self._collect_data(user_id),
            "processing_purposes": ["customer_support", "service_improvement"],
            "subprocessors": ["OpenAI (LLM API)", "PostgreSQL (storage)"],
            "retention_period": "12 months after last activity",
            "source": "Direct user input",
        }

    def right_to_erasure(self, user_id: str) -> dict:
        """Deletes all user data."""
        # Delete from local database
        deleted_local = self._delete_local(user_id)
        # Data sent to OpenAI API is subject
        # to their retention policy (max 30 days via API)
        return {
            "status": "deleted",
            "local_data": "deleted",
            "openai_data": "subject to 30-day retention",
            "date": datetime.now().isoformat(),
        }

    def right_to_portability(self, user_id: str) -> dict:
        """Exports data in a structured format."""
        data = self._collect_data(user_id)
        return {
            "format": "JSON",
            "data": data,
            "export_date": datetime.now().isoformat(),
        }

    def _collect_data(self, user_id: str) -> dict:
        return {"user_id": user_id, "conversations": [], "profile": {}}

    def _delete_local(self, user_id: str) -> int:
        return 0

Formalize the Impact Assessment

For any AI application processing personal data at scale, a Data Protection Impact Assessment (DPIA) is mandatory. The structure below shows the expected sections, and the example illustrates what a completed DPIA looks like for a customer service chatbot.

Two fields draw most of a supervisory authority’s attention. First, transfers outside the EU: whenever processing goes through a US provider, you must name the recipient, the country, and the safeguard invoked—here, Standard Contractual Clauses (SCCs) supplemented by OpenAI’s Data Processing Agreement. Second, the risk analysis, which must be specific to the described system. The risk selected in the example is personal data leakage via prompt injection, with mitigation measures being anti-exfiltration guardrails and moderation: everything you built in previous chapters finds its regulatory translation here.

@dataclass
class ImpactAssessment:
    """Structure of a DPIA for an AI system."""
    processing_name: str
    description: str
    legal_basis: str
    data_processed: list[str]
    recipients: list[str]
    transfers_outside_eu: list[dict]
    security_measures: list[str]
    risks: list[dict]
    dpo_opinion: str = ""

dpia_chatbot = ImpactAssessment(
    processing_name="Customer Service Chatbot with AI",
    description="Conversational assistant using GPT-5.6 Sol via OpenAI API",
    legal_basis="Legitimate interest (customer support)",
    data_processed=["first_name", "email", "order_history", "chat_messages"],
    recipients=["Support team", "OpenAI (API subprocessor)"],
    transfers_outside_eu=[{
        "recipient": "OpenAI Inc.",
        "country": "United States",
        "safeguard": "Standard Contractual Clauses (SCCs) + OpenAI DPA",
    }],
    security_measures=[
        "Anonymization before sending to API",
        "TLS encryption in transit",
        "Access logs with 90-day retention",
        "Right to erasure implemented",
    ],
    risks=[{
        "description": "Personal data leakage via prompt injection",
        "likelihood": "medium",
        "severity": "high",
        "mitigation": "Anti-exfiltration guardrails + moderation",
    }],
)

Key Takeaways

• The GDPR applies as soon as an AI system processes data of European residents
• Data minimization (anonymization before sending to the API) is the first reflex
• Data subject rights (access, erasure, portability) must be implemented
• A DPIA is mandatory for large-scale AI processing
• Transfers outside the EU are documented via OpenAI’s DPA and explicit safeguards (SCCs, transfer impact assessment)