Transparency, Explicit Consent, VERBİS: KVKK Practice in AI Projects

What is KVKK practice in AI projects? KVKK practice in AI projects is the discipline of taking the obligations of Türkiye's Personal Data Protection Law (KVKK, Law No. 6698) out of the realm of abstract principle and turning them into concrete, applicable, and documentable steps in an AI project that processes personal data. These steps include choosing a valid processing basis (explicit consent or legitimate interest), fulfilling the duty to inform, preparing a data-processing inventory and updating the VERBİS registration where needed, performing a DPIA for high-risk processing, and contracting the relationship with AI providers.

This guide answers not "should we use AI?" but "how do we build and operate AI in a KVKK-compliant way?" With the rigor of a management consultant and a compliance engineer, we address KVKK obligations in AI projects step by step, with template skeletons, under the headings of the duty to inform, explicit consent, legitimate interest, VERBİS, the data-processing inventory, and DPIA. An important note: this content is informational and does not constitute legal advice; every organization must work with legal and compliance experts for its own specific situation. For the law's general framework, see what is KVKK, and for the definition of personal data, what is personal data.

Definition

KVKK Practice in AI Projects

The discipline of turning the obligations of Türkiye's Personal Data Protection Law (KVKK, Law No. 6698) into concrete, applicable, and documentable steps in an AI project that processes personal data. It covers embedding a valid processing basis (explicit consent or legitimate interest), the duty to inform, a data-processing inventory and VERBİS, a DPIA where needed, the controller-processor relationship, technical-administrative security, cross-border transfer, and a retention-and-destruction policy into an AI project's lifecycle.

Also known as: KVKK in AI projects, AI KVKK compliance practice, AI data protection practice

AI projects work with an organization's most valuable and most sensitive asset — personal data. A customer-service assistant processes customer records, a hiring model processes candidate résumés, a recommendation system processes user behavior. That is why KVKK practice in AI projects is not a "nice to have" add-on but a design requirement to be addressed at the very start of the project. The law does not specifically define AI; but to the extent an AI system processes personal data, all the law's principles and obligations apply directly to it.

The first reason for its criticality is enforcement risk. KVKK provides for administrative fines in cases of unlawful processing, breach of the duty to inform, failure to take data security measures, and non-compliance with the VERBİS obligation. Because data volumes in AI projects are large, the impact of a breach can be far wider than in a traditional system. Since current fine amounts change each year with the revaluation rate, exact figures should be checked against the KVKK Authority's current announcements; instead of inventing a number, this guide uses the general phrase "the administrative fines foreseen in KVKK."

The second reason is reputation and trust. When organizations entrust their customers' data to AI, they give a promise that this trust will not be abused. A poorly designed profiling system or a data breach can destroy that trust overnight. The third reason is sustainability: adding compliance afterward is expensive and often impossible. Questioning, after the fact, whether you had the right to process the data used to train a model built by indiscriminately collecting personal data can mean rebuilding the model from scratch.

There is another dimension specific to Türkiye: the pace of adoption. According to We Are Social's "Digital 2026" data, Türkiye ranks first in the world in the share of web traffic referred from generative AI tools. This high adoption creates a gap where organizations put AI into use quickly but cannot build compliance at the same pace. Organizations that build KVKK practice in AI projects with discipline close this gap and move both fast and safely.

To build KVKK practice in AI projects correctly, you must first see at which stages of an AI project the law applies. A common fallacy is to tie compliance only to the moment of "data collection"; yet processing covers the data's entire journey inside the model. Collecting data, training the model, running the model (inference), and storing the output — all are processing activities, and each requires a basis and conformity with the principles.

This holistic view has three important consequences. First, processing applies at every stage: using data collected for one purpose to train a model is a separate processing activity and can violate purpose limitation if it does not align with the original purpose. Second, inferences are also personal data: if a model produces a prediction about a person (credit risk, interest, health tendency), that produced information is also personal data and must be protected. Third, special-category data requires special attention: health, biometrics, religion, and political opinion are subject to stricter protection.

That is why KVKK obligations in AI projects require a more careful approach than a classic database. A model can "memorize" personal data, leak it in the output, or produce unexpected inferences. KVKK practice in AI projects requires protecting "what the model infers" as much as "what the model learns." The table below summarizes the stages where the law applies and the key question at each.

Stages of the AI lifecycle where KVKK applies

Stage	Processing activity	Key KVKK question
Data collection	Acquiring training/operating data	On what basis, for what purpose?
Model training	Using personal data in learning	Is purpose limitation violated?
Inference	Producing predictions about a person	Inference is personal data; is it protected?
Automated decision	Acting on the model's output	Is there human oversight and objection?
Storage	Keeping data and output	Are retention and destruction defined?

