Industry telemetry compiled for the 2026 Data Loss Prevention Report puts 18,033 terabytes of corporate data flowing into AI and machine-learning applications during 2025, a 93% year-on-year rise. The figure that should hold a Hong Kong executive's attention is smaller: 34.8% of that data was classified as sensitive, up from 27.4% a year earlier and 10.7% two years before that.
The counterintuitive part is where the control sits. For most enterprises, the thing standing between a client list and a public chatbot is software installed on an employee's laptop. On 5 August 2026, Anthropic moved that control off the laptop entirely.
What are inference hooks?
Inference hooks are a Claude Enterprise feature that routes every governed prompt to a security server your organisation controls, which returns an allow or deny verdict before the model begins generating. A denied request never reaches Claude. The check runs on Anthropic's servers rather than on employee devices, so nothing is installed locally.
Anthropic announced the feature in beta on 5 August 2026 for Claude Enterprise organisations. According to the Anthropic product announcement, one configuration covers chat, Claude Code, Claude Cowork and other Claude Enterprise surfaces at the same time.
The strategic point is not the feature. It is the location of the checkpoint. Enforcement that lives on a managed device only governs managed devices. Enforcement that lives between the request and the model governs every request, whatever the employee is using.
Why does the position of the checkpoint matter so much?
Device-based controls fail at the edges of your estate: personal laptops, contractor machines, mobile browsers and any surface your endpoint agent has not reached. Research cited in the 2026 shadow AI literature found 77% of employees paste company data into generative AI tools, and 82% of those actions happen through personal, unmanaged accounts.
That gap is the whole problem. A department head can approve an enterprise AI licence, publish an acceptable-use policy and still have no technical mechanism that stops a regional sales manager pasting a customer file into a chat window from a home machine.
Moving the checkpoint server-side changes the coverage question from "which devices did we manage?" to "which requests did we govern?". That is a materially easier question to answer in a board paper or a regulator's enquiry.
It also changes who owns the control. The verdict is issued by your security server, not by the model vendor. Your compliance team writes the rule, and the vendor enforces the answer.
How do inference hooks actually work?
A user submits a prompt. Anthropic sends an HTTPS POST containing the conversation transcript to your organisation's security server. Your server evaluates the content and returns a JSON verdict within a configurable timeout, five seconds by default. On allow, inference proceeds. On deny, the request is rejected and logged.
The sequence, as set out in the Claude Platform documentation, has five operational details a technology leader should be able to repeat back:
--- Requests are signed. Each call follows the Standard Webhooks specification so your server can verify the request genuinely came from Anthropic.
--- The default verdict timeout is five seconds. Your organisation sets the value.
--- Failure handling is a policy choice. If your server is unreachable or slow, your configuration decides whether the request is blocked or allowed through uninspected. That single setting is the difference between availability risk and data risk.
--- Tool calls are checked too. Responses from tools reached through MCP connectors, skills and plugins are inspected before they return to the model.
--- Denials are recorded. Every blocked request lands in the organisation's compliance Activity Feed, alongside the reason your server supplied.
Rollout is staged rather than binary. Shadow mode observes verdicts on live traffic without blocking anything, a rollout percentage inspects a chosen fraction of requests, and role-based exclusions exempt chosen groups entirely.
What can inference hooks not do?
Three limitations are published and material. Image-only content is not inspected, because raw file and image bytes are never sent to your server. Verdicts are allow or deny only, with no redaction or rewriting. Voice mode, ancillary requests such as title generation, and API access through the Claude Platform are outside the scope.
The first limitation is the one that will surprise a compliance officer. A screenshot of a client contract passes through as an image, and your security server receives metadata and extracted text rather than the picture itself.
The second matters for user experience. A DLP tool that can redact a national identity number lets work continue. A tool that can only deny stops the work and generates a support ticket.
The third matters for coverage claims. If part of your organisation reaches Claude through Amazon Bedrock or Google Cloud, inference hooks do not apply there. A control that covers most of your traffic is a good control. Describing it to your board as covering all of it is a governance error.
Response-side enforcement is described as planned rather than shipped. Today the only hook event fires before inference, on the prompt.
How is this different from after-the-fact compliance logging?
Inference hooks act inline and prevent. A compliance or audit API acts afterwards and records. One stops a regulated record from reaching a model; the other tells you, later, that it did. Most enterprises need both, and most currently have only the second.
The distinction determines what you can tell a regulator. An audit log lets you report an incident accurately. An inline control lets you say the incident was prevented.
It also determines cost. Retrospective discovery of a personal-data exposure triggers assessment, notification and remediation work. Prevention costs a policy rule and some latency.
If you already run a DLP programme through Netskope, Palo Alto Networks, Proofpoint or Zscaler, the practical question is narrower than "should we buy something new". It is whether your existing inspection point can accept a webhook and return a verdict inside your timeout.
What does this mean for Hong Kong enterprises under the PDPO?
Hong Kong's Privacy Commissioner published a Checklist on Guidelines for the Use of Generative AI by Employees on 31 March 2025, and completed a third round of AI compliance checks covering 60 organisations in 2026. Inline enforcement gives Hong Kong organisations a technical answer to the checklist's central requirement: defining and controlling permissible use.
The PCPD's checklist asks organisations to identify which generative AI tools are approved, define permitted use cases, assign reviewers for high-risk uses, and audit AI use regularly. Every one of those is a policy statement that has historically been enforced by training and trust.
According to the Privacy Commissioner's May 2026 media statement, the 2026 compliance checks found no contravention of the Personal Data (Privacy) Ordinance among the organisations examined. That is a reasonable outcome, and it is not a reason to relax. The volume of AI traffic inside Hong Kong enterprises is rising far faster than the governance layer around it.
The Hong Kong Productivity Council's AI Readiness in Workplace Survey 2025 reported that 88% of employees at surveyed Hong Kong companies already use AI tools in daily work, concentrated in customer service, data analysis and marketing. Those are precisely the functions that handle personal data.
For a fuller treatment of the local regulatory picture, see UD's earlier analysis of what the 2026 PDPO compliance checks mean for Hong Kong enterprises and the related guide to shadow AI as a governance risk.
How should you decide whether to turn inline enforcement on?
Four questions decide it. Do you have a security server or DLP vendor that can return a verdict in under five seconds? Have you agreed a failure policy? Can your business tolerate deny-only outcomes? And do you have a defensible list of what should be blocked, rather than an aspiration?
Question one is an infrastructure question. If your DLP inspection currently runs as a batch process, it cannot serve an inline verdict, and the project starts with latency engineering rather than policy.
Question two is a risk-appetite question that belongs to the executive, not the engineer. Fail-closed protects data and creates an availability dependency on your own server. Fail-open protects productivity and creates an inspection gap precisely when your infrastructure is degraded. There is no neutral setting.
Question three is a change-management question. Because verdicts cannot redact, every false positive becomes a blocked employee. Shadow mode exists so you can measure that rate before anyone is stopped.
Question four is the one most organisations skip. A rule set inherited from email DLP will flag material that is entirely appropriate to discuss with an assistant, and will miss the categories that matter in an AI context, such as unreleased financials pasted for summarisation.
What goes wrong when organisations deploy this badly?
Five failure patterns recur: enforcing on day one without shadow mode, reusing email DLP rules unchanged, leaving failure handling on the default without an executive decision, claiming complete coverage while parts of the estate reach the model elsewhere, and treating the compliance log as an accepted control that nobody reads.
The first is the most damaging politically. An organisation that switches on blocking without measuring false positives will generate a wave of blocked requests in week one, and the feature will be switched off before it proves anything.
The second is the most common technically. Email DLP patterns were tuned for documents leaving the perimeter, not for conversational text where an employee describes a client situation in their own words.
The third is a governance failure disguised as a configuration default. If nobody signed off fail-open, nobody owns the gap it creates.
The fourth is a reporting failure. Coverage claims should name the surfaces in scope and the surfaces out of scope, in the same sentence.
The fifth is the quietest. Denial records that nobody reviews are evidence that a control existed, not evidence that it worked.
What should you do in the next 30 days?
Inventory which AI surfaces your organisation actually uses and which are governed. Ask your DLP vendor whether it can serve inline verdicts. Make failure handling an executive decision with a named owner. Run shadow mode for a full business cycle before enforcing anything.
Order matters. The inventory comes first because a control you cannot scope is a control you cannot report on. The vendor conversation comes second because it determines whether this is a configuration exercise or an engineering project.
The executive decision on failure handling comes third, and it should be minuted. When an inspection server times out at 09:30 on a Monday, the question of whether work stops is not one an on-call engineer should answer alone.
Shadow mode comes last and takes the longest. A month-end close generates different prompts from a quiet Tuesday, and a false-positive rate measured over three days will not survive contact with your reporting cycle.
The wider lesson is the one Hong Kong leaders have been circling for two years. AI governance stopped being a policy document the moment employees gained the ability to move regulated data in a sentence. Controls that sit between the request and the model are how the policy becomes real.
We understand AI. We understand you. With UD by your side, AI never feels cold.
Inference hooks: the facts in brief
Availability
--- Beta, Claude Enterprise organisations only. Announced 5 August 2026.
--- Not available on Amazon Bedrock or Google Cloud. Claude Platform API organisations are out of scope.
Coverage
--- One organisation-level configuration governs chat, Claude Code and Claude Cowork, on web, desktop and CLI.
--- Tool responses from MCP connectors, skills and plugins are inspected. Voice mode is not covered.
Mechanics
--- Default verdict timeout: 5 seconds, configurable.
--- Verdict values: allow or deny. Redaction is not supported.
--- Requests signed per the Standard Webhooks specification.
--- Failure handling configurable: block or allow uninspected.
Rollout controls
--- Shadow mode, percentage-based rollout, role-based exclusions.
--- Denials recorded in the compliance Activity Feed with a reason.
Reviewed by the UD enterprise AI team. UD has advised Hong Kong organisations on infrastructure, security and AI deployment since 1998.
Take the next step with UD
Knowing where the control should sit is the easy part. Deciding what your organisation can safely deploy, and in which environment, is the work. UD builds AI into isolated, monitored enterprise environments, and we'll walk you through every step, from readiness assessment and tool selection to secure deployment and ongoing oversight.
