Forward Deployed AI Engineer Nedir, Ne Yapar?

Forward Deployed AI Engineer, yapay zekâ çözümünü işletmenin gerçek çalışma ortamına taşıyan teknik bir roldür. İşi yapan kişilerle süreci öğrenir, gerekli verileri ve sistemleri bağlar, çözümü geliştirir ve kullanıcıların günlük işinde nasıl çalıştığını değerlendirir. Yaygın kısaltması FDE. Rolün kapsamı çalışılan şirkete, ürüne ve müşteri ihtiyacına göre değişir.

Bir modelin iyi cevap üretmesiyle bir çalışanın işini tamamlayabilmesi aynı şey değildir. FDE’nin ilgilendiği boşluk buradadır: doğru kaydı bulmak, gerekli yetkiyi korumak, sonucu kontrol etmek ve çözümü ekibin kullanabileceği hâle getirmek.

Ben Oğuz Erol. Bu yaklaşımla bağım, işletmeye özel web uygulamaları geliştirirken süreç, kullanıcı rolleri ve veri bağlantılarını birlikte ele almam. Aşağıda önce mesleğin ne yaptığını, ardından bu çalışma biçiminin somut bir işe nasıl uygulanabileceğini anlatıyorum.

FDE adı neyi anlatır?

“Forward deployed”, işi yapan ekibin veya müşterinin yakınına yerleşerek çalışmayı anlatır. Yalnız yazılımı sunucuya yüklemek anlamına gelmez. “Forward Deployed Engineer” genel ad, “Forward Deployed AI Engineer” yapay zekâ odağını açık eden varyanttır. “FDSE” ise yazılım vurgulu “Forward Deployed Software Engineer” adıdır.

Palantir’in FDSE ilanında müşteriyle yan yana sorun çözme, özel uygulama geliştirme ve fikirden dağıtıma kadar teknik sahiplik birlikte bulunuyor. Bu, rolün yalnız öneri hazırlamaktan daha geniş olabildiğini gösterir. Unvanın bulunduğu her şirkette aynı görev sınırları olduğunu göstermez. Palantir’in rol açıklaması

Burada “müşteri” her zaman dışarıdaki alıcı değildir. Bir kurumun finans veya operasyon ekibi de çözümün kullanıcısı olabilir. Rolü anlamanın yolu, unvandan sonra kimin problemi üzerinde çalışıldığını ve teknik teslimin nerede bittiğini okumaktır.

FDE ne iş yapar?

Belirsiz bir ihtiyacı, sınırları ve kontrol yöntemi belli bir teknik çalışmaya dönüştürür. “Raporlamayı AI ile hızlandıralım” talebi, hangi kayıtların karşılaştırılacağı ve hangi kararın kimde kalacağı anlaşılmadan uygulama tanımı sayılmaz.

FDE’nin ele alabileceği işler şunlardır:

1. İşi yerinde anlamak: Çalışanın bir kaydı nasıl tamamladığını, nerede beklediğini ve istisnaları nasıl çözdüğünü gözlemek.
2. Veriyi ve erişimi belirlemek: Bilginin hangi sistemde güncel olduğunu, neyin okunup yazılabileceğini ve bağlantının kime ait olduğunu bulmak.
3. İlk kapsamı seçmek: Çözülecek iş, dışarıda bırakılan adımlar ve kabul koşulları üzerinde anlaşmak.
4. Çözümü geliştirmek: Gerekli arayüz, servis, veri akışı, model çağrısı ve sistem bağlantılarını kodlamak.
5. Doğrulamak: Normal kayıtların yanında eksik, yanlış, tekrarlı ve yetki dışı durumları denemek.
6. Kullanıma almak: İzleme, hata yönetimi, maliyet ve devam sorumluluğunu belirlemek.
7. Öğrenileni aktarmak: İşe yarayan düzeni tekrar kullanılabilir bileşene, ürün düzeltmesine veya sonraki geliştirmeye dönüştürmek.

Bu sıra, incelediğim rollerden çıkardığım açıklama çerçevesidir; bütün şirketlerin aynı prosedürü kullandığı iddiası değildir. Databricks’in AI FDE ilanı, müşterilerin GenAI uygulamalarını geliştirme ve gerçek kullanıma alma işini professional services kapsamında anlatıyor. Databricks AI FDE ilanı

Günlük akış ve somut teslimler nasıl görünür?

Gün, kullanıcıyla görüşmek ile kod geliştirmek arasında gidip gelebilir. Sabah bir çalışanın bekleyen kaydı nasıl çözdüğünü izlemek, ardından API hatasını gidermek, örnek çıktıları kontrol etmek ve öğleden sonra tasarımı ekip ile denemek aynı işin parçaları olabilir. Bu, örnek bir gün akışıdır; sabit mesai çizelgesi değildir.

