Vai al contenuto principale
Stai mettendo un LLM davanti a informazioni sanitarie protette — un assistant di triage, un riassuntore di note cliniche, un chatbot rivolto ai pazienti — e ti serve una postura difendibile prima che veda PHI reali. Questa pagina è la checklist per un deployment HIPAA AI sul gateway hosted (api.orcarouter.ai): i controlli che puoi attivare oggi nel tuo workspace, e i pochi che restano dal tuo lato della linea.
OrcaRouter non è la tua covered entity, e attivare il pack HIPAA non è “essere conforme a HIPAA”. Il gateway ti dà salvaguardie tecniche che configuri ed evidenza che puoi consegnare a un auditor. Un Business Associate Agreement (BAA) firmato, la tua infrastruttura, la formazione del personale e i controlli fisici sono responsabilità della tua organizzazione — il report di compliance li dichiara come gap anziché fingere che il gateway li copra. Vedi §6.

​
1. Cosa copre un deployment HIPAA AI sul gateway

Il pack del framework HIPAA mappa una manciata di clausole delle Security- e Privacy-Rule su controlli che il gateway può effettivamente applicare sul percorso di relay — Guardrails per il testo e il Firewall per l’egress dei tool. Installare il pack materializza quei controlli come righe di guardrail e firewall reali e modificabili nel tuo workspace.
Clausola (45 CFR)Controllo del gateway
§164.502(b) Minimum NecessaryRedigi le PHI nei prompt e negli output
§164.514(b) De-identificationHard-block degli identificatori HIPAA nelle richieste
§164.312(b) Audit controlsLogga ogni decisione del guardrail
§164.312(e) Transmission securityNega l’egress dei tool verso range privati / metadata
Tutto quanto segue è configurato dalla console (o dalla REST API) sotto la sessione del tuo workspace — niente di ciò cambia il codice del tuo agent, e le rotte di config sono role-gated.

​
2. Installa il pack HIPAA

Sfogliare il catalogo e controllare la readiness è aperto a qualsiasi Member ed è gratuito. Installare un pack è un’azione Admin del workspace e richiede un piano a pagamento — è server-gated in entrambi i casi. 
# Admin · sessione UserAuth (NON una chiave di relay sk-orca-)
curl -X POST https://api.orcarouter.ai/api/compliance/packs/hipaa/install \
  -H "Authorization: Bearer <your-console-access-token>" \
  -H "X-Workspace-Id: <workspace-id>"
In un passo questo materializza i quattro controlli mappati come righe di guardrail e firewall che puoi poi aprire e modificare — installati in observe mode, così nulla applica finché non porti il pack live. Puoi fare lo stesso da Console → Compliance → HIPAA → Install.
Controlla GET /api/compliance/readiness prima e dopo l’installazione per vedere quali clausole sono coperte, quali sono ancora gap, e su cosa mappa ciascuna. La readiness è un endpoint leggibile dai Member e gratuito — condividilo con chiunque possieda l’audit.

​
3. Redigi le PHI prima che il modello le veda

Il controllo phi_redaction del pack semina un guardrail che blocca gli identificatori sanitari US allo stage di input — numeri NPI, codici ICD-10, codici farmaco NDC e numeri di registrazione DEA — usando regex ancorate al contesto così un numero a dieci cifre vagante non lo fa scattare. Sovrapponi un PII Shield per mascherare gli identificatori generali (email, phone, SSN, IP, e il resto dell’insieme di entità integrate) in tag tipizzati come [SSN] prima che la richiesta lasci il gateway. Dimostra la regola nel tab Test dell’editor prima di collegarla a una chiave: 
Input:  "Patient NPI 1234567890, dx ICD-10 J18.9, reply to jane@acme.com"
Verdict: blocked (medical_phi_block) · email → [EMAIL]
Il masking allo stage di input è attivo; il masking live output/streaming non lo è. Il PII Shield maschera la richiesta prima che il modello a monte la veda mai. Sulle risposte, un’azione di block è applicata sia sull’output streaming sia su quello non-streaming, ma il mask sull’output è attualmente solo non-streaming. Se hai bisogno di PHI ripulite dall’output del modello su uno stream oggi, blocca anziché mascherare, o esegui in non-streaming — e dimostra prima la tua esatta combinazione stage/stream nella sandbox. Vedi il riferimento guardrails.

​
4. Nega l’egress di PHI e logga ogni decisione

Due dei quattro controlli HIPAA riguardano cosa succede dopo che il testo è pulito:
Il pack scrive una regola deny del firewall sulla superficie egress con una deny list di host/CIDR concreta pre-compilata — loopback, link-local / cloud-metadata (169.254.0.0/16), e i range privati RFC1918 / IPv6-ULA — così un tool non può silenziosamente spedire PHI a un endpoint interno. Non devi scrivere i CIDR; puoi allargare o restringere le liste allow/deny nelle regole del firewall. L’applicazione dell’egress scatta sulle tratte in uscita che la tua integrazione di gateway riporta come egress, quindi fai prima il rollout sotto shadow mode per vedere cosa verrebbe negato prima che cambi il traffico.
Il controllo di audit del pack registra ogni decisione del guardrail nel feed Matches del workspace (GET /api/guardrail/match, Member). Per default il feed registra che una regola è scattata e la sua stringa di dettaglio ma non la sottostringa corrispondente — la postura conservativa sulla privacy, che è ciò che vuoi per le PHI. Lascia Log raw content disattivato a meno che tu non abbia una specifica esigenza di triage, dato che attivarlo persisterebbe le PHI corrispondenti stesse.
Le decisioni del firewall finiscono nel feed Events del workspace (Developer+) con il loro verdetto e superficie, così il layer delle azioni e il layer dei contenuti lasciano ciascuno una traccia indipendente.

