Anthropic Fable 5 ve Mythos 5 erişimi neden kapandı?

12 Haziran gecesi tam olarak ne oldu?

Olayın iskeleti şöyle: bir hükümet, ulusal güvenlik gerekçesiyle Anthropic'e Fable 5 ve Mythos 5 modellerine erişimi askıya alma talimatı verdi. Anthropic, yasal talimata uymak zorunda olduğu için bu iki modeli tüm müşterileri — hatta kendi yabancı uyruklu çalışanları — için kapatmak durumunda kaldı. Şirket direktife katılmadığını, gerekçe gösterilen güvenlik endişesinin dar kapsamlı ve sektördeki başka modellerde de görülen türden olduğunu açıkladı; erişimi yeniden açmak için süreci yürüttüğünü belirtti. Geri kalan modelleri etkilenmedi.

Ayrıntıların doğrusu zamanla netleşecek; ama bizim için kritik olan nokta tek bir cümleye sığıyor: kararı veren de, onu uygulayan da müşteri değildi. Modele bağlı bir ürün işleten ekip için bu, hiçbir uyarı ya da hazırlık penceresi olmadan gelen bir kesinti anlamına geldi. Yapay zekâ çağının sessiz riski de tam olarak burada saklı: artık sadece "model ne kadar iyi" diye değil, "yarın hâlâ erişebilecek miyim" diye de sormak gerekiyor.

Tek modele bağımlılık neden bu kadar riskli?

Bir modeli seçerken konuştuğumuz şeyler genelde kalite eksenindedir: hangisi daha isabetli, hangisi daha hızlı, hangisi daha ucuz. Bu olay, çoğu zaman ikinci plana attığımız bir ekseni öne çıkarıyor — süreklilik. Bir model teknik olarak en iyisi olabilir; ama tek kaynaklıysa, kapalı uçluysa ve sizin sözleşmenizin dışındaki güçlerce kapatılabiliyorsa, o "en iyi" sıfatının altında sessiz bir tek nokta arıza (single point of failure) yatıyor demektir.

Bu, sağlayıcıya bağımlılık (vendor lock-in) sorununun yapay zekâya özgü, daha keskin bir hâli. Bir bulut bölgesi çökebilir, bir API sürümü emekliye ayrılabilir, bir fiyat listesi gecede değişebilir — bunları yıllardır biliyoruz. AI'da farklı olan, bağımlılığın derinliği: model çoğu zaman ürünün çekirdek davranışını üretiyor, kolayca "başka bir kütüphaneyle değiştir" diyemeyeceğiniz kadar içeride. Bağımlılık ne kadar derinse, kesintinin yarattığı blast radius de o kadar geniş olur.

TEK MODELE BAĞLI           SOYUTLANMIŞ + YEDEKLİ
────────────────           ─────────────────────
model kapanır              model kapanır
   ↓                          ↓
çağrı hata döner           arayüz yedek modele geçer
   ↓                          ↓
ürün durur                 ürün çalışır (biraz yavaş)
   ↓                          ↓
acil müdahale              planlı düşüş, kesinti yok
kurtarma: saatler–günler     kurtarma: saniyeler

Dayanıklılık nasıl tasarlanır?

Buradaki temel fikir aslında sade: modeli ürününüzün ayrılmaz bir organı gibi değil, gerektiğinde sökülüp yenisi takılabilen değiştirilebilir bir parça gibi tasarlamak. Sağlayıcı değişse, model kapansa, hatta fiyat bir gecede üçe katlansa bile sisteminiz ayakta kalabilmeli — belki daha yavaş, belki daha sade, ama çalışır halde. İyi haber, bu riski sıfırlamak mümkün olmasa da büyük ölçüde yönetilebilir olması; üstelik kullanılan yöntemler yeni değil, sağlayıcı bağımsızlığı için yıllardır uyguladığımız sağlam yazılım alışkanlıklarının yapay zekâya taşınmış hâli. Pratikte dört yön öne çıkıyor.

Modeli bir arayüzün arkasına koyun

Kodunuz doğrudan tek bir sağlayıcının istemcisini çağırıyorsa, o sağlayıcı sizin mimarinizin bir parçası olmuş demektir. Bunun yerine kendi tanımladığınız ince bir soyutlama katmanına (abstraction layer) çağrı yapın; hangi modelin arandığı bu katmanın içinde, tek bir yerde dursun. Böylece model değiştirmek, yüzlerce dosyaya dokunmak değil, tek bir ayarı çevirmek olur.

