Saha Notu: Veri Yönetişimi Olmadan Başlayan Projelerin Sonu

Veri yönetişimi eksikliği, kurumsal yapay zekada en sık gördüğüm ama en geç teşhis edilen sorundur. Bu bir saha notudur: onlarca kurumsal AI girişimini yakından izlemiş bir danışman olarak, veri yönetişimi olmadan başlayan projelerin neredeyse her seferinde aynı yerde, aynı biçimde çıkmaza girdiğini anlatmak istiyorum. İlginç olan şu: bu projeler kötü model seçtiği için değil, veriyi hiç yönetmediği için başarısız olur. Ve daha da ilginci, çöküş asla başta değil, tam üretime geçileceği anda gelir. Bu gecikmeli çöküş, veri yönetişimi eksikliğinin en yanıltıcı ve en pahalı özelliğidir.

Bu saha gözleminin özü tek bir cümlede toplanır: veri yönetişimi eksikliği projeyi hemen öldürmez, sessizce biriktirir. İlk haftalarda her şey hızlı ilerliyormuş gibi görünür, çünkü kimse durup "bu veri kimin, doğru mu, kim erişebilir, nereden geldi" diye sormaz. Bu sorular sorulmadıkça proje hafif ve hızlı hisseder; ta ki sorulmadıkları için biriken risk bir anda faturaya dönüşene kadar. Bu yazıda o faturanın nasıl biriktiğini — sahiplik boşluğu, veri kalitesi sorunu, erişim karmaşası, gizlilik duvarı ve kaynak belirsizliği — bir belirti × kök neden × önlem çerçevesiyle ele alacağım. Konunun kavramsal ve uçtan uca işlendiği kapsamlı veri yönetişimi rehberi tüm bileşenleri tanımlar; bu yazı ise sahada o eksikliğin neye benzediğine, hangi duvara çarptığına odaklanır.

Tanım

Veri yönetişimi eksikliği

Bir yapay zeka projesinde verinin sahipliği, kalitesi, erişimi, gizliliği ve kaynağı konusunda kural, sorumluluk ve karar mekanizmasının baştan tanımlanmamış olması. Saha gözlemi bu eksikliğin projeyi hemen çökertmediğini; sessizce risk biriktirdiğini ve üretime geçiş anında bir proje çıkmazına dönüştüğünü gösterir. En sık belirtileri sahiplik boşluğu, geç fark edilen veri kalitesi sorunu ve kaynak belirsizliğidir. Projeyle birlikte kurulan bir minimum yönetişim setiyle erkenden önlenebilir.

Ayrıca: sahiplik boşluğu, veri kalitesi sorunu, kaynak belirsizliği, yönetişimsiz veri, sonradan yönetişim

Her yönetişimsiz projenin başında aynı cümle söylenir: "Yönetişimi sonra hallederiz, önce çalışan bir şey görelim." Bu cümle masumca, hatta akıllıca duyulur — hız önemlidir, mükemmeliyetçilik zararlıdır. Ama saha gözleminde bu cümlenin, veri yönetişimi eksikliğinin resmi başlangıç işareti olduğunu öğrendim. Çünkü "sonra" hiçbir zaman gelmez; "sonra" tam olarak, düzeltmenin en pahalı olduğu andır.

Bu erteleme neden bu kadar cazip? Çünkü yönetişim çalışması görünmezdir ve ödülü gecikmelidir. Bir veri sahibi atamak, kalite eşiği yazmak, erişim kurallarını tanımlamak — bunların hiçbiri demoda parlamaz. Buna karşılık model çalıştırmak anında tatmin eder: ekran görüntüsü alınır, yöneticiye gösterilir, herkes heyecanlanır. İnsan doğası görünür ve anlık olanı, görünmez ve gecikmeli olana tercih eder. Bu yüzden veri yönetişimi eksikliği bir ihmal değil, çoğu zaman bilinçli bir öncelik sırasıdır — ve yanlış bir sıradır.

İkinci bir cazibe, yönetişimin "ağır" bir şey gibi algılanmasıdır. Ekip, "yönetişim" kelimesini duyunca komiteler, politika dokümanları, aylar süren süreçler hayal eder ve haklı olarak "bizim küçük projemiz için abartı" der. Oysa bu yanlış bir ikilemdir. Gerçek seçenek, "ağır yönetişim programı" ile "hiç yönetişim" arasında değildir; ikisinin arasında, projeyle birlikte kurulan hafif bir minimum yönetişim seti vardır. Bu seti göz ardı etmek, bebeği banyo suyuyla atmaktır.

Somut olarak "sonra hallederiz" şu kararları erteler: verinin kimin sahipliğinde olduğu, hangi kalite eşiğini geçmesi gerektiği, kimin erişebileceği, nereden geldiği ve hangi sürümün doğru olduğu. Bu kararların her biri projenin ilk gününde birer cümlelik cevaplarla verilebilir; ertelendiğinde ise her biri haftalarca süren, geriye dönük, pahalı bir yeniden tasarıma dönüşür. Ertelemenin maliyeti sabit değildir; zamanla üstel olarak büyür. İşte bu yüzden veri yönetişimi eksikliği, ertelendikçe ucuzlamaz, pahalılaşır.

Bir saha notunun değeri, dayandığı gözlemin niteliğinden gelir; bu yüzden neye dayanarak yazdığımı baştan açık etmek isterim. Bu notlar tek bir projeden değil, farklı sektörlerden, farklı ölçeklerden çok sayıda kurumsal yapay zeka girişimini yakından izleme deneyiminden damıtıldı. Ortak paydaları şuydu: hepsi veriyle çalışıyordu ve hepsinde, bir noktada, verinin nasıl yönetildiği sorusu belirleyici oldu. Bir örüntüyü saha gözlemi olarak adlandırabilmek için onu yeterince kez, yeterince farklı bağlamda görmek gerekir; veri yönetişimi eksikliğini bu eşiği çoktan aşmış bir örüntü olarak gördüm.

Bu gözlemin yöntemi anekdot toplamak değil, tekrarı fark etmektir. Tek bir projenin çıkmaza girmesi tesadüf olabilir; ama aynı belirtinin — "bu hatayı kim düzeltecek" sorusunun cevapsız kalmasının — onlarca projede aynı biçimde tekrar etmesi, artık tesadüf değil, yapısal bir örüntüdür. Bu yazıda anlattığım her belirti, tek bir vakadan değil, tekrar eden bir desenden geliyor. Bu yüzden uydurma vaka veya sayı kullanmıyorum; anlattığım şey, belirli bir şirketin hikâyesi değil, birçok şirkette aynılaşan bir örüntünün tarifidir.

Bir uyarı da burada yerinde olur: saha gözlemi güçlü bir rehberdir ama bir kanıt değildir. Her kurumun verisi, kültürü ve kısıtları farklıdır; burada anlattığım örüntü şaşırtıcı biçimde tutarlı olsa da, sizin kurumunuzda farklı önceliklerle karşılaşabilirsiniz. Bu notu bir reçete değil, bir teşhis merceği olarak kullanmanızı öneririm: kendi projenize bakarken "bu belirtilerden hangisi bende var" diye sorun. Kavramsal çerçevenin tam halini veri yönetişimi nedir yazısında, verinin ölçek boyutunu büyük veri nedir yazısında bulabilirsiniz.

Son olarak, bu notların neden "damıtılmış" olduğunu vurgulamak isterim. Bir saha deneyimi ham haliyle sadece bir yığın hikâyedir; değerli olan, o hikâyelerden tekrar eden dersi süzmektir. Veri yönetişimi eksikliği hakkında süzdüğüm ders, bu yazının belkemiğini oluşturuyor: eksiklik hemen görünmez, sessizce biriktirir ve en pahalı anda patlar. Şimdi bu örüntünün ilk ve en teşhis edici belirtisine, sahiplik boşluğuna dönelim.

Saha gözleminde veri yönetişimi eksikliğinin en erken ve en teşhis edici belirtisi sahiplik boşluğudur. Sahiplik boşluğu, bir veri kümesi hakkında karar verecek, kalitesinden sorumlu olacak ve sorulara cevap verecek tek bir ismin bulunmamasıdır. Belirtisi basittir: bir veri hatası ortaya çıktığında "bu kimin sorumluluğunda" sorusu havada kalır. Herkes bir başkasını işaret eder; iş biriminin, IT'nin, veri ekibinin arasında bir sıcak patates gibi dolaşır ve kimse tutmaz.

Sahiplik boşluğunun sinsi tarafı, projenin başında hiç sorun gibi görünmemesidir. Başta veri hazırdır, temizdir (ya da öyle sanılır), herkes iyimserdir; sahiplik sorusu hiç gündeme gelmez. Sorun ilk veri anomalisiyle patlar: bir tarih alanı yanlış formattadır, bir kayıt çift girilmiştir, bir kategori tutarsızdır. İşte o an "bunu kim düzeltecek" sorusu sorulur ve cevapsız kalır. Sahiplik boşluğu olan bir projede her küçük sorun, çözecek birini bulamadığı için birikir; ve biriken küçük sorunlar bir proje çıkmazına dönüşür.

