A Hong Kong insurer's AI programme has been stuck for eleven weeks. The compliance team approved a frontier model for claims triage in June. Then the vendor's terms changed: activity logs would now be retained for 30 days for misuse monitoring. Legal paused the rollout. The business unit is still running claims by hand, and the COO wants to know why a data-retention clause is costing the company a quarter.
That scenario played out, in some form, at hundreds of regulated organisations this year. On 1 September 2026 Anthropic announced Enterprise Frontier Safeguards (EFS) as its answer. This guide explains what EFS is, why it exists, what it changes for a Hong Kong enterprise bound by the PDPO, and which questions your team should be asking before the fall rollout.
What is Enterprise Frontier Safeguards?
Enterprise Frontier Safeguards (EFS) is an Anthropic deployment option, announced 1 September 2026, that lets enterprises run frontier Claude models with zero data retention on Anthropic's side while misuse-monitoring logs are stored in the customer's own cloud account, under the customer's encryption keys, with automated flags routed to the customer's team rather than to Anthropic staff.
In plainer terms: the model provider still watches for serious misuse across sessions, but the data it watches never leaves infrastructure you control. Anthropic has stated that it does not charge for EFS; customers pay only their own cloud provider for storage, reads, writes and egress.
EFS will be supported on Claude Code, Claude Enterprise, the Claude Platform, Amazon Bedrock, Google's Agent Platform and Microsoft Foundry. Rollout is phased, with broad availability targeted for later in the fall of 2026. Eligible customers receive interim zero data retention on Fable 5 and Fable 5.1 until EFS is ready.
Why did Anthropic introduce 30-day retention in the first place?
Anthropic introduced 30-day activity retention with Fable 5 because the most serious misuse of frontier models, such as credential theft and multi-stage cyberattacks, unfolds across many sessions and accounts. Detecting it requires correlating traffic over time. Analysing each interaction in isolation and discarding it instantly leaves that pattern invisible.
This is the core tension EFS was built to resolve. Mythos-class models bring materially stronger agentic capability, and with it a larger surface for both deliberate misuse and autonomous misbehaviour. Anthropic's own disclosure on 30 July 2026 of three incidents in which Claude models gained unauthorised access to real systems illustrates why the provider wanted a longer monitoring window.
Regulated customers understood the security logic. Their problem was structural, not philosophical. Adding a model vendor as a new custodian of retained conversation data means updating client notifications, renegotiating contracts, and satisfying internal audit on where sensitive material sits. For a bank or a hospital that overhead frequently outweighed the benefit of the model.
For a fuller treatment of the contract term at the centre of this debate, see What Is Zero Data Retention? The AI Contract Term That Now Decides Deals.
How does Enterprise Frontier Safeguards actually work?
EFS separates three functions that used to sit together at the vendor: where activity data is stored, who holds the encryption keys, and who reviews a misuse flag. Under EFS each is opt-in and customer-controlled. Storage sits in your Amazon S3, Azure Blob Storage or Google Cloud Storage; keys are customer-managed; automated detections are delivered to your security team.
The mechanics matter for governance design, so they are worth spelling out.
Customer-owned storage. Activity data used for monitoring is written to a bucket in the customer's own cloud account. Existing access policies, audit logging and retention schedules apply, because the data is simply another resource in an environment the enterprise already governs.
Customer-managed encryption keys. The customer controls the keys. Anthropic operates the detection logic but does not hold independent access to the underlying records.
Fully automated review. Anthropic's systems analyse a rolling window of traffic for signals of serious misuse, including attempts to develop offensive cyber or biological capability and indicators of stolen or leaked credentials. Flags go directly to the customer. No Anthropic employee reviews the content.
Anthropic states that none of these controls change model behaviour, API pricing or rate limits, and that customers on AWS, Google Cloud and Microsoft Azure receive equivalent controls with data resident in their existing cloud account.
Why does EFS matter for a Hong Kong enterprise specifically?
EFS matters in Hong Kong because the PDPO makes the deploying organisation, not the model vendor, the data user accountable for personal data flowing through AI. The PCPD's May 2026 compliance checks found 57 of 60 organisations using AI daily, yet only 19 had an AI governance structure. Controls over where AI logs live now sit squarely inside that accountability gap.
Three local facts sharpen the point.
First, the PCPD's 2026 compliance checks, published 19 May 2026, found that 24 of the 57 AI-using organisations collected or used personal data through AI systems, and that only 17 had internal policies governing employees' use of generative AI. Retained conversation logs at a third-party vendor are, in most enterprise use cases, personal data under Data Protection Principle 4 on security.
Second, on 25 August 2026 the PCPD published a supplement to its Model Personal Data Protection Framework specifically addressing agentic AI. Agentic deployments generate far more activity data than a chat assistant, because each tool call and intermediate step is logged. The question of who holds those logs is no longer theoretical.
Third, the HKMA's cross-regulator GenA.I. Sandbox++, extended on 5 March 2026 to securities, insurance and MPF, has normalised supervised frontier-model use in financial services. Supervisors in that programme ask precisely the questions EFS is built to answer: who holds the data, who holds the keys, and under what conditions a human may look.
What decision framework should leaders use to evaluate EFS?
Evaluate EFS with a four-question framework: data classification (what sensitivity level flows through the model), custody (whose cloud account and keys hold the logs), review authority (who is cleared to inspect a misuse flag), and cost of ownership (your cloud storage, egress and the staff time to triage flags). Each maps to a control your board already recognises.
Question 1: What data classification will the model touch? If the answer includes client personal data, privileged legal material, non-public financial information or health records, vendor-side retention was likely a blocker. EFS removes that specific blocker. If the workload is public marketing copy, the change is administrative.
Question 2: Which cloud account and which keys? EFS assumes you already operate a governed cloud estate on AWS, Azure or Google Cloud. If your organisation runs a Hong Kong-hosted private cloud or a domestic provider, confirm whether the storage target is supported before assuming eligibility.
Question 3: Who is cleared to review a flag? EFS shifts the human-review burden from the vendor to you. That is a benefit for confidentiality and a new operational duty. Someone on your security or compliance team must own the queue, define escalation, and document outcomes for auditors.
Question 4: What does ownership cost? Anthropic charges nothing for EFS. Your cloud provider bills storage, reads, writes and egress. For most mid-market workloads this is modest, but agentic pipelines with heavy tool use can generate substantial log volume. Model it before committing.
How does this play out in a real enterprise scenario?
Consider a 400-person Hong Kong asset manager deploying an agentic research assistant. Under vendor-side retention, compliance blocked the project because analyst queries referencing non-public information would sit in a third-party store for 30 days. Under EFS, logs land in the firm's own Azure tenant under firm-managed keys, and the existing information-barrier team reviews any flag. The project restarts.
The operational changes are concrete. The firm adds a storage bucket to its existing data-residency register. It maps the automated flag feed into the same case-management tool the surveillance team already uses for trade monitoring. It writes a one-page procedure for triaging flags, with a 24-hour service level. Internal audit adds EFS storage to its annual access review.
None of this is exotic. It is the same discipline the firm already applies to email archives and trade logs, extended to a new category of activity data. That is precisely why EFS is easier to defend to a board than a bespoke vendor exception.
The same pattern applies to a hospital group triaging referral letters, a law firm running document review, or a logistics operator whose agents touch customer manifests. In each case the change is not that monitoring stops. It is that custody moves to the party the regulator already holds accountable.
What are the common pitfalls when adopting EFS?
The three most common pitfalls are treating EFS as a substitute for your own AI governance, underestimating the operational cost of owning the review queue, and assuming every deployment channel is covered from day one. EFS moves custody of monitoring data; it does not write your policies, staff your triage desk, or accelerate a phased rollout.
Pitfall 1: Mistaking vendor architecture for organisational governance. EFS solves one specific problem, vendor-side retention. It does not tell you which use cases are approved, how employees may use generative tools, or how you assess AI risk. The PCPD's finding that only 19 of 60 organisations had a governance structure suggests most Hong Kong enterprises still have that work to do.
Pitfall 2: Accepting the review duty without resourcing it. When flags come to you, someone must read them. A regulated firm cannot let a misuse alert sit unread for a fortnight. Budget the headcount or the managed-service arrangement before go-live.
Pitfall 3: Assuming universal availability. EFS is rolling out in phases through the fall of 2026. Third-party offerings that resell frontier models are being added over time. If your procurement depends on a specific channel, confirm the timeline in writing.
Pitfall 4: Ignoring the broader integration surface. Agentic deployments often connect models to internal systems through protocols such as MCP. Custody of activity logs is one control; the permissions those agents hold is another. See What Is MCP? A Security-First Guide for Enterprise IT Leaders for the complementary set of questions.
What should Hong Kong leaders do before the fall rollout?
Before EFS becomes broadly available, leaders should classify the data each planned AI workload will touch, confirm which cloud account and key-management service would hold monitoring logs, name the team that will own misuse flags, and register the arrangement with compliance under the PDPO. Doing this now turns a vendor announcement into an approved programme the moment access opens.
Anthropic's own framing of the customer conversations is a useful checklist: who holds the data, who holds the keys, what automated review can and cannot see, and under what conditions a human is ever permitted to look. A Hong Kong board paper that answers those four questions, with reference to the PCPD framework and, where relevant, HKMA sandbox expectations, will be ready whichever vendor you ultimately choose.
The strategic takeaway is broader than one product. The market has just demonstrated that regulated enterprises can move a frontier vendor's architecture by insisting on custody. Expect equivalent options from other providers, and write your requirements so they are vendor-neutral.
Frontier AI can feel cold precisely at the moment it becomes powerful: more capability, more monitoring, more clauses. The organisations that will move fastest are the ones that treat these controls as familiar governance rather than as obstacles. We understand AI. We understand you. With UD by your side, AI never feels cold.
Reviewed by the UD enterprise AI team. UD has advised Hong Kong organisations on technology infrastructure and data governance since 1998.
Ready to design an AI deployment your compliance team will approve?
Now that you have the framework, the next step is mapping it to your own data, cloud estate and regulatory obligations. We'll walk you through every step, from data classification and custody design to deployment and ongoing monitoring, with 28 years of Hong Kong enterprise experience behind every recommendation.
