El papel de TI en una estrategia de credenciales verificables

Una universidad inicia un proyecto de microcredenciales con una sola unidad académica. Durante el piloto emite algunos cientos de credenciales y la operación parece sencilla.

Tres años después, otras facultades quieren incorporarse, el volumen crece y la institución evalúa cambiar de proveedor.

Es en ese momento cuando aparecen preguntas que durante el piloto parecían secundarias:

• ¿Las credenciales emitidas seguirán siendo verificables?
• ¿La universidad conserva su identidad como emisora?
• ¿La información puede migrarse?
• ¿La solución puede integrarse con otros sistemas?
• ¿Cambiar de proveedor implica reconstruir parte de la operación?

Estos problemas no necesariamente surgen porque la tecnología haya funcionado mal. Pueden aparecer precisamente porque funcionó bien en el corto plazo, pero fue elegida sin considerar suficientemente lo que ocurriría cuando la estrategia creciera.

Ahí está el papel estratégico de TI.

Las áreas académicas deben definir qué quiere reconocer la institución, bajo qué criterios y quién puede autorizarlo. TI debe evaluar si la tecnología elegida permite sostener esas decisiones de manera segura, interoperable y sostenible.

TI no debería decidir la estrategia de microcredenciales, pero sí debería poder advertir cuándo una decisión tecnológica puede limitarla en el futuro.

Traducir la estrategia en requisitos tecnológicos

Cuando una universidad sabe qué quiere hacer con sus microcredenciales, TI puede transformar esas decisiones en preguntas concretas.

• Si las credenciales deberán utilizarse fuera de los sistemas universitarios, la solución necesitará interoperabilidad.
• Si varias facultades emitirán bajo un mismo marco institucional, habrá que definir permisos y responsabilidades.
• Si el volumen crecerá, será necesario considerar automatización e integración.
• Si las credenciales deben mantenerse vigentes durante años, habrá que evaluar qué componentes deberán seguir disponibles para verificarlas.

El punto no es anticipar todos los escenarios posibles. Es evitar que la institución descubra demasiado tarde que una decisión tecnológica tomó por ella una decisión que en realidad era institucional.

Integración: una nueva plataforma no debería convertirse en una isla

Durante un piloto, muchas operaciones pueden resolverse manualmente. Con cien credenciales puede ser perfectamente viable. Con diez mil, probablemente no.

A medida que una estrategia crece, las microcredenciales comienzan a relacionarse con sistemas que la universidad ya utiliza:

• control escolar
• educación continua
• plataformas de aprendizaje
• directorios institucionales
• sistemas administrativos
• mecanismos de identidad y acceso
• repositorios académicos
• sistemas de seguimiento de estudiantes o egresados.

No significa que todo deba integrarse desde el primer día.

De hecho, intentar hacerlo podría añadir complejidad innecesaria a un piloto.

La pregunta que TI debería plantearse es diferente:

¿La solución puede integrarse progresivamente al ecosistema tecnológico de la universidad o obliga a mantener permanentemente una operación paralela?

Una buena implementación debería permitir comenzar de manera sencilla y aumentar gradualmente el nivel de automatización.

La interoperabilidad promovida por estándares como Open Badges 3.0 contempla precisamente el intercambio de información entre diferentes aplicaciones y servicios, no únicamente la generación visual de una insignia.[^1]

Para TI, esto significa pensar más allá del funcionamiento inmediato. Una plataforma aislada puede ser suficiente para demostrar un concepto. Una capacidad institucional necesita convivir con los sistemas que ya sostienen la operación universitaria.

Seguridad: proteger algo más que información

La seguridad de una plataforma de credenciales verificables no se limita a proteger nombres, correos electrónicos o expedientes. Existe otro activo particularmente sensible: la capacidad de emitir en nombre de la institución.

Una cuenta con permisos de emisión no es equivalente a una cuenta común de usuario. Quien pueda utilizarla podría generar una credencial que afirme que la universidad reconoce determinado aprendizaje, competencia o logro. Esto convierte la administración de accesos en una cuestión directamente vinculada con la autoridad institucional.

Por eso TI debería revisar, entre otros aspectos:

• autenticación
• perfiles y permisos
• separación de responsabilidades
• trazabilidad de acciones
• revocación de accesos
• protección de funciones críticas

Las guías de identidad digital del National Institute of Standards and Technology (NIST) colocan precisamente la autenticación, la administración de identidades y el ciclo de vida de los accesos entre los componentes fundamentales para proteger sistemas digitales.[^2]

La pregunta práctica es sencilla: ¿Puede la institución saber quién hizo qué, con qué autorización y en qué momento?

Identidad emisora: ¿quién representa digitalmente a la universidad?

En una credencial tradicional resulta evidente quién emite. Aparecen el nombre institucional, el sello, las firmas y los elementos gráficos de la universidad.

En una credencial verificable existe además una representación técnica del emisor. Ese elemento suele permanecer invisible para estudiantes y autoridades académicas, pero tiene consecuencias importantes para TI.

El modelo de credenciales verificables del W3C distingue explícitamente al emisor como una de las partes centrales del ecosistema y permite identificar técnicamente a quien realiza la afirmación contenida en la credencial.[^3]

Los identificadores descentralizados —DID— son una de las alternativas para representar esa identidad digital y asociarla con mecanismos mediante los cuales una organización puede demostrar su relación con ella.[^4]

Para una universidad, sin embargo, la conversación importante no debería comenzar por cómo funciona técnicamente un DID. Debería comenzar por preguntas más sencillas:

• ¿Qué identidad aparecerá como emisora?
• ¿Representa inequívocamente a la universidad?
• ¿Quién administra esa identidad?
• ¿Quién administra los mecanismos criptográficos asociados?
• ¿Qué sucede si cambia el proveedor?
• ¿Existen procedimientos para mantener continuidad sobre esa identidad?
• ¿Las credenciales históricas seguirán reconociendo claramente a la institución que las emitió?

Utilizar tecnología de un tercero es completamente normal. Las universidades utilizan proveedores para correo electrónico, almacenamiento, plataformas educativas, servicios administrativos y prácticamente todas las áreas de su operación.

El punto es distinguir entre utilizar la tecnología de un proveedor y depender de su identidad para representar a la universidad.

Interoperabilidad: ¿la credencial puede salir de la plataforma?

Una microcredencial puede verse perfectamente dentro de una plataforma y aun así tener una interoperabilidad limitada fuera de ella.

Para TI, una de las preguntas más útiles debe ser: “¿La credencial puede salir de ese entorno y continuar siendo interpretable y verificable?”

Los estándares abiertos adquieren aquí un sentido operativo. W3C Verifiable Credentials define un modelo común para representar credenciales, emisores, titulares y mecanismos de verificación, mientras que Open Badges 3.0 adopta el modelo de credenciales verificables para representar logros educativos y establece mecanismos para su intercambio entre sistemas.[^1][^3]

En términos operativos, esto debería traducirse en preguntas concretas:

• ¿Puede otra aplicación interpretar la credencial?
• ¿Puede un estudiante llevarla a un entorno compatible?
• ¿Puede un tercero verificarla sin depender exclusivamente de la interfaz donde se emitió?
• ¿La universidad podría incorporar otras soluciones en el futuro?

Esta conversación ya comienza a aparecer también en México. En el marco de la Conferencia Internacional ANUIES 2026 se plantea explícitamente la necesidad de avanzar hacia una infraestructura nacional interoperable basada en credenciales verificables, billeteras digitales y estándares internacionales.[^5]

Por tanto, la interoperabilidad deja de ser una característica atractiva para convertirse progresivamente en una condición para participar en ecosistemas más amplios.

Continuidad: una credencial puede durar más que el contrato

Aquí aparece una diferencia importante entre una aplicación convencional y una plataforma de credenciales.

Muchas aplicaciones pueden reemplazarse cuando terminan su vida útil. Las credenciales que produjeron no necesariamente.

Una persona puede presentar dentro de cinco, diez o más años una microcredencial obtenida hoy. Eso obliga a TI a mirar la decisión tecnológica desde una perspectiva distinta.

• ¿Qué sucede si cambia la plataforma?
• ¿Qué ocurre si termina el contrato?
• ¿Qué componentes necesitan seguir disponibles para verificar lo emitido?
• ¿Qué pasa si cambia la tecnología?
• ¿Puede conservarse la información necesaria?
• ¿Las credenciales previamente emitidas mantienen mecanismos de verificación?
• ¿La universidad conserva los elementos necesarios para sostener su identidad emisora?

El W3C contempla precisamente que una credencial verificable contiene información sobre su emisor, mecanismos de seguridad y, cuando corresponde, información que permite conocer su estado —por ejemplo, si ha sido suspendida o revocada—. Pero utilizar un estándar no elimina automáticamente todas las dependencias. [^3]

La institución debe comprender qué servicios intervienen realmente en la verificación y cuáles deberán mantenerse disponibles. De ahí una regla institucional particularmente importante: La vida útil de una credencial no debería estar determinada por la vida útil de una relación comercial.

Escalabilidad: evaluar para la universidad posterior al piloto

Escalabilidad no significa únicamente que puedan procesar más transacciones. También significa que la solución pueda acompañar mayor complejidad institucional.

Un piloto puede comenzar con: una unidad académica; algunos programas; dos responsables; unos cientos de emisiones.

Una operación institucional puede involucrar: múltiples facultades; miles de estudiantes; distintos tipos de credenciales; múltiples responsables; integraciones con otros sistemas; distintos niveles de autorización; y diferentes experiencias de entrega y verificación.

Por eso TI debería  analizar si permite incorporar mayor complejidad institucional sin multiplicar innecesariamente: procesos manuales; cuentas independientes; duplicidades de información; tareas administrativas; desarrollos especiales; costos; o dependencias.

Una plataforma puede escalar técnicamente, pero no escalar institucionalmente.

Si cada nueva facultad requiere reconstruir procesos, desarrollar integraciones específicas o crear operaciones completamente independientes, el crecimiento tecnológico puede convertirse en fragmentación organizacional.

La pregunta adecuada no es: “¿Cuántas credenciales puede emitir el sistema?”

Sino: “¿Puede acompañar a la institución conforme la estrategia se extiende hacia nuevas áreas, volúmenes y casos de uso?”

Siete preguntas que TI debería poder responder

Antes de aprobar una solución de credenciales verificables, una revisión ejecutiva podría concentrarse en siete preguntas:

1. Integración: ¿Podremos conectarla progresivamente con los sistemas existentes?
2. Seguridad: ¿Podemos controlar quién administra, autoriza y emite, y conservar trazabilidad de esas acciones?
3. Identidad emisora: ¿Cómo se representa digitalmente a nuestra institución y qué papel juega el proveedor en esa identidad?
4. Interoperabilidad: ¿Las credenciales pueden utilizarse y verificarse fuera de la plataforma?
5. Continuidad: ¿Qué debe permanecer disponible para verificar una credencial dentro de varios años?
6. Salida: ¿Qué conserva la institución si decide cambiar de proveedor?
7. Escalamiento: ¿Podemos incorporar nuevas áreas y aumentar volumen sin reconstruir la operación?

Estas preguntas suelen decir más sobre la sostenibilidad de una solución que una larga lista de funcionalidades.