eIDAS 2.0 amplía el tablero: qué cambian las atestaciones electrónicas, los sellos y los registros para cumplimiento y seguridad

Europa quiere que pruebes menos y demuestres mejor. Esa es la idea de fondo tras la identidad digital europea: reducir la liturgia absurda de enviar documentos enteros cuando lo que hace falta es acreditar un dato concreto. No tu DNI completo, sino que eres mayor de edad. No una escritura interminable, sino que puedes representar a una sociedad. El cambio parece semántico. No lo es. Mueve piezas delicadas de identidad, confianza, evidencia y responsabilidad.

Ahí está la parte interesante. El debate sobre la European Digital Identity Wallet suele quedarse en la superficie: interoperabilidad, adopción, experiencia de usuario, “nueva era digital” y demás frases que suenan bien en un PowerPoint y mal en la realidad. Lo relevante para compliance, riesgos, seguridad y operaciones es otra cosa: quién puede emitir atributos, con qué nivel de fiabilidad, cómo se presentan, qué valor probatorio tienen y qué ocurre cuando esa cadena falla.

Y aquí aparece el segundo malentendido habitual. Mucha gente habla de la wallet como si fuera solo una app pública para guardar credenciales. No. La wallet reordena relaciones jurídicas y técnicas entre usuarios, emisores de atributos, prestadores de servicios de confianza, relying parties y supervisores. Si trabajas en banca, seguros, pagos, telecomunicaciones, sector público o servicios regulados, la pregunta útil no es si “vas a usar la wallet”. La pregunta es dónde te obligará a rediseñar procesos que hoy dependen de PDFs, portales heredados, validaciones manuales o APIs mal cosidas.

El marco revisado de eIDAS va precisamente en esa dirección. Sin entrar en etiquetas apresuradas sobre un supuesto “artículo 45 bis”, lo que sí puede sostenerse es que la revisión del Reglamento eIDAS introduce disposiciones específicas sobre la cartera europea de identidad digital y sobre los mecanismos que permiten expedir, usar y verificar datos y atributos vinculados a la identidad. El punto jurídico no es un nombre coloquial del artículo, sino el efecto práctico: el reglamento deja de hablar solo de identificación electrónica y servicios de confianza en sentido clásico y pasa a ordenar también un modelo de credenciales y atributos reutilizables entre Estados miembros y sectores.

La wallet no va de identidad. Va de atributos

La identidad electrónica ya existía en eIDAS. Lo disruptivo ahora es que el foco se desplaza hacia la capacidad de acreditar cualidades, derechos o vínculos concretos sin revelar más de la cuenta. Ese matiz conecta directamente con principios que compliance conoce bien, aunque a menudo se apliquen peor de lo que se recitan: minimización de datos en GDPR (art. 5.1.c), integridad y confidencialidad (art. 5.1.f), y protección de datos desde el diseño (art. 25).

Traducido a operación diaria: una organización podrá necesitar comprobar que una persona cumple una condición determinada sin capturar el documento entero que tradicionalmente se usaba como prueba. Ese giro no elimina obligaciones; las redistribuye. Si hoy tu proceso interno se basa en “suba aquí una copia del documento”, mañana tendrás que responder preguntas más incómodas: qué atributo exacto necesito, quién puede emitirlo con garantías suficientes, cuánto tiempo debo conservar la evidencia de verificación y qué hago si la credencial se revoca o deja de ser fiable.

Los ejemplos posibles son obvios aunque conviene no vender como cerrada una lista que el marco normativo no enumera de forma exhaustiva. La lógica del sistema apunta a atributos jurídicamente relevantes: edad, habilitación profesional, poderes de representación, afiliaciones o condiciones cuya prueba hoy exige documentación fragmentada. El detalle concreto dependerá de los esquemas de implementación, de la aceptación sectorial y de cómo cada ecosistema articule emisores y verificadores. Dicho sin maquillaje: habrá mucha política pública y bastante fontanería técnica antes de que esto funcione con la elegancia que prometen los folletos.

Para privacidad, la promesa es atractiva. Para auditoría y control interno, el reto es mayor. Un atributo no es solo un dato; es una afirmación emitida o avalada dentro de un marco de confianza. Si tu organización se apoya en esa afirmación para abrir una cuenta, conceder acceso, formalizar una operación o aceptar una firma, necesitarás gobernanza sobre tres capas distintas: la procedencia del atributo, la seguridad del canal de presentación y la conservación de la evidencia suficiente para defender la decisión después.

