Riesgos

Riesgo: si se pierden los volúmenes de la base de datos y de archivos, se pierde toda la información (usuarios, avances, notas, certificados), aunque el código esté en el repositorio. Mientras los respaldos se guarden solo en el mismo servidor, una falla del servidor o del nodo Proxmox los destruye junto con los datos.

Mitigación existente: respaldo diario activo en producción con verificación, 14 días de retención local, restauración probada (unos 13 minutos desde cero en local) y aviso al super administrador si no hay respaldo, si falló, si tiene más de un día o si no hay copia externa.

Pendiente: configurar la copia externa cifrada, el snapshot de Proxmox y repetir la prueba con un respaldo real de producción. Fuente: docs/drp.md.

Riesgo: los documentos de planificación registran un antecedente de intrusión en el servidor y diseñan el respaldo bajo el supuesto de que podría repetirse. Un atacante con control del servidor podría borrar o leer los respaldos que estén a su alcance.

Mitigación prevista en el plan: copia externa que el servidor no pueda borrar, cifrada para que el servidor no pueda leerla; perímetro en tres capas (Cloudflare, Traefik y firewall); verificación en dos pasos; actualizaciones automáticas de seguridad.

Mitigación existente: verificación en dos pasos para super administradores, bloqueo de cuentas por intentos fallidos, secretos fuera del código (las contraseñas de ejemplo que estuvieron publicadas ya no están en el código, pero siguen en el historial de Git y deben considerarse comprometidas), cabeceras sin caché del navegador, límite de intentos por IP en la recuperación de contraseña y en los registros públicos. El endurecimiento del servidor depende de TI y su estado está por confirmar. Fuente: docs/roadmap_v3.md, docs/roadmap_v4.md §9.

Riesgo: el plan v4 registra que hay un único desarrollador (probabilidad alta, impacto alto). Si no está disponible, nadie conoce a fondo la plataforma.

Mitigación: documentación de entrega, manual de recuperación, configuración como código (la plataforma se reconstruye desde el repositorio), pantallas propias para que Talento Humano opere sin TI y código propio concentrado en pocos complementos. Ver Desarrollo y Operación.

Riesgo: la plataforma guarda nombres, cédulas, correos y notas de colaboradores, postulantes y empleados de clientes. Los respaldos contienen esos datos. El plan señala tres puntos sensibles: la demora en obtener el texto legal (probabilidad alta, impacto alto), la conservación de datos de postulantes no contratados (probabilidad media, impacto alto) y la transferencia internacional al proveedor de IA (Groq procesa en Estados Unidos y su nivel de desarrollo no ofrece acuerdo de tratamiento de datos).

Mitigación existente: aceptación obligatoria del Aviso de Tratamiento de Datos Personales con versión y fecha; condiciones de uso del asistente de IA que la persona acepta antes de usarlo; las acciones del agente se ejecutan dentro de Moodle con los permisos de quien las pide; en el agente de acciones, las cédulas, los RUC y los correos se reemplazan por marcadores antes de enviarse al proveedor de IA (los nombres sí se envían); proveedores de privacidad completos en los complementos propios, de modo que las solicitudes de acceso y eliminación de datos se atienden con la herramienta de privacidad de Moodle; el código ya no contiene cédulas del personal; los postulantes no ven el chat de IA; la copia externa prevista va cifrada.

Pendiente: aprobación legal escrita de qué datos pueden salir hacia el proveedor de IA (incluidos los nombres y los mensajes del chat general), cláusula de transferencia internacional y plazo de conservación de datos de postulantes (hoy se eliminan a mano). El historial de Git todavía conserva las cédulas que estuvieron en el código: limpiarlo es decisión del desarrollador principal (ver Estado y pendientes). Fuente: docs/roadmap_v4.md §6.3.2 y §F6, docs/roadmap_v4_gaps.md G-2.

Riesgo: el chat depende de un servicio externo. El primer proveedor (Gemini) dio errores intermitentes por alta demanda y hubo que cambiarlo. Un cambio de condiciones, de precio o una caída del proveedor afecta al chat.

Mitigación: el proveedor se configura en local_ai_manager mediante un conector compatible con OpenAI, lo que permite cambiarlo sin modificar el código; el agente reintenta ante errores transitorios; la plataforma funciona sin el chat (todas las acciones del agente existen también en pantallas propias); el Asistente se puede desactivar desde Configuración IA. La planificación prevé, además, que con Dify el modelo se cambie por interfaz gráfica.

Riesgo: Dify levanta unos 8 a 10 contenedores. Con Moodle, MariaDB y eventualmente un modelo local en el mismo servidor, la memoria puede no alcanzar (probabilidad media, impacto alto, según el plan v2).

