Dirección que quiere saber si hay riesgo
No necesita el detalle técnico: necesita saber qué puede parar el servicio y cuánto costaría evitarlo.
IA y aprendizaje
Diagnóstico de Moodle según el contexto y el perfil
Este diseño plantea un panel que reúne datos verificables de Moodle, adapta la información y las acciones a cada perfil y utiliza IA para explicar los hallazgos.
El problema
Diagnosticar problemas de permisos, inscripciones, restricciones o tareas obliga a recorrer varias pantallas y a recopilar información técnica que no todos los perfiles pueden obtener.
Para priorizar un hallazgo, la herramienta debe conocer primero el contexto de la plataforma.
La misma configuración puede ser aceptable en un campus pequeño y entrañar un riesgo crítico en una plataforma de alcance nacional. El diseño prevé que la herramienta recoja datos sobre la arquitectura, la carga, las extensiones, la operación y los objetivos antes de asignar prioridad a los hallazgos.
Decisión principal
Separar la observación automática del juicio técnico.
Las comprobaciones producen resultados reproducibles a partir de datos verificables. Las recomendaciones relacionan esos resultados con el impacto y la probabilidad de que se materialice el problema, además del coste de corregirlo. Mantener ambas capas evita presentar una regla genérica como diagnóstico definitivo.
Criterios de diseño
- 01
Primero determino qué datos verificables puede consultar cada perfil según su contexto y sus permisos.
- 02
Adapto la información al perfil de quien consulta y muestro los datos y las comprobaciones que justifican cada conclusión.
- 03
Utilizo la IA para explicar y orientar a partir de un diagnóstico determinista.
Límites del producto
El informe remoto indica qué aspectos no ha podido comprobar.
Hay problemas de base de datos, red, almacenamiento o código que no pueden confirmarse desde una aplicación externa. El diseño exige que la herramienta declare la falta de evidencia y proponga la siguiente comprobación, en vez de suplir los datos ausentes con una conclusión.
Capacidades previstas en el diseño
- 01Permisos y roles
- 02Salud de cursos
- 03Inscripciones y restricciones
- 04Tareas y estado del sistema
Criterio de validación
Las recomendaciones necesitan trazabilidad y prioridad.
Cada hallazgo conserva el origen, el criterio, los datos recabados y el alcance. La validación contrasta los resultados con plataformas conocidas y revisa los falsos positivos antes de utilizar el informe para decidir una intervención.
Evidencia descrita para el diagnóstico de Moodle según el contexto y el perfil
- Catorce funciones definidas
- Arquitectura de la extensión documentada
- Matriz preliminar de roles, contexto y acciones documentada
Preguntas abiertas
Decisiones pendientes en el diagnóstico de Moodle según el contexto y el perfil.
Antes de incorporar más diagnósticos, hay que validar y ampliar la matriz: delimitar la información visible para cada perfil, las nuevas acciones seguras, los datos enviados a la IA y la carga añadida a Moodle.
- Ámbito por perfil
- Acciones seguras desde el panel
- Privacidad del contexto enviado a la IA
- Carga sobre la plataforma
Contextos en los que encaja
Quién pregunta qué le pasa a la plataforma
La misma pregunta la plantean cuatro perfiles distintos y cada uno necesita una respuesta diferente.
Responsable de plataforma con incidencias
Necesita la causa concreta y el orden en que atacarla.
Equipo técnico que hereda un sistema
Necesita el mapa: qué hay instalado, qué se tocó y qué se aparta de lo estándar.
Compras que valora una oferta
Necesita comparar dos propuestas sobre algo más que el precio.
Decisiones de arquitectura
Las decisiones que lleva dentro
La fiabilidad de un diagnóstico depende de distinguir lo que se mide de lo que se opina.
- 01
Datos comprobables primero
Configuración, versiones, extensiones, consultas y señales de infraestructura. Cada dato conserva su origen, su fecha y las condiciones de recogida; así puede comprobarse antes de utilizarlo para interpretar el riesgo.
- 02
La misma información, distinta lectura
El diagnóstico se adapta al perfil que pregunta sin cambiar los datos. Escribir un informe único obliga a todos a leer lo que no les sirve.
- 03
Nada de conclusiones sin evidencia
Cada afirmación enlaza al dato que la respalda. Una recomendación sin respaldo es una opinión con formato de informe.
- 04
Ordenar por consecuencia, no por facilidad
Lo que expone datos o puede parar el servicio va primero, aunque cueste más arreglarlo.
A escala
Qué cambia con el tamaño de la plataforma
- Una instalación pequeña
Una revisión manual con criterio puede ofrecer mejor relación entre esfuerzo y resultado que automatizar un diagnóstico completo; la elección depende del alcance, de la repetición y del coste del error.
- Plataforma con historia
La automatización puede recorrer de forma sistemática inventarios y señales para localizar extensiones abandonadas, configuraciones heredadas o consultas caras; la lectura experta determina qué implican en ese contexto.
- Varias plataformas
Comparar entre ellas revela lo que ninguna revisión aislada muestra: qué se aparta del estándar y dónde.
Decisiones de diseño documentadas
Hechos verificables antes de las explicaciones generadas
Este diseño separa las observaciones, las recomendaciones y los límites del análisis para que cada prioridad pueda rastrearse hasta los datos disponibles.
- 01Arquitectura de IA
- 02Evaluación y observabilidad
- 03Supervisión humana
- 04Datos de Moodle según el contexto y el perfil
Contexto profesional