Konferans için yapay zekâ özeti: veri sızıntısı riski nasıl azaltılır

Konferansın yapay zekâ özeti için pratik bir süreç: hangi toplantılar kaydedilmemeli, katılımcılar nasıl bilgilendirilmeli, sonuç nasıl kontrol edilmeli ve kaynak dosyalar nasıl silinmeli.

Risk kontrollü bir konferans yapay zekâ özeti, konuşmacının ilk kelimesinden önce başlar. Ekip önceden hangi oturumların kaydedilebileceğine, sisteme tam olarak neyin gireceğine, sesi ve transkripti kimin alacağına, bunların ne kadar saklanacağına ve bir katılımcı reddettiğinde botun yerine neyin kullanılacağına karar verir. Bu önlemler sızıntıyı tamamen ortadan kaldırmaz, ancak gereksiz kopyaların ve tartışmalı tutanak sürümlerinin sayısını azaltır.

Biz Aventura olarak yapay zekâ özetini konferansın üretim sürecinin bir parçası olarak görüyoruz. Önce programı ve teknik kaydı birbirine bağlıyoruz. Ardından bir yürütücü, bir editör ve nihai belgenin sahibini atıyoruz. Müşterinin hukuk ekibi ve bilgi güvenliği birimi, işleme dayanağını ve iç kuralları onaylar.

Yapay zekâ özeti tam olarak neyi oluşturur?

Kısaca: Yapay zekâ özeti birkaç veri katmanından oluşur. Sistem orijinal kaydı, transkripti, çalışma sonuçlarını ve hizmet günlüklerini saklayabilir. Her katman için kendi amacı, sahibi, erişimi ve saklama süresi gerekir. Onaylanmış tutanak, otomatik olarak makine özetiyle eş tutulmamalıdır.

İlk adım, işlevi verilere ayırmaktır. Organizatör çoğu zaman yalnızca ana hatları içeren düzenli bir sayfa görür. Bunun arkasında orijinal ses, konuşmanın tam metni, zaman damgaları, katılımcı kimlikleri, takvim etkinliği, sohbet mesajları ve harici işleyicilerdeki kopyalar kalabilir.

İçerik platforma ve ayarlara bağlıdır. Bir hizmet yalnızca metni saklar. Bir diğeri belgeyi takvime ekler, kurumsal arama için toplantı geçmişini dizinler veya silinen dosyayı kalıcı olarak temizlenene kadar saklar. Bu nedenle «özet nerede duruyor» sorusu fazla dardır.

Biz süreç pasaportuyla başlıyoruz. Bunda girdi verilerini, ara materyalleri, nihai belgeyi ve her alıcıyı belirtiyoruz. Bu şema, yapay zekâ asistanı için konferans programı hazırlığını tamamlar: program etkinliğin yapısını açıklar, kayıt pasaportu ise canlı konuşmanın verilerinden sorumludur.

Bot bağlanmadan önce toplantıların sınıflandırılması

Toplantılar en az üç sınıfa ayrılmalıdır: kayda izin verilenler, ayrı bir karar gerektirenler ve otomatik bağlantı için yasak olanlar. Botun varsayılan olarak tüm takvime girmesine izin verilmemelidir. Toplantı sahibi, davet gönderilmeden önce sınıfı belirler ve platform ayarları bu kararı sabitler.

Toplantının adı her zaman içeriği ortaya koymaz. «Haftalık durum» bir çalışanın sağlık durumuna, disiplin konusuna, sistem açığına veya anlaşma koşullarına geçebilir. Bu nedenle yasaklı kelimeler listesi tek başına yeterli değildir. Belirgin durumları ayıklamaya yardımcı olur, ancak organizatörün kararının yerini tutmaz.

Yasaklı sınıfa genellikle personel soruşturmaları, hukuki danışmanlıklar ve güvenlik olaylarının görüşülmesi girer. Bunlara tıbbi bilgiler, kamuya açık olmayan anlaşmalar ve erişim sırları da eklenebilir. Liste, sektör ve veri koruma gereklilikleri dikkate alınarak müşteri tarafındaki sorumlular tarafından onaylanır.

Koşullu sınıf için toplantı öncesinde açık bir soru gerekir: kayıt yapılabilir mi, hangi katılımcılar davetli, dış taraflar var mı, görüşmeden sonra verilere ne olacak. Karar verilmemişse bot bağlanmaz. Sekreter manuel not kullanır.

