¿Está tu LMS preparado para agentes? Ocho pruebas de arquitectura

Tesis Una plataforma está preparada para agentes cuando puede demostrar, acción por acción, quién delega, qué información está autorizada, qué puede cambiar el sistema, cómo se limita el daño y qué evidencia queda para reconstruir el resultado.

Imaginemos una petición verosímil: «Localiza al alumnado que puede quedarse atrás esta semana y actúa». Un asistente podría limitarse a explicar qué señales ha encontrado. Un copiloto podría preparar mensajes para que una tutora los revise. Un agente también podría enviarlos, reasignar fechas, crear grupos o modificar una actividad.

La frase es la misma, pero cada interpretación tiene consecuencias distintas. Enviar un recordatorio al grupo equivocado expone información. Ampliar un plazo para unas personas y no para otras altera las condiciones de evaluación. Modificar una calificación convierte un error técnico en una decisión académica. El problema de arquitectura empieza justo donde termina la demostración del chat: en la posibilidad de actuar sobre el sistema real.

La etiqueta inglesa agent-ready se utiliza para decir que un producto está «preparado para agentes». Conviene hacerla verificable. Tener una API, conectar un servidor MCP o añadir un modelo capaz de invocar herramientas son condiciones posibles; ninguna acredita por sí sola que la plataforma sea operable con seguridad. Esa preparación debe demostrarse sobre capacidades concretas, para un rol, un ámbito y una consecuencia definidos.

Una plataforma no se prepara para agentes con un chat

Un agente de IA es un sistema que utiliza un modelo para decidir qué pasos y herramientas necesita para alcanzar un objetivo dentro de unos límites. Un flujo automatizado sigue una secuencia fijada de antemano. Una herramienta es una operación discreta que el agente puede invocar mediante un contrato de entrada y salida: consultar entregas, preparar retroalimentación, crear un borrador o matricular a una persona.

La distinción importa porque el modelo introduce variabilidad en la elección de los pasos, los argumentos y el momento de la llamada. El resultado ya no depende solo del código de la operación. Depende también de la interpretación de una intención, de los datos e instrucciones suministrados y de las decisiones tomadas durante la ejecución.

Las orientaciones publicadas por la Agencia Española de Protección de Datos tratan la IA agéntica como un cambio relevante precisamente porque estos sistemas interactúan con entornos y ejecutan acciones para alcanzar objetivos. NIST ha abierto una iniciativa específica sobre estándares para agentes en la que identidad, autorización, seguridad e interoperabilidad ocupan un lugar central. No estamos ante otro modo de presentar un chatbot. Aparece una nueva frontera de control entre el razonamiento probabilístico y el estado institucional.

En un LMS —sistema de gestión del aprendizaje— esa frontera no se limita a proteger registros técnicos. Detrás hay matrículas, trabajos, adaptaciones, mensajes, calificaciones, certificados y decisiones que afectan a personas. Una arquitectura sensata parte de la consecuencia educativa, no de todo lo que el modelo es capaz de hacer.

AI-first y agent-ready responden a preguntas distintas

AI-first suele describir un producto organizado alrededor de la inteligencia artificial. Puede ser una interfaz que entiende objetivos, propone un itinerario o genera materiales. Agent-ready se refiere, en cambio, a la calidad de la interfaz mediante la que un agente consulta o modifica el sistema.

Un producto puede resolver muy bien la tarea y funcionar internamente con credenciales compartidas, llamadas demasiado amplias o integraciones sin traza. También puede ocurrir lo contrario: una plataforma con APIs sólidas, permisos finos y operaciones idempotentes —repetir la misma petición no duplica su efecto—, aunque su interfaz siga siendo convencional.

Por eso no usaría agent-ready como el último peldaño de una escala comercial. Una plataforma no «alcanza el nivel cuatro» y queda preparada para cualquier agente. Puede estar lista para consultar el progreso de un curso y no estarlo para enviar mensajes. Puede permitir borradores de retroalimentación y prohibir que un modelo publique una calificación. La madurez se expresa como un mapa de acciones permitidas y evidencias disponibles.

Cuatro grados de acción, no cuatro niveles de prestigio

La autonomía útil depende del daño que puede causar un error y de lo fácil que sea corregirlo. Esta clasificación obliga a fijar ambos aspectos antes de elegir la orquestación.

