Yapay Zekada Kendi Kendine Yap (DIY) Döneminin Sonu

Yapay Zekâda DIY Dönemi Neden Bitiyor?

Yapay zekanın ilk heyecanlı günlerini hatırlayın. Herkes kendi "özel GPT'sini" yapıyor, harika prompt listeleri paylaşıyordu. "Kendi kendine yap" (Do It Yourself) çılgınlığı tavan yapmıştı. Ama bir dakika. İş büyüdüğünde ne oluyor?

Geçenlerde bir işletmenin müşteri destek ekibini inceledim. 5 farklı çalışan, 5 farklı ChatGPT penceresinde müşterilere cevap yazıyordu. Biri kibar, diğeri argo kullanıyor, üçüncüsü şirketin fiyat listesini yanlış hatırlayıp indirim veriyor. Tam bir kaos. Ortada veri güvenliği yok, süreç tutarlılığı yok, takip edilebilir hiçbir metrik yok. İşte bu yüzden DIY dönemi kapanıyor.

AI Çağında Yazılım: Satın Almak mı, Kendi Aracını Üretmek mi?

Teknoloji dünyasının klasik "Satın Al mı, Kendin Yap mı?" (Build vs Buy) dengesi artık tamamen değişti. Eskiden ana uzmanlık alanı dışındaki yazılımları sıfırdan geliştirmek alanında mantıksız kabul edilirken, bugün şirketler hazır SaaS çözümleri kiralamak yerine kendi iç süreçlerini Make ve özel kod bloklarıyla çok daha ucuza ve esnek şekilde geliştirebiliyor.

Bespoke (özel tasarım) dahili araçlar geliştirmek, hem şirketin operasyonel verilerini dışarı sızdırmadan tam kontrol sağlıyor hem de organizasyon genelinde yapay zekâ okuryazarlığını (AI Fluency) en üst düzeye çıkarıyor.

Kurumsal Seviyede Otomasyon Mimarisi Nasıl Olmalı?

Eğer kurumsal seviyede çalışacaksanız, sistem şu 3 sütun üzerine oturmalı:

• Esnek Değil, Deterministik Akışlar: AI'ı tamamen serbest bırakmayın. Veri akışı Make veya özel kod entegrasyonlarıyla belirli kurallara bağlı olmalı. AI sadece karar anlarında veya metin işleme gibi esnek adımlarda devreye girmeli.
• İnsan Onayı (Human-in-the-Loop): Kritik süreçlerde (teklif onaylama, yanıt gönderme) sistem doğrudan sizin onayınızı beklemeli. Siz "onayla" butonuna basmadan veri yayına gitmemeli.
• Hata Yönetimi ve Loglama: API çağrılarını, ajanın çalışma durumunu anlık olarak kaydedin. Bir hata olduğunda sistem sessizce çökmesin, size bildirim atsın ve otomatik kurtarma mekanizmalarını tetiklesin.

Buradaki ayrım “hazır araç kötüdür, özel geliştirme iyidir” kadar basit değildir. Tek kişinin düşük riskli bir işi ara sıra yaptığı durumda hazır bir ürün yeterli olabilir. Aynı işlem birden fazla ekipte tekrarlanıyor, müşteri verisi taşıyor veya yanlış kararın maliyeti yükseliyorsa süreç sahibi, veri sözleşmesi, erişim yetkisi ve denetim kaydı tanımlanmalıdır. NIST'in AI Risk Management Framework yaklaşımı da yapay zekâ riskini kullanım bağlamı ve etkisiyle birlikte yönetmeyi önerir.

Karar verirken önce sürecin hacmini değil kırılma biçimini yazın: yanlış veri gelirse ne olur, sağlayıcı kapanırsa iş nasıl devam eder, kim onay verir ve kayıt nerede tutulur? Sonra küçük bir pilotta gerçek hata örneklerini ölçün. Ancak bu kanıt elde edildikten sonra otomasyonu genişletin. Bu yöntem, gösterişli bir demo ile sürdürülebilir işletim sistemi arasındaki farkı görünür kılar. Onay kapılarının teknik tasarımı için human-in-the-loop rehberini okuyabilirsiniz.

Çalışılmış Örnek: Beş Ayrı Sekmeden Tek Sürece

Aşağıdaki dönüşüm, yazının başındaki destek ekibi tablosunun nasıl toparlandığını adım adım gösterir. Akış temsilîdir ve gerçek müşteri verisi içermez; amacı DIY ile sistem arasındaki farkı somut adımlarla göstermektir.

Girdi. Beş çalışan, beş ayrı sohbet penceresinde müşteri yanıtı yazıyor. Ortada ne ortak bir bilgi kaynağı ne de kayıt var; aynı soruya beş farklı cevap, farklı üslup ve zaman zaman yanlış fiyat çıkıyor.

1. Kaynağı tekilleştirme: Fiyat listesi, teslim süreleri ve iade koşulları tek bir onaylı belgeye taşınır. Bu belge güncellendiğinde tüm yanıtlar aynı anda güncellenmiş olur; beş kişinin ayrı ayrı hatırlaması gereken hiçbir şey kalmaz.
2. Girişi tek kapıya almak: Müşteri mesajları kişisel pencerelere değil ortak bir kuyruğa düşer. Kim hangi mesaja baktı, ne zaman yanıtladı - bu iki bilgi ilk günden kaydedilir.
3. Taslak üretimi: Model yanıtı doğrudan müşteriye göndermez; onaylı belgeden beslenen bir taslak hazırlar. Belgede karşılığı olmayan soruda taslak üretmez, soruyu işaretler.
4. Onay kapısı: Taslağı insan onaylar ve gönderir. Onay adımı ortadan kalkmaz, yalnızca yazma emeği azalır.
5. Geri besleme: Belgede karşılığı olmayan sorular haftalık listelenir ve belgeye eklenir. Sistem kendini bu döngüyle iyileştirir; DIY kurulumunda bu döngü hiç yoktur çünkü eksikler hiç kaydedilmez.

