Cómo gobernar la IA en una plataforma EdTech

Un marco de gobernanza de IA para una plataforma EdTech debe gobernar actuaciones concretas, no marcas ni modelos. Para cada caso de uso ha de fijar una finalidad, una población, los datos permitidos, el efecto admisible sobre el aprendizaje, quién responde, qué resultados de evaluación debe exigir quien autoriza el despliegue y qué señales obligan a detenerlo.

La diferencia parece semántica, pero cambia el trabajo. «Usamos el modelo X» no permite saber si la plataforma resume un tema, corrige un examen o decide quién recibe un itinerario de refuerzo. Las tres funciones pueden compartir proveedor y, sin embargo, exigir controles muy distintos.

Tampoco basta con escribir principios como transparencia, equidad o supervisión humana. El gobierno existe cuando esos principios modifican una decisión de producto: impiden usar un dato, retrasan un lanzamiento, obligan a cambiar una interfaz, derivan un caso a una persona o retiran una función.

La unidad mínima de gobierno no es el modelo. Es el caso de uso completo: finalidad, datos, inferencia, salida propuesta, decisión humana, actuación ejecutada y consecuencia para la persona.

Cómo usar este marco. La ficha delimita cada caso de uso. El expediente reúne su clasificación, los resultados de evaluación y la autorización de despliegue. El plan de 90 días pone en marcha el circuito, y la lista final comprueba que cada control tenga responsable y documentación. Empieza por la ficha si analizas un caso concreto; empieza por el plan si todavía no existe un proceso común.

Gobernar casos de uso, no nombres de modelos

El inventario debería empezar en los puntos donde el sistema observa, genera, recomienda, ordena, predice o decide. Una plataforma puede emplear el mismo modelo de lenguaje de gran tamaño (LLM) para redactar preguntas de práctica, responder dudas y proponer una calificación. Si el inventario tiene una sola fila para ese modelo, mezcla tres finalidades, tres conjuntos de datos y tres consecuencias.

También ocurre lo contrario. Una decisión académica puede depender de un modelo de lenguaje, un clasificador, reglas de negocio y datos importados desde el sistema de gestión del aprendizaje (LMS). Revisar cada componente por separado hace perder de vista la consecuencia conjunta. Lo que importa es la cadena que termina en una consecuencia visible para el estudiante o el docente.

Yo abriría una ficha por caso de uso con estos campos:

El identificador de la ficha debe propagarse por la arquitectura. Debería aparecer en los requisitos, la evaluación, la configuración desplegada, las trazas, los incidentes y el contrato del proveedor. Así se puede saber qué versión produjo una salida y qué actuación ejecutó después la plataforma, sin reconstruir la secuencia a partir de correos.

Este inventario tampoco se limita a lo que el equipo llama IA. Incluye modelos integrados por un proveedor, funciones opcionales activadas por cada institución y automatizaciones que quizá queden fuera de la definición jurídica. Clasificar después requiere haberlas visto primero.

Clasificar la consecuencia antes de elegir el control

El Reglamento europeo distingue prácticas prohibidas, sistemas de alto riesgo y obligaciones específicas de transparencia. No ofrece una pirámide universal en la que todo caso de uso encaje sin matices. La clasificación depende de la definición de sistema de IA, de la finalidad prevista, de las circunstancias de uso y de las excepciones que puedan corresponder.

En educación, el anexo III del Reglamento de IA incluye usos destinados a:

• decidir el acceso, la admisión o la asignación a instituciones educativas;
• evaluar resultados de aprendizaje, también cuando se emplean para dirigir el aprendizaje;
• determinar el nivel educativo que una persona recibirá o al que podrá acceder;
• vigilar y detectar comportamientos prohibidos durante pruebas, incluida la vigilancia automatizada (proctoring) basada en IA cuando se utilice con esa finalidad.

El uso en centros educativos de sistemas que infieren emociones o intenciones a partir de datos biométricos está prohibido, salvo cuando se implanten por razones médicas o de seguridad. Otras formas de inferencia afectiva requieren un análisis distinto. La práctica prohibida no es otra variante de «alto riesgo» que pueda desplegarse acumulando controles.

Hay además casos que requieren análisis. El artículo 6.3 permite no tratar como de alto riesgo determinados sistemas del anexo III cuando no planteen un riesgo significativo para la salud, la seguridad o los derechos fundamentales, también por no influir materialmente en una decisión. Además, deben cumplir al menos una de estas cuatro condiciones:

• ejecutar una tarea procedimental estrecha;
• mejorar el resultado de una actividad humana ya completada;
• detectar patrones o desviaciones respecto de una evaluación humana previa, sin sustituirla ni influir en ella si no existe una revisión adecuada;
• realizar una tarea preparatoria.

El proveedor debe documentar esa evaluación antes de introducir el sistema en el mercado o ponerlo en servicio. La excepción no se aplica si el sistema elabora perfiles de personas. La etiqueta comercial «asistente» o «recomendador» no resuelve ninguna de estas comprobaciones.

Para profundizar en esa parte está la guía sobre cuándo una IA que dirige el itinerario de un alumno es de alto riesgo. Aquí interesa añadir una segunda escala: la prioridad interna de control. No sustituye la clasificación jurídica; decide cuánto escrutinio necesita el producto.

La prioridad interna la determina el nivel más alto asignado en cuatro ejes. Estos criterios de referencia permiten que dos equipos discutan la misma ficha sin inventar su propia escala:

El nivel provisional es el más alto de los cuatro ejes; una media no compensa una consecuencia grave. Si dos equipos discrepan, se conserva el nivel superior. Para rebajarlo, el responsable del riesgo debe documentar el motivo y una función de control independiente del equipo proponente, identificada en el expediente, debe validar la rebaja. Los incidentes y las apelaciones sirven para revisar estos criterios. P0 no es un grado superior de escrutinio: identifica un caso declarado no admisible tras el análisis correspondiente.

