Yapay Zekâ Kullanım ve Departman Uygulamaları Politikası

Politikanın Gerekçesi

Şirket bünyesindeki departmanlar, yapay zekâ (YZ) araçlarından yararlanarak kendi ihtiyaçlarına yönelik uygulama ve otomasyonlar geliştirmeye başlamıştır. Bu eğilim, operasyonel verimlilik açısından Şirket tarafından desteklenmektedir.

Bununla birlikte söz konusu uygulamaların Teknoloji Birimi'nin bilgisi dışında geliştirilmesi ve geliştirme tamamlandıktan sonra yayına alınması, işletilmesi ya da bakımının üstlenilmesi talebiyle Teknoloji Birimi'ne iletilmesi; sahipliği belirsiz ve güvenlik değerlendirmesinden geçmemiş sistemlerin Şirket altyapısına dahil olması riskini doğurmaktadır.

Bu durumun başlıca riskleri aşağıda belirtilmiştir:

• Kişisel verilerin korunması: Öğrenci kitlesinin önemli bir bölümünün 18 yaş altında olması nedeniyle öğrenci, veli ve çalışan verilerinin kişisel YZ hesaplarına veya yurt dışında konumlanan hizmetlere aktarılması, 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) kapsamında hukuki ve itibari risk oluşturmaktadır.
• Bilgi güvenliği: YZ desteğiyle kısa sürede geliştirilen yazılımlarda kimlik doğrulaması bulunmayan uç noktalar, kaynak koda eklenmiş erişim anahtarları ve internete açık veritabanları sıklıkla görülmektedir. Bu tür bir açık, uygulamanın bağlı olduğu Redshift ve iç API'ler gibi ana sistemleri de etkileyebilmektedir.
• Sahiplik ve süreklilik: Uygulamayı geliştiren çalışanın ayrılması veya uygulamanın arızalanması halinde bakım ve destek sorumluluğu belirsiz kalmaktadır.
• Maliyet kontrolü: Kişisel ödeme araçlarıyla açılan abonelikler, limitsiz API kullanımı ve izlenmeyen bulut harcamaları bütçe dışı maliyet oluşturmaktadır.
• Veri bütünlüğü: Aynı verinin birden fazla uygulamada kopyalanması, doğru ve güncel verinin hangisi olduğu konusunda belirsizlik yaratmakta; ana sistemlere doğrudan yazan uygulamalar ise Şirket'in ana verisinin bütünlüğünü bozma riski taşımaktadır.

Bu politika YZ kullanımını kısıtlamak veya departmanların geliştirme hızını yavaşlatmak amacıyla hazırlanmamıştır. Politikanın amacı, departmanların hızlı biçimde uygulama geliştirip yayına alabilmesini desteklemek ve bunu yaparken yalnızca vazgeçilemeyecek asgari koşulları tanımlamaktır. Düşük riskli uygulamalar herhangi bir onay beklenmeksizin, kısa bir kayıt ve öz kontrolle aynı gün yayına alınabilir. Onay gerektiren durumlar kişisel veri, dış kullanıcı ve kritik iş bağımlılığı ile sınırlı tutulmuş ve en geç üç iş günü ile süreye bağlanmıştır.

Teknoloji Birimi kuralları belirler, hazır şablon ve otomatik kontrollerle süreci kolaylaştırır ve ortak sistemleri korur. Departmanlarca geliştirilen uygulamaların yayına alınması, işletilmesi, bakımı ve kullanıcı desteği ise sahip departmanın sorumluluğundadır.

1. Amaç

Bu politikanın amacı; çalışanların YZ araçlarını güvenli, maliyet bilinciyle ve sorumlu biçimde kullanmasına ilişkin kuralları belirlemek ve departmanlarca YZ desteğiyle geliştirilen uygulamaların fikir aşamasından kapatılmasına kadar tüm yaşam döngüsü boyunca sorumluluk dağılımını tanımlamaktır.

Politika, departmanların üretkenliğini engellemeksizin veri dağınıklığı, kişisel veri ihlali, bakım borcu, kontrolsüz maliyet, erişim ve entegrasyon risklerinin yönetilebilir düzeyde tutulmasını hedefler.

2. Kapsam