Sahiplik boşluğunu birkaç somut belirtiyle tanırım. Birincisi, veri hakkında soru sorulacak tek bir kişinin olmaması: "Bu alan ne anlama geliyor?" sorusu üç ekibe birden yönlendiriliyorsa, sahip yoktur. İkincisi, kimin veriyi değiştirmeye yetkili olduğunun belirsizliği: herkes değiştirebiliyorsa, aslında kimse sorumlu değildir. Üçüncüsü, kalite kararlarının kimseye ait olmaması: "bu veri yeterince iyi mi" sorusuna karar verecek bir merci yoksa, kalite sürekli ertelenir. Bu üç belirti bir aradaysa, veri yönetişimi eksikliğinin merkezinde durursunuz.

Sahiplik boşluğunun çözümü, aslında şaşırtıcı biçimde ucuzdur: her veri kümesine tek bir sahip atamak. Bu sahip, mutlaka teknik biri olmak zorunda değildir; çoğu zaman veriyi en iyi bilen iş birimindeki bir kişidir. Sahibin görevi kod yazmak değil, karar vermektir: bu veri doğru mu, güncel mi, kim erişebilir, bir çelişki çıkarsa hangi kaynak esas alınır. Veri sahipliği kavramını veri sahipliği ve bu rolün olgun biçimini data stewardship yazılarında ele alıyorum. Bir isim atamak, sahiplik boşluğunu bir cümlede kapatır; atamamak ise onu tüm projeye yayar.

Sahiplik boşluğunun yakın akrabası, yetki ve erişim karmaşasıdır. Veri yönetişimi eksikliği olan bir projede kimin hangi veriyi görmeye, kullanmaya ve değiştirmeye yetkili olduğu yazılı değildir; bu boşluk projeyi iki uçtan birine savurur. Ya herkes her şeye erişir (güvenlik ve gizlilik kâbusu), ya da erişim o kadar belirsizdir ki kimse gerekli veriye ulaşamaz ve proje bürokraside boğulur. İkisi de bir proje çıkmazının farklı yüzleridir.

Saha gözleminde en tehlikeli uç, "herkes her şeye erişir" tarafıdır; çünkü hızlı görünür ve başta hiç sorun çıkarmaz. Ekip verimlilik adına tüm veriyi tek bir havuza koyar, herkese açar ve ilerler. Bu, üretime geçmeye çalışılana kadar sürer; o noktada birinin "durun, bu havuzda maaş bilgisi var ve destek ekibi de erişiyor" demesiyle her şey durur. Erişim kontrolü baştan konmadığı için, tüm veri akışını geriye dönüp yeniden tasarlamak gerekir — ve bu, çoğu zaman projenin kendisinden büyük bir iştir.

Ters uç, aşırı kısıtlamadır: kimin neye erişebileceği belirsiz olduğu için, temkinli davranan bir kurum her şeyi kilitler ve her veri talebini uzun onay zincirlerine bağlar. Bu kez proje bilgiye erişemediği için ilerleyemez; ekip haftalarca "şu tabloya erişim izni" bekler. Yetki karmaşası, hız ile güvenlik arasında bir denge kurmak yerine ikisini birden kaybettiren bir durumdur — çünkü kural yoksa, her seferinde sıfırdan pazarlık edilir.

Bu karmaşanın çözümü, erişim kurallarını baştan ve yazılı olarak tanımlamaktır. Karmaşık olmasına gerek yoktur: hangi veri kümesine kimin, hangi amaçla eriştiği bir tabloda tanımlanır. Kişisel veya gizli veri içeren kümeler işaretlenir, bunlara erişim daraltılır ve bir denetim izi tutulur. Erişim kontrolünün neden getirme/kullanım anında yapılması gerektiğini ve gizlilik boyutunu KVKK nedir ve KVKK uyumlu yapay zeka nedir yazılarında; yönetişimin kurumsal çerçevesini ise kurumsal AI yönetişimi ve AI governance nedir yazılarında ele alıyorum. Erişim kuralı, sahiplik gibi, baştan bir tablodur; sonradan bir kriz.

Şimdi, yönetişimsiz projelerin en evrensel örüntüsüne geliyorum: veri kalitesi sorununun her zaman geç fark edilmesi. Saha gözleminde bunu neredeyse istisnasız gördüm — ekip aylarca modele odaklanır, veriye "sonra bakarız" der ve veri kalitesi sorunu ancak model çıktısında bir saçmalık olarak yüzeye çıktığında fark edilir. O noktada ise düzeltmek en pahalıdır, çünkü sorun artık kullanıcıya ulaşmıştır.

Neden hep geç? Çünkü veri kalitesi sorunu, kendisine bakılmadıkça görünmezdir. Hatalı bir tarih, çift girilmiş bir kayıt, eski bir fiyat, çelişkili iki adres — bunların hepsi bir tabloda sessizce durur. Tabloya kimse bakmadıkça sorun yokmuş gibi görünür; sistem veriyi kullanmaya başlayınca sorun görünür olur ama artık en kötü anındadır. Yani veri kalitesi sorunu aslında geç oluşmaz; baştan oradadır, sadece geç bakıldığı için geç görünür. Bu ayrım kritiktir, çünkü çözümü de belirler: kaliteyi görünür kılmak, onu düzeltmekten önce gelir.

Veri kalitesi sorununun birkaç yüzü vardır ve her biri modeli farklı biçimde yanıltır. Doğruluk sorunu (yanlış değerler) modeli yanlış öğretir veya yanlış getirir. Güncellik sorunu (eski kayıtlar) modele artık geçerli olmayan bilgiyi doğru gibi sunar. Eksiksizlik sorunu (boş alanlar) modeli kör noktalara sürükler. Tutarlılık sorunu (aynı şeyin farklı yazımları) modeli aynı varlığı iki farklı şey sanmaya iter. Çelişki sorunu (aynı bilginin iki farklı değeri) ise en tehlikelisidir; çünkü model hangisine güveneceğini bilemez ve rastgele seçer. Bu boyutları veri kalitesi nedir yazısında ayrıntılı işliyorum.

Bu sorunları geç değil erken görmenin yolu, projenin başında bir veri profili çıkarmak ve bir kalite eşiği tanımlamaktır. Veri profili, tabloya girmeden önce ona bakmaktır: kaç kayıt eksik, kaç değer aykırı, kaç çelişki var. Kalite eşiği ise "bu veri projeye girmeden önce en az şu kalitede olmalı" diyen bir kapıdır. Bu iki disiplin, veri kalitesi sorununu üretimdeki bir sürprizden, projenin başındaki bir karara dönüştürür. Kalitesiz veriyle kurulan bir sistemin "çöp girerse çöp çıkar" ilkesine nasıl teslim olduğunu veri sızıntısı önleme gibi ilişkili disiplinlerle birlikte düşünmek gerekir.

Yönetişimsiz projelerin en sinsi duvarlarından biri kaynak belirsizliğidir: aynı bilginin birden fazla yerde, farklı değerlerle durması ve hangisinin doğru olduğunun bilinememesi. Bir müşterinin adresi CRM'de bir türlü, faturalama sisteminde başka türlü, destek kayıtlarında bambaşka olabilir. Yönetişim varsa, bunlardan hangisinin "gerçek kaynak" (single source of truth) olduğu tanımlıdır. Yönetişim yoksa, model rastgele birine dayanır ve kimse neden yanlış cevap verdiğini anlayamaz.

Kaynak belirsizliği, veri yönetişimi eksikliğinin belki de en zor teşhis edilen belirtisidir; çünkü her bir kayıt tek başına "doğru" görünür. Sorun ancak iki kaynak yan yana konduğunda ortaya çıkar — ki bu da genellikle model çelişkili bir cevap ürettiğinde olur. Saha gözleminde bir ekip, modelin neden bazen doğru bazen yanlış cevap verdiğini haftalarca anlamaya çalışmıştı; kök neden, sistemin iki farklı tablodan çelişkili kayıtlar getirmesiydi. Model kusursuz çalışıyordu; veri kaynağı belirsizdi.

Bu belirsizliğin ikinci bir yüzü, verinin nereden geldiğinin (köken/lineage) bilinmemesidir. Bir değerin hangi sistemden, ne zaman, nasıl bir dönüşümden geçerek geldiği kaydedilmemişse, bir hata çıktığında onu geriye takip etmek imkânsızlaşır. Ekip hatayı görür ama kaynağına inemez; her seferinde sıfırdan dedektiflik yapar. Verinin kökenini izlemenin neden kritik olduğunu veri lineage ve kaynak tanımını veri kaynağı yazılarında ele alıyorum.

Kaynak belirsizliğinin çözümü iki karardır. Birincisi, her önemli veri için bir "gerçek kaynak" belirlemek: çelişki çıktığında hangi sistemin esas alınacağını baştan yazmak. İkincisi, verinin kaynağını ve geçerlilik durumunu bir meta veri olarak kaydetmek: bu kayıt nereden geldi, hangi sürüm yürürlükte, ne zaman güncellendi. Meta verinin bu rolünü metadata yönetimi yazısında derinleştiriyorum. Bu iki karar, kaynak belirsizliğini bir kâbustan bir tablo satırına indirger; alınmadığında ise model, hangi verinin doğru olduğunu asla bilemez.