The first and most fundamental step of KVKK practice in AI projects is finding a valid legal basis for every processing activity. Under KVKK, personal data may be processed only on one of the processing conditions listed in the law; processing without a basis is unlawful, however well-intentioned. That is why every AI project must give a clear answer to "on what basis am I processing this data?" Article 5 defines conditions for general data, and Article 6 a stricter regime for special-category data.

A common mistake is treating explicit consent as an automatic first choice. Under KVKK, explicit consent is a basis resorted to when the other processing conditions do not apply. Article 5 lists conditions such as being foreseen by law, necessity for establishing/performing a contract, the controller's legal obligation, the data being made public, the establishment/exercise of a right, and legitimate interest; if none of these apply, explicit consent is required. Choosing the right basis is one of the most critical legal decisions in KVKK obligations in AI projects.

When and How Is Explicit Consent Obtained?

Explicit consent is approval given by the person on a specific matter, in an informed way, and by free will. It has three elements: it must relate to a specific matter, rest on information, and be declared by free will. Its most important feature is that it is withdrawable; the person must be able to withdraw consent at any time, and this must be technically applicable in the system too. Moreover, explicit consent cannot be tied to a service as a precondition — a "no consent, no service" ultimatum invalidates it. A blanket consent is also invalid; a separate, understandable consent is required for each purpose.

The practical difficulty of explicit consent in AI projects is that data use can change over time. Using data collected to train a model later for another purpose can fall outside the scope of the original consent. That is why, in consent-based projects, the scope must be defined clearly enough from the start, and new consent obtained if the purpose expands. The moment consent was obtained, its scope, and the withdrawal record must be kept for proof, because the burden of proof in KVKK largely lies with the controller.

How Is Legitimate Interest and the Balancing Test Built?

Legitimate interest is a basis used by balancing the controller's reasonable and genuine interest against the person's fundamental rights and freedoms without harming them. It is flexible but not arbitrary: to use it, a balancing test (interest-balancing analysis) must be performed and documented. In this test, the organization's interest is weighed against the person's reasonable expectations and rights; if the processing harms the person's rights disproportionately, legitimate interest cannot be the basis. The balancing test is the invisible but mandatory document of legitimate interest.

In AI, legitimate interest can be appropriate for processing that also benefits the person, such as fraud detection or system security. A common mistake, however, is using legitimate interest as "the easy way to avoid obtaining explicit consent." Without a balancing test, it is the most fragile basis; it is also the first thing questioned in an audit. When special-category data is involved the rule is even stricter: explicit consent or a legal exception is required in most cases, and legitimate interest alone may not suffice. This distinction is vital in biometric systems like facial recognition, which we also cover in what is facial recognition.

Comparison of explicit consent and legitimate interest

Dimension	Explicit consent	Legitimate interest
Core logic	The person's informed approval	Balanced organizational interest
Documentation	Consent record, scope notice	Balancing test (interest analysis)
Withdrawal	Always withdrawable	Right to object exists
Typical use	Marketing, optional features	Security, fraud detection
Risk	Processing stops if withdrawn	Invalid if the balancing test is weak

The duty to inform is the controller's obligation to inform the data subject before processing personal data. Under KVKK, the person has the right to know who processes which data, for what purpose, on what basis, to whom it is transferred, and what their rights are. In KVKK practice in AI projects, the duty to inform must be fulfilled both in the classic sense and with an AI-specific transparency dimension. The duty to inform is different from explicit consent: informing is a notification and is required in every processing; explicit consent is required only when used as a basis.

The classic dimension is preparing a privacy notice and presenting it to the person. This notice must include the controller's identity, processing purposes, legal basis, recipients, retention period, and the data subject's rights. When AI is involved, the notice must also clearly state that the data is processed by an AI system and that automated decisions/profiling occur if they do. The person has the right to know that their data feeds a model; hiding this is a breach of the duty to inform.

The AI-specific dimension is understandable transparency. If an AI system decides about a person or profiles them, the notice cannot suffice with "we use AI"; it must give meaningful information about the logic of the process. This is not disclosing the model's full technical detail but ensuring the person reasonably understands "on what basis they are evaluated." This transparency is required from both a KVKK and an explainable-AI standpoint; we deepen the topic in what is explainable AI.

The most common mistake in the duty to inform is writing the notice once and forgetting it. AI systems change quickly: new data sources are added, new purposes emerge, the model produces new outputs. If the notice is not kept current to reflect this change, a technically existing but substantively wrong notice results. The notice must be treated as a living document; this discipline is an invisible but decisive part of KVKK obligations in AI projects.

KVKK practice in AI projects requires not only acting correctly but being able to document that you act correctly. The two fundamental tools of this documentation are the data-processing inventory and the VERBİS registration. Without them, an organization cannot prove its claim that "we process our data lawfully"; and the burden of proof in KVKK largely lies with the controller. In AI projects this pair is especially critical, because AI constantly transforms data.

What Is the Data-Processing Inventory and How Is It Prepared?

