Saltar al contenido principal
Estás poniendo un LLM frente a información de salud protegida — un asistente de triaje, un resumidor de notas clínicas, un chatbot de cara al paciente — y necesitas una postura defendible antes de que vea PHI real. Esta página es la lista de verificación para un despliegue de IA HIPAA en el gateway alojado (api.orcarouter.ai): los controles que puedes activar en tu espacio de trabajo hoy, y los pocos que se quedan de tu lado de la línea.
OrcaRouter no es tu entidad cubierta, y activar el pack HIPAA no es “ser conforme con HIPAA.” El gateway te da salvaguardas técnicas que configuras y evidencia que puedes entregar a un auditor. Un Business Associate Agreement (BAA) firmado, tu propia infraestructura, la formación del personal y los controles físicos son responsabilidad de tu organización — el informe de cumplimiento los divulga como huecos en vez de pretender que el gateway los cubre. Ver §6.

​
1. Qué cubre un despliegue de IA HIPAA en el gateway

El pack de marco HIPAA mapea un puñado de cláusulas de la Security Rule y la Privacy Rule a controles que el gateway puede aplicar realmente en la ruta de relay — Guardrails para el texto y el Firewall para el egress de herramientas. Instalar el pack materializa esos controles como filas de guardrail y firewall reales y editables en tu espacio de trabajo.
Cláusula (45 CFR)Control del gateway
§164.502(b) Mínimo necesarioRedactar PHI en prompts y salidas
§164.514(b) De-identificaciónBloquear de forma dura los identificadores HIPAA en las solicitudes
§164.312(b) Controles de auditoríaRegistrar cada decisión de guardrail
§164.312(e) Seguridad de transmisiónDenegar el egress de herramientas a rangos privados / de metadata
Todo lo de abajo se configura desde la consola (o la API REST) bajo tu sesión de espacio de trabajo — nada de ello cambia el código de tu agente, y las rutas de configuración están restringidas por rol.

​
2. Instala el pack HIPAA

Navegar el catálogo y verificar la disposición está abierto a cualquier Member y es gratis. Instalar un pack es una acción de Admin del espacio de trabajo y requiere un plan de pago — está restringido por servidor de cualquier 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>"
En un paso esto materializa los cuatro controles mapeados como filas de guardrail y firewall que puedes abrir y editar — instaladas en modo observe, así que nada aplica hasta que lleves el pack en vivo. Puedes hacer lo mismo desde Console → Compliance → HIPAA → Install.
Verifica GET /api/compliance/readiness antes y después de instalar para ver qué cláusulas están cubiertas, cuáles siguen siendo huecos y a qué mapea cada una. La disposición es un endpoint legible por Member y gratis — compártelo con quien sea que posea la auditoría.

​
3. Redacta PHI antes de que el modelo la vea

El control phi_redaction del pack siembra un guardrail que bloquea identificadores de salud de EE. UU. en la etapa de entrada — números NPI, códigos ICD-10, códigos de medicamento NDC y números de registro DEA — usando regex anclado por contexto para que un número de diez dígitos perdido no lo dispare. Superpón un PII Shield encima para enmascarar los identificadores generales (email, phone, SSN, IP, y el resto del conjunto de entidades integrado) a etiquetas tipadas como [SSN] antes de que la solicitud salga del gateway. Demuestra la regla en la pestaña Test del editor antes de adjuntarla a una clave: 
Input:  "Patient NPI 1234567890, dx ICD-10 J18.9, reply to jane@acme.com"
Verdict: blocked (medical_phi_block) · email → [EMAIL]
El enmascarado en la etapa de entrada está en vivo; el enmascarado de salida/streaming en vivo no. PII Shield enmascara la solicitud antes de que el modelo upstream la vea siquiera. En las respuestas, una acción de block se aplica tanto en salida streaming como no-streaming, pero mask en salida es actualmente solo no-streaming. Si necesitas PHI eliminada de la salida del modelo sobre un stream hoy, bloquea en vez de enmascarar, o ejecuta en no-streaming — y demuestra tu combinación exacta de etapa/streaming en el sandbox primero. Ver la referencia de guardrails.

​
4. Deniega el egress de PHI y registra cada decisión

Dos de los cuatro controles HIPAA tratan sobre lo que pasa después de que el texto está limpio:
El pack escribe una regla de firewall deny en la superficie egress con una lista de denegación de host/CIDR concreta pre-rellenada — loopback, link-local / cloud-metadata (169.254.0.0/16) y los rangos privados RFC1918 / IPv6-ULA — para que una herramienta no pueda enviar silenciosamente PHI a un endpoint interno. No tienes que autorar los CIDRs; puedes ampliar o ajustar las listas de allow/deny en reglas del firewall. La aplicación de egress se dispara en los tramos salientes que tu integración del gateway reporta como egress, así que lánzala bajo modo shadow primero para ver qué se denegaría antes de que cambie el tráfico.
El control de auditoría del pack registra cada decisión de guardrail en el feed de Matches del espacio de trabajo (GET /api/guardrail/match, Member). Por defecto el feed registra que una regla se disparó y su cadena de detalle pero no la subcadena coincidente — la postura conservadora de privacidad, que es lo que quieres para PHI. Deja Log raw content apagado a menos que tengas una necesidad específica de triaje, ya que activarlo persistiría la PHI coincidente misma.
Las decisiones de firewall aterrizan en el feed de Events del espacio de trabajo (Developer+) con su veredicto y superficie, así que la capa de acción y la capa de contenido cada una dejan un rastro independiente.

