KVKK Generative AI Guide: 15 Questions for Companies

In short: The KVKK generative AI guide is a November 2025 publication of Türkiye's Personal Data Protection Authority (KVKK) that explains personal data protection in generative AI systems through 15 questions. It is not a law but guidance from the Authority, and it treats personal data issues within the framework of Law No. 6698. For companies, the starting point is not the name of the tool but the purpose, the data processed and the parties involved.

The Personal Data Protection Authority (KVKK) announced the Generative AI and Personal Data Protection Guide on 24 November 2025. Its Turkish subtitle, "in 15 Questions," also describes its structure: the guide first explains how generative AI works, where it is used and what risks it carries, then treats personal data processing in these systems under the Law, and ends with advice for individuals and parents. For companies, its practical value is that each of the questions maps to something a team has to answer internally about an AI project.

The KVKK generative AI guide is not a new law. It is guidance from the Authority, Publication No. 113, dated November 2025. The guide's purpose and scope section says it aims to guide actors that qualify as data controllers in the processing carried out across the life cycle of generative AI systems, and that it treats this processing within the framework of Law No. 6698 on the Protection of Personal Data (p. 8).

This means the obligations come from the Law, not from the guide. In the guide's own words, Law No. 6698 is a general legal framework that applies, independent of technology, wherever personal data is processed, and generative AI systems are assessed within it (p. 25). The guide names no tool or product, and it neither bans nor approves any tool. Instead, it explains how to assess each processing activity by its purpose, its data and its parties. This post is not legal advice. Review your specific processing with your legal team.

Start by defining one task: which team will produce which output from which input, and who will check that output? "We will use AI" does not describe a task anyone can assess. "HR will summarize incoming resumes" does.

The first four questions of the guide give the technical frame for that definition. Question 1 defines generative AI as the type of AI that can produce text, images, video, audio or software code in response to a user's prompt. Question 2 explains how content is generated and focuses on text and image generation, since these are the most common uses. Question 3 splits a model's life cycle into stages, from defining the purpose through data collection, training and fine-tuning, and evaluation to deployment. Question 4 lists areas of use ranging from customer service and health care to software development and law. We explain how text-generating models work in our post What is an LLM.

The life-cycle split is useful inside a company too. Training a model from scratch, adapting a ready-made model through fine-tuning and an employee prompting an off-the-shelf tool are different activities, and a description of one does not automatically cover another. The guide likewise treats developing a language model and developing an application built on that model as different purposes under data protection law (Example 8, p. 36).

As a first step, write a one-page use case and draw a simple data-flow diagram. The diagram should show where the data comes from, the application, the model, the logs and where the output goes. List the data used to train the model on separate lines from the files uploaded in everyday use. Do not fill in points the vendor has not answered yet with guesses. Leave them as open questions. That way everyone at the next meeting is talking about the same system.

Question 5 of the guide groups the risks of generative AI under hallucinations, biased outputs, data confidentiality and security, intellectual property infringement and deepfakes. A hallucination is content that does not match reality but often looks plausible and convincing. According to the guide, these models produce the statistically most likely output based on their training data rather than understanding the prompt, so a well-written answer can still be wrong. On the confidentiality side, there is a risk that personal data and commercially sensitive information users share in their prompts will be exposed (p. 23).

Question 6 asks where personal data is processed, and its answer is not limited to training. Alongside building training datasets and the training itself, the data entered while the system runs and the outputs it produces can also count as processing personal data (p. 24). The guide goes a step further: the absence of personal data in the input does not remove processing under the Law, because the model can produce data about a real person in its output from what it learned in training (p. 25). In the guide's Example 3, a general prompt asking for the success story of a famous Turkish physicist returns a real person's name, work history and awards.

Consider a hypothetical example. An HR team wants to summarize candidates' resumes with a language model. The files contain names, phone numbers and work histories, and the model may add experience the candidate never mentioned. The team needs to check two things: which fields it sends to the model, and whether the summary is consistent with the source file. The first is a personal data question and the second is a hallucination question, but both sit in the same workflow. The guide connects the two as well: a model that summarizes customer complaints and reflects personal data incompletely or incorrectly may breach the accuracy principle (Example 7, p. 34).

