Belediye yapay zeka çağrı merkezi: ihale analizi ve çözüm hattı tasarımı

Belediye çağrı merkezinde yapay zekanın çözdüğü ve çözmediği problem

Belediye çağrı merkezleri ve çözüm hatları, gün içinde dengesiz dağılan, büyük bölümü tekrar eden ve mesai saatlerine sığmayan bir talep hacmiyle çalışır. Su kesintisi, çöp toplama saati, emlak vergisi ödemesi, nikah randevusu, evlendirme evrakı, imar durumu sorgusu, park bahçe arızası gibi başvurular yılın belirli günlerinde yığılır; kar yağışı veya altyapı arızası olan bir günde hat kapasitesi anlamsız hale gelir. Yapay zeka bu noktada bir kapasite ve kanal problemini hedefler, bir yetkinlik problemini değil.

Belediye tarafında yapay zekanın gerçekten çözdüğü şey dört başlıkta toplanır: yoğunluk anlarında kuyruğa girmeden ilk teması karşılamak, mesai dışında ve hafta sonunda hattı açık tutmak, telefon dışındaki kanalları (web, WhatsApp, sosyal medya) tek bir akışta toplamak ve toplam hacmin büyük bölümünü oluşturan tekrar eden soruları personel dokunuşu olmadan sonuçlandırmak. Bu dördü ölçülebilir, sözleşmeye yazılabilir ve kabul kriterine bağlanabilir hedeflerdir.

Belediye tarafında yapay zekanın çözmediği şeyler ise çoğu projenin başarısız olduğu yerdir. Bir başvuruyu sisteme doğru kaydetmek, o başvuruya bakacak ekip yoksa sahada bir şeyi değiştirmez. Kurum içi bilgi dağınıksa, ücret tarifesi üç ayrı yerde farklı yazıyorsa veya müdürlükler arası görev sınırı belirsizse, dil modeli bu belirsizliği çözmez; tam tersine kendinden emin bir üslupla yayar. Mevzuat yorumu, takdir yetkisi kullanılan istisna talepleri ve şikayet konusu olabilecek hassas başvurular tasarım gereği insana kalmalıdır.

Esenyurt Belediyesi'nin 3 Haziran 2026 tarihli duyurusu bu ayrımı iyi örnekler. Duyuruda sistemin işlevi "Yapay zeka destekli altyapı sayesinde gelen başvurular otomatik olarak analiz edilerek ilgili müdürlüğe yönlendiriliyor" cümlesiyle tarif edilir: vaat edilen şey sorunun çözülmesi değil, doğru birime hatasız ve beklemesiz ulaştırılmasıdır. Nevşehir Belediyesi'nin 12 Temmuz 2026'da duyurulan iletişim asistanı da benzer biçimde bilgi verme ve yönlendirme katmanında konumlanır; sistem web sitesi, WhatsApp, Telegram, Instagram ve Facebook kanallarında 7 gün 24 saat çalışır ve 80'den fazla dil desteği sunar.

• Çözdüğü: yoğunluk anındaki bekleme, mesai dışı erişilebilirlik, çok kanallı dağınıklık, tekrar eden sorularda personel yükü.
• Çözmediği: saha ekibi kapasitesi, müdürlükler arası görev sınırı belirsizliği, güncel olmayan veya çelişkili kurum içi bilgi.
• Çözmemesi gereken: takdir yetkisi gerektiren istisna talepleri, mevzuat yorumu, hukuki sonuç doğuran beyanlar.
• Ölçülebilir olması gereken: ilk temasta çözüm oranı, insana devretme oranı, ortalama işlem süresi, yönlendirme doğruluğu.

Görev ayrıştırması: tek bir yapay zeka müşteri temsilcisi değil, dört ayrı iş

Belediye çözüm hattı projelerinde en pahalı tasarım hatası, bütün işi tek bir büyük modele yaptırmaktır. İhale dokümanlarında ve kurum içi yazışmalarda iş genellikle tek kalem olarak, "yapay zeka müşteri temsilcisi yazılımı" veya "yapay zeka asistan yazılımı kiralama hizmeti" adıyla geçer. Teknik tarafta ise bu tek kalem, birbirinden farklı zorluk seviyelerine sahip en az dört ayrı işe ayrılır: niyet sınıflandırma ve yönlendirme, onaylı kaynaktan bilgi sorgusu, talep ve şikayet kaydı oluşturma, uzun görüşmenin personel için özetlenmesi.

