Saltar al contenido principal
Integraciones LMS 12 min de lectura 16 mayo 2026

SCORM o LTI: cuál usar según tu LMS empresarial (guía técnica 2026)

Dos estándares de interoperabilidad gobiernan la conexión entre LMS y contenido externo. Esta guía explica cuándo elegir SCORM 1.2, cuándo LTI 1.3 con Deep Linking y cómo combinarlos en arquitecturas empresariales. Pensada para responsables técnicos de plataforma, LMS Managers y arquitectos edTech.

Toda organización que opera un LMS empresarial llega tarde o temprano al mismo punto. Hay contenido propio en la plataforma, contenido externo que se quiere integrar, ejercicios interactivos que viven en otro servicio y un departamento de RRHH que pide informes consolidados. La interoperabilidad entre LMS y contenido externo se resuelve históricamente con dos estándares: SCORM y LTI.

La pregunta habitual ante un proyecto de integración no es "cuál es mejor", sino "cuál encaja con el flujo que necesito ejecutar". Los dos estándares resuelven problemas distintos, conviven en la mayoría de despliegues empresariales y se eligen en función del tipo de contenido, la versión del LMS y los requisitos de seguridad y reporting. Esta guía técnica detalla las diferencias entre SCORM 1.2, LTI 1.1 y LTI 1.3, expone los criterios de elección y describe cómo implementar ambos en entornos reales.

1. SCORM 1.2 en 60 segundos

SCORM (Sharable Content Object Reference Model) es un conjunto de especificaciones técnicas para empaquetar contenido formativo de forma que pueda lanzarse desde cualquier LMS compatible. Fue desarrollado por ADL Initiative, una iniciativa del Department of Defense de Estados Unidos lanzada a finales de los años noventa para unificar la formación distribuida del ejército estadounidense entre proveedores. La versión 1.2 se publicó en 2001 y, pese a sus limitaciones técnicas, sigue siendo la implementación dominante en el sector corporativo veinticinco años después.

Técnicamente, un paquete SCORM 1.2 es un archivo ZIP autocontenido con tres elementos clave:

  • imsmanifest.xml: el descriptor XML del paquete que declara las organizaciones, los recursos, las dependencias y los metadatos del contenido. Es el archivo que el LMS parsea al importar.
  • Contenido HTML/JS/CSS: el material que se mostrará al alumno, normalmente compuesto por varios SCO (Sharable Content Objects).
  • Wrapper de JavaScript: el código que dialoga con el LMS mediante la API de SCORM (modelo de datos CMI), exponiendo funciones como LMSInitialize, LMSSetValue, LMSGetValue, LMSCommit y LMSFinish.

El flujo es sencillo: el LMS importa el ZIP, lo despliega en su sistema de archivos y, cuando el alumno abre la actividad, abre un iframe que carga el contenido. El wrapper localiza la API expuesta por el LMS subiendo por la jerarquía de ventanas (window.parent.API) y empieza a enviar el estado: progreso, tiempo de sesión, calificación, completado, suspended data. SCORM 1.2 define un modelo de datos relativamente simple basado en pares clave-valor del estándar CMI.

Por qué sigue vivo en 2026: SCORM 1.2 funciona offline una vez descargado, no requiere conectividad permanente con un servicio externo, sobrevive a la desaparición del proveedor original y es portable entre LMS sin renegociar contratos. Sigue siendo el formato de referencia para contenido formativo estático, regulatorio o que debe distribuirse a múltiples plataformas.

Existen versiones posteriores (SCORM 2004 con sus cuatro ediciones, que introducen reglas de secuenciación y navegación) pero la adopción se quedó por debajo de SCORM 1.2 debido a su mayor complejidad de implementación. En la práctica empresarial actual, SCORM 1.2 es el común denominador entre todos los LMS del mercado.

2. LTI 1.1 vs LTI 1.3 en 60 segundos

LTI (Learning Tools Interoperability) es un estándar mantenido por 1EdTech (antes IMS Global) que define cómo un LMS (denominado Platform o Tool Consumer) lanza contenido vivo alojado en un sistema externo (denominado Tool o Tool Provider) y cómo este último devuelve información al LMS. A diferencia de SCORM, el contenido no se empaqueta ni se hospeda en el LMS: vive en el servidor del proveedor y se accede a él bajo demanda con identidad federada.

LTI 1.1: la base histórica