Her projede bu teslimlerin hepsi aynı biçimde bulunmaz. Önemli olan, yalnız sunum veya ekran görüntüsüyle yetinmemektir. Sistemin doğru kaydı neye göre seçtiği, başarısız olduğunda nasıl davrandığı ve işi kimin sürdüreceği açıklanabilmelidir.

İşin kullanıcıyla buluşması neden önemlidir?

Gerçek kullanım, masa başındaki tasarımın eksiklerini görünür kılar. Uygulama veriyi doğru çıkarabilir ama çalışan düzeltme ekranını anlayamayabilir. Yanıt doğru olabilir ama dayandığı belge eski kalabilir. Bu durumda sorun yalnız modelin cevabını değiştirmekle çözülmez.

OpenAI kendi FDE modelinde üretimde öğrenmeyi ve bulguları ürün/araştırma ekiplerine taşımayı vurguluyor. Aynı sayfa, kendi FDE’lerini professional services olarak tanımlamıyor; uygulama ortaklarıyla birlikte, mevcut AI yeteneklerinin sınırındaki sorunlara odaklandığını söylüyor. Bu, OpenAI’nin organizasyon tercihi; bütün FDE’lere veya bağımsız geliştiricilere genellenemez. OpenAI’nin FDE çalışma modeli

Geri bildirim “kullanıcı beğendi” cümlesinden daha somut olmalıdır. Hangi adımda iş kesildi? Kaynak veri mi eksik, erişim mi yanlış, model mi yetersiz? Çözüm tek müşteriye özgü mü, ürünün başka kullanıcılarına da yarar mı? Bu ayrım, yerel düzeltme ile ortak ürün geliştirmesini birbirine bağlar.

AI engineer, danışman ve prompt engineer’dan farkı nedir?

Fark çoğunlukla sorumluluğun ağırlık merkezindedir; kesin meslek duvarları değildir. Kod yazan danışmanlar, müşteriyle çalışan AI mühendisleri ve üretim sorumluluğu üstlenen ürün ekipleri vardır.

Together’ın model çalıştırma (inference) odaklı FDE ilanı, solutions architect’in yerine geçen birinden değil, onunla birlikte çalışan derin alan uzmanından söz ediyor. Aynı FDE adı, bir şirkette uygulamaya, diğerinde model çalıştırma altyapısına yakın olabilir. Together rol açıklaması

Bu yüzden iş veya hizmet kapsamını değerlendirirken “Kim kod yazacak, kim kullanıma alacak, müşteriyle kim karar verecek ve sonrasında kim işletecek?” soruları unvandan daha açıklayıcıdır.

Hangi beceriler birlikte gerekir?

Yazılım geliştirme ile iş problemini çözme yeteneğinin birlikte çalışması gerekir. API, SQL, veri modeli, kimlik doğrulama ve hata yönetimi gibi temeller AI katmanının altında kalır; model kullanmak bunları ortadan kaldırmaz.

AI tarafında yapılandırılmış çıktı, kaynakla desteklenen cevap, araç çağrısı ve değerlendirme önem kazanabilir. Değerlendirme, sistemin beklenen işi temsilî kayıtlarda yapıp yapmadığının kontrolüdür. Sadece birkaç başarılı yanıt görmek yeterli değildir; hatanın hangi koşulda oluştuğunu da bilmek gerekir. Scale’ın ilanı test veri kümeleri, regresyon kontrolü, izleme ve insan denetimini üretim işinin parçası olarak ele alıyor. Scale’ın mühendislik kapsamı

Teknik kararın kullanıcıya anlaşılır anlatılması da gerekir. Bir yönetici “bu bağlantı neden bekliyor?” diye sorduğunda, yalnız araç adı değil, bağımlılık ve iş etkisi açıklanmalıdır. Belgeden getirilen kaynaklarla cevabı destekleyen RAG uygulamalarında da kaynak güncelliği ve kullanıcı yetkisi birlikte tasarlanır.

Örnek: satın alma kaydını çalışan bir akışa dönüştürmek

Aşağıdaki senaryo geliştirilebilecek bir tasarımdır; tamamlanmış müşteri vakası veya başarı sonucu değildir. Bir şirketin sipariş, teslim kaydı ve fatura belgelerini farklı yerlerde tuttuğunu düşünelim. Muhasebe, hangi belgenin hangi siparişe ait olduğunu elle araştırıyor.

