We have been building healthcare software since well before the current AI cycle — HIPAA-bound platforms with 2,048-bit encryption, e-prescribing, chronic care management, virtual consultations carrying live readings from medical instruments.
The most useful thing that work taught us is not about healthcare. It is about when you make certain decisions.
Compliance is an architecture decision, not a checklist
The common pattern is to build the product, then hand it to someone to make compliant. This produces one of two outcomes: a costly rewrite, or a thin layer of controls over an architecture that fundamentally cannot support them.
The reason is that the requirements are structural. Audit logging means every state change needs a recorded actor, timestamp and before-state — which affects how you write to the database everywhere. Access control means the permission model has to sit below the application logic, not beside it. Data minimisation means deciding what you never collect, which is a schema decision. Encryption at rest and in transit is straightforward. Encryption with key rotation and a defined recovery path is not, and it is not something you add on a Friday.
Make these choices at the start and they cost days. Retrofit them and they cost a version.
The failure mode nobody plans for
Most compliance thinking covers the malicious case — the breach, the unauthorised access. Real incidents in the systems we have worked on are more often mundane.
A support engineer needs to reproduce a bug and pulls production data into a test environment. An integration gets built quickly and logs a full request payload including a patient identifier. A report gets exported to a spreadsheet and emailed.
None of these are attacks. All of them are the system being used by people trying to do their jobs, in a way the design permitted. The lesson is that compliant systems are ones where the easy path is also the correct path. If doing it properly is inconvenient, someone will route around it, and they will be right to from their perspective.
Practically: seed test environments with synthetic data automatically, so nobody needs to copy production. Redact at the logging layer rather than trusting every call site. Build the export your users need, with the controls attached, so they do not build their own.
Release discipline is a safety property
On a system where a bad deploy sits between a patient and a doctor, the deployment pipeline is part of the clinical safety argument. We set up separate development, QA and production environments with CI/CD before feature work begins on this kind of project.
That is not engineering preference. It is the difference between a defect being caught in QA and a defect reaching a consultation.
The same reasoning applies well outside healthcare. A payments platform, a tax filing system, an operational due diligence tool used by institutional investors — anywhere the cost of a bad release is measured in something other than embarrassment.
Why this matters more now
AI systems have the same shape of problem and less established practice around it.
A retrieval system over internal documents is an access control problem wearing a new hat. If the retrieval layer does not enforce the same permissions as the application, you have built a mechanism for surfacing documents to people who should not see them — and it is worse than a traditional access bug because it surfaces content by relevance, which means it will find the sensitive document rather than a random one.
Model calls to third-party providers are a data residency question. Prompt logs are a retention question. An assistant that can answer clinical questions is a scope question with a defined escalation path, or it is a liability.
None of this is exotic. It is the same discipline, applied to a newer component. Teams treating AI features as experiments outside their normal compliance posture are creating the problem that takes eighteen months and a rewrite to fix.
What we do differently
We ask the compliance questions in the assessment, before the architecture is proposed. What data is involved, who may see it, where may it be processed, what has to be logged, how long is it retained, what is the deletion path.
Six questions. They take an afternoon, and they change the design.
That is the whole insight, and it is not sophisticated: the cost of compliance is almost entirely determined by when you ask about it. Early, it is a set of constraints that shape a design. Late, it is a rebuild.