The data-processing inventory is a living record showing which personal data the organization processes, for what purpose, on what basis, for how long it retains it, to whom it transfers it, and which security measures it takes. To prepare it in an AI project, first map all data sources and flows; then, for each processing activity, write the purpose, basis, data category, recipient groups, retention period, and transfer information. The critical point in AI is that data takes different forms — raw data, attributes, embeddings, model parameters, and outputs; a good data-processing inventory makes this transformation chain traceable.

The practical value of the data-processing inventory is that it is a "blind spot" map: while preparing it, an organization often discovers processing it had not noticed — data going to a cloud tool, a record kept at a sub-processor, an inference produced and stored by a model. Without the inventory, compliance gaps stay invisible. That is why the first practical step of KVKK practice in AI projects is often preparing a comprehensive data-processing inventory. The inventory is also a precondition for fulfilling data subject rights (especially the right to erasure): if you do not know where the data is, you cannot delete it.

Who Must Register with VERBİS?

VERBİS (the Data Controllers Registry Information System) is an official registry where controllers meeting certain criteria must register and provide information about their processing activities. The obligation to register with VERBİS depends on the organization's size (employee count, financial balance sheet) and the nature of the data it processes; current thresholds should be checked against the Authority's announcements. Because AI projects generally increase the volume and variety of processed data, they can affect the scope and accuracy of the VERBİS declaration.

The data-processing inventory and VERBİS feed each other: the inventory is internal documentation, VERBİS is a declaration to the outside (the Authority). Without a solid inventory, making an accurate VERBİS declaration is nearly impossible. When a new AI system is deployed, the data-processing inventory should be updated first, then the VERBİS declaration reviewed accordingly. Keeping both current is, for KVKK obligations in AI projects, both a legal obligation and the foundation of governance. We cover the whole of enterprise AI governance in what is AI governance.

Data-processing inventory and VERBİS: role and critical point in AI

Tool	Nature	Critical point in AI
Data-processing inventory	Internal documentation (living record)	Tracing the raw data → embedding → output chain
VERBİS registration	Declaration to the official registry	Updating the declaration for a new system
Relationship	The inventory feeds VERBİS	Without the inventory, the declaration is unreliable

A DPIA (Data Protection Impact Assessment) is a systematic exercise that assesses in advance the risks of a processing activity to people's rights and freedoms and plans mitigating measures. Because AI projects by their nature involve high-risk processing, a DPIA is often the most critical part of KVKK practice in AI projects. A DPIA is the way to see risk before the project and to improve the design accordingly.

When Is a DPIA Needed?

A DPIA is recommended when processing is likely to result in high risk. In an AI context, high-risk signals include large-scale personal data processing; systematic and extensive profiling; use of special-category data (health, biometrics); automated decisions with significant effects on a person; data of vulnerable groups (children, patients); and the first-time use of a new technology. If an AI project carries even one of these signals, a DPIA is strongly recommended. A credit-scoring model, a hiring screening system, or a health prediction model is almost always high-risk processing that requires a DPIA.

How Is a DPIA Done?

A DPIA is a systematic process and typically proceeds in five steps: a detailed description of the processing, assessment of necessity and proportionality, identification of risks to people, planning of mitigating measures, and documentation of the result. This process is not done once and finished; the DPIA must be updated as the project changes. The greatest value of a DPIA is turning risk from an abstract concern into a concrete, manageable list. Working with an AI-specific DPIA template speeds up the process.

How to

DPIA steps in an AI project

The core steps of running a data protection impact assessment end to end.

1. 1

   Describe the processing

   Write in detail which data, which purpose, which basis, which flow, and which parties.

2. 2

   Assess necessity and proportionality

   Is the processing truly necessary; is there a less intrusive way? Question data minimization.

3. 3

   Identify the risks

   List the possible harms to people (discrimination, loss of privacy, wrong decision) and rate them by likelihood/impact.

4. 4

   Plan mitigating measures

   Reduce each risk with measures like anonymization, access control, human oversight, and transparency.

5. 5

   Document and review

   Put the result in writing; update the DPIA as the project changes and review it regularly.

The strategic benefit of doing a DPIA early must be emphasized: a DPIA done before the project starts both secures compliance and improves the design. For example, during a DPIA the question "is this special-category data truly necessary?" often eliminates an unnecessary data-collection item at the outset. That is why a DPIA is not an obstacle but a tool that simplifies the design. Data minimization and anonymization are the most frequently recommended mitigating measures in a DPIA; you can find anonymization methods in what is data anonymization.

Modern enterprise AI is largely built on third-party providers: a language-model API, a cloud platform, a vector-database service. A question often ignored in KVKK practice in AI projects is "who is responsible for this data?" KVKK defines two fundamental roles: the data controller who determines the purposes and means of processing, and the data processor who processes data on the controller's behalf and instruction. In an AI project the organization is usually the controller, while its cloud/model provider is the processor.

