Kurumsal yapay zekâ projesi maliyeti: kalem kalem neye ödüyorsunuz?

"Bu iş bize ne kadara mal olur?" sorusuna verilen "duruma göre değişir" cevabı haklı olarak sinir bozucudur. Ama sorunun cevabı gerçekten tek bir rakam değildir — aynı başlığı taşıyan iki proje arasında on kat fark olabilir.

Bu yazıda rakam yerine kalem listesi veriyoruz: neye ödediğinizi, hangi kalemin neyle büyüyüp küçüldüğünü ve teklifleri karşılaştırırken neye bakmanız gerektiğini. Kendi bağlamınızda bu listeyi doldurduğunuzda ortaya sizin rakamınız çıkar — ve daha önemlisi, gelen teklifleri okuyabilir hâle gelirsiniz.

Maliyet neden tek rakamla verilemiyor?

Üç neden var ve üçü de teknik değil:

1. Veri durumu her kurumda farklı. Aynı senaryo, verisi düzenli bir kurumda haftalar, verisi üç sistemde üç farklı hâlde duran bir kurumda aylar sürer. Bu fark modele değil, yapay zekâdan önceki işe aittir.
2. Entegrasyon yüzeyi kapsamı belirler. Tek sisteme dokunan bir asistanla, beş sistemden veri toplayıp üçüne yazan bir ajan aynı işi yapmaz. Kalem sayısı değil, sınır sayısı maliyeti büyütür.
3. "Tamamlandı"nın tanımı değişkendir. Pilot çalıştığında biten bir proje ile üretimde yetkilendirme, izleme, eğitim ve destek gerektiren bir proje arasındaki fark bütçenin kendisi kadar olabilir.

Sekiz görünen kalem

1. Keşif ve fizibilite

Senaryo seçimi, veri envanteri, teknik uygulanabilirlik ve başarı kriterlerinin yazılması. Kısa bir fazdır ama atlandığında en pahalı kaleme dönüşür: yanlış senaryoyu ölçeklemek, doğru senaryoyu geç başlatmaktan pahalıdır.

Büyüten: birden çok aday senaryo, dağınık veri sahipliği, birden çok paydaş grubu. Küçülten: net tanımlanmış tek bir problem ve karar verecek tek bir sahip.

2. Veri hazırlığı

Kaynakların çıkarılması, temizlenmesi, birleştirilmesi, erişim modelinin kurulması. Sahada en sık en büyük kalem budur ve bütçelerde en sık küçümsenen kalemdir.

Büyüten: taranmış ve metin katmanı olmayan belgeler, tutarsız kodlama, aynı bilginin birden çok sistemde farklı hâli, sahipsiz veri. Küçülten: tek doğruluk kaynağı, düzenli üst veri, hazır API'ler.

3. Model erişimi

Bulut API kullanım ücretleri ya da kurum içi kurulumda model lisansı/dağıtımı. Kurumların çoğunun ilk sorduğu kalemdir; toplam içindeki payı ise genellikle beklenenden küçüktür.

Büyüten: her istekte uzun bağlam gönderilmesi, gereksiz büyük model tercihi, yüksek eşzamanlı kullanım. Küçülten: bağlam budama, senaryoya göre model boyutlandırma, önbellekleme.

4. Uygulama geliştirme

Arayüz, iş mantığı, yetkilendirme, hata durumları, kullanıcı akışları. "Modeli çağırmak" bu kalemin küçük bir parçasıdır; kalanı klasik yazılım mühendisliğidir.

5. Entegrasyon

ERP, CRM, doküman yönetimi, kimlik sağlayıcı, e-posta, sektörel sistemler. Her yeni sınır; bir yetkilendirme, bir hata senaryosu ve bir bakım yükü demektir.

6. Altyapı

Bulutta ortam ve depolama; kurum içinde donanım, ağ izolasyonu, yedeklilik. Kurum içi kurulumda bu kalem öne yığılır.

7. Değerlendirme hattı

Kurumun gerçek sorularından bir test seti kurulması ve doğruluğun sürekli ölçülmesi. Bütçelerde en çok kesilen, kesildiğinde en çok pişman olunan kalemdir: ölçüm yoksa sistemin iyi çalışıp çalışmadığı bir kanaat sorusuna döner.

8. Devir ve eğitim

İşletim dokümanı, yönetici eğitimi, kullanıcı eğitimi, destek modeli. Sistem kullanılmadığında maliyeti sıfırlanmaz — yalnızca faydası sıfırlanır.

Görünmeyen üç kalem

Bunlar tedarikçi teklifinde yer almaz ama bütçenizde yer almalıdır:

1. İç ekip zamanı. Konu uzmanlarının soru setlerini doğrulaması, veri sahiplerinin erişim açması, hukuk ve güvenliğin inceleme yapması. Bu saatler gerçek maliyettir ve genellikle en yoğun kişilerden alınır.
2. Veri temizliği. Tedarikçi veriyi işleyebilir ama içeriğin doğru olup olmadığını yalnız kurum bilir. Yanlış veriyle kurulan sistem, yanlışı hızla ölçekler.
3. Değişim yönetimi. İş akışının değişmesi, yeni alışkanlık, direnç. Teknik olarak başarılı, kullanımı sıfır projelerin ortak eksiği budur.

Bulut mu, kurum içi mi? Maliyet eğrileri farklı şekilli

Karar yalnız maliyetle verilmez — veri lokasyonu şartı varsa eğri tartışması zaten kapanır; bu ayrımı LLM API'leri ve yurt dışına veri aktarımı yazımızda ayrıntılandırdık. Ama şart yoksa kararı hacim tahmini belirler: kaç kullanıcı, kaç senaryo, günde kaç istek. Bu tahmin olmadan yapılan karşılaştırma, iki farklı eğriyi tek noktada kesip birini seçmektir.

Maliyeti belirleyen yedi değişken

Son satır çoğu zaman en pahalı olanıdır: süreyi sıkıştırmak, kapsamı küçültmediğiniz sürece maliyeti paralel çalışmayla satın almak demektir.

Pilot ile üretim arasındaki fark

Pilot bütçesini üretim bütçesiyle karıştırmak, bu alandaki en yaygın planlama hatasıdır. Aradaki fark şu kalemlerden doğar:

• Yetkilendirme ve rol modelinin gerçek kurum yapısına oturtulması
• İzleme, uyarı ve hata yönetimi
• Kullanıcı eğitimi ve destek kanalı
• Yedeklilik ve süreklilik
• Değerlendirme setinin kalıcı hâle getirilmesi
• Veri güncelleme hattının otomatikleştirilmesi

Pilot bir fizibilite kanıtıdır, fiyat etiketi değil. Doğru kullanım şudur: pilot, üretim maliyetini tahmin edilebilir kılar — çünkü hangi kalemin ne kadar büyüdüğünü gerçek veriyle gösterir.

Teklifleri karşılaştırırken sorulacak on soru

Farklı tedarikçilerden gelen teklifler çoğu zaman farklı şeyleri kapsar; asıl karşılaştırma bu on sorunun cevaplarıyla yapılır:

1. Bu tekliften çıkacak somut teslimatlar neler — sistem, belge, eğitim?
2. Veri hazırlığı kapsama dahil mi, yoksa "veri hazır varsayılmış" mı?
3. Kaç entegrasyon dahil, fazlası nasıl fiyatlanıyor?
4. Başarı kriteri ne ve nasıl ölçülecek? Ölçüm kimin işi?
5. Değerlendirme seti kuruluyor mu, kime devrediliyor?
6. Model ücretleri teklife dahil mi, kim ödüyor?
7. Kapsam dışı talepler nasıl yönetiliyor — scope creep için yazılı bir usul var mı?
8. Devir sonrası işletme kimde; destek kademeleri ve süreleri ne?
9. Kaynak kod ve modeller kimin mülkiyetinde?
10. Tedarikçi değişirse sistem taşınabilir mi, bağımlılık nerede?

Bu soruların cevapları iş tanımı belgesinde yazılı değilse, teklifler karşılaştırılabilir değildir — yalnız rakamları karşılaştırılabilir. Bir RFP sürecinde bu on maddeyi zorunlu alan yapmak, sonradan çıkan farkların büyük kısmını baştan kapatır.

Bütçeyi fazlara yaymak

Tek seferde tüm projeyi onaylamak, yanlış senaryoyu ölçeklemeyi mümkün kılar. Uyguladığımız yaklaşım üç durak içerir:

1. Keşif ve fizibilite — ayrı bütçelenir, çıktısı bir karardır: devam mı, senaryo değişikliği mi, durma mı.
2. Pilot — dar kapsam, gerçek veri, ölçülebilir kriter. Kriter tutmuyorsa burada durmak başarısızlık değil, tasarrufun kendisidir.
3. Üretim ve ölçekleme — pilotun ölçtüğü kalemler üzerinden bütçelenir.

Bu yapı, toplam sahip olma maliyetini de görünür kılar: her fazın sonunda yalnız yapılan işin değil, işletme yükünün de tahmini güncellenir.

Toparlarken

Yapay zekâ projesinin maliyetini belirleyen şey, kullandığınız model değil verinizin durumu ve dokunduğunuz sistem sayısıdır. "Ne kadar?" sorusunun işe yarar hâli şudur: hangi kalemler var, bende hangisi büyük, hangisini küçültebilirim?

Yatırımın hangi sırada yapılacağını belirlemek içinse önce nerede durduğunuzu bilmek gerekir; bunun yöntemini dijital olgunluk yazımızda, ürün mü özel geliştirme mi kararını ise karar çerçevesi yazımızda ele aldık.

Kapsamı birlikte netleştirelim — ön görüşme planlayın