KVKK & LLM Security:
Personal Data Compliance in AI Projects

What is the relationship between KVKK and LLM security?

The relationship between KVKK and LLM security is, in short, this: the moment a large language model (LLM) application processes text sent by a user, stores and later retrieves that text, or trains the model on real records, a personal-data processing activity begins — and Law No. 6698 (KVKK), the Turkish equivalent of the EU's GDPR, applies. Being "AI" does not place a system outside data-protection law; if anything, because data flows are murkier than in classic software, the compliance burden is usually heavier.

The difference lies here: in a traditional application, a developer knows line by line which field is written to the database. In an LLM, the input is natural language; a user can embed a national ID, a health detail or an IBAN inside a sentence, the model takes it into context, drops it into a log, and reproduces it on a similar prompt later. This structural ambiguity foregrounds two core obligations under KVKK: data security (Article 12) and purpose-limited, proportionate processing (Article 4). LLM security is the technical embodiment of these two duties — and, for organizations touching the EU market, of the equivalent GDPR principles and the EU AI Act's data-governance rules.

Throughout this guide, "AI data compliance" means not producing a compliance document so much as making visible — and bringing under control — where personal data actually flows through the model's real data paths. Compliance is won in the data flow, not in the contract.

Where is personal data processed in an LLM project?

In an LLM system, personal data does not sit in one place; it circulates across four distinct surfaces. Each surface is a separate leak vector and a separate control point. When assessing KVKK (and GDPR) compliance, you must audit all four one by one.

1. Prompt and input layer

The user prompt is the most visible yet most underestimated surface. When a customer-support assistant receives "My father's national ID is 1XXXXXXXXXX, cancel his policy," that sentence contains personal — sometimes special-category — data at that instant. Sample customer records embedded inside the system prompt fall under the same scope. Control at the input layer means masking the data before it reaches the model, or rejecting it when it is outside the processing purpose.

2. Log and telemetry layer

LLM systems log conversations for debugging, quality measurement and observability. These logs often store the raw prompt and raw response — and therefore the personal data inside them — verbatim. When third-party observability and LLMOps tools are involved, data may be transferred, unnoticed, to a service abroad. Under KVKK, logs carry a double risk: both a retention and a cross-border transfer obligation. Keeping logs in masked form is, in most projects, the fastest compliance win available.

3. RAG and vector database layer

In Retrieval-Augmented Generation (RAG) architectures, corporate documents are chunked, converted to embeddings and indexed in a vector database. If those documents contain customer records, medical reports or HR data, personal data now sits permanently in the index. There are two risks: an unauthorized query retrieving an unrelated person's data, and content inference (inversion) from the embeddings. The critical KVKK point is that indexing is itself a "processing" activity and must be subject to access control. This surface is a common blind spot in LLM penetration testing engagements.

4. Fine-tune and training-data layer

Fine-tuning a model on real corporate data embeds personal data into the model weights. As shown in the academic literature (e.g., Carlini et al., 2020), language models can memorize rare and unique sequences from training data — phone numbers, ID numbers — and regurgitate them given the right prompt. Under KVKK this is the hardest leak to reverse: you can delete data from a log, but removing it from the model weights practically requires retraining. That is why anonymizing or masking data before fine-tuning is a foundational safeguard — and one the EU AI Act's data-governance article (Article 10) also drives toward for high-risk systems.

How do KVKK and the regulator view generative AI?

Turkey's Personal Data Protection Authority has published advisory principles on protecting personal data in the field of artificial intelligence. These principles are not a new "AI law"; they are the existing KVKK principles adapted to the AI context — closely mirroring the trajectory of the EU's GDPR and the risk-based logic of the EU AI Act. The emphasized themes are:

• Privacy by design: Data protection must be embedded from the design phase, not bolted on after the system goes live.
• Purpose limitation: The model should work only with data necessary for the stated purpose; data should not be hoarded on a "might need it later" basis.
• Data minimization: Personal data not required for the purpose should enter neither the prompt, nor the log, nor the training set.
• Transparency and disclosure: Data subjects must be informed that their data is processed by an AI system, and how.
• Bias and potential discrimination: In systems performing automated assessment, outputs must be watched so they do not produce discriminatory outcomes.

