AI Gateway: LLM Trafiğinizi Yöneten Katman — Model Yönlendirme, Semantik Cache ve Gözlemlenebilirlik (2026)

TL;DR — AI gateway, tüm LLM sağlayıcılarınızın ve modellerinizin önünde duran tek bir kontrol düzlemidir. Uygulamalarınızla model sağlayıcıları arasına yerleşir; model yönlendirme, semantik cache, hız sınırlama, yeniden deneme ve devre kesici, gözlemlenebilirlik, guardrail (PII maskeleme, içerik filtreleme), tüm sağlayıcılar için tek bir API ve anahtar/sır yönetimi gibi yetenekleri tek noktada toplar. Bunu bir maliyet düşürme listesi olarak değil, LLM trafiğinizi yöneten bir mimari katman olarak düşünmenizi öneriyorum. Bu yazıda gateway'in ne olduğunu, hangi temel yetenekleri taşıdığını, mimaride nereye oturduğunu, KVKK ve EU AI Act açısından nasıl bir yönetişim aracına dönüştüğünü, kendin kur ya da satın al kararını ve sahada en sık gördüğüm tuzakları anlatıyorum.

Birkaç yıl önce çoğu ekip için "yapay zeka entegrasyonu" tek bir sağlayıcının SDK'sını kurup bir API anahtarını koda gömmekten ibaretti. O günlerde bu yeterliydi. Tek model, tek sağlayıcı, tek kullanım senaryosu. Ama sahada gördüğüm tablo hızla değişti. Bugün danışmanlık verdiğim kurumların neredeyse tamamında birden fazla model, birden fazla sağlayıcı ve onlarca farklı uygulama aynı anda LLM çağrısı yapıyor. Bir ekip özetleme için bir modeli, başka bir ekip kod üretimi için bambaşka bir modeli, müşteri hizmetleri tarafı ise daha ucuz ve hızlı bir modeli kullanıyor. Her biri kendi anahtarını, kendi yeniden deneme mantığını, kendi loglamasını yazmış durumda.

Bu dağınıklığın bedelini ilk başta kimse hissetmiyor. Sonra bir gün bir sağlayıcı kesinti yaşıyor ve aynı anda beş ürün birden çöküyor, çünkü hiçbirinde failover yok. Veya ay sonu fatura geliyor ve kimse hangi ekibin, hangi özelliğin ne kadar token harcadığını söyleyemiyor. Ya da hukuk ekibi "bu modele giden veride kişisel veri var mı, nereye gidiyor, loglanıyor mu" diye soruyor ve cevap veremiyoruz. İşte ben bu noktada devreye giren katmana AI gateway diyorum.

Bir AI gateway'i en yalın haliyle şöyle tarif ediyorum: tüm LLM trafiğinizin geçtiği tek bir kapı. Tıpkı mikroservis dünyasında bir API gateway'in arkadaki servisleri soyutlayıp kimlik doğrulama, hız sınırlama ve gözlemlenebilirliği merkezileştirmesi gibi, bir AI gateway de arkadaki tüm model sağlayıcılarını soyutlar ve LLM'e özgü kontrolleri tek noktada toplar. Fark şu: API gateway HTTP isteklerini yönetir; AI gateway ise token akan, akış (streaming) içeren, anlam taşıyan ve maliyeti her çağrıda değişen bir trafiği yönetir. Bu yüzden klasik bir API gateway'i alıp "olur bu da" diyemiyoruz; LLM trafiğinin kendine has dinamikleri var.

Bu yazının amacı sizi tek bir ürüne ya da açık kaynak projeye yönlendirmek değil. Amacım, bu katmanı bir mimari kontrol düzlemi olarak görmenizi sağlamak. Çünkü doğru kurgulandığında gateway, sadece para tasarrufu sağlayan bir araç değil; kurumunuzun yapay zeka kullanımını gözlemlenebilir, yönetilebilir ve denetlenebilir kılan omurga oluyor.

Mimaride gateway'in yerini netleştirelim, çünkü bunu kafanızda oturtmadan diğer her şey havada kalıyor. Uygulamalarınız, mobil istemcileriniz, arka uç servisleriniz, ajan (agent) sistemleriniz LLM sağlayıcısına doğrudan gitmek yerine gateway'e gider. Gateway isteği alır, üzerinde bir dizi karar verir ve uygun sağlayıcıya iletir. Cevap geri döndüğünde de yine gateway üzerinden, gerekirse işlenerek istemciye ulaşır.

