Yuri Gubin, DataArt CTO’su – Röportaj Serisi

Yuri Gubin, CTO at DataArt, 18 yıldan fazla süredir DataArt’ta çalışan, yazılım mimarisi, çözüm mimarisi, bulut teknolojileri, yenilik ve yönetim liderliği gibi rollerde ilerlemiş bir deneyimli teknoloji yöneticisi ve yazılım mimarıdır. Mart 2026’da Chief Technology Officer (CTO) olduğundan önceki çalışmaları, finans hizmetleri, sağlık, seyahat ve IoT gibi sektörlerde karmaşık teknoloji sorunlarını çözmeye odaklanmıştır; özellikle bulut bilişim, yapay zeka, veri platformları ve kurumsal yazılım mimarisi konularında uzmanlaşmıştır. CTO olmadan önce Gubin, beş yıldan fazla süreyle DataArt’ın Chief Innovation Officer’ı olarak görev yaptı ve 2021’den beri şirketin Board of Partners üyesidir. Ayrıca Forbes Technology Council’ın profesyonel üyesi olarak AI ve Bulut Bilişim uzman gruplarına katılmakta ve Girls Who Code’a Teknoloji Danışmanı olarak mimari, veri koruma, platform yönetişimi ve teknoloji politikaları konularında tavsiye vermektedir. DataArt, onu New York merkezli Chief Technology Officer olarak listeler.

DataArt, 1997 yılında New York’ta kurulan küresel bir yazılım mühendisliği ve veri‑AI dönüşüm şirketidir. Şirket, 20+ ülkede faaliyet gösteren 6.000’den fazla teknoloji profesyoneline ulaşmış ve 400’ten fazla müşteriye yapay zeka ve makine öğrenimi, veri ve analiz, bulut dönüşümü, özel yazılım mühendisliği, siber güvenlik ve eski sistem modernizasyonu gibi alanlarda hizmet vermektedir. DataArt, finans hizmetleri, sağlık ve yaşam bilimleri, seyahat, medya ve eğlence ve perakende gibi sektörlerde çalışmakta ve AWS, Google Cloud, Microsoft Azure, Snowflake ve Databricks gibi platformlarla teknoloji ortaklıkları sürdürmektedir. 2025 yılında şirket, veri ve AI yeteneklerine üç yıllık 100 milyon $ yatırımını duyurmuş, ardından 2026’da AI‑destekli bir işletim modeli olan Artisyn’ı, AI ajanları, yeniden kullanılabilir hızlandırıcılar, yönetişim, güvenlik ve uyumluluğu kurumsal yazılım geliştirmeye entegre edecek şekilde başlatmıştır.

DataArt’ta neredeyse iki on yıl çalıştınız; yazılım mimarı ve çözüm mimarisinden Chief Innovation Officer’a ve şimdi CTO’ya yükseldiniz. Bu yolculuk, gerçekten dönüştürücü teknolojileri hype döngülerinden nasıl ayırmanıza yardımcı oldu ve bugün AI konusundaki “şüpheci iyimserliğinizi” nasıl şekillendiriyor?

Yıllar içinde bulut ve mobilin yükselişi, farklı AI nesilleri, otomasyon, DevOps ve SRE gibi birçok dalga gördük; bu konularda kod yazdım, mimari yaptım ve müşterilerimize danışmanlık yaptım. Anladığım şey, teknolojiyle neredeyse her şeyi yapabilirsiniz ve teknoloji oldukça güçlü, ancak şeytan detaylarda gizlidir; bunun mantıklı ve çalışır olması için ne yaptığınızı bilmeniz gerekir.

Bulut ortamlarının giderek daha pahalı hale geldiğini, AI modellerinin beklendiği gibi performans göstermediğini ve sürüm döngülerini otomatikleştirme girişimlerinin kötü uygulanmış olduğunu gördüm. İyi ve kötü kararların etkisini deneyimledim; bu yüzden yeni bir şey ortaya çıktığında ve tüm duyurular, vaatler ve hype’ları okuduğunuzda aynı temele geri dönerim: teknolojiyle neredeyse her şey mümkün, ancak gerekiyor ne yaptığınızı bilmek.

