Los estándares europeos que hablamos

Publicamos model cards legibles por máquina de los modelos de matching y de predicción, guardamos una explicación factor por factor de los primeros resultados de una búsqueda talent-match y se la mostramos al estudiante en /matches/[id]/why. Las operaciones sensibles se escriben en un registro de auditoría.

El registro de algoritmos y las explicaciones por match están activos en la búsqueda talent-match. Las pruebas de sesgo, la cobertura de los demás sistemas de puntuación y la documentación técnica del Anexo IV no existen.

Exposición de autoservicio de los derechos art. 15/16/17/20. Consentimiento de cookies por categoría. Base de datos principal en la Unión Europea; la página de privacidad indica qué subencargados están fuera del EEE y con qué base de transferencia.

Acceso, rectificación, supresión y portabilidad son de autoservicio. La revisión humana del art. 22 se solicita dentro del producto desde la explicación del match: la solicitud se registra con una referencia y un vencimiento a 30 días y, al cerrarse, el resultado del revisor se escribe de vuelta en la explicación. Quien no ha iniciado sesión y la página del registro de algoritmos siguen remitiendo al correo electrónico.

Hoy: registro de auditoría en operaciones sensibles, registro público de model cards y decisión humana obligatoria en el cribado de Talent Suite. Las pruebas de sesgo y la documentación de gobernanza de datos no existen.

No estamos certificados en ISO/IEC 42001 y no disponemos de un sistema de gestión de IA documentado.

Los términos de competencias se resuelven a URIs de ESCO primero en nuestra tabla SkillMapping, luego en un pequeño mapa curado y por último en la API de ESCO en directo, con los aciertos guardados en caché en SkillMapping. El matching unifica los términos de competencias a través de ese índice mapeado a ESCO. La puntuación de matching en sí no incluye URIs de ESCO.

Los estudiantes exportan su perfil basado en pruebas como Europass v3 JSON-LD con un solo clic.

Cada Verifiable Credential que emitimos es exportable en formato EDCI JSON-LD con la prueba Ed25519 preservada. La exportación de un credential individual incluye además el nivel EQF que consta en el expediente del estudiante, cuando lo hay.

Las credenciales se emiten con la forma documental de los W3C Verifiable Credentials y se firman con Ed25519 sobre una serialización JSON canónica propia — no la suite W3C Ed25519Signature2020, que exige canonicalización RDF URDNA2015 y un proofValue multibase. La clave pública se publica para la verificación sin conexión.

Los estudiantes exportan sus competencias de nivel Avanzado/Experto como credenciales Open Badges 3.0.

Las competencias digitales de nuestro catálogo usan los nombres y áreas de DigComp. Los identificadores que asignamos no son URI publicados por el JRC.

Las competencias de emprendimiento usan los nombres y áreas de EntreComp, con los mismos límites en los identificadores.

Las competencias de sostenibilidad usan los nombres y áreas de GreenComp, con los mismos límites en los identificadores.

Los niveles EQF los asigna la autoridad que expide el título; nosotros no los deducimos. La exportación EDCI de una credencial individual solo incluye un nivel que ya conste en la ficha del estudiante y omite el campo cuando no hay ninguno.

Existe un endpoint de metadatos SAML de marcador de posición que devuelve un descriptor vacío. El flujo de autenticación no está construido.

Scaffold SPID/CIE: lista tipada de IdP y modelo de atributos. Ningún flujo de acceso conectado; el registro ante AgID está pendiente.

Las credenciales EDCI y W3C VC que emitimos están en los formatos que deberían leer los wallets EUDIW; aún no se ha construido ni probado ninguna integración con un wallet.

Las credenciales ya son compatibles con EDCI. La integración con el wallet llegará cuando las implementaciones de referencia alcancen la beta pública.

El modelo de datos para las equivalencias ECTS existe, pero hoy ninguna pantalla lo usa.

La exportación de matrículas de intercambio en OLA JSON-LD existe como endpoint de API; hoy ninguna pantalla la invoca. La integración con la red EWP requiere un onboarding SAML por institución.

El modelo de datos para los acuerdos bilaterales existe; hoy ninguna pantalla lo usa.

Sin conexión a la red EWP: ningún endpoint registrado.

No hay integración con la red ENIC-NARIC.

Previsto, sin fecha.