Eski Yazılıma AI Eklemeden Önce Neler Denetlenmeli?

Kaynaklar 9 Kasım 2026 tarihindeki hâliyle aktarıldı. KVKK ile ilgili bölüm bilgilendirme amaçlıdır, hukuki danışmanlık yerine geçmez.

Eski yazılıma AI eklemeden önce neler denetlenmeli?

Yedi alan denetlenmeli: iş kuralları, veri, testler, yetki, kayıtlar ve kişisel veri, bağlantı kapısı, sahiplik. Her biri AI'ın nerede güvenle çalışacağını belirler.

Eski sistemlere yapay zeka entegrasyonu üzerine Türkçe yazılanların çoğu bağlantının nasıl kurulacağını anlatıyor: ara katman yazılımı, API ağ geçidi, adım adım yol haritası. Bir fabrika sahibinin ya da yazılım sorumlusunun önündeki soru daha dar. Bu sistemin neresine dokunursam ne bozulur ve bozulduğunu kim fark eder? Tabloyu bu soruya göre kurdum.

Baştan söyleyeyim: bu denetimi bir müşterinin kod tabanında yapıp sonucunu yayımlamış değilim. Yöntem iki yerden geliyor. 2003 ile 2008 arasında üretim firmalarının MRP sistemlerinde çalıştım. Toyota'ya kapı ve koltuk üreten bir tedarikçinin JIT MRP uygulaması ve bir bisküvi üreticisinin MRP'sinin VB'den .NET'e taşınması bu işlerden ikisi. Bugün ise kendi dört kod tabanımda, AI ajanlarının gece çalıştığı 151 sprint tamamlandı. Yazıdaki olaylar bu sistemlerden.

Eski yazılımda iş kuralları gerçekte nerede yaşıyor?

Çoğu zaman kodda, veritabanındaki saklı yordamlarda, Excel makrolarında ve sistemi yıllardır kullanan kişinin alışkanlığında. AI'a verilecek kural önce bu yerlerden çıkarılmalı.

Taşıma projelerinden kalan alışkanlığım, belgeye inanmadan önce koda bakmak. Bir yazılımın ne yaptığını üç kaynak söyler: belge, kod ve onu her gün kullanan kişi. Eski sistemlerde üçü nadiren birebir örtüşür.

AI eklerken bunun karşılığını bir örnekle anlatayım. Sipariş onayından önce müşterinin kredi limitine bakan kontrol, veritabanındaki bir saklı yordamın içinde duruyor olsun. AI katmanı siparişi doğrudan tabloya yazarsa kontrol hiç çalışmaz. Ekranda hata çıkmaz, sipariş girilmiş görünür, limit aşımını ay sonunda muhasebe bulur.

Daha sinsi durum, aynı kuralın iki kopyası. Kendi geliştirdiğim okey oyunu Kaptırık'ta kurallar önce cihazda yazıldı, çevrim içi oyun için sunucu tarafına ikinci bir kopya sonradan eklendi. 28 Ağustos ile 2 Eylül 2026 arasında bu kopya beş kez sessizce ayrıştı. O sırada 936 test yeşildi. Testler yalnız kural katmanını sınıyordu, sunucudaki kopya hiçbir testten geçmiyordu. Hatalar sahada, oyun oynanırken ortaya çıktı.

Eski sisteme AI eklerken aynı tuzak şöyle kurulur: kural ERP'de durur, AI katmanı da hız kazanmak için kuralın kendi sürümünü yazar. İki kopya bir süre aynı sonucu verir, sonra biri güncellenir. Denetimde her kural için tek bir kaynak işaretlenir. AI o kaynağı çağırır, kuralı kendi içine kopyalamaz.

Verinin AI için hazır olup olmadığı nasıl anlaşılır?

Gerçek kayıtlardan örnek çekilip sayılır: boş alan oranı, aynı varlığın mükerrer kartları, serbest metin alanları ve kod listelerinin tutarlılığı. Tahminle karar verilmez.

Gartner'ın Şubat 2025'te yayımladığı açıklamaya göre AI'a hazır veriyle desteklenmeyen AI projelerinin yüzde 60'ı 2026 sonuna kadar bırakılacak. Aynı açıklamadaki ankette kuruluşların yüzde 63'ü, AI için doğru veri yönetimi uygulamalarına sahip olmadığını ya da bundan emin olmadığını söylüyor.

Eski sistemde veri sorunu yıllar içinde birikir. Aynı müşteri iki ayrı kodla açılır. Açıklama alanı, kimsenin adını koymadığı ikinci bir veritabanına dönüşür. Stok kartında birim bir yerde kilo, başka yerde koli olur. Dil modeli bu karmaşayı düzeltmez. Boşluğu akıcı bir tahminle doldurur ve tahmin doğru veri gibi görünür.

Örneklemi son on iki aydan ve gerçek kayıtlardan alırım. Demo için hazırlanmış temiz veriyle yapılan ölçüm, sahadaki ilk haftayı temsil etmez. Bu farkı pilot yazısında ayrıca anlattım.

