Una prueba de regresión consiste en repetir, después de cada cambio, un conjunto fijo de casos que el agente ya resolvía bien, para comprobar que sigue resolviéndolos. Hace falta porque con la IA arreglar una cosa puede estropear otra: cambias una instrucción para corregir un fallo y, sin que nadie lo note, el agente empieza a responder peor en un caso que antes dominaba.
Esto no pasa con una hoja de cálculo. Si cambias una fórmula, sabes qué celdas se ven afectadas. Un agente de IA funciona de otra manera: sus instrucciones están escritas en lenguaje normal y el efecto de cada frase sobre el conjunto no se puede calcular de antemano. La única forma fiable de saber si un cambio ha sido bueno es probarlo contra casos reales, siempre los mismos.
Dos tipos de cambio que pueden romper algo
Hay dos momentos en que un agente que funcionaba puede dejar de hacerlo:
- Cambias las instrucciones. Es lo más habitual. Pides que sea más breve, que trate de usted, que no hable de plazos o que añada un aviso. Cada ajuste corrige una cosa y puede alterar otras.
- Cambia el modelo que hay debajo. El agente se apoya en un modelo de IA de un tercero. Si ese tercero lo actualiza o lo retira, el comportamiento puede variar aunque tú no hayas tocado nada.
En ambos casos el efecto suele ser silencioso: no aparece un error, solo una respuesta distinta. Por eso la comprobación debe estar prevista como una rutina y no depender de que alguien se dé cuenta.
Antes y después: un ejemplo con una tienda online
Piensa en una tienda online cuyo agente atiende consultas sobre pedidos y devoluciones. Funciona bien. Un día el dueño se queja de que las respuestas son largas y pide acortarlas. El proveedor modifica la instrucción para que sean más concisas.
- Antes del cambio: ante una devolución fuera de plazo, el agente explicaba la política, ofrecía pasar el caso a una persona y pedía los datos del pedido.
- Después del cambio: las respuestas son más cortas, pero en las devoluciones fuera de plazo el agente ha dejado de ofrecer la opción de hablar con una persona. El cliente se queda sin salida y la queja llega días después.
Si el proveedor hubiera repetido un conjunto de casos entre los que figuraba "devolución fuera de plazo", el fallo se habría visto antes de publicar el cambio. Esa es toda la idea.
¿Qué casos debe incluir ese conjunto fijo?
El conjunto debe parecerse a tu trabajo real y crecer con el tiempo. Una buena base reúne cuatro tipos de casos:
- Los más frecuentes. Las preguntas que el agente recibe a diario, porque son las que más daño hacen si empeoran.
- Los delicados. Reclamaciones, devoluciones, temas de salud o de dinero, y cualquier situación en la que el agente deba pasar a una persona o negarse a responder.
- Los fallos del pasado. Cada error que se detecte y se corrija pasa a formar parte del conjunto, para que no vuelva sin que nadie lo vea.
- Los casos raros. Preguntas ambiguas, mensajes en otro idioma, clientes enfadados, datos que faltan.
Tú aportas el material, porque nadie conoce mejor tus consultas, y el proveedor lo estructura. Los casos se sacan de conversaciones reales, pero deben anonimizarse: quita nombres, teléfonos, direcciones y cualquier dato que identifique a una persona antes de usarlos como ejemplos. Es una cuestión de protección de datos (RGPD), no un detalle opcional.
Una precisión importante: un agente de IA no responde idénticamente dos veces, así que la prueba no consiste en comparar texto palabra por palabra. Se comprueban criterios, como si cita el plazo correcto, si ofrece pasar a una persona o si no inventa un dato, y cuando hay dudas lo revisa un humano.
¿Qué debes pedir al proveedor como parte del servicio?
Pide que las pruebas de regresión formen parte de lo que contratas, no un extra que aparece cuando algo ya ha fallado. En la práctica significa que existe un conjunto de casos acordado, que se ejecuta antes de cada cambio en las instrucciones y cuando el modelo subyacente se actualiza, y que recibes un resumen de lo que se ha comprobado y de lo que ha cambiado. Sin esa disciplina, cada ajuste es una apuesta.
Conviene dejar por escrito:
- El conjunto de casos y quién lo mantiene. Que se amplíe con cada incidencia.
- Cuándo se ejecuta. Antes de publicar cualquier cambio, y también cuando el proveedor del modelo anuncie una actualización.
- Qué recibes. Un informe breve con qué casos pasaron, cuáles no y por qué.
- Quién da el visto bueno. Una persona de tu equipo o del proveedor decide si el cambio se publica cuando hay diferencias.
- Historial de versiones y vuelta atrás. Si un cambio sale mal, debe ser posible regresar a la versión anterior de forma rápida.
Esto enlaza con el seguimiento periódico de la calidad que explicamos en cómo medir el rendimiento de un sistema de IA en tu empresa, y con el deterioro gradual del que habla qué es el data drift.
Qué hace la máquina y qué sigue haciendo una persona
El reparto es sencillo:
- El agente de pruebas (o el sistema que las ejecuta) lanza los casos, recoge las respuestas y marca las diferencias respecto a la versión anterior. Es un trabajo repetitivo que se hace bien en poco tiempo.
- Una persona decide qué es un buen resultado, aporta los casos nuevos, revisa las diferencias dudosas y aprueba el cambio. La máquina puede señalar que algo es distinto, pero no sabe si distinto significa peor para tu negocio.
Cuanto más delicado sea el trabajo del agente, más peso debe tener la revisión humana. Para ver cómo organizarla, puedes consultar cómo mantener supervisión humana en procesos con IA.
Por dónde empezar con algo pequeño
No hace falta montar un sistema complejo el primer día. Empieza con una lista de unos pocos casos escritos en un documento: la pregunta, lo que debe hacer el agente y lo que no debe hacer jamás. Úsala cada vez que se cambie algo. Añade un caso nuevo cada vez que aparezca un fallo. Con el tiempo esa lista se convierte en el activo más valioso del proyecto, porque recoge lo que tu negocio espera de su agente.
Conclusión
Con un agente de IA, cada cambio tiene el potencial de estropear algo que ya funcionaba, y la defensa es repetir siempre los mismos casos antes de publicar. Pedirlo al proveedor como parte del servicio, con casos reales anonimizados, informe de resultados y posibilidad de volver atrás, convierte los ajustes en decisiones informadas.
En MG Solutions construimos agentes de IA específicos para cada empresa, adaptados a tu forma de trabajar y a tus herramientas, no una plantilla genérica, y los acompañamos con un conjunto de casos de prueba construido con los tuyos.
Si quieres ver cómo encajaría en tu empresa, escríbenos y lo hablamos.