Yapay Zekanın Yazdığı SQL Üretime Nasıl Gider?

Bir geliştirici, üretim şemasını bir yardımcıya anlatıyor ve "geçen ayki hatalı kayıtları düzelt" diyor. Dönen SQL makul görünüyor. Kimse o metnin nereden geldiğini sormuyor, çünkü kod incelemesi metne bakar, yazarına değil. Bu yazı, yapay zekanın ürettiği SQL'in üretime giden yolunda hangi kontrolün eksik kaldığını ele alıyor.

Karar Verilmedi, Olan Oldu

Kurumların çoğu bu konuda henüz bir politika oluşturmadı, ancak durum politikayı beklemedi. 2026 tarihli bir sektör araştırması, kurumların neredeyse tamamının üretim veritabanlarıyla en az bir yapay zeka etkileşimi bildirdiğini ortaya koyuyor: analiz ve raporlama, eğitim boru hatları, iç yardımcılar ve doğrudan üretilen SQL. Buna karşılık dağıtım öncesi güvenlik ve uyum kontrollerini tutarlı biçimde otomatikleştirenlerin oranı üçte birin biraz üzerinde kalıyor.

Aradaki bu boşluk yeni bir teknoloji tartışması değil, tanıdık bir yönetişim boşluğudur: üretim veritabanına ulaşan yeni bir yol açıldı ve o yol için hiçbir kapı tanımlanmadı. Aynı araştırmada katılımcıların yaklaşık yarısı yönetişimsiz üretilen SQL'i endişe kaynağı olarak işaretliyor. Yani sorunun farkında olan çok, kontrolü kurmuş olan az.

Geliştiriciden Farkı: Tereddüt Etmemesi

"SQL sonuçta SQL'dir, kim yazdığının önemi yok" itirazı ilk bakışta mantıklıdır ve kısmen doğrudur. Metin bir kez üretildikten sonra risk değerlendirmesi açısından kaynağın önemi yoktur. Fark, metnin nasıl üretildiğindedir.

Koşulsuz bir silme ifadesi yazan bir geliştirici, o satırı yazarken duraksar. Ne olacağını bilir, sonucundan sorumlu olacağını bilir ve genellikle bir kez daha kontrol eder. Etmese bile, inceleme aşamasında bir meslektaşı fark eder.

Aynı ifadeyi üreten bir yardımcı için bunların hiçbiri geçerli değildir. Sonucun ne olacağına dair bir farkındalığı, sonuçta bir payı ve dolayısıyla bir tereddüdü yoktur. Aldığı komuta ve bağlama göre makul görünen SQL üretir; üretim veritabanının neye dayanabileceğine göre değil.

Bu ayrım önemlidir, çünkü kurumların mevcut kontrollerinin çoğu insan davranışına güvenir. "Kimse bunu yapmaz" varsayımı, üzerinde düşünülmeden kurulmuş sessiz bir kontroldür ve o varsayımın geçerli olmadığı bir üretici devreye girdiğinde sessizce ortadan kalkar.

Üç Tipik Hata Biçimi

1. Var olmayan nesne ve kolon adları. Model, şemada bulunmayan bir kolon adı üretebilir. Bu hata en zararsız olanıdır çünkü çalıştırıldığında hata verir ve fark edilir. Tehlikeli hali, adı doğru ama anlamı farklı bir kolonun seçilmesidir: iki tabloda da bir durum kolonu vardır ve model yanlış olanı kullanır. İfade sorunsuz çalışır ve yanlış satırları günceller.

2. Kapsamı fazla geniş ifadeler. "Geçen ayki hatalı kayıtları düzelt" komutu, "geçen ay" ve "hatalı" tanımlarını modele bırakır. Model makul bir yorum yapar ve o yorum çoğu zaman gereğinden geniştir. Sonuç, doğru görünen ama beklenenden çok daha fazla satıra dokunan bir ifadedir.

