Teams 外部 AI 會議 bot 入房要批,公司 IT 要執返權限
Tech News

Teams 外部 AI 會議 bot 入房要批,公司 IT 要執返權限

圖片:via iThome — https://www.ithome.com.tw/news/177095
TechLab 編輯部(譯)·

偵測到嘅第三方 bot 會留喺 lobby,批核權返到 organizer 手上

發生咩事

iThome 報道,Microsoft 6 月 29 日公布 Teams 新外部 bot 管控,重點好直接:偵測到第三方 AI 會議記錄 bot 想入 meeting,Teams 會先擺佢喺 lobby,開會 organizer 要明確批准,佢先入到。Microsoft 官方 blog 同 Learn docs 都確認,呢個 policy 預設係 偵測到就要批;就算原本 meeting 設咗某啲人可以跳過 lobby,偵測到嘅 bot 都仲要過呢一關。

Teams admin center 入面管理外部 bot 入會權限嘅 policy 設定畫面

圖片:Microsoft Learn

點解 Microsoft 而家先落手

AI meeting assistant 好方便,但麻煩位好現實:bot 入咗房,就等於多咗一個會記錄、轉錄、上載內容嘅參與者。Microsoft blog 提到,有人連接第三方服務後,bot 可能之後繼續自動加入其他 meeting。呢種情況喺企業環境好煩,客戶簡報、HR 傾談、財務會議,未必有人想份 transcript 跑去另一間公司嘅系統。

新 policy 實際點運作

官方 admin 文件寫明,呢套功能喺 Teams meeting policy 入面管,可以套落全公司預設 policy,亦可以按 group 或 user 做 targeted policy。選項主線有兩個:唔偵測 bot,或者偵測到就留喺 lobby 等批;後者係預設。Microsoft PowerShell 參考頁仲列出 BlockDetectedBots,即係有硬擋偵測到 bot 嘅值,不過 admin docs 主畫面暫時講得最清楚嘅仍然係「唔偵測」同「偵測後批核」,IT admin 要以自己 tenant 見到嘅 UI 同 PowerShell 為準。

organizer 唔應該變成人肉防火牆

呢度有個伏位:最後一下批核返到 organizer 手上,但 organizer 未必識分 bot 係咪可靠。官方文件都講,偵測唔一定捉得晒,亦可能會將真人誤認做 bot;Microsoft 建議只畀 organizer 同 co-organizer 從 lobby 放人。公司如果淨係開咗新 policy,但 presenter 仍然可以亂批人入房,成件事只係多咗個提示,唔等於管治做足。

AI meeting bot 要同 transcript policy 一齊睇

另一個易漏嘅位係 transcript。Microsoft 另外有 Teams transcript API 文件,講明 Graph access 預設關閉,開咗先畀 app 同 agent 讀 meeting transcript,仲可以管 speaker attribution。換句話講,擋 bot 入房只係前門;如果公司本身畀咗 app 讀逐字稿、錄影或者 calendar 權限,資料仍然可能經其他路徑走出去。用 Otter、Fireflies 呢類會議記錄服務,或者跨平台用 Zoom AI 類功能前,IT 唔應該只問「好唔好用」,仲要問資料放喺邊、保留幾耐、邊個可以請 bot 入會、離職後 token 會唔會收返。

下一步睇 bot 身份同 audit

Microsoft 仲話就嚟推 Teams Bot Identification Program,畀 ISV 註冊同喺 join request 放自我識別 marker;官方 blog 又提到後續會研究 allow list、全公司封鎖外部 bot、admin report 同 audit log。呢個方向幾合理,因為公司要嘅係一套可審批、可追蹤、可封鎖嘅 bot 清單,唔應該每次靠 organizer 眼力。用 Teams 開客戶會、校務會、董事會嘅團隊,最好早啲喺高敏感會議試清楚 policy,而唔係等第一次有唔知邊個 bot 坐咗入嚟先補鑊。


參考來源

本文根據原文及公開資料整理;資料有出入時,以原文及官方資料為準。

分享:WhatsAppThreadsTelegramFacebook