Hay una frase que suena muy bien y, a la vez, no dice casi nada:
Tenemos feedback de usuarios.
Vale. ¿Y eso qué significa exactamente?
Porque bajo esa etiqueta puedes meter cosas muy distintas: un alumno que reporta que una respuesta de test está mal, alguien que dice que una explicación no se entiende, un pulgar abajo en una pantalla, una valoración después de usar una funcionalidad, o un comentario libre del tipo “esto me confunde”.
Todo eso es feedback, sí. Pero tratarlo igual es una receta bastante buena para crear una bandeja de ruido.
Este artículo forma parte de la serie AI Product Engineering sin humo, donde estoy ordenando aprendizajes de producto, arquitectura y equipos al llevar IA a sistemas reales.
Lo esencial es que, en un producto educativo, no hay un único loop de feedback. Hay al menos dos:
- Un loop de calidad editorial: ¿esto que enseñamos o preguntamos es correcto?
- Un loop de producto: ¿esto ayuda al usuario, le aporta valor o le está molestando?
Parecen primos. No lo son tanto.
Cuando el usuario no opina: detecta una posible avería
El caso más claro es el usuario que reporta una pregunta.
Imaginemos algo sencillo: está haciendo un test, marca una opción, el sistema le dice que está mal, y el usuario responde algo como:
Creo que esta pregunta tiene mal la respuesta correcta.
Esto no es una “opinión de producto” en el sentido blando del término. Es una posible avería editorial.
Y una avería editorial tiene una cadena de evidencias detrás: el enunciado, las opciones, la respuesta marcada como correcta, la explicación, el contenido didáctico asociado y el propio reporte del usuario.
Antes, resolver esto era trabajo manual puro:
- leer el reporte;
- localizar la pregunta;
- entender qué está discutiendo el usuario;
- revisar el contenido relacionado;
- decidir si el usuario tiene razón;
- escribir una respuesta;
- y, si hacía falta, preparar la corrección.
No es un trabajo intelectualmente imposible, pero sí es un pateo. Sobre todo cuando se repite muchas veces y cada caso requiere abrir tres o cuatro piezas distintas de contexto.
La parte interesante es que este flujo es muy buen candidato para un agente.
No para que “decida la verdad” y publique cambios alegremente. Eso sería una barbaridad. Sino para que haga de preparador editorial: lee el reporte, contrasta la pregunta con el contenido asociado, explica si ve un error real o no, propone una respuesta al usuario y, cuando procede, deja un borrador de la actividad corregida.
Aquí aparece una conexión bastante directa con el problema del RAG útil. El agente no puede limitarse a buscar un trozo parecido. Tiene que saber qué piezas del expediente abrir: pregunta, explicación, contenido asociado, norma o sección de temario, reporte del usuario y estado de publicación. Sin ese contexto, la respuesta puede sonar bien y aun así ser editorialmente inútil.
El humano ya no empieza desde cero. Empieza desde una propuesta razonada.
Esto cambia mucho el coste del loop.
Antes el feedback era una tarea editorial pendiente. Ahora puede convertirse en una cola de decisiones preparadas: aceptar, ajustar o rechazar. Sigue habiendo responsabilidad humana, pero el trabajo mecánico baja muchísimo.
¿Qué nos enseña esto? Que la IA aporta más cuando no la usas como juez final, sino como alguien que llega a la reunión con el expediente leído.
El mismo patrón en el material de estudio
Con el contenido didáctico pasa algo parecido.
Un usuario puede reportar que una explicación no se entiende, que hay una contradicción, que falta un matiz o que una parte del temario parece incorrecta. Aquí ya no estás corrigiendo una pregunta concreta. Estás revisando una pieza del material que sostiene el aprendizaje.
El mecanismo, sin embargo, es casi el mismo:
- llega el reporte;
- el sistema localiza el contenido afectado;
- el agente lee el contexto relacionado;
- propone una interpretación: error real, mejora de claridad, caso dudoso o reporte no aplicable;
- si toca, prepara una propuesta de corrección;
- una persona valida antes de tocar el contenido publicado.
La gracia no es “automatizar contenido”. La gracia es reducir el tiempo entre una señal útil de usuario y una mejora editorial revisable.
Dicho en limpio: el usuario no solo se queja; ayuda a entrenar la calidad del producto. Y el agente convierte esa ayuda en algo que el equipo puede procesar sin morir en tareas pequeñas.
El otro feedback: producto, fricción y valor percibido
Luego está el segundo carril, que es muy distinto.
Aquí no estamos preguntando si una respuesta era correcta. Estamos preguntando si una parte del producto funciona para la persona que la usa.
Para eso tienen sentido campañas dentro de la aplicación: un widget pequeño, un pulgar arriba o abajo, una valoración rápida, una pregunta contextual, un comentario libre después de usar una funcionalidad.
Este feedback no busca una verdad factual. Busca señal de producto:
- esta pantalla se entiende;
- este flujo genera fricción;
- esta funcionalidad aporta valor;
- este cambio pasa desapercibido;
- el usuario esperaba otra cosa;
- algo le hizo perder confianza.
Aquí un comentario individual puede ser oro, pero también puede ser solo una anécdota.
Este carril tiene más que ver con producto que con corrección. No busca una verdad única, sino patrones. En ese sentido se parece al cambio de rol que describía al hablar del cambio de paradigma en la programación: la IA no elimina el criterio humano, pero sí permite movernos antes hacia diseño de sistemas, lectura de señales y revisión de propuestas.
Si alguien dice “esto no me gusta”, no puedes ignorarlo, pero tampoco deberías convertirlo automáticamente en roadmap. La pregunta buena es otra:
¿Cuánta gente lo está diciendo? ¿En qué punto del flujo aparece? ¿A qué tipo de usuario le pasa? ¿Qué estaba intentando conseguir? ¿Qué cambió después?
Por eso este feedback necesita más agregación que expediente. Necesita contexto de captura: dónde se preguntó, cuándo, a quién, con qué texto exacto y después de qué acción.
Sin eso, los comentarios libres son como mirar una pared llena de post-its. Hay información, sí, pero cuesta convertirla en decisión.
La trampa: mezclar los dos carriles
El error fácil es meterlo todo en el mismo backlog.
Una pregunta posiblemente incorrecta, una explicación confusa, un pulgar abajo en una pantalla, una queja de UX y una sugerencia comercial. Todo junto. Todo con la misma etiqueta de “feedback”.
Ahí empiezan los problemas.
Un reporte editorial necesita evidencias y resolución: correcto, incorrecto, dudoso, corregido, respondido. Un feedback de producto necesita patrones: volumen, segmento, recurrencia, impacto, oportunidad.
Si los mezclas, pasan dos cosas malas.
La primera: los errores de contenido se tratan como opiniones. Eso es peligroso, porque si algo está mal, hay que corregirlo.
La segunda: las señales de producto se tratan como tickets individuales. Eso también es peligroso, porque puedes acabar sobrerreaccionando a una anécdota.
La separación de carriles no es burocracia. Es higiene mental.
IA como acelerador del loop, no como propietario del criterio
La IA encaja muy bien en ambos carriles, pero con roles distintos.
En calidad editorial, actúa como preparador:
- recoge el caso;
- lee contexto;
- compara;
- argumenta;
- propone respuesta;
- prepara borrador de corrección.
En producto, actúa más como analista:
- agrupa comentarios;
- resume temas recurrentes;
- detecta fricciones;
- separa señal de ruido;
- ayuda a formular hipótesis.
Pero hay una línea que conviene no cruzar.
El agente puede acelerar muchísimo el camino hasta una propuesta. No debería ser quien cierre el loop sin supervisión cuando hay criterio editorial, impacto de producto o comunicación con usuarios.
La parte reutilizable no es “meter IA en feedback”. Es diseñar el mecanismo: qué contexto lee, qué propuesta genera, qué evidencia deja y dónde entra el humano. Sin eso, el agente solo produce otra opinión más rápida.
Esto conecta con una idea más general: la IA no hace valioso un proceso roto. Lo hace más rápido. Si el loop no está bien diseñado, solo aceleras la confusión.
Cierre: el feedback no sirve si no activa un mecanismo
Me interesa cada vez menos la frase “escuchar al usuario” como consigna genérica. Escuchar está bien, claro. Pero el valor aparece cuando sabes qué mecanismo se activa después.
Si el usuario reporta una pregunta, quiero un loop editorial: evidencia, contraste, propuesta, validación y respuesta.
Si el usuario valora una funcionalidad, quiero un loop de producto: captura contextual, agregación, lectura, hipótesis, decisión y seguimiento.
La pregunta práctica es sencilla:
Cuando entra feedback, ¿sabemos si estamos ante una posible corrección editorial o ante una señal de producto?
Si no sabemos responder a eso, no tenemos un feedback loop. Tenemos una bandeja de entrada con buena intención.