The correct sharing of roles is secured by contract. Between the controller and the processor there must be a written data processing agreement defining the subject, duration, purpose, data type of the processing, and the processor's obligations. This agreement must cover the processor acting only on the controller's instructions, taking the necessary security measures, notifying the controller of sub-processor use, and deleting or returning the data at the end of processing. In the AI context, the most critical clause is to regulate explicitly whether the provider may use the data to train its own models.

A common mistake is the assumption that "the provider is big and trustworthy, so it handles compliance." Yet under KVKK the controller's responsibility cannot be delegated to the processor. Even using a cloud AI tool, the organization remains primarily responsible for the personal data it sends. That is why provider selection is not only a technical but a compliance decision: the safeguards the provider offers must be enough for the organization to fulfill its own obligation. In some scenarios the parties may be joint controllers; then how responsibility is shared must be separately determined.

A special risk with AI tools is the "shadow AI" phenomenon: employees entering personal data into publicly available AI tools without the organization's approval. An employee pasting customer data into a chat tool can unknowingly create a cross-border transfer and out-of-purpose processing. This risk is managed less by technical barriers and more by culture and training; employees need to know, through a clear policy, which data they may enter into which tool. That is why AI literacy is a human, not a technical, component of KVKK practice in AI projects.

Now let us turn all these principles into an applicable order that builds an AI project end to end. The power of KVKK practice in AI projects comes from making the principles a natural part of the project; compliance stops being an add-on. The steps below offer a backbone from design to operation.

How to

KVKK implementation steps in AI projects

A step-by-step guide to building an AI project KVKK-compliant from design to operation.

1. 1

   Map data and purpose

   Clarify in a data-processing inventory which personal data the project processes and for what purpose.

2. 2

   Determine and document the basis

   Choose a valid basis for each processing; write a balancing test for legitimate interest.

3. 3

   Minimize the data

   Process only necessary data; anonymize or pseudonymize wherever possible.

4. 4

   Inform and be transparent

   Present a current privacy notice; state clearly if there is automated decision/profiling.

5. 5

   Assess risk (DPIA)

   Do a data protection impact assessment for high-risk processing.

6. 6

   Update VERBİS

   Record the new system in the inventory; review the VERBİS declaration if registration is mandatory.

7. 7

   Contract the provider

   Sign a data processing agreement with the AI provider; clarify the model-training clause.

8. 8

   Set up security and transfer

   Encryption, access control, guardrails; define cross-border transfer safeguards.

9. 9

   Define retention-destruction

   Set a retention period and destruction mechanism for each data category.

10. 10

    Monitor, document, update

    Regularly update the inventory, DPIA, and notice as the project changes.

Applying this order to a narrow pilot project is far smarter than trying to transform the whole organization at once. Building compliance end to end in a small, well-defined AI use develops the organization's compliance muscle and eases later, larger projects. KVKK practice in AI projects is not a one-off project but an organizational competence. To build it, teams need to develop their AI and data-protection literacy together; enterprise training options help close this gap.

To make the practice concrete, we provide the skeletons of the four fundamental documents of KVKK practice in AI projects. These skeletons are informational starting points; every organization must adapt them to its own situation with a legal expert and turn them into real text. The goal is to start from a structured framework rather than a blank page.

Privacy Notice Skeleton (AI-Focused)

An AI privacy notice should include these headings: (1) the controller's identity and contact information; (2) the categories of personal data processed; (3) processing purposes — here it is clearly stated that the data is processed by an AI system; (4) the legal basis (such as explicit consent or legitimate interest); (5) whether automated decisions/profiling occur and their possible effects on the person; (6) the parties to whom data is transferred (AI providers, sub-processors) and cross-border transfer status; (7) the retention period; (8) the data subject's rights and the way to apply. The duty to inform is fulfilled by presenting these headings in understandable language.

Explicit Consent Text Skeleton

The explicit consent text must be separate from and in addition to the privacy notice. Skeleton: (1) which specific processing the consent covers (a general/blanket consent is invalid); (2) a statement that consent is given freely and is not tied to a service precondition; (3) that consent can be withdrawn at any time and how to do so; (4) what the consequences of withdrawal are; (5) the date of consent and that a record is kept. Explicit consent must be obtained by an active action of the person (ticking a box themselves); pre-ticked boxes must not be used.

Data-Processing Inventory Row Skeleton

Each row of the inventory describes a processing activity and includes: the name of the processing activity; data category (e.g., contact, financial, special-category); data subject group (customer, employee, candidate); processing purpose; legal basis; AI-specific form (raw data / attribute / embedding / model output); recipient groups and sub-processors; cross-border transfer status; retention period; and the technical-administrative security measures taken. This row structure sets up the data-processing inventory to feed directly into both the VERBİS declaration and the DPIA.

DPIA Summary Skeleton

A DPIA report summary skeleton consists of these sections: (1) description of the processing and a flow diagram; (2) necessity and proportionality assessment (is there a less intrusive alternative?); (3) risk register — for each risk, likelihood, impact, and affected group; (4) mitigating measures and which risk each measure reduces; (5) residual risk assessment and decision; (6) review date and owner. This skeleton turns the DPIA into an auditable and updatable document.