El verdadero cambio: de documentos a afirmaciones verificables

Durante años, muchas empresas han confundido diligencia con acumulación. Cuanto más documento, mejor. Cuantas más copias, más tranquilos estamos. Luego llega GDPR y recuerda que guardar de más también genera riesgo. Después llegan incidentes de seguridad, brechas, accesos internos indebidos y litigios sobre conservación excesiva. Sorpresa: convertir todo en un repositorio documental no era una estrategia, era una costumbre.

La arquitectura de credenciales y atributos empuja en sentido contrario. Obliga a pensar en términos de afirmaciones verificables y de pruebas limitadas al propósito. Ese enfoque puede reducir exposición de datos, pero solo si la implementación no repite el mismo vicio con otro envoltorio. Porque sí, siempre existe la tentación corporativa de pedir la wallet y además la copia en PDF “por si acaso”. El “por si acaso” es el deporte favorito del mal compliance.

Desde el punto de vista jurídico, la cuestión no es solo de eficiencia. También afecta a la base de legitimación, la minimización y la trazabilidad de decisiones. Si una entidad pide más datos de los necesarios, tendrá más difícil justificar el tratamiento bajo GDPR. Si además automatiza decisiones o perfiles apoyándose en credenciales o atributos, deberá revisar con cuidado los artículos 13, 14, 22 y 30 del GDPR, además de los controles de seguridad del art. 32 y el régimen de notificación de brechas de los arts. 33 y 34.

La wallet, por tanto, no es una app simpática para simplificar onboarding. Es una presión regulatoria y arquitectónica para pasar de evidencia pesada a evidencia precisa. Y ese cambio toca políticas de retención, matrices de acceso, third-party risk, diseño de journeys digitales y capacidad de demostrar que una verificación existió sin almacenar medio archivo histórico del usuario.

Servicios de confianza: lo que parecía un nicho deja de serlo

Si hay una lección repetida en regulación digital europea es esta: lo que empieza como infraestructura “de confianza” termina siendo infraestructura “crítica” para procesos de negocio. Los servicios cualificados de confianza de eIDAS llevaban años ahí —firmas, sellos, sellado temporal, entrega electrónica certificada, autenticación de sitios web, conservación en ciertos contextos—, pero muchas organizaciones los trataban como una capa jurídica especializada, casi notarial, separada del grueso de sus sistemas. Mala idea.

Con la evolución del marco de identidad digital, esa separación se vuelve menos sostenible. La confianza deja de vivir solo en el momento de la firma y pasa a formar parte de cómo se expiden, presentan y verifican determinadas evidencias electrónicas. No significa que todo proveedor o componente de ese ecosistema entre automáticamente en la misma categoría regulatoria. Significa algo más útil: que identidad, evidencia y seguridad operativa empiezan a depender unas de otras de manera mucho más visible.

Para una entidad regulada, eso exige dejar de comprar servicios de confianza como si fueran un apéndice legal del negocio. Hay que evaluarlos como dependencias reales del proceso: disponibilidad, integridad, revocación, interoperabilidad, gestión de incidentes, subcontratación, pruebas de continuidad y derechos de auditoría. No porque una norma concreta haga magia por sí sola, sino porque cuando una credencial o una verificación falla, el problema ya no se queda en lo documental. Se convierte en fallo operativo, de control, de servicio al cliente y, a menudo, de cumplimiento.

Qué cambia para compliance: menos fetichismo documental, más gobierno de evidencias

Los equipos de compliance suelen sentirse cómodos con expedientes gruesos. Se ven, se archivan, se enseñan al auditor. El problema es que el regulador no premia la estética del archivo, sino la eficacia y proporcionalidad del control. La transición hacia credenciales y atributos verificables obliga a repensar varias prácticas que hoy parecen sólidas y en realidad son bastante primitivas.

La primera es la definición del dato necesario. Si tu procedimiento requiere probar una condición, tendrás que identificar si basta un atributo verificable o si sigue siendo imprescindible el documento fuente. Esto parece menor, pero no lo es: cambia formularios, UX, integraciones y retención. También cambia la conversación con negocio, que rara vez pide el mínimo indispensable a la primera.