Bu dört işin model ihtiyacı aynı değildir. Gelen bir mesajın hangi müdürlüğü ilgilendirdiğini bulmak sınırlı etiket kümesi üzerinde bir sınıflandırma problemidir ve küçük ölçekli bir model bunu yüksek doğrulukla yapar. Buna karşılık ücret tarifesi, başvuru evrakı listesi veya çalışma saatleri gibi bilgileri vermek bir üretim problemi değil, bir erişim problemidir: burada belirleyici olan modelin büyüklüğü değil, arkasına bağlanan onaylı belge setidir. Kurum içi belgeye dayanan yanıt üretimi, yani erişimle desteklenmiş üretim (RAG), yalnızca bu ikinci grup için zorunludur.

Maliyet kontrolü tam olarak buradan gelir. Belediye hattına gelen hacmin büyük bölümü sınıflandırma ve tekrar eden bilgi sorgusudur; bu iki iş küçük ve orta ölçekli modellerle karşılanabilir. Büyük modele ihtiyaç duyan kısım, mevzuat istisnası içeren veya birden çok müdürlüğü ilgilendiren karmaşık başvurulardır ve bu başvurular toplam hacmin küçük bir bölümünü oluşturur. Her görevi ayrı model ve ayrı bütçe kalemi olarak kurgulayan bir mimaride, birim başvuru maliyeti tek modelli bir mimariye göre belirgin biçimde düşer.

Ayrıştırmanın ikinci faydası sorumluluk sınırıdır. Bir görevi ayrı bileşen olarak tanımladığınızda, o bileşenin hata payını ayrı ölçebilir, ayrı eşik koyabilir ve gerektiğinde yalnızca onu insana devredebilirsiniz. Tek parça bir asistanda "yanlış cevap verdi" tespiti yapılabilir ama hangi katmanın hata verdiği izlenemez; bu da hem düzeltmeyi hem de sözleşmesel kabul denetimini imkansız hale getirir.

Doğruluk ve sorumluluk: yanlış bilgi vatandaşı mağdur eder

Belediye çözüm hattında yanlış bilgi, ticari bir müşteri hizmetleri hatasından farklı sonuç doğurur. Vatandaş, eksik evrak listesine güvenerek belediyeye gelir ve işlemini yaptıramaz; yanlış söylenen son ödeme tarihi nedeniyle gecikme zammıyla karşılaşır; başvuru hakkı olmadığı söylendiği için hiç başvurmaz. Bu üç senaryonun ortak yanı, hatanın vatandaş üzerinde zaman, para veya hak kaybı olarak somutlaşmasıdır. Bu nedenle doğruluk, projede bir kalite hedefi değil, bir tasarım kısıtıdır.

Doğruluğun ilk şartı onaylı kaynak setidir. Modelin yanıt üreteceği bilgi havuzu, kurumun kendi yayımladığı ve sahibi belli olan belgelerle sınırlandırılmalıdır: ücret tarifesi meclis kararı, hizmet standartları tablosu, başvuru evrak listeleri, resmi duyurular ve müdürlük iç genelgeleri. Her belgenin bir sahibi, bir yürürlük tarihi ve bir güncelleme sorumlusu olmalıdır. Sahipsiz belge havuza girmemelidir; çünkü tarife değiştiğinde havuzdaki eski sürümü kimin çıkaracağı belli değilse sistem eskiyen bilgiyi güvenle söylemeye devam eder.

İkinci şart, sistemin bilmediğini söyleyebilmesidir. Dil modelleri varsayılan davranış olarak boşluğu doldurur; belediye hattında istenen davranış bunun tersidir. Yanıt yalnızca onaylı kaynakta karşılığı bulunduğunda üretilmeli, karşılık yoksa model kendi genel bilgisinden yanıt üretmek yerine açık bir yetersizlik yanıtı vermeli ve akışı insana taşımalıdır. Bu davranış istemle rica edilerek değil, kaynak eşleşmesi bulunamadığında yanıt üretimini durduran bir kontrol katmanıyla sağlanır.

