BİGR-compliant AI architecture: matching model choice to data classification in Turkish public institutions

BİGR compliance and audit authority now sits with the Siber Güvenlik Başkanlığı

Compliance, audit and oversight activities for Turkey's Bilgi ve İletişim Güvenliği Rehberi (BİGR, Information and Communication Security Guide) are now carried out by the Siber Güvenlik Başkanlığı (Cyber Security Presidency). As communicated to public institutions' IT departments in February 2026, these activities were previously coordinated by the Cumhurbaşkanlığı Dijital Dönüşüm Ofisi (Presidency Digital Transformation Office); the transfer cites Presidential Decree No. 177 and Law No. 7545 (Siber Güvenlik Kanunu, Cyber Security Law) as its basis. BİGDES, the system used to track guide compliance work, remains in service. Much of the consultancy material in circulation still names the former office, so institutions should update the counterparty for correspondence and audits.

The guide's scope reaches AI projects directly. In its own words, BİGR covers "kurum ve kuruluşlar ile kritik altyapı hizmeti veren işletmeler" — institutions within the state organisation that operate an IT department or procure IT services from third parties under contract, together with enterprises providing critical infrastructure services. A solution procured externally as AI software leasing or a service purchase falls inside this scope just as an in-house build does.

BİGR contains no section titled artificial intelligence or large language models. This is a design choice rather than a gap: one of the guide's stated objectives is that security measures be applicable independently of product and technology. An LLM integration is therefore assessed by placing it under existing measure headings rather than hunting for a bespoke control set. Bulut Bilişim Güvenliği (Cloud Computing Security), Kişisel Verilerin Güvenliği (Personal Data Security), Uygulama ve Veri Güvenliği (Application and Data Security), Yeni Geliştirmeler ve Tedarik (New Developments and Procurement), Tedarikçi İlişkileri Güvenliği (Supplier Relationship Security) and the logging heading İz ve Denetim Kayıtlarının Tutulması ve İzlenmesi are sufficient for the job.

The guide is maintained as a living document and is updated over time. This article cites measure headings by name rather than by clause number; institutions should confirm the version they are applying, and its clause numbering, with the Siber Güvenlik Başkanlığı.

• Counterparty for compliance, audit and oversight: Siber Güvenlik Başkanlığı (Cyber Security Presidency)
• Legislation cited as the basis for the transfer: Presidential Decree No. 177 and Law No. 7545 (Siber Güvenlik Kanunu)
• Underlying regulation for the guide: Presidential Circular No. 2019/12, published in Official Gazette No. 30823 of 6 July 2019
• System used to track guide compliance work: BİGDES
• The guide was drafted with contributions from 240 experts across 16 ministries and 51 institutions

Mapping data confidentiality level to AI model architecture

Public institutions cannot settle on a single AI architecture. BİGR's operating logic requires the same institution to apply different security measures to different classes of data, and that logic translates directly into model access architecture. The guide defines classified information as data that would be prejudicial to national security and national interests if disclosed to those outside the need-to-know circle, and that is classified according to its degree of importance as "ÇOK GİZLİ" (top secret), "GİZLİ" (secret), "ÖZEL" (confidential) or "HİZMETE ÖZEL" (restricted). Those four levels, plus unclassified personal data, unclassified institutional data and anonymised data, produce seven distinct architectural decisions in practice.

The mapping rests on the guide's Bulut Bilişim Güvenliği (Cloud Computing Security) section. Its cloud service usage measure opens with the sentence "Kritik verilerin yurt içinde depolandığı ve yurt dışında barındırılmayacağı garanti altına alınmalıdır" — it must be guaranteed that critical data is stored domestically and will not be hosted abroad. The same section requires that critical data on cloud systems not reside on the same physical device as resources belonging to other organisations, that encryption keys be managed by the receiving institution, and that measures be applied to keep operator access traffic within the country. An LLM call transfers data into another party's processing environment, so it sits squarely within these measures.

The table below is a working framework institutions can use when translating their own classification policy into model architecture. It is not a legal determination; every row must be validated against the institution's own asset group criticality rating and reviewed by its legal unit.