​
5. Fissa la residency del report e produci evidenza firmata

Quando generi un report di compliance, la sua regione di data-residency è una proprietà dell’artefatto del report — us, eu, uk, ap, cn, o global. Impostala una volta (Admin); le letture cross-region di un report fissato a una regione diversa sono negate. 
# Admin · imposta la regione di residency per i report di compliance
curl -X PUT https://api.orcarouter.ai/api/compliance/residency \
  -H "Authorization: Bearer <your-console-access-token>" \
  -H "X-Workspace-Id: <workspace-id>" \
  -H "Content-Type: application/json" \
  -d '{"region": "us"}'
La residency qui governa l’artefatto del report di compliance, non dove i tuoi dati di inferenza vengono elaborati. Non è geo-pinning delle PHI attraverso il modello — quello è una questione di infrastruttura e BAA dal tuo lato. Non presentare il toggle della regione a un auditor come localizzazione dei dati.
Un report generato è firmato con Ed25519 e con hash SHA-256, così un auditor può verificarlo senza fidarsi della tua copia:
  • Chiave pubblica: GET /api/public/compliance/pubkey
  • Verifica un report: POST /api/public/compliance/verify
  • Condividi in sola lettura con un auditor: GET /api/public/compliance/share/:token
I report esportano in CSV, JSON o PDF. Generare e andare live con un pack (POST /api/compliance/packs/hipaa/golive) sono azioni a pagamento e gated da Admin.

​
6. Cosa resta tua responsabilità

Il pack è onesto sui suoi limiti: la checklist HIPAA include clausole che il gateway non può applicare, e il report le dichiara come gap aperti anziché marcare silenziosamente il framework coperto al 100%.
Clausola (45 CFR)Perché è tua
§164.308(b)(1) Business Associate AgreementsUn BAA è un contratto legale tra organizzazioni — nessuna impostazione del gateway lo firma.
§164.308(a)(5) Security awareness & trainingUn controllo di persone-e-processi, fuori scope per l’automazione sul percorso di relay.
Oltre a quelle clausole dichiarate, la tua infrastruttura è tua: cifratura a riposo nei tuoi sistemi, gestione degli accessi per il tuo personale, incident response, e il BAA stesso. Il gateway protegge il traffico; tu proteggi l’organizzazione.

​
7. Retention e diritto alla cancellazione

Due default della piattaforma contano per un carico di lavoro con PHI:
  • La retention dei request-log è di default 30 giorni ed è clampata lato server a un massimo rigido di 180 giorni. Imposta la tua retention per-workspace non più lunga di quanto richiede la tua policy minimum-necessary.
  • La Cancellazione è una richiesta self-service di cancellazione dell’account seguita da una finestra di grace di 30 giorni, dopo la quale le PII vengono irreversibilmente ripulite e i guardrail match e request-log associati vengono purgati. Usa questo per servire una richiesta di cancellazione del soggetto dei dati end to end.
Il default del feed Matches di non loggare il contenuto grezzo corrispondente (vedi §4) impedisce alla traccia di evidenza de-identificata di diventare essa stessa uno store di PHI. Conferma che Log raw content sia disattivato su ogni guardrail rivolto alle PHI.

​
8. Checklist di go-live

  • BAA firmato con la parte appropriata (tua responsabilità).
  • Pack HIPAA installato; readiness mostra i quattro controlli coperti.
  • medical_phi_block + PII Shield collegati alle chiavi che il tuo carico di lavoro PHI usa, e dimostrati nel tab Test.
  • Regola di egress-deny del firewall fatta il rollout sotto shadow mode, poi applicata una volta che il feed Events sembra giusto.
  • Log raw content confermato disattivato sui guardrail PHI.
  • Regione di residency del report impostata; retention impostata alla tua finestra minimum-necessary.
  • Gap organizzativi (formazione, BAA) tracciati fuori dal gateway.

​
Correlati

Riferimento Guardrails

Entità PII, masking, il tab Test e il feed Matches in profondità.

Riferimento Firewall

Regole di egress, shadow mode e il feed Events.

Evidenza SOC 2

Lo stesso flusso install → report → verify per SOC 2.

Logging PII-safe

Tieni le PHI fuori dai tuoi log e dal feed Matches.

Fermare l'esfiltrazione

Scrivi i controlli di egress dietro §164.312(e).

Responsabilità condivisa

Esattamente dove finisce la linea del gateway e inizia la tua.