Bir teknolojiyi iyi kavramak, Ar‑Ge ve özellikle gerçek projelerle olur; çünkü bu sayede neyin mümkün, neyin olmadığını ve nerelerde hatalar olabileceğini öğrenirsiniz. Bu dersleri her etkileşimden alır, akranlarınız, diğer mimarlar ve analistlerle konuşur ve desenlerin olup olmadığını, bunlar etrafında bir sistem oluşturup oluşturamayacağınızı anlamaya çalışırsınız. Sonunda bu bir rehber olur ve kararlarınızın gerçekten iyi sonuçlar verip vermediğini görürsünüz.

İşte şüpheci iyimserliğin kaynağı budur. Teknoloji ne vaat ederse etsin, hâlâ ne yaptığınızı bilmeniz gerekir; bu bilgi deneyim, iş birliği ve sürekli öğrenme, gelişme ve hype’ın arkasına bir sistem kurma çabasıyla gelir.

Kurumsal AI, deneme aşamasından hangi deneylerin ölçeklendirilmesi gerektiğine karar verme aşamasına geçiyor gibi görünüyor. Bir AI kullanım durumunun daha geniş dağıtıma hazır olduğunu hangi sinyaller gösterir ve bir şirketin çok erken ölçeklendirdiğine dair uyarı işaretleri nelerdir?

Bir şeyin ölçeklenebilir olup olmadığını ya da başka bir şey yapmamız gerekip gerekmediğini anlamak için iki yöntemi kullanıyorum: benimseme eğrisi ve öğrenme eğrisi.

Bir AI kullanım durumunun işe yarayıp yaramadığını anlamak için ona bir süre vermek ve ne tür bir değer kattığını ve kullanıcı yolculuğunun nasıl göründüğünü anlamak gerekir; böylece belirli bir ekip ya da iş akışındaki anlık “wow” etkisi yerine iniş çıkışları görebilirsiniz. Aynı kişilerin birkaç hafta sonra ne durumda olduğunu görmelisiniz. Hâlâ kullanıyorlar mı? O kullanım durumu, otomasyon ya da oluşturdukları AI yeteneği hâlâ onları memnun ediyor mu, yoksa ölçeklendirilmemesi gereken geçici bir patlama mıydı?

Bu şeylerin bir kısmı sadece zamanla doğrulanabilir. Her zaman ilk öncüler olacak, genellikle en teknik açıdan yetkin kişiler ve çok meraklı olanlar, ardından bunu diğer segmentlerle, erken benimseyenleri takip edenlerle ve daha sonra erken çoğunlukla denemeniz gerekir. Bir kez orada kendini kanıtladığında, evet, bunu ölçeklendirmeye ve o kullanım senaryosunu diğer departmanlara genişletmeye başlayabilirsiniz.

Her büyük model sürümü, bir organizasyon içinde çalışanlara hemen en yeni yeteneklere erişim sağlama baskısı yaratabilir. Teknoloji liderleri, yeni bir modelin sadece bir başka deney ve maliyet dalgası yaratmak yerine anlamlı bir iyileştirme temsil edip etmediğini nasıl değerlendirmelidir?

İşte şüpheci iyimserliğim bir kez daha. Zaten bir modelinizin olduğunu ve birkaç bin kişinin AI’ı günlük olarak kullandığını, farklı modellerin ve araçların zaten mevcut olduğunu varsayın. Yeni bir model çıktığında, hype ve doğal merak nedeniyle herkesin onunla deneme yapmak isteyeceğini bekleyebilirsiniz; bu iyi bir şey, ancak bu denemeler mutlaka belirli sonuçlara yönelik yönlendirilmiş veya odaklanmış olmayabilir ve bazen farkı ölçemeyebilirsiniz.

Ölçekli olarak bu önemlidir. Yeni modelin eskiye karşı nasıl performans gösterdiğini görmek için sadece bir iki kişi uğraşmıyor. Belirli bir kullanım senaryosu için sonuç çok da önemli olmayabilir, ancak binlerce kişi zaman harcayarak deneme yapabilir. Aynı zamanda, bir şey gerçekten çok iyi çalışıyorsa, organizasyonunuz içinde neyin işe yaradığını öğrenme süreci herkes tarafından net bir şekilde açıklanmayabilir veya görülebilir olmayabilir.

Bu yüzden yeni bir modeli değerlendiren ilk grup organizasyonun tamamı olmamalıdır. İlgili ekiplerle, ayrıca hukuk ve güvenlik birimleriyle yakın çalışacak bir Ar-Ge (R&D) grubu olmalıdır. Modeli kapsamlı bir şekilde değerlendiriyoruz, hızlı bir değerlendirme yapıyoruz ve ardından güvenlik, uyumluluk ve teknolojiyle ilgili bazı yorumlar ve rehberlik eşliğinde daha geniş bir kitleye sunuyoruz. Yeni modeller ve büyük güncellemeler sürekli geldiği için bu model ve zihniyete sahip olmanız gerekir. Bu gerçekten tek seferlik ya da nadir bir çalışma değildir.