Let us turn all these principles into an item-by-item checklist applicable end to end in an AI project. This list is the backbone of KVKK practice in AI projects; if you can check each item in your project, you have a solid compliance foundation. The list is informational and does not replace legal advice.

Ten-item implementation checklist for KVKK in AI projects

#	Checklist item	What to verify?
1	Data-processing inventory and purpose	Which personal data, for what purpose?
2	Processing basis	A valid basis (explicit consent or legitimate interest) and balancing test?
3	Data minimization	Only necessary data; anonymization where possible?
4	Duty to inform	A current privacy notice and AI transparency?
5	VERBİS	If mandatory, is the declaration current and consistent with the inventory?
6	DPIA	Was an impact assessment done for high-risk processing?
7	Automated decision and profiling	Are human oversight and an objection mechanism set up?
8	Provider agreement	Is there a data processing agreement and a model-training clause?
9	Security and cross-border transfer	Encryption, access control, and transfer safeguards documented?
10	Retention and destruction	Are retention periods and a destruction mechanism defined?

This ten-item list breaks seemingly complex compliance into manageable pieces. What matters is using the list not as an audit tool at the end of the project but as a design guide at the start. Each item is cheap and easy when asked at the design stage; expensive and sometimes impossible when asked after the project is finished. For a broader compliance checklist, see the KVKK-compliant AI checklist, and for the conceptual foundation, what is KVKK-compliant AI.

One of AI's most sensitive uses is making automated decisions about people and profiling them. KVKK gives special attention to decisions made solely on automated processing that produce legal effects on a person or similarly significantly affect them. If AI rejects a credit application, screens out a job application, or sets a person-specific price, in terms of KVKK practice in AI projects we are exactly in this sensitive area.

The core requirement is meaningful human oversight at the end of the process. The word "meaningful" is critical: a human who only approves the decision and accepts the model's output blindly provides no real oversight. Meaningful human oversight requires a person who can question the decision, change it where needed, and has the authority and knowledge to do so. The second requirement is establishing the person's right to object and present a view: a person subject to an automated decision must be able to be aware of it, object, and request human intervention. These mechanisms must be technically embedded in the system; a "complaint form" added afterward is often insufficient.

An additional care in profiling is that inferences are personal data. A model can infer information the person did not directly provide (a health tendency, a political leaning) from their behavior; this inference is also personal data and can sometimes be special-category. Moreover, the biggest risk of automated decisions is that bias in the model turns into systematic discrimination; we cover this in what is bias in AI. That is why profiling systems must look not only at the input data but at the inferences they produce and their fairness.

Automated decision and profiling: risk and required measure

Situation	Risk	Required measure
Automated decision with significant effect	Wrong/discriminatory decision	Meaningful human oversight + objection path
Systematic profiling	Privacy and bias	DPIA + transparency + limitation
Inference production	Hidden special-category data	Treat inference as personal data too
Vulnerable group data	Disproportionate harm	Extra protection + cautious processing

Most modern AI tools are cloud-based and their data may be processed on servers outside Türkiye. This raises cross-border data transfer, a special topic under KVKK. An AI tool processing personal data abroad is not by itself prohibited; but KVKK's cross-border transfer rules must be followed. This is one of the most often skipped compliance areas in KVKK practice in AI projects. The law ties transfer to certain safeguards (explicit consent, undertakings providing adequate protection, or other conditions foreseen in law).

There are practical ways to reduce cross-border transfer risk. First, data localization: choosing a solution or region that processes data in Türkiye where possible. Second, anonymization: taking data going abroad out of KVKK's scope by making the person unidentifiable. Third, self-hosting: running an open-source model in-house so data never leaves. In regulated sectors (e.g., banking's BDDK rules), cross-border transfer rules can be even stricter. We compare the parallel between GDPR and KVKK on this in what is GDPR.

On the security dimension, KVKK obliges the controller to take the necessary technical and administrative measures. In AI this surface is wider: data resides not only in a database but also in the training set, model parameters, and output records. Technical measures include access control, encryption, logging, and — AI-specific — auditing model outputs. AI also brings new attack surfaces such as prompt injection; we cover this risk in what is prompt injection and protective layers in what is a guardrail. Guardrails that prevent the model from leaking sensitive data in the output are an AI-specific security measure.

On retention and destruction, KVKK requires data to be kept only as long as necessary for the purpose; once the period expires, it must be deleted, destroyed, or anonymized. In AI this is more complex, because data may be spread across many forms (raw data, attribute, embedding, model, output). The critical question is: when a person requests deletion, is the data deleted only from the raw database, or does it also cover the traces the model learned? This difficulty must be managed from the start with data minimization and anonymization; if the model has memorized no personal data, the deletion problem largely disappears. Destruction must also cover backups, logs, and copies in third-party tools.

