Ajan Tabanlı Yapay Zekâ Veritabanı Geliştirmeyle Buluşuyor: Yapay Zekâ Sorguları Gerçekten Çalıştırabildiğinde Neler Değişiyor?

Son birkaç yıldır yapay zekâ destekli veritabanı geliştirme oldukça rahat bir işleyişe dayanıyordu. Geliştirici bir gereksinimi açıklıyor, yapay zekâ SQL kodu üretiyor, geliştirici kodu okuyup yanlış görünen yerleri düzeltiyor ve çalıştırıp çalıştırmayacağına karar veriyordu.

Bu iş akışı önemli bir sınırı koruyordu: Yapay zekâ bir eylem önerebilir, ancak bu eylemin veritabanına uygulanıp uygulanmayacağına hâlâ bir insan karar verir.

Ancak ajan tabanlı yapay zekâyla birlikte bu sınır ortadan kalkmaya başlıyor. Günümüzde yapay zekâ sistemleri şemaları inceleyebiliyor, sorguları çalıştırabiliyor, sonuçları yorumlayabiliyor ve ardından hangi adımın atılacağına karar verebiliyor. Yakın tarihli bir ankete göre, kuruluşların %62’si yapay zekâ ajanlarını denemeye başlamış durumda; %23’ü ise kurum içinde bir yerde ajan tabanlı bir sistemi ölçeklendirdiğini bildirdi.

Dolayısıyla veritabanı ekiplerinin yanıtlaması gereken, oldukça acil bir mimari soru var. Soru, yapay zekânın SQL çalıştırıp çalıştıramayacağı değil. Çalıştırabiliyor. Asıl soru, bir asistan kod önermeyi bırakıp veritabanında işlem yapmaya başladığında nelerin değiştiği ve bu özerkliğin ne ölçüde sıkı denetlenmesi gerektiği.

Önerilerden Eyleme

Basit bir indeksleme kararı, bu değişimin neden önemli olduğunu gösteriyor.

Bir ajan yavaş bir sorgu görür, şemaya bakar, indeksin işe yarayabileceğini anlar, indeksi oluşturur, iş yükünü yeniden çalıştırır ve sonucu kontrol eder.

Şu kadar sıradan bir komut çalıştırabilir:

CREATE INDEX IX_Orders_CustomerId
ON Orders(CustomerId);

Bu ifadede olağan dışı bir şey yok. Bir yapay zekâ asistanı da birebir aynı şeyi önerebilirdi. Fark, son kararı kimin verdiğidir.

Bir asistan kullanıldığında geliştirici öneriyi inceler, test eder ve çalıştırıp çalıştırmayacağına karar verir. Yapay zekâ tavsiyede bulunur, eyleme geçen ise insandır. Çalıştırma yetkisi olan bir ajanla sistem bu kararı kendi başına verebilir ve onay beklemeden ilerleyebilir.

Karar doğruysa iş akışı hızlanır. Ancak ajanlar her zaman resmin tamamını göremez. Sistemi işleten kişiler için apaçık olan uygulama bağımlılıklarını, iş kurallarını, iş yükü düzenlerini, bakım aralıklarını veya diğer bağlam unsurlarını gözden kaçırabilirler.

Dolayısıyla bir ajan, içinde bulunduğu ortamın kendine özgü kısıtlarını ve gereksinimlerini hesaba kattığımızda, teknik açıdan makul görünen bir karar verip yine de yanılabilir.

Eylemler birbirini izlemeye başladıkça tehlike artar. Kötü bir SELECT yavaş çalışabilir. Kötü bir UPDATE tüm büyük bir tabloyu kilitleyebilir veya amaçlanandan çok daha fazla satırı etkileyebilir. Tek bir sorguda kullanılan bir indeks gereksiz olabilir, ancak diğer sorgulara ek yük getirir. Ajan, sistemin işleyişine dair tüm bağlama sahip olmayabileceği ve olası her kullanım durumunu test edemeyeceği için, şema değişikliği ajanın bu değişikliğe bağlı olduğunu bilmediği bir şeyi bozabilir.