Fireflies, toplantı atlama kurallarını addaki kelimelere, katılımcıya ve alan adına göre tanımlamaya olanak tanır. Microsoft Teams hassas toplantılar için şablonları ve politikaları destekler. Teknik kısıtlamalar, kurumsal sınıflandırmayı tekrarladığında ve ondan ayrı var olmadığında faydalıdır.

Kayıttan önce katılımcılar nasıl bilgilendirilir?

Katılımcıları iki kez uyarıyoruz: davette ve kayıt başlamadan hemen önce. Mesajda amaç, oluşturulacak materyaller, alıcılar, saklama süresi ve itiraz etme yöntemi belirtilir. Platformun sistem bildirimi işlemi kaydeder, ancak sürecin açıklamasının ve müşterinin kayıt için yasal dayanak kararının yerini tutmaz.

Bildirimin davette ve kayıt sayfasında yer alması daha iyidir. Böylece dış konuşmacı veya partner, salona girmeden önce kayıttan haberdar olur. «Etkinlik kaydedilebilir» ifadesi fazla belirsizdir. Tam bir transkript oluşturulup oluşturulmayacağını, taslağı kimin göreceğini ve nihai sonucun nerede yayınlanacağını açıklamaz.

Başlamadan önce sunucu kuralları kısaca tekrarlar. Microsoft Teams'de yönetici, kayıt ve transkripsiyon için açık onay talep edebilir. Google Meet, kayıt, transkripsiyon ve otomatik notlar işlevi hakkında ayrıca bildirimde bulunur. Reddetme durumunda davranış platforma bağlıdır, bu nedenle yedek senaryo önceden test edilir. Müşteri, avukatıyla birlikte onayın gerekip gerekmediğini ve kayıt için hangi yasal dayanağın uygun olduğunu belirler.

Ret, herkesin gözü önünde bir tartışmaya dönüşmemelidir. Organizatör, botu nasıl kaldıracağını, kaydı nasıl kapatacağını veya toplantıyı manuel moda nasıl alacağını önceden bilir. Bir katılımcı itiraz ettikten sonra görüşme hizmet kaydı olmadan devam eder ve sekreter yalnızca üzerinde anlaşılan kararları kaydeder.

Konferans, forum ve seminerlerin hazırlanmasında bildirimi katılımcının genel yolculuğuna dahil ediyoruz: davet, kayıt, çevrimiçi odaya veya salona giriş, sunucunun duyurusu ve nihai bilgilendirme e-postası. Böylece metin, teknik ekibin gerçekte yaptıklarıyla çelişmez.

Roller ve veri sahipleri

Projelerimizde önceden beş rol atarız: toplantı sahibi, kayıt operatörü, platform yöneticisi, editör ve silmeden sorumlu kişi. Bir kişi görevleri birleştirebilir, ancak ekip yine de sorumluluğu kayıt altına alır. Bu, hatalı bir özeti hızla durdurmaya, gereksiz erişimi geri çekmeye ve dosyaların silindiğini doğrulamaya yardımcı olur.

Toplantı sahibi, kaydın gerekli olup olmadığına ve hangi sonucun resmi sayılacağına karar verir. Operatör, işlevi yalnızca bildirimden sonra başlatır. Yönetici ayarları, erişimi ve saklama süresini belirler. Editör, ana noktaları bağlamla karşılaştırır. Silmeden sorumlu kişi, dosyaların silindiğini ve geçici erişimlerin süresi içinde kapatıldığını kontrol eder.

Büyük bir konferansta roller oturumlara göre dağıtılır. Genel açılış oturumları tek bir standarta sahip olabilir, kapalı yuvarlak masalar başka bir standarta. Konuşmacı ofisi, konuşmacıların kısıtlamalarını önceden toplar. Teknik koordinatör, hangi kanalların kaydedileceğini ve hangilerinin yönlendirmeden çıkarılacağını bilir.

Süreç pasaportunda alıcıları da işaretleriz. Tam transkript tüm katılımcılar için nadiren gereklidir. Bir yönetici için onaylanmış kararlar yeterli olabilir. Editörün kaynağa geçici erişime ihtiyacı vardır. İletişim ekibi için ise yalnızca konferans sonrası içerik için onaylanmış bölümler.

Kurumsal ayarlar nasıl seçilir?

Konferanstan önce, müşterinin BT departmanıyla birlikte tüm oturumlar için ortak ayarları belirliyoruz. Sistem sahibi; kaydı kimin başlatacağını, açık onay gerekip gerekmediğini, hangi materyallerin saklanacağını, bunlara kimlerin erişebileceğini ve ne zaman silineceğini tanımlar. Tek bir kural seti, gereksiz kopya ve oturumlar arası tutarsızlık sayısını azaltır.