"

Gateway'i bir trafik kavşağındaki akıllı sinyalizasyon olarak düşünün. Arabalar (istekler) kavşağa gelir, sinyalizasyon (gateway) hangi yola gideceklerini, ne kadar bekleyeceklerini, hangi yolun tıkalı olduğunu bilir ve trafiği ona göre yönlendirir. Kavşak olmadan da arabalar bir şekilde gider ama kaos ve kaza kaçınılmazdır.

Burada kritik bir mimari karar var: gateway senkron mu yoksa akış (streaming) modunda mı çalışacak. Klasik bir istek-cevap senaryosunda gateway isteği alır, tam cevabı bekler ve döner. Ama bugün çoğu sohbet arayüzü token token akış bekliyor. Gateway'in bu akışı kesintisiz geçirmesi, bu arada da maliyeti ölçmesi, logu tutması ve guardrail uygulaması gerekiyor. Akış sırasında PII maskelemesi yapmak veya içerik filtrelemek, tam cevabı beklemekten teknik olarak çok daha zordur. Bu yüzden bir gateway seçerken ya da kurarken "akışı nasıl ele alıyor" sorusunu en başta sormanızı tavsiye ediyorum.

İkinci kritik karar çok sağlayıcılı soyutlama. İyi bir gateway, arkadaki sağlayıcıların farklı API şemalarını tek bir birleşik arayüze indirger. Yani uygulama kodunuz tek bir formatta istek atar; gateway bunu hedef sağlayıcının beklediği şekle çevirir. Bu sayede yarın bir modeli başka bir sağlayıcının modeliyle değiştirmek istediğinizde, onlarca uygulamayı tek tek elden geçirmek yerine sadece gateway konfigürasyonunu değiştiriyorsunuz. Bu soyutlama, satıcıya bağımlılığı (vendor lock-in) azaltan en önemli kaldıraçtır ve bence tek başına gateway'i hak ettiren özelliklerden biridir.

Gateway'in kalbi yönlendirmedir. Yani her isteği, doğru modele doğru gerekçeyle göndermek. Burada birkaç farklı yönlendirme stratejisini sahada sürekli kullanıyorum.

Görev karmaşıklığına göre yönlendirme. Her isteği en güçlü ve en pahalı modele göndermek baştan savma bir yaklaşımdır. Basit bir niyet sınıflandırması, kısa bir özet ya da bir biçimlendirme işi için devasa bir modele para ödemek israftır. Gateway, isteğin niteliğine bakarak basit görevleri küçük ve hızlı modellere, karmaşık akıl yürütme gerektiren görevleri ise güçlü modellere yönlendirebilir. Bu sınıflandırmayı kimi zaman kural tabanlı, kimi zaman küçük bir model üzerinden yapıyoruz. Önemli olan, "her şeyi en pahalıya gönder" alışkanlığından kurtulmak.

Maliyete göre yönlendirme. Aynı kalitede sonuç veren iki sağlayıcıdan o an daha uygun maliyetli olanı seçmek. Fiyatlandırmalar değişiyor, kampanyalar oluyor, bazı modeller belirli görevlerde aynı işi çok daha ucuza yapıyor. Gateway bu kararı merkezi olarak verdiğinde, fiyat değişikliğine uygulama kodunu hiç ellemeden adapte olabiliyorsunuz.

Gecikmeye göre yönlendirme. Kullanıcıya anlık cevap vermeniz gereken senaryolarda, o an en düşük gecikmeyi sunan sağlayıcıya gitmek isteyebilirsiniz. Gateway sağlayıcıların güncel yanıt sürelerini izleyip trafiği buna göre dağıtabilir.

Failover ve fallback. Bu, benim için gateway'in olmazsa olmazıdır. Bir sağlayıcı kesinti yaşadığında, hata döndürdüğünde ya da hız sınırına takıldığında gateway otomatik olarak ikincil bir sağlayıcıya geçer. Kullanıcı çoğu zaman bunun farkına bile varmaz. Tek sağlayıcıya bağımlı bir mimaride bir kesinti tüm ürünü yere serer; gateway'li bir mimaride aynı kesinti sadece bir konfigürasyon satırının devreye girmesi anlamına gelir.

