KVKK, GDPR and AI: questions to ask your DPO before you build.

The first workshop on an AI assistant for customer emails goes well until someone from legal asks where the emails will go. Nobody can answer, because nothing has been designed yet. The project pauses while everyone waits for an opinion on a system that doesn’t exist.

Data protection questions about AI are hard to answer in the abstract and much easier once you can point at a specific flow: this data, sent to this model, processed here, stored there, visible to these people. So draw the map first, then take it to your data protection officer (DPO) or counsel with the questions below.

The questions are the point: legal basis, transfers and retention under KVKK and GDPR are decisions for your DPO and counsel, and they depend on facts only you have.

Why start with a map of the data flow?

A DPO can’t approve “AI”. They can approve a specific flow of data.

A map turns a general worry into a list of decisions. It also shows the builders what they hadn’t noticed: copies in logs, a search index full of old tickets, a test set someone assembled from real emails.

Take an illustrative workflow: an assistant that drafts replies to customer emails, using order data and the returns policy. A plain map of it looks like this:

Free text carries whatever customers choose to write, including health details or another person’s name. The last two rows are copies: each needs its own purpose, retention period and access rules. Where your data goes traces each hop in technical detail.

Which questions cover purpose and legal basis?

One email can serve several purposes.

• What is the purpose of each step, in one sentence? Answering the customer, keeping a log, building a test set and improving the system are different purposes. A good answer names each one.
• Is each purpose compatible with the reason the data was collected? Customers wrote in to get an answer. Using their emails to test or tune a system may be a different matter.
• Which legal basis applies to each step, and who records it? A good answer is written down per step, agreed with your DPO, not “legal said it’s fine”.
• Could special categories of data appear? Both laws single out categories such as health and biometric data for stricter treatment. Free text makes them hard to exclude: a customer may explain a late return with a hospital stay. Ask what the system should do when they appear.
• Is employee data involved? A log of who approved which draft is data about employees, and an internal HR assistant processes far more. Ask what employees must be told, and whether HR or employee representatives should be involved.
• Does this processing need a formal risk or impact assessment? Ask who writes it, and before which milestone.

Which questions cover where data is processed and transferred?

Location is where many AI projects get stuck: providers, cloud regions and sub-processors are spread across countries.

• Where is each step processed and stored? List the provider’s processing region, the region of your index and logs, and where support staff can access data from.
• Does any step involve a transfer abroad? A provider that processes outside Türkiye, or outside the EU (more precisely, the European Economic Area), raises transfer questions, and KVKK and GDPR each have their own rules. One flow can touch both: a company in Türkiye, with customers in Europe, whose provider processes somewhere else again. Ask which rules apply and what mechanism a transfer would need. Raise it early, because the answer can decide the architecture.
• Who are the provider’s sub-processors, and where are they? Hosting, abuse monitoring and support may each involve another company.
• Is the region a commitment in the agreement or only a setting? A good answer points to the clause.

The deployment choice can change many of these answers:

• Regional processing. Some providers let you choose where requests are processed, which can keep data inside a region if the agreement backs it.
• Your own cloud. Models hosted in your own cloud account keep data under your controls, in a region you choose.
• On-premises. Open-weight models on your own servers keep the most sensitive flows inside your infrastructure, at the cost of running the hardware and proving quality on your cases.

Which questions cover retention, logs and training use?

AI systems create copies, and each copy is a retention question.

• What does the provider keep, for how long, and why? Ask per feature. Prompts held briefly for abuse monitoring are a different question from files or histories stored until deleted.
• Is your data used to train or improve any model? A good answer is a clear statement in the agreement, not a sentence on a website.
• What do your own logs keep? Full prompts and outputs usually contain personal data. Ask how long to keep them, and whether a reference to the ticket would do.
• Are real cases copied into test or fine-tuning sets? These are new stores with their own purpose question. Masked or synthetic examples may answer it; our note on masking personal data covers the technique.
• Does deletion reach every copy? When a customer’s data is deleted in the ticket system, it should also leave the logs, the search index, caches and test sets, on a timeline your DPO agrees.

Which questions cover people’s rights and transparency?

People keep their rights when an AI system is involved. The practical question is whether you can honor them across every store on the map.

• Does the privacy notice need to mention AI-assisted processing? Ask counsel for the wording.
• Should customers be told that a reply was drafted with AI? Data protection law and AI-specific rules may both touch this; our note on the EU AI Act lists the questions for the second.
• Can you answer an access request completely? That means finding a person’s data in drafts, logs and test sets, not only in the ticket.
• Can you correct or delete it everywhere? Try it once with a test request before go-live.
• Does the system decide, or does a person? Both laws give people rights around decisions made about them by automated means. A design in which a person decides, with the evidence in front of them, is a different situation from one where the system decides alone. Ask counsel how that difference applies to your workflow.

What should be documented before go-live?

The answers should exist on paper, with an owner. A short record is enough:

1. The data-flow map, versioned and current.
2. The purpose and legal basis for each step, as agreed with your DPO.
3. Processing locations, sub-processors and transfer mechanisms, per provider.
4. Retention periods for prompts, outputs, logs, indexes and test sets, and how deletion reaches each.
5. The agreement terms on training use, retention and deletion, as reviewed by counsel.
6. Access roles for drafts, logs and test sets.
7. The privacy notice and any wording shown to customers.
8. Any risk or impact assessment your DPO requires, and whether your records of processing, or your entry in Türkiye’s data controllers’ registry (VERBIS), need updating.
9. A named owner who updates all of this when a model, provider or data source changes.

This record sits next to the access mapping and approval points in our guardrails.

Map first

Draw the map for one workflow on one page, with the columns above, and take it to your DPO before anyone writes code. Many questions get shorter once the map exists, and some disappear when the design sends less data. Designing a deployment that keeps sensitive data where it needs to live is part of our data and AI foundations work; if that would help, describe your workflow.

This note is general information, not legal advice.

Sources

1. Personal Data Protection Law (Law No. 6698), English text Personal Data Protection Authority (KVKK) www.kvkk.gov.tr/Icerik/6649/Personal-Data-Protection-Law
2. Regulation (EU) 2016/679 (General Data Protection Regulation), official text EUR-Lex eur-lex.europa.eu/eli/reg/2016/679/oj
3. Guide on Generative Artificial Intelligence and the Protection of Personal Data (in 15 Questions), in Turkish Personal Data Protection Authority (KVKK) www.kvkk.gov.tr/Icerik/8547/uretken-yapay-zeka-ve-kisisel-verilerin-korunmasi-rehberi-15-soruda
4. Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models European Data Protection Board (EDPB) www.edpb.europa.eu/documents/opinion-of-the-board-art-64/opinion-282024-on-certain-data-protection-aspects-related-to_en