Üçüncü şart, insana devretme eşiğinin önceden ve sayısal olarak tanımlanmasıdır. Devretme kararı üç ayrı sinyale bağlanmalıdır: sınıflandırma güven skorunun eşik altında kalması, onaylı kaynakta eşleşme bulunamaması ve konunun önceden belirlenmiş hassas başlıklar listesine girmesi. Sosyal yardım başvurusu, sağlık durumu beyanı, hukuki uyuşmazlık, personel şikayeti ve ölüm veya defin işlemleri gibi başlıklar, model ne kadar emin olursa olsun otomatik yanıtlanmamalıdır.

Dördüncü şart izlenebilirliktir. Vatandaşa verilen her yanıtın hangi belgeye ve o belgenin hangi sürümüne dayandığı kayıt altında olmalıdır. Bir başvuru sonradan itiraza konu olduğunda, kurumun "bu bilgi hangi belgeden verildi" sorusunu cevaplayabilmesi gerekir. Bu kayıt, hem iç denetim hem de yüklenici performansının değerlendirilmesi için gereken tek somut delildir.

• Onaylı kaynak seti: her belgenin sahibi, yürürlük tarihi ve güncelleme sorumlusu tanımlı olsun; sahipsiz belge havuza girmesin.
• Yetersizlik yanıtı: kaynak eşleşmesi yoksa model tahmin üretmesin, akış insana taşınsın.
• Devretme eşiği: düşük güven skoru, kaynak bulunamaması ve hassas konu listesi olmak üzere üç ayrı tetikleyici tanımlansın.
• Otomatik yanıtlanmaması gereken başlıklar: sosyal yardım, sağlık beyanı, hukuki uyuşmazlık, personel şikayeti, defin işlemleri.
• İzlenebilirlik: her yanıt, dayandığı belge ve belge sürümü ile birlikte kayda geçsin.

KVKK: vatandaş başvurusu kişisel veri içerir

Belediye çözüm hattına gelen hemen her başvuru kişisel veri içerir. Vatandaş adını, adresini, telefon numarasını, abone numarasını, sicil numarasını, kimi zaman sağlık durumuna veya sosyal yardım ihtiyacına ilişkin bilgileri kendiliğinden yazar. Belediye bu işlemede veri sorumlusudur ve 6698 sayılı Kişisel Verilerin Korunması Kanunu'nun yükümlülükleri, işlemenin bir çağrı merkezi personeli tarafından mı yoksa bir yazılım tarafından mı yapıldığına bakmaksızın uygulanır.

Kanunun 4'üncü maddesinin ikinci fıkrası kişisel verilerin işlenmesinde uyulması zorunlu ilkeleri sayar. Bunlardan (ç) bendi işlemenin "İşlendikleri amaçla bağlantılı, sınırlı ve ölçülü olma" ilkesine tabi olduğunu belirtir. Bu ilke, çözüm hattı tasarımında doğrudan bir mühendislik kısıtına dönüşür: modele gönderilen istem, o görevi yapmak için gereken asgari veriyi taşımalıdır. Bir başvuruyu ilgili müdürlüğe yönlendirmek için vatandaşın adı, adresi veya telefon numarası gerekli değildir; başvurunun konu metni yeterlidir.

Uygulamada bu, istem ile kayıt katmanının ayrılması demektir. Kimlik ve iletişim bilgileri, talep kaydını oluşturan kurum sistemine yazılır; modele gönderilen metinden ise maskeleme veya çıkarma yoluyla ayıklanır. Modelin gördüğü metin sınıflandırma ve özetleme için yeterli, kişiyi tanımlamak için yetersiz olmalıdır. Sağlık durumu, ceza mahkumiyeti, dini inanç gibi Kanunun 6'ncı maddesi kapsamındaki özel nitelikli veriler bir başvuru metninde geçtiğinde, bu başvuru otomatik akıştan çıkarılıp doğrudan yetkili personele iletilmelidir.