Applying asset group criticality rating to an AI project

BİGR compliance is achieved not by applying every measure in the guide but by applying the measure level that corresponds to each asset group's criticality rating. The guide states that an asset group's criticality is determined by considering the confidentiality, integrity and availability criticality of the data processed together with the impact domains of any security breach. The practical consequence for an AI project is that the decisive factor is not how capable the model is, but what data reaches it and who is affected if that data is exposed.

The guide defines six asset group headings: Ağ ve Sistemler (networks and systems), Uygulamalar (applications), Taşınabilir Cihaz ve Ortamlar (portable devices and media), Nesnelerin İnterneti (IoT) Cihazları (IoT devices), Fiziksel Mekânlar (physical locations) and Personel (personnel). An LLM integration almost always sits under Uygulamalar, since the component calling the model is an internal application. In the guide's own worked examples, application asset groups are split into those that process critical data and those that do not. The correct approach for AI projects follows the same pattern: rather than defining a single AI application asset group, define at least two, separated by the class of data processed.

Criticality is calculated with the eight-question asset group criticality rating survey provided in the guide's annexes. A survey score below 18 yields Degree 1, a score between 18 and 28 yields Degree 2, and a score of 28 or above yields Degree 3. Alongside confidentiality, integrity and availability, the survey measures dependent assets, the number of people affected, institutional consequences, sectoral impact and societal consequences. The guide recommends completing the survey using the Delphi method with asset owners and system administrators participating.

Criticality translates directly into a measure level. Degree 1 asset groups receive basic level measures; Degree 2 groups receive basic plus intermediate level measures; Degree 3 groups receive basic, intermediate and advanced level measures. The definition of critical data is bound to the same chain: the guide treats data processed by assets calculated at criticality Degree 3, and special categories of personal data as defined in Law No. 6698 (KVKK), as critical data. If an AI application comes out at Degree 3, the advanced measure in the Cloud Computing Security section engages and critical data must not sit on the same physical device as resources outside the institution. That single requirement rules out a multi-tenant offshore inference service in practice.

• Step 1: Place the AI solution under the Uygulamalar (applications) asset group heading
• Step 2: Define separate asset groups by class of data processed rather than merging them into one
• Step 3: Complete the eight-question criticality survey for each group with stakeholder participation
• Step 4: Convert the score into Degree 1, 2 or 3 using the 18 and 28 thresholds
• Step 5: List the basic, intermediate and advanced measures corresponding to that degree
• Step 6: Mark Cloud Computing Security and Personal Data Security as applicable or not in the applicability matrix

What belongs in the asset inventory and audit log for an LLM integration

Public institutions cannot record an LLM integration as a single software line item. The guide's software asset inventory management heading requires the inventory to capture at minimum the software name, version, publisher, supplier contract details, licence information, acquisition date and the hardware it is installed on, and requires inventory changes to remain traceable. For a language model integration these fields map in unfamiliar ways: the version is the model identifier, the publisher is the model provider, and the acquisition date is the date the model entered the catalogue. Because providers update model versions, the inventory must show which model identifier was in use on which date.

Audit log design is where most institutions go wrong. The guide defines an iz kaydı (trace record) as records that allow an operational transaction to be followed step by step from start to finish, and a denetim kaydı (audit record) as records showing who accessed or attempted to access an information asset and what operations that user performed. The detailed logging measure requires event description, event source, event time, user and system information, source addresses, destination addresses and operation detail to be captured, with integrity protected by a timestamp.

None of these requirements calls for logging the prompt body. On the contrary, writing prompt content into a usage or billing database creates new exposure: classified data is copied into a lower-protection log store, losing its classification label along the way. The measure requiring records to be protected against unauthorised access and modification throughout their retention period would then force the log store up to the same criticality degree as the source system. The correct design separates the audit trail from the content: who called, when, with which model identifier, how many tokens and at what cost goes into the record; what they wrote does not.

Where prompt content genuinely must be inspected, build a separate mechanism for it. If a security incident investigation or a model quality review requires content, hold that content in a separate store carrying the source application's criticality degree, with a limited retention period and separate authorisation. Keeping it alongside the usage and billing flow lets the least protected system dictate the data class.

