Hay una sensación engañosa que aparece cuando trabajamos mucho con IA: como la respuesta mejora después de varias correcciones, parece que el sistema también está aprendiendo.
No siempre es así.
Puedes pasar cuarenta minutos corrigiendo un informe, lograr una versión excelente y descubrir al día siguiente que la IA vuelve a cometer exactamente los mismos errores.
No necesariamente falló la corrección. Lo que falló fue otra cosa: la corrección nunca se convirtió en una regla reutilizable.
Corrección y mejora no son lo mismo
Supongamos que pides un análisis comercial y la IA mezcla ventas brutas con ventas netas. Le indicas el error, vuelve a calcular y esta vez lo hace correctamente.
Eso resolvió la salida actual.
Pero si esa definición importa en todos los análisis futuros, todavía falta una decisión: ¿dónde queda registrada?
Si la corrección sólo vive dentro de esa conversación, puede no cambiar el próximo trabajo. En cambio, si se transforma en una definición estable —por ejemplo, “ventas netas = ventas brutas menos devoluciones”— pasa a formar parte del método.
Ahí aparece una diferencia clave.
- Una observación
- “esto está mal”.
- Una corrección
- “cámbialo en esta respuesta”.
- Una mejora del sistema
- “a partir de ahora, cuando ocurra esta situación, aplica este criterio”.
La tercera es la que reduce trabajo repetido.
El error más común: corregir el resultado y no la causa
Cuando una respuesta sale mal, solemos intervenir en el texto visible:
- “hazlo más corto”,
- “no uses esa palabra”,
- “te faltó comparar estas dos cosas”,
- “otra vez mezclaste costos con gastos”,
- “no tomes ese documento viejo”.
Algunas de esas correcciones son puramente editoriales. No necesitan sobrevivir.
Otras revelan un problema más profundo: una definición incorrecta, una fuente mal priorizada, un criterio ausente, una restricción que no quedó clara o una decisión que debería persistir.
Si no distinguimos entre ambos tipos, acumulamos correcciones sin mejorar el proceso.
Una regla práctica: pregunta si el error puede repetirse
Después de corregir algo importante, haz una pregunta adicional:
“¿Esto fue un problema de esta respuesta o un problema del método?”
Si fue sólo de esa salida, corrígela y sigue.
Si puede repetirse, conviene convertir la corrección en una de estas cosas:
- una definición;
- una regla;
- un criterio de revisión;
- una fuente prioritaria;
- una restricción;
- una decisión de proyecto;
- o un paso obligatorio del proceso.
Por ejemplo:
- Corrección local
- “No incluyas ese proveedor en esta comparación.”
- Regla reutilizable
- “En comparaciones futuras, excluye proveedores sin información verificable sobre soporte local.”
- Corrección local
- “El resumen está demasiado largo.”
- Criterio reutilizable
- “Los resúmenes ejecutivos deben permitir entender la decisión principal en menos de un minuto.”
- Corrección local
- “No uses la versión anterior del archivo.”
- Control reutilizable
- “Antes de analizar, confirma cuál es la versión vigente y trata las anteriores como histórico.”
La mejora aparece cuando el aprendizaje deja de depender de recordar una conversación específica.
No toda corrección debe volverse permanente
También existe el riesgo contrario: convertir cada preferencia momentánea en una regla eterna.
Una frase que no gustó, una excepción particular o una decisión tomada para un caso especial no deberían necesariamente gobernar todo lo que venga después.
Por eso una buena regla de persistencia puede ser:
“Conserva sólo aquello que deba modificar decisiones futuras.”
Eso evita dos problemas a la vez: repetir errores y llenar el sistema de instrucciones irrelevantes.
El cierre útil de una sesión
Cuando terminas un trabajo con varias correcciones, revisa las más importantes y clasifica cada una:
- ¿Fue sólo una edición de esta salida?
- ¿Revela una definición que debe quedar estable?
- ¿Cambia una regla de trabajo?
- ¿Modifica una decisión vigente?
- ¿Agrega un criterio de control para la próxima vez?
Si la respuesta es sí en los últimos cuatro casos, no la dejes enterrada en el historial.
Registrala donde realmente pueda influir en el próximo trabajo.
Porque una IA puede producir una versión mejor después de que la corriges. Pero un sistema de trabajo sólo mejora cuando esa corrección cambia lo que ocurre la próxima vez.