En pocas palabras: Windows Copilot invirtió tres veces la regla de desidentificación de HIPAA (45 CFR 164.514): sostuvo que un hash con clave secreta dejaba los datos como PHI, lo contrario de la norma, y citó un paper real que lo desmentía, además de inventar una cita del HHS sobre un enlace gubernamental.
Windows Copilot invirtió tres veces seguidas una regla de desidentificación de HIPAA y, para rematar, citó como respaldo un paper real que demostraba lo contrario. Lo documentó un desarrollador de infraestructura de salud en una nota publicada en Dev.to: el asistente hasta inventó una cita del HHS pegada a un enlace gubernamental genuino.
El caso Copilot HIPAA arrancó como una consulta técnica y terminó como manual de por qué no conviene usar un chatbot para temas regulatorios. Windows Copilot es el asistente de IA integrado en Windows 11 que muchos usan para consultas rápidas dentro del sistema operativo. HIPAA es la ley estadounidense que protege la información de salud de pacientes (PHI), y su norma de desidentificación, el 45 CFR 164.514, define cuándo un dataset deja de contener datos protegidos. Lo que respondió Copilot era el espejo exacto de esa norma.
En resumen
- Copilot afirmó que un hash con clave secreta dejaba los datos como “PHI, no desidentificados” y que publicar la clave era la opción “mucho mejor”: la inversa de la regla.
- La norma real, el 45 CFR 164.514(c), prohíbe dos cosas: códigos derivados del identificador y divulgar el mecanismo de re-identificación. Publicar la clave viola las dos.
- En la segunda ronda, Copilot citó entre comillas una frase atribuida al HHS que no existe en hhs.gov, con el enlace genuino del gobierno al lado.
- El origen del error parece ser un paper de AMIA de 2003 (Landi y Rao) sobre cifrado asimétrico, donde “public key” es criptografía de clave pública, no clave compartida con todos.
- Preguntado por su modelo, Copilot respondió que usa solo “tecnologías de IA propietarias de Windows”, una afirmación imposible de verificar.
Caso Copilot HIPAA: ¿qué le preguntaron sobre las claves de cifrado de pacientes?
La consulta era si, para pseudonimizar datos de pacientes con hash(clave + identificador), conviene mantener la clave secreta o publicarla. Copilot eligió publicarla como la opción segura, que es justo la que la norma prohíbe. La pregunta venía de Vadim Albarov, que construye infraestructura para el sector salud y tenía una rutina de dos ventanas: Claude Code para el trabajo serio y Copilot como bloc de notas con sabor a buscador. Preguntás, ojeás, cerrás, volvés al trabajo.
Hasta que la ventanita lateral le enseñó una regla de HIPAA con total seguridad. La regla estaba al revés. No vaga, no incompleta: invertida, y en la única dirección que convierte una pregunta de cumplimiento en una brecha. La respuesta de Copilot tenía dos ramas:
- Con clave secreta: retenés la capacidad de re-identificar, así que los datos siguen siendo PHI, no desidentificados.
- Con clave pública: nadie tiene “conocimiento privilegiado”, nadie puede revertir un hash de una sola vía, así que los datos pueden calificar como desidentificados.
Y la filosofía de fondo: HIPAA no miraría la fuerza criptográfica, miraría quién sabe qué. “Pensás como ingeniero; HIPAA la escribieron abogados.” Suena a alguien explicando un rincón contraintuitivo del derecho. Es seductor. También es falso en las dos ramas, y la segunda es peligrosa.
¿Qué dice realmente la norma 45 CFR 164.514(c) de HIPAA?
Permite justo lo que Copilot negó: una entidad cubierta puede conservar en secreto su mecanismo de re-identificación y aun así el dataset cuenta como desidentificado. El Safe Harbor termina con un cajón de sastre, “cualquier otro número, característica o código identificador único”, con una sola excepción: el código de re-identificación que cumpla el párrafo (c). Ese párrafo tiene dos puntos concretos:
- Derivación: el código no debe derivarse de información sobre el individuo ni ser traducible de vuelta a la persona.
- Seguridad: la entidad no debe divulgar el mecanismo de re-identificación ni usar el código para otros fines.
Leé esos dos puntos contra las ramas del chatbot. El hash con clave secreta falla Safe Harbor, sí, pero no por el motivo que dio Copilot: falla porque el token se deriva del identificador, y el punto 1 prohíbe la derivación sin importar cuán bien guardes la clave. La capacidad de re-identificar no es el descalificador; la derivación y la divulgación sí lo son. La guía de desidentificación del HHS cierra el círculo: los hashes con clave son aceptables por la vía de Determinación de Expertos, siempre que la clave no se divulgue, ni siquiera a los receptores de los datos.
¿Por qué la respuesta de Copilot podía terminar en una brecha de datos?
Porque publicar la clave permite reconstruir la columna completa de pacientes en segundos, con una laptop cualquiera. Publicar la clave es “divulgar el mecanismo de re-identificación”: el punto 2 del párrafo (c), palabra por palabra. Y de paso hace el código trivial de revertir, que es el punto 1.
El detalle técnico que la respuesta pasó por alto: los identificadores de salud viven en espacios chicos y enumerables. Un SSN ocupa un espacio de 10^9 valores (mil millones), y lo mismo pasa con teléfonos, historias clínicas, emails o nombre más fecha de nacimiento. La resistencia de un hash protege entradas de alta entropía; para un número de nueve dígitos no hace nada.
Ponele que seguís el consejo: publicás la clave, etiquetás el dataset como desidentificado, lo mandás al equipo de analítica, alguien lo cruza contra una lista de teléfonos en una tarde, y de golpe tenés pacientes re-identificables y una brecha que reportar. ¿Y quién te lo recomendó? Un chatbot con tabla de veredicto y emojis.
Copilot inventó una cita del HHS y la pegó a un enlace real del gobierno
Segunda ronda, ahora con el modo de pensamiento y el modo búsqueda activados y un pedido expreso de referencias. Volvió la misma conclusión invertida, ahora con encabezados con emojis, tabla de veredicto y lista de fuentes. Y algo peor en el medio: una frase entre comillas atribuida al HHS que decía que un código derivado de PHI es identificador “salvo que la clave de re-identificación no se conserve”. El autor buscó esa oración. No está en hhs.gov. No está en ningún lado. El modelo compuso una regla plausible, invirtió el verbo real de la regulación, la envolvió en comillas y le colgó la URL genuina del gobierno.
Un enlace real lavando una cita falsa. El atajo mental de cualquier lector, “enlaza a hhs.gov, así que está fundamentado”, derrotado por construcción.
Lo llamativo es que la respuesta correcta estaba en esa misma respuesta, desparramada en los márgenes: la sección de riesgos admitía que el “pepper” público (la clave añadida al hash) se rompe por fuerza bruta, lo que destruye el titular, y otro punto notaba que mantener una clave secreta para vinculación requiere determinación de expertos, que es la regla real. El modelo tenía todas las piezas y aun así despachó la conclusión invertida en el titular, la tabla y el resumen.
Tercera ronda, por si la pregunta cargada había envenenado el pozo: chat nuevo, pregunta neutra y simétrica. Veredicto: el hash con clave pública es “mucho mejor”, el de clave privada sigue siendo PHI, y el pepper público debería ser “largo, aleatorio y no adivinable” (sí, en serio). La clave tendría que ser conocida por todos, para que nadie tenga acceso privilegiado, y conocida por nadie, para que nadie la rompa por fuerza bruta. Al mismo tiempo.
Para calibrar, el autor le hizo la misma pregunta a la versión web de ChatGPT. La respondió bien: rechazó el hash con clave pública por el motivo del ataque de diccionario, etiquetó el HMAC con clave como pseudonimización que por sí solo no saca las obligaciones de PHI, y recomendó tokens aleatorios con tabla de mapeo protegida. No perfecto, porque nunca citó la prohibición de derivación, pero direccionalmente sano. Misma pregunta, un producto invertido de forma reproducible en chats independientes, el otro no.
| Método | Lo que dijo Copilot | Lo que dice la norma |
|---|---|---|
| Hash con clave secreta | “Sigue siendo PHI, no desidentificado” | Falla Safe Harbor porque el código se deriva del identificador; aceptable por Determinación de Expertos si la clave no se divulga |
| Hash con clave pública | “Nadie tiene conocimiento privilegiado; puede calificar como desidentificado” | Viola los dos puntos del párrafo (c): divulga el mecanismo y el código queda reversible por fuerza bruta |
| Token aleatorio + tabla de mapeo protegida | No lo propuso | Lo que el párrafo (c) acepta: un valor aleatorio no se deriva de nadie |
¿De dónde salió el error? El paper de AMIA de 2003 que demostraba lo contrario
De un paper de AMIA de 2003 de Landi y Rao, “Secure De-identification and Re-identification”, que las dos respuestas con referencias citaban como fuente principal. El autor lo buscó y encontró un esquema de cifrado asimétrico: los identificadores se cifran con la clave pública de un par de claves, y solo quien tiene la clave privada, el dueño de los datos, puede descifrar y re-identificar. “Public key” como en criptografía de clave pública. Un sistema cuya seguridad depende de que la clave privada quede secreta y cuyo propósito explícito es que el dueño conserve la capacidad de re-identificar. Esto se conecta con lo que analizamos en los cambios recientes en los planes.
La cadena de fallo queda a la vista: el retrieval encontró un paper con “public key” y “de-identification” cerca en el texto, la capa de resumen colapsó “criptografía de clave pública” en “clave pública”, y el modelo no se quedó en el malentendido: levantó una filosofía regulatoria completa encima, la “teoría del conocimiento privilegiado” de HIPAA, que no aparece en ninguna regulación y que el propio paper citado refuta. La cita que debía fundamentar la respuesta era la prueba de lo contrario.
¿Qué modelo de IA usa Windows Copilot?
Nadie lo sabe, y preguntarle al propio Copilot no sirve de nada. Cuando el autor le preguntó a la cara, el asistente negó usar modelos de ningún laboratorio externo: solo “tecnologías de IA propietarias de Windows”, sin poder dar detalles. La ventana decía “Smart”, que es una etiqueta de modo, no un nombre de modelo.
Esa respuesta no vale nada, y saber que no vale nada es la parte útil. Lo que un chatbot dice sobre su propia identidad es texto generado como cualquier otro: los modelos no tienen acceso introspectivo a la infraestructura que los sirve, y los “no puedo revelar” suelen ser política de system prompt, no conocimiento. El mismo producto que inventó una cita del HHS no es un testigo confiable sobre sus propias tripas. Como resume el autor citando reportes públicos, estos productos corren flotas mixtas, con modelos de frontera licenciados de laboratorios socios junto a modelos propios, y un router guiado por costos decide por consulta cuál te toca, sin indicador por respuesta.
La pregunta correcta no es “qué LLM usa este producto” sino “qué pipeline, con qué retrieval, qué router y qué incentivos”. Ningún producto de consumo responde eso. Ni cuando se lo preguntás directo.
¿HIPAA protege tus conversaciones con chatbots de inteligencia artificial?
No, en general no. Los proveedores de chatbots de consumo no son “covered entities” de HIPAA salvo que firmen un BAA (Business Associate Agreement) con un proveedor de salud, como explica Windows News. Microsoft ofrece soluciones compatibles con HIPAA vía BAA en Azure, Office 365 y Dynamics 365, pero las funciones de IA de consumo, como Windows Copilot o el Copilot de Edge, no heredan esas protecciones. Escribirle datos de pacientes a un chatbot de consumo puede ser, para una organización cubierta, una divulgación no autorizada.
Si trabajás desde Argentina o el resto de Latinoamérica para clientes de salud de Estados Unidos, esto te alcanza igual: HIPAA cubre a los business associates, no solo a entidades dentro de EE.UU. La lista de tareas es corta: BAAs claros con cada proveedor que toque datos, sistemas segmentados, personal capacitado, configuraciones auditadas y controles de acceso por rol. Nada de esto es nuevo; lo nuevo es que el canal de fuga puede ser un chat que se ve inofensivo en la barra de tareas. Para más detalles técnicos, mirá por qué Copilot pausó los registros.
Qué está confirmado y qué no
- Confirmado: las tres respuestas invertidas, documentadas ronda por ronda en la nota original, en chats independientes.
- Confirmado: la cita atribuida al HHS no aparece en hhs.gov; el autor la buscó de forma textual y no existe.
- Confirmado: el paper de AMIA de 2003 (Landi y Rao) existe y describe cifrado asimétrico con par de claves, no clave compartida.
- Pendiente: qué modelo concreto sirvió las respuestas invertidas. Copilot lo negó y no hay verificación independiente.
- Pendiente: una respuesta oficial de Microsoft sobre el caso HIPAA hasta el cierre de esta nota.
Errores comunes al usar IA para consultas de cumplimiento
- Confiarle más a la ventana secundaria que a la principal. El error del autor no fue usar Copilot, fue darle a la ventanita de consultas rápidas un estándar de evidencia más bajo porque las preguntas parecían chicas. Nada en la ventana hace más chicas las respuestas.
- Pedir referencias y creer que eso es verificación. Cuando un modelo ya se comprometió con una conclusión, pedir fuentes puede producir fabricación, hasta inventar una cita y pegarla a una URL de gobierno real. Si una cita importa, buscá la oración exacta.
- Ignorar las contradicciones internas. Las respuestas erradas se refutaban a sí mismas en sus propias secciones de riesgos. Una respuesta cuyos caveats contradicen su titular te está diciendo qué parte fue recuperada y qué parte fue compuesta.
- No leer la fuente primaria. El 164.514(c) son dos párrafos que se leen en cinco minutos. Compliance por chatbot es cómo un dataset “desidentificado” sale a producción con la clave publicada y se convierte en brecha reportable.
Preguntas Frecuentes
¿Qué respondió Copilot sobre HIPAA y el cifrado de datos de pacientes?
Afirmó que un hash de identificadores con clave secreta dejaba los datos como PHI (no desidentificados) y que usar una clave pública era la opción “mucho mejor” para HIPAA. La norma real dice lo contrario: publicar la clave divulga el mecanismo de re-identificación y deja los datos triviales de revertir por fuerza bruta sobre espacios enumerables como los SSN.
¿Es seguro usar Copilot con datos de salud o correos confidenciales?
No como canal para información protegida. Windows Copilot es una función de consumo que no hereda las protecciones HIPAA de los servicios empresariales de Microsoft. Para datos de pacientes usá servicios con BAA firmado.
¿Qué modelo de IA usa Windows Copilot?
Microsoft no lo publica, y preguntarle al propio Copilot no sirve: respondió que usa solo “tecnologías de IA propietarias de Windows”, una afirmación no verificable. Los reportes públicos indican que estos asistentes corren flotas mixtas con un router por costos que elige modelo por consulta, sin indicador visible para el usuario.
¿HIPAA protege mis conversaciones con chatbots de inteligencia artificial?
No, salvo que el proveedor del chatbot tenga un BAA firmado con una entidad de salud. Los chatbots de consumo no son covered entities, así que lo que escribas ahí no cuenta como comunicación protegida. Si manejás PHI, la conversación con un chatbot de consumo puede ser una divulgación no autorizada.
¿Cómo verifico si la información legal que me da una IA es correcta?
Leé la fuente primaria: en este caso, el 45 CFR 164.514(c) son dos párrafos que se leen en cinco minutos. Si la respuesta cita algo textual, buscá la oración exacta en el sitio oficial. Y desconfiá de respuestas cuyos propios caveats contradicen su conclusión principal.
Conclusión
Lo que cambió acá no es la tecnología, es la evidencia: quedó documentado, reproducible en chats independientes, un producto que invierte una regla regulatoria tres veces y la sostiene con una cita fabricada pegada a un enlace real. La respuesta correcta estaba en el mismo paper que el modelo citaba.
Para vos que trabajás con datos de pacientes, la lección es operativa: la ventana rápida merece el mismo escepticismo que la principal, las citas se verifican buscando la oración exacta, y todo tema regulatorio se cierra leyendo la norma. El autor mantiene su configuración de dos ventanas, pero el asiento del bloc de notas quedó vacante: dejó de usar Copilot hasta que el producto estabilice. Después de meses de confianza, una herramienta que fabrica citas regulatorias con cara de piedra pierde el beneficio de la duda.