Aşağıdaki tablo, bu yönlendirme stratejilerini ne zaman tercih ettiğimi özetliyor:

Yönlendirme stratejisi	Ne zaman öncelikli	Dikkat edilecek nokta
Görev karmaşıklığı	Karışık iş yükleri, çok sayıda basit görev	Yanlış sınıflandırma kaliteyi düşürür
Maliyet	Yüksek hacim, kaliteye duyarlılığı düşük görevler	En ucuz her zaman en iyi değildir
Gecikme	Gerçek zamanlı, kullanıcıya dönük arayüzler	Gecikme ile kalite arasında denge
Failover/fallback	Üretim ortamında her zaman	Yedek modelin kalitesi de test edilmeli

Yönlendirmede en sık yapılan hatayı da hemen söyleyeyim: sırf maliyet düşsün diye kaliteyi feda eden yönlendirme. Bir görevi daha ucuz bir modele kaydırdığınızda çıktının kalitesi düşerse, kullanıcı memnuniyetinde ve iş sonucunda kaybettiğiniz, kazandığınız token ücretinden çok daha pahalıya patlar. Bu yüzden yönlendirme kurallarını mutlaka kalite ölçümleriyle birlikte devreye almanızı öneriyorum.

Klasik cache, birebir aynı isteği tekrar görürse hazır cevabı döner. Ama LLM dünyasında insanlar aynı şeyi yüzlerce farklı şekilde sorar. "İade politikanız nedir", "ürünü nasıl iade ederim", "iade için ne yapmam lazım" — üçü de aynı anlamı taşır ama birebir string olarak farklıdır. Klasik cache bunların üçünü de ayrı görür ve üç kez modele gider.

Semantik cache işte burada devreye girer. Anlama göre cache yapar. Gelen isteğin anlamsal temsilini (embedding) çıkarır, daha önce sorulmuş benzer anlamlı sorularla karşılaştırır ve yeterince yakınsa cache'teki cevabı döner. Böylece aynı anlama gelen farklı ifadelerde modele tekrar tekrar gitmezsiniz. Bu hem maliyeti düşürür hem de gecikmeyi ciddi biçimde azaltır, çünkü cache'ten dönen cevap modele gitmekten çok daha hızlıdır.

Ama burada büyük bir uyarı yapmam gerekiyor, çünkü semantik cache yanlış kurgulandığında en sinsi hataları doğuruyor. İki soru anlamca yakın görünüp aslında farklı cevaplar gerektirebilir. "2024 iade politikası" ile "2025 iade politikası" anlamsal olarak çok yakındır ama cevapları farklı olmalıdır. Eğer benzerlik eşiğinizi gevşek tutarsanız, gateway yanlış cevabı cache'ten döndürür ve kullanıcıya güvenle yanlış bilgi verirsiniz. Bu yüzden semantik cache'te benzerlik eşiğini doğru ayarlamak, kişiselleştirilmiş veya zamana duyarlı cevapları cache'lememek ve cache geçerlilik süresini (TTL) bilinçli yönetmek hayati önemde.

"

Semantik cache'i bir kütüphane görevlisi gibi düşünün. İyi bir görevli, "bana benzer bir soru daha önce soruldu, cevabı şu" der ve size zaman kazandırır. Kötü kurgulanmış bir görevli ise "benzer bir şey sormuştun, al bu cevabı" deyip aslında sizin sorunuzla alakasız bir cevabı önünüze koyar. Aradaki fark, benzerliği ne kadar dikkatli ölçtüğünüzdür.

Cache geçersizleştirme (cache invalidation) bilgisayar biliminin en zor problemlerinden biri olarak ünlüdür ve LLM gateway'inde bu zorluk katlanır. İçerik güncellendiğinde eski cevapların cache'ten temizlenmesi gerekir; aksi halde kullanıcılara güncelliğini yitirmiş bilgi sunarsınız. Bu yüzden semantik cache'i sahaya alırken hangi içeriklerin cache'lenebilir, hangilerinin asla cache'lenemez olduğunu en baştan netleştirmenizi öneriyorum.