The first fix that comes to mind is deleting names or replacing them with placeholders. The guide's section on anonymization, however, describes anonymization as removing or altering all direct and indirect identifiers in a dataset, and it asks that a claim of anonymity be demonstrated with technical methods and objective criteria. In a resume with the name removed, the school, former employers, job title and dates can still make the person identifiable. So replacing names alone is not enough evidence for a claim of anonymity. According to the guide, data remains personal data until it has been anonymized, and the processing along the way must comply with the Law. We teach ways to use LLMs without exposing personal or confidential data, namely PII masking, reversible pseudonymization, anonymization and data residency architectures, in our Privacy-Preserving LLM Architectures course.

The guide covers these three topics in Questions 7, 8 and 9: it assigns roles by the parties' actual control, applies the Law's general principles to every stage of the life cycle and looks for a separate legal basis for each processing activity.

Question 7 defines the data controller as the person who determines the purposes and means of processing, and it asks you to look at who decides what: which data is collected from whom, for what purpose it is used, with whom it is shared and how long it is kept. According to the guide, the contract between the parties cannot by itself determine who is the controller or the processor. What decides it is the parties' actual control and decision-making power rather than the wording of the contract (p. 28).

The guide's own example is an HR unit. A company that summarizes candidates' resumes with an LLM-based system and generates preliminary scores against the job criteria may be considered the data controller, even if someone else developed the model, because it decides which data is uploaded to the system and how the outputs are evaluated (Example 4, p. 29). For closed-access models, the guide accepts that the deploying organization may not have access to every piece of information, and it recommends looking at what information the deployer can access when assigning roles. So instead of writing the same role next to every vendor, prepare a decision map showing who decides what at each stage, and send it for legal review.

Question 8 says the principles in Article 4 of the Law apply in every case to generative AI systems too: lawfulness and fairness, accuracy and being kept up to date where necessary, specified, explicit and legitimate purposes, being relevant, limited and proportionate to the purpose, and retention only for as long as necessary. The guide states plainly that vague purposes such as using data in generative AI systems or "improving our database" may breach the principle of specified purposes (p. 35).

For proportionality, the guide's example again comes from hiring: if past applications are used for a system that will analyze resumes, only the data the system needs to achieve its purpose should be processed (Example 9, p. 37). On retention, it says that an e-commerce company that trained a model on past customer support messages may breach the principle if it keeps those records indefinitely on the grounds that new versions might be developed later (Example 10, p. 38).

Add the questions these two principles raise to your use case. Does a summary need the whole file? Where do test files and model logs live, and for how long? Logs are the part of this question that is easy to forget. We cover scrubbing personal data from LLM and agent logs, retention periods and access control in our Data Minimization and KVKK Compliance in AI Logging and Observability course.

Question 9 says that all personal data processing with generative AI must rely on at least one of the conditions in Article 5 of the Law, or in Article 6 for special categories of data. According to the guide, developing the model, running it and using its outputs can be separate processing activities, and each needs its own processing condition (p. 40). In the guide's example, processing a user's input to run the model and using the same input to develop the model are two separate activities.

Nor does the guide take the approach of getting explicit consent for everything. Although explicit consent comes first in Article 5 of the Law, there is no hierarchy among the processing conditions (p. 40). If processing can rely on a condition other than explicit consent, asking for explicit consent on top of it misleads the data subject and is contrary to the principle of good faith, according to the guide (pp. 40-41). Special categories of personal data sit in a separate frame: the contract and legitimate interest conditions do not exist for them, and the adequate measures in the Board's decision 2018/10 must also be considered in generative AI systems (p. 46). Record in the use case who will assess the legal basis. Your inventory is not a legal basis. It is input for the legal team's assessment.

If personal data goes abroad when you use a generative AI system from a vendor established outside Türkiye, Question 10 of the guide says the transfer must comply with Article 9 of the Law and the cross-border transfer regulation published in the Official Gazette on 10 July 2024 (p. 48). The guide walks through the routes of Article 9 in order: first an adequacy decision, appropriate safeguards where there is no adequacy decision, and, where neither exists, transfer only in incidental cases (p. 47). So a transfer does not rest on a single general permission, and the route has to be determined for each transfer. The guide also requires the Law's safeguards for onward transfers of data sent abroad.

For the review, map the receiving party, the fields sent, the country where the data is processed and stored, onward transfers and the supporting documents in one place. This map helps the legal team choose the transfer route and tells procurement which documents to request from the vendor.