DataArt, teknoloji, hukuk, uyumluluk, InfoSec ve diğer ekipleri içeren çapraz fonksiyonlu bir “AI SWAT” oluşturdu. Bu grup pratikte nasıl çalışıyor ve yeni bir AI aracının daha geniş kullanım için onaylanmasından önce hangi riskler veya sorular çözülmeli?

Kuruluşundan bu yana, bu grup için yaklaşık her dört ya da beş ayda bir farklı hedefler belirlediğimizi düşünüyorum. Önceliği, hedefi ve bazen misyonu değiştiriyoruz ve bu hedeflerin çoğu AI ile ilgili. İş gücünü yetkinleştirmek, pazara giriş ve yeni yetenekler, ortaklıklar veya AI’ı organizasyon içinde ve ADLC genelinde daha geniş bir şekilde etkinleştirmek olabilir.

Tam konular zamanla evrimleşir ve bunun sağlıklı olduğunu düşünüyorum çünkü sürekli olarak kendi stratejinizi yeniden gözden geçirmeniz, varsayımlarınızı doğrulamanız ve yön değiştirmeniz gerekip gerekmediğini ve ekip için bir sonraki temanın ne olması gerektiğini anlamanız gerekir.

Grup, farklı departmanlardan temsilcileri içerir ve amaçlarından biri sadece herkesi bilgilendirmektir. Yeni bir duyuru, soru ya da fırsat ortaya çıktığında, birisi bu konuyu düzenli toplantılarımızdan birine getirebilir. Sadece dar bir ekip için ilgili bir teknoloji sorusu gibi görünse bile, günümüzde bu konular organizasyonun birçok bölümü için etkili olabilir.

Bu yüzden yeni bir ortaklık, araç ya da hızlandırıcıyı değerlendirirken, herkesin neler olduğunu anlaması ve soru sorma ya da denetim sağlama fırsatı bulması için konuyu açıkça tartışıyoruz. Yeni bir AI aracı için teknoloji, onu yalnız başına değerlendiremez. Güvenlik, hukuk ve uyumluluk da şirket ya da müşteri verilerini nasıl işlediğini, hangi kısıtlamaların geçerli olduğunu ve ölçekli olarak güvenli bir şekilde kullanılabilir olup olmadığını anlamalıdır.

Bazen AI SWAT ekibi, yetkinleştirme gibi belirli programlar üzerinde de çalışır; bu programlarda hedefler belirler, yol haritaları çizer ve farklı grupların nasıl dahil edileceğine karar veririz. İşte bu gerçekten nasıl çalışıyor: insanları bilgilendirmek, belirli programlar üzerinde birlikte çalışmak ve yönetim kuruluna şirket genelinde AI ile neler olduğunu görünür kılmak.

AI destekli yazılım geliştirmeye karşı çok farklı tutumlar gördüğünüz doğru; bazı organizasyonlar ajan temelli geliştirmeyi aktif olarak ölçeklendirirken diğerleri hâlâ AI tarafından oluşturulan kodu yasaklıyor. Bu bölünmeyi ne açıklıyor ve daha risk‑bilinçli işletmelerin AI’nın yazılım mühendisliğinde daha büyük bir rol oynamasından rahat olmaları için neyin değişmesi gerekiyor?

Muhtemelen hayır diyenler ile evet diyenler arasındaki farkı yönlendiren şey, risk iştahları ve belirsizlik ile muamelesine yönelik tutumlarıdır. Her iki tür organizasyona da yardımcı olan şey sürekli eğitim, deney ve değerlendirmedir. AI’ı benimseyen ve her yerde entegre eden birçok organizasyonla çalışıyor olsak da, sonuçları ve etkiyi ölçme konusunda hâlî zorluklar var. Açıkçası, AI’nın etkisini nasıl ölçtüğünüz ve bir ekibin performansını nasıl değerlendirdiğiniz sorusu bazen aniden ortaya çıkıyor, sanki kimse daha önce bunu düşünmemiş gibi.

