A healthcare startup came to us with a problem that every healthtech founder eventually hits: hospitals wouldn't talk to them without HIPAA and SOC2 compliance. Not "we'd prefer you were compliant." Not "we'll work with you while you get certified." Simply: no compliance, no conversation.
The startup had a working AI product. It solved a real problem. Hospital administrators were interested. But the moment procurement or compliance teams got involved, the conversation ended. The technical requirements for handling protected health information (PHI) were non-negotiable, and the startup's infrastructure didn't meet them.
We built the compliant platform. The startup secured multiple hospital partnerships on a timeline they estimated would have taken 8-10 months longer without it. I can't name them, but I can share every architectural lesson — because the mistakes we avoided and the decisions we made apply to any startup building AI for regulated industries.
The mistake most healthtech startups make
Most startups treat compliance as a layer you add on top of an existing system. They build the product first, then try to make it HIPAA-compliant afterward. This is like building a house and then trying to add a foundation under it.
HIPAA compliance isn't a set of features. It's a set of architectural constraints that need to inform every decision from the first line of code. The encryption requirements, access controls, audit logging, data residency rules, and breach notification obligations aren't things you can bolt onto an existing system — they need to be baked into the system's design.
When we started the engagement, the startup's existing system had several fundamental issues that couldn't be patched:
Data at rest wasn't encrypted with customer-managed keys. The data was encrypted — their cloud provider handles that by default — but HIPAA requires you to demonstrate control over encryption keys. Provider-managed encryption isn't sufficient for most hospital compliance reviews.
Audit logs were incomplete. The system logged user actions but didn't log system-level data access — which model accessed which patient data, when, and why. HIPAA requires an audit trail for every access to PHI, including automated access by ML models.
No data isolation between customers. In a multi-tenant SaaS, Hospital A's patient data and Hospital B's patient data were stored in the same database, separated only by application logic. One bug in the query layer could expose one hospital's data to another. For HIPAA, this is unacceptable.
ML model training used raw PHI. The training pipeline ingested raw patient data. In a compliant system, you need to demonstrate that model training either uses de-identified data or has appropriate safeguards around PHI access.
Each of these required fundamental re-architecture, not a patch.
The architecture we built
Encryption as a first principle
Every piece of data — at rest and in transit — is encrypted with keys managed through a dedicated key management service. Each hospital customer gets their own encryption key. If a hospital terminates their contract, their key is destroyed and their data becomes cryptographically unreadable.
This sounds simple, but the implementation details matter enormously. The ML pipeline needs to decrypt data for processing, which means the training infrastructure needs access to encryption keys, which means you need granular access controls on who and what can request decryption. We built a key access layer that grants time-limited decryption permissions for specific operations and logs every key access event.
Tenant isolation at the infrastructure level
We moved from logical multi-tenancy (one database, separated by application code) to physical multi-tenancy (separate data stores per customer). Each hospital's data lives in its own encrypted storage namespace. The application layer physically cannot query across namespaces — it's not a permission issue that could be bypassed by a bug, it's an architectural boundary.
This increases infrastructure complexity, but it makes the compliance conversation with hospitals dramatically easier. Instead of explaining your application logic, you can say: "Your data is in a separate, encrypted store. Other customers' application code can't reach it."
Comprehensive audit logging
Every access to PHI generates an immutable audit log entry: who or what accessed the data, when, what data was accessed, and for what purpose. This includes ML model inference — when a model processes patient data to generate a prediction, the audit system logs which model version, which patient record, and what prediction was generated.
The audit logs themselves are stored in a write-once, append-only system. They can't be modified or deleted, even by system administrators. This is critical for compliance audits — the integrity of your audit trail is the foundation of your compliance posture.
Privacy-preserving ML pipeline
The training pipeline was redesigned with a clear separation between PHI and model artifacts. Raw patient data is used for feature engineering, but the features themselves are de-identified before they enter the training pipeline. The trained model never contains raw PHI — it contains learned patterns from de-identified features.
This required careful feature engineering to ensure that de-identified features still carry enough signal for the model to learn effectively. In some cases, we used differential privacy techniques to add noise to features while preserving statistical properties. In other cases, we restructured features so they represent distributions or aggregates rather than individual patient records.
The result: we can demonstrate to auditors that the trained model artifact doesn't contain PHI, which simplifies the compliance requirements for model deployment, version control, and backup.
Access controls with least-privilege defaults
Every person and every system component has the minimum access necessary for their function. Engineers can access the codebase but not patient data. The model serving system can read model artifacts but not training data. The training system can access de-identified features but not raw PHI unless an audited, time-limited exception is granted.
This least-privilege architecture means a compromised component exposes only what that component was authorized to access. It's the difference between "an attacker got into our system and accessed everything" and "an attacker compromised one service and could only see de-identified feature statistics."
What the SOC2 audit looked like
SOC2 Type II certification requires demonstrating that your security controls work consistently over a period of time — usually 6-12 months. We designed the system so that every SOC2 control requirement was addressed by an architectural decision, not a policy document.
Auditors don't want to read your security policy and trust that you follow it. They want to see systems that enforce the policy automatically. When an auditor asks "how do you ensure that only authorized personnel access PHI?", the answer shouldn't be "we have a policy." The answer should be "the system architecturally prevents unauthorized access, and here's the audit log proving it."
By building compliance into the architecture rather than into policies, we made the audit process significantly smoother. The evidence was in the system logs, not in employee training records.
The business impact
The hospital partnerships that followed weren't just because the compliance boxes were checked. They were because the startup could walk into procurement meetings and demonstrate a level of technical maturity that gave hospital compliance teams confidence.
When a hospital compliance officer reviews your system and finds customer-managed encryption, physical tenant isolation, immutable audit logs, and privacy-preserving ML — they don't just approve your application. They trust you. And trust is what unlocks the partnership.
The 8-10 months the startup saved wasn't just about building faster. It was about building right the first time, so they didn't have to rebuild when compliance requirements surfaced.
What to know if you're building for healthcare
Start compliant. Don't add it later. If you know you'll need HIPAA compliance, architect for it from day one. The re-architecture cost is always higher than the build-it-right cost.
Physical isolation is easier to explain than logical isolation. Hospital compliance teams are not software engineers. "Your data is in a separate encrypted container" is easier to get approved than "our application logic prevents cross-tenant access." Both might be equally secure, but one is dramatically easier to sell.
Your audit trail is your compliance posture. If you can't prove it happened (or didn't happen), it doesn't matter. Invest in comprehensive, immutable audit logging before you invest in anything else.
De-identify before you train. The intersection of ML and healthcare compliance is where most healthtech startups get stuck. Design your ML pipeline so model artifacts don't contain PHI, and you'll avoid the hardest compliance questions.
Budget 30% more time than you think. Compliant systems take longer to build. Not because compliance is hard, but because the right way to build them is more careful, more deliberate, and more thoroughly tested than a non-compliant system.
Want help with your AI stack?
If this post matches problems you're seeing, we can map the fastest path from architecture decisions to production outcomes.
Talk to Manmeet
Manmeet Singh
Founder & CEO, AIshar Labs · Ex-Apple, Ex-Instacart · 15 AI Patents
Built ML systems at Apple (Search: Maps, Safari, Spotlight) and Instacart (Search, Recommendations, Ranking). Writes about production AI tradeoffs and system design.
Follow on LinkedIn →