Seen through an experienced compliance eye, a recurring set of violations appears in AI projects. The common feature of these mistakes is that most stem from leaving compliance to the end of the project. Organizations that build KVKK practice in AI projects early avoid most of these traps. The most common are:

• Processing without a basis: Processing personal data without determining a valid basis (like explicit consent or legitimate interest); the most basic and most common violation.
• Purpose creep: Using data collected for one purpose for an entirely different purpose, such as training a model, on the logic of "since we have it"; violates purpose limitation.
• Missing or outdated notice: Not fulfilling the duty to inform at all, or not updating the notice as the AI changes.
• Blanket explicit consent: Tying every processing to a single, general consent; a non-specific consent is invalid.
• Not updating the inventory and VERBİS: Not updating the data-processing inventory and VERBİS declaration when a new AI system is deployed.
• Skipping the DPIA: Starting high-risk processing without doing an impact assessment.
• No human oversight in automated decisions: Leaving a decision with significant effect entirely to the model without an objection path and meaningful oversight.
• Not auditing cross-border transfer: Sending data to cloud/API tools without reviewing where it is processed and the sub-processors.
• Forgetting destruction: Not deleting data (and its copies in backups) whose retention period has expired.

On the sanctions side, KVKK provides for administrative fines for unlawful processing, breach of the duty to inform, failure to take data security measures, and non-compliance with the VERBİS obligation. Because these fines are updated each year with the revaluation rate, this guide uses the phrase "the administrative fines foreseen in KVKK" instead of a specific amount; current figures should be checked against the Authority (the KVKK Authority). Beyond the administrative fine, there is also the right of affected people to claim compensation and a serious reputational risk for the organization.

KVKK practice in AI projects carries different weights by sector, because the nature of the data and the risk profile change with each sector. The examples below show which compliance dimension stands out in which sector; details vary by each organization's situation and must be clarified with legal counsel.

In healthcare, data is largely special-category (health) data and is therefore subject to the strictest protection regime. An organization building a diagnostic-support model or a patient-prediction system usually seeks explicit consent or a legal exception, performs a DPIA, and pays special attention to cross-border transfer. In finance and banking, the main topics center on automated decisions such as credit scoring and fraud detection; a model evaluating a credit application falls under significant-effect automated decisions, so meaningful human oversight and an objection path are mandatory. Banking's sector regulations may also require data localization.

In retail and marketing the main topic is customer profiling and personalized recommendations; here the processing basis, the duty to inform, and purpose limitation stand out. The most common mistake is using customer data collected for one purpose out-of-purpose to train a recommendation model. In human resources, hiring and employee evaluation carry both automated-decision and bias risks; a candidate-screening model produces significant effects on candidates, so transparency, human oversight, and discrimination auditing are critical. In customer service, where the data entered into a chatbot is processed (cross-border transfer) and stored stands out. This sectoral variety shows that KVKK practice in AI projects must be built not with a single template but adapted to context.

The common denominator is the same in every sector: whatever the nature of the personal data processed, the basis, the duty to inform, the data-processing inventory, a DPIA where needed, and VERBİS form the same backbone; the sector only determines how much weight each item receives. Public sector, education, insurance, and logistics also adapt this backbone to their own risk profiles. So the KVKK practice in AI projects an organization builds in one sector can be carried to another with the same method; what changes is not the content but the weights. For an enterprise roadmap, AI consulting support speeds up setting the sector-specific weights correctly.

One of the often-ignored yet most powerful levers of KVKK practice in AI projects is the distinction of whether data is personal. KVKK applies only to personal data; truly anonymized data — data that can no longer be linked back to an identified or identifiable person — falls outside the law's scope. This distinction can dramatically reduce an AI project's compliance burden: if a model can be trained with anonymous rather than personal data, many obligations like the duty to inform, explicit consent, and VERBİS largely ease.

A common mistake here is confusing pseudonymization with anonymization. Pseudonymization replaces identity information with a key; but because the key still exists, the data can be linked back to the person and is therefore still personal data. True anonymization must be irreversible; no reasonable way to reach the person should remain. This is hard in AI, because in rich datasets even a combination of a few seemingly innocent attributes can make a person re-identifiable. We cover anonymization methods and pitfalls in what is data anonymization.

The practical upshot is: in an AI project, saying "we anonymized this data" provides compliance only when backed by a rigorous technical assessment. Superficial masking does not remove data from KVKK's scope and creates a false sense of security. That is why KVKK practice in AI projects must treat anonymization not as a checkbox but as an engineering goal to be measured and verified. Well-designed anonymization both eases compliance and limits harm in a data breach.

Among KVKK's general principles, the two most challenging for AI are data minimization and purpose limitation. AI culture historically developed on the logic of "the more data, the better"; yet KVKK says the opposite: only as much data as necessary, only for the specified purpose. This tension sits at the heart of KVKK practice in AI projects and is most often resolved — or left unresolved — here.