LTI 1.1 se publicó en 2012 y se convirtió en el estándar de facto durante la siguiente década. El mecanismo de seguridad es OAuth 1.0a con un consumer key y un consumer secret compartidos entre LMS y proveedor. El LMS envía al lanzar la actividad un formulario POST firmado con HMAC-SHA1 que contiene claims sobre el usuario (rol, identificador, contexto del curso) y una URL de retorno para la devolución de calificaciones. Esta última opera mediante grade passback POX XML: el proveedor llama al outcomes service del LMS enviando un sourcedId y una calificación normalizada entre 0 y 1.

Las extensiones posteriores añadieron servicios como Memberships (lista de matriculados, también conocida como student roster), pero el modelo de seguridad basado en secretos compartidos y firma de formularios se quedó atrás respecto a los estándares modernos de autenticación.

LTI 1.3 / LTI Advantage: el salto a OIDC y JWT

LTI 1.3 se publicó en 2019 y reescribe los fundamentos de seguridad sobre estándares modernos. El lanzamiento utiliza OpenID Connect (OIDC) en lugar de OAuth 1.0a, las firmas se realizan con JWT (JSON Web Token) firmados con RSA, y la confianza entre LMS y proveedor se gestiona mediante claves públicas publicadas en JWKS endpoints. Esto elimina la necesidad de compartir secretos por canales fuera de banda.

Junto a LTI 1.3 se publicó LTI Advantage, un paquete de servicios opcionales pero estratégicos:

  • Deep Linking 2.0: permite a un profesor o admin del LMS abrir el content picker del proveedor desde dentro del LMS y seleccionar qué ejercicio, lección o test concreto se inserta en el curso. Sustituye al copiado manual de URLs.
  • Assignment and Grade Services (AGS): sustituye al grade passback POX XML por una API REST con JSON, soportando creación, lectura y actualización de calificaciones, línea de calificación por columna del gradebook y resultados parciales.
  • Names and Roles Provisioning Services (NRPS): el proveedor consulta dinámicamente la lista de matriculados del curso en el LMS, incluyendo roles, nombres y correos electrónicos, sin necesidad de mantener un duplicado interno.

LTI 1.3 es backward compatible con LTI 1.1 en buena parte de los casos: una misma URL del proveedor puede atender ambas versiones, distinguir el tipo de petición y procesar adecuadamente cada flujo. Esto permite migrar progresivamente sin romper las integraciones existentes.

3. Diferencias clave: tabla comparativa

Esta comparativa sintetiza los criterios técnicos relevantes a la hora de elegir entre los tres estándares en un proyecto empresarial real.

Criterio SCORM 1.2 LTI 1.1 LTI 1.3
Año de publicación 2001 2012 2019
Mecanismo Paquete ZIP empaquetado Lanzamiento en vivo Lanzamiento en vivo
Hosting del contenido En el LMS En el proveedor En el proveedor
Comunicación bidireccional API JS sobre window.parent Outcomes POX XML AGS, NRPS sobre REST/JSON
Seguridad Sin firma criptográfica OAuth 1.0a (HMAC-SHA1) OIDC + JWT RSA + JWKS
Deep Linking No aplica Limitado (Content Item) Sí, nativo (Deep Linking 2.0)
Grade passback automático Vía API CMI hacia el LMS Outcomes Service básico AGS con line items y partial grades
Provisioning de usuarios y roles No Memberships (extensión) NRPS nativo
Compatibilidad con LMS legacy Universal Amplia LMS modernos
Tipo de contenido ideal Estático, regulatorio Apps externas básicas Apps interactivas y dinámicas

La lectura simplificada de la tabla: SCORM lleva el contenido dentro del LMS, LTI deja el contenido fuera del LMS y construye un puente seguro entre ambos. Cuanto más interactiva sea la experiencia de aprendizaje, más sentido tiene LTI 1.3. Cuanto más portable, autocontenida o regulatoria sea, más sentido tiene SCORM 1.2.

4. Cuándo elegir SCORM 1.2

SCORM 1.2 sigue siendo la elección correcta en cuatro escenarios concretos que se repiten en proyectos empresariales.

LMS heredado sin soporte LTI 1.3

Muchas organizaciones operan LMS comprados hace una década, instalaciones on-premise sin parches recientes o plataformas verticales del sector industrial que nunca recibieron soporte para LTI Advantage. En estos entornos, SCORM 1.2 es prácticamente la única vía de integración disponible. El paquete se sube al LMS, se publica como recurso y se acabó.

Contenido offline-capable o de baja conectividad

