El futuro del LMS: arquitectura para aprender con IA

Un LMS administra cursos, matrículas, actividades, entregas y calificaciones. Ese trabajo sigue siendo necesario. El error consiste en pedirle además que sea la única interfaz, el repositorio universal, el motor de integración, la plataforma de datos y el lugar donde se ejecuta cualquier experimento con inteligencia artificial.

Las primeras funciones de IA incorporadas a los LMS se han concentrado en tareas visibles: resumir, generar texto, crear imágenes o conversar con los materiales de un curso. Son útiles cuando ahorran trabajo concreto. No resuelven, sin embargo, la decisión arquitectónica de fondo. Una plataforma todavía puede ignorar qué versión de un contenido utilizó, qué permiso autorizó su consulta, por qué recomendó una actividad o si la intervención produjo el resultado esperado.

Mi tesis es que el LMS del futuro será una pieza estable dentro de un sistema más amplio. Conservará el estado académico que deba conservar, abrirá funciones mediante contratos y dejará que otras partes evolucionen a ritmos distintos. La inteligencia del aprendizaje aparecerá cuando el conjunto pueda relacionar una señal con la información necesaria para interpretarla, proponer o ejecutar una intervención y comprobar después qué ocurrió.

Para dirigir esa evolución propongo seis contratos: identidad, conocimiento, evento, decisión, acción y evidencia. Cada contrato asigna una responsabilidad, fija qué datos cruzan la frontera y define la prueba necesaria para aceptar el resultado. Pueden implementarse dentro de un monolito o repartirse entre varios sistemas.

El LMS resolvió la administración del curso

El curso digital agrupó una parte enorme del trabajo educativo en una unidad manejable. Permitió matricular personas, ordenar contenidos, abrir actividades, recoger entregas, aplicar restricciones y conservar calificaciones. También dio a universidades y empresas un lugar común desde el que prestar formación a gran escala.

Ese modelo sigue resolviendo una parte esencial. Conviene defenderlo porque una arquitectura moderna no empieza sustituyendo aquello que ya funciona. Empieza reconociendo su responsabilidad y sus límites.

El curso resulta insuficiente cuando se utiliza como modelo completo del aprendizaje. Una finalización confirma que se cumplió una condición configurada. Una calificación expresa un resultado dentro de una actividad y una escala. Un tiempo de conexión registra presencia técnica. Ninguna de esas señales explica por sí sola qué entiende una persona, dónde está su dificultad o qué intervención le conviene.

El problema aparece cuando se confunde el registro con la interpretación. El LMS puede ser la fuente autorizada de una matrícula sin tener que decidir qué significa una secuencia de intentos. Puede conservar la nota oficial sin ejecutar el motor que preparó la práctica, y abrir una herramienta externa sin convertirse en responsable de toda su lógica.

La arquitectura madura cuando cada tipo de estado tiene un responsable explícito. «El LMS es la fuente única de verdad» suele ocultar demasiadas verdades diferentes: la identidad institucional, el catálogo, la matrícula, el contenido, la evaluación oficial, la evidencia de la práctica, las competencias y el consentimiento. Un solo producto rara vez es la fuente adecuada para todas.

Inteligencia del aprendizaje significa cerrar un ciclo

Uso «inteligencia del aprendizaje» en un sentido operativo. Consiste en conectar seis pasos sin perder la procedencia entre ellos:

1. observar una señal;
2. situarla en un contexto válido;
3. proponer o tomar una decisión;
4. ejecutar una intervención autorizada;
5. recoger evidencia posterior;
6. explicar el recorrido completo.

Abrir la imagen a tamaño completo

La capacidad de explicar una decisión forma parte del ciclo. Si una recomendación cambia, la plataforma debe poder reconstruir la señal observada, el conocimiento disponible, la política aplicada, la intervención ejecutada y el resultado medido. Sin ese recorrido solo queda una salida difícil de discutir.

El ciclo también distingue una plataforma de aprendizaje de un motor de personalización comercial. La decisión no se optimiza solo por clic, permanencia o conversión. Debe relacionarse con un propósito educativo declarado y con una evidencia adecuada. Recomendar la actividad que retiene más tiempo al alumno puede ser una mala decisión si no desarrolla la competencia prevista.

Una plataforma aprende sobre su funcionamiento cuando relaciona cada intervención con la evidencia que la justificó y con el resultado observado después. Esa traza reconstruye el recorrido; no demuestra por sí sola que la intervención causara el cambio.

