Arquitectura de learning analytics: del evento a la intervención

Un panel muestra que una alumna ha entrado tres veces en el curso, ha reproducido el 82 % de un vídeo y lleva cuatro días sin abrir una actividad. La interfaz la marca en ámbar. ¿Qué debería hacer el tutor?

Con esos datos, nada todavía.

La alumna pudo descargar la transcripción, trabajar sin conexión y entregar la tarea en otra herramienta. El vídeo puede no ser necesario para alcanzar el objetivo. La ausencia de actividad puede significar dificultad, autonomía o un fallo de integración. El color resume observaciones; no demuestra aprendizaje ni justifica una intervención.

SoLAR actualizó en 2025 su definición de learning analytics. La nueva formulación abarca cómo se obtienen, analizan, interpretan y comunican datos sobre quienes aprenden y sobre su proceso de aprendizaje. Además, incorpora la obtención de hallazgos pertinentes desde el punto de vista teórico y aplicables en la práctica. A partir de esa formulación, propongo que una arquitectura orientada a las intervenciones registre qué se hizo y permita evaluar después el resultado de cada intervención.

Mi criterio es diseñar la cadena completa:

observación → significado → medida → decisión → intervención → resultado

Si el propósito es intervenir y no podemos explicar un eslabón, no tenemos una cadena analítica apta para actuar. Tenemos telemetría de uso con una interpretación pendiente.

El evento mínimo debe conservar lo necesario para contribuir a responder una pregunta legítima, sin atribuirle nada que no se haya observado.

Antes de recoger datos hay que definir la decisión

Es tentador empezar inventariando tablas del LMS: accesos, tiempo, notas, mensajes, entregas. Es una forma rápida de construir un lago de datos y una forma lenta de descubrir para qué sirve. Empezaría por una decisión concreta.

Por ejemplo: «ofrecer una tutoría a quienes no han podido completar el primer ejercicio práctico durante la primera semana». Esa frase obliga a precisar población, momento, condición, responsable y acción. También permite preguntar si la acción es útil y si existe una explicación alternativa.

El contrato de una métrica debería responder, como mínimo, a estas preguntas:

Con este contrato se evitan dos errores frecuentes: medir lo que está disponible en lugar de lo que importa y reutilizar una misma señal para finalidades incompatibles. Un evento recogido para recuperar una entrega no se convierte automáticamente en evidencia para predecir el abandono.

El RGPD exige finalidad específica, minimización y limitación del plazo, además de exactitud, seguridad y responsabilidad demostrable. Antes de recoger datos, cada institución debe identificar y documentar la base jurídica aplicable y comprobar la necesidad del tratamiento. Ante una reutilización, también debe documentar si la finalidad posterior es compatible con la original o si el tratamiento se apoya en un nuevo consentimiento o en una norma que autoriza ese fin. El contrato técnico debe dejar constancia de esa base jurídica y permitir aplicar las decisiones educativas respetando estos principios; no debe obligar a duplicar datos «por si acaso».

Una jerarquía impide llamar aprendizaje a cualquier actividad

Separaría seis niveles. No forman una escalera automática: una señal no sube de nivel porque acumule volumen.

Los paneles de actividad son legítimos si se presentan como actividad. El problema aparece cuando un número bajo de sesiones se etiqueta como «riesgo», «compromiso» o «probabilidad de éxito» sin un modelo de medida, un ámbito y una validación. El Handbook of Learning Analytics recuerda que medir un constructo latente exige definirlo, relacionarlo con observaciones y considerar las fuentes de error antes de justificar un uso.

Un ejemplo sencillo: repetir una pregunta cinco veces puede indicar práctica deliberada, ensayo aleatorio, una barrera de accesibilidad, un problema de interfaz o una dificultad conceptual. El recuento puede ser correcto, pero interpretarlo exige conocer la actividad, el curso y el intento, y aun así seguirá habiendo incertidumbre.

Por eso registraría dos elementos separados: la observación y la inferencia. La observación puede ser «quinto intento enviado». La inferencia puede ser «posible dificultad en el paso C» y debe indicar la versión de la regla o del modelo, las evidencias utilizadas, el responsable y la fecha de caducidad. Nunca sobrescribiría el hecho con la etiqueta.

El evento necesita significado y procedencia

Una fila con user_id, action y created_at no basta para describir un evento útil. El registro debe indicar quién o qué actuó, sobre qué versión de un objeto, en qué ámbito, cuándo ocurrió, cuándo se recibió, qué resultado se observó y qué sistema afirma que ocurrió.

