Kurum içi yapay zeka asistanı nasıl kurulur? Kamu kurumları için mimari kararlar

Kurum içi yapay zeka asistanı nedir ve kamu kurumu hangi kararı verir?

Kurum içi yapay zeka asistanı, bir kurumun yalnızca kendi personeline açtığı, kurumun kendi belge ve verileriyle çalışan soru-cevap arayüzüdür. Kamu kurumları için buradaki asıl karar model seçimi değildir; verinin nerede işleneceği, hangi işin asistana devredileceği ve çıktının kim tarafından onaylanacağıdır. Bu üç karar, kurulumun maliyetini ve hukuki yükünü model tercihinden çok daha fazla belirler.

Türkiye'de bu yaklaşımın devlet tarafında doğrulanabilir bir emsali vardır. Cumhurbaşkanlığı İletişim Başkanlığı, 13 Haziran 2026 tarihli açıklamasında personeline yönelik kapalı devre yapay zeka platformu CibGPT'yi duyurdu. Başkanlığın kendi açıklamasına göre kurum, kendi GPU sunucuları ve altyapısıyla bağımsız bir yapay zeka mimarisi kurmuş, internete kapalı yerli LLM ve VLM modellerini kuruma özel ince ayarlarla devreye almıştır. Aynı açıklamada, yazılım süreçlerini hızlandıran kodlama ajanı İlgen ve eski sistemlerle doğal dilde konuşmayı sağlayan ULAK da yer aldı.

Açıklamada, dönüşümün kamu kurumlarına entegrasyon rehberleri gönderilerek devlet geneline taşındığı da belirtilmiştir. Bu ifade, her kurumun aynı mimariyi kurması gerektiği anlamına gelmez. Mimari kararın hukuki çerçevesini, 6 Temmuz 2019 tarihli ve 30823 sayılı Resmî Gazete'de yayımlanan 2019/12 sayılı Cumhurbaşkanlığı Genelgesi çizer. Genelge'nin 3. maddesi şu hükmü içerir: “Kamu kurum ve kuruluşlarına ait veriler, kurumların kendi özel sistemleri veya kurum kontrolündeki yerli hizmet sağlayıcılar hariç bulut depolama hizmetlerinde saklanmayacaktır.”

Genelge, kritik veri ile diğer veriyi birbirinden ayırır. Genelge'nin 2. maddesine göre “Kamu kurum ve kuruluşlarında yer alan kritik veriler, internete kapalı ve fiziksel güvenliği sağlanmış bir ortamda bulunan güvenli bir ağda tutulacak, bu ağda kullanılacak cihazlara erişim kontrollü olarak sağlanacak ve log kayıtları değiştirilmeye karşı önlem alınarak saklanacaktır.” Bu ayrım mimari kararın da temelidir: nüfus veya sağlık kaydı işleyen bir iş yükü ile birim yazışması taslağı hazırlayan bir iş yükü aynı altyapıyı gerektirmez.

• Karar 1 — Veri nerede işlenecek: kurumun kendi ağı, Türkiye'de barındırılan bir hizmet, yoksa yurt dışı bir sağlayıcı.
• Karar 2 — Asistan hangi işi yapacak ve hangi işi yapmayacak: kapsam yazılı olarak sınırlanmalıdır.
• Karar 3 — Çıktı kim tarafından onaylanacak: doğrudan kullanılabilecek çıktı ile onaydan geçmesi gereken çıktı ayrılmalıdır.
• Karar 4 — Kim neye sorabilecek: mevcut yetki matrisi asistan üzerinde de korunmalıdır.
• Bu kararlar alınmadan yapılan donanım veya hizmet alımı, kullanılmayan kapasiteye ödeme yapılmasıyla sonuçlanır.

Üç mimari seçeneği: kendi GPU altyapısı, Türkiye'de barındırılan API, global API

