Yapay Zeka Belgeyi Düzenlediğinde, Değişikliğin Sahibi Kimdir?

Bir belge, bir cümleyi kim değiştirdiğini gösterebilir, ancak şimdi ne dediğini kimin onayladığını tahmin etmenizi bırakır. Yapay zeka ve insanlar ifadeyi her ikisi de revize ettikten sonra, son düzenlemenin yanında bir isim bulunması bu soruya yanıt vermez.

İki iş günü içinde yanıt vaat eden varsayımsal bir destek politikasını düşünün. Bir yapay zeka yeniden yazımı bir iş günü önerir. Bir insan editör bunu üç iş gününe değiştirir ve bir ekip lideri belgeyi onaylar. Yayınlanan dosya sıradan görünür. Tarihçesi, reddedilen bir öneri, bir insan revizyonu ve müşterilerin ne beklemesi gerektiğiyle ilgili bir kararı içerir.

Bu değişikliğin sahibi kimdir? Bunları yayınlama sorumluluğunu atamadan önce katkıları ayırmamız gerekir. Aksi takdirde, “AI destekli” ifadesi, son ifadenin nasıl ortaya çıktığı hakkında çok az şey söyler.

Düzenlemeyi Karardan Ayırın

Microsoft’un 29 Eylül 2025 tarihli duyurusu, Agent Mode in Word, Frontier dağıtımını başlatıyordu ifadesiyle, sohbet tabanlı düzenlemeyi belge uygulamasına, başlangıçta web üzerinde, yerleştirdi. Bu duyuru, dağıtım tarihini belirler, ancak belirli bir kuruluşun ortaya çıkan değişiklikleri nasıl gözden geçirdiğini belirlemez.

Bu şekilde yapay zeka kullanan bir ekip için yararlı başlangıç noktası, düzenlemeyi talep eden kişidir. O kişiyi, düzenlemeyi üreten yazılımdan ayrı kaydedin. Birisi öneriyi yeniden yazar ise, o katkıyı da koruyun. Onay, gözden geçirenin gerçekten gördüğü sürüme eklenen başka bir eylemdir.

Bu roller, her görev için ayrı kişiler gerektirmez. Bir editör yeniden yazım talep edebilir, revize edebilir ve onaylama yetkisine sahip olabilir. Ayrım hâlâ önemlidir: daha kısa bir paragraf istemek, yazılımın yaptığı her değişikliği onaylamak anlamına gelmez.

W3C PROV data model, bu geçmişi tanımlamak için bir sözlük sağlar. Belgeler ve bunların sürümleri varlıklar olarak; düzenlemeler ve onaylar aktiviteler olarak; insanlar ve yazılım ajanlar olarak temsil edilebilir. Model, bunlar arasındaki ilişkileri tanımlar. Hukuki sorumluluğu belirlemez veya yazar alanında görünen kişinin kimliğini doğrulamaz.

Teknik yazım veya destek materyali içeren AI destekli belge iş akışları için bu, her kaydedilen eylemin neyi temsil ettiğini tanımlamak anlamına gelir. Bir yorum, tartışmaya yapılan katkıyı belirler. Bir onay, belirli bir ifadeyi yayımlama iznini tanımlamalıdır. İkisine aynı genel “incelendi” durumunu vermek, kaydı daha az yararlı kılar.

Değiştirilen Tek Bir Paragraf İçin Kayıt Oluşturun

Yanıt süresi örneğine geri dönelim. Yeniden yazım üretmeden önce, onaylanmış iki iş günü ifadesini ve belge sürümünü koruyun. Önerilen değişikliğe bir tanımlayıcı verin, ardından sonraki revizyonları ve kararları ona bağlayın.

Aşağıdakiler, uydurulmuş tanımlayıcılarla bir örnek tasarımdır. Bu, test edilmiş bir ürünün çıktısı ya da her belge aracının desteklediği bir şema değildir.

İnsan revizyonu onu değiştirdikten sonra AI önerisini tutun. Kayıt yalnızca son üç iş günü ifadesini tutarsa, sonraki bir gözden geçiren bu girdiden önceki öneriyi yeniden oluşturamaz. Reddedilen değişiklikler, yayınlanan metinde yer almasalar da tarihin bir parçasıdır.

NIST’in Temmuz 2024 Generative AI Profile profili, kaynak bilgisini, içeriğin kökeni ve geçmişi, değişiklikler ve kaynaklar dahil olmak üzere tanımlar. Ayrıca, kaynak süreçleri ile insan gözden geçirenler arasındaki ilişkiyi değerlendirmeyi önerir. Tablo, bu fikri bir belge iş akışına uygular; bu bir NIST sertifikasyon kontrol listesi değildir.

Bu kaydı belge sistemi içinde ya da bağlı bir depoda tutabilirsiniz. Hangi yöntemi seçerseniz seçin, yayınlanan sürümle ilişkiyi, birinin orijinal editörün hafızasına dayanmak zorunda kalmadan alabilecek kadar açık hale getirin.

Devirde Ne Kaldığını Kontrol Edin

