Güvenlik şirketi RedAccess, yapay zekâ kodlama araçlarıyla geliştirilen ve bu araçların kendi barındırma ortamlarında yayımlanan uygulamaları araştırdığında, neredeyse hiçbir güvenliği veya kimlik doğrulaması olmayan 5.000'den fazla uygulama buldu. Wired ile paylaştığı ekranlar arasında «çeşitli başka şirketlere ait muhtelif satış ve finans kayıtları» vardı. Finans ekipleri için yapay zekâyla geliştirilen uygulamalar da defteri kebir, bordro ve henüz açıklanmamış sonuçlarla birlikte aynı tür herkese açık adreste kalabilir.
Replit CEO'su Amjad Masad, «Herkese açık uygulamaların internetten erişilebilir olması beklenen davranıştır» diye yanıt verdi. Mekanizma konusunda haklı. Benim yorumuma göre bu ifşa, bir görünürlük ayarından ve atlanan bir incelemeden kaynaklandı; ikisi de aracı geliştiren kişinin düzeltebileceği konular.
Özetle
- Yapay zekâyla geliştirilen bir finans aracı, geliştiricinin düzeltebileceği altı yayına alma hatasıyla veri sızdırabilir: herkese açık bağlantı, kodda veya sohbet geçmişinde bırakılan parolalar ve anahtarlar, yönetici düzeyinde veritabanı erişimi, ikinci bir onaylayan olmadan muhasebe kayıtlarına işleme, dış hizmetlere gönderilen veriler ve kimsenin kaydetmediği hesaplama değişiklikleri.
- Her hatanın bir çözümü vardır. Çoğu, uygulamayı geliştiren aynı yapay zekâ aracı üzerinden uygulanır. Ayrıca çözümün işe yaradığını kanıtlayan açık bir kontrol vardır: veritabanının reddettiği bir yazma işlemi veya artık çalışmayan eski bir parola gibi.
- Finans aracını varsayılan olarak özel ağda tutun; finans dışındaki kişilerin ihtiyacı olduğunda şirket hesabıyla giriş ekleyin. Araç ikinci bir onaylayan olmadan deftere kayıt yapıyor, kart verilerine dokunuyor veya SOX kapsamındaki finansal tablolara sayı sağlıyorsa BT'ye devredin.
- Sunucu bölgesi, uygulamanın birincil VPS depolamasının yerini belirler; ancak yedekler, günlükler ve üçüncü taraf hizmetler başka yerlerde kopya oluşturabilir. Düzenin bütünüyle uyumlu olup olmadığı ayrı bir sorudur. Bölgenizdeki çerçeveleri uyumluluk ekibinize götürün.
Finansal Verileri Sızdıran Yayına Alma Hataları
Yapay zekâyla geliştirilen bir finans aracı altı yayına alma hatasıyla veri sızdırabilir: herkese açık bağlantıda bırakmak, kimlik bilgilerini kodda veya sohbette tutmak, salt okunur erişim yeterliyken yönetici erişimiyle bağlanmak, ikinci onaylayan olmadan kayıt yapmak, finansal verileri dış hizmetlere göndermek ve hesaplamaları kayıtsız değiştirmek. Demolarda bu varsayılanların her biri işe yarar görünür.
Aşağıdaki her çözüm, uygulamayı geliştiren yapay zekâ aracı için bir istem içerir; yapıştırmadan önce köşeli parantez içindeki alanları değiştirin. İstemler bu makale için yazılmış, test edilmemiş başlangıç noktalarıdır. Yapay zekâ aracınızın bir değişiklik yaptığını söylemesi hiçbir şeyi kanıtlamaz. Kanıt, her istemin altındaki kontroldür. İstemleri kod ve örnek ya da sentetik veri kümesi üzerinde çalıştırın; gerçek kayıtları veya kullanılan canlı anahtarları asla sohbete yapıştırmayın.
Aracı Yapay Zekâ Geliştirme Platformunun Herkese Açık Bağlantısında Bırakmak
Yapay zekâ geliştirme platformunun barındırma ortamında herkese açık bırakılan bir nakit tahmin panosunu, adresini bilen herkes açabilir ve gösterdiği her şeyi görebilir: borç yaşlandırması, bütçe ile gerçekleşen karşılaştırması ve çeyreğin açıklanmamış sonuçları. Wired'ın RedAccess bulgularına ilişkin haberi, araştırmacıların yapay zekâ sağlayıcılarının alan adlarında basit Google ve Bing aramalarıyla bu uygulamaları bulduğunu anlatır.
Bu uygulamaların bazıları ziyaretçilerden yalnızca herhangi bir e-posta adresiyle giriş yapmalarını istiyordu. Her e-posta adresini kabul eden bir giriş sistemi erişim denetimi değildir.
Gerçek verileri sağlayıcının barındırma ortamından kaldırın. Araç kontrol ettiğiniz bir sunucuda çalışana kadar (sonraki bölüm yer seçimini ele alır) geliştirme ve demoları sentetik veri kümesiyle veya varsa ERP'nizin sanal alanı ya da test şirketiyle yapın; asla gerçek veri dışa aktarımıyla yapmayın. Değişiklikten sonra yeniden yayına alın; barındırılan adres son yayına alınan sürümü sunar.
Bu uygulama için okuduğu tablo ve sütunlarla eşleşen sentetik bir veri kümesi oluştur: [tabloları ve sütunları listele; ör. vendors, invoices, journal_lines].
Uydurma tedarikçi ve müşteri adları, uydurma banka hesap numaraları ve gerçek muhasebe kayıtları gibi davranan [para birimi] tutarları kullan: her yevmiye kaydı dengelensin ve yardımcı defter toplamları [borçlar / alacaklar kontrol hesabı] ile mutabık olsun.
Uygulamayı herhangi bir gerçek veri dışa aktarımı yerine bu veri kümesine yönlendir; değiştirdiğin her dosyayı veya ayarı listele.
Benden gerçek kayıtlar isteme.
İşe yaradığını doğrulayın: sağlayıcıda barındırılan adresi oturum açılmamış bir tarayıcıdan açın veya finans dışındaki bir meslektaşınızdan açmasını isteyin. Yalnızca sentetik veri, bir giriş duvarı veya hiçbir şey göstermediğini doğrulayın. Ardından uygulamanın veri dosyalarında ve depoda gerçek ERP'nizden alınmış üç tedarikçi veya müşteri adını arayın; hiçbir eşleşme olmamalıdır. Son olarak uygulamanın mizanını veya özet görünümünü çalıştırın ve toplam borçların toplam alacaklara eşit olduğunu doğrulayın.
ERP, Banka Veri Akışı ve Veritabanı Kimlik Bilgilerini Kodda veya Sohbette Bırakmak
Kullanımdaki bir kimlik bilgisi burada saklanıyorsa, sohbet geçmişini, depoyu veya MCP yapılandırma dosyasını okuyabilen herkes bu bilgiyle ERP'ye, finans veritabanına veya banka veri akışı entegrasyonuna erişebilir. MCP, Claude gibi bir yapay zekâ aracının ERP veya veritabanıyla doğrudan iletişim kurmasını sağlayan bağlayıcıdır; yapılandırma dosyası da parolanın bulunabileceği başka bir yerdir.
GitGuardian'ın State of Secrets Sprawl 2026 raporu, MCP yapılandırma dosyalarında açığa çıkmış 24.008 benzersiz gizli bilgi buldu; bunların %14'ü PostgreSQL veritabanı bağlantı dizeleriydi. Aynı rapor, herkese açık GitHub commit'lerinde Claude Code'un ortak yazarı olduğu commit'lerin temel oranın yaklaşık iki katı sıklıkta gizli bilgi sızdırdığını buldu ve insan faktörünün de kritik olmaya devam ettiğini ekledi.
Sohbet mesajını silmek ifşayı geri almaz: sohbetin, deponun veya geçmişinin kopyasına sahip olanlarda değer hâlâ vardır. Bu yerlerden herhangi birinde bulunmuş her parola, anahtar veya belirteç için ERP, veritabanı ya da banka veri akışı yönetim konsolunda yenisini oluşturun ve eskisini devre dışı bırakın. Kimlik bilgilerini döndürmek bu demektir.
Uygulama daha sonra başlangıçta kimlik bilgilerini ortam değişkenlerinden (kodun dışında tutulan adlandırılmış ayarlardan) okur. Bunları, sunucunuzda uygulamayı derleyip çalıştıran dağıtım katmanı sağlar. Birkaç araç gizli bilgileri paylaşıyor ve bunların tek yerden döndürülmesi gerekiyorsa bir üst adım HashiCorp Vault'tur.
Ekibin kendi parola kopyaları Vaultwarden gibi insanlar için tasarlanmış bir parola yöneticisinde tutulmalıdır; çalışan uygulama değerlerini ortamdan okur. Önce yapay zekânın oluşturduğu kodda bulunan tüm sabit yazılmış gizli bilgileri bulun.
Bu projeyi sabit yazılmış gizli bilgiler açısından denetle. .env dosyaları, not defterleri, MCP yapılandırma dosyaları ve [ERP adı / banka veri akışı sağlayıcısı / finans veritabanı] bağlantı kodu dahil tüm parolaları, API anahtarlarını, erişim belirteçlerini ve bağlantı dizelerini bul.
Koddaki her değeri adlandırılmış bir ortam değişkeniyle değiştir ve değişken adlarının listesini ver.
Gerçek değerler içeren hiçbir dosyanın depoya commit edilmediğinden emin ol; depo geçmişinde bu değerlerden birinin göründüğü her commit'i listele.
Yalnızca konumları göster. Hiçbir gizli değeri yazdırma.
İşe yaradığını doğrulayın: eski parolayı veya belirteci kendiniz deneyin ya da BT'den denemesini isteyin; reddedilmelidir. Ardından mevcut proje dosyalarında eski değerleri arayın; bulunmamalıdır. Geçmişte kalan bir eşleşme, ancak değerin iptal edildiğini veya süresinin dolduğunu doğruladıktan sonra erişim sağlamaz.
Araç Yalnızca Okumalıyken Geliştiricinin Yönetici Hesabıyla Bağlanmak
Alacak yaşlandırması gösteren bir pano defteri kebiri değiştirememelidir. Araç geliştiricinin yönetici hesabıyla bağlanırsa o hesabın yetkilerini devralır. Supabase gizli anahtarı veya eski service_role anahtarı proje verilerine yükseltilmiş erişim sağlar ve Row Level Security'yi atlar; bu nedenle sıradan salt okunur erişim için kullanılmamalıdır. Tek bir yaşlandırma çizelgesi için hazırlanan rapor, böylece bordro tabloları dahil tüm defteri kebiri açığa çıkarır.
İşin maliyetli hâle geldiği yer yazma tarafıdır. Symbiotic Security'nin Supabase kullanan, yapay zekâyla geliştirilmiş 1.072 uygulamayı taraması, 172 uygulamanın herkesin kimlik doğrulaması olmadan kayıt silmesine, 172 uygulamanın mevcut kayıtları değiştirmesine izin verdiğini ve 39 uygulamanın tablolarının herkese açık anahtarı tutan herkesçe tamamen okunabildiğini buldu.
Araca yalnızca okuduğu tablolarla sınırlı, salt okunur bir kimlik bilgisi verin. ERP veya veritabanında bu, özel bir entegrasyon kullanıcısı demektir: araç için oluşturulmuş, yalnızca raporun ihtiyaç duyduğu nesneleri okuma yetkisine sahip ayrı bir hesap. Supabase'de aracın kullandığı dışarıya açık her tablo için Row Level Security'yi (her isteğin hangi satırları görebileceğine karar veren veritabanı kuralını) açın ve tablo yetkilerini de inceleyin: yetkiler, bir rolün select, insert, update veya delete işlemlerini yapıp yapamayacağını belirler. Salt okunur finans uygulamasının rolünde ihtiyaç duymadığı yazma işlemleri bulunmamalıdır. RLS ve en az ayrıcalıklı yetkiler doğruysa publishable anahtarı tarayıcı kodunda bulunabilir. Gizli ve eski service_role anahtarları sunucuda kalmalı; gerçekten yükseltilmiş erişim isteyen ve kendi yetkilendirmesini uygulayan arka uç görevlerine ayrılmalıdır.
Not: Supabase publishable anahtarının veya eski anon anahtarının sayfanın JavaScript'inde görünmesi normaldir. Supabase'in API anahtarı belgeleri, bunun yalnızca Row Level Security'nin izin verdiğine eriştiğini söyler. Gizli anahtar Row Level Security'yi atladığı için tarayıcıya gönderilen hiçbir şeyde görünmemelidir.
Bu uygulamanın [ERP veya veritabanı adı] üzerinde yaptığı her okuma ve yazmayı tablo veya nesneye göre gruplayarak listele.
Uygulamayı yalnızca [ihtiyaç duyduğu tabloları] okuyacak ve ortam değişkeninden sağlanan ayrı bir salt okunur kimlik bilgisiyle bağlanacak şekilde değiştir; asla benim hesabımı kullanmasın.
Uygulama Supabase kullanıyorsa: dokunduğu dışarıya açık her tabloda Row Level Security'yi aç. anon ve authenticated için select, insert, update ve delete yetkilerini listele. Bu salt okunur uygulamada gerekmeyen yazma yetkilerini kaldır; başka bir üretim uygulaması bunlardan birine bağımlıysa değiştirmek yerine işaretle. Ardından oturum açmamış ziyaretçilerin hiçbir şey okuyamamasını, oturum açmış kullanıcıların yalnızca [kural; ör. kendi maliyet merkezlerinin satırları] okuyabilmesini sağlayan politikalar yaz. Tarayıcıya gönderilen hiçbir dosyada gizli veya eski service_role anahtarı bulunmadığını doğrula.
Oluşturduğun politikaları listele.
İşe yaradığını doğrulayın: aracın kimlik bilgisiyle, örneğin bir test kaydını değiştiren tek bir yazma işlemi deneyin; reddedilmelidir. Supabase için oturum açmadan bir finans tablosunun satırlarını isteyin; boş sonuç veya hata almalısınız.
Aracın İkinci Bir Onaylayan Olmadan Deftere Kayıt Yapmasına İzin Vermek
Doğrudan kayıt yapan bir yevmiye içe aktarıcısı veya dosyayı doğrudan bankaya gönderen bir ödeme dosyası üreticisi, onu çalıştıran kişiyi hem hazırlayan hem onaylayan yapar. Tek bir hata bir aylık tahakkukları çoğaltır. Değişen tek bir alan tedarikçi ödemesini yanlış hesaba gönderir. Bu, finansın iki kişi arasında kabul etmediği görevler ayrılığı ihlalidir; yapay zekâ asistanıyla geliştirilen yazılıma istisna tanınmaz.
Zarar uygulamayla sınırlı kalmaz. Hatalı parti muhasebe kayıtlarına girer; geri almak için düzeltme kaydı ve dönem kapanışında açıklama gerekir. Araç geliştiricinin kendi hesabıyla kayıt yaparsa her mükerrer kayıt geliştiricinin adını taşır.
Yapay zekâyla geliştirilen araç okur ve hazırlar; kayıt ve ödeme serbest bırakma, ERP'nin kendi onay akışında, aracı çalıştırandan başka biri tarafından onaylanır. Çalıştığım her muhasebe motoru kaydı ve onayını iki ayrı sahibin iki ayrı olayı olarak ele alır; yapay zekâyla geliştirilen araç da aynı şekilde ele alınmalıdır.
Uygulamada her doğrudan kaydı, ERP içinde onay bekleyen taslak kayda veya hazırlanmış içe aktarıma çevirin. Araç sıkıcı işi (eşleme, doğrulama, parti oluşturma) yapmaya devam eder; onay, kapanışın bağlı olduğu diğer onayların yanında ERP'de kalır. ERP'de içe aktarımlar için onay adımı yoksa aracın çıktısı, ikinci kişinin parti özetiyle karşılaştırıp inceleyerek bizzat içe aktaracağı bir dosya olur.
Otomatik kayıt yapması, ödeme dosyası üretmesi veya tedarikçi banka bilgilerini değiştirmesi gereken araç, sonraki bölümdeki koşullarda BT'ye aittir.
Bu uygulamanın [ERP adı] içinde [yevmiye kayıtları / faturalar / ödemeler] oluşturduğu, değiştirdiği veya kaydettiği her yeri listele.
Her birini uygulamanın, kayıt yapılmadan önce [ERP adı] içinde onaylanması gereken taslak kayıt veya hazırlanmış içe aktarım yazacağı şekilde değiştir. [ERP adı] içe aktarımlar için onay adımı sunmuyorsa bunun yerine içe aktarım dosyası üret ve hiçbir kayıt yapma.
Bu onay olmadan kayıt yapan veya ödeme serbest bırakan her kod yolunu kaldır.
Her parti için satır sayısı, toplam borçlar ve toplam alacakları içeren özet üret.
Hâlâ doğrudan kayıt yapan her şeyi incelemem için listele.
İşe yaradığını doğrulayın: örnek veriden bir parti çalıştırın. İkinci kullanıcı ERP'de onaylayana kadar hiçbir şey kaydedilmiş görünmemelidir. Ardından parti özetini ERP'nin aynı parti için gösterdikleriyle karşılaştırın: satır sayısı, toplam borçlar ve toplam alacaklar tam olarak eşleşmelidir. Bir satırlık fark yuvarlama meselesi değil, başarısız mutabakattır.
Finansal Verileri Kontrolünüz Dışındaki Hizmetlere Göndermek
Defteri kebirin tam dışa aktarımını yapay zekâ API'sine gönderen bir sapma açıklama özelliği, her satırı üçüncü tarafa iletir. Daha az görünür iki yol da veri çıkarır: her ziyareti sağlayıcısına bildiren sayfa analiz betiği ve tam istek gövdelerini tutan hata izleyici veya günlük. Bunlarda bordro satırları, müşteri banka bilgileri ve açıklanmamış sayılar bulunabilir.
Finans ekibinin geliştirdiği dahili araçta, hizmet ve tam veri akışı kuruluşunuzun tedarikçi, güvenlik ve uyumluluk süreciyle açıkça onaylanmadıkça açıklanmamış sonuçları ve bordroyu üçüncü taraf çağrılarından uzak tutun. Diğer her şey için tüm hedefleri listeleyin ve her çağrıya yalnızca gereken alanları gönderin. Dış hizmetin aldıklarını saklayıp saklamadığı veya eğitimde kullanıp kullanmadığı, o sağlayıcının koşullarına bakarak tedarikçi sözleşmelerini imzalayan kişinin yanıtlayacağı sorudur. Ekip aracın kullanım sıklığını öğrenmek istiyorsa Umami gibi kendi barındırdığınız bir analiz aracı sayfa görüntülemelerini kendi sunucunuzda tutar.
Bu uygulamanın [sunucumuz] dışına veri gönderdiği her yeri listele; yapay zekâ API'leri, analiz betikleri, hata takibi, e-posta, webhook'lar ve günlük dosyaları dahil.
Her hedefin tam olarak hangi alanları aldığını listele.
[Bordro tutarları / banka hesap numaraları / açıklanmamış sonuçlar / müşteri adları] içeren her şeyi işaretle.
İşaretlenen her öğe için daha az alan veya hiçbir alan göndermemenin yolunu göster; değişikliği ancak ben onayladıktan sonra yap.
İşe yaradığını doğrulayın: tanınabilir sahte hesap numarası ve sahte bordro tutarı içeren örnek veriyle her özelliği bir kez tetikleyin. Hata izleyicide ve günlüklerde iki değeri de arayın; bulunmamalıdır. Yapay zekâ API'si yolu için örnek çalıştırmada uygulamanın giden istek gövdesini günlüğe yazmasını sağlayın. Günlükte aynı iki değeri arayın; yalnızca onayladığınız alanlar bulunmalı, ikisi de bulunmamalıdır. Sonrasında bu günlüğe yazmayı kapatın.
Hesaplamaları Kayıt ve Mutabakat Olmadan Değiştirmek
Tahakkuk hesaplayıcısında veya gelir şelalesi (revenue waterfall) doğrulayıcısında kod, kontrolün kendisidir. Bir formülü değiştirirseniz kapanışa giden sayılar da değişir. Sürüm kontrolü yoksa kimin neyi ne zaman değiştirdiğini kimse söyleyemez.
Bir CPA firmasının Claude Code ile geliştirdiği dahili araçları anlattığı r/ClaudeAI başlığında bir yorumcu sınırı açıkça ifade etti: «'muhasebeci + claude code', denetim izi gerekliliklerine gelene kadar çalışır. Gerçek sınır budur.»
Bir şeyi değiştirmeden önce bugünkü davranışı sabitleyin. Çıktılar sabitlendiğinde mantık, toplamların fark edilmeden kaymasına yol açmadan geliştirilebilir. Kodu, her değişikliği yazarı ve tarihiyle kaydeden sürüm kontrolünde tutun.
Aracı sabit bir örnek dosyayla çalıştıran ve sonuçları kayıtlı referansla karşılaştıran testler yazın; böylece her değişiklik yayımlanmadan önce kod bir mutabakattan geçmelidir. Sabitlenen test, hatalar dahil kaydettiği her şeyi korur; bu nedenle güvenmeden önce referans toplamlarını ERP'nin aynı dönem toplamlarıyla mutabık hâle getirin.
Hesaplama mantığındaki her değişikliği ikinci bir kişinin incelemesini zorunlu kılın; her üretim çalıştırmasını ERP'nin kendi toplamlarıyla mutabık hâle getirin.
Henüz değilse bu projeyi sürüm kontrolüne al; hangi dosyaların hesaplama mantığı içerdiğini listele.
Uygulamayı [örnek dosya] ile çalıştıran ve bugünkü çıktıları kaydeden testler yaz: [hesap / tüzel kişilik / dönem] bazında satır sayıları ve toplamlar.
Kayıtlı çıktıları kaydetmeden önce toplamları bana göster; böylece [dönem] için [ERP adı] ile mutabakat yapabilirim.
Bu toplamların herhangi birini değiştiren her değişiklik bir testi başarısız kılmalı.
Testleri yazarken hesaplama mantığını değiştirme.
İşe yaradığını doğrulayın: örneğin bir yuvarlama kuralını değiştirerek bir hesaplamayı bilerek değiştirin ve bir testin başarısız olduğunu doğrulayın. Değişikliği geri alın ve tüm testlerin tekrar geçtiğini doğrulayın.
Varsayılan Olarak Özel Ağ, Daha Fazla Kişi Gerektiğinde Şirket Girişi, Defter İçin BT
Gerçek finansal veriler asla yapay zekâ aracının barındırma ortamında kalmaz. Yapay zekâyla geliştirilen finans uygulamasını yalnızca finans ekibi için güvenli biçimde yayına almak üzere, kontrol ettiğiniz ve yalnızca özel ağdan erişilebilen bir sunucuya koyun. Ekip dışındaki kişilere gerektiğinde şirket hesabıyla giriş ekleyin; aşağıdaki listedeki herhangi bir koşul geçerliyse BT'ye devredin.
VPS, işletim sistemini ve yazılım yığınını kontrol ettiğiniz kiralık sanal sunucudur. Özel ağ (Tailscale terimiyle tailnet), onaylı cihazları bu sunucuya bağlar. Aracı açık internetten uzak tutmak için örneğin sunucu güvenlik duvarıyla uygulamaya herkese açık gelen erişimi yine engellemeniz ve yalnızca VPN veya tailnet arayüzünden sunmanız gerekir. Kimlik sağlayıcısı şirketin kullanıcı hesaplarını tutar; ters vekil sunucu ise uygulamanın önündeki kapı bekçisidir ve her isteği önce girişten geçirir.
| Yayına Alma Düzeyi | Kim Erişebilir? | Uygun Kullanımlar | Çalıştıran Bileşenler |
|---|---|---|---|
| Yalnızca özel ağ | Finans ekibi, kendi cihazlarıyla | Mutabakat yardımcıları, nakit tahminleri, kapanış kontrol listeleri, açıklanmamış sayıları gösteren her şey | Coolify veya Dokku gibi bir dağıtım katmanına sahip, yalnızca Tailscale veya WireGuard üzerinden erişilebilen VPS |
| Önde şirket hesabıyla giriş | Bütçe sahipleri ve bölüm yöneticileri gibi şirket genelinde adı belirlenmiş kişiler | Bütçe ile gerçekleşen karşılaştırmaları, harcama talepleri | Düzey 1'e ek olarak ters vekil sunucu (Caddy veya Nginx Proxy Manager) arkasında kimlik sağlayıcısı (Authentik veya Keycloak) |
| Sahibi BT veya mühendislik ekibidir | BT'nin belirlediği kişiler | BT'ye devir listesindeki bir koşulu karşılayan her araç | BT'nin kendi platformu |
İlk hatada belirtilen nedenlerle yapay zekâ aracının kendi barındırması tabloda yer almaz. Northflank gibi kurumsal dağıtım platformları da yer almaz; bunlar platform sağlayıcılarını ve gerektirdikleri incelemeleri zaten bütçelendiren büyük kuruluşlara uygundur. Birkaç kullanıcılı departman aracının ihtiyaç duyduğundan daha fazla sözleşme yükü getirir.
Deneyimime göre iki özel ağ seçeneğinden daha hızlı kurulabileni Tailscale'dir; ancak Tailscale koordinasyon hizmetini kendisi barındırır. Tamamen kendi barındırdığınız seçenek WireGuard'dır.
Özel ağı varsayılan yapmamın gerekçesi şudur: internetten yanıt vermeyen araç aramayla bulunamaz veya giriş sayfasından saldırıya uğramaz; yapay zekâ aracının yazdığı giriş sayfası ise arkasındaki yapay zekâ kodu kadar iyidir. Uygulamayı özel ağın ötesine açmanız gerekiyorsa şirket girişi önüne yönetilen kimlik doğrulama katmanı ekler; bu yüzden ikinci sıradadır.
Bütçe sahiplerinin erişmesi gerektiğinde aracın kendi girişini, tek oturum açma (SSO) da denen şirket girişiyle değiştirin: kişiler mevcut şirket hesaplarını kullanır; o hesabın devre dışı bırakılması yeni girişleri engeller. Mevcut oturumların sürmemesi için oturum iptali, arka kanal çıkışı veya yeterince kısa oturum süreleri yapılandırın. İstem, Authentik ve Keycloak'ın desteklediği standart giriş protokolü OIDC'yi kullanır.
Bu uygulamanın kendi girişini, OIDC kullanarak [Authentik / Keycloak / kimlik sağlayıcımız] üzerinden şirket girişiyle değiştir.
Girişten her kullanıcının grubunu oku.
[Bordro sayfalarına] yalnızca [grup adı] üyelerinin erişmesine izin ver; bu kuralı yalnızca menüde değil, her sayfa, dışa aktarım ve API uç noktası için sunucuda uygula.
Geçerli giriş bilgisi taşımayan her isteği reddet.
İşe yaradığını doğrulayın: grupta olmayan bir test hesabıyla giriş yapın; kısıtlı sayfayı ve dışa aktarım ya da API adresini doğrudan isteyin. İkisi de reddedilmelidir. Ardından kimlik sağlayıcısında test hesabını devre dışı bırakın ve yeni oturum başlatamadığını doğrulayın. Mevcut oturumun da iptal edildiğini veya yapılandırdığınız süre içinde dolduğunu doğrulayın.
Bazı araçlar ekibin elinde hiç kalmamalıdır. Bunlardan biri geçerliyse aracı BT'ye veya mühendisliğe devredin:
- ERP'de bir kişinin onayı olmadan defteri kebire veya başka bir kayıt sistemine kayıt yapıyorsa.
- Ödeme dosyaları üretiyor, ödemeleri serbest bırakıyor veya tedarikçi banka bilgilerini değiştiriyorsa.
- Çıktısı SEC'e kayıtlı bir kuruluşun finansal tablolarına giriyorsa; bu durum aracı finansal raporlama üzerindeki iç kontrol (ICFR) kapsamına sokabilir. Kapanışta kullanılmadan önce iç denetime danışın; SOX Bölüm 404(b)'ye tabi ihraççılar için dış denetçi de ilgili kontrolleri test edebilir.
- Ödeme kartı verilerini saklıyor, işliyor veya iletiyorsa.
- Bireylerin kredi değerliliğini puanlıyorsa.
- Ekipte kimse yamaları, erişim incelemelerini ve aracın kullanımdan kaldırılmasını üstlenmeyecekse.
Altıncı koşul göründüğünden daha önemlidir. Kendi barındırmanızda güncellemeler, yedekler ve izleme sizin sorumluluğunuzdadır; kimsenin bakımını yapmadığı finans aracı BT'de daha güvenlidir. BT daha yavaş olabilir; bu, bu koşulların gerektirdiği yönetişimin bedelidir.
1 ve 2. düzeylerde, biri aracı açmadan önce sunucu, dağıtım katmanı, özel ağ ve 2. düzey için kimlik sağlayıcısı kurulmuş olmalıdır; mühendisi olmayan finans ekibi bunları kendisi kurmalıdır. Linux VPS hizmetimizde root erişimi alırsınız. Coolify ve WireGuard tek tıkla dağıtım olarak sunulur; Tailscale resmi tek komutlu kurucusuyla yüklenir, Authentik ise resmi Docker Compose yığınından çalışır. Böylece ekip zamanını dağıtım yığınını sıfırdan kurmak yerine yukarıdaki çözümlere ayırabilir. Konumlarımız arasında AB'de Frankfurt ve Amsterdam, Birleşik Krallık'ta Londra ve ABD'de birkaç şehir bulunur; uygulamanın birincil VPS depolaması için bölge seçebilirsiniz. Seçimin kabul edilebilir olup olmadığı uyumluluk ekibinin sorumluluğundadır.
Bölgelere Göre Uyumluluk Ekibinizle Kontrol Edilecek Kurallar
Hangi çerçevelerin geçerli olduğu, aracın neye dokunduğuna ve şirket ile verilerdeki kişilerin nerede bulunduğuna bağlıdır. AB çalışanlarının maaşlarını tutan bordro tablosu ile ABD borsasında işlem gören bir şirketin finansal tablolarına giren gelir çizelgesi farklı çerçevelere tabi olabilir.
Bu makaledeki hiçbir şey hukuki danışmanlık değildir. Aşağıdaki tablo, uyumluluk ekibinize götüreceğiniz çerçeveleri listeler; bunlardan herhangi birinin size uygulanıp uygulanmadığını belirlemez.
| Nerede / Ne Zaman | Uyumluluk Çerçevesi | Uyumluluğa Sorulacak Soru | Nereden Okunur? |
|---|---|---|---|
| ABD, SEC'e raporlama yapan şirketler | Sarbanes-Oxley Bölüm 404, finansal raporlama üzerindeki iç kontrol (ICFR) | Bu aracın çıktısı finansal tablolara giriyor mu; kontrol envanterimizde yer almalı mı? | PCAOB'nin AS 2201 standardı |
| AB, kişisel veriler (bordro, çalışan giderleri, müşteri banka bilgileri) | GDPR | Bu araçtaki veriler için hukuka uygun dayanağımız nedir; güvenlik önlemleri Madde 32'yi karşılıyor mu? | EDPB'nin kişisel verileri güvenceye alma rehberi |
| Birleşik Krallık, kişisel veriler | UK GDPR | UK GDPR kapsamındaki hukuka uygun dayanağımız nedir; araç güvenlik ilkesini karşılıyor mu? | ICO'nun veri koruma ilkeleri rehberi |
| Kart verilerinin söz konusu olduğu her yer | PCI DSS (sektör standardıdır, kendi başına kanun değildir) | Bu araç kart verilerini kapsama dahil ediyor mu; kart verilerine hiç dokunmaması mümkün mü? | PCI Security Standards Council'ın PCI DSS açıklaması |
| AB, araç bireylerin kredi değerliliğini değerlendiriyorsa (Ek III yüksek risk kuralları mevcut takvime göre 2 Aralık 2027'den itibaren uygulanır) | AB Yapay Zekâ Yasası, yüksek risk kategorisi (finansal dolandırıcılığı tespit etmek için kullanılan yapay zekâ hariçtir) | Bu, Ek III kapsamında yüksek riskli bir yapay zekâ sistemi mi? | Avrupa Komisyonunun Yapay Zekâ Yasası sayfası; Yapay Zekâ Yasası Ek III |
| Geçerli yargı alanı dışında ayrı bir alıcıya sunulan AB veya Birleşik Krallık kişisel verileri ya da kayıtların yerini belirleyen müşteri sözleşmeleri | GDPR Bölüm V, Birleşik Krallık uluslararası aktarım kuralları, müşteri sözleşmeleriniz | Bu veriler [konum] içindeki sunucuda tutulabilir mi; herhangi bir müşteri sözleşmesi bunu kısıtlıyor mu? | EDPB'nin uluslararası veri aktarımları rehberi; ICO'nun uluslararası aktarımlar rehberi |
SOX satırı için AS 2201, Sarbanes-Oxley Yasası'nın Bölüm 404(b)'sinde atıf yapılan denetçi tasdikine ilişkin PCAOB standardıdır. Dolandırıcılık riskini ele alırken denetçinin değerlendirdiği kontroller arasında dönem sonu finansal raporlama sürecinde yapılan yevmiye kayıtları ve düzeltmelere ilişkin kontrolleri sayar. Bu bölgeler dışında, ulusal veri koruma düzenleyicinizin kendi sitesinden başlayın. Sunucunun konumu birincil depolamanın yerini belirler; her yedeğin, günlüğün veya üçüncü taraf kopyasının nerede olduğunu söylemez ve yukarıdaki çerçevelerden herhangi birini tek başına karşılamaz.
Sıkça Sorulan Sorular
Vibe Coding Finans Araçları İçin Güvenli mi?
Demodan kalan açıklar kapatıldığında olabilir; kanıtları kodlamadan çok yayına alma sorunu olarak yorumluyorum. Finans aracı, ERP'yi okuduğu ve muhasebe kayıtlarına yazabildiği için kişisel projeden daha risklidir. İkinci bir onaylayan olmadan kayıt yapmaya, ödemeleri işlemeye veya kart verilerine dokunmaya başladığında BT'ye aittir.
Finansta Gölge Yapay Zekâ Nedir?
Gölge yapay zekâ, BT'nin bilgisi veya onayı olmadan şirket verilerinde kullanılan yapay zekâ araçları veya yapay zekâyla geliştirilen uygulamalardır; örneğin BT'nin hiç görmediği ERP bağlantılı tahmin panosu. IBM'in duyurusuna göre IBM'in 2025 Cost of a Data Breach Report raporu, yüksek düzeyde gölge yapay zekâ kullanan kuruluşların ortalama ihlal maliyetinin az kullanan veya hiç kullanmayanlardan 670.000 ABD doları daha yüksek olduğunu buldu.
İç Denetime veya Dış Denetçiye Ne Göstermeliyiz?
Araç kapanışta kullanılmadan önce dört şey sunun: nerede çalıştığı ve kimin erişebildiği, sabit çıktı testleriyle değişiklik geçmişi, ERP'de kayıtların nasıl onaylandığı ve her partiyi ERP toplamlarıyla eşleştiren mutabakat kanıtları. Denetçinin ne isteyeceğine kendisi karar verir; bunlar değerlendirebileceği somut malzemeler sağlar.
Geliştiren Kişi Ayrıldıktan Sonra Yapay Zekâyla Geliştirilen Finans Aracının Sahibi Kimdir?
Lansmandan önce finanstan bir sahip ve teknik irtibat kişisi belirleyin. Aracı geliştiricinin kendi hesabı yerine hizmet kimlik bilgisiyle çalıştırın ve erişimi şirket girişinden geçirin; böylece ayrılan kişinin şirket hesabını devre dışı bırakmak yeni girişleri engeller. Mevcut oturumlar politikanıza göre iptal edilmeli veya süreleri dolmalıdır. Aracı kullanımdan kaldırmak, kimlik bilgilerini devre dışı bırakmak, saklama politikanızın gerektirdiklerini tutmak, kalanları silmek ve aracı kapatmak demektir.
Tartışma
Yorumlar
Tartışmaya katılmak için giriş yapın.