yapay zeka neden mimari tasarlayamaz

yapay zekânın fintech gibi alanlarda mimari kurmaya soyunması, ehliyeti yeni almış birine zırhlı para transfer aracı teslim etmek gibidir.

direksiyon var.
motor güçlü.
görüntü havalı.
ama adam daha hangi yolda frene basacağını bilmiyor.

bugün yapay zekâya “bana fintech mimarisi çiz” diyorsun, sana tertemiz kutular çıkarıyor. api gateway, auth service, payment service, fraud service, kafka, redis, postgresql, kubernetes, observability, ci/cd, vault… her şey yerli yerinde gibi duruyor. diyagramı görünce insanın içi açılıyor.

sonra biraz kazıyorsun, altından mimari değil, teknoloji panayırı çıkıyor.

çünkü yapay zekâ çoğu zaman şu hatayı yapıyor:
işin regülasyonunu, veri sınıflandırmasını, operasyon sorumluluğunu, silme/anonimleştirme gerekliliğini, audit ihtiyacını, finansal kayıt zorunluluğunu ve kvkk tarafındaki hassasiyeti aynı anda tartamıyor.

daha doğrusu tartıyor gibi yapıyor.

fintech’te mesele sadece ödeme almak değildir.
müşteri kimliği var.
telefon var.
iban var.
ip adresi var.
cihaz bilgisi var.
işlem geçmişi var.
risk skoru var.
log var.
bildirim var.
mutabakat var.
itiraz süreci var.
denetim var.

yani ortada “birkaç endpoint yazalım, gerisini event-driven yaparız” diye geçilecek bir konu yoktur.

ama yapay zekâ ne yapıyor?

“tüm event’leri kafka’ya basalım.”
“logları merkezi olarak toplayalım.”
“müşteri bilgilerini cache’leyelim.”
“fraud için bütün veriyi data lake’e akıtalım.”
“analytics ekibi de okusun.”
“support paneli de görsün.”
“ai agent da bunları analiz etsin.”

oh ne güzel.

kişisel veri almış başını düğün konvoyu gibi mikroservisler arasında geziyor.

sonra biri çıkıp “kvkk kapsamında bu kullanıcının verisini nasıl sileceğiz?” diyor. mimari çizimdeki bütün oklar bir anda sana bakıyor.

asıl patlama burada başlıyor.

çünkü kötü kurulmuş bir fintech mimarisinde kişisel veri tek yerde durmaz.
postgresql’de durur.
redis’e düşer.
kafka topic’lerinden akar.
elastic’e gider.
log dosyasında kalır.
data lake’e basılır.
backup’a girer.
müşteri destek panelinde görünür.
fraud sisteminde kopyalanır.
test ortamına yanlışlıkla replike edilir.
bir de üzerine “ai analiz servisi” diye yeni bir oyuncak bağlanır.

sonra “silme talebi geldi” denir.

neyi siliyoruz kardeşim?
asıl tabloyu mu?
event’i mi?
log’u mu?
backup’ı mı?
cache’i mi?
arama indeksini mi?
raporlama kopyasını mı?
modelin gördüğü prompt geçmişini mi?
embedding store’u mu?
vektör veritabanını mı?

işte yapay zekâ mimarilerinde en çok kaçan yer burasıdır.

ai sana güzel sistem kurar gibi yapar ama veri yaşam döngüsünü çoğu zaman yüzeysel geçer. “data retention policy uygulanmalı” diye bir cümle yazar, sonra devam eder. sanki o policy’yi yazınca veri kendiliğinden terbiyeye gelecek.

kvkk gerektiren işlerde bu yaklaşım sağlam patlar.

çünkü kişisel veriyle çalışıyorsan şu soruların cevabı mimarinin göbeğinde olmalı:

bu veri niye alınıyor?
hangi amaçla işleniyor?
ne kadar süre tutuluyor?
hangi servisler erişiyor?
hangi event’lerde taşınıyor?
loglara düşüyor mu?
cache’e giriyor mu?
backup’ta ne kadar kalıyor?
maskeleniyor mu?
anonimleştiriliyor mu?
silme talebinde ne oluyor?
erişim yetkisi kimde?
audit kaydı nasıl tutuluyor?
test ortamına gerçek veri gidiyor mu?
llm bu veriyi görüyor mu?

bunların cevabı yoksa orada mimari yoktur, sadece renkli kutular vardır.

yapay zekâ özellikle şu konuda çok tehlikeli bir rahatlık veriyor: “bunu da ekleyelim.”

redis ekleyelim.
kafka ekleyelim.
elastic ekleyelim.
clickhouse ekleyelim.
vector db ekleyelim.
llm agent ekleyelim.
rag ekleyelim.
observability ekleyelim.
data lake ekleyelim.

ekle, ekle, ekle.

sonra kişisel veri nereye gitti, kim gördü, kim sakladı, kim unuttu belli değil.

fintech’te mimari “hangi teknolojiyi kullanalım?” sorusuyla başlamaz.
“hangi veriyi hangi sorumlulukla taşıyoruz?” sorusuyla başlar.

bu farkı anlamayan yapay zekâ çıktısı, üretimde çok tehlikelidir.

mesela ai sana der ki:

“tüm ödeme event’lerini kafka üzerinden yayınlayın.”

güzel. peki event payload’ında ne var?

müşteri adı soyadı mı var?
telefon mu var?
iban mı var?
kart bilgisi mi var?
merchant bilgisi mi var?
ip adresi mi var?
cihaz parmak izi mi var?

consumer’lar kim?

fraud servisi mi?
bildirim servisi mi?
raporlama mı?
müşteri destek mi?
data science mı?
dış entegrasyon mu?

retention kaç gün?

