As the Principal Engineer at Arya Health, Anand Naidu stands at the high-stakes intersection of healthcare staffing and cutting-edge artificial intelligence. In a landscape where a single misplaced line of code can lead to a multi-million dollar HIPAA violation, his expertise in managing clinician recruitment and EMR integration platforms is indispensable. This conversation dives into the complex architecture of data privacy, exploring why the promise of Zero Data Retention is often more nuanced than marketing departments suggest. We examine the specific hurdles of deploying agentic AI in a regulated environment, the structural differences between major cloud providers like Google and specialized AI labs like Anthropic, and the practical governance steps engineering leaders must take to protect patient information in 2026.
When a developer is deep in the zone and pastes a function into an AI tool to fix a scheduling bug, there is often a moment of uncertainty regarding where that data actually goes. How should engineering leaders interpret the concept of Zero Data Retention in this high-pressure context?
The term “Zero Data Retention” often feels like a warm security blanket, but in practice, it is more of a complex contractual framework than a simple “off” switch for data storage. When your team is handling something as sensitive as a Medicaid eligibility window, you have to realize that true ZDR means the provider processes the data in real-time and discards it immediately, leaving no trace in prompt logs or training sets. However, what we are seeing across the industry is a “contractual ZDR” that typically requires manual negotiation and is only accessible to enterprise-tier customers. Even then, there are significant “safety monitoring” carve-outs; for instance, if a session is flagged for a violation, that data might be held for up to two years. It is a sobering thought for any CTO to realize that ZDR is not an absolute guarantee of ephemerality, and importantly, it is not synonymous with HIPAA compliance—you can have one without the other, and neither happens by accident.
Looking specifically at the tools that have become staples in our development workflows, like Claude Code, what are the specific nuances or “gotchas” that healthcare technology teams need to be wary of before a full-scale rollout?
Claude Code is undeniably one of the most powerful agentic tools we have right now, but its application in healthcare requires a very specific, high-touch setup. You cannot simply sign up for a few seats and assume you are protected; Anthropic’s HIPAA-ready offerings are explicitly tied to direct commercial contracts via their API, and standard bundled seats usually fall outside this umbrella. We have to be incredibly careful with the Files API as well, because those uploaded files—think care plans or lab reports—are retained until they are explicitly deleted, regardless of your ZDR agreement. Furthermore, if your team enables metrics logging for cost tracking, that specific data is exempted from ZDR protections, which can create a silent leak of metadata. It is also vital to remember that accessing Claude through AWS Bedrock or Google Vertex AI changes the entire compliance posture, moving you toward architectural isolation and cloud-specific Business Associate Agreements rather than a direct relationship with Anthropic.
OpenAI remains a dominant force with Codex and ChatGPT Enterprise, but there seems to be a significant divide between their consumer-facing products and their enterprise-grade security. Where does the risk lie for a dev team trying to stay agile?
The biggest risk is the “shadow AI” factor, where developers use personal ChatGPT accounts on healthcare codebases because they are faster or more familiar. Research shows that roughly 38% of employees have shared confidential company data with unapproved AI tools, often through these unsanctioned accounts which offer zero contractual safeguards. Even with a sanctioned OpenAI Enterprise tier, ZDR is not a self-serve feature; you have to specifically request approval, and even then, it typically only applies to the local CLI and IDE extensions. If your team delegates tasks to Codex cloud agents, that traffic moves through OpenAI-hosted containers where tasks run outside the ZDR protection window. It is a classic trap where the tool feels the same to the developer, but the underlying data retention policy changes completely based on whether the workload is local or cloud-hosted.
Google Vertex AI seems to take a different path by building privacy into the platform’s DNA rather than offering it as a tiered add-on. How does this structural approach change the way we build HIPAA-compliant workloads?
Google’s approach is fundamentally different because their privacy commitment is baked into the platform: they won’t use your data to train models without permission, and this applies to the managed models in the Vertex Model Garden, including Claude. For a team at Arya Health, this means HIPAA support is not a premium “add-on” but a baseline covered by the Google BAA, which simplifies the legal hurdle significantly. However, even this “safe” route has technical nuances, such as the default 24-hour Time to Live for data cached in-memory to reduce latency. While this caching is intended to boost performance, a truly paranoid security posture requires you to go into the project level and manually disable it. It’s a great example of how “secure by default” still requires a knowledgeable engineer to turn the final key to ensure no patient data lingers for even a single day.
As we move toward more autonomous agent workflows in 2026, where the AI is actually executing code and handling bulk processing, where are the failure modes that might break an otherwise solid ZDR posture?
The transition to production agents is where the real “silent” failures happen, especially when you are building pipelines for care coordination or claim processing. While the standard Messages API is usually ZDR-eligible, common patterns like using the Batch API for nightly eligibility recalculations will break your compliance because it has a standard 29-day retention policy. We also see teams getting excited about beta features, but those are almost categorically excluded from ZDR arrangements until they reach general availability. Even the code execution sandboxes used to test logic can retain container data for up to 30 days. The architectural rule we follow is simple: route every single PHI-adjacent inference through the Messages API, treat all beta features as “toxic” to regulated data, and never assume an automated workflow inherits the privacy settings of a manual prompt.
With the cost of healthcare data breaches now averaging $7.42 million per incident, what is your advice for our readers who are trying to balance the immense pressure to innovate with the absolute necessity of data privacy?
My advice is to stop treating AI governance as a secondary task and start treating it as a core architectural constraint. You must begin with a comprehensive audit of every AI tool in your ecosystem, assuming that anything not explicitly covered by a signed BAA is a liability for PHI-adjacent code. Do not let your team rely on “memory” or good intentions; implement technical controls like code review gates and network isolation that prevent sensitive data from ever leaving your secure environment. Understand that ZDR is a contractual relationship that requires an active opt-in and a high organizational tier, and keep in mind that the compliance rules from six months ago are likely already outdated. If you put your privacy architecture first and document every routing path—whether it’s direct to a provider or through a cloud-managed service like Bedrock—the speed and power of AI will follow naturally without putting your organization or your patients at risk.
