# Production LLM/AI App Data Privacy & Compliance Guide 2026 | PII Minimization, Provider Data Use, APPI/GDPR

> A practical guide to guaranteeing data privacy and compliance for production LLM/AI apps through architecture. Covers the major API providers' data-use and retention policies (OpenAI/Anthropic/Google/Bedrock/Vercel), PII minimization and redaction, zero data retention, data residency, and APPI (Art. 28 cross-border transfer) and GDPR (Art. 28 DPA / data minimization) — with real TypeScript code.

- Published: 2026-07-23
- Author: 友田 陽大
- Tags: 生成AI, LLM, セキュリティ, プライバシー, コンプライアンス, PII, APPI, GDPR, AI駆動開発, アーキテクチャ設計
- URL: https://tomodahinata.com/en/blog/llm-application-data-privacy-compliance-pii-appi-gdpr-guide
- Category: 本番LLMアプリ実装（信頼できるAI）
- Pillar guide: https://tomodahinata.com/en/blog/production-llm-application-engineering-guide

## Key points

- Major providers' API/business tiers do NOT train on your data by default — verified for OpenAI, Anthropic, Google (paid), Bedrock, and Vercel. But there are exceptions, e.g. the free Gemini API/AI Studio may train on your data.
- Default no-train still isn't enough. Minimize and mask PII BEFORE sending, and layer on zero data retention (ZDR) and region pinning.
- Cross-border transfer requires consent in principle under APPI Art. 28 (exceptions: a PPC-adequate country or a standards-conforming recipient). Under GDPR the provider is a processor, so an Art. 28 DPA and Art. 5(1)(c) data minimization are required.
- Reversible pseudonymization is still 'personal data' (GDPR Recital 26 / APPI pseudonymously-processed info). Don't confuse it with irreversible anonymization.
- Logs, traces, and eval datasets are a blind spot for raw PII. Redact BEFORE the logging boundary, and sign a DPA with your observability vendor.

---

When putting generative AI into a production product, the thing that stops most companies at the finish line is **"how do we protect customer data and PII (personal information)?"** Can you put personal data in a prompt? Is data sent to an external LLM provider used for training? Does it run afoul of Japan's Act on the Protection of Personal Information (APPI) or GDPR? While that stays ambiguous, legal blocks the launch and the project stalls.

Bottom line up front: the privacy of a production LLM app comes down to three design decisions.

1. **Provider APIs don't train on your data by default — but know the exceptions correctly.**
2. **Minimize and mask PII BEFORE sending.** Defense in depth that doesn't depend on the provider's policy.
3. **Bake cross-border transfer (APPI Art. 28) and the DPA (GDPR Art. 28) into the design, not as an afterthought.**

Written from the standpoint of having implemented APPI-compliant measurement and application security ([LLM app security](/blog/llm-application-security-owasp-top-10-prompt-injection-guide)), this article — after **verifying each provider's official policy and the primary regulatory text** — designs "privacy by design" in real TypeScript. It's the fourth pillar of **trustworthy production AI**, following security, [MCP](/blog/mcp-model-context-protocol-production-server-guide), and [evaluation](/blog/llm-application-evaluation-testing-llm-as-judge-ci-guide).

> ⚠️ This article is **engineering guidance, not legal advice.** How regulations apply varies by case. Always confirm important decisions with primary sources and a legal professional. Provider policies change — re-verify each source before implementing.

## First, clear up the misconception: APIs don't train "by default" — but there are exceptions