LLM çağrıları pahalıdır ve sağlayıcıların kendi hız sınırları vardır. Gateway, bu sınırları kurum içinde adil ve kontrollü dağıtmanızı sağlar. Bir ekip ya da bir özellik tüm kotayı tüketip diğerlerini aç bırakmasın diye ekip bazında, kullanıcı bazında veya özellik bazında kotalar tanımlayabilirsiniz.

Bu sadece teknik bir kısıt değil, aynı zamanda bir maliyet yönetişimi aracı. Bir geliştirici yanlışlıkla sonsuz döngüye girip binlerce çağrı yaptığında ya da bir saldırgan sisteminizi kötüye kullanmaya çalıştığında, gateway'deki kotalar sizi astronomik faturalardan korur. Kotaları sadece bir güvenlik önlemi olarak değil, ekiplere bütçe disiplini kazandıran bir mekanizma olarak da görüyorum.

Dağıtık sistemlerde geçici hatalar kaçınılmazdır. Bir sağlayıcı anlık olarak yanıt vermeyebilir, geçici bir ağ sorunu olabilir veya bir hız sınırına takılabilirsiniz. Gateway, bu geçici hataları akıllı bir yeniden deneme mantığıyla ele alır: üstel geri çekilme (exponential backoff) ile bekleyip tekrar dener, ama sonsuza kadar değil.

Devre kesici (circuit breaker) deseni ise bir sağlayıcı sürekli hata vermeye başladığında devreye girer. Bir sağlayıcının sağlıksız olduğunu tespit eden gateway, bir süreliğine o sağlayıcıya istek göndermeyi durdurur ve trafiği sağlıklı alternatiflere kaydırır. Böylece zaten boğulmuş bir sağlayıcıyı daha fazla istekle boğmaz, kendi sisteminizi de yanıt vermeyen çağrıları beklerken kilitlenmekten korursunuz. Bu desenleri her uygulamada ayrı ayrı yazmak yerine gateway katmanında bir kez doğru kurmak, hem kod tekrarını ortadan kaldırır hem de tutarlılık sağlar.

Benim için bir gateway'i gerçekten vazgeçilmez kılan şey gözlemlenebilirliktir. Çünkü göremediğiniz şeyi yönetemezsiniz. Gateway tüm LLM trafiğinizin tek geçiş noktası olduğu için, doğal olarak her şeyi gören tek nokta da odur.

İyi bir gateway şunları size sunar: her isteğin uçtan uca izlenmesi (tracing), hangi ekibin, hangi özelliğin, hangi kullanıcının ne kadar token ve maliyet ürettiğinin dökümü (cost attribution), gecikme dağılımları, hata oranları, hangi modellerin ne sıklıkla kullanıldığı. Ay sonu faturası geldiğinde "bu para nereye gitti" sorusuna saniyeler içinde cevap verebilmek, bence tek başına gateway yatırımını karşılayan bir kazanımdır.

Token ve maliyet atıfını ekip ve özellik bazında çıkarabilmek, kurum içinde yapay zeka kullanımının olgunlaşmasında dönüm noktasıdır. Çünkü ancak ölçtüğünüzde optimize edebilir, ancak gördüğünüzde sorumluluk dağıtabilirsiniz. Hangi özelliğin değer ürettiğini, hangisinin sadece para yaktığını ancak bu atıf verisiyle anlayabilirsiniz.

Burada en sık karşılaştığım sorun gözlemlenebilirlik kör noktalarıdır. Eğer bazı uygulamalar gateway'i atlayıp doğrudan sağlayıcıya gidiyorsa, o trafiği hiç göremezsiniz. Bu yüzden gateway'in gerçek değeri, kurum içindeki tüm LLM trafiğinin istisnasız ondan geçmesiyle ortaya çıkar. Atlanabilen bir gateway, gözlemlenebilirlik açısından yarım bir gateway'dir.

Gateway, kurumsal yapay zeka kullanımında güvenlik ve uyumun da en doğal yeridir. Çünkü tüm trafik buradan geçtiği için, koruma kurallarını burada bir kez tanımlayıp her uygulamaya otomatik uygulayabilirsiniz.