Sorun, ajanların veritabanı hakkında iyi kararlar verememesi değil. Çoğu zaman verebiliyorlar. Sorun, bu kararları uygulamalarına izin verildiğinde ekiplerin bu yetkinin sınırlarını, ajanın hangi bağlamı görebildiğini, hangi durumlarda bir insanın devreye girmesi gerektiğini ve sonuçtan kimin sorumlu olduğunu çok daha net belirlemesi gerekmesi.

Gartner, kısmen yetersiz risk denetimleri nedeniyle, ajan tabanlı yapay zekâ projelerinin %40’tan fazlasının 2027 sonuna kadar iptal edileceğini öngörüyor. Veritabanı ekipleri için çıkarılacak ders oldukça basit: Çalıştırma yetkisi denetimlerden önce değil, sonra verilmeli.

Neler Güvenle Devredilebilir?

Bazı veritabanı görevlerini devretmek diğerlerinden çok daha güvenlidir.

Sorgu analizi buna iyi bir örnektir. Bir ajan, üretim verilerini değiştirmeden sorgu istatistiklerini inceleyebilir, yürütme planlarını alabilir, indeksleri ve tablo yapılarını denetleyebilir ve olası düzeltmeler önerebilir.

Büyük bir tabloyu tekrar tekrar tarayan şöyle bir sorguyu fark edebilir Orders tablo:

SELECT OrderId, OrderDate, Total
FROM Orders
WHERE CustomerId = @CustomerId
ORDER BY OrderDate DESC;

Buradan hareketle taramanın nedenini açıklayabilir, bir indeks önerebilir ve DDL kodu oluşturabilir. Yararlı olabilmesi için bu kodu çalıştırma iznine ihtiyacı yoktur. CREATE INDEX yararlı olması için.

Aynı durum şu görevler için de geçerlidir:

• Yürütme planlarını açıklamak;
• Eksik veya gereksiz indeksleri belirlemek;
• Şunları işaretlemek: SELECT * sorgular veya sargable olmayan koşullar;
• Birleştirme ve filtre işlemlerinin alt katmanlara itilmesini incelemek;
• Bağımlılıkları ve şemaları incelemek;
• SQL hatalarını gidermek;
• SQL betiklerini optimize etmek.

Uygulanabilir ayrım basit: Ajanın sorunu anlayabilmesi için yeterli erişim verin, ancak veritabanını değiştirebilmesi için otomatik olarak yeterli erişim vermeyin. Geniş görünürlük yararlı olabilir; ancak geniş kapsamlı çalıştırma yetkisi ayrı bir karardır.

İnsan Denetiminin Hâlâ Önem Taşıdığı Noktalar

Bazı veritabanı kararlarında hâlâ bir insanın sürece dahil olması gerekir. Örneğin bir ajan, yüz milyonlarca satır içeren bir AuditLog tablo bulup eski kayıtların silinmesi gerektiğine karar verebilir:

DELETE FROM AuditLog
WHERE CreatedAt < DATEADD(year, -2, GETDATE());

SQL tamamen geçerli olsa bile bu karar son derece kötü olabilir.

Belki de mevzuat, verilerin yedi yıl boyunca saklanmasını gerektiriyordur. Bir uygulama bu kayıtlara bağlı olabilir. İşlem günlüğünün büyümesini önlemek için silme işleminin gruplar hâlinde yapılması gerekebilir. Kayıtların silinmeden önce arşivlenmesi de gerekebilir.

Bu gerekliliklerin hiçbiri şemada mutlaka yer almaz.

Veritabanı çalışmalarını kod üretme sorunu olarak ele almanın sınırlarından biri de budur. Veritabanları teknik yapılardan oluşur, ancak bu yapıların çevresindeki kararlar çoğu zaman teknik işlemlerle ifade edilen iş kararlarıdır. Aynı ihtiyat, şu işlemler için de geçerli olmalıdır:

• DROP ve yıkıcı ALTER ifadeler;
• üretim UPDATE ve DELETE işlemler;
• büyük veri taşıma işlemleri;
• rol ve izin değişiklikleri;
• kısıt değişiklikleri;
• replikasyonu veya kullanılabilirliği etkileyen değişiklikler;
• iş mantığı içeren saklı yordamların dağıtımı.

Teknik açıdan doğru bir işlem, mutlaka yerinde bir işlem olmayabilir. Bu nedenle insan onayı, ajan tabanlı yapay zekâ için can sıkıcı bir kısıtlama olarak görülmemelidir. Etkisi yüksek veritabanı işlemlerinde bu onay, mimarinin bir parçasıdır.

Yapay Zekâ Ajanlarının da En Az Yetki İlkesiyle Çalışması Gerekir

Veritabanı ekiplerinin kaçınması gereken kestirme yollardan biri, ajanın bir geliştiricinin mevcut kimlik bilgilerini kullanmasına izin vermektir. Bu kolay bir çözümdür, ancak ajana söz konusu geliştiricinin sahip olduğu tüm erişim yetkilerini verir.

Daha güvenli yaklaşım, kullanıcılar ve hizmetler için kullanılan yaklaşımın aynısıdır: en az yetki ilkesi. Microsoft, yalnızca görev için gereken izinlerin verilmesini ve ayrıcalıklı etkinliklerin izlenmesini öneriyor.

Örneğin bir performans analizi ajanının şunlara ihtiyacı olabilir:

CONNECT
SELECT
VIEW DATABASE STATE
VIEW DEFINITION

Muhtemelen şunlara ihtiyacı yoktur:

ALTER ANY TABLE
CONTROL DATABASE
db_owner
sysadmin

Farklı ajanlara farklı kimlikler de atanabilir. Örneğin bir raporlama ajanına şunlar verilebilir: SELECT birkaç şemaya erişim. Bir geçiş ajanı yalnızca geliştirme veya hazırlık ortamında çalışabilir. Üretim ortamındaki bir ajana kapsamı sıkı biçimde sınırlandırılmış izinler verilebilir; ancak bu ajanın işlem yapmadan önce yine de onay alması gerekebilir.

OWASP, yapay zekâ ajanları için de aynı temel yaklaşımı öneriyor: okuma ve yazma erişimini birbirinden ayırın, araçları ve kaynakları sınırlandırın, hassas işlemler için açık yetkilendirme isteyin.

Kural basittir: ajana, onu başlatan kişinin izinlerini değil, görevinin gerektirdiği izinleri verin.

İnsanı İş Akışının Bir Parçası Hâline Getirin

Ajan tabanlı veritabanı çalışmaları için daha iyi bir model, kontrollü bir iş akışıdır:

Gözlemle → Analiz et → Öner → Gözden geçir → Uygula → Doğrula → Kaydet

Bir ajanın yavaş bir API uç noktasını araştırdığını düşünün. Ajan, bu uç noktanın arkasındaki SQL sorgusunu bulur, yürütme planını ve tablo istatistiklerini inceler, muhtemelen eksik olan bir dizini tespit eder ve bir geçiş betiği hazırlar.

Bu betik önce hazırlık ortamında çalıştırılabilir. Ajan iş yükünü yeniden çalıştırır, sonucu kontrol eder ve üretim ortamında yapılacak değişikliği hazırlar.

Sonra durur.

Bir geliştirici veya veritabanı yöneticisi geçişi inceler, bağımlılıkları ve iş üzerindeki etkisini kontrol eder ve üretim ortamına herhangi bir şey aktarılmadan önce onay verir.

Ajan, tekrarlayan işlerin büyük bölümünü yine de üstlenebilir. Etkisi yüksek bir değişiklik konusundaki nihai sorumluluk ise insanda kalır.

