El 14 de abril de 2026, el Comité Europeo de Protección de Datos abrió a consulta su primera plantilla DPIA armonizada a escala de la UE. Detrás de la promesa de simplificación administrativa, un giro metodológico más silencioso: la separación entre los riesgos de diseño y los riesgos de incidente. Una distinción que redistribuye las cartas entre las plataformas que protegen los datos y las que conciben la ausencia de riesgo.
La armonización que los DPO esperaban desde 2018
El 14 de abril de 2026, el EDPB hizo pública su primera plantilla armonizada de Data Protection Impact Assessment, adoptada en versión 1.0 el 10 de marzo mediante procedimiento escrito. El documento está abierto a consulta pública hasta el 9 de junio de 2026. Después de esa fecha, todas las autoridades europeas (incluida la CNIL francesa) deberán adoptarla como modelo único, o como meta-modelo con el que sus plantillas nacionales deberán permanecer compatibles.
Para los DPO que gestionan tratamientos transfronterizos, es el fin de una fragmentación que duraba desde hace siete años. Hasta ahora, un DPIA estructurado según un enfoque nacional no era necesariamente reconocido por otra autoridad. La plantilla EDPB pone fin a esta asimetría.
Es la lectura consensuada del texto. Es acertada, pero pasa por alto lo esencial.
Dos riesgos, dos secciones, dos lógicas
La verdadera innovación de la plantilla 2026 no es formal. Es metodológica. Por primera vez en un documento oponible a escala europea, la plantilla distingue dos naturalezas de riesgos que la mayoría de las metodologías DPIA de primera generación mezclaban en una matriz única.
En la sección 3, el responsable documenta los riesgos inherentes al propio tratamiento. Los que existen incluso si todo funciona perfectamente, si ninguna configuración se descontrola, si ningún atacante entra en el sistema. Centralización de datos, duraciones de conservación prolongadas, identificadores persistentes, combinación de conjuntos heterogéneos. Estos riesgos son consecuencias de elecciones arquitectónicas, no de eventos.
En la sección 4, por separado, se documentan los riesgos operativos. Bugs, malas configuraciones, errores humanos, accesos abusivos, ataques externos. Son los riesgos de incidente.
Esta separación parece técnica. Es en realidad política. Obliga a plantear una pregunta que los DPIA de primera generación eludían con frecuencia: ¿es esta arquitectura compatible con los derechos y libertades de las personas, incluso cuando funciona como está previsto?
Dicho de otro modo, antes incluso de hablar de seguridad, ¿es el propio diseño el que plantea un problema? La respuesta a esta pregunta no se encuentra en la calidad de los cortafuegos. Se encuentra en el plano de arquitectura.
Cuando la seguridad no repara el diseño
La respuesta, para un gran número de arquitecturas actuales, es incómoda. Un data lake construido en torno a un almacenamiento centralizado de larga duración, incluso perfectamente operado, comporta riesgos estructurales que ahora se documentan en una sección aparte, sin que la adición de medidas operativas los responda.
El cifrado no transforma una retención de diez años en una ausencia de retención. El control de accesos no hace inocuo el hecho de concentrar en un único lugar los datos sensibles de millones de personas. La sección 3 de la plantilla obligará a documentar estas elecciones por sí mismas.
Las plataformas que han crecido sobre el modelo «recolectar ampliamente, almacenar duraderamente, proteger intensamente» tendrán que enfrentarse a este espejo. No es una acusación, es una constatación. La plantilla EDPB no inventa nada: hace explícito lo que el artículo 25 del RGPD pedía desde 2018. Pero lo hace explícito en una sección dedicada, trazable, comparable de un expediente a otro.
El otro espejo: las arquitecturas que no tienen nada que almacenar
El espejo devuelve una imagen muy diferente cuando se observan arquitecturas concebidas de otro modo.
Una plataforma que trata los datos durante su transporte, sin desplazarlos ni almacenarlos, comprime por diseño la sección 3 de la plantilla. No hay centralización que documentar, porque no hay centralización. No hay duración de retención que justificar, porque el tratamiento es in-transit. Los conjuntos combinados no dejan traza persistente, porque la combinación se disuelve con el contexto de uso. Los identificadores persistentes desaparecen, porque la plataforma no los fabrica.
Es el principio de la tecnología DataCell de iD4Connect: cada unidad de tratamiento actúa sobre el dato durante su tránsito y luego lo libera. Nada persiste del lado de la plataforma. DataGraph garantiza la inteligencia contextual, que se disuelve con el contexto de uso. La arquitectura no es una capa de protección añadida sobre una topología clásica. Es otra topología (ver la arquitectura completa).
¿Y la sección 4, sobre los incidentes? Hay que rellenarla, por supuesto. Ninguna arquitectura exime de analizar sus propios fallos. Pero cuando el activo que se debe defender no incluye ni data lake ni warehouse, la pregunta «qué ocurre si un atacante entra» cambia de naturaleza. No hay patrimonio que exfiltrar fuera de las fuentes, que permanecen dentro del perímetro del responsable original con sus propias medidas.
Una arquitectura que no tiene nada que perder no se defiende como una arquitectura que tiene todo que proteger.
Cinco preguntas para poner a prueba su DPIA actual
Antes de la finalización de la plantilla en junio, puede ser útil pasar su DPIA actual, o su última revisión, por el filtro de cinco preguntas. No sustituyen a un análisis de cumplimiento, pero dan una señal rápida.
- ¿Distingue claramente su sección sobre los riesgos los que provienen del diseño del tratamiento de los que provienen de incidentes operativos, o se tratan ambos en una matriz única?
- Cuando describe sus medidas en el marco del artículo 25 (data protection by design), ¿se trata de parámetros añadidos sobre una arquitectura existente, o de propiedades intrínsecas de la propia arquitectura?
- Si una autoridad le pidiera mañana: «¿qué ocurriría para las personas afectadas si toda la arquitectura funcionara perfectamente, sin incidente alguno?», ¿sería su respuesta corta o larga?
- ¿Incluye su inventario de activos (sección 1.3 de la plantilla) componentes de almacenamiento de larga duración que existen principalmente por razones históricas, y cuyo valor de negocio sería difícil defender hoy?
- Si recomenzara la arquitectura desde cero, con los estándares de 2026 en mente, ¿elegiría la misma topología de datos, u otra?
Estas preguntas no se planteaban en los mismos términos hace un año. Se plantearán en estos términos durante los cinco próximos.
Según su rol, lo que esto cambia
Para un DPO: a misión igual, el volumen de documentación necesario depende ahora del tipo de arquitectura. Defender un DPIA ante la autoridad se vuelve mecánicamente más sencillo cuando la arquitectura subyacente no obliga a justificar cada riesgo estructural mediante una medida compensatoria.
Para un CISO: un nuevo tipo de herramienta entra en la conversación. No un producto de seguridad adicional, sino una arquitectura de datos que reduce mecánicamente la superficie que defender. «Un dato que no se puede robar no necesita ser defendido» deja de ser un aforismo para convertirse en una categoría documental.
Para un CIO o un CTO: un arbitraje económico se formaliza. Las plataformas de analítica centralizada tienen un coste de operación y un coste de cumplimiento. Hasta ahora, el segundo permanecía difuso, desigual, difícil de cuantificar. La plantilla EDPB lo hace visible sección por sección. En los sectores regulados (finanzas y banca, salud, energía, sector público), donde cada DPIA es documentado, auditado y revisado, este arbitraje deja de ser teórico.
Para una autoridad de regulación: un criterio de diferenciación gana en legibilidad. Las arquitecturas que encarnan el artículo 25 por diseño y no por parámetro disponen ahora de un lenguaje común para demostrarlo, y las autoridades disponen de un lenguaje común para reconocerlo.
Contribuir a la consulta mientras está abierta
La consulta EDPB está abierta hasta el 9 de junio. Toda contribución será publicada en el sitio de la autoridad.
Creemos que la plantilla ganaría si reconociera explícitamente, en su sección sobre data protection by design, la categoría de las arquitecturas data-at-source y stateless. No porque fueran mejores en sí mismas (ese juicio corresponde a los responsables y a sus autoridades), sino porque transforman cualitativamente, y no cuantitativamente, el perfil de riesgo de un tratamiento.
Por eso invitamos a los DPO, juristas, integradores y editores que tienen experiencia concreta de estas arquitecturas a participar en la consulta. Una consulta pública solo es útil si quienes hacen el trabajo se toman la molestia de escribir.
Dentro de seis semanas, la plantilla estará finalizada. En unos meses, será la referencia oponible a todos los editores de plataformas de datos presentes en Europa. Dos preguntas se plantean en ese momento, una técnica y una estratégica. La primera, acabamos de plantearla.
La segunda es más simple: ¿y si recomenzara la arquitectura mañana, elegiría la misma?
La plantilla DPIA del EDPB no crea ninguna obligación nueva. Simplemente hace legible lo que el artículo 25 del RGPD pedía desde 2018: separar lo que corresponde al diseño del tratamiento y lo que corresponde al incidente. En esta rejilla de lectura, las arquitecturas que no almacenan los datos no tienen que compensar su diseño con medidas: reducen mecánicamente el perímetro que documentar. De aquí a junio, ya no será una intuición. Será un formato oponible.
