---
title: "Centro de confianza — Hanah (US)"
description: "Centro de confianza de Hanah (Estados Unidos): las historias de los pacientes se almacenan en Estados Unidos. Controles de seguridad y privacidad, y proveedores de servicios del despliegue en EE. UU."
source: https://hanah.health/es/us/trust/
---

# Centro de confianza

Transparencia para profesionales sanitarios, titulares de clínicas y compradores institucionales. Esta página resume cómo trata Hanah la información sanitaria, qué proveedores de servicios intervienen en el despliegue de producción de y cómo se relaciona cada control de seguridad con las normas de seguridad, privacidad y notificación de brechas de HIPAA (Security, Privacy y Breach Notification Rules). Los indicadores de estado son una ayuda editorial temporal y se retirarán cuando cada elemento esté verificado en producción.

✅ Hecho 🔧 Implementado a medida

Resumen Controles Correspondencia con marcos normativos Proveedores de servicios Recursos

**A quién va dirigido:** clínicas, redes sanitarias, responsables de privacidad y equipos de seguridad informática que hacen la diligencia debida sobre Hanah. **De un vistazo:** este Centro de confianza resume los controles de seguridad de Hanah y los proveedores de servicios que intervienen en el despliegue de producción de . Las historias clínicas se almacenan en . El reconocimiento de voz se realiza con un proveedor especializado en Estados Unidos, y la redacción de borradores con IA con proveedores en Estados Unidos y en otros países donde tienen instalaciones, con condiciones que prohíben entrenar con tu contenido. La evidencia más detallada está en nuestro Security & Operations Handbook; la pestaña **Controles** describe cómo se implementa cada control.

### Controles de seguridad

Cifrado, control de acceso, segmentación de red, registros, copias de seguridad y recuperación ante desastres, y salvaguardas específicas para la IA, con un estado honesto en cada línea.

Ver controles →

### HIPAA relacionada con el RGPD (GDPR), ISO y SOC 2

Cada requisito de HIPAA junto a sus equivalentes en Australia, el RGPD, Nueva Zelanda, ISO/IEC 27001 y SOC 2, y el control de Hanah que lo cumple.

Ver correspondencia →

### Proveedores de servicios

Qué categorías de proveedores tratan datos, con qué finalidad, qué conservan y dónde los tratan.

Ver proveedores de servicios →

### Recursos y próximos pasos

Estado del servicio y cómo solicitar los paquetes completos de políticas bajo acuerdo de confidencialidad (NDA).