Kamu kurumları kurum içi yapay zeka asistanı için pratikte üç mimariden birini seçer. Her kurumun kendi GPU sunucusunu alması gerekmez ve çoğu kurum için bu seçenek ekonomik olarak savunulabilir değildir. Doğru seçim; kurumun işleyeceği verinin kritiklik düzeyine, kullanım hacminin sürekliliğine ve kurumda kalıcı teknik kadro bulunup bulunmadığına bağlıdır.

Kendi GPU altyapısının ekonomisi tamamen kullanım hacmine bağlıdır. Donanım maliyeti sabittir ve sistem boşta dururken de devam eder; API maliyeti ise yalnızca kullanımla birlikte artar. Sürekli ve yüksek hacimli kullanımda kendi altyapı istek başına ucuzlar; düşük veya dalgalı kullanımda atıl kapasite maliyeti API modelinin toplam maliyetini aşar. Bu kırılma noktasını genel bir kural olarak vermek yanıltıcı olur; kurumun kendi tahmini günlük istek sayısı ve ortalama istek uzunluğu üzerinden hesaplaması gerekir.

Kendi altyapının, API ile ikame edilemeyen üç gerçek avantajı vardır. Birincisi internete kapalı çalışma: Genelge'nin kritik veri için tarif ettiği “internete kapalı ve fiziksel güvenliği sağlanmış bir ortamda bulunan güvenli bir ağ” koşulunu birebir karşılayan tek seçenek budur. İkincisi kuruma özel ince ayar: model ağırlıklarına kurum verisiyle müdahale etmek, ancak modeli kendiniz işletirken mümkündür. Üçüncüsü sağlayıcı bağımsızlığı: harici bir sağlayıcının fiyat, kota veya model emekliliği kararı kurumun hizmet sürekliliğini etkilemez. Kritik veri işleyen ve kalıcı teknik kadrosu olan bir kurum için bu üç başlık, API modelinin maliyet avantajından daha ağır basabilir.

Kurumların çoğu için makul yol, tek bir mimariye baştan bağlanmak değildir. Kritik olmayan bir iş yükünde API üzerinden pilot yapmak, kapsamı ve gerçek kullanım hacmini ölçmek, kendi altyapı yatırımına bu ölçüme dayanarak karar vermek; donanımı önce alıp sonra ona iş aramaktan daha az risklidir. OpenAI uyumlu bir arayüz kullanıldığında bu geçiş uygulama kodunu değiştirmez, yalnızca yapılandırma değişir.

Kapsam belirleme: asistanın yapacağı işler ve yapmayacağı işler

Kurum içi yapay zeka asistanı projelerinin en sık atlanan adımı, asistanın hangi işi yapmayacağının yazılı olarak belirlenmesidir. Kapsamı tanımlanmamış bir asistan personel tarafından her işe sürülür ve ilk hatalı çıktıda tüm projenin güvenilirliği kaybolur. Kapsam teknik değil idari bir karardır; ilgili birim amirleri ile hukuk müşavirliğinin birlikte onaylaması gerekir.

Kişisel Verileri Koruma Kurumu'nun 5 Mart 2026 tarihinde yayımladığı “İş Yerlerinde Üretken Yapay Zekâ Araçlarının Kullanımı” rehberi, çıktıya güven konusunda net bir çerçeve çizer. Rehberde şu ifade yer alır: “ÜYZ araçları tarafından üretilen çıktılara nihai kararların dayanağı olarak yaklaşılmaması, bu çıktıların insan denetimi ve değerlendirmesi altında, destekleyici unsurlar olarak ele alınması önem taşımaktadır.” Rehber ayrıca, otomatik çıktıların sorgulanmadan doğru kabul edilmesini “otomasyon ön yargısı” olarak tanımlar.

Kapsam belgesi iki listeden oluşmalıdır. Birinci liste asistanın destekleyeceği işleri, ikinci liste asistanın girdi olarak dahi görmeyeceği işleri sayar. İkinci liste birincisinden daha önemlidir, çünkü personelin tereddüde düştüğü anda başvuracağı tek kaynak odur.

