Saltar para o conteúdo principal
Você está colocando um LLM na frente de informações de saúde protegidas — um assistente de triagem, um sumarizador de notas clínicas, um chatbot voltado ao paciente — e precisa de uma postura defensável antes que ele veja PHI real. Esta página é o checklist para um deploy de IA para HIPAA no gateway hospedado (api.orcarouter.ai): os controles que você pode ligar no seu workspace hoje, e os poucos que ficam do seu lado da linha.
O OrcaRouter não é a sua covered entity, e ligar o pack HIPAA não é “estar em conformidade com HIPAA.” O gateway lhe dá salvaguardas técnicas que você configura e evidência que você pode entregar a um auditor. Um Business Associate Agreement (BAA) assinado, sua própria infraestrutura, treinamento de pessoal e controles físicos são responsabilidade da sua organização — o relatório de compliance os divulga como gaps em vez de fingir que o gateway os cobre. Veja §6.

​
1. O que um deploy de IA para HIPAA cobre no gateway

O pack de framework HIPAA mapeia um punhado de cláusulas das Security e Privacy Rules sobre controles que o gateway pode de fato aplicar no caminho de relay — Guardrails para o texto e o Firewall para o egress de ferramenta. Instalar o pack materializa esses controles como linhas de guardrail e firewall reais e editáveis no seu workspace.
Cláusula (45 CFR)Controle do gateway
§164.502(b) Minimum NecessaryRedigir PHI em prompts e saídas
§164.514(b) De-identificationBloquear de forma rígida os identificadores HIPAA nas requisições
§164.312(b) Audit controlsRegistrar cada decisão de guardrail
§164.312(e) Transmission securityNegar egress de ferramenta para ranges privados / de metadata
Tudo abaixo é configurado a partir do console (ou da API REST) sob a sua sessão de workspace — nada disso muda o código do seu agente, e as rotas de configuração são controladas por papel.

​
2. Instale o pack HIPAA

Navegar pelo catálogo e checar prontidão está aberto a qualquer Member e é gratuito. Instalar um pack é uma ação de Admin do workspace e exige um plano pago — é controlado pelo servidor de qualquer forma. 
# Admin · UserAuth session (NOT a relay sk-orca- key)
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>"
Em um passo isto materializa os quatro controles mapeados como linhas de guardrail e firewall que você pode então abrir e editar — instaladas em observe mode, de modo que nada aplica enforcement até você levar o pack ao ar. Você pode fazer o mesmo a partir de Console → Compliance → HIPAA → Install.
Cheque GET /api/compliance/readiness antes e depois do install para ver quais cláusulas estão cobertas, quais ainda são gaps e para o que cada uma mapeia. Readiness é um endpoint legível por Member e gratuito — compartilhe-o com quem for dono da auditoria.

​
3. Redija PHI antes que o modelo a veja

O controle phi_redaction do pack semeia um guardrail que bloqueia identificadores de saúde dos EUA no stage input — números NPI, códigos ICD-10, códigos de medicamento NDC e números de registro DEA — usando regex ancorado em contexto para que um número de dez dígitos perdido não o dispare. Sobreponha um PII Shield por cima para mascarar os identificadores gerais (email, phone, SSN, IP e o resto do conjunto de entidades embutido) para tags tipadas como [SSN] antes que a requisição deixe o gateway. Prove a regra na aba Test do editor antes de vinculá-la a uma chave: 
Input:  "Patient NPI 1234567890, dx ICD-10 J18.9, reply to jane@acme.com"
Verdict: blocked (medical_phi_block) · email → [EMAIL]
A máscara no stage input está disponível; a máscara ao vivo de output/streaming não está. O PII Shield mascara a requisição antes que o modelo upstream sequer a veja. Em respostas, uma ação de block é aplicada tanto em output streaming quanto não-streaming, mas mask no output atualmente é somente não-streaming. Se você precisar de PHI limpa da saída do modelo sobre um stream hoje, faça block em vez de mask, ou rode em não-streaming — e prove a sua combinação exata de stage/stream no sandbox primeiro. Veja a referência de guardrails.

​
4. Negue egress de PHI e registre cada decisão

