Notivex Teknik Değerlendirme Süreci Nasıl İşler?

Teknik değerlendirme neden önemlidir?

Kritik iletişim ve operasyonel kontrol platformları, bir kurumun kimlik altyapısına, ağ topolojisine ve güvenlik politikalarına derinlemesine dokunur. Bu nedenle bir demo izlemek ya da özellik listesini okumak, kurumun gerçek ortamında nasıl konumlanacağını göstermez.

Teknik değerlendirme süreci tam olarak bu boşluğu kapatmak için vardır. Süreç şu sorulara somut yanıt arar:

• Sistem nerede barınacak: kurum içi sunucuda mı, hybrid mi, yoksa dış ağa kapalı (air-gapped) bir ortamda mı?
• Kullanıcılar hangi kimlik altyapısı üzerinden doğrulanacak: LDAP, Active Directory, SSO ya da Keycloak?
• Yapay zekâ destekli işlemler kurum verisini dışarı çıkarmadan local LLM ile mi çalışacak?
• Mevcut sistemlerle (bildirim kanalları, olay yönetimi, dizin servisleri) hangi entegrasyon noktaları gerekecek?
• Denetim ve erişim kayıtları nasıl tutulacak ve kim tarafından incelenebilecek?

Bu sorular netleşmeden yapılan bir satın alma, sonradan entegrasyon zorlukları ve uyum sorunları doğurabilir. Teknik değerlendirme, bu riskleri sözleşme öncesinde görünür kılar.

Klasik yöntemler neden yetersiz kalır?

Birçok kurum, bir iletişim aracını yalnızca özellik karşılaştırması ya da fiyat üzerinden seçer. Bu yaklaşım kritik iletişim katmanında çoğu zaman yetersiz kalır. Çünkü:

• Barındırma modeli göz ardı edilir. Veri gizliliği hassas kurumlarda bulut tabanlı genel araçlar kabul edilemeyebilir; bu kısıt çoğu zaman değerlendirmenin sonunda fark edilir.
• Kimlik entegrasyonu sonraya bırakılır. LDAP/SSO uyumu test edilmeden seçilen bir ürün, mevcut kullanıcı dizinine bağlanamayabilir.
• Yapay zekâ işlemlerinin nerede çalıştığı sorgulanmaz. Dış sağlayıcıya veri gönderen bir AI yaklaşımı, bilgi güvenliği politikalarına takılabilir.
• Denetlenebilirlik unutulur. Bildirimin ulaşıp ulaşmadığı, kimin okuduğu ve onayladığı kayıt altına alınmazsa, kritik süreçler sonradan kanıtlanamaz hale gelir.

Bu boşluklar genellikle RFP/RFI aşaması atlandığında ortaya çıkar. Yapılandırılmış bir teknik değerlendirme, bu kalemleri baştan masaya koyar.

Notivex yaklaşımı

Notivex teknik değerlendirme süreci, kurumun gereksinimlerini varsayımlara değil, somut yapı taşlarına bağlar:

• Barındırma senaryosunun netleştirilmesi — On-premise, hybrid ve air-gapped seçenekleri kurumun ağ ve veri politikalarına göre değerlendirilir; verinin nerede kalacağı baştan tanımlanır.
• Kimlik ve erişim entegrasyonu — LDAP, Active Directory, SSO ve Keycloak gibi mevcut kimlik altyapısına bağlanma noktaları belirlenir.
• Local LLM değerlendirmesi — Yapay zekâ destekli işlemlerin kurum verisini dışarı çıkarmadan kurum içinde çalışmasını hedefleyen mimari seçenekleri konuşulur.
• Zorunlu görünürlük ve acknowledge telemetrisi — Kritik bildirimlerin yalnızca gönderilmesi değil, alıcı tarafından görülüp onaylandığının (acknowledge) ölçülebilir biçimde takip edilmesi gereksinim olarak ele alınır.
• SLA ve eskalasyon kurgusu — Belirlenen süre içinde yanıt alınmayan kritik bildirimlerin eskalasyon zincirine taşınması, kurumun operasyonel kurallarına göre tasarlanır.
• Denetlenebilir operasyon kaydı (audit trail) — Tüm bildirim, görüntüleme ve onay işlemlerinin denetlenebilir bir kayda dönüşmesi planlanır.

Bu süreçte mutlak güvenlik ya da tam uyum iddiası kullanılmaz. Gereksinimler, kuruma özel teknik değerlendirme görüşmelerinde ve RFI/RFP soru setleri üzerinden somutlaştırılır. Notivex bu adımda kritik iletişim, görünürlük, onay, SLA ve denetlenebilir kayıt katmanını sağlar; kurumun tüm güvenlik ve uyum yükümlülüklerini tek başına üstlenmez.

Örnek senaryo

Bir kamu kurumunun bilgi işlem birimi, kritik olaylarda saha ve merkez ekiplerine zorunlu görünürlükle bildirim ulaştıran bir platform arıyor. Satınalma birimi bir RFI hazırlıyor ve teknik şartnameye "verilerin kurum dışına çıkmaması" ve "mevcut Active Directory ile kimlik doğrulama" maddelerini ekliyor.

Teknik değerlendirme süreci şöyle ilerliyor:

• Keşif görüşmesi — Kurumun ağ topolojisi, kullanıcı sayısı, lokasyonlar ve mevcut bildirim kanalları konuşuluyor.
• RFI/RFP yanıtları — On-premise kurulum, local LLM seçeneği, LDAP/SSO entegrasyonu ve audit trail gereksinimleri madde madde ele alınıyor.
• Mimari taslağı — Verinin kurum içinde kaldığı, kimliğin Active Directory üzerinden doğrulandığı ve tüm işlemlerin denetlenebilir kayda dönüştüğü bir kurulum senaryosu çiziliyor.
• Güvenlik değerlendirmesi — Bilgi güvenliği müdürü erişim, log ve eskalasyon kurallarını gözden geçiriyor.

Bu adımların sonunda kurum, satın alma kararını eksik varsayımlarla değil, netleşmiş teknik kısıtlarla veriyor.

Kullanılabilecek modüller

• On-Premise / Air-Gapped Kurulum — Kurum içi, hybrid ve kapalı ağ senaryolarına göre barındırma değerlendirmesi.
• Entegrasyonlar — LDAP, Active Directory, SSO ve Keycloak ile kimlik ve sistem entegrasyonu.
• Audit Trail — Bildirim, görüntüleme ve onay işlemlerinin denetlenebilir operasyon kaydına dönüşmesi.