Bir AI girişimini daha kapsamlı bir şekilde değerlendirmeye başladığınızda, etkisini ve size gerçekten sağladığı değeri anlamaya başlarsınız; bu da teknolojinin nerede mantıklı olduğuna dair daha iyi kararlar almanıza yol açar. AI’ye hayır diyen şirketler için, teknolojinin neler yapabileceğini ve şu anda nerede durduğunu gözden geçirmek için sürekli bir süreç hâlâ gereklidir. Üç yıl önce alınan bir kararın, kimse varsayımları yeniden gözden geçirmediği için şirket politikası olarak kalmasını istemezsiniz.

Agentic AI, bireysel ekiplerin kendi ajanlarını oluşturmasını giderek daha kolay hâle getiriyor ve bu da neredeyse aynı görevleri yapan birden çok ajanın ortaya çıkmasına yol açabilir. Deneyler ne zaman ajan yayılımına dönüşür ve sahiplik, izinler, kopya ve yaşam döngüsü yönetimini kontrol etmek için ne tür bir yönetişim katmanı gerekir?

Her geliştiriciye bir AI lisansı verildiği ve deneylerin yönlendirilmediği tipik bir senaryoya baktığımızda, herkes kendi şeylerini yaratmaya ve kendi yöntemleriyle çalışmaya başlar. Bu genellikle düşük performanslı ekipler, kaçırılan beklentiler, geride kalan kalite ve artan masraflara yol açar. Sonuç olarak, herkesin beklediği şeyi yapmaz, kalite kötüdür ve maliyetler artar. Bunu hafifletmek için, daha geniş bir departman ya da organizasyon çabasının parçası bir ekip çalışması olması gerekir; işte yönetişim burada devreye girer.

Proje seviyesinde, bilgi tabanı ve bağlam üzerinde, ayrıca AI’ı kullanmaya başlayacağınız kullanım senaryoları üzerinde mutabık kalabilirsiniz. Ardından, geliştirme iş akışının bir parçası olan ve herkesin yeniden kullanabileceği beceriler ve ajanlar oluşturursunuz; böylece her seferinde yeniden yaratmak yerine bilgi ve en iyi uygulamaları biriktirirsiniz. Bu proje‑seviyesi çaba daha sonra bir kurumsal mimari kurulu, bir teknoloji grubu, CTO ya da AI benimsenmesinden sorumlu bir ekip gibi bir yapı tarafından koordine edilmelidir. İyi çalışan ajanları yeniden kullanmak, sürecin sağlam olduğundan emin olmak ve bunun organizasyon genelinde çalışmasını sağlamak istersiniz; kaosa ve gürültüye dönüşmemelidir.

Bu yüzden bunun proje seviyesinde, belki program seviyesinde ve ardından departman ve organizasyon seviyelerinde de senkronize bir çaba olması gerektiğini düşünüyorum.

Token tüketimi ve çıkarım maliyetleri bir pilot aşamasında nispeten küçük görünebilir, ancak AI sistemleri binlerce çalışan ya da otonom ajan üzerinde dağıtıldığında önemli hale gelir. İşletmeler AI maliyet yönetimini nasıl ele almalı ve AI iş yükleri için özellikle FinOps benzeri bir yaklaşımın ortaya çıkmasını bekliyor musunuz?

Şunu söyleyerek başlayayım: neredeyse ideal bir senaryo, AI maliyetlerinin artıp bir plato seviyesine ulaşması ve ardından zamanla hafifçe azalmasıdır. Bu, maliyetleri öngörebileceğinizi, kontrol edebileceğinizi, AI’ye gerçekte ne harcadığınızı anlayabileceğinizi ve aldığınız kararların sonuçlarını görebileceğinizi gösterir. Kötü durumlar ise maliyetlerin sürekli yükselip düşmesi; bu genellikle bir şeyin sürdürülebilir olmadığını gösterir, ya da maliyetlerin yükselip tamamen düşmesi; bu da benimsenmenin gerçekleşmediğini, bir şeylerin çalışmadığını ya da insanların başka bir şey kullandığını ve bunu göremediğinizi işaret eder.

FinOps bir kavramdır ve AI FinOps da bir kavramdır. Bazı teknikler çok teknik iken, diğerleri oldukça basittir. En pahalı modele her zaman bağımlı olmamak için tercih edilen modeli seçmek gibi temel bir adım olabilir ve bu kararlar parça parça tasarruf sağlamaya başlar. Aynı zamanda, maliyetleri nasıl tasarruf edeceğinizi ve kontrol edeceğinizi bilmek sadece denklemin yarısıdır. Benim gördüğüm FinOps, AI çabalarını değerlendirirken neyi ölçtüğünüzü tanımlamanız gerektiği için ürün ve iş liderlerini de içeren bir disiplin ve metodolojidir.

