Lovable ile Uygulamayı Siz Geliştirdiniz — Veri Sızdığında Sorumlu Kim?
Bir ürün yöneticisinin dahili bir panele ihtiyacı vardır. Bir talep açıp mühendislik ekibinin bir çeyrek boyunca sırasının gelmesini beklemek yerine, Lovable'ı açar, ne istediğini sade bir dille tarif eder, şirketin Google Workspace'ine bağlar ve aynı öğleden sonra çalışan bir uygulamayı devreye alır. Drive'dan okur, birkaç e-tablo çeker ve haftalık bir özeti e-posta ile gönderir. İşe yarar. Herkes memnundur.
Altı ay sonra bir güvenlik denetçisi ya da bir düzenleyici sorunca önem kazanan soruyu kimse sormaz: o uygulamanın dokunduğu verileri nasıl işlediğinden kim sorumludur?
Bu sorunun cevabı, kodu üreten platform değildir. Onu devreye alan şirkettir. Bu makale, "bunu yapay zekayla geliştirdik" ifadesinin neden bir savunma olmadığını, yapay zekayla geliştirilen uygulamalarda özellikle nelerin ters gittiğini ve soru öfkeyle sorulmadan önce nasıl görünürlük kazanılacağını açıklıyor.
"Yapay zekayla geliştirilen uygulama" gerçekte ne anlama gelir
Lovable, Base44, Bolt.new, Cursor ve giderek büyüyen bir liste oluşturan diğer araçlardan oluşan yeni bir kategori, insanların doğal dilde yazdıkları komutlardan gerçek web uygulamaları geliştirmesine ve devreye almasına olanak tanıyor. Bunlara sıklıkla "vibe coding" platformları deniyor. Cazibesi açık: yazılım geliştirici olmayan biri, daha önce bir ekip gerektiren bir şeyi üretebiliyor ve bunu saatler içinde yapabiliyor.
Bu uygulamalar oyuncak değil. Gerçek kullanıcılara devreye alınıyorlar ve düzenli olarak sıradan OAuth izinleri üzerinden gerçek şirket sistemlerine — Google Workspace, Salesforce, dahili veritabanları — bağlanıyorlar. Verinin bakış açısından, bir öğleden sonrada bir komutla geliştirilen uygulama ile bir mühendislik ekibi tarafından aylarca sürede geliştirilen uygulama birbirinin aynı görünür: her ikisi de bir erişim jetonu tutar ve her ikisi de o jetonun izin verdiği her şeyi okuyabilir.
Bu simetri, sorunun tam kalbidir. Yapay zeka geliştiricilerini çekici kılan hız, bir uygulamanın hassas verilere kimse o verilerle ne yaptığını incelemeden ulaşmasına olanak tanıyan aynı hızdır.
Yapay zekayla geliştirmek, güvenli olmakla aynı şey değildir
Burada kesin ve adil olmakta fayda var: Lovable veya Base44 ile geliştirilen bir uygulama doğası gereği güvensiz değildir. Bu platformlar son derece makul uygulamalar üretebilir ve çoğu zaman da öyle yapar. Risk, yapay zekanın kötü kod yazması değildir. Risk yönetişimdir ve kendini üç öngörülebilir şekilde gösterir.
Devreye alan kişi kodu nadiren okur. Vibe coding'in tüm değer önerisi, bunu yapmak zorunda kalmamanızdır. Dolayısıyla uygulamayı devreye alan kişi çoğu zaman verinin nasıl saklandığını, hassas alanların kaydedilip kaydedilmediğini, bilginin nereye gönderildiğini veya herhangi bir şeyin ne kadar süre saklandığını size söyleyemez. Sorumlu taraf, sorumlu olduğu şey hakkında en az görünürlüğe sahip olandır.
Erişim geniş ve görünmezdir. Yapay zeka geliştiricileri, demoyu çalıştıracak kapsamları ister ve "çalışmasını sağlamak" genellikle geniş okuma erişimi anlamına gelir. Yalnızca tek bir klasörü okuması gereken dahili bir pano, tüm Drive'a okuma erişimine sahip olabilir. Bu izin sıradan bir OAuth onay ekranı üzerinden gerçekleştiği için, hiçbir zaman kimsenin güvenlik radarına girmemiştir — tanım gereği bu, gölge BT'dir.
Belgelenmiş bir veri işleme politikası yoktur. Elle geliştirilmiş bir üretim sisteminin saklama politikasını sorun, genellikle bir cevap alırsınız. Bir meslektaşınızın geçen salı ürettiği bir uygulamanın saklama politikasını sorun, kayıtlı hiçbir şey yoktur. Veri koruma hukuku altında, "verinin ne kadar süre tutulduğunu bilmiyoruz" tarafsız bir cevap değildir — bir bulgudur.
Neden platform değil, şirket sorumlu tutulur
İşte insanları şaşırtan kısım burası. Yapay zekayla geliştirilen bir uygulama veriyi hatalı işlediğinde, hukuki ve düzenleyici sorumluluk onu üreten yapay zeka geliştiricisine değil, onu devreye alan kuruluşa düşer.
Bu, genel olarak yapay zeka hukukunu yeniden şekillendiren aynı sorumluluk kaymasıdır. AB'nin Genel Veri Koruma Tüzüğü (GDPR) kapsamında, kişisel verilerin işlenme amaçlarını ve yöntemlerini belirleyen taraf veri sorumlusudur ve yükümlülükleri — hukuka uygunluk temeli, veri minimizasyonu, saklama sınırlaması ve tüm bunları kanıtlama yükümlülüğü — veri sorumlusu taşır. Şirketiniz müşteri verilerini işleyen bir uygulamayı devreye aldığında, veri sorumlusu şirketinizdir. Geliştirici platform, en fazla kullandığınız bir araçtır.
2026'nın daha geniş hukuki manzarası da aynı yönü işaret ediyor. Mahkemeler, bir yapay zeka sistemini kullanan şirketi onun davranışından sorumlu tutmaya başladı — Amerika Birleşik Devletleri'ndeki *Mobley v. Workday* davası bir vekalet (agency) teorisi üzerinden ilerledi ve daha sonra ülke çapında bir toplu davanın koşullu onayını kazandı. Almanya'da, OLG Hamm bir yapay zeka sisteminin müşterilere söylediklerinden sorumluluğu ele aldı ve genel bir "garanti yoktur" ibaresinin tek başına devreye alan şirketi korumadığını işaret etti. AB Yapay Zeka Yasası, yüksek riskli kullanımlar için önemli cezalarla birlikte devreye alanlara özgü yükümlülükleri buna ekliyor. Bu kaymayı bir yapay zeka aracısı veri sızdırdığında kimin sorumlu olduğuna dair genel bakışımızda derinlemesine ele alıyoruz.
Ortak nokta şu: yapay zekayla geliştirilen bir uygulamayı devreye almak, kuruluşunuzun verdiği bir karardır ve hukuk kararları sorumluluk taşıyan şeyler olarak ele alır. Kodu bir yapay zekanın yazmış olması, onu şirket verisine bağlamayı kimin seçtiği konusunda hiçbir şeyi değiştirmez.
Kör nokta, somut olarak
Parçaları bir araya getirdiğinizde, belirli ve yaygın bir hata modeli ortaya çıkar:
- Teknik olmayan bir çalışan, bir yapay zeka geliştirici aracıyla bir uygulama oluşturur.
- Uygulama, OAuth üzerinden Google Workspace'e bağlanır ve geniş kapsamlar verilir.
- Müşteri veya çalışan kişisel verilerine — kişiler, e-posta içerikleri, dosyalar — ulaşır.
- Kimse veri işlemeyi incelemez ve kayıtlı bir saklama politikası yoktur.
- Güvenlik ekibinin uygulama için envanter kaydı yoktur, çünkü hiçbir zaman bir incelemeden geçmemiştir.
Her adım tek başına makuldür. Bir araya geldiklerinde, şirketinizin hukuken sorumlu olduğu ve güvenlik ekibinizin varlığından haberdar olmadığı, kişisel veri işleyen bir uygulama ortaya çıkar. İşte bu, bir denetçinin sorguladığı ve bir ihlalin istismar ettiği boşluktur.
Boşluğu nasıl kapatırsınız
Çözüm, yapay zeka geliştirici araçlarını yasaklamak değildir — o yarış zaten kaybedilmiştir ve verimlilik gerçektir. Çözüm görünürlük ve kanıttır: hangi yapay zekayla geliştirilen uygulamaların bağlı olduğunu bilmek, her birinin nereye ulaşabildiğini bilmek ve onları yönettiğinizi gösterebilmek.
8200.dev'in yaptığı tam olarak budur. Google Workspace'inize bağlı OAuth uygulamalarını keşfeder ve bunların arasından Lovable, Base44, Bolt.new, Cursor ve benzerleri gibi yapay zeka geliştirici araçlarından kaynaklananları — uygulama adı ve yönlendirme adresi (redirect-host) imzalarından, ve doğrulanmamış, yakın zamanda oluşturulmuş ve zaten geniş kapsamlara sahip olan uygulamaların belirgin desenlerinden — işaretler. Her biri için geliştirici platformunu, verilen tam kapsamları, kimin yetkilendirdiğini ve bir risk puanını, diğer yapay zeka aracılarınız ve OAuth uygulamalarınızın yanında özel bir Yapay Zekayla Geliştirilen Uygulamalar görünümünde görürsünüz.
Yapay zekayla geliştirilen bir uygulama müşteri PII'sine ulaşabildiğinde veya belgelenmiş bir saklama politikası olmadan geniş erişime sahip olduğunda, belirli bir bulgu tetiklenir — böylece boşluk bir denetimde sürpriz olmak yerine sahibi olan bir görev haline gelir. Ve her yapay zekayla geliştirilen uygulama, Yapay Zeka Aracısı Kayıt Defteri'ne (AI Agent Registry) kaydedilebilir, böylece hiçbir bağlayıcının ulaşamadığı uygulamalar bile tek, eksiksiz bir envanterde görünür. Tam özellik setini burada görebilirsiniz.
Mesele, ekiplerinizi yavaşlatmak değildir. Mesele, soru geldiğinde — bir düzenleyiciden, bir denetçiden veya bir müşteri güvenlik incelemesinden — cevap verebilmenizi sağlamaktır. "Bunu yapay zekayla geliştirdik, bu yüzden platformun sorunu" demek bir savunma değildir; ama "işte uygulama, işte tam olarak neye erişebildiği ve işte onu incelediğimizin kanıtı" demek bir savunmadır. İncelemecilerin artık ne beklediğine daha derinlemesine bakmak için denetçilerin 2026'da yapay zeka yönetişimi için gerektirdiklerine göz atın.
Yapay zekayla geliştirmek hızlıdır. Geliştirdiğiniz şeyden sorumlu olmak isteğe bağlı değildir. İkisi tek bir şeyle uzlaştırılır: yapay zekayla geliştirdiğiniz uygulamaların gerçekte neye ulaşabildiğini bilmek.
Workspace'inize zaten neyin bağlı olduğunu görerek başlayın. Yapay zekayla geliştirilen uygulamalarınızı haritalandırabilir, erişimlerini puanlayabilir ve ücretsiz katmanda ilk kanıt parçanızı oluşturabilirsiniz — planları görün ve ücretsiz başlayın.
*Bu makale genel bilgi niteliğindedir, hukuki tavsiye değildir. Kuruluşunuza özgü rehberlik için yetkin bir hukuk danışmanına başvurun.*
İlgili makaleler
- AI Yönetişiminde Uyumluluk: Denetçiler 2026'da Artık Ne İstiyor
AI yönetişimi artık standart bir denetim kalemi. Denetçilerin 2026'da beklediklerine ve kanıtları önceden hazır bulundurmaya dair pratik bir rehber.
- AI Ajanınız Veri Sızdırdığında Sorumluluk Kimde? 2026 Hukuki Gerçekliği
Mahkemeler giderek AI'yı kullanan şirketi -sadece tedarikçiyi değil- sorumlu tutuyor. 2026 sorumluluk manzarasına net, gerçekçi bir bakış.
- OpenAI–Hugging Face Olayı Kurumsal Şirketler İçin Gerçekte Ne Anlama Geliyor?
OpenAI modelleri izole bir test korumalı alanından kaçarak Hugging Face üretim sistemlerine ulaştı. Ne oldu, ne olmadı ve bu, AI ajanlarınız için ne anlama geliyor.