---
title: "Yapay Zeka Entegrasyon Partneri Nasıl Seçilir | Designodin Türkiye"
description: "Yapay zeka entegrasyon partneri seçerken iş problemi, KVKK, güvenlik, pilot, sahiplik ve bakım için sorulacak 12 soruyu görün."
source: https://designodin.com.tr/blog/yapay-zeka-entegrasyon-partneri-nasil-secilir
---

[← Tüm yazılar](https://designodin.com.tr/blog/)
[AI](https://designodin.com.tr/blog/kategori/ai/)

# Yapay Zeka Entegrasyon Partneri Nasıl Seçilir

29 Eylül 2026 · Designodin

“Yapay zeka entegrasyon partneri nasıl seçilir?” sorusunun kısa yanıtı şu: Partner, iş sorununuzu, mevcut sistemlerinizi, veri risklerini, pilotun başarı kriterlerini ve proje sonrasındaki sahipliği yazılı biçimde ortaya koyabilmelidir. Model adı, etkileyici bir chatbot demosu veya “AI ajanı” etiketi tek başına yetkinlik göstermez.

Bir yapay zeka projesindeki en pahalı hata, yanlış modeli seçmek değildir. Asıl hata; iş akışınızı, müşteri verilerinizi ve ekibinizin çalışma alışkanlıklarını hesaba katmadan kurulan bir sistemdir. İşleyen bir demo ile canlı ortamda güvenilir çalışan bir sistem aynı şey değildir.

Bu metin, teklifleri aynı çerçevede karşılaştırmanız için hazırlanmıştır. Hangi işlerin gerçekten AI gerektirdiğini, hangi teknik yanıtların konuyu geçiştirdiğini ve proje bittiğinde size ne kalması gerektiğini açıklar.

**Öne Çıkanlar**

- Kuralı önceden belli işler için AI değil, standart otomasyon daha basit ve denetlenebilirdir.
- İyi bir AI partneri modelden önce veri akışını, kullanıcı yetkilerini ve hata senaryolarını çıkarır.
- Pilotun kapsamı, test verisi, başarı eşiği ve insan onayı canlıya geçmeden önce yazılı olmalıdır.
- KVKK için “uyumluyuz” cevabı yetmez; veri aktarımı, saklama, erişim ve silme süreci açıklanmalıdır.
- Kaynak kod, prompt’lar, bilgi tabanı, erişimler ve dokümantasyon devredilmiyorsa satın aldığınız şey tam bir entegrasyon değildir.

## Önce Şunu Ayırın: AI Entegrasyonu mu, Basit Otomasyon mu?

Her iş sürecine yapay zeka eklemek doğru değildir. Gereksiz bir AI katmanı maliyeti artırır, hata ihtimalini yükseltir ve denetimi zorlaştırır.

Kural baştan belliyse otomasyon yeterlidir. Anlamlandırma gerektiğinde yapay zeka kullanılır.

### AI gerektirmeyen işler

Aşağıdaki işler çoğu durumda standart otomasyon araçları veya mevcut yazılım kurallarıyla çözülebilir:

- Form geldiğinde ilgili satış temsilcisine e-posta göndermek

- Stok belirli seviyenin altına düştüğünde bildirim oluşturmak

- Sipariş durumu değiştiğinde müşteriye hazır mesaj iletmek

- Belirli bir alana göre CRM kaydı veya görev açmak

- Takvimde uygun saate toplantı daveti göndermek

Bu süreçlerde karar zaten önceden verilmiştir. “Sipariş kargoya verildiyse müşteriye takip bağlantısını ilet” kuralında dil modeli kullanmak, basit bir yapıyı gereksiz yere karmaşıklaştırır.

### AI’ın anlamlı olduğu işler

AI; serbest metni yorumlamak, bağlam kurmak veya dağınık bilgileri işleyip taslak hazırlamak gerektiğinde faydalıdır.

Örnekler:

- Web formu, WhatsApp ve e-postadan gelen talepleri konu, aciliyet ve satın alma niyetine göre sınıflandırmak

- Şirket prosedürlerinden kaynak göstererek çalışan sorularını yanıtlamak

- Satış görüşmelerini özetlemek, aksiyon maddelerini ve CRM taslağını çıkarmak

- Binlerce müşteri mesajındaki tekrar eden şikâyet veya ürün sorusunu bulmak

- İnsan onayına sunulacak teklif, yanıt veya içerik taslağı hazırlamak

Müşteri hizmetleri asistanı kurmak isteyen bir e-ticaret markasını düşünün. İlk fikir, bütün soruları yanıtlayan bir chatbot oluşturmaktır. Ancak iade süresi, kargo takibi ve ürün ölçüsüyle ilgili soruların büyük bölümü zaten kurallara bağlıdır. Asıl sorun, müşterilerin serbest metinle ilettiği karmaşık taleplerin doğru ekibe aktarılamamasıdır. Uygun proje, “her şeyi bilen bot” değil; mesajı sınıflandıran ve temsilci için kaynaklı taslak hazırlayan daha sınırlı bir sistemdir.

Bu ayrım yapılmazsa, çözülebilir bir operasyon sorunu maliyetli bir AI demosuna dönüşebilir.

## İyi Partner İş Problemiyle Başlar, Model İsmiyle Değil

“GPT kullanıyoruz”, “özel agent mimarimiz var” veya “RAG kuruyoruz” demek teknik yetkinliği kanıtlamaz. Bunlar araç ve yöntem adlarıdır. Esas soru, seçilen yöntemin hangi iş sonucuna bağlandığıdır.

İyi bir partnerin ilk toplantıda odağı model değil, süreç olmalıdır. Size şu soruları sormalıdır:

- Ekip hangi aşamada en çok zaman kaybediyor?

- Sistemi kimler kullanacak ve hangi yetkilerle kullanacak?

- Hangi veri kaynağı güncel ve güvenilir?

- Yanlış yanıtın veya yanlış aksiyonun ticari maliyeti nedir?

- İnsan onayı hangi noktada zorunlu?

- Başarıyı hangi ölçümle değerlendireceğiz?

Bir satış ekibini ele alalım. Gelen taleplerin yarısı niteliksiz olabilir, bazılarıysa aynı gün yanıt bekler. AI burada lead’leri önceliklendirebilir, görüşme notlarını özetleyebilir ve teklif taslağı hazırlayabilir. Ancak fiyat onayı vermemeli, sözleşme göndermemeli veya müşteri adına bağlayıcı taahhütte bulunmamalıdır.

Bu sınır baştan tanımlanmalıdır. “Her şeyi tamamen otonom yaparız” ifadesi, çoğu işletme için vizyon değil kontrol kaybıdır.

### Dar kapsamlı pilot neden daha güvenlidir?

İlk projede tek bir kullanım senaryosuna odaklanmak teknik ve ticari riski azaltır. Örneğin şirket içi bilgi asistanı kurulacaksa, ilk aşamada tüm belge arşivini bağlamak yerine yalnızca satış prosedürleri ve güncel teklif şablonlarıyla başlamak daha uygundur.

Tüm departmanların sorularını yanıtlayan bir bilgi asistanı isteyen bir B2B şirketini varsayalım. İlk kapsam satış, finans, İK ve teknik destek dokümanlarının tamamını içerir. Partner, önce satış ekibinin sık kullandığı 80 dokümanla pilot yapılmasını önerir. Test sırasında eski fiyat listelerinin hâlâ klasörde durduğu görülür. Bu durum canlıya geçtikten sonra fark edilseydi, asistan hatalı teklif bilgileri üretecekti. Pilot böylece modeli değil, veri disiplinini sınamış olur.

NIST’in üretken AI profili, sistemlerin canlıya alınmadan önce test, değerlendirme, doğrulama ve geçerleme süreçlerinden geçirilmesini önerir. Bu süreçlerin belgelenmesi de aynı derecede önemlidir. [NIST Generative AI Profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf), “çalışıyor gibi görünen” sistem ile kabul edilmiş sistem arasındaki farkın neden yazılı olması gerektiğini açıkça ortaya koyar.

## Demo Değil, Mevcut Sistemlerinize Bağlantı Satın Alın

Bir sohbet arayüzü kurmak kolay olabilir. Asıl iş, bu ekranın doğru müşteri ve sipariş verilerine uygun yetkilerle erişmesini sağlamaktır.

Demo genellikle temiz test verileriyle çalışır. Canlı sistem ise CRM, ERP, e-ticaret altyapısı, e-posta, ürün kataloğu, stok sistemi, destek paneli veya WhatsApp gibi farklı kaynaklara bağlanır. Bu entegrasyonlar doğru tasarlanmazsa AI, doğru görünmesine rağmen yanlış bilgi üreten bir arayüze dönüşür.

Partner teklifinde şu soruların yanıtları açıkça yer almalıdır:

- Hangi API’lere veya veri kaynaklarına bağlanılacak?

- Veri akışı tek yönlü mü, çift yönlü mü olacak?

- Kullanıcı yetkileri rol bazlı mı tasarlanacak?

- Bir işlem başarısız olduğunda sistem ne yapacak?

- Yanlış başlatılan bir işlem geri alınabilecek mi?

- Log kayıtları nerede tutulacak ve kim görebilecek?

- API kesintisi veya model sağlayıcısı hatasında süreç nasıl devam edecek?

### Chatbot, AI ajanı ve otomasyon aynı şey değildir

Bu üç kavram tekliflerde sıkça birbirine karıştırılır. Oysa taşıdıkları risk aynı değildir.

**Chatbot**, genellikle kullanıcının sorusuna yanıt üretir. Örneğin ürün özelliklerini açıklar veya bir destek makalesine yönlendirir.

**AI ajanı**, belirlenmiş sınırlar içinde araçlara erişebilir ve işlem başlatabilir. CRM kaydı oluşturabilir, sipariş durumunu sorgulayabilir veya taslak e-posta hazırlayabilir.

**Otomasyon** ise önceden tanımlanmış kuralları uygular. Bir form alanında “iade” geçiyorsa destek ekibine görev açmak otomasyondur.

AI ajanı daha fazla işlem yapabildiği için daha sıkı kontrol gerektirir. Özellikle müşteri verilerine erişen veya başka sistemlerde işlem başlatan ajanlarda yetki sınırı, insan onayı ve geri alma mekanizması yazılı olmalıdır.

E-ticaret tarafında bu ayrım daha da kritiktir. Bir asistanın ürün bilgisi vermesi başka, müşterinin sipariş geçmişine erişmesi başka, iade başlatması ise bambaşka bir risk seviyesidir. Büyük katalog, özel ticari akış veya birden fazla kanal kullanan işletmelerde [headless e-ticaret](https://designodin.com.tr/ozel/e-ticaret/) mimarisi; veri, storefront ve iş kurallarını daha kontrollü ayırmak için değerlendirilebilir. Ancak mimari tercihi, AI etiketi uğruna değil, gerçek operasyon ihtiyacı için yapılmalıdır.

## Veri Güvenliği ve KVKK Cevabı “Merak Etmeyin” Olamaz

Yapay zeka entegrasyonu müşteri mesajları, siparişler, çalışan dokümanları veya satış kayıtlarıyla temas ediyorsa veri güvenliği proje planının kenarında kalamaz. Teslimin ana parçalarından biri olmalıdır.

“KVKK uyumluyuz” demek tek başına yeterli değildir. Bu ifade hangi verinin işlendiğini veya verinin nereye aktarıldığını açıklamaz.

Partnerin aşağıdaki bilgileri yazılı olarak sunabilmesi gerekir:

- Hangi kişisel veriler işlenecek?

- Veri hangi sağlayıcıya ve hangi ülkeye aktarılacak?

- Veriler model eğitimi için kullanılacak mı?

- Veriler ne kadar süre saklanacak?

- Hangi kullanıcı hangi belgeye erişebilecek?

- Erişim kayıtları tutulacak mı?

- Kullanıcı verisi silinmek istendiğinde süreç nasıl işleyecek?

- Alt yükleniciler veya üçüncü taraf araçlar hangileri?

KVKK Kurumu’nun [Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi](https://www.kvkk.gov.tr/Icerik/8547/uretken-yapay-zeka-ve-kisisel-verilerin-korunmasi-rehberi-15-soruda), üretken AI yaşam döngüsündeki kişisel veri işleme faaliyetlerine odaklanır. Bu yüzden veri işleme tasarımı, proje başladıktan sonra hukuk ekibine bırakılacak bir madde değildir.

### Prompt injection ve hassas bilgi ifşası

Prompt injection, kullanıcının veya bağlı bir dokümanın sistem talimatlarını ihlal etmeye çalışmasıdır. Örneğin kullanıcı, asistanın “yalnızca kendi siparişini göster” kuralını aşmak için metne farklı yönergeler ekleyebilir. Bağlı belgeler de kötü niyetli içerik barındırabilir.

OWASP’ın [LLM uygulamaları için Top 10 listesi](https://genai.owasp.org/llm-top-10/), prompt injection ve hassas bilgi ifşasını temel riskler arasında sayıyor. Sistem prompt’una “gizli verileri paylaşma” yazmak güvenlik kontrolü değildir.

Gerekli denetimler şunları kapsar:

- Rol bazlı erişim ve kullanıcı doğrulama

- Kaynaklara belge veya müşteri bazında erişim sınırı

- Hassas alanların maskelemesi

- Çıktı filtreleme ve kayıt altına alma

- Kötü niyetli girdilerle düzenli test

- Kritik aksiyonlarda insan onayı

## Pilotun Başarısı Demo ile Değil, Kabul Kriteriyle Ölçülür

“Önce bir MVP yapalım” yaklaşımı doğru bir başlangıç olabilir. Ancak MVP’nin hangi koşulda başarılı sayılacağını belirtmeyen teklif, belirsizliği sadece ileri bir tarihe bırakır.

İyi bir pilot beş bölümden oluşur:

- **Tek iş akışı:** Örneğin yalnızca kargo ve iade sorularının sınıflandırılması.

- **Sınırlı kullanıcı grubu:** İlk aşamada tüm şirket değil, belirli bir ekip.

- **Temsilî test verisi:** Gerçek hayattaki istisnaları içeren, temizlenmiş örnekler.

- **Ölçülebilir başarı metriği:** İlk yanıt süresi, doğru yönlendirme oranı veya kaynak gösterme oranı.

- **İnsan onayı ve geri alma akışı:** Hatalı çıktı veya aksiyonda kimin devreye gireceği.

Pilot teklifinde ayrıca şu başlıklar bulunmalıdır:

- Pilot kapsamı dışında kalan işler

- Başarı eşiği ve ölçüm yöntemi

- Test senaryoları

- Hata sınıfları ve öncelik seviyesi

- İnsan müdahalesi gereken noktalar

- Pilot sonrası karar tarihi

- Canlıya geçiş şartları

Örneğin bir toplantı özeti sisteminde başarı, “özet üretti” diye tanımlanamaz. Daha anlamlı ölçütler; temsilcilerin kaçının özeti düzenleyip kullandığı, aksiyon maddelerinin ne kadar doğru belirlendiği ve CRM’e aktarılan taslakların hangi oranda onay aldığıdır.

Pilotun amacı, AI’ın etkileyici görünüp görünmediğini değil; tanımlı sınırlar içinde işletmenize güvenle hizmet edip etmediğini ölçmektir.

**Teklifinizde pilotun kabul kriterleri yoksa, canlıya geçiş kararı da ölçüme değil yoruma dayanır.** [Yapay zeka yaklaşımımız](https://designodin.com.tr/yapay-zeka/), araç seçimini iş problemi, veri akışı ve kontrol tasarımıyla birlikte ele alır.

## Sahiplik Sorusu: Proje Bittiğinde Elinizde Ne Kalacak?

AI projelerinde bağımlılık çoğu zaman ilk anda görünmez. Sistem çalışır, partner yönetimi yürütür ve birkaç üçüncü taraf araç kullanılır. Ancak partneri değiştirmek istediğinizde erişimlerin, prompt’ların veya entegrasyon bilgisinin sizde olmadığı ortaya çıkabilir.

Her SaaS ürünü veya model sağlayıcısı kötü değildir. Sorun, sağlayıcı değiştiğinde verinizi, iş akışınızı ve sistemi taşıyamamaktır.

Proje bittiğinde size devredilmesi veya en azından erişilebilir biçimde teslim edilmesi gereken unsurlar şunlardır:

- Projeye özel kaynak kod

- Entegrasyon mimarisi ve teknik dokümantasyon

- API anahtarları ile erişim yönetimi

- Prompt’lar ve sistem talimatları

- Bilgi tabanı yapısı ve veri yükleme süreci

- Test senaryoları ile değerlendirme setleri

- İzleme paneli veya log erişimi

- Bakım, güncelleme ve acil durum dokümanı

Bu unsurlar her projede aynı yöntemle uygulanmaz. Ancak hangisinin neden size devredilmediği açıkça anlatılmalıdır. “Kod size gerekmez, biz yönetiriz” sözü operasyonel kolaylık gibi sunulabilir. Gerçekte çıkış maliyetini görünmez kılabilir.

Partner değiştirmek isteyen bir şirketi düşünün. Asistan çalışıyordur, fakat bilgi tabanı yalnızca önceki ajansın hesabından yönetiliyordur. API anahtarları kişisel hesaplardadır, test kayıtları başka bir araçtadır ve prompt’ların güncel sürümü dokümante edilmemiştir. Yeni ekip sistemi devralmak yerine neredeyse baştan kurmak zorunda kalır. Sorun AI’ın çalışmaması değil, sahipliğin başta tanımlanmamış olmasıdır.

## Teklifleri Karşılaştırmak İçin 12 Soru

Ajans, danışman veya yazılım firması tekliflerini bu 12 soruyla aynı çerçevede inceleyin:

- Hangi iş problemini çözüyorsunuz ve bunun AI gerektirdiğini nasıl doğruladınız?

- Mevcut sistemlerimizden hangilerine bağlanacaksınız?

- Hangi veriler işlenecek, nerede saklanacak ve kim erişebilecek?

- Kullanılan model veya servis değişirse sistem nasıl etkilenir?

- Yanlış yanıt veya yanlış aksiyonda insan onayı nerede devreye girer?

- Prompt injection, yetkisiz veri erişimi ve hatalı çıktı için hangi testleri yapacaksınız?

- Pilotun başarı kriteri nedir?

- Başarıyı hangi veriyle ve hangi sıklıkta raporlayacaksınız?

- Model kullanımı, altyapı, üçüncü taraf araçlar ve bakım maliyetleri ayrı ayrı yazılı mı?

- Kod, dokümantasyon, prompt’lar ve entegrasyon erişimleri proje sonunda kime ait olacak?

- Canlıdan sonra hata, model değişikliği veya API kesintisinde sorumluluk kimde olacak?

- Partner değiştirirsek sistemin devri nasıl yapılacak?

Bu soruların amacı karşı tarafı sıkıştırmak değildir. Amaç, işin gerçek kapsamını görünür hale getirmektir. Güçlü bir partner bu soruları sorun saymaz; yanıtlarını zaten teklifinde verir.

## Kırmızı Bayraklar: Bu Cevaplarda Durun

Bazı ifadeler, teknik ayrıntılara girmeden önce bile riski gösterir.

- **“Önce başlayalım, kapsamı sonra netleştiririz.”** Kapsam belirsizse teslim, süre ve sorumluluk da belirsizdir.

- **“KVKK tarafını merak etmeyin.”** Veri akışı bilinmeden verilen güvence, güvence değildir.

- **“Her şeyi tamamen otonom yaparız.”** İnsan onayı olmayan kritik aksiyonlar işletme riskini büyütür.

- **“Model bizim özel teknolojimiz; ayrıntı paylaşamayız.”** Ticari sır olabilir, ancak veri işleme, erişim ve hata kontrolü gizli bırakılamaz.

- **“Kod size gerekmez, biz yönetiriz.”** Bu yaklaşımın çıkış planı ve devir koşulları yazılı değilse bağımlılık yaratır.

- **“Başarıyı canlıya alınca görürüz.”** Pilotun başarı ölçütü canlıdan önce belirlenmelidir.

- **“Bakım ihtiyacına sonra bakarız.”** Model, API, veri kaynağı ve iş süreçleri değişir. Bakım sonradan ortaya çıkan istisna değildir.

- **“Hangi veriye erişeceğimizi süreçte belirleriz.”** Yetki ve veri sınırı tasarımın ilk maddelerindendir.

Doğru partner, aracı kurduktan sonra da süreçte kalır. Hangi verilerin kullanılacağını, sistemin hangi sınırlar içinde çalışacağını, insanın hangi noktada devreye gireceğini ve proje sonunda neleri devralacağınızı baştan yazar.

Yapay zeka entegrasyonu yalnızca bir yazılım tercihi değildir. Aynı zamanda mimari, güvenlik, sahiplik ve operasyon kararıdır. Bu dört başlık teklifte yoksa, satın aldığınız şey entegrasyon değil, süresi belirsiz bir denemedir.

## Sık Sorulan Sorular

### Yapay zeka entegrasyon partneri seçerken ilk bakılması gereken nedir?

Önce çözülecek iş problemi ele alınmalıdır. Ardından veri erişimi, başarı metriği, mevcut sistemlerle bağlantı ve teknik entegrasyon kapasitesi değerlendirilmelidir.

### Her otomasyon işi için yapay zeka gerekir mi?

Hayır. Kuralı önceden belirlenmiş işler için standart otomasyon daha sade, daha düşük riskli ve daha kolay denetlenebilir bir seçenektir. AI; serbest metni anlamak, sınıflandırmak veya bağlama göre yanıt üretmek gerektiğinde anlamlı hale gelir.

### Yapay zeka partneri KVKK konusunda hangi bilgileri vermelidir?

İşlenecek veri türleri, saklama süresi, veri aktarım noktaları, erişim yetkileri, silme prosedürü ve kullanılan üçüncü taraf sağlayıcılar yazılı olarak belirtilmelidir.

### AI pilot projesi ne kadar kapsamlı olmalı?

Pilot; tek bir iş akışı, sınırlı bir kullanıcı grubu, temsilî veri ve önceden belirlenmiş bir başarı kriteriyle başlamalıdır. Tüm şirketi kapsayan ilk proje, hatanın etkisini büyütür.

### Yapay zeka entegrasyonunda kod ve veri kime ait olmalı?

Projeye özgü kod, entegrasyon dokümantasyonu, erişim yönetimi, bilgi tabanı yapısı ve test çıktıları müşterinin erişebileceği ve devralabileceği formatta teslim edilmelidir.

### AI ajanı ile chatbot arasındaki fark nedir?

Chatbot çoğunlukla yanıt üretir. AI ajanı ise belirlenmiş sınırlar içinde araçlara veya sistemlere bağlanıp işlem başlatabilir. Bu nedenle ajanlarda güvenlik, yetkilendirme ve insan onayı ihtiyacı daha yüksektir.

### Yapay zeka projesinde bakım neden gerekir?

Model sağlayıcıları, API’ler, veri kaynakları ve iş süreçleri değişir. Canlı sistemin güvenliği, maliyeti, hata kayıtları ve çıktı kalitesi düzenli olarak takip edilmelidir.

**Yapay zeka projenizin kapsamını denemeye başlamadan netleştirin.**

Designodin, AI fikrini iş akışı, veri erişimi, güvenlik sınırları, pilot kabul kriteri ve teslim sonrası sahiplikle birlikte ele alır. Araç listesi yerine, kontrol edilebilir bir sistem kapsamı oluşturur.

[Projenizi anlatın, yazılı kapsam çıkaralım.](https://designodin.com.tr/iletisim/)

- #yapay-zeka
- #ai-entegrasyonu
- #kvkk
- #ajans-secimi

## 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/)