İşlem denetimleri ek bir güvenlik katmanı sağlayabilir. Örneğin PostgreSQL’deki kayıt noktaları, bir işlemin önceki tüm adımlarını geçersiz kılmadan işlemin bir bölümünün geri alınmasına olanak tanır. Bu, birbirine sıkı biçimde bağlı otomatik değişikliklerde yardımcı olabilir; ancak geri alma, uygun izinlerin ve onayın yerini tutmaz.

dbForge AI Assistant gibi araçlar da bu noktada doğal bir yer bulur. Şema bağlamından yararlanarak SQL üretebilir ve açıklayabilir, hataları giderebilir, DDL’yi karşılaştırabilir, verimsiz dizinleri tespit edebilir ve optimizasyon betikleri hazırlayabilir; bu sırada ortaya çıkan SQL’i geliştiricinin incelemesine açık tutar.

Amaç, önemli kararları insana bırakırken rutin işleri otomatikleştirmektir.

Asıl Amaç Kontrollü Özerkliktir

Ajan tabanlı yapay zekâ, “Yapay zekâ yalnızca öneride bulunur” ile “Yapay zekâ veritabanını yönetir” seçeneklerinden birini seçmek anlamına gelmek zorunda değil. Bu ikisinin arasında geniş bir hareket alanı var.

Ekipler, SQL’i açıklama, şemaları gözden geçirme ve salt okunur denetimler yapma gibi daha düşük riskli görevlerle başlayabilir. Ardından ajanlar geliştirme ve hazırlık ortamlarında kademeli olarak daha fazla iş üstlenebilir.

Yazma erişimi çok daha sonra verilmeli ve etkilenen satırlar, işlemler, geri alma, izleme ve onaylar konusunda net sınırlar getirilmelidir. Üretim ortamındaki tamamen özerk değişiklikler nadir olmalıdır.

Bu yaklaşım, Deloitte’un önerileriyle de benzerlik taşıyor: daha düşük riskli iş akışları ve kritik olmayan verilerle başlayın, ilgili kişileri süreçten haberdar edin ve ajanlar daha fazlasını üstlendikçe yönetişimi güçlendirin.

Amaç mutlak özerklik değildir. Ajanın yardımcı olmasına yetecek kadar özgürlük tanımak, ancak ihtiyacından fazla erişim vermemektir.

Özet: Veritabanı geliştirme hâlâ muhakeme gerektiriyor

Yapay zekâ ajanları, veritabanı mühendisliğindeki tekrarlayan işlerin büyük bölümünü üstlenebilir. İş yüklerini görebilir, sorguları inceleyebilir, şemaları, yürütme planlarını, hataları ve performans verilerini ilişkilendirebilir ve gördüklerine göre harekete geçebilirler.

Ancak bir yapay zekâ sistemi veritabanının durumunu değiştirebildiğinde sorun da değişir. Ekiplerin kimlik, izinler, işlem sınırları, onaylar, gözlemlenebilirlik, geri alma ve denetim izleri için açık kurallara ihtiyacı vardır.

İşte bu yüzden, 2025’te kuruluşların %88’i yapay zekâ kullanırken, yalnızca %7’si yapay zekânın kuruluş genelinde tam ölçekli kullanıma geçirildiğini belirtti. Asıl zor olan, yapay zekâyı büyük ölçekte çalışabilecek kadar güvenilir hâle getirmektir.

Veritabanı geliştirme de aynı yönde ilerliyor. En kullanışlı ajan, en çok işi yapmasına izin verilen değil, yetki alanı açıkça tanımlanıp denetlenen ajan olacaktır.

Artık soru, yapay zekânın veritabanı görevlerini yerine getirip getiremeyeceği değil; hangi görevleri yerine getirmesi için ona güvenmemiz gerektiği ve bunu hangi kısıtlar altında yapacağıdır.