KVKK and generative AI: a developer's compliance checklist

In November 2025, Turkey's data protection authority published a guide titled "Generative Artificial Intelligence and the Protection of Personal Data (in 15 Questions)". Lawyers have already analysed it in detail. In this article I want to do something different: translate what the guide says into what a software team building an AI feature actually has to do.

Let me say this up front: this article is not legal advice. The guide itself is not binding either; it is a set of recommendations, and in a dispute the law and its secondary legislation prevail. Before you start a project, review it together with your legal team or a data protection consultant who knows Turkish law.

KVKK in a nutshell

KVKK stands for Kişisel Verilerin Korunması Kanunu, Turkey's Law No. 6698 on the Protection of Personal Data, in force since 2016. The same abbreviation is used for the authority that enforces it, the Personal Data Protection Authority.

If you know the GDPR, much of KVKK will look familiar. The law was modelled on the EU's earlier Data Protection Directive (95/46/EC), so it works with the same core concepts: data controller and data processor, legal bases for processing, data subject rights, information notices and security obligations. It is not a copy of the GDPR, though. The details differ, Turkey does not have an adequacy decision from the EU, and being GDPR-compliant does not automatically make you KVKK-compliant. The rules on cross-border transfers were rewritten in 2024 and now follow a structure closer to the GDPR: an adequacy decision first, otherwise appropriate safeguards such as standard contracts.

If your product processes personal data of people in Turkey, KVKK applies, and the generative AI guide shows how the authority reads the law for this technology.

What the guide says, in short

The guide covers 15 questions, from what generative AI is to advice for parents. These are the points that matter most to a software team:

• Personal data can be processed at every stage of an AI system: training, use and output generation.
• An organisation that uses an off-the-shelf model for its own purposes is usually the data controller for that processing. Roles are determined by actual control, not by what the contract says.
• A separate legal basis must be identified for each processing activity. If another legal basis is available, explicit consent should not be relied on.
• For cross-border transfers, the first question is whether there is an adequacy decision; if not, one of the appropriate safeguards, such as a standard contract, has to be used.
• Users must be told that they are interacting with an AI, and the privacy notice must be accessible in the interface.
• Outputs are not always correct; human oversight and monitoring for hallucinations are required.
• For security, the guide recommends a data protection impact assessment, privacy-enhancing technologies and testing against AI-specific threats such as prompt injection.

Now let's turn these into engineering steps.

1. Map the data flow

Everything starts with knowing where personal data enters the system and where it goes. In an AI feature, data usually sits in five places:

1. Prompt: the text the user writes or the document they upload.
2. Context: the data the system adds for the model: a customer record, previous requests, documents retrieved via RAG.
3. Output: the text the model generates. It can contain personal data, and it can even produce incorrect personal data.
4. Logs: requests and responses stored for debugging or auditing.
5. Training and improvement: data used to train or fine-tune the model.

For each of these, answer three questions in writing: What personal data is there? Where does it go (which country, which provider)? How long is it kept?

2. Data the model never sees cannot leak

The guide's data minimisation principle becomes the most effective measure in the architecture: personal data never reaching the model at all.

• Ask whether it is needed. Summarising a report, simplifying a text or classifying a request rarely requires the person's name, national ID number or phone number.
• Mask before sending. If it is not needed, replace ID numbers, phone numbers, email addresses and names with pseudonyms before sending them to the model, and map them back when the response comes in if necessary.
• Narrow the context. Give the model only the fields the task requires, not the entire customer record.
• Enforce permissions in the context too. If you use RAG, a document the user is not allowed to see must not end up in the context.

3. Determine the legal basis per activity

The guide asks for a separate legal basis for each activity: training, use, output generation and development. On the software side, this means:

• Using user data to improve the model is a different activity from processing the same data to serve the user. Keep the two apart, and by default do not use service data for training.
• According to the guide, data that is openly accessible on the internet is not automatically considered "made public" by the data subject. If you plan to train a model on data collected from the web, it needs a separate assessment.
• Explicit consent is not a button that solves everything. Determine the legal basis with your legal team, and don't treat adding a consent checkbox to the interface as the default solution.

4. Solve cross-border transfers when choosing a provider

Most widely used large language models run outside Turkey. That makes choosing a model provider a data transfer decision as well.

