Kurumların yıllardır mücadele ettiği Shadow IT sorunu, üretken yapay zekâ ile yeni ve daha karmaşık bir biçime dönüştü. Artık mesele yalnızca çalışanların BT’nin onaylamadığı bir SaaS uygulamasını kullanması değil; kurumsal verinin bilinmeyen modellere taşınması, AI araçlarının kurumsal hesaplara bağlanması ve agent’ların şirket adına işlem yapabilmesi.
Shadow AI, Shadow IT’nin yalnızca “yapay zekâ kullanan” yeni sürümü değildir. Veri işleyen, bağlam üreten, kararları etkileyen ve giderek kurum adına aksiyon alabilen sistemlerin görünürlük ve yönetişim dışında kalmasıdır.
Shadow AI nedir?
Shadow IT kavramı yeni değil. Kurum çalışanlarının BT biriminin bilgisi veya onayı dışında uygulama, bulut servisi, depolama alanı ya da cihaz kullanması yıllardır bilinen bir problem. Bir departmanın kendi kredi kartıyla proje yönetim aracı satın alması, çalışanların kişisel bulut hesaplarında dosya paylaşması veya kurumsal süreçlerin BT envanterinde bulunmayan bir SaaS üzerinde yürütülmesi klasik Shadow IT örnekleridir.
Shadow AI ise çalışanların, ekiplerin veya iş birimlerinin kurum tarafından onaylanmamış ya da yeterince değerlendirilmemiş üretken yapay zekâ servislerini, AI özelliklerini, coding assistant’ları, toplantı botlarını, model API’lerini veya AI agent’larını kurumsal amaçlarla kullanmasıdır. Burada “onaysız” sözcüğünü yalnızca yasaklanmış araçlar olarak okumamak gerekir. Kurumda erişimine izin verilmiş bir SaaS ürününün sonradan eklenen yapay zekâ özelliği de güvenlik, hukuk ve veri yönetişimi ekiplerinin değerlendirmesinden geçmediyse fiilen bir Shadow AI bileşenine dönüşebilir.
Sorunun büyüklüğü yalnızca yeni araçların sayısından kaynaklanmıyor. Üretken yapay zekâ, geleneksel bir SaaS uygulamasına göre çok daha doğal bir veri toplama arayüzüne sahip: prompt kutusu. Kullanıcı birkaç saniye içinde sözleşme metnini, kaynak kodunu, müşteri listesini, finansal tabloyu, olay kaydını veya henüz yayımlanmamış strateji dokümanını bir modele kopyalayabilir. Üstelik bunu çoğu zaman “dosya paylaşımı” olarak düşünmez; yalnızca işini hızlandıran bir soru sorduğunu düşünür.
Shadow IT ile Shadow AI arasındaki fark neden önemli?
Klasik Shadow IT’nin temel problemi görünürlük, veri sahipliği ve kontrol kaybıdır. Shadow AI bunların tamamını devralır; fakat üç yeni boyut ekler: yorumlama, üretme ve eyleme geçme.
Bir bulut depolama servisine yüklenen PDF çoğunlukla aynı PDF olarak kalır. Bir AI servisine yüklenen PDF ise özetlenebilir, sınıflandırılabilir, başka içeriklerle ilişkilendirilebilir, yeni çıktılar üretmek için kullanılabilir veya bir agent’ın sonraki kararını etkileyebilir. Aynı nedenle yapay zekâya verilen verinin yaşam döngüsünü yalnızca “nerede saklanıyor?” sorusuyla yönetmek yetersizdir. “Hangi model işliyor?”, “hangi alt hizmetler devrede?”, “loglarda ne tutuluyor?”, “veri model geliştirme amacıyla kullanılabiliyor mu?”, “hangi ülke veya bölgede işleniyor?” ve “çıktı başka bir sisteme otomatik aktarılıyor mu?” gibi sorular da gerekir.
| Boyut | Shadow IT | Shadow AI |
|---|---|---|
| Temel nesne | Uygulama / SaaS / cihaz | Model, AI servisi, agent, AI özellikli SaaS |
| Veri ilişkisi | Depolama ve işleme | İşleme, türetme, özetleme, çıkarım ve bağlam oluşturma |
| Kullanıcı etkileşimi | Form, dosya, API | Prompt, dosya, sohbet, ses, görüntü, API, agent |
| Yetki | Uygulama izinleri | Uygulama izinleri + model araç kullanımı + agent otonomisi |
| Başlıca risk | Görünürlük ve veri kaybı | Veri kaybı + yetki kötüye kullanımı + yanlış karar + prompt tabanlı saldırılar |
Shadow AI kurumlara nasıl giriyor?
En görünür senaryo çalışanların kişisel hesaplarıyla ChatGPT, Gemini, Claude veya benzeri genel amaçlı servisleri kullanmasıdır. Ancak gerçek saldırı yüzeyi bundan çok daha geniştir. Güvenlik ekiplerinin sadece birkaç popüler sohbet sitesini engellemesi bu nedenle sorunu çözmez.
1. Kişisel üretken AI hesapları
Çalışan bir sözleşmenin riskli maddelerini bulmak, uzun bir e-postayı özetlemek, ihale dokümanına cevap hazırlamak veya Excel’deki veriyi analiz etmek için kurumsal içeriği kişisel AI hesabına yükleyebilir. Bu işlem iş açısından son derece verimli olabilir; fakat kurum açısından veri sınıflandırma, kayıt, saklama, sözleşmesel gizlilik ve erişim politikalarının dışına çıkar.
2. AI coding assistant’ları
Yazılım ekiplerinde risk yalnızca kaynak kodunun dış sisteme taşınması değildir. Kod parçaları API anahtarlarını, dahili host adlarını, veri modellerini, güvenlik kontrollerini ve kurumun mimarisi hakkında saldırgan için değerli olabilecek bağlamı barındırabilir. AI coding araçları kullanılacaksa ürün seçimi, tenant yönetimi, kaynak kodu politikası, telemetry ayarları ve hangi repository’lere erişebildiği güvenlik mimarisinin bir parçası olmalıdır.
3. Toplantı botları ve transkripsiyon servisleri
Bir toplantıya eklenen AI not tutucu; müşteri görüşmesini, fiyat pazarlığını, hukuk değerlendirmesini, insan kaynakları konuşmasını veya henüz açıklanmamış iş kararlarını kaydedebilir. Kullanıcı açısından “not çıkarmak” olan faaliyet, kurum açısından ses verisinin üçüncü tarafa aktarılması ve yeni bir veri deposunun oluşması anlamına gelebilir.
4. SaaS ürünlerinin içine eklenen AI özellikleri
CRM, ticketing, doküman yönetimi, tasarım, ofis üretkenliği ve iş zekâsı ürünleri artık kendi AI yardımcılarını sunuyor. Kurum SaaS ürününü yıllar önce güvenlik değerlendirmesinden geçirmiş olabilir; ancak ürünün sonradan kazandığı model sağlayıcısı, veri akışı veya AI agent yetenekleri aynı değerlendirmeden geçmemiş olabilir. Onaylı uygulama içinde onaysız AI oluşması, Shadow AI’ın en kolay gözden kaçan biçimlerinden biridir.
5. Tarayıcı eklentileri ve masaüstü yardımcıları
“Bu sayfayı özetle”, “e-postamı yaz” veya “PDF’yi analiz et” gibi işlevler sunan eklentiler bazen kullanıcının ziyaret ettiği sayfaların içeriğine geniş erişim ister. Buradaki risk yalnızca prompt’a manuel olarak yapıştırılan içerik değildir; eklenti sayfa bağlamını otomatik olarak okuyabilir. Bu nedenle browser extension governance, endpoint güvenliğinin bir alt başlığı olmaktan çıkıp AI yönetişiminin de parçası haline gelmektedir.
6. Low-code otomasyonlar ve AI agent’lar
En kritik dönüşüm burada yaşanıyor. Bir kullanıcı birkaç dakika içinde bir agent oluşturup Google Drive, Microsoft 365, CRM, Slack, GitHub, ticketing sistemi veya şirket içi API’lere bağlayabiliyor. Bu noktada Shadow AI artık yalnızca veri paylaşımı problemi olmaktan çıkar ve kimlik ile yetki problemi haline gelir.
Bir satış çalışanının sözleşme taslağını kişisel AI hesabında özetlemesi veri güvenliği problemidir. Aynı çalışan bir AI agent’a e-posta, CRM ve dosya sistemi erişimi verip müşteri taleplerini takip etmesini söylediğinde risk; veri güvenliğinin yanında kimlik, erişim kontrolü, işlem bütünlüğü ve hesap verebilirliği de kapsar.
Shadow AI’ın temel güvenlik ve iş riskleri
Hassas bilgi ifşası
OWASP’ın güncel GenAI güvenlik çalışmalarında Sensitive Information Disclosure temel risklerden biri olarak ele alınıyor. Kişisel veri, finansal bilgi, sağlık verisi, güvenlik kimlik bilgileri ve gizli kurumsal içerik; LLM uygulamalarında özel koruma gerektiren veri sınıfları arasında sayılıyor. Shadow AI bağlamında sorun daha da temel: kurum, verinin AI sistemine girdiğini çoğu zaman bilmediği için mevcut veri güvenliği kontrollerini uygulama fırsatı bulamıyor.
Burada önemli ayrım şudur: “Model bu veriyi eğitim için kullanıyor mu?” tek soru değildir. Eğitim için kullanılmasa bile veri servis loglarında, konuşma geçmişinde, entegrasyon katmanında, dosya depolamasında veya alt işleyenlerde tutulabilir. Dolayısıyla kurumsal değerlendirme; veri işleme amacı, saklama süresi, silme mekanizması, veri lokasyonu, erişim kontrolleri, alt işleyenler ve sözleşmesel yükümlülükleri birlikte incelemelidir.
Fikri mülkiyet ve ticari sır kaybı
Kaynak kodu, ürün tasarımı, fiyatlandırma modeli, teklif stratejisi, müşteri listesi, Ar-Ge dokümanı veya birleşme-satın alma planı kişisel AI hesabına aktarılırsa mesele yalnızca siber güvenlik olayı değildir. Ticari sır statüsünün korunması, sözleşmesel gizlilik yükümlülükleri ve fikri mülkiyet yönetimi de etkilenebilir. Bu yüzden Shadow AI politikası sadece CISO’nun konusu değildir; hukuk, insan kaynakları, satın alma, veri koruma ve iş birimlerinin birlikte sahiplenmesi gereken bir yönetişim konusudur.
Kimlik ve OAuth yetkilerinin kontrolsüz yayılması
AI servisleri artık “dosya yükleyip soru sorulan” web uygulamalarından ibaret değil. Birçok servis OAuth aracılığıyla e-posta, takvim, Drive, OneDrive, GitHub, Slack veya CRM’e bağlanabiliyor. Kullanıcı birkaç tıklamayla bir üçüncü tarafa uzun süreli erişim verebilir. Güvenlik ekiplerinin yalnızca web trafiğini izlemesi bu durumda yeterli değildir; OAuth uygulamaları, service principal’lar, API token’ları ve agent identity’leri de envantere alınmalıdır.
Prompt injection ve güvenilmeyen içerik
OWASP, Prompt Injection riskini LLM tabanlı uygulamalar için temel tehditlerden biri olarak tanımlıyor. Saldırganın doğrudan yazdığı kötü niyetli prompt dışında, modelin okuduğu web sayfası, doküman, e-posta veya harici veri kaynağı içine yerleştirilmiş talimatlar da davranışı etkileyebilir. Bu durum indirect prompt injection olarak özellikle agent ve RAG senaryolarında önemlidir.
Örneğin e-postaları otomatik özetleyen ve belirli koşullarda ticket açabilen bir agent düşünelim. Agent’ın okuduğu dış kaynaklı bir e-postada modele yönelik gizli bir talimat bulunması, yeterli güvenlik sınırları yoksa agent’ın beklenmeyen işlemler yapmasına yol açabilir. Burada klasik “kullanıcı kötü linke tıklamasın” yaklaşımından farklı olarak saldırgan doğrudan kullanıcıyı değil modelin bağlamını hedefler.
Yanlış veya doğrulanmamış çıktının iş kararına dönüşmesi
Üretken AI sistemleri güvenilir görünen fakat hatalı içerik üretebilir. Shadow AI bağlamında asıl fark kurumun bu modelin hangi süreçte kullanıldığını bilmemesidir. İnsan kaynakları aday değerlendirmesinde, hukuk sözleşme analizinde, finans tahminde veya satış teklifinde onaylanmamış bir AI sisteminin çıktısı kullanılıyorsa model riski artık operasyonel riske dönüşür. Kritik karar mekanizmalarında insan doğrulaması, kaynak kontrolü ve karar kaydı bu nedenle yalnızca “iyi uygulama” değil, kontrol tasarımının parçası olmalıdır.
Uyum, denetim izi ve hesap verebilirlik
KVKK, sözleşmesel veri koruma hükümleri, sektörel düzenlemeler ve kurumun kendi bilgi güvenliği politikaları açısından temel soru “AI kullanıldı mı?” değil, “hangi verinin hangi amaçla, hangi sistem tarafından, hangi hukuki ve teknik koşullar altında işlendiği”dir. Shadow AI bu zincirin görünürlüğünü kırar. Bir denetimde veya olay müdahalesinde geriye dönük olarak hangi prompt’un hangi dosyayla, hangi hesap üzerinden, hangi modele gönderildiğini belirlemek mümkün olmayabilir.
AI agent’lar neden oyunu değiştiriyor?
İlk üretken AI dalgasında kurumsal tartışmanın merkezinde çoğunlukla “çalışan modele ne yazıyor?” sorusu vardı. Agentic AI ile daha kritik soru şudur: AI hangi sistemlere erişebiliyor ve kurum adına ne yapabiliyor?
OWASP’ın Excessive Agency başlığı tam olarak bu noktaya odaklanır. Bir LLM tabanlı sistemin gereğinden fazla fonksiyona, gereğinden geniş izinlere veya aşırı otonomiye sahip olması; beklenmeyen ya da manipüle edilmiş çıktının gerçek sistemlerde zararlı eyleme dönüşmesine neden olabilir.
Agent güvenliğinde klasik kullanıcı hesabı mantığı tek başına yeterli değildir. Her agent için ayrı bir kimlik, açık bir sahip, tanımlı amaç, minimum yetki, mümkün olduğunda kısa ömürlü credential, kapsamı sınırlı API erişimi, işlem logu ve gerektiğinde insan onayı gerekir. Bir insan çalışana vermeyeceğiniz sürekli ve sınırsız yetkiyi, “otomasyon hızlı olsun” diye bir agent’a vermek kabul edilebilir değildir.
Örneğin kurumsal e-postayı okuyabilen, CRM kaydı güncelleyebilen ve müşteriye e-posta gönderebilen bir agent düşünün. Bu agent’ın yetkileri üç farklı sistemde üç farklı risk alanı yaratır. Prompt injection, yanlış sınıflandırma veya hatalı bağlam nedeniyle yanlış müşteriye yanlış içeriğin gönderilmesi yalnızca model hatası değildir; erişim kontrolü ve mimari tasarım hatasıdır.
“AI’ı yasaklayalım” neden sürdürülebilir bir çözüm değil?
Shadow AI’ın en kolay görünen çözümü genel AI servislerini engellemektir. Bazı yüksek güvenlikli ortamlarda belirli servislerin tamamen yasaklanması elbette gerekli olabilir. Ancak kurum genelinde “AI kullanmayın” yaklaşımı çoğu organizasyonda iki nedenle başarısız olur.
Birincisi, kullanıcı ihtiyacı gerçektir. Üretken AI; araştırma, metin üretimi, kodlama, analiz, özetleme ve otomasyon işlerinde ciddi verimlilik sağlar. Çalışanın ihtiyacını karşılayacak güvenli alternatif sunulmazsa kullanım ortadan kalkmaz; görünmez hale gelir. Kullanıcı kişisel cihazına, kişisel hesabına veya güvenlik ekibinin göremediği başka bir servise geçebilir.
İkincisi, AI artık ayrı bir web sitesi değildir. Tarayıcıda, işletim sisteminde, ofis paketinde, CRM’de, kod editöründe ve toplantı platformunda yerleşik özellik olarak bulunur. Dolayısıyla alan adı engelleyerek AI kullanımını bütünüyle kontrol etmek giderek gerçekçi olmaktan uzaklaşıyor.
Shadow AI yönetiminin amacı yapay zekâyı kurumdan çıkarmak değil; hangi AI’ın, hangi veriyle, hangi kimlikle, hangi yetkiyle ve hangi iş amacı için kullanıldığını görünür ve yönetilebilir hale getirmektir.
Shadow AI nasıl yönetilmeli? Beş aşamalı model
NIST AI Risk Management Framework: Generative AI Profile, yapay zekâ risklerinin yaşam döngüsü boyunca yönetişim ve risk yönetimi yaklaşımıyla ele alınmasını önerir. Shadow AI için pratik kurumsal model bunu beş operasyonel aşamaya dönüştürebilir: Discover, Classify, Govern, Control, Monitor.
1. Discover — Önce gerçekte ne kullanıldığını bulun
Envanter olmadan yönetişim kurulamaz. Kurum; web proxy, Secure Web Gateway, CASB/SSE, DNS, endpoint telemetry, tarayıcı kontrolleri, SaaS discovery ve kimlik sağlayıcı loglarından yararlanarak hangi AI servislerinin kullanıldığını görünür hale getirmelidir. Ancak sadece domain listesini çıkarmak yeterli değildir. OAuth ile kurumsal hesaba bağlanan AI uygulamaları, API anahtarları, low-code otomasyonlar ve agent’lar da keşif kapsamına alınmalıdır.
Bu aşamada amaç kullanıcı avlamak değil, kullanım ihtiyacını anlamaktır. Bir departmanda onaylanmamış bir AI servisi yoğun kullanılıyorsa soru “kim yasağı ihlal etti?” ile başlamamalı; “hangi iş ihtiyacı güvenli kurumsal araçlarla karşılanmıyor?” olmalıdır. Shadow AI’ın gerçek kaynağı çoğu zaman kötü niyet değil, kullanıcıların hızlı çözmeye çalıştığı gerçek bir iş problemidir.
2. Classify — AI kullanımını risk seviyesine göre sınıflandırın
Her AI kullanımı aynı riske sahip değildir. Halka açık bir metnin özetlenmesi ile müşteri sözleşmesinin kişisel hesaba yüklenmesi aynı sınıfta değerlendirilemez. Kurumun mevcut veri sınıflandırma şeması AI politikasına bağlanmalıdır. Public, Internal, Confidential, Restricted gibi sınıflar için hangi AI servislerinin kullanılabileceği açıkça belirlenmelidir.
Kullanım amacı da sınıflandırılmalıdır. Sadece içerik taslağı üreten düşük yetkili bir sistem ile kurumsal e-postaya ve CRM’e yazma yetkisi olan agent aynı onay sürecinden geçmemelidir. Risk değerlendirmesinde verinin hassasiyeti, modelin erişim alanı, çıktıların kritikliği, otonomi düzeyi ve üçüncü taraf bağımlılıkları birlikte ele alınmalıdır.
3. Govern — Yasak listesi değil yönetişim modeli oluşturun
AI Acceptable Use Policy tek başına yeterli değildir ama gereklidir. Politika; hangi verinin hangi servislerde kullanılabileceğini, kişisel hesap kullanımını, dosya yükleme kurallarını, kod paylaşımını, toplantı kayıtlarını, agent kullanımını, insan onayı gereken işlemleri ve istisna süreçlerini tanımlamalıdır.
Bunun yanında bir Approved AI Catalogue oluşturulabilir. Çalışan hangi iş için hangi servisin onaylı olduğunu bilmelidir. Güvenli seçeneğin kolay erişilebilir olması politikaya uyumu doğrudan artırır. Kurumsal lisans, SSO, merkezi loglama ve veri koruma taahhütleri bulunan bir AI hizmetinin çalışanlara sunulması, kişisel hesap kullanımını azaltmanın en etkili yollarından biridir.
4. Control — Teknik kontrolleri veri ve kimlik etrafında kurun
Shadow AI kontrolünde iki eksen öne çıkar: onaysız AI uygulamalarına erişimi yönetmek ve hassas verinin bu uygulamalara taşınmasını engellemek. Microsoft’un Temmuz 2026 güvenlik duyurularında da Purview DLP ile Entra Internet Access entegrasyonunun, yönetilmeyen bulut ve Shadow AI uygulamalarına hassas metin veya dosya gönderimini ağ katmanında tespit edip engellemeye odaklandığı görülüyor. Üründen bağımsız düşünüldüğünde kontrol katmanları Secure Web Gateway/SSE, CASB, DLP, browser controls, endpoint controls, SSO, MFA, Conditional Access, OAuth application governance ve API security bileşenlerini içerir.
Kurumsal AI servisleri mümkün olduğunca SSO üzerinden sunulmalı, kişisel hesap yerine kurumsal tenant kullanılmalı, kullanıcı yaşam döngüsü IAM ile yönetilmeli ve işten ayrılma durumunda erişim merkezi olarak kesilebilmelidir. Agent ve entegrasyonlarda minimum yetki, ayrı kimlik, secret yönetimi ve işlem bazlı yetkilendirme uygulanmalıdır.
5. Monitor — AI kullanımını loglayın ve sürekli yeniden değerlendirin
AI ekosistemi hızlı değişiyor. Bugün yalnızca sohbet eden uygulama birkaç ay içinde dosya sistemi veya kurumsal SaaS erişimi kazanabilir. Bu nedenle vendor risk assessment bir defalık satın alma kontrolü değildir. Ürün kabiliyetleri, veri politikası, alt işleyenler, model sağlayıcıları, entegrasyonlar ve varsayılan ayarlar periyodik olarak yeniden incelenmelidir.
SOC açısından AI logları da yeni bir telemetry kaynağıdır. Kim hangi modeli kullandı, hangi veri sınıfıyla etkileşim kurdu, hangi agent hangi API’yi çağırdı ve hangi kritik aksiyon insan onayı olmadan gerçekleşti gibi sorular olay müdahalesinde cevaplanabilir olmalıdır. Bu veriler SIEM’e aktarılabilir; ancak her şeyi loglamak yerine gerçek detection use-case’leri tasarlanmalıdır.
Önerilen kurumsal Shadow AI kontrol mimarisi
Shadow AI için tek bir ürün satın alıp problemi kapatmak mümkün değildir. Mimari, kullanıcıdan veriye ve AI servisinden agent’ın ulaştığı hedef sistemlere kadar zincirin tamamını kapsamalıdır. Kontrollerin üç temel ekseni vardır: kimlik, veri ve aksiyon.
Kurum içinde uygulanabilecek politika matrisi
Politikanın kullanıcı tarafından anlaşılabilir olması gerekir. On sayfalık “AI kullanım prosedürü” yayımlayıp tüm sorumluluğu çalışana bırakmak yerine veri sınıfı ve kullanım tipine göre basit bir karar matrisi oluşturmak daha işlevseldir.
| Senaryo | Önerilen yaklaşım | Kontrol |
|---|---|---|
| Halka açık metni özetleme | Onaylı AI ile izin verilebilir | Kurumsal hesap, temel loglama |
| İç kullanım dokümanı analizi | Kurumsal tenant ile sınırlandırılmalı | SSO, DLP, saklama politikası |
| Müşteri verisi / kişisel veri | Risk ve hukuk değerlendirmesi gerekir | DLP, sözleşme, veri lokasyonu, erişim kontrolü |
| Kaynak kodu | Onaylı coding assistant ve repository politikası | Secret scanning, tenant kontrolü, repo scope |
| AI agent ile e-posta okuma | Yüksek riskli kullanım | Scoped OAuth, ayrı agent kimliği, loglama |
| AI agent ile işlem yapma | Kritik riskli kullanım | Least privilege, human-in-the-loop, işlem limiti |
Shadow AI için 15 maddelik kontrol listesi
- Kurum ağında ve yönetilen cihazlarda kullanılan AI servislerini keşfedin.
- OAuth ile kurumsal hesaplara bağlanan AI uygulamalarını envantere alın.
- AI agent’ları, botları ve low-code otomasyonları klasik uygulama envanterinden ayrı izleyin.
- Onaylı AI servisleri kataloğu oluşturun ve çalışanlara açık biçimde yayımlayın.
- Kişisel AI hesaplarında kurumsal veri kullanımına ilişkin açık kural belirleyin.
- Mevcut veri sınıflandırma modelini AI kullanım politikasıyla ilişkilendirin.
- Confidential ve Restricted sınıftaki verilerin onaysız AI servislerine aktarımını DLP ile kısıtlayın.
- Kurumsal AI servislerinde SSO, MFA ve merkezi kullanıcı yaşam döngüsü yönetimi kullanın.
- AI coding assistant’ları için kaynak kodu, secret ve repository erişim politikası belirleyin.
- Toplantı botları ve transkripsiyon araçları için kayıt, saklama ve katılımcı bilgilendirme kuralları oluşturun.
- Agent’lara ayrı kimlik verin; kişisel kullanıcı token’larının kontrolsüz biçimde yeniden kullanılmasını önleyin.
- Agent yetkilerini least privilege ilkesine göre sınırlandırın ve yüksek etkili işlemlerde insan onayı kullanın.
- AI servislerinin audit loglarını SIEM ve olay müdahalesi süreçlerine dahil edin.
- AI tedarikçilerini veri saklama, alt işleyen, model sağlayıcı, veri lokasyonu ve güvenlik kontrolleri açısından periyodik olarak yeniden değerlendirin.
- Shadow AI bulgularını yalnızca “politika ihlali” olarak değil, karşılanmamış iş ihtiyacının göstergesi olarak değerlendirin.
CISO ve yöneticilerin sorması gereken sorular
Kurumun AI güvenliği olgunluğunu anlamak için yüzlerce maddelik anketlere gerek yoktur. Aşağıdaki sorulara net cevap verilemiyorsa Shadow AI için önemli bir görünürlük boşluğu vardır.
- Şirketimizde bugün kaç farklı üretken AI servisi kullanılıyor?
- Hangileri kurumsal, hangileri kişisel hesaplarla kullanılıyor?
- Bu servislere hangi veri sınıfları gönderiliyor?
- Hangi AI uygulamaları kurumsal OAuth izinlerine sahip?
- Kurumsal e-posta, dosya, CRM veya kaynak koduna erişebilen agent var mı?
- Bu agent’ların sahibi kim ve kapatılması gerektiğinde merkezi olarak erişimi kesebiliyor muyuz?
- Hassas verinin onaysız AI servislerine gönderildiğini tespit edebiliyor muyuz?
- Bir AI güvenlik olayında geriye dönük inceleme yapabileceğimiz yeterli log var mı?
- Kullandığımız SaaS ürünlerine sonradan eklenen AI özelliklerini yeniden değerlendiriyor muyuz?
- Çalışanlara “kullanmayın” demenin yanında güvenli ve onaylı alternatif sunuyor muyuz?
Shadow AI bir teknoloji problemi değil, kontrol problemi
Shadow AI tartışmasını yalnızca ChatGPT, Claude, Gemini veya başka bir ürün üzerinden yürütmek bizi yanlış sonuca götürür. Bugün popüler olan servisler değişebilir; birkaç yıl içinde yapay zekâ işletim sistemlerinin, ofis araçlarının ve kurumsal uygulamaların doğal bileşeni haline gelecektir. Kalıcı mesele ürün adı değil, kontrol modelidir.
Kurumların cevaplaması gereken soru “çalışanlarımız AI kullanıyor mu?” değildir. Bunun cevabı giderek daha fazla kurum için zaten “evet” olacaktır. Asıl soru şudur: Hangi AI, hangi kimlikle, hangi veriye erişiyor, bu veriyi ne amaçla işliyor, hangi sistemlerle konuşuyor ve kurum adına hangi aksiyonları alabiliyor?
Bu soruların cevabı yoksa güvenlik ekibinin karşısındaki problem yalnızca Shadow IT’nin yeni bir versiyonu değildir. Kurumun veri akışlarının, kimliklerinin ve otomasyon yetkilerinin bir bölümünün görünürlük dışına çıkmasıdır.
Bu nedenle doğru strateji, üretken yapay zekâyı bütünüyle engellemek yerine kullanım alanlarını keşfetmek, riske göre sınıflandırmak, kabul edilebilir kullanım kurallarını belirlemek, güvenli kurumsal alternatifler sunmak ve veri ile kimlik etrafında teknik kontroller kurmaktır. Agentic AI yaygınlaştıkça bu yaklaşım daha da önemli hale gelecektir; çünkü geleceğin Shadow AI problemi yalnızca “veri nereye gitti?” sorusunu değil, “AI bizim adımıza ne yaptı?” sorusunu da içerecektir.
Son soru: Kurumunuz bir AI kullanım politikası yayımlamış olabilir. Peki bugün kurumunuzda gerçekte hangi AI sistemlerinin kullanıldığını, hangi veriye eriştiklerini ve hangi işlemleri yapabildiklerini görebiliyor musunuz?