Una EIPD se centra en las personas cuyos datos se tratan, no en la organización que realiza el tratamiento. El significado de EIPD se solapa sustancialmente con el de evaluación de impacto en la privacidad (PIA), un término más antiguo y amplio para referirse al mismo tipo de ejercicio, utilizado en regímenes de protección de datos fuera de la UE y, en el Reino Unido, en directrices anteriores al propio RGPD. En la práctica, muchas organizaciones e incluso algunas autoridades de control utilizan ambos términos indistintamente, y la metodología subyacente es en gran medida la misma: mapear los flujos de datos, evaluar el riesgo para las personas y definir las garantías. La distinción legalmente relevante es más acotada: en el marco específico del RGPD, EIPD es el término definido, con los detonantes, el contenido y los requisitos de consulta contemplados en el Artículo 35. Ese enfoque en las personas y no en la organización condiciona todo lo demás sobre su funcionamiento.

¿Por qué son importantes las EIPD?

Detectar un problema de privacidad antes del lanzamiento es infinitamente mejor que descubrirlo después. Ese es el argumento práctico a favor de una EIPD: saca a la luz el riesgo mientras el proyecto aún puede rediseñarse en función de este, en lugar de hacerlo tras el lanzamiento, cuando las opciones se reducen al control de daños. También resulta ser una de las formas más claras de demostrar la responsabilidad proactiva (accountability) del RGPD: no señalando una política, sino mostrando el razonamiento real detrás de una decisión de tratamiento específica.

Nada de esto exige eliminar todos los riesgos que revela una EIPD. El cometido consiste en identificar lo que hay, decidir si es aceptable y establecer las garantías adecuadas. Si se realiza con la suficiente antelación, este mismo ejercicio integra la protección de datos en la forma en que se diseña un proyecto, en lugar de añadir la privacidad como un simple paso de revisión al final.

¿Cuándo se exige una EIPD según el RGPD?

El Artículo 35 establece el detonante: se exige una EIPD siempre que sea probable que el tratamiento entrañe un alto riesgo para los derechos y libertades de las personas. Que se alcance ese umbral depende de la naturaleza, el alcance, el contexto y los fines del propio tratamiento, no del tamaño de la organización que lo lleva a cabo.

Tratamientos que exigen automáticamente una EIPD

Tres escenarios cruzan siempre esa línea, según el Artículo 35 del RGPD:

• Evaluación o elaboración de perfiles sistemática y exhaustiva que produzca efectos jurídicos o significativamente similares. Un algoritmo de scoring crediticio que decide la elegibilidad para un préstamo es un ejemplo claro.

• Tratamiento a gran escala de datos de categorías especiales o relativos a condenas penales, como registros de salud o datos biométricos, de forma masiva.

• Observación sistemática a gran escala de zonas de acceso público, como una red de videovigilancia a nivel de toda una ciudad.

Otros indicadores de tratamiento de alto riesgo

Esos tres escenarios son el mínimo, no la lista completa. La observación sistemática, los datos sensibles, el tratamiento a gran escala, la combinación de conjuntos de datos de distintas fuentes, el tratamiento que involucra a personas vulnerables, el uso de tecnologías innovadoras y la toma de decisiones automatizada pueden llevar el tratamiento a un territorio de alto riesgo, incluso fuera de los supuestos expresamente nombrados. Las autoridades de control nacionales también publican sus propias listas —como la guía de EIPD de la ICO en el Reino Unido—, y estas suelen ir más allá de los propios ejemplos del RGPD.

¿Qué tipo de riesgo evalúa una EIPD?

Una EIPD se indaga sobre los daños físicos, financieros, sociales u otros daños materiales e inmateriales para las personas. La discriminación derivada de una decisión automatizada, el robo de identidad tras una brecha de datos o simplemente la pérdida de control sobre datos personales sensibles cuentan como daños para la persona, independientemente de si la organización llega a sufrir o no alguna consecuencia. Se trata de una cuestión genuinamente distinta a la que plantea un marco convencional de gestión de riesgos, el cual suele evaluar el riesgo para la propia organización en lugar de para las personas a las que afecta el tratamiento.

EIPD frente a la evaluación de riesgos de seguridad de la información

Una evaluación de riesgos de seguridad de la información se centra por lo general en las amenazas a la confidencialidad, la integridad y la disponibilidad. Las consecuencias para las personas involucradas son lo que realmente está diseñada a detectar una EIPD. Los controles de seguridad suelen cumplir una doble función como medidas de mitigación en la EIPD, pero realizar una evaluación de seguridad de la información conforme a la ISO 27001 no la sustituye. Ambas responden a preguntas distintas, incluso cuando analizan los mismos sistemas.

¿Qué debe incluir una EIPD?

El Artículo 35 del RGPD establece cuatro elementos mínimos:

¿Quién es responsable de llevar a cabo una EIPD?

El responsable del tratamiento es el encargado de garantizar que se realice una EIPD cuando esta sea exigible. Se trata de una responsabilidad formal, no necesariamente de una tarea individual: cuando la organización cuenta con un Delegado de Protección de Datos (DPD), su asesoramiento debe formar parte del proceso, y los equipos pertinentes, encargados del tratamiento y especialistas técnicos a menudo aportan información o conocimientos a lo largo del camino. La responsabilidad y la colaboración son dos cosas distintas en este contexto, y confundirlas es una forma habitual de que la responsabilidad desaparezca silenciosamente.

¿Cuándo debe realizarse una EIPD?

El RGPD exige que la EIPD se lleve a cabo con la suficiente antelación como para influir realmente en el diseño del tratamiento, y siempre antes de que comience el tratamiento de alto riesgo. Para cuando el sistema ya está construido, la EIPD se convierte en un mero trámite: la arquitectura está fijada, el proveedor seleccionado y cambiar cualquier aspecto en ese punto implica costes y retrasos reales. Tratar la EIPD como parte de la planificación del proyecto, en lugar de como una aprobación de cumplimiento añadida al final, es lo que realmente la conecta con el principio más amplio del RGPD de protección de datos desde el diseño y por defecto.

¿Debe revisarse una EIPD?

Nada en una EIPD finalizada es permanente. Un nuevo proveedor podría hacerse cargo de parte del tratamiento, un sistema podría empezar a recopilar un campo de datos adicional o un modelo diseñado para un fin podría reutilizarse para otro. Cualquiera de estas situaciones puede invalidar silenciosamente la evaluación original, sin que nadie decida explícitamente hacerlo. Vale la pena revisar una EIPD cuando cambie la naturaleza, el alcance, el contexto o la finalidad del tratamiento, cuando entren en juego nuevas tecnologías, cuando surjan nuevos riesgos o cuando las garantías implantadas originalmente cambien de forma sustancial. Debe tratarse como un proceso vivo, no como un documento que se archiva una vez aprobado.

¿Qué ocurre si una EIPD identifica un riesgo residual elevado?

La primera respuesta es buscar medidas que reduzcan el riesgo. Si, incluso tras la mitigación, el tratamiento sigue conllevando un alto riesgo para las personas, el responsable del tratamiento debe consultar a la autoridad de control competente antes de iniciar el tratamiento. Se trata de un detonante distinto al que motiva el inicio de la EIPD: un riesgo alto inicial exige realizar la EIPD, mientras que un riesgo residual elevado no mitigado exige consultar a la autoridad antes de proceder.

¿Existe una plantilla estándar de EIPD?

El RGPD no exige un formato único. Define qué debe abarcar una EIPD y deja libertad a las organizaciones para utilizar la plantilla publicada por una autoridad de control o adaptar su propia metodología, siempre que se aborden eficazmente los elementos requeridos.

El Comité Europeo de Protección de Datos (EDPB) adoptó una plantilla armonizada de EIPD (versión 1.0) concebida como marco de referencia común para toda la UE en marzo de 2026 y la publicó en abril de ese mismo año. La consulta pública sobre el borrador finalizó en junio de 2026 y, en el momento de redactar este texto, la propia página del EDPB señala que la versión definitiva sigue pendiente. Conviene seguir de cerca su evolución, aunque todavía no constituye el único formato obligatorio.

Cómo respalda Formalize la gestión de las EIPD

La mayoría de las organizaciones aún conservan sus EIPD en documentos, hojas de cálculo y cadenas de correo electrónico. Esto impide tener una vista unificada de qué evaluaciones están pendientes, vencidas o silenciosamente desactualizadas.

Formalize mantiene todo ese trabajo en un único sistema estructurado:

• Flujos de trabajo para EIPD y TIA (evaluaciones de impacto de las transferencias) con responsables asignados y fechas límite, en lugar de un documento esperando en la bandeja de entrada de alguien.

• Actividades de tratamiento conectadas con riesgos, sistemas y proveedores, de modo que la EIPD refleje lo que ocurre en realidad, y no una simple instantánea del momento en que se redactó.

• Evidencias y garantías adjuntas directamente a cada riesgo, lo que permite presentar la EIPD finalizada cuando se solicite, en lugar de tener que reconstruirla de memoria.

• El RGPD, la ISO 27001, la Directiva NIS2 y otros marcos normativos dentro del mismo sistema, en lugar de estar dispersos en herramientas independientes que requieren sus propias actualizaciones por separado.

Nada de esto determina si una EIPD específica es jurídicamente suficiente. Ese criterio sigue siendo responsabilidad de las personas que comprenden el tratamiento y su contexto. Lo que hace Formalize es facilitar la documentación, acreditación y posterior revisión de ese criterio.