Para usar Amazon Quick con información sanitaria protegida (PHI) en un flujo sujeto a HIPAA, define primero las responsabilidades y las decisiones de acceso y cifrado que quedan fijadas al crear recursos. La elegibilidad del servicio no convierte por sí sola el entorno de una organización en conforme: el cliente también debe aceptar el acuerdo aplicable a su cuenta y configurar sus propios controles y salvaguardas. HIPAA es el marco federal estadounidense tratado aquí.
AWS explicó estos ajustes en una guía publicada el 22 de octubre de 2026. Sus afirmaciones sobre el producto describen las indicaciones del proveedor, no una certificación del entorno de cada cliente.
Antes de crear recursos
Prepara el acuerdo de asociado comercial (BAA, por sus siglas en inglés) y decide quién administrará las identidades, los permisos y la gobernanza de los datos. AWS indica que el BAA se acepta mediante AWS Artifact para una cuenta concreta; no se extiende automáticamente a otras cuentas, a servicios no elegibles ni a la configuración que corresponde al cliente.
AWS describe Amazon Quick como elegible para HIPAA en sus clientes web, de escritorio y móviles. La guía de configuración se centra en la versión web. La designación de elegibilidad no cubre por sí sola las decisiones y salvaguardas de la organización.
Pasos para preparar el flujo
- Acepta el BAA para la cuenta de AWS que usarás. Así delimitas la cuenta a la que se aplica el acuerdo, según AWS. Confirma también qué servicios elegibles formarán parte del flujo.
- Elige el cifrado y el modelo de identidad antes de poner en marcha Amazon Quick. AWS dice que el cifrado en reposo está activado por defecto con claves propiedad o bajo gestión de AWS. Las claves administradas por el cliente son opcionales y requieren una suscripción Enterprise. La clave de datos de Quick queda fijada cuando se crean por primera vez datos de Quick en la cuenta; AWS indica que no puede cambiarse después.
- Selecciona la identidad que gobernará el acceso. AWS enumera IAM Identity Center, Active Directory, federación de IAM y usuarios locales de Quick. La detección de usuarios inactivos está disponible, según AWS, con IAM Identity Center o Active Directory. Si se cambia de proveedor de identidad, habrá que volver a aprovisionar los permisos y las pertenencias a espacios.
- Activa la aplicación de ACL de documentos al crear cada base de conocimiento compatible. Las listas de control de acceso (ACL) limitan qué documentos puede recuperar cada usuario. AWS dice que esta opción se elige al crear la base de conocimiento y no se puede añadir más tarde. Valida las correspondencias entre identidades y ACL antes de incorporar documentos sensibles: una asignación incorrecta puede exponerlos sin que aparezca un error o una alerta. La actualización predeterminada de la base de conocimiento es cada 24 horas; AWS sugiere acortar el intervalo si los cambios de acceso deben propagarse antes.
- Separa los controles de documentos de los de datos estructurados. En el ejemplo ficticio que plantea AWS, documentos de Amazon S3 pasan por una base de conocimiento con ACL. Los datos de reclamaciones se preparan y se desidentifican antes, se gobiernan con Lake Formation y se consultan mediante Athena y Amazon Quick Sight, con controles por filas y columnas. Para datos estructurados también cuentan los permisos del lago de datos y del Glue Data Catalog.
- Configura la auditoría antes de incorporar datos sensibles. AWS distingue CloudTrail, que registra operaciones de API compatibles y determinados eventos no relacionados con API, de los registros de Amazon CloudWatch específicos de Quick. Estos incluyen
CHAT_LOGS,FEEDBACK_LOGS,AGENT_HOURS_LOGS,INDEX_USAGE_LOGSyKB_FILE_SYNC_LOGS. AWS señala que los registros de chat y comentarios pueden contener PHI; CloudTrail no recoge el contenido de los mensajes de chat ni de las respuestas.
| Decisión | Cuándo fijarla | Consecuencia indicada por AWS |
| Clave de datos de Amazon Quick | Antes de crear los primeros datos de Quick en la cuenta | La clave no puede cambiarse después. AWS también advierte de que, si se elimina, la recuperación requiere cancelar y volver a suscribir el servicio, con pérdida permanente de los datos de Quick. |
| Modelo de identidad | Antes de aprovisionar usuarios y espacios | Cambiar de proveedor obliga a volver a aprovisionar permisos y pertenencias a espacios. |
| ACL de la base de conocimiento | Al crear una base de conocimiento compatible | La aplicación de ACL de documentos no puede añadirse después; una correspondencia errónea de identidad y ACL puede exponer documentos sin alerta. |
Qué retener y durante cuánto tiempo
La regla de seis años de 45 CFR §164.316 se refiere a la documentación que exige §164.316(b)(1): políticas y procedimientos escritos, y registros escritos de las acciones, actividades o evaluaciones que la Regla de Seguridad exige documentar. El plazo se cuenta desde la creación del documento o desde la fecha en que dejó de estar vigente, la que sea posterior. 45 CFR §164.316
AWS recomienda por separado conservar los registros durante al menos seis años en su guía de despliegue. Esa recomendación del proveedor tiene un alcance distinto del plazo que la disposición citada establece para la documentación especificada.
| Retención | Qué abarca | Plazo y cómputo |
| 45 CFR §164.316(b)(1) y (b)(2)(i) | Documentación que la disposición exige mantener por escrito | Seis años desde su creación o desde la fecha en que estuvo vigente por última vez, la que sea posterior. |
| Recomendación de AWS | Registros del despliegue de Amazon Quick, según la guía de AWS | Al menos seis años, como recomendación del proveedor. |
Límites que afectan al diseño
AWS describe las barreras de seguridad de Quick como probabilísticas, por lo que recomienda complementarlas con controles deterministas, como políticas de IAM, ACL y límites de red. También caracteriza el servicio como regional, sin conmutación por error entre regiones; plantea una implementación separada y datos de apoyo en otra región como posible estrategia de recuperación.