In practice these principles translate into the technical controls on the four surfaces above: minimization → input masking; purpose limitation → RAG access control; transparency → a privacy notice and, where required, explicit consent; privacy-by-design → not embedding real PII into the system prompt. Regulation is abstract, implementation is concrete; the bridge between them is architecture.

How do you protect Turkey-specific PII? (TCKN, IBAN, VKN)

This is the most frequently missed point in AI data compliance: foreign vendors' PII-detection tools are trained on US and EU formats. They recognize the US Social Security Number (SSN) but mistake a TCKN for an ordinary 11-digit number. In Turkish deployments this means local identifiers slip through the filter. The Turkey-specific personal-data types and their correct detection methods are:

The last row deserves its own heading. You can catch a TCKN or IBAN with an algorithm; but catching the health data in a sentence like "I refilled my hypertension medication" is not possible with format matching — it requires a layer that understands context. This falls into KVKK's special-category data (Article 6), which demands a stricter protection regime, directly comparable to GDPR's Article 9 special categories.

Searching for local PII with regex alone produces high false positives: every random 11-digit number is mistaken for a TCKN, every long digit string for a card. Algorithmic validation (checksum, MOD-97, Luhn) filters out this noise — regex finds the "candidate," the algorithm answers "is it real?" This two-stage approach is the foundation of practical detection in Turkish LLM deployments.

How do KVKK principles apply to LLM data processing?

KVKK Article 4 enumerates the general principles of personal-data processing — principles that align one-to-one with GDPR's Article 5. Each maps to a concrete engineering decision in an LLM project:

• Lawfulness and fairness: The processing purpose of data given to and received from the model must be documented; "shadow AI" — feeding data into unsanctioned tools — must be prevented.
• Accuracy and currency: Claims about personal data produced by the model must be verifiable; false personal information produced by hallucination is also a processing problem.
• Specific, explicit and legitimate purpose: Data collected for a chat assistant must not be reused later for marketing or profiling.
• Relevant, limited and proportionate: Only data necessary for the purpose should enter the prompt, log and training set — which technically means masking and minimization.
• Retention only as long as needed: Conversation logs must not be kept indefinitely; a retention period must be defined and automatic deletion applied.

The most concrete way to audit these principles is to test the system adversarially: whether the model leaks one person's data to another user, or reveals its system prompt, only becomes visible through LLM penetration testing. Compliance is not a set-and-forget state; it is a process that must be re-verified with every model, every prompt change and every new data source.

Does LLM data need to stay inside the country?

KVKK does not ban cross-border data transfer; Article 9 conditions it. A transfer requires either explicit consent, transfer to a country the Board has declared to provide adequate protection, or appropriate safeguards (a written undertaking or standard contractual clauses) — the same logic GDPR applies through adequacy decisions and SCCs. The problem is that meeting and documenting these conditions is complex for cloud-based third-party LLM APIs: where does the data actually go, how long is it retained, who are the sub-processors — these questions often go unanswered.

This is why, especially in sectors handling special-category data — banking, insurance, healthcare, public sector — the increasingly common choice is to host open-source models (e.g., the Llama, Mistral, DeepSeek families) on the organization's own infrastructure. Domestic self-hosting removes most of Article 9's transfer obligation because the data never leaves the border, and it grants full control over log and RAG data.

The regulatory frame is moving in this direction on both sides. Turkey's Cybersecurity Law (No. 7545), in force since 2025, has strengthened the expectation of domestic solutions and data control on the critical-infrastructure and public side; on the EU side, the EU AI Act introduces data-governance and record-keeping obligations for high-risk AI systems. For organizations operating in Turkey while also touching the EU market, the two frameworks — plus GDPR — must be read together rather than in isolation.

How does the EU AI Act change LLM data obligations?

For any organization that places an AI system on the EU market or whose outputs are used in the EU, the EU AI Act adds a layer on top of data-protection law. It does not replace GDPR or KVKK; it operates alongside them with a risk-based logic. Three of its obligations bear directly on the four LLM surfaces described above:

