İkinci AI sağlayıcısı yetmez: Kesinti planını uçtan uca sınayın

AI hizmeti kesinti planı hazırlamak için önce AI’ye bağlı işleri envantere alın; ardından her kritik görev için işlevsel bir alternatif, izinli veri sınırı, hazır kimlik bilgileri, taşınabilir bağlam, manuel çalışma yolu ve düzenli tatbikat tanımlayın. Başarı ölçütü ikinci sağlayıcının varlığı değil, ana hizmet devre dışıyken aynı iş sonucunun yeni erişim talebi veya mühendis müdahalesi olmadan üretilebilmesidir.

Bu yaklaşım yalnızca API kullanan uygulamaları değil, sohbet araçlarını, kodlama yardımcılarını ve bunlara bağlanan otomasyonları da kapsamalı. OpenAI’nin 3 Eylül 2026 olay kaydı, yükselen hata oranlarının ChatGPT ile birlikte Codex bileşenlerini de etkilediğini gösteriyor; dolayısıyla bir sohbet ekranının açılması, bağlı iş akışının tamamının çalıştığı anlamına gelmez.

1. AI bağımlılıklarını görev düzeyinde çıkarın

Envanteri satın alınan ürünlerin listesi olarak değil, tamamlanması gereken görevlerin haritası olarak kurun. Her satırda iş sahibi, kullanılan model veya arayüz, girdinin geldiği sistem, çıktının gittiği sistem, kabul edilebilir bekleme süresi ve kesinti sırasında doğacak operasyonel sonuç bulunmalı.

Önceliği, durduğunda müşteriyi, geliri, mevzuat yükümlülüğünü ya da üretim hattını etkileyen görevlere verin. Müşteri yanıtı taslağı, yazılım değişikliği incelemesi ve kurum içi özetleme aynı sağlayıcıyı kullansa bile farklı veri, izin ve doğrulama ihtiyaçlarına sahiptir; bu nedenle tek bir genel “AI yedeği” kaydı yeterli olmaz.

• Görevin tetikleyicisini ve beklenen nihai çıktısını yazın.
• Model dışındaki bağımlılıkları kaydedin: dosya deposu, arama dizini, eklenti, kimlik sağlayıcı, ağ geçidi ve insan onayı.
• Görevi kritik, ertelenebilir veya kesinti boyunca durdurulabilir olarak sınıflandırın.
• Her kritik görev için teknik ve operasyonel bir sorumlu belirleyin.

Bu çalışma, ortak altyapı bağımlılıklarını da görünür kılar. IT Pro’ya konuşan uzmanlar, AI kullanılabilirliğinin iş sürekliliği meselesi olarak ele alınmasını; çoklu model stratejileri, yedek iş akışları, iş sürekliliği planları ve altyapıyı da kapsayan bağımlılık haritaları kurulmasını öneriyor.

2. İşlevsel eşdeğerliği ve veri sınırını ayrı ayrı doğrulayın

İkinci adım, alternatifin aynı görevi gerçekten tamamlayıp tamamlamadığını ölçmektir. Model adları veya genel yetenek tabloları bunun için yeterli değildir. Aynı temsilî girdiyi iki yolda çalıştırın; çıktı biçimini, gerekli araç çağrılarını, dil kalitesini, gecikmeyi ve insan kontrolü ihtiyacını görevin kabul ölçütleriyle karşılaştırın.

Birincil yol yapılandırılmış JSON üretiyor, şirket belgelerinde arama yapıyor veya kod deposuna değişiklik önerisi gönderiyorsa alternatif yolun da bu zinciri tamamlaması gerekir. Bire bir eşdeğerlik mümkün değilse daha dar ama güvenli bir çıktı tanımlayın; örneğin otomatik gönderim yerine insan onayına düşen bir taslak üretin. Bu, başarısızlık değil önceden kararlaştırılmış azaltılmış hizmet seviyesidir.

Üçüncü adım, veri sınırıdır. Yedek sağlayıcı teknik olarak uygun olsa bile kişisel veri, ticari sır, müşteri içeriği veya kaynak kodu o ortama aktarılmaya yetkili olmayabilir. Her görev için hangi veri sınıflarının gönderilebileceğini, saklama ve kayıt ayarlarını, coğrafi ya da sözleşmesel kısıtları ve kesintide de geçerli olacak maskeleme kurallarını yazılı hale getirin.

3. Kimlik bilgilerini, izinleri ve bağlamı önceden hazırlayın