Ver recursos →[

### Metodología de validación

Cómo medimos la precisión de la transcripción y las alucinaciones en la documentación: un banco de pruebas, un corpus, dos capas de evaluación (WER + jurado de LLM). Las reglas con las que se califica cada cifra publicada.

Leer la metodología →](https://hanah.health/es/us/trust/wer-methodology/)[

### Transparencia de la validación

Transcripciones por grabación, documentos generados y veredictos de cada jurado LLM frente a un corpus de referencia fiable. Todos los datos, no solo las cifras principales.

Ver informe →](https://hanah.health/es/us/trust/transparency/)[

### Resultados anteriores

Cada prueba comparativa que hemos publicado, con el cambio respecto a la ejecución anterior. Las cifras se mantienen exactamente como se midieron ese día, incluso cuando el propio panel de calificación ha cambiado desde entonces.

Comparar ejecuciones →](https://hanah.health/es/us/trust/benchmarks/)

Cada fila es un control en el sentido habitual de ISO: **organizativo** (gobernanza y procedimiento documentado), **técnico** (aplicado mediante sistemas y configuración) o **de proveedor** (garantía contractual y de subencargados). Las etiquetas muestran el tipo de evidencia predominante; muchas filas combinan más de uno. El detalle remite a nuestro **Security & Operations Handbook** interno. La línea bajo cada fila cita las disposiciones de HIPAA (45 CFR) con las que se corresponde ese control; es solo orientativa y no sustituye el asesoramiento jurídico.

**Base normativa:** [HIPAA Administrative Simplification regulations](https://www.hhs.gov/hipaa/for-professionals/index.html), 45 CFR Part 164: Subpart C (Security Rule), Subpart D (Breach Notification Rule) y Subpart E (Privacy Rule).

Técnico Controles del sistema y de la plataforma: infraestructura, aplicación, criptografía, automatización. Política Gobernanza de la organización: responsabilidad, políticas firmadas, registro de riesgos, pruebas de los procedimientos. Proveedor Dependencia de terceros: condiciones del DPA, lista de subencargados, certificaciones de proveedores.

## Infraestructura y plataforma

Seguridad de la infraestructura

Define dónde se ejecuta Hanah en el despliegue regional, cómo se separa la producción de las operaciones y cómo el cifrado protege los datos de los clientes entre los profesionales sanitarios, nuestra infraestructura y los subencargados de IA. Son sobre todo controles técnicos, respaldados administrativamente en el Manual de seguridad y operaciones.

-   ✅
    
    Técnico Política
    
    **Cargas de producción alojadas en la región**
    
    Los servidores de aplicación principales, las bases de datos, el almacenamiento de objetos y las copias de seguridad del despliegue se encuentran en la región. Los registros administrativos describen las regiones y la aprobación de cambios; el despliegue técnico fija los recursos al proyecto regional.
    
    **Correspondencia con HIPAA:** §164.308(a)(1)(ii)(A)–(B) análisis y gestión de riesgos; §164.310(a)(1) controles de acceso a las instalaciones, a cargo del proveedor de alojamiento. Las historias se almacenan en Estados Unidos; el tratamiento por parte de proveedores se indica en Proveedores de servicios.
    
-   ✅
    
    Técnico
    
    **Cifrado en tránsito**
    
    El tráfico público de entrada usa TLS moderno. El tráfico hacia los proveedores de reconocimiento de voz y de modelos de IA usa TLS hacia los endpoints configurados de cada proveedor. Es un control técnico verificado en las revisiones de arquitectura y en la configuración del despliegue.
    
    **Correspondencia con HIPAA:** §164.312(e)(1) seguridad de la transmisión; §164.312(e)(2)(ii) cifrado.
    
-   ✅
    
    Técnico Política
    
    **Cifrado en reposo**
    
    Las bases de datos, el almacenamiento de objetos y las copias de seguridad usan algoritmos estándar del sector (p. ej., AES-256-GCM) con claves gestionadas según nuestra política de criptografía. Las copias de seguridad de WAL-G añaden cifrado en el cliente antes de almacenarse fuera de las instalaciones.
    
    **Correspondencia con HIPAA:** §164.312(a)(2)(iv) cifrado y descifrado; §164.308(a)(7)(ii)(A) plan de copias de seguridad.
    
-   ✅
    
    Técnico Política
    
    **Detección de intrusiones**
    
    Detección por capas: la plataforma de alojamiento proporciona IDS de red, mientras que cada máquina virtual ejecuta fail2ban (prevención de ataques de fuerza bruta por SSH), UFW con denegación por defecto y actualizaciones de seguridad automáticas. Los eventos de autenticación y acceso del proxy de autenticación se envían a una plataforma central de Loki/Grafana para que los patrones de inicio de sesión anómalos aparezcan en paneles y alertas. Las políticas asignan quién se encarga del triaje cuando salta una alerta. Un IDS de kernel en tiempo de ejecución para los contenedores es una mejora prevista sobre esta base.
    
    **Correspondencia con HIPAA:** §164.308(a)(1)(ii)(D) revisión de la actividad de los sistemas de información; §164.308(a)(6) procedimientos ante incidentes de seguridad; §164.312(b) controles de auditoría.
    

## Producto y aplicación

Seguridad del producto

Cómo se autentican los usuarios, cómo se aplica la autorización en el producto y en la capa de API, y cómo creamos y publicamos el software. Combina la aplicación técnica (JWT, RBAC) con requisitos administrativos del ciclo de desarrollo (SDLC) y de revisión.

-   ✅
    
    Técnico Proveedor
    
    **Autenticación y sesiones**
    
    Los profesionales sanitarios se autentican a través de un proveedor de identidad gestionado (flujos de tipo OIDC/OAuth); cada ruta de la API valida la identidad. La duración de la sesión y el bloqueo se ajustan a nuestra política de control de acceso.
    
    **Correspondencia con HIPAA:** §164.312(d) autenticación de personas o entidades; §164.312(a)(2)(iii) cierre de sesión automático.
    
-   ✅
    
    Técnico Política
    
    **Control de acceso basado en roles**
    
    Las capacidades de profesional sanitario, paciente y administrador están separadas en el modelo de datos y en la capa GraphQL, de modo que el mínimo privilegio es la opción por defecto. Las definiciones de roles y la frecuencia de revisión están documentadas administrativamente.
    
    **Correspondencia con HIPAA:** §164.312(a)(1) control de acceso; §164.308(a)(4) gestión del acceso a la información; §164.502(b) mínimo necesario.
    
-   ✅
    
    Técnico Política
    
    **MFA para despliegues empresariales**
    
    Los despliegues empresariales exigen MFA al iniciar sesión, mediante el proveedor de identidad de tu organización con inicio de sesión único (por ejemplo, Microsoft Entra ID) o mediante el nuestro.
    
    **Correspondencia con HIPAA:** §164.312(d) autenticación de personas o entidades.
    
-   ✅
    
    Técnico Política
    
    **Ciclo de desarrollo seguro**
    
    Los cambios pasan por el control de versiones y despliegues automatizados y repetibles, con las dependencias y las imágenes base de los contenedores fijadas a versiones exactas. El impacto en la seguridad se tiene en cuenta en las funciones de cierta envergadura como requisito administrativo.
    
    **Correspondencia con HIPAA:** §164.308(a)(1)(ii)(B) gestión de riesgos; §164.308(a)(8) evaluación.
    

## Datos y privacidad

Datos y privacidad

Conservación, eliminación, derechos de los interesados y visibilidad de los eventos relevantes para la seguridad. Estos controles combinan la aplicación automatizada en el producto y la base de datos con procedimientos administrativos (gestión de solicitudes de acceso, notificación de brechas, informes trimestrales).

-   ✅
    
    Técnico Política
    
    **Conservación y eliminación de los artefactos de la escucha ambiental**
    
    El audio se elimina en cuanto Hanah termina de transcribirlo. Cada organización fija sus propios plazos de conservación para las transcripciones y las notas clínicas, y Hanah las elimina automáticamente cuando vencen. Una vez integrada con tu sistema de historias clínicas, la historia clínica de referencia sigue siendo tuya.
    
    **Correspondencia con HIPAA:** §164.310(d)(2)(i) eliminación; §164.502(b) mínimo necesario.
    
-   ✅
    
    Técnico Política
    
    **Registro de eliminación y pista de auditoría**
    
    Cuando la política de conservación elimina una transcripción o una nota, el registro conserva una marca fechada que indica que el contenido se eliminó según la política de conservación de la organización, y el contenido eliminado nunca se envía, sincroniza ni vuelve a redactarse después. Las acciones sensibles de los operadores, como el acceso a secretos, la administración de cuentas y las sesiones de soporte, se registran en tablas de auditoría específicas.
    
    **Correspondencia con HIPAA:** §164.312(b) controles de auditoría; §164.312(c)(1) integridad; §164.316(b) documentación.
    
-   ✅
    
    Política Técnico
    
    **Acceso y rectificación por parte del interesado**
    
    Las personas pueden solicitar el acceso a su información personal o su rectificación; Hanah documenta los plazos, los formatos (JSON + exportaciones legibles) y las vías de escalado. Las herramientas permiten exportar los datos que están en los sistemas de Hanah.
    
    **Correspondencia con HIPAA:** §164.524 derecho de acceso; §164.526 modificación. Hanah facilita la respuesta de la clínica.
    

## IA y seguridad clínica

Seguridad y cumplimiento de la IA

Controles específicos de la IA de escucha ambiental: ningún uso secundario de los datos de salud para entrenar, supervisión humana antes de que se dependa clínicamente del resultado, medición de la calidad (WER) e instrucciones resistentes al abuso. Combina controles contractuales con terceros con el flujo del producto y la gobernanza clínica.

-   ✅
    
    Proveedor Política Técnico
    
    **Ningún uso secundario para entrenar modelos**
    
    Usamos nuestros proveedores de reconocimiento de voz y de modelos de IA solo con condiciones comerciales de pago, que prohíben entrenar con el contenido de los clientes, y las solicitudes se envían con el almacenamiento del proveedor desactivado siempre que el proveedor lo permite. Hanah no tiene un proceso interno de entrenamiento con tus datos de salud. Las revisiones administrativas de proveedores respaldan esta afirmación.
    
    **Correspondencia con HIPAA:** §164.502(a) usos y comunicaciones, limitados a la finalidad para la que la clínica contrató a Hanah; los proveedores están obligados por contrato a no entrenar con el contenido ni conservarlo más allá de las condiciones indicadas en Proveedores de servicios.
    
-   ✅
    
    Política Técnico
    
    **Revisión del profesional sanitario antes del uso clínico**
    
    Hanah prepara el borrador, y el profesional sanitario revisa y edita cada borrador. Una nota solo se envía a un paciente o se archiva en el programa de gestión clínica cuando el profesional sanitario lo decide. Es a la vez un control del producto y un compromiso de la política recogido en la PIA.
    
    **Correspondencia con HIPAA:** §164.312(c)(1) integridad; §164.526 modificación.
    
-   ✅
    
    Política Técnico
    
    **Metodología WER y resultados publicados por cohorte**
    
    Un banco de pruebas y dos capas de evaluación, ejecutadas en cada calificación: la **tasa de error de palabras (WER)** frente a transcripciones literales de referencia (capa A), y un **jurado de LLM** que mide tanto la _cobertura_ (¿recoge la nota cada expectativa registrada de antemano?) como la _alucinación_ (¿contiene la nota afirmaciones que la transcripción no respalda, es decir, contenido inventado por el modelo?). La [metodología completa](https://hanah.health/es/us/trust/wer-methodology/) está publicada, y los [resultados en directo](https://hanah.health/es/us/trust/transparency/) se generan directamente a partir de los datos agregados del banco de pruebas. El corpus sigue avanzando de v1 (sintético) → v2 (simulación de roles) → v3 (real, con consentimiento) → v4 (conjunto con socios del sistema sanitario).
    
    **Correspondencia con HIPAA:** §164.312(c)(1) integridad; §164.308(a)(8) evaluación.
    
-   ✅
    
    Técnico Política
    
    **Supervisión de la inyección de instrucciones y de las respuestas no seguras**
    
    Las instrucciones del sistema las controla el servidor y las entradas están acotadas por el flujo clínico (no hay un chat libre). Los clasificadores de seguridad del proveedor se ejecutan en cada generación; cuando se activan, el flujo devuelve un motivo de finalización por filtro de contenido que se guarda en la fila `ai_audit` de cada llamada junto con un código de error canónico `ai.content_policy`, la latencia, los tokens y un ID de traza de Tempo. Los patrones anómalos aparecen en paneles basados en esa tabla de auditoría. La detección de anomalías de comportamiento entre llamadas para identificar patrones de abuso es una mejora prevista sobre esta base.
    
    **Correspondencia con HIPAA:** §164.308(a)(1)(ii)(D) revisión de la actividad de los sistemas de información; §164.308(a)(5)(ii)(B) protección frente a software malicioso.
    
-   ✅
    
    Técnico Política
    
    **Consentimiento de grabación registrado por paciente**
    
    Hanah guarda el consentimiento de grabación de cada paciente (sí, no o aún sin registrar) y su origen: la respuesta del profesional sanitario, o el formulario, la nota o el registro del programa de gestión clínica en el que Hanah lo leyó. Las clínicas pueden mostrarlo en cada consulta, para que el profesional sanitario lo vea antes de grabar.
    
    **Correspondencia con HIPAA:** §164.506(b) consentimiento para usos relacionados con el tratamiento. También se aplican las leyes estatales sobre grabaciones: varios estados, entre ellos California y Florida, exigen el consentimiento de todas las partes para grabar.
    

## Organización y terceros

Seguridad organizativa

Cómo gestiona Hanah, como empresa, la seguridad: responsabilidad, gestión de riesgos y políticas documentadas. Son controles administrativos.

-   ✅
    
    Política
    
    **Gobernanza de la seguridad y registro de riesgos**
    
    Un directivo designado es responsable de la seguridad de la información; los riesgos se registran con responsables y fechas objetivo y se revisan con una periodicidad fija. Esto se corresponde con lo que los compradores suelen esperar de un sistema de gestión de tipo ISO, incluso a nuestra escala actual.
    
    **Correspondencia con HIPAA:** §164.308(a)(2) asignación de la responsabilidad de seguridad; §164.308(a)(1) proceso de gestión de la seguridad.
    
-   ✅
    
    Política
    
    **Políticas de seguridad de la información**
    
    Hay políticas formales sobre control de acceso, criptografía, respuesta a incidentes, gestión de proveedores, gestión de cambios, gestión de vulnerabilidades y conservación y eliminación de datos. Están bajo control de versiones; el contenido completo está disponible bajo acuerdo de confidencialidad (NDA).
    
    **Correspondencia con HIPAA:** §164.316 políticas, procedimientos y documentación.
    

En Estados Unidos, los cuestionarios de diligencia debida suelen llegar redactados con referencia a HIPAA y, a veces, a ISO/IEC 27001 o SOC 2. Esta tabla parte de cada requisito de HIPAA, indica la disposición más cercana en los Australian Privacy Principles, el RGPD (GDPR), la Privacy Act de Nueva Zelanda, ISO/IEC 27001 y SOC 2, y nombra el control de Hanah que lo cumple.

Las equivalencias son orientativas y no constituyen asesoramiento jurídico.

| Requisito de HIPAA | Australian Privacy Principles | RGPD / RGPD del Reino Unido | NZ Privacy Act 2020 / HIPC 2020 | ISO/IEC 27001:2022 | SOC 2 (TSC 2017) | Cómo lo cumple Hanah |
| --- | --- | --- | --- | --- | --- | --- |
| §164.530(a), (i): responsable de privacidad, políticas y procedimientos | APP 1 gestión abierta y transparente | Art. 5(2) responsabilidad proactiva; arts. 24, 30 | s 201 responsable de privacidad | Cl. 5.2 política; A.5.1 | CC1.1–CC1.3; CC2.3 | Directivo responsable designado, registro de riesgos, políticas de seguridad documentadas y este Centro de confianza. |
| §164.520: aviso de prácticas de privacidad | APP 5 notificación de la recogida | Art. 13–14 información que deberá facilitarse | IPP 3; regla 3 del HIPC | A.5.34 | P1.1 aviso | Estado del consentimiento de grabación guardado en el producto; la política de privacidad indica los países en los que se tratan los datos. |
| §164.502(b), §164.514(d): mínimo necesario | APP 3 recogida de información solicitada | Art. 5(1)(b)–(c) limitación de la finalidad y minimización | IPP 1, 2, 4; reglas 1, 2, 4 del HIPC | A.5.34 | P3.1–P3.2 recogida | Recogida limitada al encuentro que inicia el profesional sanitario, con el consentimiento confirmado antes de cada grabación. |
| §164.502(a), §164.506: usos y comunicaciones permitidos | APP 6 uso o comunicación | Art. 5(1)(b) limitación de la finalidad; art. 28 condiciones del encargado del tratamiento | IPP 10, 11; reglas 10, 11 del HIPC | A.5.34; A.5.10 uso aceptable | P4.1 uso; P6.1 comunicación a terceros | Tratamiento solo según las instrucciones de la clínica; sin uso secundario y sin entrenamiento de modelos. |
| §164.508(a)(3): autorización para marketing | APP 7 marketing directo | Art. 21(2)–(3) derecho de oposición a la mercadotecnia directa | Sin equivalente directo (Unsolicited Electronic Messages Act 2007) | Sin equivalente directo | P2.1 | La información de los pacientes nunca se usa para marketing; los pacientes solo reciben comunicaciones de una clínica cuando un profesional sanitario les envía algo. |
| §164.502(e), §164.504(e), §164.308(b): business associates y subcontratistas | APP 8 comunicación transfronteriza | Art. 28 encargados del tratamiento; capítulo V, arts. 44–49 transferencias internacionales | IPP 12; regla 12 del HIPC | A.5.19–A.5.22 relaciones con proveedores | CC9.2 riesgo de proveedores; P6.4 | Historias almacenadas en Estados Unidos. Los proveedores se indican por país en Proveedores de servicios, con límites contractuales de no entrenamiento y de conservación. |
| §164.312(c): integridad | APP 10 calidad de la información personal | Art. 5(1)(d) exactitud | IPP 8; regla 8 del HIPC | A.5.34 | P7.1 calidad | Revisión del profesional sanitario de cada borrador antes de enviarlo o archivarlo; medición publicada de la precisión y las alucinaciones. |
| §164.308, §164.310, §164.312: salvaguardas administrativas, físicas y técnicas | APP 11.1 seguridad de la información personal | Art. 32 seguridad del tratamiento | IPP 5; regla 5 del HIPC | A.5.15, A.8.5 acceso y autenticación; A.8.24 criptografía; A.8.13 copias de seguridad; A.8.15–A.8.16 registro y supervisión | CC6 acceso lógico; CC7 operaciones del sistema; CC8 gestión de cambios | Cifrado en tránsito y en reposo, acceso basado en roles, MFA para despliegues empresariales, detección de intrusiones, copias de seguridad cifradas. |
| §164.310(d)(2)(i): eliminación | APP 11.2 destrucción o desidentificación; APP 4 información no solicitada | Art. 5(1)(e) limitación del plazo de conservación; art. 17 supresión | IPP 9; regla 9 del HIPC | A.8.10 eliminación de la información | C1.2 eliminación; P4.3 | El audio sin procesar se elimina en cuanto se genera la transcripción; las transcripciones se eliminan automáticamente según el ajuste de conservación de la organización, dejando una marca fechada en el registro. |
| §164.524: derecho de acceso | APP 12 acceso | Art. 15 acceso; art. 20 portabilidad | IPP 6; regla 6 del HIPC | A.5.34 | P5.1 acceso | Exportaciones en JSON y en formatos legibles para facilitar la respuesta de la clínica. |
| §164.526: modificación | APP 13 rectificación | Art. 16 rectificación | IPP 7; regla 7 del HIPC | A.5.34 | P5.2 rectificación | Los profesionales sanitarios pueden editar las notas en cualquier momento, con historial de cambios; las solicitudes de modificación siguen un procedimiento documentado. |
| §164.400–414: Breach Notification Rule | Part IIIC: régimen de Notifiable Data Breaches | Art. 33–34 notificación de brechas | Parte 6: brechas de privacidad notificables | A.5.24–A.5.27 gestión de incidentes | CC7.3–CC7.5 respuesta a incidentes | Política de respuesta a incidentes, registro centralizado de seguridad y apoyo a la evaluación de riesgos y la notificación de la clínica. |

Estas son las categorías de proveedores de servicios que **pueden tratar o almacenar datos de clientes de Hanah** en nuestra arquitectura de producción de , qué gestiona cada uno, qué conserva y dónde trata los datos. Todos los proveedores están obligados por contrato a proteger los datos de los clientes, y ninguno puede entrenar modelos con ellos. El inicio de sesión de los profesionales sanitarios usa una infraestructura de identidad global que **no contiene información de salud de los pacientes**.

| Categoría de servicio | Finalidad | Datos tratados | Conservación | Región de tratamiento |
| --- | --- | --- | --- | --- |

Transparencia operativa: una página pública de **estado** (disponibilidad e incidencias) se suma al endpoint de disponibilidad `/healthz` de producción que usa nuestra propia supervisión.

[Estado del servicio](https://hanah.health/es/us/trust/status/ "Estado de cada componente, disponibilidad en 90 días e historial de incidentes del despliegue en EE. UU.") [Solicitar el paquete completo de seguridad bajo NDA](mailto:hello@hanah.health?subject=Trust%20%2F%20security%20pack%20request) [Volver a hanah.health](https://hanah.health/es/)

PhysiPal Pty Ltd (con el nombre comercial Hanah): . Este Centro de confianza es un resumen general. Los compromisos contractuales y las condiciones de tratamiento de datos vigentes en el momento de la firma prevalecen sobre esta página. Los emojis de estado (✅ 🔧) son provisionales y se retirarán tras la verificación independiente de cada fila.
