AIPA: Yapay zekâ girişimlerinde ürün, güven ve toplumsal etkiyi birlikte düşünmek

Yapay zekâ kullanan bir ürünün dikkat çekici bir gösterim yapmasıyla gerçek bir iş ihtiyacını güvenilir biçimde karşılaması arasında önemli bir mesafe bulunabilir. Kullanıcıların beklentisi, verinin niteliği, hata durumlarının etkisi ve kurum içindeki karar düzeni bu mesafeyi belirler. Bu nedenle yapay zekâ girişimciliği yalnızca model seçimine indirgenemez. Ürün geliştirme ekibinin farklı uzmanlıklarla konuşabilmesi ve kendi varsayımlarını sorgulayabilmesi gerekir.

Yapay Zekâ Politikaları Derneği, kısa adıyla AIPA, Orion TEKMER paydaşları arasında yer almaktadır. Aşağıdaki kurumsal bilgiler resmî kaynaklara dayanır. Ürün tasarımı ve iş birliği hazırlığına ilişkin bölümler ise Orion TEKMER editör ekibinin değerlendirmeleridir. Bunlar AIPA tarafından verilmiş bir sertifika, teknik denetim, yatırım veya özel danışmanlık taahhüdü olarak sunulmamaktadır.

AIPA'nın çalışma çerçevesi

AIPA, resmî hakkımızda sayfasına göre Şubat 2021'de kurulmuş bağımsız bir dernektir. Kurum, yapay zekâ konusunda farkındalık oluşturmayı ve alanın gelişimi için farklı kesimlerin bir araya gelebildiği bir zemin sağlamayı amaçlamaktadır. Akademi, sanayi ve kamu arasındaki etkileşim, resmî tanıtımında vurgulanan başlıklardandır. Bu çerçeve, yapay zekâyı hem teknoloji hem de toplumsal uygulama alanı olarak ele alan bir yaklaşımı göstermektedir.

Derneğin araştırmalar sayfasında toplumda ve işletmelerde yapay zekâ algısı, eğitim, medya ve dijitalleşme gibi konulara ilişkin çalışmalar listelenmektedir. Resmî ana sayfa ayrıca araştırmalar, kitaplar, politika belgeleri ve söyleşi içeriklerine erişim sunmaktadır. Bu yayın başlıklarının bulunması, her araştırmanın bütün sektörleri temsil ettiği veya her bulgunun bugünkü kullanıcı davranışını açıkladığı anlamına gelmez; kaynaklar kendi yöntem ve tarihleriyle değerlendirilmelidir.

Bir girişim açısından bu kurumsal odağın önemi, ürüne yalnızca geliştiricinin gözünden bakmamayı hatırlatmasıdır. Aynı özellik bir kullanıcı için kolaylık, başka biri için belirsizlik yaratabilir. Teknolojinin ne yapabildiği kadar, insanların onu hangi koşullarda kullanmak istediği de ürün kararlarını etkiler. AIPA'nın çalışma alanını araştırmak, bu tür soruları teknik yol haritasıyla birlikte ele almak isteyen ekipler için anlamlı bir başlangıç olabilir.

İlk soru model değil, çözülecek iş olmalı

Bir ürün fikrini “yapay zekâ kullanacağız” cümlesiyle başlatmak, çözümün gerçek ihtiyacını gölgede bırakabilir. Daha yararlı başlangıç, kullanıcının bugün hangi işi nasıl yaptığını tarif etmektir. Bilgi mi arıyor, belge mi karşılaştırıyor, tekrar eden bir talebi mi sınıflandırıyor, yoksa karar öncesinde seçenek mi hazırlıyor? Bu işler benzer teknoloji bileşenleri kullanabilse de başarı ölçütleri ve hata sonuçları farklıdır.

