Lo que el HHS publica sobre sus PIAs deja una lección incómoda para Europa: la privacidad útil se documenta, no se declama

La privacidad suele morir de éxito burocrático. Se habla mucho de ella, se firma mucho sobre ella y, a la hora de la verdad, cuesta encontrar un documento claro que explique qué datos recoge un sistema, para qué los usa, con quién los comparte y qué riesgo real genera. Por eso la página del Department of Health and Human Services (HHS) de EE. UU. sobre sus Privacy Impact Assessments (PIAs) merece más atención de la que parece. No porque descubra América —nunca mejor dicho—, sino porque muestra algo bastante menos glamuroso y mucho más útil: privacidad documentada de forma pública y operativa.

El mensaje oficial del HHS es sencillo: la ley federal obliga a las agencias a completar PIAs cuando desarrollan u operan sistemas que recogen información personal identificable, y esas evaluaciones deben ayudar a identificar y reducir riesgos de privacidad antes y durante la operación del sistema. La base legal que cita el propio HHS está en los Títulos II y III de la E-Government Act of 2002. Nada revolucionario. Lo interesante no es la teoría, sino el escaparate: decenas de evaluaciones publicadas, incluidos sistemas internos y herramientas de terceros, desde Zendesk hasta Smartsheet o GovDelivery, pasando incluso por una entrada para Credal AI.

Aquí está el detalle que importa en 2026: mientras muchas organizaciones europeas siguen tratando la evaluación de impacto como un trámite de PDF enterrado en SharePoint, una agencia federal sanitaria exhibe catálogos completos de PIAs, en PDF y CSV, accesibles al público. Eso no convierte automáticamente al HHS en campeón mundial de la privacidad, pero sí deja una pregunta bastante incómoda: si una administración mastodóntica puede publicar qué sistemas usa y cómo evalúa su impacto sobre datos personales, ¿por qué tantas empresas siguen sin tener ni un inventario mínimamente serio de tratamientos, proveedores y flujos de datos?

La noticia no es que existan PIAs. La noticia es que el HHS las trata como infraestructura de gobernanza

La página del HHS distingue dos grandes categorías. Primero, las System Privacy Impact Assessments, que cubren sistemas que recogen o mantienen datos personales. Segundo, las Third-Party Website and Application PIAs, pensadas para sitios web o herramientas digitales no operadas por el Gobierno federal, como redes sociales u otros servicios externos. Esta división, por sí sola, dice bastante.

Dice, para empezar, que la privacidad no se agota en la aplicación “core” ni en la base de datos principal. También vive —y a veces se complica— en la periferia: herramientas de soporte, plataformas de atención, suites colaborativas, automatizaciones, CRM, formularios, servicios de analítica o proveedores SaaS que entran por la puerta lateral con una demo convincente y acaban conectados a medio ecosistema corporativo. Si te suena familiar, no es casualidad.

El HHS no se limita a proclamar principios. Publica nombres concretos de sistemas y servicios. En la sección de la Administration for Children and Families aparecen, por ejemplo, ACF Zendesk, Enterprise Smartsheet, GovDelivery, Federal Case Registry o Head Start Enterprise System. También figura Credal Artificial intelligence Corporation (Credal AI). No es un matiz menor. En 2026, cuando media industria presume de “AI governance” con presentaciones muy pulidas y trazabilidad bastante menos pulida, que una agencia publique una PIA ligada a una herramienta de IA es una señal de madurez documental. No porque resuelva todos los riesgos, sino porque asume que la novedad tecnológica no exime de describir datos, usos, accesos y controles.

El contraste con la práctica habitual en el sector privado es demoledor. Bajo GDPR, el registro de actividades de tratamiento del art. 30 debería ser pan de cada día. La evaluación de impacto del art. 35, también cuando procede. Y, sin embargo, sigue siendo frecuente encontrar organizaciones que pueden enseñarte una política corporativa impecable pero no responder en diez minutos a cuatro preguntas básicas: qué PII entra en un sistema, qué proveedor la toca, con qué base jurídica se usa y qué transferencias internacionales implica.

