近期 That Privacy Guy 一篇文章指出，Google Chrome 瀏覽器會在使用者未明確同意下，於本機下載約 4GB 的 Gemini Nano AI 模型權重檔，並放置在 OptGuideOnDeviceModel 相關目錄中。更敏感的是，使用者即使手動刪除相關檔案，Chrome 仍可能在符合條件後重新下載。這個說法聽起來像是瀏覽器偷偷塞了一個大型 AI 模型進你的電腦，但如果對照 Google 官方文件，事情比單純的偷裝更微妙，也更值得關注。
這裡要先釐清一件事，這次爭議中的Nano不是大家熟悉的 Nano Banana 影像生成模型，而是 Gemini Nano，也就是 Google 為裝置端推論設計的小型語言模型。它被用於 Chrome 的 Built-in AI APIs，例如 Prompt API、Summarizer API、Writer API、Rewriter API、Proofreader API 等。Google 官方文件明確說明，Prompt API 可讓開發者在瀏覽器內對 Gemini Nano 發送自然語言請求，讓網頁或擴充功能具備本機端 AI 推論能力。
從技術角度看，Chrome 內建 AI 的方向並非沒有價值。Google 主張，這類本機端 AI 可帶來較低延遲、離線使用、降低雲端 API 成本，以及讓資料在裝置上處理的隱私優勢。官方文件也特別指出，使用本機模型時，後續推論不需要網路，且資料不會傳送給 Google 或第三方。對企業與開發者來說，這是一個很有吸引力的架構，模型由瀏覽器管理，應用程式只要呼叫標準化 API，就能取得本機 AI 能力。
不但如此，Chrome 148 還正式擴大推進了 Prompt API 的功能，允許網頁開發者透過 JavaScript 直接呼叫瀏覽器內建的 AI 模型來處理任務。為了支援這些新功能，Chrome 依然將該 AI 模型視為基礎元件自動派發到符合硬體條件的裝置上。使用者即使手動刪除該檔案，只要觸發相關機制或瀏覽器重新連網，系統就會自動重新下載。
Gemini Nano 的模型管理會在背景自動完成
Google 在 Understand built-in model management in Chrome 文件中寫得相當清楚，Gemini Nano 的模型管理會在背景自動完成，初次下載通常由第一個依賴 Gemini Nano 的內建 AI API *.create() 呼叫觸發，例如 Summarizer.create()。Chrome 會根據裝置 GPU 或 CPU 條件，決定下載較大的 Gemini Nano 版本，或較小、較有效率的版本，如果硬體條件不符，就不下載。
官方文件還指出，下載機制具有韌性，網路中斷後可續傳，觸發下載的分頁關閉後，下載仍可能在背景繼續，瀏覽器關閉後，只要 30 天內重新開啟，也可能恢復下載。這些設計站在工程角度是合理的，因為大型模型下載若因分頁關閉就中止，使用者體驗會很差。但站在隱私與資源治理角度，這也正是爭議來源，使用者可能根本不知道是哪個網站、哪個功能、哪次操作觸發了幾 GB 的模型下載。
更進一步說，這不是一次性的軟體更新而已。Google 文件表示，Gemini Nano 模型會定期更新，Chrome 啟動時會檢查新版本，其他補充資源如 LoRA 權重也可能每日檢查更新。由於模型權重差異可能很大，Chrome 的模型更新通常是完整新模型下載，而非差分更新，這項能力一旦被納入瀏覽器底層，就不只是多一個功能，而是讓瀏覽器開始承擔模型生命週期管理器的角色。
這也解釋了為什麼許多使用者會在磁碟空間中看到突然多出的 weights.bin 或 OptGuideOnDeviceModel 目錄。Super User 上已有使用者回報，在 macOS 的 Chrome 應用程式支援目錄下看到 OptGuideOnDeviceModel，其中 weights.bin 約 4GB。這類回報與 That Privacy Guy 文章中提到的現象吻合，也與 Google 官方對模型大小會隨版本變動的說法是對德上的。
真正值得討論的，不是 Google 能不能把 AI 放進 Chrome，而是這種資源佔用與功能啟用，是否應該有更明確的使用者同意與我們看得到的控制選項。Google 其實也知道這是使用者體驗問題，官方另有文件建議開發者在模型下載時告知使用者，並透過 create() 的 monitor 選項顯示下載進度。文件甚至提醒，若模型尚未下載，應顯示進度，讓使用者知道何時才能使用本機端功能。這代表 Google 在開發者指南層面承認，模型下載不是可以完全無感處理的小事。
但問題是，開發者被要求告知，不等於 Chrome 本身已經提供足夠清楚的全域控制。對企業來說，Chrome Enterprise 已提供 BuiltInAIAPIsEnabled 政策，可控制網頁是否能使用 LanguageModel API、Summarization API、Writer API、Rewriter API 等內建 AI API，政策未設定時，這些 API 預設仍允許使用。這代表企業 IT 管理員可以透過群組原則或雲端管理關閉相關能力，但一般消費者面對的是另一個問題，是否有一個清楚、可理解、可持久的選項，讓他們知道我是否允許 Chrome 下載並管理本機 AI 模型？
Mozilla 已公開對 Prompt API 表示反對，擔心出現瀏覽器模型相容性碎片化
這場爭議也不只限於隱私社群。Mozilla 已公開對 Prompt API 表示反對，並在標準立場討論中標記 interoperability concerns與position: negative。The Register 報導指出，Mozilla 擔心將 AI API 直接綁入瀏覽器，會對 Web 平台的互通性、可更新性與中立性造成負面影響。如果開發者開始針對 Gemini Nano 的輸出特性調整提示詞與流程，Web 可能再度出現類似早年瀏覽器相容性問題的模型相容性碎片化。
對此，Brave 瀏覽器則是直接剔除 Google 的底層自動更新元件，Safari 瀏覽器則依賴蘋果 macOS/iOS 原生的作業系統級別 AI 框架，並未選擇將龐大模型塞進瀏覽器中。
從資安與隱私角度看，Chrome 內建 AI 並不必然是壞事。本機推論確實比把所有資料送到雲端更有隱私優勢，尤其在摘要、分類、寫作輔助、詐騙偵測等場景中，裝置端 AI 有其合理性。Google 也已在 Chrome 安全防護中使用 Gemini Nano 強化詐騙網站偵測，讓 Safe Browsing 可利用裝置端模型產生更高信心的風險訊號。
然而，好的安全功能也不能跳過透明度。瀏覽器已經不只是單純的網頁瀏覽工具，而是作業系統之上的第二層平台。當這個平台開始自動下載、更新、刪除、重新下載數 GB 等級的 AI 模型時，使用者需要的不只是這是為了體驗更好的說明，而是明確的告知、可理解的開關、可審計的下載紀錄，以及對企業與個人使用者都一致清楚的治理方式。
如果這件事放在歐盟 ePrivacy Directive 的脈絡下，也可能引發更大的合規討論。歐洲資料保護委員會 EDPB 在 Article 5(3) 技術範圍指引中指出，對使用者終端設備儲存資訊或存取已儲存資訊，原則上涉及同意或特定必要性例外，且該條文不只適用於 Cookie，也涵蓋類似技術。不過，是否適用例外、是否構成違規，仍須依具體情境與各會員國法制個案判斷，不能僅憑模型下載本身就下結論。
怎樣檢查自己的 Chrome 瀏覽器有沒有下載 Gemini Nano 模型 ?
CyberQ 認為，Chrome 下載 Gemini Nano 模型這件事，從目前資料看來不是空穴來風，也不是惡意軟體式的攻擊行為，它是 Google 將瀏覽器轉型為本機 AI 平台的一部分。但這種轉型若缺少清楚的使用者選擇權，就會讓本機 AI從隱私賣點變成新的信任問題。
CyberQ 建議，對一般使用者來說，現階段可以到瀏覽器上方列，貼上這段 chrome://on-device-internals，去檢查確認是否已安裝相關模型，貼上時，會提醒你要同意開啟內部偵錯模式。
點選它講的 chrome//chrome-urls 進入該頁面後，點選 enable 即可進入 chrome://on-device-internals 畫面檢查 AI 模型設定。
若不需要 Chrome 內建 AI，可檢查 Chrome flags 或等待 Google 提供更正式的使用者設定。對企業 IT 與資安團隊來說，則應優先盤點 Chrome/Edge 的內建 AI API 政策，評估是否關閉 BuiltInAIAPIsEnabled，並將瀏覽器 AI 模型納入端點資產、磁碟容量、資料治理與軟體生命週期管理範圍。
CyberQ 指出，就目前一般使用者的常規設定介面而言，幾乎沒有選擇權。Chrome 的一般設定中並沒有一個直覺的開關可以一鍵阻擋模型下載。若要奪回控制權，必須依賴進階設定：
修改隱藏旗標 (Flags)，必須在網址列輸入 chrome://flags，將 #optimization-guide-on-device-model 與 #on-device-model-background-download 設為 Disabled（停用），接著再手動刪除電腦中的資料夾。但隱憂是，當瀏覽器進行大版本更新時，這些旗標設定可能會被重置。
企業群組原則 (Group Policy)， 針對企業端受管裝置，IT 管理員可透過設定 OnDeviceModelEnabled 為 false 來永久阻擋，這是目前唯一不受版本更新影響的可靠做法。
網頁開發者可能之後會面臨兩難，當前端工程師嘗試使用 Chrome 推出的 Prompt API 開發網頁應用時，會發現程式碼只能在「已成功下載模型的 Chrome 使用者」設備上順利執行。對於其他瀏覽器，或是硬碟空間不足、硬體不達標的 Chrome 使用者，開發者仍必須自行準備雲端 API 作為備案。
這打破了以往 Web 標準「寫一次，到處皆可執行」的跨平台一致性。未來的網頁生態可能演變成：特定的 AI 網頁功能只能被綁定在特定的瀏覽器上，進而讓開發與維護的複雜度大幅上升。
CyberQ 認為，AI 進瀏覽器已經是趨勢，並開始成為本機 AI 執行平台之一，使用者與企業需要的是更高透明度，而不是在某天清理磁碟空間時，才突然發現自己的瀏覽器已經多了一顆 4GB 的小型AI 模型。