PII maskeleme. Kullanıcıdan gelen istemde T.C. kimlik numarası, telefon, e-posta, kredi kartı gibi kişisel veriler varsa, bunların model sağlayıcısına gitmeden önce gateway katmanında maskelenmesi ya da temizlenmesi gerekir. Bu, KVKK uyumu açısından kritik. Her uygulamada ayrı ayrı maskeleme kodu yazmak yerine gateway'de merkezi bir kural tanımladığınızda, hiçbir uygulamanın bu kuralı atlama ihtimali kalmaz.

İçerik filtreleme. Hem giren hem çıkan içeriğin zararlı, uygunsuz veya politikalarınıza aykırı olup olmadığını gateway kontrol edebilir. Prompt injection denemelerini, kötü niyetli girdileri ve uygunsuz çıktıları burada yakalamak, her uygulamada ayrı ayrı uğraşmaktan çok daha sağlıklıdır.

Guardrail'leri gateway'e koymanın en büyük avantajı tutarlılıktır. Güvenlik politikanız tek bir yerde yaşar, denetlenebilir ve güncellenebilir. On farklı ekibin on farklı şekilde maskeleme yapmasındansa, herkesin geçtiği kapıda tek bir doğru kural uygulanır.

Çok sağlayıcılı bir dünyada her sağlayıcının kendi API formatı, kendi kimlik doğrulama yöntemi ve kendi anahtarı vardır. Bu anahtarların kod içinde, ortam değişkenlerinde ya da farklı yerlerde dağınık durması ciddi bir güvenlik riski ve yönetim kabusudur.

Gateway, tüm sağlayıcıları tek bir birleşik API'nin arkasına alır. Uygulamalarınız sadece gateway ile konuşur, gateway de sağlayıcı anahtarlarını merkezi ve güvenli biçimde saklar. Bir anahtarı değiştirmeniz gerektiğinde tek bir yerde değiştirirsiniz; bir anahtar sızdığında tek bir yerden iptal edersiniz. Geliştiriciler artık üretim anahtarlarını hiç görmek zorunda kalmaz; onlar sadece gateway'in kendi erişim jetonunu kullanır. Bu, hem güvenlik hem de operasyonel sadelik açısından devasa bir kazanımdır.

Hangi modelin ya da hangi prompt'un sizin iş senaryonuzda daha iyi sonuç verdiğini ancak ölçerek bilebilirsiniz. Gateway, trafiğin bir kısmını bir modele, bir kısmını başka bir modele yönlendirerek kontrollü A/B testleri yapmanızı sağlar. Aynı şekilde farklı prompt varyasyonlarını yan yana deneyebilirsiniz.

Bunu gateway katmanında yapmanın güzelliği, uygulama kodunu hiç ellemeden deneyleri başlatıp durdurabilmenizdir. Yeni bir model çıktığında, onu önce trafiğin küçük bir yüzdesine açar, gözlemlenebilirlik verisiyle kalitesini ve maliyetini ölçer, sonuç tatmin ediciyse kademeli olarak genişletirsiniz. Bu, yapay zeka mimarinizi sürekli ve güvenli biçimde iyileştirmenin en olgun yoludur.

Gelelim en sık sorulan soruya: bu gateway'i kendim mi kurmalıyım, hazır bir çözüm mü almalıyım. Net bir tek cevabı yok; kurumunuzun ölçeğine, ekibinizin kapasitesine ve gereksinimlerinize bağlı. Ama karar verirken bakmanız gereken eksenleri paylaşabilirim.

Örnek araç kategorilerini de burada anmak isterim; bunları tavsiye olarak değil, ekosistemi tanımanız için örnek olarak veriyorum. Açık kaynak ve kendi kendine barındırılan tarafta LiteLLM gibi projeler birleşik bir API ve yönlendirme sunar. Portkey gibi çözümler hem yönetilen hem de barındırılabilen seçeneklerle gözlemlenebilirlik ve guardrail'lere odaklanır. Bulut sağlayıcı tarafında Cloudflare AI Gateway gibi yönetilen hizmetler caching ve gözlemlenebilirliği kenar (edge) üzerinde sunar. API gateway dünyasından gelen Kong AI Gateway gibi çözümler ise mevcut API altyapınızla bütünleşik bir yaklaşım getirir. Bunların her biri farklı dengelerle gelir; doğrusu sizin bağlamınızda hangisinin uyduğunu değerlendirmektir.