"Everything I send to an LLM gets trained on" is a **misconception for the API/business tier.** For their API, business, and enterprise tiers, the major providers explicitly state they **do not use your data to train models by default** (verified against each vendor's official page). This is the opposite of the free consumer tiers.

| Provider (API/business tier) | Trains on your data by default? | Retention | Zero Data Retention (ZDR) |
|---|---|---|---|
| **OpenAI API** | **No** (since Mar 2023, except explicit opt-in) | Abuse-monitoring logs up to 30 days | Yes (eligible endpoints, requires approval) |
| **Anthropic API** | **No** (doesn't train on commercial input/output by default) | Submitted feedback retained | Yes (some Platform/Enterprise contracts) |
| **Google Gemini (paid) / Vertex AI** | **No (paid only)** | Abuse-monitoring logs up to 30 days (not used for training) | Available in Vertex |
| **AWS Bedrock** | **No** (doesn't train foundation models; no third-party sharing) | Encrypted in your Region (no fixed public number) | In-region by design |
| **Vercel AI Gateway** | **No** (Vercel doesn't train/retain) | Deleted after the request under ZDR | Yes (`zeroDataRetention`) |

**The pitfalls (know the exceptions correctly):**

- **Only Google's "paid/Vertex" is no-train.** The **free Gemini API / AI Studio, not tied to a billing account, may use your data for training.** Don't lump "Gemini" together as safe.
- **Vercel's provider-side no-train / ZDR is opt-in.** The gateway itself doesn't retain, but to route no-train upstream you explicitly enable `disallowPromptTraining` / `zeroDataRetention`.
- **Bedrock has no fixed public retention period** (you control it via your logging config / KMS). Don't assume a number.
- **Default no-train doesn't mean "safe to send."** Some log retention remains, and **sending PII externally at all** is a cross-border-transfer / third-party-provision issue (below).

## Privacy by design: architect so you "don't send" PII

The most reliable privacy measure is to **not put unnecessary PII in the prompt in the first place.** The provider's policy is your second line of defense; the first is your own architecture.

**(1) Data minimization — send only the fields you need** (the engineering form of GDPR Art. 5(1)(c)). Pass **IDs or references instead of raw names/addresses, and re-resolve on the app side.**

```ts
import { z } from "zod";

// 送信ペイロードは「必要なフィールドだけ」。生PIIではなくIDを渡し、
// 表示に必要な氏名・住所はアプリ側（信頼境界の内側）で再解決する。
const PromptContext = z.object({
  orderId: z.string().uuid(),       // ← 顧客レコード全体ではなく参照だけ
  itemCount: z.number().int(),
  region: z.enum(["JP", "US", "EU"]), // 属性の粒度も最小化
});

// これで「氏名・住所・電話・カード番号」はそもそもプロンプトに存在しない。
```

**(2) If you must send free text, anonymize the PII before sending.** Use a detector like [Microsoft Presidio](https://presidio.dataprivacystack.org/) to detect and mask names/addresses/phones/emails (detection isn't perfect, so combine with other controls).

```ts
// 自由文（問い合わせ本文など）はプロバイダに渡す"前"にマスクする。
// これはプロバイダのZDRに依存しない多層防御（送る前に消す）。
async function redactPii(text: string): Promise<string> {
  const findings = await analyzePii(text); // 例: Presidio Analyzer（PERSON/EMAIL/PHONE…）
  return findings.reduce((masked, f) => masked.replaceAll(f.text, `<${f.entityType}>`), text);
}
```

## Zero Data Retention (ZDR) and data residency

Once you've narrowed what you send, tighten the provider's **retention and location.**

- **Obtain ZDR.** For sensitive data, enable OpenAI's ZDR-eligible endpoints (requires application) or Vercel AI Gateway's `zeroDataRetention`, so nothing is retained after the request.
- **Pin the region (data residency).** Bedrock and Vertex can process/store data **within a specified region.** Pinning the region lets you architect so that **no cross-border transfer occurs at all** — structurally reducing your APPI/GDPR burden.

```ts
// データレジデンシー：リージョンを固定し、"越境そのものを設計で防ぐ"。
// 東京固定なら、日本の個人データが国外に出ない構成にできる。
const bedrock = new BedrockRuntimeClient({ region: "ap-northeast-1" });
// OpenAI: ZDR対象エンドポイント（要事前申請）。Vercel: team/リクエストで zeroDataRetention を有効化。
```

## Cross-border transfer and compliance (APPI Art. 28 / GDPR Art. 28)

Sending PII to an overseas LLM API can legally constitute **"providing personal data to a third party located in a foreign country."** Lock this down early in the design.

**APPI (Japan):**
- **Third-party provision (Art. 27)** in principle requires the person's consent. But **outsourcing (委託, Art. 27(5))** and **joint use (共同利用)** are treated as not being a "third party."
- **Cross-border transfer (Art. 28)** in principle requires the person's **prior consent.** Exceptions: **(a) a country PPC designates as having an adequate protection level**, or **(b) the recipient maintains a system conforming to PPC standards.** Under the consent route, you must **provide the person in advance with the destination country's name and its data-protection system, etc.**
- **Processing categories:** **personal information** (identifiable) / **pseudonymously-processed information** (not identifiable unless collated with other info — still tightly regulated) / **anonymously-processed information** (unrecoverable and unidentifiable — a more permissive regime).

**GDPR:**
- LLM providers and observability vendors are usually **processors.** Sign an **Art. 28 DPA (data processing agreement)** and use only processors giving "sufficient guarantees."
- **Art. 5(1)(c) data minimization** — process only the data necessary for the purpose.
- **Reversible pseudonymization is still 'personal data'** (Recital 26). If you tokenize (name → `<PERSON>`) but keep a recovery map, that is not anonymization. **Don't call reversible masking "anonymized."**

> Practical point: **region pinning + PII minimization** to "reduce the PII that crosses borders at all" structurally shrinks the burden of obtaining consent and running DPAs. Compliance is best achieved by **architecture**, not just contracts.

## The blind spot: PII in logs, traces, and eval datasets

PII leaks not only from the prompt body but from the **observability path.** Trace backends, [eval fixtures](/blog/llm-application-evaluation-testing-llm-as-judge-ci-guide), and dashboards are classic places where raw PII silently accumulates.

The fix is simple: **mask BEFORE the logging/eval boundary.** Record only the masked payload.

```ts
// トレース/評価データにも生PIIを残さない（ログ境界の"前"でマスク）。
logger.info("llm_call", {
  route: "support.reply",
  // prompt: rawUserMessage,                         // ❌ 生PIIがトレースに残る
  promptRedacted: await redactPii(rawUserMessage),   // ✅ マスク後だけ記録
  tokens: usage.totalTokens,
  latencyMs,
});
```

Observability vendors (trace/eval SaaS) are also usually processors, so they are **subject to a DPA.** Design observability with [production observability via OpenTelemetry](/blog/opentelemetry-observability-production-tracing-metrics-logs), and secret handling with [preventing secret leaks in Next.js](/blog/nextjs-env-secret-leak-prevention-public-vars-guide).

## Adoption checklist (before going to production)

- [ ] **Provider tier check** — are you using the API/business tier (default no-train)? Are you NOT using training-enabled tiers (free Gemini/AI Studio) for business data?
- [ ] **Data minimization** — do you send IDs/references instead of raw PII, limited to the necessary attributes?
- [ ] **PII masking** — do you redact free text before passing it to the provider?
- [ ] **ZDR** — is zero data retention enabled/obtained for sensitive data?
- [ ] **Data residency** — is the region pinned to reduce cross-border transfer itself?
- [ ] **Cross-border (APPI Art. 28)** — have you organized how it's justified: consent, an adequate country, or a standards-conforming system?
- [ ] **DPA (GDPR Art. 28)** — have you signed a DPA with the LLM/observability vendors?
- [ ] **PII in logs/eval** — do traces and eval datasets record only masked data?
- [ ] **Pseudonymized vs anonymized** — are you avoiding treating reversible masking as "anonymization"?

## Summary

The privacy of a production LLM app is decided by **architecture** more than contract wording. Achieving **"don't send, don't retain, don't transfer across borders"** by design is the shortest path to clearing legal review and advancing enterprise adoption.

- **Provider APIs don't train by default** — but know the exceptions of free tiers and opt-in settings correctly.
- **Minimize and mask PII before sending, and tighten with ZDR and region pinning** in layers.
- **Bake cross-border transfer (APPI Art. 28) and the DPA (GDPR Art. 28) into the design.** Reversible pseudonymization is not anonymization.

Security, MCP, evaluation, privacy — with these four pillars, generative AI becomes a production system that is "fast to build, secure, unbreakable, and **trustworthy**." Building fast and defending fully are compatible when you design correctly.