Dışa aktarılan bir dosya kendi denetimini hak eder. Düzenleme sırasında mevcut olan geçmiş, alıcının inceleyebileceği şeyden, uygulamaya, formata ve dışa aktarma ayarlarına bağlı olarak farklılık gösterebilir. Her PDF’nin atıf kaybettiğini ya da görünür yorumların korunmasının her inceleme kararını koruduğunu varsaymayın.

Microsoft’un mevcut Copilot ile düzenleme belgeleri şunu belirtiyor: Değişiklikler, bu özellik etkinleştirildiğinde Track Changes’i saygı gösterir. Bu faydalı bir işlevsellik. Ancak, tam onay geçmişinizin her sonraki dönüştürme veya devretme işleminde korunacağını ortaya koymuyor.

Ekibinizin gerçekten kullandığı yolu test edin. Örnek belgeyi inceleme ve dışa aktarma sürecinden geçirin, ardından tutulan kayıtları kullanarak kabul edilen revizyonu ve onaylayanı geri almaya çalışın. Yayınlanan dosya bu geçmişi taşıyamıyorsa, başka bir yerde kontrollü bir kayıt tutun ve aralarındaki bağlantıyı koruyun.

Daha az net durumlar da dikkat gerektirir. Bir önerinin yalnızca bir kısmını kabul edin ve kaydın ne dediğini inceleyin. İki inceleyicinin aynı temel sürüm üzerinde çalışmasını sağlayın, ardından hangi değişikliklerin yayınlanan dosyaya ulaştığını belirleyin. Son olarak, onaydan sonra bölümü düzenleyin ve önceki kararın sessizce yeni ifadeyi onay haline getirip getirmediğini doğrulayın.

Görüntülenen yazar adı, kimliğe güvenmeden önce kimliği doğrulanmış bir hesaba izlenebilir olmalıdır. Benzer şekilde, bir dosya özeti yayınlanan varlığı tanımlamaya yardımcı olabilir, ancak yanıt süresi taahhüdünün doğru olup olmadığını söyleyemez. Bunlar ayrı denetimlerdir ve inceleme süreciniz bu ayrımı korumalıdır.

Yayınlamadan Önce Onay Sınırını Belirleyin

Bir başlığın biçimlendirmesini değiştirmek ile bir müşteri taahhüdünü değiştirmek aynı inceleme yollarını izlemek zorunda değildir. Hangi düzenlemelerin yerleşik bir politika kapsamında ilerleyebileceğine ve hangilerinin belirlenmiş bir kişinin onayına ihtiyaç duyduğuna karar verin. Bu seçim, değişikliğin belgeyi kullanan kişiler üzerindeki etkisini yansıtmalıdır.

Burada açık AI karar yetkisi argümanı pratik bir hâl alır. Örneğimizde, birinin üç iş günü yanıt taahhüdünü onaylama yetkisine sahip olması gerekir. Dosyayı düzenleme izni tek başına bu yetkinin kanıtı olarak değerlendirilmemelidir.

İnceleyiciye karar vermesi için yeterli bağlam sağlayın. Orijinal ve önerilen ifadeyi araya giren insan revizyonlarıyla birlikte gösterin. Çözülmemiş çatışmaları görünür kılın ve yayınlanması amaçlanan sürümü belirleyin. Sadece düzenlenmiş son paragrafı gören bir inceleyici, yanıt süresinin değiştiğini fark etmeyecek bir durumda kalabilir.

İş akışını kullanıcılara devretmeden önce sürümün kime ait olduğunu netleştirin. Bu kişi her düzenlemeyi yapması gerekmez, ancak gerekli incelemenin gerçekleştiğini ve yayınladığı dosyaya uygulandığını kanıtlayacak bir yola sahip olmalıdır. Atamayı belirsiz bırakmak, belge yayına hazır olduğunda tartışmalı bir değişikliği çözmeyi zorlaştırır.

Bu, her gizli istemi süresiz olarak saklamayı gerektirmez. Kuruluşunuzun erişim ve saklama politikasına uygun olarak kararı açıklamak için gereken kanıtı tutun. Model sürümü bilgisi mevcut değilse, sınırlamayı kaydedin. Kullanışlı bir geçmiş, eksik bilgiyi ortaya çıkarmalı, sistemin hiç yakalamadığı bir detay seviyesini ima etmemelidir.

Sadece Hesaplayabildiğiniz Sürümü Yayınlayın

Önemli bir değişikliği yayınlamadan önce, kayıttan geriye doğru izlemeye çalışın. Orijinal öneriyi bulun, insan editörün neyi değiştirdiğini belirleyin ve o revizyonu kabul eden kararı geri alın. Ardından onaylı sürümü teslim edilen dosyayla karşılaştırın.

Bu bağlantı eksikse, inceleme değişikliğini bekletin. Belgenin “onaylandığını” hatırlayan birinin, hangi ifadeyi onayladığını kanıtlaması yeterli değildir.

Bir editör, AI tarafından üretilen her öneriye atanmış olmadan katkısını açıklayabilmelidir. Yayın sorumlusu, tam olarak neyi yetkilendirdiğini bilmelidir. İnsanları, değişikliklerin nasıl yapıldığını güvenilir bir şekilde inceleme imkanı olmadan bu değişikliklerin arkasında durmaya zorlayamayız.