Un caso puede ser P1 aunque no resulte jurídicamente de alto riesgo. Puede afectar a menores, tratar información sensible o dañar el aprendizaje si falla de forma sistemática. Y un producto descrito como «bajo riesgo» por un proveedor no evita el análisis de la institución que lo integra en otro flujo.

La clasificación debe terminar con una resolución: prohibir, explorar en entorno aislado, probar en modo de observación sin ejecutar las actuaciones propuestas —también llamado modo sombra—, desplegar con límites o desplegar. «Pendiente de cumplimiento» no es un estado seguro si la función ya está activa.

Qué cambia con el calendario europeo

Este apartado es una nota de vigencia, no otra fase del método. Si solo necesitas aplicar el marco, puedes continuar en «Convertir cada caso en un expediente vivo» y volver aquí al revisar obligaciones y plazos.

La categoría jurídica determina qué obligaciones pueden corresponder; el calendario indica cuándo resultan aplicables. Ninguna de las dos escalas sustituye la prioridad interna de control.

Tras la entrada en vigor del AI Omnibus el 27 de julio de 2026, las obligaciones para los sistemas de alto riesgo del anexo III se aplicarán desde el 2 de diciembre de 2027. El artículo 50 se aplica con carácter general desde el 2 de agosto de 2026. Como excepción transitoria, los proveedores de sistemas que generen contenido sintético y que hayan sido introducidos en el mercado antes de esa fecha tienen hasta el 2 de diciembre de 2026 para cumplir su apartado 2. El Reglamento (UE) 2026/1744 recoge esa transición.

El artículo 4 reformado exige que proveedores y responsables del despliegue adopten medidas para apoyar la alfabetización en IA. Abarca a su personal y a quienes operen o usen sistemas en su nombre. Las medidas deben atender a sus conocimientos, experiencia, formación, contexto de uso y personas afectadas. Es un deber más amplio que formar solo a quienes supervisan un sistema de alto riesgo.

El plazo adicional no justifica esperar. Inventariar proveedores, reconstruir procedencia, aislar instituciones, crear un flujo de apelación o renegociar un contrato puede llevar más de un curso académico. Además, el RGPD, la seguridad, la protección del consumidor y las obligaciones educativas siguen aplicándose cuando correspondan.

Convertir cada caso en un expediente vivo

El expediente es la pieza que une gobierno y operación. Debe permitir que una persona ajena al proyecto reconstruya qué se autorizó, por qué, con qué límites y en qué resultados de evaluación y documentos se basó la autorización; no hace falta que tenga cien páginas.

Lo dividiría en siete apartados:

1. Propósito y límites. Resultado educativo u operativo esperado, métricas asociadas, población, situaciones excluidas y usos razonablemente previsibles.
2. Clasificación. Análisis jurídico, nivel interno, derechos afectados y justificación de las excepciones aplicadas.
3. Datos y proveedores. Fuentes, base jurídica, minimización, residencia, retención, subencargados y política de entrenamiento.
4. Cadena de actuación. Qué salida produce la IA, qué decide una persona, qué actuación ejecuta la plataforma, qué consecuencia se observa y cómo se revierte la actuación o se repara la consecuencia.
5. Evaluación. Conjunto de pruebas, resultados por subgrupos, umbrales, limitaciones y defectos conocidos.
6. Operación. Métricas, alertas, muestreo, incidentes, apelaciones y condiciones de parada.
7. Autorización. Quién autoriza, riesgo residual aceptado, fecha de revisión y cambios que reabren el expediente.

Ejemplo abreviado: comentarios formativos de álgebra

Un caso hipotético permite ver el grado de concreción esperado:

La tabla no demuestra que ese caso deba ser P2 en cualquier plataforma. Muestra qué información debe quedar visible para que el equipo pueda discutir la clasificación, exigir resultados de evaluación y autorizar o rechazar el caso.

El expediente distingue tres responsabilidades: el responsable del caso lo mantiene, el responsable del riesgo acepta el riesgo residual y el equipo de operaciones ejecuta las decisiones y puede suspender el sistema dentro de los límites delegados de antemano. La matriz posterior asigna quién propone, valida y autoriza cada decisión; estos nombres no sustituyen cargos concretos.

El expediente debe actualizarse cuando cambia el sistema. Una nueva versión del modelo, un corpus distinto, otra población, un cambio de finalidad o la automatización de un paso antes humano pueden invalidar la autorización anterior. La autorización solo ampara una configuración concreta, no una marca para siempre.

El AI Risk Management Framework 1.0 de NIST (2023) organiza el trabajo en cuatro funciones: gobernar, mapear, medir y gestionar. Mapear significa establecer las circunstancias de uso. El Reglamento exige además un sistema continuo de gestión del riesgo para los sistemas de alto riesgo. El expediente reúne en un documento versionado las circunstancias de uso, las mediciones, las actuaciones y las autorizaciones. Lo comparten los equipos de producto, ingeniería, seguridad, privacidad y dirección académica.

No llamaría a este documento «AI Protection Assessment» como si fuera una figura normativa. Según el caso puede ser necesario realizar una evaluación de impacto relativa a la protección de datos (EIPD), una evaluación de impacto en derechos fundamentales (FRIA), preparar documentación técnica de alto riesgo o llevar a cabo otros análisis internos. Se relacionan, pero no son intercambiables.

Autorizar los datos antes de construir la entrada del modelo

La pregunta no es solo si la empresa protege los datos, sino si el tratamiento de cada dato está autorizado para esa finalidad y si puede conservarse en cada almacén. La información que mejora una respuesta puede aumentar el riesgo: añadir notas, historial, mensajes o datos del aula permite personalizar más, pero también inferir información, filtrarla o conservar más datos de los necesarios.

Aplicaría una autorización explícita por capa:

En una arquitectura para varias instituciones, el identificador de cada una no debería ser una simple etiqueta añadida a la consulta. El control de acceso debe incluirlo en todas las rutas: recuperación, cachés, vectores, exportaciones, observabilidad, soporte y evaluación. Una prueba de aislamiento tiene que intentar obtener datos de otra institución, no limitarse a revisar la configuración.