Ese hueco no es teórico. Es el hueco por el que luego entran incidentes, sanciones y discusiones interminables con compras, legal, seguridad y negocio. Cada uno con su Excel. Cada uno convencido de que el problema lo tiene el otro.

PIA federal y DPIA europea: parecidos razonables, diferencias importantes

Conviene no mezclar marcos como si fueran equivalentes perfectos. Las PIAs del ecosistema federal estadounidense y las evaluaciones de impacto relativas a la protección de datos del GDPR no son lo mismo, aunque comparten ADN.

Bajo el GDPR, el art. 35 exige una evaluación de impacto cuando un tipo de tratamiento, en particular si utiliza nuevas tecnologías, pueda entrañar un alto riesgo para los derechos y libertades de las personas físicas. El art. 35.7 además concreta el contenido mínimo: descripción sistemática de las operaciones de tratamiento y sus fines; evaluación de necesidad y proporcionalidad; evaluación de riesgos; y medidas previstas para afrontarlos. Si el riesgo alto persiste, el art. 36 obliga a consultar a la autoridad de control antes de tratar.

La lógica de las PIAs federales, según resume el HHS, está más anclada a la obligación general de examinar sistemas que recogen PII y hacer pública esa evaluación. Esa publicidad externa es una diferencia cultural relevante. En Europa, una DPIA no suele publicarse de forma íntegra, y no hay una obligación general equivalente de colgarla para que cualquiera la lea. Puede haber transparencia parcial o resúmenes, pero no es el patrón estándar.

Eso tiene ventajas y costes. La ventaja europea es obvia: una DPIA contiene información sensible sobre arquitectura, riesgos y medidas que no siempre conviene exponer. El coste también lo es: al quedar dentro de la organización, la calidad del documento depende casi por completo de la disciplina interna y del apetito real por someter decisiones a escrutinio. Si nadie fuera del circuito la verá, la tentación de convertirla en formalidad es altísima.

La aproximación del HHS introduce una disciplina adicional: escribir sabiendo que habrá lectores externos. Eso obliga a cierta claridad. Y la claridad, en privacidad, es una forma de control. Cuando un equipo tiene que explicar públicamente qué datos recoge un sistema, por qué los necesita, cómo se protegen y quién accede a ellos, afloran antes las incoherencias. Sucede algo incómodo pero saludable: el documento ya no sirve solo para cumplir, también sirve para dejar en evidencia lo que no está bien pensado.

¿Significa eso que Europa debería publicar todas sus DPIAs? No necesariamente. Pero sí debería aprender dos cosas. Primera: una evaluación de impacto que no pueda entender un tercero inteligente, aunque no sea especialista del proyecto, probablemente está mal hecha. Segunda: una evaluación que no se actualiza cuando cambia el sistema tampoco vale gran cosa. El propio HHS subraya que las divisiones son responsables de completar y mantener PIAs tanto para sistemas en desarrollo como ya en uso. Esa obligación de mantenimiento importa más que el PDF inicial. El riesgo raramente nace en el día de aprobación; suele aparecer después, cuando llegan integraciones, ampliaciones de finalidad, nuevos proveedores o un “solo vamos a activar esta funcionalidad” que acaba tocando datos sensibles.

La lección escondida en la lista de proveedores: la privacidad ya no se juega solo dentro de casa

Hay otra razón por la que esta publicación merece análisis: la lista de PIAs funciona como radiografía de dependencia tecnológica. Y eso conecta directamente con uno de los problemas más serios de 2026: la gestión de terceros.

