İşe AI Katmak: Üniversitede AI Agent — Öğrenci İşlerinden Yönetim Masasına
Önceki yazılarda sigorta masasına ve müşteri hizmetlerine baktık. Allianz Nemo, Klarna, büyük sayılar, büyük dersler.
Bu yazıda eve dönüyoruz. Çünkü bu sefer anlatacağım vakayı bir raporda okumadım. Biz kurduk.
Yıllardır bir üniversitenin veri tarafında çalışıyorum. Öğrenci bilgi sistemi, ÖSYM verileri, mezun istatistikleri, anketler. Ve son bir yıldır aynı soruyu kendi kurumumuzda test ediyoruz: AI agent bir üniversitede gerçekten ne işe yarar?
Cevap: düşündüğünüzden fazlasına. Ama düşündüğünüz yerde değil.
Üniversite Neden İyi Bir Agent Sahası?
Müşteri hizmetleri yazısındaki dört kriteri hatırlayın: yüksek hacim, tekrarlı sorular, yapılandırılmış kaynaklar, ölçülebilir başarı.
Üniversite bu tabloya şaşırtıcı derecede iyi oturuyor:
- Yüksek hacim → binlerce öğrenci, her dönem aynı yoğunluk zirveleri: kayıt haftası, sınav dönemi, mezuniyet
- Tekrarlı sorular → "yerleşme puanları nasıl değişti", "mezunlarımızın ortalaması ne", "bu bölümün doluluk oranı kaç"
- Yapılandırılmış kaynaklar → öğrenci bilgi sistemi, ÖSYM verileri, anket veritabanları — hepsi SQL'in altında hazır bekliyor
- Ölçülebilir başarı → cevap süresi, rapor hazırlama süresi, kurul toplantısına yetişen analiz sayısı
Ama bir fark var. Klarna'da agent müşteriyle konuşuyordu. Üniversitede ilk kazanım başka bir yerde çıktı: yönetimin veriyle konuşması.
Üç senaryoyla anlatayım. Üçü de kendi masamızdan.
Senaryo 1 — Yönetimin Veri Soruları
Masadaki iş:
Yönetim toplantısı öncesi telefon çalar: "Bu yıl bölümlere yerleşen öğrenci profili geçen yıla göre nasıl değişti? Bir de mezunlarımızın ortalamalarına bakalım."
Manuel akış: SQL'i aç, ÖSYM yerleştirme verisine sorgu yaz, sonucu Excel'e al, pivotla, bir de mezun tablosuna ayrı sorgu, iki çıktıyı birleştir, özetle, maille gönder. En iyi ihtimalle yarım saat. Toplantı öğlense ve soru sabah geldiyse, öğle yemeği iptal.
Asıl problem şu: bu soruların cevabı hep aynı iki-üç veri kaynağında. Değişen tek şey sorunun cümlesi.
Agent ne yapıyor:
Yönetici soruyu doğal dille yazıyor: "2025 ve 2026 yerleştirme sonuçlarını karşılaştır." Agent hangi veri kaynağına gideceğine kendi karar veriyor — yerleştirme sorusu mu, mezun sorusu mu, yoksa Türkiye geneli bir kıyas mı? Doğru kaynağa sorguyu atıyor, sonucu tabloya döküp yorumluyor.
Türkiye geneli kıyas dediğim şey de önemli: agent'a YÖK Atlas verisini de bağladık. Yani "bizim bölümün taban puanı diğer üniversitelerin aynı bölümüne göre nerede?" sorusu, iç veri + ulusal veri birleşimiyle cevaplanıyor.
Arkada ne dönüyor:
İlk yazıdaki mimariyi hatırlayın.
Tools — iki ayrı SQL aracı: biri ÖSYM yerleştirme verisi, biri mezun ortalamaları. Üçüncü araç olarak YÖK Atlas bağlantısı (MCP ile). Burada bir parantez açayım: bu bağlantıyı mümkün kılan YÖK Atlas MCP'yi geliştiren Said Sürücü'ye teşekkürler — açık kaynak ekosisteminin en güzel tarafı bu: birinin emeği, herkesin agent'ına araç oluyor. Kritik bir tasarım kararı: bu araçların hiçbiri bireysel öğrenci kaydına bakmıyor. Hepsi toplulaştırılmış istatistik görünümleri üzerinde çalışıyor — agent'ın gördüğü en küçük birim, bir bölümün ortalaması.
LLM — hangi sorunun hangi araca gideceğine karar veren katman. Bu, kulağa basit geliyor ama en çok uğraştığımız kısım burasıydı. İlk versiyonlarda agent yerleştirme sorusunu mezun aracına yönlendiriyordu. Çözüm: sistem prompt'una net bir kapsam kapısı koymak — "önce sorunun hangi veri alanına ait olduğunu belirle, sonra aracı seç."
Planning — soruyu anla → kaynağı seç → sorguyu çalıştır → sonucu yorumla → sun.
Bir ders daha: agent'ın çıktısı ham tablo olmamalı. Yönetici sayı yığını değil, cümle ister. Bu yüzden agent'a net bir kural koyduk: önce tek cümlelik yorum — "yerleşen öğrenci profili geçen yıla göre şu yönde değişti, en belirgin fark şu bölümde" — sonra tablo. Küçük bir prompt detayı gibi görünüyor, ama çıktının okunup okunmamasını belirleyen şey bu.
Senaryo 2 — Aday ve Öğrenci Soruları
Masadaki iş:
Uluslararası öğrenci başvuru dönemi. Adaylar soruyor: "Bu bölüme başvurabilir miyim? Kontenjan var mı? Geçen yıl kaç kişi alındı?"
Her soru aynı verinin farklı bir dilimi. Ve her biri bir personelin mesaisinden 5-10 dakika alıyor. Başvuru döneminde günde onlarca kez.
Agent ne yapıyor:
Aday soruyu bir mesajlaşma botuna yazıyor. Bot cevabı, kontenjan ve geçmiş yıl istatistikleri gibi zaten ilan edilen, toplulaştırılmış bilgilerden üretiyor. Kişisel veri sormuyor, kişisel kayıt açmıyor, hiçbir şey saklamıyor. Ve veri yoksa — bu kritik — "bu konuda bilgi bulunamadı" diyor. Uydurmuyor.
Arkada ne dönüyor:
Tools — başvuru verisine giden SQL sorgusu, mesajlaşma platformu entegrasyonu.
LLM — soruyu sorguya çeviren ve cevabı aday diline döken katman.
Buradaki asıl mühendislik "sıfır sonuç" davranışında. LLM'ler boşluk sevmez; veri yoksa doldurma eğilimindedir. Bir aday botuna "kontenjan var" dedirtmek istemezsiniz — o cevabın kurumsal sonucu olur. Bu yüzden kural net: veri yoksa cevap "yok"tur. Agent'ın en değerli cümlesi bazen "bilmiyorum"dur.
Senaryo 3 — Anket Denizinde Yüzmek
Masadaki iş:
Dönem sonu. Öğrenci memnuniyet anketleri kapandı. Binlerce yanıt, yüzlerce açık uçlu yorum. Yönetim soruyor: "Öğrenciler ne diyor? Fakülte bazında rapor alabilir miyiz?"
Klarna yazısındaki 2300 konuşma problemi — birebir aynısı. Kimse binlerce yorumu elle okuyamaz. Örneklem alınır, örneklem yanıltır.
Agent ne yapıyor:
İki katmanlı bir sistem kurduk.
Birincisi: fakülte ve bölüm bazında anket raporlarını otomatik üreten bir hat. Veri tabanından çekiliyor, AI analiz katmanından geçiyor, kurum kimliğine uygun şablonla PDF'e dönüşüyor. Eskiden günler süren dönem sonu rapor maratonu, artık bir tetiklemeyle çalışan bir süreç.
İkincisi: açık uçlu yorumlar için anlamsal arama. Yorumlar, kimlik bilgilerinden arındırılmış halde vektör veritabanına işleniyor — sistemde kimin yazdığı yok, ne yazıldığı var. Artık "yemekhaneyle ilgili şikayetler neler?" diye sorabiliyorsunuz — kelime eşleşmesi değil, anlam eşleşmesi. "Yemekler soğuk geliyor" yorumu, içinde "yemekhane" kelimesi geçmese de bulunuyor.
Arkada ne dönüyor:
Tools — SQL görünümleri, PDF üretim servisi, vektör veritabanı.
Memory — işte ilk yazıdaki "uzun vadeli hafıza / vector database" kavramının gerçek hayattaki hali. Teorik bir kutu değil; öğrenci yorumlarının anlam haritası.
LLM — Likert ölçeklerini yorumlayan, açık uçlu cevapları temalandıran, rapor dilini kuran katman.
Bir detay: "Fikrim yok" cevapları. Ortalamaya katarsanız sonucu bozar, atarsanız veri kaybedersiniz. Bu tür kurallar — hangi cevap hesaba girer, hangisi girmez — agent'a değil, veri modeline aittir. AI katmanı ne kadar akıllı olursa olsun, altındaki veri disiplini yanlışsa çıktı da yanlıştır.
Bu da Bizim Nemo'muz
Allianz, Nemo'yu 100 günde canlıya aldı demiştim. Burada anlattığım sistemlerin hiçbiri de yıllar süren dönüşüm projeleri değil. Hepsini mevcut veri altyapısının üstüne, açık kaynak otomasyon araçlarıyla, dar ve net kapsamlarla kurduk.
Ve Nemo'yla aynı ilkeyi paylaşıyor: karar hâlâ insanda.
Agent yerleştirme trendini gösteriyor; kontenjan kararını yönetim veriyor. Agent yorumları temalandırıyor; iyileştirme aksiyonunu kurullar belirliyor. Agent adaya kontenjan bilgisi veriyor; kabul kararını komisyon veriyor.
Ama Üniversitede İşler Daha da Hassas
Sigorta yazısında dört risk saymıştım. Üniversitede bunlara iki katman daha ekleniyor:
KVKK ve öğrenci verisi. Öğrenci verisi, müşteri verisinden daha hassas bir kategoride. Agent'ın hangi veriye, hangi yetkiyle dokunduğu baştan tasarlanmalı. Bizim kurduğumuz sistemlerde bu iş en alttan başlıyor: agent'ın kullandığı veritabanı kullanıcısı sadece belirli görünümleri okuyabiliyor. Yazma yetkisi yok, tablo erişimi yok. Ve o görünümler bireysel kayıt değil, toplulaştırılmış veri taşıyor. Çünkü en sağlam KVKK stratejisi, kişisel veriyi agent'ın göreceği katmana hiç koymamaktır. En küçük yetki prensibi — tercih değil, zorunluluk.
Bir adım daha ilerisi de mümkün: hassas veri hatlarında modelin kendisini kurum içinde çalıştırmak. Biz de öyle yaptık. Bu senaryolardaki analiz katmanı, kurumun kendi donanımında — Apple Silicon üzerinde koşan açık kaynak bir Qwen modeliyle — çalışıyor. Bulut API'si yok, yurt dışına veri aktarımı tartışması yok. Veri sadece agent'ın göremeyeceği katmanda değil; binanın dışına da çıkmıyor.
Bunun bir bedeli var elbette: yerel model, en güncel bulut modellerinin gerisinde kalabiliyor ve donanımı siz yönetiyorsunuz. Ama denklem net — hassas veride egemenlik, birkaç puan model performansından daha değerli.
Yönetmelik kararları otomatize edilemez. Kayıt silme, ilişik kesme, not itirazı sonucu... Bunlar kurul kararlarıdır. Agent bilgi hazırlar, gerekçe derler, taslak yazar. Karar cümlesini kuramaz. Allianz "ödeme kararları asla otomatize edilmez" diyordu. Üniversitedeki karşılığı: "öğrenci hakkındaki kararlar asla otomatize edilmez."
Bir de mütevazı bir itiraf: bu sistemler ilk denemede çalışmadı. Agent yanlış araca gitti, boş sonuçlarda uydurma riski çıktı. Her biri prompt'ta, veri modelinde veya akışta bir düzeltme turu demekti. Agent kurmak bir "kur ve unut" işi değil; bir kalibrasyon süreci.
Kapanış
Klarna yazısını iki cümleyle bitirmiştim. Buna da benzer bir çift yakışıyor:
Birinci cümle: Üniversitede AI agent, veriyle yönetim arasındaki mesafeyi kapatıyor. Yarım saatlik sorgu işi, bir soru cümlesine iniyor.
İkinci cümle: Üniversitede AI agent, kararların sahibini değiştirmiyor. Yönetmelik, kurul ve insan — üçü de yerinde duruyor.
Soru artık "üniversiteye AI girer mi?" değil. Girdi bile.
Soru şu: "Veriyi taşıyan biz mi olacağız, soruyu soran biz mi?"
Biz ikincisini seçtik. Masadaki fark, bu seçimin kendisi.
Serinin devamında hangi alana bakalım? Sağlık mı, finans mı, kamu mu? Yorumlara yazın — bir sonraki durağı birlikte seçelim.