Data minimization is the principle that only necessary, relevant, and proportionate personal data is processed. In AI this means not collecting every field just because "it might marginally improve model performance," removing unnecessary personal attributes from the training dataset, and using anonymization or pseudonymization wherever possible. Its practical power is that it is also a risk-reduction strategy: data that is not processed cannot be leaked. When a breach occurs, the less personal data the system processes, the more limited the harm.

Purpose limitation is the principle that personal data is processed only for the specific, explicit, and legitimate purpose for which it was collected and not used in a way incompatible with it. This is the most frequently violated principle in AI: using data collected for one purpose (e.g., order delivery) later for another (training a recommendation model) can violate purpose limitation. The way to protect this principle is to ask, for each dataset, "for what purpose was this collected, and is this use compatible with it?" If not, either a new basis (e.g., explicit consent) must be obtained or the data anonymized to take it out of the law's scope.

The point where compliance most often fails in an AI project is not technical inadequacy but an ownership gap. When "compliance is everyone's job," it often becomes "compliance is no one's job." KVKK practice in AI projects cannot be sustained without a clearly defined ownership structure; someone must be responsible for monitoring that compliance happens and intervening on deviations.

A solid governance model brings together at least three roles. The data protection officer or contact person oversees that legal obligations are met and data subject requests answered; they represent the legal backbone. The technical team or AI engineer is responsible for actually applying data minimization, security measures, and technical constraints; they turn principles into code. The business owner knows the project's purpose and benefit; they assess the realism of the processing basis and purpose. Without these three roles together, compliance either stays on paper or is not applied in practice.

The second dimension is the decision mechanism. When a new AI use is proposed, it must pass a compliance assessment (which data, which basis, which risk, which measure). If this is not embedded as a formal stage, projects proceed skipping the check and the problem surfaces only in an audit or breach. Mature organizations pass AI ideas through a "compliance gate" that exists not to block the project but to see risk early. To catch these mistakes with an independent eye, AI consulting support adds high value at the design stage.

KVKK practice in AI projects is not a one-off goal but a maturity state that must be monitored continuously. An organization should answer "are we compliant?" not with a yes/no but with a maturity level. Measuring compliance makes it manageable; unmeasured compliance erodes over time and turns into a violation unnoticed. That is why mature organizations track compliance with a regular self-assessment.

The practical way is a regular assessment across a few dimensions. The first is coverage: are all the organization's AI systems in the data-processing inventory and assessed, or only some? The second is depth: how much of the ten-item checklist is truly met for each system — is the basis documented, is the duty to inform current, was a DPIA done? The third is continuity: was compliance done once, or updated with changes? The fourth is culture: do employees see data protection as a burden or as a natural way of working?

An organization that regularly measures these dimensions catches compliance gaps before they turn into violations. Measurement can be tied to a dashboard: how many AI systems are inventoried, for how many a DPIA was done, how many privacy notices are current, in how many systems there is automated-decision auditing, with how many providers a data processing agreement is signed. These metrics turn KVKK practice in AI projects from an abstract goal into a concrete, trackable state. The strategic value of maturity is that the compliance competence built in the first projects accelerates later ones: an organization that once builds a solid framework (inventory template, DPIA process, notice library, supplier criteria) rapidly builds each new AI project on top of it.

In short, KVKK practice in AI projects is building an AI project that processes personal data in line with KVKK's principles and obligations, from the design stage onward. This requires choosing a valid basis for each processing (explicit consent or documented legitimate interest), fulfilling the duty to inform in two layers, preparing a data-processing inventory and keeping VERBİS current, doing a DPIA for high-risk processing, contracting the relationship with the AI provider, managing technical-administrative security and cross-border transfer, and defining a retention-and-destruction policy.

The most important message is this: compliance is not a formality left to the end of the project but a part of the design. Organizations that use the ten-item checklist as a design guide at the start move both fast and safely; those who leave compliance to the end face expensive and sometimes impossible fixes. For organizations serving Europe, combining KVKK with the EU AI Act in a single governance framework is especially efficient. Fulfilling the duty to inform on time, choosing a valid basis (explicit consent or legitimate interest), keeping the data-processing inventory and VERBİS current, and doing a DPIA at high risk — these four habits form the backbone of KVKK practice in AI projects. This content is informational and does not replace legal advice; every organization should obtain expert advice for its own situation.

For the basics, see the what is KVKK, what is personal data, and what is AI guides; for a broader compliance checklist, see the KVKK-compliant AI checklist; for a compliance and AI roadmap specific to your organization, start with AI consulting, review enterprise training options for your teams, and deepen all the concepts in the learning center.

What is KVKK practice in AI projects?