Esta definición impone una condición incómoda: muchas funciones llamadas «inteligentes» todavía no cierran el ciclo. Generan una respuesta sin conservar qué cambió, recomiendan un recurso sin expresar qué hipótesis intentan comprobar y marcan un riesgo sin registrar si alguien intervino ni qué ocurrió después.

Esa carencia no invalida la función, pero sí limita la promesa que puede hacerse sobre ella. Un asistente puede ahorrar tiempo sin ser un tutor, una búsqueda puede encontrar un fragmento útil sin decidir un itinerario y una alerta puede orientar a un docente sin demostrar que ha mejorado el aprendizaje. Dar a cada función un nombre que no exagere sus capacidades es el primer mecanismo de gobierno.

Seis contratos sustituyen a la lista de funciones

Una compra de LMS suele empezar por una lista: autoría con IA, tutor, recomendaciones, analítica, integraciones, aplicaciones móviles y automatizaciones. Las casillas sirven para una primera comparación comercial. No explican cómo funcionará la plataforma cuando entren varios proveedores, cambie un modelo o haya que investigar una decisión.

Los seis contratos siguientes permiten evaluar la arquitectura antes de elegir productos.

Identidad y permiso

La identidad contiene más que un identificador de usuario reutilizable. Una persona actúa dentro de una institución, un curso, un grupo, una actividad y un momento. El permiso depende de ese ámbito. También depende de la finalidad: abrir un simulador, corregir una entrega y entrenar un modelo son tratamientos distintos aunque utilicen la misma cuenta.

El contrato debería definir quién autentica, quién asigna roles, cómo se traducen a permisos de dominio, qué datos personales recibe cada herramienta y cómo se revoca el acceso. Debe cubrir además las identidades técnicas. Un agente que consulta contenidos o actualiza un registro necesita una identidad, unos alcances y un responsable igual que una persona.

Conocimiento y procedencia

Un archivo encontrado no equivale a conocimiento autorizado. La construcción de la entrada mantiene dos representaciones enlazadas. El sobre de control conserva la identidad interna, el rol, los permisos, el responsable, la audiencia, el ámbito, la decisión de autorización y las referencias completas de auditoría; no se serializa para el modelo. La entrada visible contiene solo los fragmentos ya autorizados, las etiquetas de fuente, versión y vigencia que necesite para citarlos y las restricciones de la tarea. Si esta requiere un atributo del ámbito, se envía el mínimo posible y, cuando proceda, mediante un identificador seudónimo.

Una lista de campos permitidos impide transferir por defecto datos del sobre de control. Si falta un dato necesario para autorizar o interpretar el fragmento, el orquestador trata la entrada como incompleta y se abstiene. El modelo no decide permisos ni aplica efectos.

La procedencia permite retirar información sin reconstruir todo el índice, comparar versiones y explicar por qué una respuesta utilizó un contenido concreto. También evita mezclar un reglamento vigente con una presentación antigua o una guía del profesorado con un material destinado al alumno.

Evento y significado

Un evento describe algo observable: una actividad abierta, una respuesta enviada, un recurso consultado o una calificación registrada. Su nombre, el esquema, el actor, el objeto y el momento deben ser coherentes. El evento, por sí solo, no contiene su significado educativo.

Una reproducción de vídeo puede mostrar interés, obligación administrativa o una pestaña abierta sin atención. Una segunda respuesta puede ser práctica deliberada o ensayo al azar. El contrato separa el hecho observado de la inferencia y obliga a declarar qué combinación de señales permite sostener una conclusión.

Decisión y responsabilidad

La decisión une las señales, el conocimiento y una política. Esa política puede ser una regla escrita, un modelo estadístico, una combinación de recuperación y generación o una revisión humana. La arquitectura debe conservar la versión de cada política y dejar claro qué autoridad se le ha otorgado.

No todas las decisiones necesitan la misma revisión. Ordenar resultados de búsqueda tiene un impacto distinto de bloquear el acceso a una actividad, asignar un nivel o calificar una respuesta. El contrato fija el umbral de confianza, las condiciones de abstención, la intervención humana y la persona responsable de aceptar el riesgo.

Acción y reversibilidad

Una recomendación solo adquiere consecuencias cuando alguien o algún sistema actúa. Mostrar una sugerencia, matricular en un itinerario, ocultar un contenido y registrar una nota son acciones distintas. Toda acción debe quedar registrada. Las que cambian el estado necesitan una confirmación proporcional al efecto, idempotencia o deduplicación y una estrategia de reversión o compensación; una sugerencia meramente informativa puede requerir controles más ligeros.