Two conclusions follow from this framework. Because the guide assesses roles, legal basis and transfers by the processing activity rather than by the product, using a cloud tool such as ChatGPT is not in itself a KVKK breach. What decides it is which data is processed, for what purpose, on what legal basis and through which transfer route. For the same reason, running the model in-house makes the transfer question smaller but does not by itself make you compliant, because purpose, legal basis, data subject rights and the security obligations of Question 13 remain. We compare the two architectures in our local LLM vs ChatGPT decision guide, and cover the technical setup steps in how to run an LLM locally.

For work where data must never leave the company, RuneLab's RuneBox is on-premise LLM infrastructure installed on the company network. Models, RAG and agent workflows run on a box with NVIDIA GPUs in a closed network without an external connection, and questions, documents and answers do not leave the organization. In the product page's words: "Because data is processed within the organization's boundaries, it makes your BDDK and KVKK assessments easier. Compliance remains your organization's own assessment."

Before the system goes live, prepare a privacy notice and a process for handling data subject requests. The guide covers these in Questions 11 and 12.

Question 11 recalls that the duty to inform in Article 10 of the Law also applies to generative AI systems. The guide considers it important to inform people separately and explicitly about processing done to use a system and processing done to develop it (pp. 49-50). In systems that interact with users directly, such as chatbots, it is also important that users clearly know they are communicating with an AI system (p. 50).

Question 12 deals with data subject rights. The guide accepts that the multi-layered structure of these systems can make access, rectification or erasure requests harder to meet, but it states plainly that this difficulty does not make the rights in Article 11 of the Law inapplicable (pp. 51-52). The scope is broad: training data, fine-tuning data, information in model outputs and content entered in user queries all fall within these rights (p. 52). According to the guide, the right to object to an adverse result produced solely by automated analysis matters even more in areas such as hiring and credit assessment.

Review the draft privacy notice side by side with the data-flow diagram from your first step. Have the legal team assess how purpose, legal basis, recipients and rights are described, and have operations rehearse who receives a request and which systems they search. The guide recommends keeping systematic records of processing and using methods such as data mapping for this work (p. 53). Do not promise users that deleting one chat also deletes all training data or what the model has learned. Confirm with the technical team what can be done at each layer of the system.

On security, the guide recalls the obligation in Article 12 of the Law and lists example technical and organizational measures. For employee use, Question 14, which is written for individuals, should be read together with the workplace document the Authority published in 2026.

Question 13 recalls that the data controller must take all necessary technical and organizational measures to prevent unlawful processing of and unlawful access to personal data and to safeguard the data, and that when someone else processes the data on its behalf, the controller is jointly responsible with them for these measures (p. 54). It then lists measures as examples: data protection impact assessments, technical controls against known weaknesses such as prompt injection and jailbreak attempts, red teaming, regular updates to risk assessments, employee training, patching and software updates, multi-factor authentication and secure storage of processing logs (pp. 55-56). The guide gives these as examples, so decide which measures each system needs based on its own risk. The Authority also covered systems in which the model uses tools and takes actions on its own in a separate 2026 document, Agentic AI (Etken Yapay Zeka). We explain how these systems work in what is an AI agent.

Question 14 focuses on individuals' everyday use. It recommends thinking carefully about what you share, not sharing data such as names, addresses, phone numbers and ID details or other people's personal data, using generalized wording where possible and reviewing privacy settings. It asks for even more caution with health, financial and legal information (pp. 57-58).

Question 14 speaks to the individual, but for a company the bigger risk is an employee uploading work files to a tool without the organization knowing. The Authority addresses this in its February 2026 document Use of Generative AI Tools in the Workplace. The document's definition of shadow AI describes employees using generative AI tools in their work outside the organization's knowledge, approval or corporate control (p. 5). It points out that meeting notes, internal correspondence, draft reports and information about employees or customers can end up shared with third-party tools this way (p. 6).

The document does not recommend a ban. It says that banning use outright is not realistic in practice and can push employees toward uncontrolled use (p. 10). Instead, it recommends a clear corporate policy that sets out the tools that may be used, the purposes of use, the types of information that may be given to the tools as input and the rules for using outputs (p. 11). As an example, it notes that some organizations allow uses such as brainstorming or polishing text, provided no personal data or trade secrets are involved, while not permitting information such as customer files and HR data to be shared (p. 12). Add to your policy who an employee should tell when something has been uploaded by mistake.