Aşağıdaki tablo kendin kur ile satın al arasındaki temel dengeyi özetliyor:

Boyut	Kendin kur (self-hosted/açık kaynak)	Satın al (yönetilen hizmet)
Kontrol ve özelleştirme	Yüksek	Sınırlı
Veri egemenliği / on-prem	Tam kontrol	Sağlayıcıya bağlı
Başlangıç hızı	Yavaş	Hızlı
Bakım yükü	Sizde	Sağlayıcıda
Maliyet yapısı	Altyapı + emek	Abonelik / kullanım
Uzmanlık gereksinimi	Yüksek	Düşük

Veri egemenliğinin kritik olduğu, kişisel verinin yurt dışına çıkmasının istenmediği senaryolarda kendi gateway'inizi on-prem ya da kendi bulutunuzda barındırmak çoğu zaman tek doğru yol oluyor. Buna birazdan KVKK başlığında daha ayrıntılı değineceğim. Öte yandan hızlı başlamak isteyen, ekip kapasitesi sınırlı kurumlar için yönetilen bir çözümle başlayıp ihtiyaç büyüdükçe kendi katmanınıza geçmek de makul bir yol.

Benim genel tavsiyem şu: en baştan devasa bir kendi gateway'inizi inşa etmeye girişmeyin. İhtiyacı net görün, küçük başlayın, gerçek trafikle öğrenin. Bir çözümün soyutlama katmanı yeterince temizse, ileride altındaki motoru değiştirmek görece kolaydır.

Türkiye'de kurumsal yapay zeka projelerinde en sık karşılaştığım tıkanma noktası teknik değil, yönetişimsel. "Bu veri nereye gidiyor, kim görüyor, loglanıyor mu, KVKK'ya uygun mu" soruları cevaplanmadan hiçbir ciddi proje üretime çıkamıyor. İşte gateway, tam da bu soruların cevabının verildiği yer.

Gateway'de PII maskeleme. Yukarıda teknik olarak bahsettim ama yönetişim açısından da vurgulamam gerekiyor: kişisel verinin model sağlayıcısına ulaşmadan önce maskelenmesi, KVKK'nın veri minimizasyonu ilkesiyle birebir örtüşür. Gateway bu maskelemeyi merkezi, denetlenebilir ve atlatılamaz biçimde uygular.

Denetim loglaması (audit logging). Hangi kullanıcının, hangi veriyle, hangi modele, ne zaman istek attığını eksiksiz loglamak, hem iç denetim hem de yasal yükümlülükler için gereklidir. Gateway tek geçiş noktası olduğu için bu denetim kaydını eksiksiz ve tutarlı tutabileceğiniz tek yer de odur. Bir veri ihlali şüphesinde ya da bir denetimde, "kim neye erişti" sorusuna güvenle cevap verebilmek paha biçilmezdir.

On-prem / egemen gateway ve veri ikametgâhı. Kişisel verinin Türkiye sınırları içinde kalması gereken senaryolarda, gateway'i kendi altyapınızda barındırıp trafiği kontrol altında tutmak, veri ikametgâhı (data residency) gereksinimlerini karşılamanın en sağlam yoludur. Egemen bir gateway, hangi verinin hangi sağlayıcıya gidebileceğini kural bazında belirler; örneğin hassas veri içeren çağrıları yalnızca yurt içi ya da onaylı sağlayıcılara yönlendirir.

Maliyet yönetişimi. Kurumsal yapay zeka harcamasının kontrolden çıkmaması için, kim ne harcıyor görünür olmalı. Gateway'in maliyet atıf verisi, bütçe sahiplerine sorumluluk ve finans ekiplerine öngörülebilirlik kazandırır.

Gölge yapay zeka (shadow AI) kontrolü. En sinsi risklerden biri, ekiplerin kurumsal kontrol dışında, kendi başlarına yapay zeka araçlarına kurumsal veri akıtmasıdır. Tüm trafiğin gateway'den geçmesini zorunlu kıldığınızda, bu gölge kullanımı görünür kılar ve yönetilebilir hale getirirsiniz. Görmediğiniz kullanımı yönetemezsiniz; gateway ise tam olarak görünürlüğü sağlar.