Despliegues en planta industrial, formación a operarios en entornos sin red estable, formación de campo o auditorías de cumplimiento que deben funcionar sin depender de la disponibilidad de un servicio externo encajan con SCORM. Una vez instalado, el paquete no necesita salir hacia internet hasta el momento de sincronizar resultados.

Contenido estático o de cumplimiento regulatorio

Cursos de prevención de riesgos laborales, protección de datos, ética corporativa o normativa sectorial que cambian poco entre actualizaciones anuales son perfectos candidatos para SCORM. La inmutabilidad del paquete y la facilidad de archivado son atributos deseables para auditorías futuras.

Distribución del mismo contenido a múltiples LMS

Cuando una academia, una editorial o un proveedor de contenido tiene que distribuir el mismo curso a decenas de clientes con LMS distintos (Moodle, Cornerstone, SuccessFactors, Docebo, TalentLMS), el paquete SCORM es el formato común que todos los compradores aceptan sin negociaciones técnicas adicionales.

En la práctica empresarial, SCORM 1.2 es también la opción defensiva: si una organización no puede arriesgarse a que la integración con un proveedor externo se rompa o desaparezca, empaquetar el contenido en SCORM garantiza que el conocimiento queda dentro del LMS independientemente del futuro del proveedor.

5. Cuándo elegir LTI 1.3 con Deep Linking

LTI 1.3 con Deep Linking es la elección correcta cuando el contenido es vivo, interactivo o multi-tenant. Cuatro escenarios concretos en los que SCORM se queda corto:

Aplicaciones de aprendizaje en tiempo real

Plataformas que evolucionan constantemente, donde el contenido se actualiza varias veces por semana o donde la experiencia del alumno depende de cómputo backend (corrección por inteligencia artificial, generación dinámica de ejercicios, contenido personalizado por nivel) no caben en un paquete ZIP. LTI 1.3 permite que el LMS sea solo la puerta de entrada y que el proveedor controle al cien por cien la experiencia.

Ejercicios interactivos con grading en vivo

Tests adaptativos, evaluaciones por IA generativa, ejercicios de tipo puzle, retos de programación con ejecución en sandbox: todos requieren backend siempre disponible y devolución inmediata de calificaciones al gradebook del LMS. AGS resuelve el flujo de calificación con granularidad por línea de calificación.

IDE o entornos de programación en navegador

Editores de código, terminales web, entornos virtualizados de bases de datos o de sistemas operativos no pueden empaquetarse en SCORM. Estos contenidos viven necesariamente en un servicio externo con contenedores efímeros, y LTI 1.3 con SSO OIDC es la única forma razonable de lanzarlos desde el LMS.

Despliegues multi-tenant donde el LMS es un shell

Universidades y consultoras que dan acceso a estudiantes a través del LMS oficial pero quieren que toda la experiencia formativa real ocurra en una plataforma especializada encajan en este patrón. El LMS gestiona matrícula, calendario y calificación final; la plataforma externa, todo lo demás. Deep Linking facilita que cada profesor inserte la actividad concreta que quiera sin necesidad de un administrador técnico.

LTI 1.3 también es preferible cuando el proveedor necesita visibilidad sobre la lista de alumnos sin recibir un volcado manual desde el LMS. NRPS permite consultar dinámicamente el roster del curso, lo que es fundamental para servicios que cobran por usuario activo o que necesitan precrear los entornos antes de que el alumno entre por primera vez.

6. Implementación práctica con CertiDevs

La plataforma CertiDevs implementa de forma nativa ambos estándares. Los clientes que integran su LMS corporativo (Moodle, Canvas, Blackboard, Brightspace, TalentLMS, instalaciones internas) eligen la vía adecuada según el tipo de contenido y la versión del LMS.

Vía LTI 1.3 con Deep Linking

Configuración estándar entre LMS empresarial y CertiDevs como Tool Provider:

  1. Registro del Tool en el LMS: el administrador da de alta el proveedor introduciendo el Client ID, las URLs de Authentication Request, JWKS y Deep Linking publicadas por CertiDevs, y las URLs de redirect.
  2. Intercambio de claves públicas: ambos lados publican su JWKS endpoint y consumen el del contrario. No se comparten secretos por correo electrónico ni por hojas de cálculo.
  3. Habilitación de servicios AGS y NRPS: el LMS concede los scopes correspondientes para que CertiDevs pueda crear line items, escribir calificaciones y consultar el roster.
  4. Inserción de actividades por Deep Linking: el profesor abre un editor de actividad en el LMS, selecciona CertiDevs como herramienta externa, se autentica de forma transparente vía OIDC y navega por el content picker del catálogo. Al seleccionar una lección, un test o un ejercicio concreto, el LMS recibe el ítem y lo guarda como recurso del curso.
  5. Lanzamiento por el alumno: al abrir la actividad, el alumno se autentica vía OIDC, se crea su cuenta automáticamente en CertiDevs si no existía, se mapea su email al dominio corporativo y se le concede el rol que el LMS indique en los claims.
  6. Devolución de calificaciones: al completar el ejercicio, CertiDevs envía la calificación al gradebook del LMS por AGS, en la columna correspondiente y con metadatos adicionales (tiempo invertido, intentos, estado).

