Tasarımdan İtibaren Uyum

Birçok yapay zekâ projesi uyumu canlıya geçişten önce hazırlanacak son dosya gibi ele alır: veri korumasını kontrol et, birkaç ekran görüntüsü topla, riskleri yaz, onayı imzala — tamam.

Sorun tam da burada başlar.

Çünkü sonradan oluşturulan bir dokümantasyon çoğu zaman yalnızca ne yaşandığına dair makul bir hikâye anlatabilir. Gerçekte hangi model sürümünün çalıştığını, hangi verinin hangi bölgede işlendiğini, onaydan önce hangi testlerin geçtiğini, bir istisnayı kimin onayladığını veya sonraki bir değişikliğin neden yeni inceleme tetiklemediğini güvenilir biçimde kanıtlayamaz.

Profesyonel yapay zekâ yönetişimi bu nedenle farklı bir yaklaşım gerektirir:

Uyum, projenin sonunda açılan bir arşiv klasörü değildir. Uyum; çalışma sırasında hangi kanıtların oluşacağını, bunlardan kimin sorumlu olduğunu, hangi kontrollerin gerçekten kural uyguladığını ve kanıt yoksa hangi adımın ilerleyemeyeceğini belirleyen bir mimaridir.

Tasarımdan İtibaren Uyum budur.

Tasarımdan İtibaren Uyum ilk üretim çalışmasından önce başlar

Klasik dokümantasyonda önce iş yapılır, sonra ne yapıldığı anlatılır. Tasarımdan İtibaren Uyum yaklaşımında ise kritik bir iş akışı başlamadan önce şu sorular cevaplanır:

Hangi düzenleyici veya kurum içi gereklilik geçerli? Bunu hangi somut kontrol karşılıyor? Bu kontrolün sahibi kim? Hangi kanıt otomatik ya da manuel üretilmeli? Kanıt hangi sistem, model ve artefakt sürümüne bağlanmalı? Ne zaman incelenecek? Hangi eksiklik sürümü bloke edecek? Kanıt ne zaman yenilenmeli? Ne kadar süre saklanabilir veya saklanmalıdır?

Böylece uyum, hafızadan çıkar ve sistem tasarımının parçası olur.

Dokümantasyon ile uyum aynı şey değildir

Bir proje çok iyi dokümante edilmiş olup yine de uyumsuz olabilir.

Tersine, bir sistem maddi bir gerekliliği gerçekten karşılayabilir; fakat kurum bunu sonradan ispatlayamadığı için sorun yaşayabilir.

Bu nedenle beş kavramı ayırmak gerekir:

Rapor kontrol değildir. Kontrol de kendi etkinliğinin otomatik kanıtı değildir.

Temel değişim: sonradan tutulan kayıttan operasyonel kontrol sistemine

Olgun yapay zekâ projelerinde proje yönetimi veya yönetişim sistemi, iş bittikten sonra sonuçlarla doldurulmamalıdır.

Riskler, kararlar, gate’ler, istisnalar, kanıtlar ve sürümler gerçek çalışma sırasında oluşmalıdır.

Bu, kanıt kalitesini kökten değiştirir.

Bir agent bir iş adımına başladığında çalışma; görev, veri sınıfı ve izin verilen tool policy ile önceden bağlanabilir. Gate’e gelindiğinde hangi kanıtların gerekli olduğu bellidir. Model değiştiğinde değişiklik yeni bir inceleme ihtiyacı doğurabilir. Kritik test başarısız olduğunda sonraki release bloke kalır.

Ortaya bir audit günlüğü değil, uygulanabilir bir kontrol yapısı çıkar.

Evidence by Construction

En güçlü kanıt çoğu zaman ayrı bir bürokratik iş olarak üretilmek zorunda olmayan kanıttır.

Bir sistem her kritik çalışmada otomatik olarak model ve sürümünü, geçerli policy’yi, işlenen veri sınıfını, çağrılan araçları, üretilen artefaktı, uygulanan eval sürümünü ve ardından verilen gate kararını kaydediyorsa, kanıt doğru kurulmuş sürecin yan ürünü hâline gelir.

Buna Evidence by Construction denebilir.

Alternatif, haftalar sonra sohbetlerden, hafızadan ve ekran görüntülerinden ne olmuş olabileceğini yeniden kurmaktır. Agentic sistemlerde bu yaklaşım ölçeklenmez.

Uyum bir doküman değil, zincirdir

Sağlam bir uyum zinciri şöyle kurulabilir:

Gereklilik → Risk → Kontrol → Uygulama → Kanıt → İnceleme → Karar → Sürüm → İzleme

Her halka farklı bir işlev görür.