Mitigación: medir el consumo antes de desplegar; en producción usar modelos externos en lugar de un modelo local; los contenedores actuales tienen límites de memoria definidos (base de datos 2 GB, sitio 3 GB, cron 1 GB). Fuente: docs/roadmap.md §9, docs/roadmap_v2.md §13, docker-compose.yml.

Riesgo: los videos viven en YouTube. Si se borran, se vuelven privados o no permiten insertarse, el alumno nunca llega al final y no puede completar el módulo. La revisión del 26 de agosto de 2026 encontró 6 de 128 videos no disponibles.

Mitigación: Módulos → Revisar los módulos detecta videos que YouTube ya no deja ver y otros bloqueos; los videos caídos se pueden alojar en Cloudflare R2 y cambiar el enlace. Fuente: README.md, classes/health.php.

Riesgo: preguntas u objetivos propuestos por la IA con errores del dominio contable o tributario (probabilidad alta, impacto alto, según el plan).

Mitigación: la IA es opcional al crear un módulo desde un documento, propone a partir del texto del tema y todo módulo nace como borrador hasta que Talento Humano lo revisa y lo publica.

Riesgo: la plataforma aplica parches propios sobre complementos de terceros (chat de IA, video interactivo, certificados). Una actualización de esos complementos podría deshacerlos. Además, local_ai_manager y block_ai_chat están en su última versión compatible con Moodle 4.5; la siguiente exige Moodle 5.0.

Mitigación: todos los complementos están fijados a un commit o una versión exacta; la construcción falla si un parche importante no se aplicó (verify-patches.php); la política de actualizaciones del plan exige aprobación de TI y prueba previa para todo lo que no sea un parche de seguridad. El paso a la siguiente LTS está previsto para 2027.

Riesgo: Groq, Cloudflare (incluido R2) y el destino de la copia externa necesitan un responsable de pago. El plan advierte que el control del respaldo vigila que el respaldo corra, no que la factura esté pagada; una tarjeta vencida puede detener un servicio sin aviso.

Mitigación pendiente: definir el responsable de cada servicio, qué pasa al vencer un medio de pago y quién recibe las alertas de renovación (Gerencia). Fuente: docs/roadmap_v4_gaps.md G-6.

Riesgo: Office 365 puede rechazar el envío si la cuenta no tiene habilitado el SMTP autenticado, si la clave se altera al cargarla o por acceso condicional; acepta unos 30 correos por minuto. Si dos instalaciones (por ejemplo, una prueba de recuperación) tienen el correo configurado, los correos en cola pueden salir dos veces a personas reales.

Mitigación: cola con límite y reintentos; Diagnosticar la conexión indica qué falla y quién lo corrige; las copias de prueba deben ir sin correo o con desvío (MOODLE_MAIL_DIVERT_TO); en una mudanza se pausa el correo en el servidor viejo. Sin correo, la contraseña se recupera con la cédula. Fuente: docs/drp.md §4.1.

Riesgo: el 6 de octubre de 2026 el reloj del servidor estaba unos 16 minutos adelantado y sin sincronizar. Afecta a los códigos de verificación en dos pasos de los administradores y a la fecha de los registros.

Mitigación pendiente: activar la sincronización NTP en el nodo Proxmox (TI). Fuente: docs/drp.md.

Riesgo: que alguien rinda un repaso sin ver el video, use intentos ilimitados o consulte otras fuentes durante el examen.

Mitigación: candado real de cuestionarios para todos los perfiles (salvo el super administrador), nadie previsualiza (todos los intentos cuentan), preguntas aleatorias y secuenciales sin mostrar respuestas, y control de cambio de pantalla contado en el servidor. Límite: la protección contra descargas y el control de pantalla funcionan en el navegador y no impiden, por ejemplo, fotografiar la pantalla.

Riesgo: que el único administrador olvide su contraseña o pierda la aplicación de verificación en dos pasos.

Mitigación: dos super administradores que se restablecen mutuamente; la cuenta de respaldo se crea con una contraseña tomada de una variable de entorno y cambio obligatorio al primer ingreso; si se pierde la verificación en dos pasos en ambas cuentas, TI puede desactivarla desde la consola del contenedor. Ver Operación.

Riesgo: según el DRP, la cuenta de Cloudflare R2 que hoy aloja videos es personal. Si esa persona deja la empresa, el acceso a esos videos y a su facturación queda fuera del control de Deltamontero.

Mitigación pendiente: migrar a una cuenta de la empresa antes de usar R2 también para la copia externa (Gerencia).