7 gün mü?
90 gün mü?
1 yıl mı?
sonsuz mu çünkü kimse ayar yapmadı mı?

işte gerçek mimari burada başlar.

yapay zekâ bu detayları sormadan cevap veriyorsa, verdiği şey fintech mimarisi değil, teknoloji menüsüdür.

bir başka bela da log meselesi.

ai genelde “detaylı loglama yapılmalı” der.

ne güzel cümle.

sonra developer gider request body’yi komple loglar. içinde müşteri bilgisi, iban, telefon, kimlik bilgisi, hata mesajı, bazen token bile vardır. elastic’e akar. siem’e gider. backup’a girer. dashboard’da görünür. sonra güvenlik ekibi “abi burada kişisel veri var” deyince herkes birbirine bakar.

detaylı loglama başka şeydir.
kişisel veriyi log çöplüğüne çevirmek başka şeydir.

fintech’te log tasarımı bile mimarinin parçasıdır.

hangi alan maskelenecek?
hangi alan hiç yazılmayacak?
hangi hata mesajı kullanıcıya dönecek?
hangi hata mesajı internal kalacak?
correlation id nasıl taşınacak?
müşteri id pseudonymous mı olacak?
log retention kaç gün olacak?
log erişimi kimde olacak?

bunlar düşünülmeden “observability kurduk” demek, eve kamera takıp görüntüyü apartman girişine projeksiyonla yansıtmak gibidir.

bir de yapay zekânın sevdiği “agent” meselesi var.

llm agent loglara baksın.
incident analiz etsin.
müşteri destek talebini incelesin.
fraud skorunu yorumlasın.
release notu yazsın.

tamam, güzel de bu agent ne görüyor?

ham log mu görüyor?
müşteri verisi mi görüyor?
ödeme bilgisi mi görüyor?
kişisel veri içeren ticket mı görüyor?
prompt geçmişi tutuluyor mu?
model dış servise mi gidiyor?
embedding oluştururken kişisel veri vektör veritabanına mı basılıyor?

fintech ve kvkk tarafında llm bağlamak oyuncak değildir.

hele dış apı’ye müşteri verisi göndermek ayrı bir tartışmadır. sözleşme, açık rıza, veri işleyen/veri sorumlusu ilişkisi, aktarım, saklama, maskeleme, kayıt, denetim; bunların hepsi masadadır. “ama yapay zekâ çok güzel özetliyor” diye regülasyonun üstünden atlanmaz.

yapay zekâ burada yardımcı olabilir mi? evet.

ama mimariyi tek başına ona çizdirip production’a koşarsan, o artık yapay zekâ değil, yapay cesarettir.

doğru kullanım şudur:

ai fikir verir.
insan mimar sorgular.
güvenlik ekibi inceler.
hukuk/kvkk tarafı kontrol eder.
veri sınıflandırması yapılır.
tehdit modeli çıkarılır.
log politikası yazılır.
retention netleşir.
silme/anonimleştirme akışı tasarlanır.
erişim kontrolleri uygulanır.
sonra mimari konuşulur.

yanlış kullanım şudur:

“chatgpt bana fintech mimarisi çizdi, kafka da koymuş, kubernetes de var, çok profesyonel duruyor.”

bu cümle tek başına incident postmortem başlangıcıdır.

özellikle kvkk gerektiren yapılarda kötü mimari sonradan kolay düzelmez.

çünkü veri bir kere yanlış yerlere akmaya başladı mı, o akışı geri toplamak zordur. event geçmişi kalır, loglar kalır, backup kalır, downstream kopyalar kalır, raporlama tabloları kalır, test ortamları kalır, analitik ekiplerin export ettiği csv’ler kalır.

en başta “bu veri buraya girmeyecek” demek, sonradan “bu veriyi her yerden silelim” demekten bin kat ucuzdur.

yapay zekâ ile mimari kurarken asıl tehlike yanlış cevap vermesi değil, eksik cevabı doğruymuş gibi vermesidir.

çünkü ekranda her şey derli toplu görünür.
servis isimleri mantıklıdır.
oklar düzgündür.
teknolojiler moderndir.
cümleler özgüvenlidir.

ama eksik olan şey, gerçek dünyanın kirli detaylarıdır.

regülasyon.
veri sorumluluğu.
erişim sınırı.
saklama süresi.
silme hakkı.
log hijyeni.
audit.
operasyon.
maliyet.
ekip yetkinliği.
incident senaryosu.

bunlar yoksa mimari değil, linkedin görselidir.

özetle:

yapay zekâ fintech mimarisi çizebilir.
ama kvkk, güvenlik, denetim, veri yaşam döngüsü ve operasyonel sorumluluk düşünülmeden çizilen mimari patlar.

hem de öyle “bir servis down oldu” diye değil.

kişisel veri yanlış yerde durur.
müşteri verisi gereksiz yere çoğalır.
silme talepleri karşılanamaz.
loglar veri çöplüğüne döner.
event streaming kontrolsüz yayılır.
llm prompt’larına hassas veri girer.
denetimde herkes diyagramın arkasına saklanmaya çalışır.

sonunda da klasik cümle gelir:

“aslında mimari güzeldi ama uygulamada sorun oldu.”

hayır kardeşim.

kvkk gerektiren işte veri akışını düşünmeden kurulan mimari güzel değildir. sadece makyajlıdır.

fintech’te iyi mimari, en yeni teknolojiyi koyan mimari değildir.
kişisel veriyi en az dolaştıran, en net sınırlayan, en iyi izleyen, gerektiğinde silebilen ve denetimde hesabını verebilen mimaridir.

yapay zekâdan fikir alınır.
ama sorumluluk yapay zekâya atılmaz.

çünkü ceza geldiğinde prompt geçmişini mahkemeye sanık diye çıkaramıyorsun.