Entiendo la reversibilidad como la posibilidad de detener la función, compensar un efecto y recuperar el estado autorizado. Algunas acciones no podrán deshacerse sin coste. Si el proveedor desaparece, la institución debe conservar suficiente información para continuar el proceso o trasladarlo.

Evidencia y operación

El último contrato comprueba dos planos. El técnico mide la disponibilidad, la latencia, el coste, los errores, la calidad de la recuperación y el comportamiento del modelo. El educativo registra el resultado observado después de la intervención sin atribuirle causalidad. Cuando sea necesario estimar el efecto, define antes el diseño adecuado: asignación aleatoria si resulta viable o una comparación cuasiexperimental con línea de base, grupo comparable, abandono e incertidumbre. El informe separa siempre el cambio observado del efecto estimado.

Una función puede ser rápida y estable mientras produce recomendaciones irrelevantes. También puede ofrecer respuestas valoradas por los usuarios sin mejorar la competencia que debía trabajar. La aceptación del sistema necesita criterios en ambos planos y un responsable que pueda retirar la función cuando deje de cumplirlos.

La plataforma ya no cabe dentro de un solo producto

Los seis contratos no exigen comprar seis sistemas, sino separar responsabilidades. Un monolito modular puede implementarlos dentro de un único despliegue, mientras que una plataforma grande puede repartirlos entre servicios. En ambos casos, la institución puede conservar el LMS como sistema académico, utilizar herramientas externas mediante LTI y mantener los datos, el conocimiento y la evaluación en servicios compartidos.

Abrir la imagen a tamaño completo

Los seis contratos son fronteras transversales, no seis servicios. En las cinco bandas, identidad y permiso atraviesan el conjunto; conocimiento se concentra en contexto y datos; evento conecta esa banda con los sistemas de registro; decisión corresponde a decisión y evaluación; acción, a orquestación; y evidencia enlaza las cinco. Una misma pieza puede implementar varios contratos, pero cada frontera conserva un responsable y una prueba.

La arquitectura que utilizaría como referencia tiene cinco bandas:

1. Interfaces. Aulas, portales, aplicaciones, simuladores, asistentes y herramientas de trabajo docente.
2. Orquestación e intervención. Flujos que coordinan pasos, herramientas, aprobaciones, notificaciones y compensaciones.
3. Decisión y evaluación. Reglas, modelos, rúbricas, recomendadores y políticas que interpretan señales bajo una finalidad.
4. Contexto, conocimiento y datos. Fuentes versionadas, índices, grafos, eventos, evidencias y estados derivados.
5. Sistemas de registro. LMS, sistema académico, recursos humanos, identidad, repositorios y aplicaciones responsables del estado autorizado.

La identidad, la seguridad, el gobierno y la observabilidad atraviesan las cinco bandas. Si solo aparecen en una caja lateral del diagrama, llegarán tarde a las decisiones donde importan.

El LMS puede ocupar más de una banda. Moodle, por ejemplo, ofrece interfaz, actividades, registros académicos, APIs y un subsistema de IA que separa componentes de interfaz, acciones y proveedores. Esa separación facilita cambiar el proveedor que ejecuta una acción. No convierte por sí sola el curso en conocimiento gobernado ni define cómo evaluar un tutor. La decisión relevante consiste en reconocer qué contrato cubre cada función y cuál sigue fuera.

Headless, componible, modular o distribuido

«Headless LMS» se usa para describir arquitecturas muy distintas. En su sentido clásico separa la interfaz del sistema que administra el contenido o el estado. En una plataforma educativa, cambiar la pantalla es solo una de las decisiones. También hay que separar identidad, lógica de aprendizaje, conocimiento, eventos, evaluación y operación.

No elegiría una arquitectura por la etiqueta. Elegiría el grado de separación que necesita cada responsabilidad.

La tabla evita una falsa progresión. Los servicios distribuidos resuelven problemas que quizá una organización todavía no tiene y crean otros desde el primer día. Para muchos equipos, un monolito modular con una capa de integración clara será más fiable que veinte servicios sin responsabilidad operativa.

Tampoco sacaría automáticamente toda función de IA fuera del LMS. La decisión depende de la frecuencia de cambio, los datos necesarios, la carga, el riesgo y el grado de reutilización. Un resumen acotado dentro de una actividad puede vivir cerca de ella. Un servicio de contexto utilizado por varios canales necesita una responsabilidad independiente aunque se despliegue inicialmente junto al resto.

La pregunta útil es qué debe poder cambiar sin obligar a cambiar lo demás. Si sustituir un modelo exige actualizar cuarenta plugins, falta una frontera. Si renovar la interfaz duplica reglas de matrícula, la separación es aparente. Si una herramienta externa no puede devolver sus datos ni reconstruir sus decisiones, la plataforma es componible en el diagrama y cautiva en la operación.

