Context Engineering en EdTech: gobernar lo que recibe la IA

Tesis El reto consiste en justificar por qué entró cada dato en la ventana del modelo, qué política lo autorizó, cuándo caduca y para qué acción puede utilizarse.

Un LMS sabe mucho más de lo que un tutor de IA necesita para responder una pregunta. Conoce matrículas, grupos, fechas, intentos, calificaciones, adaptaciones, foros, soluciones, versiones del curso y actividad reciente. Dar acceso a todo no vuelve más inteligente al modelo, sino que convierte una duda concreta en una consulta sobre la institución entera.

La alternativa tampoco es escribir un prompt enorme con una lista de prohibiciones. En cada interacción pueden variar la persona, la actividad, la versión de los materiales, el estado de una entrega y el conjunto de acciones permitidas. Por eso la entrada debe reconstruirse y poder explicarse.

Ahí empieza Context Engineering. En una plataforma de aprendizaje, es la disciplina que transforma estado institucional disperso en la información mínima, autorizada, vigente y trazable que una inferencia necesita. RAG puede recuperar fuentes y MCP exponer recursos y herramientas, pero ninguno decide por sí solo qué debe recibir cada usuario para una finalidad concreta.

Cinco piezas que no son intercambiables

El término se vuelve confuso cuando «prompt», «RAG», «memoria», «MCP» e «información de entrada» se utilizan para nombrar la misma caja. Resuelven problemas distintos y fallan de forma distinta.

Anthropic popularizó la expresión como evolución del diseño de prompts: no se trata solo de redactar instrucciones, sino de seleccionar y mantener el conjunto de señales que llega al modelo durante la inferencia. Su principio de trabajo es útil: la ventana es un recurso finito y conviene buscar un conjunto pequeño con alta densidad de información.

Ese principio necesita una extensión institucional. En EdTech, la utilidad de la señal no basta: también debe estar permitida, actualizada, aislada y ligada a una finalidad. La relevancia es una condición entre varias.

Compilar la información en lugar de concatenarla

La implementación ingenua concatena las instrucciones del sistema, los últimos mensajes, los resultados del buscador, el perfil del usuario y las salidas de las herramientas. Todo se envía si cabe en la ventana, aunque el orden pueda variar y la procedencia termine perdida en una masa de texto.

Propongo pensar la capa como un compilador. No porque traduzca código, sino porque recibe entradas con tipos y reglas, rechaza combinaciones inválidas y produce un artefacto delimitado para una acción.

Abrir la imagen a tamaño completo

El recorrido tiene siete pasos:

1. La capa recibe una solicitud tipada que indica quién pide qué, sobre qué actividad, con qué finalidad y qué clase de salida o acción espera.
2. Después resuelve la identidad y el ámbito: organización, curso, grupo, rol, matrícula, sesión y delegaciones vigentes.
3. Con ese perímetro aplica las políticas de fuentes, datos prohibidos, acciones, retención, jurisdicción y confirmación humana.
4. A continuación planifica la obtención mediante búsqueda, consulta estructurada, grafo, memoria o herramienta, porque no todo problema necesita RAG.
5. La información obtenida se valida y reduce: se comprueban la procedencia, la versión, la sensibilidad, las contradicciones y las instrucciones no fiables, y se elimina lo innecesario.
6. El resultado se divide en dos salidas enlazadas. El sobre de control conserva identidad, autorización, política completa y auditoría; el paquete para el modelo incluye solo el contenido autorizado y las restricciones que necesita para la tarea.
7. Por último, se registra y evalúa la decisión con información suficiente para reconstruir, medir y revocar sin almacenar indiscriminadamente todos los datos.

El orden forma parte del diseño: las políticas restringen el universo antes de buscar, la reducción se aplica antes de generar y la traza nace con el paquete, en lugar de reconstruirse después a partir de registros parciales.

El contrato separa control y entrada del modelo

Si la salida del compilador es una cadena de texto, la aplicación pierde las distinciones que acaba de calcular. Una cita se confunde con una instrucción; una restricción con material docente; una fuente vigente con otra caducada. Pero convertir todo el estado interno en entrada del modelo sería el error contrario: la IA no necesita conocer una identidad, una delegación o una política completa para obedecer el resultado de una autorización.

El contrato produce dos objetos tipados y relacionados por un identificador:

No todos los modelos aceptan esa estructura de la misma forma, por lo que el contrato se define con independencia del proveedor. Un adaptador puede convertir el paquete visible en mensajes, bloques de contenido o llamadas. Por defecto deniega el paso de campos del sobre de control. Solo añade un identificador seudónimo o un atributo del ámbito cuando la tarea lo necesita; el orquestador aplica permisos y efectos fuera del modelo.