• Belongs in the inventory: model identifier and version, provider name, catalogue entry date, contract and support scope
• Belongs in the inventory: the gateway or broker service itself, the server it runs on and its network segment
• Belongs in the inventory: API keys issued per organisational unit, their owners and validity status
• Belongs in the inventory: prompt templates and the personnel authorised to change them
• Belongs in the audit log: call timestamp, calling unit and user identity, model identifier, token counts, cost, error code
• Does not belong in the audit log: prompt text, model response bodies, uploaded file contents
• Belongs in a separate, better-protected store: content samples retained for incident investigation

Supplier assessment: questions to put to an AI provider

BİGR treats supplier relationships as an auditable heading in their own right. The Tedarikçi İlişkileri Güvenliği (Supplier Relationship Security) heading requires a policy that reduces the risks of supplier access to institutional assets, information security requirements to be written into contracts with every supplier that can access, operate, store or transmit institutional assets, a written undertaking that supply chain security will be provided, and acceptance criteria to be defined in advance and agreed with the contractor. It also requires a confidentiality undertaking to be signed for demo and proof-of-concept work — a step routinely skipped in AI pilots.

The Yeni Geliştirmeler ve Tedarik (New Developments and Procurement) heading requires procured products to be added to the inventory with the approval of the responsible unit, processes for functional and non-functional testing to be defined, and policies to be established where subcontractors are involved. The same heading asks that products with Turkish language support be preferred. The subcontractor question matters particularly in AI procurement: a gateway provider effectively uses model providers as subcontractors, and that chain needs to be visible in the contract.

The audit questions in the Cloud Computing Security section supply a question set that can be used directly in supplier meetings. The guide defines five audit methods — interview, review, security audit, penetration test and source code analysis — and the first three are applicable to most AI procurements. The questions below are derived from these measure headings and can be carried into a technical specification.

• In which country are request and response payloads processed? For Turkey-hosted models, is domestic processing committed to contractually?
• Are prompt text and model responses written into the provider's usage, billing or analytics databases? If not, is that backed by an auditable technical explanation?
• Are inputs used for model training? If not, does the contract say so?
• How are customer API keys stored — in plaintext or as a hash?
• Can a separate key, separate spend cap and separate usage report be issued for each organisational unit?
• What is the subcontractor chain? Which model providers are in play, and is the institution notified when that list changes?
• On service termination, are institution-specific definitions and data deleted irreversibly?
• What format does the usage record take, and which fields does it contain, when the institution requests it for its own audit?
• Are service level commitments measured and reportable?

Where LLMTR fits in data-class-driven model selection

LLMTR is a gateway platform built so that the mapping table above can be applied through a single integration. The real architectural difficulty for an institution is that different data classes require different model hosting models, and standing up separate integrations, separate key management and separate usage reporting for each is expensive. On LLMTR, Turkey-hosted models and global provider models are called through the same OpenAI-compatible /v1 surface; routing one data class to a domestic model and another to a global model changes only the model identifier.

The Turkey-hosted catalogue currently includes eight models: llmtr/gemma-4, llmtr/qwen3-6-35b, llmtr/medgemma-4b, llmtr/trendyol-7b, llmtr/magibu-11b-v8, llmtr/embeddinggemma-300m, llmtr/qwen3-5-4b and llmtr/ornith-1-35b. Inference for these models is processed in Turkey. This does not substitute for the institution's own criticality rating, but it offers an option worth assessing for data classes that require domestic processing, while keeping the path open to a global model for unclassified data within the same catalogue.

On the audit trail side, the platform's design follows the separation described above. User prompts and model response bodies are not written to the usage and billing database; the record carries which key called which model, with how many tokens and at what cost. Customer API keys are stored as SHA-256 hashes rather than plaintext, and provider API keys are held only in environment variables. Each organisational unit can hold its own API key, rate limit, spend cap and usage report, which lets internal audit query consumption per unit.