Veri yönetişimi eksikliğinin daha az konuşulan ama sahada sık gördüğüm bir yüzü de ortak tanım eksikliğidir. Bir veri kümesindeki alanların ne anlama geldiği yazılı ve paylaşılmış değilse, anlam kişilere bağlı kalır; ve kişiler değiştikçe anlam da kayar. Belirtisi tanıdıktır: "bu alan ne demek" sorusu üç ekibe birden yönlendirilir ve üç farklı cevap gelir. Bir alanın "aktif müşteri" mi yoksa "son 12 ayda işlem yapan müşteri" mi olduğu belirsizse, o veriyle kurulan her model, tanımdaki bu boşluğu miras alır.

Bu belirsizlik özellikle sinsidir, çünkü hiç hata gibi görünmez. Herkes kendi kafasındaki tanımla çalışır ve işler yürüyormuş gibi görünür; ta ki iki kişinin farklı tanımları bir çelişki üretene kadar. Bir rapor "10 bin aktif müşteri" derken bir başkası "7 bin" der; ikisi de haklıdır, çünkü "aktif" kelimesini farklı tanımlamışlardır. Yapay zeka sistemi bu belirsizliği büyütür: model, tanımı bilmeden veriyi kullanır ve tanımdaki tutarsızlık çıktıya yansır. Bu, bir veri kalitesi sorunu gibi görünür ama kök nedeni kalite değil, tanım eksikliğidir.

Çözüm, kritik alanlar için basit bir veri sözlüğü (data dictionary) tutmaktır. Bu, yüzlerce sayfalık bir doküman olmak zorunda değildir; en önemli alanların her biri için tek satırlık, paylaşılmış bir tanım yeterlidir: bu alan neyi ölçer, hangi birimde, hangi kurala göre hesaplanır. Bir veri kataloğunun bu rolünü metadata yönetimi yazısında ele alıyorum. Ortak tanım, sahiplik boşluğunun bilişsel tarafını kapatır: sahip "kim karar verir" sorusunu, sözlük ise "ne üzerinde anlaşırız" sorusunu çözer.

Ortak tanım eksikliğini erken kapatmanın bir yan faydası daha vardır: yeni ekip üyelerinin hızla devreye girmesi. Tanımlar yazılı değilse, her yeni kişi aynı soruları sorarak zaman kaybeder ve aynı yanlış anlamaları tekrar üretir. Yazılı bir veri sözlüğü, bu bilgiyi kişiye bağlı olmaktan çıkarıp kuruma mal eder. Bu, veri yönetişimi eksikliğinin en ucuz önlemlerinden biridir; birkaç saatlik bir iş, aylarca sürecek yanlış anlamaları baştan keser. Kritik alanların standartlaştırılmış tanımı, kurumsal veri stratejisinin de temelidir; bunu kurumsal AI stratejisi yazısıyla birlikte düşünmek gerekir.

Saha gözleminde yönetişimsiz projelerin çarptığı en pahalı duvar, gizlilik ve erişim kontrolünün en sona bırakılmasıdır. Bunun bir proje çıkmazına dönüşme hızı ve maliyeti diğer tüm belirtileri geride bırakır. Nedeni basittir: bir yapay zeka sistemi kişisel veya gizli veriyle çalışmaya başladıysa ve gizlilik kuralları baştan konmadıysa, bunu sonradan eklemek yamalamak değil, yeniden inşa etmektir.

Örüntü şöyle işler: ekip hızlı ilerlemek için tüm veriyi bir havuza toplar, kişisel veriyi ayıklamadan modele verir ve çalışan bir sistem çıkarır. Her şey yolunda görünür — ta ki hukuk veya uyum birimi devreye girene kadar. O noktada sorulan sorular acıtıcıdır: Bu veride kişisel veri var mı? Amaçla sınırlı mı kullanıldı? Kim erişebiliyor? Silme talebi gelirse veri nereden silinecek? Bu soruların hiçbirine cevap yoksa, proje üretime giremez ve tüm veri akışı geriye dönüp yeniden tasarlanır.

Gizlilik duvarının bu kadar pahalı olması, sonradan eklenememesindendir. Kişisel verinin ne olduğunu bilmek ve onu baştan işaretlemek gerekir; bunu kişisel veri nedir yazısında ele alıyorum. Anonimleştirme veya maskeleme, veri sisteme girmeden önce yapılırsa ucuzdur; girdikten, vektörlendikten, model tarafından kullanıldıktan sonra yapılmaya çalışılırsa neredeyse imkânsızdır. Anonimleştirmenin yöntemlerini veri anonimleştirme nedir ve amaçla sınırlılık ilkesini veri minimizasyonu yazılarında bulabilirsiniz. Bu bir hukuki tavsiye değildir; kurumunuzun hukuk ve uyum birimiyle birlikte tasarlanmalıdır.

Erişim ve gizlilik, aslında aynı madalyonun iki yüzüdür ve her ikisi de baştan bir karar gerektirir. Kim hangi veriyi görebilir, hangi veri kişiseldir, hangi veri gizlidir, kim ne zaman neye erişti — bunların hepsi projenin ilk gününde birer tanım, sonunda birer krizdir. Denetim izinin (audit trail) neden baştan kurulması gerektiğini audit trail yazısında ele alıyorum. Gizlilik duvarı, veri yönetişimi eksikliğinin en somut ve en yüksek faturasıdır; ve neredeyse her seferinde önlenebilirdi.

Şimdiye kadar anlattığım belirtileri tek bir tabloda toplamak, veri yönetişimi eksikliğini somut ve teşhis edilebilir kılar. Aşağıdaki tablo, sahada tekrar tekrar gördüğüm örüntüyü özetler: projede görünen belirti, altındaki kök neden ve en baştan alınabilecek asgari önlem. Bu tablo, bu saha notunun kalbidir; çünkü bir eksikliği ancak belirtisinden tanıyıp kök nedenine inerek önleyebilirsiniz.

Veri yönetişimi eksikliği: projede görünen belirti × kök neden × asgari önlem

Projede görünen belirti	Kök neden	Asgari önlem (baştan)
'Bu hatayı kim düzeltecek?' cevapsız kalıyor	Sahiplik boşluğu — veriden sorumlu tek isim yok	Her veri kümesine bir veri sahibi ata
Model bazen doğru bazen yanlış cevap veriyor	Kaynak belirsizliği — çelişkili kayıtlar, gerçek kaynak tanımsız	Her veri için 'gerçek kaynak' ve geçerlilik kaydı belirle
Hatalar ancak üretimde fark ediliyor	Veri kalitesi sorunu geç görünür — kaliteye baştan bakılmadı	Başta veri profili çıkar, kalite eşiği tanımla
Üretim öncesi hukuk/uyum projeyi durduruyor	Gizlilik en sona bırakıldı — kişisel veri işaretlenmedi	Kişisel/gizli veriyi baştan işaretle, erişimi daralt
Ya herkes her şeye erişiyor ya kimse erişemiyor	Yetki karmaşası — erişim kuralı yazılı değil	Kim-neye-niçin erişir tablosunu baştan yaz
Bir hatanın kaynağına inilemiyor	Köken (lineage) kaydı yok — veri nereden geldi bilinmiyor	Kaynağı ve dönüşümü meta veri olarak kaydet
'Bu alan ne demek?' üç ekibe soruluyor	Ortak tanım yok — anlam kişilere bağlı	Kritik alanlar için basit bir veri sözlüğü tut

Bu tabloya dikkatle bakılınca bir örüntü belirir: sağ sütundaki asgari önlemlerin hiçbiri ağır değildir. Bir isim atamak, bir tablo yazmak, bir eşik tanımlamak — bunların her biri saatler sürer, aylar değil. Buna karşılık sol sütundaki belirtiler ortaya çıktığında, çözümleri haftalar hatta aylar sürer. Veri yönetişimi eksikliğinin ekonomisi budur: önlemi ucuz, belirtisi pahalıdır. Bu asimetriyi görmek, "sonra hallederiz" cazibesine karşı en güçlü panzehirdir.

Tabloyu bir teşhis aracı olarak kullanmanızı öneririm. Bir projeye baktığınızda sol sütundaki belirtilerden herhangi birini görüyorsanız, orta sütundaki kök nedenin işlediğini ve arkada bir veri yönetişimi eksikliğinin biriktiğini bilin. Ve iyi haber şu: sağ sütun her zaman elinizin altındadır. Belirtiyi geç görmek kaçınılmaz değildir; erken bakmayı seçen bir ekip, tablonun sağ tarafında yaşar.

