Kurumsal İstihbarat: OSINT ve Data Fusion ile Karar Verme Mimarisi

Bir kurum bir konuda karar verirken, ihtiyacı olan bilginin yarısından fazlası kendi sistemlerinde zaten vardır. Diğer yarısı dışarıdaki açık kaynaklarda: kamu kayıtları, sosyal medya, sektör haberleri, dark web sızıntıları, harici tedarikçi verileri. Sorun bilgiye erişim değil, bu iki kümeyi aynı soruya cevap verecek şekilde birleştirebilmedir. Bizim siber istihbarat ekibimizin son üç yılda gözlemlediği şu: kurumsal kararların gecikme sebebi genellikle "veri yokluğu" değil, "veri parçalanması"dır.

Bu yazı, OSINT ile data fusion disiplinlerinin nasıl birlikte çalışıp bir kurumun karar verme katmanını değiştirdiğini anlatıyor. Hem teknik mimari, hem yasal sınırlar, hem operasyonel pratik birlikte. Mühendislik ekibimizin Palantir-tipi platformlar kurarken edindiği yedi pratiği sırayla paylaşıyoruz.

1. İki disiplinin sınırı ve birleştiği yer

OSINT (Open Source Intelligence) bir veri kaynağı tipini tanımlar — herkese açık, yasal yollarla erişilebilir dijital izlerden yapılandırılmış bilgi toplamayı kapsar. İçerik şunlardır: kamu kayıtları (ticari sicil, mahkeme kararları, vergi verileri), sosyal medya açık paylaşımları, haber siteleri, dark web forumları (yasal sınırlar dahilinde), şirket web siteleri, akademik makaleler, harici veri sağlayıcılar.

Data fusion ise farklı kaynaklardan gelen verileri tek bir bağlantı grafiğinde birleştirme disiplinidir. Kaynaklar OSINT olabilir, kurumsal CRM'iniz olabilir, SOC log'larınız olabilir, harici tehdit istihbaratı feed'leri olabilir. Data fusion'ın değeri yeni veri toplamakta değil — zaten var olan veriyi yeni sorulara cevap verecek şekilde modellemekte.

İki disiplinin birleştiği yer şudur: OSINT topladığınız ham veriyi, data fusion platformu üzerinden kurumsal verinizle entegre edersiniz. Tek başına OSINT raporu PDF olarak kalır; tek başına data fusion içeride sıkışıp dışarıyı görmez. Birleştirildiğinde, "Bu yeni müşteri adayı son altı ayda hangi hukuki dava ile ilişkilendi, yönetim kurulundaki kim Twitter'da hangi rakibi takip etti, BİST'teki hisse hareketi son raporlarımızla uyumlu mu?" tipi soruların cevabı bir tıklama ile gelir.

2. Veri kaynak haritası — ilk hafta

Her data fusion projesinin başında yapılan en kritik iş, kaynak haritasının çıkarılmasıdır. Bu, "şu sistemleri kullanıyoruz" listesi değil; her sistemin hangi entity'leri tuttuğu, hangi alanlarda eşleştirilebilir olduğu, ne sıklıkta güncellendiği şeklinde detaylı bir envanterdir.

Tipik bir kurumsal projede haritada şunlar yer alır:

• Kurumsal sistemler: CRM (müşteri, kontak, fırsat), ERP (sipariş, fatura, stok), HR sistemi (çalışan, pozisyon), helpdesk (ticket, çözüm).
• Operasyonel veriler: SOC log'ları, network telemetri, uygulama log'ları, audit trail.
• OSINT besleme: ticari sicil API'leri, BİST/finansal veri sağlayıcıları, dark web izleme servisleri, sosyal medya monitoring (yasal sınırlar içinde), KVKK Veri İhlali Bildirim sayfası.
• Doküman arşivi: sözleşmeler, hukuki yazışmalar, denetim raporları, müşteri görüşme notları.

Haritanın çıkarılması sırasında en sık bulunan sürpriz: aynı entity'nin farklı sistemlerde farklı ID'lerle tutulması. Aynı müşteri CRM'de "Acme A.Ş.", ERP'de "ACME ANONIM SIRKETI", helpdesk'te "acme" diye geçer. Bu farklılığı çözmek entity resolution denilen ayrı bir mühendislik problemidir.