Cuando el HHS publica PIAs de herramientas como Zendesk, Smartsheet o GovDelivery, está admitiendo una realidad que muchas organizaciones siguen maquillando: gran parte del tratamiento de datos personales ya no sucede únicamente en infraestructura propia ni en aplicaciones diseñadas a medida. Sucede en servicios externos, en plataformas configurables y en entornos donde el dato circula entre varios actores con responsabilidades distintas.

Eso tiene consecuencias jurídicas y operativas muy concretas en Europa. Bajo GDPR, el art. 28 obliga a seleccionar encargados del tratamiento que ofrezcan garantías suficientes y a formalizar contratos con contenido específico. El art. 32 exige medidas técnicas y organizativas apropiadas. Si hay transferencias internacionales, entran en juego el capítulo V y, según el caso, mecanismos como las cláusulas contractuales tipo o el Data Privacy Framework UE-EE. UU. cuando aplique. Si el sistema implica monitorización intensiva, datos sensibles del art. 9 o decisiones que afecten significativamente a personas, el análisis escala rápido.

En sanidad, el problema se multiplica. En el mundo HIPAA, cuando un proveedor maneja protected health information (PHI) por cuenta de una entidad cubierta o de un business associate, hacen falta acuerdos específicos y controles más robustos. El mero hecho de que una herramienta “sea popular” o “esté en la nube” no resuelve nada. Tampoco el hecho de que tenga certificaciones bonitas en la web corporativa. Las certificaciones ayudan; no sustituyen el análisis de flujos de datos ni aclaran por sí solas quién accede a qué, con qué fines secundarios o qué telemetría genera el servicio.

La ironía regulatoria es esta: muchas organizaciones invierten meses en redactar políticas de uso aceptable y, mientras tanto, siguen sin saber con precisión cuántos SaaS procesan datos personales de clientes, pacientes o empleados. Luego llega una solicitud de acceso, una brecha, una due diligence o una auditoría, y empieza el deporte favorito del compliance improvisado: preguntar por Teams si alguien sabe quién contrató aquella herramienta.

La página del HHS no arregla ese caos universal, pero deja ver el enfoque correcto. Primero se identifica el sistema. Después se documenta el tratamiento. Luego se analiza el riesgo y la protección. Y, crucialmente, eso se mantiene. No es sexy. Tampoco lo es pagar una sanción o explicar a un regulador que el mapa de proveedores estaba “en revisión”.

Por qué esto importa también para IA, aunque la web del HHS no vaya de AI Act

La aparición de Credal AI en la lista tiene más miga de la que parece. En 2026, casi cualquier programa serio de gobernanza de IA se enfrenta al mismo choque con la realidad: antes de evaluar sesgos, explicabilidad o supervisión humana, hay que saber qué datos entran en el sistema, quién los sube, si se reutilizan, dónde se almacenan y qué trazas deja la interacción de usuarios con la herramienta.

Es decir, privacidad básica. O, si queremos ser menos indulgentes, higiene documental mínima.

Desde la perspectiva europea, esto conecta con varias capas regulatorias a la vez. Si la herramienta de IA trata datos personales, GDPR no desaparece porque pongas “copilot” en el nombre del proyecto. Si además el uso encaja en supuestos del AI Act —dependiendo del caso, del rol de la organización y de la clasificación del sistema—, la trazabilidad del dato y la gobernanza del proveedor se vuelven todavía más críticas. Y si la entidad está en sectores regulados, el análisis ya no es solo de privacidad: también hay que mirar seguridad, resiliencia, continuidad y control de terceros.

Lo que hace interesante una PIA sobre una herramienta de IA no es el fetichismo documental. Es que obliga a responder preguntas que demasiados despliegues evitan durante la fase comercial. Por ejemplo: ¿se introducen datos identificables en prompts? ¿se almacenan conversaciones? ¿se usan para mejorar el modelo o el servicio? ¿qué controles existen para separar entornos? ¿hay acceso del proveedor a contenido generado? ¿pueden aparecer datos personales en salidas no previstas? ¿qué procedimiento hay para borrar, limitar o auditar uso?