İşlemenin hukuki sebebi de belirlenmelidir. Kanunun 5'inci maddesinin ikinci fıkrası, açık rıza aranmaksızın işlemeye imkan veren halleri sayar; (a) bendi "Kanunlarda açıkça öngörülmesi", (ç) bendi ise "Veri sorumlusunun hukuki yükümlülüğünü yerine getirebilmesi için zorunlu olması" halini düzenler. Belediyenin görev alanındaki bir başvurunun kaydedilmesi ile hattı işleten yüklenicinin analitik amaçlı veri kullanımı aynı hukuki sebebe dayanmaz; bu ikisi ayrı değerlendirilmelidir.

Aydınlatma yükümlülüğü kanalın kendisinde yerine getirilmelidir. Kanunun 10'uncu maddesi, verilerin elde edilmesi sırasında veri sorumlusunun ilgili kişilere veri sorumlusunun kimliği, işleme amacı, aktarım yapılacak taraflar, toplama yöntemi ile hukuki sebebi ve 11'inci maddedeki haklar konusunda bilgi vermesini zorunlu kılar. Bu, WhatsApp hattının ilk mesajında, web sohbet penceresinin açılışında ve sesli kanalın karşılama anonsunda aydınlatma metnine erişimin sağlanması anlamına gelir.

Güvenlik ve saklama tarafında Kanunun 12'nci maddesinin birinci fıkrası veri sorumlusuna, verilerin hukuka aykırı işlenmesini ve bunlara hukuka aykırı erişilmesini önlemek ile muhafazalarını sağlamak amacıyla "uygun güvenlik düzeyini temin etmeye yönelik gerekli her türlü teknik ve idari tedbirleri almak" zorunluluğu getirir. Sözleşmede görüşme metinlerinin ne kadar süreyle saklanacağı, kimin erişebileceği, model eğitiminde kullanılıp kullanılamayacağı ve hizmet sonunda nasıl imha edileceği açıkça yazılmalıdır. Yurt dışında barındırılan bir hizmet kullanılacaksa Kanunun 9'uncu maddesindeki yurt dışına aktarım rejimi ayrıca değerlendirilmelidir.

• İsteme giren: başvuru konu metni, kategori bilgisi, gerekliyse mahalle düzeyinde konum.
• İsteme girmemesi gereken: ad soyad, T.C. kimlik numarası, telefon, açık adres, abone ve sicil numarası.
• Özel nitelikli veri tespit edilen başvuru otomatik akıştan çıkarılıp yetkili personele iletilsin.
• Saklama süresi, erişim yetkisi, model eğitiminde kullanım yasağı ve imha yöntemi sözleşmede yazılı olsun.
• Aydınlatma metni her kanalın giriş noktasında erişilebilir olsun; kanal listesi veri envanterine işlensin.

Belediye yapay zeka ihalesi: İKN 2026/743700 yapısı ve en düşük fiyat esasının anlamı

Belediye yapay zeka çağrı merkezi projeleri Türkiye'de artık somut ihale dokümanları üzerinden yürüyor ve bu dokümanların yapısı projenin teknik tasarımını doğrudan belirliyor. Bahçelievler Belediyesi Bilgi İşlem Müdürlüğü'nün "Yapay Zeka Asistan ve Yapay Zeka Müşteri Temsilcisi Yazılımı Kiralama Hizmeti" işi, İKN 2026/743700 ile 11 Mayıs 2026 saat 10:00'da ihale edilmek üzere ilan edilmiştir. İş, 4734 sayılı Kamu İhale Kanunu'nun 19'uncu maddesine göre açık ihale usulüyle yapılmakta; Kanunun ilgili maddesi bu usulü "Açık ihale usulü, bütün isteklilerin teklif verebildiği usuldür" cümlesiyle tanımlar.

İlanın taşıdığı diğer şartlar bir yıllık, tek yüklenicili ve yerli tedarikçiye kapalı bir operasyon tarif eder. İşin süresi işe başlama tarihinden itibaren 365 gün, işe başlama ise sözleşmenin imzalanmasından itibaren 7 gün içindedir. İlanda "İhaleye sadece yerli istekliler katılabilecektir" ve "Konsorsiyum olarak ihaleye teklif verilemez" ifadeleri yer alır. Teklif geçerlilik süresi 90 takvim günü, sınır değer hesabında kullanılan R katsayısı ise "Diğer Hizmetler" kategorisi için 0,78 olarak belirtilmiştir.