Un sobre interno mínimo podría ser:

{
  "event_id": "01J…",
  "source": "simulator-a",
  "source_event_id": "attempt-928:5",
  "schema": "practice.attempted@2",
  "occurred_at": "2026-04-08T09:14:11Z",
  "recorded_at": "2026-04-08T09:14:14Z",
  "actor_ref": "analytics:7f31…",
  "scope": { "course": "C-42", "cohort": "2026-Q2" },
  "object": { "activity": "A-17", "version": "v6" },
  "attempt": 5,
  "action": "submitted",
  "result": { "completed": true, "score_ref": "S-184" },
  "purpose": "support-initial-practice",
  "retention_class": "support-90d",
  "provenance": { "producer": "simulator-a@4.8.1" }
}

No es una propuesta de estándar. Es un contrato interno que conserva las decisiones propias de la institución, ajenas al alcance de los estándares de intercambio. purpose y retention_class son afirmaciones del productor, no autorizaciones. La capa de entrada las contrasta con la política versionada del responsable del tratamiento y determina, a partir de ella, el ámbito institucional aplicable, la versión vigente y la fecha de caducidad. El productor nunca puede ampliar los permisos ni el plazo de conservación.

El momento en que ocurre el evento y el momento en que se registra deben conservarse por separado. Una aplicación móvil puede sincronizar horas después, de modo que ordenar los eventos por su llegada cambiaría la secuencia. La versión del objeto evita atribuir un resultado actual a un contenido que ya no existe, mientras que el identificador de origen permite tratar los reintentos sin duplicar datos. El productor y su versión explican qué código emitió la observación. W3C PROV ofrece un vocabulario general para relacionar entidades, actividades y agentes; no hace falta adoptar toda la ontología para conservar esa idea de linaje.

También hay que conservar la procedencia de cada transformación. Una métrica debería permitir averiguar qué eventos, filtros, reglas y versiones la generaron. Una rectificación invalida los derivados afectados y obliga a recalcularlos. La supresión, la limitación y la caducidad se propagan de acuerdo con la finalidad y la base aplicables: los derivados personales se eliminan o bloquean; los agregados irreversiblemente anonimizados y los rastros de auditoría estrictamente necesarios se tratan por separado.

xAPI y Caliper facilitan el intercambio, pero no definen la pedagogía

La versión 2.0 de xAPI está normalizada como IEEE 9274.1.1-2023 y fue adoptada después como ISO/IEC/IEEE 39274-1-1-2025. Parte de xAPI 1.0.3, pero introduce cambios y no conviene tratar ambas versiones como equivalentes. Sus declaraciones relacionan un actor, un verbo y un objeto, junto con propiedades opcionales o completadas por el LRS, como el resultado, el contexto, el tiempo, la autoridad y la versión. Dentro del protocolo no se corrigen como filas transaccionales: conservan su identidad lógica y una declaración posterior puede anularlas. Esta inmutabilidad no obliga al LRS a conservar los datos indefinidamente. Un LRS valida la estructura de la declaración y la identidad de quien la envía según el protocolo, la conserva y permite consultarla. No demuestra que el hecho externo ocurrió ni que tenga valor educativo: el contrato de medida decide si puede tratarse como evidencia.

La inmutabilidad de xAPI es lógica dentro del protocolo: anular una declaración no borra su contenido. No sustituye las obligaciones de rectificación, limitación del plazo o supresión que resulten aplicables. Por eso evitaría incluir identificadores directos en la declaración, separaría y restringiría la copia original y definiría de antemano cómo eliminarla o anonimizarla físicamente cuando venza su finalidad, aunque esa operación no forme parte de la API estándar de xAPI.

Caliper Analytics 1.2 define perfiles métricos para actividades frecuentes —evaluación, lectura, medios, foros, calificación, lanzamiento— y un vocabulario común para reunir eventos de distintas herramientas. Esa consistencia reduce el número de adaptadores necesarios y las discusiones sobre nomenclatura.

Ninguno de los dos decide:

• si «visualizó» es una evidencia válida para una competencia;
• qué identificadores de una misma persona pueden vincularse entre herramientas y durante cuánto tiempo;
• qué versión de una actividad estaba vigente;
• qué métrica autoriza una intervención;
• quién puede ver el resultado;
• si una ausencia significa riesgo o elección legítima.