• Data governance (Article 10): Training, validation and testing datasets for high-risk systems must meet quality and governance criteria — relevant, representative, and examined for biases. For LLM projects this reaches straight into the fine-tune and RAG surfaces, where personal data quality and provenance must be controlled.
• Record-keeping and logging (Articles 12 and 19): High-risk systems must automatically log events over their lifecycle and retain those logs. This intersects directly with the log/telemetry surface — logging is required, but that same logging must not become an uncontrolled personal-data store, which is exactly where masking earns its place.
• Transparency (Article 50): Users must be informed when they are interacting with an AI system, and certain generated content must be marked. This mirrors the KVKK and GDPR transparency duties and is satisfied at the same disclosure layer.

Read together, KVKK and GDPR define "what" the obligation is on personal data; the EU AI Act adds "how" that data must be governed and logged across a high-risk system's lifecycle. The technical controls do not multiply — masking, access control, retention limits and adversarial testing serve all three frameworks at once.

What does an AI data compliance checklist include?

The list below summarizes the minimum compliance steps to clear before taking an LLM project live. Each item rests on one of the surfaces described above.

• Data inventory: Is it recorded which personal data enters the model (prompt, RAG, fine-tune) and which data could leave it?
• Lawful basis: Is explicit consent or a statutory ground established for each processing purpose? Is the extra condition met for special-category data?
• Input masking: Are TCKN, IBAN, VKN, card and phone numbers algorithmically detected and masked before reaching the model?
• Output control: Is the model's response checked before it can leak another user's data or the system prompt?
• Log hygiene: Are logs masked, is a retention period defined, is access authorization-based?
• RAG access control: Are documents in the vector index filtered according to user authorization?
• Cross-border transfer: If a third-party API is used, is the Article 9 basis and the sub-processor chain documented?
• Transparency and disclosure: Are data subjects informed that data is processed with AI?
• Special-category data: Is there separate detection and stricter control for Article 6 data such as health, belief and sexual life?
• Breach response: Is there a defined process to notify within the required window in the event of a leak?
• Regular testing: Is the model periodically red-teamed for PII leakage and prompt injection?

This list does not replace a compliance document; it shows the technical team where to anchor compliance at the code and architecture level. The gap between the legal text and the running system is where most breaches are born.

Which standards does this map to?

KVKK-LLM compliance does not stand alone; it sits on firmer ground when read alongside international frameworks. The main mappings:

These frameworks are not mutually exclusive: KVKK and GDPR tell you "what" the obligation is, while OWASP, MITRE ATLAS and NIST AI RMF tell you "how" to defend, and the EU AI Act governs how data is managed across a high-risk system's lifecycle.

How do you apply masking and technical controls?

The most practical technique for turning compliance into code is masking: replacing personal data — before processing or before logging — with an irreversible or authorization-reversible placeholder. A TCKN, for example, can reach the model as "[TCKN]"; the model does its work from context and never sees the real number. A layered architecture has three control points:

• Input layer: Detect TCKN/IBAN/VKN/card/phone with regex + algorithmic validation; mask or reject on detection.
• Context layer: Catch special-category data (health, belief, sexual life) in free text via contextual classification.
• Output layer: Check the model's response one last time for PII or system-prompt leakage.

AltaySec's Guardian product combines these three layers into a single defense line; its PII module is designed to target, from the first line, the TCKN/IBAN/VKN algorithmic detection and KVKK Article 6 categories that Turkish deployments need. The point here is not to promote a product but to show that the gap foreign tools leave in the Turkish and KVKK context can be closed concretely. The same approach can be built with open-source libraries and your own controls; what matters is that all three layers are in place.

Conclusion

KVKK and LLM security are not two separate topics but two faces of the same problem. A language-model project processes personal data across four surfaces — prompt, log, RAG, fine-tune — and each surface demands its own compliance decision. The particular challenge of Turkish deployments is that foreign tools do not recognize local identifiers like TCKN, IBAN and VKN and cannot read special-category data from context. This gap can be closed with local rules, algorithmic validation and layered masking.

Compliance is won not in a document but in the data flow of the running system. The most robust approach is therefore to embed compliance at design time, keep data in-country where feasible, and regularly test the model for PII leakage — while reading KVKK, GDPR and the EU AI Act as one obligation set rather than three. Pushing AI projects into production without controls, for the sake of speed, is the most costly mistake in the growing compliance wave of 2026.

For feedback, an enterprise assessment or a project-specific conversation: [email protected]

Frequently Asked Questions