Bu ilanın teknik tasarım açısından en belirleyici maddesi, ekonomik açıdan en avantajlı teklifin en düşük fiyat esasına göre belirlenecek olmasıdır. 4734 sayılı Kanunun 40'ıncı maddesinin ikinci fıkrası şu düzenlemeyi getirir: "Ekonomik açıdan en avantajlı teklif, sadece fiyat esasına göre veya fiyat ile birlikte işletme ve bakım maliyeti, maliyet etkinliği, verimlilik, kalite ve teknik değer gibi fiyat dışındaki unsurlar da dikkate alınarak belirlenir." İdare bu iki yoldan birincisini seçtiğinde, kalite ve teknik değer teklif değerlendirmesinde puanlanmaz.

Sonuç şudur: en düşük fiyat esaslı bir ihalede kaliteyi taşıyan tek belge teknik şartnamedir. Şartnamede yazmayan bir doğruluk eşiği, bir insana devretme kuralı veya bir saklama süresi, değerlendirme aşamasında hiçbir isteklinin lehine puan üretmez ve sözleşme döneminde de talep edilemez. Bu nedenle yukarıdaki bölümlerde tarif edilen onaylı kaynak seti, yetersizlik yanıtı davranışı, hassas konu listesi ve izlenebilirlik kaydı, teklif kriteri olarak değil asgari teknik gereklilik olarak şartnameye girmelidir.

En düşük fiyat esası, isteklinin maliyet hesabını da doğrudan etkiler. Kullanım başına birim fiyatı bilinmeyen bir altyapıyla çalışan istekli, 365 günlük bir hizmet için belirsizlik payı ekleyerek teklif verir; bu pay teklifi yukarı çeker. Buna karşılık girdi ve çıktı birim fiyatları model bazında ilan edilmiş bir altyapı kullanan istekli, beklenen aylık başvuru hacmini görev tiplerine dağıtarak öngörülebilir bir maliyet tabanı kurar ve belirsizlik payını daraltabilir. Aynı şekilde idare de yaklaşık maliyet çalışmasında hacim varsayımlarını açık biçimde kurabilir.

Ölçüm tarafı da bu mantığın devamıdır. En düşük fiyat esaslı bir sözleşmede idarenin elindeki tek kaldıraç kabul ve hakediş aşamasıdır; bu nedenle metrikler şartnamede sayısal eşiklerle tanımlanmalıdır. İzlenmesi gereken asgari küme dörttür: ilk temasta çözüm oranı, insana devretme oranı, ortalama işlem süresi ve vatandaş memnuniyeti. Bu metrikler yalnızca toplamda değil, görev tipi ve kanal kırılımında raporlanmalıdır; aksi halde yüksek hacimli kolay soruların başarı oranı, karmaşık başvurulardaki başarısızlığı gizler.

• İlk temasta çözüm oranı: insana devredilmeden sonuçlanan başvuruların payı; görev tipi kırılımında raporlanmalı.
• İnsana devretme oranı: hedef sıfır değildir; hassas konularda yüksek devretme oranı doğru davranıştır.
• Ortalama işlem süresi: ilk yanıt süresi ile kayıt oluşturma süresi ayrı ölçülmeli.
• Vatandaş memnuniyeti: görüşme sonunda toplanan puan, devredilen ve devredilmeyen akışlar için ayrı raporlanmalı.
• Yönlendirme doğruluğu: müdürlükler arası geri gönderim sayısı, sınıflandırma kalitesinin en dürüst göstergesidir.

LLMTR belediye çözüm hattı projesinde nerede duruyor

LLMTR, bu yazıda tarif edilen görev ayrıştırmasını tek bir entegrasyonla kurulabilir hale getiren bir gateway platformudur. Sınıflandırma için küçük, bilgi sorgusu için orta, karmaşık başvuru için büyük model kullanmak isteyen bir yüklenici ya da belediye bilgi işlem ekibi, bunların her biri için ayrı sağlayıcı sözleşmesi ve ayrı entegrasyon yapmak yerine OpenAI uyumlu tek bir /v1 yüzeyi üzerinden çağrı yapar. Model değişikliği, temel adres ve model kimliğinin değiştirilmesinden ibarettir; bu da pilot sırasında model denemeyi ucuz hale getirir.

