Küçük ekipler için Governance: kurumsal formalizm yerine her yapay zekâ kullanımı için bir sayfa

Küçük bir kuruluş iki kötü tasvir arasında seçim yapmak zorunda değildir. İlk tasvir, üretken yapay zekâ kullanımının ancak büyük bir Governance programı, komite, politika el kitabı ve özel yazılımla sorumlu olacağını söyler. İkincisi, metin üretecinin yalnızca bir yazma aracı olduğunu ve bu nedenle özel bir karara gerek olmadığını söyler. İkisi de iş hayatına uymaz. Beş kişilik bir işletme kurumsal formalizmi yeniden kuramaz. Ancak belirli bir hizmetin ne için kullanılacağına, hangi bilgilerin içine girebileceğine, bir taslağı kimin inceleyeceğine, kimin itiraz edebileceğine ve denemenin ne zaman biteceğine karar verebilir.

Bu makale bunun için küçük ve görünür bir biçim önerir: her yapay zekâ kullanım durumu için bir Use-Case-Card. Bu, bir Tool için genel izin ya da “etik yapay zekâ” etiketi değildir. Kesin biçimde sınırlandırılmış bir faaliyet için kısa bir çalışma anlaşmasıdır. Odakta tamamen kurgusal bir örnek vardır: küçük bir bina hizmetleri işletmesi, iç iş raporlarının ilk taslakları için üretken yapay zekâ kullanmayı değerlendirir. Girdi olarak yalnızca genel, kişisel olmayan iş notları öngörülür. Bir rapor işletme kaydına girmeden önce sorumlu bir kişi onu inceler ve düzenler. Yapay zekâ hiçbir şey göndermez, kişiler hakkında karar vermez ve olgular için kaynak olarak görülmez.

Örnek bilerek sıradandır. Faaliyet önemsiz göründüğünde alışkanlıklar doğar: bir not fazla geniş kopyalanır, taslak çok hızlı benimsenir veya zaman baskısıyla inceleme atlanır. İyi Governance her hatalı kararı önlemez. Kararı, kontrolü ve durdurmayı küçük bir ekibin günlük işte gerçekten uygulayabileceği kadar somutlaştırır.

Başlangıç noktası: bir Tool için izin değil, bir eylem hakkında soru

Soru “Bu yapay zekâ Tool'unu kullanabilir miyiz?” değildir. Bir hizmet zararsız bir yazı taslağı için uygun, müşteri kaydını işlemek için uygunsuz olabilir. Bu nedenle kart şu biçimde bir cümleyle başlar: “[Açıkça tanımlanmış görev] için [açıkça tanımlanmış rol], [açıkça tanımlanmış veri bölgesini], [inceleme ve sınırlar] yerine getirildiği sürece kullanabilir.”

Kurgusal bina hizmetleri işletmesi için bu cümle şöyle olabilir:

İç iş raporunun ilk taslağı için operasyon sorumlusu, genel ve kişisel olmayan iş notlarıyla onaylanmış bir üretken metin sistemini kullanabilir; ancak yetkin bir kişi her taslağı iş raporu olarak dosyalanmadan önce inceler, düzeltir ve onaylar.

Bu cümle bile önemli soruları açık bırakır: “Genel” sayılan nedir? Kim yetkindir? Notlar çelişirse ne olur? Bu açıklık kusur değildir. Kart her düşünülebilir riski tahmin etmek zorunda değildir. Ekibin karar verdiği veya durduğu yerleri işaretlemelidir.

Bu nedenle yapay zekâ kullanılmayan çalışma biçimi de aynı kartta yer alır. Örnekte operasyon sorumlusu raporu standart bir şablondan kendisi yazar veya bir meslektaşına okutabilir. Bu karşılaştırma sembolik bir yükümlülük değildir. Gerçekçi bir alternatif olmadan “zaman tasarrufu” kolayca yalnızca bir iddia olur. Ekip Pilot öncesinde hangi işin gerçekten ortadan kalktığını ve hangi işin eklendiğini kaydetmelidir: notları temizlemek, çıktıyı incelemek, hataları düzeltmek, sürümü dosyalamak. İnceleme iyi bir şablondan daha çok zaman alıyorsa, kullanmamak makul bir sonuçtur.

Kurgusal örnek: taslaklar, otomatik kayıtlar değil

