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. copilot ile ilgili önceki yazımız yazımızda bu konuya da değinmiştik.
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 Claude Opus 4.8 GitHub Copilot’a Geldi: Peki Gerçekte Ne Değişiyor? yazımıza bakabilirsiniz.
Bi saniye — Ayrıca default model availability ekranının yenilenmesi de boş bir kozmetik dokunuş değil bence; çünkü yönetici ekranı karmaşıksa insanlar hatayı orada yapar.
Bir sistemi iyi yapan şey sadece arkadaki API değil… ön yüzdeki akışın da sade olması lazım.
Geçen mart ayında Ankara’daki bir kamu iştirakinde bunun tersini yaşadık: arayüz güçlüydü ama kullanım yolu dolaşıktı, sonuçta birkaç yanlış atama yapıldı. Geri almakla uğraştık.
İnsan faktörü işte!
Bunu biraz açayım.
Merkezî kontrol ile yerel esnekliği dengede tutamıyorsanız büyüdükçe sorun çözmüyor; sadece ertelenmiş problem üretiyor.
Maliyet tarafını nasıl okumalı?
Maliyet burada doğrudan fiyat etiketi olarak görünmeyebilir ama dolaylı maliyet bayağı gerçek olur:
yanlış modele erişen ekiplerin oluşturduğu destek yükü,
gözden kaçan kullanım senaryoları,
ve gereksiz pilot çalışmalar…
Hepsi zaman demek.
Zaman da para demek!
TL bazında düşündüğünüzde küçük hatalar bile büyüyebiliyor çünkü döviz dalgalanmasıyla birlikte lisans planlama işi hassaslaşıyor.
Kurumsal müşterilerimde şunu defalarca gördüm:
“Bütün modellere açalım” yaklaşımı ilk hafta rahatlatıyor,
ikinci ayda işe hem governance hem destek hem de eğitim maliyetleri çıkmaya başlıyor.
Yanı ucuz gibi duran şey bazen pahalıya patlıyor…Dikkat Edilmesi Gereken Noktalar
- Kural setinizi önce küçük bir pilot org üzerinde deneyin. — bunu es geçmeyin
- Error loglarını takip edin; yanlış atamalar ilk orada görünür.
- Erişim matrisini yazılı hâle getirin ki unutulmasın.
- Ekiplerden gelen geri bildirimi toplayıp haftalık gözden geçirin. — ciddi fark yaratıyor
Bir hata örneği de paylaşayım: Bu servisi ilk test ettiğimde yanlışlıkla policy scope’u üst seviyede bıraktığım için beklemediğim birkaç org’a model görünür öldü.
Sorunu fark etmemiz uzun sürmedi ama düzeltirken öğrendiğim şey netti:
scope mantığını ciddiye almazsanız konfigürasyon sizi ters köşeye yatırır.
Çözüm oldukça basitti — önce mevcut default’ları temizledik sonra targeted rule’ları tek tek uyguladık.. Tahmin eder mısınız? fakat o ilk şaşkınlık hafife alınacak türden değildi. SharePoint Framework 1.23 ve Ötesi: Asıl Mesaj Ne? yazımızda bu konuya da değinmiştik.
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
2 comments