Si eso no se resuelve al principio, luego llega la ficción favorita de 2026: el comité dice que la herramienta está aprobada “con restricciones”, pero nadie ha convertido esas restricciones en controles técnicos, cláusulas contractuales, formación a usuarios y evidencias auditables. Resultado: política magnífica, práctica imprevisible.

La lección aquí es casi grosera por lo evidente. La gobernanza de IA sin disciplina de PIA o DPIA es decoración. Bonita, cara y sorprendentemente inútil cuando hay que defender una decisión frente a un regulador o frente a una filtración interna.

Transparencia pública: virtud democrática, pero también mecanismo de presión interna

El HHS insiste en que, una vez completada, la PIA debe ponerse a disposición del público para apoyar transparencia y rendición de cuentas. Eso tiene una dimensión democrática obvia: si una agencia trata información personal, la ciudadanía puede conocer de manera más precisa qué sistemas operan y bajo qué lógica de tratamiento.

Pero hay otra dimensión menos noble y más efectiva: la transparencia pública presiona a la propia organización para no entregar documentos vacíos.

Quien ha leído suficientes evaluaciones de impacto sabe detectar el maquillaje al segundo párrafo. Frases genéricas, finalidades amplísimas, riesgos descritos en abstracto y controles tan vaporosos que podrían servir para una app de recetas o para un sistema de vigilancia biométrica. Cuando el documento es interno, esa pobreza puede pasar. Cuando es público, se nota demasiado.

El sector privado europeo no necesita copiar este modelo tal cual, pero sí puede adoptar un principio similar: redactar como si el documento pudiera acabar sobre la mesa de un regulador, un auditor externo, un DPO recién incorporado o el consejo de administración. Porque, seamos serios, puede acabar ahí.

También conviene recordar que transparencia no equivale a exposición suicida. Se puede diseñar una política de publicación por capas: resumen ejecutivo público, inventario interno completo, anexos técnicos restringidos y evidencia de revisión periódica. Lo central es abandonar la lógica del archivo muerto. Una evaluación de impacto que nadie consulta después de la aprobación inicial no es gobernanza. Es sedación administrativa.

Qué deberían copiar las empresas europeas mañana mismo, sin esperar a otra guía del regulador

La utilidad de esta noticia no está en admirar la diligencia ajena, sino en extraer prácticas replicables. Hay al menos cinco que merecen adopción inmediata.

1. Separar sistemas internos y servicios de terceros

La distinción que hace el HHS entre PIAs de sistema y PIAs de webs o aplicaciones de terceros es más inteligente de lo que parece. Mezclar ambos mundos en una sola ficha suele ocultar riesgos distintos. Un sistema propio exige foco en arquitectura, accesos, minimización y ciclo de vida interno. Un tercero exige, además, diligencia contractual, subencargados, transferencias, telemetría, uso secundario de datos y control de cambios del proveedor. Si tu organización aún evalúa todo con un formulario idéntico, ya vas tarde.

2. Publicar —al menos internamente— un catálogo vivo de evaluaciones

La página del HHS funciona como repositorio navegable. No es un detalle cosmético. Un catálogo vivo permite saber qué existe, qué está actualizado y qué división es responsable. En una empresa, ese catálogo debería enlazar tratamiento, sistema, proveedor, base jurídica, clasificación de datos, jurisdicciones, fecha de revisión y dependencia de ciberseguridad. Si legal tiene una versión, seguridad otra y compras una tercera, no tienes un catálogo: tienes una disputa futura.

3. Exigir revisión por cambio, no solo por alta

La mayor debilidad de muchas DPIA es temporal. Se hacen al inicio y se olvidan después. Sin embargo, los riesgos se alteran cuando cambian finalidades, categorías de datos, conectores, ubicaciones de almacenamiento, modelos de IA, analítica o perfiles de acceso. La actualización por evento debería ser obligatoria. No hace falta esperar a una revisión anual si el sistema ha cambiado de forma material en marzo.