Geçtiğimiz iki projeden ortaya çıkan pratik örnek: bir finans kurumu için yaptığımız haritada dokuz farklı sistem listelendi; iki haftalık derin tarama sonunda on dört olduğu anlaşıldı. Eksik beş sistem küçük departman araçlarıydı (Excel macro şablonları, paylaşımlı SharePoint klasörleri, eski bir Access veritabanı, bir tedarikçi portalı, bir e-posta filtre kuralı). Bu beş kaynak harici listede yoktu çünkü kurumsal IT envanteri bunları "shadow IT" olarak gizli sayıyordu. Pratik kural: haritalama her seferinde eksik başlar, ekiplerin günlük iş akışını gözlemleyerek tamamlanır. Yalnızca CIO ofisinden gelen IT envanterine güvenen projelerin %40-60'ı üretimde "bilmediğimiz veri kaynağı" sürpriziyle gecikir.

3. Entity resolution — graf modelinin omurgası

Entity resolution, farklı sistemlerde aynı varlığa ait farklı kayıtları birleştirme sürecidir. Üç teknik birlikte kullanılır:

Deterministik eşleşme: vergi numarası, MERSİS numarası, TC kimlik numarası gibi benzersiz tanımlayıcılar üzerinden eşleştirme. En güvenilir yol; %99+ doğruluk. Sınırı: bu tanımlayıcılar her sistemde tutulmuyor olabilir.

Olasılıksal eşleşme: ad benzerliği (Levenshtein mesafesi, fonetik algoritmalar), telefon/e-posta normalizasyonu, adres parsing. %85-95 doğruluk; eşik üzeri eşleşmeler otomatik birleştirilir, eşik altı insan analiste düşer.

Bağlamsal eşleşme: aynı toplantıya katılmış iki kişi, aynı ip adresinden işlem yapan iki hesap, aynı imza dosyasını imzalamış iki şirket. Graf üzerinde komşuluk üzerinden çıkarılır; AIGENCY V4'ün AI ajanlarıyla otomatize edilir.

Üç tekniğin birleştirilmesinden çıkan birleşik entity grafiği, sonraki tüm sorgulamaların temelidir. Bu grafiği doğru kurmak için projenin ilk iki haftasını ayırırız; yanlış kurulduğunda sonraki tüm analiz hatalı verilen üzerine çalışır.

4. KVKK uyumu — eklenti değil mimari karar

OSINT ve data fusion projeleri KVKK uyumunu son katmana eklenti olarak ekleyemez. Tasarım aşamasında üç katman birlikte düşünülmek zorundadır:

Hukuki temel katmanı: Hangi veri kategorisi (kişisel, hassas, anonim) hangi hukuki temele dayanarak işleniyor? KVKK md.5 (açık rıza), md.6 (özel nitelikli veri için ek koşul), md.9 (yurt dışı aktarım) çerçevesinde her veri akışı belgelenir. "Halka açık olduğu için işleyebiliriz" yaklaşımı yanlıştır — KVKK'da bu istisna yoktur; meşru menfaat dengesi yapılmalıdır.

Anonimleştirme katmanı: Karar verme amacı için tam kimlik gerekli değilse, entity ID'leri hash'lenir; ham veri yalnız yetkilendirilmiş analiste açık kalır, dashboard'lar agrega/anonimleştirilmiş veri gösterir. Türkiye sınırları içinde işlenmek üzere AIGENCY V4'ün şifrelenmiş bellek katmanı kullanılır.

Denetim izi katmanı: Her sorgu, hangi rol, hangi entity'ye, hangi sebeple eriştiğine dair log üretir. Bu log değiştirilemez (append-only) şekilde tutulur. KVKK Kurumu denetim talebinde 24 saat içinde dump üretilebilir olmalı.

Üç katman birlikte tasarlanırsa uyum maliyeti proje toplam efforunun %5-10'unu geçmez. Sonradan eklenirse aynı uyumu sağlamak %30-50 ek geliştirme süresi anlamına gelir; bizim kurumsal yapay zekâ platformu kurulum hizmetimiz bu mimariyi standart olarak içerir.

5. Yetkilendirme — kim hangi düğümü görür

Data fusion platformunun en sık ihmal edilen ama en kritik özelliği rol-bazlı yetkilendirmedir. Tek bir veri tabanı + tek bir dashboard yaklaşımı küçük ekipler için çalışır; orta-büyük kurumlarda çekirdek güvenlik problemi yaratır.

Permissioned graph mimarisinde her düğüm (entity) ve her ilişki (edge) ayrı yetkilendirme metadata'sı taşır. Örnek senaryolar:

• Pazarlama analisti: müşteri adı + sektör + satış geçmişini görür; finansal sağlamlık skoru görünmez.
• Hukuk birimi: tüm sözleşme metni + risk uyarıları görür; CRM iletişim notlarını görmez.
• Üst yönetim: sentez raporları + trend analizleri görür; ham veriye erişim YOK.
• SOC ekibi: tüm sistem log'ları + tehdit istihbaratı görür; müşteri kişisel verisi YOK.

