Skip to content
VeriSwarm
Acerca de
DocumentaciónPreciosHabilidad del agente
Iniciar sesiónRegistrarse
  1. Inicio
  2. /Healthcare
  3. /Hipaa compliant ai agents
VeriSwarm
  • English
  • ✓ Español
  • Deutsch
  • Français
  • Italiano
  • Português
  • 日本語
  • 한국어
  • 简体中文

Producto

  • Precios
  • Documentación
  • API
  • Habilidad del agente
  • Especificación OATS

Confianza

  • Centro de confianza
  • Seguridad
  • Cumplimiento
  • Estado
  • Registro de cambios

Empresa

  • Acerca de
  • Blog
  • Código abierto
  • Inversionistas
  • Prensa

Legal

  • Términos
  • Privacidad
  • SLA
  • DPA
  • Accesibilidad
Para responsables de privacidad, cumplimiento y BISO que despliegan agentes con acceso a PHI.

Un agente de IA compatible con HIPAA empieza
en el límite de la tokenización.

No existe un interruptor que haga que un agente de IA cumpla con HIPAA. Lo que reduce la exposición ante un análisis de riesgos de la OCR es tokenizar el PHI antes de que llegue a un LLM o a una llamada de herramienta, y conservar la prueba de que ocurrió. VeriSwarm Guard tokeniza el PHI en el límite usando detección NER de Presidio — reemplazando SSN, MRN, nombres y otros identificadores por tokens tipados antes de que el modelo o la herramienta posterior vean el valor original — y Vault encadena cada evento de tokenización en un libro de auditoría a prueba de manipulaciones. Ambas son funciones del plan Max. Ninguna certifica el cumplimiento por sí sola; consulte qué no cubre esto más abajo.

Empezar gratis — con puntuación de confianza incluidaVer el mapa completo de prioridades de la OCR

Por qué el PHI es más difícil de controlar cuando interviene un agente

Un clínico humano que escribe en un EHR es un actor conocido y auditable dentro de un sistema que usted ya gobierna. Un agente de IA que gestiona el mismo flujo de trabajo enruta el PHI por lugares por los que un humano nunca pasaría: la API de inferencia de un proveedor de LLM, una llamada a una herramienta de terceros, el registro de solicitudes de una integración, una traza de depuración. Cada salto es un nuevo lugar por el que puede filtrarse el PHI, y la mayoría de ellos quedan fuera de los controles de acceso que un análisis de riesgos HIPAA tradicional fue diseñado para cubrir.

  • PHI incrustado en un prompt enviado a un LLM de propósito general que no está contratado bajo un BAA.
  • Un identificador de paciente transmitido sin modificar a través de una llamada de herramienta a una integración de programación de citas, facturación o CRM.
  • PHI en bruto que persiste en registros de solicitudes o en la memoria de conversación más allá de la interacción que lo generó.
  • Un agente que escala o reintenta una llamada fallida y reenvía PHI a un proveedor de respaldo que nadie revisó.

Nada de esto requiere un infiltrado humano ni un atacante externo. Es lo que ocurre cuando un agente hace exactamente lo que se le indicó, a una velocidad y escala que hacen imposible la revisión manual.

Tokenizar el PHI en el límite

La tokenización de PII de Guard se ejecuta antes de que el texto salga del límite — antes de llegar a un LLM, antes de llegar a una llamada de herramienta. La detección NER de Presidio analiza el texto saliente en busca de valores con forma de PHI y reemplaza cada uno por un token tipado y limitado a la sesión. El modelo y la herramienta posterior solo llegan a ver el token.

POST /v1/suite/guard/pii/tokenize
{
  "text": "Patient SSN 555-12-3456, MRN 88213, call at 917-555-0199",
  "ttl_seconds": 3600
}

→ {
  "tokenized_text": "Patient SSN [VS:SSN:a1b2c3], MRN [VS:ID:d4e5f6],
                      call at [VS:PHONE:g7h8i9]",
  "session_id": "sess_...",
  "tokens_created": 3
}

Los tokens se resuelven a sus valores originales únicamente mediante una llamada de rehidratación independiente, limitada a la misma sesión, y solo cuando una operación de escritura posterior realmente necesita el valor real — por ejemplo, un sistema de programación que tiene que marcar un número de teléfono real. Cada rehidratación es en sí misma un evento que el tenant puede auditar.

El rastro de auditoría que realmente exige un análisis de riesgos

El patrón de aplicación de la OCR de HHS en 2026 tiene una causa raíz constante: no realizar un análisis de riesgos preciso y exhaustivo, la mayor categoría de medidas de aplicación con una diferencia amplia sobre cualquier otra causa combinada. Un análisis de riesgos es tan sólido como la evidencia que lo respalda — y un registro editable es evidencia débil.

Vault encadena cada evento de tokenización, cada rehidratación y cada decisión del agente con un enlace SHA-256 a su predecesor. Una llamada de verificación recorre toda la cadena e informa exactamente dónde se rompe, si se rompe:

GET /v1/suite/vault/verify

→ {
  "ok": true,
  "events_verified": 41_902,
  "first_event_id": "evt_...",
  "last_event_id":  "evt_...",
  "errors": []
}

Un inventario de PHI por tenant (GET /v1/suite/guard/phi-inventory) agrega las mismas señales de tokenización en un informe por tipo de PHI, por agente y por nivel de sensibilidad al estilo HIPAA — respondiendo a la pregunta que un análisis de riesgos debe responder primero: por dónde está fluyendo realmente el PHI a través de la flota de agentes.

Qué no cubre esto

