--- title: "Yapay Zeka Teknik Borcu ve Uzun Vadeli Bakım | Designodin Türkiye" description: "Yapay zeka teknik borcu nedir? Model, veri, API ve entegrasyon kaynaklı uzun vadeli bakım maliyetlerini proje başlamadan görün." source: https://designodin.com.tr/blog/yapay-zeka-teknik-borcu-bakim --- [← Tüm yazılar](https://designodin.com.tr/blog/) [AI](https://designodin.com.tr/blog/kategori/ai/) # Yapay Zeka Teknik Borcu ve Uzun Vadeli Bakım 18 Ekim 2026 · Designodin **Yapay zeka teknik borcu**, bir AI sistemini hızla canlıya almak için verilen teknik kararların sonradan bakım, model değişikliği, veri kalitesi, güvenlik, test ve entegrasyon maliyeti olarak geri dönmesidir. AI projelerinde pahalı olan bölüm çoğu zaman ilk kurulum değildir. Asıl maliyet, model değiştiğinde, veri güncelliğini kaybettiğinde veya otomasyon yanlış işlem yaptığında başlar. Bir müşteri destek botu ilk haftasında sorunsuz görünebilir. Ancak üç ay sonra iade şartları değişir, ürün verileri güncel kalmaz ve bot müşterilere yanlış yanıt vermeye başlar. Kurulum tamamlandığında, bilgi tabanını kimin güncelleyeceği yazılı değilse iç ekip bunu bilemez. Sorun chatbot değildir. Sorun, sorumlusu olmayan sistemdir. Bu yazıda, bir yapay zeka projesine başlamadan önce bakım borcunu nasıl görünür kılacağınızı ele alıyoruz. Hangi risklerin olağan olduğunu, aylık bakım kapsamına hangi işlerin girmesi gerektiğini ve hangi projelerde hazır bir aracın yeterli kalacağını göreceksiniz. **Öne Çıkanlar** - Yapay zeka teknik borcu yalnızca koddan değil; model, prompt, veri kaynağı, API, yetki ve iş kurallarından birikir. - Model sağlayıcısı değişikliği, CRM alan güncellemesi veya eski bilgi tabanı canlıdaki AI sistemini sessizce bozabilir. - Aylık bakım; hata müdahalesi, model geçişi, yeni özellik ve veri güncellemesini tek bir belirsiz “destek” başlığında toplamamalıdır. - İade, fiyat, ödeme, müşteri verisi ve sözleşme süreçlerine dokunan AI akışlarında insan onayı ve hata kayıtları gerekir. - Düşük riskli iç araçlarda hazır AI ürünleri yeterli olabilir; kritik entegrasyonlarda ise sahiplik ve bakım planı baştan yazılmalıdır. ## Yapay zeka teknik borcu nedir Yapay zeka teknik borcu, hızlı teslim için ertelenen teknik tercihlerin zamanla işletme maliyetine dönüşmesidir. Bu maliyet bazen ek geliştirme faturası olarak çıkar. Bazen yanlış fiyat veren bir bot, kaçan satış fırsatı veya kişisel verilere gereksiz erişim olarak karşınıza gelir. Geleneksel yazılım teknik borcunda sorun genellikle kod kalitesi, güncelliğini yitirmiş kütüphaneler veya karmaşık mimaridir. AI teknik borcunda kod, bunların yalnızca bir parçasıdır. Sistemin davranışını aynı anda şu katmanlar belirler: - Kullanılan model ve model sürümü - API sağlayıcısı ve fiyat yapısı - Prompt’lar ile sistem yönergeleri - Bilgi tabanı, ürün kataloğu ve CRM verisi - Araç çağrıları ve üçüncü taraf entegrasyonlar - Erişim yetkileri - İnsan onayı kuralları - Test senaryoları, hata kayıtları ve geri dönüş planı Google Research’ün [makine öğrenmesi sistemlerindeki gizli teknik borç çalışması](https://research.google/pubs/hidden-technical-debt-in-machine-learning-systems/) bu farkı yıllar önce ortaya koydu: AI sistemlerinde veri bağımlılıkları, geri besleme döngüleri ve dış dünyadaki değişimler bakım yükünü büyütür. Bugün LLM tabanlı chatbotlar ve otomasyonlar bu tabloyu daha basit hale getirmedi. Sadece kurulumu daha kolay gösterdi. Yapay zeka teknik borcu, AI kullandığınız için oluşmaz. Sistemi neye bağladığınızı, değişiklik olduğunda kimin sorumluluk taşıdığını ve hangi verinin doğru kabul edildiğini yazmadığınız için oluşur. Bir AI sisteminin iyi yanıt üretmesi, işletme açısından kolay yönetildiği anlamına gelmez. İlk demoda ikisi aynı şeymiş gibi görünebilir. Gerçek kullanım, aradaki farkı ortaya çıkarır. ## AI projelerinde borç nereden birikir ### Model ve API sağlayıcısına bağımlılık API kullanan her AI uygulaması, model sağlayıcısının ürün kararlarına bağlıdır. Model sürümleri kaldırılabilir, fiyatlar değişebilir, kullanım limitleri güncellenebilir veya çıktı formatı farklılaşabilir. OpenAI gibi sağlayıcılar, kaldırılacak modeller ve endpoint’ler için geçiş tarihleri yayımlar. Ancak bildirim verilmesi, uygulamanızın otomatik olarak yeni modele uyum sağlayacağı anlamına gelmez. [OpenAI’nin kaldırma politikası](https://developers.openai.com/api/docs/deprecations) genel kullanıma açık modeller için olağan koşullarda en az altı ay önceden bildirim öngörür. Altı ay, planı olan ekip için yeterlidir. Sistemin nerede ne kullandığını bilmeyen ekip için değildir. Örneğin içerik aracınız, belirli bir modelden sabit JSON formatında çıktı alacak şekilde kurulmuş olabilir. Yeni model alanları farklı sırada üretebilir, bazılarını eksik döndürebilir veya daha yüksek maliyet yaratabilir. Yalnızca API adını değiştirmek çözüm değildir. Çıktı kalitesi, maliyet, hız, hata durumları ve entegrasyonlar yeniden test edilmelidir. **Yapay zeka API maliyeti** de bu bağımlılığın parçasıdır. Kullanım arttıkça token tüketimi, araç çağrıları ve veri işleme giderleri yükselir. Maliyet limiti olmayan bir sistem, özellikle beklenmeyen kullanıcı davranışlarında veya hatalı döngülerde kontrolsüz harcama yaratabilir. ### Prompt ve iş kurallarının birbirine karışması Prompt, botun içine yazılmış birkaç cümle değildir. Sistem davranışının doğrudan bir parçasıdır. Buna rağmen birçok projede iade şartı, fiyat istisnası, müşteri segmenti veya teklif kuralı doğrudan prompt içine yazılır. Bu yöntem başlangıçta hızlıdır. Ancak altıncı ayda hangi cümlenin hangi sonucu etkilediğini kimse bilemeyebilir. İş kuralları ve model talimatları birbirinden ayrılmalıdır. “İade süresi 14 gündür” gibi değişebilen işletme bilgileri güvenilir bir veri kaynağından gelmelidir. “İade talebini otomatik onaylama; istisnaları operatöre yönlendir” gibi işlem sınırları ise sistem tasarımında açıkça tanımlanmalıdır. Bu nedenle prompt sürümleme önemlidir. Hangi prompt’un ne zaman değiştirildiği, hangi testlerden geçtiği ve neden canlıya alındığı kayda geçmezse sistem davranışı tahmine kalır. ### Veri kaynağı değiştiğinde sessizce bozulan sistemler AI sistemlerinin çoğu model hatası nedeniyle değil, eski veya yanlış veri nedeniyle hatalı davranır. Botun veri kaynağı eski bir Google Sheet, güncellenmeyen bir PDF veya sorumluluğu belirsiz bir CRM alanıysa model ne kadar iyi olursa olsun yanlış bilgi üretir. Bu durum e-ticarette sık görülür. Bir destek botu ürün verisini eski bir tablodan alır. Kampanya biter, fiyat güncellenmez. İade politikası değişir, fakat bilgi tabanında eski içerik kalır. Bot da müşteriye kendinden emin bir şekilde yanlış bilgi verir. Bu durumda çözüm “daha güçlü model” değildir. Yapılması gereken şunları netleştirmektir: - Her veri kaynağının işletme içindeki sahibi kim? - Veri ne sıklıkla güncelleniyor? - Eski dokümanlar nasıl arşivleniyor veya kaldırılıyor? - Sistem güncel veri gelmediğinde ne yapıyor? - Kritik bilgi için AI cevap vermek yerine insan ekibe yönlendirebiliyor mu? Veri kaynağının sahipliği, yapay zeka projesinin sürdürülebilirliği için temel bir konudur. Sahibi belli olmayan bilgi, canlı sistemde borç yaratır. ### İnsan onayı olmayan otomasyonlar AI’ın tavsiye vermesi ile işlem yapması arasında ciddi fark vardır. İçerik taslağı oluşturan bir araç düşük risklidir. Buna karşılık iade talebini onaylayan, CRM’e lead ekleyen veya müşteriye fiyat teklifi gönderen sistem düşük riskli değildir. CRM’e teklif taleplerini aktaran bir otomasyon kurulduğunu düşünün. Sistem, form yanıtlarını okuyup satış ekibi için uygun kayıtlar oluşturur. Bir ay sonra CRM’e yeni bir “sektör” alanı eklenir. Otomasyon eski alan eşlemesini kullanmaya devam eder ve bazı kayıtları yanlış segmente aktarır. Ekip hatayı iki hafta sonra fark eder. Çünkü hata bildirimi yoktur, günlük kayıtlar incelenmez ve satış temsilcileri eksik lead’leri tek tek göremez. Buradaki sorun AI’ın formu yanlış yorumlaması değildir. Sorun, entegrasyon değiştiğinde sistemi doğrulayacak bir kontrol mekanizmasının olmamasıdır. İade, ödeme, fiyat, sözleşme, müşteri verisi ve finansal karar gibi sonuç üreten işlemlerde **“AI önerir, insan onaylar”** yaklaşımı çoğu durumda daha güvenlidir. İnsan onayı yavaşlık demek değildir. Hatalı otomasyonun maliyetini sınırlayan bir tasarım tercihidir. ### Log, test ve geri dönüş planı eksikliği Bir sistem arızalandığında önce şu üç soruya yanıt verebilmelisiniz: - Ne değişti? - Hangi kullanıcılar etkilendi? - Eski çalışan sürüme nasıl döneriz? Bu soruların yanıtı yoksa bakım süreci araştırma sürecine döner. Hata kayıtları, sistemin hangi girdiyi aldığını, hangi modeli kullandığını, hangi aracı çağırdığını ve hangi sonucu ürettiğini gösterebilmelidir. Kişisel veri içeren loglar için erişim, saklama ve maskeleme kuralları ayrıca tanımlanmalıdır. Yeni bir model, prompt veya entegrasyon canlıya alınmadan önce test senaryoları çalıştırılmalıdır. “Doğru cevap verdi mi?” sorusu tek başına yeterli değildir. Sistemin yanlış bilgi karşısında nasıl davrandığı, yetkisiz işlem yapıp yapmadığı ve maliyet limitini aşıp aşmadığı da kontrol edilmelidir. [Google Cloud’un MLOps rehberi](https://docs.cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning), veri değişimlerinin izlenmesini ve gerektiğinde önceki sürüme dönebilmeyi önerir. LLM tabanlı uygulamalarda da ilke aynıdır: değişiklik yapılır, ölçülür, sorun varsa geri alınır. ## Uzun vadeli bakım neleri kapsamalı “AI için aylık bakım var” ifadesi tek başına bir şey anlatmaz. Hata düzeltmeleri dahil mi? Model kaldırılırsa geçişi kim yapacak? CRM’e yeni alan eklenirse bu bakım kapsamına mı girer, yoksa ayrı geliştirme mi sayılır? Bunlar yazılı değilse anlaşma, kapsamı belirsiz bir aylık bakım ücretine dönüşür. Sistemin çalışır kalması için hazırlanan planda şu başlıklar açıkça yer almalıdır: - **Sistem sağlığı ve hata takibi:** Entegrasyonlar çalışıyor mu, hata oranı arttı mı, sistem ne zaman uyarı veriyor? - **Model ve API değişiklikleri:** Kullanılan modeller, endpoint’ler ve sürüm geçiş sorumluluğu kayıtlı mı? - **Prompt ve iş kuralı güncellemeleri:** Kim değişiklik talep edebilir, hangi değişiklik test gerektirir? - **Bilgi tabanı bakımı:** Yeni içerik, ürün, politika ve dokümanlar nasıl eklenir; eskiler nasıl kaldırılır? - **Kullanım ve maliyet izleme:** API tüketimi, limitler ve anormal kullanım nasıl takip edilir? - **Erişim ve güvenlik kontrolleri:** Kim hangi veriyi görebilir, ekipten ayrılan kişinin erişimi nasıl kapatılır? - **Test ve kalite değerlendirmesi:** Canlıya çıkmadan önce hangi senaryolar tekrar çalıştırılır? - **İnsan onayı sınırları:** AI’ın hangi noktada duracağı ve işlemi kime devredeceği tanımlı mı? - **Veri yaşam döngüsü:** Veriler nerede tutuluyor, ne kadar süre saklanıyor, ne zaman siliniyor? - **Dokümantasyon ve devir:** Kod, erişim, entegrasyon şeması ve süreç bilgisi işletmeye teslim ediliyor mu? NIST’in AI Risk Management Framework yaklaşımı, AI sistemlerinin yayından önce ve kullanım sırasında ölçülmesini, test edilmesini ve dokümante edilmesini önerir. [NIST AI RMF kaynakları](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) bunu yalnızca model doğruluğu açısından ele almaz; operasyon, güvenlik ve etki risklerini de kapsar. AI destekli müşteri deneyimini mevcut sitenize bağlayacaksanız, altyapının da kontrol edilebilir olması gerekir. [Elle kodlanmış WordPress geliştirme](https://designodin.com.tr/hizmetler/wordpress/), destek veya lead akışlarını mevcut kurumsal siteye page builder yükü ve belirsiz eklenti zinciri olmadan bağlamak için daha temiz bir temel sunar. **Bakım kapsamınız bugün net değilse, sisteminiz büyümeden bunu yazılı hale getirin.** Özellikle müşteri verisine veya satış sürecine temas eden akışlarda “sonra bakarız” yaklaşımı en maliyetli seçenektir. ## Bakım anlaşmasında yazılı olması gereken 10 madde Teklif veya sözleşme aşamasında aşağıdaki sorulara yazılı yanıt isteyin. “Gerekirse bakarız” yanıt değildir. - **Sistemin sahibi kim?** Kodun, yapılandırmaların, prompt’ların, hesapların ve dokümantasyonun mülkiyeti açıkça belirtilmelidir. - **Hangi model, API ve üçüncü taraf araçlar kullanılıyor?** Sağlayıcılar, hesap sahipleri ve kritik bağımlılıklar listelenmelidir. - **Model veya API kaldırılırsa geçişi kim yapacak?** Test, uygulama ve maliyet sorumluluğu tanımlanmalıdır. - **Aylık bakım hangi işleri kapsıyor?** Hata inceleme, küçük güncelleme, model geçişi ve veri güncellemesi ayrı ayrı yazılmalıdır. - **Yeni özellik talebi bakım mı, ayrı geliştirme mi?** Yeni entegrasyon veya yeni otomasyon akışı bakım kapsamına gizlenmemelidir. - **Hata müdahale süresi nedir?** Kritik hata ile küçük iyileştirme talebi aynı öncelikte değerlendirilmemelidir. - **Hangi işlemler insan onayı olmadan yapılamaz?** Fiyat, iade, ödeme, müşteri verisi ve sözleşme kararları için sınır konmalıdır. - **Prompt, bilgi tabanı ve entegrasyon değişiklikleri nasıl test edilir?** Canlıya alma öncesi kontrol yöntemi belirtilmelidir. - **Loglar nerede tutulur ve kim erişir?** Kişisel veri, erişim yetkisi ve saklama süresi burada önemlidir. - **Proje bittiğinde ne devredilir?** Kod, hesaplar, API anahtarları, dokümantasyon, veri şeması ve erişimler işletmeye teslim edilmelidir. Bu liste yalnızca ajans seçmek için gerekli değildir. Sistemin sorumluluğunu üstlenmek için gereklidir. Kapsamı hazırlayan taraf, teknik bağımlılıkları anlaşılır bir dille açıklayabilmelidir. ## Bakım planı olmadan başlamaması gereken AI projeleri Bazı AI projelerine düşük riskli bir pilotla başlanabilir. Ancak aşağıdaki sistemler, bakım ve sahiplik planı olmadan canlıya alınmamalıdır: - Müşterilerle doğrudan konuşan chatbotlar - CRM veya ERP’ye veri yazan otomasyonlar - Teklif, fiyat, stok veya iade kararına dokunan akışlar - Kişisel veri işleyen araçlar - Birden fazla SaaS platformunu birbirine bağlayan sistemler - İşletmenin günlük operasyonuna bağlı agent ve otomasyonlar - Sipariş, katalog veya müşteri verisiyle çalışan e-ticaret araçları KVKK’nın [üretken yapay zeka ve kişisel verilerin korunması rehberi](https://www.kvkk.gov.tr/Icerik/8547/uretken-yapay-zeka-ve-kisisel-verilerin-korunmasi-rehberi-15-soruda), veri işleme risklerinin sistemin tüm yaşam döngüsü boyunca değerlendirilmesi gerektiğini vurgular. Bu nedenle “veriyi sadece API’ye gönderiyoruz” yaklaşımı yeterli değerlendirme değildir. Hangi verinin gönderildiği, hangi amaçla işlendiği, kimin eriştiği ve ne kadar süre saklandığı bilinmelidir. AI, katalog, sipariş veya müşteri süreçlerine daha derinden bağlanacaksa hazır eklenti zincirleri kısa sürede sınır yaratabilir. Bu tür senaryolarda [headless e-ticaret altyapısı](https://designodin.com.tr/ozel/e-ticaret/), entegrasyonları ve özel iş kurallarını daha kontrollü tasarlamak için değerlendirilebilir. ## Hangi durumda hazır araç yeterlidir Her AI projesi özel geliştirme gerektirmez. Basit bir işi gereksiz yere karmaşık mimariye çevirmek de teknik borç yaratır. Doğru çözüm; risk, işlem hacmi, veri hassasiyeti ve entegrasyon karmaşıklığı dikkate alınarak belirlenir. Hazır araçlar çoğunlukla şu koşullarda yeterlidir: - İç ekip için taslak metin veya özet üreten araçlar - İnsan onayıyla kullanılan içerik destek akışları - Kritik sisteme veri yazmayan kişisel verimlilik otomasyonları - Sınırlı kullanıcıyla yürütülen kısa pilotlar - Hassas müşteri verisi kullanmayan araştırma ve fikir üretme süreçleri Örneğin operasyon ekibi toplantı notlarını özetlemek, satış temsilcisi teklif taslağı hazırlamak veya sosyal medya ekibi ilk metin seçeneklerini üretmek için hazır araç kullanabilir. Buradaki amaç sistemin bağımsız işlem yapması değildir. İnsanların daha hızlı karar vermesidir. Küçük bir ekibin gelen müşteri taleplerini sınıflandırmak için bir AI aracı kullanmaya başladığını düşünün. Araç yalnızca öneri üretiyor, CRM kaydını satış temsilcisi açıyor. İlk aşamada bu doğru bir karardır. Talep hacmi artıp araç CRM’e otomatik yazmaya başladığında ise risk değişir. Loglama, alan eşleme, yetki ve hata bildirimi artık zorunlu hale gelir. Pilot ile kalıcı sistem arasındaki çizgiyi açıkça belirleyin. Pilot dönemde kabul edilen geçici istisnalar, canlı sistemin görünmeyen mimarisine dönüşmemelidir. ## AI projesini kurulum değil, yaşam döngüsü olarak planlayın Yapay zeka projesi, bir kez kurulup unutulacak bir web formu değildir. Model değişir, veri eskir, iş kuralları güncellenir. Kullanıcılar sistemi başlangıçta tasarlandığı gibi kullanmaz. Bunlar istisna değil, ürünün olağan yaşam döngüsüdür. MLOps’un teknik tanımı geniştir. İşletme açısından karşılığı daha basittir: AI sistemini yalnızca canlıya almak değil, çalışırken ölçmek, güncellemek, test etmek ve gerektiğinde geri çekmek için süreç kurmaktır. Küçük bir chatbot için ağır kurumsal altyapı gerekmez. Ancak her sistemin bir sahibi, veri sorumlusu, değişiklik kaydı ve geri dönüş planı olmalıdır. Yapay zeka teknik borcu, hızlı başlamanın zorunlu bedeli değildir. Sistemin sahibi, bakım kapsamı, test planı ve veri sorumluluğu baştan yazılırsa AI projesi işletmenin üzerinde kalan bir yük değil, yönetilebilen bir araç olur. ## Sık sorulan sorular ### Yapay zeka teknik borcu nedir? Yapay zeka teknik borcu, bir AI sistemini hızla canlıya almak için verilen ve sonradan bakım, veri, entegrasyon, model değişikliği, güvenlik ve test maliyeti olarak geri dönen teknik kararlardır. ### Yapay zeka projesi neden sürekli bakım ister? Model sağlayıcıları, API’ler, veri kaynakları, iş kuralları ve kullanıcı davranışları zamanla değişir. Sistem canlıda kaldığı sürece bu değişiklikler takip edilmeli, test edilmeli ve yönetilmelidir. ### Yapay zeka bakım anlaşması neleri kapsamalı? Model ve API değişimleri, hata takibi, log incelemesi, prompt ve bilgi tabanı güncellemeleri, maliyet izleme, erişim kontrolleri, test senaryoları ve küçük yapılandırma değişiklikleri açıkça belirtilmelidir. ### Model değişirse AI uygulaması çalışmayı bırakır mı? Uygulama çalışmaya devam edebilir, fakat aynı kaliteyi veya aynı çıktı formatını koruyacağı garanti edilemez. Yeni model; maliyet, hız, doğruluk, güvenlik ve entegrasyon açısından test edilmelidir. ### AI chatbotta insan onayı ne zaman gerekir? İade, ödeme, fiyat, sözleşme, müşteri verisi, sağlık, hukuk veya finansal sonuç doğuran işlemlerde insan onayı ya da açık işlem sınırları gerekir. ### Yapay zeka teknik borcu nasıl azaltılır? Teknik borç; sistem bileşenlerini dokümante ederek, model ve prompt sürümlerini izleyerek, veri kaynaklarına sahip atayarak, log tutarak, test senaryoları oluşturarak ve bakım kapsamını yazılı hale getirerek azaltılır. **Yapay zeka otomasyonunuzun bakım borcunu ilk günden görün.** Designodin, AI destekli sistemleri yalnızca ilk demo için kurmaz. Veri akışı, erişim, test, model değişikliği ve uzun vadeli sahiplik planını baştan ele alır. [AI çözümlerimizi inceleyin](https://designodin.com.tr/yapay-zeka/) [Teklif alın](https://designodin.com.tr/iletisim/) - #yapay-zeka - #teknik-borc - #ai-otomasyon - #bakim-maliyeti ## Bu konu sizin işinizde nasıl karşılık buluyor? Genel geçer cevaplar yerine, sizin durumunuza bakalım. Kapsamı ve teklifi yazılı olarak veririz — satış baskısı yok. [Projenizi anlatın →](https://designodin.com.tr/iletisim/)