這場爭議很容易被簡化成一句話：Chrome 是否偷偷吃掉了 4GB？但從隱私角度看，真正要問的不是檔案大不大，而是瀏覽器新增一層 AI 能力時，使用者是否看得見、管得到、關得掉。
先把兩件事分開：官方文件與第三方報導
**官方已經確認的部分是：**Google 的 Chrome 開發者文件把 Chrome 描述為 Built-in AI 平台，網站與 Web 應用程式可透過由瀏覽器管理的 AI 模型與 API 執行 AI 任務；文件也明確把 Gemini Nano 放在這個脈絡中 [17][
18]。同一套 Built-in AI 說明提到，模型可快取在裝置上，讓應用程式啟動更快 [
18]。Google 開發者部落格也稱 LiteRT-LM 是讓 Chrome 等產品使用裝置端 Gemini Nano 的框架之一 [
20]。
**目前仍主要來自報導指稱的部分是：**多篇文章宣稱 Chrome 會在使用者設定檔中的 OptGuideOnDeviceModel 資料夾放入約 4GB、名為 weights.bin 的模型檔，而且過程沒有清楚提示，手動刪除後還會再次下載 [2][
3][
7][
10][
14]。不過，Chrome 官方開發者文件雖然證實 Built-in AI 與裝置端快取，卻沒有在相關文件中確認這個精確檔案大小、檔名，或刪除後會自動恢復的行為 [
17][
18]。
所以，這件事既不宜直接定調為已證實的重大隱私醜聞，也不應輕描淡寫成一般更新。比較精準的問題是：Chrome 內建本機 AI 後，使用者與管理員到底有多少控制權？
為什麼透明度比 4GB 更重要
大型本機模型本身不是原罪。若內容確實留在裝置上處理，本機 AI 在某些情境下反而可能比雲端處理更有利於隱私 [19]。問題在於，當一個瀏覽器新增能處理文字、頁面或使用者輸入的 AI 層，使用者是否清楚知道它何時存在、何時啟動、會處理什麼，以及如何停用。
Chrome Built-in AI 也不只是內部效能調整。Google 文件描述的是一組讓網站與 Web 應用程式透過由瀏覽器管理的模型執行 AI 任務的 API [17][
18]。Google I/O 資料列出的應用情境包括翻譯、摘要、寫作與改寫內容 [
28]。當這些能力被放進瀏覽器，使用者需要的不只是「硬碟空間被占用」的資訊，而是可理解、可選擇的控制介面。
用途要說清楚：寫作、翻譯、安全防護是不同問題
隱私風險很大程度取決於用途。同樣是 Gemini Nano，在瀏覽器中可能用於寫作輔助、翻譯、摘要、改寫，也可能用於安全防護。Google 的 Chrome Built-in AI 文件與 Google I/O 資料都提到翻譯、摘要、寫作與改寫這類任務 [17][
18][
28]。另外，Infosecurity Magazine 報導稱，Google 在 Chrome 137 的 Safe Browsing「Enhanced Protection」模式中，實驗把 Gemini Nano 作為對抗垃圾內容、詐騙與釣魚攻擊的額外防護層 [
25]。
這些用途不一定有問題，甚至可能很有用。但它們需要不同層次的開關。使用者應能分辨自己是否要啟用：
- 便利功能，例如寫作、摘要、翻譯；
- 安全功能，例如詐騙或釣魚偵測；
- 給網站或 Web 應用程式呼叫的開發者 API；
- 或完全不使用本機 AI。
如果用途沒有說清楚，瀏覽器更新就很容易被感受成「靜默擴權」。
裝置端不等於自動零風險
Google 對 Gemini Nano 的裝置端說明指出，它可以在不需要網路連線、也不必把資料送到雲端的情況下提供生成式 AI 體驗 [19]。這正是本機 AI 最有力的隱私優勢：如果輸入內容真的留在裝置上，雲端資料流就可能減少。
但「在本機」不等於「已經透明」。仍需要回答幾個關鍵問題：
- 哪些內容會被交給本機模型？
- 哪些 Chrome 功能、網站或 Web 應用程式能呼叫模型？
- prompt、輸出、錯誤訊息、使用量指標或遙測資料是否會被保存或傳送？
- 模型更新如何發送？
- 使用者刪除或停用模型後，是否會永久維持？
Chrome 文件已說明 Web 應用程式可透過 Built-in AI API 使用由瀏覽器管理的模型 [17][
18]。因此，隱私討論不能只看模型檔案本身，也要看圍繞模型的權限、API 與資料流設計。
瀏覽器看得到的內容，往往很敏感
瀏覽器每天接觸的資料可能包括表單、內部文件、電子郵件、聊天內容、客服紀錄、客戶資料或工作檔案。當 AI 功能負責翻譯、摘要、寫作或改寫時，就可能接觸這些內容 [28]。若處理過程確實只在本機完成，當然比自動送往雲端更友善 [
19]。但使用者仍應清楚看見：AI 什麼時候正在工作？哪些內容被納入？是否還有其他資料傳到 Google 或第三方服務？
目前 Chrome AI 官方頁面說明了 Built-in AI API 的存在與方向，但並未回答每一個具體的控制、遙測與資料保存問題 [17][
18]。這正是透明度不足時容易引發不信任的地方。
能不能退出，才是實務上的壓力測試
最尖銳的指控不只是「下載了一個大檔案」，而是「刪不掉、關不清」。多篇報導宣稱，相關模型檔在手動刪除後會再次下載，而且一般 Chrome 設定中沒有明顯、簡單的 opt-out 選項 [3][
7][
10][
14]。若這些說法屬實，問題就不只是容量，而是使用者自主權：刪除不等於真正移除，不使用也不等於明確拒絕。
對一般使用者來說，這牽涉儲存空間、頻寬與信任。對公司、學校、政府機關或其他受管環境來說，還會牽涉軟體盤點、核准流程、瀏覽器政策，以及在受規範環境中如何管理 AI 元件。部分報導也因此把事件放在供應商風險與合規管理的框架下討論 [1][
12]。
GDPR 與 ePrivacy：有潛在爭點，但不能直接下結論
從目前資料看，還不能斷言 Chrome 一定違反法律。缺少的資訊包括實際派送條件、使用者提示、設定選項、啟用邏輯，以及是否或如何產生資料傳輸。部分隱私報導認為，這件事可能牽涉 GDPR 的透明度、資料保護設計原則，以及 ePrivacy 對終端裝置儲存或存取資訊的規範 [12][
13]。
重點是要分清楚：模型檔案不是因為大就必然有隱私問題。真正敏感的是，如果 Chrome 在缺乏清楚告知的情況下安裝可處理使用者內容的元件，或對遙測、啟用資料、使用資料的說明不足，才會讓資料保護風險升高。
比較符合隱私期待的做法應該有哪些
若瀏覽器要內建本機 AI，至少應做到以下幾點：
- 在安裝大型 AI 元件前，提供清楚易懂的更新說明；
- 在一般設定中提供啟用、停用與移除模型的選項；
- 清楚說明刪除模型後，是否以及何時會重新下載；
- 將便利功能、安全功能與開發者 API 分開控制；
- 說明哪些處理只在本機完成，哪些情況可能呼叫雲端；
- 說明遙測資料的類型、用途與保留方式；
- 提供企業與機關可集中管理的管理員政策；
- 當網站或 Chrome 功能正在使用本機模型時，給使用者可見提示。
這些不是形式上的法律條款，而是使用者能否信任本機 AI 的基礎。若做得好，裝置端 AI 可以是隱私加分；若做得不透明，它就會變成瀏覽器裡一層難以理解的新權限。
結論
Chrome Built-in AI 與 Gemini Nano 的存在已有官方文件支持 [17][
18]。但「Chrome 靜默下載約 4GB
weights.bin，且刪除後會重載」這項具體指控，目前主要仍來自多篇第三方報導，並未在相關 Chrome 官方開發者文件中被完整確認 [2][
3][
7][
10][
14][
17][
18]。
因此，冷靜的判斷是：本機 AI 不是問題的全部，甚至可能在內容不離開裝置時改善隱私 [19]。真正關鍵在於 Chrome 是否清楚說明安裝了什麼、用來做什麼、會產生哪些資料流，以及使用者與管理員能否有效關閉。換句話說，這場爭議的核心不是 4GB，而是控制權。
