Alguien conectó un modelo en una tarde
El modelo funciona e impresiona en la demostración, pero no encuentro ningún registro de la información que sale de la organización ni de la base jurídica que ampara esa salida.
Moodle · Inteligencia artificial
Inteligencia artificial en Moodle: contexto, permisos y evaluación
Moodle dispone de un subsistema de inteligencia artificial. Lo uso para conectar proveedores de modelos mediante extensiones —servicios comerciales o modelos gestionados por la propia organización— y habilitar acciones en puntos concretos de la plataforma. Con una extensión compatible, completo con rapidez la conexión técnica inicial. Antes de ponerla en servicio, reviso el contrato, los datos, los permisos y la evaluación. En los casos más avanzados —como un asistente que responde sobre documentación propia, el apoyo a la corrección o un modelo predictivo— defino una arquitectura y un gobierno propios. Antes de habilitar esas funciones, decido qué información pueden consultar, qué datos personales salen hacia un tercero, cómo compruebo lo que devuelven, quién actúa cuando se equivocan y si el uso justifica los costes de supervisión y mantenimiento.
- El subsistema organiza la IA en ubicaciones dentro de la plataforma y acciones concretas, con proveedores que se añaden como extensiones.
- Activar el subsistema no incorpora por sí solo un asistente sobre documentación propia ni apoyo a la corrección: cada caso necesita su proveedor, su punto de integración y, a menudo, desarrollo.
- La detección de riesgo de abandono pertenece al subsistema de analítica, no al generativo, y exige datos históricos, entrenamiento y configuración.
- Decido antes qué sale hacia un tercero. Descubrirlo después leyendo un registro llega tarde.
Experiencia en inteligencia artificial
Delimito el caso de uso, el subsistema, el proveedor, las fuentes autorizadas y los datos que salen de Moodle. Fijo permisos, ubicación del procesamiento, evaluación, supervisión humana y apagado para detectar respuestas plausibles pero falsas y evitar envíos de datos personales sin una decisión expresa.
Mi trayectoriaCuándo abordo la inteligencia artificial en Moodle
Clasifico casi todas las iniciativas de inteligencia artificial en cuatro puertas de entrada. Cada una exige revisar un riesgo y una evidencia distintos.
Dirección pide «tener IA»
Dirección lo pide sin un problema concreto detrás. No veo un riesgo técnico, sino el de construir algo que nadie use y mantenerlo durante años.
El profesorado quiere ayuda con la corrección
La IA puede aportar valor cuando el volumen y el proceso actual lo justifican, pero mido el retorno con dos referencias: el tiempo empleado antes y el coste de supervisión. Separo qué parte propone la máquina y qué parte firma una persona.
Protección de datos pregunta qué se envía
La pregunta llega tarde, pero está justificada. Necesito saber qué contexto incluyo en cada petición para responderla. Diseño ese contexto antes de conectar nada.
Cómo decidir
Planteo seis preguntas. Si no respondo con claridad a la primera, las demás sobran.
- 01
¿Qué trabajo concreto reduce y para quién?
Pido nombre, tarea y frecuencia. Si la respuesta es «mejorar la experiencia» o «no quedarnos atrás», la considero una intención, no un caso de uso.
- 02
¿Qué datos personales van en cada petición?
Enumero los datos uno a uno. Con la respuesta «lo que haya en el contexto» no puedo responder sobre protección de datos ni valorar el riesgo.
- 03
¿Qué fuentes puede utilizar el modelo para responder?
Delimito el contenido autorizado. Si no lo hago, el modelo responde con lo que sea y no puedo distinguir un acierto de una invención plausible.
- 04
¿Cómo evalúo su precisión y su utilidad?
Evalúo la precisión y la utilidad con un conjunto de casos con respuesta conocida y una medida repetible. Sin esas dos cosas, solo me queda la impresión de quien la probó el primer día.
- 05
¿Quién revisa la salida y quién responde si contiene un error?
Defino quién supervisa toda salida que influya de forma relevante en una decisión sobre una persona, con qué autoridad interviene y qué queda registrado. Ajusto la intensidad de la revisión al riesgo, la autonomía, la reversibilidad y el contexto. En los casos que lo exigen, exijo que una persona identificada confirme la decisión y responda de ella.
- 06
¿Qué pasa si el proveedor falla o sube el precio?
Decido de antemano si acepto que la función deje de existir cuando el proveedor falle o suba el precio, o si preparo una alternativa.
Cómo diseño la puesta en servicio
Tomo seis decisiones en este orden: con las cuatro primeras delimito el caso y con las dos últimas preparo su funcionamiento.
- 01
Distingo qué subsistema resuelve el caso
Distingo dos subsistemas de la plataforma que a menudo se confunden. El de IA conecta proveedores de modelos y habilita acciones generativas en puntos concretos de la interfaz. El de analítica incorpora modelos predictivos —entre ellos, el de riesgo de abandono— entrenados con los datos históricos del propio sitio. No doy por terminada una capacidad con solo activar uno u otro. Los casos avanzados, como un asistente que responde sobre documentación propia o el apoyo a la corrección, requieren un proveedor, un punto de integración y, con frecuencia, desarrollo.
- 02
Elijo el caso de uso y compruebo que merece la pena
Identifico qué trabajo concreto reduce el caso, para quién y en qué medida. Un caso que ahorra diez minutos a dos personas al mes difícilmente justifica una dependencia nueva, porque una función poco utilizada también añade costes de supervisión y mantenimiento. Con esta pregunta descarto la mayoría de las ideas; además, es la que menos cuesta responder.
- 03
Elijo el proveedor y decido dónde ejecutar el procesamiento
Integro proveedores en el subsistema mediante extensiones: servicios comerciales o modelos alojados por la organización. Valoro la calidad y el coste, pero también si los datos salen de la organización, a qué país y bajo qué condiciones.
- 04
Delimito las fuentes y lo que envío
Delimito qué contenido consulta el modelo para responder y qué envío en cada petición. Recorto lo que sale hacia el tercero: envío solo el fragmento pertinente en lugar del expediente completo y anonimizo antes lo que no hace falta identificar.
- 05
Fijo los permisos y la ubicación
Decido en qué puntos de la plataforma aparece cada acción y qué roles pueden usarla. Si extiendo un asistente a todo el mundo y a todos los contextos, me resulta mucho más difícil gobernarlo, evaluarlo y explicarlo.
- 06
Evalúo, observo y controlo su apagado
Preparo un conjunto de casos con su respuesta esperada y aplico la misma medida de acierto cuando cambia el modelo. Registro el coste y la latencia, y añado un interruptor para desactivar la función sin desplegar. Sin este sistema, no detecto cuándo deja de funcionar bien.
Lo que suele salir mal
Siete problemas que he encontrado con la función ya en producción.
Datos personales enviados sin una decisión expresa
Descubro en una auditoría que la función manda más contexto del necesario porque así era más fácil programarla. Para entonces, lleva meses enviándolo.
Respuestas plausibles y falsas
Compruebo que, sin fuentes delimitadas ni evaluación, el sistema produce contenido que suena bien, pero no es correcto. En un contexto educativo, no considero menor ese fallo.
Coste que se dispara
Compruebo que enviar contexto de más multiplica el gasto por consulta. Veo el aumento en la factura cuando la función alcanza el uso previsto, justo cuando retirarla ya tiene consecuencias.
Latencia que arruina la experiencia
Mido con personas y recorridos reales el tiempo de espera aceptable para cada tarea. Si una respuesta supera ese umbral, deja de usarse aunque sea buena. Si la operación es síncrona, compruebo también cómo afecta a la plataforma.
Cambio silencioso de comportamiento
El proveedor actualiza su modelo y las respuestas cambian. Las evalúo periódicamente para detectar la degradación antes de que alguien se queje.
Permisos demasiado amplios
Reviso qué roles pueden usar cada acción. Si la habilito para roles no previstos, aumento el riesgo de consultas o accesos indebidos. Compruebo además que la recuperación, el contexto enviado y cada punto de autorización respeten el alcance de la cuenta.
No puedo desactivar la función con rapidez
Si solo puedo desactivar la función con un despliegue, el incidente dura lo que tarda ese despliegue.
Diez preguntas antes de conectar un modelo
No conecto el modelo mientras falte una respuesta crítica sobre finalidad, datos y licitud, permisos, evaluación, responsabilidad o retirada. Priorizo las demás carencias según el riesgo del caso.
- Puedo decir qué trabajo concreto ahorra y a cuántas personas.
- He descartado explícitamente resolverlo sin un modelo generativo.
- Puedo enumerar qué datos personales van en cada petición.
- Sé dónde se procesan esos datos y bajo qué condiciones.
- El contenido del que puede beber la respuesta está delimitado.
- Existe un conjunto de casos con respuesta esperada para evaluar.
- Sé cuánto cuesta una consulta y cuántas se harán al mes.
- Sé cuánto tarda y qué pasa si el proveedor no responde.
- Está claro quién revisa la salida y quién responde de ella.
- Puedo desactivar la función hoy mismo sin desplegar.
Qué exigir sobre IA en un pliego
Con estas cinco filas descarto la mayoría de los planteamientos de IA.
| Requisito | Evidencia exigible | Criterio de aceptación |
|---|---|---|
| Caso de uso con beneficio medible | Tarea concreta, personas afectadas y forma de medir la mejora | Medición antes y después del despliegue |
| Tratamiento de datos declarado | Qué se envía, a quién, dónde se procesa y con qué base legal | Análisis de protección de datos aceptado por la organización |
| Fuentes autorizadas delimitadas | Corpus con control de versiones, fuentes citables y conjunto de prueba diseñado para provocar fallos, con preguntas que no tienen respuesta | Tasa de respuestas sin respaldo por debajo del umbral acordado, medida sobre ese conjunto y repetida después de cada cambio |
| Evaluación repetible | Conjunto de casos con respuesta esperada y resultados | Tasa de acierto por encima del umbral acordado, medida de nuevo tras cada cambio |
| Supervisión y reversibilidad | Quién revisa, dónde queda registrado y cómo se desactiva | Comprobar la desactivación de la función sin despliegue |
Qué cambia con el uso
Al aumentar el volumen, veo muchos problemas de coste, latencia y operación. Antes de extender el uso, detecto los riesgos de datos, permisos y calidad.
- Pruebo con un grupo pequeño
Antes del piloto preparo la evaluación y la medida de referencia. Durante el uso con un grupo pequeño compruebo la calidad, el coste y la latencia mientras el alcance sigue acotado.
- Extiendo el uso en un curso
Identifico las preguntas que no había previsto y los casos límite. Así compruebo si había delimitado bien las fuentes.
- En toda la plataforma
Trato el coste como una partida presupuestaria y la latencia como un asunto de arquitectura. Mido el número de solicitudes por unidad de tiempo y la concurrencia que admite el servicio. Solo valoro una caché para respuestas reutilizables. En ese caso, la separo por alcance y versión de la fuente, defino su caducidad e invalidación y excluyo los datos personales o sensibles.
- La IA forma parte de un proceso con efectos
Cuando el resultado influye en una calificación o en una decisión sobre una persona, exijo trazabilidad completa, una revisión humana registrada y la capacidad de explicar cada caso.
Los tres atajos más caros
Detecto el mismo rasgo en los tres: tratan la IA como una función que se enciende, no como una capacidad que alguien debe gestionar.
Un asistente genérico en toda la plataforma
Delimito el contenido al que debe atenerse. Sin ese límite, el modelo intenta responder sobre demasiados asuntos y acierta de forma irregular. La solución acaba abandonada, pero el coste y el riesgo permanecen.
Mandar el contenido entero en cada petición
La descarto aunque sea la más fácil de programar: es la peor en coste por consulta, latencia y cantidad de información que sale de la organización.
Dar por bueno lo que devuelve
Comparo las respuestas del modelo con un conjunto de casos de respuesta conocida. Así sé si acierta y detecto si empeora tras un cambio de versión del proveedor.
Referencias
Fuentes y límites
- Documentación oficialSubsistema de IA — documentación oficial de Moodle
Ubicaciones y acciones, proveedores mediante extensiones, compatibilidad con modelos comerciales y abiertos. Consultado el 1 de agosto de 2026.
- Documentación oficialPrincipios de IA de Moodle
Criterios que declara el fabricante para la incorporación de IA. Es una declaración de principios, no una especificación técnica. Consultado el 1 de agosto de 2026.
- Documentación oficialAnalítica del aprendizaje — documentación oficial de Moodle
Subsistema independiente del generativo. Incorpora modelos predictivos, entre ellos el de estudiantes en riesgo de abandono, que deben entrenarse con los datos del propio sitio antes de predecir. Consultado el 1 de agosto de 2026.
- NormativaReglamento europeo de inteligencia artificial
El anexo III incluye determinados usos de IA en educación entre los sistemas de alto riesgo. La clasificación depende de la función concreta y de las condiciones del artículo 6, y debe revisarse jurídicamente en cada caso. Consultado el 3 de agosto de 2026.
Las seis decisiones y el orden en que las planteo son criterio propio, no una metodología publicada. Las capacidades del subsistema cambian entre versiones de la plataforma y hay que comprobarlas en la documentación oficial antes de planificar nada. Sobre obligaciones legales, esta página señala dónde mirar pero no sustituye a un análisis jurídico: la clasificación de un caso de uso concreto tiene que hacerla quien tenga esa competencia.
Blog
Casos, pruebas y fuentes.
En el blog analizo casos de IA en Moodle con su flujo de datos, evaluación, coste y condiciones de retirada.
Ir a blog.albertolarah.comContacto
Antes de incorporar IA a una plataforma
Empiezo por el caso de uso y por a quién ayudaría. Después, qué información necesita consultar el modelo y qué restricciones condicionan dónde se procesan esos datos. Muchas veces la primera pregunta es si ese caso merece la pena.
hola@albertolarah.comLinkedIn ↗