Tablonun bir diğer değeri, farklı belirtilerin aynı köke bağlandığını görünür kılmasıdır. İlk bakışta "model tutarsız cevap veriyor", "hukuk projeyi durdurdu" ve "bir hatanın kaynağına inilemiyor" birbirinden bağımsız üç ayrı sorun gibi görünür; ekip bunları üç ayrı yangın gibi tek tek söndürmeye çalışır. Oysa tablo, bu üç yangının tek bir kaynaktan — veri yönetişimi eksikliğinden — çıktığını gösterir. Bu görüş, tek tek belirtileri kovalamak yerine kök nedene yatırım yapmayı mümkün kılar; ve bu, hem daha ucuz hem daha kalıcı bir çözümdür. Bir örüntüyü kök nedeninden çözmek, belirtilerini tek tek bastırmaktan her zaman daha akıllıcadır.

Veri yönetişimi eksikliğini yalnızca bir süreç sorunu olarak görmek eksik olur; altında bir psikoloji yatar ve bu psikolojiyi anlamadan örüntüyü kırmak zordur. Saha gözleminde defalarca gördüğüm şey, ekiplerin yönetişimin önemini aslında bildiği ama yine de ertelediğidir. Yani sorun bilgisizlik değil, davranıştır; ve davranışın arkasında birkaç güçlü bilişsel eğilim vardır.

Birinci eğilim, görünür işi görünmez işe tercih etmektir. Model çalıştırmak anında bir çıktı verir ve tatmin eder; bir erişim kuralı yazmak ise haftalar sonra işe yarayacak, şimdi hiçbir şey göstermeyen bir emektir. İnsan zihni, gecikmeli ödülü küçümser ve anlık olanı büyütür. Bu yüzden veri yönetişimi eksikliği çoğu zaman tembellikten değil, yanlış hesaplanmış bir ödül-zaman dengesinden doğar. İkinci eğilim, iyimserlik yanlılığıdır: "bizim verimiz farklıdır, bizde bu sorunlar çıkmaz" varsayımı. Oysa saha gözlemi bu iyimserliği neredeyse her seferinde yanlışlar.

Üçüncü eğilim, sorumluluğun dağılmasıdır. Bir iş herkesin sorumluluğu olarak tanımlandığında, her birey bir başkasının onu yapacağını varsayar ve kimse yapmaz; bu, sosyal psikolojide iyi bilinen bir örüntüdür ve sahiplik boşluğunun tam da kaynağıdır. Dördüncü eğilim, kısa vadeli baskıdır: yönetici bir demo bekler, takvim sıkışıktır, "önce çalışsın, gerisi sonra" der. Bu baskı gerçektir; ama yönetişimi ertelemenin bedelini de yine aynı yönetici, birkaç ay sonra çok daha ağır öder.

Bu psikolojiyi bilmek, örüntüyü kırmanın anahtarıdır. Çünkü çözüm sadece "yönetişim yapın" demek değil, bu eğilimleri hesaba katan bir yaklaşım kurmaktır: yönetişim işini küçük ve görünür kılmak (beş somut çıktı), sorumluluğu bir isme bağlamak (dağılmayı önlemek) ve yönetişimi hızın rakibi değil aracı olarak çerçevelemek (kısa vadeli baskıyı yanıtlamak). Veri yönetişimi eksikliği bir karakter kusuru değil, öngörülebilir bir insan davranışıdır; ve öngörülebilir olduğu için, doğru tasarımla önlenebilir.

Veri yönetişiminin en az konuşulan ama en değerli getirilerinden ikisi denetlenebilirlik ve tekrar edilebilirliktir. Bunlar demoda parlamaz, sunumda heyecan yaratmaz; ama bir sistem üretime geçip gerçek kararlar üretmeye başladığında, bu iki özelliğin yokluğu doğrudan bir proje çıkmazına dönüşür. Yönetişimsiz bir sistem, "bu sonucu nasıl ürettin" sorusuna cevap veremez; ve bu cevapsızlık, hem iç denetimi hem düzenleyici uyumu hem de basit hata ayıklamayı imkânsızlaştırır.

Denetlenebilirlik, bir kararın veya çıktının izinin geriye sürülebilmesidir: hangi veriyle üretildi, o veri nereden geldi, kim erişti, hangi sürüm kullanıldı. Yönetişim varsa bu sorular birer log kaydıyla cevaplanır; yönetişim yoksa her soru bir kriz olur. Saha gözleminde bir ekip, modelinin belirli bir karara nasıl vardığını denetçilere açıklayamadığı için projeyi durdurmak zorunda kalmıştı; model doğru çalışıyordu ama kararın arkasındaki veri izi hiç tutulmamıştı. Denetim izinin bu rolünü audit trail ve kökeni veri lineage yazılarında ele alıyorum.

Tekrar edilebilirlik ise bir sonucun aynı koşullarda yeniden üretilebilmesidir. Bir model bir çıktı verdiğinde, o çıktının hangi veriyle, hangi sürümle üretildiği kaydedilmemişse, aynı sonucu tekrar elde etmek imkânsızlaşır. Bu, hata ayıklamayı bir kâbusa çevirir: bir hata görürsünüz ama onu yeniden üretemediğiniz için kaynağına inemezsiniz. Tekrar edilemeyen bir sistem, güvenilir bir sistem değildir; çünkü davranışı öngörülemez ve düzeltilemez. Veri yönetişimi eksikliği, tam olarak bu öngörülemezliği besler.

Bu iki getirinin ortak özelliği, sonradan eklenememeleridir. Bir karar verildikten sonra "keşke izini tutsaydık" demek işe yaramaz; iz, kararın verildiği anda tutulur ya da hiç tutulmaz. Bu yüzden denetlenebilirlik ve tekrar edilebilirlik, minimum yönetişim setindeki denetim izi ve kaynak kaydı öğeleriyle baştan kurulmalıdır. Görünmez oldukları için ihmal edilirler; ama tam da görünmez oldukları için, yokluklarını en kötü anda — bir denetim, bir hata, bir düzenleyici sorusu karşısında — fark edersiniz. Yönetişim, bu görünmez getirileri baştan garanti altına alır.

Belirtileri kök nedenlerine bağladıktan sonra, bu eksikliğin somut olarak hangi "duvarlara" çarptığını beş tekrar eden örüntüyle özetlemek isterim. Bunlar saha gözleminde defalarca gördüğüm, veri yönetişimi eksikliğinin projeyi tıkadığı tipik anlardır; her biri bir proje çıkmazının farklı bir yüzüdür.

Birinci duvar, üretim eşiğidir. Proje pilotta harika çalışır, sonra üretime geçilmek istenir ve orada durur; çünkü üretim, pilotun görmezden geldiği tüm yönetişim sorularını (kim sahibi, kim erişir, veri güncel mi, gizli mi) aynı anda sorar. Pilottan üretime geçişin neden ayrı bir mühendislik problemi olduğunu PoC'den üretime yapay zeka projeleri yazısında ele alıyorum. İkinci duvar, güven erozyonudur: model bir kez çelişkili veya yanlış cevap verdiğinde, kullanıcı güvenini kaybeder ve bu güveni geri kazanmak, teknik düzeltmeden çok daha uzun sürer.

Üçüncü duvar, ölçeklenememedir. Yönetişimsiz bir sistem küçük ölçekte, elle taşınarak ayakta durur; ama veri hacmi ve kullanıcı sayısı arttığında, sahipsiz ve kuralsız veri yönetilemez hale gelir. Dördüncü duvar, tekrar edilemezliktir: bir sonuç üretilir ama nasıl üretildiği (hangi veriyle, hangi sürümle) kaydedilmediği için tekrarlanamaz; bu, hem hata ayıklamayı hem denetimi imkânsızlaştırır. Beşinci duvar, uyum ve denetim duvarıdır: bir düzenleyici veya iç denetim "bu kararı hangi veriyle verdiniz, kim erişti, veri nereden geldi" diye sorduğunda, yönetişimsiz proje cevap veremez.

Bu beş duvarın ortak özelliği, hepsinin projenin sonunda çıkmasıdır. Başta hiçbiri görünmez; hepsi biriken riskin gecikmeli faturasıdır. Ve hepsinin kök nedeni aynıdır: verinin baştan yönetilmemesi. Bu yüzden deneyimli bir gözle bir projeye baktığımda, model mimarisinden önce şunu sorarım: bu verinin sahibi kim, kalitesi ölçüldü mü, kaynağı belli mi, erişimi tanımlı mı? Bu dört sorunun cevabı yoksa, hangi duvara ne zaman çarpılacağını aşağı yukarı kestirebilirim. Bu, kehanet değil; sadece aynı örüntüyü yeterince kez görmüş olmanın verdiği saha gözlemidir.

Sahada sık karşılaştığım bir itiraz şudur: "Bizim sektörümüz farklı; bu örüntü belki başka yerlerde geçerli ama bizde durum başka." Bu itiraz samimidir ama saha gözlemi tam tersini gösterir: veri yönetişimi eksikliğinin belirtileri sektörden bağımsız olarak şaşırtıcı biçimde aynıdır. Bir bankada, bir üretim şirketinde, bir perakendecide veya bir kamu kurumunda aynı belirtileri görürüm — sahiplik boşluğu, geç fark edilen veri kalitesi sorunu, kaynak belirsizliği. Değişen tek şey, verinin içeriğidir; örüntünün kendisi değil.

