Data Dünyasında İki Hafta: Ajanları Kim Yönetecek? - Çağlar Özenç

Merhaba,

Son iki haftanın haberlerine tek tek baktığınızda dağınık bir liste görürsünüz: bir protokol sürümü, bir güvenlik ürünü, bir kanun maddesi, bir yatırım turu, bir analist raporu ve birkaç bulut güncellemesi. Farklı şirketler, farklı katmanlar, hatta farklı kıtalar. 27 Temmuz-7 Ağustos 2026 dönemi, bu blogda anlatmayı sevdiğim türden bir dönemdi: haberler ayrı ayrı sıradan, birlikte okununca tek bir şey söylüyorlar.

Bu yazıda esas anlatmak istediğim şey o tek şey. Haberleri sırayla geçeceğim, her birinin altına neden-sonuç kısmı koyacağım, sonra da hepsini aynı yere bağlayacağım.

Baştan söyleyeyim, bu dönemin öne çıkan cümlesi “yeni bir model çıktı” değil. Öne çıkan cümle şu: veriyi nereye koyacağımız tartışması bitti, artık ajanlar o veriye ve araçlara nasıl erişecek ve bunu kim yönetecek tartışması başladı. Haberlerin neredeyse tamamı doğrudan bu sorunun cevabını inşa ediyor. Üstelik bu sefer soruyu soranlar arasına bir de düzenleyici katıldı.

Dönemin özeti: tek tabloda

Tarih	Olay	Durum	Neden önemli
27 Tem	Google DMS + Gemini	GA	Migrasyon kod dönüşümü kalite denetimi yapay zekaya devrediliyor
27 Tem	AB Yapay Zeka Omnibus’u yürürlükte	Yürürlükte	Yüksek riskli sistem yükümlülükleri 2 Aralık 2027’ye ertelendi
28 Tem	MCP 2026-07-28	Final (GA)	Ajan-araç protokolü stateless oldu; eski taşıma katmanları emekliye ayrıldı
28 Tem	Snowflake Cortex AI Gateway	Public preview (yakında)	Ajanların modele, araca ve MCP sunucusuna erişimi tek kapıdan yönetiliyor
29 Tem	Cloudera lakehouse liderliği	Analist raporu	Lakehouse kategorisi olgunlaştı, artık altyapı katmanı
29 Tem	lakeFS Summer 2026	Sürüm	Veri kümesi sürümleme ve denetim kaydı, yönetişimi ürünün içine alıyor
30 Tem	DataBahn 40 milyon $	Series B	Ajanlara veri taşıyan “kontrol katmanı” ayrı bir kategori oluyor
2 Ağu	AB Yapay Zeka Yasası şeffaflık kuralları	Uygulanıyor	Kullanıcıya “bu bir yapay zeka” demek artık kanuni yükümlülük
5 Ağu	Google veritabanı ajanları	Karışık (GA + preview)	Kurulum önerisi ve kök neden teşhisi ajana devrediliyor

Tüm tarihler 27 Temmuz-7 Ağustos 2026 aralığındadır. Yazının sonunda kısaca değineceğim MySQL sürüm paketi bu pencerenin birkaç gün öncesine (21 Temmuz) ait; bütünü tamamladığı için not düştüm ama tabloya almadım.

1. MCP 2026-07-28: ajan-araç protokolü büyüdü ve sadeleşti

28 Temmuz’da Model Context Protocol’un yeni spesifikasyonu, 2026-07-28, release candidate aşamasından çıkıp final (GA) haline geldi. Sürüm 21 Mayıs’ta aday olarak kilitlenmiş, SDK bakımcıları ve istemci geliştiricileri tarafından on hafta boyunca denendikten sonra yayınlandı. Yani aceleye getirilmiş bir sürüm değil.

Teknik başlıkları sade tutayım, çünkü asıl mesele detayda değil yönde:

Stateless çekirdek. MCP artık çift yönlü, durum tutan bir protokol değil; istek/yanıt temelli, durumsuz bir protokol. initialize / initialized el sıkışması ve Mcp-Session-Id başlığı kaldırıldı. Her istek kendi protokol sürümünü ve kimliğini _meta içinde taşıyor.
Başlık tabanlı yönlendirme. Streamable HTTP istekleri artık Mcp-Method ve Mcp-Name başlıklarını taşıyor. Yani bir ağ geçidi ya da rate limiter, JSON gövdesini açmadan trafiği yönlendirip sayabiliyor.
Multi Round-Trip Requests (MRTR). Sunucunun açık tuttuğu akışlar üzerinden istemciye istek göndermesi (sampling gibi) yerine, sunucu “girdi gerekiyor” deyip istemciye topu atıyor.
Önbelleklenebilir liste sonuçları. Araç, prompt ve kaynak listeleri artık ttlMs ve cacheScope taşıyor.

Kaldırılan tarafta da net bir tablo var. Roots, Sampling ve Logging özellikleri, eski HTTP+SSE taşıma katmanı ve Dynamic Client Registration (DCR) emekliye ayrıldı. Ama panik yok: bunların hepsi en az on iki aylık resmi bir kullanımdan kaldırma penceresiyle geliyor.

Neden-sonuç kısmı: Bir protokolün “durum tutan” halden “durumsuz” hale geçmesi kulağa dar bir mühendislik detayı gibi gelir, ama sonucu operasyonel. Daha önce uzaktan çalışan bir MCP sunucusu, yapışkan oturumlar (sticky session), paylaşımlı bir oturum deposu ve ağ geçidinde derin paket incelemesi ister; artık sıradan bir round-robin yük dengeleyicinin arkasında çalışabiliyor, trafik bir başlığa bakılarak yönlendirilebiliyor. Yani MCP, bir prototip protokolünden kurumsal ölçekte işletilebilen bir protokole geçti. Bu, bir sonraki haberlerin neden bu dönemde geldiğini de açıklıyor.

Pratik tarafı şu: Eğer kendi ortamınızda bir MCP sunucusu işletiyorsanız, bu sürümü bugün production planına almanız gerekmez ama mimari planına almanız gerekir. Kaldırılan özellikleri kullanıyorsanız on iki aylık pencereyi bir takvim kalemi olarak yazın. Kendi sunucunuzda güvenli, salt-okunur bir kurulumu adım adım nasıl yapacağınızı daha önce SQL MCP Server: 3 Adımda Güvenli ve Kolay Kurulum yazısında anlatmıştım; oradaki mantık bu sürümle de aynı, sadece taşıma katmanı sadeleşti.

2. Snowflake Cortex AI Gateway: ajanın veriye açılan kapısına bir bekçi

Aynı gün, 28 Temmuz’da, Snowflake Black Hat 2026’da Cortex AI Gateway‘i duyurdu. GA/preview ayrımını hemen yapayım, çünkü bu tür duyurularda en çok orada kayboluyoruz: Snowflake bazı güvenlik yeteneklerini genel kullanıma (GA) taşıyor, ama Cortex AI Gateway’in kendisi public preview’a girecek (duyuru anında “yakında” konumunda). Yani ürün var, henüz herkesin elinde değil.

Ne işe yarıyor? İki cümlede: kurumdaki AI ajanlarının modele, araca, MCP sunucusuna ve kurumsal sistemlere erişimini tek bir kapıdan yönetmek; bu erişimin maliyetini ve token tüketimini tek bir yerden görmek. Snowflake CoWork ve CoCo’nun yanı sıra Claude Code ve Cursor gibi dış platformlarda geliştirilen ajanları da kapsıyor. Ağ geçidi, hangi ajanın ne yaptığını, hangi araçlara ve sistemlere ulaştığını ve adımların sırasını uçtan uca kaydediyor.

Bir nüans daha var, ve bu bir tesadüf değil: Cortex AI Gateway, Snowflake’in Mayıs 2026’da satın aldığı Natoma‘nın teknolojisi üzerine kuruluyor. Natoma, tam olarak araç çağrısı seviyesinde kimlik, politika ve denetim uygulayan merkezi bir MCP ağ geçidi yapan 27 kişilik bir girişimdi. Yani bir numaralı haberdeki protokol standartlaşırken, Snowflake o standardın etrafına yönetişim inşa etti.

