BT Ekiplerinin Dilemması: AI Uzantısı Gerçekten AI Trafiği mi Taşıyor?

Paketin adresinde .ai geçmesi, paketin ağda bir yapay zekâ modeline istek gönderdiğini kanıtlamaz; bunu ancak istek kaydı, hedef uç nokta ve taşınan veri kanıtlayabilir.

Bu ayrım küçük görünür ama kurumsal BT için oldukça büyük sonuçları vardır. Bir eğitim platformunun alan adında “ai” bulunabilir, tanıtımında yapay zekâdan söz edilebilir, hatta platform bazı iş akışlarında yapay zekâ kullanabilir. Bunların hiçbiri, o anda incelenen SCORM eğitiminin bir AI servisiyle konuştuğu anlamına gelmez.

Bir kurumun İSG veya KVKK eğitimi için yüklediği SCORM paketi yalnızca HTML, JavaScript, görsel, video, soru ve standart SCORM iletişimi içerebilir. Bu durumda paketin yaptığı iş; LMS’e ilerleme, skor, tamamlanma ve bazen süre bilgisi yazmaktır. Ağdaki gerçek davranış budur. Alan adının çağrıştırdığı şey değil.

BT ekiplerinin önündeki asıl soru şu olmalı:

“Bu içerik ne diye adlandırılıyor?” değil, “Tarayıcı hangi hedefe, hangi veriyi, hangi amaçla gönderiyor?”

Bu yaklaşım bazen daha zahmetli görünür. Ama güvenlik zaten biraz budur: isim etiketlerini değil, davranışı incelemek. Bir kutunun üstünde “kimya seti” yazmasıyla içinden ne çıktığını öğrenemezsiniz. İnsanlar kutu etiketlerine güvenmeyi seviyor; ağ paketleri ise bu alışkanlığa pek saygı duymuyor.

Alan adı, teknoloji sınıflandırması değildir

Bir alan adındaki uzantı teknik bir beyan değildir. .ai, .com, .org ya da başka bir uzantı; uygulamanın hangi servislerle iletişim kurduğunu, veriyi nerede işlediğini veya istemciden hangi bilgileri çıkardığını açıklamaz.

Aynı şekilde bir ürünün broşüründe “AI” sözcüğünün geçmesi de tek başına güvenlik bulgusu değildir. Broşür, ürünün hangi problemlerde yapay zekâ kullandığını anlatabilir. Ağ kaydı ise o anda çalışan bileşenin gerçekte ne yaptığını gösterir. Bu ikisini karıştırmak, mimari incelemeyi pazarlama metni okumasına dönüştürür.

Nextrain’de yapay zekâ ile eğitim üretimi, içerik yapılandırma, soru üretimi, öğrenme yolculuğu tasarımı ve rapor üretimi gibi işler yapılabilir. Bunun yanında SCORM 1.2 ve SCORM 2004 paketleri içe aktarılabilir; yani kurumun daha önce ürettiği veya başka yerden aldığı içerikler tek çatı altında yönetilebilir.

Bu iki durum birbirinden ayrıdır:

Tablodaki en önemli satır, belki de üçüncüsü: AI işlevi gerçekten çağrılıyor mu? Bir AI özelliğinin ürün içinde var olması, her kursun, her kullanıcının ve her oturumun o özelliği kullandığı anlamına gelmez.

Bu, elektrikli bir binada her odada aynı anda fırının çalıştığını varsaymaya benzer. Kablo var olabilir; yük, anahtar açıldığında oluşur.

SCORM paketi aslında ne yapar?

SCORM, eğitimin LMS ile konuşabilmesini sağlayan bir standarttır. Bir paketin içinde genellikle içerik dosyaları, bir içerik manifesti ve eğitimin ilerlemesini yöneten JavaScript bulunur. Paket LMS içinde açıldığında, içerik tarayıcı üzerinden standart SCORM API’sine ulaşarak şu tür bilgileri iletebilir:

• Eğitime başlanıp başlanmadığı,
• Tamamlanma durumu,
• Başarı veya geçme durumu,
• Test skoru,
• Eğitimde geçirilen süre,
• Bazı tasarımlarda cevap veya etkileşim verileri.

