GDPR, KVKK, CPRA, FADP: AI Data Privacy Compliance Guide

If your AI application touches users in more than one jurisdiction, you are not picking which privacy law to follow. You are following all of them simultaneously — and the strictest clause in any one law sets the floor for your entire system.

This is the practical reality of building global AI products in 2026. GDPR, KVKK, CPRA, and FADP overlap in intent but diverge in mechanics. Getting compliance right means understanding what each law actually requires, then wiring those requirements into your architecture rather than treating them as a legal afterthought.

The Four Laws You Are Already Subject To

GDPR — European Union

The General Data Protection Regulation is the reference point every other privacy law is measured against. Fines reach €20 million or 4% of global annual turnover — whichever is higher. The law applies to any organization processing personal data of EU residents, regardless of where the organization is based.

Core requirements:

• Lawful basis for processing — consent, legitimate interest, contract, legal obligation, vital interests, or public task. You must document which basis applies for each processing activity.
• Right to be forgotten — users can request deletion of their data. Your system must be able to execute this across all storage layers, including backups and caches.
• Data minimisation — collect only what you need for the stated purpose. Collecting additional fields “in case they are useful later” is a violation.
• Data Protection Impact Assessment (DPIA) — required before deploying high-risk processing, including most AI systems that make decisions about individuals.

The tension with AI is real. Models trained on user data, embeddings stored in vector databases, conversation histories cached for context — all of these are personal data under GDPR and must be covered by a lawful basis, a retention policy, and a deletion path.

KVKK — Turkey

The Kişisel Verilerin Korunması Kanunu is Turkey’s data protection law, modeled closely on GDPR but with distinct operational requirements.

The key difference from GDPR: data controllers must register with the Turkish Data Protection Authority (VERBIS) before processing personal data. This is an active registration, not a self-declaration. Missing it is itself a violation.

Beyond registration:

• Personal data cannot be processed without explicit, informed consent unless a legal exemption applies
• Cross-border data transfers require either the recipient country to be on Turkey’s approved list or specific additional safeguards
• Data subjects have the right to access, correct, and request deletion of their data

For AI applications with Turkish users, KVKK means your consent flows and data subject request handling must be tested and operational before you onboard a single user in that market.

CPRA — California, USA

The California Privacy Rights Act strengthened and expanded the earlier CCPA. It applies to for-profit businesses that meet one of three thresholds: annual gross revenue over $25M, buy or sell personal information of 100,000+ consumers or households per year, or derive 50%+ of revenue from selling personal information.

Consumer rights under CPRA:

• Right to know — what data is collected, how it is used, and with whom it is shared
• Right to delete — request deletion of personal information
• Right to opt out — of the sale or sharing of personal information
• Right to correct — inaccurate personal information
• Right to limit use — of sensitive personal information

The “sharing” language is significant for AI applications. Sending user data to a third-party LLM provider — even without payment — may qualify as “sharing” under CPRA, triggering opt-out obligations. Review your data processing agreements with every AI vendor.

FADP — Switzerland

The revised Federal Act on Data Protection came into force in September 2023. Switzerland is not in the EU, so GDPR does not apply directly — but FADP aligns closely with it by design, maintaining Switzerland’s adequacy status for data transfers from the EU.

Key requirements:

• Privacy notices must be provided when collecting personal data
• Data processing agreements are required for processors
• Cross-border data transfers require either adequacy or appropriate safeguards
• Mandatory breach notification to the Federal Data Protection and Information Commissioner (FDPIC) for breaches likely to lead to high risks

For most AI applications, FADP compliance is largely achieved alongside GDPR compliance — the concepts map closely. The distinction matters for transfers: Switzerland has its own adequacy decisions and its own notification authority.

Technical Controls That Make Compliance Architectural

Compliance is not a checkbox you add at launch. It is the result of building the right controls from the start. These three are the foundation.

Rate Limiting

Per-user request limits serve two compliance functions. First, they prevent abuse — bulk data extraction attacks that could exfiltrate user data at scale. Second, they enforce the principle that your system processes data at human scale, not at the scale of automated harvesting.

Under GDPR’s data minimisation principle, processing more data than your stated purpose requires is a violation. Rate limits enforce a technical constraint that supports the legal argument that you are not processing data in bulk.

Implementation: rate limits should be per authenticated identity, not per IP address. IP-based limits are trivially bypassed and do not correspond to the legal subject (the data subject) that privacy law protects.

API Key Protection

API keys are credentials. Under every privacy law in this list, credentials that provide access to personal data must be protected with the same care as the data itself. Storing plain-text API keys in a database means a database breach is also a credential breach — giving attackers access to all the personal data those keys protect.

The standard: hash API keys before storage. The plain-text key is shown to the user once at creation and never stored. On subsequent requests, the presented key is hashed and compared against the stored hash.

This is the same model as password storage, applied to API credentials. It satisfies the security controls expected under GDPR Article 32 (appropriate technical measures) without requiring complex key management infrastructure.

Encryption at Rest and in Transit

AES-256 at rest and TLS/HTTPS in transit is the baseline expected by every regulator on this list. Under GDPR, encryption is explicitly named as an appropriate technical measure. Under CPRA, the California AG considers encryption a factor in assessing whether a business implemented “reasonable security.”

What this means in practice:

• At rest: database encryption, encrypted backups, encrypted filesystem for any storage layer holding personal data
• In transit: TLS 1.2 minimum, TLS 1.3 preferred, HSTS enforced, no mixed content
• Key management: encryption keys stored separately from the data they protect, with rotation policies

Encryption does not eliminate your compliance obligations — an encrypted database still holds personal data and must support deletion requests. But it substantially reduces the risk and regulatory exposure of a breach.

Mapping Requirements to Architecture

The AI-Specific Problem

Standard web applications handle mostly human-generated data at human scale. AI applications are different in three ways that create compliance complications.

Training and fine-tuning. If user data is used to improve a model, that use must be covered by a lawful basis and disclosed to users. Consent for “improving our service” typically does not cover model training — this requires a specific disclosure and, under GDPR, likely a DPIA.

Embeddings and vector stores. Semantic embeddings derived from personal data are still personal data. They can be reversed or used to identify individuals. Deletion requests must reach your vector database, not just your primary database.

Third-party model providers. Every time you send a user’s message to an external LLM, you are transferring personal data to a processor. That transfer requires a Data Processing Agreement (DPA) with the provider and, for EU-to-US transfers, Standard Contractual Clauses or equivalent safeguards.

Auth0’s framework for AI agents addresses the identity layer of this problem. The data layer requires the same level of deliberate design.

Where to Start

If you are building an AI application and need to cover all four jurisdictions, the practical sequence is:

1. Audit your data flows — map every piece of personal data from collection to deletion, including third-party processors
2. Implement deletion end-to-end — the right to erasure is the hardest control to retrofit; build it first
3. Draft your consent and disclosure UI — cover all four laws’ disclosure requirements in a single, clear privacy notice
4. Register with VERBIS if you have Turkish users — this is time-gated and cannot be done retroactively
5. Get DPAs with every AI vendor — before your first user in a regulated jurisdiction
6. Encrypt everything — at rest, in transit, and for backups
7. Test your incident response — breach notification timelines are short (72 hours under GDPR)

Global compliance is not a one-time project. Regulations change, data flows change, and your vendor roster changes. Build compliance as an ongoing process with ownership, not a launch gate that gets checked once and forgotten.