Esa separación técnica solo funciona cuando alguien responde de cada frontera. Por eso la siguiente decisión no es tecnológica: consiste en repartir la responsabilidad, la autoridad y el trabajo operativo entre los equipos.

Los contratos también reparten trabajo entre equipos

Una arquitectura no se sostiene si el organigrama la contradice. Cuando la identidad, el conocimiento, los datos, el aprendizaje y la IA dependen de equipos distintos, cada frontera técnica necesita un reparto equivalente de responsabilidades. De lo contrario, el diagrama las distribuye y las reuniones vuelven a concentrarlas en la persona que conoce el LMS.

No crearía un «equipo de IA» responsable de cualquier función que utilice un modelo. Ese equipo puede mantener la pasarela de modelos, la evaluación común y las salvaguardas técnicas. No debería decidir por su cuenta qué evidencia demuestra una competencia, qué información puede usar un tutor o cuándo una recomendación afecta de forma indebida a una trayectoria.

Tampoco encargaría toda la plataforma al área de aprendizaje. El diseño educativo necesita autoridad sobre finalidad, actividades, rúbricas e intervención docente. La identidad, la seguridad, la fiabilidad o los contratos de integración requieren otras especialidades. La dirección tecnológica debe hacer explícito dónde termina la responsabilidad de cada una y quién arbitra el desacuerdo.

La responsabilidad del resultado debe recaer en quien puede cambiar el proceso, no en quien proporciona la tecnología. Si un proveedor ejecuta el modelo y la institución decide la finalidad, la institución sigue necesitando un responsable capaz de limitar el uso. Si una recomendación aumenta trabajo docente sin mejorar la intervención, el problema no se resuelve afinando el modelo: hay que cambiar el producto o retirarlo.

Un equipo de plataforma puede reducir el coste común. Mantiene la identidad, la integración, la observabilidad, las plantillas de seguridad, los contratos de eventos y los mecanismos de despliegue. Trabaja como proveedor interno con un catálogo pequeño de capacidades y condiciones de uso. No se convierte en una oficina de proyectos que aprueba cada pantalla ni en el equipo que implementa todos los casos.

La medida de ese equipo tampoco debería ser cuántos conectores entrega. Miraría el tiempo necesario para incorporar una herramienta sin copiar identidades, el porcentaje de integraciones con trazas y responsable, la facilidad para revocar un proveedor y la cantidad de decisiones que pueden reconstruirse con su salida original y sus versiones. Los componentes deterministas sí deben poder reproducirse; los generativos se vuelven a evaluar sin exigir una salida idéntica. Son medidas de control arquitectónico, no de actividad.

Repartir responsabilidades permite además localizar el coste real. Sin ese reparto, la licencia parece barata porque la integración, el soporte, la evaluación y la salida quedan escondidos en presupuestos distintos.

El coste total aparece al cambiar y al salir

El precio de licencia es la parte más visible y con frecuencia la menos decisiva. Una plataforma acumula costes de integración, duplicación de datos, pruebas, soporte, observabilidad, revisión de contenido, evaluación de IA, cambios de versión y coordinación entre proveedores. Una función barata puede resultar cara si obliga a rehacer permisos o investigar a mano cada incidencia.

Compararía alternativas mediante seis partidas:

1. Adopción. Configuración, migración, formación, accesibilidad y cambio de procesos.
2. Integración. Contratos, identidades, sincronización, pruebas y tratamiento del fallo.
3. Operación. Infraestructura, guardias, soporte, trazas, conservación y respuesta a incidentes.
4. Evolución. Actualizaciones, compatibilidad, adaptación de contenidos y cambios regulatorios.
5. Evaluación. Conjuntos de prueba, revisión humana, seguimiento de resultados y corrección de deriva.
6. Salida. Exportación, transición, cierre de accesos, conservación de evidencia y sustitución.

No convertiría esas partidas en una cifra universal. Las utilizaría para comparar la misma función en dos diseños. Una función dentro del LMS puede ahorrar integración inicial y encarecer la actualización del núcleo. Un servicio externo puede acelerar la puesta en marcha y añadir costes de operación de red, gestión de identidad y continuidad. Un modelo gestionado puede reducir la infraestructura y aumentar la dependencia de políticas o precios que la institución no controla.