3. Bağlamın taşınmaması. Model, kurumun kritik nesne listesini, bakım penceresini, o tablonun neden özel olduğunu ve yıllar önce alınmış bir kararı bilmez. Bu bilgiler hiçbir şema tanımında yazmaz. Teknik olarak kusursuz bir ifade, kurumun kendi kurallarına aykırı olabilir.

Doğal Dil Korkulukları Neden Yetmez

Yaygın çözüm, modele talimat vermektir: "yalnızca okuma sorgusu üret", "asla silme ifadesi yazma". Bu yaklaşım bir güvenlik kontrolü değil, bir ricadır.

Sistem komutuyla konulan bu tür sınırlar iki yolla aşılabilir. Birincisi, dikkatlice hazırlanmış bir girdi talimatı geçersiz kılabilir. İkincisi ve daha sinsisi, modelin kendi yapısal hatası sınırı fark etmeden delebilir: yalnız okuma yapması söylenen bir model, veri değiştiren bir ifade üretebilir çünkü ürettiği metnin ne anlama geldiğini değerlendirmez, yalnızca olası devamı tahmin eder.

Güvenlik açısından geçerli olan kural şudur: sınır, sınırı aşacak tarafın kendisine sorularak uygulanmaz. Kontrol, metni üreten yerde değil, metnin veritabanına ulaştığı yerde durmalıdır. Bu, yeni bir ilke değildir; girdi doğrulamasının neden istemci tarafında bırakılamayacağıyla aynı ilkedir.

Ölçek Sorunu: Elle İnceleme Yetişmez

Bu konudaki en yaygın plan şudur: "yapay zekanın ürettiği her SQL'i bir veritabanı yöneticisi incelesin." Plan doğru niyetlidir ve uygulanamaz.

Sebep basittir: üretim hızı değişti, inceleme kapasitesi değişmedi. Bir geliştiricinin günde yazdığı betik sayısı ile bir yardımcının aynı sürede üretebileceği betik sayısı arasında büyüklük farkı vardır. Elle inceleme bu hacme ve hıza yetişemez. Yetişmeye zorlandığında da bilinen sonucu üretir: inceleme biçimsel bir onaya dönüşür ve gerçek kontrol ortadan kalkar.

Bu, insan incelemesinin gereksiz olduğu anlamına gelmez. Anlamı şudur: insan incelemesi ilk filtre olamaz. İlk filtrenin makine olması, insanın da makinenin işaretlediği azınlığa bakması gerekir. Bu, yapay zeka için icat edilmiş bir model değildir; risk bandına göre onay derinliği belirlemek zaten bilinen bir yaklaşımdır ve burada da aynen çalışır.

Çalışan Model: Kaynağa Değil Metne Bakmak

Doğru kurgunun temel ilkesi şudur: kural, metni kimin ürettiğine bakmaksızın aynı biçimde uygulanır. Bir insan da bir yardımcı da aynı kapıdan geçer ve aynı ölçüte tabi olur. Bu ilke, yapay zeka için ayrı bir yönetişim rejimi kurma ihtiyacını ortadan kaldırır.

Metin ayrıştırılır, aranmaz. Anahtar kelime araması yanıltır: bir ifadenin koşulsuz olup olmadığı, hangi nesneye dokunduğu ve hangi türde olduğu ancak dilin kendi yapısına göre çözümlendiğinde güvenilir biçimde anlaşılır. Metin ayrıştırıldığında, ifadenin kim tarafından yazıldığının hiçbir önemi kalmaz.

Risk içerikten çıkar. Koşulsuz güncelleme, kritik nesne listesindeki bir tabloya dokunma, geri alınamaz bir işlem: bunlar yazılı kurallardır ve aynı betik her zaman aynı bandı alır. Değerlendirmenin insan yargısından çıkarılması, hacim arttıkça değerin de arttığı tek özelliktir.

Onay çalıştırma kapısına bağlanır. Onay bir alan değil bir koşuldur; onay tamamlanmadan çalıştırma açılmaz. Bir yardımcının ürettiği metin, ne kadar makul görünürse görünsün, bu kapıyı kendi başına geçemez.