SCORM 1.2 ile SCORM 2004 arasındaki farklar önemli olabilir; ancak AI trafiği incelemesinde temel soru değişmez: Paket, LMS’in standart öğrenme kayıtları dışında nereye konuşuyor?

Bir SCORM paketi teknik olarak tarayıcıda çalışan web içeriğidir. Bu yüzden paketin içine eklenen özel JavaScript kodu, izin verildiği ölçüde farklı ağ istekleri üretmeye çalışabilir. Bir paket harici görsel yükleyebilir, video çağırabilir, analiz verisi gönderebilir ya da bir API’ye istek yapabilir. Hatta tasarımcı isterse bir AI servisinin uç noktasına da bağlanabilir.

Ama “yapabilir” ile “yapıyor” arasında ağ geçidi kadar fark vardır.

SCORM standardının kendisi yapay zekâ çağrısı gerektirmez. Standart, öğrenme durumunun kaydedilmesiyle ilgilidir [SCORM 1.2, 2001; SCORM 2004, 2004]. Dolayısıyla bir SCORM paketi gördüğünde otomatik olarak “AI riski” etiketi yapıştırmak teknik sınıflandırma değil, ihtiyatın aceleci kuzeni olur.

BT ekibi ilk olarak nereye bakmalı?

Bir güvenlik değerlendirmesi, ürünü tek kelimeyle sınıflandırmak yerine veri akışını haritalamalıdır. Bence doğru başlangıç noktası, “AI var mı?” sorusunu daha gözlemlenebilir parçalara bölmektir.

1. Paket içeriğini açın ve manifesti okuyun

SCORM paketi genellikle sıkıştırılmış bir arşivdir. İnceleme şu dosyalardan başlayabilir:

• imsmanifest.xml
• HTML sayfaları
• JavaScript dosyaları
• Yapılandırma dosyaları
• Harici kaynak adresleri
• Video, görsel ve PDF bağlantıları

Manifest, paketin giriş noktasını ve kaynaklarını gösterir. Tek başına tüm ağ davranışını anlatmayabilir; fakat paketin yapısını anlamak için iyi bir başlangıçtır.

JavaScript dosyalarında özellikle şu ifadeler aranmalıdır:

fetch(
XMLHttpRequest
WebSocket
EventSource
sendBeacon
axios
https://
wss://

Bu kelimelerin bulunması otomatik olarak risk bulgusu değildir. Modern web içeriği ağ isteği yapabilir. İnceleme burada bitmez; bu çağrının hangi alan adına, hangi veriyle ve hangi zamanlarda yapıldığı incelenir.

Bir kursun video yüklemek için bir medya adresine gitmesi ile kullanıcının serbest metin sorusunu bir üretken model uç noktasına göndermesi aynı şey değildir. İkisi de “trafik”tir; ama risk profilleri, veri kategorileri ve denetim gereksinimleri farklıdır.

2. Tarayıcıdaki gerçek ağ kaydını izleyin

Bir SCORM paketi, test ortamında normal kullanıcı akışıyla çalıştırılmalıdır. Sadece ana ekranı açmak yetmez. Quiz çözülmeli, bölümler geçilmeli, video açılmalı, varsa serbest metin alanları doldurulmalı ve tamamlanma süreci bitirilmelidir.

Sonra tarayıcının ağ kayıtlarında şu sorular sorulmalıdır:

• İstekler hangi alan adlarına gidiyor?
• İstek yöntemi ne: GET, POST, PUT?
• İstek gövdesinde ne var?
• Yanıt akış hâlinde mi geliyor?
• İstek, kullanıcı bir eylem yaptığında mı oluşuyor?
• Aynı istek her oturumda mı, yalnızca belirli bir etkileşimde mi oluşuyor?
• Trafik LMS alan adıyla mı sınırlı, yoksa yeni harici hedefler var mı?

Özellikle POST istekleri dikkat ister. Çünkü istemciden veri gönderildiğini gösterebilir. Yine de her POST AI çağrısı değildir: skor kaydı, form gönderimi, oturum yönetimi veya olay kaydı da olabilir. Bu ayrımı yapmadan “POST gördük, AI var” sonucuna ulaşmak, yağmur görünce her bulutu yangın sanmaya benzer.

3. DNS, proxy ve güvenlik duvarı kayıtlarını birlikte okuyun

Tarayıcı geliştirici araçları kullanışlıdır; ancak kurumsal ağ görünümü daha geniştir. BT ekibi mümkünse şu kayıtları aynı zaman aralığında karşılaştırmalıdır:

• DNS sorguları,
• Güvenli web geçidi veya proxy kayıtları,
• Güvenlik duvarı çıkış kayıtları,
• Uygulama erişim kayıtları,
• CDN ve medya istekleri,
• Kimlik doğrulama olayları.

Bir içeriğin yalnızca onaylı alan adlarına erişmesi, açıklanabilir ve sınırlı bir ağ davranışıdır. Yeni veya bilinmeyen uç noktalara yapılan çağrılar ise araştırılmalıdır. Buradaki ölçüt “adı AI gibi mi duruyor?” olmamalı. Bazı AI servisleri sıradan görünen alan adları kullanabilir; bazı tamamen AI’siz platformlar ise .ai uzantılı olabilir.

Ağın gözünden bakınca uzantılar dekor, yönlendirme kayıtları ise delildir.

AI trafiğini ayırt etmek için hangi işaretler önemlidir?

AI trafiği tek bir teknik imzaya sahip değildir. Ancak bazı işaretler, incelemeyi doğru yere yönlendirebilir.

Bir üretken AI etkileşiminde sıklıkla şunlar görülür:

• Kullanıcının yazdığı serbest metnin istek gövdesinde yer alması,
• Uzun metin parçalarının veya belge içeriklerinin gönderilmesi,
• İstek-yanıtın sohbet biçiminde ilerlemesi,
• Akış hâlinde yanıt alınması,
• Kullanıcının sorusuna göre değişen, dinamik metin üretimi,
• Bir model veya çıkarım servisine yönelik çağrı yapısı.

Buna karşılık aşağıdaki davranışlar tek başına AI çağrısı değildir:

• SCORM tamamlama durumunun kaydedilmesi,
• Quiz skorunun gönderilmesi,
• Video oynatma olayının kaydedilmesi,
• Sertifika koşulunun kontrol edilmesi,
• Eğitim ilerlemesinin raporlanması,
• Görsel, font veya video dosyasının yüklenmesi.

Nextrain’de AI destekli yardım gibi etkileşimler eğitim içinde tasarlanabilir. Böyle bir etkileşim kullanılıyorsa, BT ekibinin onu ayrı bir akış olarak değerlendirmesi gerekir. Buna karşılık AI etkileşimi içermeyen klasik bir SCORM paketinin davranışı, paket içeriği ve ağ izleri üzerinden değerlendirilmelidir. Aynı platformda bulunmaları, aynı ağ davranışına sahip olduklarını göstermez.

Bu noktada Kalde'nin senaryo yazarken yaptığı o ısrarlı ayrım aklıma geliyor: hikâyede sonucu değiştiren şey, karakterin hangi kapının önünde durduğu değil, hangi seçimi yaptığıdır. Ağ incelemesinde de alan adı kapıdır; istek ise seçim. Güvenlik kararı ikincisine dayanmalı.

“Hepsini kapatalım” neden yeterli bir politika değil?

Kurumların yapay zekâ konusunda temkinli olması anlaşılır. Özellikle KVKK kapsamındaki veriler, müşteri bilgileri, ticari sırlar, sağlık bilgileri veya çalışan performans verileri söz konusu olduğunda temkin bir fazlalık değil, tasarım şartıdır.

Ama her şeyi tek kategoride engellemek iki farklı maliyeti görünmez kılabilir:

1. Gerçek riskler gözden kaçabilir.
   .ai uzantısı olmayan bir servis de veri dışarı çıkarabilir. Alan adı filtresi, veri akışı denetiminin yerine geçmez.

2. Zararsız veya gerekli eğitim akışları kesilebilir.
   AI çağrısı yapmayan bir SCORM içeriği, yalnızca alan adı çağrışımı yüzünden engellenirse çalışan eğitime erişemez; BT ise hangi teknik davranışı engellediğini net olarak açıklayamaz.

Benim karşıma çıkan daha ilginç durum şu: Aynı kurum, bir yandan “AI içeren her şeyi kapatalım” diyebiliyor; diğer yandan eğitim raporunun neden güncel olmadığını sorabiliyor. Bu çelişki kötü niyetli değil. İnsanlar çoğu zaman riskten korunmakla operasyonun devam etmesi arasındaki bağı ayrı ekranlarda düşünüyor. Sistemler ise ikisini aynı anda yaşamak zorunda.

Daha iyi politika, kategorik yasaktan önce şu ayrımları yapar:

• AI işlevi kullanılıyor mu?
• Kullanılıyorsa hangi veri gönderiliyor?
• Bu veri kişisel veri, hassas veri veya kurum içi gizli bilgi içeriyor mu?
• İstek hangi onaylı uç noktaya gidiyor?
• Veri aktarımı ve saklama koşulları kurum politikasına uygun mu?
• AI işlevi kullanılmıyorsa, içerik standart SCORM akışıyla mı çalışıyor?

Bu, güvenliği gevşetmek değildir. Tersine, denetimi daha isabetli hâle getirmektir.

SCORM ve AI incelemesi için uygulanabilir kontrol listesi

BT, bilgi güvenliği, hukuk ve eğitim ekipleri aynı dosyaya farklı sorularla bakar. En sağlıklısı, değerlendirmeyi tek bir ekibe bırakmamak; fakat sorumlulukları da bulanıklaştırmamaktır.

Aşağıdaki kontrol listesi ilk değerlendirme için kullanılabilir:

• SCORM paketi arşivden çıkarıldı mı?
• Manifest, HTML ve JavaScript dosyaları incelendi mi?
• Harici URL’ler listelendi mi?
• Paket test ortamında uçtan uca çalıştırıldı mı?
• Tarayıcı ağ kayıtları dışa aktarıldı mı?
• DNS ve proxy kayıtlarıyla karşılaştırma yapıldı mı?
• İstek gövdelerinde kişisel veri, serbest metin veya belge içeriği var mı?
• AI etkileşimi varsa, hangi kullanıcı eyleminin çağrıyı başlattığı belirlendi mi?
• Yalnızca gerekli alan adları için erişim kuralı tanımlandı mı?
• KVKK açısından veri kategorileri ve aktarım şartları değerlendirildi mi?
• Eğitimin kesilmesi hâlinde iş, uyum veya İSG etkisi belgelendi mi?
• Karar “alan adı” yerine gözlemlenen trafik ve veri akışıyla gerekçelendirildi mi?

Bu liste bir bürokrasi ritüeli değil. İyi tutulmuş bir inceleme kaydı, altı ay sonra “Bu erişimi neden açmıştık?” sorusu geldiğinde hafızadan daha güvenilir olur. İnsan hafızası şaşırtıcı derecede yaratıcıdır; loglar o kadar yaratıcı değildir.

Sonuç: Broşür niyeti anlatır, ağ davranışı kanıtlar

Bir kurum yapay zekâ kullanımı konusunda sınır koyabilir. Hatta çok sıkı sınırlar koyabilir. Bu, gayet meşru bir yönetim tercihidir. Fakat sınırın teknik karşılığı; alan adı uzantısı, ürün kategorisi ya da broşürdeki tek bir kelime olmamalıdır.

BT ekibinin incelemesi üç katmanda ilerlemelidir:

1. Paket ne içeriyor?
   Manifest, JavaScript, harici kaynaklar ve yapılandırmalar.

2. Tarayıcı ne yapıyor?
   Gerçek kullanıcı akışındaki ağ istekleri, hedefler ve veri gövdeleri.

3. Kurum açısından anlamı ne?
   KVKK, veri sınıflandırması, izinli uç noktalar, erişim kontrolü ve operasyonel etki.

Bir AI özelliği olan sistem ile her oturumda AI trafiği üreten sistem aynı şey değildir. Bir .ai alan adı da AI çağrısının delili değildir. Delil; ağda yaşayan, zaman damgası olan, hedefi ve yükü görülebilen istektir.

BT ekipleri için en güvenli refleks “her şeyi kapatmak” değil, hangi kapının gerçekten açıldığını görmek olmalı. Bu yaklaşım hem güvenliği daha ciddi ele alır hem de eğitim, uyum ve İSG süreçlerini gereksiz bir karanlıkta bırakmaz.

Notlar

1. SCORM 1.2, 2001. Öğrenme içeriğinin LMS ile iletişimi için standart teknik model.
2. SCORM 2004, 2004. Sıralama ve gezinme kuralları dahil olmak üzere genişletilmiş SCORM standardı.