Running clinical AI under HIPAA and GDPR at the same time

Health projects tend to arrive with both regimes attached. The client is European, the data is patient data, and somewhere in the chain there is a US partner. Teams often treat that as two compliance exercises. It is cheaper to treat it as one architecture question.

Two constraints settle most of it. Where the data physically sits: we run these workloads in Swiss and EU cloud isolation, which removes the transfer argument before it starts rather than documenting a justification for it afterwards. What the model is allowed to retain: zero training on client data, contractually, across every model vendor in the chain. This is the clause people assume is standard and frequently is not.

Sprints run on sanitised data with no connection to live patient records, which is covered separately.

None of this is exotic. It is ordinary architecture applied early, which is considerably less expensive than the same architecture applied after a risk review has already said no.

written here as an absolute across every vendor in the chain, so someone has to confirm that still holds before it ships. That is the H1 blocker on this piece.

Public vendor names already on the site, which is the list to check rather than an open-ended hunt: Azure OpenAI (`/pipeline`, xLongevity case), OpenAI and Anthropic and open-source (`/engagement` Run features). If any other model host is in the current chain, it is in scope too. Confirm or drop the absolute. Do not invent a yes from the copy on `/trust` alone.

"Why our sprints run on sanitised data", per the shared-facts-not-shared-jobs rule added on 26 August.