Perakende BT’sinde iş sürekliliği soyut bir kavram değildi. Bir bölgedeki mağazaların ağ bağlantısı koptuğunda kasaların çalışmaya devam etmesi, veri merkezi durduğunda ERP’nin felaket kurtarma merkezinden ayağa kalkması gerekiyordu. HPE SimpliVity projemizde yedekleme ve geri yüklemeyi bu yüzden en çok önemsediğimiz konulardan biri yaptık. SD-WAN geçişinde de aynı soruyu sorduk: bağlantı koparsa mağaza ne yapar?
Bugün yapay zekâ birçok sürecin içine giriyor: müşteri hizmetlerinde cevap önerisi, depoda sevkiyat doğrulaması, fabrikada kalite kontrol, sahada iş güvenliği uyarısı. Bir süreç yapay zekâya bağımlı hâle geldiğinde, yapay zekânın kesintisi de bir iş sürekliliği riski oluyor. Ama mevcut planların çoğu bu bağımlılığı içermiyor.
Yapay zekâya özgü üç kesinti türü
| Kesinti | Örnek | Nasıl fark edilir |
|---|---|---|
| Hizmetin durması | Bulut yapay zekâ sağlayıcısının kesintisi, GPU sunucusunun arızası | Erişilebilirlik izlemesi, hata oranı |
| Sessiz bozulma | Model çalışıyor ama sonuçlar kötüleşmiş: veri değişmiş, sağlayıcı modeli güncellemiş, kamera açısı kaymış | Sonuç kalitesi izlemesi, kullanıcı bildirimleri |
| Veri hattının kopması | ERP güncellemesiyle bir alan boş gelmeye başlamış, kamera akışı kesilmiş | Beklenen veri hacmi ve şema izlemesi |
İlk tür, klasik felaket kurtarma planlarının bildiği bir şey. Diğer ikisi yapay zekâya özgü ve daha tehlikeli; çünkü sistem çalışır görünüyor. Bir süre kimse fark etmeden yanlış sonuçlar üretilmeye devam edebiliyor.
Sessiz kesintiye karşı: sonuç kalitesini izleyin
Erişilebilirlik izlemesi “sistem cevap veriyor mu?” sorusunu soruyor. Yapay zekâda yeterli değil. Ek olarak şunlar izlenmeli:
- Çıktı dağılımı: Modelin ürettiği sınıfların, skorların ya da uyarı sayısının olağan aralıktan sapması. Bir günde uyarı sayısının birden sıfıra düşmesi ya da on katına çıkması bir şeylerin bozulduğunun işareti.
- Girdi dağılımı: Modele gelen verinin özelliklerinin değişmesi; örneğin görüntülerin parlaklığı, metinlerin uzunluğu, alanların boş gelme oranı.
- Örneklem kontrolü: Sonuçların küçük bir bölümünün düzenli olarak insan tarafından kontrol edilmesi.
- Kullanıcı bildirimleri: “Bu sonuç yanlış” bildirimlerinin sayısı ve eğilimi.
Sahada çalışan modellerin zamanla nasıl bozulduğunu ve bunu nasıl yakaladığımızı tespit modellerini sahada ayakta tutmak yazımda anlattım.
Her süreç için bir geri düşüş modu
Her yapay zekâ destekli süreç için şu soru cevaplanmalı: yapay zekâ çalışmazsa bu süreç nasıl devam eder? Üç tip cevap var:
- Manuel süreç: Yapay zekâ öncesindeki yöntem. Bu cevap ancak o yöntemi bilen ve uygulayabilecek kişiler hâlâ varsa geçerli; yapay zekâ yıllarca çalıştıktan sonra manuel süreç unutulmuş olabiliyor.
- Kural tabanlı yedek: Daha basit ama öngörülebilir bir kural seti; örneğin dil modeli yerine anahtar kelimeye dayalı yönlendirme.
- Önceki model sürümü ya da ikinci sağlayıcı: Yeni sürüm sorun çıkardığında geri dönülebilecek kararlı bir sürüm ya da hazırda bekleyen alternatif bir model.
Geri düşüş moduna kimin, hangi koşulda ve ne kadar sürede geçeceği yazılı olmalı. Ve en önemlisi, düzenli olarak denenmeli. Hiç denenmemiş bir geri düşüş planı, ihtiyaç anında çalışmıyor.
Dış sağlayıcıya bağımlılığı azaltmak
Kritik süreçler tek bir dış yapay zekâ sağlayıcısına bağlıysa şunlar yardımcı oluyor:
- Sağlayıcıya özgü arayüzleri bir soyutlama katmanının arkasına almak; böylece sağlayıcı değiştirmek uygulamanın tamamını değiştirmeyi gerektirmiyor.
- İkinci bir sağlayıcıyı ya da şirket içinde çalışan daha küçük bir modeli alternatif olarak hazır tutmak.
- Sözleşmede hizmet seviyesi, kesinti bildirimi ve model değişikliği bildirimini düzenlemek; bunu yapay zekâ tedarikçi sözleşmesi yazımda ayrıntılı anlattım.
- Kritik ve gecikmeye duyarlı işlemeyi mümkünse sahada ya da şirket içinde yapmak. Bağlantı koptuğunda çalışmaya devam etmesi gereken sistemler için edge mi bulut mu yazımdaki değerlendirme bu açıdan da geçerli.
Model de bir yedeklenecek varlıktır
Klasik felaket kurtarma planları veritabanlarını ve sunucuları yedekliyor. Yapay zekâ için ek olarak şunlar yedeklenmeli:
- Model dosyaları ve sürüm geçmişi.
- Yapılandırma, eşikler ve kurallar.
- Eğitim ve test verisi; özellikle etiketlenmiş veri, yeniden üretmesi en pahalı varlık.
- Veri hattı tanımları ve altyapı kodu.
Her biri için hedef kurtarma süresi (RTO) ve kabul edilebilir veri kaybı (RPO) belirlenmeli ve geri yükleme düzenli olarak test edilmeli. Bu konuda NIST SP 800-34 acil durum planlaması için ayrıntılı bir rehber; yönetim sistemi düzeyinde ise ISO 22301 iş sürekliliğinin çerçevesini çiziyor.
Mevcut plana eklenecek beş madde
- Yapay zekâ destekli süreçlerin listesi ve her birinin iş etkisi.
- Her süreç için geri düşüş modu, sorumlusu ve geçiş koşulu.
- Sonuç kalitesi ve veri hattı izlemesi; yalnızca erişilebilirlik değil.
- Model, yapılandırma ve eğitim verisi için yedekleme, RTO ve RPO.
- Yılda en az bir kez geri düşüş ve geri yükleme tatbikatı.
Yapay zekâ bir sürecin içine girdiğinde, o süreç onsuz da çalışabilmeli. Bu, yapay zekâya güvenmemek değil; kurumsal BT’nin her kritik sisteme gösterdiği özeni yapay zekâya da göstermek.
Sık sorulan sorular
Yapay zekâ hizmeti durursa ne olur?
Bu, sürecin yapay zekâya ne kadar bağımlı olduğuna ve önceden tanımlanmış bir geri düşüş modu olup olmadığına bağlıdır. İyi bir planda her yapay zekâ destekli süreç için manuel süreç, kural tabanlı yedek ya da önceki model sürümü gibi bir alternatif ve bu alternatife kimin, ne zaman geçeceği tanımlıdır.
Yapay zekâda sessiz kesinti nedir?
Hizmetin çalışmaya devam etmesine rağmen sonuçlarının bozulmasıdır. Veri dağılımı değişmiş, kamera açısı kaymış, sağlayıcı modeli güncellemiş ya da veri hattında bir alan boş gelmeye başlamış olabilir. Erişilebilirlik izlemesi bunu yakalamaz; sonuç kalitesini ölçen izleme gerekir.
Yapay zekâ için felaket kurtarma planında neler olmalı?
Model dosyaları ve sürümleri, yapılandırma ve kurallar, eğitim ve test verisi, veri hattı tanımları ve altyapı kodu yedeklenmeli; hedef kurtarma süresi ve veri kaybı toleransı belirlenmeli; geri yükleme düzenli olarak test edilmelidir.
Dış yapay zekâ sağlayıcısına bağımlılık nasıl azaltılır?
Kritik süreçlerde sağlayıcıya özgü arayüzler bir soyutlama katmanının arkasına alınır, ikinci bir sağlayıcı ya da yerel bir model alternatif olarak hazır tutulur, sözleşmede hizmet seviyesi ve kesinti bildirimi düzenlenir ve geri düşüş modu düzenli olarak denenir.