La cuarta fila no es la meta. Con frecuencia será el límite. Un equipo no demuestra madurez porque permita a un agente hacer más cosas, sino porque sabe qué cosas no debe delegar y puede defender esa decisión. El artículo sobre IA de alto riesgo en plataformas de aprendizaje desarrolla el análisis cuando la función interviene en decisiones sensibles.

Regla de diseño La autonomía se concede a una acción delimitada, no a un agente en abstracto. Cuanto mayor sea la consecuencia y menor la posibilidad de recuperación, más estrechos deben ser el mandato y el control humano.

Ocho pruebas para declarar una función preparada

Las siguientes pruebas se aplican a una acción concreta. Declarar que todo el LMS está preparado para agentes es demasiado amplio. En cambio, sí se puede diseñar, probar y aceptar una función que prepara un borrador de aviso para que lo revise la persona tutora, usa la actividad de su grupo durante los últimos siete días y tiene prohibido enviarlo.

1. La finalidad cabe en una frase comprobable

La función declara quién obtiene qué resultado y dónde termina. «Ayudar al profesorado» no sirve como finalidad operativa. «Preparar un borrador de retroalimentación sobre esta entrega para la docente responsable» sí delimita persona, objeto, salida y responsable.

El contrato debe incluir las acciones prohibidas. En el ejemplo anterior, el agente no publica, no cambia la calificación, no consulta otras asignaturas y no reutiliza el trabajo para entrenar otro sistema. Los límites forman parte de la función; no son una advertencia añadida al prompt.

Evidencia de paso: una ficha con objetivo, rol solicitante, población, estado que puede cambiar, estado que nunca puede cambiar y condición de éxito.

2. La identidad viaja como una delegación limitada

Un agente no debería convertirse en un superusuario técnico que actúa en nombre de cualquiera. Cada llamada necesita una delegación: organización, usuario, rol, curso o grupo, finalidad, operaciones autorizadas y caducidad. El sistema de destino vuelve a comprobarla; no confía en que el orquestador ya lo hizo.

Las credenciales compartidas impiden atribuir cada acción y aumentan el radio de impacto. También son insuficientes los permisos heredados de una interfaz si la nueva herramienta agrupa en una sola llamada operaciones que antes exigían varios pasos. La autorización se evalúa sobre el efecto real de la herramienta.

Evidencia de paso: pruebas positivas y negativas para dos organizaciones, dos cursos y varios roles, que incluyan una delegación caducada, un cambio de grupo y un intento de acceso cruzado.

3. La información se autoriza antes de recuperarse

Un buscador semántico puede encontrar el fragmento más parecido y aun así entregar el fragmento equivocado para esa persona y finalidad. La plataforma resuelve primero el universo permitido y después ordena por relevancia. Filtrar al final llega tarde si un documento ajeno ya entró en la clasificación de resultados, la caché, el resumen intermedio o la traza.

La capa descrita en Context Engineering en EdTech debe entregar un paquete con procedencia, vigencia, política y restricciones, no una masa de texto. Para un tutor, el estado de aprendizaje tampoco equivale al expediente completo. La plataforma entrega lo mínimo necesario para esa intervención.

Evidencia de paso: una prueba de aislamiento, otra de revocación y la posibilidad de explicar por qué cada elemento entró en la ejecución.

4. Cada herramienta expresa una acción de dominio

Una API técnica puede exponer update_record y seguir siendo una herramienta inadecuada para un agente. El nombre no explica qué cambia; el esquema admite combinaciones ilegales y la política tiene que reconstruir el significado a partir de campos genéricos.

Las herramientas deben hablar el lenguaje del aprendizaje: crear_borrador_de_retroalimentacion, consultar_entregas_pendientes o proponer_ampliacion_de_plazo. Una operación acotada es más fácil de autorizar, observar y evaluar que «actualizar actividad». El contrato especifica tipos, campos obligatorios, valores permitidos, versión, errores de dominio, efectos secundarios, límite de lote y resultado devuelto.

También conviene separar las consultas de las mutaciones. Si una herramienta busca, interpreta, modifica y notifica en la misma llamada, no existe un punto claro para revisar la intención ni recuperar un fallo parcial.

Evidencia de paso: esquema validado, ejemplos válidos e inválidos, contrato de errores, límite de volumen y prueba de que los parámetros no autorizados se rechazan en el servidor.

5. La confirmación, los reintentos y la reversión se diseñan de antemano