Birim bazlı anahtar ve tavan yapısı, belediye organizasyonuna doğrudan oturur. Çağrı merkezi, web sohbeti ve WhatsApp kanalı için ayrı API anahtarı tanımlanabilir; her anahtarın kendi hız sınırı, kendi harcama tavanı ve kendi kullanım raporu olur. Bir kanalda beklenmedik hacim artışı yaşandığında tavan devreye girer ve bütçe tek noktadan taşmaz. Aynı yapı, müdürlük bazlı kullanım dağılımını da görünür kılar.

Tek kullanım raporu, en düşük fiyat esaslı bir sözleşmenin hakediş ve kabul aşamasında pratik bir karşılık üretir. Girdi ve çıktı kullanımı model ve anahtar bazında raporlandığı için, aylık maliyetin hangi görev tipinden geldiği izlenebilir; büyük model kullanımının beklenenin üzerine çıkması, akış tasarımında bir sorun olduğunun erken sinyalidir. Fiyat tarafında kredi yüklemede %8 platform marjı uygulanır; model fiyatlarının kendisine marj eklenmez, bu da yaklaşık maliyet ve teklif hesabında ilan edilen birim fiyatların doğrudan kullanılabilmesi anlamına gelir.

Veri tarafında iki nokta belediye tasarımını ilgilendirir. Birincisi, Türkiye'de barındırılan modeller katalogda mevcuttur; llmtr/gemma-4, llmtr/qwen3-6-35b ve llmtr/embeddinggemma-300m gibi modeller, aynı katalogdaki global sağlayıcı modelleriyle birlikte tek arayüzden çağrılır. Vatandaş metninin yurt dışına çıkmasının tercih edilmediği akışlar için Türkiye'de barındırılan model, yurt dışı aktarım değerlendirmesini gündemden çıkarma imkanı verir. İkincisi, kullanıcı istemleri ve model yanıt gövdeleri kullanım ve faturalama veritabanına yazılmaz; müşteri API anahtarları düz metin olarak değil SHA-256 özet değeriyle saklanır.

Bu yazıdaki hiçbir ifade LLMTR'nin bir sertifikasyona, akreditasyona veya resmi onaya sahip olduğu anlamına gelmez. Platform bir altyapı bileşenidir; onaylı kaynak setinin kurulması, devretme eşiklerinin tanımlanması, aydınlatma metninin hazırlanması ve şartname hükümlerinin yazılması kurumun kendi sorumluluğundadır.

Kaynaklar

Bu yazıdaki mevzuat referansları ve ihale bilgileri 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.

• 4734 sayılı Kamu İhale Kanunu madde 19 ve madde 40 — mevzuat.gov.tr
• 6698 sayılı Kişisel Verilerin Korunması Kanunu madde 4, 5, 6, 9, 10 ve 12 — mevzuat.gov.tr
• Yapay Zeka Asistan ve Yapay Zeka Müşteri Temsilcisi Yazılımı Kiralama Hizmeti ihale ilanı, İKN 2026/743700 — bahcelievler.istanbul
• Esenyurt Belediyesi yapay zeka destekli WhatsApp çözüm hattı duyurusu, 3 Haziran 2026 — esenyurt.bel.tr
• Nevşehir Belediyesi yapay zeka destekli iletişim sistemi haberi, 12 Temmuz 2026 — fibhaber.com

Belediye yapay zeka çözüm hattı kurma adımları

Belediye çağrı merkezi ve çözüm hattı için yapay zeka destekli bir katman kurarken izlenecek altı adım: talep envanteri, onaylı kaynak seti, görev bazlı model ataması, devretme kuralları, KVKK envanteri ve ölçülebilir kabul kriterleriyle pilot.

