HelmGuard’ın CEO’su ve Kurucu Ortağı John Daley – Röportaj Dizisi

John Daley, HelmGuard’ın CEO’su ve Kurucu Ortağıdır. Daha önce Palantir’de sekiz yıl çalışmış, burada hukuk ekibine ve küresel gelir fonksiyonuna eş liderlik etmiştir. Kurumsal büyüme, hukuki risk ve yapay zekânın devreye alınması alanlarındaki deneyimi, kuruluşların faaliyet gösterdiği sistemlere yönetişimi yerleştirme yaklaşımını şekillendiriyor.

HelmGuard, güvenlik, yönetişim, risk ve uyumluluk alanlarında yapay zekâ destekli bir platform geliştiriyor. Platform, kurum içi ve üçüncü taraf verilerini birbirine bağlayıp kanıt toplamak ve kontrolleri değerlendirmek için uzmanlaşmış ajanlardan yararlanıyor; atıflar ve denetim izleri aracılığıyla insanların inceleme yapmasını destekliyor. Çalışmaları üçüncü taraf risk yönetimini, kurum içi uyumluluğu ve kuruluşlarda çalışan yapay zekâ ajanlarına yönelik güvenceyi kapsıyor.

Palantir’de hukuk ekibine ve küresel gelir fonksiyonuna eş liderlik ettiniz; bu da büyüme ile risk arasındaki gerilimi yakından görmenizi sağladı. Bu deneyim, geleneksel yönetişimin eksiklikleri hakkında size ne gösterdi ve HelmGuard’ı kurma kararınızı nasıl şekillendirdi?

Hem hukuk hem de gelir tarafında görev almak, sözünü ettiğiniz gerilimin tam merkezinde bulunmamı sağladı. Buradan çıkardığım en önemli ders, sunum ve uygulama süreçlerinden fazla uzak kalan yönetişimin her iki açıdan da başarısız olduğuydu. İşlerin ilerlemesini engelliyor, üstelik çoğu zaman riski de yönetemiyor.

Sorunun bir kısmı, yönetişimin hızdan çok titizliğe ve derinliğe önem verme eğiliminde olması. Politikalar yazılıyor, komitelerde inceleniyor ve sonradan denetimler ile anketler yoluyla uygulanıyor. Yönetişim işlevi bir görüş oluşturduğunda ise risk, genellikle şu ya da bu biçimde çoktan işin içine girmiş oluyor.

HelmGuard, yönetişimin bir departman olarak değil, altyapı olarak yeniden kurulması gerektiği düşüncesinden doğdu. Yapay zekâ ajanları bu dönüşümü acil hâle getiriyor; çünkü işlerin giderek daha büyük bir bölümü artık ajanlar tarafından ve ajanlar arasında yürütülüyor, geleneksel yaklaşımlar da bu hıza yetişemiyor.

Bir finans kuruluşu, eylem öneren yapay zekâdan bu eylemleri gerçekleştirebilen ajanlara geçtiğinde, risk maruziyetinde temelden en çok ne değişir? Sizce bankalar ve finans teknolojisi şirketleri şu anda hangi riskleri hafife alıyor?

Temel değişim, insanın artık darboğaz olmaktan çıkmasıdır. Öneri sunan bir sistemde insan, modelin çıktısı ile gerçek dünya arasında yer alır. Bir ajanda ise eylemi gerçekleştiren modeldir; insan da en iyi ihtimalle olup biteni sonradan inceleyen kişidir. Ajanların yaptıklarının hızı, ölçeği ve kapsamı düşünüldüğünde, uygulamada bu inceleme bile zorlaşır.

Risk, çalıştırma süresi uzadıkça katlanarak artar. Kendi çalışmalarımız, bir ajanın görevinden sapma olasılığının çalıştırma uzadıkça ve daha fazla araç çağrısı içerdikçe yükseldiğini gösteriyor. Yetenekler bu kadar hızlı ilerlerken ve verimlilik kazanımları bu kadar cazipken, uzun süre çalışan ajanlara daha fazla görev devretme baskısı çok büyük olacak. Denemelere yeni başlayan kuruluşlar ise bunun, ajanların çalışma biçimine özgü bir güvence mekanizması gerektirdiğini henüz kavramış değil.