• Asistanın destekleyebileceği işler: mevzuat ve yönerge içinde arama, birim yazışması taslağı, toplantı notu özeti, rapor taslağı, kurum belgelerinin özetlenmesi, terminoloji ve çeviri desteği, sık sorulan personel sorularının yanıtlanması.
• Asistanın yapmayacağı işler: nihai idari işlem metni üretmek, disiplin veya personel değerlendirmesi hakkında görüş vermek, ihale değerlendirme kararı önermek, hukuki mütalaa yerine geçecek metin üretmek, vatandaşa doğrudan onaysız yanıt göndermek.
• Asistana girdi olarak verilmeyecek bilgiler: kapsam dışı bırakılan mimarilerde sağlık verisi, biyometrik veri, soruşturma dosyası, gizlilik dereceli belge ve henüz kamuya açılmamış ihale bilgisi.
• Kapsam belgesi bir sürüm numarası ve yürürlük tarihi taşımalı, kapsam genişlediğinde yeniden onaydan geçmelidir.
• Kapsam dışı bir soru geldiğinde asistanın vereceği yanıt önceden yazılmalıdır; sistem mesajında bu davranış tanımlanır.

Kurum bilgisiyle besleme (RAG) ve birim bazlı erişim ayrımı

Kurum içi yapay zeka asistanının değeri, bağlandığı kurum belgelerinin kalitesinden gelir. Modelin genel bilgisi kurumun kendi yönergesini, tarifesini veya iç genelgesini bilmez; bu bilgiyi asistana taşıyan katman, erişimli üretim (RAG) katmanıdır. Bu katmanın kurulmasında asıl iş model tarafında değil, onaylı kaynak setinin derlenmesi ve bir birime sahiplendirilmesindedir. Uygulamada projelerin çoğu, model kalitesinden değil, kaynak setinin güncelliğini kimsenin üstlenmemesinden başarısız olur.

Onaylı kaynak setinde her belgenin üç bilgisi bulunmalıdır: sürümü, yürürlük tarihi ve sahibi olan birim. Mülga bir yönerge kaynak setinde kaldığı sürece asistan onu geçerliymiş gibi kullanır ve hata modelin değil, veri yönetiminin hatası olur. Yanıtın dayandığı belgenin adını ve yürürlük tarihini göstermesi, personelin doğrulama yapabilmesi için asgari koşuldur.

Erişim ayrımı, kaynak setinden ayrı ve ondan daha kritik bir kontroldür. Personel özlük dosyası, soruşturma evrakı veya ihale ön yeterlik belgesi kurum içinde de herkese açık değildir; asistan bu ayrımı korumazsa mevcut yetki matrisini fiilen ortadan kaldırır. Pratikte her birim için ayrı bir indeks ve ayrı bir API anahtarı tanımlanır, sorgu kullanıcının bağlı olduğu birimin indeksine yönlendirilir ve yetkisiz kapsamdan yanıt üretilmez.

Bu kontrollerin hukuki dayanağı 6698 sayılı Kişisel Verilerin Korunması Kanunu'nun 12. maddesidir: “Veri sorumlusu; a) Kişisel verilerin hukuka aykırı olarak işlenmesini önlemek, b) Kişisel verilere hukuka aykırı olarak erişilmesini önlemek, c) Kişisel verilerin muhafazasını sağlamak, amacıyla uygun güvenlik düzeyini temin etmeye yönelik gerekli her türlü teknik ve idari tedbirleri almak zorundadır.” Asistan, kurumun mevcut yetki matrisini uygulayan bir arayüz olarak kurgulanmalıdır, onu delen bir kısayol olarak değil.

