---
title: "Çok Kiracılı SaaS Sözleşmeleri için Federated Learning Yönetişim Maddeleri"
---

# Çok Kiracılı SaaS Sözleşmeleri için Federated Learning Yönetişim Maddeleri

**Federated Learning** (FL)’in (birleştirilmiş öğrenme) bulut‑tabanlı yazılım‑hizmeti (SaaS) platformları üzerindeki hızlı benimsenmesi, veri yerelliğini korurken işbirlikçi yapay zekâ için yeni fırsatlar sundu. Ancak, veri işleme etrafında geleneksel olarak bulunan yasal çerçeve—standart *Veri İşleme Anlaşmaları* (DPAs) veya *Machine Learning* ekleri gibi—**çok‑kiracılı** bir ortamda FL’in nüanslı risk profilini yakalamakta sık sık yetersiz kalıyor. Çok‑kiracılı bir SaaS modelinde, onlarca ya da yüzlerce ayrı müşteri, özel veri setlerinden model güncellemeleri sağlar; ancak bu ham veriler hiçbir zaman kendi tesislerinden dışarı çıkmaz. Bu mimari, hibrit bir uyum sorunu yaratır: Her kiracı, verilerinin hâlâ kendi kontrolü altında olduğundan emin olmalı; SaaS sağlayıcısı ise toplu model parametrelerinin istemeden hassas bilgileri ifşa etmediğini garanti etmelidir.

Bu boşluğu kapatmak için sözleşme yazarlarının **Federated Learning Yönetişim Maddesi** (FLGC) adlı özel bir maddeye ihtiyacı vardır. Geleneksel olarak veri aktarımı, depolama ve ihlal bildirimi üzerine odaklanan maddelerin aksine, FLGC üç temel boyutu ele alır: (1) **algoritmik şeffaflık**, (2) **parametre gizliliği önlemleri** ve (3) **kiracı‑arası sorumluluk tahsisi**. Aşağıda bu boyutların neden önemli olduğuna, *Genel Veri Koruma Yönetmeliği* (GDPR), *Ulusal Standartlar ve Teknoloji Enstitüsü* (NIST) ve *Uluslararası Standart Organizasyonu* (ISO/IEC 27001) gibi mevcut düzenlemelerle nasıl eşleştiğine ve Contractize.app tarafından oluşturulan bir sözleşme şablonunda somut olarak nasıl ifade edilebileceğine değineceğiz.

## Neden Geleneksel Veri‑İşleme Maddeleri Yetersiz Kalıyor?

Standart DPAs, bir veri denetleyicisinin bir işlemciye kişisel verileri **taşıma, depolama veya dönüştürme** yetkisi vermesi üzerine kuruludur. FL’de işlemci (SaaS sağlayıcısı) ham veriye doğrudan erişmez; bunun yerine bir dizi **yerel eğitim turu** yürütür ve model ağırlıklarını toplar. Bu farklılık iki yasal kör nokta yaratır:

1. **Dolaylı veri sızıntısı** – **gradient inversion** gibi saldırılar, birleştirilmiş gradyanlardan ham girdileri yeniden oluşturabilir; bu risk tipik ihlal‑bildirimi maddelerinde ele alınmaz.  
2. **Kiracı‑arası çıkarım** – Kötü niyetli bir kiracı, başka bir kiracının veri seti hakkında bilgi elde etmek için kasıtlı olarak model güncellemeleri oluşturabilir; bu durum **ortak sorumluluk** ve **adil kullanım** sorularını gündeme getirir.

Dolayısıyla, sağlam bir FLGC, teknik önlemleri sözleşmesel garantilerle birleştirmeli ve **çift‑parmaklı bir yaklaşım** sunmalıdır; bu sayede hem yasal denetçiler hem de güvenlik mühendisleri tatmin olur.

## Federated Learning Yönetişim Maddesinin Temel Unsurları

### 1. Algoritmik Şeffaflık ve Dokümantasyon

Madde, SaaS sağlayıcısının **Model Yönetişim Belgesi** (MGD) sunmasını şart koşmalıdır; bu belge federated algoritmayı, toplama yöntemini (örn. FedAvg, Secure Aggregation) ve kullanılan **gizlilik‑artırıcı teknikleri** (ör. diferansiyel gizlilik, homomorfik şifreleme) detaylandırmalıdır. Bu dokümantasyon **sürüm denetimli** olmalı ve her büyük sürümden önce tüm kiracılara erişilebilir hâle getirilmelidir. **Contractize.app madde jeneratörü**ne bir referans eklemek, güncellemelerin tüm aktif anlaşmalara otomatik olarak yansıtılmasını sağlar.

> “Sağlayıcı, her Federated Learning hizmeti için algoritmik iş akışını, toplama stratejisini ve kullanılan tüm gizlilik‑koruyucu mekanizmaları açıklayan bir Model Yönetişim Belgesi (\"MGD\") hazırlayacak ve bu belgeyi maddi bir değişiklik