Önce işi ve kayıtların anlamını öğrenmek

İlk soru “hangi model?” değildir. Siparişi kim açıyor, kısmi teslim nasıl işaretleniyor ve fatura farkını kim kabul ediyor? Çalışanla temsilî bir kayıt baştan sona izlenir. Eksik teslim, iade veya belge düzeltmesi gibi durumlar ayrı adımlar olabilir.

Başlangıç durumu kaydedilir: nerede bekleniyor, hangi alan tekrar giriliyor, hangi farkların açıklaması aranıyor? Ölçülmemiş bir zaman tasarrufu yüzdesi hedef diye yazılmaz. İlk kapsam, örneğin farkların bulunması ve yetkiliye gösterilmesiyle sınırlanabilir.

AI, kurallar ve insan kararını ayırmak

AI faturadan tarih, tutar ve açıklama alanlarını taslak olarak çıkarabilir. Yazılım, tanımlı hesap ve mükerrerlik kurallarını uygular. Eşleşme belirsizse sonucu kesinleştirmek yerine incelemeye yollar. Yetkili çalışan belgeyi kaynak kayıtla yan yana görerek kabul eder veya düzeltir.

Gerekli veri izinli API’den ya da başlangıçta dosya yükleyerek alınabilir; bu iki bağlantı biçimi aynı şey değildir. Hangi yöntemin mümkün olduğu doğrulanır. Ekran, çalışanın görevine göre alan gösterir. Onay, ödeme emri verme yetkisini kendiliğinden içermez.

Çalışanla denemek ve teslimi doğrulamak

Aynı fatura yeniden geldiğinde ne olur? Bağlantı kesilirse onaylı işlem kaybolur mu? Kullanıcı yetkisi olmayan bir siparişi görebilir mi? Testler bu soruları da kapsar. Çalışan işi uygulamada tamamlar; takıldığı adımlar ve düzeltmeler incelenir.

Somut teslim, belge alanlarını gösteren bir ekrandan fazlasıdır: fark listesi, inceleme kaydı, izinli yazma, işlem geçmişi ve hata durumunun sahibi belli olur. Resmî muhasebe kaydı veya banka işlemi gerekiyorsa bunlar ayrıca kapsamlandırılır. Devamında hangi ekibin bakım yapacağı da açıklanır.

Benim özel uygulama hizmetlerimle kesişim burada somutlaşır: kayıtları, kullanıcı rollerini ve onayları çalışan bir süreç etrafında birleştirebilirim.

FDE yaklaşımı ne zaman mantıklı, ne zaman gereksiz?

Belirsizlik, sistem bağlantıları ve kullanıcıyla birlikte öğrenme ihtiyacı arttığında bu çalışma biçimi daha anlamlı olur. İş açısından önemli bir sorun, süreci bilen kişiler ve erişilebilir veri bulunması da gerekir.

• Birden fazla sistem arasında sürekli elle bilgi taşınıyorsa.
• İlk prototip çalışıyor ama günlük işe yerleşmiyorsa.
• İstisnalar yüzünden tek bir kural veya standart ürün yetmiyorsa.
• Kullanımdan çıkan öğrenmenin ortak ürüne ya da tekrar kullanılabilir çözüme dönmesi bekleniyorsa.

Buna karşılık mevcut programın ayarıyla çözülen bir iş için yeni uygulama gerekmez. Girdisi ve sonucu belli basit bir işlemde normal yazılım veya hazır entegrasyon yeterli olabilir. Her özel yazılım projesine FDE adı vermek, kapsamı daha doğru anlatmaz.

Veriye erişim yoksa veya işi sahiplenecek kullanıcı bulunmuyorsa önce bu engel çözülmelidir. Teknik ekibin tek başına uygulama yapması, işletmenin karar ve kullanım sorumluluğunu üstlenebileceği anlamına gelmez. Sistem kurmakla kurumda benimsenmesini sağlamak birlikte planlanır.

LinkedIn’de FDE talebi ne söylüyor?

Rolün işe alım açısından görünür olduğuna dair resmî bir işaret var. LinkedIn, 29 Eylül 2026 duyurusunda forward-deployed uzmanlara talebin son bir yılda %226 arttığını bildiriyor. Bu metrik için ülke kapsamı ve hesaplama ayrıntıları tam verilmediğinden oranı Türkiye ilan artışı, arama hacmi veya iş garantisi olarak kullanmıyorum. LinkedIn’in açıklaması

Bu veri, işletmenin hangi çalışma modelini seçmesi gerektiğini tek başına belirlemez. Sürekli ürün geliştirme için kurum içi ekip, sınırları belli bir ihtiyaç için proje çalışması uygun olabilir. Belirleyici olan unvanın popülerliği değil, gerekli teknik sahipliktir.