La arquitectura debe expresar dónde se paga cada coste. Si aparece una cola, alguien tendrá que operarla. Si hay una caché, hará falta una política de invalidación. Si una aplicación externa conserva notas provisionales, deberá conciliarlas. Si un agente puede ejecutar herramientas, habrá que mantener los permisos, las confirmaciones y los registros. Las cajas del diagrama representan compromisos de mantenimiento.

La prueba de salida ofrece una medida especialmente honesta. Antes de renovar un componente crítico, ejecutaría en un entorno de ensayo la exportación, la revocación y la recuperación del proceso. Si la organización descubre entonces que faltan identificadores, historial o semántica, el coste ya existe aunque todavía no figure en ninguna factura.

El contexto gobernado vale más que la respuesta generada

Una arquitectura RAG suele describirse mediante una secuencia de ingestión, fragmentación, indexación, recuperación y generación. Ese recorrido explica cómo llega el texto al modelo, pero no decide cuál puede utilizarse para una persona, una tarea y un momento concretos.

El sobre de control de una intervención debería construirse con varias fuentes:

• la finalidad educativa y la actividad actual;
• la identidad, el rol y los permisos;
• el estado del alumno que resulte legítimo utilizar;
• el conocimiento vigente para esa audiencia;
• la política de respuesta y abstención;
• las acciones disponibles y sus límites.

El orden importa: los permisos se aplican antes de recuperar información y la vigencia se comprueba antes de componer la respuesta. Después, la política decide si hace falta una explicación, una pregunta o la intervención de una persona. Solo entonces se compone la entrada mínima para el modelo. El sobre de control y esa entrada deben poder reconstruirse sin conservar datos personales más tiempo del necesario.

Por eso separaría el conocimiento del contenido. El contenido es una unidad publicada: un PDF, una página, un vídeo o una actividad. El conocimiento añade relaciones y condiciones: la versión, la autoría, la competencia, los prerrequisitos, la audiencia, la validez, los derechos y la procedencia. Dos fragmentos idénticos pueden no ser intercambiables si uno está aprobado para evaluación y otro es una nota de trabajo.

Esta capa resulta decisiva cuando aparecen varios modelos, agentes y canales. Sin ella, cada función construye su propio índice, aplica permisos de manera distinta y produce una versión incompatible de la verdad. Con ella, el sistema puede compartir reglas y procedencia sin obligar a que todas las interfaces utilicen el mismo proveedor.

Los eventos todavía no demuestran aprendizaje

Estándares como Caliper y xAPI ayudan a expresar actividad con vocabularios y estructuras comunes. cmi5 añade convenciones para lanzar y seguir contenidos dentro de un entorno compatible con xAPI. Su valor aumenta cuando varias herramientas necesitan compartir eventos sin inventar un formato por integración.

El estándar describe la estructura del evento y una parte del lenguaje. La organización sigue decidiendo qué evidencia acepta, porque el almacén de eventos no puede tomar esa decisión.

Pensemos en una simulación clínica. El sistema registra que una persona abrió el caso, eligió una intervención, consultó una ayuda y completó el escenario. Esos eventos permiten reconstruir la secuencia. Para convertirla en evidencia hacen falta más decisiones: qué competencia se observa, qué opciones eran aceptables, qué ayuda invalida una inferencia, qué versión del caso estaba activa y qué evaluador responde de la rúbrica.

El recorrido debería conservar al menos cuatro niveles:

Una plataforma de inteligencia del aprendizaje debe hacer visibles esas fronteras y registrar tanto la incertidumbre como el desacuerdo. Si dos evaluadores no interpretarían la misma secuencia de forma parecida, añadir un modelo no corrige la validez del instrumento.

La separación entre la actividad, la evidencia y el resultado obliga a revisar otra pieza que suele quedar implícita: qué información mantiene la plataforma sobre cada alumno y durante cuánto tiempo la considera válida.

El modelo del alumno debe conservar incertidumbre

Una plataforma que recomienda termina construyendo alguna representación del alumno, aunque no la llame así. Puede incluir competencias observadas, dificultades probables, preferencias declaradas, actividades recientes y objetivos. El riesgo aparece cuando todas esas piezas se mezclan en un perfil permanente y el sistema empieza a tratar una inferencia como un hecho.

Separaría tres clases de estado:

1. Estado institucional. Matrícula, rol, acreditación o calificación oficial. Tiene una fuente autorizada y un procedimiento de corrección.
2. Evidencia observada. Respuesta, entrega, secuencia o valoración conservada con la actividad, la versión y el criterio que la produjo.
3. Inferencia temporal. Estimación sobre el grado de dominio, una dificultad o una necesidad de apoyo. Incluye el método, la fecha, la incertidumbre y la condición de caducidad.