Girişim, hedef işin başlangıcını ve bitişini açıkça belirleyebilir. Örneğin “müşteri hizmetlerini iyileştirmek” yerine “destek çalışanının yanıt hazırlamadan önce ilgili belgeyi bulmasına yardımcı olmak” daha sınanabilir bir kapsam oluşturur. Kullanıcıya kalan sorumluluk ve sistemin üstlendiği adım ayrılır. Böylece ürünün yanlış çıktısı bütün müşteri ilişkisini etkileyen bir işlem mi, yoksa çalışanın kontrol edeceği bir öneri mi üretiyor sorusu yanıtlanabilir.

İlk çözümün mutlaka en karmaşık yöntem olması gerekmez. Kurallı bir filtre, daha iyi bir arama düzeni veya form tasarımındaki iyileştirme aynı ihtiyacın bir kısmını karşılayabilir. Ekip alternatifleri karşılaştırdığında yapay zekânın hangi noktada ek değer oluşturduğunu daha dürüst biçimde anlatabilir. Bu yaklaşım teknolojik iddiayı küçültmez; ürünün gerekçesini güçlendirir. Girişim, “hangi modeli kullanıyoruz?” sorusuna geçmeden önce “hangi işin sonucunu nasıl iyileştireceğiz?” sorusunu yanıtlamış olur.

Veri hazırlığı, ürün kararlarının görünmeyen bölümüdür

Yapay zekâ projelerinde veri bazen hazır bir kaynak gibi düşünülür. Oysa verinin bulunmasıyla amaç için kullanılabilir olması aynı şey değildir. Kayıtların güncelliği, anlamı, tutarlılığı, erişim koşulları ve temsil ettiği kullanıcı grupları farklı sorunlar doğurabilir. Ürün ekibi bunları tanımlamadan başarılı örnekler seçerse gerçek kullanımda karşılaşacağı çeşitliliği gözden kaçırabilir.

Basit bir veri envanteri hazırlanabilir. Her veri kaynağı için sahibi, kullanım amacı, güncelleme biçimi ve bilinen eksiklikler yazılır. Kişisel veya gizli bilgilerin bulunup bulunmadığı ayrıca değerlendirilir. Veriyi bir sisteme yükleyebilmek, onu her amaçla kullanma yetkisi olduğu anlamına gelmez. Somut kullanımın hukuki ve sözleşmesel boyutu gerektiğinde yetkin uzmanlarla ele alınmalıdır. Bu yazı belirli bir veri işleme faaliyetinin uygunluğuna ilişkin görüş vermemektedir.

Teknik hazırlıkta da örnek seçimine dikkat etmek gerekir. Yalnızca düzgün biçimlendirilmiş belgelerle çalışan bir prototip, eksik alanlı veya eski sürümlü belgeler geldiğinde farklı davranabilir. Ekip kolay örneklerin yanına zor, belirsiz ve kapsam dışı örnekler ekleyebilir. Sistemin yanıt vermemesi gereken durumlar da bu çalışma içinde tanımlanır. Böylece veri hazırlığı, modeli beslemek için dosya biriktirme işi olmaktan çıkar; ürünün hangi koşullarda kullanılabileceğini açıklayan bir bilgi tabanına dönüşür. Bu taban daha sonra değerlendirme, müşteri iletişimi ve destek süreçlerini de besler.

Başarıyı gösterimden ayrı ölçmek

Bir ürün gösteriminde doğru yanıt görmek, sistemin düzenli kullanıma hazır olduğunu tek başına göstermez. Gösterimi hazırlayan ekip örnekleri tanıyor olabilir; gerçek kullanıcı ise farklı sözcükler, eksik bilgiler veya beklenmedik talepler getirebilir. Bu nedenle değerlendirme, sunum senaryosundan ayrı hazırlanmalıdır. Girişim önce hangi çıktıların kabul edilebilir olduğunu ve hangi hataların daha ciddi sonuç doğurduğunu belirlemelidir.