Ser directos sobre el límite aquí importa más que el discurso de ventas. La tokenización de PHI y el libro de auditoría de Vault no son una certificación de cumplimiento HIPAA, una opinión legal ni un sustituto de un análisis de riesgos formal. Activarlos no hace que una entidad cubierta o un asociado de negocio cumplan con HIPAA. HIPAA sigue exigiendo un análisis de riesgos que realmente tenga en cuenta a sus agentes, el conjunto completo de salvaguardas técnicas de la Regla de Seguridad (cifrado, control de acceso, integridad, seguridad de transmisión), un Acuerdo de Asociado de Negocio con cada parte en la ruta de los datos — incluido el proveedor del modelo — y políticas y formación que existen fuera de cualquier pieza de software.

Lo que hace VeriSwarm es eliminar una brecha específica y de alto impacto: PHI que llega a un LLM o a una llamada de herramienta sin tokenizar, y un registro de auditoría que no puede demostrar que no fue editado después de los hechos. Todo lo demás en un programa de cumplimiento HIPAA — alcance, BAA, respuesta a incidentes, formación del personal — sigue teniendo que construirlo el equipo que despliega los agentes, con asesoría legal involucrada en cualquier cosa que afecte a una presentación formal o a un Plan de Acción Correctiva.

Preguntas frecuentes

¿Qué hace que un agente de IA sea "compatible con HIPAA"?

No existe una certificación de cumplimiento HIPAA que un proveedor pueda entregarle, ni una función de software que por sí sola haga que una entidad cubierta o un asociado de negocio cumpla. Lo que requiere un flujo de trabajo de agente de IA compatible con HIPAA es un análisis de riesgos que realmente tenga en cuenta al agente, PHI gestionado conforme a las salvaguardas técnicas de la Regla de Seguridad (control de acceso, controles de auditoría, integridad, seguridad de transmisión), y un Acuerdo de Asociado de Negocio con cualquiera que toque PHI en su nombre — incluido el proveedor del modelo. El papel de VeriSwarm es más acotado y concreto: tokenizar el PHI antes de que llegue a un LLM o a una llamada de herramienta, y producir la evidencia de auditoría que realmente exigen un análisis de riesgos y un requisito de controles de auditoría de HIPAA.

¿Tokenizar el PHI antes de una llamada a un LLM satisface la Regla de Seguridad de HIPAA?

La tokenización respalda directamente dos salvaguardas técnicas de la Regla de Seguridad: control de acceso (el PHI nunca llega a un sistema — incluido un LLM de terceros — que no debería verlo) y controles de auditoría (el §164.312(b) exige mecanismos de hardware, software o procedimiento que registren y examinen la actividad en sistemas que contienen ePHI). Por sí sola no satisface el conjunto completo de salvaguardas técnicas — el cifrado en tránsito y en reposo, los controles de integridad, la seguridad de transmisión y un BAA firmado con cada parte en la ruta de los datos siguen teniendo que estar implementados de forma independiente.

¿Cómo tokeniza VeriSwarm el PHI en las llamadas de herramienta de un agente?

El endpoint de tokenización de PII de Guard (POST /v1/suite/guard/pii/tokenize) ejecuta detección NER de Presidio sobre el texto saliente y reemplaza los valores detectados — SSN, MRN, nombres, números de teléfono, direcciones — por tokens tipados como [VS:SSN:a1b2c3], limitados a una sesión con un TTL configurable (1 hora por defecto, máximo 24). El texto tokenizado es lo que llega al LLM o a la herramienta posterior. Una llamada de rehidratación independiente restaura los valores originales solo cuando una operación de escritura realmente los necesita, y cada rehidratación es en sí misma un evento auditable.

¿Qué ocurre con el rastro de auditoría después de tokenizar el PHI?

Cuando Vault está activado, cada evento de tokenización y rehidratación se escribe en un libro encadenado por hash — cada evento se enlaza con el hash de su predecesor, de modo que cualquier edición retroactiva rompe la cadena de forma visible. GET /v1/suite/vault/verify recorre toda la cadena y devuelve ok: true/false con el evento exacto donde falla la verificación, si falla. Ese es el artefacto que un análisis de riesgos o una revisión de controles de auditoría de la OCR pueden verificar, en lugar de confiar en un registro no verificable.

¿La tokenización de PHI está disponible en el plan gratuito?

No. La tokenización de PHI forma parte de Guard, y el libro de auditoría inmutable es Vault — ambas son funciones del plan Max (299 $/mes), no incluidas en el nivel gratuito de Gate. El nivel gratuito de Gate cubre la puntuación de confianza de agentes, la ingesta de eventos y las verificaciones de decisión; la gestión de PHI y el rastro de evidencia encadenado por hash requieren Max.

¿Usar VeriSwarm elimina la necesidad de un Acuerdo de Asociado de Negocio?

No. Un BAA es un instrumento legal entre una entidad cubierta y cualquiera que cree, reciba, mantenga o transmita PHI en su nombre — esa obligación no desaparece porque un control técnico reduzca la exposición. Si las llamadas de herramienta de su agente, el proveedor del LLM o la infraestructura tocan PHI, esas relaciones siguen necesitando BAA vigentes, haya o no tokenización.

Lecturas relacionadas

Si la OCR ya ha abierto una revisión o ha solicitado un Plan de Acción Correctiva, el paquete de evidencia es distinto al de un análisis de riesgos preventivo — consulte Aplicación del análisis de riesgos de la OCR y agentes de IA. Para conocer el mapeo completo de las prioridades de aplicación de la OCR en 2026 con las capacidades de VeriSwarm, empiece en VeriSwarm para el sector salud.

Vea la tokenización de PHI aplicada a su propio tráfico de agentes

Una demostración guiada de 30 minutos, en vivo con su propia flota — no con datos de demostración. Guard y Vault son funciones del plan Max; la puntuación de confianza en sí es gratuita.

Crear cuenta gratuitaLeer el mapa de prioridades de la OCR