​
5. Fija la residencia del informe y produce evidencia firmada

Cuando generas un informe de cumplimiento, su región de residencia de datos es una propiedad del artefacto de informe — us, eu, uk, ap, cn o global. Establécela una vez (Admin); las lecturas inter-región de un informe fijado a una región diferente se retienen. 
# 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"}'
La residencia aquí gobierna el artefacto de informe de cumplimiento, no dónde se procesan tus datos de inferencia. No es geofijación de PHI a través del modelo — eso es un asunto de infraestructura y BAA de tu lado. No presentes el conmutador de región a un auditor como localización de datos.
Un informe generado está firmado con Ed25519 y con hash SHA-256, así que un auditor puede verificarlo sin confiar en tu copia:
  • Clave pública: GET /api/public/compliance/pubkey
  • Verificar un informe: POST /api/public/compliance/verify
  • Compartir de solo lectura con un auditor: GET /api/public/compliance/share/:token
Los informes se exportan a CSV, JSON o PDF. Generar e ir en vivo con un pack (POST /api/compliance/packs/hipaa/golive) son acciones de pago, restringidas a Admin.

​
6. Qué se queda como tu responsabilidad

El pack es honesto sobre sus límites: la lista de verificación HIPAA incluye cláusulas que el gateway no puede aplicar, y el informe las divulga como huecos abiertos en vez de marcar silenciosamente el marco como 100% cubierto.
Cláusula (45 CFR)Por qué es tuya
§164.308(b)(1) Business Associate AgreementsUn BAA es un contrato legal entre organizaciones — ningún ajuste del gateway lo firma.
§164.308(a)(5) Concienciación y formación de seguridadUn control de personas-y-procesos, fuera del alcance de la automatización en la ruta de relay.
Más allá de esas cláusulas divulgadas, tu infraestructura es tuya: el cifrado en reposo en tus sistemas, la gestión de acceso de tu personal, la respuesta a incidentes y el BAA mismo. El gateway asegura el tráfico; tú aseguras la organización.

​
7. Retención y derecho al borrado

Dos valores por defecto de la plataforma importan para una carga de trabajo de PHI:
  • La retención del registro de solicitudes por defecto es de 30 días y está acotada por el servidor a un máximo duro de 180 días. Establece tu retención por espacio de trabajo no más larga de lo que tu política de mínimo necesario requiere.
  • El Borrado es una solicitud de eliminación de cuenta autoservicio seguida de una ventana de gracia de 30 días, tras la cual la PII se limpia de forma irreversible y las coincidencias de guardrail y registros de solicitudes asociados se purgan. Usa esto para atender una solicitud de borrado de sujeto de datos de extremo a extremo.
El valor por defecto del feed de Matches de no registrar contenido coincidente en bruto (ver §4) evita que el rastro de evidencia de-identificado se convierta él mismo en un almacén de PHI. Confirma que Log raw content está apagado en cada guardrail de cara a PHI.

​
8. Lista de verificación de go-live

  • BAA firmado con la parte apropiada (tu responsabilidad).
  • Pack HIPAA instalado; readiness muestra los cuatro controles cubiertos.
  • medical_phi_block + PII Shield adjuntos a las claves que usa tu carga de trabajo de PHI, y demostrados en la pestaña Test.
  • Regla de firewall de denegación de egress lanzada bajo modo shadow, luego aplicada una vez que el feed de Events se vea bien.
  • Log raw content confirmado apagado en los guardrails de PHI.
  • Región de residencia del informe establecida; retención establecida a tu ventana de mínimo necesario.
  • Huecos organizacionales (formación, BAA) rastreados fuera del gateway.

​
Relacionado

Referencia de Guardrails

Entidades PII, enmascarado, la pestaña Test y el feed de Matches en profundidad.

Referencia de Firewall

Reglas de egress, modo shadow y el feed de Events.

Evidencia SOC 2

El mismo flujo de instalar → informe → verificar para SOC 2.

Registro seguro de PII

Mantén la PHI fuera de tus propios registros y del feed de Matches.

Detener la exfiltración

Autora los controles de egress detrás de §164.312(e).

Responsabilidad compartida

Exactamente dónde termina la línea del gateway y empieza la tuya.