Kurgusal bina hizmetleri işletmesi küçük ticari mülklerin bakımını yapar. Bir görevden sonra sorumlu uzman şunu not edebilir: “Filtre değiştirildi; görsel kontrol tamamlandı; malzeme stoğu kontrol edildi; sonraki randevu plana göre.” Bu maddelerden, yapılan işleri ve açık noktaları anlaşılır biçimde kaydeden bir iç rapor oluşturulacaktır.

İsimler, iletişim bilgileri, erişim kodları, kesin mülk adresleri, fotoğraflar, serbest müşteri mesajları, çalışan bilgileri, sağlık verileri, uyuşmazlıklar veya sözleşme belgeleri girilmemelidir. Sistem yeni olgular icat etmemeli, süreleri yorumlamamalı, hizmetleri faturalamamalı veya raporu kendisi müşteri portalına koymamalıdır. Bu sınırlar, hizmetin “güvenli” olduğu iddiasından çıkmaz. Seçilmiş görev sınırından çıkar: genel bir taslak için genel notlar yeterlidir.

Olası iş akışı şöyledir:

1. Operasyon sorumlusu izin verilen notları belirlenmiş bir giriş formuna aktarır. 2. Sistem iç yapıya göre bir taslak üretir: yapılan iş, açık noktalar, çözümlenmemiş bilgiler. 3. Adı belirlenmiş inceleyici uzman her ifadeyi notlarla karşılaştırır, siler veya ekler. 4. Yalnızca incelenmiş sürüm iç rapor olarak dosyalanır. Taslak sürüm yanlışlıkla yetkili kayıt olarak kalmaz. 5. Belirsizlikte, makul bir şey görünene kadar tekrar Prompt yazılmaz. Uzman durumu sorumlu kişiyle açıklar veya açık olarak kaydeder.

İş akışı yapay zekânın sorumluluğunu almaz; yapay zekânın zaten sorumluluğu yoktur. Sorumluluğu insanlara ve rollere atar. Notu oluşturan kişi, notun mesleki temelinden sorumludur. İnceleyen kişi raporu onaylamaktan sorumludur. Yönetim sınırlı kullanımın sürüp sürmeyeceğinden sorumludur. Bir hatayı fark eden kişinin, sebebin algoritma olduğunu önce kanıtlamak zorunda kalmadan bildirim yapabileceği bir yol gerekir.

Veri bölgeleri: küçük tutun, görünür kılın

“Hiç hassas veri yok” günlük iş için fazla belirsizdir. Küçük ekipler az sayıda veri bölgesi ve açık örneklerle daha iyi çalışır. Bu örnek için dört bölge yeterlidir:

Bölgeler veri koruma analizinin veya sözleşme incelemesinin yerini tutmaz. Bunlar pratik ön ayırmadır. Gücü, girdi öncesinde işlemeleridir: bir kişi metni kopyalamadan önce “kırmızı”yı görebilir. Sınırı da açıktır: görünüşte genel bir cümle bağlamda tanınabilir olabilir. Bu yüzden “şüphede girme, önce açıklığa kavuştur” kuralı tam liste yanılsamasından daha önemlidir.

Kart taslaklara ne olduğunu da kaydetmelidir. Prompt loglanıyor mu? Metin çıktıları sağlayıcıda saklanıyor mu? Yönetim veya eğitim ayarları var mı? İçeride hangi saklama süresi geçerli? Bu sorular sözleşme, konfigürasyon ve sağlayıcıyla değişir. Kart bu nedenle bir günün durumunu kalıcı izne dönüştürmemelidir.

Felsefi mercek: sorumluluk paylaşılır, sulandırılmaz

Iris Marion Young, Responsibility for Justice eserinde toplumsal bağlantı modelini açıklar. Bu model yapısal ilişkilere dikkat çeker: zarar ve adaletsiz sonuçlar çoğu kez birçok olağan eylem, kural ve iş bölümüyle ortaya çıkar; sorumluluk da yalnızca geriye bakıp tek bir suçlu kişi aramakla tükenmez. Kurgusal yapay zekâ kullanımı için mercek olarak farklı bir soru sormaya yardım eder. “Metin üreteci hata yaparsa suç kimde?” değil; “Hangi roller, teşvikler ve rutinler bizi bu hata olasılığına bağlar ve bunlarda neyi değiştirebiliriz?”