Örneğin belge arama aracında, ilgili içeriğin bulunmasıyla içeriğin yanlış yorumlanması ayrı değerlendirilir. Yanıtın hızlı gelmesi, dayandığı belgenin eski olmasını telafi etmez. Kullanıcıya yanlış bir kesinlik hissi verilmesi de yalnızca doğruluk oranıyla görünmeyebilir. Ekip, uzman değerlendirmesi, kullanıcı geri bildirimi ve iş akışı ölçümlerini birlikte düşünmelidir. Tek bir puan bütün ürün davranışını açıklamak zorunda değildir.

Değerlendirme seti hazırlanırken ürünün en yaygın işleri kadar en riskli yanlış anlamaları da temsil edilmelidir. Sonuçlar sürümler arasında karşılaştırılabilir biçimde saklanabilir. Başarılı ortalama, belirli bir kullanıcı grubunun sürekli zorlandığı gerçeğini gizlememelidir. Henüz güvenilir ölçüm yoksa pazarlamada kesin performans iddiaları kullanılmamalıdır. “İlk denemelerde gözlendi” ile “düzenli kullanımda doğrulandı” ifadeleri farklı kanıt düzeylerini anlatır. Bu ayrım, hem ürünün gelişimini hem müşterinin beklentisini daha sağlıklı yönetmeye yardımcı olur.

İnsan denetimini gerçek bir iş adımı olarak tasarlamak

“Son kararı insan verir” ifadesi tek başına yeterli bir tasarım değildir. Kararı verecek kişinin hangi bilgiyi göreceği, ne kadar zamanı olduğu ve hatayı nasıl fark edeceği önemlidir. Kullanıcı sistemin önerisini kontrol edecek kaynaklara erişemiyorsa, denetim yalnızca bir onay düğmesine dönüşebilir. Bu nedenle insan denetimi arayüz, görev dağılımı ve eğitimle birlikte düşünülmelidir.

Ürün ekibi, kullanıcının öneriyi kabul etme, değiştirme, reddetme ve ilgili birime yönlendirme yollarını ayrı ele alabilir. Kaynak gösterimi, belirsizliğin açıklanması ve kapsam dışı taleplerin fark edilmesi bu kararları destekleyebilir. Ancak her üründe aynı arayüz çözümü uygun olmayacaktır. Bir içerik önerisiyle bir iş sürecini tetikleyen otomasyonun etkileri farklıdır. Kontrolün ayrıntısı, yanlış işlemin geri alınabilirliği ve kullanıcı üzerindeki sonuçlarıyla ilişkilendirilmelidir.

Denetim yükünün kime aktarıldığı da sorulmalıdır. Sistem görünürde zaman kazandırırken çalışanların sürekli hatalı önerileri düzeltmesini gerektiriyorsa beklenen fayda gerçekleşmeyebilir. Pilot sırasında yalnızca otomatik üretilen çıktı sayısı değil, düzeltmeye ayrılan zaman ve kullanıcının güven düzeyi de incelenebilir. Kullanıcı itirazlarının kaydedilmesi ürün geliştirme için değerli veri oluşturabilir. Böylece insan denetimi, sorumluluğu kullanıcıya devreden bir cümle yerine, gerçekten çalıştığı gözlenebilen bir ürün özelliği hâline gelir.

Algı araştırmalarını kullanıcı araştırmasının yerine koymamak

AIPA'nın araştırma başlıkları, yapay zekânın toplum ve işletmeler tarafından nasıl algılandığını incelemek isteyen girişimler için bir okuma alanı sunmaktadır. Bu kaynakları değerlendirirken araştırmanın tarihi, katılımcı profili, soruların kapsamı ve yöntemi birlikte okunmalıdır. Bir araştırmada teknolojiye yönelik olumlu tutum bulunması, belirli bir ürünün satın alınacağını göstermez. Genel farkındalıkla ödeme isteği arasında ayrıca araştırılması gereken sorular vardır.

