SCORM y xAPI explicados

Por Brian Tr · Actualizado el 7 de octubre de 2026

SCORM y xAPI son estándares técnicos que permiten que el contenido de aprendizaje y el software de aprendizaje intercambien datos. SCORM empaqueta un curso para que pueda ejecutarse dentro de cualquier sistema de gestión del aprendizaje (LMS) compatible y reportar un estado de finalización y una calificación. xAPI es una especificación más reciente que registra la actividad de aprendizaje como declaraciones breves y las envía a una base de datos llamada Learning Record Store (LRS), con o sin un LMS de por medio.

Si vende cursos, compra software de capacitación o desarrolla un producto de EdTech, se encontrará con ambos acrónimos en la primera semana. Aparecen en llamadas de ventas, RFP y menús de exportación de las herramientas de autoría. Este artículo explica qué es cada uno, de dónde vienen, qué puede y qué no puede registrar cada uno, cómo un tercer estándar llamado cmi5 los conecta y cómo decidir cuál exigir. También cubre LTI, que se parece pero resuelve un problema distinto.

Por qué existen los estándares de aprendizaje

Imagine que compra un curso de seguridad a un proveedor de contenido y su LMS viene de otra empresa. Sin un estándar compartido, el curso no tiene forma de decirle al LMS "este estudiante terminó y obtuvo 85%". Necesitaría trabajo de integración a medida para cada curso y cada plataforma.

Los estándares resuelven esto acordando de antemano tres cosas:

• Cómo se empaqueta el contenido, para que cualquier sistema pueda desempaquetarlo y lanzarlo.
• Cómo se comunican el contenido y la plataforma, para que los resultados regresen.
• Cómo se ven los resultados, para que un estado "completado" signifique lo mismo en todas partes.

Los estándares no hacen bueno a un curso. Hacen que piezas de distintos proveedores funcionen juntas, y eso sostiene el mercado de LMS y el licenciamiento de contenido de capacitación.

¿Qué es SCORM?

SCORM significa Sharable Content Object Reference Model. Scorm.com, el sitio de referencia de larga trayectoria operado por Rustici Software, explica que ADL (Advanced Distributed Learning) no escribió SCORM desde cero. En cambio, ADL observó que la industria ya tenía muchos estándares que resolvían cada uno una parte del problema y los combinó en un único modelo de referencia.

SCORM cubre dos áreas:

1. Empaquetado de contenido. Un curso se agrupa en un solo archivo zip con un manifiesto que describe sus páginas, módulos y estructura. Si sube el zip a un LMS compatible, este sabe cómo lanzarlo.
2. Comunicación en tiempo de ejecución. Mientras el estudiante realiza el curso, el contenido llama a un conjunto de funciones que el LMS expone en el navegador y devuelve datos como la finalización, aprobado o reprobado, una calificación, el tiempo dedicado y un marcador para que el estudiante pueda retomar el curso.

Versiones de SCORM

Verá sobre todo dos nombres, y el segundo tiene varias ediciones. Según el historial de versiones de Scorm.com:

La característica principal de la línea 2004 es la secuenciación y la navegación: reglas que indican qué parte de un curso puede abrir el estudiante a continuación, por ejemplo "desbloquear el módulo 3 solo después de aprobar el cuestionario del módulo 2". SCORM 1.2 no tiene un equivalente, así que un proveedor que dice "SCORM" sin indicar la versión no le ha dicho mucho. Pregunte cuál.

Cómo funciona SCORM en la práctica

El modelo de ejecución de SCORM es simple y algo anticuado. El LMS coloca un objeto JavaScript en el navegador y el curso tiene que encontrarlo. Según la documentación de ejecución, ese objeto se llama API en SCORM 1.2 y API_1484_11 en SCORM 2004, y debe estar en una ventana que sea padre del curso o de la ventana que lo abrió. El curso debe llamar a Initialize antes que a cualquier otra función y a Terminate cuando termina. La misma fuente señala que todo el contenido SCORM debe poder entregarse por web y que la comunicación ocurre dentro de una sesión de navegador, de modo que solo el curso puede iniciar la conversación. El LMS se limita a responder.