La promesa «no entrenamos con tus datos» es insuficiente. Hay que saber si el proveedor los conserva, si un subencargado los ve, si alimentan evaluaciones, si se copian a registros y cómo se cumplen la supresión o la limitación del tratamiento. Tampoco debe suponerse que un embedding es anónimo por su nombre técnico: su clasificación como dato personal, dato seudonimizado o dato anónimo exige analizar el sistema y las posibilidades razonables de vinculación en esas circunstancias. El Comité Europeo de Protección de Datos aplica esa evaluación caso por caso a la anonimidad de los modelos de IA.

El consentimiento tampoco es una salida automática. En educación puede no ser libre si negarse perjudica el acceso a una actividad, y con menores exige especial cuidado. El RGPD obliga a justificar finalidad y base jurídica, minimizar, limitar la conservación y diseñar la protección de datos desde el principio. El consentimiento es una base posible en ciertos escenarios, no el nombre genérico de cualquier pantalla de aceptación.

La Ley de Derechos Educativos y Privacidad Familiar de Estados Unidos (FERPA) pertenece a otra jurisdicción. Para las agencias e instituciones educativas que reciben fondos de programas administrados por el Departamento de Educación de Estados Unidos, la excepción del «school official» exige, entre otras condiciones, que el tercero preste una función institucional y quede bajo control directo respecto al uso y mantenimiento de los expedientes. No convierte FERPA en una alternativa al RGPD ni en una certificación global del proveedor. La guía oficial de privacidad educativa de Estados Unidos debe aplicarse a la institución correspondiente.

Por último, anonimizar prompts no corrige una finalidad ilegítima ni hace segura una entrada de datos excesiva. Primero se limita la finalidad y el acceso. Después se seudonimiza o anonimiza lo que sea compatible con la tarea.

Medir la validez pedagógica, no una seguridad aparente

Antes de medir el rendimiento, fijaría dos condiciones centradas en las personas, coherentes con las directrices éticas de la Comisión para educadores y con la orientación de la UNESCO sobre IA generativa en educación. La función no debe sustituir la destreza que el alumno necesita practicar. Cuando su uso no sea imprescindible, debe existir una alternativa sin IA que no lo perjudique.

En EdTech, una respuesta puede ser correcta y, aun así, inadecuada desde el punto de vista pedagógico. Puede dar la solución cuando el objetivo era practicar, utilizar una explicación demasiado avanzada, confirmar una idea errónea del alumno o evaluar una habilidad distinta de la descrita en la rúbrica.

Por eso no aceptaría «usa RAG» como garantía de veracidad. La recuperación puede reducir algunos errores cuando encuentra una fuente pertinente y vigente. No evita recuperar un fragmento incorrecto, interpretar mal una excepción, mezclar versiones ni producir una conclusión que la fuente no sostiene. Por qué un sistema RAG conectado al LMS sigue alucinando desarrolla ese modelo de fallo.

Tampoco fijaría un 85 % o un 90 % universal para derivar a una persona. En los LLM, una puntuación que muestra el producto puede medir probabilidad de tokens, similitud de recuperación, acuerdo entre muestras o un clasificador propio. Ninguna equivale por sí sola a la probabilidad de que una corrección sea justa. Un umbral útil tiene que calibrarse para una tarea, una población y un coste de error concretos.

La evaluación debería cubrir, como mínimo, cinco familias:

Un conjunto de evaluación no debería construirse únicamente con salidas del mismo modelo que se va a juzgar. Necesita ejemplos creados o validados por docentes, casos difíciles, desacuerdos razonables y situaciones en las que el sistema debe abstenerse de responder. También debe representar el idioma y la configuración real del producto.

La equidad no se agota en comparar una media. Conviene mirar falsos positivos y negativos, cobertura, severidad del daño y resultados del recorrido de apelación. Un detector de riesgo que señala en exceso a un grupo puede generar más vigilancia aunque su exactitud agregada parezca aceptable.

Para una evaluación asistida, la propuesta tendría que vincular cada criterio con fragmentos del trabajo. En cómo usar IA con rúbricas y comentarios formativos propongo separar la ayuda formativa de la calificación oficial. Así, un error en la ayuda no modifica una nota y ambos recorridos pueden evaluarse por separado.

Los criterios de aceptación deben fijarse antes de empezar la prueba. Si se eligen después de ver los resultados, el equipo tenderá a llamar aceptable a lo que ya ha construido. Además de mínimos cuantitativos, incluiría defectos que bloquean el lanzamiento aunque sean poco frecuentes: fuga entre instituciones, fabricación de una cita, discriminación grave o imposibilidad de revertir una nota.

Diseñar la supervisión humana y la apelación

«Hay una persona en el bucle» describe una posición en un diagrama, no una protección. La supervisión es efectiva cuando esa persona comprende qué puede hacer el sistema y dónde falla, dispone de tiempo, puede ignorar la salida y tiene autoridad para cambiar la decisión, impedir la actuación o detener el sistema.

El artículo 14 del Reglamento exige que la supervisión de sistemas de alto riesgo permita entender su alcance y sus límites, vigilar anomalías, evitar el sesgo de automatización, interpretar la salida y anularla o parar el sistema. El artículo 26 obliga al responsable del despliegue a asignar la supervisión a personas con competencia, formación, autoridad y apoyo.

La interfaz debe hacerlo posible. Si el profesor solo ve una puntuación y un botón de confirmar, la plataforma le empuja a ratificar. Para revisar una corrección necesita la rúbrica, los fragmentos pertinentes del trabajo, las limitaciones conocidas y una forma sencilla de modificar la propuesta. También necesita saber que su modificación no se utilizará para reentrenar otro sistema sin autorización.

El Reglamento no exige que todos los casos tengan idéntica interfaz ni que cada texto pase por aprobación previa. Exige controles proporcionados. El borrador de un docente puede admitir revisión antes de publicar; una pregunta frecuente puede operar dentro de fuentes y límites; una nota o una exclusión necesita una supervisión humana mucho más fuerte.