La inferencia nunca debería sobrescribir el estado institucional ni presentarse como una característica estable de la persona. «Probabilidad de necesitar refuerzo en ecuaciones lineales» puede orientar una práctica. «Alumno con baja capacidad matemática» convierte una señal limitada en una etiqueta y hace mucho más difícil corregir el sistema.

Modelaría cada inferencia como una afirmación versionada. Incluiría el sujeto, la competencia o el objetivo, la evidencia de origen, la política o el modelo que la calculó, un intervalo de confianza si procede, la fecha de validez y el responsable. También registraría qué decisión la utilizó. De ese modo se puede retirar una política y localizar las intervenciones que dependieron de ella.

Los permisos de acceso deben ser más precisos que una autorización general de analítica. Un docente puede consultar las evidencias de su grupo sin ver inferencias producidas para orientación. Un alumno debería conocer qué información relevante utiliza la plataforma y disponer de un cauce para corregir errores. Un proveedor técnico puede necesitar trazas agregadas sin acceder a respuestas identificables.

El modelo tampoco debe crecer porque haya datos disponibles. Cada atributo necesita una finalidad, un periodo de conservación y una acción que justifique su existencia. Si una preferencia no cambia ninguna decisión, se elimina. Si una inferencia caduca tras una unidad, no se arrastra al resto del programa. Esta disciplina reduce el riesgo y mejora la interpretación: un conjunto de datos reducido y fechado suele resultar más útil que un perfil exhaustivo que nadie sabe mantener.

La fiabilidad de una recomendación depende tanto de estas reglas como del algoritmo. Dos sistemas pueden calcular la misma puntuación y comportarse de forma distinta si uno conserva incertidumbre y el otro la oculta. El primero permite revisar; el segundo convierte una estimación en destino.

Cada función de IA entra por una puerta distinta

Agrupar toda la IA en una sola categoría conduce a controles genéricos. Generar una imagen de apoyo, buscar una norma, recomendar un itinerario y calificar una respuesta no tienen el mismo efecto ni necesitan la misma evidencia.

La supervisión humana también cambia por familia. En autoría puede consistir en aprobar antes de publicar. En búsqueda puede exigir mostrar la fuente y permitir contraste. En una recomendación conviene explicar qué señal influyó y ofrecer una alternativa. En evaluación, la persona que revisa necesita tiempo, autoridad, información y una interfaz que permita cambiar el resultado.

El análisis sobre IA educativa de alto riesgo desarrolla la clasificación europea a partir de la finalidad y la influencia material. La consecuencia arquitectónica aquí es más amplia: el inventario debe organizarse por funciones. Un mismo proveedor puede intervenir en varias familias y cada una necesita su propio contrato.

El docente necesita decisiones que pueda discutir

Los paneles educativos suelen sumar señales y colorearlas. Un indicador rojo puede significar pocas conexiones, baja calificación, retraso, un modelo predictivo o una combinación desconocida. Si el docente no sabe qué observó el sistema, no puede decidir si la alerta merece una intervención.

Una alerta operable debería responder cinco preguntas en la misma vista:

1. ¿Qué se ha observado?
2. ¿Qué interpretación propone la plataforma?
3. ¿Qué información falta o podría cambiarla?
4. ¿Qué acción se recomienda y por qué?
5. ¿Qué quedará registrado después de actuar o descartar?

Esto obliga a diseñar la incertidumbre. «Riesgo: 78 %» parece preciso y puede ser menos útil que «dos actividades críticas sin entregar; no hay datos sobre el trabajo realizado fuera del campus». La segunda formulación permite discutir la evidencia. La primera exige confiar en un modelo que quizá optimice abandono histórico, no necesidad de apoyo.

También evitaría convertir cada señal en una tarea docente. Una plataforma puede detectar cientos de desviaciones y trasladar su coste a quien enseña. El diseño debe priorizar, agrupar y medir el tiempo y la autoridad disponibles para intervenir. Una alerta sin responsable o sin tiempo disponible no produce una intervención viable.

Interoperabilidad significa poder cambiar de decisión

LTI, las APIs y los eventos resuelven fronteras distintas: LTI permite abrir herramientas remotas con contexto y servicios acotados; una API de dominio expone operaciones propias; xAPI y Caliper expresan actividad; y cmi5 añade un modelo para distribuir, lanzar y seguir contenidos. Ninguno de estos mecanismos convierte por sí solo el ecosistema en una plataforma sustituible.

La guía de LTI 1.3 en producción explica por qué el lanzamiento, la identidad y la autorización necesitan contratos separados. La comparativa entre LTI, API y xAPI sitúa cada mecanismo según la frontera que cruza.

