GitHub Copilot Model Yönetiminde Yeni Dönem: Kuralları İnce Ayarla
Açık konuşayım, GitHub tarafında bazen öyle küçük görünen değişiklikler geliyor ki, ilk bakışta “tamam, güzel bir dokunuş” deyip geçiyorsunuz. Ama biraz eşeleyince anlaşılıyor; mesele küçük değil, doğrudan yönetişim, güvenlik. Ekip ölçeğiyle ilgili (ki bu çoğu kişinin gözünden kaçıyor). Bu hafta duyurulan targeted model rules tam da o klasmanda. Enterprise owner’lar artık tek bir enterprise-geneli ayarla yetinmiyor; hangi organizasyonda hangi Copilot modelinin görüneceğini daha ince ayarla yönetebiliyor.
Açık konuşayım, bu haber bana ilk anda “nihayet” dedirtti. Çünkü büyük yapılarda sorun çoğu zaman modelin var olup olmaması değil, kimin neyi ne zaman kullanacağı. Bir finans kuruluşunda 2024 Eylül’ünde yaptığımız Copilot yaygınlaştırma çalışmasında bunu birebir yaşadık; güvenlik ekibi bir modeli istiyordu, yazılım ekibi başka bir modeli denemek istiyordu, uyum ekibi işe üçüncü bir seçenek için kapıyı aralık bırakıyordu. Tek merkezden aç-kapa yapmak kağıt üstünde temiz dürüyor ama pratikte biraz hantal kalıyor… işte bu yüzden bu yeni yaklaşım fena değil, hatta baya işe yarıyor.
Neden Bu Değişiklik Önemli?
İtiraf edeyim, Enterprise seviyede çalışan herkes bilir: standartlar güzel şeydir,. Her organizasyon aynı ihtiyaçla gelmez. Bazı takımlar deneyseldir, bazıları regülasyon yüzünden kıpırdayamaz. GitHub’ın yeni model kuralları tam burada devreye giriyor. Sız ne dersiniz? Artık enterprise içinde bazı organizasyonlara belirli Copilot modellerini açıp diğerlerine kapalı tutabiliyorsunuz.
Bu bence sadece “yeni özellik” değil; yönetişim tarafında ciddi bir olgunlaşma adımı. En çok da Copilot Business ve Copilot Enterprise kullanan müşterilerde sık gördüğüm şey şu: merkezî kontrol isteniyor ama aşırı merkeziyet de işi kilitliyor. Hani klasik hikâye vardır ya — herkes aynı arabaya binmek ister ama koltuğu kimse kendine göre ayarlayamaz. Sız ne dersiniz? İşte biraz öyle.
Şimdi gelelim işin can alıcı noktasına.
Benzer bir tabloyu 2025 Şubat’ında Logosoft tarafında yürüttüğümüz hibrit bulut danışmanlığında da gördük. Müşterinin üç farklı organizasyonu vardı; biri Ar-Ge gibi çalışıyor, biri operasyon ağırlıklı gidiyor, biri de dış denetime çok açık durumda (ben de ilk duyduğumda şaşırmıştım). Aynı politika hepsine uymadı. Bir yerde Optional mantığı doğruydu, başka yerde Enabled ile standardizasyon gerekiyordu. Bu ne anlama geliyor? Bu tip detaylar büyüdükçe önem kazanıyor.
Bir de şu var: model erişimini sadece “var/yok” şeklinde düşünürseniz yanlış yere saparsınız. Asıl değer, hangi modelin hangi iş yükü için uygun olduğuna karar verebilmekte yatıyor. Kimi takım hızlı prototip ister, kimi takım daha kontrollü ve tahmin edilebilir davranış ister (inanın bana). yanı mesele biraz da organizasyon psikolojisi.
Targeted Model Rules Ne Sağlıyor?
Ne yalan söyleyeyim, Yeni yapı sayesinde enterprise owner olarak belirli organizasyonlara özel kurallar tanımlayabiliyorsunuz. Mesela A organizasyonu için Model X açık olabilirken B organizasyonu için hiç görünmeyebilir ya da sadece opsiyonel bırakılabilir. Böylece büyük çoğunluk şirkete tek şablon dayatmak yerine daha gerçekçi bir dağıtım yapıyorsunuz.
Enabled ve Optional ayrımı burada önemli. Enabled dediğinizde model otomatik olarak tüm organizasyonlarda aktif oluyor; Optional dediğinizde işe karar organizasyonun kendi yönetimine bırakılıyor. Küçük ekiplerde bu fark çok hayatı olmayabilir ama enterprise’da fark geceyle gündüz kadar hissediliyor.
Kendi deneyimimde en çok sıkıntı çıkaran nokta şu öldü: merkezî ekip “herkes aynı modeli kullansın” diyor, yerel ekipler işe “bizim kullanım senaryomuz farklı” diye itiraz ediyor. Geçen yıl Kasım ayında İstanbul’daki bir üretim firmasının BT ekibinde buna benzer bir durum yaşadık; test ortamlarında denenmesi gereken modeller ile canlı geliştirme akışındaki modelleri ayırmak zorunda kaldık çünkü aksi hâlde destek talepleri çorap söküğü gibi geliyordu (evet, doğru duydunuz)
Küçük ekip mi, büyük kurum mu?
Küçük startup tarafında bakınca iş daha basit: birkaç kişi aynı modeli dener, karar hızlı alınır ve merkezî politika ihtiyacı azdır. Orada fazla kural bazen gereksiz yük olur.
Büyük kurumsal yapıda işe durum tersine dönüyor (ben de ilk duyduğumda şaşırmıştım). On ayrı ekipten on ayrı talep geliyor ve hepsini tek default ile yönetmeye çalışırsanız kısa sürede sürtünme başlıyor.
Bence ideal yaklaşım şu: küçük ekiplerde sade tutun, enterprise’da katmanlı gidin (merkezde ana politika + org bazlı istisnalar). Bakın şimdi… tam burada GitHub’ın yaptığı şey mantıklı hâle geliyor (buna dikkat edin)
| Senaryo | Daha Mantıklı Seçim | Neden? |
|---|---|---|
| Küçük startup | Tüm modellere sınırlı erişim | Yönetim yükü düşük olsun diye |
| Büyük enterprise | Targated rules + Optional/Enabled karışımı | Ekip bazlı esneklik gerektiği için |
| Düzenlemeye tabi sektör | Sınırlı allow-list yaklaşımı | Uyum ve denetim kolaylığı sağlamak için |
Bence Asıl Kazanç Güvenlik Değil Sadece Kontrol Değil
E tabi güvenlik kısmı hemen göze çarpıyor ama ben asıl kazancı operasyonel netlikte görüyorum.. Hangi takım hangi modeli kullanıyor sorusuna cevap vermek bile bazen saatler alabiliyor! Mesela denetim zamanı geldiğinde raporlama işleri iyice can sıkıcı oluyor (şaşırtıcı ama gerçek) Daha fazla bilgi için
Nereden başlamalı?
Lafı gevelemeden söyleyeyim: önce en kritik iki ya da üç organization seçin.
Onların ihtiyaçlarını çıkarın.
Sonra hangi modelin neden gerekli olduğunu yazın.
Bu kadar basit görünüyor ama çoğu proje burada dağılıyor çünkü herkes direkt teknolojiye atlıyor, süreç kısmını atlıyor.. sonra sürpriz!
Peki neden?
{
"defaultModels": {
"model-a": "Enabled",
"model-b": "Optional"
},
"targetedRules": [
{
"organization": "finance-org",
"allowedModels": ["model-a"]
},
{
"organization": "r-and-d-org",
"allowedModels": ["model-a", "model-b"]
}
]
}
Bazı İç Linkler ve Benzer Okumalar
Eğer GitHub tarafındaki kontrol mekanizmaları ilginizi çekiyorsa şu yazıya da bakabilirsiniz:
GitHub Code Quality API: Repo Bazlı Açma-Kapama Dönemi.
Orada da benzer şekilde merkezî yönetimin repo düzeyine inmesini konuşmuştuk; tema aynı aslında: ince ayar kazanıyor.”
“?>
Copilot tarafını.NET odaklı değerlendirmek isterseniz şu yazı faydalı olur:
GitHub Copilot’ta.NET İşini Doğru Yerden Tutmak.
Bilhassa geliştirici deneyimi ile yönetişim arasındaki dengeyi güzel anlatıyor.
Model yönetişimi geniş resimde MCP. Ajan güvenliğiyle de kesişiyor.
Bu yüzden ilgili düşünecek başka okuma isterseniz:
Agent Governance Toolkit ile MCP Güvenliği:.NET’te Yeni Katman.
Aynı problemin biraz daha ajan katmanına inmiş hali gibi düşünebilirsiniz.
Sıkça Sorulan Sorular
Targeted model rules nedir?
Size bir şey söyleyeyim, Aslında — hayır dur, daha doğrusu şöyle düşünün: belli GitHub Copilot modellerini tüm enterprise’a açmak yerine, sadece seçtiğiniz organization’lara özel açmanızı sağlayan bir kural seti. Yanı ince ayar yapmak isteyen büyük kurumlar için biçilmiş kaftan.
Bunu kimler kullanabiliyor?
Copilot Business veya Copilot Enterprise planı olan müşteriler kullanabiliyor. Bireysel kullanım için değil, açıkçası odak tamamen kurumsal yönetim tarafında.
Enabled ile Optional arasındaki fark ne?
Enabled seçerseniz model otomatik olarak aktif oluyor. Optional seçerseniz kararı organization’a bırakıyorsunuz. Bence bunu şöyle özetleyebiliriz: biri zorunlu yaygınlaştırma, diğeri kontrollü serbestlik.
Küçük şirketlerde buna gerek var mı?
Genelde hayır, tecrübeme göre basit default ayar çoğu zaman yeterli oluyor. Ama birkaç takım arasında birbirinden farklı ihtiyaçlar varsa, o zaman yine işe yarıyor tabiî.
Bunun en büyük artısı ne?
Bence en güçlü yanı esneklik ile yönetişimi aynı yerde toplaması. Hani tek panelden herkese aynı şeyi dayatmak yerine, organization bazında ayrı ayrı karar verebiliyorsunuz. Bu ciddi bir fark yaratıyor.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
2 comments