La unidad reutilizable es el contrato que permite cambiar la entrada del modelo mientras el sobre de control conserva identidad, finalidad, permisos y procedencia fuera de su ventana.

Autorizar antes de buscar

Filtrar después de recuperar parece eficiente: se consulta un índice común y se eliminan los resultados que la persona no puede ver. Sin embargo, para entonces el sistema ya ha mezclado recursos que nunca debieron formar parte del conjunto candidato y puede filtrarlos mal en la ordenación, los resúmenes, las cachés o los registros intermedios.

La regla defendible es autorizar antes de aplicar relevancia. Primero se construye el universo permitido para esa identidad, finalidad y actividad. Después se busca dentro de él. Cada resultado conserva la decisión de acceso que lo acompañó.

En un campus multiinstitución, la prueba mínima debe intentar cruzar cuatro fronteras: organización, curso, grupo y persona. También debe comprobar cambios en el tiempo. Si un docente retira un recurso o un alumno pierde una matrícula, el sistema debe dejar de recuperarlo e invalidar las cachés asociadas dentro del plazo de revocación acordado.

El principio de minimización del RGPD refuerza el diseño cuando hay datos personales: una finalidad específica y solo datos adecuados, pertinentes y limitados a lo necesario. No significa que todo tratamiento quede legitimado por reducir campos; obliga a empezar por el propósito y la base aplicable. En arquitectura, evita la frase «lo incluimos por si acaso».

Un conjunto de aceptación debería cubrir:

• consulta válida con los recursos esperados;
• intento de acceso a otra organización, grupo o actividad cerrada;
• recurso cuya autorización cambia entre dos turnos;
• caché creada antes de una revocación;
• resultado derivado que conserva información de una fuente ya retirada;
• registro de auditoría que explica el rechazo sin guardar el dato rechazado.

Dónde encajan RAG y MCP

RAG se ocupa de la recuperación dentro del conjunto autorizado que le entrega el compilador, junto con las consultas, los filtros, el presupuesto y las condiciones de vigencia. Después, el compilador valida los candidatos antes de construir el paquete. La similitud semántica nunca decide por sí sola si puede utilizarse una solución de examen, una observación privada o un recurso de otro grupo.

MCP aporta una frontera de integración. La revisión 2025-11-25 de la especificación permite negociar funciones como prompts, recursos, herramientas, registro y completado. También incorpora tasks, pero aún como función experimental cuyo diseño puede cambiar; por eso conviene aislarla detrás de un adaptador. Es una base útil para no escribir un conector exclusivo por cada agente.

El protocolo puede proteger un servidor remoto con flujos de autorización, ámbitos de mínimo privilegio y validación de audiencia, aunque deja fuera la lógica académica. La aplicación sigue decidiendo si una herramienta puede publicar una calificación, si la actividad permite pistas o si el coordinador puede consultar datos de otra cohorte.

La guía oficial de seguridad prohíbe traspasar sin más el token recibido a un sistema posterior, porque se pierden controles y atribución. El mismo criterio se aplica al contenido: que una salida proceda de MCP no basta para incorporarla; antes hay que validar su esquema, su origen, su sensibilidad y las posibles instrucciones embebidas. RAG tampoco elimina la inyección de instrucciones.

MCP permite descubrir recursos y herramientas; la capa decide cuáles puede usar cada identidad, con qué límites y cómo incorpora los resultados.

La memoria no es un historial sin fin

Guardar toda la conversación y enviarla en cada turno constituye una forma de implementación, pero no una política de memoria, porque mezcla datos caducados, instrucciones anteriores, errores corregidos y detalles personales cuya utilidad ya terminó.

Una plataforma de aprendizaje necesita separar al menos cuatro estados:

La distinción evita que un resumen generado se convierta en expediente. El agente puede recibir una proyección mínima del estado institucional sin ser su fuente de verdad. Si la información cambia, la siguiente compilación utiliza el registro vigente.

La memoria también necesita procedencia. «El alumno prefiere ejemplos visuales» puede venir de una preferencia declarada, de una elección puntual o de una inferencia del sistema. No tienen la misma autoridad ni la misma fecha de caducidad.

Tres procedimientos operativos para plataformas de aprendizaje

El contrato se entiende mejor al aplicarlo a flujos que exigen información distinta.

Incorporación a un puesto

En la incorporación a un puesto, la finalidad consiste en orientar el siguiente paso del itinerario asignado. La capa puede recibir el rol, la unidad, la ruta vigente, los recursos habilitados y la versión de la política, pero excluye por defecto los datos de otras personas, el contenido de equipos ajenos y los módulos futuros. La prueba decisiva consiste en comprobar que un cambio de unidad o rol modifica inmediatamente las fuentes y explica la diferencia.