Usaría el estándar en los puntos de integración para facilitar la interoperabilidad y mantendría un modelo canónico interno que responda a las preguntas de la institución. El adaptador puede traducir el evento, pero debe conservar el original solo durante el plazo y para la finalidad autorizados. Mientras ese original siga autorizado, permite reproducir la transformación. Después, solo podrán recalcularse las métricas que admita el modelo canónico aún conservado. El contrato debe declarar el horizonte de reconstrucción y qué operaciones dejan de ser posibles tras cada caducidad.

Tampoco convertiría el LRS en el sistema académico principal. Las matrículas, las calificaciones oficiales, las adaptaciones y las autorizaciones deben permanecer en los sistemas que las gestionan. El LRS conserva declaraciones de experiencia y el almacén analítico produce vistas, pero ninguno debería tratar una corrección académica como si fuera la simple actualización de una dimensión.

La arquitectura separa siete responsabilidades

Separaría siete responsabilidades, aunque un despliegue pequeño pueda implementarlas en menos servicios:

1. Producción y adaptación. El LMS, las herramientas LTI, los simuladores, las bibliotecas y las aplicaciones emiten eventos sujetos a un contrato y con un origen autenticado.

2. Recepción y prevalidación. La capa de entrada autentica y autoriza el origen, limita el tamaño y la frecuencia y comprueba en memoria transitoria el formato, el ámbito y los campos permitidos. Define por separado la demora máxima admisible de un evento nuevo, la ventana de reintento del productor y el plazo de conservación de la huella de deduplicación.

   La entrada busca primero una identidad de deduplicación derivada solo del ámbito institucional, source y source_event_id. Si ya existe y sigue abierta la ventana de reintento, compara el HMAC de los campos inmutables: cuando coincide, devuelve el acuse original; cuando difiere, rechaza la carga, registra un conflicto y exige un nuevo identificador o un evento de corrección relacionado con el anterior. Si la identidad es nueva, comprueba la demora admisible antes de reservarla de forma atómica. Guarda aparte el HMAC, la versión de la clave y el acuse. Durante la rotación comprueba también las versiones de clave que sigan vigentes.

   El registro de deduplicación se conserva durante el mínimo plazo que cubra la demora admisible y los reintentos previstos, aunque la carga se elimine antes. Fuera de esos plazos, un evento antiguo se rechaza y nunca se convierte en una observación nueva. Cuando vence la finalidad, se cierra la entrada para ese tratamiento. Un hash simple de identificadores previsibles no basta.

3. Validación y aislamiento. Esta capa comprueba la validez semántica, las marcas temporales, el productor y la coherencia entre la política autorizada y los metadatos del evento. Los eventos inválidos se rechazan o se aíslan según el motivo. La cuarentena conserva la clave, un HMAC calculado con otro secreto y otro dominio, la regla incumplida, el productor y las marcas temporales, pero no el contenido prohibido. Una copia de la carga solo puede pasar a un almacén aislado y cifrado, sin reproducir su contenido en registros ni trazas, si existe una base jurídica, la necesidad está documentada, hay autorización expresa, el acceso es restringido y se configura una caducidad automática.

4. Normalización y enriquecimiento. Los adaptadores traducen vocabularios, resuelven versiones y consultan la identidad o la pertenencia únicamente cuando lo permite la finalidad declarada.

5. Almacenamiento gobernado. El almacén mantiene eventos, declaraciones o vistas con su linaje, sus permisos, sus plazos de conservación y la posibilidad de propagar correcciones.

6. Medición y presentación. Esta capa calcula métricas versionadas y alimenta paneles, alertas o conjuntos de investigación, cada uno con su propio contrato.

7. Intervención y resultados. El sistema registra qué información vio la persona, qué decidió, qué acción ejecutó y qué ocurrió después.

Los derechos, la transparencia y el riesgo atraviesan las siete responsabilidades. Antes de activar un producto analítico hay que documentar su necesidad, su base jurídica, sus destinatarios y, cuando proceda, la evaluación de impacto relativa a la protección de datos. La arquitectura necesita una ruta auditable para informar a las personas, atender sus solicitudes de acceso, rectificación, limitación, supresión u oposición y permitirles pedir una revisión humana. También debe probar que cada cambio se propaga hasta las métricas, los paneles y las intervenciones afectadas.