Duyuruda ekosistem tarafı da öne çıktı: 1Password, Aembit, Linx Security, Okta, SailPoint ve Saviynt ile entegrasyonlar. Bu isimlerin ortak yanı kimlik ve erişim yönetimi. Yani ajan güvenliği, klasik kimlik dünyasının araçlarıyla birleşiyor.

Neden-sonuç kısmı: Bir yıldır sahada ajan projesi yapan herkesin bildiği bir gerçek var: modeli seçmek kolay, o modele “kurumsal veriye ve araçlara sınırlı, denetlenebilir erişim” vermek zor. “Bu ajan hangi tabloyu okuyabilir?”, “hangi aracı çağırabilir?”, “bu ay kaç token harcadı ve neden?” sorularının makine tarafından uygulanabilir bir cevabı olmak zorunda. Snowflake’in yaptığı şey bu soruyu bir ürün kategorisine çevirmek. Bunu daha önce genel çerçevede Yapay Zekaya Veri Erişimini Yönetmek yazısında Observe-Govern-Act modeliyle anlatmıştım; Cortex AI Gateway o modelin “Govern” tarafının paketlenmiş bir örneği. Kritik soru şu: ajan katmanının önüne konan bekçi, ajanın erişebildiği veritabanının kendi içindeki yetkilendirmenin yerine geçmez, onun üstüne biner. İkisini birden düşünmeniz gerekiyor.

3. AB Yapay Zeka Yasası: şeffaflık kuralları artık yürürlükte

Bu dönemin en az konuşulan ama en kalıcı haberi bir ürün duyurusu değil, bir takvim maddesi. 2 Ağustos 2026 itibarıyla AB Yapay Zeka Yasası’nın şeffaflık kuralları uygulanmaya başladı. Kabaca üç şey demek: bir kullanıcı yapay zeka sistemiyle konuştuğunda bunu ona söylemek zorundasınız, üretken yapay zeka çıktılarının makine tarafından okunabilir şekilde işaretlenmesi gerekiyor, ve deepfake türü içeriklerin açıkça bildirilmesi gerekiyor.

Aynı pencerede ikinci bir hareket daha oldu: 27 Temmuz‘da yürürlüğe giren Yapay Zeka Omnibus’u, yüksek riskli sistemlere (biyometri, kritik altyapı, eğitim, istihdam, göç ve sınır kontrolü gibi alanlar) dair yükümlülükleri 2 Aralık 2027‘ye erteledi. Yani takvimin sert kısmı bir buçuk yıl ileri kaydı, ama şeffaflık kısmı kaymadı ve şu anda geçerli.

Neden-sonuç kısmı: Yazının geri kalanındaki haberler yönetişimi bir ürün olarak satıyor; bu haber yönetişimi bir yükümlülük haline getiriyor. Fark önemli. Snowflake’in ağ geçidini almazsanız kimse size bir şey demez; kullanıcıya karşı şeffaflık yükümlülüğünü atlarsanız durum farklı. Türkiye’de çalışan bir ekip için “bizi ilgilendirmez” demek de kolay değil: AB’de müşterisi, kullanıcısı ya da iştiraki olan her yapı bu kapsama girebiliyor. Somut karşılığı şu: sohbet arayüzünüzde “bu bir yapay zeka asistanıdır” ibaresi, ajanın ürettiği içeriğin işaretlenmesi ve hangi çıktının makineden geldiğinin kaydı artık “güzel olur” değil, dosyalanabilir bir gereklilik. Ertelenen yüksek risk maddelerine gelince, o ertelemeyi rahatlama değil hazırlık süresi olarak okuyun; 2027 sonu göründüğünden yakın.

4. lakeFS Summer 2026: yönetişim ürünün içine giriyor

29 Temmuz’da lakeFS, kurumsal sürümü için Summer 2026 paketini duyurdu. Öne çıkan iki başlık var. Birincisi veri kümeleri (datasets): nesneler, önekler, Iceberg tabloları ve isim alanları boyunca yayılan mantıksal veri kümelerini tanımlayıp sürümleyebiliyor, keşfedilebilir ve paylaşılabilir hale getirebiliyorsunuz; her küme değişmez (immutable) ve yeniden kullanılabilir. İkincisi çok kiracılılık (multi-tenancy): tek kurulum içinde izole ortamlar açarak ekipleri, iş birimlerini ya da düzenleyici alanları ayırabiliyorsunuz.