Çıktı. Aynı soruya aynı cevap verilir, her yanıt izlenebilir, yanlış fiyat riski kaynağında kapanır ve ekibin öğrendiği şey kişilerde değil belgede birikir. Kullanılan model değişmemiştir; değişen şey modelin etrafındaki süreçtir.

Veri ve Ölçüm: Kararı Sayıya Bağlamak

Hazır araç mı özel kurulum mu sorusunun cevabı marka tercihinde değil, dört ölçülebilir değişkendedir: tekrar sıklığı, hata maliyeti, veri hassasiyeti ve süreç sahipliği. Bu dört değişken yazılmadan verilen karar, sonradan pahalıya dönen bir tahmindir.

Bu tabloyu bir çerçeveye oturtmak isteyenler için NIST AI Risk Management Framework, yapay zekâ riskinin kullanım bağlamı ve etkisiyle birlikte yönetilmesini önerir - yani aynı teknolojinin farklı bağlamlarda farklı kontrol seviyesi gerektirdiğini kabul eder. Teknik tarafta ise araçları modele bağlamanın artık ortak bir standardı vardır: Model Context Protocol, sunucuların istemcilere tools, resources ve prompts ilkellerini sunduğu, JSON-RPC 2.0 üzerinde çalışan açık bir protokoldür. Bu standart, her entegrasyon için sıfırdan bağlayıcı yazmayı gereksiz kılar ve DIY kurulumların en pahalı kalemini - her aracı ayrı ayrı bağlamayı - ortadan kaldırır.

Ölçülecek sayılar da bu karardan doğar: aynı işin kişiler arasındaki süre farkı, yanıtların onaylı kaynaktan sapma oranı, tekrar eden soruların belgeye eklenme hızı ve hata sonrası geri alma süresi. Dördü de pilot aşamada ölçülür; genişletme kararı ancak bu kanıt elde edildikten sonra verilir.

Hata Desenleri: DIY'den Sisteme Geçerken Yapılan Dört Yanlış

Geçişin kendisi de yanlış yapılabilir ve en sık görülen dört desen şunlardır.

Aracı değiştirip süreci değiştirmemek. Beş sohbet penceresini tek bir kurumsal araca taşımak, ortak bilgi kaynağı ve kayıt kurulmadıysa yalnızca kaosun yerini değiştirir. Değişmesi gereken şey araç değil, cevabın nereden geldiğidir.

Onay kapısını verimlilik uğruna kaldırmak. Taslak onayı ilk haftalarda yavaş gelir ve kaldırmak cazip görünür. Oysa onay kapısı geri alınamaz hatanın tek sigortasıdır; kaldırılacaksa önce sapma oranının uzun süre sıfıra yakın kaldığı ölçülmelidir.

Eksikleri kaydetmemek. Modelin cevaplayamadığı sorular kayda geçmiyorsa sistem öğrenmez. DIY kurulumların gizli maliyeti budur: her çalışan aynı boşluğa ayrı ayrı çarpar ve hiçbiri kalıcı olarak kapanmaz.

Yapay zekâ okuryazarlığını tek kişide toplamak. Kurulumu yapan kişi ayrıldığında sistem bakımsız kalır. Doğru yaklaşım, süreç sahibini ve yedeğini baştan tanımlamak ve kurulumun nasıl çalıştığını yazılı bırakmaktır. Bireysel yetkinliğin nasıl sistem yetkinliğine dönüştüğü yapay zekâ okuryazarlığı uçurumu yazısında, akış tasarımının teknik disiplini ise akıllı iş akışları tasarımı rehberinde ele alınmıştır.

Bu dört desenin ortak sebebi, geçişi bir araç projesi gibi ele almaktır. Oysa DIY'den sisteme geçiş bir yönetim kararıdır: neyin standartlaşacağı, kimin sahip olacağı ve hangi durumda insanın devreye gireceği belirlenir. Araç bu kararların uygulanma biçimidir, kendisi karar değildir. Pratikte geçişin başarısı da tek bir soruyla ölçülür: kurulum, onu kuran kişi izinliyken de aynı kaliteyle çalışıyor mu? Cevap hayırsa ortada bir sistem değil, kişiye bağlı bir alışkanlık vardır ve DIY dönemi fiilen sürüyor demektir.

Geçişi küçük tutmak da bilinçli bir tercihtir. Tek bir süreçle başlayıp o süreci uçtan uca kayıtlı, ölçülü ve onay kapılı hâle getirmek; beş süreci aynı anda yarım kurmaktan daha hızlı sonuç verir. Kurulan ilk süreç aynı zamanda kurumun şablonu olur: ikinci süreçte tartışılacak konu araç seçimi değil, aynı şablonun bu işe nasıl uyarlanacağıdır. Bu yüzden ilk sürecin seçimi de önemlidir: tekrar sıklığı yüksek, hatası geri alınabilir ve sonucu ölçülebilir bir iş seçilir. Görünürlüğü yüksek ama riski de yüksek bir süreçle başlamak, ilk hatada kurumun otomasyona olan güvenini baştan tüketir ve geçiş orada durur. Doğru seçilen ilk süreç ise iki şey üretir: ölçülebilir bir kazanç ve ekibin bir sonraki süreçte tekrar edeceği bir çalışma biçimi. İkincisi genellikle birincisinden daha değerlidir, çünkü kazanç tek seferliktir, çalışma biçimi ise her yeni süreçte yeniden kullanılır.