Testi olmayan koda AI eklemek neden riskli?

Testsiz kodda AI'ın bozduğu davranışı yakalayacak bir şey yok. Önce sistemin bugünkü davranışını sabitleyen testler yazılır, değişiklik ondan sonra gelir.

Michael Feathers, 2004'te yayımlanan Working Effectively with Legacy Code kitabında eski kodu basitçe testi olmayan kod diye tanımlıyor. AI kodlama araçlarıyla bu tanım daha da önem kazandı. Bir ajan dakikalar içinde yüzlerce satırı değiştirebiliyor. Testsiz sistemde bunun neyi bozduğunu size ancak kullanıcı söyler.

Testin varlığı da yetmiyor. 15 Ekim 2026'da Kaptırık'ın sunucu testleri için "223/223 geçti" dedim. Testler bir önceki derlemenin çıktısına karşı koşuyordu. Bedava çip miktarını 500'den 1.000'e çıkaran değişikliği üç testin yakalaması gerekiyordu, yakalamadı. Canlıdaki davranış doğruydu, bayat olan testlerdi. "Doğrulandı" demem yine de yanlıştı.

Denetimde testlere dört soru sorarım: koşuyorlar mı, neye karşı koşuyorlar, hangi davranışı sabitliyorlar ve en son ne zaman bir hatayı yakaladılar? Test yoksa ilk iş, sistemin bugün ne yaptığını kayda geçiren testleri yazmak. Feathers bunlara karakterizasyon testi diyor. Bu test davranışın doğru olup olmadığını sormaz, bugünkü hâlini sabitler. AI'ın yaptığı değişiklik bu hâli bozarsa test kırmızıya döner ve kararı insan verir.

AI ajanına eski sistemde hangi yetki verilmeli?

İşe salt-okur yetkiyle başlanır. Sisteme yazma, insan onayından geçen bir kuyrukla açılır. Silme, ödeme ve toplu güncelleme başlangıçta ajana hiç verilmez.

OWASP'ın dil modeli uygulamaları için hazırladığı 2025 risk listesi bu sorunu Excessive Agency, yani aşırı yetki başlığıyla ele alıyor. Liste üç kaynak sayıyor: gereğinden fazla işlev, gereğinden fazla izin ve insan onayı olmadan yürüyen gereğinden fazla özerklik. Eski sistemde en kolay kestirme, ajana mevcut bir yönetici hesabını vermek. Üç riski birden açan da bu kestirme.

Kendi sistemimde ajanlar ana dala kod gönderemiyor, canlıya çıkaramıyor, veritabanı şemasını değiştiremiyor. Bu kuralları ajanın talimat dosyasına yazmakla yetinmedim. Komut çalışmadan önce onu durduran, dil modeli kullanmayan bir kapı var. Talimatı model unutabilir, kapıyı atlayamaz.

Kayıtlarda ve kişisel veride neye bakılmalı?

Modele hangi alanın gideceği, log dosyalarına ne yazıldığı ve verinin yurt dışına çıkıp çıkmadığı kurulumdan önce listelenmeli. Kimlik ve IBAN gibi alanlar maskelenir.

Eski sistemlerin log dosyaları genelde hata ayıklamak için yazılmıştır ve kimsenin açmadığı bir klasörde birikir. Bir istek kaydı müşterinin adını, telefonunu ve adresini düz metin taşıyabilir. AI katmanı bu kayıtları bağlam diye okursa kişisel veri fark edilmeden modele gider.

KVKK'nın 12. maddesi veri sorumlusunu güvenlik tedbirlerinden sorumlu tutuyor. Veri sizin adınıza başka biri tarafından işleniyorsa, tedbirlerden o kişiyle birlikte sorumlusunuz. Model yurt dışında çalışıyorsa 9. maddenin aktarım şartları devreye giriyor. Somut kurulumunuz için bu soruyu hukukçunuza kurulumdan önce sorun.

Kodun kendisi de veri taşır. Eski kod tabanlarında veritabanı şifresinin bir yapılandırma dosyasına ya da doğrudan koda yazılmış olması sık görülür. Denetimde bir sır bulursam raporda yerini ve türünü yazarım, değerini asla yazmam ve aynı gün haber veririm. Kodu bir sohbet aracına yapıştırmadan önce siz de aynı taramayı yapın.

API'si olmayan eski sisteme AI nasıl bağlanır?

Okuma için veritabanına salt-okur görünüm yeterli. Yazma için önce mevcut servis, sonra içe aktarım dosyası denenir. Ekran otomasyonu son çaredir.

2008 ile 2015 arasında .NET ile WCF ve SOAP servisleri yazdım. Bu tür servisler belgesi kaybolsa da yıllarca çalışmaya devam eder ve çoğu zaman kuralı uygulayan katman onlardır. Doğrudan tabloya yazan bir AI katmanı bu katmanı atlar. Yukarıdaki kredi limiti örneğinde olan da buydu.

