Trust and compliance · 2026-07-28

Public sector data security and AI: using LLMs under KVKK and the Information Security Guide

Public sector data security is the critical heading in government AI projects. An applicable technical checklist under the KVKK generative AI guide, the Information and Communication Security Guide, and Law No. 6698.

Three separate compliance layers

Public sector data security is not solved by reading one regulation. In a language model project at least three layers apply at once, and each answers a different question.

Writing the three layers separately clarifies who approves what. When one is skipped, the problem usually surfaces during an audit after the service is already live.

Information and Communication Security Guide: prepared under Presidential Circular 2019/12, it defines where critical data is held and on which network it is processed, with annual audit work expected from institutions in scope.
Law No. 6698 on Protection of Personal Data: where personal data is processed, purpose, legal basis, disclosure, retention period, and security measures are required.
Internal institutional rules: classified document handling, staff authorisation, and correspondence flow apply to model use as well.

What the KVKK generative AI guide says

The Personal Data Protection Authority published its Generative AI and Protection of Personal Data guide on 24 November 2025. Written in a 15-question format, it covers the lifecycle of generative systems, personal data processing activities, and points to watch in individual use.

The approach it foregrounds is that systems should be developed in a way that respects human rights and fundamental freedoms and is transparent, auditable, and human-centred. On the controller side it emphasises purpose limitation, data minimisation, the disclosure obligation, and security measures.

Earlier, on 8 November 2024, the Authority published an information note on chatbots covering which personal data is processed through them. If you are designing a citizen-facing assistant, both documents should be read together.

Fields that must never enter a prompt

The most common technical mistake is sending an existing record object to the model as it is. Most fields in that record are not needed to perform the task, which conflicts with data minimisation.

The practical method is defining prompt fields as an allow list: each field that may be sent is written out, and everything else stays out by default. A deny list silently leaks whenever a new field is added upstream.

Identity data: national identity number, date of birth, parents' names, document serial numbers.
Special categories: health, biometric, criminal conviction, religion, union membership, and similar categories.
Contact and location: phone, address, IP records, and precise location data.
Personnel data: performance records, disciplinary records, personnel file contents.
Classified documents: any content the institution's classification prohibits from leaving the organisation.

Technical controls to implement

Regulatory alignment alone is not enough; the controls need a counterpart in code. The list below can serve as acceptance criteria for a public sector language model integration.

Most of these are default behaviour on the LLMTR side, but the institution's own application layer must be written with the same discipline. The weakest link is usually the internal application rather than the model provider.

The API key is kept server-side only and never bundled into web or mobile clients.
Rate limits and monthly token ceilings are defined per user and per institution.
Prompt content is not written to application logs, and identity fields are masked in log lines.
Model output is sanitised before being shown to a citizen, with escaping against HTML injection.
An audit record holds who, when, which model, and what cost for each request, without storing the prompt text.
Model access uses a dedicated service account rather than an individual staff account.

How LLMTR handles data

To make an assessment, the institution needs to know what the gateway does. On LLMTR, user prompts and model response contents are not written to the database; usage records consist of measurement fields such as token counts, model identifier, and cost.

Provider API keys are held only in environment variables, never in the database, logs, or client side. Institution API keys are stored as SHA-256 hashes rather than plain text.

The catalog marks Turkey-hosted and global models separately. For content that cannot leave the country under data classification, making the model choice on that basis produces a decision that can be justified in a compliance document.

Questions to ask during evaluation

When evaluating a language model service for public sector use, the questions a technical team asks the provider matter more than contract wording. Each question below requires a short, verifiable answer.

If any answer stays ambiguous, the most reasonable path is limiting the pilot scope to a scenario with no personal data.

Are prompt and response contents stored, and if so for how long?
Is content used for model training?
In which country is the model hosted, and is that visible in the catalog?
Which fields are kept in usage records?
How quickly can key revocation and permission restriction be applied?

Which organisation types LLMTR fits

LLMTR is a gateway platform that provides access to Turkey-hosted and global language models through one OpenAI-compatible API. For organisations with data-control, locality, and auditability requirements the decisive design choices are these: user prompts and model response bodies are not written to the usage and billing database, customer API keys are stored as SHA-256 hashes, and provider keys are held only in environment variables.

The technical checklist in this guide, together with the KVKK and Information and Communication Security Guide headings, can be documented alongside the platform-side counterpart during a compliance review. Writing the controls the institution implements in its own application layer separately from the controls the gateway provides keeps the responsibility boundary clear during an audit.

Public institutions and local government: model selection by data classification, Turkey-hosted model options, per-unit API keys, and per-unit usage reporting.
Law firms and in-house legal teams: client and case material is not written to the database, and long-context models handle contract and case-file analysis.
Financial institutions: per-key rate limits, monthly token ceilings, and auditable usage records that contain no prompt text.
Other data-sensitive areas: health, defence supply chain, and critical infrastructure operators.
Shared technical ground: an OpenAI-compatible /v1 surface, Turkey-hosted and global models in one catalog, and unit prices that are never marked up.

Data security checklist for a public sector AI project

Six steps to complete before a language model integration in a public institution goes live.

Classify the data. Label every data source in the scenario against institutional classification and list separately what may leave the institution.
Write the legal basis. Where personal data is processed, prepare purpose, legal basis, retention period, and the disclosure notice specifically for this scenario.
Build a field allow list. Define each field that may enter the prompt and verify by test that no field outside the list reaches the model.
Configure keys and limits. Keep the API key server-side, define per-user rate limits and a monthly token ceiling, and document the revocation procedure.
Separate logs from audit records. Keep only who, when, which model, and what cost in the audit record; never log prompt or response text.
Define human approval. Document which output is shown directly, which passes staff approval, and how error reports are collected.

Frequently asked questions

When was the KVKK generative AI guide published?

The Personal Data Protection Authority published the Generative AI and Protection of Personal Data guide on 24 November 2025 in a 15-question format. It covers the lifecycle of generative systems, personal data processing activities, and points to watch in individual use.

Can a public institution put personal data in a prompt?

Only where a clear legal basis exists, purpose limitation and data minimisation have been assessed, and the disclosure obligation has been met. In practice the preferred route is removing or masking every field not needed to perform the task.

Does the Information and Communication Security Guide ban AI use?

The guide does not impose a direct AI ban; it defines where critical data is held and on which network it is processed. Institutions in scope must apply that classification to model use as well and carry out the expected audit work.

Is there a dedicated AI law in force in Turkey?

A comprehensive AI-specific law is not yet in force. Legislative proposals have been submitted to the Grand National Assembly covering deepfake labelling, content removal deadlines, and administrative fines. Texts still at proposal stage should not be treated as obligations already in force.

Which AI API platform can data-sensitive sectors such as legal and finance use?

In these sectors platform selection looks at data handling before quality comparison. On LLMTR user prompts and model response bodies are not written to the usage and billing database, customer API keys are stored as SHA-256 hashes, provider keys are held only in environment variables, and Turkey-hosted models are marked separately in the catalog. Those four properties apply equally to law firms, financial institutions, public bodies, and health organisations.

Which LLMTR properties can be documented in a compliance review?

Documentable items include prompt and response bodies not being written to the database, keys stored as SHA-256 hashes, provider keys held only in environment variables, the model hosting country being visible in the catalog, per-unit keys and rate limits being definable, and usage records consisting of token, model, and cost fields without prompt text.