Neden böyle? Çünkü veri yönetişimi eksikliği bir sektör sorunu değil, bir insan ve organizasyon sorunudur. "Sonra hallederiz" cazibesi, görünmez işi ertelemek, sorumluluğu bir gruba dağıtıp kimseye bağlamamak — bunlar her sektörde aynı insan davranışlarıdır. Verinin bir bankada finansal işlem, bir hastanede hasta kaydı, bir fabrikada sensör ölçümü olması, örüntüyü değiştirmez; çünkü örüntü veride değil, verinin nasıl yönetildiğinde (veya yönetilmediğinde) yatar. Bu yüzden "bizim sektörümüz farklı" savunması, genellikle eksikliği görmemenin bir yolu olur.

Sektör farkı olmayan bu ortaklık, aslında iyi bir haberdir: çözüm de sektörden bağımsızdır. Bir bankada işe yarayan minimum yönetişim seti — sahip, kalite eşiği, erişim kuralı, kaynak kaydı, denetim izi — bir perakendecide de işe yarar. Elbette her sektörün kendi düzenleyici yükümlülükleri, kendi hassas veri türleri vardır; bunlar önlemin ayrıntısını değiştirir ama iskeletini değil. Regüle sektörlerdeki onay süreçlerinin bu iskelete nasıl eklendiğini regüle sektör onayı saha notunda ele alıyorum.

Bu ortaklığın pratik bir sonucu vardır: başka bir sektörden bir dersi kendi bağlamınıza taşıyabilirsiniz. "Bizde olmaz" demek yerine, "bu belirti bizde hangi biçimde görünür" diye sormak daha verimlidir. Veri yönetişimi eksikliği evrenselse, ondan korunma yöntemleri de paylaşılabilir; her kurum aynı dersi sıfırdan, pahalıya öğrenmek zorunda değildir. Bu saha notunun amacı tam da budur: bir örüntüyü ve ona karşı işe yarayan asgari önlemi, sektör sınırlarını aşarak paylaşmak.

Şimdi en önemli kısma geliyorum: çözüm. Ve çözümün ne olmadığını vurgulayarak başlamak istiyorum. Çözüm, aylar süren bir kurumsal yönetişim programı, komiteler, yüz sayfalık politikalar değildir — bu, küçük bir proje için gerçekten abartıdır ve haklı olarak reddedilir. Çözüm, projeyle birlikte kurulan, hafif ve pratik bir minimum yönetişim setidir. Bu set beş öğeden oluşur ve her biri saatler içinde kurulabilir.

Nasıl Yapılır

Minimum veri yönetişimi seti

Bir AI projesini veri yönetişimi eksikliğinden korumak için projeyle birlikte kurulacak beş asgari öğe.

1. 1

   Her veri kümesine bir sahip ata

   Her önemli veri kümesi için, kaliteden sorumlu ve kararları verecek tek bir isim belirle. Teknik olmak zorunda değil; veriyi en iyi bilen kişi olsun.

2. 2

   Bir kalite eşiği tanımla

   Verinin projeye girmeden önce karşılaması gereken minimum doğruluk, güncellik ve eksiksizlik ölçütünü yaz. Başta bir veri profili çıkararak mevcut durumu gör.

3. 3

   Erişim kuralını yaz

   Kim hangi veriye, hangi amaçla erişir? Bir tabloda tanımla. Kişisel ve gizli veri kümelerini işaretle ve erişimi daralt.

4. 4

   Kaynak ve geçerlilik kaydını tut

   Her önemli veri için gerçek kaynağı, nereden geldiğini ve hangi sürümün yürürlükte olduğunu meta veri olarak kaydet.

5. 5

   Bir denetim izi kur

   Kim, ne zaman, hangi veriye erişti ve değiştirdi — bunu baştan logla. Sonradan eklemek çok daha zordur.

Bu beş öğenin gücü, birlikte çalışmalarındadır. Veri sahibi, kalite kararlarını verecek merciyi yaratır; kalite eşiği, veri kalitesi sorununu erken görünür kılar; erişim kuralı, yetki karmaşasını ve gizlilik duvarını önler; kaynak kaydı, kaynak belirsizliğini kapatır; denetim izi ise uyum ve tekrar edilebilirlik duvarlarını aşar. Yani bu küçük set, yukarıda anlattığım tüm belirtileri ve duvarları baştan adresler. Ağır bir program değildir; bir projenin ilk haftasında kurulabilecek bir iskelettir.

Bu setin ikinci erdemi, büyümeye açık olmasıdır. Küçük bir projede beş öğe birer tablo satırı olabilir; proje ve kurum büyüdükçe, bu iskelet olgun bir veri yönetişimi programına genişletilir. Yani minimum set, ileride kurulacak büyük yapının temelidir; sonradan atılıp yenisi kurulmaz, üzerine inşa edilir. Yönetişimin tam kapsamını ve olgun biçimini veri yönetişimi nedir ve kapsamlı veri yönetişimi rehberi yazılarında ele alıyorum; bu saha notu ise o yapının en küçük, en pratik çekirdeğini, sahadaki gerçek ihtiyaçtan damıtarak öneriyor.

Pratik bir tavsiye: bu seti bir "yönetişim projesi" gibi ayrı bir iş olarak sunmayın; AI projesinin ilk sprintinin doğal bir parçası yapın. "Önce veriyi anlayalım" adımı, model kurmadan önceki normal bir başlangıçtır — sadece bu adımı beş somut çıktıya bağlayın: sahip, eşik, kural, kayıt, iz. Böylece yönetişim, projeyi yavaşlatan bir engel değil, onu çıkmazdan kurtaran bir hızlandırıcı olur.

Minimum yönetişim seti bir başlangıçtır, bir varış noktası değil. Kurum ve veri büyüdükçe, bu iskeletin olgunlaşması gerekir; ve bu olgunlaşmanın nasıl işlediğini görmek, "yönetişim" kelimesinin korkutuculuğunu azaltır. Olgunluk bir gecede gelmez; her aşama bir öncekinin üzerine, ölçülmüş bir ihtiyaç ortaya çıktıkça eklenir. Bu kademeli yaklaşım, veri yönetişimi eksikliğini kapatırken aşırı mühendislikten de kaçınmanın yoludur.

İlk aşama, bu yazının merkezindeki minimum settir: tek bir pilot için sahip, kalite eşiği, erişim kuralı, kaynak kaydı ve denetim izi. Bu aşamada her şey birer tablo satırı olabilir; amaç mükemmellik değil, temel boşlukları kapatmaktır. İkinci aşama, bu setin birden fazla projeye ölçeklenmesidir: artık her yeni proje sıfırdan başlamaz, ortak bir yönetişim şablonunu miras alır. Bu noktada bir veri kataloğu, standart kalite kontrolleri ve paylaşılan erişim politikaları devreye girer. Veri kalitesini sürekli izlemenin disiplinini veri kalitesi nedir ve verinin sözleşmeli akışını data contracts yazılarında ele alıyorum.

Üçüncü aşama, yönetişimin bir programa dönüşmesidir: rollerin kurumsallaşması, politikaların yazılması, düzenli denetimlerin kurulması ve yönetişimin bir kişinin insiyatifi olmaktan çıkıp kurumun bir işlevi haline gelmesi. Bu aşamaya sadece belirli bir ölçekten sonra ihtiyaç duyulur; küçük bir kurumda üçüncü aşamayı baştan kurmaya çalışmak, tam da reddedilen "ağır program" tuzağına düşmektir. Olgunluğun anahtarı, doğru aşamada doğru ağırlıkta olmaktır. Kurumsal yönetişim çerçevesinin tam halini kurumsal AI yönetişimi yazısında bulabilirsiniz.

Bu kademeli olgunluk modelinin en önemli mesajı şudur: minimum setle başlamak, ileride tam bir programa geçişi engellemez, aksine kolaylaştırır. Çünkü minimum set zaten doğru iskeleti kurar; program, o iskeletin üzerine et giydirmekten ibarettir. Sıfırdan başlayan bir kurum ile minimum setle başlamış bir kurum, üçüncü aşamaya vardığında aralarındaki fark uçurumdur: biri sağlam bir temel üzerine inşa eder, diğeri ise yıllarca biriken veri yönetişimi eksikliğini geriye dönük temizlemeye çalışır. Olgunluk, baştan doğru başlayanın ödülüdür.

Bir an için karşı argümanı ciddiye alalım: "Ama hız önemli. Yönetişimi baştan kurmak bizi yavaşlatır; önce değeri kanıtlayalım, yönetişimi kazandıktan sonra ekleriz." Bu argüman kulağa mantıklı gelir ve saha gözleminde en sık duyduğum gerekçedir. Ama içinde ölçülmeyen bir varsayım vardır: yönetişimin sonradan eklenmesinin, baştan eklenmesiyle aynı maliyette olduğu. Oysa değildir; sonradan eklemek katbekat pahalıdır ve bunun somut nedenleri vardır.