Şirketin kendi ifadesi “tasarımdan gelen yapay zeka veri yönetişimi” ve denetime hazır kanıtı otomatik ürettiği iddiasında. Bunun üretici beyanı olduğunu not düşeyim; bağımsız bir ölçüm değil.

Neden-sonuç kısmı: Duyurunun zamanlaması tesadüf değil, üç gün sonra AB tarafında şeffaflık kuralları yürürlüğe giriyordu. Ama asıl mesele pazarlama zamanlaması değil, mühendislik tarafındaki karşılığı: bir modeli ya da ajanı denetlenebilir kılmak istiyorsanız, “hangi veriyle eğitildi, hangi veriyi gördü, o veri o gün hangi haldeydi” sorusuna cevap verebilmeniz gerekiyor. Bu, veriyi kod gibi sürümlemek demek. Yıllardır kodda yaptığımız şeyin (commit, branch, diff) veri tarafında karşılığının olmaması en büyük eksiklerdendi. Denetim kaydını sonradan raporla üretmeye çalışmak yerine veri katmanının kendisinden almak, bir sonraki iki haberin de aynı yöne baktığını gösteriyor.

5. DataBahn 40 milyon dolar: “ajan veri kontrol katmanı” bir kategori oluyor

30 Temmuz’da Dallas merkezli DataBahn, Insight Partners liderliğinde 40 milyon dolarlık Series B turunu kapattığını duyurdu. Bu turla toplam yatırımı 59 milyon dolara çıktı; mevcut yatırımcılar Forgepoint, GTM Capital ve S3 Ventures de tura katıldı.

Şirketin kendini tanımladığı ifade dikkat çekici: “kurumun Agentic Data Control Plane’i”, yani ajan veri kontrol katmanı. Yaptığı iş, telemetri verisini (log, olay, metrik) kaynağından alıp normalize etmek, zenginleştirmek, yönetişimini yapmak ve hedefe yönlendirmek. DataBahn’ın iddiası 600’den fazla kaynaktan veri toplayıp herhangi bir hedefe, herhangi bir modele “vendor kilidi olmadan, Fortune 100 ölçeğinde” taşıyabildiği. Bu rakamlar ve ölçek ifadeleri vendor iddiası, sahada bağımsız teyit edilmiş değil; ama kategorinin varlığı iddia değil, artık bir yatırım kalemi.

Neden-sonuç kısmı: Buradaki asıl haber turun büyüklüğü değil, turun neye yapıldığı. İki yıl önce “veri boru hattı” (data pipeline) olgun, sıkıcı, çözülmüş bir kategoriydi. AI ajanları bu kategoriyi yeniden açtı, çünkü ajanların ihtiyaç duyduğu şey ham veri değil, bağlamlı, güvenilir, yönetişimi yapılmış veri. Insight Partners bu turu “gelecekteki güvenlik mimarisinin temeli” diye konumlandırdı; yani veri taşıma işi, güvenlik bütçesinin içine giriyor. Yukarıdaki haberlerle birlikte okuyun: MCP protokolü ajanın nasıl konuşacağını, Snowflake ajanın erişimini kimin yöneteceğini, DataBahn ise ajana giden verinin hangi kalitede geleceğini çözmeye çalışıyor. Aynı problemin üç ayrı ucu.

6. Cloudera lakehouse liderliğine seçildi: kategori olgunlaştı

29 Temmuz’da Cloudera, bağımsız bir araştırma firmasının Forrester Wave: Data Lakehouses, Q3 2026 değerlendirmesinde Lider olarak konumlandırıldığını duyurdu. Cloudera, vizyon ve yol haritası kriterinde alınabilecek en yüksek puanı almış.