• Kaynak setini tek bir birim sahiplenir; güncelleme sorumlusu ve güncelleme sıklığı yazılı olur.
• Her belge sürüm numarası, yürürlük tarihi ve sahip birim bilgisiyle indekslenir; mülga belgeler setten çıkarılır.
• Asistan yanıtın dayandığı belgeyi ve yürürlük tarihini gösterir; kaynak setinde karşılığı yoksa bulunamadığını söyler.
• Her birim için ayrı indeks ve ayrı API anahtarı tanımlanır; sorgular kullanıcının birimine göre yönlendirilir.
• Anahtar bazında kullanım tavanı ve hız sınırı belirlenir; birim bazlı kullanım raporu düzenli incelenir.
• Sorgu ve erişim kayıtları denetim izi olarak saklanır; kimin hangi kapsama eriştiği sonradan gösterilebilir olur.

İnsan onayı, kullanım politikası, personel eğitimi ve ölçüm

Kurum içi yapay zeka asistanı devreye alındıktan sonra kurumun yazması gereken ilk belge kullanım politikasıdır. Kişisel Verileri Koruma Kurumu'nun 5 Mart 2026 tarihli rehberi, bu politikanın içeriğini ayrıntılı biçimde tarif eder ve yasaklayıcı yaklaşımı önermez. Rehberde şu değerlendirme yer alır: “Zira yasaklayıcı yaklaşımlar, çalışanların ÜYZ araçlarını kurumsal kontrol ve görünürlük dışında kullanmasına zemin hazırlayarak kontrol dışı kullanım biçimlerini teşvik edebilecektir.”

Rehber bu duruma “Gölge YZ” adını verir: “Gölge YZ (Shadow AI); kurum veya kuruluş bünyesinde ÜYZ araçlarının, söz konusu kurum veya kuruluşun bilgisi, onayı veya kurumsal kontrolü dışında çalışanlar tarafından iş süreçlerinde kullanılması durumunu ifade etmektedir.” Kurum içi asistan kurmanın en güçlü gerekçelerinden biri budur: personel zaten üretken yapay zeka kullanıyorsa ve kurumun sunduğu kontrollü bir alternatif yoksa, bu kullanım kurumun görünürlüğü dışında sürer. Rehber ayrıca çalışanların yalnızca kurum tarafından belirlenmiş ve kullanım koşulları tanımlanmış araçlara erişebilmesini, erişimin görev ve ihtiyaç temelli ele alınmasını önerir.

Onay akışı ikiye ayrılır. Kurum içinde kalan ve idari sonuç doğurmayan çıktılar, personelin kendi kontrolüyle doğrudan kullanılabilir. Kurum dışına çıkan, imza gerektiren veya idari işlem niteliği taşıyan çıktılar ise yetkili amirin onayından geçmeden kullanılamaz. Bu ayrımın kullanım politikasında açıkça yazılması, personelin her çıktı için ayrı karar vermesini gereksiz kılar.

Ölçüm olmadan kapsam genişletme kararı verilemez. Kurum, asistanın gerçekten hangi işte kullanıldığını ve nerede yanıldığını görmeden ne ek bütçe talep edebilir ne de kapsamı daraltabilir. Rehber, çalışanların deneyimlerini ve karşılaştıkları sorunları paylaşabilecekleri geri bildirim mekanizmalarının kurulmasını da bu nedenle önerir. Kurum, ayrıca Kurumun “Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi (15 Soruda)” başlıklı çalışmasını da dikkate alabilir; 5 Mart 2026 tarihli rehber bu belgeye açıkça atıf yapmaktadır.