Avrupa Birliği AI Act'i ve onun etkisiyle şekillenen düzenleyici iklim, yapay zeka sistemlerinde izlenebilirlik ve loglamayı giderek daha fazla zorunlu kılıyor. Yüksek riskli kullanım senaryolarında, sistemin nasıl çalıştığını, hangi kararları neden verdiğini ve hangi verilerle çalıştığını kayıt altına almak bir uyum gereksinimi hâline geliyor. Türkiye'deki kurumlar da hem Avrupa'ya hizmet verdikleri ölçüde hem de yerel düzenlemelerin bu çerçeveyle yakınsaması nedeniyle bu gereksinimlere hazırlanmak durumunda.

İşte gateway'in loglama ve izlenebilirlik yetenekleri, bu uyum yükünün önemli bir kısmını doğal olarak karşılar. Her çağrının kaydının tutulması, hangi modelin kullanıldığının izlenebilmesi, girdi ve çıktıların denetlenebilir biçimde saklanması — bunlar zaten iyi bir gateway'in sunduğu şeyler. Yani gateway'i sadece bir performans veya maliyet aracı olarak değil, uyum altyapınızın bir parçası olarak da konumlandırabilirsiniz. Düzenleme geldiğinde panikle altyapı kurmak yerine, baştan izlenebilir bir mimari kurmuş olmak çok büyük bir avantaj.

Şimdi de teorinin ötesine geçip, danışmanlık projelerinde tekrar tekrar karşılaştığım hataları ve bunlardan nasıl kaçınacağınızı paylaşmak istiyorum. Çünkü gateway kurmak bir şey, doğru kurmak başka bir şey.

Tuzak 1: Cache geçersizleştirmeyi ihmal etmek. Semantik cache'i coşkuyla devreye alan ekiplerin çoğu, içerik güncellendiğinde eski cevapların cache'te kalmaya devam ettiğini fark etmiyor. Kullanıcılar günlerce eski bilgiyle karşılaşıyor. Çözüm: hangi içeriğin cache'lenebileceğini, TTL'in ne olacağını ve içerik değişiminde cache'in nasıl temizleneceğini en baştan tasarlamak.

Tuzak 2: Kaliteyi düşüren yönlendirme. Sırf maliyet düşsün diye agresif biçimde ucuz modellere kaydırılan trafik, çıktı kalitesini sessizce eritir. Kullanıcı şikayet etmeye başladığında iş işten geçmiş olur. Çözüm: her yönlendirme kuralını kalite ölçümleriyle birlikte devreye almak ve düzenli olarak çıktı kalitesini izlemek.

Tuzak 3: Gözlemlenebilirlik kör noktaları. Bazı uygulamalar gateway'i atlayıp doğrudan sağlayıcıya gidiyorsa, o trafiğin maliyetini, riskini ve davranışını hiç göremezsiniz. Çözüm: gateway'i atlanamaz kılmak; mümkünse sağlayıcı anahtarlarına doğrudan erişimi tamamen kapatıp tek çıkış yolunu gateway yapmak.

Tuzak 4: Gateway'i tek hata noktasına dönüştürmek. Tüm trafik gateway'den geçtiği için, gateway çökerse her şey çöker. Çözüm: gateway'i yüksek erişilebilirlikle, yedekli ve ölçeklenebilir biçimde kurmak. İronik biçimde, failover sağlayan katmanın kendisinin failover'a ihtiyacı vardır.

Tuzak 5: Akış senaryolarını sonradan düşünmek. Senkron istek-cevap için tasarlanmış bir gateway'e sonradan akış (streaming) eklemeye çalışmak acı verir. Çözüm: akış gereksinimini en baştan mimariye dahil etmek.

Tuzak 6: Guardrail'leri performans uğruna kapatmak. PII maskeleme ve içerik filtreleme bir miktar gecikme ekler. Bazı ekipler "yavaşlatıyor" diye bunları kapatma eğiliminde oluyor. Çözüm: guardrail'leri bir lüks değil, uyum ve güvenliğin olmazsa olmazı olarak görmek; gecikmeyi optimize etmek ama korumayı kaldırmamak.

"

Sahada öğrendiğim en önemli ders şu: gateway bir kez kurulup unutulan bir altyapı değildir. Yaşayan, sürekli ayarlanan, gözlemlenen ve iyileştirilen bir kontrol düzlemidir. Onu canlı tutan da arkasındaki disiplindir.