Girişim bu tür yayınlardan hareketle kendi görüşme sorularını geliştirebilir. Kullanıcı teknolojinin adını biliyor mu, hangi durumda kullanmayı düşünüyor, hangi sonucu kontrol etmek istiyor? “Yapay zekâya güveniyor musunuz?” gibi geniş bir sorunun yanına somut senaryolar eklemek daha açıklayıcı olabilir. Aynı kişi toplantı notlarının özetlenmesini yararlı bulurken müşteri adına işlem yapılmasını uygun görmeyebilir. Tercihlerin bağlam içinde anlaşılması ürün kapsamını etkiler.

Araştırmadan çıkan değerlendirmeler ekip içinde kesin yargılara dönüştürülmemelidir. Kullanıcıların bir özelliği istemediği görüldüğünde sorun teknolojiye karşı olmaları değil, ürünün açıklaması veya mevcut işlerine uyumu olabilir. Buna karşılık olumlu geri bildirim de düzenli kullanım garantisi değildir. Küçük ve açık amaçlı denemelerle davranış gözlenmelidir. AIPA yayınları bu düşünme sürecini besleyebilir; girişimin kendi hedef kitlesini tanıma sorumluluğunu ortadan kaldırmaz. İki bilgi türü birlikte kullanıldığında genelden somut ürüne daha dikkatli geçiş yapılabilir.

Kurumsal müşteriye değer ve sınırları aynı açıklıkla anlatmak

Kurumsal bir alıcı, ürünün etkileyici özelliklerinin yanında iş sürekliliğini ve sorumluluk paylaşımını da anlamak ister. Veriler nerede işleniyor, sistem çalışmadığında ne oluyor, kullanıcılar hangi yetkilere sahip ve sonuç nasıl kontrol ediliyor? Bu soruların yanıtı yalnızca teknik ekibin hafızasında kalmamalıdır. Satış, destek ve ürün ekiplerinin aynı bilgiyi paylaşması gerekir.

Girişim, teklif dosyasını iş sonucu etrafında yapılandırabilir. Hedeflenen görev, kapsam, kullanım sınırı, değerlendirme yöntemi ve insanın rolü ayrı başlıklar hâlinde yazılır. Henüz ölçülmemiş zaman tasarrufu için kesin oran verilmez. Başka bir müşterinin başarısı kullanılıyorsa bağlamı ve paylaşım izni gözetilir. Bir çözümün belirli bir kurumda denenmiş olması, bütün kurumlarda aynı sonucu üreteceği anlamına gelmez.

Dış hizmet sağlayıcılarına bağımlılık da açıklanması gereken bir konudur. Model veya altyapı değiştiğinde ürün davranışının nasıl değerlendirileceği, maliyetlerin hangi varsayımlara dayandığı ve hizmet kesintisinde hangi sürecin işleyeceği düşünülmelidir. Bu konuların tamamı ilk görüşmede ayrıntılı sözleşmeye dönüşmeyebilir; ancak ekip kendi açık sorularını bilmelidir. Sınırlarını saklamayan bir anlatım, gelişim planının daha gerçekçi konuşulmasını sağlar. Yapay zekâ ürünü, yalnızca bugün ürettiği yanıtla değil, değişiklikleri nasıl yöneteceğiyle de değerlendirilir.

Kurumsal değerlendirmeye hazırlanırken bir örnek vaka dosyası da oluşturulabilir. Varsayımsal bir destek asistanı için doğru belgeyi bulma, eski belgeyi ayırt etme ve yanıt bulunamadığında bunu açıklama ayrı senaryolar olarak yazılır. Her senaryoda kullanıcının beklentisi, sistemin yapması gereken iş ve insanın kontrol edeceği nokta belirtilir. Bu dosya yalnızca başarılı ekran görüntülerinden oluşmaz; ürünün zorlandığı durumları da içerir. Böylece müşteriye sunulan gösterim, ürünün gerçek davranışını daha iyi temsil eder.