Dois dos quatro controles HIPAA são sobre o que acontece depois que o texto está limpo:
O pack escreve uma regra de deny de firewall na superfície egress com uma deny list concreta de host/CIDR pré-preenchida — loopback, link-local / cloud-metadata (169.254.0.0/16) e os ranges privados RFC1918 / IPv6-ULA — para que uma ferramenta não possa silenciosamente enviar PHI para um endpoint interno. Você não precisa criar os CIDRs; você pode ampliar ou apertar as listas de allow/deny em regras de firewall. O enforcement de egress dispara nas pernas outbound que a sua integração de gateway reporta como egress, então faça o rollout sob shadow mode primeiro para ver o que seria negado antes que mude o tráfego.
O controle de auditoria do pack registra cada decisão de guardrail no feed de Matches do workspace (GET /api/guardrail/match, Member). Por padrão o feed registra que uma regra disparou e sua string de detalhe mas não a substring correspondente — a postura conservadora de privacidade, que é o que você quer para PHI. Deixe Log raw content desligado a menos que você tenha uma necessidade específica de triagem, já que ligá-lo persistiria a própria PHI correspondente.
As decisões de firewall caem no feed de Events do workspace (Developer+) com seu veredito e superfície, então a camada de ação e a camada de conteúdo cada uma deixa uma trilha independente.

​
5. Fixe a residência do relatório e produza evidência assinada

Quando você gera um relatório de compliance, sua região de residência de dados é uma propriedade do artefato de relatório — us, eu, uk, ap, cn ou global. Defina-a uma vez (Admin); leituras cross-region de um relatório fixado a uma região diferente são retidas. 
# Admin · set the residency region for compliance reports
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"}'
A residência aqui governa o artefato de relatório de compliance, não onde os seus dados de inferência são processados. Não é geo-fixação de PHI através do modelo — isso é uma questão de infraestrutura e BAA do seu lado. Não apresente o toggle de região a um auditor como localização de dados.
Um relatório gerado é assinado com Ed25519 e com hash SHA-256, então um auditor pode verificá-lo sem confiar na sua cópia:
  • Chave pública: GET /api/public/compliance/pubkey
  • Verificar um relatório: POST /api/public/compliance/verify
  • Compartilhar somente leitura com um auditor: GET /api/public/compliance/share/:token
Os relatórios exportam para CSV, JSON ou PDF. Gerar e ir ao ar com um pack (POST /api/compliance/packs/hipaa/golive) são ações pagas e controladas por Admin.

​
6. O que permanece sua responsabilidade

O pack é honesto sobre seus limites: o checklist HIPAA inclui cláusulas que o gateway não pode aplicar, e o relatório as divulga como gaps abertos em vez de silenciosamente marcar o framework 100% coberto.
Cláusula (45 CFR)Por que é sua
§164.308(b)(1) Business Associate AgreementsUm BAA é um contrato legal entre organizações — nenhuma configuração de gateway o assina.
§164.308(a)(5) Security awareness & trainingUm controle de pessoas-e-processos, fora do escopo da automação no caminho de relay.
Além dessas cláusulas divulgadas, a sua infraestrutura é sua: criptografia em repouso nos seus sistemas, gestão de acesso para o seu pessoal, resposta a incidentes e o próprio BAA. O gateway protege o tráfego; você protege a organização.

​
7. Retenção e direito ao apagamento

Dois padrões de plataforma importam para uma carga de PHI:
  • A retenção de request-log tem padrão de 30 dias e é limitada pelo servidor a um máximo rígido de 180 dias. Defina sua retenção por workspace não mais longa do que a sua política de mínimo necessário exige.
  • O apagamento é uma requisição de exclusão de conta self-service seguida de uma janela de carência de 30 dias, após a qual a PII é irreversivelmente limpa e as guardrail matches e request logs associados são purgados. Use isto para atender a uma requisição de apagamento de titular de dados de ponta a ponta.
O padrão do feed de Matches de não registrar conteúdo bruto correspondente (veja §4) impede que a trilha de evidência de-identificada se torne ela própria um repositório de PHI. Confirme que Log raw content está desligado em cada guardrail voltado a PHI.

​
8. Checklist de go-live

  • BAA assinado com a parte apropriada (sua responsabilidade).
  • Pack HIPAA instalado; readiness mostra os quatro controles cobertos.
  • medical_phi_block + PII Shield vinculados às chaves que a sua carga de PHI usa, e provados na aba Test.
  • Regra de firewall de egress-deny lançada sob shadow mode, depois aplicada uma vez que o feed de Events pareça certo.
  • Log raw content confirmado desligado nos guardrails de PHI.
  • Região de residência de relatório definida; retenção definida na sua janela de mínimo necessário.
  • Gaps organizacionais (treinamento, BAA) rastreados fora do gateway.

​
Relacionado

Referência de Guardrails

Entidades de PII, máscara, a aba Test e o feed de Matches em profundidade.

Referência de Firewall

Regras de egress, shadow mode e o feed de Events.

Evidência SOC 2

O mesmo fluxo de install → relatório → verificação para SOC 2.

Logging seguro de PII

Mantenha PHI fora dos seus próprios logs e do feed de Matches.

Pare a exfiltração

Crie os controles de egress por trás de §164.312(e).

Responsabilidade compartilhada

Exatamente onde a linha do gateway termina e a sua começa.