Kritik bildirimlerde AI destekli risk skorlama yaklaşımı.

Problem: Kritik bildirim, hacim büyüdükçe görünmez olur

Çoğu kurumda bildirim sorunu "az bildirim" değil, "çok bildirim"dir. İzleme araçları, ticket sistemleri, sunucu uyarıları, saha ekiplerinden gelen mesajlar ve yönetimsel duyurular aynı kanallara akar. Sonuçta gün içinde yüzlerce sinyal oluşur ve bunların büyük kısmı bilgilendirme niteliğindedir.

Bu yoğunlukta asıl sorun şu hâle gelir: Hangi bildirim gerçekten kritik? Bir disk doluluk uyarısı mı, yoksa SLA'sı dolmak üzere olan bir müşteri kesintisi mi? Her ikisi de kırmızı renkte düşebilir; ama operasyonel etkileri ve aciliyetleri çok farklıdır. İnsan operatör bu ayrımı yapmaya çalışırken hem zaman kaybeder hem de yanılma riski taşır.

Klasik yöntemler neden yetersiz kalır?

• Sabit öncelik etiketleri — "düşük / orta / yüksek / kritik" gibi statik seviyeler, bildirimi gönderenin o anki algısına bağlıdır. Aynı olay farklı kişiler tarafından farklı seviyelendirilir ve zamanla "her şey yüksek öncelikli" hâline gelir.
• Kural tabanlı filtreler — "şu kelime geçerse kritik say" türü kurallar başlangıçta işe yarar, ancak olay çeşitliliği arttıkça bakımı zorlaşır ve bağlamı (etkilenen birim, geçmiş benzer olaylar, SLA durumu) göz ardı eder.
• Manuel triyaj — bir nöbetçi ekibin her bildirimi tek tek değerlendirmesi ölçeklenmez; yoğun saatlerde tıkanır ve insan yorgunluğuna açıktır.
• Bağlamsız aciliyet — klasik sistemler bir bildirimin *ne kadar acil* olduğunu söyleyebilir ama *kim için, neden ve hangi SLA penceresinde* acil olduğunu çoğu zaman söyleyemez.

Bu sınırların toplam sonucu, ilerleyen bölümde ele alacağımız alert fatigue ve kaçırılan kritik uyarılardır.

Notivex yaklaşımı

Notivex, AI risk skorlamayı tek başına bir "karar makinesi" olarak değil, kritik iletişim sürecinin içine yerleşmiş bir karar destek katmanı olarak konumlandırır. Skor, sürecin başlangıcıdır; sonu değil. Yapı taşları şöyle bağlanır:

• Sinyal toplama — AI risk skorlaması; bildirimin içeriği, etkilenen birimler, geçmiş olay benzerliği ve ilgili SLA hassasiyeti gibi sinyalleri bir arada değerlendirir. Tek bir kelimeye değil, bağlama bakar.
• Öncelik önerisi — model bir öncelik *önerisi* üretir. Bu öneri, kritik bildirim akışını tetiklemek yerine karar vericiye gerekçesiyle birlikte sunulur; nihai çağrıyı insan yapar.
• Hedef kitle önerisi — yüksek riskli bir bildirim için sistem, "bunu kimin görmesi gerekir?" sorusuna öneri getirir. Böylece kritik uyarı doğru ekibe yönelir, herkese gönderilen gürültü azalır.
• Zorunlu görünürlük — yüksek skorlu bildirimler, sıradan duyuru akışında kaybolmaz; alıcının önüne görünür biçimde gelir.
• Acknowledge (okudum-onayladım) — alıcının kritik bildirimi gördüğünü ve sahiplendiğini açık onayla kayda almak, "gördüm sanıyordum" boşluğunu kapatır.
• SLA ve eskalasyon — bildirim, ilgili SLA penceresine bağlanır; onay gelmez veya süre dolarsa eskalasyon zinciri devreye girer. Risk skoru burada eskalasyon eşiklerini bağlamlandırmaya yardımcı olur.
• Audit trail (denetlenebilir operasyon kaydı) — bildirimin ne zaman üretildiği, hangi gerekçeyle hangi öncelikte sunulduğu, kimin ne zaman onayladığı ve eskalasyonun nasıl ilerlediği denetlenebilir biçimde kayıt altına alınır.
• Raporlama — zaman içinde hangi skorların doğru çıktığı, hangi eskalasyonların tetiklendiği ve alert fatigue eğiliminin nasıl değiştiği raporlanarak modelin ve sürecin sürekli gözden geçirilmesi mümkün olur.

Bu zincirde önemli olan ilke şudur: skor şeffaftır, gerekçelidir ve insan denetimine açıktır. Notivex'in amacı operasyon ekibinin karar otoritesini elinden almak değil, ekibin dikkatini gerçekten kritik olana yöneltmektir.

Örnek senaryo

Bir e-ticaret operasyonunda ödeme servisinde gecikme başlar. İzleme sistemi onlarca teknik uyarı üretirken, Notivex AI risk skorlaması bunlardan birini öne çıkarır: etkilenen birim "ödeme", geçmişte benzer olayların gelir kaybına yol açtığı görülmüş, ilgili SLA penceresi ise dar. Sistem bu bildirim için yüksek öncelik önerir ve hedef kitle olarak ödeme ile operasyon nöbet ekibini işaret eder.

> "Yüksek riskli bildirim: Ödeme servisi yanıt süresi eşiği aştı. Etkilenen birim: Ödeme. Geçmiş benzer olay etkisi: yüksek. SLA penceresi: 15 dakika. Önerilen öncelik: Kritik. Lütfen okuyup onaylayın."

Nöbetçi mühendis bildirimi açar ve acknowledge ile sahiplenir; bu onay audit trail'e işlenir. 15 dakikalık pencere içinde çözüm gelmezse eskalasyon zinciri otomatik olarak bir üst seviyeye taşır. Gün sonunda raporlamada görülür ki yüksek skorlu tek bir bildirim, onlarca düşük öncelikli uyarının arasından zamanında görünür kılınmıştır. Kararı yine insan vermiştir; AI yalnızca doğru bildirimi doğru anda öne çıkarmıştır.

Kullanılabilecek modüller

• AI Karar Destek — bildirimlerin aciliyetini, etkisini ve hedef kitle ihtiyacını değerlendirerek gerekçeli öncelik önerisi sunar; kararı insana bırakır.
• Kritik Bildirim — yüksek riskli uyarıların zorunlu görünürlük ve acknowledge ile doğru kişiye ulaşmasını sağlar.
• Eskalasyon — onay gelmez veya SLA penceresi dolarsa bildirimi tanımlı zincir boyunca bir üst seviyeye taşır.
• SLA — her bildirimi ilgili hizmet seviyesi penceresine bağlar; risk skoru eskalasyon eşiklerini bağlamlandırır.
• Audit Trail — skor gerekçesini, onayları ve eskalasyon adımlarını denetlenebilir operasyon kaydı olarak tutar.