Timnit Gebru’dan ilham alan AI hesap verebilirlik kontrol listesi: veriyi, sınırlamaları ve olası kullanıcı zararlarını belgeleyin ki bir özelliğin gönderilip gönderilmeyeceğine karar verebilesiniz.
Bir zamanlar AI özelliği geliştirmek çoğunlukla teknik bir soruydu: modeli çalıştırabilir miyiz? Artık daha zor soru, bunu dağıtmalı mıyız ve hangi sınırlamaları koymalıyız?
Gerçek kullanıcılar AI çıktısına güvendikçe, küçük sorunlar gerçek maliyetlere dönüşür: yanlış kararlar, kafası karışan müşteriler, gizlilik sızıntıları veya adaletsiz muamele.
AI hesap verebilirlik bir ruh hali ya da söz değil. Yazılı dokümantasyon artı birilerinin sahip olduğu net karar demektir. Hangi veriyi kullandığınızı, sistemin neleri yapamadığını ve başarısız olduğunda ne yapacağınızı gösteremiyorsanız hesap verebilirliğiniz yoktur. Sadece umut vardır.
Bu, lansmandan hemen önce en çok önem kazanır; o aşamada dokümantasyonu isteğe bağlı görmek cazip gelir. Dokümantasyonsuz gönderim sonradan pahalı sürprizler üretir: cevaplanmamış destek talepleri, kızgın kullanıcılar, ürün geri çekmeleri ve içte parmak gösterme.
Basit bir hesap verebilirlik kontrol listesi somut cevapları zorunlu kılar:
Amaç teori değil. Temel şeyleri (veri, sınırlar, riskler) belgeleyip, hızlı olsanız bile daha sonra savunabileceğiniz bir karar vermektir.
Timnit Gebru, AI hesap verebilirliği sahnesindeki en çok atıf yapılan seslerden biri çünkü birçok ekibin atladığı basit bir fikri zorladı: sadece "inşa edebilir miyiz?" demek yeterli değil. Ayrıca "bunu dağıtmalı mıyız, kim zarar görebilir ve nasıl fark ederiz?" diye sormalısınız.
Bu kaymanın büyük bir parçası, AI sistemlerini başkaları için anlaşılır kılmaktır. Sadece modeli eğiten mühendislere değil, inceleyicilere, ürün yöneticilerine, destek ekiplerine ve kullanıcılara da. Amaç, sistemin ne yapması gerektiğini, hangi verilerin onu şekillendirdiğini, nerede başarısız olduğunu ve risklerin gerçek hayatta nasıl göründüğünü yazılı hale getirmektir.
Bu görünürlüğü somut yapan iki pratik belge popüler oldu:
Ürün ekipleri için bu bir kağıt işi değildir. Dokümantasyon kanıttır. Birisi "Neden bu özelliği gönderdik?" veya "Neden bu hata modunu yakalayamadınız?" diye sorduğunda işaret edebileceğiniz bir şeye ihtiyacınız vardır: ne ölçtüğünüz, neyi desteklemediğiniz ve hangi korumaları eklediğiniz.
Somut bir örnek: destek aracına bir AI özet butonu eklerseniz, model notları bunun hassas konularda test edilip edilmediğini, belirsizlikle nasıl başa çıktığını ve insan inceleme adımının ne olduğunu söylemelidir. Bu, belirsiz bir endişeyi savunulabilir ve geliştirilebilir bir karara dönüştürür.
Bir AI özelliği, bir modelin çıktısının insanların ne gördüğünü, ne yapabildiğini veya nasıl muamele gördüğünü değiştirebildiği ürün parçasıdır. Eğer çıktı bir kararı etkiliyorsa, küçük bile olsa bunu gerçek sonuçları olan bir özellik gibi ele alın.
Yaygın türler arasında özetleme, sıralama, öneriler, moderasyon ve puanlama (risk, dolandırıcılık, kalite, uygunluk, öncelik) bulunur.
İşler ters gittiğinde etki, düğmeye tıklayan kişiyi aşabilir. Zarar görebilecek kişiler arasında son kullanıcılar, kullanıcı olmayanlar (bahsedilen veya profillendirilen kişiler), destek personeli ve moderatörler, yükleniciler ve inceleyiciler ile özelliği eğitmek veya değerlendirmek için kullanılan veri konuları bulunur.
Hataları zarardan ayırmak yardımcı olur. Hata, modelin yanlış olmasıdır: kötü bir özet, yanlış bir bayrak veya alakasız bir öneri. Zarar, o hatanın gerçek dünyada neden olduğu sonuçtur: para kaybı, haksız erişim, itibar hasarı veya güvenlik riskleri. Örneğin, bir destek asistanının uydurduğu bir iade politikası hata; zararı ise müşterinin buna göre bir satın alma yapıp reddedilmesi ya da destek temsilcisinin öfke dolu bir talep ile uğraşmak zorunda kalmasıdır.
Zararlar gruplar ve bağlamlar arasında dengesiz olabilir. Bir moderasyon modeli çoğu kullanıcı için "iyi çalışıyor" gibi görünse de argo veya lehçeyi sürekli yanlış okuyarak bir topluluk için daha fazla içerik kaldırmaya yol açabilir. Bir sıralama modeli küçük satıcıları gözden kaçırabilir, ancak büyük markalara özgü kalıplara uyanları öne çıkarabilir.
Koder.ai gibi sohbet odaklı bir oluşturucuyla AI özellikleri geliştiriyorsanız hız gerçek bir avantajtır, ama hesap verebilirlik işi aynı kalır. Modelin nerede başarısız olabileceğini ve başarısız olduğunda kimlerin bedel ödediğini açıkça belirtmeniz gerekir.
Özelliği göndermeden önce küçük bir belge setiyle cevaplamanız gereken soru: ne inşa ettik, kim için ve neler ters gidebilir? Kısa tutun, ama her iddiayı test edilebilir yapın.
Yayın öncesi yazılı halde olması gereken asgari set:
"Belgelenmiş" olmak "anlaşılmış" olmakla aynı değildir. Hiç kimsenin okumadığı bir belge sadece bir dosyadır. Ekip dışından bir kişinin belgeyi okuyup sade dilde: "Sınırlamaları ve kullanıcı etkisini anlıyorum" yazısını imzalaması gerekir. Eğer belgeyi geri özetleyemiyorlarsa hazır değilsiniz demektir.
Dokümanları güncel tutmak için tek bir sahip atayın (genellikle özelliğin ürün sahibi, hukuk değil). Bir tempo belirleyin (her sürümde veya her ay), ve herhangi bir olaydan sonra derhal güncelleme yapın.
Ton dürüst ve somut olsun. "Yüksek doğruluk" gibi iddialardan kaçının; eğer kullanacaksanız test setini, metriği ve düzeltmediğiniz hata vakalarını belirtin.
İyi veri notları iki işi yapar: kullanıcılar bulmadan önce hataları öngörmenize yardımcı olur ve gelecekteki ekip üyelerine sistemi neden güvenilir veya güvensiz saymaları gerektiğini açıklar.
Detay düzeyini "zor sorulara 10 dakikada cevap verecek kadar" tutun. Bir tez yazmıyorsunuz. Bir hata raporu, gizlilik incelemesi veya müşteri şikâyeti sırasında ihtiyaç duyulacak gerçekleri yazıyorsunuz.
Basit bir veri envanteriyle başlayın. Her veri kümesi (günlükler, geribildirim, üçüncü taraf kaynaklar dahil) için kaynağını ve kimin kontrol ettiğini, ne zaman toplandığını ve ne sıklıkla güncellendiğini, hangi ürün davranışını desteklediğini, hangi rıza ve gizlilik sınırlarının uygulandığını ve nasıl etiketlendiğini veya temizlendiğini kaydedin.
Temsiliyet ayrı bir satırı hak eder. Eksik olanı isimlendirin: bölgeler, diller, cihazlar, erişilebilirlik ihtiyaçları, kullanıcı türleri veya uç durumlar. Basitçe yazın: "çoğunlukla ABD İngilizcesi mobil kullanıcılar" veya "küçük işletmelerden az örnek" gibi.
İnsan etiketleme kullanıyorsanız, etiketleyicinin bağlamını (uzman mı kalabalık iş gücü mü), gördükleri talimatları ve nerede anlaşmazlık çıktığını belgeleyin. Anlaşmazlık saklanacak bir kusur değildir; tasarlanması gereken bir uyarı işaretidir.
Sınırlamalar bölümü, "demo çalıştı"dan "bu özellik güvenle neyi yapabilir" aşamasına geçtiğiniz yerdir. Sadece mutlu yolu yazarsanız, kullanıcılar kenarları sizin için bulur.
Modelin görevini bir cümleyle yazıp sonra ne için olmadığına dair ifadeler ekleyin. "Ortak sorular için kısa cevaplar taslaklamak" ile "iade kararları vermek" veya "dolandırıcılığı tespit etmek" çok farklıdır. Bu sınır UI metni, yükseltme kuralları ve destek eğitimi gibi sonraki kararları kolaylaştırır.
Bilinen hata desenlerini sade dilde yakalayın. İyi bir sınırlamalar bölümü genellikle hangi girdilerin onu şaşırttığını (belirsiz istekler, eksik bağlam, karışık diller), hangi tonu yanlış okuduğunu (ironi, şaka, öfke), nadir durumlarda neyi kötü yaptığını (nadir terimler, alışılmadık ürünler) ve kasten nasıl kırılabileceğini (prompt injection, özel veriyi açığa çıkarmaya yönelik yemleme) kapsar.
Operasyonel kısıtları ekleyin çünkü bunlar kullanıcı deneyimini ve güvenliği değiştirir. Gecikme hedeflerini, maliyet sınırlarını ve onlara ulaşıldığında ne olduğunu (zaman aşımı, daha kısa yanıtlar, daha az yeniden deneme) yazın. Bağlam penceresi limitlerini (önceki mesajları unutabilir) ve bağımlılık değişikliklerini (LLM sağlayıcı değişimi veya model yükseltmesi davranışı değiştirebilir) not edin.
Sonra üründe tekrar kullanabileceğiniz tek bir uyarı hazırlayın:
"AI tarafından üretilen yanıtlar eksik veya yanlış olabilir. Hukuki, tıbbi veya finansal kararlar için kullanmayın. Faturalama, iadeler veya hesap erişimiyle ilgiliyse destek ile iletişime geçin."
Model, prompt veya politika değiştiğinde bu notu güncelleyin.
Zarar değerlendirmesi soyut bir etik tartışması değil. Bu, eğer bu özellik yanlışsa kim zarar görebilir, nasıl ve lansmandan önce ve sonra ne yapacağımızı söyleyen kısa bir belgedir.
Başlaması için geniş kategoriler kullanın ki göreceğiniz bariz sorunları kaçırmayın: güvenlik, ayrımcılık, gizlilik, aldatma ve güvenilirlik.
Sonra her zararı gerçek bir duruma dönüştürün. Her kategori için bir veya iki somut hikâye yazın: kullanıcı kim, ne soruyor, model ne üretebilir ve kullanıcı bundan dolayı ne yapabilir. Anahtar nokta eylem zinciridir. Yanlış bir cevap sinir bozucudur. Bir yanlış cevap tıbbi karar, para transferi veya politika değişikliğini tetikliyorsa çok daha büyük bir meseledir.
Önceliklendirmek için basit ölçekler kullanın. Her senaryo için şiddeti (düşük, orta, yüksek) ve olasılığı (düşük, orta, yüksek) işaretleyin. Mükemmel sayılara ihtiyacınız yok. Şu an neyin üzerinde çalışılması gerektiği konusunda ortak bir görüşe ihtiyacınız var.
Son olarak sahipler atayın. İsimsiz bir azaltma önlemi azaltma değildir. Her senaryo için lansmandan önceki azaltmayı (guardrail’lar, UX uyarıları, engellenen konular, kayıt), lansmandan sonraki azaltmayı (destek oyun kitabı, izleme, geri alma tetikleyicisi) ve kimlerin sorumlu olduğunu yazın.
Gate’leme, "inşa edebiliriz"den "göndermeliyiz"e geçiş yöntemidir. Bunu bir dizi çıkış gibi düşünün: temel maddeler yazılmadan, gözden geçirilip test edilmeden bir sonraki çıkışı geçmeyin.
Amacı ve etkilediği kararı yazın. Kim kullandığını, ne karar verdiğini ve çıktı yanlışsa ne olduğunu açıkça belirtin.
Veri ve sınırlama notlarını erken taslağa alın. Bunu UI cilalanmadan önce yapın; özellik hâlâ kolayca şekillendirilebilir.
Gerçekçi, uç ve hassas vakalarda test edin. Dağınık metin, argo, farklı diller, uzun konuşmalar ve belirsiz istekleri kullanın. Yüksek riskli birkaç vaka ekleyin (fatura ihtilafları, hesap erişimi, tıbbi veya hukuki sorular) — özellik onlar için olmasa bile kullanıcılar deneyecektir.
Kullanıcı mesajlaşması, yedekler ve yükseltme süreçleri ekleyin. Model reddettiğinde, emin olmadığında veya kötü performans gösterdiğinde kullanıcıya ne gösterileceğine karar verin. Güvenli bir varsayılan sağlayın (örneğin "bir insana sor") ve kötü bir yanıtı bildirmeyi kolaylaştırın.
İzleme, olaylar ve geri alma tanımlayın. İzleyeceğiniz sinyalleri seçin (şikâyetler, geri alma oranı, işaretlenen çıktılar), kimin uyarılacağını ve "özelliği durdurma"nın ne anlama geldiğini belirleyin.
Her adım zor geliyorsa, bu sürümdeki gerçek riskin nerede olduğunu size söyler.
Güveni baltalamanın en hızlı yolu laboratuvardaki iyi bir skoru gerçek dünyada güvenli olduğunuzun kanıtıymış gibi görmektir. Kıyaslamalar yardımcı olur ama insanların özelliği nasıl zorlayacağını, yanlış anlayacağını veya ona nasıl güveneceğini göstermez.
Başka bir yaygın hata belirsizliği gizlemektir. Sisteminiz her zaman aynı güvenle konuşuyorsa kullanıcılar bunun her zaman doğru olduğunu varsayar. Basit bir "emin değil" yolu veya cevabın hangi kaynağa dayandığını kısaca gösteren bir not, insanların sarsak çıktıyı gerçek kabul etmesini engelleyebilir.
Ekipler genellikle sadece kendi alışkanlıklarıyla test eder. Dahili promptlar kibar ve öngörülebilirdir. Gerçek kullanıcılar yorgun, aceleci ve yaratıcıdır. Dağınık metin yapıştırırlar, takip soruları sorarlar veya modeli kuralları bozması için zorlarlar.
Tekrar eden beş hata:
Pratik bir düzeltme, hesap verebilirliği inşa sürecinin bir parçası yapmaktır. Kontrol listesini spesifikasyonun içinde tutun ve gönderim öncesi şunu zorunlu kılın: hangi veriyi kullandınız, neye takılıyor, kim zarar görebilir ve yanlış gittiğinde ne yapacaksınız.
Somut örnek: bir uygulama oluşturucu içinde AI asistanı dağıtırsanız, onu belirsiz isteklerle ("Airbnb gibi yap"), çelişkili gereksinimlerle ve hassas içerikle test edin. Sonra net bir geri alma planı belirleyin (anlık yedekler, versiyonlama, hızlı devre dışı bırakma) ki kullanıcılar zararı raporladığında hızlıca müdahale edebilesiniz.
Bu bölümü ürün spesifikasyonunuza yapıştırın ve göndermeden önce doldurun. Kısa tutun ama her cevap spesifik olsun. Her risk için bir sahip atayın.
### 1) Amaç ve etkilenen kişiler
- Özellik adı:
- AI hangi karar veya işlemi destekliyor (bir cümle):
- Kim kullanıyor:
- Kullanmadan etkilenenler kimler (müşteriler, çalışanlar, üçüncü kişiler):
- "İyi" bir sonuç nasıl görünür:
### 2) Kullanılan veriler (eğitim, ayarlama, getirme, günlükler)
- Veri kaynakları (nereden geldi ve neden izinli):
- Neleri hariç tuttunuz (ve neden):
- Hassas veriler (KİŞİSEL, sağlık, finans, çocuklar):
- Veri saklama süresi ve silme planı:
- Güvenlik ve erişim kontrolleri:
### 3) Sınırlar ve "kullanılmaması gereken" alanlar
- Bilinen hata modları (3–5 somut örnek verin):
- Desteklenen ve desteklenmeyen diller:
- Reddetmesi gereken girdiler (veya bir insana yönlendirme):
- Hangi durumlarda kullanılmamalı (hukuki, tıbbi, işe alım vb.):
### 4) Kullanıcı zarar değerlendirmesi
- İlk 5 zarar (sıralı):
- Her zararı için azaltma:
- Her azaltma için sahibi (isim + ekip):
- Kullanıcılara ne söyleyeceksiniz (uyarılar, güven işaretleri, atıflar):
### 5) Yayın sonrası operasyon
- İzleme sinyalleri (kalite, şikayetler, önyargı işaretleri, maliyet dalgalanmaları):
- İnsan inceleme yolu (ne zaman ve nasıl yükseltme yapılır):
- Geri alma tetikleyicisi (kesin eşik veya koşul):
- Geri dönebileceğiniz anlık yedek/versiyon:
Gönderime tam da hemen önce başlayın; gerçek kullanıcılar çıktılara güvenmeye başladığında bu çalışmalar önem kazanır.
Eğer lansmandan sonra beklerseniz, olayları belgelemekle yetinirsiniz; önlemek yerine düzeltme zamanı bulmaya çalışırsınız ve guardrail eklemek için daha az seçeneğiniz olur.
Hesap verebilirlik, yazılı kararları gösterebilmeniz demektir:
Bu kararları ve onlara sahip bir kişiyi gösterebiliyorsanız hesap verebilirlik vardır.
Model çıktısının insanların ne gördüğünü, ne yaptığını veya nasıl muamele gördüğünü değiştirebildiği her özellik.
Özetler veya önerilen yanıtlar gibi "küçük" görünen özellikler bile birine bu çıktılar üzerinden işlem yapma imkânı veriyorsa (müşteriye gönderme, isteği reddetme, öncelik değiştirme vb.), gerçek risk taşıyan bir ürün yüzeyi gibi muamele görün.
Yayın öncesi yazılı olarak bulunması gereken asgari set:
Zor soruları kısa sürede cevaplayacak kadar ayrıntı kaydedin:
Eksik kapsama alanını açıkça yazın (örneğin: “çoğunlukla ABD İngilizcesi; küçük satıcılardan az örnek”).
Bir cümleyle modelin işini yazın: ne yaptığı. Sonra “kapsam dışı” sınırlarını ekleyin.
Kısa bir liste halinde şunları dahil edin:
Hata ile zararı ayırın:
Sonra kısa senaryolar yazın: kullanıcı kim, ne soruyor, model ne üretebilir ve bunun sonucunda kullanıcı ne yapar. Her senaryoyu şiddet ve olasılık açısından derecelendirin ve her azaltma için bir sahip atayın.
Prototipten yayınlamaya geçiş için kapılar:
Her kapı zor geliyorsa, genellikle riskin olduğu yerdir.
Yaygın hatalar:
Pratik çözüm: kontrol listesini ürün spesifikasyonunun içinde tutun ve gönderim öncesi imza gerektirin.
Hız sorumluluğu ortadan kaldırmaz. Koder.ai gibi sohbet tabanlı bir araçla hızlı inşa ediyorsanız aynı disiplini koruyun:
Hızlı yineleme iyidir; yeter ki ne gönderdiğinizi ve bozulduğunda nasıl davranacağınızı açıklayabiliyor olun.
Kısa tutun ama her iddia test edilebilir olsun.
3–5 somut kötü çıktı örneği ekleyin ki teknik olmayanlar sınırları anlasın.