一句話結論
一位資安研究者發現，AI 會議記錄工具 tl;dv 的資料庫少做了租戶隔離，任何一個註冊帳號都查得到全平台 181,874 筆會議、84,312 名使用者、35,003 個 email 網域——而且外洩的不只是紀錄，還包含約 1,000 場正在進行中、研究者稱可以直接走進去的會議室。研究者說他通報後拖了六個月沒修；tl;dv 說那是兩個不同的漏洞，也說外人要加入會議很少見、要主持人手動核准才進得去、第二個在 24 小時內修補、現已把 Firebase 整個移除並通過外部驗證。兩邊說法我都列出來。但真正要帶走的不是誰對誰錯，是那個你公司大概還沒問過的問題：你允許員工把主管會議丟進哪一家的 AI？那家出事，誰負責？
這篇的起點不是「AI 很危險」。
起點是一件更尷尬的事：這不是被駭。沒有人破解密碼、沒有人繞過防火牆。就是一條資料庫的存取規則沒寫好。
發生了什麼
資安研究者 BobDaHacker 在 2026 年 8 月 4 日發表了一份揭露報告。他發現 tl;dv 的 Firestore 資料庫裡，那個存放會議的 collection 沒有做租戶隔離。
「租戶隔離」聽起來很技術，但意思很簡單：A 公司的資料跟 B 公司的資料，要分開。這是所有多客戶服務的最基本設定——就像旅館的房卡只能開自己那間房。
少了這道設定的結果是：任何一個已登入的 tl;dv 使用者——註冊一個免費帳號就算——可以查詢全平台所有帳號的會議。
研究者查到的規模：
- 181,874 筆會議紀錄
- 84,312 名不重複使用者
- 35,003 個 email 網域
- 涵蓋 23 個國家的政府單位（.gov）、全球各地的大學（.edu／.ac）
- 企業客戶包含 HubSpot、Confluent、三井集團旗下公司
每一筆紀錄裡有：建立者的 email、會議的 conference ID、供應商、錄製狀態、時間戳。
重點在 conference ID。
最嚴重的不是紀錄，是那道還開著的門
conference ID 不是一串沒用的編號。它是 Google Meet 或 Teams 會議室的門牌號碼——可以直接加入的那種。
而報告指出，在那 18 萬筆裡，有約 1,000 場處於「recording」狀態。意思是：那場會議此刻正在進行。
研究者為了證明這不是理論風險，實際走進去兩場：
- 馬來西亞教育部的一場會議，現場超過 157 名參與者
- 美國某大學的一場創業開發討論，21 名參與者
他沒有被邀請。他就是拿著撿到的門牌號碼走進去。
請把這件事翻譯成你公司的情境：你們正在開的那場談併購、談裁員、談報價的會議，如果有人用了某個 AI 記錄工具，而那個工具的設定出了問題——一個陌生人可以安靜地坐進來，而你不會知道。他不需要駭進任何東西。
報告另外還提到，超過 1,000 場會議可公開存取，其中含 715 個受邀者 email、橫跨 228 個網域；以及一個沒做身分驗證的世界盃預測遊戲 API，外洩了 19 名 tl;dv 員工的姓名與信箱。
兩造說法：這裡要小心，我不幫任何一邊下結論
接下來是這則新聞最需要謹慎處理的部分。
研究者的說法（依其公開的時間軸）：
- 2026 年 1 月 28 日：透過 LinkedIn 聯絡創辦人，並寄信給技術長，附上漏洞細節
- 1 月 29～30 日：創辦人回覆會請團隊盡快處理，技術長未回應
- 2 月 14 日：仍未解決，研究者警告客戶曝險
- 2 月 19 日：得到回覆「我們在處理……請放心我們會follow through」
- 3 月 6 日：訊息已讀，沒有回覆
- 7 月 22 日：「還是沒修……」，無人回應
- 8 月 4 日發表時：研究者表示漏洞在通報六個月後仍未修復
tl;dv 的說法（見於 2026 年 8 月 13 日的媒體報導）：
- 這其實是兩個不同的攻擊向量，影響同一塊系統區域——不是「同一個漏洞拖了六個月」
- 新發現的第二個漏洞，在發現後 24 小時內修補
- 已將 Firebase 整個從基礎架構中移除，以避免同類問題
- 經外部機構 Abicom 正式驗證，確認漏洞已完全修復
- 外洩的僅限會議詮釋資料（建立者 email、會議 ID、錄製狀態、時間戳），錄音、逐字稿、AI 筆記沒有被存取
我的立場很清楚：這兩邊我都無法獨立驗證。
研究者的時間軸是他單方面提供的截圖與敘述；tl;dv 的說法是廠商自己的聲明，而且我沒有看到 Abicom 那份驗證報告的原文。我不會告訴你誰在說謊。
但有一件事兩邊都沒有爭議，而那件事就足夠了：會議資料確實曾經對其他註冊帳號敞開（18 萬筆是研究者的統計，廠商沒有確認筆數）。爭的是修了多久，不是有沒有發生。
而如果你是那 35,003 個網域裡的其中一個，你到現在大概都還不知道自己在名單上。
所以這篇真正的問題是：你們公司買 AI 工具，問過什麼？
我在課堂上每一場都會示範用 AI 整理會議紀錄。這是最好上手、最快看到價值的應用之一，我不會叫你別用。
但這件事把一個平常被跳過的步驟推到台前：你們公司採購 AI 工具的時候，問過哪些問題？
大多數公司問的是：多少錢、支援中文嗎、好不好用。
下面這五個問題，是我認為應該加進去的。你可以直接印出來，下次評估工具時當檢查表用：
| 要問什麼 | 為什麼要問 | 好的答案長什麼樣 |
|---|---|---|
| 我們的資料存在哪個國家？哪一家雲？ | 牽涉法遵、跨境傳輸、客戶合約條款 | 講得出具體區域與服務商，寫在合約裡 |
| 你們接受外部資安通報嗎？窗口是誰？ | tl;dv 事件的核心爭議就在這裡——有沒有人接、多久回 | 有公開的通報信箱或漏洞回報頁，有承諾回應時限 |
| 出事時你們多久通知我們？ | 你要對你的客戶交代，你需要時間 | 合約寫明通知義務與時限，不是「我們會盡快」 |
| 我們的資料會被用來訓練模型嗎？企業版跟免費版一樣嗎？ | 兩者條款經常不同，而員工用的常是免費版 | 條款原文指得出來，不是業務口頭保證 |
| 離職／解約後，資料多久刪除？怎麼證明？ | 會議紀錄是留存最久、最沒人管的一類資料 | 有刪除流程與可查的憑證，不是「我們會刪」 |
我知道你在想什麼：中小企業哪有本錢問這些，人家也不見得理你。
兩點回應。第一，問了會被拒絕，本身就是答案。一家連通報窗口都說不出來的廠商，跟一家能把條款頁面指給你看的廠商，風險差很多——這個判斷不用你懂資安。
第二，你不需要每個工具都跑完五題。用這個標準分級就好：會議內容涉及人事、財務、客戶名單、未公開決策的，走完整五題；純粹用來整理公開資料的，不用這麼嚴格。
誠實踩煞車
- 截至我查證的 2026 年 9 月 13 日，tl;dv 宣稱漏洞已完全修復並通過外部驗證。本文不是在說 tl;dv 現在不安全。你讀到這篇時狀態也可能又變了。
- 兩造說法我都無法獨立驗證。研究者的時間軸是單方陳述；tl;dv 的聲明是利害關係人的說法；Abicom 的驗證報告我沒有取得原文。本文呈現雙方說法，不裁決。
- 我沒有、也不建議任何人去重現這個漏洞。未經授權存取他人系統在多數司法管轄區都是違法的，就算「只是看看」。
- 這不代表其他 AI 會議工具就安全。這類設定疏漏是產業共通的風險型態，不是某一家的體質問題。反過來說，一家出過事並公開修補紀錄的廠商，未必比一家從沒被檢查過的廠商更危險。
- 181,874 這個數字是研究者的統計，不是 tl;dv 公布的。廠商的聲明中沒有確認或否認具體筆數。
- 那五個採購問題是我整理的實務建議，不是任何標準或法規的要求。你們公司如果有正式的資安或法遵流程，以那個為準。
所以你該做什麼
如果你是一般上班族：做一件三分鐘的事——打開你在用的 AI 會議工具，看看它的分享設定。那些「有連結就能看」的會議紀錄，現在有多少條連結流在外面？另外，下次開涉及人事或報價的會議前，問一句「這場要錄嗎」，就已經比大多數人謹慎了。
如果你在管工具採購：先做盤點，不是先做禁令。列出公司裡實際在用的 AI 工具（你會發現比你以為的多），然後只對「會碰到敏感內容」的那幾個跑五問。範圍抓小，才做得完。
如果你是主管：這件事最該記住的一點是——出事的不是模型，是設定。你們評估 AI 廠商時，很容易把注意力放在「它的 AI 準不準」，但這次出問題的地方跟 AI 一點關係都沒有，是最基礎的軟體工程。所以你的評估不能只看 AI 能力，要看這家公司像不像一家會把基本功做好的公司——有沒有人接資安通報，就是最便宜的一個指標。
你是機長，AI 是機組人員
機長上飛機之前，不會親自去檢查每一顆螺絲。他沒有那個時間，也沒有那個專業。
他依靠的是維修簽放——一份有人簽名、負責任、可追溯的文件，說明這架飛機經過了什麼檢查、誰做的、發現什麼、修了沒有。機長看的是那份文件，然後他簽下自己的名字，扛起這趟飛行。
這件事的重點從來不是「機長懂不懂機械」，而是責任有沒有落在一個具體的人身上。
你們公司用的每一個 AI 工具也是一樣。你不需要看懂它的資料庫怎麼設定——你需要知道的是，如果它出事，有沒有一個人、一份合約、一個窗口要負責。
tl;dv 這個案子裡，最讓人不安的細節不是那 18 萬筆會議。是那半年裡，那封信寄出去之後沒有人接。
你是機長。你可以不懂機械，但你不能接受一架沒有維修簽放的飛機。
常見問題 FAQ
Q：所以我們該禁用 AI 會議記錄工具嗎？
不建議。禁令通常只會把行為推到你看不見的地方——員工改用自己的手機錄、用個人帳號的工具，那更糟。比較有效的做法是分級：公開性質的會議隨意，涉及人事、財務、客戶、未公開決策的會議指定工具、或乾脆不錄。
Q：我們用的是大廠的工具（Google、Microsoft 那種），是不是就沒事？
大廠在這類基礎設定上出錯的機率確實比較低，資源也比較多。但這不是保證，而且大廠的問題通常是另一種——條款複雜、預設設定寬鬆、你以為沒開的功能其實開著。不管哪一家，「分享連結權限」和「保留期限」這兩個設定都值得你進去看一眼。
Q：那 conference ID 外洩為什麼這麼嚴重？我開會都要密碼啊。
要看你的設定。很多組織為了方便，會把會議設成「有連結就能加入」或「組織內免等候室」。研究者能直接走進馬來西亞教育部那場 157 人的會議，代表那場會議的設定就是這樣。參加人數愈多的會議，愈不會有人注意到多了一個人。等候室這個功能，在大型會議裡反而最有價值。
Q：我們公司規模小，廠商根本不會理我們的資安問題，怎麼辦？
你不需要他們客製回答。去看他們網站上有沒有資安或隱私頁面、有沒有回報信箱、條款是不是寫得出來。這些都是公開的、不用問就看得到的。看不到，就是一個訊號。真的要問，用 email 問並留存回覆——就算只是備而不用。
Q：這件事跟「AI 會不會偷我們資料去訓練」是同一個問題嗎？
不是，這點很重要。「拿去訓練」是條款問題——寫在合約裡，你同意了它就可以。這次的事件是工程問題——不管條款怎麼寫，資料本來就不該被其他客戶看到。兩個都要管，但用的手段不一樣：前者看法務，後者看廠商的基本功。
資料來源
以下均於 2026 年 9 月 13 日查證：
- 資安研究者 BobDaHacker 的揭露報告（bobdahacker.com/blog/tldv-hack，2026 年 8 月 4 日）：181,874 筆會議／84,312 名使用者／35,003 個 email 網域、23 國政府與學術機構、HubSpot 與 Confluent 等企業、每筆紀錄的欄位內容、約 1,000 場 recording 狀態可加入、實際加入馬來西亞教育部（157+ 人）與美國某大學（21 人）兩場會議、715 個受邀者 email／228 個網域、19 名員工資料經由世界盃預測遊戲 API 外洩，以及 1/28 通報至 7/22 的完整往來時間軸。
- GIGAZINE：tl;dv 資料外洩事件報導與廠商回應（gigazine.net，2026 年 8 月 13 日）：tl;dv 官方說法的出處——「兩個不同的攻擊向量」、第二個漏洞於 24 小時內修補、已將 Firebase 完全移除、經 Abicom 正式驗證確認完全修復。
查證說明（誠實揭露）：①本文呈現兩造說法，不做裁決——研究者的時間軸為其單方陳述，tl;dv 的回應為利害關係人聲明，我兩邊都無法獨立驗證。②Abicom 的驗證報告我沒有取得原文，僅能轉述 tl;dv 宣稱其存在與結論。③181,874 等數字全部出自研究者的統計，tl;dv 的公開聲明中我沒有查到對具體筆數的確認或否認。④截至查證日，tl;dv 宣稱問題已完全修復，本文並非主張該服務目前不安全；讀者閱讀時狀態可能已再變動。⑤我沒有嘗試重現該漏洞，也不建議任何人這麼做——未經授權存取他人系統在多數司法管轄區均屬違法。⑥本文未查證其他 AI 會議工具的資安狀況，因此不對「哪一家比較安全」做任何排序或暗示。⑦文中那五個採購提問與分級建議是我依培訓現場經驗整理的實務作法，不是任何標準、法規或認證的要求，企業應以自身法遵流程為準。⑧關於「大型會議比較不會有人注意到多一個人」的判斷是我的經驗推論，非報告內容。
出事的不是模型，是設定
我會把這類事件拆成企業實際用得上的檢查動作：我的電子報大約一到兩週一封 → startupforyou.substack.com
如果你是主管：我的企業內訓有一個資安模組，不是講理論，是帶團隊把「哪些會議能錄、能丟哪個工具、誰有權限看」當場寫成貴公司自己的一頁規則，下課就能發給全公司。想聊聊寫信到 ai@autolab.cloud，或看看 AI 顧問教練團。
公司想導入 AI、安排內訓 → 企業內訓諮詢表單
關於作者
黃敬峰（AI峰哥／阿峰老師），企業 AI 實戰培訓專家，服務客戶包含國泰人壽、工研院、士林電機、電通、城邦媒體等。聯絡方式：ai@autolab.cloud