Sıkça Sorulan Sorular

FDE ile FDA aynı kısaltma mı?

Bu konu için yaygın kısaltma FDE: Forward Deployed Engineer. AI odağı belirtilirken AI FDE de kullanılabilir. Araştırmaya bu yazımlarla başlamak daha uygundur; unvanın günlük kapsamı ayrıca okunmalıdır.

FDE yalnız müşteriye danışmanlık mı yapar?

Birçok rol uygulamayı geliştirmeyi ve gerçek kullanıma taşımayı da kapsar. Ancak danışmanlık, ürün ve mühendislik ekipleri arasındaki sınır şirkete göre değişir. Görüşmenin yanında hangi kodun ve teknik teslimin beklendiğini öğrenmek gerekir.

FDE ile prompt yazan kişi arasındaki temel fark ne?

Prompt bir modelin davranışını yönlendiren talimattır. FDE kapsamı, o davranışın hangi veriyle çalıştığını, kullanıcıya nasıl sunulduğunu, kim tarafından kontrol edildiğini ve sistemlere nasıl bağlandığını da içerebilir. İyi prompt tek başına bu teslimlerin yerine geçmez.

Her FDE model eğitir mi?

Hayır. Bazı roller mevcut modelleri uygulamaya bağlar; bazıları inference veya model uyarlama gibi daha derin bir alana odaklanır. Model eğitimi zorunluluğu, ortak unvandan değil belirli görevin kapsamından anlaşılır.

Her projede AI ajanı gerekir mi?

Hayır. İşin adımları ve karar kuralları belliyse daha sade bir uygulama yeterli olabilir. AI, belgeden alan çıkarma veya taslak üretme gibi sınırlı bir göreve eklenebilir. Her adımı bağımsız karar veren ajana çevirmek şart değildir.

“Forward deployed” her gün müşteri ofisinde olmak mı?

Tek başına bunu söylemez. Kullanıcı ve müşteriyle yakın çalışma beklenir; ofis, uzaktan çalışma ve seyahat koşulları şirkete göre değişir. Fiziksel yerleşimden ayrı olarak, işi yapan kişilerle düzenli erişim ve deneme olanağı gerekir.

Üretime çıktıktan sonra iş biter mi?

Kullanımda hatalar, veri değişiklikleri ve yeni ihtiyaçlar görülebilir. Bakım, izleme, düzeltme ve devir sorumluluğunun kimde kalacağı açıkça belirlenmelidir. FDE’nin bunları süresiz üstlenmesi bütün şirketler için ortak bir kural değildir.

FDE projesinde insan onayı neden önemli?

Bir öneriyle geri alınması zor bir işlem aynı riskte değildir. Ödeme, kritik silme veya müşteriye kesin taahhüt gibi adımlarda uygun yetki ve kontrol tasarlanır. İnsan onayının yeri, işin olası hataları ve kabul koşulları üzerinden belirlenir.

Başarı nasıl ölçülür?

Önce mevcut durum ve beklenen iş tanımlanır. Tamamlanma süresi, tekrar giriş, hata türü veya çözülen istisna gibi uygun ölçütler aynı koşullarla karşılaştırılır. Modelin doğru görünen cevabı, tek başına işletme sonucunun iyileştiğini kanıtlamaz.

Şirket FDE işe almak zorunda mı?

Hayır. Sürekli ürün ve müşteri teslimi için ekip gerekebilir; belirli bir iş için proje çalışması veya mevcut ekiple görev paylaşımı yeterli olabilir. Teknik sahiplik, erişim, kullanıcı katılımı ve devam sorumluluğu hangi modelde çalışılacağına göre netleştirilir.

Bu yaklaşımın kendi işinizle bağlantısı

Excel, CRM veya müşteri iletişimi arasında bölünen bir işiniz varsa, önce o işin başlangıcını, kararlarını ve sorumlusunu belirlemek anlamlıdır. Oğuz Erol olarak bu tür süreçler için özel uygulama geliştirebilirim; AI’ı ihtiyaç olan bölüme yerleştirip kullanıcıların işi tamamlamasını esas alırım.

İletişim sayfasından mevcut akışı ve kullandığınız sistemleri kısaca anlatabilirsiniz. Ücretli kapsam görüşmesinde hangi parçanın geliştirileceği ve nasıl doğrulanacağı belirlenir.

Kaynaklar 31 Ekim 2026 itibarıyla incelenmiştir. Günlük akış ve satın alma örneği açıklama amaçlıdır.