• Kullanım politikası; kullanılabilecek araçları, izin verilen amaçları, girdi olarak verilebilecek bilgi türlerini ve çıktının kullanım esaslarını sayar.
• Politika kurum içinde duyurulur, personelin kolayca erişebileceği yerde tutulur ve güncellemeler zamanında bildirilir.
• Personel eğitimi asistanın nasıl kullanılacağını değil, çıktının nasıl doğrulanacağını ve hangi bilginin girilmeyeceğini öğretir.
• Ölçülecek asgari veriler: haftalık aktif kullanıcı sayısı, birim bazlı sorgu sayısı, kaynakta bulunamadı yanıtı oranı, hatalı yanıt bildirimi sayısı ve ortalama yanıt süresi.
• Hata bildirim kanalı asistanın kendi arayüzünde bulunur; bildirilen her hata kaynak seti sahibine yönlendirilir.
• Kapsam genişletme kararı, üç aylık kullanım ve hata verisi incelenmeden alınmaz.

LLMTR bu kurulumun neresine karşılık veriyor?

LLMTR, kurum içi yapay zeka asistanının yalnızca model erişim katmanını sağlar; kapsam belirleme, onaylı kaynak seti ve onay akışı kurumun kendi kararı ve sorumluluğudur. Platform, OpenAI uyumlu tek bir /v1 yüzeyi üzerinden hem Türkiye'de barındırılan modelleri hem global sağlayıcıları aynı katalogdan çağırır. Bu yapı, yukarıdaki üç mimari arasındaki geçişi uygulama kodu değişikliği olmaktan çıkarıp yapılandırma seviyesine indirir.

Bu yazının dördüncü bölümünde tarif edilen birim bazlı erişim ayrımı, platform tarafında doğrudan karşılığı olan tek maddedir: her birim ayrı bir API anahtarı, kendi hız sınırı, kendi harcama tavanı ve kendi kullanım raporunu alabilir. Kullanıcı promptları ve model yanıt gövdeleri kullanım ve faturalama veritabanına yazılmaz. Müşteri API anahtarları düz metin olarak tutulmaz, SHA-256 hash olarak saklanır. Kredi yüklemede %8 platform marjı uygulanır; model fiyatlarına marj eklenmez.

LLMTR, kendi GPU altyapısının yerini tutmaz ve bunu iddia etmez. Kritik verinin internete kapalı bir ağda işlenmesi gereken senaryolarda kurumun kendi donanımı üzerinde çalışan bir kurulum gerekir; bu senaryoda LLMTR yalnızca kritik sayılmayan iş yükleri için tamamlayıcı bir katman olarak kalır. Kurumun hangi verisinin kritik sayılacağı ve hangi sağlayıcının hangi iş yükü için uygun olduğu, kurumun kendi bilgi güvenliği ve hukuk birimlerinin değerlendirmesidir.

Aşağıdaki örnek, OpenAI uyumlu bir istemciyle kurum asistanının model çağrısını gösterir. Mimari kararı iki satırda toplanır: base URL ve model kimliği. Kurum ileride kendi altyapısına geçmeye karar verirse base URL kendi uç noktasına çevrilir, uygulama kodunun geri kalanı aynı kalır. Satın alma tarafında bu iş genellikle yapay zeka yazılımı kiralama veya hizmet alımı olarak tanımlanır; teknik tarafta karşılığı budur.

• Türkiye'de barındırılan model kimlikleri katalogda doğrudan çağrılabilir: llmtr/gemma-4, llmtr/qwen3-6-35b, llmtr/ornith-1-35b ve katalogdaki diğerleri.
• Her birim için ayrı API anahtarı, hız sınırı, harcama tavanı ve kullanım raporu tanımlanabilir.
• Kullanıcı promptları ve model yanıt gövdeleri kullanım ve faturalama veritabanına yazılmaz.
• Müşteri API anahtarları SHA-256 hash olarak saklanır, düz metin tutulmaz.
• Kredi yüklemede %8 platform marjı vardır; model fiyatlarına marj eklenmez.
• OpenAI uyumlu /v1 yüzeyi sayesinde kendi altyapıya geçiş base URL değişimiyle sınırlı kalır.

Kurum içi asistanın model çağrısı: mimari değişse de yalnızca base URL ve model kimliği değişir

import os
from openai import OpenAI

