UI generativa: cómo validar simulaciones que sí enseñen

La UI generativa permite imaginar un producto que transforma una necesidad de aprendizaje en una experiencia manipulable. Pero que un control se mueva no demuestra que sus efectos sean correctos. Para un equipo de producto, la decisión importante es qué puede variar con cada generación y qué debe seguir siendo verificable. Sin esa frontera, una demostración atractiva puede convertirse en una explicación falsa que el usuario aprende por ensayo y error.

El 17 de septiembre de 2026, Google Research anunció una biblioteca pública de más de treinta interactivos educativos en inglés, generados con IA y revisados por docentes. Es una entrega concreta para explorar el problema. Este artículo propone cinco decisiones de ingeniería para evaluar iniciativas similares; son recomendaciones editoriales, no una integración probada por Wasyra ni una afirmación de eficacia educativa.

El informe técnico de Google, fechado el 16 de septiembre, describe planificación, objetivos por niveles, generación de interfaz y ayudas. La iteración evalúa aspectos visuales, mecánicos, de solución y de telemetría, utilizando código y ejecución en Chrome. Su evaluación incluye estudios y valoraciones de docentes; no establece por sí sola una mejora causal del aprendizaje de los estudiantes.

La consecuencia arquitectónica que proponemos es tratar cada resultado como software versionado. El prompt es una entrada; el entregable incluye reglas, controles, estados y explicaciones. Si una corrección cambia la fórmula pero conserva una pista escrita para la versión anterior, el producto queda internamente contradictorio. Por eso conviene revisar y publicar el conjunto como una unidad, con evidencia que permita reconstruir exactamente qué recibió cada participante.

Empieza por una acción observable: comparar dos escenarios, predecir un resultado o explicar una decisión. Después especifica las variables permitidas, sus unidades, sus rangos y las relaciones que deben conservarse. Incluye condiciones de éxito y estados imposibles. Una petición como «enseña capacidad de servicio» deja demasiadas decisiones abiertas; un contrato que exige identificar cuándo la demanda supera la capacidad ofrece un criterio comprobable.

Para el primer piloto, separa el núcleo de cálculo de la presentación generada. Mantén las reglas esenciales en funciones revisadas y deja que la IA proponga distribución, contexto y secuencia de ejercicios dentro de límites explícitos. Esta restricción reduce la libertad del generador, pero facilita localizar errores: puedes distinguir un cálculo incorrecto de una etiqueta equivocada o de una interacción que comunica mal un resultado correcto.

Ejemplo hipotético: una empresa quiere entrenar a responsables de soporte con un simulador simplificado. Llegan doce solicitudes por hora y cada persona puede resolver cinco. Con dos personas, la capacidad agregada es diez; bajo esas hipótesis, el trabajo pendiente crece. Con tres, la capacidad es quince. El ejercicio pide anticipar la tendencia antes de mover el control. No representa tiempos de espera reales: excluye variabilidad, descansos y diferencias entre solicitudes.

El evaluador debe calcular esos resultados fuera del código generado. Además, comprobará que el gráfico, el texto y la señal de éxito correspondan al mismo estado. Si la interfaz celebra una respuesta porque el usuario pulsó el botón correcto, aunque la predicción sea incorrecta, la actividad falla. Guarda ejemplos de entrada y salida junto con el artefacto; una captura bonita no sustituye esa comparación.

Organiza tres revisiones con criterios propios. La primera verifica relaciones del dominio mediante casos conocidos y límites. La segunda recorre el producto: teclado, pantalla estrecha, reinicio, cambios rápidos, pistas y persistencia. La tercera observa si una persona puede explicar la relación que acaba de explorar sin copiar la interfaz. Ninguna nota agregada debería ocultar un fallo esencial de las otras dos dimensiones.

En nuestro ejemplo, prueba demanda cero, capacidad cero y el punto exacto de equilibrio. Repite después de cambiar de nivel y después de reiniciar. La revisión humana debe preguntar qué supuestos omite el modelo simplificado y si las ayudas fomentan una predicción o entregan inmediatamente la respuesta. Para medir aprendizaje, diseña una evaluación propia con una tarea nueva; completar la actividad y valorar su apariencia son señales distintas.

Propongo generar durante la preparación y servir versiones aprobadas durante la sesión. Así, el tiempo de revisión no se confunde con la latencia que experimenta el participante. Registra solicitudes, intentos descartados, tiempo de especialistas y coste de mantener cada versión. El indicador útil para decidir un piloto es el coste por actividad aceptada, no el coste de la primera respuesta del modelo.

Fija un límite de intentos y una salida explícita cuando no se alcance la calidad mínima: devolver la solicitud al autor o utilizar una actividad revisada previamente. No relajes la rúbrica para agotar el presupuesto con una publicación. Si cambias modelo, instrucciones o núcleo de cálculo, vuelve a ejecutar los casos conservados. Una variante que corrige el móvil puede alterar accidentalmente el estado de los controles.

Acompaña la actividad con sus objetivos, supuestos, versión y responsable de revisión. Ofrece una forma sencilla de señalar incoherencias. Aísla el contenido ejecutable del resto de la aplicación y limita sus capacidades a lo necesario para practicar. En un piloto, evita introducir datos personales que no aporten al objetivo; usa escenarios sintéticos y decide qué eventos necesitas observar antes de instrumentar todo.

Define quién puede retirar una versión y cómo se recupera una actividad válida. Si detectas una explicación incorrecta, identifica las sesiones afectadas antes de sustituir el archivo. Conserva la evidencia necesaria para revisar el fallo sin guardar conversaciones completas por defecto. La trazabilidad sirve para corregir el producto y sus contenidos, no para asumir que una actividad aprobada seguirá siendo correcta después de cualquier cambio.

La entrega de Google abre una conversación útil para productos educativos y de capacitación: cuánto valor aporta adaptar una experiencia cuando también hay que revisar su comportamiento. Empezaría por un concepto acotado, un responsable del dominio y una actividad de referencia. Mantendría la generación solo si permite una adaptación útil sin trasladar al usuario la tarea de descubrir errores conceptuales.

Si estás evaluando una experiencia de IA a medida, convierte estas cinco decisiones en criterios de aceptación antes de elegir el modelo. Puedes apoyarte en nuestro roadmap de implementación y conversar con Wasyra sobre el alcance de un piloto. El siguiente paso razonable es definir qué debe aprender o decidir el usuario y qué evidencia permitirá aprobar la experiencia.