How to Make AI API Calls GDPR-Compliant

Every LLM API call sends data to a third party. Under GDPR, that's a transfer to a data processor. Learn how to make your AI API calls compliant — lawful basis, data minimization, PII redaction, and EU-hosted processing.

The problem: every AI API call is a data transfer

Every time your application sends a prompt to OpenAI, Anthropic, or Google, you're transferring data to a third-party processor. If that prompt contains personal data — and it almost certainly does — you have GDPR obligations.

Most teams don't think about it this way. They see an API call. GDPR sees a data processing operation involving a controller (you), a processor (the AI provider), and data subjects (your users).

The penalties are real: up to 20 million EUR or 4% of global annual turnover. And regulators are paying attention to AI. The Italian DPA temporarily banned ChatGPT in 2023. The French CNIL has published specific guidance on AI and personal data. The European Data Protection Board issued an opinion on AI models and GDPR in 2024.

This guide covers the practical engineering steps to make your AI API calls GDPR-compliant. It's not legal advice — talk to your DPO for that. This is what you need to implement.

GDPR basics for AI API calls

Six principles apply every time you send data to an AI provider:

  1. Lawful basis — You need a legal ground to process personal data. For AI API calls, this is usually legitimate interest (Article 6(1)(f)) or the performance of a contract (Article 6(1)(b)). Consent works too, but it must be freely given, specific, informed, and withdrawable — hard to implement for every API call.

  2. Purpose limitation — You can only use personal data for the purpose you collected it. If users gave you their email for account management, you can't feed it into a marketing prompt without a separate legal basis.

  3. Data minimization — Only send the personal data that's strictly necessary. If the AI model doesn't need the user's name to generate a summary, don't include it.

  4. Storage limitation — Don't keep personal data longer than needed. This applies to logs, caches, and any stored prompts or responses.

  5. Integrity and confidentiality — Protect data in transit and at rest. TLS is a minimum. Encryption at rest is expected.

  6. Accountability — You must be able to demonstrate compliance. That means documentation, audit trails, and data processing records.

For AI API calls specifically, data minimization is where most teams fail. It's easy to dump an entire support ticket into a prompt when the model only needs a summary.

What counts as personal data in prompts

Personal data is any information relating to an identified or identifiable natural person. In AI prompts, PII shows up in places you don't expect:

Obvious PII:

  • Names, email addresses, phone numbers
  • Physical addresses, dates of birth
  • Social security numbers, tax IDs
  • Credit card numbers, bank account numbers

Less obvious PII:

  • IP addresses (yes, these are personal data under GDPR)
  • User IDs that can be linked back to a person
  • Device identifiers and cookie values
  • Location data, even approximate
  • Health information mentioned in support tickets
  • Employment details, salary information

PII hiding in typical prompts:

  • Support tickets: "Customer john.doe@company.com reports..." — name and email embedded in the ticket text
  • RAG chunks: Documents retrieved from your vector store may contain personal data from the original source
  • CRM data: Customer records pulled into prompts for personalization
  • Chat history: Previous messages in a conversation often contain names, locations, and other identifiers
  • Code snippets: Hardcoded credentials, API keys, database connection strings with usernames

The risk isn't just direct identifiers. Under GDPR, data is personal if it can be combined with other information to identify someone. A user ID alone might not be personal data — but a user ID plus a timestamp plus a location probably is.

The data transfer problem

Most major AI providers — OpenAI, Anthropic, Google — are US-based companies. Sending personal data to them is a cross-border transfer under GDPR Chapter V.

Since the Schrems II ruling invalidated the Privacy Shield, US transfers require:

  • Standard Contractual Clauses (SCCs) — Contractual commitments between you and the processor. OpenAI and Anthropic offer these in their data processing agreements.
  • Supplementary measures — Technical or organizational measures that ensure the level of protection isn't undermined. Encryption in transit isn't enough on its own — the provider can still access plaintext data to process your request.
  • Transfer Impact Assessments (TIAs) — Documentation showing you've assessed the legal framework in the recipient country and the risks to data subjects.

The EU-US Data Privacy Framework (DPF), adopted in July 2023, provides an adequacy basis for transfers to certified US companies. But it faces legal challenges, and relying solely on it is risky.

The simplest approach: don't transfer personal data at all. If you redact PII before the API call, there's no cross-border transfer of personal data to worry about. The prompt contains only anonymized or pseudonymized data, which falls outside GDPR's transfer restrictions.

Practical steps to comply

1. Audit what you're sending

Before you can minimize data, you need to know what data you're sending. Log your AI API calls (in a GDPR-compliant way) and review the prompts:

  • What fields contain personal data?
  • Is that personal data necessary for the AI task?
  • Could you achieve the same result with anonymized data?

2. Implement data minimization

Strip personal data from prompts before sending them. Replace names with placeholders, remove email addresses, redact phone numbers. If the model needs to reference entities, use consistent tokens ([PERSON_1], [EMAIL_1]) instead of real values.

3. Set up a Data Processing Agreement (DPA)

You need a DPA with every AI provider you use. Most providers offer standard DPAs:

  • OpenAI: Available in their enterprise terms
  • Anthropic: Available on request
  • Google Cloud: Part of their Cloud Data Processing Addendum