Yeni kullanıcılar için botun otomatik bağlanmasını yasaklayarak başlayın. Ardından izin verilen senaryoları açın: belirli bir takvim, toplantı şablonu, organizatör grubu veya program sınıfı. Dış katılımcılar için yapay zekâ işlevlerinin başlatılmasını sınırlamak ve erişimi yalnızca sahibin kararından sonra vermek faydalıdır.

Microsoft Teams'de kayıt ve transkripsiyon, yönetici politikaları, şablonlar ve hassas toplantıya özel ayarlarla yönetilir. Copilot ise politikalar ve şablonlarla düzenlenir, hassasiyet etiketiyle değil. Araç seti platformdan platforma farklılık gösterdiği için kontrol listesi tarife adına göre değil, ihtiyaç duyulan kontrole göre oluşturulur.

Platform denetimi sözleşmeyi ve verilerin fiili akış yolunu kapsar. Müşterinin, verilerin nerede işlendiğini ve hizmetin bunları hangi yüklenicilere aktardığını öğrenmesi gerekir. Geçici ve yedek kopyalar ile materyallerin modellerin iyileştirilmesi için kullanımı ayrıca kontrol edilir. Rusya vatandaşları için yerelleştirme ve sınır ötesi aktarım, müşterinin hukukçusu ve bilgi güvenliği departmanı tarafından değerlendirilir.

Ses kaydı, transkript ve sonuçlara erişim

Proje için, kaynaktan nihai belgeye doğru ilerledikçe erişim haklarını daraltıyoruz. Tam kaydı sınırlı bir süre için küçük bir çalışma grubu alır. Transkript editörlere gerekirken, onaylanmış sonuç ayrı bir listeye göre dağıtılır. Takvim ve ortak klasör hakları otomatik olarak tüm materyallere geçmemelidir.

Klasör için tek bir ortak bağlantı kullanışlıdır ancak farklı risk düzeyindeki materyalleri birbirine karıştırır. Yalnızca nihai karar listesine ihtiyaç duyan bir katılımcının tüm konuşmaları ve tanıma hatalarını görmesi gerekmez. Video kurgu yüklenicisi, komşu oturumun kapalı toplantılarına erişim almamalıdır.

Takvimi ayrıca kontrol edin. Bazı platformlar etkinliğe not ekler veya belgeyi organizatöre ve işlevi açan kullanıcıya gönderir. Takvim erişimi bir asistana, ortak gruba veya hizmet hesabına devredilebilir. Bu, editörün farkına varmadan alıcı çevresini genişletir.

Hibrit etkinliklerin organizasyonunda uzaktan konuşmacılar, paralel odalar ve harici platformlar da eklenir. Her kanal için ayrı bir tanımlayıcı, izin verilen işlevler listesi ve hedef klasör bulunması faydalıdır. Böylece kapalı yuvarlak masa toplantısının kaydı genel materyal çıktısına karışmaz.

Proje için şu erişim matrisini oluşturuyoruz:

Tutanakların insan tarafından kontrol edilmesi

Yapay zekâ özeti, atanan kişi kararları ve görevleri kaynakla karşılaştırmadıkça taslak olarak kalır. Editör ayrıca sorumluları, son tarihleri, sayıları ve soyadları kontrol eder. Özellikle olumsuzluk ifadelerine dikkat ederiz: atlanan tek bir edat anlamı değiştirir. Kontrol, sürümün açık bir durum bilgisiyle sona erer.

Editör virgül düzelticisi gibi çalışmaz. Makine özetini transkriptle ve gerekirse ses kaydıyla karşılaştırır. Özellikle «karar verildi», «onaylandı», «taahhüt eder» ve «şu tarihe kadar» ifadelerini dikkatle kontrol eder. Bu sözcükler belgenin yönetimsel anlamını değiştirir.

NIST AI RMF, insan rollerinin tanımlanmasını ve sonuç kontrolünün belgelenmesini önerir. Bir konferans için bu basit bir zincir anlamına gelir: yapay zekâ yapıyı önerir, editör düzeltir, toplantı sahibi onaylar. Karar tartışmalıysa, olası anlama göre tahmin edilmez, katılımcılara geri gönderilir.

Tutanakta olguları ve görevleri ayırırız. Olgu, söyleneni veya gösterileni tanımlar. Görevin bir sorumlusu, son tarihi ve kararın kaynağı vardır. Varsayımlar ve fikirler ayrı bir durum alır. Bu yapı, çarpıcı bir sözün resmî tutanağa taahhüt olarak girmesi riskini azaltır.

