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 建置于隔离而受监控的企业环境之内，并手把手带你完成每一步，由准备度评估、方案选型，到安全部署与持续监察。