The document also recommends announcing the policy and running training and awareness activities for employees (p. 14). A policy only works when employees know which data they may enter into which tool. RuneLab's AI Awareness Training is a one-day hands-on training so the team uses generative AI tools in the right place and safely.

Question 15 of the guide matters directly to companies when they build a product or an education service that children will use, because the question is addressed to parents. The guide recommends that parents check whether the platform their child uses offers age-appropriate content, adjust privacy settings and help the child cope with misleading content (p. 59). It also asks them to explain what generative AI is, how it works and where its limits are in a way suited to the child's age (p. 60). In January 2026 the Authority published a separate brochure of recommendations for parents on the same topic.

If you are building a service for children, add this section to the product team's reading list. Do not present the recommendations for parents as new obligations for every workplace.

Bring a list that assigns the guide's question groups to owners inside the company. The table below shows, for each group, the question to ask internally, the team responsible and the document to bring to the meeting.

Do not end the meeting with just "tool selected." Give every unanswered question an owner and a check date, record the decision with a date, and decide which document gets reviewed again if the model, a vendor setting or a data source changes. To make this ownership permanent, that is, to build a corporate AI governance framework and the mechanisms that run it, we offer the Enterprise AI Governance Framework and Operating Mechanisms course.

The Personal Data Protection Authority published the guide on 24 November 2025, the date given in its official announcement. The guide's cover says November 2025 and Publication No. 113.

No. The guide is guidance from the Authority and treats personal data issues within the framework of the existing Law No. 6698. It names and bans no tool, and it explains how to assess each processing activity by its own purpose, data and parties.

No, a breach cannot be inferred from the name of the tool alone. In the guide's approach, roles, legal basis and transfers are assessed by the processing activity, so what matters is which data is processed, for what purpose and through which transfer route. If personal data is transferred abroad, you need a transfer route that complies with Article 9 of the Law.

No. An in-house setup makes the cross-border transfer question smaller, but purpose, legal basis, data subject rights and the security obligations of Article 12 of the Law remain. The questions of the guide that cover these topics apply regardless of where the model runs.

Question 7. The guide assigns roles not by the labels in the contract but by the parties' actual control and decision-making power over the purposes and means of processing. A company that integrates a ready-made model into its work and decides which data is uploaded may be considered the data controller.

Question 14 of the guide contains recommendations for individuals' everyday use: be careful about what you share, do not share other people's personal data and review your privacy settings. For workplace use and shadow AI, the Authority's February 2026 document Use of Generative AI Tools in the Workplace separately recommends a corporate policy.

According to KVKK's workplace document, shadow AI is employees using generative AI tools in their work outside the organization's knowledge, approval or corporate control. Instead of banning use outright, the document recommends a clear corporate policy that sets out the tools that may be used and the types of information that may be entered into them.

• Personal Data Protection Authority (KVKK), Üretken Yapay Zeka ve Kişisel Verilerin Korunması Rehberi (15 Soruda), announcement, 24 November 2025, full text of the guide (in Turkish), Publication No. 113, November 2025: the purpose and scope section and Questions 1 to 15.
• Personal Data Protection Authority (KVKK), Use of Generative AI Tools in the Workplace (İş Yerlerinde Üretken Yapay Zeka Araçlarının Kullanımı), February 2026, full text of the document (in Turkish): the definition of shadow AI, the risks and the corporate policy recommendations.
• Personal Data Protection Authority (KVKK), Agentic AI (Etken Yapay Zeka): announcement of the document.
• Personal Data Protection Authority (KVKK), Recommendations for Parents of Children Using AI Tools (Yapay Zeka Araçları Kullanan Çocuklar İçin Ebeveynlere Yönelik Tavsiyeler): the parents' brochure.

• Local LLM vs ChatGPT: how to decide under KVKK
• How to run an LLM locally: offline AI setup guide
• What is prompt injection?
• What is an AI agent?
• What is an LLM? How large language models work
• Courses: Privacy-Preserving LLM Architectures, Data Minimization and KVKK Compliance in AI Logging and Observability, Enterprise AI Governance Framework and Operating Mechanisms, AI Awareness Training