Yapay Zeka ile Geliştirdiğin Uygulamada Kullanıcı Verilerini Nasıl Korursun (Güvenlik Ekibi Olmadan)

Yapay zeka ile geliştirdiğin uygulama, gerçek insanlar hakkında gerçek bilgiler tutuyor. İşte kullanıcı verilerini üç alışkanlık ve beş soruyla nasıl koruyacağın — güvenlik geçmişi gerekmez.

Tanıdığımız bir koç, bir hafta sonu boyunca bir yapay zeka uygulama oluşturucu ile müşteri takip uygulaması geliştirdi. Seans notları, hedefler, gelişim kontrolleri — eskiden bir deftere yazdığı her şey, artık aranabilir ve düzenli. O kadar iyi çalıştı ki iki koç arkadaşı da kullanmak istedi.

İşte o zaman fark etti: artık kendi notlarını tutmuyordu. Başkalarının kendi müşterileri hakkındaki notlarını tutuyordu — sağlık ayrıntıları, kişisel zorluklar, isimler. O veri sızsa, bu onun utancı olmazdı. Onların utancı olurdu.

Bunu sorumlu bir şekilde ele almak için bir güvenlik ekibine ihtiyacın yok. Üç alışkanlığa ve yapay zeka oluşturucuna birkaç doğrudan soru sorma isteğine ihtiyacın var. Bu rehber, yapay zeka ile geliştirdiğin uygulamada kullanıcı verilerini, küçük bir ürün için gerçekten önemli olan düzeyde nasıl koruyacağını anlatıyor.

Önce gerçekte hangi kullanıcı verisini tuttuğunu fark ederek başla

Çoğu üretici bunu hafife alır. “Sadece bir kayıt formum var” genellikle şu anlama gelir:

  • E-posta adresleri — birine spam ya da oltalama yapacak kadar.
  • Davranışla bağlantılı isimler — ne aldıkları, ne yazdıkları, ne zaman giriş yaptıkları.
  • Kullanıcılarının serbest metin kutularına yazdığı her şey — ve insanlar bir not alanına her şeyi yazar: telefon numaraları, tıbbi ayrıntılar, maaşlar, patronları hakkında şikâyetler.

On dakika ayır ve uygulamanın bir kişi hakkında sakladığı her bilgi parçasını yaz. Veritabanı alanlarını değil — insani anlamı. “E-posta”, “hangi takviyeleri aldıkları”, “antrenörlerinin onlar hakkında yazdığı notlar”. O liste, senin sorumluluk yüzeyindir. Bu yazıdaki diğer her şey, onu daha küçük ve daha güvenli yapmakla ilgili.

Alışkanlık 1: Daha az topla

Korunması en ucuz veri, hiç toplamadığın veridir. Bir şeyi korumadan önce, listeyi küçült.

Az önce yaptığın listenin üzerinden geç ve her madde için sor: bunu kullanıyor muyum? Koçun uygulaması, kayıt sırasında doğum tarihi istiyordu çünkü yapay zeka oluşturucunun kayıt şablonu onu içeriyordu. Hiçbir yerde kullanmadı. Yapay zeka oluşturucuya tek bir cümle — “kayıttan doğum tarihini kaldır ve sütunu sil” — ve hassas verinin tam bir kategorisi yok oldu.

Uygulamaların topladığı ve hiç kullanmadığı yaygın şeyler: doğum tarihleri, telefon numaraları, fiziksel adresler, cinsiyet, “bizi nereden duydunuz”. Bu ay kullanmıyorsan, daha sonra her zaman isteyebilirsin. Sızdırdığını geri alamazsın.

Alışkanlık 2: Kimin neyi görebileceğini kontrol et

Bu sorunun iki versiyonu var ve ikisine de ihtiyacın var.

Uygulamanın içinde: bir kullanıcı başka bir kullanıcının verisini görebiliyor mu? Uygulamanda müşteriler ve koçlar varsa, A müşterisi hiçbir zaman B müşterisinin notlarını görebiliyor mu? Yapay zeka ile geliştirdiğin uygulamada kullanıcı izinleri hakkında koca bir rehber yazdık, ama kısa versiyonu şu: kuralı yapay zeka oluşturucuna sade bir dille anlat (“bir koç yalnızca kendi müşterilerini görür; müşteriler yalnızca kendilerini görür”) ve sonra kendin test et, iki hesapla. Bir kullanıcı olarak giriş yap, tıklayarak başka bir kullanıcının verisine ulaşmaya çalış. Beş dakika, iki test hesabı. Bu tek test, küçük uygulamalardaki en yaygın sızıntıyı yakalar.

Uygulamanın dışında: veritabanının kendisini kim görebiliyor? O da sensin, yapay zeka uygulama oluşturucu platformun ve giriş bilgilerini paylaştığın herkes. Bu da bizi sorulara getiriyor.

Alışkanlık 3: Oluşturucuna şu beş soruyu sor