İkinci bir model her zaman hazır olsun

Bir fallback zinciri kurun: birincil model yanıt vermediğinde istek otomatik olarak ikinci bir sağlayıcıya, oradan da daha mütevazı bir modele düşsün. İkinci modelin en iyisi olması gerekmez; kesinti anında "çalışan", "yeterince iyi" olması yeter. En kötü senaryoyu test edin — birincil sağlayıcıyı bilerek kapatıp ürününüz ayakta kalıyor mu, görün.

Elinizin altında kendi çalıştırabileceğiniz bir model bulunsun

Tüm yedekleriniz de aynı dış sağlayıcı ailesindeyse, gerçek bir çeşitlilikten söz edemeyiz. Açık kaynak, kendi altyapınızda çalıştırabileceğiniz (self-host) daha küçük bir model, en kötü günde son emniyet ağıdır: kimse onu uzaktan kapatamaz. Bu, daha önce yazılımın AI ajanlarına geçişini ele aldığımız yazıda değindiğimiz "küçük, işe özel modeller" eğiliminin pratik bir faydası — kalite kadar dayanıklılık da kazandırıyor.

Kontrollü düşüşü baştan tasarlayın

Her özelliğin AI'sız bir "asgari çalışır hâli" olsun. Model devre dışıyken arama daha basit bir yöntemle dönsün, öneri yerine varsayılan gösterilsin, otomatik özet yerine ham içerik sunulsun. Amaç, AI kesildiğinde ürünün çökmesi değil, sadeleşmesi. Kullanıcı bir özelliğin bugün daha yalın çalıştığını fark eder; ama kapının kapandığını görmez.

Peki ekipler bugün ne yapmalı?

Bu tek olay yüzünden mevcut sağlayıcınızı bırakmanız gerekmez. Gereken, bağımlılığınızı görünür kılmak ve en kötü güne hazırlanmak. Sade bir kontrol listesi:

• Bağımlılığınızı haritalayın — hangi özellik hangi modele bağlı ve o model kapanırsa ne durur? Bu envanter olmadan riski konuşmak mümkün değil.
• Çağrıları tek bir katmanda toplayın — sağlayıcıya özel kodu uygulamanın her yerine dağıtmayın. Değiştirilebilirlik, ancak tek bir değişim noktası varsa gerçektir.
• En az bir gerçek alternatifi test edin — ikinci bir sağlayıcıya ya da self-host bir modele geçişi tatbikat olarak deneyin. Kâğıt üzerindeki yedek, yedek değildir.
• Kritik veriyi tek sağlayıcıya kilitlemeyin — istem kalıpları, değerlendirme setleri ve veriniz taşınabilir kalsın ki başka bir modele geçiş haftalar değil günler sürsün.
• Kesinti senaryosunu planınıza yazın — "model erişilemez" durumu, tıpkı bir bölge kesintisi gibi olağan bir başa çıkma senaryosu olsun; sürpriz değil, tatbikatı yapılmış bir durum.

Peki geriye ne kalıyor?

12 Haziran'daki olay, yapay zekânın ne kadar iyi olduğuyla ilgili bir tartışma gibi başladı; ama altyapı kuran ekipler için asıl ders başka yerde. Bir model, sizin hiçbir hatanız olmadan, bir gecede erişime kapanabiliyor. Bu, AI'dan kaçınmak için değil, AI'ı doğru konumlandırmak için bir gerekçe: modeli ürününüzün ayrılmaz bir organı değil, gerektiğinde değiştirebileceğiniz güçlü bir bileşen olarak tasarlayın.

Soyutlama katmanı, fallback zinciri, elinizin altında kendi çalıştırdığınız bir model ve kontrollü düşüş — bunların hiçbiri yeni mucitler değil; sağlayıcı bağımsızlığı için yıllardır bildiğimiz disiplinlerin yapay zekâ çağına taşınmış hâli. Tek değişen, bu disiplinleri artık ürününüzün en görünür özelliğine de uygulamanız gerektiği.

Konunun temellerine daha yakından bakmak isterseniz Bilgi Merkezi · Yazılım & Mimari, API Tasarımı & Entegrasyon, DevOps & Otomasyon ve Gözlemlenebilirlik & Loglama rehberlerine göz atabilirsiniz.