Dördüncü adım, erişimin kesinti anından önce çalışır durumda olmasıdır. API anahtarlarını veya kurumsal oturumu onaylı gizli bilgi kasasında tutun; anahtarın süresini, kota ve faturalandırma durumunu, ağ izinlerini ve servis hesabının rolünü düzenli olarak doğrulayın. Acil durumda ilk kez hesap açmak ya da satın alma onayı beklemek, yedek plan değil yeni bir projedir.

Beşinci adım, bağlamı sağlayıcıdan bağımsız hale getirmektir. Kritik sistem istemlerini, çıktı şemalarını, örnekleri, araç tanımlarını ve gerekli çalışma talimatlarını sürümlü bir depoda saklayın. Sohbet geçmişini körlemesine taşımak yerine görevin devamı için gereken asgari bağlamı çıkarın; hassas veriyi temizleyin ve alternatif model için önceden doğrulanmış bir istem sürümü bulundurun.

eWeek’in sağlayıcı zaman çizelgesi analizi, ChatGPT, Claude ve Grok için doğrulanmış kesinti sürelerinin 93 dakika örtüştüğünü hesaplıyor. Analiz ayrıca bir yük devretme tatbikatının kimlik doğrulama, API uyumluluğu, bağlam aktarımı, izinler ve çalışan hazırlığındaki açıkları gösterebileceğini belirtiyor; Gemini ise tutarlı başlangıç ve toparlanma zamanları bulunmadığı için süre hesabına katılmadı.

4. AI olmadan çalışacak kontrollü bir yol kurun

Altıncı adım, sağlayıcıların hiçbiri kullanılamadığında uygulanacak manuel yolu tanımlamaktır. Bu yol normal sürecin bütün hızını korumak zorunda değildir; güvenli bir asgari hizmet üretmelidir. Hazır yanıt şablonları, insan tarafından yapılan sınırlı sınıflandırma, kuyrukta bekletme veya yalnızca yüksek öncelikli kayıtların işlenmesi uygun seçenekler olabilir.

Manuel prosedür; kimin geçiş kararı vereceğini, işlerin nerede kuyruğa alınacağını, hangi çıktıların yasak olduğunu ve normale dönüşte biriken kayıtların nasıl uzlaştırılacağını açıklamalı. AI çıktısının daha sonra geriye dönük eklenmesi veri bütünlüğünü bozacaksa bunu da baştan engelleyin. Kullanıcıya gösterilecek hizmet durumu mesajı ile kurum içi operasyon talimatını birbirinden ayırın.

5. Planı arıza enjekte ederek sınayın

Yedinci adım, ana modeli kontrollü biçimde devreden çıkaran uçtan uca tatbikattır. Üretim verisini riske atmayan bir ortam ve temsilî görev seçin; ana uç noktayı erişilemez kılın, alarmın oluşmasını bekleyin ve ekipten çalışma kitabını kullanarak alternatif yola geçmesini isteyin. Sonuç yalnızca API’nin yanıt vermesiyle değil, iş çıktısının hedef sisteme güvenli biçimde ulaşmasıyla ölçülmeli.

1. Kesintinin algılanma, karar ve geçiş zamanlarını kaydedin.
2. Yeni yetki, istem düzenleme veya mühendis müdahalesi gerekip gerekmediğini not edin.
3. Çıktıyı önceden belirlenmiş kalite, biçim ve veri güvenliği ölçütleriyle kontrol edin.
4. Alternatif de kapanınca manuel yolun başlayabildiğini doğrulayın.
5. Birincil hizmet döndüğünde çift işleme, kayıp kayıt ve çelişkili çıktı kontrolü yapın.

Tatbikat, görev sahibi alternatif yoldan kabul edilebilir sonucu üretemiyorsa başarısız sayılmalı; yalnızca yedek uç noktaya bağlantı kurulması başarı değildir. Her başarısızlık için sorumlu ve düzeltme tarihi atayın, istemlerle erişim belgelerini güncelleyin ve görevin kritikliğine uygun aralıkla testi tekrarlayın. Böylece kesinti planı, tedarikçi listesinden uygulanabilir bir operasyon prosedürüne dönüşür.

Ayrıca okuyun:

• AI iş akışında çıktı sayısı yetmez: Ölçülmesi gereken gerçek sonuç
• Kripto borsası seçerken logo yetmez: SPK listesindeki kritik dipnot