İş verileriyle güvenli çalışma pratiği, Çalışanlar için AI Day materyalinde daha ayrıntılı ele alınmıştır. Editör için de aynı kural geçerlidir: izin verilen ortamı kullanmak ve hızlı bir düzeltme uğruna ham transkripti rastgele bir harici sohbete taşımamak.

Ses kaydı ne zaman ayrı bir risk haline gelir?

Ses ayrı bir inceleme gerektirir, ancak sıradan bir kayıtta sesin bulunması tek başına biyometri hakkında hazır bir hukuki sonuç doğurmaz. 152-FZ kapsamında belirleyici olan amaçtır: ses özellikleri kişinin kimliğini tespit etmek için kullanılıyor mu? Ad, unvan, konuşmalar ve kişiyle ilişkilendirilen transkript ise kişisel veri olarak kalabilir.

Politikada her mikrofonun "biyometri topladığını" baştan yazmamak gerekir. Tedarikçiden işlevin tanımını talep ediyor ve sistemin kayıt içindeki konuşmacıları ayırt edip etmediğini ya da kimlik tespiti için kalıcı bir ses şablonu saklayıp saklamadığını netleştiriyoruz.

Rusya Merkez Bankası, uzaktan kimlik tespiti senaryosunda sesi biyometrik kişisel veri olarak tanımlar. 152-FZ sayılı Federal Kanun, biyometrik kategoriyi kimlik tespiti için kullanılan özelliklerle ilişkilendirir. İşlevin somut nitelendirmesini, tedarikçi belgelerini inceledikten sonra müşterinin hukukçusu teyit eder.

Biyometri olmasa bile kayıt hassas içerik barındırabilir. Birleşik Krallık düzenleyicisinin hazırladığı veri koruma etki değerlendirmesinde, kayıt ve transkripsiyon için sağlık verileri, iş uyuşmazlıkları, inançlar ve diğer özel kategorilere ilişkin verilerin ortaya çıkma riski sıralanmıştır. Bu nedenle toplantının sınıfı ve içeriği, işlevin genel adından daha önemlidir.

Saklama süreleri ve silmenin teyidi

Ham kayıt, transkript, taslak özet ve onaylanmış nihai sonuç için ayrı ayrı süreler belirliyoruz. Silme düğmesi her zaman kalıcı temizlik anlamına gelmez. Çöp kutusu ve yedek kopyalar kontrol edilmelidir. Hukuki nedenlerle silme yasağı, kurumsal arama ve alıcılardaki kopyalar ayrıca dikkate alınır. Sürecin kapatılması kayıt defterine işlenir.

Her şeyi "her ihtimale karşı" saklamak, yalnızca ilk arama talebine, erişimin geri alınmasına veya bir soruşturmaya kadar kolaydır. Kopya sayısı arttıkça konuşmayı kimin gördüğünü ve nerede kaldığını kanıtlamak zorlaşır. 152-FZ'nin genel ilkesi, işlemeyi belirli bir amaca bağlamak ve bu amaca uygun saklama süresini belirlemektir. Kanunun somut uygulamasını müşterinin hukukçusu teyit eder.

İşleyiş şeması kısa olabilir: ham kayıt doğrulama için gereklidir, ardından silinir; transkript onaya kadar saklanır; nihai tutanak, müşterinin bu tür belgeler için benimsediği süre boyunca saklanır. Somut süreler başka bir örnekten alınamaz. Bunlar süreç sahipleri, hukukçu ve bilgi güvenliği birimi tarafından onaylanır.

Kurumsal platform, toplantı kayıtları, transkriptleri ve diğer materyalleri için saklama sürelerinin merkezi olarak belirlenmesine olanak tanımalıdır. Kabul testi, arayüzden silmeyi kalıcı temizlikten ayırt eder. Çöp kutusu, yedek kopyalar ve hukuki silme yasakları süreç pasaportunda yansıtılır.

Projeyi kapatmadan önce veri sahibiyle birlikte şunları kontrol ediyoruz:

1. Geçici bağlantılar ve misafir yetkileri geri alındı mı?
2. Ham kayıt çalışma klasöründen ve çöp kutusundan silindi mi?
3. Transkriptin saklama süresi doldu mu?
4. Materyal kurumsal aramadan çıkarıldı mı?
5. Nihai belgenin hakları kadrolu sahibine devredildi mi?
6. Yüklenicideki kopyalar kararlaştırılan usule göre silindi mi?
7. İstisnalar ve bunların saklanma gerekçesi kayda geçirildi mi?