Ese diseño explica tanto las fortalezas de SCORM como sus límites.

Qué puede registrar SCORM

• Si un estudiante completó el curso y si aprobó o reprobó
• Una calificación
• El tiempo dedicado en una sesión
• Un marcador para retomar

Qué no puede registrar SCORM (fácilmente)

• El aprendizaje fuera del LMS. Si no ocurre en una ventana de navegador lanzada desde el LMS, SCORM no lo ve.
• El aprendizaje en aplicaciones móviles, simuladores o sin conexión. Todo lo que no cabe en un marco de navegador junto al LMS no tiene un lugar natural donde reportar.
• Muchos estudiantes y muchas actividades como una sola historia. SCORM guarda un registro por estudiante y por curso. No está pensado para registrar "esta persona vio un video, luego se unió a un seminario web y después asesoró a un colega".
• El comportamiento detallado. Obtiene un estado y una calificación, no un rastro completo de lo que hizo el estudiante.

Nada de esto hace malo a SCORM. Para lo que la mayoría de las organizaciones realmente necesita demostrar, que una persona terminó un curso obligatorio, funciona y casi todos los LMS y herramientas de autoría lo admiten. Su antigüedad también es una ventaja: casi todos los proveedores de contenido y herramientas de autoría saben producirlo.

¿Qué es xAPI?

xAPI, abreviatura de Experience API, fue diseñado para registrar el aprendizaje dondequiera que ocurra. La especificación de ADL en GitHub dice que su objetivo es facilitar la documentación y comunicación de experiencias de aprendizaje que están "dispersas en una amplia variedad de fuentes". Antes se conocía como Tin Can API.

Según la descripción general del propio proyecto xAPI, nació del Project Tin Can, que Rustici Software inició después de que ADL pidiera investigar especificaciones de eLearning de próxima generación, y finalmente la comunidad redactó el estándar.

Cómo funciona xAPI: declaraciones y el LRS

Todo en xAPI es una declaración (statement) con tres partes centrales:

• Actor: quién lo hizo (el estudiante)
• Verbo: qué hizo (completó, intentó, respondió, vio, comentó)
• Objeto: sobre qué lo hizo (un curso, un video, un cuestionario, un escenario)

El ejemplo de la propia especificación es "Anna probó una receta de pastel", con Anna como actor, "probó" como verbo y la receta como objeto. Una versión empresarial podría ser "Mai completó el taller de precios" o "Tuan respondió la pregunta 4 del cuestionario de cumplimiento".

Las declaraciones se envían a un Learning Record Store (LRS). La especificación lo define como un servidor responsable de recibir, almacenar y dar acceso a los registros de aprendizaje. Piense en él como una base de datos creada para guardar estas declaraciones, a la que cualquier herramienta compatible con xAPI puede enviar datos o de la que puede leerlos. Un LRS puede estar dentro de un LMS o funcionar por sí solo, y varias herramientas pueden escribir en el mismo.

Qué puede registrar xAPI

La especificación indica que lo que registra es muy diverso, con ejemplos como leer un libro, tomar un curso en línea, hacer una visita de campo, investigar de forma autónoma o recibir un certificado. La descripción general del proyecto enumera el aprendizaje móvil, las simulaciones, los mundos virtuales, los juegos serios, las actividades del mundo real, el aprendizaje social y el aprendizaje sin conexión. Los datos también pueden recopilarse sin conexión y enviarse al LRS más tarde.

Así, el historial de un solo estudiante en un LRS podría incluir la finalización de un curso, un video visto en una aplicación móvil, una sesión de simulador, la aprobación de una habilidad por parte de un gerente y un evento de coaching entre pares, todo en un mismo formato.

Qué no puede hacer xAPI por sí solo

La flexibilidad tiene un costo, y los compradores suelen tropezar con él.

