AI Projects, Data Privacy, and KVKK: How to Safely Hand Customer Data to an LLM

There's a moment when a client or your own boss says, "Let's hook our support tickets and order history up to an AI tool so it can auto-reply." Sounds simple. But that's exactly the moment to stop and ask: what does sending this customer data to a third-party AI service actually mean under data protection law? AI project data privacy and KVKK compliance usually only come up halfway through a project, when a lawyer — or a sharp-eyed client — asks "where does this data actually go?" Get it right at the start, though, and it's both cheaper and far less stressful.

##Why does data privacy law add a separate risk layer to an AI project?

In a normal software project, data usually stays on your own server or a cloud provider you already trust (AWS, your own VPS). In an AI project, by the nature of the work, you're sending data as a prompt to an LLM API — OpenAI, Anthropic, Google. That single step opens a new category under Turkey's KVKK (and similarly under GDPR): cross-border data transfer. KVKK's Article 9 puts this under its own regime; your company is the 'data controller,' the AI provider is usually the 'data processor,' and you need a data processing agreement (DPA) between you. Most teams discover this after the project is done, when changing the architecture costs far more than getting it right up front.

The second difference is logging. Every prompt you send an LLM can be retained somewhere, temporarily or permanently — for debugging, quality checks, or (in some consumer products) model improvement. The critical distinction: consumer products like ChatGPT's web interface can have very different terms from enterprise API agreements. Enterprise APIs usually let you get zero data retention and a guarantee your data won't train the model; pasting real customer data into a consumer chat interface is a whole different risk level.

##The concrete risk: what not to send an LLM raw

KVKK's Article 6 classifies certain data types as 'special category personal data,' and the bar for these is much higher — explicit consent is required in most cases. In an AI project it's easy to unknowingly stuff this category into a prompt, especially with support tickets or free-text fields (a customer might write 'I'm having surgery, please delay delivery' — that's now health data).

• ▸National ID, passport, or tax ID numbers
• ▸Special category data: health, religion, sexual orientation, and similar
• ▸Full payment card or bank account details
• ▸Biometric data (face, fingerprint, voice sample)
• ▸Name + address + phone sent together, unmasked

That last one matters because individually harmless-looking fields can combine into a re-identification risk. Also keep prompt injection in mind: if a user manages to smuggle special instructions into the system, and your system prompt contains another customer's data, that can turn into a real data leak. So it's not just 'what data am I sending' — it's also 'could the model leak this back out in a different context.'

##Five practical ways to use data safely

• ▸Data minimization: send the LLM only the field it needs for the task, not the full customer record.
• ▸Masking / pseudonymization: send a reference like 'Customer #4821' instead of a real name, and keep the mapping table in your own system.
• ▸Use an enterprise API with a zero data retention agreement, not a consumer interface.
• ▸For genuinely sensitive data (health, finance), consider a self-hosted / on-prem model — costlier, but full control.
• ▸Update your privacy notice: make it explicit to customers that their data may be processed by AI.

These five work together, not in isolation — think of them as defense in depth. Masking protects the real person even if the provider mishandles a log; the contract clarifies legal responsibility; the privacy notice satisfies KVKK's most basic requirement (Article 10). Most SaaS or retail projects don't need an on-prem model — masking plus an enterprise API plus the right contract is usually enough.

##A real scenario: a furniture store's support assistant

A mid-sized online furniture store wants an AI assistant that auto-replies to hundreds of daily support tickets: 'where's my order,' 'I want to exchange this item,' and similar repeat questions. Here's how the architecture is set up: order data and customer records stay entirely in their own database. Before anything reaches the LLM, a masking layer kicks in — name, phone, and address fields are automatically converted into a reference code. The model only ever sees: 'Customer #4821, order #98213, product: three-seat sofa, complaint: delivery is 5 days late.' Personal data never appears in the text the model sees.

The model's reply gets merged back with the real name inside their own system before it's sent — the customer gets a normal-looking answer and never sees the anonymization step in between. The API provider they use has a signed zero-data-retention agreement; the privacy notice has been updated so customers know AI may be used in the support process. The result: faster support response times, with no raw personal data ever sitting on the provider's servers.

##FAQ

>Is pasting customer data into ChatGPT or a similar tool a KVKK violation?

Not automatically 'illegal,' but high-risk. Consumer interfaces often have different, less transparent retention and usage terms than enterprise APIs. Instead of pasting real customer data directly, using an enterprise API plus a zero-retention agreement plus masking is a far more defensible position.

>Is masking (pseudonymization) enough on its own, or do you need explicit consent too?

Pseudonymization doesn't count as full anonymization, since you still hold the mapping table — so it doesn't eliminate your obligations entirely, but it cuts the risk substantially. If special category data is involved (health, biometric, etc.), explicit consent or another legal basis is almost always required.

>Does using a foreign AI provider automatically count as a cross-border data transfer?

Yes. The moment data reaches the provider's server, KVKK's cross-border transfer provisions kick in, and you need an appropriate transfer mechanism (a commitment letter, explicit consent, or another mechanism the board recognizes). That's why the contract and privacy notice work needs to be finished before launch, not bolted on afterward.

>Does a small business need to run an on-prem model?

Usually not. Self-hosted models require hardware, maintenance, and expertise, so they usually cost more than an enterprise API. It makes sense if you're handling genuinely sensitive data (health, government, finance) or a client contract explicitly requires it; otherwise, masking plus a properly contracted enterprise API is enough for most projects.

Sorting this out before a project starts is always cheaper than rebuilding the architecture after launch. If you're curious how LLMs actually work at the token and context-window level, there's a related post for that; if you want to talk through how to set this layer up for your own project, I'm here.