¿Cedemos la apertura y la seguridad de los REA por hacer recursos más vistosos con código generado por inteligencia artificial?
Crear recursos educativos ha dejado de ser un acto de artesanía lenta para convertirse en un proceso de copia, generación y pegado. La inteligencia artificial permite hoy que cualquier docente inserte en minutos animaciones complejas, cronómetros sofisticados o juegos interactivos en sus materiales. Pero ¿a qué precio?
El espejismo de lo vistoso
Con herramientas como eXeLearning, la democratización de la creación de contenido educativo digital es un logro enorme. Sin embargo, la integración de código generado por IA introduce una paradoja que conviene nombrar con claridad: cuanto más sofisticado visualmente es un recurso, menos abierto suele ser.
Un REA no es abierto únicamente porque lleve una licencia Creative Commons. Es abierto porque otra persona puede descargarlo, leerlo, comprenderlo, modificarlo y mejorarlo. Si ese recurso contiene cientos de líneas de JavaScript que nadie entiende —ni siquiera quien las insertó— ha dejado de ser abierto en lo esencial, aunque la licencia diga lo contrario.
La trampa es tentadora: un script bien colocado hace que nieve sobre un texto, que aparezca un temporizador elegante, que los elementos se animen al hacer scroll. El resultado es vistoso. Pero ese código que «hace magia» es exactamente el que rompe la cadena de la apertura. Si el siguiente docente no puede tocarlo, el recurso muere en su primera versión.
«Si no sabes explicar qué hace el código que acabas de pegar, tu recurso acaba de perder la A de Abierto.»
Lo que de verdad importa: el núcleo pedagógico
Antes de hablar de scripts y seguridad, conviene recordar para qué existe un REA. No para impresionar. Para enseñar.
Un recurso con una buena secuencia didáctica —aprendizaje basado en proyectos, aula invertida, evaluación formativa bien articulada— es infinitamente más valioso que uno con un diseño web espectacular, pero sin fondo pedagógico. La pregunta que todo docente debería hacerse al crear un material no es «¿cómo hago esto más bonito?» sino «¿cómo ayuda esto a que mi alumno aprenda mejor?»
Hay tres pilares que ningún script puede sustituir. El primero es la claridad del objetivo de aprendizaje: un alumno debe saber en todo momento qué se espera que aprenda y por qué. El segundo es la retroalimentación formativa: no basta con mostrar si una respuesta es correcta o incorrecta; importa explicar por qué, ofrecer una pista, invitar a intentarlo de nuevo. El tercero es la coherencia metodológica: cada actividad, cada recurso, cada interacción debería responder a una decisión didáctica consciente, no a lo que la IA propuso por defecto.
Si cedemos nuestro pensamiento a la IA para que genere tanto el contenido como el código, ¿desde dónde enseñamos pensamiento crítico a nuestros estudiantes? Un REA no es un producto de diseño: es un acto didáctico. Y los actos didácticos los toman personas, no algoritmos.
El código como caballo de Troya
Más allá de la apertura, hay un riesgo concreto que los repositorios de REA no pueden ignorar: el código malicioso. Los repositorios públicos funcionan sobre la base de la confianza comunitaria, pero esa confianza puede ser explotada. Un usuario malintencionado puede pedirle a una IA que oculte un script que «robe datos del usuario» dentro de un recurso aparentemente inofensivo. Incluso sin mala intención, la IA puede generar código con «alucinaciones»: referencias a librerías inexistentes o suplantadas por versiones maliciosas sin que el creador ni el repositorio lo detecten.
Existe, no obstante, una primera línea de defensa que muchos docentes descubren por sorpresa: los propios editores de contenido de los LMS (Moodle, Canvas, Blackboard, Chamilo…) filtran o bloquean el JavaScript cuando se intenta pegar en sus campos de texto. Lo que parece un «error técnico» es una medida de seguridad deliberada. Si el LMS rechaza tu código, no está fallando: te está advirtiendo de que ese contenido no es apto para un entorno educativo compartido.
Conviene aclarar un malentendido frecuente: que el LMS rechace el código en su editor no significa que un paquete SCORM o HTML5 exportado desde eXeLearning esté libre de riesgos. El SCORM es simplemente un contenedor; si el recurso original tenía código malicioso, ese código viaja dentro del paquete y se ejecutará igualmente cuando el alumno lo abra. El filtro del LMS protege su propio editor, no el contenido que se sube empaquetado. La única garantía real es que el autor comprenda y revise el código antes de publicarlo, sea cual sea el formato de exportación.
El semáforo del código en los REA
Para ayudar a los docentes a evaluar el código que incluyen en sus recursos, proponemos una clasificación visual en tres niveles. Cada nivel se describe con su criterio, la razón por la que importa y un ejemplo concreto extraído de situaciones reales en el aula.
⬤ VERDE — Código seguro y abierto
| Criterio | Por qué importa | Ejemplo práctico |
| iDevices nativos de eXeLearning | Los iDevices incluidos en eXeLearning (cuestionarios, galerías, actividades SCORM) han sido desarrollados y revisados por el equipo oficial. Su código es conocido, estable y funciona en cualquier entorno compatible. Cualquier docente puede editarlos sin tocar una sola línea de código. | Un docente crea un cuestionario de opción múltiple usando el iDevice «Pregunta de opción múltiple» de eXeLearning. Otro docente descarga el REA, abre el editor y modifica las preguntas sin necesidad de conocimientos técnicos. |
| HTML y CSS estándar y legible | El uso de etiquetas HTML básicas (párrafos, negritas, listas, tablas) y CSS sencillo para colores o márgenes es comprensible para cualquier docente con nociones mínimas. No requiere programación: es el mismo lenguaje que usan los procesadores de texto avanzados.
No obstante, el propio eXeLearning incluye herramientas para editar este tipo de valores sin ver una sola línea de código. |
Un docente añade en el editor HTML de eXeLearning: <p style=»color:#333;»>Texto de introducción</p>. Cualquier colega puede identificar que ese código cambia el color del texto y modificarlo. |
⬤ AMARILLO — Riesgo moderado: vigilar antes de publicar
| Criterio | Por qué importa | Ejemplo práctico |
| Widgets externos vía iframe | Al incrustar contenido de Genially, Canva, LearningApps o similares, el REA depende de que esa plataforma siga existiendo, mantenga la misma URL y no cambie sus condiciones de uso. Si el servicio cierra o modifica su política, el iframe queda vacío. El docente no tiene control sobre ese contenido.
La recomendación es usar esto solo para vídeos y similares, no para actividades que se pueden generar con iDevices de eXe |
Un REA de geografía incrusta un mapa interactivo de Genially. Tres años después, Genially cambia a un modelo de pago y elimina las presentaciones gratuitas. El REA muestra un recuadro en blanco y el docente no puede recuperar el contenido porque no tiene el archivo original. |
| JavaScript generado por IA | El código JavaScript generado por IA sin comentarios funciona como una caja negra: si falla o necesita adaptarse, resulta difícil entenderlo y corregirlo. En cambio, cuando incluye comentarios explicativos en lenguaje natural, otros docentes pueden comprender, modificar y mantener el recurso con mayor facilidad | Por ejemplo, un juego de vocabulario generado por IA puede dejar de funcionar tras una actualización del navegador; sin documentación, localizar el problema es complicado. Si el código está comentado, su mantenimiento y adaptación resultan mucho más sencillos… |
| Efectos puramente decorativos | Animaciones de entrada, cursores personalizados, nieve animada o fondos con partículas no aportan valor pedagógico pero aumentan el peso del archivo, ralentizan la carga en conexiones lentas y pueden interferir con lectores de pantalla o tecnologías de asistencia.
Prestar especial atención a como esos efectos pueden afectar a la accesibilidad. |
Un REA sobre el ciclo del agua incluye un script de «lluvia animada» que añade 200 KB de código. En un aula con conexión 3G, el recurso tarda 12 segundos en cargar. Un alumno con daltonismo no puede distinguir las gotas animadas del texto del contenido. |
⬤ ROJO — Código peligroso o cerrado: no publicar
| Criterio | Por qué importa | Ejemplo práctico |
| Código ofuscado o minificado | La ofuscación consiste en transformar el código de forma que sea ilegible para humanos, pero ejecutable por la máquina. Es la técnica más habitual para ocultar código malicioso. Un script legítimo no tiene razón para estar ofuscado. Si ves una línea de 2.000 caracteres sin espacios ni palabras reconocibles, es una señal de alerta máxima. | Un REA descargado de un repositorio incluye este fragmento: var _0x3f2a=[«\x63\x6F\x6F\x6B\x69\x65″…]. Ese código, en realidad, lee las cookies del navegador del alumno y las envía a un servidor externo. Sin desofuscarlo (proceso que requiere herramientas especializadas), es imposible saber qué hace. |
| Llamadas a servidores externos no identificados | Cualquier instrucción como fetch(‘https://api.desconocida.com/datos’) o XMLHttpRequest que apunte a un dominio que no sea el propio repositorio o una fuente reconocida debe ser investigada. Puede estar enviando los resultados del alumno, su dirección IP, su nombre de usuario en Moodle o cualquier otro dato sin su consentimiento. | Un REA de matemáticas incluye un cuestionario final. Al completarlo, un script envía las respuestas a «https://stats-track.net/collect». El docente pensaba que era un contador de uso. En realidad, ese dominio recopila datos de alumnos menores de edad sin el consentimiento requerido por el RGPD. |
| Permisos sospechosos sin justificación | JavaScript ejecutado en un navegador puede solicitar acceso a la cámara, el micrófono, la ubicación geográfica o el portapapeles. En un REA, estos permisos solo se justifican en casos muy concretos y documentados. Su presencia sin explicación pedagógica clara es un indicador de código potencialmente malicioso. | Un REA de idiomas solicita al alumno activar el micrófono «para practicar pronunciación». El script de grabación, sin embargo, no procesa el audio localmente: lo envía a un servidor de terceros. El alumno y el docente creen que es una función de reconocimiento de voz, pero sus conversaciones quedan almacenadas externamente. |
| Bloques masivos de código no comprendido | Cuando el propio autor del REA no puede explicar qué hace el código que ha insertado, ese recurso ha dejado de ser abierto y se ha convertido en un riesgo potencial. La IA puede generar código con «alucinaciones»: referencias a funciones o librerías que no existen, que han sido suplantadas por copias maliciosas, o que tienen efectos secundarios no documentados. | Un docente pide a una IA generar un «sistema de seguimiento del progreso del alumno». El resultado son 400 líneas de código que el docente no revisa. Una de esas líneas importa una librería de npm cuyo nombre es casi idéntico a una librería legítima (typosquatting). La librería falsa contiene un minero de criptomonedas que se ejecuta en el navegador de cada alumno que abre el recurso. |
A modo de resumen podemos ver lo anterior en la siguiente infografía:
Cómo detectar código peligroso sin saber programar
No es necesario ser programador para identificar señales de alerta. Estas cuatro preguntas pueden hacerse ante cualquier fragmento de código antes de incluirlo en un REA:
- ¿Puedo leerlo? Un código legítimo tiene palabras reconocibles en inglés (function, if, return, document), espacios entre instrucciones y líneas de longitud razonable. Si ves una línea de más de 200 caracteres sin espacios, con letras y números mezclados al azar, es código ofuscado.
- ¿Hace referencia a URLs externas? Busca en el código las palabras http, fetch, XMLHttpRequest o src=. Si aparecen seguidas de una dirección web que no reconoces, investiga ese dominio antes de publicar.
- ¿Pide permisos? Palabras como getUserMedia, geolocation, clipboard o camera en el código indican que el script solicita acceso a hardware o datos del dispositivo. Solo son aceptables si el recurso lo justifica explícitamente con una finalidad pedagógica clara.
- ¿El propio autor puede explicarlo? Antes de publicar un REA con código externo, el autor debería ser capaz de resumir en dos frases qué hace ese código. Si no puede, aún no está listo para publicarse.
Regla de oro: si no puedes explicar en dos frases qué hace el código que acabas de pegar, tu recurso aún no está listo para publicarse. La incapacidad de explicarlo es exactamente lo que cierra el recurso y lo que puede hacerlo peligroso.
Soluciones para equilibrar la balanza
El problema no es la IA. El problema es el desplazamiento de la responsabilidad. A continuación, cuatro propuestas concretas:
| Propuesta | En qué consiste |
| Documentación obligatoria del código IA | Incluir en el REA un iDevice que solamente sea visible en modo edición, que explique qué hace cada script, qué prompt se usó para generarlo y cómo puede modificarlo otro docente en lenguaje no técnico. |
| Código limpio y estándar | Fomentar el uso de las herramientas nativas de eXeLearning. Si no son suficientes, usar librerías de código abierto conocidas y contrastadas, nunca fragmentos opacos generados al azar. |
| Auditoría comunitaria y técnica | Los repositorios de REA deberían añadir una capa de revisión técnica de scripts, además de la evaluación pedagógica (norma UNE 71362). Una revisión automática básica podría detectar llamadas sospechosas. |
| Principio de simplicidad adaptable | Un buen REA es «hackeable»: preferir siempre lo funcional y sencillo sobre lo complejo y cerrado. El criterio de calidad no es la espectacularidad, sino la reutilizabilidad. |
¿Qué docente queremos ser?
No permitamos que la fascinación por lo que la IA puede programar nos haga olvidar lo que solo un docente puede diseñar: una experiencia de aprendizaje humana, segura y, sobre todo, compartida.
La «A» de Abierto es una «A» de generosidad. Y no hay generosidad si entregamos algo que nadie más puede tocar, comprender ni mejorar. Los recursos educativos abiertos son, en su mejor versión, un acto de confianza entre colegas. Cuidemos esa confianza también cuando usamos inteligencia artificial para crearlos.