Bankaların ve finans teknolojisi şirketlerinin hafife aldığı konulara gelince, üç noktaya dikkat çekerim. Birincisi, saldırı yüzeyi modeldeki bir güvenlik açığı değil, ajanın meşru erişimidir. İkincisi, ajanın yalnızca görevin tamamlandığını bildirdiği özet düzeyindeki gözetim, gerçekte ne yaptığı hakkında neredeyse hiçbir şey söylemez. Üçüncüsü, ajanın arkasındaki tedarik zinciri —model sağlayıcısı, orkestrasyon tedarikçisi ve araç entegrasyonları— bir dördüncü taraf riski sorunudur. Kuruluşların çoğu bu zinciri etkili biçimde haritalayabilecek konumda değildir ve standart üçüncü taraf risk yönetimi (TPRM) programlarının buna yetişmesi mümkün değildir.

Bir ajan bir ödeme sistemine meşru erişime sahip olduğu hâlde uygunsuz bir işlem başlatabilir. Finans kuruluşları, ajanın teknik olarak yapmasına izin verilenlerle belirli bir iş bağlamında yapmaya yetkili olduğu şeyleri nasıl birbirinden ayırmalı?

İzin, kimlik bilgisinin bir özelliğidir; yetkilendirme ise bağlamın bir özelliğidir. Geleneksel kimlik ve erişim yönetimi, bu kimliğin bu API’yi çağırmasına izin verilip verilmediğini söyleyebilir. Ancak bu kimliğin bugün, bu nedenle, bu karşı tarafa bu ödemeyi yapmasının gerekip gerekmediğini söyleyemez.

İnsanlar bu açığı muhakeme, kontroller ve kurumsal bilgiyle kapatır. Ajanlar yalnızca kendilerine sağlanan bağlama sahip olduğundan, bu bağlam açıkça sunulmalıdır. Ayrıca, kuruluş içinde çalışan yeni türde bir çalışan olan ajanlara uygun hâle getirmek için kontrollerin kendisini de yeniden düşünmek gerekir.

Uygulamada bu, ajanın niyeti ile kayıt sisteminin arasına yerleştirilen bir katman anlamına gelir. Bu katman, kuruluşun bildiği ve güvendiği varlıklara, onaylı karşı taraflara, limitlere ve kimin kimin adına ne yapabileceğine ilişkin kendi veri modelini barındırır. Üretim ortamında her eylem, ajanların çalışma hızıyla aynı hızda bu modele göre denetlenir.

Bunu düşünmenin sezgisel bir yolu, şu testi uygulamaktır: Bu ajanın söz konusu belirli eylemi gerçekleştirmesine neden izin verildiğini iş gerekçesiyle tek bir cümlede açıklayabiliyor musunuz? Yanıtınız erişimi olduğuysa, bu izin anlamına gelir; yetkilendirme değil.

Bir tedarikçinin faturasını okuyup ödeme başlatabilen bir ajan düşünün. Belgeye yerleştirilmiş kötü amaçlı talimatlara karşı bu iş akışını nasıl korurdunuz ve ajanın kendisinin geçersiz kılamayacağı kontrolleri nerelerde devreye sokardınız?

Ajanın okuduğu her belgeyi, tıpkı bir e-posta ekini ele alır gibi güvenilmeyen girdi olarak kabul ederek başlardım. Fatura, talimatların izleneceği bir kaynak değil, içinden veri çıkarılacak bir belgedir; ajanın yetki çerçevesinde bu açıkça belirtilmelidir.

Ardından okuma ve eyleme geçme adımları birbirinden ayrılmalı; faturayı ayrıştıran ajan, ödeme bilgilerini kullanma yetkisine sahip olmamalıdır. Veri çıkarımı, karşı tarafı, tutarı ve referansı içeren yapılandırılmış bir öneri oluşturur. Herhangi bir işlem yapılmadan önce bu öneri, ayrı bir adımda politikaya göre doğrulanıp onaylanır.

Son olarak, eylem belgenin iddialarına göre değil, kurumun zaten bildiklerine göre doğrulanmalıdır. Bu tedarikçiyi tanıyor muyuz? Bu tedarikçinin banka bilgileri kayıtlarımızdakilerle aynı mı? Tutar sözleşme kapsamına giriyor mu ve zamanlama geçmişle tutarlı mı? İstem enjeksiyonu bir belgenin içeriğini değiştirebilir, ancak kurumun kendi verilerini değiştiremez. Bu veriler, bağlam ajana ulaştığı takdirde, bir kişinin eylemlerine nasıl yön veriyorsa ajanın eylemlerine de aynı şekilde yön verebilir.

Bazı kontroller, ajanın müdahale edemeyeceği noktalarda bulunmalıdır. Bir karşı tarafın veya banka bilgilerinin değiştirilmesi, farklı bir kanaldan doğrulama gerektirmeli; ödeme limitleri ajan katmanının altında uygulanmalı; yeni alıcılar beklemeye alınmalı ve yerleşik örüntünün dışındaki her işlem için bir kişinin onayı alınmalıdır.