• Find out in which region the provider processes and stores the data.
• Check the contract and settings for whether data sent via the API is used for model training and how long it is retained. Terms for enterprise APIs and consumer chat apps are usually different.
• Without an adequacy decision, one of the appropriate safeguards under Article 9 of the law (a standard contract, for example) is required. That process belongs to your legal team, but asking during technical selection whether the provider can supply these documents is your job.
• For tasks that genuinely need personal data, consider a model that runs in Turkey or on your own servers.

5. Put the notice in the interface

• Clearly show users that they are talking to an AI, or that a piece of content was generated by AI.
• Describe the use of AI separately in the privacy notice: which data goes to which provider, for what purpose.
• Make the notice reachable in one click from the screen where the AI feature lives.

6. Make data subject rights technically possible

Data subjects have the right to learn whether their data is processed, and to request correction or deletion. The guide reminds us that these rights apply at every stage of an AI system. In the architecture, this means you need answers to these questions:

• Can you find a person's data in logs, caches and the vector database built for RAG?
• When a deletion request comes in, can you delete all of those copies?
• If an AI analysis leads to an outcome against a person, is there a flow that lets a human review that decision and lets the person object?

These answers cannot be bolted on later; they have to be considered when you design the data model.

7. Verify the output

Generative models can produce convincing but wrong information. When personal data is involved, that means producing wrong information about a person.

• Outputs that lead to decisions about people must always have human approval.
• If you use RAG, show which source the answer is based on.
• Build a test set from real examples and rerun it whenever the model or the prompt changes.

8. Test for AI-specific vulnerabilities

Classic security measures (authorisation, multi-factor authentication, secure logging, patch management) still apply. On top of them:

• Prompt injection: If the model reads external content (an email, a document, a web page), it can be steered by instructions hidden inside it. Keep the tools and data the model can access to a minimum.
• Jailbreaks: Test against prompts in which users try to get around the model's rules.
• Key security: Model API keys must never live on the client side (mobile app, browser). In the Lullai app, for example, all AI calls run on the server; there is no key inside the app.
• Impact assessment: For high-risk processing, carry out a data protection impact assessment before going live.

9. Don't forget how employees use AI

In most organisations, the first KVKK risk doesn't come from an AI product they built. It comes from employees pasting customer data into consumer chat apps. Banning this rarely works. What works better:

• A short internal policy that explains which tools can be used with which data.
• Giving employees an enterprise tool with clearly defined data terms.
• Simple examples of how to mask personal data.

The checklist

1. A data flow map exists: prompt, context, output, logs, training.
2. Personal data sent to the model is minimised; unneeded fields are masked.
3. The legal basis for each activity has been determined with the legal team.
4. The model provider's processing location, retention period and training terms are known; safeguards for cross-border transfer are in place.
5. AI use is disclosed in the interface, and the privacy notice is reachable.
6. It has been verified that data can be found and deleted, including in logs, caches and the vector database.
7. Outputs with consequences for people require human approval.
8. Prompt injection and jailbreak tests have been run; API keys live on the server.
9. A data protection impact assessment has been carried out where required.
10. An AI usage policy for employees has been published.

Frequently asked questions

Can employees paste customer data into ChatGPT?

That depends on an assessment the organisation has to make as the data controller, and in most cases it raises the cross-border transfer question. In practice, the safest path is not to enter unmasked personal data into consumer tools and to give employees an enterprise tool with clearly defined terms.

Is getting explicit consent from users enough?

The guide says explicit consent should not be relied on if another legal basis is available. Explicit consent is not a shortcut that replaces assessing the legal basis; decide with your legal team which basis fits.

Does every AI project that processes personal data need a model hosted in Turkey?

No, but it can be the simplest solution. A design in which personal data never reaches the model lets you use powerful models hosted abroad. For tasks that genuinely require personal data, a model running in Turkey or on your own servers is worth considering.

Is a GDPR-compliant AI product automatically KVKK-compliant?

No. The two laws share many concepts, so a solid GDPR setup is a good starting point, but KVKK has its own rules, for example on legal bases and cross-border transfers out of Turkey. Have the Turkish side reviewed separately.

Conclusion

The KVKK guide was not written to stop AI projects, but to help them get built properly. From an architectural point of view, most of the measures rest on the same idea: know your data, don't send more than you need, log every step and leave the final decision about people to a human.

I wrote about how these principles can be applied in the public sector in the article on AI in local government, and about the additional risks agents bring in the article on AI agents. If you'd like to review your own project's data flow together, take a look at the AI and automation service or get in touch.