2026 年《Data Loss Prevention Report》整理的行業數據顯示，2025 年流入 AI 及機器學習應用的企業數據達 18,033 TB，按年上升 93%。真正值得香港管理層警惕的，是另一個數字：其中 34.8% 屬敏感資料，一年前是 27.4%，兩年前只有 10.7%。
反直覺之處在於「管控點的位置」。對大多數企業而言，橫亙在客戶名單與公開聊天機械人之間的，只是安裝在員工手提電腦上的一套軟件。2026 年 8 月 5 日，Anthropic 把這個管控點徹底搬離了員工的電腦。
什麼是 Inference Hooks？
Inference Hooks 是 Claude Enterprise 的功能，會把每一個受管控的提示詞，先送到由你的組織自行掌控的安全伺服器，由該伺服器在模型開始生成之前回覆「允許」或「拒絕」。被拒絕的請求永遠不會到達模型。檢查點運行於 Anthropic 的伺服器，員工裝置上無須安裝任何東西。
根據 Anthropic 於 2026 年 8 月 5 日發布的產品公告，此功能現以 Beta 形式提供予 Claude Enterprise 組織，一次設定即可同時覆蓋 chat、Claude Code、Claude Cowork 等多個介面。
值得留意的並非功能本身，而是檢查點所處的位置。建立在受管裝置上的管控，只能管到受管裝置；建立在「請求與模型之間」的管控，則能管到每一個請求，無論員工使用什麼工具。
為何檢查點的位置如此關鍵？
裝置層面的管控，必然在企業版圖的邊緣失守：私人電腦、外判人員的機器、手機瀏覽器，以及任何端點代理未能覆蓋的介面。2026 年關於影子 AI 的研究指出，77% 員工曾將公司資料貼入生成式 AI 工具，其中 82% 是透過未受管理的個人帳戶進行。
這個缺口正是問題核心。部門主管可以批出企業 AI 授權、頒布使用守則，卻依然沒有任何技術機制，能夠阻止一位區域銷售經理在家中電腦上，把客戶檔案貼進對話視窗。
把檢查點移至伺服器一側，等於把問題由「我們管理了哪些裝置」改寫為「我們管控了哪些請求」。在董事會文件或監管查詢面前，後者遠比前者容易回答。
這同時改變了管控權的歸屬。判斷由你的安全伺服器作出，而非由模型供應商代勞。規則由你的合規團隊撰寫，供應商只負責執行結果。
Inference Hooks 實際如何運作？
員工提交提示詞後，Anthropic 會以 HTTPS POST 把對話內容送往你的安全伺服器。伺服器評估內容，並在可設定的逾時時間內（預設 5 秒）回覆一個 JSON 判斷。判斷為允許，推理照常進行；判斷為拒絕，請求即被攔截並記錄在案。
根據 Claude Platform 官方技術文件，當中有五項操作細節，是科技主管應該能夠複述的：
--- 請求附有簽章。每次呼叫均依照 Standard Webhooks 規範簽署，讓你的伺服器可驗證請求確實來自 Anthropic。
--- 預設判斷逾時為 5 秒。實際數值由組織自行設定。
--- 失效處理是一項政策抉擇。當你的伺服器無法連接或反應過慢，設定決定該請求是被攔截，還是未經檢查直接放行。這一個開關，就是「可用性風險」與「數據風險」之間的分野。
--- 工具呼叫同樣受檢。透過 MCP 連接器、Skills 及外掛取得的工具回應，在返回模型之前亦會被檢查。
--- 拒絕紀錄會被保存。每一次攔截連同伺服器提供的理由，均會寫入組織的合規 Activity Feed。
推行方式並非一刀切。Shadow mode 只觀察實際流量的判斷結果而不作攔截；百分比推行可先檢查部分請求；角色豁免則可讓指定群組完全不受影響。
Inference Hooks 做不到什麼？
三項限制已公開列明，且影響重大。純圖像內容不會被檢查，因為原始檔案與圖片位元組不會傳送到你的伺服器；判斷只有允許與拒絕兩種，不支援遮蔽或改寫；語音模式、標題生成等附屬請求，以及透過 Claude Platform API 存取的組織，均不在覆蓋範圍。
第一項最容易令合規主管措手不及。一張客戶合約的螢幕截圖以圖像形式通過，你的安全伺服器只會收到元數據與抽取出的文字，而非圖片本身。
第二項直接影響使用體驗。能夠遮蔽身分證號碼的 DLP 工具，讓工作得以繼續；只能拒絕的工具，則會令工作中斷並產生一張支援工單。
第三項影響你對外的覆蓋率陳述。若組織中有部分單位透過 Amazon Bedrock 或 Google Cloud 使用模型，Inference Hooks 在該處並不適用。覆蓋大部分流量已是良好的管控；但若向董事會聲稱覆蓋全部，則屬於治理上的錯誤。
回應端的執行管控目前仍屬規劃階段。現時唯一的觸發事件發生在推理之前，針對提示詞本身。
這與事後合規記錄有何分別？
Inference Hooks 屬於即時介入並預防；合規或審計 API 屬於事後查閱並記錄。前者阻止受規管資料到達模型，後者只在事後告訴你資料已經到達。大多數企業兩者皆需要，而目前手上通常只有後者。
這個分別決定了你能向監管機構說什麼。審計日誌讓你準確申報一宗事故；即時管控則讓你說明事故已被阻止。
它同時決定成本。事後發現個人資料外洩，會觸發評估、通知與補救等一連串工作；預防的成本，只是一條政策規則與若干延遲。
若你已透過 Netskope、Palo Alto Networks、Proofpoint 或 Zscaler 推行 DLP 計劃，真正要問的問題其實更狹窄：現有的檢查點能否接收 webhook，並在逾時之內回覆判斷。
在香港《私隱條例》下這代表什麼？
香港個人資料私隱專員公署於 2025 年 3 月 31 日發布《僱員使用生成式 AI 的指引清單》，並於 2026 年完成涵蓋 60 間機構的第三輪 AI 循規審查。即時執行的管控，為香港機構提供了一個技術答案，回應清單中最核心的要求：界定並管控可容許的使用範圍。
私隱專員公署的清單要求機構識別哪些生成式 AI 工具獲准使用、界定容許的使用場景、為高風險用途指派審核人，並定期審計 AI 的使用情況。這幾項在過去，全部只能依靠培訓與信任來執行。
根據私隱專員公署 2026 年 5 月的新聞公報，該年度的循規審查並未在受查機構中發現違反《個人資料（私隱）條例》的情況。這是合理的結果，卻不是放鬆的理由。香港企業內部的 AI 流量增速，遠遠拋離其治理層的建設速度。
香港生產力促進局《2025 年職場 AI 就緒度調查》指出，受訪香港企業中有 88% 員工已在日常工作使用 AI 工具，集中於客戶服務、數據分析與市場推廣。這些正正是處理個人資料的職能。
若想更完整了解本地監管圖景，可參閱 UD 早前對 2026 年私隱條例循規審查對香港企業的意義 的分析，以及 影子 AI 治理風險 的專文。
如何決定是否啟用即時管控？
四個問題足以定案。你是否有能在 5 秒內回覆判斷的安全伺服器或 DLP 供應商？失效處理政策是否已有定案？業務能否承受「只能拒絕、不能遮蔽」的結果？你手上是否有一份站得住腳的攔截清單，而非一個願望？
第一個是基礎設施問題。若現時的 DLP 檢查以批次方式運行，它根本無法提供即時判斷，項目的起點將是延遲工程，而非政策制定。
第二個是風險胃納問題，屬於管理層而非工程師。失效攔截保障數據，卻讓可用性依賴於自家伺服器；失效放行保障生產力，卻恰好在基礎設施最不穩定之時留下檢查缺口。這裡不存在中立選項。
第三個是變革管理問題。由於判斷無法遮蔽，每一次誤判都等於一位員工被攔下。Shadow mode 的存在意義，正是讓你在有人被攔截之前先量度這個比率。
第四個最常被略過。直接沿用電郵 DLP 的規則，會標記大量本來完全適合與助理討論的內容，同時漏掉 AI 場景中真正要緊的類別，例如貼上未公布財務數字要求撮要。
部署失敗時通常錯在哪裡？
五種失敗模式反覆出現：首日直接啟用攔截而略過 shadow mode；原封不動沿用電郵 DLP 規則；失效處理停留在預設值而無管理層決定；部分單位經其他途徑接觸模型卻仍聲稱全面覆蓋；以及把無人翻閱的合規日誌當成已生效的管控。
第一種在政治上最具破壞力。未量度誤判率便直接開啟攔截的機構，會在第一星期製造大量被攔請求，功能未證明任何價值便已被關閉。
第二種在技術上最常見。電郵 DLP 的規則是為離開網絡邊界的文件而調校，並非為員工以自己的措辭描述客戶情況的對話文字而設。
第三種是披着設定預設值外衣的治理失誤。若無人簽署同意失效放行，也就無人為它造成的缺口負責。
第四種是匯報失誤。覆蓋率的陳述，應該在同一句話裡同時說明納入與不納入的介面。
第五種最為安靜。無人審視的拒絕紀錄，只證明管控曾經存在，不證明它發揮過作用。
未來 30 天應該做什麼？
盤點組織實際使用的 AI 介面，並標示哪些已被管控。向 DLP 供應商查證能否提供即時判斷。把失效處理提升為有指定負責人的管理層決定。在正式攔截之前，先讓 shadow mode 運行一個完整業務週期。
次序有其道理。盤點必須最先，因為一個界定不了範圍的管控，也是一個無法匯報的管控。供應商對話排第二，因為它決定這是一次設定工作，還是一個工程項目。
失效處理的管理層決定排第三，而且應該寫入會議紀錄。當檢查伺服器在星期一早上九時半逾時，工作是否應該停下，不該由當值工程師獨自回答。
Shadow mode 排最後，耗時亦最長。月結期產生的提示詞，與平靜的星期二截然不同；一個只量度了三天的誤判率，撐不過你的匯報週期。
更宏觀的啟示，香港的管理層已經摸索了兩年。當員工只需一句話便能移動受規管資料的那一刻起，AI 治理便不再是一份政策文件。真正令政策落地的，是安置在請求與模型之間的管控。
懂AI，更懂你 UD相伴，AI不冷。
Inference Hooks 重點事實一覽
供應情況
--- Beta 階段，僅限 Claude Enterprise 組織。2026 年 8 月 5 日公布。
--- 不適用於 Amazon Bedrock 及 Google Cloud；Claude Platform API 組織不在範圍內。
覆蓋範圍
--- 一次組織層級設定，涵蓋 chat、Claude Code 與 Claude Cowork，適用於網頁、桌面應用與 CLI。
--- MCP 連接器、Skills 及外掛的工具回應會被檢查；語音模式不在覆蓋之列。
運作機制
--- 預設判斷逾時：5 秒，可自行設定。
--- 判斷結果：允許或拒絕，不支援遮蔽。
--- 請求依 Standard Webhooks 規範簽署。
--- 失效處理可設定為攔截或未經檢查放行。
推行控制
--- Shadow mode、按百分比推行、按角色豁免。
--- 拒絕紀錄連同理由寫入合規 Activity Feed。
本文由 UD 企業 AI 團隊審閱。UD 自 1998 年起為香港機構提供基礎設施、資訊保安與 AI 部署顧問服務。
下一步，由 UD 陪你走
知道管控點應該放在哪裡，是容易的部分。判斷你的組織可以安全部署什麼、部署在什麼環境之中，才是真正的工作。UD 把 AI 建置於隔離而受監控的企業環境之內，並手把手帶你完成每一步，由準備度評估、方案選型，到安全部署與持續監察。