Bütün bunları okuyup "tamam da nereden başlayacağım" diyorsanız, sahada işe yaradığını gördüğüm kademeli bir yaklaşımı paylaşayım. Hiçbir kurumun her şeyi bir gecede kurması gerekmiyor; doğrusu, değeri erken görüp güveni adım adım inşa etmek.

İlk adımda gateway'i şeffaf bir geçiş katmanı olarak devreye alın. Hiçbir akıllı yönlendirme, cache ya da guardrail olmadan, sadece tüm trafiğin ondan geçtiği bir kapı kurun. Bu aşamada tek hedefiniz gözlemlenebilirlik: kim ne kadar token harcıyor, hangi modeller ne sıklıkla kullanılıyor, maliyet nereye gidiyor. Bu veriyi görmek bile çoğu kurumda gözleri açar.

İkinci adımda güvenlik ve uyum katmanını ekleyin: merkezi anahtar yönetimi, PII maskeleme, denetim loglaması. Bu, hukuk ve güvenlik ekiplerinizin güvenini kazanır ve projeyi yönetişim açısından sağlam zemine oturtur.

Üçüncü adımda dayanıklılık desenlerini devreye alın: failover, yeniden deneme, devre kesiciler, kotalar. Artık sisteminiz tek bir sağlayıcının kesintisinde yere serilmiyor.

Dördüncü adımda optimizasyona geçin: önce muhafazakâr eşiklerle semantik cache, sonra kalite ölçümleriyle desteklenmiş model yönlendirme. Burada acele etmeyin; her optimizasyonu kalite verisiyle doğrulayarak ilerleyin.

Son adımda ise sürekli iyileştirme kültürünü kurun: model ve prompt A/B testleri, yeni modellerin kontrollü denenmesi, eşiklerin düzenli gözden geçirilmesi. Gateway artık bir altyapı parçası değil, yapay zeka stratejinizin kontrol kulesi.

Şimdi tüm bunları sizin bağlamınıza oturtmak için, bir danışman olarak bir kurumda işe nereden başlardım onu anlatayım. Önce mevcut durumu çıkarırdım: hangi ekipler hangi modelleri, hangi sağlayıcılarla kullanıyor, anahtarlar nerede duruyor, kim ne kadar harcıyor, hukuk hangi endişeleri taşıyor. Bu envanteri çıkarmadan atılan her adım körlemesine olur.

Sonra en acil acıyı tespit ederdim. Bazı kurumda bu kontrolsüz maliyet, bazısında failover eksikliği, bazısında ise KVKK endişesi oluyor. Gateway'i önce o acıyı dindirecek minimum yetenekle devreye alır, hızlı bir kazanım gösterip güven inşa ederdim. Çünkü kurumsal dönüşümde en kıymetli para, ekiplerin ve yöneticilerin güvenidir.

Ardından gateway'i kademeli olarak zenginleştirirdim — yukarıdaki planın adımlarıyla. Her adımda "bunu ölçebiliyor muyuz, bu kuralı denetleyebiliyor muyuz, bir şey ters gittiğinde geri alabiliyor muyuz" sorularını sorardım. Çünkü iyi bir gateway, sadece ne yaptığını değil, ne yaptığını nasıl kanıtlayacağını da bilen bir katmandır.

Ve en önemlisi, bunu bir kerelik bir proje değil, yaşayan bir disiplin olarak konumlandırırdım. Modeller değişiyor, fiyatlar değişiyor, düzenlemeler değişiyor, kurumun ihtiyaçları değişiyor. Gateway, tüm bu değişime kurumunuzun tek bir noktadan, sakin ve kontrollü biçimde cevap verebilmesini sağlayan katmandır. Onu doğru kurarsanız, yapay zeka maceranızın her aşamasında elinizi rahatlatan, görünmez ama vazgeçilmez bir omurgaya dönüşür. Eğer kurumunuzda LLM trafiği artık birkaç dağınık entegrasyonun ötesine geçtiyse, bence bu katmanı konuşmanın tam zamanı; çünkü bu trafiği yönetmeyi ne kadar geciktirirseniz, sonradan toparlamanın maliyeti o kadar büyüyor.