4. Tratar la descripción del dato como control, no como literatura

Una buena evaluación distingue categorías concretas: identificadores, datos de contacto, metadatos de uso, credenciales, datos financieros, categorías especiales del art. 9 GDPR, datos de menores, registros de soporte, transcripciones, adjuntos. Esa granularidad no es obsesión documental; permite decidir retención, cifrado, segregación y respuesta a derechos. Decir “datos personales” a secas es casi no decir nada.

5. Vincular la evaluación a seguridad y continuidad

Privacidad y seguridad siguen viajando en departamentos distintos en demasiadas casas. Error viejo. Una evaluación de impacto útil debería enlazar con controles de acceso, registros, cifrado, backup, gestión de vulnerabilidades, respuesta a incidentes, pruebas de restauración y, cuando proceda, dependencia de terceros críticos. En sanidad o servicios esenciales, esta conexión es todavía más necesaria. Un sistema puede ser impecable desde la minimización y aun así un desastre desde la resiliencia.

GDPR, HIPAA y el viejo problema de las palabras gemelas que no significan lo mismo

La categoría sugerida para esta pieza es GDPR, pero la fuente viene del HHS y habla de PIAs en un entorno federal estadounidense. Eso obliga a evitar la pereza comparativa.

GDPR y HIPAA comparten preocupación por la protección de información sensible, pero no regulan lo mismo ni operan con el mismo alcance. HIPAA se centra en protected health information dentro de un perímetro definido de entidades cubiertas y business associates. GDPR tiene un alcance mucho más amplio sobre datos personales y categorías especiales, con principios generales del art. 5, bases jurídicas del art. 6, condiciones del art. 9 para datos sensibles, seguridad del art. 32, brechas del art. 33 y evaluaciones del art. 35.

El riesgo práctico es que algunas multinacionales crean que un programa sólido de HIPAA ya resuelve gran parte del trabajo de privacidad. No. Ayuda, sí. Sustituye, no. HIPAA puede ser riguroso en salvaguardas sanitarias y aun así dejar lagunas relevantes para requisitos europeos sobre minimización, limitación de finalidad, transferencias, licitud del tratamiento o derechos individuales en otros contextos.

La lección de las PIAs del HHS no es “haz como Estados Unidos”. Es otra: documenta tratamientos con un nivel de detalle que sirva en operaciones reales, no solo en revisiones formales. Eso es compatible con GDPR, con HIPAA y con cualquier entorno donde los datos personales viajen por sistemas complejos y terceros numerosos. O sea, con casi todo.

El regulador no siempre te pedirá una gran teoría. A veces te pedirá algo mucho más cruel: enséñame el documento

Hay una fantasía recurrente en compliance: creer que las sanciones nacen de grandes principios mal entendidos. A veces ocurre. Más a menudo, lo que destruye una defensa es algo bastante más prosaico: no poder demostrar quién decidió qué, con qué análisis y con qué salvaguardas.

Una PIA o una DPIA bien hecha cumple precisamente esa función probatoria. No elimina el riesgo, pero permite enseñar un hilo lógico: qué sistema se evaluó, qué datos procesaba, qué riesgos se identificaron, qué medidas se adoptaron, quién aprobó, cuándo se revisó y qué cambios activaron nueva evaluación. Esa trazabilidad vale oro cuando hay una reclamación, una investigación interna, una compra corporativa o una auditoría regulatoria.

También vale para algo menos dramático y más frecuente: evitar discusiones absurdas dentro de la organización. Cuando surge una duda sobre uso secundario, retención, acceso de soporte o legitimidad de una integración, el documento debería permitir responder sin improvisación épica. Si no existe, o si está redactado en jerga tan abstracta que nadie se aclara, el riesgo operativo ya está servido.