1. Kanal ve talep envanterini çıkarın. Son on iki ayın çağrı merkezi, WhatsApp, web formu ve sosyal medya kayıtlarını tek tabloda toplayın. Başvuruları konu başlığına göre gruplayıp hacim sırasına dizin ve her grubun hangi müdürlüğe gittiğini işaretleyin. Toplam hacmin büyük bölümünü oluşturan tekrar eden başlıklar, otomasyonun ilk kapsamını belirler; kuyruk yoğunluğunun saat ve gün dağılımı ise mesai dışı kapsamın gerekçesini oluşturur.
2. Onaylı bilgi kaynağı setini kurun. Modelin yanıt üretebileceği belgeleri kurumun kendi yayımladığı kaynaklarla sınırlayın: ücret tarifesi meclis kararı, hizmet standartları tablosu, başvuru evrak listeleri, resmi duyurular ve müdürlük iç genelgeleri. Her belgeye bir sahip, bir yürürlük tarihi ve bir güncelleme sorumlusu atayın. Sahibi belirlenmemiş veya yürürlük tarihi olmayan belgeyi havuza almayın.
3. Görevleri ayrıştırın ve her göreve model atayın. İşi sınıflandırma ve yönlendirme, onaylı kaynaktan bilgi sorgusu, talep kaydı oluşturma ve özetleme olmak üzere ayrı bileşenlere bölün. Sınıflandırma için küçük, bilgi sorgusu ve özetleme için orta, mevzuat istisnası içeren karmaşık başvurular için büyük model atayın. Erişimle desteklenmiş üretimi yalnızca onaylı belgeye dayanması gereken bilgi sorgusu ve karmaşık başvuru bileşenlerinde kullanın.
4. Devretme eşiği ve insan onayı noktalarını tanımlayın. İnsana devretmeyi üç tetikleyiciye bağlayın: sınıflandırma güven skorunun eşik altında kalması, onaylı kaynakta eşleşme bulunamaması ve konunun hassas başlıklar listesine girmesi. Sosyal yardım, sağlık beyanı, hukuki uyuşmazlık, personel şikayeti ve defin işlemleri gibi başlıkları otomatik yanıt dışında bırakın. Talep kaydı oluşturmadan önce vatandaşa özet teyidi gösterin.
5. KVKK envanterini ve aydınlatma metnini güncelleyin. Yeni kanalları ve işleme faaliyetlerini kişisel veri işleme envanterine işleyin; her faaliyet için 6698 sayılı Kanunun 5'inci maddesindeki hukuki sebebi belirleyin. Modele giden istemde hangi alanların maskeleneceğini yazılı kurala bağlayın. Aydınlatma metnine WhatsApp hattının ilk mesajından, web sohbet penceresinden ve sesli kanal anonsundan erişim sağlayın. Saklama süresi, erişim yetkisi ve imha yöntemini sözleşmeye yazın.
6. Pilot çalıştırın ve metrikleri şartnameye kabul kriteri olarak yazın. En yüksek hacimli iki veya üç başlıkla sınırlı bir pilot yürütün ve ilk temasta çözüm oranı, insana devretme oranı, ortalama işlem süresi, memnuniyet ve yönlendirme doğruluğunu görev tipi ile kanal kırılımında ölçün. Pilotta gözlenen değerleri gerçekçi eşiklere dönüştürüp teknik şartnameye asgari gereklilik ve kabul kriteri olarak yazın. Raporlama kırılımını ve raporlama sıklığını da şartnamede belirtin.

Sık sorulan sorular

Belediye yapay zeka çağrı merkezi projesi hangi ihale usulüyle satın alınıyor?

Doğrulanmış bir örnekte iş, 4734 sayılı Kamu İhale Kanunu'nun 19'uncu maddesine göre açık ihale usulüyle satın alınmıştır. Bahçelievler Belediyesi Bilgi İşlem Müdürlüğü'nün İKN 2026/743700 sayılı "Yapay Zeka Asistan ve Yapay Zeka Müşteri Temsilcisi Yazılımı Kiralama Hizmeti" ihalesi 11 Mayıs 2026 saat 10:00 için ilan edilmiş, işin süresi işe başlamadan itibaren 365 gün olarak belirlenmiştir. İlanda ihaleye sadece yerli isteklilerin katılabileceği ve konsorsiyum olarak teklif verilemeyeceği belirtilmiştir. Her idarenin kendi ihtiyaç ve yaklaşık maliyetine göre farklı usul seçebileceği unutulmamalıdır.