• xAPI no define cómo debe ser una buena declaración. Dos proveedores pueden decir "compatible con xAPI" y registrar la misma actividad con verbos distintos, de modo que los datos no coinciden. Los equipos suelen necesitar un perfil acordado (un conjunto de verbos y convenciones) antes de que los reportes funcionen.
• No lanza contenido. SCORM incluye empaquetado y lanzamiento. xAPI puro no dice cómo un LMS inicia un curso ni cómo transmite la identidad del estudiante.
• No le entrega reportes. Un LRS almacena declaraciones. Los dashboards, las tablas de finalización y los reportes de cumplimiento son otra capa del stack tecnológico de aprendizaje que alguien tiene que construir o comprar.

¿Es xAPI un estándar oficial?

Sí. xAPI comenzó como una especificación de ADL, y el proyecto xAPI lo describe como un estándar aprobado por el IEEE (IEEE 9274.1.1-2023). La página de estándares del IEEE lista IEEE 9274.1.1-2023 como un estándar activo, titulado como un formato de modelo de datos JSON y servicio web RESTful para el seguimiento y acceso a datos de experiencia del estudiante, con aprobación de la junta el 30 de marzo de 2023.

cmi5: el puente

Si SCORM le da el lanzamiento y xAPI le da datos ricos, ¿se puede tener ambos? Eso es lo que hace cmi5.

cmi5 es un perfil de especificación para xAPI. Su texto lo describe como una especificación que cubre la comunicación interoperable en tiempo de ejecución entre los LMS y las Assignable Units (AU), que son piezas individuales de contenido de aprendizaje. Usa xAPI como transporte de datos y completa lo que xAPI puro deja abierto:

• Lanzamiento. El LMS lanza una AU mediante una URL que incluye un endpoint, una URL de obtención de autorización, la identidad del estudiante, un ID de registro y un ID de actividad.
• Un conjunto fijo de verbos. cmi5 especifica declaraciones como launched, initialized, completed, passed, failed y terminated, además de otras emitidas por el LMS como abandoned, waived y satisfied.
• Un LRS detrás del LMS. El LMS trabaja con un LRS para dar seguimiento al progreso y generar reportes.

En términos simples, cmi5 le da el "lanza este curso y dime si el estudiante aprobó" al estilo de SCORM, pero con la infraestructura moderna de xAPI. El contenido no necesita vivir en el mismo marco de navegador que el LMS, y los datos terminan en un LRS.

El problema es la adopción. cmi5 es mucho menos común que SCORM. Muchas herramientas de autoría y plataformas admiten SCORM y xAPI pero no cmi5, así que verifique que tanto su herramienta de contenido como su plataforma lo soporten antes de convertirlo en un requisito.

SCORM vs xAPI vs cmi5: comparación directa

Lea la tabla por filas. Si su necesidad es "demostrar que todos terminaron", la columna de SCORM la resuelve. Si es "entender cómo aprende la gente en distintas herramientas", solo xAPI lo logra.

LTI: un tipo distinto de estándar

LTI (Learning Tools Interoperability) a menudo se agrupa con SCORM y xAPI, pero cumple una función diferente. Lo mantiene 1EdTech y, según su propia descripción, permite a las instituciones conectar herramientas de aprendizaje con su entorno de aprendizaje sin que los estudiantes tengan que iniciar sesión en cada herramienta por separado. Según la página de 1EdTech, admite el paso seguro de información sobre los usuarios, su inscripción y sus roles, y permite que las herramientas envíen tareas y calificaciones de vuelta al libro de calificaciones central. La versión actual es LTI 1.3.

La forma más sencilla de recordarlo:

• SCORM y cmi5 se ocupan del contenido que se lanza y reporta resultados.
• xAPI se ocupa de los registros de la actividad de aprendizaje.
• LTI se ocupa de conectar herramientas completas con una plataforma, con inicio de sesión único y devolución de calificaciones.

Cómo decidir qué exigir

Este es un camino práctico, ya sea que compre o desarrolle.