# Mimari karari bu iki satirda toplanir: base URL ve model kimligi.
client = OpenAI(
    api_key=os.environ["KURUM_LLM_ANAHTARI"],  # anahtar koda gomulmez
    base_url="https://llmtr.com/v1"            # kendi altyapiya geciste bu adres degisir
)

SISTEM = (
    "Bir kamu kurumunun ic asistanisin. "
    "Yalnizca sana verilen onayli kurum kaynaklarina dayanarak yanit ver. "
    "Kaynakta karsiligi yoksa 'kurum kaynaklarinda bulunamadi' de, tahmin yurutme. "
    "Yanitin sonunda dayandigin belgenin adini ve yururluk tarihini yaz."
)


def kuruma_sor(soru: str, onayli_kaynaklar: str,
               model: str = "llmtr/gemma-4") -> str:
    yanit = client.chat.completions.create(
        model=model,
        messages=[
            {"role": "system", "content": SISTEM},
            {"role": "user", "content":
                f"Onayli kaynaklar:\n{onayli_kaynaklar}\n\nSoru: {soru}"}
        ],
        temperature=0.2
    )
    return yanit.choices[0].message.content


# Model degisimi tek satirdir; uygulama kodunun geri kalani ayni kalir.
# kuruma_sor(soru, kaynaklar, model="llmtr/qwen3-6-35b")
# kuruma_sor(soru, kaynaklar, model="llmtr/ornith-1-35b")

Kaynaklar

Bu yazıdaki mevzuat referansları aşağıdaki birincil kaynaklardan doğrulanmıştır. Son kontrol: 13 Ağustos 2026.

Bu içerik bilgilendirme amaçlıdır, hukuki görüş niteliği taşımaz. Nihai değerlendirme kurumun uyum ve hukuk birimlerinin kararıdır.

• 6698 sayılı Kişisel Verilerin Korunması Kanunu madde 12 — mevzuat.gov.tr
• İş Yerlerinde Üretken Yapay Zekâ Araçlarının Kullanımı rehberi, 5 Mart 2026 — kvkk.gov.tr
• 2019/12 sayılı Cumhurbaşkanlığı Bilgi ve İletişim Güvenliği Tedbirleri Genelgesi, 6 Temmuz 2019 tarihli ve 30823 sayılı Resmî Gazete — resmigazete.gov.tr
• İletişim Başkanı Burhanettin Duran'ın Başkanlığın yapay zekâ girişimlerine ilişkin 13 Haziran 2026 tarihli açıklaması — iletisim.gov.tr
• Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi (15 Soruda) — kvkk.gov.tr

Kamu kurumunda kurum içi yapay zeka asistanı kurma adımları

Bir kamu kurumunun kendi personeline yönelik yapay zeka asistanını kapsam belirlemeden ölçüme kadar kurma adımları.

