Cómo evaluar y elegir una plataforma de credenciales digitales
Marco completo de due diligence, auditoría técnica, validación funcional, pruebas de verificabilidad, checklist documental, formulario maestro y matriz comparativa para universidades e instituciones educativas.
Idea central
No alcanza con comparar demos, claims comerciales o listas de features. Una institución debe exigir evidencia verificable: estándares implementados, certificaciones vigentes, pruebas funcionales, integraciones comprobadas, arquitectura de datos, controles de privacidad, continuidad operativa y una auditoría real de verificabilidad de la credencial.
Contenido de esta guía
01 · Objetivo, alcance y principios
Una evaluación rigurosa, no una demo comercial.
Este documento está diseñado para que una universidad pueda evaluar con rigor técnico, operativo, legal y funcional una plataforma de credenciales digitales antes de contratarla. Puede utilizarse como guía de mercado, documento interno de comité, checklist de due diligence, formulario de RFI/RFP, base para una prueba piloto y matriz de comparación entre múltiples proveedores.
La institución no está comprando solamente una herramienta para emitir badges o certificados visualmente atractivos. Está eligiendo infraestructura crítica para reputación digital, verificación, portabilidad, trazabilidad, privacidad, empleabilidad, integración académica y continuidad futura.
Seis principios rectores
Priorizar interoperabilidad y portabilidad
La institución debe evitar quedar atada a un proveedor o a un visor propietario.
Distinguir estándar, implementación y certificación
Decir que una plataforma «soporta» un estándar no equivale a demostrar una implementación real y verificable.
Evaluar el producto completo, no solo la emisión
Deben analizarse emisión, verificación, revocación, correcciones, experiencia del receptor, integraciones, analytics, gobierno operativo y salida futura.
Pedir evidencia y no solo afirmaciones
Cada claim relevante debe venir acompañado de documentos, pruebas, sandbox, logs, certificados, reportes o referencias verificables.
Comparar con casos de uso reales
La validación debe hacerse con escenarios concretos: diploma, microcredencial con skills, badge apilable, integración con LMS/SIS, verificación pública y revocación.
Tomar una decisión con criterios ponderados
Debe existir scoring, umbrales mínimos y red flags de descarte.
Diez dominios del alcance mínimo
02 · Proceso recomendado de selección
Siete fases. Saltar etapas sale caro.
Saltarse etapas suele generar compras basadas en discurso comercial, costos ocultos y migraciones traumáticas.
| Fase | Objetivo | Entregable | Qué valida | Señal de avance |
|---|---|---|---|---|
| 1. Definición interna | Alinear objetivos académicos, técnicos, legales y de empleabilidad | Casos de uso priorizados, criterios de éxito y responsables | Qué se quiere emitir y para qué | La institución sabe exactamente qué necesita |
| 2. RFI inicial | Filtrar proveedores que no cumplen mínimos | Respuesta documental y evidencias | Seriedad, estándar, certificaciones, integraciones y soporte | Quedan solo proveedores viables |
| 3. Demo guiada | Comparar flujos reales bajo el mismo guion | Acta de demo con observaciones | Claims comerciales y UX real | Se valida lo que el proveedor dice tener |
| 4. Due diligence | Revisar seguridad, privacidad, arquitectura y cumplimiento | Checklist completo con semáforos | Riesgos ocultos no visibles en una demo | Se detectan debilidades estructurales |
| 5. Piloto controlado | Probar con datos y procesos reales | Resultados del piloto y feedback | Operación real, tiempos y adopción | Se comprueba que funciona en contexto institucional |
| 6. Evaluación económica y contractual | Entender costo total y salida futura | TCO, SLA, DPA, plan de salida | Costos ocultos, lock-in y continuidad | La comparación económica es realista |
| 7. Decisión e implementación | Elegir y arrancar con gobernanza clara | Matriz final y plan de rollout | Madurez global del proveedor | Inicio con responsables, KPIs y alcance |
Recomendación práctica
El proveedor no debería ver la ponderación completa antes de responder. Primero debe entregar evidencia; luego la universidad aplica el scoring. Esto evita respuestas «optimizadas» para un formulario sin sustento real.
03 · Qué pedir obligatoriamente al proveedor
La carpeta mínima de evidencias.
Si el proveedor no puede o no quiere entregarla, ya existe una señal de riesgo.
| Documento / evidencia | Por qué importa | Aceptable si… |
|---|---|---|
| Ficha técnica del producto y arquitectura | Permite entender alcance real, límites, módulos, dependencias y modelo de datos | Describe entornos, arquitectura, flujos principales, módulos, APIs y dependencias |
| Documentación de APIs + sandbox | Valida integrabilidad real | Incluye endpoints, autenticación, ejemplos, rate limits, versionado y ambiente de prueba |
| Matriz de estándares soportados | Evita claims vagos | Indica estándar exacto, versión, alcance y evidencia de conformidad |
| Listado de certificaciones vigentes | Comprueba madurez | Incluye organismo, vigencia, alcance y fecha de auditoría |
| DPA/DPSA y política de privacidad | Revisa obligaciones legales | Aclara roles, subprocesadores, transferencias internacionales y derechos del titular |
| Listado de subprocesadores | Muestra la cadena de tratamiento de datos | Incluye proveedor, función, país y medidas contractuales |
| SLA y esquema de soporte | Permite exigir servicio | Define tiempos, canales, severidades, escalamiento y cobertura horaria |
| Plan de continuidad / disaster recovery | Evalúa resiliencia | Indica backups, RTO, RPO y pruebas periódicas |
| Informe de pentest o carta ejecutiva | Mide seguridad real | Es reciente, de tercero independiente y con remediaciones documentadas |
| Clientes de referencia | Contrasta discurso con uso real | Hay casos comparables a la institución |
| Plan de salida | Evita lock-in | Explica exportación, continuidad de verificación, revocaciones y costos de salida |
merahki.ai + pok.tech
¿Ya sabés qué pedir? Nosotros ya tenemos las respuestas.
merahki.ai, impulsado por pok.tech, entrega el paquete completo de evidencias que esta guía exige: estándares abiertos, ISO 27001 vigente, credenciales verificables en blockchain, APIs documentadas con sandbox y plan de salida.
Ver la solución de certificación04 · Dimensiones de evaluación y evidencia exigible
Diez pilares. Cada uno con evidencia documentable.
Seguridad de la información
- Autenticación multifactor obligatoria para perfiles administrativos y emisores.
- Gestión de roles con principio de menor privilegio y revocación inmediata de accesos.
- Cifrado en tránsito con TLS 1.2 o superior y cifrado en reposo, idealmente AES-256.
- Logs auditables de acceso, cambios de permisos, emisión, revocación, exportación y eventos críticos.
- Escaneos de vulnerabilidades, pentests externos, SDLC seguro, revisión de código y gestión de dependencias.
- Plan de respuesta a incidentes, responsables claros y SLA de notificación.
Cómo validarlo
Pedir demostración en vivo de alta, cambio de rol y revocación; solicitar logs; pedir evidencia de políticas de cifrado y un resumen ejecutivo de las auditorías de seguridad.
Estándares abiertos e interoperabilidad
- Open Badges 3.0 implementado de manera nativa, no solo mencionado comercialmente.
- W3C Verifiable Credentials cuando el producto afirma emitir credenciales verificables alineadas a ese modelo.
- CLR cuando el proyecto necesita un registro longitudinal o académico más amplio.
- LTI 1.3, OneRoster, CASE u otros marcos cuando la institución necesita integraciones académicas formales.
- European Learning Model (ELM) y compatibilidad con Europass para alineación con el ecosistema europeo, movilidad académica, portabilidad semántica o emisión de credenciales compatibles con European Digital Credentials for Learning.
- Posibilidad de exportación en formatos estándar y validación con herramientas independientes.
Cómo validarlo
Para cualquier estándar: versión exacta, alcance concreto, ejemplos emitidos, documentación, validadores externos y, cuando exista, certificación o presencia en directorios oficiales.
Cumplimiento regulatorio y certificaciones
- ISO/IEC 27001 vigente para gestión de seguridad de la información.
- SOC 2 Type II cuando aplique, cubriendo Security, Availability, Confidentiality, Processing Integrity y Privacy.
- Cumplimiento con GDPR, LGPD, CCPA, LFPDPPP, FERPA u otras normas relevantes.
- DPA/DPSA claros, subprocesadores identificados y mecanismos de transferencia internacional.
Cómo validarlo
No aceptar respuestas genéricas del tipo «cumplimos con GDPR». Deben pedirse roles contractuales, políticas, flujos de derechos del titular, mapa de datos y mecanismos concretos de eliminación, exportación y respuesta a incidentes.
Blockchain y verificabilidad
- Declaración precisa de qué blockchain se usa y qué función cumple.
- Explicación exacta de qué se registra on-chain y qué se mantiene off-chain.
- Confirmación de que no se almacenan datos personales en blockchain.
- Existencia de validador público y posibilidad de comprobación independiente en explorer.
- Capacidad de auditar hash, timestamp, estado y trazabilidad de una credencial.
Funcionalidades técnicas del producto
- Emisión individual y masiva.
- Templates, branding, múltiples idiomas, unidades académicas y permisos por rol.
- Skills, competencias, outcomes, evidencias, rúbricas, pathways, stackability y relaciones entre credenciales.
- Revocación, expiración, renovación, reemisión, corrección controlada y versionado.
- Wallet o locker del receptor, sharing, descarga, verificación pública, accesibilidad y experiencia móvil.
- Analytics operativos y reportes útiles para gestión académica y empleabilidad.
Integraciones y APIs
- APIs documentadas, autenticación clara, sandbox, ejemplos, límites, versionado y backward compatibility.
- SSO con SAML 2.0, OAuth 2.0 u OpenID Connect según el caso.
- LMS, SIS, CRM, ERP, HRIS, plataformas de assessment y mensajería.
- Webhooks o eventos para emisión, revocación, claim, expiración u otros flujos.
- LTI 1.3 y otros marcos edtech cuando corresponda.
Privacidad y gestión de datos
- Mapa exacto de datos personales y académicos: obligatorios, opcionales y derivados.
- Ubicación de datos por ambiente y por cliente.
- Retención, eliminación, corrección, anonimización, exportación y derecho de acceso.
- Consentimiento explícito cuando corresponda y registro auditable de ese consentimiento.
- Capacidad de separar continuidad de verificación de eliminación de datos personales.
Infraestructura en nube
- Región o país de hosting.
- Redundancia, backups, alta disponibilidad y arquitectura multi-tenant o single-tenant.
- RTO, RPO, continuidad operativa y pruebas de disaster recovery.
- Gestión de secretos, llaves y ambientes separados.
Monitoreo y auditoría
- Retención de logs y nivel de detalle.
- Alertas de seguridad y trazabilidad de acciones administrativas.
- Integridad de registros, exportabilidad y soporte a análisis forense.
- Paneles o reportes de monitoreo para la institución.
Sostenibilidad operativa
- Roadmap claro y consistencia del producto.
- Equipo de soporte y capacidad real de implementación.
- Viabilidad de negocio y continuidad del proveedor.
- Comunidad, alianzas, referencias y estabilidad del servicio.
05 · Cómo validar las funcionalidades declaradas
Dos proveedores pueden decir “sí” a lo mismo y ofrecer productos radicalmente distintos.
Una funcionalidad solo debe considerarse disponible si fue documentada y además demostrada end-to-end.
- Exigir una demostración sobre un guion común preparado por la universidad.
- Pedir acceso temporal a sandbox o tenant de prueba.
- Solicitar documentación, capturas, video corto o walkthrough por cada feature crítica.
- Usar un caso de prueba propio de la institución con datos reales o semi-reales.
- Verificar la funcionalidad de punta a punta: configuración, emisión, experiencia del alumno, verificación externa, corrección posterior y administración.
- Registrar evidencia en acta con semáforo: existe, existe parcialmente, requiere desarrollo adicional, depende de partner/servicio profesional o no existe.
- No puntuar roadmap, marketplace o dependencia de terceros como funcionalidad nativa disponible.
Nueve pruebas con score 0–5
| Feature crítica | Prueba exigida | Resultado esperado |
|---|---|---|
| Emisión masiva | Emitir lote real con archivo de prueba | Se emiten correctamente, con trazabilidad y errores controlados |
| Verificación pública | Validar credencial sin login desde enlace externo | Verificación clara, pública y consistente |
| Revocación | Revocar y volver a validar | El estado cambia correctamente y queda auditado |
| Corrección / actualización | Editar dato permitido o reemitir según política | Se mantiene traza y coherencia del historial |
| Skills / competencias | Mapear skill, nivel, evidencia y criterio | La estructura queda visible y verificable |
| LTI / LMS | Lanzar desde el LMS y capturar contexto | El flujo funciona con el estándar declarado |
| API de emisión | Emitir desde API con credenciales de prueba | La emisión funciona con auth y respuesta documentadas |
| Analytics | Extraer dashboard o reporte útil | Los datos son utilizables para gestión |
| Exportación | Descargar datos y credenciales | El formato es estándar y utilizable |
06 · Auditoría técnica y verificabilidad en blockchain
La palabra “blockchain” se usa con frecuencia sin rigor técnico.
Advertencia crítica
Esta sección describe cómo auditar si una credencial realmente fue registrada de forma correcta y verificable, o si el proveedor solo exhibe una narrativa de marketing.
6.1 · Siete preguntas no negociables al proveedor
- ¿Qué blockchain utiliza exactamente? Ethereum, Polygon, LACNet, Bitcoin, Solana, Hyperledger, cadena privada, sidechain u otra.
- ¿Quién opera los nodos y si la red es pública, permisionada o completamente privada.
- ¿Qué dato registra on-chain: hash, identificador, prueba criptográfica, evento de contrato, metadata mínima o la credencial completa.
- ¿Qué dato se guarda off-chain y dónde se aloja.
- ¿Cómo se realiza la validación de integridad de una credencial y cómo se prueba la revocación.
- ¿Cómo evita almacenar datos personales en blockchain.
- ¿Cuál es la relación entre el viewer de la credencial, el botón de validación y la transacción que muestra el explorer.
6.2 · Procedimiento obligatorio de auditoría on-chain (10 pasos)
La universidad debe entrar en una credencial real del proveedor, validar la credencial apretando el botón de validación, luego hacer click en el hashtag, ícono o enlace de blockchain que muestra la credencial, y recién allí verificar en el explorer que la transacción fue correcta. La transacción no puede estar en estado failed, reverted o dropped.
Entrar en una credencial real del proveedor, preferentemente una credencial pública emitida por un cliente o por el propio proveedor.
Usar el botón de validación de la credencial. El validador debe confirmar el estado de la credencial y exponer, directa o indirectamente, el vínculo con la prueba criptográfica o transacción.
Hacer click en el hashtag, ícono o enlace de blockchain que muestra la credencial o el validador. Ese link debería llevar a un blockchain explorer o a una referencia equivalente verificable públicamente.
Una vez en el explorer, verificar que la transacción exista y que su estado sea exitoso. No debe figurar como failed, reverted, dropped, cancelled ni con estados equivalentes según la cadena.
Revisar el hash de transacción, timestamp, bloque, dirección o contrato involucrado y consistencia con la fecha de emisión de la credencial.
Revisar todos los tabs relevantes del explorer: Overview, Logs, Token Transfers, Internal Transactions, Events o State. La revisión no debe quedarse solo en la portada de la transacción.
Confirmar que no exista una situación engañosa en la que el explorer muestre una transacción fallida, sin token transfers, o con failed internal transactions.
Verificar que el dato grabado o el evento emitido esté razonablemente conectado con la credencial auditada. Si el proveedor solo muestra un link genérico al explorer sin forma de vincularlo, la prueba no alcanza.
Repetir la validación en más de una credencial si es posible: una activa, una revocada y una recién emitida.
Documentar capturas, URLs, estado de transacción y cualquier inconsistencia detectada.
6.3 · Matriz operativa de revisión del explorer
| Elemento | Qué debería verse | Red flag |
|---|---|---|
| Estado / Status | Success, confirmed o equivalente. Debe existir la transacción y haber sido procesada correctamente. | Failed, reverted, dropped, cancelled, pending indefinido o error sin explicación. |
| Token Transfers | Solo si el modelo realmente implica minting o transferencia. Deben ser coherentes con la credencial auditada. | No hay transfers cuando el proveedor afirma minting/NFT; transfers inconsistentes con fecha, contrato o receptor. |
| Internal Transactions | Deben ser coherentes con la lógica del contrato, o no existir si la arquitectura no las usa. | Failed internal transactions, reverts o trazas inconsistentes sin explicación técnica suficiente. |
| Logs / Events | Eventos del contrato o logs que permitan vincular la evidencia on-chain con la credencial. | No hay forma de conectar la credencial con el evento, o los logs contradicen lo que dice el visor. |
| Timestamp, bloque y contrato | Deben ser consistentes con fecha de emisión, red y contrato declarados por el proveedor. | Diferencias temporales relevantes, contrato no identificado o red distinta a la declarada. |
No todas las arquitecturas registran una credencial como token transfer. Algunas registran solo hashes, eventos o pruebas criptográficas. La verificación no consiste en «ver un NFT», sino en entender si la prueba on-chain real existe, fue exitosa y está vinculada de manera consistente con la credencial auditada.
6.4 · Seis pruebas prácticas mínimas de verificabilidad
Prueba 1
Generación de credencial test
Pedir una credencial de prueba, descargarla o verla en el viewer y extraer sus identificadores.
Prueba 2
Verificación independiente del hash o txid
Usar el explorer directamente y no depender solo del viewer del proveedor.
Prueba 3
Validación de firma criptográfica
O de estructura verificable, cuando el estándar lo permita.
Prueba 4
Revocación
Revocar la credencial de prueba y comprobar que el estado cambia en el validador y, cuando aplica, en la evidencia on-chain.
Prueba 5
Validador público
Comprobar que una tercera parte puede verificar la credencial sin login y sin exponer datos innecesarios.
Prueba 6
Portabilidad
Exportar la credencial o sus metadatos en formato estándar y comprobar que siguen siendo utilizables.
6.5 · Nueve red flags de blockchain-washing
07 · Red flags y causales de descarte
Situaciones que justifican detener una evaluación.
Salvo que el proveedor pueda remediarlas con evidencia fuerte y verificable.
merahki.ai + pok.tech
Ninguna de estas señales aplica a merahki.ai + pok.tech.
Documentación técnica completa. Trazabilidad en blockchain auditable públicamente. ISO 27001 vigente. DPA disponible. APIs con sandbox. Plan de salida incluido — todo verificable, sin promesas comerciales.
Verificalo vos mismo08 · Formulario maestro de evaluación institucional
Cómo se califica cada ítem.
Esta batería puede utilizarse como formulario de RFI/RFP o de due diligence. Se recomienda pedir respuestas con evidencia adjunta y marcar cada ítem como: Documentado · Demostrado · Certificado · Pendiente · No disponible.
Producto y alcance funcional
¿Qué tipos de credenciales emite y gestiona la plataforma?
¿Soporta emisión individual y masiva, renovación, expiración, revocación, reemisión y versionado?
¿Permite skills, competencias, resultados de aprendizaje, evidencias, rúbricas o alineaciones?
¿Soporta pathways, stackability, equivalencias o relaciones entre credenciales?
¿Permite múltiples marcas, unidades académicas, campus, idiomas y permisos por rol?
Estándares e interoperabilidad
¿Qué estándares soporta exactamente? Indicar versión y alcance: Open Badges, W3C Verifiable Credentials, CLR, European Learning Model (ELM), Europass / European Digital Credentials for Learning, LTI, OneRoster, CASE u otros.
¿El proveedor puede demostrar compatibilidad semántica y/o interoperabilidad práctica con Europass o con el European Learning Model (ELM)? Adjuntar mapeo de campos, ejemplos emitidos, validación y evidencia funcional.
¿Qué partes del estándar están implementadas nativamente y cuáles requieren desarrollo adicional?
¿Existe certificación externa, validación o presencia en directorios oficiales?
¿Cómo se maneja la verificación criptográfica, la revocación y la portabilidad entre sistemas?
¿Qué dependencia existe de viewers o wallets propietarias?
Integraciones
¿Qué APIs ofrece? Adjuntar documentación, autenticación, rate limits y versionado.
¿Cuenta con webhooks, colas, exportaciones programadas o conectores nativos?
¿Qué integraciones tiene con LMS, SIS, CRM, ERP, HRIS, assessment platforms y SSO?
¿Puede operar con SAML, OAuth 2.0, OpenID Connect o SCIM donde corresponda?
¿Cómo se sincronizan alumnos, cursos, resultados, cohortes y cambios?
Seguridad
¿Requiere MFA para perfiles administradores y emisores?
¿Cómo se gestiona el acceso privilegiado, la segregación por tenant y la revocación inmediata de usuarios?
¿Qué cifrado utiliza en tránsito y en reposo?
¿Conserva logs auditables? ¿Por cuánto tiempo? ¿Cómo garantiza integridad y monitoreo?
¿Con qué frecuencia realiza escaneos de vulnerabilidades y pentests externos?
¿Qué prácticas de SDLC seguro, revisión de código, gestión de dependencias y CI/CD aplica?
¿Cuál es su proceso de gestión de incidentes y notificación a clientes?
Privacidad y datos
¿Qué datos personales y académicos almacena exactamente? Separar obligatorios, opcionales y derivados.
¿Dónde se alojan los datos por ambiente y por cliente? Indicar país o región.
¿Quiénes son sus subprocesadores y qué rol cumplen?
¿Cómo se gestionan retención, borrado, anonimización, corrección y exportación?
¿Qué mecanismos usa para transferencias internacionales de datos?
¿Cómo aborda GDPR, FERPA y legislación local aplicable?
Operación y servicio
¿Cuál es el SLA estándar y qué incluye el soporte?
¿Qué idioma y huso horario cubre el soporte?
¿Cómo se implementa, cuánto dura y qué depende del cliente?
¿Qué formación ofrece a administradores, emisores y soporte interno?
¿Qué referencias comparables puede compartir?
Contrato, costos y salida
Describir el modelo de pricing y todos los componentes facturables.
Indicar límites de uso, storage, emisores, templates, integraciones, wallets, analytics y ambientes.
¿Qué ocurre al terminar el contrato con verificación, hosting y exportación de datos?
¿Existe costo por migración, salida o continuidad de verificación?
¿La universidad conserva propiedad y control sobre sus datos y metadatos?
09 · Guion de demo, piloto y pruebas
Doce pasos del piloto.
Configurar una credencial con branding institucional, metadatos, criterios y evidencias.
Emitir una credencial individual y un lote masivo.
Asignar skills o competencias y mostrarlas en la credencial o en su detalle.
Realizar claim por parte del receptor y compartirla externamente.
Verificar la credencial desde fuera de la plataforma.
Auditar el botón de validación y el enlace a blockchain/explorer cuando exista.
Revocar una credencial y verificar el cambio de estado.
Corregir un dato permitido y revisar la trazabilidad.
Consumir una API o webhook de ejemplo.
Mostrar permisos por rol y segregación por unidades académicas.
Exportar datos, metadatos y evidencias relevantes.
Probar accesibilidad, experiencia móvil y multilenguaje cuando sea requisito.
10 · Metodología de scoring
Escala 0 – 5.
El scoring debe aplicarse solamente a funcionalidades o controles documentados y demostrados. El roadmap no se puntúa como disponibilidad actual.
| Score | Significado | Interpretación | Aceptación |
|---|---|---|---|
| 0 | No cumple | No implementado o explícitamente no soportado | 🔴 Rechazo |
| 1 | Muy débil / roadmap | Prometido o parcialmente conceptual | 🟠 No contar como feature disponible |
| 2 | Parcial | Existe con limitaciones significativas | 🟠 Requiere investigación adicional |
| 3 | Adecuado | Implementado correctamente y con evidencia suficiente | 🟣 Cumple mínimo |
| 4 | Sólido | Implementado robustamente y con auditoría o madurez comprobable | 🟢 Muy buen nivel |
| 5 | Excelente | Implementación excepcional, transparente y líder | 🟢 Fortaleza clara |
Ponderación sugerida por dimensión
| Dimensión | Peso | Umbral mín. |
|---|---|---|
| Estándares e interoperabilidad | 20% | ≥ 3/5 |
| Funcionalidad del producto | 20% | ≥ 3/5 |
| Seguridad | 15% | ≥ 4/5 |
| Privacidad y datos | 15% | ≥ 4/5 |
| Blockchain y verificabilidad | 10% | ≥ 3/5 |
| Integraciones y APIs | 10% | ≥ 3/5 |
| Operación y soporte | 5% | ≥ 3/5 |
| Economía total | 3% | ≥ 3/5 |
| Plan de salida / no lock-in | 2% | ≥ 3/5 |
Fórmula sugerida
Score final = Σ (score dimensión × peso)Interpretación
- ≥ 4.0 · recomendado
- 3.0 – 3.9 · aceptable con reservas
- < 3.0 · no recomendado
Regla de gobierno
Aunque el promedio general sea alto, un proveedor no debería aprobar si no alcanza los mínimos en seguridad, privacidad o verificabilidad.
11 · Evaluación económica, contractual y plan de salida
Costo total, TCO real y salida.
- Revisar precio por emisor, por alumno, por credencial, por módulo, por integración o por storage.
- Identificar costos ocultos: implementación, branding, APIs, analytics, soporte premium, migración, wallet, templates, ambientes y training.
- Exigir SLA, DPA, límites de responsabilidad, subprocesadores, continuidad, backups y tratamiento de incidentes.
- Confirmar qué ocurre al finalizar el contrato: exportación de datos, revocaciones, continuidad de verificación, costos y formato de entrega.
- Verificar que la universidad conserve propiedad y control sobre datos, metadatos y evidencias que le pertenecen.
12 · Recomendación institucional final
No elegir por estética ni por discurso comercial.
Una universidad debería elegir una plataforma por capacidad demostrada para emitir, verificar, integrar, preservar, proteger y gobernar credenciales y datos con estándares abiertos, evidencia verificable y un costo total entendible.
La mejor práctica es combinar formulario documental, demo guiada, due diligence, piloto real, scoring ponderado y revisión contractual. Cuando un proveedor realmente tiene la capacidad que declara, este proceso lo fortalece. Cuando no la tiene, este proceso lo expone.
Toda evaluación madura debería incluir la auditoría práctica de una credencial real y de su evidencia de validación. Si la credencial no puede validarse de manera confiable e independiente, la promesa de verificabilidad queda seriamente debilitada.
Anexo A · Checklist rápida de descarte
Ocho preguntas de semáforo.
Si la respuesta es no a cualquiera de estas preguntas y el proveedor no aporta evidencia de remediación inmediata, la plataforma debería pasar a estado de descarte o pausa.
Anexo B · Plantilla resumida para RFI / RFP
Diez bloques de una RFI / RFP.
Anexo C · Referencias de estándares y marcos utilizados
Fuentes oficiales consultadas.
1EdTech Consortium — Open Badges. Página oficial del estándar y recursos de implementación.
www.1edtech.org/standards/open-badges
1EdTech — Open Badges Certification Process. Proceso oficial de certificación de conformidad.
www.1edtech.org/certification/open-badges
1EdTech — TrustEd Apps Program. Directorio oficial de productos con certificación/interoperabilidad verificada.
www.1edtech.org/program/trustedapps
W3C — Verifiable Credentials Data Model v2.0. Recomendación oficial publicada el 15 de mayo de 2025.
www.w3.org/TR/vc-data-model-2.0
Europass — European Digital Credentials. Infraestructura oficial para crear, emitir, almacenar, compartir y verificar credenciales digitales europeas.
europass.europa.eu/en/european-digital-credentials
Europass — EDC for Learning. Definición oficial de credenciales digitales europeas para aprendizaje.
europass.europa.eu/en/european-digital-credentials-learning
Europass — Information for Developers. Documentación técnica del ecosistema Europass.
europass.europa.eu/en/information-developers
Europass — European Learning Model (ELM) Browser. Modelo oficial de datos europeo para aprendizaje y credenciales.
europa.eu/europass/elm-browser/index.html
Europass — Latest developments to the European Learning Model.
europass.europa.eu/en/news/latest-developments-european-learning-model
OWASP — Application Security Verification Standard (ASVS).
owasp.org/www-project-application-security-verification-standard
OWASP — Authentication Cheat Sheet.
cheatsheetseries.owasp.org
NIST — SP 800-218 Secure Software Development Framework (SSDF).
csrc.nist.gov/publications/detail/sp/800-218/final
EUR-Lex — Regulation (EU) 2016/679 (GDPR).
eur-lex.europa.eu/eli/reg/2016/679/oj
Etherscan Docs.
docs.etherscan.io
Referencias consolidadas a partir de fuentes oficiales de 1EdTech, W3C y OWASP revisadas en marzo de 2026. Se recomienda verificar siempre la vigencia de certificaciones, versiones de estándares y evidencias técnicas directamente en las fuentes oficiales al momento de la compra.
No compre declaraciones.
Compre evidencia.
merahki.ai · Guía Integral · v1.0 · Abril 2026
¿Tu institución está evaluando plataformas de credenciales digitales?
El equipo de merahki.ai puede ayudarte a aplicar este marco de evaluación y encontrar la solución adecuada para tus casos de uso.
30-min personalized walkthrough
A tailored demo of the platform matched to your specific use case.
Talk to an expert, not a sales rep
You'll speak with someone who deeply understands education-led growth.
Implementation roadmap included
Walk away with a clear plan for launching your first program.
Used by teams in 8+ industries
From healthcare to SaaS — we've seen and solved your challenges.