Si usted es comprador de L&D

1. Parta del registro que necesita. Si un auditor o un cliente pide una prueba de finalización, necesita como mínimo compatibilidad con SCORM o cmi5. Revise las tasas de finalización de cursos y qué cuenta como "completo" antes de fijarlo.
2. Pregunte por la versión de SCORM. "SCORM 1.2" y "SCORM 2004 4.ª edición" no son la misma promesa. La 1.2 tiene el soporte más amplio. La 2004 es necesaria para las reglas de secuenciación.
3. Pregunte qué significa "compatible con xAPI". ¿La plataforma puede enviar declaraciones, recibirlas o ambas? ¿Incluye un LRS o se conecta a uno externo? ¿Qué verbos y perfil sigue? Un "sí" vago no es una respuesta.
4. Decida si va a usar los datos. xAPI solo rinde frutos si alguien va a analizarlo. Si solo reporta finalización, no pague por una función que no tocará. Si quiere conectar la actividad con los resultados, vea las métricas de participación de los estudiantes.
5. Pruebe con un curso real. Suba uno de sus propios cursos y verifique la finalización, la calificación y los marcadores antes de firmar. La compatibilidad es lo que más se rompe en las adquisiciones. El proceso de adquisición de aprendizaje empresarial es el lugar para incluir esa prueba.

Si usted es creador de cursos o desarrollador de EdTech

1. Exporte primero en SCORM. Es el mínimo común denominador, y los sistemas de la mayoría de los compradores corporativos lo aceptan. Ofrecer 1.2 y 2004 cubre la mayoría de las solicitudes.
2. Agregue xAPI cuando un cliente quiera datos más allá de la finalización, como decisiones en escenarios, resultados de simulaciones o actividad fuera del LMS.
3. Considere cmi5 si vende a compradores que ya lo usan, o si quiere un modelo de lanzamiento más limpio que SCORM sin renunciar a un LMS.
4. Elija LTI cuando esté construyendo una herramienta, no un curso. Si los estudiantes usarán su producto junto con el LMS, con las calificaciones regresando, LTI es la integración que debe construir. Un buen diseño instruccional define, para empezar, qué vale la pena registrar.

Datos clave

• SCORM 1.2 se lanzó en octubre de 2001 y sigue muy extendido; las ediciones de SCORM 2004 llegaron en julio de 2004, octubre de 2006 y marzo de 2009 (Scorm.com).
• La comunicación de SCORM ocurre dentro de una sesión de navegador, y solo el contenido puede iniciarla (Scorm.com).
• xAPI registra el aprendizaje como declaraciones de actor, verbo y objeto enviadas a un Learning Record Store, incluido el aprendizaje formal e informal (especificación xAPI de ADL).
• xAPI es un estándar del IEEE, IEEE 9274.1.1-2023, aprobado por la junta del IEEE el 30 de marzo de 2023 (IEEE).
• cmi5 es un perfil de xAPI que define cómo un LMS lanza contenido y qué declaraciones debe producir (especificación cmi5).
• LTI es un estándar independiente de 1EdTech para conectar herramientas con una plataforma de aprendizaje; la versión actual es la 1.3 (1EdTech).

Errores comunes

Tratar "compatible con SCORM" como una sola cosa. La versión 1.2 y las ediciones de 2004 se comportan de forma distinta, y cada LMS las interpreta a su manera. Pruebe siempre.

Tratar "compatible con xAPI" como un punto más de una lista de funciones. Sin un conjunto de verbos acordado y un lugar donde analizar los datos, termina con un montón de declaraciones que nadie puede usar.

Exigir xAPI cuando solo necesita un registro de finalización. Agrega costo y complejidad sin beneficio si su pregunta es "¿quién terminó?".

Confundir LTI con SCORM. Si un proveedor pregunta "¿SCORM o LTI?", está preguntando si usted entrega contenido o conecta una herramienta.

Para un contexto más amplio, consulte qué es EdTech.