Bir uyarı: bu bir ürün lansmanı değil, bir analist raporu. Forrester Wave gibi değerlendirmeler, bir kategorinin oyuncularını “mevcut teklif”, “strateji” ve “müşteri geri bildirimi” üzerinden karşılaştırır. Bir vendor’un “Lider” seçilmesi kendi başına teknik bir gerçek değil, kategorinin belli bir olgunluğa ulaştığının işaretidir. Analist raporları vendor tarafından sıkça pazarlama malzemesi olarak kullanılır; okurken bunu akılda tutun.

Neden-sonuç kısmı: Forrester’ın “Data Lakehouses” başlığı altında ayrı bir Wave yayınlaması bile başlı başına bir haber. İki yıl önce tartışma “data warehouse mı data lake mi” idi; bugün lakehouse o tartışmanın kazananı ve kendi başına bir kategori olarak analist tarafından ölçülüyor. Bunun sizin için anlamı şu: lakehouse artık deneysel bir mimari tercih değil, üzerine kurumsal bahis oynanan bir altyapı katmanı. Ve yukarıdaki haberlerin tamamı tam olarak bu katmanın üstünde çalışıyor. Ajanlar veriye erişecekse, o verinin durduğu yer giderek daha çok lakehouse oluyor.

7. Google Database Migration Service: kod dönüşümünün kalite denetimini yapay zeka yapıyor

27 Temmuz’da Google Cloud, Database Migration Service (DMS) tarafında iki güncellemeyi genel kullanıma (GA) taşıdı. Birincisi ve önemlisi: heterojen migrasyonlarda (örneğin Oracle’dan PostgreSQL’e) Gemini destekli dönüşüm kalitesi denetimi GA oldu. Yani Gemini, dönüştürülen kodu kaynak kodla doğruluk ve işlevsel eşdeğerlik açısından analiz ediyor. İkincisi: heterojen Oracle ve SQL Server migrasyonlarında tablo seviyesinde gözlemlenebilirlik geldi, yani her tablonun migrasyon ilerlemesini ayrı ayrı izleyebiliyorsunuz.

Neden-sonuç kısmı: Migrasyon işinin içinde olan biri olarak açık konuşayım: bu tür araçlar sözdizimini çevirmekte iyi, davranışı çevirmekte değil. NULL karşılaştırmaları, collation, implicit conversion, tarih aritmetiği ve isolation level farkları hala insan gözü ister. Google’ın burada attığı adım tam olarak bu boşluğa dokunuyor: dönüşümü yapmak değil, dönüşümün doğru olup olmadığını denetlemek. “İşlevsel eşdeğerlik analizi” iddiası kağıt üzerinde güzel; ama bir yapay zekanın “bu iki sorgu eşdeğer” demesi, sizin kabul testlerinizin yerine geçmez. Bunu bir ilk süzgeç olarak kullanın, son onay olarak değil. Yine de işin en sıkıcı %70’ini alması bile ciddi bir kazanç.

Bu, aslında bir numaralı temanın bir başka yüzü: yapay zeka, veri işinin en zahmetli kalemlerine (migrasyon, kalite denetimi, yönetişim) giriyor. Vektör aramanın veritabanlarının içine nasıl girdiğini kronolojik olarak Veritabanı İçerisine Vektör Aramanın Kısa Tarihi yazısında çıkarmıştım; aynı hareket şimdi migrasyon araçlarında tekrar ediyor.

8. Google’ın veritabanı ajanları: ayrıntılar 5 Ağustos’ta geldi

Bir netleştirmeyle başlayayım, çünkü bu tür haberlerde tarih karışıyor: Database Onboarding Agent ve Database Observability Agent, Google Cloud Next ’26’da Agentic Data Cloud lansmanının parçası olarak duyurulmuştu. 5 Ağustos’ta gelen şey yeni bir duyuru değil, bu iki ajanın ayrıntılı anlatımı. Yeni olan bilgi, ne yaptıkları ve hangi kısmının kimin elinde olduğu.

Database Onboarding Agent, iş yükünüzün performans, ölçek, veri tipi ve güvenilirlik ihtiyaçlarını analiz edip hangi yönetilen veritabanı hizmetinin uygun olduğunu öneriyor; hizmeti seçtikten sonra kurulum komutlarını da kendisi üretiyor. Database Observability Agent ise Database Insights, Cloud Monitoring, Cloud Logging ve Cloud Trace verilerini birbirine bağlayarak “filomdaki hangi veritabanı en çok CPU tüketti” türü soruları yanıtlıyor, kök nedene götürüyor.

