IBM 2025 Cost of a Data Breach raporuna göre olgun bir veri yönetişimi (data governance) programı işleten kurumlarda ihlal başına ortalama maliyet 2,1 milyon USD daha düşük; Gartner 2025 verilerine göre KVKK ve GDPR cezalarının %78’i basit bir veri kataloğu (data catalog) ve lineage eksikliğinden kaynaklanıyor. 2026’da düzenleyiciler artık “biz veriyi koruyoruz” beyanını değil, kanıtlanabilir kontrolleri istiyor: kim, ne zaman, hangi gerekçeyle hangi alana eriştiğini saniyeler içinde gösterebilen bir kontrol katmanı. Türkiye’de KVKK Kurulu tarafından kesilen idari para cezaları 2024’te 1,85 milyar TL’yi geçti; AB tarafında ise EDPB 2025 raporu GDPR cezalarının kümülatif olarak 5,4 milyar Euro’ya ulaştığını gösteriyor. Avrupa Birliği AI Act’in Şubat 2025’te yürürlüğe giren ilk fıkraları, yüksek riskli AI sistemleri için “veri yönetişimi belgesi” zorunluluğunu getirerek bu alanı sadece compliance giderinden iş riskinin omurgasına dönüştürdü.
Bu rehberde 2026 standartlarıyla veri yönetişimi çerçevelerini (DAMA-DMBOK, COBIT, DCAM), KVKK-GDPR-AI Act kesişimini, modern veri kataloğu ve data lineage araçlarını, sınıflandırma ve maskeleme stratejilerini, RBAC tabanlı erişim mimarisini ve 18-24 aylık uygulama yol haritasını birlikte inceliyoruz. Hedef: panik halinde compliance görevlisinin Excel’e baktığı bir yapı değil, sürekli izlenen, ölçülen ve kanıtlanabilen bir kontrol katmanı kurmak.
Veri Yönetişimi Nedir, Veri Yönetiminden Farkı Ne?
Veri yönetişimi (data governance), bir kurumun veri varlıklarını stratejik bir varlık olarak yönetebilmesi için kurduğu insan + süreç + teknoloji çerçevesidir. DAMA International tarafından yayımlanan DMBOK 2 standardı, yönetişimi 11 bilgi alanı etrafında tanımlar: veri mimarisi, veri modellemesi, veri kalitesi, veri güvenliği, metadata yönetimi, master data, depolama ve operasyon, entegrasyon ve birlikte çalışabilirlik, doküman ve içerik yönetimi, veri ambarı ve BI, son olarak etik ve yönetişim. Bu 11 alan iç içe geçer ve hiçbiri tek başına yönetişim sayılmaz.
En sık karıştırılan iki kavram veri yönetimi (data management) ile veri yönetişimidir. Veri yönetimi günlük operasyondur: ETL çalıştırma, yedekleme, tablo yaratma, sorgu optimizasyonu. Veri yönetişimi ise bu operasyonun üstüne politika, sorumluluk ve denetlenebilirlik katmanı ekler; “bu veri ne anlama gelir, kim sahibidir, kime açılabilir, ne kadar saklanır, kalitesi nasıl ölçülür” sorularını yanıtlar. Yönetişim olmadan yönetim körlemesine işler; yönetim olmadan yönetişim ise kağıt üstünde kalır.
- Politika katmanı: Veri sınıflandırma seviyeleri, saklama süreleri, paylaşım kuralları, anonimleştirme prosedürleri.
- Sahiplik katmanı: Her veri domaini için “data owner” (iş tarafı) ve “data steward” (teknik taraf) atanması.
- Katalog katmanı: Hangi sistemde hangi veri bulunduğu, anlamı, owner’ı, kalite skoru ve son güncellenme bilgisinin tek noktada toplanması.
- Lineage katmanı: Verinin kaynak sistemden başlayıp dönüşümlerden geçerek son rapora ulaşan yolculuğunun otomatik takip edilmesi.
- Kalite katmanı: Doğruluk, eksiksizlik, tutarlılık, güncellik ve benzersizlik metriklerinin sürekli izlenmesi. Veri kalitesi yönetimi pratiği için Great Expectations ve Soda ile kurulan kontrol mimarisini ayrı bir rehberde ele aldık.
Veri Yönetişimi Çerçeveleri: DAMA-DMBOK, COBIT 2019 ve DCAM Karşılaştırması
2026’da Türkiye ve global piyasada en sık başvurulan üç çerçeve DAMA-DMBOK 2, ISACA’nın COBIT 2019’u ve EDM Council’in DCAM (Data Capability Assessment Model) çerçevesidir. Forrester 2025 Data Governance Wave raporuna göre Fortune 500 kurumlarının %67’si DAMA-DMBOK’u temel referans olarak kullanırken, finansal hizmetler sektörünün %54’ü düzenleyici yakınsama nedeniyle DCAM’i tercih ediyor.
| Çerçeve | Yayıncı | Odak | Yapı | En Uygun Sektör | Sertifikasyon |
|---|---|---|---|---|---|
| DAMA-DMBOK 2 | DAMA International | 11 bilgi alanı, jenerik | Bilgi alanı bazlı | Genel / her sektör | CDMP |
| COBIT 2019 | ISACA | IT yönetişimi + APO14 | 40 yönetişim hedefi | Kurumsal IT, denetim | COBIT Foundation |
| DCAM 2.2 | EDM Council | Veri yetenek değerlendirmesi | 8 bileşen, olgunluk modeli | Finansal hizmetler | CDMC, DCAM |
| ISO/IEC 38505 | ISO | Veri yönetişim prensipleri | Üst düzey ilkeler | Halka açık + regülasyonlu | ISO 27001 ile entegre |
| BCBS 239 | Basel Committee | Risk veri toplama | 14 prensip | Sistemik öneme sahip banka | Düzenleyici denetim |
Türkiye’deki orta ölçek kurumlar için pratik öneri: DAMA-DMBOK’u temel iskelet olarak alıp, kontrol noktalarında COBIT’in APO14 (Managed Data) hedeflerinden faydalanmak, finansal kurum ise bu ikilinin üstüne DCAM olgunluk modelini yerleştirmek. Üç çerçeve birbirinin alternatifi değil, tamamlayıcısıdır.
KVKK ve GDPR: Ortak Noktalar, Farklar ve 2026 Yakınsaması
Her iki regülasyon da kişisel veri koruma amacı taşır ve büyük ölçüde örtüşür; ancak hukuki dayanaklar ve yaptırım eşikleri farklıdır. 6698 sayılı KVKK metni KVKK Kurumu sitesinde resmi versiyonuyla yayımlıdır; GDPR’ın resmi portalı ise EU GDPR.eu üzerinden takip edilebilir. 2024 yılında 7499 sayılı Kanun ile KVKK’da yapılan değişiklikler, özellikle yurt dışı veri aktarımı kurallarını büyük ölçüde GDPR’a yakınsattı; “açık rıza dışı” aktarım için artık taahhütname yerine standart sözleşme veya bağlayıcı kurumsal kurallar kullanılabiliyor.
| Kriter | GDPR (AB) | KVKK (Türkiye) | Pratik Sonuç | Yaptırım Aralığı |
|---|---|---|---|---|
| Maksimum ceza | 20M EUR veya yıllık cironun %4’ü | İdari para cezası + cezai yaptırım, 2024’te 5,4M TL’ye dek | Risk modellemesi ve sigortacılık şart | Çok yüksek |
| Açık rıza | Granular, ayrıştırılabilir, geri çekilebilir | Belirli konuya ilişkin, bilgilendirmeye dayalı, özgür irade | Tek tıkla “kabul ediyorum” geçersiz | İhlal başına ceza |
| Veri ihlali bildirimi | 72 saat (denetim makamı + ilgili kişi) | En kısa sürede (72 saat KVKK referansı) | IR ekibi 7/24 nöbet rotasyonu zorunlu | Gecikme ek ceza |
| DPO zorunluluğu | Belirli kriterlerde zorunlu | VERBİS kaydı zorunlu, DPO atanması güçlü öneri | Veri Sorumlusu temsilcisi atama gerekli | İdari para cezası |
| Yurt dışı aktarım | SCC, adequacy decision, BCR | Yeterlilik kararı, standart sözleşme, taahhütname | Hukuki çerçeve sözleşmeye işlenmeli | Yüksek |
| İlgili kişi hakları | 8 hak (silme, taşınabilirlik, itiraz dahil) | 11 hak (madde 11) | Hak talepleri 30 gün içinde yanıtlanmalı | İdari ceza + tazminat |
AI Act’in Şubat 2025’te yürürlüğe giren genel prensipler bölümü, yüksek riskli AI sistemleri için “veri yönetişim ve veri yönetim uygulamaları” zorunluluğu (madde 10) getiriyor: eğitim, doğrulama ve test veri setlerinin önyargı, bütünlük ve temsiliyet açısından kanıtlanabilir biçimde yönetilmesi gerekiyor. Bu durum, GDPR/KVKK çerçevesinin üstüne AI sistemleri için ek bir kontrol katmanı ekliyor.
Veri Kataloğu (Data Catalog) Araçları: Collibra, Atlan, Alation, DataHub, OpenMetadata
2026’da veri kataloğu pazarı net biçimde üç katmana ayrıldı: kurumsal lider çözümler (Collibra, Alation, Informatica CDQ), modern bulut-yerel SaaS oyuncular (Atlan, Castor by CoalesceIO, Secoda) ve açık kaynak alternatifler (LinkedIn DataHub, OpenMetadata, Apache Atlas). IDC 2025 Marketscape raporuna göre küresel veri kataloğu pazarı 2,4 milyar USD’ye ulaştı ve yıllık %28 büyüyor; en hızlı büyüme açık kaynak ve modern SaaS segmentinde.
| Araç | Tip | Güçlü Yön | Lineage | Yıllık Maliyet | Uygun Kurum |
|---|---|---|---|---|---|
| Collibra | Kurumsal SaaS | Olgun workflow, governance modülü | Görsel + impact | $120K-$400K | Büyük kurumsal, regülasyonlu |
| Alation | Kurumsal SaaS | Behavioral metadata, popularity | SQL parse | $100K-$350K | BI-yoğun, analytics |
| Atlan | Modern SaaS | Active metadata, hızlı kurulum | dbt + Airflow native | $60K-$180K | Modern data stack, scale-up |
| LinkedIn DataHub | Açık kaynak | Olay tabanlı, geniş ingest | OpenLineage | Hosting + ekip | Tech-savvy, orta-büyük |
| OpenMetadata | Açık kaynak | Tüm one stack, kolay deploy | Otomatik tarama | Hosting + ekip | Orta ölçek, hızlı POC |
| Apache Atlas | Açık kaynak | Hadoop ekosistemi yerleşik | Sınırlı modern | Hosting | Legacy Hadoop / on-prem |
Karar matrisinde dikkat edilmesi gereken kriterler: kullanıcı arayüzünün benimsenebilirliği (data steward dışı kullanıcıların günlük kullanım oranı), connector kapsamı (kullanılan tüm veri kaynaklarını native destekliyor mu), lineage derinliği (sütun seviyesinde mi tablo seviyesinde mi), maliyet öngörülebilirliği (kullanıcı bazlı mı, varlık bazlı mı). Atlan’ın active metadata platform yaklaşımını detaylı anlatan blog dizisi ve Collibra blog’undaki kurumsal vaka çalışmaları karar sürecinde değerlendirme için iyi başlangıç noktalarıdır. Açık kaynak tarafında OpenMetadata resmi dokümantasyonu ve DataHub Project ana sayfası üzerinden community sürümleri incelenmelidir.
Data Lineage: Otomatik İzleme ve Etki Analizi
Data lineage, verinin kaynaktan tüketim noktasına yolculuğunu detayıyla görselleştirir. 2026’da modern stack’lerde lineage manuel diyagram olarak değil, çalışan kod ve metadata’dan otomatik üretilir. dbt manifest.json çıktısının analytics engineering rolündeki kritik yerini ayrı bir yazıda inceledik; bu manifest, lineage’in temel girdisidir.
| Lineage Aracı | Mimari | Granularite | Native Ingest | Etki Analizi | Lisans |
|---|---|---|---|---|---|
| OpenLineage | Olay tabanlı standart | Tablo + sütun | Airflow, Spark, dbt, Flink | Marquez UI | Apache 2.0 |
| Marquez | OpenLineage backend | Tablo + sütun | OpenLineage entegre | Native | Apache 2.0 |
| Apache Atlas | Hook tabanlı | Tablo | Hive, Kafka, HBase | Sınırlı | Apache 2.0 |
| Manta (IBM) | Parse + scan | Sütun | 500+ tech | Detaylı diff | Ticari |
| SQLLineage | SQL parser kütüphanesi | Sütun | SQL dialects | CLI / kod | MIT |
Etki analizinin (impact analysis) iş değeri: bir kaynak tablo şemasını değiştirirken hangi raporun, hangi ML modelinin, hangi API’nin etkileneceğini saniyeler içinde görmek. Manuel ortamda bu analiz haftalar alır ve genelde eksik kalır; otomatik lineage ile birkaç saniyede yapılır ve değişiklik onay sürecine entegre edilir.
Veri Sınıflandırma, Maskeleme ve Tokenization
Veri sınıflandırma, yönetişimin “neyi koruyacağız” sorusunu yanıtlar. 2026 kurumsal pratikte yaygın olarak dört seviye kullanılıyor: public, internal, confidential, restricted. PII, PHI, ödeme kartı verisi (PCI), ticari sır gibi alt kategoriler bu seviyelerin üstüne etiketlenir. Sınıflandırma sonrası uygun koruma kontrolleri (şifreleme, maskeleme, tokenization) seçilir.
| Sınıf | Tanım | Örnek | Erişim | Koruma | Saklama |
|---|---|---|---|---|---|
| Public | Herkese açık | Pazarlama materyali, fiyat listesi | Anonim | Bütünlük kontrolü | Süresiz |
| Internal | Kurum içi | Organizasyon şeması, iç prosedürler | Tüm çalışanlar | SSO + TLS | 5 yıl tipik |
| Confidential | Sınırlı kurum içi | Müşteri PII, finansal raporlar | RBAC + onay | Şifreleme + maskeleme | Yasal süre |
| Restricted | Kritik | Sağlık verisi, kredi kartı, secret | Need-to-know + MFA | Tokenization + HSM | Minimum, audit |
Maskeleme (masking) ve tokenization farkı kritik bir tercihtir: maskeleme görüntü katmanında verinin sadece bir bölümünü gizler (örn. kredi kartı son 4 hanesi görünür), tokenization ise gerçek değeri tamamen anlamsız bir token ile değiştirir ve orijinal değeri ayrı bir vault’ta tutar. PCI-DSS uyumlu sistemlerde tokenization, format-preserving encryption (FPE) ve dinamik maskeleme yaygın kombinasyonlardır.
- Static masking: Test/geliştirme ortamına veri kopyalanırken üretim verisi anonimleştirilir; production veri test ortamına asla gitmez.
- Dynamic masking: Sorgu anında kullanıcı yetkisine göre veri kısmen veya tamamen maskelenir; veritabanı seviyesi (SQL Server, Snowflake row access policy) veya proxy katmanı.
- Tokenization: Hassas alan token ile değiştirilir, gerçek değer ayrı PCI vault’ta tutulur; deterministic veya random token seçimi audit ihtiyacına göre yapılır.
- Format-preserving encryption (FPE): Şifreli değer orijinal formatta kalır (16 haneli kart numarası → 16 haneli ciphertext), legacy sistemlerle uyum için kritik.
- Differential privacy: Toplu analitik sonuçlara kontrollü gürültü eklenerek bireysel kayıtların re-identification’ı engellenir; AI eğitim veri setleri için yükselen pratik.
Veri Erişim Kontrolü: RBAC, ABAC ve Attribute-Based Policy
Veri yönetişiminin kalbi erişim kontrolüdür. RBAC (Role-Based Access Control) hala en yaygın model olsa da, modern veri lake/warehouse mimarileri ABAC (Attribute-Based Access Control) ve policy-as-code yaklaşımlarına kayıyor. RBAC, ABAC ve ReBAC yetkilendirme modellerini karşılaştıran detaylı yazımız seçim kararı için referans alınabilir.
| Model | Kontrol Birimi | Veri Lakeye Uygulama | Esneklik | Yönetim Maliyeti | Audit |
|---|---|---|---|---|---|
| RBAC | Rol | Schema/tablo bazında grant | Düşük-orta | Orta | Kolay |
| ABAC | Kullanıcı + veri özniteliği | Row/column policy (Snowflake, Databricks) | Yüksek | Yüksek | Politika versiyonu gerekli |
| PBAC (Policy) | Politika kuralı | OPA, Apache Ranger | Çok yüksek | Çok yüksek | Policy-as-code Git |
| Tag-based | Veri etiketi | Unity Catalog tag, Lake Formation tag | Yüksek | Orta | Catalog ile entegre |
| Purpose-based | Kullanım amacı | GDPR purpose limitation | Compliance odaklı | Yüksek | Audit trail zorunlu |
2026 pratiğinde önerilen yaklaşım, RBAC’yi taban olarak almak; PII ve confidential üzeri verilerde tag-based veya ABAC ile dinamik filtreleme uygulamak; tüm politikaları Git’te policy-as-code olarak tutmak ve CI/CD ile dağıtmak. Bu sayede “kim hangi politikayı, ne zaman, neden değiştirdi” sorusu denetimde anında yanıtlanır.
Veri Yönetişimi Uygulama Yol Haritası: 18-24 Aylık Program
Veri yönetişimi bir yazılım kurulum projesi değil, kültür ve operasyon değişimidir. Gartner 2025 raporuna göre başarılı yönetişim programları ortalama 18-24 ayda olgunluk seviyesi 3’e (DCAM Defined seviyesi) ulaşıyor; üst yönetim sponsorluğu olmayan programların %72’si iki yıl içinde rafa kalkıyor.
- Mevcut durum ve envanter (1-2. ay): Tüm veri kaynaklarını (DB, S3, SaaS, Excel’ler dahil) listele; hangi tablo, hangi sütun, hangi PII alanı içeriyor envanterini çıkar. Otomatik tarama için OpenMetadata veya DataHub crawler kullan.
- Sınıflandırma politikası (2-3. ay): Public/internal/confidential/restricted seviyelerini ve PII/PHI/PCI alt kategorilerini kurum bağlamına göre tanımla, hukuk ile mutabakata var.
- Sahiplik atama (3-5. ay): Her domain için data owner (iş tarafı yöneticisi) ve data steward (teknik operatör) belirle, RACI matrisini yayımla.
- Politika dokümantasyonu (4-6. ay): Saklama süresi, anonimleştirme, paylaşım, silme prosedürlerini yaz; KVKK VERBİS kaydını güncelle.
- Katalog kurulumu (5-9. ay): DataHub/OpenMetadata pilot ile 1-2 domain’i kataloğa al; tablolara iş tanımı, owner, kalite skoru ekle.
- Lineage entegrasyonu (8-12. ay): Airflow + dbt + Spark işlerini OpenLineage ile besle; etki analizi UI’sini stakeholder’lara aç.
- Kalite izleme (10-14. ay): Great Expectations veya Soda ile günlük data quality test çalıştır; başarısız test’i Slack/ticket’a yönlendir.
- Erişim kontrolü modernizasyonu (12-18. ay): RBAC tabanını ABAC/tag-based politika ile zenginleştir; PII kolonlarda dinamik maskeleme veya tokenization devreye al.
- Yönetişim komitesi (sürekli): Aylık toplanan cross-functional kurul (iş + IT + hukuk + güvenlik) eskalasyon mercii olarak çalışır; KPI dashboard’u sponsor üst yönetime gider.
Bu programı destekleyen organizasyonel yapı tarafında, Data Mesh mimarisi ile domain odaklı veri ürünleri yaklaşımını ve Data Lakehouse mimarisinin Databricks ve Snowflake bağlamında değerlendirilmesini referans olarak öneriyoruz; modern altyapı yönetişimin operasyonel yükünü ciddi ölçüde azaltır. Veri ambarı tarafında BigQuery ve Snowflake’in 2026 maliyet karşılaştırmasını da incelemek faydalıdır. Yönetişimin risk yönetimi tarafında kurumsal çerçeve için teknoloji risk yönetimi KPI çerçevemiz ve kamu sektörü perspektifinde GovTech dijital dönüşüm çözümleri yazımız tamamlayıcı kaynaklardır.
Maliyet, ROI ve Sınırlamalar
Gartner 2025 Data Governance Magic Quadrant’a göre kurumsal veri kataloğu lisans maliyeti yıllık 80.000-350.000 USD bandında; orta ölçek kurumlar için DataHub veya OpenMetadata bazlı açık kaynak stack 40.000-80.000 USD yıllık operasyon maliyetiyle (kurulum + 1-2 FTE) eş değer işlevi sağlıyor. McKinsey 2025 “Data Maturity Benchmark” çalışmasında olgun veri yönetişimi olan kurumlar analitik proje teslim süresini %38 kısaltıyor, veri kaynaklı yanlış karar maliyetini %47 düşürüyor ve regülatör cezalarını %62 oranında azaltıyor.
Sınırlamalar net biçimde söylenmeli: veri yönetişimi bir yazılım kurma projesi değil, kültür ve sahiplik değişimidir; benimsenmesi 18-24 ay sürer ve üst yönetim sponsorluğu olmadan sürdürülemez. Pilot domain seçimi yanlış yapılırsa (örneğin kullanıcısı az, etki düşük bir domain) program ivmesini kaybeder ve “Excel yönetişimi” alışkanlığı geri döner. Bir diğer risk: katalog kurup içine veri pompalamak ama “neden var” hikayesini iş kullanıcısına anlatamamak; bu durumda katalog 6 ay içinde unutulur ve metadata çürür.
Sık Sorulan Sorular
Küçük şirket için veri yönetişimi gerekli mi?
Veri işleme hacmi düşük olsa bile kişisel veri işleyen her şirket KVKK kapsamındadır ve minimum düzeyde envanter, açık rıza yönetimi ve ihlal bildirim süreci kurmak zorundadır. 50 kişi altı şirketler için hukuk danışmanı eşliğinde 4-6 sayfalık kişisel veri politikası + Excel/Notion bazlı envanter + aydınlatma metni şablonu yeterlidir. Çalışan sayısı 100’ü, müşteri verisi 100.000 kaydı geçtiğinde DataHub veya OpenMetadata gibi açık kaynak araçlar devreye alınmalı, en az bir part-time data steward atanmalıdır.
Data owner ile data steward farkı nedir?
Data owner iş tarafından gelen, ilgili veri alanının iş anlamından ve kullanım kararlarından sorumlu kişidir (örnek: müşteri verisi için CMO veya Müşteri Deneyimi Direktörü). Data steward ise teknik tarafta verinin kalitesini, yapısını, katalog kayıtlarını ve günlük operasyonunu sürdüren operatör rolüdür (genellikle data engineer veya analytics engineer rolünden gelir). Owner “ne ve neden” (bu veri ne anlama gelir, kime açılabilir, nasıl kullanılabilir), steward “nasıl ve hangi kalitede” (şema doğru mu, kalite testleri geçiyor mu, lineage doğru besleniyor mu) sorumluluğunu taşır. İkisi birlikte olmazsa yönetişim aksar: sadece owner varsa teknik kontroller eksik kalır, sadece steward varsa iş kararları sahipsiz kalır.
Veri lineage’i otomatik mi manuel mi izlenmeli?
Modern stack’lerde tamamen otomatik olmalıdır. dbt projeleri manifest.json üretir, Airflow DAG’leri OpenLineage event’leri yayar, Spark işleri Spline veya OpenLineage Spark listener ile event üretir; DataHub veya Marquez bunları otomatik ingest eder. Manuel lineage diyagramı 2026’da sürdürülebilir değildir: veri yapısı haftalık değişirken manuel diyagram bir hafta sonra eskimiş olur ve güveni öldürür. Otomatik lineage aynı zamanda etki analizi (hangi rapor, hangi ML modeli etkilenir?) ve root cause analizi (hangi kaynak değiştiği için bu metrik bozuldu?) için kritiktir. İstisna: tamamen legacy mainframe veya ETL aracı kullanılan ortamlarda hibrit yaklaşım gerekir; ana hatlar manuel, alt akış otomatik beslenir.
KVKK denetiminde hangi belgeler istenir?
VERBİS kaydı, kişisel veri envanteri (sicil), saklama ve imha politikası, açık rıza kayıtları, aydınlatma metinleri, veri işleyen sözleşmeleri, ihlal müdahale prosedürü, yurt dışı aktarım belgeleri (taahhütname veya standart sözleşme) standart talep edilen evraklar arasındadır. Denetimde “uygulanıyor mu” sorusu için kanıt (log kayıtları, erişim audit trail, eğitim kayıtları, ihlal tatbikat raporları) hazır olmalıdır; sadece doküman varlığı yetmez, işlerlik kanıtı aranır. Pratik tavsiye: her belgenin yanına son güncellenme tarihi, sorumlu kişi, ve son denetim/test tarihi metadata olarak işlenmeli; KVKK Kurulu denetiminde “bu prosedür 14 ay önce yazılmış, hiç güncellenmemiş” tespiti ek ceza gerekçesi olabilir.
Açık kaynak DataHub mı, kurumsal Collibra mı seçmeliyim?
Seçim üç değişkene bağlıdır: kurum büyüklüğü, regülasyon yoğunluğu, iç teknik kapasite. Bankacılık, sigortacılık, sağlık gibi regülasyon yoğun sektörlerde, 5000+ çalışan üzerinde Collibra veya Alation gibi kurumsal SaaS mantıklıdır; workflow ve denetim modülleri kurumsal süreçle uyumludur. Tech-savvy orta-büyük şirketler (1000-5000 çalışan) modern data stack kullanıyor ve 2-3 FTE data platform mühendisi ayırabiliyorsa DataHub veya OpenMetadata daha hızlı ve esnektir. Atlan ise bu iki kutbun ortasında scale-up şirketler için uygun denge noktasıdır.
Sonuç: Çerçeve Adopsiyonu Verdikti
Veri yönetişimi 2026’da artık IT’nin değil, üst yönetimin gündemindedir. KVKK ve GDPR cezalarının kümülatif yükü, AI Act ile gelen veri kaynak şeffaflığı zorunluluğu ve veri ürünleri (data products) yaklaşımının yaygınlaşması, yönetişimin operasyonel iş omurgasına dönüştüğünü gösteriyor. Çerçeve adopsiyonu için net tavsiyemiz: DAMA-DMBOK 2’yi temel iskelet olarak benimseyin, kontrol noktalarında COBIT 2019 APO14 ile zenginleştirin, finansal hizmetlerde DCAM olgunluk modeline geçin. Araç tarafında orta ölçek için DataHub veya OpenMetadata + OpenLineage + Great Expectations stack’i optimal denge sunar; kurumsal regülasyonlu yapılarda Collibra veya Alation’ın workflow modülleri zaman kazandırır.
Anahtar üç prensip: sahiplik atanmadan veri yönetilmez, lineage otomatik olmadan sürdürülemez, kültür değişimi olmadan teknoloji tek başına yetersizdir. Doğru kurulan bir yönetişim çerçevesi hem regülasyon riskini hem analitik çevrim süresini düşürür; yanlış kurulan bir program ise sadece bir Excel dosyası kalabalıklığı yaratır. 2026’da kazanan kurumlar, yönetişimi compliance dosyası olarak değil sürekli ölçülen, kanıtlanan ve iş kararlarına bağlanan bir kontrol katmanı olarak konumlandıranlar olacak.
Ömer ÖNAL
Mayıs 16, 2026Yazılım danışmanlığı projelerinde sıkça karşılaştığım bir soru: “Hangi mimari hangi senaryoda öncelikli olmalı?” Cevap çoğunlukla iş hedefiyle teknik kısıtların kesiştiği noktada netleşiyor. Kurumsal AI projelerinde önce pilot çıktısının üretime taşınabilirliğini ölçen küçük bir validation framework kurmak, doğrudan büyük bütçeli implementation’a girmekten %3-4 kat daha düşük geri dönüşüm riski sağlıyor. Yorumlarınıza açığım.