La aprobación humana pierde utilidad cuando el cuadro de confirmación dice «¿Continuar?» y oculta el efecto. Debe mostrar quién solicita, sobre qué personas, qué valores cambiarán, qué mensajes se enviarán y qué no podrá deshacerse. La persona confirma una operación comprensible, no un resumen persuasivo generado por el mismo modelo.

Las operaciones recuperables necesitan una clave de idempotencia, control de concurrencia y compensación probada. Si la red corta la respuesta después de crear un grupo, reintentar no debe crear otro. Si tres de veinte mensajes fallan, la traza distingue enviados, rechazados y pendientes. «Deshacer» debe tener significado de dominio; borrar el registro de auditoría no revierte el efecto.

Evidencia de paso: ensayo de doble envío, fallo a mitad de lote, cambio concurrente y recuperación dentro del plazo acordado.

6. Cada decisión educativa necesita responsables identificados

Una recomendación puede ser técnicamente correcta y pedagógicamente inapropiada. Una actividad escasa no demuestra riesgo de abandono. Una entrega breve no prueba falta de comprensión. El sistema debe distinguir los datos, las inferencias, las recomendaciones y las decisiones.

La ficha de la función asigna quién revisa el contenido, quién responde por la regla y quién atiende una impugnación. También indica qué situaciones deben derivarse a una persona responsable: adaptaciones, menores, decisiones de evaluación, indicios relacionados con el bienestar o cualquier caso para el que la información disponible sea insuficiente. El artículo dedicado a los tutores de IA desarrolla por qué una conversación convincente no equivale a una intervención educativa válida.

Evidencia de paso: una matriz de responsabilidad, una ruta de derivación, un modo de expresar la incertidumbre y casos donde la respuesta correcta sea abstenerse.

7. La observabilidad permite reconstruir y evaluar

Registrar la respuesta final es insuficiente. Para investigar una ejecución hacen falta la identidad delegada, la finalidad, la versión de la política, las referencias de las fuentes, las herramientas solicitadas, los argumentos aceptados o rechazados, la aprobación, el resultado, la latencia y el coste. Los datos sensibles no tienen que copiarse sin límite: pueden conservarse identificadores, resúmenes controlados y huellas que permitan localizar la evidencia bajo una política de retención.

La evaluación tampoco se reduce a comprobar si el texto «parece bueno». Se comprueban la selección de la herramienta, la exactitud de los argumentos, el respeto de los ámbitos, la abstención, la resistencia a instrucciones incrustadas en documentos, el uso de fuentes vigentes y el resultado real de la acción. Las pruebas incluyen casos normales, casos límite y ataques.

Evidencia de paso: conjunto versionado de casos, umbrales por métrica, reproducción de una ejecución y alerta cuando cambia el comportamiento tras actualizar el modelo, el prompt, la herramienta o la política.

8. La operación sobrevive al proveedor y al incidente

Una operación preparada tiene un responsable del servicio, objetivos de disponibilidad, límites de uso, presupuesto, cola de reintentos, interruptor de emergencia y procedimiento de incidente. El agente debe degradarse de forma segura: si falta una fuente o una política, la operación se detiene o se degrada a un modo de consulta o preparación que ya haya sido evaluado; no rellena el hueco con suposiciones.

El contrato de dominio no debe depender de la sintaxis de un proveedor de modelos. Cambiar el modelo, el orquestador o el protocolo no puede obligar a redefinir quién puede ampliar un plazo. Para demostrar la sustituibilidad, una muestra crítica debe ejecutarse con la alternativa y comparar decisiones, errores, coste y trazas.

Evidencia de paso: un simulacro de caída, un límite de gasto, la desconexión inmediata de una herramienta y la ejecución de la batería crítica con un proveedor alternativo.

La arquitectura necesita una compuerta de acciones

Las ocho pruebas se entienden mejor como una frontera explícita. El agente no se conecta directamente a la base de datos ni hereda todas las funciones de la API. Solicita una operación a una compuerta que comprueba la delegación y la idempotencia, aplica la política, evalúa el riesgo y decide si hace falta una confirmación. Solo después se invoca la herramienta de dominio. Los datos autorizados y las trazas acompañan la decisión sin mezclarse con el estado académico.

Abrir la imagen a tamaño completo

La separación distribuye responsabilidades:

Esta arquitectura no exige microservicios. Puede implementarse dentro de un monolito modular si las fronteras y contratos son reales. La preparación para agentes depende de las propiedades de la operación, no del diagrama de despliegue.

MCP conecta capacidades; no concede confianza