La apelación forma parte del diseño, no del servicio posventa. El estudiante debe poder identificar la decisión, conocer los elementos esenciales que la sustentan, aportar información y solicitar una revisión humana. La persona revisora no debería limitarse a ejecutar de nuevo el mismo modelo.

El artículo 22 del RGPD añade garantías ante decisiones basadas únicamente en tratamiento automatizado que produzcan efectos jurídicos o significativos. Según el caso, incluye intervención humana, expresión del punto de vista e impugnación. El análisis depende del flujo real: llamar «recomendación» a una salida no sirve si la plataforma ejecuta la actuación propuesta sin una revisión sustantiva.

La supervisión también falla por carga. Si un docente recibe cientos de propuestas en pocos minutos, el control puede convertirse en un clic mecánico. Yo mediría tiempo de revisión, porcentaje de cambios, discrepancias, colas y apelaciones. Una tasa de confirmación del 99,9 % no demuestra un buen rendimiento; puede demostrar automatización del consentimiento.

Conservar una traza proporcionada

Para explicar una actuación ejecutada hay que conservar su procedencia. Pero guardar todos los prompts y respuestas sin límite crea un segundo repositorio de datos personales, trabajos académicos y contenido sensible. La trazabilidad debe bastar para reconstruir lo ocurrido y limitarse a lo necesario para no ampliar el daño.

Un evento que enlaza salida, decisión, actuación y consecuencia podría tener esta forma conceptual:

traza_id: identificador estable del evento
caso_uso: ficha y versión autorizada
institucion: ámbito institucional seudonimizado
operacion: id, clave para reconocer la misma acción de negocio y transición local
entrada: referencias y huellas, no copias indiscriminadas
fuentes: identificadores, versiones y permisos aplicados
sistema: modelo, reglas, configuración y proveedor
salida_sistema: tipo, estado y métricas calibradas
decision_humana: revisión, decisión, motivo y autoridad cuando exista
actuacion_ejecutada: cambio de estado producido por la plataforma
consecuencia_persona: tipo, severidad, reversibilidad y evidencia observada
entrega: bandeja de salida transaccional, id externo y acuse cuando correspondan
recuperacion_tecnica: conciliación y, cuando proceda, compensación enlazadas
remedio_persona: apelación o reversión enlazadas
tiempos: creación, revisión, aplicación y caducidad

La estructura separa lo que propuso el sistema, lo que decidió una persona, lo que ejecutó la plataforma y la consecuencia observada. Sin esa separación, una auditoría posterior no sabe si investiga el modelo, la política, una decisión humana o el daño producido.

No todo campo necesita el contenido completo. Una huella criptográfica permite comprobar que la rúbrica recuperada coincide con la versión registrada. Para demostrar que fue la que empleó el sistema, la ejecución debe registrar de forma protegida la huella de la rúbrica efectivamente cargada y enlazarla con la configuración y la actuación ejecutada. Una referencia permite recuperar el documento con los permisos correspondientes cuando se abre un incidente. El contenido íntegro solo se conserva si hay una necesidad definida, acceso restringido, cifrado y plazo.

El Reglamento establece funciones de registro para sistemas de alto riesgo. Los responsables del despliegue conservan los registros bajo su control durante un periodo adecuado y, en principio, al menos seis meses, salvo que otra norma aplicable disponga lo contrario. Esta obligación no autoriza a guardar cualquier dato indefinidamente. El RGPD sigue exigiendo minimización y limitación de la conservación.

Detalle para arquitectura: reintentos y efectos externos

Este apartado es para quien diseña integraciones. Si buscas el marco de gobierno, basta con exigir tres capacidades: que los reintentos no dupliquen la actuación cuando el destino pueda reconocerlos y, si no puede, que cualquier duplicado se detecte y repare; que no se pierda un evento entre sistemas; y que el equipo pueda reconstruir qué ocurrió. Puedes continuar en la vigilancia del daño sin entrar en la implementación.

La trazabilidad tampoco evita por sí sola que una acción se repita. La clave idempotente —el identificador que permite reconocer una misma acción aunque se reintente— debe representar de forma estable una acción de negocio y su ámbito institucional. Todos los reintentos reutilizan esa clave. Cuando existe una decisión humana, la operación también queda enlazada con ella.

Consultar el estado antes de escribir no impide que dos reintentos concurrentes avancen a la vez. Una única transacción o escritura condicional debe registrar de forma persistente la reserva de la clave, el cambio de estado local y, cuando haya que publicar un evento, la entrega pendiente en la bandeja de salida. La restricción de unicidad es una defensa dentro de esa operación, no un sustituto de su atomicidad.

Si la acción ocurre en otro sistema, la misma clave debe llegar al destino y el receptor debe descartar duplicados. Una bandeja de salida transaccional —un registro local de entregas pendientes— evita que el evento se pierda entre la escritura local y su publicación, pero puede entregarlo más de una vez. Cuando el destino no puede reconocer duplicados, hacen falta conciliación y compensación; ninguna consulta previa crea una transacción entre sistemas independientes.

Vigilar el daño y operar los incidentes

La monitorización debe detectar daños, no limitarse a medir la disponibilidad. Añadiría señales como:

• incremento de abstenciones, correcciones o apelaciones;
• diferencias de rendimiento entre grupos o idiomas;
• respuestas sin apoyo o con fuentes caducadas;
• acceso denegado o intento de cruzar el aislamiento institucional;
• cambio brusco después de actualizar el modelo, el prompt, el corpus o una regla;
• revisiones humanas demasiado rápidas o colas que impiden intervenir;
• contenido de evaluación filtrado, instrucciones manipuladas o usos no previstos.

Cada señal necesita una persona responsable, un umbral, un periodo de observación y una respuesta prevista. Un indicador en rojo que nadie tiene autoridad para interpretar no es un control.

El botón de parada tampoco debe consistir en apagar toda la plataforma. Conviene poder desactivar por caso de uso, institución, versión o población; volver a un flujo sin IA; preservar los registros del incidente; y avisar a las personas afectadas. La reversión se prueba antes del despliegue.