Evet, AI FinOps’un, bir AI SWAT ekibinin tartışması gereken iyi bir konu olduğunu düşünüyorum: ne kadar harcadığınız, ne kadar geri aldığınız, nasıl kontrol ettiğiniz ve fırsatların nerede olduğu.

Birçok şirket, AI’ı tanıtmadan önce ekiplerinin ne kadar üretken olduğuna dair güvenilir bir temel oluşturmamış olsalar bile, AI’dan elde edilen YG’yi (ROI) göstermek zorunda bırakılıyor. AI’ın anlamlı bir iş değeri yaratıp yaratmadığını belirlemek isteyen organizasyonlar aslında neyi ölçmeli?

AI’a karşı tutumunuz ya da şu anki konumunuz ne olursa olsun, belki zaten ajanları her yerde kullanıyorsunuz ya da gelecek yıl AI kullanmaya başlayacağınızı düşünüyorsunuz; bu durumda bir temel oluşturmak günümüzde kesinlikle vazgeçilmezdir.

Birkaç metrik sınıfı vardır. Bazıları öznel olup, sadece geliştiricilerinizin ya da çalışanlarınızın geri bildirimleri olabilir; çünkü insanlarla çalışıyorsunuz ve AI değerini nasıl algıladıklarını anlamak önemlidir. Daha nesnel ölçütler mekanik ya da sentetik metriklerle başlayabilir, ancak herkesi onlara çok sıkı bağlanmamaları konusunda uyarırım. Kastedilen şey, kod commit’leri ya da story point’ler gibi ölçütlerdir. Bu metrikler çalışmanın gerçekleştiğini gösterir, ancak değeri ya da etkisini gerçekten ortaya koymaz.

Daha fazla fark yaratan şey, işin ne kadar hızlı ya da ne kadar iyi teslim edildiğini açıklayan ölçütlerdir. Lead time ya da MTTR gibi DORA ölçütlerini düşünün; bir hatadan ne kadar çabuk kurtulabileceğiniz, üretimdeki bir hatayı ne kadar hızlı düzeltebileceğiniz ya da bu ölçütlerin zaman içinde nasıl değiştiği. Tek bir sayı, yönelim hakkında size bir şey söylemez. Mimarlarımızdan biri yakın zamanda, yazılım geliştirmede iyi bir ölçütün, AI benimsenmesi arttıkça tahminlerin ne kadar güvenilir olduğunun da göstergesi olabileceğini belirtti; bu, çabaların sürdürülebilirliği ve ekiplerin gerçekten ne kadar üretken olduğu hakkında bir şeyler söyler. Ayrıca maliyetleri de takip etmeniz gerekir; çünkü sadece faydalardan bahsedip bunları elde etmenin maliyetini anlamazsanız, tam resmi göremezsiniz.

Yazılım geliştirme dışındaki alanlarda da benzer bir yaklaşım benimserim. Her iş akışı ya da süreçte bir iş birimi ve bir tamamlanma tanımı vardır. İddiaları işliyor, evrakları inceliyor ya da müşteri taleplerini ele alıyor olun, ne sunduğunuzu tanımlayın ve ardından AI öncesinde ne kadar sürdüğünü, şimdi ne kadar hızlı ve ne kadar iyi yapabildiğinizi ve maliyetinin ne olduğunu ölçün. Bu, hem temel çizgi hem de ölçüt çerçevesi için iyi bir başlangıç noktası sağlar.

DataArt, Artisyn gibi girişimler aracılığıyla AI’ı yazılım teslim yaşam döngüsünün her aşamasına entegre ediyor. AI daha fazla uygulama, test ve iş akışı görevini üstlendikçe, yazılım mühendisliğinin hangi bölümleri insanlar için daha değerli hâle geliyor ve hangi beceriler daha az önemli hâle gelme riski taşıyor?

AI’ı geliştirmede etkili bir şekilde kullanabilmeniz, iyi tanımını hâlâ hatırlamanıza bağlıdır. Bu uzmanlığa, ajanlarınızı yönlendirmek, sonuçları gözden geçirmek, kısıtlamalar koymak ve kuralları tanımlamak için ihtiyaç duyarsınız. En iyi uygulamaların ne olduğunu ve iyi bir mimarinin nasıl görünmesi gerektiğini anlamalısınız; çünkü bunu bilmeden neyin geliştirildiğini kavrayamazsınız ve bu tür bir uzmanlığın değeri çok, çok önemli ölçüde artmaktadır.