La segunda es la calidad de la evidencia. No toda verificación tiene el mismo peso. Una comprobación visual de un PDF remitido por correo no equivale a una credencial emitida o validada bajo un marco de confianza robusto. Pero tampoco cualquier “token” o credencial digital merece confianza por defecto. Compliance deberá clasificar supuestos por nivel de riesgo y por consecuencia jurídica: alta de cliente, acceso a sistemas, firma contractual, representación societaria, autorización interna, pagos, reclamaciones, siniestros o ejercicio de derechos.

La tercera es la conservación. Aquí está una de las trampas más frecuentes. Reducir datos en el momento de la verificación no significa quedarse sin evidencia para auditoría, defensa jurídica o supervisión. Significa conservar la evidencia adecuada. Ese equilibrio debe anclarse a finalidades y plazos internos consistentes con GDPR art. 5.1.e sobre limitación del plazo de conservación y con las obligaciones sectoriales que sí exijan trazabilidad. Guardarlo todo no es prudencia; a veces es pereza con coste legal diferido.

¿Y los registros electrónicos? Útiles, sí; barra libre, no

Otro punto que conviene enfriar un poco: la tentación de presentar los libros de registro electrónicos o mecanismos equivalentes como una solución universal para cualquier necesidad de prueba. El marco eIDAS revisado amplía y actualiza instrumentos de confianza electrónica, pero de ahí no se deduce automáticamente una lista cerrada de casos de uso operativos para auditoría, accesos privilegiados, consentimientos o ejecución de controles. Esos son escenarios plausibles desde el punto de vista técnico y de gobierno de evidencias, pero no deben venderse como una consecuencia textual y cerrada del reglamento.

La lectura seria es otra. Si tu organización necesita preservar integridad, trazabilidad y fuerza probatoria de determinados eventos o evidencias, algunos servicios de confianza y mecanismos alineados con eIDAS pueden ser relevantes para el diseño del control. Cuándo lo son de verdad depende del caso de uso, del requisito legal aplicable, del valor que deba tener la prueba y de si existe una exigencia sectorial específica. La palabra clave aquí no es “puede”, sino “para qué”.

Eso obliga a distinguir entre tres planos que muchas empresas mezclan con entusiasmo improductivo: registro técnico, evidencia jurídica y registro regulatorio. Un log de sistema puede servir para investigar un incidente. No siempre bastará como prueba robusta de una manifestación de voluntad o de una entrega electrónica. Del mismo modo, una evidencia con fuerte valor jurídico no reemplaza por sí sola las necesidades de observabilidad, correlación y detección de seguridad. Cuando alguien promete resolver todo con un único “registro confiable”, suele estar vendiendo simplicidad donde hay capas distintas de control.

Privacidad: la minimización gana terreno, pero la gobernanza se complica

Si algo tiene sentido en la wallet europea es la idea de revelar menos. GDPR lleva años pidiendo exactamente eso y demasiadas organizaciones siguen actuando como si la minimización fuera un consejo decorativo. La posibilidad de compartir atributos concretos en lugar de documentos completos encaja bien con el principio de minimización del art. 5.1.c y con la protección de datos desde el diseño del art. 25.

Ahora viene la parte menos romántica. Cuanto más fino es el intercambio de datos, más exigente se vuelve la gobernanza. Hay que definir qué atributo se solicita, con qué finalidad, si basta una comprobación puntual o hace falta conservar una evidencia asociada, qué base jurídica aplica y qué información se da al usuario. También hay que entender la cadena de actores: emisor, wallet, verificador, posibles prestadores de servicios de confianza y, en algunos casos, integradores tecnológicos. Cuantos más intermediarios, más preguntas sobre roles, responsabilidades y medidas de seguridad.

Las tensiones con GDPR no desaparecen; cambian de sitio. La minimización puede mejorar, pero aparecen retos nuevos sobre trazabilidad de consentimiento cuando este sea la base aplicable, ejercicio de derechos, transparencia sobre verificaciones realizadas y gestión de incidentes. Si una credencial o atributo revela información sensible o permite inferencias delicadas, la evaluación de impacto del art. 35 puede dejar de ser una opción cómoda para convertirse en una necesidad razonable.

Y no olvidemos la higiene básica: si una organización implementa la wallet pero sigue pidiendo capturas de pantalla, reenvío por correo y almacenamiento paralelo de documentos completos, no ha modernizado nada. Solo ha encarecido el desorden.

La conexión con resiliencia operativa existe, pero hay que explicarla sin atajos

