What does a private AI reference architecture for healthcare look like?

Key facts

PHI boundary	Region pinning, VPC, on-prem or air-gapped deployment
HIPAA posture	HIPAA support on Enterprise with a BAA
PII controls	no-PII, detect-only and passthrough modes; no-PII default for embeddings
Identity	SSO/SCIM and RBAC to enforce minimum-necessary access
Audit	Per-request logs plus key/admin audit events, exportable to SIEM
Key custody	BYOK via cloud KMS or HSM; customer-controlled revocation
Imaging and audio	Image generation and audio endpoints are coming soon
Compliance posture	SOC 2 Type II and ISO 27001 readiness in progress (not yet certified)

TL;DR

• Keep PHI inside the clinical boundary you can defend.
• Redact identifiers at the gateway; send the minimum data the task needs.
• Log every access to PHI and test deletion down to derived vectors.
• Keep a clinician in the loop for anything affecting care.
• Confirm BAA coverage and residency before the first production patient record.

How it works, step by step

1. Classify workloads: administrative, research, clinical decision support and patient-facing.
2. Choose the boundary — region-pinned cloud, VPC, on-prem — per workload class.
3. Confirm BAA coverage and residency commitments before production data flows.
4. Redact identifiers in the gateway and enforce minimum-necessary prompts.
5. Connect SSO/SCIM and define role-based access for clinical and non-clinical staff.
6. Wire audit export and test access reviews, retention and deletion including vectors.
7. Add clinician review and a documented escalation path for model outputs.

Try it yourself

Open the AI data residency checklist →

Workload classes drive the design

• Administrative: coding, scheduling, claims and correspondence — usually the right place to start, with strict de-identification.
• Research: analysis over de-identified or consented datasets, often with aggregated outputs.
• Clinical decision support: requires the tightest boundary, full audit and clinician oversight; never expose raw PHI to a shared endpoint.
• Patient-facing: triage and navigation need guardrails against diagnosis, with clear escalation to humans.

Design each class separately. A single global deployment usually over-exposes research workloads or under-protects clinical ones.

Reference architecture for PHI

1. Gateway: redacts direct identifiers, enforces minimum-necessary context and logs every access.
2. Inference boundary: a region-pinned, VPC or on-prem deployment with no external data path.
3. Retrieval: clinical knowledge bases and document stores hosted inside the same boundary, with identifiers redacted at ingestion.
4. Identity: SSO/SCIM and RBAC so access follows clinical roles and leavers are deprovisioned automatically.
5. Keys and audit: BYOK or HSM custody, audit export to your SIEM, and alerting on anomalous PHI access.
6. Safety layer: clinician review, refusal paths and documented escalation for anything that influences care.

De-identification and its limits

De-identification is a spectrum, not a switch. Direct identifiers — names, medical record numbers, contact details — can be detected and removed with patterns and named-entity recognition. Indirect identifiers — rare conditions, dates, geography, employment — can still re-identify individuals in combination, so test with realistic data and involve privacy counsel on the standard you are claiming. For imaging and audio workflows, note that Plugsky's image generation and audio endpoints are coming soon; plan around text and vision-input chat models today, and do not promise generation features before they ship.

Governance and honest gaps

Healthcare diligence wants evidence: a data map, residency configuration exports, audit samples, retention and deletion schedules, role definitions and incident response. Record the gaps honestly — SOC 2 Type II and ISO 27001 are readiness in progress rather than completed certification, and HIPAA support is an Enterprise BAA arrangement rather than a blanket platform property. Keep the safety story credible: models assist, clinicians decide, and every output that influences care is attributable to a person. Contractual terms live at /legal/terms and service commitments at /legal/sla.

Honest comparison

Requirement	Plugsky for healthcare	General-purpose AI API	Self-hosted clinical model
PHI boundary	Region, VPC, on-prem, air-gapped	Shared endpoint with policy controls	Your data centre
HIPAA	BAA on Enterprise	Often unavailable or restricted	You operate the controls
PII controls	Gateway redaction plus three modes	Varies	You build detection
Audit	Request logs and SIEM export	Limited	Custom pipeline
Imaging/audio	Coming soon	Varies	Depends on weights
Certification status	SOC 2 / ISO 27001 readiness in progress	Varies	Your own programme

Frequently asked questions

Does Plugsky support HIPAA?

HIPAA support is documented on Enterprise with a Business Associate Agreement. Confirm BAA coverage, scope and residency during contracting before any production patient data flows.

Can PHI stay inside our network?

Yes. Choose a region-pinned deployment at minimum, or a VPC, on-prem or air-gapped deployment when the data path itself must remain inside your perimeter. The API stays OpenAI-compatible across tiers.

How should we redact identifiers?

Redact in your gateway before the model call, using patterns, named-entity recognition and allowlists, and enforce minimum-necessary context. Test with realistic clinical text, including Arabic and mixed-language content.

Are embeddings safe to store?

Embeddings derive from your text and inherit the same obligations. Keep them inside the boundary, include vector stores in retention and deletion, and keep sensitive corpora on the no-PII default.

Can we generate medical images or transcribe audio?

Not yet. Image generation and audio transcription are documented as coming soon. Build on chat completions, vision inputs and embeddings today, and keep generation features behind a flag.

What audit evidence do we need?

Per-request logs with model, region and request ID, plus audit events for key and admin actions, exported to your SIEM. Deletion evidence must cover prompts, logs and derived vectors.

How do we keep clinicians in the loop?

Define which outputs influence care, require review for those, provide refusal and escalation paths, and log the reviewing clinician alongside the model output so the decision path is attributable.

What are the main residual risks?

Re-identification of de-identified data, model errors in clinical contexts, and certification gaps. Mitigate with de-identification review, clinician oversight, private deployment and tracked compliance milestones.