Mimari kalıpları anlamak önemlidir; aynı zamanda belirli bir sektör, uygulama ya da çözüm sınıfı için neyin uygun olduğunu kavramak da kritiktir. Şu anda hangi mimarinin iyi olduğunu ve çözüm ölçeklendiğinde hâlâ iyi kalacağını bilmeniz gerekir; çünkü bazen aynı mimari bir çözüm ya da platformun tüm ömrü boyunca işe yaramaz.

Belirli bir çözüm için neyin uygun olduğuna dair bu denge, insan unsurudur. Bu, hizmetlerin ve yazılım geliştirme sürecinin arkasındaki zevk, zanaatkârlıktır. Ne yaptığınızı bilmelisiniz ve bu da müşteriyi ve sektörü anlamaktan gelir.

Hangi beceriler daha az önemli? Bunu söylemek benim için gerçekten zor, belki de kodu ne kadar hızlı yazabildiğiniz bir ölçüt olabilir. Şaka bir yana, kod artık çok, çok daha hızlı üretilebiliyor ve belirli bir kütüphane ya da dil hakkındaki özel bilgi de AI sayesinde çok daha çabuk öğrenilebiliyor.

.NET geliştiricilerinin Java geliştiricilerine çok hızlı bir şekilde yeniden eğitildiğini gördüm; beş ya da on yıl önce bunu ölçekli bir şekilde yapmanın neredeyse imkânsız olduğunu söylerdim. Günümüzde ise mümkün. Güçlü bir kıdemli geliştirici, diller arasında giderek daha fazla geçiş yapabilir; çünkü asıl önemli olan, teknolojiyi, mimariyi, çözüm en iyi uygulamalarını, SDLC’yi ve ADLC’yi anlamalarıdır.

Şirketler, onlarca AI pilot projesinden bağımsız hareket edebilen üretim sistemlerine geçerken, bir AI ajanının maliyetli bir hatayı yaptığı durumda sorumluluk nihai olarak nerede olmalı: geliştiricide, iş sahibi, model sağlayıcıda, yönetişim ekibinde ya da bunların bir kombinasyonunda?

Suçsuz iş birliği ve paylaşılan sorumluluk fikrini seviyorum; çünkü organizasyondaki herkes en iyi uygulamalara, mimari çerçevelere ve çözümlere katkıda bulunur. Bir geliştirici AI ile ya da AI olmadan kod oluşturduğunda, başka bir geliştirici bunu inceler, takım liderleri rehberlik eder, mimarlar mimariyi ve kısıtlamaları sağlar, yönetişim ekibi ise bütçeler, zamanlamalar ve sürümlerle ilgili kararları verir. Herkes bir şekilde dahil olur.

Çok sık, bir şeyler ters gittiğinde sorunun süreçte olduğu görülür; bu anlamda sorumluluk farklı roller arasında paylaşılıktır. Ancak sadece sorumluluğun paylaşıldığını ve bu yüzden suçsuz olduğunu söylemek yeterli değildir; hâlâ belirli sorumluluklara bölünmesi gerekir.

Geliştiriciler, bir pull request olarak sundukları koddan sorumludur ve neyin gerçekleştiğini anlamalıdır. Mimarlar, verdikleri kararlar ve ajanlar ile geliştiricilere sağladıkları mimari kararlar için sorumludur. Platform ekibi ise, belirli bir kod satırını kim ya da ne oluşturmuş olursa olsun, çözümün güvenilirliğinden sorumludur.

Dolayısıyla sorumluluk vardır, ancak bunu ekip, rol ve departmana göre ayrıntılı olarak tanımlamanız gerekir. Analizi sadece “AI bunu yaptı” şeklinde durduramazsınız. Hangi kontrollerin, testlerin ya da denetimlerin bu hatanın üretime ulaşmasına izin verdiğini sormanız gerekir.

Eğer birim testlerinin eksikliği kötü kodun üretime itilmesine, ya da denetim ve incelemenin eksikliği buna yol açtıysa, bu sorumluluğu AI’ya devredemezsiniz. Ayrıca her hata ya da kesinti için model sağlayıcıyı ya da bulut sağlayıcıyı suçlamak da mümkün değildir.

Harika röportaj için teşekkür ederiz, daha fazla bilgi edinmek isteyen okuyucular DataArt sitesini ziyaret etmelidir.