Un incidente grave puede exigir notificaciones adicionales según el Reglamento, el RGPD, el contrato o la normativa sectorial. El procedimiento interno debe indicar quién clasifica, quién preserva la documentación, quién comunica y quién decide la reanudación. No debería improvisarse cuando ya hay notas o admisiones afectadas.

Hacer que el gobierno acompañe todo el ciclo de vida

La aprobación abre una fase de vigilancia que puede devolver el caso a clasificación, exigir una nueva evaluación o terminar en retirada.

Proponer. Los equipos de producto y dirección académica definen el problema, la alternativa sin IA y la mejora esperada. Si no pueden expresar qué mejora para quién, el caso no avanza.

Clasificar. Los responsables de privacidad, seguridad, asuntos jurídicos y dirección académica analizan finalidad, datos, población, derechos, categoría jurídica y nivel interno. El equipo detiene aquí cualquier práctica prohibida.

Probar. El equipo ejecuta evaluaciones técnicas y pedagógicas con una configuración reproducible. Los casos P1 deberían pasar antes por un modo de observación: producen salidas, pero no alteran todavía el recorrido real.

Aprobar. El cargo identificado en una matriz preaprobada acepta el riesgo residual, los límites, los umbrales, la supervisión y la fecha de revisión. Toda excepción debe tener una persona responsable y una fecha de caducidad definida.

Vigilar. El equipo de operaciones recoge métricas, muestras, incidentes y apelaciones. Si aparece una señal de daño, revisa el caso de inmediato.

Retirar. El equipo desactiva la función, resuelve dependencias, conserva la documentación necesaria y borra lo que ya no tenga finalidad. Retirar también incluye sustituir una versión sin dejar rutas antiguas activas.

El bucle se reabre cuando cambian el modelo, el proveedor, el corpus, el prompt estructural, las reglas o los umbrales. También se reabre si cambian la población, la finalidad o las reglas y permisos que determinan si una salida queda como propuesta o se convierte en una actuación ejecutada, o si una integración aporta datos nuevos. Una modificación técnica aparentemente menor puede alterar de forma sustancial el nivel de riesgo.

Repartir decisiones, no crear un comité ornamental

Un consejo de IA que escucha presentaciones y publica principios no gobierna el producto. Necesita competencias claras para decidir. Debe saber qué puede autorizar, qué debe elevar a otra instancia y quién ordena o ejecuta la suspensión.

El responsable del caso mantiene el expediente y coordina la operación. El responsable del riesgo acepta el riesgo residual y ejerce la autoridad que corresponda al nivel. Pueden ser la misma persona en un caso sencillo, pero son responsabilidades distintas y deben constar por separado.

No todas las funciones requieren una reunión. Los casos P3 pueden seguir un procedimiento simplificado con controles predefinidos. Los P1 necesitan una revisión conjunta porque ninguna especialidad puede aceptar por sí sola el riesgo completo.

La matriz real debe nombrar el cargo, no solo el nivel. Antes de evaluar el primer caso, deben quedar fijados la independencia respecto del equipo proponente, el cuórum, las incompatibilidades, la suplencia, el desempate y el escalado. La matriz también separa quién puede suspender de inmediato de quién puede reanudar. Una etiqueta como «autoridad P2» sin una persona o función institucional preasignada no autoriza nada.

El responsable del caso no es necesariamente quien programó la función. Es quien responde de que la finalidad siga siendo legítima, los resultados de evaluación continúen vigentes y el equipo responda a cada señal. Debe tener autoridad para introducir cambios en el producto; asignar el puesto a alguien sin presupuesto ni autoridad solo desplaza la responsabilidad.

El órgano central sí tiene funciones permanentes:

• mantener criterios comunes de clasificación y documentación;
• resolver excepciones y conflictos entre beneficio esperado, riesgo y derechos;
• revisar la cartera, los incidentes y las diferencias entre instituciones;
• vigilar dependencias de proveedores y concentración tecnológica;
• aprobar el apetito de riesgo y comunicarlo a los equipos;
• mantener medidas de alfabetización en IA adaptadas a quienes operan o usan los sistemas;
• comprobar que las personas que supervisan reciben formación y apoyo.

La dirección académica no debería entrar al final para validar textos. Participa en la definición del objetivo educativo, la elección de métricas y la interpretación de errores. El equipo de seguridad tampoco se limita a una prueba de penetración: revisa inyección de instrucciones, exfiltración, cadena de suministro, aislamiento y abuso.

El equipo de compras puede actuar como un punto de control decisivo. Un contrato debería identificar finalidad, versiones, subencargados, ubicación, retención, uso para entrenamiento, notificación de cambios, acceso a la documentación justificativa, asistencia para atender el ejercicio de derechos, gestión de incidentes y plan de salida. Si el proveedor no puede entregar la información necesaria para clasificar y operar, esa ausencia es un riesgo del producto.

Probar el circuito en 90 días

Para iniciar un programa de gobierno conviene hacer visible la cartera de casos, elegir uno real y demostrar que el circuito puede detener algo antes de redactar un manual exhaustivo.

Este calendario es viable si ya existen patrocinio ejecutivo, un equipo con dedicación, acceso a la cartera y autoridad para detener un caso. No promete completar el cumplimiento en tres meses. Sirve para demostrar el circuito con un piloto P2 acotado. Si el equipo dispone de capacidad, puede añadir un caso P1 en modo de observación para probar el procedimiento de los casos con consecuencias altas sin lanzarlo. Si faltan esas condiciones de entrada, conviene mantener las fases, no el plazo.

Días 1 a 30: inventariar y delimitar

1. Nombra un responsable ejecutivo y un equipo pequeño con producto, academia, ingeniería, seguridad, privacidad y jurídico.
2. Localiza funciones activas, pilotos, compras y usos integrados por terceros. Incluye opciones que cada institución puede activar.
3. Crea la ficha común y clasifica de forma preliminar cada caso. Detén de inmediato prácticas posiblemente prohibidas o usos sin responsable.
4. Dibuja los flujos de datos y revisa contratos de los proveedores más expuestos.
5. Elige un piloto P2 con consecuencias acotadas. Si hay capacidad suficiente, añade un caso P1 en modo de observación; no lo uses como primer lanzamiento.