Örneğin aynı sorunun iki farklı tarihteki politika belgesiyle yanıtlanması gerektiğinde, hangi belgenin geçerli olduğunun nasıl belirlendiği sorgulanabilir. Sistem bu ayrımı yapamıyorsa arayüzün kullanıcıyı nasıl yönlendireceği düşünülür. Kullanıcıdan bütün belgeleri yeniden okuması bekleniyorsa sağlanan fayda tekrar değerlendirilir. Burada çözüm belirli bir modelin seçilmesiyle sınırlı değildir; belge yönetimi, güncelleme sorumluluğu ve ürün kapsamı birlikte ele alınır. Böyle bir örnek, teknik hata ile iş süreci eksikliğinin birbirine karışmasını azaltabilir.

Vaka dosyasının zaman içinde güncellenmesi de önemlidir. Yeni sürüm eski örneklerde iyi çalışırken farklı kullanıcı ifadelerinde zorlanabilir. Ekip müşteriden gelen sorunları uygun izin ve veri düzeniyle yeni değerlendirme örneklerine dönüştürebilir. Her örneğin neden önemli olduğu yazıldığında testler yalnızca puan üreten bir liste olmaz; ürünün hangi kullanıcı deneyimini korumaya çalıştığını anlatır. Bu birikim, AIPA gibi çok paydaşlı ortamlarda tartışılabilecek somut soruların geliştirilmesine de katkıda bulunabilir.

Çok paydaşlı bir görüşmeye somut katkıyla katılmak

AIPA gibi farklı kesimleri bir araya getirmeyi amaçlayan bir kuruma yaklaşırken, talebin yalnızca görünürlük arayışı olarak kalmaması yararlıdır. Girişim hangi deneyimi paylaşabilir, hangi soruyu tartışmak ister ve kimlerin bakış açısına ihtiyaç duyar? Bu sorulara verilen kısa yanıtlar, bir etkinlik veya çalışma önerisinin değerlendirilmesini kolaylaştırabilir. Kurumun mevcut program ve öncelikleri ayrıca doğrulanmalıdır.

Öneri dosyasında çözülen problem, hedef kullanıcılar, ürünün mevcut aşaması ve tartışılmak istenen konu bulunabilir. Örneğin kullanıcıların yapay zekâ önerisini nasıl kontrol ettiğine ilişkin anonim bir gözlem, genel bir ürün tanıtımından daha verimli konuşma başlatabilir. Ancak müşteri verileri veya görüşme kayıtları izin olmadan paylaşılmamalıdır. Girişimin kendi deneyimi ile bütün sektör adına ileri sürdüğü iddia arasında açık sınır kurulmalıdır.

Orion üzerinden ilerlemek isteyen ekipler AIPA paydaş profilini inceleyebilir. Tamamlayıcı uzmanlıkları araştırmak için paydaş ekosistemi, girişimin genel gelişim çerçevesi için TEKMER rehberi kullanılabilir. İlk görüşmenin beklenen çıktısı belirli bir sorunun netleşmesi veya uygun bir sonraki adımın belirlenmesi olabilir. Etkinlikte konuşma, araştırmaya katılma ya da özel destek alma imkânları kurumun değerlendirmesine bağlıdır; bu yazı bunlardan herhangi birini garanti etmez.

Ürün ekibi için dört haftalık bir değerlendirme çalışması

Aşağıdaki çalışma sırası, AIPA'nın resmî programı değil, girişimlerin kendi içinde uygulayabileceği editoryal bir öneridir. İlk hafta tek bir kullanım senaryosu seçilip mevcut iş akışı çizilebilir. Kullanıcı hangi noktada karar veriyor, neye güveniyor ve hangi işi tekrar yapıyor? Ekip, çözümün tam olarak hangi adımı değiştireceğini yazar. Çok sayıda özelliği aynı anda değerlendirmek yerine tek bir iş üzerinde anlaşmak, sonraki gözlemleri yorumlamayı kolaylaştırır.