Tüm bunların temelindeki ilke şudur: Bir istemi engellemek, bir ajanı yönetmek anlamına gelmez. Doğru savunma, mevcut iş akışlarına yalnızca otomasyon eklemek yerine, ajanlarla çalışan işletmenin ne anlama geldiğini yapısal olarak yeniden düşünmeyi gerektirir.

HelmGuard, diğer ajanları izlemek için yapay zekâ ajanları kullanıyor. Denetleyici sistemin, temel ajanın gözden kaçırdığı hataları fark edeceğini nasıl doğruluyorsunuz ve hangi korumalar her iki sistemden de bağımsız kalmalı?

Denetleyicinin avantajı, izlediği ajandan daha akıllı olması değil; farklı bilgilere sahip olması ve farklı bir iş yapmasıdır. Özet yerine tüm işlem izini görür, kurumun kontrollerini ve risk yaklaşımını bilir ve görevi tamamlamaya çalışmadığından kestirme yolları haklı çıkarmak için bir motivasyonu yoktur.

Ajanın gözden kaçırdıklarını denetleyicinin yakaladığını, diğer kontrolleri doğruladığımız gibi, bilinen hatalara karşı sınayarak doğrularız. İşlemleri iz kayıtlarından yeniden oluşturur, belirtilen yetki çerçevesi ve kontrollerle karşılaştırır, etiketlenmiş test çalışmaları boyunca sapmaların ne ölçüde tespit edildiğini ölçeriz.

Bağımsızlık kritik önem taşır; finans kuruluşlarının risk yönetiminin birinci, ikinci ve üçüncü hatlarını birbirinden ayırmasının nedeni de budur. Denetleyici katman, mümkün olduğunda ajandan farklı modeller kullanmalı, ajanın işlem yaptığı sistemlere salt okunur erişime sahip olmalı ve ajanın kimlik bilgilerini hiçbir zaman paylaşmamalıdır. Bu yaklaşım, birbiriyle bağlantılı hatalara karşı tasarım yapılmasına yardımcı olur ve inceleme ile doğrulama katmanının amacını ve kapsamını sınırlar.

Her iki sistemden de bağımsız olması gereken bazı korumalar vardır: sistem düzeyinde uygulanan kesin limitler ve görevler ayrılığı; iki ajanın da değiştiremeyeceği, değiştirilemez kayıtlar; her iki modelin de değerlendirmesine bağlı olmayan acil durdurma anahtarları ve sistemleri sınırlandırma mekanizmaları; ayrıca doğrulama katmanının çıktılarına yönelik düzenli insan incelemesi.

Yapay zekâ temelli güvence gereklidir; çünkü ancak ajanın çalışma biçimine, hızına ve verilerine uyum sağlayan bir sistem ona ayak uydurabilir. Ancak bu güvence, kurumların yıllar içinde geliştirdiği aynı kurumsal yapıya, uyum ve risk çerçevesine dayanmalıdır.

HelmGuard’ın bir bankanın yazılı politikasını, ajan çalışırken uygulanan bir kontrole nasıl dönüştüreceğini adım adım anlatabilir misiniz? Örneğin, başka açılardan yetkilendirilmiş bir ödeme kurum içi bir kısıtlamayla çeliştiğinde ne olur?

İlk adım, “yeni tedarikçilere yapılacak 50 bin doların üzerindeki ödemeler için ikinci hat onayı gerekir” gibi bir politikayı; karşı tarafın durumu, tutar ve onay durumu gibi makine tarafından denetlenebilir koşullara ayırmak ve bunları kurumun veri modeliyle eşleştirmektir.

İkinci adım, bu koşulları ajanın tabi olduğu yetki çerçevesine yerleştirmektir; denetleyici katman da önerilen her eylemi bu koşullara göre değerlendirir. Verdiğiniz örneği ele alalım: Bir ajan, yetkileri ve tedarikçiyle yapılan sözleşme kapsamında kalan bir ödeme öneriyor, ancak kurum, durum tespiti yenilenene kadar bu tedarikçiyi beklemeye almış olsun. Sistem eyleme izin verirken politika bunu engeller. Denetleyici katman çelişkiyi işaretler, eylemi duraklatır, gerekçesini kaydeder ve kanıtları ekleyerek belirlenen onay merciine iletir.