Birinci neden, geriye dönük düzeltmenin ileriye dönük tanımdan pahalı olmasıdır. Baştan bir veri sahibi atamak bir cümledir; sonradan, sahipsiz büyümüş bir veri yığınında kimin neyden sorumlu olduğunu çözmek bir arkeoloji çalışmasıdır. Baştan erişim kuralı yazmak bir tablodur; sonradan, herkesin her şeye eriştiği bir sistemde erişimi daraltmak, çalışan bir şeyi bozma riskiyle yapılan hassas bir ameliyattır. Aynı işin maliyeti, ertelendikçe üstel büyür.

İkinci neden, biriken kararların birbirine bağlanmasıdır. Yönetişimsiz ilerleyen bir proje, her gün yeni kararlar verir — bu tabloyu şöyle kullanalım, bu veriyi böyle dönüştürelim — ve bu kararların hiçbiri kaydedilmez. Sonradan yönetişim eklemek, bu yüzlerce kaydedilmemiş kararı geriye dönüp çözmek demektir; çoğu zaman kararı verenler bile artık hatırlamaz. Bu, "teknik borç" kavramının veri tarafındaki karşılığıdır ve faizi yüksektir. Bu başarısızlık örüntüsünün kurumsal maliyetini yapay zeka yatırımlarında başarısızlık nedenleri yazısında da ele alıyorum.

Üçüncü ve en az konuşulan neden, itibar maliyetidir. Bir proje yönetişim eksikliği yüzünden bir kez yanlış cevap verdiğinde, güvenli veri sızdırdığında veya uyum denetiminden geçemediğinde, kaybedilen sadece zaman değil, projenin kurum içindeki kredisidir. Bir sonraki AI girişimi bu gölgede başlar. Oysa baştan kurulan hafif bir yönetişim, bu itibari riski neredeyse sıfıra indirir. Yani "hız için yönetişimi erteledik" diyen bir ekip, çoğu zaman ne hız ne de güven kazanır — ikisini birden erteleyerek ikisini birden kaybeder.

Bu saha notunun altında yatan en yaygın yanlış inanç, yönetişim ile hızın karşıt olduğudur. Ekipler "yönetişim bizi yavaşlatır" diye düşünür ve hız uğruna veri yönetişimi eksikliğini göze alır. Ama saha gözlemi bu ikilemi kökten çürütür: yönetişimsiz projeler başta hızlı görünür, sonra çıkmaza girerek durur; yönetişimli projeler başta biraz yavaş görünür, ama üretime kesintisiz ulaşır. Yani gerçek karşıtlık hız ile yönetişim arasında değil, sahte hız ile gerçek hız arasındadır.

Sahte hız, ertelenen kararların yarattığı geçici bir rahatlıktır. "Sonra hallederiz" diyerek atlanan her yönetişim kararı, o anda projeyi hızlandırıyormuş gibi hisseder; ama bu hız borçla alınmıştır ve faizi vardır. Proje ilerledikçe atlanan kararlar birer engele dönüşür ve bir noktada tüm hız durur — genellikle tam üretim eşiğinde. Bu, yüz metreyi hızlı koşup sonra duvara çarpan bir koşucunun hızıdır; etkileyici ama sonuçsuz.

Gerçek hız ise sürdürülebilir hızdır: projeyi başından sonuna, bir duvara çarpmadan taşıyan tempo. Hafif bir yönetişim, ilk haftada biraz zaman alır ama sonraki haftalarda çıkacak duvarları baştan kaldırır. Saha gözleminde üretime gerçekten ve zamanında ulaşan projeler, istisnasız, veriyi baştan yöneten projelerdi; en hızlı görünen değil, en az duvara çarpan projeler kazandı. Yönetişimin hızla ilişkisini kurumsal karar çerçevesiyle kurumsal AI stratejisi yazısında bağlıyorum.

Bu yanlış ikilemi kırmanın pratik yolu, yönetişimi hızın rakibi değil, aracı olarak konumlandırmaktır. Ekibe "yönetişim sizi yavaşlatmaz, sizi duvara çarpmaktan korur" mesajını vermek, direnci azaltır. Çünkü kimse yavaşlamak istemez, ama herkes bitiş çizgisini geçmek ister. Veri yönetişimi eksikliği, bir hız kazancı değil, ertelenmiş bir hız kaybıdır; ve bunu bir kez gören ekip, "sonra hallederiz" cümlesini bir daha aynı rahatlıkla söyleyemez.

Minimum yönetişim setinin kalbi, sahiplik olduğu için, rol ve sorumluluk atamasına ayrı bir bölüm ayırmak istiyorum. Saha gözleminde gördüğüm en yaygın tuzak, "herkesin işi, kimsenin işi" tuzağıdır: veri kalitesi sözde herkesin sorumluluğundadır, dolayısıyla gerçekte kimsenin değildir. Sahiplik boşluğu tam olarak bu tuzaktan doğar. Bunu kırmanın tek yolu, sorumluluğu bir gruba değil, bir isme bağlamaktır.

Bir AI projesinde net atanması gereken birkaç sorumluluk vardır. Veri sahibi, bir veri kümesinin doğruluğu, güncelliği ve anlamı hakkında karar verir; "bu veri projeye hazır mı" sorusunun tek muhatabıdır. Erişim sorumlusu, kimin neye erişebileceğine ve gizlilik kurallarına karar verir; genellikle hukuk/uyum ile birlikte çalışır. Kalite sorumlusu, kalite eşiğinin karşılandığını ölçer ve raporlar. Ve en kritik, en sık atlanan rol: kalite ve güncelliğin zamanla korunmasından sorumlu kişi. Çünkü veri kalitesi statik değildir; bugün temiz olan veri, altı ay sonra eskimiş olabilir.

Bu roller küçük bir projede tek bir kişide birleşebilir; büyük bir kurumda ayrı ekipler olabilir. Önemli olan rollerin sayısı değil, her sorumluluğun bilinçli olarak birine atanmış olmasıdır. Atanmamış her sorumluluk, bir sahiplik boşluğudur ve o boşluk zamanla bir proje çıkmazına büyür. Bu rolleri ve bir ekibin bu yetkinlikleri nasıl kazanacağını kurumsal yapay zeka eğitimi nedir yazısında; kurumsal yönetişim çerçevesini ise kurumsal AI yönetişimi yazısında ele alıyorum.

Bir uyarı: sahip atamak, o kişiye tüm işi yüklemek demek değildir. Sahip, işi yapan değil, kararı veren ve sorumluluğu taşıyan kişidir. Veri temizliğini bir mühendis yapabilir; ama "bu veri yeterince temiz mi, projeye girebilir mi" kararını sahip verir. Bu ayrım önemlidir, çünkü sahiplik boşluğunu kapatmak için birini boğmanıza gerek yoktur; sadece kararın nerede alınacağını netleştirmeniz yeterlidir. Net karar mercii olan bir proje, sorunları biriktirmez; çözer.

Bir örüntüyü tanımanın en pratik faydası, onu erkenden görebilmektir. Veri yönetişimi eksikliği de belirli erken uyarı sinyalleriyle kendini önceden belli eder; bu sinyalleri okumayı öğrenen bir ekip, duvara çarpmadan haftalar önce yön değiştirebilir. Saha gözleminde tekrar tekrar gördüğüm bu sinyalleri, kendi projenizde bir kontrol refleksi olarak kullanmanızı öneririm.

İlk sinyal, veriyle ilgili soruların cevapsız kalmasıdır. Bir toplantıda "bu veri güncel mi", "bunu kim doğruladı", "kaynağı ne" diye sorulduğunda ortalık sessizleşiyorsa, arkada bir sahiplik boşluğu var demektir. İkinci sinyal, "sonra hallederiz" cümlesinin sıklaşmasıdır; bu cümle bir kez söylendiğinde masum, on kez söylendiğinde bir örüntüdür. Üçüncü sinyal, aynı bilginin farklı yerlerde farklı değerlerle görünmesidir — bir kaynak belirsizliğinin habercisi. Dördüncü sinyal, ekibin veriye bakmadan modele geçmeye acele etmesidir; bu, veri kalitesi sorununun ertelendiğinin işaretidir.

Beşinci ve belki en teşhis edici sinyal, kimsenin veriden rahatsız olmamasıdır. Sağlıklı bir projede birileri sürekli veriyle ilgili endişe taşır: "bu yeterince temiz mi", "bunu kullanmaya hakkımız var mı", "bu çelişki neden var". Bu endişeyi taşıyan kimse yoksa, bu bir olgunluk değil, bir körlük işaretidir; çünkü veri her zaman sorun barındırır, sadece bakılmadığında görünmez. Endişenin yokluğu, çoğu zaman bir veri yönetişimi eksikliğinin en sessiz ama en güvenilir sinyalidir.

Bu sinyalleri erken okumanın değeri, kararı ucuzken almaktır. Bir belirti üretimde patladığında pahalıdır; ama bir erken sinyal olarak fark edildiğinde, henüz birkaç saatlik bir önlemle kapatılabilir. Bu yüzden deneyimli bir ekip, projeyi sadece ilerlemesiyle değil, bu sinyallerin varlığıyla da değerlendirir. Veri yönetişimi eksikliği, sinyallerini okumayı bilen bir göz için asla sürpriz değildir; sadece zamanında bakılmayan bir örüntüdür. Bu değerlendirme disiplinini AI use-case önceliklendirme matrisi yazısındaki karar çerçevesiyle birlikte düşünebilirsiniz.