Al terminar este tramo deben existir una cartera visible, personas responsables, un mecanismo de suspensión operativo y al menos un expediente en marcha; una política redactada no basta.

Días 31 a 60: producir resultados y controles

1. Define conjuntos de prueba por tarea, idioma y población. Incorpora casos de abstención y daño.
2. Versiona la configuración e implanta el aislamiento, la minimización y la traza de la decisión humana.
3. Diseña en la interfaz la revisión, el cambio, la apelación y la derivación a una persona responsable.
4. Escribe umbrales y condiciones de parada antes de evaluar.
5. Ejecuta pruebas pedagógicas, de equidad, privacidad, seguridad y reversión.
6. Realiza antes del despliegue una sesión accesible con alumnado y docentes representativos. Si participan menores, aplica las salvaguardas y autorizaciones que correspondan; registra desacuerdos, cargas y barreras para usar la alternativa o apelar.
7. Documenta defectos conocidos y riesgo residual; no permitas que la media oculte un mal resultado.

El tramo termina cuando la configuración y los resultados de evaluación son reproducibles, no cuando la demostración funciona en una reunión.

Días 61 a 90: autorizar y aprender en producción

1. Emite la primera autorización formal con autoridad, límites, duración y cambios que reabren la revisión.
2. Despliega por cohortes o instituciones, con una alternativa sin IA y la posibilidad de desactivar de forma selectiva.
3. Monitoriza errores pedagógicos, equidad, revisiones, apelaciones e incidentes desde el primer día.
4. Ejecuta, en un entorno aislado y con datos sintéticos, una prueba autorizada que intente cruzar el aislamiento entre instituciones. Ensaya también una actualización defectuosa y una apelación sin afectar a expedientes reales.
5. Revisa el piloto a los 30 días con alumnado y docentes; decide continuar, restringir o retirar.
6. Convierte lo aprendido en patrones reutilizables, sin asumir que las mismas evaluaciones sirven para otro caso.

El piloto se considera operativo cuando existe un expediente versionado, una autorización formal, una alternativa sin IA, una parada ensayada y una revisión con las personas afectadas. Para considerarlo operativo, el piloto debe haber superado todos los criterios que impiden el despliegue dentro del ámbito evaluado y no conservar defectos de ese tipo sin resolver. El expediente debe registrar quién aceptó cada excepción no bloqueante.

Solo puede ampliarse si los resultados de evaluación y las condiciones operativas anteriores se mantienen en la población y las circunstancias de uso autorizadas. Ampliar consiste en automatizar documentación y controles repetibles, no en rebajar la revisión de las funciones con consecuencias altas.

Lista de comprobación de la IA en una plataforma EdTech

Una casilla no demuestra cumplimiento. Cada respuesta afirmativa debe tener un responsable y enlazar al documento, a la configuración, al resultado o al ejercicio que se especifica en su fila. Si nadie puede mostrarlo, la respuesta operativa sigue siendo «no».

La lista es un instrumento de revisión, no un segundo recorrido lineal. Puedes abrir solo el bloque que corresponda a una compra, un despliegue o un incidente, siempre que el expediente conserve la relación con los demás controles.

Antes de completarla, clasifica cada control como universal, condicionado por el nivel o condicionado por el rol y la jurisdicción. Registra cuatro estados: no procede, con justificación, pendiente bloqueante, pendiente no bloqueante y verificado, con enlace al documento, a la configuración, al resultado de evaluación o al ejercicio de la fila. Bloquean cualquier despliegue la ausencia de responsable, finalidad, autorización de datos, autorización formal del despliegue, evaluación pertinente, supervisión humana efectiva y condición de parada. Una práctica prohibida bloquea el caso; una carencia de vigilancia obliga a corregir la operación o restringirla.

1. Inventario y clasificación

• Caso acotado. ¿La ficha describe una finalidad, población y entrada concretas, además de la salida del sistema, la decisión humana cuando proceda, la actuación ejecutada y la consecuencia para la persona? — Responsable: producto. Acreditación: ficha versionada.
• Cadena completa. ¿Están inventariados modelos, reglas, corpus, integraciones y proveedores que participan? — Responsable: arquitectura. Acreditación: diagrama y catálogo de dependencias.
• Definición de IA. ¿Se ha comprobado si la función entra en la definición del Reglamento, en vez de asumirlo por su nombre? — Responsable: jurídico y arquitectura. Acreditación: análisis razonado.
• Anexo III. ¿Se ha analizado si interviene en admisión, evaluación, dirección del aprendizaje, nivel o vigilancia automatizada de pruebas? — Responsable: jurídico. Acreditación: clasificación del caso.
• Prácticas prohibidas. ¿Se ha descartado el reconocimiento de emociones a partir de datos biométricos en educación, la categorización biométrica para deducir las características sensibles del artículo 5.1.g y los demás usos prohibidos? — Responsable: jurídico y producto. Acreditación: clasificación jurídica y resultados de pruebas funcionales.
• Nivel interno. ¿Se ha asignado P0, P1, P2 o P3 según sus consecuencias y no solo por categoría legal? — Responsable: responsable del riesgo. Acreditación: matriz de consecuencias.
• Cambios materiales. ¿Está definido qué modificación obliga a reclasificar? — Responsable: gobierno de IA. Acreditación: política de cambios.
• Autorización formal. ¿El cargo preasignado ha aprobado la configuración versionada, el riesgo residual, los límites, la duración y las condiciones de reapertura? — Responsable: cargo autorizado y responsable del riesgo. Acreditación: resolución enlazada al expediente y al manifiesto de despliegue.

2. Datos, privacidad y fuentes autorizadas