Bundan sonra üç şeyden biri olur ve her biri kayda geçirilir. Onay mercii gerekçesini belirterek kısıtlamayı geçersiz kılar; kısıtlama yürürlükte kalır ve ajana nedeni bildirilir ya da politikanın hatalı olduğu anlaşılır ve politika değiştirilir. Yazılı politika ile fiilî kontrollerin birbirinden uzaklaşmasını önleyen, işte bu son döngüdür.

Finans kuruluşları hâlihazırda tedarikçileri kapsamlı bir durum tespit sürecinden geçiriyor. Bir tedarikçi, ilk incelemenin ardından bir ajanın modelini, araçlarını veya izinlerini değiştirerek kurumun sistemleri içindeki davranışını etkileyebiliyorsa bu süreçte nelerin değişmesi gerekir?

Belirli bir zamandaki durum tespiti, değerlendirilen şeyin sonunda çalıştırılacak şey olduğunu varsayar. Ajanlarda bu varsayım, tedarikçinin temel modeli değiştirdiği, bir araç eklediği veya izinleri genişlettiği anda geçerliliğini yitirir. Bu nedenle ajanın davranışına daha fazla odaklanan farklı bir yaklaşım gerekir.

Sözleşmeler açısından kurumlar, asgari olarak model sürümünde, araç setinde ve izin kapsamındaki önemli değişikliklerin kendilerine bildirilmesini şart koşmalı ve neyin önemli değişiklik sayılacağını önceden tanımlamalıdır.

Ancak daha da önemlisi, operasyonel açıdan kurumların kendi sürekli kanıtlarını toplaması; gözlemlenen davranışı beklenen davranışla karşılaştırması, sapma oranlarındaki değişimi izlemesi ve başlangıç ölçütlerini yeniden belirleyebilme olanağını koruması gerekir. Tedarikçi ajanı değiştirebiliyorsa, sizin de değiştiğini görebilmeniz gerekir.

Ajanlar, model sağlayıcısından barındırma katmanına ve her bir araç entegrasyonuna kadar uzanan bir alt tedarikçi zincirini de beraberinde getirir. Bu, dördüncü taraf riskidir ve üçüncü taraf risk programlarının çoğu bunu gerektiği gibi izleyebilecek şekilde tasarlanmamıştır.

Platformumuzun iki bileşeni burada bir araya geliyor. Üçüncü taraf riski, tedarikçinin kim olduğunu ve hangi taahhütlerde bulunduğunu gösterirken ajan güvencesi, yazılımının sizin ortamınızda gerçekte ne yaptığını ortaya koyar. Durum tespiti her ikisini de kapsamalıdır.

Bir ajan mali kayba yol açtıktan sonra, kurumun kararı yeniden oluşturabilmesi ve iş ekibi, yazılım sağlayıcısı ve model sağlayıcısı arasındaki hesap verebilirliği belirleyebilmesi için hangi kanıtlara ihtiyacı olur? Bu kanıtların bugün kaydedilme biçiminde en büyük eksiklikleri nerede görüyorsunuz?

Çalıştırmanın eksiksiz izine ihtiyaç duyarsınız: her girdi, araç çağrısı, ara akıl yürütme adımı ve çıktı; ayrıca ajanın o sırada hangi yetki çerçevesi altında çalıştığı, o andaki politika ve kontrol durumu, kullanılan model ve sürümü ve tedarikçinin devreye aldığı yapılandırma. Bunlara, kimin neyi ne zaman ve hangi kanıta dayanarak onayladığını gösteren insan etkileşimlerinin kaydı da eklenmelidir.

Hesap verebilirlik kabaca üçe ayrılıyor; ancak bize göre model sağlayıcısı katmanında kayda değer bir hesap verebilirlik tesis etmek zor olacak. Yetki çerçevesi ve onaylar iş ekibinin; ajanın yapılandırması, araçları ve değişiklik yönetimi ise yazılım sağlayıcısının sorumluluğunda olmalı. Bu sınıflandırmayla hatanın hangi katmanda başladığını gösterebilirseniz sorumluluğu paylaştırmaya başlayabilirsiniz.

Bugün en büyük eksiklik, özet düzeyindeki denetime bel bağlanması. Bir çalıştırmanın kaydında “görev başarıyla tamamlandı” yazıyorsa, kayba yol açan eylem para kaybolana kadar görünmez kalır ve geriye dönük inceleme adli soruşturmaya dönüşür. Baştan hesap verebilirlik için tasarlanmış; değiştirilemez, yetki çerçevesine ve kontrollere bağlı, hem ajandan hem de tedarikçisinden bağımsız bir kanıt izi gerekir. Bu iz, özel amaçlı ajanlar tarafından sürekli izlenmeli ve inceleme gerektiğinde sorunları hızla görünür kılmalıdır.