KVKK practice in AI projects means turning the obligations of Türkiye's Personal Data Protection Law (Law No. 6698) into concrete steps in an AI project that processes personal data. This covers choosing a valid processing basis (explicit consent or legitimate interest), fulfilling the duty to inform, preparing a data-processing inventory and updating VERBİS where needed, performing a DPIA for high-risk processing, contracting the controller-processor relationship, and documenting every step. In short, it embeds the law's principles into the AI project's lifecycle. This is not legal advice.

Should an AI project prefer explicit consent or legitimate interest?

It depends, and explicit consent is not an automatic first choice. Under KVKK, explicit consent is a basis used when the other processing conditions do not apply; it is approval given freely, on a specific matter, and in an informed way, always withdrawable, and it cannot be tied to a service as a precondition. Legitimate interest is used by balancing the controller's reasonable interest against the person's rights and freedoms without harming them, and it requires a documented balancing test. If special-category data is processed, explicit consent or a legal exception is required in most cases. The right basis is project-specific and should be clarified with legal counsel.

How is the duty to inform fulfilled in AI?

The duty to inform is met in two layers. The first is the classic privacy notice: the controller's identity, processing purposes, legal basis, recipients, retention period, and the data subject's rights. The second is AI-specific transparency: stating that data is processed by an AI system, that automated decisions or profiling occur if they do, and explaining the logic of that process understandably. The person should be able to reasonably understand on what basis they are evaluated. The notice is a living document; it must be updated as the system changes.

Is VERBİS registration mandatory for AI projects?

VERBİS registration is mandatory for controllers meeting certain criteria; the obligation depends on the organization's size and the nature of the data it processes. An AI project does not create the obligation directly, but it can affect the scope of an existing VERBİS declaration by increasing the volume and variety of personal data processed. A controller obliged to register must update its data-processing inventory and review its VERBİS declaration accordingly when deploying a new AI system. For current registration thresholds, consult the Authority's announcements.

How do you prepare a data-processing inventory?

The data-processing inventory is a living record showing which personal data the organization processes, for what purpose, on what basis, for how long, to whom it transfers it, and which security measures it takes. To prepare it in an AI project, first map all data sources and flows; then, for each processing activity, write the purpose, basis, data category, recipient groups, retention period, and transfer information. The critical point in AI is that data takes different forms — raw data, attributes, embeddings, model parameters, and outputs; a good inventory makes this transformation chain traceable. The inventory is also the basis of the VERBİS declaration.

When does a DPIA become necessary?

A DPIA is a systematic assessment performed when a processing activity is likely to result in a high risk to people's rights and freedoms. In an AI context, high-risk signals include large-scale personal data processing, systematic and extensive profiling, use of special-category data, automated decisions with significant effects, data of vulnerable groups, and the first-time use of a new technology. If an AI project carries even one of these, a DPIA is strongly recommended. A DPIA done early both secures compliance and improves the design by eliminating unnecessary data collection at the outset.

Is the AI provider a controller or a processor?

In most scenarios the organization is the controller and its cloud/model provider is the processor; the provider processes data on the controller's instruction and for its purposes. But if the provider uses the data for its own purposes (e.g., training its model), it may become a controller for that processing. The critical principle is that the controller's responsibility cannot be delegated to the processor. Even using a cloud AI tool, the organization remains primarily responsible for the personal data it sends. The relationship must therefore be secured with a data processing agreement and a clause explicitly regulating whether the provider may use the data for model training.

What are the most common KVKK violations and sanctions in AI projects?

The most common violations are: processing data without a valid basis; not fulfilling, or partially fulfilling, the duty to inform; out-of-purpose use; not updating the data-processing inventory and VERBİS; starting high-risk processing that requires a DPIA without assessing it; not providing human oversight and an objection path in automated decisions; and not auditing cross-border transfer. KVKK provides for administrative fines for unlawful processing, breach of the duty to inform, failure to take data security measures, and non-compliance with the VERBİS obligation. Because current fine amounts change each year with the revaluation rate, consult the KVKK Authority's current announcements for exact figures.

Where should a small business start with KVKK practice in AI projects?

A small business first lists which AI tool it uses with which personal data in a simple inventory. Then it writes the processing basis (explicit consent or legitimate interest), purpose, and retention period for each use; updates the privacy notice; and checks where its cloud/tool provider processes data and its KVKK safeguards. If there is a high-risk use (customer profiling, automated decisions), it performs a simple DPIA and checks the VERBİS obligation. These steps provide most of the compliance even without a large legal department; in unclear or high-risk situations, expert advice should be sought.

Is there a ready implementation order for KVKK in AI projects?

Yes. The practical order is: (1) map data and purpose (inventory), (2) determine and document the basis for each processing, (3) minimize the data and anonymize where possible, (4) set up the privacy notice and AI transparency, (5) perform a DPIA for high-risk processing, (6) update the VERBİS declaration, (7) sign a data processing agreement with the AI provider, (8) set up technical-administrative security and cross-border transfer safeguards, (9) define retention-destruction periods, (10) monitor, document, and update as things change. This order turns KVKK practice in AI projects into a manageable backbone and is informational only.