El eIDAS 2.0 es la modificación del marco europeo de identificación electrónica y servicios de confianza que incorpora la Cartera Europea de Identidad Digital. Para una empresa que presta servicios, la decisión no es «instalar una cartera», sino preparar cómo solicitar, verificar y usar pruebas de identidad o atributos dentro de un proceso real, con protección de datos y alternativas para el usuario.
La cartera no sustituye por sí sola los controles de riesgo, la diligencia debida, las políticas de acceso o la intervención humana. Puede reducir fricción y duplicidades, pero ese beneficio solo se comprueba frente a una línea base y depende del sector, del papel jurídico de cada entidad y de la disponibilidad efectiva del ecosistema.
Qué es eIDAS 2.0 y qué cambia
El Reglamento (UE) 2024/1183 modifica el Reglamento (UE) 910/2014: no borra el marco anterior. Extiende el esquema de identidad digital europea y establece las bases de las carteras para presentar datos de identificación personal y acreditaciones de atributos. La Comisión Europea explica que los Estados miembros deberán ofrecer carteras a ciudadanos y empresas; el desarrollo depende también de normas de ejecución y despliegues nacionales.
Una acreditación puede probar un dato específico sin repetir todo el alta documental. En términos de arquitectura, la empresa que recibe esa presentación es una parte usuaria o relying party: debe determinar qué pide, verificar la prueba y decidir qué hace con ella. Emitir carteras o prestar servicios de confianza son papeles diferentes, que este artículo no atribuye a OpenSistemas.
La AEPD subraya que el control del titular y la protección de datos son centrales. La posibilidad técnica de pedir un dato no justifica recogerlo: hay que definir finalidad, base jurídica, conservación y una experiencia comprensible.
Qué debe decidir una empresa antes de integrar una cartera
No todas las organizaciones tienen las mismas obligaciones. Hay que distinguir si se actúa como prestador de servicios, entidad obligada a identificar, emisor de atributos o proveedor cualificado; identificar el territorio y revisar los textos aplicables con el equipo jurídico. Una cartera tampoco convierte automáticamente en válida cualquier firma, autenticación o decisión comercial.
La pregunta operativa es concreta: ¿qué prueba hace falta para completar un alta, permitir acceso o aceptar una representación? Si basta verificar un atributo, solicitar el expediente completo añadiría superficie de riesgo. En nuestro análisis del alta digital se detalla por qué identidad, consentimiento, riesgo y activación deben coordinarse sin convertirse en un único formulario gigante.
Arquitectura: de la presentación a la decisión trazable
Un diseño útil separa cuatro funciones: canal de interacción, verificación técnica, decisión de negocio e integración con sistemas. La arquitectura de referencia de la cartera europea documenta roles e interfaces; la integración empresarial concreta necesita además permisos, registros de eventos, tratamiento de errores y responsables del proceso.
La secuencia propuesta comienza cuando la persona acepta presentar un atributo. El verificador comprueba integridad, emisor, vigencia y adecuación al propósito conforme al perfil técnico que corresponda. Una regla de negocio o una persona responsable decide si continuar, revisar o detener el trámite. Solo entonces se actualizan los sistemas corporativos necesarios, evitando replicar sin límite el dato recibido.
En Open Banking se aborda otro problema de intercambio de datos con consentimiento y APIs; no es una explicación alternativa de eIDAS. El enlace ayuda a separar arquitectura de integración e identidad.
Privacidad, seguridad y continuidad: controles que no se pueden omitir
La minimización exige pedir únicamente los atributos necesarios. La verificación exige definir fuentes de confianza, controles de integridad y respuesta a pruebas no válidas. La continuidad exige una vía alternativa accesible mientras las carteras y los prestadores no estén disponibles para todos los supuestos. La traza debe documentar las comprobaciones y la decisión sin conservar copias innecesarias de credenciales.
Conviene separar autenticación, identificación, prueba de un atributo y firma: resuelven preguntas distintas. Si el proceso requiere diligencia reforzada o validación de representación, debe mantenerse el control específico aplicable. Un piloto no acredita cumplimiento general; seguridad, privacidad y asesoría jurídica deben aprobar el alcance.
| Función | Pregunta operativa | Salida esperada |
|---|---|---|
| Canal | ¿Qué atributo se solicita y con qué finalidad? | Solicitud entendible y proporcionada |
| Verificación | ¿Qué prueba, emisor y vigencia se aceptan? | Resultado verificable o excepción |
| Decisión | ¿Quién acepta, revisa o rechaza? | Criterio, responsable y traza |
| Integración | ¿Qué sistema necesita el resultado? | Actualización limitada y auditable |
Cinco decisiones para pasar del mapa al piloto
Primero, definir el caso de uso: elegir una interacción y el atributo estrictamente necesario. Segundo, asignar responsabilidades: identificar quién recibe, verifica y decide. Tercero, diseñar la verificación: establecer confianza, vigencia, rechazo y revisión. Cuarto, conectar con el proceso: permisos, registros y vía alternativa. Quinto, medir antes de ampliar: contrastar errores, tiempo y coste con la línea base. Ningún paso presupone que la empresa emita credenciales.
Un primer piloto puede centrarse en una prueba de atributo dentro de un proceso ya existente, no en rediseñar simultáneamente todos los canales. Antes de activar una integración, se debe comprobar el perfil técnico vigente de la cartera y las normas de ejecución pertinentes.
Qué medir para evaluar el valor real
Mida tasa de trámites completados, tiempo hasta decisión, porcentaje de verificaciones que requieren revisión, errores de identidad o atributos y coste operativo por trámite. Segmente por canal y vía alternativa para no ocultar exclusión. Registre la línea base, período de comparación y criterios de calidad antes del piloto; un cambio de volumen o de mezcla de casos puede alterar el resultado sin que la tecnología sea la causa.
El retorno de inversión es una hipótesis: ahorro de trabajo manual y menor fricción podrían compensar costes de integración, operación, seguridad y soporte. No deben presentarse como una garantía ni confundirse con una reducción de obligaciones regulatorias.
Una credencial verificada responde qué prueba se presentó; no decide por sí sola si el proceso debe continuar.
Cómo puede ayudar OpenSistemas
El papel defendible de OpenSistemas es analizar el proceso, diseñar la integración entre experiencia, datos y sistemas, definir controles y acompañar la operación tecnológica. No actuamos aquí como autoridad de identidad ni afirmamos emitir carteras o certificados cualificados. Si necesitas decidir dónde encaja la identidad digital europea en un alta o servicio existente, empecemos por el caso de uso y sus dependencias.
GUÍA PARA COMITÉS DE DIRECCIÓN
¿Cómo pasar de los pilotos de IA a una capacidad operativa real?
Una guía para estructurar la conversación sobre adopción de IA empresarial antes de la próxima inversión.
Descargar la guíaPreguntas frecuentes sobre eIDAS 2.0
¿Qué es eIDAS 2.0?
Es la evolución del Reglamento europeo de identificación electrónica y servicios de confianza mediante el Reglamento (UE) 2024/1183. Incorpora el marco de las carteras europeas de identidad digital y nuevas reglas de confianza, sobre la base del Reglamento 910/2014.
¿Toda empresa debe emitir una cartera europea?
No. Emitir una cartera, prestar servicios de confianza y recibir una prueba como parte usuaria son funciones diferentes. Las obligaciones concretas dependen del papel de la entidad y de la normativa aplicable al servicio.
¿Una cartera sustituye el onboarding y el KYC?
No automáticamente. Puede aportar pruebas de identidad o atributos, pero el alta, la diligencia debida, el control de fraude y la activación requieren decisiones y controles propios del sector y del riesgo.
¿Hay que almacenar la credencial presentada?
No por defecto. Es preferible definir primero qué resultado necesita el proceso, con qué fundamento jurídico y durante cuánto tiempo debe conservarse. La minimización y la seguridad han de guiar el diseño.
¿Qué ocurre si una prueba no puede verificarse?
El proceso debe rechazarla o enviarla a revisión según reglas documentadas y ofrecer un recorrido alternativo cuando corresponda. La disponibilidad técnica de la cartera y la fiabilidad de cada prueba se comprueban en el contexto real.
¿Cómo se mide un piloto de identidad digital?
Compare con una línea base la finalización, el tiempo, los errores, las revisiones humanas y el coste por trámite. Registre también accesibilidad y uso de vías alternativas para evitar una mejora aparente a costa de excluir personas.