Esta separación facilita sustituir una tecnología cuando el contrato está versionado, hay compatibilidad de lectura y escritura, pueden migrarse el estado y el linaje y los cálculos históricos están probados. PostgreSQL puede bastar para un volumen inicial. Más adelante quizá haga falta una plataforma de eventos. Ninguna de las dos opciones resuelve por sí sola la semántica, la finalidad ni la identidad. Dimensionaría el almacenamiento y el procesamiento después de definir la latencia, el volumen, la corrección, las consultas y la recuperación.

La identidad no debería copiarse en cada capa

Para reconstruir un recorrido hace falta un identificador seudónimo estable dentro de la finalidad, el ámbito y el periodo autorizados, no un identificador universal. Un nombre y un correo en cada evento tampoco son necesarios. Los identificadores seudónimos siguen siendo datos personales mientras la persona pueda identificarse razonablemente, incluso por singularización. Los derivaría con claves separadas por responsable, finalidad, dominio y versión; conservaría aparte tanto las correspondencias como las claves, con acceso auditado, rotación y borrado. Solo las funciones que necesitan actuar sobre una persona resuelven la identidad; las agregaciones y los análisis exploratorios aplican umbrales de divulgación para reducir el riesgo de reidentificación.

La pertenencia también cambia. Un estudiante puede pasar de grupo, abandonar, volver a matricularse o actuar bajo varios roles. Guardar solo el grupo «actual» reescribe el pasado. El enriquecimiento necesita una referencia temporal o una instantánea de la relación aplicable al evento, sin copiar el expediente entero.

Separaría al menos cuatro ámbitos:

• operativo, para soporte inmediato y acceso restringido;
• docente, para el curso y la cohorte que la persona responsable puede atender;
• institucional, con agregaciones y umbrales de divulgación para reducir el riesgo de reidentificación;
• investigación, con aprobación, finalidad y conjunto preparado específicamente.

El código de práctica de Jisc recomienda transparencia sobre la finalidad, los datos, las métricas, el acceso y la interpretación, así como registrar y revisar las intervenciones. Estas recomendaciones afectan directamente a la arquitectura, porque una etiqueta puede cambiar la forma en que docentes y alumnos perciben a una persona. Una predicción no es solo una columna: puede alterar el entorno que pretende describir.

Un panel debe permitir actuar o decidir no hacerlo

Diseñaría cada vista para una decisión concreta y para la persona que debe tomarla. El tutor necesita casos que pueda revisar, las evidencias que explican cada señal, su fecha y sus límites, y una acción permitida. El diseñador del aprendizaje necesita patrones agregados por versión de la actividad. El alumno necesita información comprensible, la posibilidad de corregir sus datos y una recomendación que preserve su autonomía.

Una alerta debería incluir:

1. qué condición se cumplió;
2. qué observaciones la sostienen y qué datos faltan;
3. qué explicaciones alternativas se conocen;
4. cuándo caduca;
5. qué acciones están permitidas;
6. quién es responsable;
7. cómo registrar «no intervenir» y por qué.

Registrar que el tutor no actuó es tan importante como registrar un mensaje. Puede deberse a una señal incorrecta, a la falta de tiempo o de personal, a que el caso ya esté resuelto o a una decisión profesional. Sin ese dato, el equipo no distingue un modelo inútil de una intervención imposible de ejecutar.

El resultado tampoco puede ser «se envió una notificación». Interesa si fue recibida, si la persona aceptó ayuda y si cambió el indicador educativo acordado, sin atribuir causalidad por adelantado. Una mejora posterior no demuestra por sí sola que la alerta la causara. Registrar el resultado permite, al menos, comparar hipótesis y retirar señales que generan trabajo sin beneficio observable.

La IA empieza después de tener una medida defendible

Un modelo predictivo puede combinar cientos de rasgos y producir una puntuación precisa sobre datos históricos. Si el objetivo, las etiquetas o la intervención no son válidos, solo automatiza una asociación. Antes de incorporar IA exigiría:

• finalidad y población documentadas;
• definición de resultado y ventana temporal;
• procedencia de cada rasgo;
• comparación con una regla sencilla y con la opción de no intervenir;
• resultados por grupos relevantes y datos ausentes;
• explicación útil para quien actúa;
• umbral vinculado a los recursos disponibles y a la consecuencia de cada decisión;
• calibración, intervalos de incertidumbre y condiciones para los datos ausentes o ajenos a la población validada;
• una regla de abstención en ejecución, una degradación segura y una desconexión independiente;
• seguimiento de deriva, correcciones y apelaciones;
• condición de retirada.