Erişim durumu karışık, ayırmakta fayda var: Gemini Cloud Assist sohbeti üzerinden kullanım GA; ürün içi incelemeler ve onayınızla uygulanan düzeltmeler (örneğin bir Cloud SQL örneğine indeks eklemek) seçili müşterilerle preview aşamasında. Kapsam Cloud SQL (PostgreSQL, MySQL, SQL Server), Spanner, AlloyDB, Bigtable, Firestore ve Memorystore.

Neden-sonuç kısmı: Bu, yazının başındaki soruya bulut sağlayıcısı tarafından verilen cevap. Snowflake ajanın erişimine bekçi koyuyordu; Google doğrudan ajanı DBA’nın masasına oturtuyor. DBA’lerin gününün ciddi bir kısmı “hangi sorgu yavaş, neden yavaş” tahmininde geçiyor ve bu iş, birden fazla telemetri kaynağını kafada birleştirmeyi gerektiriyor; ajanın iyi olduğu iş tam olarak bu. Ama önemli olan sınırı görmek: teşhis önerisi ile uygulanan düzeltme arasındaki fark, preview etiketinin durduğu yer. Google da düzeltme tarafını herkese açmamış olması boşuna değil. Bu ayrımı kendi ortamınızda da koruyun: ajan teşhis etsin, üretimde değişikliği insan onaylasın.

Bir de kenar notu: MySQL takvim tabanlı sürüme geçti

Bu haber seçtiğim pencerenin birkaç gün öncesine, 21 Temmuz civarına ait; o yüzden tabloya almadım ama resmi tamamladığı için not düşüyorum. Oracle, Temmuz 2026 MySQL GA sürümlerini yayınladı ve MySQL 26.7.0 Innovation ile birlikte Innovation sürümleri artık takvim tabanlı (Yıl.Ay.Yama) bir numaralandırmaya geçti; bir sonraki Innovation sürümü 26.10 olacak. Aynı pakette 9.7.2 LTS, 8.4.11 LTS ve 8.0.46 de var. Küçük bir haber gibi görünüyor ama bir sinyal: büyük veritabanları sürüm ritmini “özellik hazır olunca” yerine “takvim dolunca” modeline çeviriyor, tıpkı işletim sistemleri ve tarayıcıların yıllar önce yaptığı gibi. Sürüm takibini otomatikleştirmeniz gereken bir dünyaya gidiyoruz.

Hepsini bağlayalım: sekiz haber, tek soru

Şimdi başa dönelim. Bir protokol finali, bir güvenlik ürünü, bir kanun maddesi, bir sürüm paketi, bir yatırım turu, bir analist raporu ve iki bulut güncellemesi. Ortak paydaları ne?

Hepsi aynı soruyu farklı katmandan cevaplıyor: ajanlar veriye ve araçlara nasıl erişecek, bunu kim yönetecek?

MCP ortak dili sağlıyor: ajan bir araca hangi kurallarla konuşacak, standartlaştırdı ve kurumsal ölçekte işletilebilir hale getirdi.
Snowflake Cortex AI Gateway kapıya bekçi koyuyor: ajanın erişimini, maliyetini ve iz kaydını tek yerden yönetiyor.
AB Yapay Zeka Yasası aynı işi zorunlu kılıyor: şeffaflık artık tercih değil yükümlülük.
lakeFS denetim kaydını veri katmanının içine koyuyor: hangi ajan hangi veriyi hangi halde gördü, sürümlenebilir hale geliyor.
DataBahn boruyu döşüyor: ajana giden verinin normalize, zenginleştirilmiş ve yönetişimi yapılmış gelmesini sağlıyor.
Cloudera’nın lakehouse liderliği zemini işaret ediyor: bütün bu erişimin altında duran veri katmanı olgunlaştı.
Google’ın Gemini destekli migrasyonu ve veritabanı ajanları ise yapay zekanın artık sadece “veriye erişen” değil, “veri işini yapan” tarafa da geçtiğini gösteriyor.