Bu, Young'ın önerilen modeli doğrulaması değildir. Onun teorisi ne bir Use-Case-Card ne de onay formülü sunar. Ancak iki kaçış yolunu engeller. İlki, yapay zekânın eylemde bulunduğunu ve bu nedenle kimsenin sorumlu olmadığını söyler. İkincisi, diğer kişiler veri kurallarını, zaman hedeflerini, satın almayı ve dosyalama biçimini belirlemiş olsa da yalnızca son inceleyenin sorumlu olduğunu söyler. Toplumsal bağlantı görevleri rol ve etkiye göre dağıtır; ama onları belirsiz bırakmaz.

Kurgusal işletme için bu, yönetimin inceleme isteyip bunun için zaman ayırmaması gerektiği anlamına gelir. Operasyon sorumlusu belirsiz veri kuralıyla yalnız bırakılmamalıdır. İnceleyen uzman, engel sayılmadan eleştirel bir takip sorusu sorabilmelidir. Etkilenen kişi veya meslektaş hata ve itiraz bildirebilmelidir. Paylaşılan sorumluluk, her rolün somut ve yapılabilir bir görevi olduğu; hiçbir rolün Tool'a işaret ederek görevini devredemeyeceği anlamına gelir.

Bu mercek bir amaç çatışmasını da görünür kılar. Daha hızlı raporlar iç genel bakışı iyileştirebilir ve teknik iş için zaman açabilir. Daha fazla inceleme zaman alır; küçük işletmelerde zaman azdır. Ancak zaman baskısı, ekonomik yarar yönetimde kalırken yanlış belgeleme riskleri müşteriler, çalışanlar veya tek tek inceleyenlerde kaldığında nötr değildir. Anlaşılır durdurma kuralı olan sınırlı Pilot bu nedenle bürokratik süs değildir. Bu dağılımı görünür ve değiştirilebilir kılmanın yoludur.

K merkezde: bir kartı taşıyan dört adım

K, bu makaledeki merkezi, kullanıcı tarafından geliştirilmiş danışma ve Governance modelidir. Temel döngüsünün dört adımı vardır: Exploration → Reflection/Analysis → Decision/Recommendation → Feedback/Evaluation. Ne sertifikalı bir kontrol sistemi ne de kararın etik veya hukuken doğru olduğunun kanıtıdır. Tekrarlanabilir bir görüşme ve karar biçimi yaratır.

Exploration aşamasında ekip terimleri büyüsünden arındırmalıdır. “İş raporu” yalnızca iç hatırlatıcı veya faturalar, sorumluluk soruları ve müşteri iletişimi için temel olabilir. Kart sorusu gerçek kullanım yolunu söylemelidir. Kurgusal Pilot'ta yalnızca iç taslağa açıkça izin verilir. Rapor daha sonra fatura, sözleşme veya uyuşmazlık açıklaması için kullanılacaksa yeni değerlendirme başlar; eski kart buna uzanmaz.

Reflection/Analysis değerleri birbirine karşı hesaplayan bir formül içermez. Ancak en güçlü karşı görüşü adil biçimde kurmayı zorunlu kılar: küçük ekipler uzun tartışmaları ve çift belgelendirmeyi zor karşılar. Her yazma yardımına kapsamlı dosya yüklemek ya kullanmaktan vazgeçmeyi ya da gizli gölge kullanımı teşvik eder. Bu eleştiri gerçek bir noktaya dokunur. Kimsenin okumadığı ve yalnızca görünüş için olan kart uygulamayı kötüleştirir.

Yanıt incelemeyi bırakmak olamaz. Belgelendirme iş akışındaki bir karara hizmet etmelidir. Kullanım durumu başına bir sayfa, bir rolün hareket etmek için ihtiyaç duyduğu bilgiyi içerir. Komiteyi sahte bir küçültmeyle değiştirmez. Küçük ekipte aynı kişiler çoğu kez birden fazla rolde görünür. Önemli olan etkileyici organizasyon şeması değil, “Tool'u satın alma”, “girdiyi onaylama”, “çıktıyı inceleme”, “çatışmada durdurma” işlerinin görünmeden birbirine karışmamasıdır.

Örnekteki Decision/Recommendation, “yapay zekâya izin verildi” değildir. Şöyle olabilir: altı haftalık Pilot, haftada en fazla on rapor taslağı, yalnızca Yeşil veri, dış iletişim yok, her zaman uzman incelemesi ve haftalık kısa değerlendirme. Yönetim inceleme için zaman sağlar. Operasyon sorumlusu belirsizlikte durabilir. İnceleyen uzman taslağı reddedebilir. Belirlenmiş iletişim rolü çalışanların itirazlarını toplar. Bu kurallar somut oldukları için gözden geçirilebilir.

