KVKK and AI: What Turkish Companies Can and Can't Send to ChatGPT
A practical guide to using AI automation lawfully under Türkiye's KVKK—what counts as personal data, when sending it to a foreign model is a problem, and the architectures that keep you compliant without giving up AI.
Somewhere in almost every Turkish company right now, an employee is pasting a customer email, a CV, a contract, or a support transcript into a chatbot to save themselves twenty minutes. It works, it feels harmless, and under KVKK it can be a data-transfer decision nobody authorised. This is not a reason to ban AI—it is a reason to design for it. This article explains, in practical terms, what KVKK actually requires when personal data meets AI, where the real risk sits, and the architectures that let you automate aggressively while staying on the right side of the law.
A necessary disclaimer: this is practical guidance, not legal advice. KVKK compliance for a specific process should be confirmed with your legal counsel or data protection officer. What follows is the engineering and governance shape of the problem, so you can have that conversation from an informed position.
KVKK in one paragraph
The Kişisel Verilerin Korunması Kanunu (KVKK), Türkiye's personal data protection law, is closely modelled on the EU's GDPR. Its core logic is simple: personal data—any information relating to an identifiable person—may only be processed on a lawful basis, for a defined purpose, with appropriate security, and it may not be transferred abroad without meeting specific conditions. That last clause is where AI collides with the law, because most of the world's most capable models run on servers outside Türkiye. When you send text to a foreign API, you are potentially transferring personal data abroad—and KVKK cares a great deal about that.
The question that actually matters: is there personal data in the prompt?
Almost every KVKK-and-AI problem reduces to one question asked at the right moment: does the text you are about to send contain personal data? Personal data is broader than people expect. It is not just names and ID numbers; it is anything that can identify a person directly or indirectly.
| Likely personal data | Often not personal data |
|---|---|
| Customer names, emails, phone numbers | Anonymised, aggregated statistics |
| National ID (TCKN), passport, tax numbers | Public product documentation |
| CVs, employee records, performance notes | Internal policies with no person named |
| Health, financial, or biometric detail (special categories) | Fully synthetic or fictional test data |
| Support transcripts, call recordings, chat logs | General knowledge questions |
| Contracts naming individuals | Code with no embedded personal data |
Two things make this harder than it looks. First, special categories—health, religion, ethnicity, biometric and genetic data, criminal records—carry stricter conditions and much higher stakes. Second, data hides. A "general" support transcript contains names and account details; a contract PDF is full of identifiable people; a spreadsheet "just for analysis" has an email column. The practical discipline is to assume personal data is present until you have confirmed it is not.
Related: Self-Hosted LLMs for Enterprises: When Local Models Beat the Frontier
Where the real risk lives (and where it doesn't)
Not all AI use is equally risky. Sorting your workloads by risk is the fastest way to know where to spend effort.
Lower risk: No personal data involved at all. Drafting marketing copy, summarising a public report, answering a general question, generating code against a non-personal schema. Here, using a frontier API is usually fine—there is simply no personal data to protect.
Higher risk: Personal data in the prompt, sent to an external model. Summarising real customer complaints, screening actual CVs, extracting fields from signed contracts, analysing support conversations. This is where KVKK obligations bite: lawful basis, transfer conditions, transparency to the data subject, and security all come into play.
Highest risk: Special-category data, or large volumes of personal data, sent externally without controls. Processing health records, financial profiles, or biometric data through an uncontrolled external service is where fines and reputational damage concentrate.
The mistake most organisations make is treating all three the same—either banning everything (and losing the value) or allowing everything (and taking the risk). The mature move is to route each workload according to its actual risk.
Related: The Turkish AI & LLM Landscape in 2026: Who Is Building What
The architectures that keep you compliant
You do not have to choose between "use AI" and "obey KVKK." A handful of architectural patterns let you do both, and most real systems combine several.
1. Keep personal data out of the prompt
The simplest compliant AI request is one that never contains personal data. Often the task does not actually need it—you want the shape of an answer, not the person's identity. Redaction and pseudonymisation replace names, IDs, and contact details with neutral placeholders before the text ever reaches the model, then restore them in the output if needed. The model reasons over "Customer A" and "Order #12345"; the real identity never leaves your systems. For a large class of tasks, this alone resolves the problem.
2. Process personal data only on infrastructure you control
When the task genuinely needs the real data, keep the model inside your perimeter. A self-hosted, open-weight model running on your servers or a Türkiye/EU-resident private cloud means personal data is processed but never transferred abroad. This is the architecture regulated Turkish sectors—finance, health, public sector—increasingly default to, and it is precisely why the maturing Turkish open-model ecosystem matters.
3. Use compliant, region-appropriate hosting for external models
If you do use a major provider, the terms and the region matter enormously. Enterprise agreements with data-residency guarantees, no-training-on-your-data commitments, and EU/Türkiye data processing can bring an external model within KVKK's transfer conditions. This is a legal-and-procurement exercise as much as a technical one—the default consumer chatbot terms are not the same as a properly negotiated enterprise data processing agreement.
4. Put governance around the humans
Technology alone will not save you if an employee pastes a client list into a public chatbot. Governance closes that gap: a clear AI usage policy, approved tools for personal data, training so staff can recognise personal data, and—ideally—automation that makes the compliant path the easy path, so nobody has to choose between doing their job and following the rules.
Related: Agentic AI Workflow Architecture: Designing Multi-Agent Systems for Enterprise Automation
A practical checklist before any AI workflow touches real data
Run any proposed AI automation through these questions before it goes live:
- Does the input contain personal data? If unsure, assume yes until proven otherwise.
- Is any of it special-category data? If so, the bar is much higher—escalate to legal.
- What is the lawful basis for processing it this way? Consent, contract, legitimate interest—name it.
- Where does the data physically go? If it leaves Türkiye, are the transfer conditions met?
- Can the task be done with redacted or pseudonymised data instead? If yes, prefer that.
- Does the provider train on your data or retain it? Confirm in writing, not from a marketing page.
- Is the person informed, and can the processing be explained and audited? Transparency is an obligation, not a courtesy.
- Is there a log of what was sent and why? You cannot demonstrate compliance you did not record.
If a workflow cannot answer these cleanly, it is not ready—but usually the fix is a design change (redaction, local processing, better hosting), not abandoning the automation.
The takeaway
KVKK does not forbid AI. It forbids careless processing of personal data—and AI just happens to make careless processing very easy and very fast. The organisations that get this right are not the ones that ban chatbots; they are the ones that decide, deliberately, which data can go where, and build automation that enforces those decisions by default. Done well, compliance and capability point the same direction: keep personal data close, keep prompts clean, and reserve external models for the work that carries no personal data at all.
For Turkish companies specifically, the maturing local-model ecosystem and the option of Türkiye/EU-resident hosting mean you rarely have to choose between ambition and compliance. You can automate aggressively and stay lawful—if the architecture is designed for it from the start.
At Orbitra, we build AI automation and agentic workflows with KVKK compliance designed in from the first diagram—redaction and pseudonymisation where it fits, self-hosted models where the data demands it, proper governance around both, and audit trails throughout. If you want to move fast on AI without inheriting a data-protection problem, we can help you map your workflows by risk and build the compliant path first.