En el futuro del LMS añadiría una exigencia: toda integración importante debe especificar cómo se sustituirá o retirará. ¿Qué datos puede recuperar la institución? ¿Con qué semántica? ¿Qué procesos quedan pendientes? ¿Cómo se revocan los accesos? ¿Quién conserva la evidencia oficial? ¿Qué ocurre durante una caída o al terminar el contrato?

Un catálogo con cien conectores puede seguir siendo cautivo. Basta con que las decisiones, los identificadores o el historial de versiones solo tengan sentido dentro del proveedor. La interoperabilidad se demuestra sustituyendo un componente en un entorno de ensayo, no contando logotipos en una página.

Accesibilidad, seguridad y regulación atraviesan el recorrido

Una interfaz accesible no compensa una intervención imposible de entender. Un LMS conforme no garantiza que el contenido generado, el tutor externo o la aplicación móvil conserven esa conformidad. WCAG 2.2 define criterios comprobables e independientes de una tecnología concreta, pero la plataforma debe aplicar el objetivo a cada interfaz y a cada estado dinámico.

La IA añade problemas específicos. Una respuesta puede cambiar de longitud, idioma y estructura. Una interfaz conversacional puede mover el foco de forma inesperada. Una explicación generada puede depender del color o de una imagen sin alternativa. Las pruebas de cada interfaz deben recorrer esas situaciones con las tecnologías de apoyo que utilice la audiencia.

La seguridad tampoco termina al autenticar. El conocimiento recuperado puede contener instrucciones hostiles. Una herramienta puede recibir más datos de los que necesita. Un agente puede ejecutar una acción válida fuera del ámbito autorizado. El sistema debe tratar contenido, herramientas y modelos como fronteras distintas, con permisos mínimos y confirmaciones proporcionales al efecto.

La regulación europea obliga además a distinguir usos. Determinadas funciones educativas pueden entrar en la categoría de alto riesgo cuando afectan al acceso, la evaluación o el recorrido de una persona. Inferir emociones en instituciones educativas está prohibido salvo excepciones limitadas. La arquitectura debe permitir clasificar cada función por finalidad, documentarla y retirarla sin desmontar el resto de la plataforma.

La observabilidad debe seguir la decisión completa

Las trazas, métricas y registros técnicos permiten investigar peticiones, errores y consumo. En una plataforma inteligente hay que añadir la decisión como unidad de seguimiento. No basta con saber que el proveedor respondió en 820 milisegundos.

Asignaría un identificador a cada intervención relevante y enlazaría, bajo políticas de minimización y retención, estos elementos:

• la señal y el evento de origen;
• la versión de la política, el modelo y las instrucciones;
• las fuentes y los fragmentos de contexto;
• la salida del sistema y el grado de confianza, si existe;
• la revisión humana y el cambio aplicado;
• la acción ejecutada o compensada;
• la evidencia posterior asociada al objetivo.

La información sensible no debe viajar como etiqueta por toda la plataforma de observabilidad. Los identificadores de persona, respuestas y contenido necesitan registros protegidos y acceso acotado. Las métricas agregadas sirven para tendencias; la investigación de un caso utiliza la traza protegida y su política de conservación.

Usaría cuatro cuadros de mando separados: uno para la disponibilidad, la latencia y los errores; otro para el coste y el consumo por caso de uso; un tercero para la calidad del sistema de IA, incluida la recuperación, la abstención, las discrepancias y los fallos por conjunto de prueba; y un cuarto para el resultado educativo o laboral. Mezclarlos en un único porcentaje oculta si el problema está en el servicio, el modelo, la política o el diseño del aprendizaje.

Una recomendación que no puede reconstruirse Si una persona impugna un itinerario y el equipo solo conserva el resultado final, la plataforma no dispone de trazabilidad. Necesita saber qué señal activó la decisión, qué versión se aplicó, qué contexto se utilizó y qué intervención recibió. El registro se diseña antes del incidente.

La evolución empieza haciendo visible el sistema actual

No sustituiría el LMS de una vez. Tampoco empezaría construyendo una plataforma de datos universal. La evolución puede organizarse en tres horizontes, cada uno con una condición de salida.

Primer horizonte: hacer explícitas las responsabilidades

El equipo inventariaría los sistemas, las integraciones, los responsables y los estados autorizados. Dibujaría los recorridos críticos: el alta, la matrícula, el acceso, la actividad, la evaluación, la certificación y la baja. Para cada frontera registraría la identidad, los datos, los errores, los reintentos y el responsable.

