Cómo auditar una IA en educación superior
Guía práctica para evaluar propósito, datos, sesgos, supervisión, seguridad y monitoreo antes de desplegar IA en educación superior.
Una plataforma promete identificar estudiantes que necesitan apoyo. Otra ofrece retroalimentación automática. Una tercera clasifica solicitudes, resume evidencias o detecta conductas “anómalas”. La demostración funciona, el proveedor exhibe buenos indicadores y el piloto parece fácil de activar. ¿Es suficiente para usarla con estudiantes, docentes o equipos institucionales? No. Una demostración muestra lo que el sistema puede hacer en condiciones seleccionadas; una auditoría pregunta qué ocurre cuando se usa con datos, personas, reglas y consecuencias reales. Para una institución de educación superior, auditar una IA no consiste en revisar una lista ética al final de la compra. Significa reunir evidencia antes de decidir, probar el sistema en su contexto, definir límites y conservar la capacidad de corregirlo o retirarlo. La exigencia debe ser proporcional: no requiere la misma revisión un asistente para ordenar ideas que un modelo capaz de influir en admisión, calificaciones, beneficios, alertas de permanencia o sanciones académicas. Auditar un uso, no “la IA” en abstracto La unidad de análisis debe ser concreta: un sistema y su versión, aplicado a una finalidad, con determinada población, datos y responsables. Preguntar si una herramienta “es confiable” sin especificar su uso se parece a preguntar si un medicamento es bueno sin mencionar para quién, en qué dosis ni con qué diagnóstico. La lista ALTAI de la Comisión Europea traduce la idea de IA confiable a siete dimensiones: supervisión humana; robustez y seguridad; privacidad y gobernanza de datos; transparencia; diversidad, no discriminación y equidad; bienestar social y ambiental; y rendición de cuentas. Es una referencia útil, pero no un sello que certifique automáticamente un producto. El marco de gestión de riesgos de IA de NIST propone cuatro funciones —gobernar, mapear, medir y gestionar— y su Playbook aclara algo decisivo: sus acciones no forman una receta que deba aplicarse completa e idéntica en todos los casos. La institución necesita adaptar la profundidad de la revisión al riesgo educativo y humano del uso. Primera puerta: ¿hay un problema que justifique usar IA? La auditoría comienza antes de mirar el modelo. El equipo debe describir el problema, a quién afecta, qué resultado espera mejorar y qué alternativa no automatizada existe. “Modernizar” o “innovar” no son propósitos auditables. Si una institución quiere predecir riesgo de abandono, por ejemplo, debe explicar qué acción seguirá a la alerta. Un puntaje sin capacidad de tutoría, apoyo financiero, flexibilidad académica o derivación oportuna solo clasifica dificultades que la institución quizá no está preparada para resolver. Incluso puede estigmatizar a una persona sin entregarle ayuda. Las directrices británicas para adquirir IA recomiendan hacer explícito el beneficio buscado, considerar alternativas y evaluar riesgos desde el inicio de la compra. La pregunta incómoda, pero necesaria, es esta: ¿la IA agrega valor frente a mejorar un proceso, capacitar al equipo o corregir la calidad de los datos? Segunda puerta: datos, privacidad y contrato Un sistema puede funcionar técnicamente y ser inviable por la forma en que obtiene, combina o conserva información. Antes del piloto conviene levantar un inventario: qué datos ingresan, de dónde provienen, con qué base se usan, quién puede acceder, dónde se almacenan, cuánto tiempo se conservan y si el proveedor los reutiliza para entrenar otros modelos. También debe revisarse la pertinencia. Datos históricos no son neutrales: reflejan oportunidades desiguales, decisiones anteriores y vacíos de registro. Un modelo de permanencia puede aprender que trabajar, vivir lejos o pedir ciertos apoyos se asocia con trayectorias más frágiles. La correlación puede ser real, pero no convierte esas características en causas ni autoriza a reducir oportunidades. El contrato debería precisar subcontratistas, ubicación y transferencia de datos, registros disponibles para auditoría, notificación de incidentes, cambios de modelo, portabilidad, eliminación de información y condiciones de salida. Si la institución no puede saber cuándo el proveedor cambió el sistema o recuperar sus datos al terminar la relación, la dependencia tecnológica ya comenzó antes del despliegue. Tercera puerta: evidencia y prueba local Los indicadores comerciales son un punto de partida, no una conclusión. La institución debe conocer sobre qué población, idioma, tarea y condiciones fueron calculados. Un promedio de precisión puede ocultar errores concentrados en sedes, modalidades, disciplinas o grupos determinados. Una prueba local debería usar casos representativos y separar tipos de error. En un sistema de alertas, no es lo mismo dejar sin identificar a alguien que necesita apoyo que etiquetar erróneamente a quien no lo necesita. En una herramienta de evaluación, tampoco son equivalentes una sugerencia imprecisa y una calificación injusta. La gravedad depende de la consecuencia. Antes de probar, el equipo debe definir umbrales: qué resultado permitiría avanzar, qué daño obligaría a ajustar y qué hallazgo detendría el piloto. Establecer esas reglas después de ver los datos facilita justificar retrospectivamente una compra ya deseada. La validación tampoco termina con un único ensayo. Idioma, currículum, población, datos y versión del sistema pueden cambiar. La evidencia debe corresponder al contexto y al momento de uso. Cuarta puerta: supervisión humana que realmente pueda intervenir “Hay una persona en el proceso” suele presentarse como garantía. No siempre lo es. Si esa persona carece de tiempo, información, competencia o autoridad para contradecir el resultado, la supervisión es decorativa. La auditoría debe identificar quién revisa, qué información recibe, cómo documenta discrepancias y cuándo puede pausar el sistema. También debe definir qué decisiones no se delegarán. Cuando una salida incide en admisión, calificación, beneficios, integridad académica, apoyo psicoeducativo o continuidad de estudios, se necesitan explicación comprensible, revisión humana y un canal de impugnación. La Recomendación de UNESCO sobre la Ética de la Inteligencia Artificial ofrece un marco internacional centrado en derechos, dignidad, equidad, transparencia y responsabilidad. Su valor institucional aparece al convertir esos principios en procedimientos: informar a las personas, limitar usos, registrar decisiones y reparar impactos. Quinta puerta: transparencia y documentación La institución necesita una ficha viva del sistema. Debería incluir finalidad y usos prohibidos; versión y proveedor; datos utilizados; desempeño conocido; limitaciones; grupos y contextos no evaluados; responsables; intervención humana; incidentes; cambios y fecha de próxima revisión. Esa documentación no debe quedar encerrada en TI. Las áreas académicas, de calidad, jurídica, datos, seguridad, inclusión y experiencia estudiantil necesitan comprender la parte que les corresponde. Cuando el riesgo es relevante, estudiantes y trabajadores también deben saber que una IA interviene, para qué lo hace y cómo pueden solicitar una revisión. Transparencia no significa publicar código propietario ni entregar detalles que comprometan seguridad. Significa ofrecer información suficiente para comprender el uso, discutir sus límites y atribuir responsabilidad. Sexta puerta: robustez, incidentes y dependencia del proveedor La prueba debe incluir condiciones incómodas, no solo el camino feliz de la demostración. ¿Qué sucede con datos incompletos, consultas ambiguas, instrucciones adversariales, caída de servicios o cambios de volumen? ¿El sistema inventa información? ¿Entrega una confianza aparente cuando debería reconocer incertidumbre? ¿Existe una alternativa manual cuando falla? También se necesita un protocolo de incidentes: quién recibe reportes, cómo se protege a las personas afectadas, qué evidencia se conserva, quién comunica y bajo qué criterio se suspende el uso. Un sistema sin botón institucional de pausa no está realmente bajo control. La salida importa tanto como la entrada. Conviene saber si la institución puede exportar información, migrar configuraciones, mantener continuidad y abandonar al proveedor sin perder procesos críticos. La auditoría debe mirar el costo de revertir, no solo el precio de adoptar. Séptima puerta: monitoreo y renovación Aprobar un piloto no autoriza un uso indefinido. Después del despliegue deben observarse desempeño, errores, reclamos, diferencias entre grupos, intervenciones humanas, incidentes, beneficios y costos. También debe verificarse si el sistema mejora el problema que justificó su adopción. La renovación contractual es una oportunidad para repetir la pregunta inicial: ¿sigue siendo necesario?, ¿funciona mejor que las alternativas?, ¿sus beneficios compensan riesgos y costos?, ¿cambiaron el modelo, los datos o la población?, ¿existen daños que antes no eran visibles? La decisión final no tiene solo dos opciones. Una institución puede aprobar, aprobar con límites, mantener en piloto, exigir correcciones, restringir a usos de bajo riesgo o descartar. Auditar bien también significa aceptar que una tecnología atractiva puede no ser adecuada para ese contexto. Una pauta breve para el comité responsable Antes del despliegue, el equipo debería poder responder con evidencia: ¿Qué problema específico resuelve y por qué IA es una opción proporcional? ¿Qué personas pueden beneficiarse o resultar perjudicadas? ¿Qué datos usa y qué permite el contrato hacer con ellos? ¿Qué desempeño y errores presenta en el contexto local y por grupos pertinentes? ¿Qué decisión conserva una persona y cómo puede corregir, detener o impugnar? ¿Qué información recibirán las comunidades afectadas? ¿Cómo se registrarán versiones, cambios, incidentes y verificaciones? ¿Qué umbral suspende el piloto o el uso? ¿Cómo se medirá el beneficio educativo o institucional prometido? ¿Cómo se sale del sistema sin perder datos, capacidades ni continuidad? La pauta no elimina incertidumbre. Hace algo más realista: obliga a identificarla, distribuir responsabilidades y decidir con mejores antecedentes. En educación superior, una IA no es responsable porque el proveedor lo declare ni porque una política institucional use buenas palabras. Lo es, en la medida en que puede demostrar propósito, límites, evidencia, control humano y capacidad de corrección. La auditoría no frena la innovación; evita que la comunidad educativa pague el costo de una experimentación sin reglas. Si te interesa seguir explorando herramientas para tomar mejores decisiones sobre IA, calidad y transformación institucional, regístrate gratis en InnovacionAcademica.org y participa en una comunidad que busca innovar con evidencia y responsabilidad. Fuentes consultadas Comisión Europea. Assessment List for Trustworthy Artificial Intelligence (ALTAI) . National Institute of Standards and Technology. AI Risk Management Framework 1.0 . NIST. AI RMF Playbook . Gobierno del Reino Unido. Guidelines for AI procurement . UNESCO. Recomendación sobre la Ética de la Inteligencia Artificial .