Kaynak kodu kaybolmuş programlar da var. Bu durumda AI, programın yazdığı veriyi okuyabilir ve içe aktarım dosyası hazırlayabilir. Programın davranışını değiştirmek ise kod olmadan risklidir. API vermeyen muhasebe programları için aynı sırayı muhasebe ofisi yazısında anlattım.

Eski kod tabanında AI kodlama aracı kullanılacaksa ne hazırlanmalı?

Ajanın okuyacağı bir ürün dosyası, koddan çıkarılmış bir mimari dosyası ve testlerin gevşetilmesini yakalayan bir kontrol. Bunlar olmadan her geliştiricinin ajanı başka yöne kodlar.

Stack Overflow'un 2025 geliştirici anketinde katılımcıların yüzde 84'ü AI araçlarını kullanıyor ya da kullanmayı planlıyor. Çıktının doğruluğuna güvenmeyenler yüzde 46, güvenenler yüzde 33. Eski kod tabanında bu güvensizlik daha yerinde, çünkü ajan kodun neden öyle yazıldığını bilmiyor.

Kendi kod tabanlarımdaki her sprint, ajanın okuduğu iki dosyayla başlıyor. PRODUCT.md ürünün ne olduğunu ve neyin bilerek kapsam dışında bırakıldığını anlatıyor. ARCHITECTURE.md yığını, veri modelini, dış bağlantıları ve bilinen tuzakları. 25 Eylül 2026'da bu dosyaları kendi dört repomda koddan geriye doğru çıkardım. Her dosyanın başında aynı kural yazıyor: bu dosya niyeti bağlar, kodla çelişirse kod kazanır.

Ajanların bir alışkanlığını da ayrıca izliyorum: kırmızı testi yeşile çevirmenin en ucuz yolunu seçmek. Testi kolaylaştırır, uyarıyı susturur ya da eşiği düşürür. Sprint motorundaki test bekçisi bu hareketleri sayıyor. 26 Ekim'deki kalibrasyonda 102 sprintte bir kez tetiklendi. Testleri zaten zayıf olan eski bir kod tabanında bu bekçi olmadan zayıf test daha da zayıflar.

Sistemi kim biliyor, sahiplik neden denetimin parçası?

Eski sistemlerde bilgi çoğu zaman bir iki kişide toplanır. Denetim o kişiyi sürece katar, AI katmanının sahibini ve hata çıktığında kimin bakacağını yazar.

Eski sistemi bilen kişi çoğu zaman şirketin en yoğun çalışanıdır ve denetim onun zamanını ister. Bu yüzden ilk gün iki ayrı görüşme yaparım. Biri sistemi teknik olarak tanıyan kişiyle: neyin kırılgan olduğunu, hangi raporun elle düzeltildiğini o bilir. Diğeri sonucun hesabını soran yöneticiyle: hangi işin zaman ya da para kaybettirdiğini o bilir. Biri eksik kalırsa rapor da eksik kalır.

AI katmanının da bir sahibi olmalı. Kendi otomasyonlarımda her 30 dakikada bir zamanlanmış işlerin sağlığına bakan ayrı bir iş var. Hata ya da gecikme olursa telefonuma bildirim düşüyor. Sahibi olmayan AI katmanı durduğunda bunu kimse fark etmez, eski sistem de işini AI yokmuş gibi yapmaya devam eder. Pilot sonrası sahiplik sorusunu pilot yazısının beşinci sebebinde ayrıntılı ele aldım.

Eski yazılım AI denetimi ne kadar sürer, sonunda ne çıkar?

Tek kod tabanı için beş iş günü planlıyorum, birden çok sistemde iki haftaya çıkar. Sonunda kod tabanı haritası, risk listesi ve pilot sınırı elinizde olur.

Kod sizin ortamınızda kalır, bir yere kopyalanmaz. Önerdiğim her değişiklik ayrı bir dalda durur, ana dala alma kararı sizindir. Kabul ölçüsü de baştan yazılır: teknik sorumlu ürün ve mimari dosyalarını onaylamış olmalı, ekipten biri dördüncü günün değişikliğini aynı dosyalardan yeniden üretebilmeli. "Beğendik" kabul ölçüsü sayılmaz.

Ücretin nasıl belirlendiğini AI danışmanlık fiyatları yazısında, pilotta başarının nasıl ölçüldüğünü eval ve golden set yazısında anlattım.

Sık sorulan sorular

Eski yazılıma AI eklerken en çok zaman, sistemin bugün ne yaptığını anlamaya gidiyor. Kuralın yeri, verinin hâli, testlerin neye karşı koştuğu ve ajana verilecek yetki yazılıysa ilk pilotu küçük ve geri alınabilir tutmak kolaylaşır. Diğer yazılara blog sayfasından, çalışma biçimimize hizmetler sayfasından ulaşabilirsiniz.