KVKK's public sector compliance guide and AI: applying the March 2026 guide to your project

What the KVKK public sector compliance guide is and why it governs AI projects

The Turkish data protection authority (Kişisel Verileri Koruma Kurumu, KVKK) published a 144-page compliance guide for public institutions and professional organisations with public institution status in March 2026, as KVKK Publication No. 114 (Kamu Kurum ve Kuruluşları ile Kamu Kurumu Niteliğindeki Meslek Kuruluşları için Kişisel Verilerin Korunması Kanununa Uyum Rehberi). The guide covers the obligations that Law No. 6698 (KVKK, the Turkish personal data protection law) places on public institutions under headings including core concepts, general principles, processing conditions, transfer, the duty to inform, data security, data subject rights, retention and destruction, registration with VERBİS (the controllers' registry), investigation procedures, inter-agency transfer, and exemptions.

The phrase "yapay zeka" (artificial intelligence) does not appear anywhere in the 144 pages. That does not place AI projects outside the guide's scope; the guide deliberately sets out a technology-neutral framework. The definition of processing in Article 3 of Law No. 6698 already covers automated means, and the guide describes automated processing as operations "carried out by devices with processors such as computers, telephones and watches, occurring by themselves without human intervention within the scope of algorithms prepared in advance through software or hardware features". A prompt sent to a language model and the response returned by it fall inside that definition.

The practical consequence for a public institution is that no separate or new legislation needs to be found for a system procured as "yapay zeka yazılımı kiralama" (AI software leasing) or as a service acquisition. The framework in the guide applies directly. Writing the project document, the technical specification and the compliance assessment against the guide's own chapter headings produces a structure that can be defended in an audit.

• Chapter 2: Core concepts; personal data, processing conditions, controller and processor, and the distinction between data sharing and data transfer.
• Chapter 3: Obligations of public institutions; general principles, correctly identifying the processing condition, transfer, the duty to inform, data security, data subject rights, retention and destruction, VERBİS.
• Chapter 4: Obligations during investigations; exhausting the application route, responding to the Board on time, implementing Board decisions.
• Chapter 5: Lawful data transfer between public institutions; identifying special legal provisions, the limits of protocols, proportionality, secure transfer methods.
• Chapter 6: Full and partial exemptions under Article 28 of Law No. 6698.

Controller status of the public institution and the chain of responsibility in an AI project

Public institutions are the data controllers in their AI projects, and that status cannot be delegated to an internal unit or to a contractor. The guide states this without leaving room for doubt: the controller is "not the head of department, branch manager, human resources directorate, legal counsel, strategy department, IT unit within the public institution, or the institutions and persons from whom services are procured externally, but the public institution itself". The guide adds that assigning a person, unit or team to handle work related to the Law does not make that person or unit the controller.

Affiliated and related organisations of a ministry, along with its provincial branches, are not controllers if they do not themselves determine the purposes and means of processing; the obligations are then discharged by the ministry. Even if an AI project starts as a pilot in a provincial directorate, the ministry is the party responsible for the privacy notice, the inventory record and the data subject applications.

The model provider and the contractor performing the integration are processors where they process personal data on behalf of the institution under its authority and instructions. The guide illustrates this with a public institution procuring storage services from a private company, which it classifies as a processor. Under Article 12(2) of Law No. 6698, the controller is jointly responsible with the processor for the implementation of security measures; responsibility is not transferred to the provider by contract.

Among the administrative shortcomings the guide reports as frequent in breach investigations is the following: "failure to detail matters relating to personal data security in contracts made with the processor; failure to carry out the necessary audits of the processor in order to be satisfied that personal data security is ensured". Leaving this heading blank in an AI service acquisition contract produces a direct audit finding.

• The processor contract states the purpose, scope, data categories and the boundaries of the instructions explicitly.
• It commits the provider not to process for its own purposes outside the institution's instructions, including use for model training.
• Use of sub-processors, along with their identity and country of location, is stated in the contract.
• The institution's right to audit the processor and the procedure for that audit are written into the contract.
• Return or destruction of the data on termination, and documentation of it, are regulated.
• Following another finding in the guide, avoiding the use of real individuals' personal data in test and analysis environments is reflected in the contract and the technical specification.

Lawful basis in a public sector AI project: why explicit consent is a weak foundation

Public institutions must base every AI-driven processing activity on at least one of the conditions in Article 5 of Law No. 6698. The guide notes that processing conditions are set out exhaustively in the Law and cannot be extended. The conditions that typically apply to public institutions are express provision in laws, necessity for the controller to fulfil a legal obligation, and necessity for the establishment, exercise or protection of a right.

Explicit consent is usually the wrong choice for a public institution. The guide puts it this way: "explicit consent is an exceptional legal basis to be relied on where the other processing conditions cannot be applied, and it cannot be turned into a mandatory condition of the processing activity". The guide also states that obtaining explicit consent in addition, where processing could be carried out on another condition, would constitute abuse of a right and would mislead the data subject.

The practical reason is straightforward: explicit consent can always be withdrawn. If the AI component of a citizen-facing service is tied to consent, withdrawal is expected to stop the processing. Where the institution is in fact carrying out that activity under a statutory duty, the activity will continue, which leaves the data subject with a false impression.

The legitimate interest condition also warrants caution in the public sector. The guide states that institutions should be prudent about relying on legitimate interest for activities conducted on the basis of public power, and that because institutional activities rest largely on statutory duties and administrative powers, this condition may not always constitute an appropriate legal foundation.

Where special categories of personal data are involved, the assessment is made under Article 6 of Law No. 6698 and the adequate measures set by Board Decision No. 2018/10 of 31 January 2018 apply in addition. If health, criminal conviction, biometric or trade union membership data is to be sent to a language model, that step of the project requires a separate legal assessment.

• List field by field which data category will appear in which prompt; determine the lawful basis separately for each category.
• More than one processing condition may be relied on for the same purpose; the guide gives payroll processing resting on both contract performance and legal obligation as an example.
• Where a condition other than explicit consent applies, do not also collect explicit consent; doing so creates unlawfulness.
• If no processing condition applies, the guide's position is clear: the activity is stopped and the data is securely destroyed.
• Document the identification of the processing condition; the guide describes documenting processing activities and auditing them regularly as sound practice.

Inter-agency data sharing, the limits of protocols, and cross-border transfer

A data sharing protocol signed between institutions does not on its own make the data source of an AI project lawful. The guide sets this out in two sentences: "it must not be forgotten that this protocol cannot on its own be the basis of the transfer" and "however, this protocol does not take the place of the legal ground; it only regulates the manner in which the existing legal ground is applied". According to the guide, a protocol is a guiding document on how a transfer whose lawfulness has already been established will be carried out, and on its limits.

The order therefore matters. The legal provision underpinning the transfer is identified first, for example a statutory provision or one of the processing conditions in Article 5(2) of Law No. 6698; the scope, purpose, data categories, technical and administrative security measures and the parties' responsibilities are then detailed in a protocol. A project planning to feed an AI model with data coming from another institution has to write down that legal ground before the protocol.

The distinction between internal sharing and transfer also affects the project directly. According to the guide, sharing between employees or different units within a single legal entity that holds controller status is not a transfer under Article 8 of Law No. 6698. The guide's example is a state hospital affiliated with the Ministry of Health sending patient records to the provincial health directorate. Sharing between separate legal entities, by contrast, is a transfer and Article 8 applies.

On cross-border transfer, the guide's most consequential finding bears directly on model selection: "there is currently no country, sector within a country, or international organisation in respect of which an adequacy decision has been issued". Rather than an approach based on waiting for an adequacy decision, the guide asks institutions to first examine the laws and international agreements that could form the basis of the transfer, and where no such basis exists, to rely on one of the appropriate safeguards in Article 9(4) or, where the conditions are met, on the occasional cases listed in Article 9(6).

One of the appropriate safeguards available to public institutions is an agreement that does not have the character of an international treaty, made with a foreign public institution or international organisation. This route is regulated in Article 11 of the Regulation on the Procedures and Principles for the Transfer of Personal Data Abroad (Kişisel Verilerin Yurt Dışına Aktarılmasına İlişkin Usul ve Esaslar Hakkında Yönetmelik), published in Official Gazette No. 32598 of 10 July 2024; the Board's opinion is sought during negotiation and the transfer may begin only after the Board grants permission. A public project sending personal data to a model hosted abroad cannot skip this assessment.

The guide also broadens the scope of what counts as a cross-border transfer: transferring personal data to international institutions not established in Turkey is a cross-border transfer, and transfers made to those institutions' offices located in Turkey may also be considered cross-border transfers. Contracting with the Turkish office of a foreign-headquartered provider does not by itself make the transfer domestic.

At the same time, the guide stresses that the Law is a framework that sets conditions rather than prohibiting transfer, and warns institutions: "the Law must not be interpreted as an absolute and unlimited barrier, rendering special laws ineffective". Institutions should not reject information requests categorically and systematically by simply citing non-compliance with KVKK.

• Identify the legal ground first and write the protocol second; the reverse order produces an audit finding.
• Keep the scope of the transfer proportionate; the guide asks institutions not to transfer data for possible future needs or general-purpose requests.
• Record the country in which the model is hosted as a separate field in the project's compliance document.
• Where cross-border transfer is required, work through the three tiers of Article 9 of Law No. 6698 in order and justify the outcome in writing.
• Where a scenario can be handled with a domestically hosted model, the transfer question does not arise at all; that is a design decision that can be justified in the compliance document.

Mapping the guide's headings onto the AI project: notice, inventory, retention and applications

The duty to inform is discharged at the moment data is collected in an AI flow. Under Article 10 of Law No. 6698, the controller must disclose its identity, the purpose of processing, to whom and for what purpose the data may be transferred, the method and legal ground of collection, and the rights listed in Article 11. The guide asks institutions to avoid general expressions about the purpose and to describe it in more specific terms; a phrase such as "improving service quality" does not disclose that data is being sent to a language model. The guide also reminds controllers that the burden of proving the duty was discharged rests with them.

Where data is not collected directly from the data subject, a timing rule applies. Under Article 6 of the Communiqué on the Procedures and Principles to be Followed in Fulfilling the Duty to Inform (Aydınlatma Yükümlülüğünün Yerine Getirilmesinde Uyulacak Usul ve Esaslar Hakkında Tebliğ), published in Official Gazette No. 30356 of 10 March 2018, notice is given within a reasonable period after collection, at the first contact if the data will be used to communicate with the person, and at the latest at the time of the first transfer if the data will be transferred. An AI project fed from an existing database falls under that third limb.

Inventory and VERBİS are the step projects quietly skip. According to the guide, institutions must prepare a personal data processing inventory before notifying VERBİS, and the information declared to VERBİS must be consistent with the inventory. The guide asks that the information in the inventory be taken into account when discharging the duty to inform, when responding to data subject applications, when determining the scope of explicit consent, and when setting maximum retention periods. If an AI project creates a new data category, a new recipient group or a new recording medium, the inventory must be updated.

On retention, the decisive question is which new records the project creates. The prompt text, the model response and the usage record are separate records, and a retention period must be set for each. The guide requires institutions to follow any period prescribed in legislation, and where none is prescribed, to retain data only for as long as necessary for the purpose of processing, destroying it once the purpose or the valid legal ground disappears. The periods in the retention and destruction policy must also match those declared in VERBİS.

Data subject applications connect directly to AI output. Article 11(1)(g) of Law No. 6698, as set out in the guide, grants the following right: "data subjects have the right to apply to the controller and object to a result arising against the person as a consequence of the analysis of processed personal data exclusively by automated systems". When such an application arrives, for example after a request was refused following a model-assisted preliminary assessment, the institution must be able to explain which input produced that output and through which process.

The deadlines are short and apply equally to the public sector. The guide states that the controller must review and respond to a data subject request as soon as possible and within 30 days at the latest, and that an institution receiving an application must respond even if it processes no personal data about that person. During an investigation, information and documents requested by the Board must be sent within 15 days, other than those constituting state secrets; a Board decision must be implemented without delay and within 30 days of notification at the latest. In the event of a data breach, Board Decision No. 2019/10 of 24 January 2019 requires notification to the Board without delay and within 72 hours at the latest.

The nature of the sanction also differs for public institutions. Under Article 18(4) of Law No. 6698, where unlawfulness is established within a public institution or a professional organisation with public institution status, disciplinary proceedings are brought against the civil servants and other public officials concerned upon notification by the Board, and the outcome is reported back to the Board. The result is therefore a disciplinary process concerning personnel rather than an administrative fine charged to the institution's budget.

Which headings of the guide LLMTR corresponds to

LLMTR is a gateway platform that provides access to models hosted in Turkey and to global language models through a single OpenAI-compatible API. The points below show where the platform's design decisions correspond to headings in the guide. They do not remove the institution's obligations; identifying the lawful basis, giving notice, maintaining the inventory and setting the retention policy remain the work of the institution that holds controller status.

For the retention, destruction and inventory headings, the decisive point is this: in LLMTR, user prompts and model response bodies are not written to the usage and billing database. The usage record consists of measurement fields such as token counts, model identifiers and cost. On the inventory side, the consequence is that no prompt or response body arises in the gateway's billing layer for which a retention period would need to be set. Whether the institution records those bodies in its own application layer is a separate question, and it is the institution's own decision that goes into the inventory.

The data security chapter of the guide lists the following among the technical shortcomings frequently seen in breaches reported to the Board: "failure to use secure communication protocols where personal data is shared over APIs or web services, failure to manage access keys appropriately, and deficiencies in authentication and authorisation processes". On key management, LLMTR stores customer API keys as SHA-256 hashes rather than plaintext, and provider API keys are held only in environment variables.

Another shortcoming on the same list is the absence of control mechanisms such as alerts, monitoring, or query limits and quotas in personal data query systems. In LLMTR, each unit can hold its own API key with its own rate limit, its own ceiling and its own usage report. That structure provides the gateway-side counterpart to the access authorisation matrix and query limiting the guide calls for, and unit-level usage records remain auditable without containing prompt text.

For the cross-border transfer heading, the catalogue distinction is what helps. Models hosted in Turkey and models from global providers are marked separately within the same catalogue. Where data classification means content cannot leave the country and a domestically hosted model is selected, the assessment under Article 9 of Law No. 6698 does not arise for that flow. That is a design decision that can be justified in writing in the compliance document.

The mapping table in this article can be used in the institution's compliance file alongside the platform-side counterpart of each row. Writing the measures the institution must implement in its own application layer separately from the measures the gateway provides keeps it clear, under the joint responsibility set out in Article 12(2) of Law No. 6698, who has undertaken what when an audit arrives.

Sources

The legislative references in this article were verified against the primary sources listed below. The direct quotations from the guide were checked against the full text of KVKK Publication No. 114. Last checked: 13 August 2026.

This content is informational and does not constitute legal advice.

• Kamu Kurum ve Kuruluşları ile Kamu Kurumu Niteliğindeki Meslek Kuruluşları için Kişisel Verilerin Korunması Kanununa Uyum Rehberi (Compliance guide for public institutions), KVKK Publication No. 114, March 2026, 144 pages — kvkk.gov.tr
• Law No. 6698 on the Protection of Personal Data (KVKK), Articles 3, 4, 5, 6, 8, 9, 10, 11, 12, 13, 15, 16, 18 and 28 — kvkk.gov.tr
• Kişisel Verilerin Yurt Dışına Aktarılmasına İlişkin Usul ve Esaslar Hakkında Yönetmelik (Regulation on transfer of personal data abroad), Official Gazette No. 32598 of 10 July 2024 — resmigazete.gov.tr
• Kişisel Verilerin Silinmesi, Yok Edilmesi veya Anonim Hale Getirilmesi Hakkında Yönetmelik (Regulation on deletion, destruction and anonymisation), Official Gazette No. 30224 of 28 October 2017 — resmigazete.gov.tr
• Aydınlatma Yükümlülüğünün Yerine Getirilmesinde Uyulacak Usul ve Esaslar Hakkında Tebliğ (Communiqué on the duty to inform), Official Gazette No. 30356 of 10 March 2018 — resmigazete.gov.tr
• Veri Sorumlusuna Başvuru Usul ve Esasları Hakkında Tebliğ (Communiqué on applications to the controller), Official Gazette No. 30356 of 10 March 2018 — resmigazete.gov.tr
• Personal Data Protection Board Decision No. 2019/10 of 24 January 2019, procedures and principles for data breach notification — kvkk.gov.tr
• Personal Data Protection Board Decision No. 2018/10 of 31 January 2018, adequate measures for special categories of personal data — kvkk.gov.tr
• Personal Data Protection Board Decision No. 2021/238 of 11 March 2021, VERBİS registration deadline — kvkk.gov.tr

Reviewing a public sector AI project against KVKK Publication No. 114

Six steps for applying the headings of the March 2026 public sector compliance guide to an existing or planned AI project.

1. Write down the data flow and the controller. Map step by step where data comes from and where it goes in the project. Document that the controller is the institution itself, or the parent ministry where a provincial branch is involved. Determine whether the model provider and the contractor sit in the processor role.
2. Establish a lawful basis for each data category. List the fields that will enter the prompt one by one and identify the appropriate processing condition under Article 5 of Law No. 6698 for each. Where a condition other than explicit consent applies, do not collect explicit consent. If special category data is involved, assess it separately under Article 6 and add the adequate measures from Board Decision No. 2018/10.
3. Separate out the transfer question. Determine for each sharing step whether it is internal sharing or a transfer. If data arrives from another institution, identify the legal ground before the protocol. Record the country in which the model is hosted; where a cross-border element exists, work through the tiers of Article 9 in order and justify the outcome.
4. Update the privacy notice and the proof record. Add the specific processing purpose, recipient groups, collection method and legal ground to the privacy notice, avoiding general expressions. Where data is not collected directly from the data subject, follow the timing rules in Article 6 of the Aydınlatma Tebliği (Communiqué on the duty to inform) and keep a record proving notice was given.
5. Align the inventory, the VERBİS notification and retention periods. Record the new data categories, recipient groups and recording media the project creates in the personal data processing inventory. Set separate retention periods for prompt text, model response and usage record. Verify that the periods in the retention and destruction policy match those declared in VERBİS.
6. Build the application, breach and audit flow. Define a flow that answers data subject applications within 30 days, and ensure enough traceability to explain which input produced a given output if an objection to model output arrives. Prepare a response plan for the 72-hour breach notification to the Board, and put the access authorisation matrix, query limits and access logs into operation.

Frequently asked questions

When was KVKK's compliance guide for public institutions published and what does it cover?

The Turkish data protection authority published the compliance guide for public institutions and professional organisations with public institution status as KVKK Publication No. 114 in March 2026. The guide runs to 144 pages and covers core concepts, general principles, processing conditions, transfer, the duty to inform, data security, data subject rights, retention and destruction, registration with VERBİS, investigation procedures, inter-agency transfer and exemptions.

If the guide never mentions artificial intelligence, are AI projects outside its scope?

No. The phrase "yapay zeka" (artificial intelligence) does not appear in the text, but the guide sets out a technology-neutral framework. The definition of processing in Article 3 of Law No. 6698 covers wholly or partly automated means, and the guide describes automated processing as operations occurring by themselves without human intervention within the scope of algorithms prepared in advance. A prompt sent to a language model and the response returned fall inside that definition.

Who is the controller in a public sector AI project, the IT unit or the contractor?

Neither. According to the guide, controller status in a public institution rests not with the head of department, branch manager, legal counsel, IT unit or externally procured service providers, but with the public institution itself. If a ministry's provincial branch does not determine the purposes and means of processing, the ministry discharges the obligations.

Is a language model provider a processor, and what should the contract contain?

The provider and the integration contractor are processors where they process personal data on behalf of the institution under its authority and instructions. The guide lists failure to detail personal data security in processor contracts, and failure to audit the processor, as frequent administrative shortcomings. The contract should cover the limits of instructions, security measures, sub-processors, the right to audit, and return or destruction of data on termination.

Is a data sharing protocol signed between institutions sufficient on its own for a transfer?

It is not. In the guide's words, the protocol does not take the place of the legal ground; it only regulates the manner in which the existing legal ground is applied. The legal provision underpinning the transfer, such as a statutory provision or one of the processing conditions in Article 5(2) of Law No. 6698, is identified first; the protocol then details the scope, purpose, data categories and the parties' responsibilities.

Can an institution wait for an adequacy decision before sending data to a model hosted abroad?

The guide treats that approach as a common mistake and states that there is currently no country, sector within a country, or international organisation in respect of which an adequacy decision has been issued. Instead, the laws and international agreements that could form the basis of the transfer are examined first; where no such basis exists, one of the appropriate safeguards in Article 9(4) applies, or the occasional cases in Article 9(6) where their conditions are met. Where a flow can be handled with a domestically hosted model, the question does not arise at all.

Related posts

• Can a Turkish public institution use ChatGPT or the OpenAI API? The KVKK cross-border transfer framework
• KVKK standard contracts for cross-border LLM transfers: the operational cost

• KVKK Disclosure Notice
• Security documentation
• Usage tracking
• Model catalog