Belediye chatbotu vatandaşa yanlış bilgi verirse sorumluluk kimde olur?

Kişisel veri işleme bakımından belediye veri sorumlusudur ve 6698 sayılı Kanunun yükümlülükleri işlemenin personel ya da yazılım eliyle yapılmasına göre değişmez. Hizmetin içeriğine ilişkin sorumluluk dağılımı ise idare ile yüklenici arasındaki sözleşme ve teknik şartname hükümlerine bağlıdır. Bu nedenle onaylı kaynak setinin kapsamı, güncelleme sorumluluğu, yanıtın hangi belgeye dayandığının kayda geçmesi ve hangi konularda otomatik yanıt verilemeyeceği şartnamede açıkça yazılmalıdır. Bu içerik bilgilendirme amaçlıdır, hukuki görüş niteliği taşımaz.

En düşük fiyat esaslı bir ihalede kalite gereklilikleri nereye yazılır?

En düşük fiyat esaslı ihalelerde kalite ve teknik değer teklif değerlendirmesinde puanlanmaz; 4734 sayılı Kanunun 40'ıncı maddesi ekonomik açıdan en avantajlı teklifin sadece fiyat esasına göre veya fiyat dışı unsurlarla birlikte belirlenebileceğini düzenler ve idare birinci yolu seçtiğinde kaliteyi taşıyan tek belge teknik şartname olur. Doğruluk eşiği, insana devretme kuralları, saklama süresi, raporlama kırılımı ve hassas konu listesi şartnamede asgari gereklilik olarak yazılmalıdır. Şartnamede yer almayan bir gereklilik sözleşme döneminde talep edilemez.

Vatandaş başvurusundaki kişisel veriler modele gönderilir mi?

Gönderilmemesi tasarım hedefi olmalıdır. 6698 sayılı Kanunun 4'üncü maddesi kişisel verilerin işlendikleri amaçla bağlantılı, sınırlı ve ölçülü olmasını zorunlu kılar; bir başvuruyu ilgili müdürlüğe yönlendirmek için ad, adres veya telefon numarası gerekli değildir. Uygulamada kimlik ve iletişim bilgileri talep kaydını tutan kurum sistemine yazılır, modele gönderilen metinden ise maskeleme veya çıkarma yoluyla ayıklanır. Sağlık durumu gibi özel nitelikli veri içeren başvurular otomatik akıştan çıkarılıp doğrudan yetkili personele iletilmelidir.

Belediye çözüm hattında hangi işler için büyük model gerekir?

Büyük model ihtiyacı hacmin küçük bir bölümünde yoğunlaşır. Niyet sınıflandırma ve müdürlüğe yönlendirme sınırlı etiket kümesi üzerinde çalıştığı için küçük ölçekli bir modelle karşılanabilir; ücret tarifesi veya evrak listesi gibi bilgi sorguları orta ölçekli bir modelle ve onaylı belge setine dayalı erişimle çözülür. Büyük model, mevzuat istisnası içeren veya birden çok müdürlüğü ilgilendiren karmaşık başvurular için ayrılmalıdır. Görev bazlı model ataması, birim başvuru maliyetini tek modelli mimariye göre düşürür.

Belediye yapay zeka çözüm hattının başarısı hangi metriklerle ölçülür?

Asgari dört metrik izlenmelidir: ilk temasta çözüm oranı, insana devretme oranı, ortalama işlem süresi ve vatandaş memnuniyeti. Bunlara yönlendirme doğruluğu, yani müdürlükler arası geri gönderim sayısı eklenmelidir. Metrikler toplamda değil, görev tipi ve kanal kırılımında raporlanmalıdır; aksi halde yüksek hacimli basit soruların başarı oranı, karmaşık başvurulardaki başarısızlığı gizler. İnsana devretme oranında hedef sıfır değildir; hassas konularda yüksek devretme oranı doğru davranıştır.

İlgili yazılar

• Yapay zeka teknik şartname hazırlama rehberi: madde madde örnek metinler
• Kurum içi yapay zeka asistanı nasıl kurulur? Kamu kurumları için mimari kararlar

• Model kataloğu
• Fiyatlandırma
• Birim bazlı API anahtarları
• KVKK ve veri işleme