Decir que todo esto “encaja de lleno” con DORA suena contundente, pero necesita más precisión de la que suele verse en artículos apresurados. Lo que sí puede afirmarse con fundamento es que, para las entidades dentro del ámbito de DORA, los servicios, proveedores y dependencias tecnológicas que soporten procesos críticos de identificación, autenticación, firma o verificación pueden entrar en el análisis de riesgo TIC, gobernanza, gestión de incidentes, continuidad y terceros previsto por el reglamento.

La conexión regulatoria no nace porque eIDAS y DORA digan exactamente lo mismo, sino porque DORA obliga a gestionar el riesgo operativo digital asociado a funciones y servicios ICT relevantes. Ahí importan, entre otros, la gobernanza del riesgo TIC y el marco de gestión del riesgo del capítulo II, la notificación de incidentes del capítulo III, las pruebas de resiliencia operativa digital del capítulo IV y la gestión del riesgo de terceros TIC del capítulo V, incluido el art. 28 sobre principios clave para gestionar riesgo derivado de terceros.

En la práctica, si una entidad financiera depende de componentes de identidad o confianza electrónica para procesos esenciales, no puede tratarlos como un asunto exclusivamente legal o de experiencia de usuario. Debe decidir si son soporte de funciones críticas o importantes, cómo se documentan en el inventario de dependencias, qué escenarios de fallo afectan al servicio, qué cláusulas contractuales necesita y qué evidencias pedirá al proveedor sobre seguridad, continuidad, subcontratación e incidentes. Esa es la lectura útil. La otra —la de meter cualquier prestador del ecosistema eIDAS dentro de DORA por reflejo— es demasiado gruesa para ser seria.

NIS2 también asoma, sobre todo donde identidad y acceso sostienen servicios esenciales

Fuera del perímetro financiero, la conversación se cruza con NIS2 de una manera más natural de lo que parece. No porque la wallet aparezca como fetiche normativo, sino porque identidad, autenticación y gestión de acceso son piezas centrales de la seguridad de redes y sistemas de información. NIS2 art. 21 exige medidas técnicas, operativas y organizativas apropiadas y proporcionadas, incluyendo políticas de análisis de riesgos y seguridad de sistemas, gestión de incidentes, continuidad, seguridad de la cadena de suministro y uso de soluciones de autenticación multifactor o autenticación continua cuando proceda.

Si una organización esencial o importante integra carteras, credenciales o servicios de confianza en accesos, onboarding, interacción con usuarios o procesos críticos, esa capa pasará a formar parte de su superficie de riesgo. Lo interesante es que NIS2 no premia palabras mágicas; premia control efectivo. Una identidad digital bien diseñada puede mejorar seguridad y reducir fraude. Una mal integrada puede crear un precioso punto único de fallo con terminología europea impecable.

La pregunta práctica es sencilla: si mañana se cae tu mecanismo de verificación de atributos, ¿qué proceso se interrumpe, cuánto tarda en recuperarse y qué alternativa controlada existe? Si no puedes contestarlo, la sofisticación del esquema importa menos de lo que crees.

El riesgo menos comentado: representación y delegación

Hay un área especialmente delicada que no está recibiendo suficiente atención fuera de círculos jurídicos y de diseño de identidad: la representación. Acreditar que una persona es quien dice ser ya era complicado. Acreditar que puede actuar válidamente en nombre de una sociedad, una administración, un cliente o una unidad interna es bastante más espinoso.

La razón es obvia. La representación cambia, caduca, se limita, se revoca y depende de registros, poderes, estatutos, mandatos y controles internos que rara vez viven en un único sistema limpio y actualizado. Cualquier arquitectura de atributos que aspire a soportar estos casos necesitará una gobernanza impecable sobre fuente de verdad, actualización y revocación. Si no, el riesgo no será teórico: decisiones adoptadas por quien ya no tenía facultades, accesos mantenidos de más, operaciones ejecutadas sobre una base representativa discutible y un festival de remediación posterior.

Para compliance, este punto merece más atención que muchas discusiones abstractas sobre interoperabilidad paneuropea. La interoperabilidad está muy bien. El problema real llega cuando una empresa acepta una representación aparentemente válida y luego descubre que nadie definió quién responde por la actualización del atributo o qué evidencia se conserva de la comprobación realizada en ese momento.

Qué deberían revisar ya las empresas

Si tu organización quiere prepararse con algo más de seriedad que un webinar con fondo azul, hay cinco preguntas que conviene resolver pronto.