Gereklilik yoksa kontrolün niçin var olduğu bilinmez. Risk tanımı yoksa önlem orantısız olabilir. Kontrol yoksa uyum beyan düzeyinde kalır. Kanıt yoksa etkinlik ispatlanamaz. Sürümleme yoksa kanıtın hangi sistem durumuna ait olduğu bilinmez. İzleme yoksa karar fark edilmeden eskir.

Bu nedenle uyumun gerçek birimi PDF değil, birbirine bağlanmış kanıt zinciridir.

Yapay zekâ projeleri için Compliance Stack

Pratikte katmanlı bir yapı yardımcı olur.

1. Scope & Classification

Kurum hangi rolde? Hangi sistem, use case ve kullanıcı grubu söz konusu? Hangi hukuk alanı ve sektör kuralı geçerli? Gerçekten düzenlemeye tabi yüksek riskli bir durum mu var, yoksa çok daha basit bir senaryo mu?

2. Risk & Impact

Hangi zararlar veya temel hak etkileri gerçekçi? Hangi veri riskleri bulunuyor? Hangi kişi ya da gruplar etkilenebilir? Hatalar nerede geri alınabilir, nerede alınamaz?

3. Control Design

Bu riskleri hangi teknik ve organizasyonel kontroller karşılıyor? Veri bölgeleri, tool yetkileri, gate’ler, insan gözetimi, rate limit’ler, istisna kuralları ve onay süreçleri bunlara örnektir.

4. Operational Evidence

Gerçek işletimde hangi loglar, test sonuçları, review’lar, kararlar ve sürümler oluşuyor?

5. Technical Documentation

Amaç, mimari, ilgili sürümler, bağımlılıklar, veri akışları, testler, sınırlamalar ve işletim koşulları nasıl bütünlüklü dokümante ediliyor?

6. Change & Lifecycle Governance

Hangi değişiklikler yeni test, yeni onay, impact assessment veya risk sınıfının yeniden değerlendirilmesini tetikliyor?

7. Monitoring & Incident Response

Canlıya geçişten sonra performans, risk, provider, veri veya kullanıcı davranışındaki değişimler nasıl tespit ediliyor?

Bu stack açıkça gösterir: uyum arşivlemeyle değil, scope ve tasarımla başlar.

Önce sınıflandır, sonra dokümante et

Yaygın bir hata, risk sınıflandırması yapılmadan azami dokümantasyon üretmektir.

Bunun iki sonucu vardır. Birincisi, düşük riskli süreçler gereksiz bürokrasiye boğulur. İkincisi, belge kalabalığı gerçekten kritik kanıtları görünmez hâle getirebilir.

Daha profesyonel yaklaşım riskle orantılıdır:

Use case’i tanımla. Kurumsal rolü ve sorumluluğu belirle. Veri sınıflarını ve etkilenen grupları çıkar. Düzenleyici kapsamı kontrol et. Risk düzeyi ile geri alınabilirliği değerlendir. Kontrol ve kanıt derinliğini buna göre belirle.

Daha fazla doküman otomatik olarak daha fazla uyum değildir. Daha iyi eşleştirme daha fazla uyumdur.

Provider ile deployer aynı rol değildir

Özellikle EU AI Act bakımından rol belirleyicidir.

Yüksek riskli bir sistemi geliştirip kendi adıyla piyasaya sunan kuruluş ile mevcut bir sistemi kullanan kuruluşun yükümlülükleri farklı olabilir. Importer, distributor, authorized representative veya başka roller de önem taşıyabilir.

Veri koruma rolleri de farklı bir yapıya sahiptir: controller ve processor, provider ve deployer kavramlarının eş anlamlısı değildir.

Bu nedenle uyum planının başında bir Role Map bulunmalıdır.

Aksi hâlde yanlış yükümlülük için yanlış dokümantasyon hazırlanabilir.

Güncel hukuki temel de bir proje artefaktıdır

Uyum dokümantasyonu yalnızca sistemi değil, kararların dayandığı regülasyon temelini de sürümlemelidir.

Bu özellikle hızlı değişen yapay zekâ düzenlemelerinde önemlidir. Ağustos 2026 itibarıyla AI Act genel olarak 2 Ağustos 2026’dan beri uygulanırken, 2026’da yürürlüğe giren AI Omnibus sonrasında birçok bağımsız yüksek riskli sistem için kurallar 2 Aralık 2027’de, düzenlenmiş ürünlere gömülü yüksek riskli sistemler için ise 2 Ağustos 2028’de uygulanmaya başlar.^[1]

Bu nedenle proje şunları kaydetmelidir:

Hangi hukuki metin sürümünün incelendiği, hangi tarihte incelendiği, hangi sınıflandırmanın bundan türetildiği, hangi kılavuz veya standardın hâlâ beklemede olduğu ve bir sonraki legal review’un ne zaman yapılacağı.

“Bunu zamanında kontrol etmiştik” bir kontrol değildir.

Tek bir evrensel saklama süresi yanılsaması

Retention konusunda da tek rakamlı kısa yollar yanıltıcıdır.

“Yapay zekâ proje dokümanları X ay tutulmalı” biçiminde genel bir kural yoktur.

AI Act içindeki farklı yükümlülüklerin farklı süreleri vardır. Yüksek riskli sistem provider’ları için Article 18, belirli dokümanların piyasaya arz veya hizmete alma sonrasında genel olarak on yıl erişilebilir tutulmasını öngörür.^[7] Article 19, provider’ın kontrolündeki otomatik logların başka Birlik veya ulusal hukuk farklı bir şey gerektirmedikçe en az altı ay tutulmasını öngörür. Article 26 da deployer’ın kontrolündeki ilgili loglar için benzer şekilde en az altı aylık kural getirir.^[8]

Veri koruma, çalışma, finans, sağlık ve diğer sektör düzenlemeleri farklı süreler yaratabilir.

Sonuç:

Retention, her artefakt ve hukuki dayanak için ayrı belirlenmelidir.

Tek bir “uyum arşivi süresi” çoğu zaman fazla kabadır.

Compliance Matrix

En etkili yapılardan biri, soyut yükümlülükleri somut proje nesnelerine çeviren bir matristir.

Matris üç sık hatayı engeller: sahipsiz yükümlülükler, kanıtsız kontroller ve güncelleme tetikleyicisi olmayan belgeler.

Minimum Viable Evidence Pack

Her projenin yüksek riskli bir sistem kadar kapsamlı regülasyon dosyasına ihtiyacı yoktur.

Ancak normal profesyonel bir yapay zekâ iş akışı için Minimum Viable Evidence Pack faydalı olabilir. Bu kanunda tanımlanmış bir asgari liste değil, metodolojik bir temel standarttır:

Amaç ve sınırları içeren System Card. Veri akışı ve veri sınıflandırma haritası. Model/provider/sürüm kaydı. Risk & Decision Log. Kritik kalite kriterleri için Eval Record. Gate/Release Record. Change Log. Incident Log. Sorumluluklar ve eskalasyon yolu.

Böylece küçük proje gereksiz ağırlaştırılmaz; fakat sonradan yeniden kurulabilir durumda kalır.

System Card: kontrol nesnesi olarak amaç

System Card yalnızca ürün tanımı olmamalıdır.

En azından şunları belirtmelidir:

Intended use, non-intended use, kullanıcı grupları, ilgili veri sınıfları, izin verilen aksiyonlar, bilinen sınırlamalar, kritik bağımlılıklar, system owner ve review tarihi.

Bu alanlar statik değildir.

Ekip içi metin asistanı daha sonra aday eleme sistemine dönüşürse bu küçük bir özellik güncellemesi değildir. Use case temelden değişmiştir; dolayısıyla düzenleyici kapsam da tamamen değişebilir.

Data Map: sadece “Hangi verilerimiz var?” sorusu değildir

Uyuma elverişli bir veri haritası yalnızca kaynak listesini göstermez.

İlgili veri akışları için şunları açıklamalıdır:

Kaynak, amaç, hassasiyet, hukuki ve policy dayanağı, saklama yeri, aktarım bölgesi, erişim rolleri, retention, silme mantığı ve downstream alıcılar.

Özellikle hibrit mimarilerde, görünüşte yerel bir akışın telemetri, retrieval, debugging veya harici araçlar üzerinden yine de veri dışarı çıkarıp çıkarmadığı böyle görülür.

Risk ve etki değerlendirmesi etkiden önce gelmelidir

Canlıya geçişten sonra yazılan bir impact assessment en önemli işlevini kaçırmıştır.

Amaç yalnızca gerçekleşmiş etkileri anlatmak değil; olası etkileri kritik kullanımdan önce belirlemek ve kontrolleri bunlara göre tasarlamaktır.

Bu ilke hem veri korumada hem AI Act içinde görülür. GDPR altında, işlemenin yüksek risk yaratması muhtemelse DPIA genel olarak işlem başlamadan önce yapılmalıdır. AI Act ise belirli yüksek riskli sistemlerin belirli deployer’ları için kullanımdan önce temel haklar etki değerlendirmesi ister.^[9]

