The Clinical Frontier · 26 September 2026 · Issue 010 Anthropic’s new data infrastructure layer converts DPDP-compliant clinical AI in India from a policy aspiration into a practical engineering problem.
In this issue
- Anthropic’s Enterprise Frontier Safeguards, announced September 1, 2026, introduces zero data retention, customer-owned activity logs, and customer-managed encryption for Claude API customers in regulated industries, with healthcare explicitly included.
- The immediate Indian healthcare use case this enables: AI-powered clinical de-identification, stripping patient identifiers from discharge summaries, referral letters, lab reports, and clinical notes before those records are used for research, analytics, or national registry submissions.
- The specific compliance barrier this clears: under the DPDP Act 2023, using an external AI API to process patient records is a data processing event requiring documented safeguards. EFS makes those safeguards auditable and hospital-controlled, not dependent on Anthropic’s internal policies.
- A practical four-step de-identification pipeline buildable today on Claude Fable 5 or 5.1 under the interim zero data retention arrangement.
What shipped
Anthropic Enterprise Frontier Safeguards, announced September 1, 2026, addresses the most common objection enterprise regulated-industry customers raise when deploying Claude on sensitive data: who at the vendor can see it, where it goes, and how long it is retained.
EFS bundles three controls, each opt-in independently:
- Zero data retention. Text submitted to the API is not retained by Anthropic after the response is returned. No Anthropic staff review the content. The zero data retention arrangement on Fable 5 and Fable 5.1 is available to eligible customers immediately as an interim measure while full EFS deploys in phased rollout through fall 2026.
- Customer-owned log storage. Activity logs route to the enterprise’s own cloud account: Amazon S3, Azure Blob Storage, or Google Cloud Storage. The hospital controls the bucket, the access policies, and the audit trail.
- Customer-managed encryption. The organisation provides its own encryption keys. Anthropic operates automated safety monitoring against the log stream without holding the keys to the underlying content.
The customer’s compliance team receives safety alerts directly, with no Anthropic human in the loop. Supported deployment paths include Claude Platform, Claude Enterprise, Claude Code, Amazon Bedrock, Claude Platform on AWS, Google’s Agent Platform, and Microsoft Foundry. Healthcare is explicitly listed among the regulated industries EFS targets.
The Indian clinical data problem
Indian hospitals and health systems hold large, largely unexploited volumes of clinical text. Discharge summaries, referral letters, operation notes, radiology and pathology reports, nursing notes, and outpatient encounter records accumulate across hospital information systems, often in free-text narrative fields where the clinically meaningful content sits.
This data has real secondary value: research on disease patterns and treatment outcomes, training data for clinical AI models, quality indicator calculation, and population-level submissions to national registries including NCRP (cancer) and ABDM-linked quality reporting programmes.
The barrier is consistent. Under the DPDP Act 2023 (No. 22 of 2023, enacted August 11, 2023), health records are personal data. Processing them beyond the purpose of direct patient care requires either patient consent for the secondary purpose or a recognised legitimate use. When that processing is performed by a third-party AI system, the third party is a Data Processor and must operate under a data processing agreement covering purpose limitation, data minimisation, and appropriate technical safeguards. The DPDP Rules 2025, notified by MeitY on November 13, 2025, formalise these obligations.
Many hospital legal and compliance teams have treated this framework as a reason to avoid AI-on-patient-data workflows entirely. The underlying concern is not the AI model itself but the residual footprint: who at the AI vendor can see the notes, how long are they retained, and where are the logs stored?
EFS gives direct, auditable answers to each of those questions.
How EFS changes the compliance calculation
Retention. Zero. After the API call returns, Anthropic does not hold the submitted text. This addresses the data minimisation obligation directly.
Human access to content. None required. Safety monitoring runs as an automated pattern-detection process against the customer-owned log stream. Clinical notes do not go in front of Anthropic staff for review.
Log location. The hospital’s own cloud account, in whatever region the hospital selects. Amazon S3, Azure Blob Storage, and Google Cloud Storage all operate in Indian regions (Amazon’s ap-south-1 in Mumbai, Azure’s Central and South India, GCP’s asia-south1 in Mumbai). A hospital using any of these providers can ensure its activity logs stay within India.
Encryption control. The hospital holds the keys for log storage. Anthropic’s safety detection is fully automated; Anthropic staff do not review individual records.
This converts the data governance question from “can we trust Anthropic’s internal controls?” to “can we configure and audit our own cloud bucket?” The second question is within a typical hospital IT team’s operational scope.
A practical de-identification pipeline
A DPDP-ready de-identification workflow for Indian clinical text has four stages.
Stage 1: Pre-extraction and scoping. Retrieve clinical documents from the HIS or document management system under a documented purpose (the specific research scope, the registry submission type, or the analytics programme). Apply document-level access controls so only records within the approved cohort or consent group enter the pipeline. Log the retrieval with a local audit entry per document.
Stage 2: AI-powered identifier removal. Pass each document to Claude Fable 5 or 5.1 via the API with a structured de-identification prompt. Instruct the model to identify and replace: name, address, phone number, Aadhaar number, PAN, MRD number, treating physician name, family member names, and exact dates of birth (replaced with year only or shifted by a consistent per-patient random offset to preserve temporal relationships within a record). Under the current interim ZDR arrangement, text is not retained by Anthropic after the API call returns.
Stage 3: Sampling review. A clinical informatics or data governance reviewer checks a defined fraction of the de-identified output (typically 5 to 10 percent) against the source documents to confirm identifier removal and check for quasi-identifier leakage: rare diagnoses combined with narrow age bands, specific facility references, or unusual treatment sequences that could enable re-identification. This step is not optional for a DPDP-compliant workflow.
Stage 4: Metadata scrubbing and documentation. Strip document metadata (author fields, creation timestamps, revision history) before the de-identified output leaves the secure processing environment. Record the de-identification method, the sampling review result, and the processing date in the data governance log for the dataset.
What this pipeline does not do
It does not replace a Data Processing Agreement. Before any patient data flows to Claude, even under EFS, the hospital must have a signed DPA with Anthropic covering purpose limitation, data minimisation, sub-processor terms, and incident notification. The DPA is the legal foundation; EFS is the technical implementation that supports it.
Zero data retention does not equal anonymisation. Removing identifiers from text reduces but does not eliminate re-identification risk, particularly for rare conditions, small facilities, or unusual clinical episodes. A documented risk assessment for the specific secondary use is required. De-identification is not a one-size outcome; it is a risk reduction step.
This does not handle handwritten records. Physical paper notes and handwritten discharge summaries require OCR or manual transcription before entering the pipeline. Accuracy of upstream transcription directly affects de-identification completeness: an identifier missed in OCR will not be caught by the model.
The takeaway
Enterprise Frontier Safeguards removes the single most common technical objection to deploying Claude on Indian clinical data: the absence of a verifiable, hospital-controlled data governance layer. Zero data retention combined with customer-owned log storage and customer-managed encryption means the hospital’s compliance team can audit the entire processing path without depending on Anthropic’s internal access controls alone.
De-identification is the right entry point for this capability. The task is well-defined (remove a defined set of identifier types), the secondary-use value is clear (research, quality analytics, registry submissions), and the DPDP framework makes the requirement explicit: secondary processing of personal data needs either consent or a legitimate use with documented safeguards. EFS operationalises those safeguards.
The pipeline can be built on Fable 5 or 5.1 today under the interim ZDR arrangement. Full EFS, with customer-owned storage and managed encryption in phased deployment through fall 2026, is the window to complete the DPA, establish the data governance framework, and validate de-identification accuracy on a representative sample of the hospital’s own clinical text before the workflow goes live at scale.
The Clinical Frontier is a daily briefing from HCITExperts. More tomorrow.