Kaynak kaydedilir. Kaynak riski belirlemez ama kaydedilmelidir. Altı ay sonra "bu betiği kim yazdı" sorusunun cevabı "bir yardımcı üretti, şu kişi gönderdi, şu kişi onayladı" olabilmelidir. Bu bilgi, bir sorun çıktığında değil, deseni anlamak istediğinizde işe yarar.

SQL Change Guard bu modeli kaynak ayrımı yapmadan uygular: her betik ayrıştırılır, risk bandı içerikten üretilir, onay tamamlanmadan çalıştırma açılmaz ve geri alma betiği sunucudaki güncel tanımdan hazırlanır. Yapay zeka için ayrı bir rejim tanımlamaya gerek kalmaz, çünkü kapı zaten metnin kendisine bakmaktadır.

Sık Sorulan Sorular

Yapay zeka araçlarını yasaklamak daha basit değil mi?

Basit görünür ama uygulanabilir değildir ve genellikle sonucu tersine çevirir. Yasak, kullanımı ortadan kaldırmaz; görünmez hale getirir. Geliştirici yardımcıyı yine kullanır, ürettiği metni kendi yazmış gibi gönderir ve kurum artık kaynağı hiç bilemez. Ölçülemeyen bir kullanım, yönetilemeyen bir kullanımdır. Daha iyi sonuç veren yaklaşım, kullanımı kabul edip metnin geçtiği kapıyı sağlamlaştırmaktır.

Modele şemayı vermek güvenlik riski mi?

İki ayrı soru vardır ve karıştırılmamalıdır. Şema bilgisi, yani tablo ve kolon adları, dış bir hizmete gönderildiğinde kurumun iç yapısı hakkında bilgi sızar; bu, veri sızıntısından farklı ama gerçek bir risktir ve kurum içinde çalışan modellerle azaltılabilir. Asıl büyük risk ise şemayı vermek değil, gerçek veriyi girdi olarak vermektir: bir hatayı anlatmak için üretim satırlarını yapıştırmak, o veriyi kurum dışına çıkarır ve bu bir veri aktarımıdır. İkisi ayrı ayrı değerlendirilmelidir.

Yardımcıya yalnızca okuma yetkisi versek yeterli olmaz mı?

Bu, doğru yönde atılmış en etkili adımdır ve doğal dil talimatından çok daha güçlüdür, çünkü sınırı bağlantının kendisi kurar. Ancak iki noktaya dikkat etmek gerekir. Birincisi, salt okuma yetkisi veri değişikliğini engeller ama veri görmeyi engellemez; hassas kolonlar hala okunabilir durumdadır ve bu KVKK açısından ayrı bir konudur. İkincisi, kötü yazılmış bir okuma sorgusu da üretimi yavaşlatabilir. Salt okuma, değişiklik riskini kapatır; erişim ve performans risklerini kapatmaz.

Yapay zeka ürettiyse betiği ayrı bir sürece mi sokmalıyız?

Hayır, ayrı bir süreç kurmak iki nedenle zayıflatır. Birincisi, ayrım kaynağın doğru beyan edilmesine bağlıdır ve beyan edilmediğinde tüm ayrım çöker. İkincisi, kaynağa göre kural uygulamak riskin yanlış yerde ölçüldüğü anlamına gelir: koşulsuz bir silme ifadesi, kim yazarsa yazsın aynı derecede tehlikelidir. Doğru kurgu tek süreç ve içerik tabanlı değerlendirmedir; kaynak yalnızca kayıt için tutulur.

Bugün atılacak ilk adım ne olmalı?

Envanterle başlayın: hangi ekipler, hangi araçlarla, hangi ortamlara bağlanıyor? Bu listeyi çıkarmak birkaç gün sürer ve genellikle beklenenden uzun olur. Ardından tek bir kural koyun: üretim veritabanına ulaşan hiçbir SQL, kaynağı ne olursa olsun, ayrıştırılıp değerlendirilmeden ve onaydan geçmeden çalışmasın. Bu iki adım, yapay zekaya özgü bir politika yazmadan riskin büyük kısmını kapatır.