Model Context Protocol (MCP), el protocolo para conectar modelos con recursos y herramientas, aporta una forma común de descubrir y usar esas capacidades. Para las herramientas, exige describir la entrada mediante un esquema y puede reducir las integraciones hechas a medida. El protocolo incorpora negociación de capacidades y requisitos de seguridad que conviene respetar.

Aun así, un servidor MCP no sabe por sí solo qué docente puede ver un grupo, qué adaptación puede modificar, qué fuente contiene la solución de una prueba o qué acción necesita aprobación. Tampoco convierte una herramienta amplia en una herramienta segura. La autorización del protocolo, la política institucional y las reglas de dominio son capas relacionadas, no intercambiables.

Hay tres errores que una integración debe evitar: reenviar credenciales del usuario a servicios que no son su destinatario, aceptar ámbitos genéricos que abren todas las herramientas y confiar en metadatos de una herramienta remota sin fijar el proveedor, la versión y el proceso de revisión. MCP puede aportar una sintaxis común para la conexión, pero el gobierno sigue correspondiendo a la plataforma.

Un solo agente con buenas herramientas suele ser el punto de partida

La arquitectura multiagente resulta atractiva en una diapositiva: un agente planifica, otro investiga, otro revisa y otro ejecuta. Cada transferencia obliga a compartir estado, añade latencia y coste, y crea una nueva frontera de confianza. También complica la pregunta básica: ¿qué identidad y qué mandato conserva el siguiente agente?

La recomendación práctica es usar la menor complejidad que resuelva el caso de forma fiable. Un flujo determinista puede bastar cuando los pasos son conocidos. Un solo agente con herramientas acotadas cubre muchas tareas abiertas. Varios agentes tienen sentido cuando deben separarse la información disponible, las capacidades o los privilegios y la evaluación confirma que la ganancia compensa los nuevos fallos.

Lo que importa es que una acción incorrecta quede bloqueada antes de llegar al LMS; la cantidad de agentes del diagrama no demuestra esa propiedad.

La ficha de aceptación obliga a concretar

Antes de construir una función, el equipo puede completar una página con estas diez decisiones. Si una casilla no tiene respuesta, el desarrollo aún no está listo para empezar.

La ficha debe terminar con casos de aceptación. Incluye al menos un uso correcto, una denegación por rol, otra por ámbito, una fuente revocada, argumento mal formado, doble envío, fallo parcial, instrucción maliciosa en una fuente y una situación que exige intervención humana. Ese conjunto se convierte en la primera batería de regresión.

El primer corte vertical debe ser pequeño y completo

La adopción puede empezar con una única función de preparación, no con una «plataforma de agentes» horizontal. Un buen primer corte sería preparar un borrador de aviso sobre entregas pendientes para que lo revise la persona tutora. La función solo consulta datos acotados, produce un artefacto visible, no publica nada y ofrece un resultado fácil de comparar.

El equipo puede avanzar en esta secuencia:

1. Definir la ficha, los casos y las acciones prohibidas antes de elegir el modelo.
2. Construir la herramienta como operación de dominio y probarla sin IA.
3. Añadir delegación, fuentes autorizadas, compuerta y traza.
4. Permitir que el modelo prepare la llamada, manteniendo la ejecución en modo de simulación.
5. Evaluar con casos reales anonimizados y ataques antes de abrirla a un grupo controlado.
6. Medir la utilidad, las correcciones humanas, las denegaciones, los incidentes, el coste y el tiempo ahorrado; solo después decidir si merece más autonomía.

Este recorrido evita construir una capa genérica sin consumidores y obliga a resolver desde el principio la parte que suele posponerse: la identidad, las consecuencias y la operación. La visión de conjunto se desarrolla en El futuro del LMS: gobernar contexto, decisiones y confianza.

La preparación para agentes se demuestra al abrir una operación sin perder el control sobre el mandato, el significado ni la responsabilidad. Permitir que el modelo actúe en más lugares no aporta esa garantía. Cuando hay evidencia para las ocho pruebas, el agente pasa a ser otro consumidor sujeto a las reglas de la plataforma; cuando falta, la autonomía amplifica una deuda que ya existía.

Última revisión: 28 de julio de 2026.

Alberto Lara Hernández trabaja en dirección técnica, arquitectura de software, inteligencia artificial aplicada y plataformas de aprendizaje. Publica análisis para equipos que necesitan convertir posibilidades técnicas en decisiones, contratos y pruebas que resistan la operación real.