Palantir’in özel şirketten halka açık bir şirkete dönüşüm sürecini deneyimlediniz. Yatırımcılar, büyümesi otonom yapay zekâya bağlı şirketleri değerlendirirken etkili yönetişimi güven verici açıklamalardan ayırmak için hangi kanıtları talep etmeli?

Palantir’in özel şirketten halka açık şirkete dönüşümünü yaşamış biri olarak, açıklamalarda yönetişimi güven verici bir dille anlatma eğiliminin farkındayım: benimsenen çerçeveler, yayımlanan ilkeler ve kurulan komiteler. Yatırımcılar bunları asgari beklentiler olarak görmeli ve bunun yerine uygulamaya ilişkin kanıtları talep etmelidir.

Sorulmaya değer birkaç somut soru var.

Ajan eylemlerinin ne kadarı özet düzeyinde değil, eylem düzeyinde denetleniyor?

Ölçülen sapma oranı nedir ve zaman içinde nasıl bir seyir izledi?

Kaç olay yaşandı, bunlar ne kadar hızlı tespit edildi ve tespit edilmesi tasarım gereği miydi, yoksa şans eseri mi?

Bir ajanı kim durdurabilir, bunu ne kadar hızlı yapabilir ve bu kontrol onu geliştiren ekipten bağımsız mı? Yanıt, birinin bir şeyi fark etmesine dayanıyorsa bu bir kontrol değildir.

Son olarak ve biraz da sezgilere aykırı biçimde, şirketin başarısızlıklar yaşadığına ve bunlara nasıl karşılık verdiğini açıklayabildiğine dair kanıt arayın. Hiç ajan kaynaklı olay yaşanmadığını bildiren bir şirket ya ajanları geniş ölçekte kullanmıyordur ya da olup biteni izlemiyordur.

Bir finans kuruluşunun, bir ajanın yetkisini sınırlı bir pilot uygulamadan müşteri fonlarını aktarmaya veya işlem gerçekleştirmeye kadar genişletmeye hazır olduğuna sizi ne ikna ederdi? Hangi ölçülebilir sonuçlar ajana daha fazla özerklik verilmesini haklı çıkarır, hangileri ise özerkliğin azaltılmasını gerektirir?

Ajanın gerçekleştirdiği her eylemin eylem düzeyinde yetki çerçevesine göre denetlendiği, sapma oranının düşük ve istikrarlı olduğu ve ne anlama geldiğinin anlaşıldığı uzun bir dönem görmek isterdim.

Ölçülebilir göstergeler açısından, anlamlı sayıda çalıştırmada sapma oranının üzerinde anlaşılmış bir eşiğin altında kalmasını; meydana gelen her sapmanın, kayıt sistemine ulaşmadan önce denetim katmanı tarafından yakalanmasını; tespit ve kontrol altına alma sürelerinin günlerle değil dakikalarla ölçülmesini ve kanıt izinin gerçekten işe yaradığını göstermek için en az bir gerçek ramak kala olayın eksiksiz biçimde yeniden oluşturulmasını arardım.

Yetki, büyük sıçramalarla değil, aşamalı olarak genişletilmelidir. Daha yüksek sınırlara geçmeden önce kapsam genişletilmeli; denetimsiz çalışmaya geçmeden önce okuma-yazma yetkisi verilmeli; müşteri fonlarından önce kurum içi fonlar kullanılmalı ve her aşama için ayrı bir başlangıç ölçütü belirlenmelidir.

Özerkliği geri çekme gerekçeleri arasında kayıt sistemine ulaşan herhangi bir sapma; model veya araç değişikliğinin ardından sapma oranının yükselmesi; kurumun önceden haberdar olmadığı bir tedarikçi değişikliği; iz kaydındaki bir boşluk ya da insan müdahalesi oranının artması yer alır. Bu son durum genellikle yetki kapsamının kendisinin yanlış olduğu anlamına gelir.

Temel ilke, tıpkı yeni bir çalışanda olduğu gibi, özerkliğin hak edilmesi ve geri alınabilir olmasıdır; kurum, her iki durumda da bunu destekleyen kanıtları sunabilmelidir.

Harika röportaj için teşekkürler. Finansal hizmetlerde yapay zekâ yönetişimini sürekli güvencenin, bağımsız kontrollerin ve eylem düzeyindeki kanıtların nasıl destekleyebileceğini keşfetmek isteyen okurlar HelmGuard’ı ziyaret edebilir.