AI botu olmadan manuel yedek

Manuel senaryoyu yapay zekâ işleviyle birlikte hazırlıyoruz. Sekreter, konuşmanın kelimesi kelimesine kaydı olmadan konuyu, kararı, sorumluyu, süreyi ve açık soruyu kaydeder. Bu mod, katılımcının reddetmesi, platform arızası, tanıma kalitesinin düşük olması veya kayıt yasağı durumunda devreye alınır. Ekip, bu tutanağın nerede saklandığını ve kimin onayladığını önceden bilir.

Manuel yedek, kişisel not defterinde dağınık notlar anlamına gelmez. Ekip onaylanmış şablonu ve aynı erişim sınıflandırmasını kullanır. Sonunda sekreter kararları yüksek sesle okur ve tartışmalı ifadelerin onaylanmasını ister. Toplantıdan sonra sahibi, düzeltmeler için taslak sonuçları gönderir.

Bu senaryo kötü ses koşullarında da faydalıdır. Salonda birden fazla mikrofon, gürültülü bir tartışma veya dil karışıklığı varsa makine transkripsiyonu ikna edici görünebilir ama kilit ayrıntılarda hata yapabilir. Sekreter boşlukları tahminle doldurmak yerine netleştirilmesi gereken yerleri işaretler.

Etkinliklerde fotoğraf ve video çekimi sırasında program, röportaj ve ham görüntü teslimi kayıtlarını ayrıca onaylıyoruz. AI özetini de aynı ayrıntıyla planlıyoruz: sinyal kaynağını, izin verilen oturumları, dosya sahibini, aktarım yolunu ve silme süresini belirliyoruz.

Konferans öncesi süreç kabulü

Konferans öncesinde harici bir katılımcı ve sıradan bir cihazla test toplantısı yapıyoruz. Önce bildirimi, reddi ve botun bağlanmasını kontrol ediyoruz. Toplantı bittikten sonra oluşturulan dosyaları, erişim haklarını, özet kalitesini, manuel yedeği ve ham kaynakların silinmesini inceliyoruz. Test, "işlev açıldı" notuyla değil kanıtlarla sona erer.

Toplu davetiyeler gönderilmeden önce bir deneme çalıştırması yapıyoruz. Katılımcı, gerçek etkinlikte göreceği metnin ve düğmelerin aynısını görmelidir. Farklı rolleri kontrol ediyoruz: organizatör, şirket içi katılımcı, harici konuşmacı, kurumsal hesabı olmayan misafir ve manuel mod sekreteri.

Kabul aşamaları:

1. Gerekli sınıfta bir test toplantısı oluşturun.
2. Davetiyeyi ve ön bildirimi kontrol edin.
3. Şirket içi ve harici katılımcı olarak giriş yapın.
4. Kaydı başlatın ve sistem mesajını kaydedin.
5. Bir katılımcının kaydı reddetmesini sağlayın ve yedeği devreye alın.
6. Toplantıyı bitirin ve oluşturulan materyallerin listesini toplayın.
7. Her alıcının haklarını kontrol edin.
8. AI özetini test senaryosuyla karşılaştırın ve hataları düzeltin.
9. Ham kaynağı silin ve çöp kutusunu, aramayı ve yeniden erişimi kontrol edin.
10. Sonucu, sahipleri ve açık notları kaydedin.

İş etkinliklerinin organizasyonu sırasında bu deneme çalıştırması genel teknik provanın parçasıdır. Yalnızca ses ve görüntüyü değil veri yolunu da kontrol ediyoruz: işlevi kim başlattı, katılımcı ne gördü, sonuç nereye ulaştı ve uyuşmazlık durumunda ekip süreci nasıl durduracak.

Kaynaklar

• Federal Law No. 152-FZ "On Personal Data", güncel metin, Garant sisteminde
• Rusya Merkez Bankası: yüz ve ses ile uzaktan kimlik doğrulama
• Microsoft Teams: katılımcıların kayıt ve transkripsiyona onayı
• Microsoft Teams: hassas toplantılar için kayıt ayarları
• Google Meet: kayıt, transkripsiyon ve Take notes for me
• Fireflies: kayıt kuralları ve belirli toplantıları atlama
• NIST AI Risk Management Framework 1.0
• ICO: Microsoft Teams kaydı ve transkripsiyonu için DPIA