Compatibilidad LTI 1.1 ↔ 1.3: CertiDevs mantiene también la implementación LTI 1.1 con grade passback POX XML y student roster para LMS que aún no han migrado a 1.3. La misma URL de proveedor responde a ambos protocolos.

Vía SCORM 1.2 export

Para LMS sin LTI o para flujos donde la portabilidad es clave, CertiDevs exporta exámenes y roadmaps como paquetes SCORM 1.2:

  1. Generación del paquete: desde el panel de administración se selecciona el examen o roadmap, se elige modo SCORM y se obtiene un ZIP con el imsmanifest.xml, el wrapper JS, la API stub y los recursos necesarios.
  2. Subida al LMS: el administrador del LMS importa el paquete como un recurso SCORM más, lo asocia a un curso y lo asigna a los alumnos correspondientes.
  3. Persistencia de calificaciones: el wrapper envía el progreso y la calificación al LMS por la API CMI estándar. Para LMS antiguos donde la sincronización requiere acuses, el ScormSyncAckService de CertiDevs gestiona el envío con reintentos y la persistencia del estado a nivel de servidor.

Patrón híbrido: LTI 1.3 + SCORM 1.2

En despliegues corporativos grandes es habitual combinar ambos estándares. Un esquema que se repite:

  • LTI 1.3 para ejercicios vivos, lecciones interactivas, IDE en navegador y evaluaciones por IA. Calificaciones automáticas al gradebook por AGS.
  • SCORM 1.2 para el módulo de cumplimiento (RGPD, prevención, ética) y para el certificado final del itinerario, que queda archivado dentro del LMS.
  • SSO/OIDC corporativo compartido entre ambas vías, con auto-creación de usuarios y mapeo de email domains, de modo que el alumno tiene siempre una sola identidad.

7. Errores frecuentes en integraciones LMS

Los siguientes errores se repiten en proyectos de integración SCORM y LTI. Conocerlos por adelantado ahorra semanas de depuración.

Asumir que SCORM tracking funciona con AJAX moderno

Algunos wrappers SCORM acoplan el ciclo de vida del SCO al evento window.unload o a llamadas síncronas en beforeunload. Si la SPA hace navegación cliente sin recargar la página, esos eventos no se disparan y los datos no se persisten. Verificar siempre que el wrapper invoque LMSCommit de forma explícita en cada interacción relevante, no al cerrar la ventana.

No firmar correctamente el JWT en LTI 1.3

El error más común en LTI 1.3 es firmar el JWT con la clave incorrecta, no incluir el claim nonce, dejar el iss apuntando al endpoint equivocado o reutilizar el mismo JWT para validar varios mensajes. La validación debe seguir estrictamente el flujo OIDC con verificación de firma contra el JWKS del LMS, validación de aud, exp y iat, y rechazar tokens reutilizados.

Olvidar configurar AGS si quieres notas automáticas

Tener LTI 1.3 funcionando para el lanzamiento de la actividad no implica que las calificaciones lleguen automáticamente al gradebook. El administrador del LMS debe habilitar explícitamente los scopes de Assignment and Grade Services (lectura de line items, escritura de scores, lectura de results) en la configuración del Tool. Sin esos scopes, el proveedor no puede llamar a los endpoints de AGS y el profesor tiene que importar notas manualmente.

Confundir Deep Linking con SSO

Son dos cosas distintas. Deep Linking es el flujo por el cual un profesor selecciona qué contenido se inserta en el curso. SSO/OIDC es el flujo por el cual un alumno se autentica al lanzar ese contenido. Tener uno no implica tener el otro. Algunos LMS soportan SSO LTI 1.3 pero requieren copiar URL manual de cada actividad porque no han implementado Deep Linking. Verificarlo antes de prometer al cliente un flujo end-to-end.

Hardcodear URLs de retorno y endpoints