La evaluación por grupos utiliza un conjunto separado y aprobado para esa finalidad, con base jurídica, acceso restringido, umbrales de divulgación para reducir el riesgo de reidentificación y una política propia de conservación. Si no existe una comparación lícita y suficientemente robusta, se documenta la incertidumbre y no se afirma que la métrica sea equitativa.

Un indicador de riesgo no debería modificar por sí solo el acceso, la evaluación o el itinerario de una persona. En ejecución, el sistema debe abstenerse y derivar a revisión cuando no se cumplan las condiciones de población, cobertura o calidad de los datos. La revisión corresponde a una persona identificada, formada y con tiempo, contexto y autoridad para rechazar o modificar la recomendación. La interfaz no preselecciona la acción y registra los desacuerdos, las revocaciones, la capacidad disponible y sus motivos. Esta revisión humana no modifica por sí sola la clasificación jurídica: los usos educativos se evalúan según su finalidad y las reglas del artículo 6 y del anexo III del Reglamento de IA. Esa frontera se desarrolla en IA de alto riesgo en plataformas de aprendizaje. La arquitectura analítica debe mantener separadas la señal, la inferencia y la acción para clasificar cada función y poder desactivarla sin perder el resto.

Esta distinción encaja con la arquitectura más amplia de un LMS que gobierna evidencia, decisiones e IA: el sistema de registro conserva el estado institucional; la capa analítica observa e interpreta los datos con una finalidad definida. Ninguno de los dos componentes debe asumir de forma implícita las decisiones que corresponden al otro.

El primer piloto debe cerrar un ciclo pequeño

No empezaría con un panel institucional ni con «predecir abandono». Elegiría una decisión de bajo impacto, una población acotada y una intervención disponible. Por ejemplo: identificar fallos técnicos repetidos durante el primer ejercicio y ofrecer un canal de ayuda.

Antes de iniciar el piloto, registraría al responsable, la duración, la línea base, los umbrales de cobertura y calidad, el máximo de avisos erróneos y de carga operativa, el criterio de utilidad, el umbral de perjuicio para cada grupo que obliga a detener el piloto y la regla de parada o ampliación. Los controles siguientes son prerrequisitos técnicos, no una prueba de beneficio educativo:

1. cada evento procede de un productor autenticado e identifica las versiones del esquema, del objeto y del productor;
2. dentro del horizonte admitido, los reenvíos del mismo evento reciben el acuse original y no duplican la observación; fuera de ese horizonte, se rechazan antes de persistir;
3. los conflictos generan un identificador nuevo o un evento de corrección relacionado con el anterior;
4. los nuevos intentos de la actividad se conservan como hechos distintos;
5. la llegada tardía de eventos hace que el sistema recalcule la vista correspondiente;
6. los cambios de contenido no reescriben cohortes anteriores;
7. la identidad y la pertenencia se resuelven con ámbito temporal;
8. los campos prohibidos se descartan y la cuarentena conserva únicamente la evidencia mínima autorizada para investigar;
9. una corrección se propaga a métricas y paneles;
10. el tutor puede ver la evidencia, sus límites y una acción posible;
11. la intervención y la no intervención quedan registradas;
12. el resultado acordado vuelve al ciclo;
13. el sistema elimina o anonimiza los datos de cada capa cuando lo establece la política de conservación;
14. una métrica sin utilidad demostrable puede retirarse.

Solo después ampliaría las fuentes o el alcance del sistema. Ese orden evita construir una plataforma técnicamente impresionante cuyo único resultado sea un panel que nadie puede interpretar o una cola de alertas que nadie puede atender.

La intervención es parte del modelo de datos

La analítica del aprendizaje no debería medir a personas desde lejos. Debería ayudar a alumnos, docentes y diseñadores a comprender una situación y decidir mejor, con límites visibles. Para eso, el dato necesita semántica, procedencia y finalidad; la medida necesita validez; y la interfaz necesita una acción responsable.

El cambio más importante es incluir la intervención en la arquitectura desde el principio. Obliga a declarar quién puede actuar, con qué medios, qué riesgo asume y cómo se evalúa el resultado. También permite descubrir que una métrica no sirve antes de recopilar años de datos.

Un clic puede iniciar la cadena. Nunca debería terminarla.