The DPA must cover: purpose of processing, types of personal data, categories of data subjects, duration, and sub-processor obligations.

4. Use EU-hosted processing where possible

Some providers offer EU-hosted endpoints or regions. This eliminates the cross-border transfer entirely:

  • Azure OpenAI: Available in West Europe (Netherlands) and other EU regions
  • Google Vertex AI: Available in europe-west regions
  • AWS Bedrock: Available in eu-west (Ireland) and eu-central (Frankfurt)

5. Implement logging and audit trails

GDPR Article 30 requires records of processing activities. For AI API calls, track:

  • What data was sent (or a hash/reference, not the actual PII)
  • When it was sent
  • Which provider processed it
  • What the lawful basis was
  • Whether redaction was applied and which rules fired

6. Handle data subject rights

Users can request access to, correction of, or deletion of their personal data. If you're logging prompts that contain PII, you need to be able to find and delete that data on request. This is much easier if you've already minimized the data you store.

How Grepture helps

Grepture is an open-source security proxy that makes GDPR compliance for AI API calls practical:

Proxy-level redaction — PII is detected and masked before it leaves your infrastructure. No code changes in your application. Your existing OpenAI/Anthropic/Google calls work exactly the same — the proxy handles redaction transparently.

Reversible redaction — Sensitive values are replaced with tokens ([PERSON_1], [EMAIL_1]) in the outbound request. When the AI responds referencing those tokens, Grepture restores the original values. Your application gets a complete, personalized response without PII ever reaching the AI provider.

EU-hosted infrastructure — Grepture's proxy runs in Frankfurt (eu-central-1). Your data stays in the EU. Even when forwarding to US-based AI providers, personal data is stripped before the cross-border transfer happens.

Audit trail — Every request is logged with metadata: which detection rules fired, what was redacted, timestamps, and request identifiers. This gives your DPO the documentation they need for GDPR Article 30 compliance.

Zero-data mode — For maximum data minimization, enable zero-retention processing. No request or response bodies are stored. Only operational metadata (method, status code, latency, rule hits) is logged. If you don't store it, you can't leak it.

Code example

Before — raw PII sent to OpenAI:

import OpenAI from "openai";

const openai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY!,
});

const response = await openai.chat.completions.create({
  model: "gpt-4o",
  messages: [
    {
      role: "user",
      content: `Summarize this support ticket:

      From: Maria Schmidt <maria.schmidt@example.de>
      Phone: +49 30 1234567
      IBAN: DE89 3704 0044 0532 0130 00
      Tax ID: 12/345/67890

      My subscription renewal failed. I'm in Berlin
      and need this resolved before my trip to Munich.`,
    },
  ],
});

Every piece of PII — name, email, phone, IBAN, tax ID, locations — is sent directly to OpenAI's US servers.

After — Grepture SDK wrapping OpenAI client:

import OpenAI from "openai";
import { Grepture } from "@grepture/sdk";

const grepture = new Grepture({
  apiKey: process.env.GREPTURE_API_KEY!,
  proxyUrl: "https://proxy.grepture.com",
});

const openai = new OpenAI({
  ...grepture.clientOptions({
    apiKey: process.env.OPENAI_API_KEY!,
    baseURL: "https://api.openai.com/v1",
  }),
});

// Same code as before — Grepture handles redaction transparently
const response = await openai.chat.completions.create({
  model: "gpt-4o",
  messages: [
    {
      role: "user",
      content: `Summarize this support ticket:

      From: Maria Schmidt <maria.schmidt@example.de>
      Phone: +49 30 1234567
      IBAN: DE89 3704 0044 0532 0130 00
      Tax ID: 12/345/67890

      My subscription renewal failed. I'm in Berlin
      and need this resolved before my trip to Munich.`,
    },
  ],
});

What OpenAI actually receives:

Summarize this support ticket:

From: [PERSON_1] <[EMAIL_1]>
Phone: [PHONE_1]
IBAN: [IBAN_1]
Tax ID: [TAX_ID_1]

My subscription renewal failed. I'm in [LOCATION_1]
and need this resolved before my trip to [LOCATION_2].

Your application gets the full response with original values restored. The model never sees real personal data. No cross-border PII transfer. No GDPR headache.

GDPR compliance checklist for AI API calls

Use this as a starting point — your DPO should review and adapt it to your specific processing activities.

  • Lawful basis documented — You've identified and recorded the legal basis for each AI processing activity
  • Data Processing Agreements signed — DPAs in place with every AI provider you use
  • Data minimization implemented — PII is redacted or anonymized before API calls
  • Cross-border transfers assessed — Transfer Impact Assessments completed for non-EU providers
  • Processing records maintained — Article 30 records of processing activities exist and are current
  • Audit trail active — You can show what data was sent, when, and to whom
  • Data subject rights handled — Processes exist for access, rectification, and erasure requests
  • Retention policy defined — Prompts, responses, and logs have defined retention periods
  • Security measures documented — Encryption in transit, access controls, and incident response plans
  • Privacy impact assessment completed — DPIA done if processing is likely high-risk (Article 35)

Further reading