Certificación

En una certificación, la finalidad es informar del estado y de las opciones para completar un requisito. La entrada puede incluir las reglas vigentes, las evidencias válidas, los intentos, los plazos y la supervisión. El agente no modifica el expediente ni toma una decisión opaca, y la prueba debe demostrar que una evidencia caducada se señala y que cualquier excepción exige la confirmación de la persona responsable.

Transferencia de conocimiento

En la transferencia de conocimiento se busca explicar cómo se ejecuta un procedimiento o por qué se decidió. La entrada puede reunir documentación autorizada, incidencias resueltas, decisiones de arquitectura y propietarios actuales, pero nunca presenta una decisión antigua como práctica vigente. La prueba decisiva comprueba que la respuesta cita la fecha y la procedencia, y que señala el hueco cuando las fuentes discrepan.

Los tres procedimientos comparten el compilador, aunque cambian la finalidad, las fuentes, los atributos prohibidos, las herramientas, la retención, la evaluación y el escalado. El contrato permite reutilizar la mecánica sin fingir que todos los flujos son iguales.

Cuándo convertir la capa en servicio

Context as a Service tiene sentido cuando la compilación se expone como servicio reutilizable para varios tutores, agentes, copilotos o automatizaciones. El nombre describe una decisión de plataforma; no es un estándar formal ni exige comprar un producto.

Centralizar demasiado pronto crea un equipo de plataforma sin consumidores reales. Centralizar demasiado tarde multiplica índices, filtros, memorias y registros incompatibles. La señal para extraer no es que la arquitectura quede bonita: es que varias aplicaciones repiten las mismas decisiones de identidad, política, procedencia y evaluación.

Una frontera compartida tampoco debe convertirse en cuello de botella. Los dominios conservan la propiedad de sus reglas y fuentes; el servicio aporta contrato, ejecución, observabilidad y componentes comunes.

Métricas y pruebas de aceptación

Contar tokens o medir latencia no basta. La capa tiene que demostrar que selecciona bien y que respeta sus límites.

NIST organiza la gestión del riesgo de IA en cuatro funciones: GOVERN, MAP, MEASURE y MANAGE; en castellano, gobernar, analizar el contexto, medir y gestionar. La tabla traduce esa lógica a una frontera técnica: propietario y política, flujo y daños, pruebas, y respuesta ante cambios o incidentes.

El paquete debe registrarse de forma suficiente para depurar, no necesariamente de forma literal. Guardar todos los datos para demostrar minimización sería una contradicción. Identificadores, versiones, decisiones y resúmenes controlados pueden permitir reconstrucción sin duplicar el contenido sensible.

Una secuencia de adopción sin plataforma prematura

1. Primero se instrumenta un caso real para registrar qué instrucciones, fuentes, permisos y herramientas utiliza, y medir los fallos antes de abstraer.
2. A partir de ese caso se define el contrato, separando la solicitud, la política, las evidencias, las fuentes, las restricciones, la caducidad y la traza.
3. Las decisiones repetidas solo se extraen cuando aparece un segundo consumidor que necesita compartir identidad, autorización, catálogo, procedencia o evaluación.
4. Cuando la capa ya tiene varios clientes, se opera como producto interno y se añaden versiones, acuerdos de servicio, compatibilidad, responsables de dominio y pruebas de regresión.

Este orden entrega utilidad en cada etapa y también permite detenerse. Una biblioteca mantenida por dos equipos puede ser la arquitectura correcta durante años; no todo necesita una plataforma distribuida.

Condición de salida No publiques una nueva integración si no puedes reconstruir qué identidad, finalidad, política, fuentes, versiones y herramientas formaron su entrada, ni demostrar que una revocación impide reutilizarlas.

La ventaja está en justificar cada entrada

La ventana de un modelo seguirá creciendo y los protocolos incorporarán nuevas funciones. Ninguno elimina la pregunta institucional: qué información debía entrar en esta acción y por qué.

Context Engineering aporta la disciplina, que el compilador convierte en arquitectura mediante un paquete capaz de conservar las decisiones. RAG y MCP proporcionan los mecanismos, mientras que la memoria guarda solo el estado que tiene una finalidad. Cuando varias aplicaciones necesitan ese conjunto de forma repetida, tiene sentido exponerlo como Context as a Service.

La arquitectura del LMS que aprende con IA explica el sistema completo. El artículo sobre tutores de IA decide qué intervención conviene. Esta capa ocupa la frontera entre ambos: sirve la información exacta con la que una decisión puede ser útil, limitada y auditable.

La ventaja estará en poder explicar cada inclusión, cada ausencia y cada cambio sin depender de la memoria de quien escribió el primer prompt.