Arquitectura de un tutor de IA que pueda demostrar cuándo enseña
Cuatro contratos separan una conversación convincente de un sistema educativo: identidad y alcance, conocimiento, intervención y evidencia.
La diferencia esencial Un chatbot produce respuestas. Un tutor selecciona intervenciones para que una persona aprenda y debe demostrar cuándo ayuda, cuándo perjudica y cuándo tiene que apartarse.
Una respuesta correcta también puede enseñar mal. Puede resolver el ejercicio que el alumno necesitaba intentar, ocultar el error que convenía hacer visible o dar una explicación impecable en un momento en que hacía falta una pregunta. La fluidez verbal no corrige ninguna de esas decisiones.
Por eso, conectar un modelo a los documentos de un curso no crea un tutor de IA. Crea, como máximo, un asistente capaz de conversar sobre esos documentos. Puede ser útil. Incluso puede ser un buen producto. Lo que no debería hacerse es llamarlo tutor y atribuirle beneficio educativo sin haber diseñado la parte que enseña.
La distinción tiene consecuencias prácticas. La OCDE advierte en su Digital Education Outlook 2026 que una herramienta generativa puede mejorar el resultado inmediato de una tarea sin producir aprendizaje. Cuando sustituye el esfuerzo cognitivo, el alumno puede entregar algo mejor y conservar menos. En cambio, los usos guiados por un propósito pedagógico claro sí pueden favorecer el aprendizaje.
La diferencia no es meramente terminológica. Un equipo que construya un chatbot medirá la calidad de sus respuestas; si construye un tutor, tendrá que gobernar las intervenciones y medir los cambios que producen. Entre ambos productos hay cuatro contratos de arquitectura.
El contrato del tutor se diseña antes que el modelo
El modelo es una pieza intercambiable dentro del sistema. El contrato del tutor define qué puede hacer la pieza completa cuando una persona pide ayuda. Sin ese contrato, cada respuesta depende de una mezcla opaca de instrucciones, texto recuperado y comportamiento probabilístico.
Yo exigiría cuatro decisiones explícitas antes de elegir proveedor, tamaño de modelo o base de datos:
| Contrato | Pregunta que debe resolver | Fallo que evita |
|---|---|---|
| Identidad y alcance | ¿Quién pregunta, dentro de qué actividad y con qué permisos? | Revelar recursos, respuestas o datos fuera de su ámbito |
| Conocimiento | ¿Qué conceptos, relaciones y fuentes vigentes puede utilizar? | Responder con material obsoleto, aislado o contradictorio |
| Intervención | ¿Conviene preguntar, dar una pista, practicar, explicar, abstenerse o escalar? | Resolver una tarea cuando el objetivo era aprender a resolverla |
| Evidencia | ¿Qué observación permitiría saber si la ayuda funcionó? | Confundir una conversación agradable con aprendizaje |
Estos contratos no tienen por qué convertirse en cuatro servicios separados. Son fronteras de responsabilidad. Una implementación pequeña puede resolverlas en un solo producto; una universidad o una plataforma con varios proveedores quizá necesite componentes distintos. Lo importante es que las decisiones no queden escondidas dentro de un único mensaje al modelo.
El artículo sobre la arquitectura del LMS que aprende con IA desarrolla los contratos de plataforma. Aquí el foco es más estrecho: qué hace falta para que una conversación merezca la función tutorial.
Un estado del alumno basado en evidencias
Un tutor humano no responde igual a quien empieza que a quien ha demostrado dominio y pide un reto mayor. Un tutor de IA también necesita estado, pero ahí aparece uno de los riesgos peor resueltos: convertir unas pocas señales de la plataforma en una descripción total de la persona.
«No ha entregado dos actividades» no significa «carece de motivación». «Falló tres preguntas de fracciones» no prueba «no entiende las fracciones». Quizá interpretó mal el enunciado, utilizó otra notación, tuvo un problema de accesibilidad o simplemente se equivocó ese día. Un sistema que borra esa incertidumbre fabrica diagnósticos con apariencia matemática.
El estado mínimo debería guardar evidencias observables y las condiciones en que se produjeron:
| Campo | Ejemplo defendible | Lo que no permite afirmar |
|---|---|---|
| Objetivo actual | Resolver ecuaciones lineales con una incógnita | Que ese sea el único objetivo relevante para la persona |
| Evidencia | Dos intentos, respuesta y procedimiento utilizados | Un dominio permanente a partir de dos muestras |
| Momento y versión | Actividad 3, versión 2, 28 de julio | Que una evidencia antigua siga describiendo el estado actual |
| Grado de confianza | Indicio débil, evidencia suficiente, contradicción | Una certeza que los datos no sostienen |
| Fuente | Cuestionario, explicación escrita, revisión docente | Que todas las fuentes tengan el mismo peso |
| Posible siguiente paso | Pedir que explique el primer cambio de signo | Que la recomendación deba ejecutarse sin opción docente |
Ese registro debe poder rectificarse, caducar y explicar por qué ha influido en una intervención. También debe distinguir entre ausencia de evidencia y evidencia de ausencia. No saber si alguien domina un concepto no equivale a saber que no lo domina.
La personalización responsable empieza siendo modesta. Utiliza solo lo necesario para la ayuda concreta, declara la incertidumbre y permite que el alumno o el docente corrijan los datos. Cuanto más ambicioso sea el perfil, mayor será la carga de prueba sobre su utilidad, su legitimidad y sus efectos.
Del repositorio documental al mapa de aprendizaje
Una carpeta de PDF puede alimentar una búsqueda. No representa por sí sola un curso. Le faltan las relaciones que dan sentido educativo al contenido: qué concepto depende de cuál, qué material está vigente, qué actividad intenta observar una competencia, qué ejemplo es introductorio, qué respuesta debe permanecer oculta y qué explicación contradice una edición posterior.
RAG —recuperar información antes de generar— resuelve una pregunta útil: qué fragmentos pueden aportar hechos a la respuesta. No decide qué ayuda conviene, ni convierte los documentos en currículo, ni garantiza que el fragmento recuperado sea el autorizado para ese alumno. Es una función del sistema, no la arquitectura del tutor.
El saber que necesita una tutoría defendible tiene, como mínimo, cinco propiedades:
- Estructura. Conceptos, prerrequisitos, competencias, actividades y fuentes están relacionados. El tutor puede saber que una dificultad actual nace en un concepto anterior sin inventar una trayectoria.
- Vigencia. Cada fuente tiene versión, fecha, responsable y estado. Una nueva edición no convive silenciosamente con la anterior.
- Procedencia. La respuesta conserva de dónde sale cada afirmación y puede mostrar una referencia comprensible.
- Función pedagógica. El sistema distingue un enunciado, una explicación, una respuesta modelo, una rúbrica, una pista y una nota interna del profesorado.
- Ámbito de uso. Los permisos viajan con la fuente y se aplican antes de recuperarla, no después de que el modelo la haya leído.
| Carpeta documental | Mapa de aprendizaje |
|---|---|
| Fragmentos parecidos a la consulta | Conceptos y actividades relacionados con el objetivo |
| Fecha del archivo, si existe | Versión, responsable, vigencia y sustituciones |
| Un texto es un texto | Cada recurso tiene función y reglas de exposición |
| La similitud decide | La intención pedagógica restringe la recuperación |
| La cita es opcional | La procedencia forma parte de la respuesta y de la auditoría |
Esto no exige empezar con un grafo semántico gigantesco. Se puede comenzar por un mapa pequeño de objetivos, actividades, fuentes y dependencias críticas. La solidez reside en que esas relaciones sean explícitas y versionables, no en que la tecnología del catálogo suene sofisticada.
Cada respuesta es una intervención pedagógica
El error más costoso de una demostración aparece precisamente cuando la recuperación funciona: el sistema encuentra la página adecuada y construye una respuesta correcta, pero revela la solución que el alumno debía elaborar. El mecanismo técnico ha funcionado y, aun así, la intervención ha eliminado la actividad de aprendizaje.
Un tutor necesita una política de intervención anterior a la redacción. Esa política traduce el diseño de aprendizaje en conductas permitidas. Para una misma pregunta, el sistema podría elegir:
- pedir al alumno que muestre el intento;
- señalar el punto exacto donde cambia el razonamiento;
- ofrecer una pista que reduzca el problema sin resolverlo;
- proponer un ejemplo análogo y volver después al original;
- explicar el concepto de forma directa;
- confirmar una respuesta y pedir justificación;
- abstenerse porque la tarea es evaluable o falta información;
- derivar al docente cuando hay contradicción, riesgo o bloqueo persistente.
La elección depende del objetivo, de la fase de la actividad, de la evidencia disponible y de los límites definidos por el responsable pedagógico. No debería depender solo de que el modelo «decida ser socrático». Tampoco existe una conducta universalmente correcta: hacer preguntas sin fin puede ser tan inútil como regalar siempre la respuesta.
La investigación reciente confirma por qué esta capa no se puede dar por resuelta. MathTutorBench separa dominio de la materia, comprensión del alumno y destreza pedagógica. En sus pruebas, saber resolver un problema no se tradujo automáticamente en saber enseñar, y mantener el nivel en diálogos largos resultó más difícil. MRBench evalúa respuestas mediante ocho dimensiones pedagógicas, no con una nota genérica de «utilidad». La tarea compartida BEA 2025 descompuso el problema en identificación y localización del error, orientación y utilidad práctica de la retroalimentación; incluso los mejores sistemas dejaron margen considerable de mejora.
El diseño de producto debería reflejar esa complejidad. La política pedagógica ha de ser visible, versionada y editable por quien responde del aprendizaje. Cambiar de modelo no puede cambiar sin aviso cuándo se entregan soluciones o cuándo se deriva a una persona.
Una regla útil Primero se elige la intervención; después se redacta. Si el modelo recibe a la vez el problema, los materiales y la libertad de decidir qué significa enseñar, la arquitectura ha delegado su decisión principal.
Autorizar antes de recuperar; minimizar antes de generar
Una plataforma educativa contiene fronteras que una conversación no puede borrar: matrículas, grupos, fechas de apertura, adaptaciones, calificaciones, retroalimentación privada, bancos de preguntas y soluciones. Ocultar un enlace en la interfaz no impide que un índice semántico recupere su contenido.
La secuencia correcta es menos cómoda y mucho más segura:
| Momento | Control | Evidencia que debe quedar |
|---|---|---|
| Antes de buscar | Identificar usuario, curso, actividad, fase y finalidad | Identidad, ámbito y política aplicable |
| Al seleccionar fuentes | Filtrar por permiso, vigencia, sensibilidad y función | Candidatos aceptados y descartados con motivo |
| Antes de generar | Minimizar datos y separar instrucciones de contenido no fiable | Entrada exacta entregada al modelo |
| Al responder | Limitar acciones, referencias y datos expuestos | Salida, citas, herramientas y bloqueos |
| Después | Retener solo la traza necesaria y permitir revisión | Registro auditable con plazo y responsable |
«Minimizar» no significa quitar información hasta volver inútil el sistema. Significa no entregar al modelo todo lo que la plataforma conoce solo porque está disponible. Para responder a una duda conceptual no hacen falta las notas de otras personas, el historial académico completo ni las observaciones privadas del docente.
También hay que tratar los materiales como contenido potencialmente hostil. Una instrucción escondida en un documento, una página enlazada o una imagen puede intentar alterar el comportamiento del modelo. OWASP advierte que RAG y el ajuste del modelo no eliminan por sí solos la inyección de instrucciones. La defensa exige aislar fuentes, restringir herramientas y acciones, validar salidas y asumir que ninguna instrucción del contenido tiene autoridad sobre la política del sistema.
UNESCO añade dos criterios que a veces desaparecen en la arquitectura: diseño centrado en la persona y adecuación a la edad, junto con protección de datos y validación pedagógica. No basta con tener una respuesta segura en términos técnicos si la experiencia presiona al alumno para revelar información, oculta que habla con una máquina o desplaza el criterio del profesorado.
Cuando la herramienta pasa de ayudar a estudiar a evaluar, asignar itinerarios o influir en decisiones con consecuencias, el análisis cambia. La guía sobre IA de alto riesgo en plataformas de aprendizaje explica cómo clasificar el caso. Aquí basta una regla: no ampliar la función del tutor por una modificación de prompt. Cada nueva consecuencia exige revisar propósito, datos, supervisión y evidencia.
Cómo evaluar si el sistema enseña
Una demo suele reunir diez preguntas, celebrar las respuestas convincentes y declarar el piloto satisfactorio. Esa prueba no permite saber si el tutor recuperó la fuente correcta, respetó una actividad, ayudó a corregir un error o produjo dependencia.
La evaluación debe separar cinco capas para que un buen resultado en una no oculte un fallo en otra:
| Capa | Qué se comprueba | Ejemplo de evidencia |
|---|---|---|
| Sistema | Recuperación, autorización, latencia, coste, disponibilidad y reconstrucción | Pruebas con consultas, usuarios y fuentes controladas |
| Contenido | Corrección, vigencia, procedencia, contradicciones y abstención | Casos de referencia revisados por especialistas |
| Intervención | Diagnóstico del error, pista adecuada, carga, acción siguiente y escalado | Rúbrica pedagógica con revisión humana |
| Seguridad y equidad | Exposición de datos, inyección, diferencias entre grupos, accesibilidad y edad | Pruebas adversariales y recorridos representativos |
| Aprendizaje | Retención, transferencia, autonomía y desempeño sin ayuda | Actividad posterior o diferida que no replica el entrenamiento |
Exactitud y aprendizaje se relacionan, pero no son equivalentes. Una respuesta falsa no es buena tutoría; una respuesta verdadera tampoco basta. El resultado que importa puede aparecer después: cuando el alumno resuelve un problema nuevo, explica el procedimiento con sus palabras o deja de necesitar la misma ayuda.
Por eso mediría el efecto en tres momentos. Durante la conversación comprobaría si la intervención identifica el punto de bloqueo y ofrece un siguiente paso adecuado. Después observaría si la persona completa la actividad con menos apoyo y, pasado un tiempo, si transfiere lo aprendido a una situación que no apareció en el diálogo. Sin esta última comprobación, el sistema podría estar entrenando al alumno para repetir su propia respuesta.
Los jueces automáticos ayudan a escalar la revisión, pero no deberían ser la única autoridad. MRBench utiliza anotaciones humanas de referencia; la tarea BEA 2025 mostró que evaluar destrezas pedagógicas también sigue siendo un problema abierto. Si un modelo genera la respuesta, otro modelo la puntúa y el equipo acepta la cifra sin calibración humana, el cuadro de mando puede medir el grado de acuerdo entre máquinas, no la calidad del criterio educativo.
Un conjunto de evaluación útil incorpora casos normales, límites y ataques: preguntas ambiguas, materiales contradictorios, ausencia de evidencia, solicitudes de respuesta final, cambios de idioma, errores plausibles, estudiantes que persisten en una idea equivocada y documentos con instrucciones maliciosas. El tutor no se valida únicamente en situaciones favorables.
Una matriz de aceptación para el piloto
Antes de exponer el sistema a un curso real, convertiría los cuatro contratos en pruebas con una persona responsable y una condición de parada. Esta matriz es deliberadamente exigente: un piloto sirve para reducir incertidumbre, no para trasladarla al alumnado.
| Contrato | Prueba de aceptación | Evidencia | Condición de parada |
|---|---|---|---|
| Identidad y alcance | Cada usuario obtiene solo las fuentes incluidas en su ámbito; una fuente excluida del permiso de uno de ellos nunca aparece entre sus candidatos ni en su respuesta | Registro de fuentes candidatas, filtradas y usadas | Una respuesta modelo, un dato o un recurso aparece fuera de su ámbito |
| Conocimiento | Toda afirmación material remite a una fuente vigente y las contradicciones que no puedan resolverse mediante la vigencia, la autoridad o la versión de las fuentes provocan abstención | Casos de referencia y trazas de procedencia | No se puede explicar qué versión sustentó una respuesta |
| Estado | La intervención utiliza solo evidencias necesarias, temporales y rectificables | Ficha de estado visible y prueba de corrección | El sistema atribuye rasgos o competencias sin evidencia observable suficiente, sin indicar la incertidumbre o sin permitir rectificación |
| Intervención | La respuesta respeta la fase de la actividad y ofrece un siguiente paso apropiado | Rúbrica revisada por responsables pedagógicos | Entrega soluciones donde la política exige andamiaje |
| Seguridad | Fuentes hostiles no cambian políticas ni activan herramientas no autorizadas | Pruebas adversariales y registro de bloqueos | Una instrucción del contenido altera el comportamiento permitido |
| Abstención y escalado | El tutor reconoce falta de información, conflicto o riesgo y deriva con motivo | Banco de casos negativos | Inventa, oculta incertidumbre o bloquea sin salida humana |
| Aprendizaje | El diseño se acuerda antes del piloto. Para estimar el efecto del tutor se usa asignación aleatoria cuando sea viable; si no, un grupo comparable con medidas anteriores y posteriores, control de diferencias iniciales, abandono e incertidumbre. Una comparación solo con la línea de base se informa como cambio observado, no como efecto causal | Protocolo, análisis y umbrales acordados antes del piloto | Solo mejora satisfacción, velocidad o el entregable asistido; o se atribuye causalidad a una comparación que no permite estimarla |
| Operación | Cada respuesta se reconstruye y una política se puede retirar sin desplegar todo el producto | Traza, versiones y ensayo de desactivación | No se puede investigar un incidente o detener una conducta |
La matriz debe acordarse antes de ver resultados. Si el equipo cambia el umbral después de una demo decepcionante, ya no está evaluando: está justificando una decisión tomada.
También conviene acotar el piloto a una función y una población concretas. Un sistema que ayuda a practicar preguntas de recuperación no queda validado para orientar itinerarios, corregir ensayos o intervenir en una evaluación. Cada nuevo uso modifica los datos, las políticas, los posibles daños y la evidencia necesaria.
Cuándo no construir un tutor
Hay organizaciones que no necesitan todavía un tutor de IA. Necesitan arreglar el contenido, aclarar quién decide la pedagogía o mejorar la ayuda humana. La tecnología conversacional no corrige una asignatura con versiones contradictorias ni una plataforma incapaz de saber qué material está vigente.
No lo desplegaría si falta cualquiera de estas condiciones:
- un objetivo de aprendizaje concreto que no se reduzca a «responder dudas»;
- una persona responsable de la política pedagógica y de sus cambios;
- fuentes con una persona responsable, vigencia, función y permisos claros;
- una representación mínima y rectificable de la evidencia del alumno;
- casos de evaluación normales, negativos y adversariales;
- una vía de abstención y escalado a una persona;
- trazabilidad suficiente para reconstruir una intervención;
- posibilidad de desactivar el sistema o una conducta sin esperar al proveedor.
En ese escenario, un buscador con buenas referencias, una ayuda contextual o un asistente que declare sus límites puede aportar más utilidad y menos riesgo. Ser honesto con la función es una decisión de producto, no una renuncia a innovar.
Decisión de arquitectura Si no puedes explicar qué sabía el sistema, qué política eligió la intervención y qué evidencia demostraría aprendizaje, todavía no tienes un tutor. Tienes una conversación que puede resultar útil, pero no una función educativa gobernada.
La secuencia completa como unidad de evaluación
El espejismo nace de mirar solo la respuesta. Una frase clara, una cita correcta y un tono amable hacen que el sistema parezca terminado. Sin embargo, la unidad de evaluación de un tutor no es esa respuesta aislada. Es la secuencia completa: identificar el ámbito, reunir fuentes autorizadas, elegir una intervención, observar su efecto y corregir la política.
Ese ciclo desplaza la pregunta que debería hacer una dirección tecnológica. No es «¿qué modelo responde mejor?», sino «¿qué sistema puede justificar por qué intervino así y demostrar que esa intervención ayuda a aprender?».
Cuando los cuatro contratos existen, el modelo puede cambiar sin perder el propósito. Cuando no existen, cada mejora de fluidez hace más convincente una decisión que nadie ha gobernado. Esa es la frontera entre añadir IA a un curso y diseñar un sistema inteligente de aprendizaje.
Más de 22 años construyendo y evolucionando plataformas de aprendizaje que tienen que operar de verdad.
Seguir leyendo
- Evaluación con IA: cómo usar rúbricas sin delegar la nota
Arquitectura y pruebas para usar IA con rúbricas, preparar retroalimentación y reducir carga docente sin convertir una sugerencia del modelo en nota automática.
- Por qué un RAG conectado al LMS sigue alucinando
Un modelo de arquitectura para evitar que un RAG educativo mezcle documentos, estado actual y reglas de acceso como si tuvieran la misma autoridad.
- Loop Engineering: tres formas de aprobar tus propios fallos
Tres falsos verdes encontrados al automatizar un ciclo editorial con agentes: integrar tus propios cambios, recortar la auditoría y probar el registro en lugar del defecto.