Bir satış uzmanı, kampanya dönemi için müşteri listesini birleştiren küçük bir uygulama kuruyor. Muhasebeden biri, banka ekstresindeki satırları muhasebe koduyla eşleştiren bir otomasyon hazırlıyor. İkisi de birkaç saatte, yapay zekâ destekli bir araçla, BT birimine bilet açmadan bitiyor. İş görülüyor; ama kurumun envanterinde bu iki uygulamanın izi yok.
Yapay zekâ ile uygulama geliştirme ve low code araçları yaygınlaştıkça bu tablo istisna olmaktan çıkıyor. BT biriminin haberi olmadan çalışan bu uygulamalar için kullanılan yerleşik bir terim de var: gölge BT (shadow IT). Gartner'ın Eylül 2026'da açıkladığı 2027 ve sonrası stratejik öngörülerinden biri doğrudan bu konuyu ele alıyor. Bu yazı, çalışanların kendi kurduğu uygulama ve otomasyonları yasaklamadan nasıl kayıt altına alabileceğinizi ele alıyor.
Gartner'ın öngörüsü: yeni uygulamaların çoğu bir yıldan kısa yaşayacak
Gartner'a göre 2029'a kadar yeni uygulamaların %80'i bilinçli olarak tek kullanımlık olacak, yani bir yıldan kısa süre kullanılacak. Gartner bunu yazılım yaşam döngüsünü kökten değiştirecek bir gelişme olarak tanımlıyor.
Gerekçe de açık: yapay zekâ, uygulama geliştirmeyi o kadar erişilebilir kılıyor ki çalışanlar kısa vadeli iş ihtiyaçları için giderek daha fazla geçici uygulama üretecek. Burada "tek kullanımlık" bir kusur değil, bir tasarım tercihi. Bir kampanya, bir denetim dönemi ya da bir taşıma projesi bitince uygulama da işini bitirmiş oluyor.
Sorun uygulamanın kısa ömrü değil, iz bırakmadan çalışması. Gartner'ın uyarısı bu noktada: kurumlar yeni yönetişim, güvenlik, uyum ve kayıt yönetimi sorunlarıyla karşılaşacak. Gartner bunun özellikle uygulamalar kararları etkilediğinde ya da hassas verilere eriştiğinde önem kazandığını vurguluyor.
Neden klasik BT süreci bu hıza uymuyor?
Geleneksel yazılım yönetimi, uzun yaşayan sistemler için kuruldu: talep, analiz, geliştirme, test, devreye alma, bakım. Bu akış, birkaç haftalık bir ihtiyaç için kurulan uygulamaya uygulandığında iki sonuçtan biri çıkar. Ya iş, onay beklerken önemini yitirir. Ya da çalışan süreci atlar ve uygulama kayıt dışında kalır.
İkinci sonuç daha yaygındır, çünkü araç elinin altındadır. Bu yüzden çözüm, kurulan her uygulamayı tam BT sürecinden geçirmek değil. Uygulamanın taşıdığı riske göre farklı bir yol tanımlamaktır.
Gartner'ın üç önerisi
Gartner bu öngörü için kurumlara üç somut adım öneriyor:
- Risk tabanlı yönetişim çerçeveleri kurmak.
- İş birimlerinin oluşturduğu uygulamaları otomatik kayıt sistemleriyle izlemek.
- Kayıt saklama politikalarını, yapay zekâyla üretilen uygulama ve ajanları kapsayacak şekilde güncellemek.
Aşağıdaki çerçeve bu üç öneriyi uygulamaya çeviren bir başlangıç noktasıdır.
Uygulamaya çevirmek: dört soruluk risk süzgeci
Her yeni uygulama ya da otomasyon için dört soru yeterli bir ilk ayrım sağlar:
- Veri: Uygulama kişisel veriye, müşteri verisine ya da ticari sır niteliğindeki bilgiye erişiyor mu?
- Karar: Çıktısı bir kararı etkiliyor mu? Örneğin bir ödeme, bir fiyat, bir işe alım ya da bir kredi kararı.
- Bağlantı: Kurumun ana sistemlerine (ERP, muhasebe, CRM, banka) yazıyor mu, yoksa yalnız okuyor mu?
- Ömür: Ne kadar süre kullanılacak, kim kapatacak?
Dört sorunun hepsine "hayır" ya da "kısa" cevabı veren uygulama hafif bir kayıtla yaşayabilir: adı, sahibi, amacı, kapanış tarihi. Veri ya da karar sorusuna "evet" cevabı geldiğinde ise uygulama, BT ve uyum biriminin bakacağı bir incelemeden geçer. Bu ayrım, Gartner'ın vurguladığı iki risk alanıyla, yani karar etkisi ve hassas veri erişimiyle örtüşüyor.
Kayıt sistemi: yasaklamak yerine görünür kılmak
Gartner'ın önerdiği "otomatik kayıt sistemi", çalışanın elle form doldurmasına dayanmaz. Fikir, kurumun kullandığı geliştirme ve otomasyon platformlarından yeni uygulamaların kendiliğinden listeye düşmesidir. Pratikte bu, şu bilgilerin tek bir yerde görülebilmesi demek:
- Uygulamayı kim kurdu, hangi birimde?
- Hangi veri kaynaklarına bağlanıyor?
- Son ne zaman çalıştı?
- Kapanış tarihi var mı?
Bu liste iki işe yarar. Birincisi, sahipsiz kalan uygulamayı fark ettirir. Kurucusu birimden ayrılmış ama hâlâ her gece çalışan bir otomasyon, en sık karşılaşılan risklerden biridir. İkincisi, birden fazla birimin aynı ihtiyaç için ayrı ayrı uygulama kurduğunu gösterir. Bu da kalıcı bir çözüme yatırım yapmanın zamanının geldiğini söyler.
Kayıt saklama: uygulama silinse de iz kalmalı
Tek kullanımlık uygulamanın en az konuşulan riski, kapatıldığında geride ne bıraktığıdır. Bir uygulama bir ödeme listesini hazırladıysa ya da bir müşteriye yanıt ürettiyse, o işlemin nasıl yapıldığı ileride sorulabilir. Gartner'ın üçüncü önerisi bu yüzden kayıt saklama politikalarının güncellenmesi.
Uygulamada bu üç soruya cevap vermek demek: Uygulamanın ürettiği çıktılar nerede saklanıyor? Uygulamanın mantığı (kullanılan kurallar, istemler, bağlantılar) kapatılmadan önce arşivleniyor mu? Saklama süresi, uygulamanın etkilediği işlemin türüne göre mi belirleniyor?
Aynı bültendeki başka bir öngörü bu konunun neden yönetim düzeyine taşındığını gösteriyor. Gartner'a göre 2030'a kadar Global 500 şirketlerinin %80'i, yapay zekâ hesap verebilirliği için BT yöneticisini (ya da yapay zekâ yöneticisini) sözleşmeyle "kanıt sorumlusu" yapacak. Yapay zekânın bir işlemde ne yaptığını sonradan gösterebilmek, kurumsal bir yükümlülüğe dönüşüyor.
Nereden başlamalı?
Kapsamlı bir program kurmadan önce üç küçük adım yeterli bir başlangıçtır:
- Mevcut durumu görün. Çalışanların kullandığı yapay zekâ destekli geliştirme ve otomasyon araçlarını listeleyin.
- Dört soruluk süzgeci yazılı hâle getirin. Hangi cevabın hangi incelemeyi tetiklediği tek sayfada dursun.
- Kapanış tarihini zorunlu alan yapın. Her yeni uygulama bir sahip ve bir bitiş tarihiyle kayda girsin; tarih geldiğinde sahibine sorulsun: kapatılacak mı, uzatılacak mı, kalıcı çözüme mi dönüşecek?
Çalışanların kendi araçlarını üretebilmesi, otomasyonun kurum içinde yayılmasının en hızlı yolu. Yönetişimin amacı bu hızı kesmek değil, neyin nerede çalıştığını bilinir kılmak.
#interimmanagement #forwarddeployedengineering