Hangi rolün hangi alanı göreceği iş sahibi ile kararlaştırılır, mühendislik kendi başına karar veremez. Bizim pratiğimiz: proje başında "rol matrisi" çıkarılır, her sütun (rol) × satır (entity tipi) için yetki seviyesi (görmüyor / agrega / detay) belirlenir. Bu matris ortaya çıkmadan kod yazılmaz.

6. AIGENCY V4 entegrasyonu — doğal dil sorgulama

Data fusion grafiğinin gerçek değeri, analist olmayan kullanıcıların da sorguya cevap alabilmesine bağlıdır. Klasik yaklaşımda her sorgu için SQL/Cypher bilen bir veri analisti gerekir; bu hem darboğaz, hem yüksek operasyon maliyeti.

AIGENCY V4'ün 8-ajan mimarisi bu darboğazı çözer. Kullanıcı doğal dilde sorar: "Acme A.Ş. ile son altı ayda hangi davalarımız geçti, hangi yönetim üyeleri bu süreçlerde adı geçen kişilerle bağlantılı?"

Sistemin yaptığı:

1. Koordinatör ajan soruyu alt görevlere böler.
2. Araştırmacı ajan graf veritabanına Cypher sorguları yazar (Neo4j'de) veya GraphQL API'sini çağırır.
3. Denetçi ajan sonuçların yetkilendirme katmanından geçtiğini doğrular; izin yoksa kısmi cevap döner.
4. Yazılımcı ajan sonuçları kullanıcının istediği formata (tablo, görsel, sentez) dönüştürür.
5. Sentez ajanı doğal dilde cevap yazar; kaynak düğüm referansları (kanıt zinciri) ile birlikte.

Bu mimari, kurumsal AI platformu kurulum hizmetimiz ile birlikte gelir. Eğitilmiş bir analist saatte 3-5 sorgu cevaplarken, AIGENCY V4 destekli sistem saatte 30-50 sorgu cevaplayabilir; analiste yalnızca belirsizlik durumlarında danışılır.

Doğal dil sorgulamanın iki ek faydası vardır. Birincisi, soru formülasyonu kullanıcının veri modelini öğrenmesini gerektirmez; analist "müşteri segmenti" derken pazarlama "müşteri kohortu" diyebilir, mimari iki terimi de aynı entity'ye çözer. İkincisi, kullanıcı sorgusu zaman içinde kullanım örüntüsü olarak kaydedilir; en sık sorulan 50 sorguya optimize edilmiş materialize view'lar üretilebilir, sistem performansı kullanıma göre öğrenir. Klasik BI araçlarının statik dashboard yaklaşımından temel farkı budur.

Doğal dil sorgulamanın sınırı şudur: belirsiz veya çelişkili sorularda model kendi yorumunu uygular. Bu yüzden denetçi ajan kritiktir — sorgunun yorumu (parse tree) kullanıcıya gösterilir, "şunu mu sormak istediniz?" doğrulaması yapılır. Bu adımı atlayan sistemler yanlış cevabı doğru gibi sunma riskine açıktır; AIGENCY V4'te bu adım zorunludur.

7. Tipik kurulum hatalarımız ve öğrendiklerimiz

Son üç yılda yaptığımız 12 data fusion projesinde ortaya çıkan ortak hataların listesi (ve kendimize koyduğumuz süreç değişiklikleri):

Hata 1: Veri modeli kararını çok geç vermek. İlk iki projemizde graf şemasını ETL'den sonra rafine ettik; sonuç: pipeline'ları iki kez yazdık. Düzeltme: Faz 1 (1-2 hafta) sonunda graf şeması donmuş olmalı; sonraki tüm pipeline'lar bu şemaya yazılır.

Hata 2: Entity resolution eşiğini tek değer olarak ayarlamak. Tek bir 0.85 benzerlik eşiği ya çok birleştirir (yanlış pozitif) ya yetersiz birleştirir (yanlış negatif). Düzeltme: İki eşik kullanıyoruz — 0.95 üstü otomatik birleştir, 0.75-0.95 arası insan analiste düşer, altı reddedilir.

Hata 3: KVKK denetim sorularını sona bırakmak. Bir projemizde proje sonunda KVKK Veri Sorumlusu rehberindeki denetim log dump gereksinimi atlandığı için ek 3 hafta refactor yaşadık. Düzeltme: Audit logging artık Sprint 0'da kurulur, son uygulamadır değil ilk uygulamadır.

Hata 4: Çok kullanıcı seçeneği sunmak. Erken bir projede analiste 20+ filtre + 15+ görselleştirme seçeneği verdik; kimse hepsini kullanmadı, dokümantasyon büyüdü. Düzeltme: Önce 3-5 "altın senaryo" tanımlanır; tüm UI bu senaryoları optimize eder.

Hata 5: Yedek + felaket kurtarma planını yazmamak. İki yıl boyunca büyüyen graf veritabanının ne kadar kritik olduğunu, bir disk arızası ile fark ettik. Düzeltme: Her projede günlük snapshot + farklı coğrafyada (Şanlıurfa + Düsseldorf) replikasyon + 4 saatlik RPO/RTO garantisi.

Hata 6: Performans testlerini gerçek veri ölçeği ile yapmamak. Pilot ortamda 10.000 düğüm üzerinde mükemmel çalışan sorgu, üretime 5 milyon düğümle çıkınca 90 saniyeye yavaşladı. Düzeltme: Pilot aşamada bile sentetik veri jeneratörü ile üretim ölçeğinde stres testi zorunlu. Sorgu süresi p95 < 2 saniye eşiği geçilmedikçe canlıya çıkmaz.

Hata 7: Kullanıcı eğitimini son haftaya bırakmak. Teknik mükemmellik tek başına benimsenmeyi sağlamıyor. Önceki bir projemizde sistem teslim edildi, 6 hafta sonra kullanım oranı %15'te kaldı; kullanıcılar eski Excel raporlarına döndü. Düzeltme: Pilot fazından itibaren haftalık çalıştay ile son kullanıcılar dahil edilir; teslimat günü değil ilk gün eğitim başlar. Bu pratik benimsenme oranını %85+ seviyesine çıkardı.

Bu yedi hatanın çözümü artık standart sürecimizin parçasıdır; yeni projelerde başlangıçtan uygulanır. Ekipten bir mühendis, projenin son haftasında "ne yanlış gitmiş olabilir" check-listini bu yedi başlık üzerinden tarar — proje teslimattan önce son bir savunma katmanı olarak çalışır.

Karar matrisi: kuruma uygun mu, ne zaman uygun değil

Data fusion her kurum için doğru çözüm değildir. Üç soru cevaplayarak hızlı bir değerlendirme yapabilirsiniz:

Üç+ "Evet" çıkıyorsa data fusion mantıklıdır. İki ve altı için, önce daha basit data warehouse / BI çözümlerini değerlendirin; ölçek büyüdükçe fusion'a geçilebilir.

Bizim açık kaynak istihbarat hizmetimiz ile data fusion mimari hizmetimiz iki ayrı paket olarak da, birlikte de alınabilir. Tipik kurumsal müşterilerimiz ikisini birden tercih ediyor — çünkü OSINT'in değeri kurumsal veriyle birleştirildiğinde katlanarak artar.

Pilot proje yaklaşımımız

Yeni başlayan bir kurum için önerimiz: 3-haftalık pilot ile başlayın. Pilot kapsamı şudur:

• Tek bir karar senaryosu seçilir (örn: "Yeni müşteri adayının risk değerlendirmesi 1 saatten 5 dakikaya inmeli").
• 2 OSINT kaynağı + 2 iç sistem entegre edilir.
• Mini bir graf (5-10 entity tipi) + 1 analist arayüzü teslim edilir.
• Üç hafta sonunda demo + ROI değerlendirmesi yapılır.

Pilot sonunda iki yol vardır: ya genişletilir (ek kaynaklar, ek senaryolar, kurumsal ölçek), ya da daha basit bir BI çözümüne yönelinir. Her iki yön de veriye dayalı kararla seçilir; bizim danışmanlık sürecimiz bu kararı sizin yerinize değil sizinle birlikte verir.

Kendi kurumunuzun OSINT + data fusion ihtiyacını değerlendirmek istiyorsanız, iletişim sayfamız üzerinden bir ön görüşme talep edebilirsiniz. Ücretsiz 60 dakikalık görüşmede yedi maddenin sizin senaryonuza göre nasıl uygulandığını birlikte inceleriz; pilot için kapsam önerisi sunarız.

Bu yazıyı sektörlerinde benzer bir yapı kurmayı düşünen meslektaşlarınızla paylaşmaktan çekinmeyin; kurumsal istihbarat alanında Türkçe somut pratik içerik hâlâ az ve değerli. Ekibimiz, bu konuda yeni yazılar yayınladıkça blog sayfamızda duyuracağız — sıradaki yazılar arasında "permissioned blockchain ile entity resolution" ve "AIGENCY V4 ile çoklu-ajan analist iş akışları" konuları planlandı. Bu konular sizin için de önemliyse, görüşme talebinizde belirtmeniz halinde ilgili teknik dokümanları görüşme öncesinde paylaşabiliriz.