El payload del lanzamiento LTI contiene URLs dinámicas para devolución de calificaciones, NRPS y Deep Linking response. Hardcodearlas en el código del proveedor produce integraciones que solo funcionan con un LMS específico. La implementación correcta lee lineitems, context_memberships_url y deep_linking_settings.deep_link_return_url de los claims y los respeta en cada deployment.

8. FAQ técnica

¿LTI 1.3 reemplaza por completo a SCORM?

No. LTI 1.3 y SCORM resuelven problemas distintos. LTI conecta el LMS con contenido vivo alojado en un sistema externo en tiempo real, con autenticación federada y devolución automática de calificaciones. SCORM empaqueta contenido autocontenido que el LMS hospeda y reproduce sin depender de un servicio externo. Convivirán durante años, especialmente en entornos con LMS heredados.

¿Necesito implementar SCORM y LTI a la vez en mi organización?

Depende del catálogo de contenido y de la versión del LMS. Si la organización tiene un LMS moderno (Moodle 4.x, Canvas, Blackboard Ultra, Brightspace) y todo el contenido se imparte en vivo, LTI 1.3 es suficiente. Si conviven LMS antiguos sin soporte LTI o se requiere portabilidad del contenido entre plataformas, mantener una vía SCORM 1.2 sigue siendo la opción defensiva.

¿Qué LMS soportan SCORM 1.2 y LTI 1.3 en 2026?

Casi todos los LMS comerciales y de código abierto soportan SCORM 1.2: Moodle, Canvas, Blackboard, Brightspace, Cornerstone, SuccessFactors, TalentLMS, Docebo y Open edX, entre otros. LTI 1.3 con Deep Linking y AGS está soportado de forma nativa en Moodle 3.10+, Canvas, Blackboard Ultra, Brightspace, Open edX (Sumac y posteriores) y TalentLMS. Versiones antiguas de algunos LMS solo soportan LTI 1.1.

¿Cómo se migra de SCORM a LTI sin perder el histórico de calificaciones?

La migración no es automática porque ambos estándares modelan los datos de forma distinta. El procedimiento habitual es mantener el contenido SCORM legacy archivado y de solo lectura, configurar la integración LTI 1.3 con Assignment Grade Services en paralelo, mapear los identificadores de usuario mediante claims OIDC o NRPS, y dejar que las nuevas asignaciones generen calificaciones por la vía LTI mientras se conservan las históricas en el LMS.

¿Hay alternativas a SCORM y LTI?

Sí. xAPI (también conocido como Tin Can) cubre el tracking de experiencias de aprendizaje fuera del LMS, pero requiere un Learning Record Store y no resuelve el lanzamiento de contenido como SCORM. cmi5 combina paquetes empaquetables con xAPI para tracking moderno. QTI estandariza la importación y exportación de bancos de preguntas. En la práctica, LTI 1.3 sigue siendo el estándar dominante para integraciones empresariales en tiempo real.

¿Cuánto cuesta integrar SCORM o LTI 1.3 con un LMS?

Como proveedor de contenido, exportar un paquete SCORM 1.2 desde una herramienta que ya lo soporta tiene coste cero por paquete. Implementar SCORM desde cero requiere desarrollo del manifest, el wrapper de JavaScript y la API stub. LTI 1.3 implica desarrollar el proveedor (Tool Provider) con OIDC, validación de JWT, AGS y NRPS, lo que implica varias semanas de ingeniería. En CertiDevs ambos estándares están implementados de forma nativa, por lo que el cliente solo configura claves y URLs.

9. Próximos pasos

Si estás evaluando una integración LMS y necesitas decidir entre SCORM, LTI 1.1 o LTI 1.3, los siguientes recursos profundizan en aspectos concretos:

Integra CertiDevs con tu LMS empresarial

LTI 1.3 con Deep Linking, AGS y NRPS. SCORM 1.2 export para LMS heredados. SSO/OIDC corporativo con auto-creación de usuarios y mapeo de dominios. Sin permanencia, sin coste de setup, demo y soporte incluidos.

Alan Sastre

Alan Sastre

Founder, CEO y Formador en CertiDevs

Arquitecto de software especializado en plataformas SaaS de formación, estándares de interoperabilidad LMS y tecnologías de IA generativa. Más de 10 años diseñando integraciones LTI y SCORM con LMS corporativos y universitarios.

LinkedIn

¿Necesitas integrar contenido externo en tu LMS?

Te asesoramos sobre la vía adecuada (SCORM, LTI 1.1 o LTI 1.3), realizamos la integración y damos soporte continuo. Sin permanencia, sin coste de setup.