1. Kapsamı ve dışlanan işleri yazılı olarak belirleyin. Asistanın destekleyeceği işleri ve kesinlikle yapmayacağı işleri iki ayrı liste hâlinde yazın. Listeyi ilgili birim amirleri ile hukuk müşavirliğine onaylatın. Belgeye sürüm numarası ve yürürlük tarihi ekleyin; kapsam genişlediğinde belge yeniden onaydan geçsin.
2. Veri sınıflandırması yapın ve mimariyi seçin. Asistanın dokunacağı veriyi kritik ve kritik olmayan diye ayırın. 2019/12 sayılı Genelge kritik veriyi internete kapalı güvenli bir ağda tutma yükümlülüğü getirir. Kritik veri içeren iş yükü için kendi altyapı, diğerleri için Türkiye'de barındırılan bir model üzerinden API seçeneğini değerlendirin. Tahmini günlük istek sayısını çıkarmadan donanım almayın.
3. Onaylı kurum kaynak setini derleyin ve sahiplendirin. Yönerge, genelge, tarife ve sık sorulan soru belgelerini tek bir sette toplayın. Her belgeye sürüm, yürürlük tarihi ve sahip birim bilgisini ekleyin. Mülga belgeleri setten çıkarın. Kaynak setinin güncellenmesinden sorumlu birimi ve güncelleme sıklığını yazılı olarak belirleyin.
4. Pilot birimde kurulumu yapın ve erişim ayrımını tanımlayın. Tek bir birimle başlayın. Her birim için ayrı indeks ve ayrı API anahtarı tanımlayın, anahtar bazında hız sınırı ve harcama tavanı belirleyin. Sistem mesajında asistanın yalnızca onaylı kaynaklara dayanmasını, kaynakta karşılığı olmayan soruda bulunamadığını söylemesini ve dayandığı belgeyi göstermesini şart koşun.
5. Kullanım politikasını yayımlayın ve personeli eğitin. Kullanılabilecek araçları, izin verilen amaçları, girdi olarak verilebilecek bilgi türlerini ve hangi çıktının onaydan geçeceğini politikada yazın. Politikayı kurum içinde duyurun ve erişilebilir tutun. Eğitimde asistanın kullanımını değil, çıktının nasıl doğrulanacağını ve hangi bilginin girilmeyeceğini anlatın.
6. Ölçün, geri bildirim kanalını açın ve kapsamı kademeli genişletin. Haftalık aktif kullanıcı, birim bazlı sorgu sayısı, kaynakta bulunamadı oranı ve hatalı yanıt bildirimi sayısını izleyin. Hata bildirim kanalını asistanın arayüzüne koyun ve bildirimleri kaynak seti sahibine yönlendirin. Kapsamı ancak üç aylık kullanım ve hata verisini inceledikten sonra genişletin.

Sık sorulan sorular

Her kamu kurumunun kurum içi yapay zeka asistanı için kendi GPU sunucusunu alması gerekir mi?

Hayır. Kendi GPU altyapısı, kritik veri işleyen, sürekli ve yüksek hacimli kullanımı olan ve kalıcı teknik kadrosu bulunan kurumlar için anlamlıdır. 2019/12 sayılı Genelge kritik veriyi internete kapalı güvenli bir ağda tutma yükümlülüğü getirir, ancak kurumun her iş yükü kritik veri içermez. Birim yazışması taslağı, mevzuat içinde arama veya toplantı notu özeti gibi işler için Türkiye'de barındırılan bir model API üzerinden çağrılabilir. Donanım maliyeti sistem boşta dururken de devam ettiğinden, düşük veya dalgalı kullanımda kendi altyapı toplam maliyette API modelinin gerisinde kalır.

CibGPT nedir ve diğer kamu kurumları bu sistemi kullanabilir mi?

CibGPT, Cumhurbaşkanlığı İletişim Başkanlığı'nın kendi personeli için geliştirdiği kapalı devre yapay zeka platformudur ve 13 Haziran 2026 tarihli açıklamayla duyurulmuştur. Başkanlığın açıklamasına göre sistem, kurumun kendi GPU sunucuları üzerinde, internete kapalı yerli LLM ve VLM modelleriyle ve kuruma özel ince ayarla çalışmaktadır. Aynı açıklamada dönüşümün kamu kurumlarına entegrasyon rehberleri gönderilerek devlet geneline taşındığı belirtilmiştir. CibGPT'nin diğer kurumlara doğrudan bir hizmet olarak açıldığına dair bir bilgi bulunmamaktadır; kurumların kendi kurulumlarını yaparken bu mimariyi emsal alması söz konusudur.

Kurum içi yapay zeka asistanı satın alırken ihale konusu nasıl tanımlanır?