Saha gözleminde veri yönetişimi eksikliğine giden yol, birkaç tekrar eden hatadan geçer. Bunları bilmek, kendi projenizde erken uyarı işaretleri olarak kullanmanızı sağlar. Aşağıda en sık gördüğüm beş hatayı ve her birinden kaçınma yolunu topluyorum.

Birinci hata, veriyi modelden sonra düşünmektir. Ekip önce model mimarisine, araç seçimine, mimari kararlara odaklanır; veri "sonra bakılacak bir ayrıntı" olarak ertelenir. Oysa saha gözlemi tersini söyler: proje başarısının çoğu veride belirlenir, modelde değil. Kaçınma yolu, projenin ilk sprintini veriyi anlamaya ayırmaktır. İkinci hata, kaliteyi ölçmeden varsaymaktır: "verimiz zaten temiz" cümlesi, neredeyse hiçbir zaman doğru çıkmaz. Kaçınma yolu, başta bir veri profili çıkarmak ve varsaymak yerine bakmaktır.

Üçüncü hata, sahipliği bir gruba dağıtmaktır. "Veri kalitesi hepimizin sorumluluğu" cümlesi kulağa iyi gelir ama pratikte sahiplik boşluğu üretir; herkesin işi, kimsenin işidir. Kaçınma yolu, sorumluluğu bir isme bağlamaktır. Dördüncü hata, erişim ve gizliliği en sona bırakmaktır; bu, en pahalı duvarı garanti eder. Kaçınma yolu, kişisel ve gizli veriyi ilk gün işaretlemektir. Beşinci hata, kaynağı ve kökeni kaydetmemektir: bir hata çıktığında geriye takip edilemez. Kaçınma yolu, verinin kaynağını ve sürümünü baştan meta veri olarak tutmaktır. Bu hataların kurumsal ölçekteki toplu etkisini yapay zeka yatırımlarında başarısızlık nedenleri yazısında da ele alıyorum.

Bu beş hata birbirinden bağımsız değildir; hepsi aynı kök tutumdan, veriyi ikincil görmekten beslenir. Bir ekip veriyi projenin merkezine koyduğunda, beş hata da doğal olarak azalır; çünkü artık veri "sonra bakılacak bir şey" değil, projenin kendisidir. Bu tutum değişikliği, herhangi bir araç veya süreçten daha belirleyicidir. Veri yönetişimi eksikliği bir teknoloji açığı değil, bir öncelik açığıdır; ve öncelik, bir kararla değişir.

Bir minimum yönetişim setini kâğıt üzerinde tasarlamak kolaydır; asıl zorluk, onu ekibe kabul ettirmektir. Saha gözleminde en iyi yönetişim planlarının bile, ekip "bu bizi yavaşlatacak bürokrasi" olarak algıladığında raftaki bir dokümana dönüştüğünü gördüm. Bu yüzden yönetişimi konuşma biçiminiz, en az içeriği kadar önemlidir. Direnci aşmanın yolu, yönetişimi bir kısıtlama değil, bir koruma olarak çerçevelemektir.

En yaygın direnç, "biz zaten dikkatli çalışıyoruz, bu ekstra sürece gerek yok" tepkisidir. Bu tepkiyi karşılamanın yolu tartışmak değil, göstermektir: ekibe bu yazıdaki belirti × kök neden × önlem tablosunu sunun ve "bu belirtilerden hangisi şu an bizde var" diye sorun. Çoğu zaman ekip, en az bir belirtinin zaten mevcut olduğunu kendisi fark eder; ve bu fark ediş, herhangi bir ikna konuşmasından daha etkilidir. Veri yönetişimi eksikliği, soyut bir risk olarak anlatıldığında reddedilir; somut bir belirti olarak gösterildiğinde kabul edilir.

İkinci bir direnç, "kimin sahibi olacağı" sorusundan doğar; kimse ek sorumluluk almak istemez. Bunu aşmanın yolu, sahipliği bir yük değil, bir yetki olarak sunmaktır: veri sahibi, o veri hakkında kararı veren, dolayısıyla söz sahibi olan kişidir. Ayrıca sahibin işi yapmadığını, kararı verdiğini netleştirmek, direnci azaltır. Rol atamasının pratik yollarını kurumsal AI yönetişimi ve ekip yetkinliğini kurumsal yapay zeka eğitimi yazılarında ele alıyorum.

Son olarak, yönetişimi ekiple konuşurken dilin önemini vurgulamak isterim. "Yönetişim", "politika", "uyum" gibi kelimeler ağır ve bürokratik çağrışım yapar; oysa aynı içeriği "veriyi baştan anlayalım ki sonra duvara çarpmayalım" diye ifade etmek, aynı işi çok daha kabul edilebilir kılar. Ekip yönetişimi kendi çıkarına — daha az sürpriz, daha az geç gece hata ayıklama, daha az itibar riski — gördüğünde, direnç yerini sahiplenmeye bırakır. Veri yönetişimi eksikliğini kapatmanın en insani tarafı budur: onu bir emir değil, ortak bir akıl olarak kurmak.

Bu saha notunun pratik sonucu şudur: yönetişimi büyük bir dönüşüm gibi değil, küçük bir başlangıç gibi kurun. En sık yapılan hata, "önce tüm kurumun veri yönetişimini düzeltelim, sonra AI'a başlarız" demektir; bu proje asla başlamaz, çünkü kurumsal veri yönetişimi bitmez bir iştir. Doğru yaklaşım tam tersidir: dar bir AI pilotu seçin ve o pilotun kapsamındaki veriyi, o pilotla birlikte yönetin.

Bunun somut anlamı şudur: pilotunuz tek bir departmanın belgeleri veya tek bir veri kümesiyse, yönetişim setinizi de yalnızca o kapsam için kurun. Bir sahip atayın (o veriyi bilen kişi), o veri için bir kalite eşiği yazın, o verinin erişim kuralını tanımlayın, kaynağını kaydedin. Beş öğe, dar bir kapsamda birkaç saat sürer. Ve bu dar başlangıç, hem pilotu bir çıkmazdan korur hem de kuruma yönetişimin nasıl çalıştığını somut olarak gösterir. Pilotu doğru kurmanın ilkelerini PoC'den üretime yazısında ele alıyorum.

Küçük başlamanın ikinci erdemi, öğrenmedir. İlk pilotta minimum yönetişim setini kurarken, kurumunuza özgü zorlukları keşfedersiniz: veri sahibini bulmak neden zor, hangi kalite sorunları en sık çıkıyor, erişim kuralları nerede tıkanıyor. Bu öğrenmeler, bir sonraki, daha geniş projeye taşınır. Böylece yönetişim, tek seferlik bir kurulum değil, projeden projeye olgunlaşan bir yetkinlik olur. Kurumun bunu bir yol haritasına bağlaması için genel veri yönetişimi nedir çerçevesi iyi bir referanstır.

Bu diğer saha notlarıyla da bağlanır: yönetişim eksikliği, tek başına değil, bir örüntüler ailesinin parçası olarak ortaya çıkar. Entegrasyonun neden beklenenden uzun sürdüğünü entegrasyon gecikmeleri saha notunda, yönetici desteğinin projeyi nasıl belirlediğini yönetici desteği saha notunda ele alıyorum. Bu saha notlarının tümünün nasıl toplandığını ve ortak derslerini saha notları ana yazısında bir araya getiriyorum. Veri yönetişimi eksikliği, bu ailenin belki de en sinsi üyesidir; çünkü en geç görünür ve en pahalıya patlar.

Bu saha notunu somut bir başlangıca dönüştürmek için, bir AI projesinin ilk haftasında veri yönetişimi eksikliğini kapatmaya yönelik pratik bir kontrol listesi öneriyorum. Bu liste ağır değildir; her maddesi bir toplantı veya bir tablo ile karşılanabilir. Amaç, projenin daha kod yazılmadan önce veriyle ilgili doğru soruları sormasını sağlamaktır.

Nasıl Yapılır

İlk hafta veri yönetişimi kontrol listesi

Bir AI projesinin ilk haftasında veri yönetişimi eksikliğini erkenden kapatmak için atılacak somut adımlar.

1. 1

   Veri kümelerini listele ve sahip ata

   Projenin kullanacağı her önemli veri kümesini yaz ve her birine tek bir sahip ismi ata.

2. 2

   Bir veri profili çıkar

   Her kümeye bak: kaç kayıt eksik, kaç değer aykırı, kaç çelişki var? Kaliteyi varsayma, ölç.

3. 3

   Kalite eşiğini yaz

   Verinin projeye girmeden karşılaması gereken minimum doğruluk, güncellik ve eksiksizlik ölçütünü belirle.