İki yıl önce bu iki haftanın gündemi “hangi veritabanını, hangi ambarı kuralım” olurdu. Bu sefer gündemin neredeyse tamamı, kurulu veriye ajanların nasıl, kimin denetiminde ulaşacağıyla ilgiliydi. Kategori değişti. Ve bu sefer tartışmaya üreticilerin yanında bir de düzenleyici katıldı, ki bu genellikle bir teknolojinin “deneysel” evresinin bittiğinin en net işaretidir.

Peki bu sizin için ne demek? Dört somut çıkarım bırakayım:

Bir: Ajan projesine başlamadan önce yönetişim ve erişim katmanını planlayın. 2026’da “önce ajanı kuralım, güvenliği sonra ekleriz” yaklaşımı, iki yıl öncesine göre çok daha zayıf bir savunmaya sahip. Snowflake, DataBahn ve Natoma satın alması, piyasanın bu işi “sonra” değil “önce” olarak fiyatladığını gösteriyor.

İki: Ajan katmanındaki yetkilendirme, veritabanındaki yetkilendirmenin yerine geçmez, üstüne biner. Cortex AI Gateway gibi bir kapı bekçisi koysanız bile, ajanın eriştiği veritabanının kendi içindeki rol ve izinleri hala doğru olmak zorunda. İki katmanı birden düşünün.

Üç: Yapay zeka destekli otomasyon araçlarına (migrasyon kalite denetimi, kod dönüşümü, kök neden teşhisi) ilk süzgeç olarak güvenin, son onay olarak değil. Google’ın Gemini eşdeğerlik analizi işinizin %70’ini alır; kalan %30 hala sizin kabul testinizdir. Google’ın kendi ajanında bile düzeltme uygulama kısmının preview’da tutulması aynı sınırı işaret ediyor.

Dört: Şeffaflık tarafını bugün bir kontrol listesine çevirin. Kullanıcı bir ajanla mı konuşuyor, bunu görüyor mu? Üretilen içerik işaretleniyor mu? Bu sorular artık mühendislik tercihi değil, uyum kalemi.

Bu konuların sizin ortamınızda ne anlama geldiğini konuşmak isterseniz, DMC Bilgi Teknolojileri olarak yönetilen veritabanı hizmetleri tarafında SQL Server’ın yanı sıra PostgreSQL ve MongoDB yönetimi de yapıyoruz. Bu dönemin esas konusuna, yani veriye ajan erişimi ve yönetişimine denk gelen tarafta ise yapay zeka hizmetleri ve veri güvenliği başlıklarına bakabilir ya da doğrudan iletişim sayfasından yazabilirsiniz.

Bu formatı düzenli hale getirmeyi düşünüyorum. Hangi başlığı daha derin işlememi istersiniz, yorumlarda yazın. 🙂

Kaynaklar

Aşağıdaki bağlantıların tamamı 7 Ağustos 2026 itibarıyla kontrol edildi. Bazı rakam ve ölçek ifadeleri (özellikle DataBahn’ın kaynak sayısı ve ölçek iddiaları, lakeFS’in “denetime hazır kanıt” ifadesi ve Cloudera’nın analist raporundaki konumu) üretici ya da araştırma firması beyanıdır; yazı içinde bunu ayrıca belirttim. GA/preview ayrımları da metinde tek tek işaretlenmiştir.

Bir yanıt yazın Yanıtı iptal et

günün sonunda insan bedenin de dolaşan robotlar olacak o zamana kadar devam :)

Yavaş yavaş bilim kurgu filmleri gerçek oluyor istediğin soruyu sor cevabını al şeklinde başlayan yapay zekadan işleri senin yerine yapan…

çok güzel bir derleme olmuş. elinize sağlık!

Oracle veri tabanında materialized view kullanıyorum ve de tablelarda geçmiş yıllardaki verileri donuk olarak tutuyorum. Star schema kurulumu, DWH yapısının…

Merhaba Ali Rıza Bey, Değerli yorumunuz ve ilginiz için çok teşekkür ederim 🙏 Sorularınıza yanıt vereyim: 🔸 “Bu sistem SQL…