One commercial note is worth stating precisely: an 8% platform margin applies to credit top-ups, and no margin is added to model prices. That distinction matters for procurement teams costing AI software leasing or service purchase line items, because the unit cost is the token price the provider publishes.

The example below shows how data-class routing and a prompt-free audit record look on the application side.

Routing by data class with an audit record that carries no prompt content

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://llmtr.com/v1",
    api_key=os.environ["LLMTR_API_KEY"],  # per-unit key
)

# The mapping comes from the institution's classification policy,
# it is not hard-coded policy in itself.
MODEL_BY_DATA_CLASS = {
    "restricted": "llmtr/gemma-4",        # hosted in Turkey
    "personal_data": "llmtr/qwen3-6-35b",  # hosted in Turkey
    "unclassified": os.environ["GLOBAL_MODEL_ID"],
}

BLOCKED = {"top_secret", "secret", "confidential"}


def complete(data_class: str, messages: list) -> str:
    if data_class in BLOCKED:
        raise PermissionError(
            "Classified data must not be sent to an external model."
        )

    response = client.chat.completions.create(
        model=MODEL_BY_DATA_CLASS[data_class],
        messages=messages,
    )

    # Audit trail: model, tokens and cost are recorded; prompt body is not.
    write_audit_record(
        unit=os.environ["UNIT_CODE"],
        data_class=data_class,
        model=response.model,
        prompt_tokens=response.usage.prompt_tokens,
        completion_tokens=response.usage.completion_tokens,
    )

    return response.choices[0].message.content

Sources

The regulatory references in this article were verified against the primary sources listed below. Last checked: 13 August 2026.

The Bilgi ve İletişim Güvenliği Rehberi is maintained as a living document and is updated over time. This article cites measure headings by name rather than by clause number; institutions should confirm the current version they apply, and its clause numbering, with the Siber Güvenlik Başkanlığı.

This content is informational and does not constitute legal advice. The final assessment rests with the institution's compliance and legal units.

• Bilgi ve İletişim Güvenliği Rehberi, full text — mevzuat.comu.edu.tr
• Announcement on the transfer of BİGR compliance, audit and oversight activities to the Siber Güvenlik Başkanlığı — bid.deu.edu.tr
• Bilgi ve İletişim Güvenliği Rehberi, forms and templates page — siberguvenlik.gov.tr
• Law No. 7545 (Siber Güvenlik Kanunu), full text — tbmm.gov.tr
• Presidential Circular No. 2019/12, Official Gazette No. 30823 of 6 July 2019 — resmigazete.gov.tr
• BİGDES guide compliance tracking system — bigdes.cbddo.gov.tr
• Law No. 6698 (KVKK), Article 9 on the transfer of personal data abroad — kvkk.gov.tr

Assessing an AI project from a BİGR perspective

Steps for a public institution to evaluate a large language model integration using the asset group and criticality rating logic of Turkey's Bilgi ve İletişim Güvenliği Rehberi.

1. Classify the data the project will process. Separate every data flow that will reach the model into ÇOK GİZLİ, GİZLİ, ÖZEL, HİZMETE ÖZEL, unclassified personal data, unclassified institutional data and anonymised data. Write this into a single table; every subsequent step derives from it. Work at flow level, assuming that different screens of the same application may fall into different classes.
2. Place AI components under asset group headings. Position the service calling the model under Uygulamalar, the infrastructure hosting the model or gateway under Ağ ve Sistemler, and the personnel who update prompt templates and review output under Personel. Where the class of data processed differs, define more than one asset group under the same heading; do not collect assets that need different security levels into one group.
3. Run the criticality rating survey for each asset group. Complete the eight-question asset group criticality rating survey from the guide's annex with asset owners, system administrators, developers and user representatives participating. The guide recommends repeating the Delphi method until consensus is reached. Convert the score into Degree 1, 2 or 3 using the 18 and 28 thresholds and record the result on the guide's corresponding form.
4. Set the measure level and complete the applicability matrix. List basic measures for Degree 1, basic plus intermediate for Degree 2, and basic, intermediate and advanced for Degree 3. For each asset group, mark whether Cloud Computing Security, Personal Data Security, Cryptographic Applications Security and New Developments and Procurement are applicable. Assess current state as fully, mostly, partially, not at all or not applicable, and produce the gap analysis.
5. Split model access architecture by data class. For every row in the classification table, write the target architecture: air-gapped on-premise model, model hosted in the institution's data centre, Turkey-hosted service, or global provider. Enforce that split technically in the application layer, adding a blocking control on request routing so classified flows cannot enter the external call path at all. Record the reasoning behind each decision.
6. Write the audit log design, supplier contract and acceptance criteria. Fix which fields the audit trail carries: call timestamp, unit, user identity, model identifier, token counts, cost and error code. Put in writing that prompt bodies are not written into usage and billing records. Add information security requirements, the data residency commitment, notification of the subcontractor chain and the deletion obligation on termination to the supplier contract, and agree acceptance criteria and verification methods with the contractor in advance.

