The AI Trust Framework. Three questions every CFO should ask.
Most healthcare AI pitches collapse on three questions: where does the model run, what data does it see, how is its decision auditable. Vendors that cannot answer all three should not be touching claims, codes, or credentials. We built the suite so the answers are documented before the question is asked. This page walks the three questions in order, with the architecture, the controls, and the HIPAA §164.312 mapping.
If a vendor cannot answer these three, the AI does not belong in your stack.
The three questions look simple. The full answer is engineering, contracts, and audit telemetry. Each question below is expanded with the implementation evidence the vendor should be willing to produce on request.
Where does the model run?
If the answer is a vendor cloud you do not have a BAA with, the conversation should stop. PHI cannot legally enter a cloud boundary that is not under HIPAA contractual coverage. The honest version of this question has three parts: where does the inference happen, who has signed a BAA along the path, and is the BAA chain documented end to end.
Every AI call in our suite runs in HIPAA-eligible AWS infrastructure. Inference goes to foundation models under signed BAAs with zero-retention enabled. Internal classifiers run on AWS-managed compute we control. There is no shadow path. There is no SaaS vendor cloud we forgot to put in the data-processing inventory. The LLM Gateway is the single boundary between our application code and any foundation model, and every call through it logs which BAA boundary the call crossed.
This matters in three operational moments. Diligence: the vendor list with BAAs is one query, not a coordination exercise across security and procurement. Incident response: if a sub-processor has a breach, we know exactly which calls were in scope. Audit: the model-call inventory is real telemetry, not a reconstructed answer to a regulator question.
- All inference inside HIPAA-eligible AWS. Reference architecture documented for client review under NDA.
- BAAs signed with AWS, Anthropic, Twilio, NPDB, CAQH. Sub-processor inventory updated monthly.
- Zero-retention configurations enabled on every foundation-model account. No prompt logging on the provider side.
- LLM Gateway log captures the BAA boundary, sub-processor, and account ID for every model call.
What data does it see?
The vendor that wants to improve the model on your data is the vendor whose contract you read carefully. The vendor that masks PHI by default and only reveals it under an audited request is the vendor you can defend in front of compliance. The default state of the system tells you everything about whose interests the system was designed to serve.
PHI in our suite is encrypted at rest with AES-256-GCM. Sensitive identifiers (SSN, Tax ID, full date of birth, NPI in sensitive contexts) are masked by default in API responses. Revealing them requires hitting a dedicated reveal endpoint, which writes to a PHI access log with actor, role, IP address, and timestamp on every call. The reveal log is queryable by tenant and is reviewed in the same audit cadence as the application audit log.
On training: client data does not train shared models. The clause is in every client BAA and every sub-processor BAA. Our internal classifiers (denial-pattern recognition, document-type detection, line-item matching) retrain only on data that has been explicitly permissioned and PHI-scrubbed first. The default training posture is opt-out. Opt-in is a deliberate, contractual event with a documented data-use limitation. There is no shadow data lake collecting client prompts for a future training run.
- AES-256-GCM PHI encryption at rest with HMAC integrity tags on sensitive columns.
- Mask-by-default API responses on SSN, Tax ID, DOB, sensitive NPI contexts. Revealing requires the dedicated endpoint.
- PHI access log records actor, role, IP, timestamp, and target column on every reveal call. Reviewed weekly.
- Zero-retention enabled with every foundation-model provider. Provider does not retain prompts or train on them.
- Internal classifier retraining is opt-in only, with explicit data-use limitations in the contract.
How is its decision auditable?
An AI suggestion without source evidence is a guess with a model name attached. The only AI worth running in a regulated environment is AI that shows its work, every time, against the chart, the rule, the regulation, and the model version that produced the output. The audit trail is not a separate feature. It is the same view your validating specialist sees.
Every model output in our suite carries five pieces of metadata: the model version, the prompt version, the input it received (scrubbed and stored), the source evidence (MEAT documentation for HCC, payer rule text for denials, source document line for credentialing), and the confidence score. The audit log is queryable by case, by date range, by model version, by prompt version, by user, and by purpose. When a specialist confirms or rejects a suggestion, the validation event is logged against the specific model version. Per-version accuracy is tracked. When a new version regresses on a class of cases, the router rolls back automatically while we investigate.
Regulatory teams have asked us to reproduce a specific HCC code from 11 months prior. We were able to show the exact input, the exact prompt version, the exact model version, the exact MEAT evidence the model relied on, and the exact specialist who validated it. That is what we mean by auditable. The audit trail is the product, not a marketing feature.
- Every output carries model version, prompt version, scrubbed input, source evidence, and confidence score.
- Audit log queryable by case, date, model version, prompt version, user, and purpose. Tenant-isolated.
- Per-version accuracy tracking. Automatic router rollback on regression against the prior version.
- Specialist validation event logged against the specific model version. Per-validator accuracy visible.
- Regulatory reproducibility tested annually. Specific code retrieval target is sub-five-minute end to end.
The LLM Gateway. Four layers, one choke point.
The Gateway is the one place every AI call must pass through. Application code does not talk to a foundation model directly. It sends a structured request to the Gateway with a purpose tag. The Gateway scrubs PHI on the way in, routes by purpose to the right model, pins the prompt version from the registry, enforces the rate limit for the tenant, makes the upstream call, captures the audit log, and returns the structured response with the model version and confidence score attached.
The result is a single boundary for every AI interaction. One audit log answers every regulator question. One cost meter answers every CFO question. One prompt registry answers every model-risk question. When a new control is required, we add it once at the Gateway, not eight times across eight model integrations.
Twelve technical controls. Mapped to §164.312 and §164.308.
HIPAA technical safeguards are not aspirational for the suite. The implementations below are wired into application code, infrastructure-as-code, and the LLM Gateway. Each control maps to a specific regulatory requirement and each one is verifiable by your audit team during diligence.
Access control: unique user identification
Every actor in the system has a unique identifier. RBAC roles enforce minimum necessary access. Row-level security per tenant in the database layer. Service accounts have machine-only identities with rotation.
Access control: automatic logoff
Session timeout at 30 minutes of inactivity. Refresh tokens rotate on use. Sensitive endpoints require step-up authentication. Reveal endpoints require step-up plus reason-for-access capture.
Access control: encryption and decryption
AES-256-GCM at rest with HMAC integrity tags on PHI columns. Per-tenant data keys wrapped by a key-encryption key in AWS KMS. Key rotation quarterly. Decryption requires authenticated, authorized, audited access.
Audit controls: application log
Every user action and every system action writes to the application audit log with actor, action, target, timestamp, and outcome. Logs are tenant-isolated. Retention is seven years. Queryable from a single console.
Audit controls: PHI access log
Every PHI reveal call is captured separately with actor, role, IP, timestamp, target column, and reason for access. Reviewed weekly by the privacy lead. Anomaly thresholds alert on unusual access patterns.
Audit controls: LLM Gateway log
Every model call captures purpose, tenant, tokens in, tokens out, latency, model version, prompt version, BAA boundary, and cost. Queryable for the entire suite from one console. The foundation of cost, audit, and model-risk reporting.
Integrity: HMAC tags on PHI columns
PHI columns carry HMAC integrity tags computed at write time and verified at read time. Tag mismatch triggers an integrity incident, blocks the read, and pages the on-call engineer. Tampering is detectable.
Person or entity authentication
Multi-factor authentication required for every interactive user. Service-to-service authentication uses RS256-signed credentials issued by the credential service. Token TTL is short. Revocation is one click.
Transmission security: TLS 1.2+
TLS 1.2 minimum. TLS 1.3 preferred. HSTS enforced. Certificate transparency monitored. Internal service mesh uses mutual TLS. No plaintext PHI ever crosses a network boundary.
Transmission security: integrity controls
Every API response carries an HMAC signature over the response body. CSP headers locked down. X-Frame-Options DENY. X-Content-Type-Options nosniff. Replay protection on sensitive endpoints with nonce and timestamp.
Information system activity review
Audit log review is a scheduled weekly task. PHI access log is reviewed by the privacy lead. LLM Gateway log is reviewed by the model-risk lead. Findings are tracked to closure in the security ticketing system.
Contingency plan: backup and recovery
Point-in-time recovery enabled on all databases. Cross-region snapshots daily. Quarterly recovery drills with documented RTO and RPO. Tenant-isolated restore tested.
Frequently asked questions: the AI Trust Framework.
What is the AI Trust Framework?
Why does Where the model runs matter so much?
What does mask by default mean and why is it important?
What is the LLM Gateway and what does it actually do?
How does the suite map to HIPAA §164.312 technical safeguards?
Does my data train any shared model?
Can I see the LLM Gateway audit log on my own data?
How does the framework handle a model that produces a bad output?
Bring your security team. We bring the architecture review.
A 60-minute architecture review with our security and model-risk leads. Walk the LLM Gateway, the audit logs, the PHI access controls, and the HIPAA mapping. The deliverable is a written response to your diligence questionnaire. Useful whether or not you hire us.