La condición de salida es operativa: el equipo puede explicar un caso de extremo a extremo sin depender de la única persona que conoce la plataforma. Las integraciones críticas tienen alertas, un procedimiento de actuación y una prueba de recuperación.

Segundo horizonte: separar conocimiento, eventos y decisiones

Después normalizaría los contratos que necesitan varias interfaces. No hace falta centralizar todos los datos, aunque sí conviene compartir un modelo de identidad, criterios comunes de procedencia del conocimiento, un vocabulario de eventos y un registro de decisiones.

La condición de salida es la sustitución controlada. Una nueva interfaz puede reutilizar esos contratos sin copiar la base de datos del LMS. Un proveedor puede cambiarse en un entorno de ensayo y la institución conserva los estados que necesita.

Tercer horizonte: introducir intervenciones evaluables

Solo entonces ampliaría la IA desde las tareas asistivas hacia las recomendaciones, la tutoría o la evaluación. Cada función debe tener un propósito, un conjunto de pruebas, un responsable, unos límites, un mecanismo de supervisión y una condición de retirada. El despliegue empieza en un ámbito donde el equipo pueda observar el resultado y corregir el sistema.

La condición de salida se cumple cuando la intervención técnica satisface sus criterios y el equipo puede detenerla sin perder el proceso educativo. El número de usuarios no demuestra ninguna de las dos cosas.

Qué preguntaría antes de comprar un LMS con IA

Una demostración comercial debería terminar con evidencias, no con una lista de impresiones. Estas son las preguntas que utilizaría:

La precisión de la respuesta importa más que la marca. Un proveedor maduro puede reconocer un límite y ofrecer una forma clara de operarlo. Una promesa absoluta suele trasladar la incertidumbre al comprador.

Cinco cambios que considero probables

No sabemos qué modelos ni qué productos dominarán dentro de cinco años. Sí podemos señalar cambios que ya se desprenden de las restricciones actuales y declarar qué los refutaría.

El LMS seguirá siendo un sistema de registro relevante. Matrículas, cursos, calificaciones y estados oficiales necesitan continuidad. Esta previsión fallaría si otro sistema institucional asumiera esas responsabilidades con menor coste y mejor gobierno.

La interacción se repartirá entre varias interfaces. Aplicaciones, asistentes y herramientas especializadas avanzan a ritmos distintos del núcleo académico. La previsión fallaría si el LMS pudiera ofrecer esa diversidad sin multiplicar el acoplamiento ni el coste de actualización.

El contexto gobernado será más valioso que la generación indiferenciada. Los modelos cambiarán; la procedencia, los permisos y el conocimiento propio permanecen. La previsión fallaría si los sistemas pudieran producir respuestas fiables sin distinguir vigencia, audiencia y autorización.

La evaluación distinguirá las demostraciones de los productos operables. Cuando dos asistentes parezcan igual de fluidos, importará cuál puede probarse, observarse y retirarse. La previsión fallaría si el mercado aceptara de forma sostenida funciones opacas en decisiones educativas relevantes.

La posibilidad de salida se convertirá en una característica de producto. La fragmentación de proveedores hace que conservar datos, decisiones y continuidad tenga una utilidad directa. La previsión fallaría si los costes de sustitución dejaran de influir en las compras y las renovaciones.

El futuro del LMS es una decisión de arquitectura

El LMS no necesita desaparecer para que cambie la plataforma, pero sí asumir una responsabilidad más precisa. Debe conservar los estados académicos que le correspondan, abrirlos mediante contratos gobernados y dejar que el conocimiento, las interfaces y las decisiones evolucionen sin convertir el núcleo en un catálogo de dependencias.

La IA tampoco convierte el sistema por sí sola. Puede acelerar la autoría, mejorar una búsqueda o proponer una intervención. El salto ocurre cuando la plataforma sabe qué observó, con qué contexto trabajó, quién autorizó la decisión, qué cambió para la persona y cómo se comprobó el resultado después.

Los seis contratos ofrecen una prueba sencilla. Si la identidad, el conocimiento, los eventos, las decisiones, las acciones y la evidencia tienen un responsable, una versión y un criterio de aceptación, la plataforma puede evolucionar. Si esos contratos permanecen implícitos dentro de productos e integraciones, cualquier función nueva aumenta una deuda que todavía no se ve.

Última revisión: 28 de julio de 2026.

Alberto Lara Hernández trabaja en dirección técnica, arquitectura de plataformas de aprendizaje e IA aplicada con gobierno. Publica análisis para equipos que necesitan tomar decisiones tecnológicas que sigan siendo explicables cuando el sistema crece.