HIPAA by architecture.

ChironAI is HIPAA-aligned in a way that survives inspection. That is the claim. The reason the claim survives inspection is that the structural commitments behind it are architectural rather than promotional. This essay describes what the difference is, and what a CMIO and a CISO can sign comfortably as a result.

The shape of the institutional question

Every institutional buyer of clinical AI asks the same question first: does my patient data train your model? The honest answers vary. Some vendors train continuously on customer data with consent language buried in the agreement. Some train on de-identified extracts under a policy that could be revised. Some claim not to train at all.

ChironAI does not train on customer data. Eve-Genesis (Clinical Edition) is 100% synthetic by construction. The customer-data-in-training question is solved at the dataset layer. There is no policy promise to revise because there is no path by which customer data could enter the training pipeline. The corpus generator takes published clinical guidelines, peer-reviewed literature, structured reasoning templates, and taxonomy ontologies as inputs. It does not take patient data as input. That is verifiable by inspection of the dataset and the generator.

Why this matters past the policy line

A policy commitment can change. An architectural commitment cannot, without rewriting the architecture. The distinction is the part a CISO is being asked to sign for.

A platform that says “we will not train on your PHI” is making a promise that depends on the operator’s discipline. The promise is only as strong as the controls. A platform that says “our training pipeline is structurally incapable of consuming your PHI” is making a different kind of statement. The structural statement is enforceable by inspection. The pipeline can be examined. The corpus can be examined. The fact that no patient data is in either is not a discipline claim but a construction claim.

The four commitments that follow

Synthetic-by-construction is the foundational commitment. From it, four further commitments follow as architectural properties rather than as separate promises.

First: no PHI in training. This is the dataset-level commitment. Eve-Genesis (Clinical Edition) contains no patient data. There is no de-identification process to second-guess, because there is no patient data being de-identified. The corpus is generated, not gathered.

Second: no PHI in evaluation. The held-out evaluation set used to qualify new LoRA adapters is also synthetic. Adapters ship if they hold up against the held-out traces; the held-out traces are no more derived from patient data than the training traces. The evaluation is auditable by inspection.

Third: no model exfiltration of PHI. Even if a deployed model encounters PHI at inference time, the training pipeline does not see it. The runtime does not write encounter data back into the corpus. There is no feedback path from production to training that is shaped to consume identified data. Adapters are re-fitted on the synthetic corpus on a quarterly cadence; no identified path is in the loop.

Fourth: tenant-level isolation enforced at the data layer. Every clinical-data row in the application carries a tenant identifier. PostgreSQL Row-Level Security policies enforce isolation at the database, independently of application logic. Cross-tenant disclosure is prevented at the layer where prevention is auditable, not at the layer where it is convenient.

Beyond the dataset layer

The architectural posture extends past the corpus into the runtime. Every clinical action writes to a tamper-evident audit chain — HMAC + previous-hash — that is verifiable end to end. Every signed document carries a SHA-256 hash captured at signature time; subsequent modification fails verification. The AB 489 / SB 1120 gate is enforced architecturally, not as a UI banner that can be styled away.

These properties are not separable from the substrate posture. A platform that fine-tunes on patient interactions and says “we protect PHI” is performing a contradiction. The training pipeline either consumes PHI or it does not. We chose the construction in which it does not, and the trust posture is what follows.

What this lets a CMIO and a CISO sign

A CMIO is asked to attest that the platform’s outputs hold up clinically. A CISO is asked to attest that the platform’s data posture holds up legally and operationally. Both attestations are easier to make when the underlying claims are architectural rather than promotional. The CMIO can read the methodology and verify the substrate. The CISO can read the data-handling commitments and verify the dataset. Neither is being asked to take a discipline claim on faith.

The architectural commitments are what make the procurement signature responsible. We designed the architecture to make the signature easier. The whole arrangement is meant to be inspected, not just trusted.

Read the data-handling commitments in detail on the data handling page, and the underlying methodology in the Eve-Genesis (Clinical Edition) whitepaper.