Kamu satın alma pratiğinde bu iş genellikle yapay zeka yazılımı kiralama veya yazılım hizmet alımı olarak tanımlanır; teknik şartnamede ise model erişimi, token veya istek bazlı kullanım, barındırma ülkesi ve erişim yetkilendirmesi başlıkları yer alır. Şartnamede kapsamın ve dışlanan işlerin yazılı olması, verinin hangi ülkede işleneceğinin açıkça belirtilmesi, birim bazlı yetkilendirme ve kullanım raporlaması istenmesi, hata bildirim ve kaynak güncelleme sorumluluğunun tanımlanması önerilir. Kapsam tanımlanmadan yapılan alım, kullanılmayan kapasiteye ödeme yapılmasıyla sonuçlanır.

Kurum verileri asistanı sağlayan modelin eğitiminde kullanılır mı?

Bu, seçilen mimariye ve sağlayıcının sözleşmesine bağlıdır ve kurum tarafından ayrıca doğrulanması gereken bir noktadır. Kendi altyapısında çalışan bir kurulumda veri kurum ağından çıkmaz, dolayısıyla soru gündeme gelmez. API üzerinden çalışılan mimarilerde sağlayıcının veri işleme ve eğitimde kullanma davranışı sözleşmede açıkça yazılmalıdır. Kişisel Verileri Koruma Kurumu'nun 5 Mart 2026 tarihli rehberi, kurumsal açıdan hassas bilgilerin üçüncü taraf araçlarla paylaşılmasının bu bilgilerin model geliştirme süreçlerinde kullanılabilmesi riskini doğurduğuna dikkat çekmektedir. LLMTR tarafında kullanıcı promptları ve model yanıt gövdeleri kullanım ve faturalama veritabanına yazılmaz.

Asistanın hatalı veya uydurma yanıt vermesi riski nasıl yönetilir?

Risk üç katmanda yönetilir. Birincisi kaynak seti: asistan yalnızca onaylı kurum belgelerine dayanarak yanıt vermeli, kaynakta karşılığı olmayan soruda bulunamadığını söylemelidir. İkincisi şeffaflık: her yanıt dayandığı belgenin adını ve yürürlük tarihini göstermeli, personel doğrulama yapabilmelidir. Üçüncüsü insan onayı: Kişisel Verileri Koruma Kurumu'nun 5 Mart 2026 tarihli rehberi, üretken yapay zeka çıktılarına nihai kararların dayanağı olarak yaklaşılmamasını, bu çıktıların insan denetimi altında destekleyici unsurlar olarak ele alınmasını önermektedir. Ayrıca asistanın arayüzünde hata bildirim kanalı bulunmalı ve bildirilen hatalar kaynak seti sahibine yönlendirilmelidir.

Kurum içi asistan ile personelin kendi kullandığı genel yapay zeka araçları arasındaki fark nedir?

Kurum içi asistan, kurumun onayladığı kaynaklara bağlı çalışır, kurumun yetki matrisini uygular ve kullanımı kurum tarafından görülebilir. Personelin bireysel olarak kullandığı genel araçlar bu üç özelliğin hiçbirini taşımaz. Kişisel Verileri Koruma Kurumu'nun 5 Mart 2026 tarihli rehberi bu ikinci duruma Gölge YZ adını verir ve kurum bilgisi, onayı veya kurumsal kontrolü dışında gerçekleşen kullanım olarak tanımlar. Rehber, tamamen yasaklayıcı yaklaşımların gerçekçi sonuç doğurmayacağını, çalışanların araçları kurumsal görünürlük dışında kullanmasına zemin hazırlayabileceğini değerlendirmektedir. Kurum içi asistan kurmanın temel gerekçelerinden biri, kontrollü bir alternatif sunmaktır.

İlgili yazılar

• Yerli LLM yeterli mi? BİLGE, KUMRU ve MAIN ile çoklu model stratejisi
• BİGR uyumlu yapay zeka mimarisi: kamu kurumlarında veri sınıfına göre model seçimi
• Belediye yapay zeka çağrı merkezi: ihale analizi ve çözüm hattı tasarımı

• Model kataloğu
• Güvenlik ve veri işleme
• API anahtarı yönetimi
• Kullanım ve maliyet raporları