Cuando la IA educativa deja de caber en una caja de chat
Durante dos años, la conversación sobre inteligencia artificial en los centros educativos ha girado, casi en bucle, alrededor de dos preguntas: cómo se escribe un buen prompt y si el alumnado está usando ChatGPT para hacer los trabajos. Son preguntas razonables. También se están quedando viejas a una velocidad incómoda.
Mientras tanto, en el tejido empresarial la IA ya no es la herramienta con la que se juega: es la que sostiene procesos. Atención al cliente, análisis de datos, generación de documentación, soporte interno. Y ahí ha aparecido una distinción que el aula todavía no ha terminado de asimilar: una cosa es usar IA de terceros y otra muy distinta es desplegarla uno mismo, con sus reglas, sus datos y su responsabilidad encima.
Esa es la frontera que importa ahora.
El «prompting» no es un espejismo, pero sí es el escalón de entrada
Conviene matizar algo que se repite con cierta ligereza: que saber escribir prompts es trivial. No lo es. La ingeniería de contexto bien hecha —dar instrucciones precisas, acotar el rol, controlar las fuentes, encadenar pasos— marca diferencias enormes en la calidad de lo que devuelve un modelo, y seguirá importando aunque montes tu propia infraestructura. Quien dice que «el prompt ya no sirve» normalmente no ha visto la diferencia entre un prompt cuidado y uno descuidado contra el mismo modelo.
Dicho esto, es verdad que es una habilidad de superficie. Equivale, más o menos, a saber buscar bien en Google en 2005: útil, pero insuficiente como salida profesional. El mercado no busca «escribidores de prompts». Busca a quien sepa coger un modelo de código abierto, conectarlo a una base documental propia, exponerlo por una API y dejarlo funcionando dentro de un sistema más grande sin que se filtre nada por el camino. Eso ya no es saber pedir cosas a una IA. Es saber construir con ella.
Por qué en educación esto pesa más que en una empresa cualquiera
En una empresa, una fuga de datos a través de una herramienta de IA comercial es un problema serio: propiedad intelectual, información de clientes, secretos de negocio. En un centro educativo el problema cambia de naturaleza, because los datos que se manejan incluyen expedientes académicos, evaluaciones y, muy a menudo, información de menores de edad. Subir eso a un chatbot comercial cuya política de uso de datos no controlas no es una imprudencia técnica: puede ser una infracción.
Regulación de Alto Riesgo: UE 2024/1689
Y aquí entra la parte que en España y la UE ya no es opcional. El Reglamento de IA (UE 2024/1689) clasifica como sistemas de alto riesgo los destinados a la evaluación de resultados de aprendizaje y a decisiones de admisión. Alto riesgo significa obligaciones concretas: transparencia, explicabilidad, vigilancia humana, gestión de sesgos y documentación técnica.
A eso se le suma el RGPD —y su lectura agravada cuando hay datos de menores— y la supervisión de la AESIA, la agencia española que se ocupa precisamente de esto. Un centro que despliegue IA para apoyar evaluación o tutorización no está innovando en un terreno libre; está operando en un terreno regulado.
La consecuencia práctica es contundente: la decisión de dónde se procesan los datos deja de ser un detalle de infraestructura para convertirse en una decisión de cumplimiento. Y ahí es donde el despliegue local —o híbrido— pasa de ser una opción «para techies» a ser un argumento de gobernanza.
Lo que de verdad hay que aprender a montar
Si bajamos del discurso al taller, la «alfabetización de infraestructura» tiene componentes muy concretos, y ninguno es magia:
Hoy se hace con herramientas como Ollama, vLLM o LM Studio, ejecutando modelos abiertos (Llama, Mistral, Qwen, Gemma) cuantizados para que quepan en hardware razonable. Un modelo de 7–8B cuantizado corre en una GPU de gama media; no hace falta un centro de datos para empezar.
Es decir, que el modelo no responda solo con su conocimiento general, sino apoyándose en tus documentos: apuntes, guías, normativa, casos. Implica trocear los documentos, generar embeddings, guardarlos en una base vectorial (Chroma, Qdrant, pgvector) y recuperar los fragmentos relevantes antes de responder. Es la diferencia entre un tutor que improvisa y uno que cita tu material.
Una API que el LMS, una app o un script puedan consumir, con su autenticación, su control de errores y sus límites de uso. Aquí la arquitectura empieza a parecerse a la de cualquier microservicio corporativo, porque lo es.
Contenedores, copias, monitorización, pruebas de carga, actualización de modelos. La parte menos vistosa y la que decide si el proyecto sobrevive al primer trimestre.
No es ciencia ficción. En la propia FP española ya hay centros públicos pilotando plataformas de tutores virtuales ejecutadas en infraestructura local, comparando de forma medida la IA propia frente a la comercial en la nube: privacidad, coste por interacción, contextualización de las respuestas, trazabilidad. Que esto ocurra en institutos y no solo en departamentos de I+D de grandes empresas dice bastante de hacia dónde va el suelo de la profesión.
El contrapeso que casi nadie pone: lo local no es gratis
Aquí toca ser honesto, porque el entusiasmo por «la soberanía del dato» se salta un capítulo. Desplegar en local tiene un coste inicial (hardware, GPU) y, sobre todo, un coste de mantenimiento que no desaparece: alguien tiene que parchear, actualizar modelos, vigilar el servidor y responder cuando algo cae a las nueve de la mañana con treinta alumnos esperando. Un modelo abierto de 8B no rinde como el último modelo cerrado de frontera; para muchas tareas basta, para otras no.
Por eso la respuesta sensata para la mayoría de centros no es «todo local» ni «todo nube», sino híbrido y deliberado: local para lo que toca datos sensibles de menores o expedientes, nube para lo que no compromete privacidad y exige máxima capacidad. La pregunta correcta no es «¿en local o en la nube?», sino «¿qué dato puede salir del centro y cuál no, y qué nos cuesta cada opción?». Quien venda el despliegue local como una victoria sin contrapartidas no lo ha mantenido en producción.
Qué debería copiar el aula del mundo IT (y qué no)
Las empresas que han integrado IA con cabeza no la soltaron a ver qué pasaba. Trabajaron con método, y hay tres prácticas que la educación puede adaptar sin complejos:
• Entornos de prueba aislados: Un laboratorio donde alumnado y profesorado experimenten con modelos sin riesgo de que un documento confidencial acabe alimentando un modelo público.
• Métricas que midan lo que importa: No «cuánto más rápido se hacen las tareas», sino si el aprendizaje mejora de verdad: comprensión, autonomía, reducción de dudas repetitivas. La velocidad no es el objetivo.
• Integración con lo que ya existe: Conectar la IA al LMS, a las bases de datos y a los flujos del centro, en lugar de añadir otra herramienta suelta más.
Lo que el aula no debería copiar es la prisa por desplegar sin gobernanza. En una empresa, un error de IA es un incidente; en un centro, puede afectar al expediente o a la igualdad de oportunidades de un estudiante. El estándar de prudencia tiene que ser más alto, no más bajo.
El verdadero cambio es de competencias
Al final, esto no va de comprar un servidor. Va de qué sabemos formar. Si seguimos preparando a la gente solo para escribir en una caja de chat, la estaremos preparando para una fase del mercado que ya pasó. El salto está en formar perfiles capaces de entender la infraestructura, integrar modelos, gobernar datos y moverse dentro del marco legal —que en Europa ya no es un anexo, es el terreno de juego—.
Es un cambio exigente y nada espectacular: más consola y contenedores que titulares. Pero es exactamente la diferencia entre consumir la tecnología de otros y tener algo que enseñar sobre ella.
Deja una respuesta