• Finalidad y base jurídica. ¿Cada categoría de datos tiene una finalidad necesaria y una base jurídica documentada? — Responsable: protección de datos. Acreditación: registro de tratamiento.
• EIPD. ¿Se ha determinado si el tratamiento exige una evaluación de impacto de protección de datos? — Responsable: delegado de protección de datos (DPD). Acreditación: cribado y EIPD cuando proceda.
• Minimización. ¿La llamada omite atributos que no cambian la tarea? — Responsable: producto y datos. Acreditación: contrato de datos y prueba.
• Aislamiento multitenant. ¿El control de acceso por institución se aplica en recuperación, vectores, cachés, trazas, soporte y evaluación? — Responsable: seguridad. Acreditación: pruebas negativas entre instituciones.
• Entrenamiento. ¿El uso para mejora o entrenamiento está separado de la inferencia y desactivado por defecto? — Responsable: compras y privacidad. Acreditación: configuración y contrato.
• Retención y derechos. ¿Prompts, salidas, embeddings, muestras y resultados de evaluación del sistema tienen plazo, responsable y proceso de acceso, supresión o limitación? — Responsable: privacidad y plataforma. Acreditación: calendario y simulación.
• Transferencias y subencargados. ¿Se conocen ubicación, cadena de proveedores y mecanismo de transferencia? — Responsable: compras y jurídico. Acreditación: anexos contractuales.
• Menores y alternativa. ¿El recorrido de consentimiento, sus pantallas y la alternativa evitan forzar la aceptación y ofrecen una vía no perjudicial cuando sea necesaria? — Responsable: producto y privacidad. Acreditación: recorrido de usuario.

3. Rendimiento, pedagogía y equidad

• Diseño del objetivo educativo. ¿Se ha definido qué resultado debe mejorar la función y cómo se comprobará que no sustituye la habilidad que se pretende enseñar? — Responsable: dirección académica. Acreditación: hipótesis, comparador y protocolo.
• Resultado observado. ¿La evaluación identifica población, comparador, ventana, métrica primaria, margen o regla de decisión y resultado obtenido? — Responsable: evaluación y dirección académica. Acreditación: informe versionado y decisión adoptada conforme a los criterios previos.
• Corpus gobernado. ¿Las fuentes tienen responsable, vigencia, permisos y reglas de retirada? — Responsable: contenido. Acreditación: catálogo de fuentes.
• Conjunto de prueba. ¿Representa tareas reales, idiomas, accesibilidad, casos difíciles y situaciones en las que el sistema debe abstenerse de responder? — Responsable: evaluación. Acreditación: versión, procedencia, matriz de cobertura y huecos conocidos.
• Criterios previos. ¿Los umbrales y los defectos que impiden el despliegue se fijaron antes de ver los resultados? — Responsable: responsable del riesgo. Acreditación: plan de evaluación fechado.
• Resultados desagregados. ¿Se miden errores y daños por los grupos relevantes, no solo la media? — Responsable: evaluación y academia. Acreditación: informe.
• Revisión experta. ¿Docentes cualificados han valorado utilidad, nivel, comentarios formativos y posibles atajos? — Responsable: dirección académica. Acreditación: muestras y desacuerdos.
• Límites visibles. ¿Se documentan cobertura, defectos conocidos y usos para los que la función no se ha validado? — Responsable: producto. Acreditación: instrucciones y ayuda.

4. Transparencia, supervisión y apelación

• Interacción identificada. ¿La persona sabe cuándo interactúa directamente con una IA, salvo que resulte obvio por las circunstancias? — Responsable: diseño. Acreditación: pantallas y pruebas.
• Contenido sintético. ¿Se aplica el marcado técnicamente exigible y se distingue de las obligaciones de divulgación del responsable del despliegue? — Responsable: plataforma y jurídico. Acreditación: metadatos y política.
• Explicación útil. ¿Una corrección enlaza criterio, fragmentos del trabajo y propuesta, en vez de mostrar solo una nota o una explicación genérica? — Responsable: producto académico. Acreditación: interfaz.
• Autoridad humana. ¿La persona revisora puede ignorar, modificar o anular la propuesta y detener el sistema? — Responsable: operaciones académicas. Acreditación: permisos y simulación.
• Sesgo de automatización. ¿La interfaz evita confirmaciones masivas y muestra incertidumbre y límites relevantes? — Responsable: diseño. Acreditación: prueba con usuarios.
• Apelación. ¿El alumno puede identificar la decisión, aportar información y obtener revisión humana independiente? — Responsable: operaciones académicas. Acreditación: caso simulado y plazos.
• Alternativa y reversión. ¿Existe un flujo sin IA y se puede revertir la actuación ejecutada y reparar su consecuencia? — Responsable: producto y plataforma. Acreditación: ejercicio de reversión.
• Participación previa. ¿Alumnado y docentes representativos han podido detectar antes del despliegue barreras, cargas, problemas de comprensión y efectos pedagógicos? — Responsable: investigación de producto y academia. Acreditación: protocolo, salvaguardas, participantes, desacuerdos y cambios realizados.
• Alfabetización en IA. ¿El personal y quienes operan o usan sistemas en nombre de la organización reciben apoyo adaptado a sus conocimientos, experiencia, formación, contexto y personas afectadas? — Responsable: gobierno de IA y personas. Acreditación: análisis de necesidades, registro fechado de la participación, comprobación práctica adaptada a cada función y mejoras posteriores.

Nota jurídica del control. El artículo 50 del Reglamento no exige la misma señal visible en todo contenido. Los proveedores de sistemas que generan contenido sintético deben garantizar que sus salidas estén marcadas en formato legible por máquina y puedan detectarse como generadas o manipuladas artificialmente. Las soluciones deben ser eficaces, interoperables, sólidas y fiables en la medida técnicamente viable, sin perjuicio de las excepciones concretas del apartado 2. Para textos publicados con el fin de informar sobre asuntos de interés público, la divulgación del apartado 4 no se exige cuando el contenido ha pasado por revisión humana o control editorial y una persona física o jurídica asume la responsabilidad editorial. La interfaz debe aplicar la obligación que corresponda a su función real, no una fórmula indiscriminada.