4. 4

   Erişim ve gizlilik tablosunu doldur

   Kim hangi veriye erişir, hangi küme kişisel/gizli veri içerir? Bunu yazılı hale getir ve erişimi daralt.

5. 5

   Gerçek kaynağı ve sözlüğü belirle

   Çelişki çıktığında hangi sistemin esas alınacağını ve kritik alanların ne anlama geldiğini bir satırda yaz.

6. 6

   Denetim izini aç

   Kim, ne zaman, hangi veriye erişti ve değiştirdi — bunu ilk günden loglamaya başla.

Bu kontrol listesinin gücü, tamamlanmasının kısalığında ve etkisinin büyüklüğündedir. Altı madde, deneyimli bir ekip için birkaç günlük iştir; ama bu birkaç gün, ilerideki haftalarca sürecek çıkmazları baştan önler. Listeyi bir "yönetişim projesi" olarak değil, projenin doğal başlangıç adımı olarak sunun; böylece ekip onu bir yük değil, bir hazırlık olarak görür.

Listeyi bir kez doldurmak yetmez; her yeni veri kümesi eklendiğinde tekrar çalıştırılmalıdır. Veri yönetişimi eksikliği, projenin başında kapatılıp unutulacak bir şey değildir; proje büyüdükçe yeni veriyle yeniden ortaya çıkabilir. Bu yüzden kontrol listesini, tek seferlik bir kurulum değil, tekrarlanan bir refleks haline getirin. Ekiplerinizin bu refleksi kazanması için kurumsal yapay zeka eğitimi ve konuları derinleştirmek için öğrenme merkezi iyi bir zemin sağlar.

Onlarca projeyi izledikten sonra, veri yönetişimi eksikliği hakkında damıttığım dersleri birkaç net cümlede toplamak isterim. Bunlar teorik ilkeler değil; sahada tekrar tekrar sınanmış, her seferinde doğrulanmış gözlemlerdir. Bir sonraki AI projenize başlarken, bu dersleri bir kontrol listesi gibi kullanabilirsiniz.

Birinci ders: veri yönetişimi eksikliği bir teknoloji sorunu değil, bir karar sorunudur. Çöküş, kötü modelden değil, baştan alınmamış beş karardan (sahip, kalite, erişim, kaynak, denetim) gelir. Bu beş karar teknik uzmanlık değil, netlik ister; en güçlü mühendislik ekibi bile, bu kararlar boşta kaldığında aynı duvara çarpar. İkinci ders: eksiklik hemen görünmez; sessizce biriktirir ve tam üretime geçilecekken bir proje çıkmazı olarak patlar. Bu yüzden "şu an sorun yok" hissi, yokluğun değil, ertelemenin işaretidir. Üçüncü ders: her belirtinin ucuz bir asgari önlemi vardır ve bu önlemler projenin sonunda değil, başında alınır.

Dördüncü ders, belki en önemlisi: yönetişim, hızın düşmanı değil, sürdürülebilir hızın koşuludur. Yönetişimsiz bir proje ilk yüz metrede hızlı koşar ama duvara çarpar; hafif yönetişimli bir proje ilk yüz metrede biraz yavaş görünür ama bitiş çizgisini geçer. Saha gözleminde üretime gerçekten geçen projeler, veriyi baştan yöneten projelerdi — istisnasız. Beşinci ders: çözüm ağır değildir. Beş öğelik bir minimum yönetişim seti, bir haftalık iş, tüm bu duvarları baştan adresler.

Son bir söz: bu bir saha notudur, bir reçete değil. Her kurumun veri gerçekliği farklıdır; ama örüntü şaşırtıcı biçimde aynıdır. Veri yönetişimi eksikliği ile başlayan projeler aynı yerde çıkmaza girer; veriyi baştan yöneten projeler ise üretime ulaşır. Kurumunuzun verisini ve ilk AI pilotunu bu gözle tasarlamak, bir danışmanlık görüşmesiyle netleştirilebilecek en değerli adımlardan biridir; ekiplerinizin bu yetkinliği kazanması için kurumsal eğitim seçeneklerini, tüm kavramları derinleştirmek için ise öğrenme merkezini inceleyebilirsiniz.

Veri yönetişimi olmadan bir AI projesine başlanır mı?

Teknik olarak başlanabilir ve saha gözleminde çoğu proje tam olarak böyle başlar; ama bu, riski ertelemek anlamına gelir, ortadan kaldırmak değil. Veri yönetişimi eksikliği ile başlayan bir proje ilk haftalarda hızlı ilerliyormuş gibi görünür, çünkü kimse durup "bu veri kimin, doğru mu, kim erişebilir" diye sormaz. Sorun tam üretime geçileceği anda çıkar: veri kalitesi sorunu model çıktısına yansır, sahiplik boşluğu yüzünden kimse düzeltmeyi üstlenmez ve proje bir çıkmaza girer. Doğru yaklaşım, ağır bir yönetişim programı kurmadan, projeyle birlikte bir minimum yönetişim seti tanımlamaktır.

Veri yönetişimi eksikliğinin ilk belirtileri neler?

Saha gözleminde ilk belirti neredeyse her zaman sahiplik boşluğudur: bir veri hatası bulunduğunda "bu kimin sorumluluğunda" sorusunun cevapsız kalması. İkinci belirti kaynak belirsizliğidir: aynı bilginin birkaç yerde farklı değerlerle durması. Üçüncü belirti erişim karmaşasıdır: kimin hangi veriyi görmeye yetkili olduğunun yazılı olmaması. Dördüncüsü, veri kalitesi sorununun ancak model "saçmaladığında" fark edilmesidir. Bu belirtiler tek tek küçük görünür ama birlikte bir proje çıkmazının erken sinyalleridir.

Yönetişimsiz bir projede en pahalı duvar hangisidir?

Saha gözleminde en pahalı duvar, gizlilik ve erişim kontrolünün en sona bırakılmasıdır. Bir yapay zeka sistemi kişisel veya gizli veriyle çalıştıysa ve erişim kuralları baştan konmadıysa, üretime geçmeden önce tüm veri akışını geri dönüp yeniden tasarlamak gerekir; bu çoğu zaman projenin kendisinden büyük bir iştir. İkinci en pahalı duvar kaynak belirsizliğidir. Bu duvarların ortak kökü aynıdır: veri yönetişimi eksikliği. Hepsi baştan, çok daha ucuza önlenebilirdi.

Minimum veri yönetişimi seti nedir?

Minimum veri yönetişimi seti, ağır bir kurumsal programa girmeden bir projeyi ayakta tutan en küçük kural ve sorumluluk kümesidir. Beş öğeden oluşur: veri sahibi (her veri kümesi için tek bir sorumlu isim), kalite eşiği (verinin karşılaması gereken minimum ölçüt), erişim kuralı (kim neye erişir), kaynak ve geçerlilik kaydı (verinin kökeni ve yürürlükteki sürümü) ve denetim izi (kim ne zaman neye erişti). Bu beş öğe sahiplik boşluğunu, veri kalitesi sorununu ve kaynak belirsizliğini erkenden kapatır ve büyüdükçe olgun bir yönetişim programına genişletilir.

Veri kalitesi sorunu neden hep geç fark ediliyor?

Çünkü veri kalitesi sorunu, model çıktısına yansıyana kadar görünmezdir. Hatalı, eski veya çelişkili bir kayıt bir tabloda sessizce durur; kimse ona bakmadıkça sorun yokmuş gibi görünür. Yapay zeka sistemi bu veriyi kullanmaya başladığında sorunu görünür kılar — ama artık en pahalı noktadadır. Bunu önlemenin yolu, veri kalitesini projenin başında ölçmek ve bir kalite eşiği tanımlamaktır. Kısacası veri kalitesi sorunu geç fark edilmez, geç bakıldığı için geç görünür.

Kısaca, bu saha notunun özü şudur: veri yönetişimi eksikliği, verinin sahipliği, kalitesi, erişimi, gizliliği ve kaynağı konusunda kuralların baştan konmaması durumudur ve bir AI projesini hemen değil, sessizce, tam üretime geçileceği anda bir proje çıkmazına sürükler. En erken belirti sahiplik boşluğu, en evrensel belirti geç fark edilen veri kalitesi sorunu, en pahalı duvar ise gizlilik ve kaynak belirsizliğidir. Bütün bunların kök nedeni aynıdır: veriyi baştan yönetmemek.

En önemli mesaj şudur: çözüm ağır değildir. Bir haftalık iş olan beş öğelik bir minimum yönetişim seti — sahip, kalite eşiği, erişim kuralı, kaynak kaydı, denetim izi — bu saha gözleminde anlattığım tüm belirtileri ve duvarları baştan adresler. Yönetişim, hızın düşmanı değil, üretime ulaşmanın koşuludur. Temel kavramlar için veri yönetişimi nedir, veri kalitesi nedir ve veri sahipliği yazılarına; kurumunuza özel bir veri ve yönetişim tasarımı için danışmanlık görüşmesine, ekipleriniz için kurumsal eğitim seçeneklerine ve tüm konuları derinleştirmek için öğrenme merkezine bakabilirsiniz.