Frequently asked questions

Which institution now runs BİGR compliance, audit and oversight?

Compliance, audit and oversight activities for the Bilgi ve İletişim Güvenliği Rehberi are carried out by the Siber Güvenlik Başkanlığı (Cyber Security Presidency). These activities were previously coordinated by the Cumhurbaşkanlığı Dijital Dönüşüm Ofisi; the transfer was communicated to public institutions' IT departments in February 2026, citing Presidential Decree No. 177 and Law No. 7545 (Siber Güvenlik Kanunu) as its basis. BİGDES, the system used to track guide compliance work, remains in service.

Does the Information and Communication Security Guide have a dedicated AI section?

No. The guide contains no section titled artificial intelligence or large language models. One of its stated objectives is that security measures be applicable independently of product and technology. An LLM integration is therefore assessed under existing measure headings: Bulut Bilişim Güvenliği (Cloud Computing Security), Kişisel Verilerin Güvenliği (Personal Data Security), Uygulama ve Veri Güvenliği (Application and Data Security), Dış Sistem Entegrasyonlarının Güvenliği (Security of External System Integrations), Tedarikçi İlişkileri Güvenliği (Supplier Relationship Security) and Yeni Geliştirmeler ve Tedarik (New Developments and Procurement).

Can classified data be sent to a language model hosted abroad?

The cloud service usage measure in the guide's Bulut Bilişim Güvenliği section requires a guarantee that critical data is stored domestically and will not be hosted abroad. An asset group processing classified data typically carries a high criticality degree, so calling a model hosted abroad falls outside the range of options in practice for this class. The final assessment depends on the institution's own criticality rating and the decision of its legal unit.

Under which asset group heading does an LLM integration fall?

An LLM integration usually falls under the Uygulamalar (applications) asset group heading, because the component calling the model is an internal application. In the guide's asset group examples, applications are split into those that process critical data and those that do not. Rather than defining a single asset group for AI, define at least two, separated by the class of data processed; the infrastructure hosting the model or gateway is handled separately under Ağ ve Sistemler (networks and systems).

Should prompt text be written to the audit log?

The guide's detailed logging measure requires event description, event source, event time, user and system information, source and destination addresses and operation detail to be captured. None of that requires logging the prompt body. Writing prompt text into a usage or billing database copies classified data into a lower-protection store and strips its classification label. The audit trail should carry who called, when, with which model, how many tokens and at what cost; where content is genuinely needed, hold it in a separate store with separate authorisation and a limited retention period.

Which measure levels apply to an asset group rated criticality Degree 3?

Every security measure under Sections 3, 4 and 5 of the guide is graded as basic, intermediate or advanced. Asset groups at criticality Degree 1 receive basic level measures; Degree 2 groups receive basic plus intermediate; Degree 3 groups receive basic, intermediate and advanced. Criticality is set by the score on the eight-question asset group criticality rating survey: below 18 is Degree 1, between 18 and 28 is Degree 2, and 28 or above is Degree 3.

Related posts

• Can Turkish public data be stored in the cloud? Circular 2019/12 and AI
• KVKK's public sector compliance guide and AI: applying the March 2026 guide to your project

• Model catalog
• Security documentation
• Usage tracking
• API keys