5. Robustez, seguridad y operación

• Inyección y exfiltración. ¿Se han probado escenarios adversos sin que se produzcan accesos indebidos en el conjunto evaluado, y existen controles externos al modelo que limiten privilegios, validen acciones y reduzcan las consecuencias si el sistema se desvía? — Responsable: seguridad. Acreditación: ejercicio de equipo rojo y controles de autorización.
• Abuso académico. ¿Las defensas distinguen ayuda legítima, respuestas de evaluación y usos no previstos? — Responsable: academia y seguridad. Acreditación: escenarios ejecutados sobre una configuración versionada, resultados, fallos y resolución.
• Versionado. ¿Modelo, reglas, prompt estructural, fuentes y configuración pueden reproducirse? — Responsable: ingeniería. Acreditación: manifiesto de despliegue.
• Trazabilidad mínima. ¿La plataforma separa salida del sistema, decisión humana, actuación ejecutada y consecuencia para la persona sin registrar contenido de más? — Responsable: arquitectura y privacidad. Acreditación: esquema y muestras.
• Control de reintentos y duplicados. ¿Una única transacción o escritura condicional registra de forma persistente la reserva, el cambio de estado local y, cuando corresponde, la entrega pendiente en la bandeja de salida; y el destino descarta duplicados con la misma clave o existe un mecanismo probado para detectarlos, conciliarlos y compensarlos si no puede hacerlo? — Responsable: plataforma. Acreditación: escritura atómica con unicidad y ensayos concurrentes de reintento, entrega duplicada, recuperación, conciliación y compensación.
• Monitorización de daño. ¿Se supervisan los errores pedagógicos, la equidad, las apelaciones y la carga humana, además de la latencia y los fallos técnicos? — Responsable: operaciones de IA. Acreditación: panel y alertas.
• Condiciones de parada. ¿Cada señal tiene umbral, autoridad y acción? — Responsable: responsable del riesgo. Acreditación: procedimiento de guardia.
• Desactivación selectiva. ¿Puede desactivarse una función o versión, o suspenderse en una institución, sin interrumpir todo el servicio educativo? — Responsable: plataforma. Acreditación: simulacro.
• Incidentes. ¿Están definidas la clasificación, la preservación, la notificación, la corrección y la reanudación? — Responsable: seguridad y cumplimiento. Acreditación: procedimiento de respuesta y ejercicio.

6. Proveedores, documentación y ciclo de vida

• Información suficiente. ¿El proveedor entrega finalidad, funciones, límites, versiones, datos, métricas y apoyo para interpretar salidas? — Responsable: compras. Acreditación: dossier contractual.
• Cambios y subencargados. ¿Debe avisar antes de cambiar modelo, ubicación, política de datos o cadena de suministro? — Responsable: compras. Acreditación: cláusulas y registro.
• Obligaciones de rol. ¿Está claro cuándo la organización actúa como proveedor, responsable del despliegue, importador, distribuidor o fabricante? — Responsable: jurídico. Acreditación: mapa de roles.
• FRIA. ¿Se ha determinado si el responsable del despliegue debe evaluar el impacto en derechos fundamentales? — Responsable: jurídico y derechos fundamentales. Acreditación: cribado y evaluación.
• Conformidad. Para los sistemas de alto riesgo, ¿se dispone de la documentación y del procedimiento de evaluación de conformidad que corresponda al rol y al sistema? — Responsable: cumplimiento. Acreditación: expediente y declaración aplicable.
• No dependencia de una certificación. ¿La institución conserva la posibilidad de verificar el sistema y mantenerlo en funcionamiento, aunque el proveedor muestre sellos o informes? — Responsable: gobierno de IA. Acreditación: pruebas propias.
• Vigilancia posterior. ¿Hay revisión periódica y extraordinaria tras cambios o incidentes? — Responsable: responsable del caso. Acreditación: calendario y actas.
• Salida. ¿Se pueden exportar datos con su semántica, configuración, versiones y trazas necesarias; cerrar las operaciones pendientes y tramitar las apelaciones; vaciar las entregas pendientes de la bandeja de salida y conciliar las actuaciones ejecutadas; revocar claves y webhooks; acreditar el borrado en subencargados; y sustituir el proveedor? — Responsable: arquitectura y compras. Acreditación: manifiesto de salida probado con resultados y pendientes.

La declaración UE de conformidad y la intervención de un organismo notificado no son requisitos idénticos para cualquier módulo educativo. Dependen de la clasificación, el rol, el tipo de sistema y el procedimiento aplicable. La lista sirve para exigir el expediente correcto, no para presumir que toda EdTech debe contratar la misma auditoría externa.

Cómo demostrar que existe gobierno

Un marco sólido no se reconoce por el número de principios ni por el tamaño del comité. Se reconoce porque la organización puede tomar un caso real y dar respuesta a estas preguntas:

• qué finalidad autorizó y qué usos excluyó;
• qué datos permitió y por qué;
• qué resultados y documentos sostuvieron la autorización;
• quién tuvo autoridad para cambiar la decisión o la actuación ejecutada;
• qué ocurrió cuando el sistema falló;
• cómo se corrigió la consecuencia para la persona;
• qué cambio obligaría a revisar o retirar.

Si la respuesta depende de preguntar al proveedor o de leer el estado actual de la configuración, todavía no hay trazabilidad. Si una alerta no puede detener nada, todavía no hay supervisión. Si el alumno no puede impugnar, todavía no hay control humano completo.

La prioridad es impedir que un fallo opaco se convierta en una consecuencia académica incuestionable, no prometer que la IA nunca fallará. Gobernar significa conservar, desde el diseño, la capacidad de entender lo ocurrido, intervenir y prescindir del sistema.

Este marco es una propuesta de arquitectura y operación, no asesoramiento jurídico. La clasificación y las obligaciones concretas deben determinarse atendiendo al sistema, la jurisdicción, el papel contractual y las circunstancias de uso reales.