Cevapları derinlemesine anlamana gerek yok. Sorman gerek ve cevapların kendinden emin “evet”ler olması gerek. Bunları yapay zeka uygulama oluşturucuna tek tek yapıştır:

  1. “Kullanıcı şifreleri özetlenerek (hashed) mi saklanıyor, yoksa herkes okuyabiliyor mu?” Tek kabul edilebilir cevap, “özetlendi” (hashed) kelimesini içerir. Uygulaman şifreleri herkesin okuyabileceği şekilde saklıyorsa, bugün düzelt — genellikle tek komutluk bir düzeltmedir ve çoğu modern oluşturucu bunu varsayılan olarak doğru yapar.
  2. “Uygulamaya bağlantı şifreli mi (HTTPS)?” Kendi tarayıcında asma kilidi ara. Uygulamanın adresi https:// ile başlıyorsa, bu konuda işin bitti.
  3. “Birisi veritabanı dosyasını ele geçirse, hassas alanları okuyabilir mi?” Bu, beklemedeki şifreleme (encryption at rest) ile ilgili. Çoğu barındırma platformu bunu otomatik olarak halleder — yine de sor ve cevabı yaz.
  4. “Hangi üçüncü taraf hizmetleri kullanıcı verisi alıyor?” E-posta araçları, analiz, ödeme işlemcileri. Onları kaldırmıyorsun — listeni tamamlıyorsun, çünkü kullanıcılarının verisini tutan her hizmet, sorumluluk yüzeyinin bir parçasıdır.
  5. “Bir yedek var mı ve ona kim erişebiliyor?” Yedekler, verinin kopyalarıdır ve kopyalar da korunmaya ihtiyaç duyar. (Hiç yedek kurmadıysan, buradan başla.)

Cevapları bir belgeye kaydet. O belge, güvenlik duruşunun başlangıcıdır ve bir müşteri — ya da bir müşterinin avukatı — ilk kez sorduğunda var olduğuna sevineceksin.

Biri “verimi sil” dediğinde

Eninde sonunda biri diyecek ve çoğu yerdeki yasa (Avrupa’da GDPR, başka yerlerde benzer kurallar) bunu gerçekten yapmak zorunda olduğunu söyler. Cevabının ne olacağına şimdi karar ver:

  • Bir kullanıcıyı ve onunla bağlantılı her şeyi silebiliyor musun? Yapay zeka oluşturucundan bunu eklemesini iste — “bir kullanıcıyı ve tüm verilerini silen bir yönetici eylemi oluştur” — daha bir son tarih baskısı altında ihtiyaç duymadan.
  • Onları uygulamada silmek, e-posta aracından ve analizden de kaldırıyor mu? 4. sorudaki listeni kontrol et.
  • Yedekler bir süre daha onları içerecek. Bu normaldir ve genellikle sorun değildir — sadece bunu bil ki dürüstçe söyleyebilesin.

Bir silme isteğini, hazırlandığın için bir günde yanıtlamak profesyonel görünür. İki hafta boyunca telaşlanmak ise tam olarak göründüğü gibi görünür.

Sade dilli gizlilik sayfasını yaz

Şimdilik 4.000 kelimelik üretilmiş hukuk jargonunu atla. Beş dürüst cümle yaz: ne topladığın, neden, başka kimin dokunduğu (e-posta aracın, ödeme işlemcin), ne kadar süre tuttuğun ve silme talebinin nasıl yapılacağı. Onu /privacy adresine koy ve kayıt sayfandan bağla.

Bu hukuki tavsiye değildir ve gerçekten hassas veriler işliyorsan — sağlık, çocuklar, finans — bir avukatla bir saatlik görüşmeye para harca. Ama açık, dürüst bir sayfa, kimsenin okuyamadığı etkileyici görünen bir sayfayı yener ve onu yazmak, kendi cevaplarını gerçekten bilmeye seni zorlar.

Çıta korktuğundan daha düşük, ama sıfırdan yüksek

Ulus-devletlere karşı savunma yapmıyorsun. Sıkıcı, yaygın hatalara karşı savunma yapıyorsun: kimsenin ihtiyaç duymadığı, geride kalmış bir veri alanı, kimsenin test etmediği bir izin kuralı, birinin özetlemeyi (hash) unuttuğu bir şifre tablosu. Kullanıcı verilerini bu düzeyde korumak uzmanlık gerektiren bir beceri değildir — bu hataların her biri, sade dilli bir komut ve beş dakikalık bir testle düzeltilebilir.

Baştaki koç bunların hepsini bir öğleden sonrada yaptı: kullanılmayan iki alanı sildi, iki hesaplı testi çalıştırdı (ve bir sızıntı yakaladı — müşteriler bir açılır menüde birbirlerinin adlarını görebiliyordu), beş soruyu sordu, gizlilik sayfasını yazdı. Uygulaması sonrasında hiç farklı görünmedi. Ama arkadaşı “bu şey müşteri notlarım için güvenli mi?” diye sorduğunda, gerçek bir cevabı vardı.

O öğleden sonrayı ayır. Kullanıcıların sana verilerini güvenerek verdi — onu korumak işte böyle bir şeydir.