Bu politika aşağıdakileri kapsar:

• YZ araçlarını (Claude, Cursor, ChatGPT vb.) iş amacıyla kullanan tüm çalışanlar, öğretmenler ve Şirket adına hizmet veren dış kaynaklar,
• YZ desteğiyle uygulama, otomasyon veya araç geliştiren, yayımlayan ya da işleten tüm departmanlar,
• Söz konusu uygulamaların Şirket verilerine, mevcut sistemlere ve ortak altyapıya erişimi,
• Politikanın yürürlüğe girdiği tarihte kullanımda bulunan departman uygulamaları (geçiş hükümleri Bölüm 14'te düzenlenmiştir).

Teknoloji Birimi'nin kendi yol haritası kapsamında geliştirdiği ürünler bu politikaya değil, Şirket'in yazılım geliştirme süreçlerine tabidir.

3. Tanımlar

4. Temel İlkeler

1. Politika hızlandırıcıdır, engel değildir. Süreç adımları riskle orantılıdır. Düşük riskli uygulamalar onay beklenmeksizin yayına alınır; onay gerektiren adımlar süreye bağlıdır. Riski anlamlı ölçüde azaltmayan hiçbir adım zorunlu tutulmaz.
2. Geliştiren sahiplenir. Uygulamayı geliştiren departman; fikir, geliştirme, test, yayın, kullanıcı desteği, hata giderme, güncelleme, yedekleme, maliyet, devir ve kapatma dahil olmak üzere tüm yaşam döngüsünün sahibidir. Arıza, büyüme veya geliştiren çalışanın ayrılması gibi durumlar sorumluluğu Teknoloji Birimi'ne devretmez.
3. Teknoloji Birimi kolaylaştırıcı ve gözlemcidir. Teknoloji Birimi hazır şablon, skill seti ve otomatik kontrollerle departmanların hızlı ve güvenli başlangıç yapmasını sağlar. Bir kaydı incelemesi veya görüş bildirmesi, uygulamanın doğru ve güvenli çalıştığına ilişkin bir kabul ya da bakım taahhüdü niteliği taşımaz.
4. Kayıt olmaksızın yayın yapılamaz. Proje kaydı yaklaşık beş dakikada doldurulan kısa bir formdur. Kaydı bulunmayan uygulamalara ortak altyapı, Şirket alan adı ve Şirket verilerine erişim tanınmaz.
5. Risk bazlı değerlendirme esastır. Düşük riskli uygulamalarda yayın kararı departman yöneticisine aittir; kişisel veri, dış kullanıcı veya kritik bağımlılık bulunması halinde süreye bağlı hedefli değerlendirme yapılır.
6. Kişisel verinin korunması önceliklidir. Öğrenci, veli ve çalışan verileri KVKK'ya uygun şekilde işlenir; geliştirme hızı gerekçesiyle kişisel verinin korunmasından taviz verilmez.
7. Tüm varlıklar Şirket kontrolündedir. Kaynak kod, hesaplar, erişim anahtarları, alan adları ve abonelikler Şirket'e aittir ve Şirket hesaplarında tutulur.
8. Ana veri salt okunur, uygulama verisi kapsüllenir. Departman uygulamaları Şirket'in ana verisine yalnızca salt okunur API veya view üzerinden erişir; ana sistemlere yazma yetkisi hiçbir koşulda verilmez. Her uygulama kendi ürettiği veriyi yalnızca kendisine ait ayrı bir veritabanında tutar. Ana veri her zaman tek doğru kaynaktır.
9. Maliyetler görünür kılınır. Abonelik, geliştirme ve canlı ortam tüketim maliyetleri limitler ve uyarılar aracılığıyla izlenir.

5. Roller ve Sorumluluklar

Teknoloji Birimi'nin sorumluluğunda olmayan hususlar: Kod incelemesi, test, sürüm onayı, dağıtım (deployment), günlük izleme, hata ayıklama ve kullanıcı desteği Teknoloji Birimi'nin taahhütleri arasında yer almaz. Düzenli danışma saati, inceleme süresi garantisi veya projeye özel eğitim ve mentorluk sağlanmaz. Yeni API talepleri otomatik olarak iş taahhüdü doğurmaz.

6. Eğitim, Hesaplar ve YZ Araçlarına Veri Girişi

6.1 Eğitimler

YZ aracı hesabı talep edildiği gün açılır; eğitimlerin tamamlanması hesap açılışının ön koşulu değildir. Zorunlu eğitimler hesap açılışından itibaren 14 gün içinde tamamlanır. Bu süre içinde tamamlanmayan hesaplar, eğitim tamamlanana kadar askıya alınır.

Zorunlu eğitimler asgari düzeyde tutulmuştur; diğer eğitimler öneri niteliğindedir.

Eğitimlerin dili İngilizcedir; Türkçe özet materyal hazırlanması Bölüm 16'da açık karar olarak yer almaktadır. Teknoloji Birimi projeye özel eğitim veya mentorluk sağlamaz.

6.2 Hesaplar, limitler ve harcamalar

• Hesaplar Şirket adına kurumsal (business) hesap olarak açılır. Kurumsal hesaplarda girilen veriler, hizmet sağlayıcının kurumsal sözleşme koşulları gereği model eğitiminde kullanılmaz; bu husus her sağlayıcının sözleşmesinde ayrıca teyit edilir. Kişisel hesaplarda bu güvence bulunmamaktadır.
• Şirket işleri kişisel hesaplar veya kişisel ödeme araçlarıyla yürütülemez. Departmanlar adına kişisel olarak açılmış abonelikler, politikanın yürürlüğe girmesinden itibaren 30 gün içinde Şirket hesabına taşınır veya kapatılır.
• Kullanıcı ve departman bazında kullanım limitleri tanımlanır; harcamalar otomatik olarak raporlanır.
• Merkezi erişim için LiteLLM tabanlı bir YZ erişim katmanı (gateway) veya doğrudan AWS Bedrock kullanımı değerlendirilmektedir (Bölüm 16).
• Model seçiminde işi karşılayan en uygun maliyetli model tercih edilir. Metin çıkarma, sınıflandırma ve özetleme gibi işlerde küçük modeller yeterlidir; üst düzey modeller karmaşık akıl yürütme ve yazılım geliştirme işleri için kullanılır.

6.3 YZ araçlarına veri girişi

Bir verinin YZ araçlarına girilip girilemeyeceği konusunda tereddüt bulunması halinde departman yöneticisinin görüşü alınır. Kişisel verinin sehven girilmesi durumunda konu Bölüm 12 uyarınca aynı gün bildirilir.

7. Teknoloji ve Güvenlik Standartları

7.1 Varsayılan teknoloji yığını

Departman uygulamaları için varsayılan teknoloji yığını Node.js (çalışma ortamı), Next.js (web uygulaması), PostgreSQL (veritabanı) ve Docker (paketleme ve dağıtım) olarak belirlenmiştir. Varsayılan yığınla geliştirilen uygulamalar hazır şablon, ortak altyapı ve otomatik kontrollerden doğrudan yararlanır.

Farklı bir teknolojinin kullanılması onaya tabi değildir; tercih edilen teknoloji proje kaydında belirtilir. Ancak varsayılan yığın dışındaki uygulamalar hazır şablon ve ortak altyapı desteğinden yararlanamayabilir.

Kaynak kod, Şirket'in GitHub organizasyonu altındaki bir depoda tutulur.

7.2 Hazır şablon, otomatik kontroller ve skill seti

Departmanların hızlı ve güvenli başlangıç yapabilmesi için Teknoloji Birimi koordinasyonunda aşağıdakiler hazırlanır:

• Kimlik doğrulama, yetkilendirme ve temel güvenlik ayarları hazır olarak gelen proje şablonu,
• Gizli anahtar ve paket güvenliği taramalarını her kod gönderiminde otomatik olarak çalıştıran sürekli entegrasyon (CI) yapılandırması,
• YZ araçlarının bu standartlara uygun kod üretmesine yardımcı olan ortak skill seti.

Şablonla başlatılan uygulamalarda Bölüm 7.3'teki kontrollerin büyük bölümü otomatik olarak karşılanır. Skill ve talimatlar YZ aracına yol gösterir ancak bunlara uyulacağını garanti etmez; otomatik kontrollerin sonuçlarının takibi sahip departmanın sorumluluğundadır.

7.3 Asgari güvenlik kontrolleri

Tüm uygulamalar yayın öncesinde aşağıdaki koşulları sağlar:

• Uygulama yalnızca kendi veritabanına yazar; ana sistemlere ve Redshift'e yalnızca salt okunur yetkiye sahip, uygulamaya özel bir kullanıcıyla bağlanılır.
• Gizli anahtarlar ve .env dosyaları kaynak kodda veya depoda bulunmaz.
• Tüm uç noktalarda kimlik doğrulama ve yetki kontrolü bulunur; bir kullanıcının başka bir kullanıcının verisine erişmesi engellenir.
• Veritabanı internete açık değildir.
• Kullanılan paketler güvenlik açıklarına karşı taranır.
• Dış kullanıcılara açılan uygulamalarda ayrıca HTTPS, istek sınırlama (rate limiting) ve hata mesajlarında iç sistem bilgisinin gösterilmemesi zorunludur.

8. Uygulama Yaşam Döngüsü

Her departman uygulaması kısa bir proje kaydıyla başlar ve risk seviyesine göre yayına alınır. Düşük riskli uygulamalar onay beklenmeksizin aynı gün; yüksek riskli uygulamalar ise en geç üç iş günü içinde sonuçlandırılan hedefli değerlendirmenin ardından yayına alınabilir.

Düşük riskli uygulamalarda yayın kararı departman yöneticisine aittir ve herhangi bir birimin onayı beklenmez. Yüksek riskli uygulamalarda hedefli değerlendirmede tespit edilen eksiklikler, giderilmek üzere sahip departmana iade edilir.

8.1 Başlangıç: proje kaydı

• Proje kaydı, geliştirme başlarken doldurulan ve yaklaşık beş dakika süren kısa bir formdur (Ek A). Yalnızca zorunlu alanlar doldurulur; diğer alanlar ihtiyaç doğdukça eklenir.
• İlk denemeler örnek veya anonimleştirilmiş verilerle yapılır. Gerçek kişisel verilerle prototip geliştirilmez.

8.2 Yayın kararı

• Düşük riskli uygulamalar: Yayın kararı departman yöneticisine aittir. Ek B'deki temel kontrol listesi tamamlandığında uygulama, herhangi bir onay beklenmeksizin aynı gün yayına alınabilir. Teknoloji Birimi her uygulama için onay makamı değildir.
• Hedefli değerlendirme gerektiren durumlar: Kişisel veya hassas veri işlenmesi, dış kullanıcılar (B2B müşteriler, öğrenciler, veliler) ve kritik iş bağımlılığı.
• Hedefli değerlendirme süreye bağlıdır. Talep proje kaydı üzerinden iletilir; değerlendirme toplantı zorunluluğu olmaksızın yazılı olarak yürütülür ve en geç üç iş günü içinde sonuçlandırılır. Süresi içinde sonuçlandırılamayan değerlendirmeler doğrudan yönetime iletilir.
• Hedefli değerlendirme bir kez yapılır; uygulamanın risk profilini değiştiren bir güncelleme olmadıkça sonraki sürümlerde tekrarlanmaz.
• Değerlendirme sürerken uygulama örnek verilerle ve sınırlı bir iç kullanıcı grubuyla kullanılmaya devam edebilir.
• Teknoloji Birimi'nin hedefli değerlendirmedeki rolü; kendi sistemlerine erişim, ortak altyapıya etki ve Bölüm 7.3'te tanımlanan asgari güvenlik koşullarıyla sınırlıdır. Dış kullanıcılara açılan bir uygulamanın bu koşulları sağlamaması halinde Teknoloji Birimi yayını durdurur.
• Öğrencilere açılan uygulamalarda aydınlatma metni ve gerekli hallerde veli onayı KVKK sorumlusuyla netleştirilir; YZ ile üretilen eğitsel içerik öğrenciye sunulmadan önce öğretmen kontrolünden geçirilir (Bölüm 10).

8.3 Yayın öncesi hazırlık

Yayın öncesi hazırlık, risk seviyesine göre Ek B'deki kontrol listesiyle yapılır ve departman yöneticisi tarafından onaylanır:

• Tüm uygulamalar: Kaynak kod ve hesaplar Şirket kontrolündedir; teknik sorumlu ve yedek belirlenmiştir; kısa bir kurulum notu mevcuttur; temel iş akışları ve yetki sınırları test edilmiştir; Bölüm 7.3'teki kontroller tamamlanmıştır.
• Yüksek riskli uygulamalar için ek olarak: Test ve canlı ortamlar ayrıdır; geri dönüş planı mevcuttur; yedekleme ve geri yükleme denenmiştir; uygulamanın çalışmaması halinde izlenecek alternatif yöntem tanımlanmıştır.

8.4 Yayın sonrası izleme

• Kullanım: 90 gün boyunca kullanılmayan uygulamalar kapatılmak üzere değerlendirmeye alınır.
• Maliyet: Maliyetler, tanımlı limitler ve otomatik uyarılar aracılığıyla izlenir.
• Kayıt güncelliği: Proje kaydı yalnızca uygulamanın risk seviyesini, veri kaynaklarını veya sahipliğini değiştiren durumlarda güncellenir.

8.5 Bakım

Güncelleme, yedekleme, hata giderme ve kullanıcı desteği sahip departmanın ve teknik sorumlunun yükümlülüğündedir. Departman yöneticisi bakım için gerekli zamanı ve bütçeyi ayırır; bunun mümkün olmaması halinde uygulamanın kapsamını daraltır veya uygulamayı kapatır.

9. Veri, KVKK ve Mevcut Sistemlere Erişim

9.1 Kişisel veriler ve KVKK

• Kişisel veri işleyen her uygulama hedefli değerlendirmeye tabidir; KVKK sorumlusunun görüşü proje kaydına eklenir.
• Veri minimizasyonu: Uygulama, amacı için gerekli olan asgari veriyi işler. İhtiyaç duyulmayan kişisel veri alanları toplanmaz ve saklanmaz.
• Kişisel verinin bir YZ modeline iletilmesi durumunda modelin çalıştığı konum ve verinin yurt dışına aktarılıp aktarılmadığı proje kaydında belirtilir. Yurt dışına aktarım, KVKK'nın 9. maddesi kapsamındaki aktarım kuralları çerçevesinde KVKK sorumlusu ile birlikte değerlendirilir. Mümkün olan hallerde veri, modele iletilmeden önce anonimleştirilir veya takma adla değiştirilir.
• Saklama ve imha süreleri uygulamanın tasarım aşamasında belirlenir; süresi dolan veriler imha edilir.
• Öğrenci ve veli verilerine ilişkin aydınlatma metni ve gerekli hallerde açık rıza süreci KVKK sorumlusuyla netleştirilmeden uygulama yayına alınmaz.

9.2 Ana veri ve uygulama verisi

Departman uygulamalarının veriyle ilişkisi aşağıdaki kurallara dayanır:

• Ana veri salt okunurdur. Şirket'in ana sistemlerindeki veriler departman uygulamalarına yalnızca okuma amacıyla açılır. Departman uygulamalarına ana sistemlere veya ana veritabanlarına yazma yetkisi hiçbir koşulda verilmez; bu kural istisna sürecine tabi değildir.
• Uygulama verisi kapsüllenir. Her uygulama, kendi ürettiği veriyi yalnızca kendisine ait ayrı bir veritabanında tutar. Bu veritabanı başka uygulamalarla paylaşılmaz ve ana sistemlere geri yazılmaz.
• Asıl kaynak ana sistemdir. Okunan ana veri uygulamada saklanacaksa yalnızca önbellek niteliğinde tutulur; asıl kaynağı ve güncellenme yöntemi proje kaydında belirtilir. Departman uygulamasındaki kopya, başka sistemlere doğru veri kaynağı olarak sunulmaz.
• Ana veride değişiklik ihtiyacı departman uygulaması üzerinden değil, ilgili ana sistemin kendi süreçleri ve veri/sistem sahibi aracılığıyla karşılanır.
• Erişim kapsamı: Salt okunur erişimin kapsamı veri/sistem sahibi tarafından belirlenir. Sahip departman; uygulama içindeki kullanıcı yetkilerini, kendi veritabanındaki verileri, saklama ve imha sürelerini ve kayıtları (log) yönetir.

9.3 Redshift ve iç API'ler

• Redshift: Belirli view veya tablolara, salt okunur yetkiyle, sorgu sınırları tanımlanarak ve uygulamaya özel bir kullanıcı hesabı üzerinden erişim verilir. Uygulamalar kişisel kullanıcı hesaplarıyla bağlantı kuramaz. Sahip departman, uygulamayı veri güncelliği ve erişilebilirlik koşullarını dikkate alarak tasarlar.
• API'ler: Ana veriye erişim için Teknoloji Birimi tarafından salt okunur API'ler sağlanır; öncelikle mevcut API'ler kullanılır. Departman uygulamalarına ana veriyi değiştiren veya ana sistemlerde işlem başlatan API erişimi verilmez. Yeni bir okuma API'si ihtiyacı halinde Teknoloji Birimi'ne gereksinimleri ayrıntılı olarak açıklayan bir talep iletilir; talep ayrıca önceliklendirilir ve kapasite durumuna göre değerlendirilir.
• Kayıt tutma: Uygulamanın kendi veritabanında kayıt değiştiren veya işlem başlatan işlemler; işlemi yapan, işlem zamanı ve işlem içeriği bilgileriyle kayıt altına alınır.
• Bağımlılık kaydı: Uygulamanın kullandığı API ve view'lar proje kaydında tutulur. Ana sistemlerde yapılan değişikliklerde departman uygulamalarının gözetilmesi zorunlu değildir; bu değişikliklere uyum sağlanması sahip departmanın sorumluluğundadır.

10. Uygulama İçinde YZ Kullanımı

Çalışma sırasında YZ modeli kullanan uygulamalarda aşağıdaki hususlar sahip departmanın iş akışına dahil edilir:

• Çıktı kontrolü: YZ çıktıları doğrudan doğru kabul edilmez; hatalı sonucun olası etkisine göre örneklem bazlı veya tam kontrol uygulanır.
• Eğitsel içerikte insan onayı: Öğrencilere sunulan soru, çözüm, açıklama ve geri bildirim gibi YZ ile üretilmiş içerikler, yayımlanmadan önce ilgili alan öğretmeni tarafından kontrol edilir.
• Değişiklik sonrası test: Model veya komut (prompt) değişikliklerinin ardından temel senaryolar yeniden test edilir.
• Agent yetkileri: YZ ajanları (agent) yalnızca görevleri için gerekli araç ve verilere erişir. Silme, ödeme işlemi ve toplu mesaj gönderimi gibi geri alınamayan işlemlerde insan onayı zorunludur.
• Komut enjeksiyonu (prompt injection): Kullanıcılardan veya dış kaynaklardan (e-posta, doküman, web sayfası) gelen içerik modele talimat olarak değil veri olarak iletilir; bu içeriklerin ajan üzerinden yetkili işlem başlatması engellenir.
• Şeffaflık: Kullanıcılar, bir YZ sistemiyle etkileşimde bulunduklarından veya içeriğin YZ ile üretildiğinden haberdar edilir.
• Harcama limiti: Her uygulamanın YZ API anahtarı için aylık harcama limiti tanımlanır.

11. Barındırma, Ortak Servisler ve Maliyet

• Barındırma: Sahip departman; barındırma, uygulama ve veritabanı işletimi, güncelleme, yedekleme ve servis maliyetlerini planlar ve işletebileceği bir çözüm seçer. Hesap sahipliği Şirket'te kalır; günlük yönetim sorumlusu proje kaydında belirtilir.
• Alan adı: Alan adı ve barındırma hesapları Şirket adına açılır. Şirket alan adına bağlı alt alan adları yalnızca kayıtlı uygulamalara tahsis edilir.
• Ortak servisler: Ofis sunucusu, Coolify/Easypanel veya merkezi YZ erişim katmanı kurulması halinde bu servislerin işletme sahibi ve bütçesi ayrıca belirlenir. Bu görevin Teknoloji Birimi'ne verilmesi durumunda birimin sorumluluğu yalnızca ilgili altyapının işletimiyle sınırlıdır; altyapı üzerinde çalışan departman uygulamaları bu sorumluluğun kapsamı dışındadır.
• Maliyet takibi: Abonelik, geliştirme ve canlı ortam tüketim maliyetleri ayrı ayrı izlenir. Bütçe ve limitlerin belirlenmesi, uyarı alıcılarının tanımlanması ve limit aşımında hizmetin durdurulması kararı sahip departmana aittir. Teknoloji Birimi maliyet özetlerini ve ortak kaynak ihlallerini izleyebilir.
• Limit doğrulama: Kullanılan araçların tanımlı limitleri fiilen uygulayabildiği, ilgili hizmetin işletme sahibi tarafından doğrulanır. Yalnızca bildirim gönderen ve harcamayı durdurmayan mekanizmalar limit olarak kabul edilmez.

12. Arıza, Güvenlik Olayı ve Büyüme

• Arıza ve şikâyet: Uygulama arızaları, hatalı sonuçlar ve kullanıcı şikâyetleri sahip departmana iletilir. İlk müdahale, kullanıcı iletişimi ve alternatif sürecin işletilmesi sahip departman tarafından yürütülür.
• Güvenlik olayı: Veri sızıntısı, yetkisiz erişim, erişim anahtarının ifşası, YZ aracına kişisel verinin sehven girilmesi veya ortak sistemleri etkileyen her türlü olay aynı gün içinde Şirket olay yönetimi sürecine ve KVKK sorumlusuna bildirilir. Kişisel veri ihlallerine ilişkin yasal bildirim sürelerinin kısa olması nedeniyle bildirimde gecikme yapılmaz.
• İzolasyon: Teknoloji Birimi, yönetim tarafından tanımlanan yetki çerçevesinde kendi yönettiği sistemlerde riski izole edebilir (erişimin kapatılması, anahtarın iptali, uygulamanın ortak altyapıdan ayrılması vb.). Uygulamanın düzeltilmesi sahip departmanın sorumluluğundadır.
• Kritik hale gelen uygulamalar: Bir uygulamanın birden fazla departmanın günlük işleyişi, gelir veya öğrenci deneyimi açısından kritik hale gelmesi durumunda yönetim, sahip departman ve ilgili sistem sahibi yeni destek modelini birlikte belirler. Uygulamanın Teknoloji Birimi tarafından devralınması ancak ayrıca tanımlanan kapsam, kaynak ve açık mutabakat ile mümkündür; bu karar alınana kadar mevcut sahiplik devam eder.

13. Raporlama, Devir ve Kapatma

• Raporlama: Sahip departman, üç ayda bir uygulamanın sağladığı faydayı ve toplam maliyetini kısa bir notla proje kaydına ekler.
• Personel ayrılışı ve devir: Ayrılan çalışanın sorumluluğundaki uygulamanın devralınacağı kişi, dokümantasyon ile hesap ve anahtar devri, ayrılış tarihinden önce departman yöneticisi tarafından tamamlanır. Ayrılan çalışanın erişimi bulunan anahtarlar yenilenir. Merkezi erişimlerin kapatılması mevcut işten ayrılış süreci kapsamında yürütülür.
• Kapatma: Sürdürülemeyen veya kullanılmayan uygulamalar, bağımlılıkları kontrol edilerek sahip departman tarafından kapatılır. Bu kapsamda veriler saklama ve imha kurallarına göre imha edilir, anahtar ve abonelikler iptal edilir ve proje kaydı "Kapatıldı" olarak güncellenir.

14. Geçiş Hükümleri ve Uyum

14.1 Mevcut uygulamalar için geçiş süreci

Politikanın yürürlüğe girdiği tarihte kullanımda olan uygulamalar aşağıdaki takvim çerçevesinde politikaya uyumlu hale getirilir:

• 30 gün içinde: Her departman, kullandığı veya geliştirdiği YZ destekli tüm uygulama ve otomasyonları ile kişisel hesaplarla açılmış YZ aboneliklerini proje kaydına işler.
• 60 gün içinde: Yayındaki uygulamalar için yayın öncesi hazırlık (Ek B) tamamlanır; yüksek riskli uygulamalar hedefli değerlendirmeden geçirilir.
• 60 günlük sürenin sonunda, yedi gün önceden bildirim yapılarak, kaydı veya hazırlığı tamamlanmamış uygulamaların ortak altyapı, alan adı ve Şirket verilerine erişimi kapatılır.

14.2 Uygunsuzluk halinde uygulanacak işlemler

• Kayıt dışı olarak yayına alınan veya kişisel verileri politikaya aykırı şekilde işleyen uygulamaların erişimleri Teknoloji Birimi tarafından derhal durdurulabilir; durum aynı gün içinde ilgili departman yöneticisine bildirilir.
• Kişisel YZ hesaplarına Şirket verisi veya kişisel veri girilmesi güvenlik olayı olarak değerlendirilir (Bölüm 12).
• Tekrarlayan ihlaller, Şirket'in disiplin süreçleri çerçevesinde yönetime iletilir.

Politikanın amacı yaptırım uygulamak değil, kayıt dışı uygulamaları kayıt altına almaktır. Politikaya aykırı bir uygulama tespit eden çalışanların bu durumu sahip departmana veya Teknoloji Birimi'ne bildirmesi beklenir.

15. Riskler ve Politikadaki Karşılıkları

16. Açık Kararlar

Aşağıdaki hususlar yönetim tarafından karara bağlanacaktır:

• Teknoloji Birimi'nin gözlemci modelinin ve bu görev dağılımının onaylanması
• Düşük riskli uygulamalar için bütçe sınırının (aylık tutar) belirlenmesi
• KVKK sorumlusunun ve hedefli değerlendirme katılımcılarının belirlenmesi
• Şirket içi KVKK ve veri kullanım kuralları modülü ile Türkçe eğitim özetlerinin hazırlanması
• Merkezi YZ erişimi için LiteLLM tabanlı erişim katmanı veya doğrudan AWS Bedrock seçeneklerinden birinin belirlenmesi; işletme sahibi ve bütçesi
• Ortak barındırma altyapısının (ofis sunucusu, Coolify/Easypanel) kurulup kurulmayacağı; işletme sahibi ve bütçesi
• Hazır proje şablonu, CI yapılandırması, ortak skill seti ve departman uygulamalarına sunulacak salt okunur API/view setinin hazırlanma takvimi ile bakım sorumlusunun belirlenmesi
• Kullanıcı ve departman bazında YZ kullanım limitleri ile harcama raporlama sıklığının belirlenmesi
• Onaylı teknoloji yığını dışındaki talepler için istisna sürecinin tanımlanması
• Kritik hale gelen uygulamalar için destek ve devralma modelinin belirlenmesi
• Proje kayıtlarının tutulacağı ortamın belirlenmesi (ör. Notion veritabanı)
• Politikanın yürürlük tarihi, onay makamı ve gözden geçirme sıklığının belirlenmesi (öneri: altı ayda bir)

Ek A: Proje Kaydı Şablonu

Zorunlu alanlar yaklaşık beş dakikada doldurulur. Diğer alanlar yalnızca ilgili durum söz konusu olduğunda eklenir.

Ek B: Yayın Öncesi Kontrol Listesi

Tüm uygulamalar (hazır şablon kullanılıyorsa güvenlik maddelerinin büyük bölümü otomatik olarak karşılanır):

• Proje kaydının zorunlu alanları doldurulmuştur
• Kaynak kod Şirket'in GitHub organizasyonunda; hesaplar Şirket adınadır
• Gizli anahtarlar ve .env dosyaları depoda bulunmamaktadır
• Tüm uç noktalarda kimlik doğrulama ve yetki kontrolü bulunmaktadır
• Veritabanı internete kapalıdır
• Uygulama yalnızca kendi veritabanına yazmaktadır; ana sistemlere erişim salt okunurdur
• Temel iş akışları test edilmiştir

Yüksek riskli uygulamalar için ek olarak:

• Hedefli değerlendirme tamamlanmıştır
• Test ve canlı ortamlar ayrıdır; geri dönüş planı mevcuttur
• Yedekleme ve geri yükleme denenmiştir
• Kişisel veri işleniyorsa KVKK görüşü proje kaydına eklenmiştir
• Öğrencilere açılıyorsa YZ içeriği için öğretmen kontrol süreci tanımlanmıştır
• YZ API anahtarları için harcama limiti tanımlanmıştır

Liste, departman yöneticisi tarafından proje kaydı üzerinden onaylanır.