İkinci hafta veri ve değerlendirme hazırlığına ayrılabilir. Kullanılabilecek kaynaklar, erişim sınırları, temsili örnekler ve kabul ölçütleri seçilir. Üçüncü hafta sınırlı bir denemeyle kullanıcı davranışı gözlenir. Kullanıcının yalnızca ne dediğine değil, çıktıyı nasıl kontrol ettiğine, nerede duraksadığına ve hangi adımı elle tekrarladığına bakılır. Yanlış sonuçların saklanmadığı bir değerlendirme toplantısı yapılır.

Dördüncü hafta devam, değişiklik veya durdurma kararı alınabilir. Bir özelliğin teknik olarak çalışması onun ürün yol haritasına mutlaka girmesini gerektirmez. Beklenen fayda görülmediyse kapsam daraltılabilir veya farklı bir yöntem denenebilir. Kararın dayandığı bilgi kaydedildiğinde ekip sonraki görüşmelerde daha somut bir deneyim paylaşabilir. Böylece ekosistemle kurulan temas yalnızca fikir aşamasında kalmaz; araştırılmış bir soru ve gözlenmiş bir sonuç etrafında gelişir. Bu düzen, teknolojiye duyulan ilgiyi ölçülebilir ürün öğrenmesine dönüştürmenin uygulanabilir yollarından biridir.

Sık sorulan sorular

AIPA bir yapay zekâ ürününe uygunluk belgesi veriyor mu?

Bu yazı için incelenen kaynaklar böyle bir genel yetki veya her girişime sunulan belgelendirme hizmeti göstermemektedir. Dernekle ilişki kurulması, ürünün hukuken veya teknik olarak onaylandığı anlamına gelmez. Belirli bir doğrulama ihtiyacı varsa ilgili yetkili kurum, standart ve değerlendirme kapsamı ayrıca araştırılmalıdır. Ürünün sınırlarını açıklama sorumluluğu girişimde kalır.

Yapay zekâ kullanmayan bir girişim bu konuları neden takip etmeli?

Müşterilerin, çalışanların veya tedarikçilerin kullandığı araçlar girişimin iş süreçlerini etkileyebilir. Ayrıca teknoloji ekleme kararı verilmeden önce hangi ihtiyacın karşılanacağı anlaşılmalıdır. Konuyu takip etmek, her ürüne yapay zekâ eklemek zorunluluğu doğurmaz. Bazen daha açık bir süreç veya daha iyi veri düzeni, mevcut sorunu daha uygun biçimde çözebilir.

AIPA araştırmaları doğrudan pazar büyüklüğü hesabında kullanılabilir mi?

Her araştırmanın amacı ve yöntemi ayrı değerlendirilmelidir. Algı veya farkındalık ölçümü, belirli bir ürün için satın alma niyeti ya da pazar büyüklüğüyle aynı değildir. Girişim, kaynağın tarihini ve örneklemini incelemeli; kendi hedef kullanıcı görüşmeleri ve kullanım gözlemleriyle birlikte yorumlamalıdır. Bu yazıda araştırmalardan hareketle herhangi bir yatırım getirisi veya satış tahmini yapılmamaktadır.

Orion paydaşlığı özel programa kabul sağlar mı?

İncelenen Orion profilinde otomatik kabul veya özel kontenjan açıklanmamaktadır. AIPA'nın güncel etkinlik ve katılım koşulları resmî kanallardan öğrenilmelidir. Orion üzerinden iletilecek bir iş birliği talebinin somut amacı ve beklenen katkısı belirtilirse değerlendirme daha açık bir çerçevede yapılabilir. Kurulan ilk temas, kendi başına anlaşma veya hizmet taahhüdü oluşturmaz.