Feedback/Evaluation, soyut “yapay zekâ kalitesini” değil, kullanımı sorar. Veri bölgelerine uyuldu mu? Kaç ifade düzeltildi ve bunlar ne tür hatalardı? İnceleyenler taslağı gerçekten okudu mu, yoksa yalnızca onayladı mı? Kural pratik olmadığı için aşıldı mı? Zaman tasarrufu ek incelemeyi makul biçimde dengeledi mi? Küçük hata sayacı tek başına bunu yanıtlamaz, fakat mesleki gözden geçirmeye neden olabilir. Ekip başarılı taslakların yanında karşı örnekleri ve şikâyetleri de kaydeder.

Ayrı: beş adımlı K vaka senaryosu genişletmesi

Daha ayrıntılı vaka çalışması için K'nin beş adımlı senaryo genişletmesi vardır: Exploration, Reflection, Decision, Implementation/Pilot, Final Evaluation/Optimisation. Bu, dört adımlı temel değildir. Ek değeri, deneme başlatmayı ve son değerlendirmeyi ayrı çalışma aşamaları yapmasıdır.

Bina hizmetlerinde genişletme, kararı Pilot'tan ayırır. Ekip önce veri bölgelerini, inceleme adımlarını, erişimi ve durdurma kurallarını belirler; sonra Workflow'u bu koşullarda dener. Son değerlendirme kartın değiştirilmesine, Pilot'un uzatılmasına veya kullanımın bitmesine karar verir. Bu ayrım “bir deneyelim” sözünün sessiz kalıcı izne dönüşmesini önler.

Use-Case-Card: günlük işte kullanılan bir sayfa

Aşağıdaki yapı bir sayfaya sığar. Bilerek her kuruluş için şablon veya her hukuk alanı için tam kontrol listesi değildir. Sınırlı karar için çalışma nesnesidir.

Use-Case-Card UCC-01: iç rapor taslakları (kurgusal örnek)

Kart erişilebilir olmalıdır: girdinin hazırlandığı yerde ve çalışanların anlayacağı bir sürümde. Bir kişi kartı değiştirebilir, ancak değişiklik için tarih, neden ve yeniden onay gerekir. Aksi halde sağlayıcı güncellemesi veya sessiz süreç değişikliğinden sonra eski kart yanlış güvence olur.

Log bilerek dardır. Hangi Workflow'un hangi sürümde çalıştığını ve taslağa ne olduğunu açıklayabilmelidir. Prompt'ların, personel davranışının veya müşteri verilerinin gölge arşivini yaratmamalıdır. “Hatayı anlamak için neyi bilmeliyiz?” sorusu “Neleri kaydedebiliriz?” sorusundan iyidir.

İtiraz, geri bildirim ve karar gücü

Küçük ekiplerde itiraz kanalı anonim veya teknik olarak karmaşık olmak zorunda değildir; erişilebilir ve olumsuz sonuç olmadan kullanılabilir olmalıdır. Kurgusal işletmede her çalışan hata veya kaygıyı operasyon sorumlusuna, inceleyen uzmana veya belirlenmiş iletişim rolüne bildirebilir. Bildirim tarih, kısa açıklama ve kararla kayda geçer: hemen durdurmak, sonraki Review'da ele almak veya uzman sorusu olarak iletmek. Workflow'dan sorumlu kişi, bildirim kendi incelemesinin kalitesiyle ilgiliyse kendi kararını tek başına kapanmış sayamaz. Yönetim sürdürme ve kaynaklara karar verir, ama tek raporun teknik doğruluğuna karar vermez.

Dışarıdaki etkilenen kişilerin de duyulmak için Tool'a erişmesi gerekmez. Bir müşteri daha sonra dosyalanmış raporda hata bulursa, rapor iş ürünü olarak düzeltilir, neden incelenir ve gerekirse Pilot kartı yeniden değerlendirilir. Usul çatışmasız çözüm vaat etmez; geri bildirimin “teknik sorun” ile “insan hatası” arasında kaybolmasını önler. Ekip ayrıca hangi geri bildirimin hemen düzeltmeye, hangisinin örüntü incelemesine yol açtığını ve Pilot'u bitirmeye kimin karar verdiğini kaydetmelidir. Böylece itiraz hakkı dostça dipnot değil, işletme görevi olur.