Bu, her yapay zekâ kullanımının otomatik olarak resmi FRIA veya DPIA gerektirdiği anlamına gelmez.

Ama her profesyonel proje şu sorudan yararlanır:

Bu sistem durumunu üretime almadan önce hangi etkiyi anlamamız gerekiyor?

Kontroller gerçek sistem sınırlarına bağlanmalıdır

PDF içindeki bir policy, etkili bir sürece çevrilmediği sürece hiçbir şeyi kontrol etmez.

Örnekler:

“Hassas veri harici modele gönderilmez” → Data Router tanımlı sınıfları engeller. “Onaysız yayın yok” → Publishing Tool gate token ister. “Yalnızca eval edilmiş model sürümleri” → Deployment sadece onaylı registry sürümlerini kabul eder. “İstisna için onay gerekir” → Exception Record sahibi, gerekçesi ve son kullanma tarihiyle oluşturulur.

Compliance dokümantasyonu ile compliance engineering arasındaki köprü budur.

No Evidence, No Release

Kritik artefaktlarda basit bir kural geçerli olmalıdır:

Kanıt yoksa release yok.

Bu, her küçük metin taslağının compliance officer gerektirdiği anlamına gelmez.

Anlamı şudur: Proje bir kontrol gerekliliği tanımladıysa, sonraki sistem durumuna ancak gerekli Evidence Packet mevcutsa geçilebilir.

Örneğin release gate şunları isteyebilir:

Eval geçti, veri onayı geçerli, model sürümü kayıtlı, bilinen riskler kabul edilmiş, Human Authority atanmış, rollback mevcut.

Böylece uyum bir niyet değil, state transition rule hâline gelir.

Gate kanıtı bir sistem durumuna bağlanmalıdır

Sürüm referansı olmayan onay tehlikelidir.

“12 Ağustos’ta onaylandı” ifadesi, sonra prompt, model, veri temeli ve tool yetkileri değişmişse çok az şey söyler.

Sağlam bir onay en azından şunlara referans vermelidir:

System veya release ID, model sürümü, ilgili policy sürümü, eval sürümü, veri ve context durumu, karar, karar veren, zaman ve geçerlilik koşulları.

Tanımlı bir koşul değişince onay eskimiş sayılmalıdır.

Change Management aynı zamanda Compliance Management’tır

Yapay zekâ sistemleri hızla değişir.

Yeni model sürümü. Yeni provider. Yeni system prompt. Ek veri kaynağı. Yeni kullanıcı grubu. Daha fazla tool yetkisi. Daha yüksek otonomi. Farklı output kanalı.

Bunların her biri önceki kanıtın bir kısmını geçersiz kılabilir.

Bu nedenle projelerin Change Classes tanımlaması gerekir.

Sınıf A — kozmetik

Fonksiyon, veri veya risk üzerinde maddi etki yoktur. Değişikliği kaydet; tam review gerekmez.

Sınıf B — işlevsel

Fonksiyon veya davranış değişir. Hedefli re-eval ve ilgili dokümantasyon güncellemesi gerekir.

Sınıf C — material risk change

Veri sınıfı, kullanıcı grubu, etki alanı, tool yetkileri, otonomi veya kritik bağımlılıklar değişir. Yeni risk/uyum review’u ve gerekiyorsa yeni impact assessment tetiklenir.

Somut sınıflandırma projeye özeldir. Önemli olan mekanizmadır: değişiklik otomatik olarak yeni bir inceleme sorusu yaratır.

Sürümleme kodun ötesine geçmelidir

Tek başına Git yeterli değildir.

Yapay zekâ projelerinde en az şu nesneler sürümlenebilir veya benzersiz tanımlanabilir olmalıdır:

Sistem tanımı, prompt ve instruction set, model ve provider konfigürasyonu, retrieval kaynakları, tool schema ve yetkileri, eval suite, policy kuralları, veri sınıflandırmaları, onay ve teknik dokümantasyon.

Yoksa tuhaf bir durum oluşur: Kod kusursuz sürümlenmiştir, fakat gerçek üretim sürümünün hangi policy ve modelle çalıştığını kimse bilmez.

Uyumun sahipleri olmalıdır

Owner’sız kontroller sessizce ölür.

Her önemli kontrol en az şu rolleri gerektirir:

Control Owner — işlev ve bakımın sorumlusu.

Evidence Owner — kanıtın oluşmasını ve erişilebilir kalmasını sağlar.

Reviewer — etkinliği veya uygunluğu inceler.

Accountable Authority — kalan riski kabul eder veya release’i bloke eder.

Küçük ekiplerde bir kişi birden fazla rolü üstlenebilir. Yine de rol mantığı açık olmalıdır.