El HHS, con su repositorio público, recuerda que las evaluaciones de impacto no son un ritual jurídico autónomo. Son piezas de gobernanza. Y una pieza de gobernanza que no puedes localizar, explicar y mantener es tan útil como un extintor pintado en la pared.

Qué puede hacer ahora un DPO, un CISO o un responsable de compliance que lea esto en 2026

Sin caer en plantillas milagrosas, hay decisiones inmediatas bastante concretas.

La primera es identificar si la organización distingue de verdad entre inventario de tratamientos, inventario de sistemas y inventario de terceros. En muchas empresas, esos tres mapas existen, pero no se hablan entre sí. El resultado es perverso: sabes que hay un tratamiento, sabes que existe un proveedor y sabes que hay un sistema, pero no puedes unir las tres piezas con evidencia coherente.

La segunda es revisar si las evaluaciones de impacto incluyen herramientas periféricas. No solo el ERP o el expediente clínico. También soporte, mensajería, colaboración, automatización, formularios, chat, analítica, herramientas con IA generativa y plataformas de relación con usuarios. Justo ahí es donde suelen esconderse los datos no previstos, las retenciones excesivas y los accesos amplios “porque era más cómodo así”.

La tercera es introducir un disparador de revaluación asociado a cambios materiales. Ejemplos verificables y muy concretos: incorporación de un nuevo subencargado; activación de una función de IA; transferencia a una jurisdicción nueva; inclusión de datos de menores; cambio de base jurídica; integración con otro sistema que amplíe finalidad; ampliación de categorías de datos a salud, biometría o geolocalización. Si no tienes disparadores definidos, la revisión llegará tarde.

La cuarta es preparar una versión legible para dirección. No un resumen infantil, sino un formato ejecutivo que explique exposición, dependencia de terceros, riesgos residuales y decisiones pendientes. El consejo no necesita cien páginas de anexos para ejercer supervisión; necesita saber dónde están los puntos de fricción que podrían convertirse en problema legal, reputacional o de continuidad.

La quinta, y quizá más ingrata, es decidir qué documentos podrían publicarse parcial o internamente de forma más transparente. La visibilidad ordena. Cuando un área sabe que su evaluación será leída por otras funciones, mejora la calidad media. Milagros no hace, pero reduce bastante la tentación de rellenar casillas en piloto automático.

La verdadera moraleja: privacidad sin inventario y sin mantenimiento es solo branding regulatorio

La página de PIAs del HHS no anuncia una norma nueva, no cambia el tablero global de privacidad y no trae un plazo dramático que obligue a rehacer programas enteros antes de fin de trimestre. Precisamente por eso es interesante. Obliga a mirar la capa de trabajo menos vistosa y más decisiva: el mantenimiento serio de la documentación que conecta sistemas, datos, terceros y riesgos.

En 2026, ya no cuela decir que la privacidad es una prioridad estratégica y seguir operando con evaluaciones desactualizadas, catálogos incompletos y proveedores incorporados sin una visión clara del tratamiento. Menos aún en sectores de salud, administración pública, finanzas o servicios críticos, donde la combinación de datos sensibles, dependencias tecnológicas y escrutinio regulatorio hace que cualquier agujero documental termine costando tiempo, dinero o credibilidad. A veces las tres cosas.

Lo que el HHS pone sobre la mesa es casi vulgar de tan básico: si un sistema recoge PII, evalúalo; si lo operas, mantenlo; si usas terceros, explícitalo; si la evaluación existe, que sirva para algo más que para cumplir una casilla. Suena elemental. Lo es. Y, sin embargo, sigue siendo una de las disciplinas peor ejecutadas en privacidad corporativa.

La conclusión no requiere fanfarria. La privacidad útil no se mide por el número de políticas aprobadas, sino por la capacidad de una organización para enseñar, en cualquier momento, qué datos trata cada sistema, por qué, con qué riesgo, bajo qué control y con qué terceros. Todo lo demás —el discurso, la estética, la solemnidad— viene después. Si llega.