• Qué decisiones dependen hoy de documentos completos. Haz un mapa de procesos: alta de clientes, poderes, acceso a áreas privadas, firma, contratación, autorizaciones internas, verificación de edad o elegibilidad. Si no sabes dónde pides más datos de los necesarios, no podrás rediseñar nada.
• Qué atributos serían suficientes. No desde tecnología, sino desde necesidad jurídica y operativa. La unidad de análisis no es “qué wallet soportamos”, sino “qué afirmación basta para este control”.
• Quién emite o valida la evidencia. Revisa si dependes de registros públicos, prestadores de confianza, sistemas internos, terceros sectoriales o combinaciones de todos ellos. La procedencia condiciona fiabilidad, continuidad y defensa ante auditoría.
• Qué evidencia conservas y por cuánto tiempo. Ni todo ni nada. Define qué rastro necesitas para acreditar la verificación sin quedarte con datos excesivos. Aquí chocan, como siempre, legal, seguridad, negocio y operaciones. Bienvenidos al trabajo real.
• Qué pasa si el sistema falla. Contingencia manual, degradación controlada, aceptación diferida, mecanismos alternativos y criterios de rechazo. Si tu único plan es “ya veremos”, tu diseño todavía es una demo.

Este ejercicio tiene una ventaja: sirve aunque la adopción de la wallet vaya más lenta de lo que Bruselas imagina, una posibilidad que nadie con experiencia debería descartar. Revisar minimización, evidencias, representación y dependencias de terceros ya aporta valor por sí mismo. Y bastante.

No todo será armonización feliz

Conviene rebajar un poco el entusiasmo regulatorio. Europa tiene tendencia a presentar la interoperabilidad como si fuera un destino y no un proceso plagado de excepciones nacionales, fricciones sectoriales y sistemas heredados que se resisten a morir. La wallet europea aspira a ofrecer un lenguaje común. Eso no significa que todos los casos complejos de identidad, mandato, elegibilidad o prueba documental vayan a resolverse de manera uniforme y rápida.

Habrá tensiones entre derecho nacional y esquemas comunes. Habrá sectores más preparados que otros. Habrá relying parties que acepten ciertos atributos y otras que, por prudencia o por simple inmadurez, sigan exigiendo pasos redundantes. Y habrá un largo periodo en el que convivirán procesos nuevos y viejos, justo el escenario favorito para los fallos de control, los tratamientos duplicados y las inconsistencias de auditoría.

Ese periodo híbrido merece más atención de la que recibe. No es una nota al pie; es donde vivirán los riesgos reales. La mayor parte de incidentes no se producen cuando un modelo está plenamente implantado, sino cuando dos modelos compiten y nadie ha definido con claridad cuál prevalece, qué evidencia manda y cómo se reconcilian las excepciones.

La cuestión de fondo: confianza demostrable, no confianza declarativa

La Unión Europea lleva años construyendo marcos de confianza digital. A veces con buena técnica. A veces con entusiasmo normativo digno de estudio. El valor de la wallet y de la revisión de eIDAS no estará en la retórica de soberanía digital ni en el número de apps desplegadas, sino en algo más terrenal: si una organización puede aceptar una afirmación electrónica y defender después, con base técnica y jurídica suficiente, que hizo lo correcto.

Esa defensa no se improvisa. Requiere saber qué atributo se verificó, con qué nivel de seguridad, quién lo emitió o respaldó, bajo qué reglas, qué dependencia tecnológica intervino, qué evidencia se conservó y qué alternativa existía si el proceso fallaba. Lo demás es marketing regulatorio.

Por eso el debate interesante no es si la wallet “va a revolucionar” la identidad digital europea. Esa frase sirve para eventos. La pregunta seria es mucho menos glamourosa: ¿tu organización está preparada para sustituir documentos por atributos sin perder control, trazabilidad ni capacidad de defensa? Si la respuesta es no, el trabajo empieza bastante antes de la primera integración técnica.

Y sí, hay una ironía final. Llevamos años diciendo que las empresas deben recoger menos datos, depender menos de procesos manuales y diseñar mejor sus evidencias. Ahora llega una arquitectura que empuja exactamente en esa dirección y muchos descubrirán que el obstáculo no era la falta de tecnología. Era el apego corporativo a pedirlo todo, guardarlo todo y entender la confianza como una carpeta compartida.

No será un cambio cosmético. Será un examen de madurez. Y esos, por desgracia, no se aprueban con un PDF más bonito.