"Ahora que lo veo funcionando, quiero que responda distinto en este caso concreto." Es, con diferencia, una de las frases que más escuchamos en las primeras semanas después de poner en marcha un agente de IA. Es una reacción natural: hasta que no ves el sistema trabajando con casos reales, es difícil anticipar todos los matices que querrás ajustar. La buena noticia es que sí, normalmente se pueden pedir cambios sobre la marcha sin rehacer el proyecto desde cero. La pregunta importante no es si se puede, sino qué tipo de cambio es, y eso determina si el ajuste tarda minutos o requiere una fase de prueba antes de aplicarlo en real.
No todos los cambios son iguales, y eso está bien
Antes de nada, vale la pena entender por qué un proveedor serio no te dice simplemente "sí, cualquier cambio se aplica al instante". Un agente de IA en producción está tomando decisiones reales sobre clientes reales, y un cambio mal probado puede introducir un problema nuevo mientras se intenta resolver uno pequeño. Distinguir el tipo de cambio antes de pedirlo ayuda a poner expectativas correctas sobre cuánto va a tardar.
Cambios de contenido o tono: rápidos, casi siempre en horas
Ajustar cómo se formula una respuesta, cambiar el tono en un tipo concreto de mensaje, corregir un dato desactualizado (un horario, un precio, una política) o añadir una pregunta frecuente nueva son cambios de bajo riesgo que la mayoría de proveedores serios aplican en cuestión de horas, sin necesidad de una fase de pruebas extensa. Si estos cambios te tardan semanas en llegar, es una señal de que el proveedor no tiene un proceso ágil de mantenimiento, no de que el cambio en sí sea complicado.
Cambios de reglas de negocio: necesitan una validación breve
Cambiar un umbral de decisión —por ejemplo, a partir de qué importe una acción necesita aprobación humana—, añadir una nueva excepción a una regla existente, o modificar qué información pide el agente antes de continuar, son cambios que sí conviene probar brevemente antes de activarlos en real, porque pueden interactuar con otras reglas ya existentes de formas que no siempre son evidentes a simple vista. Un plazo razonable para este tipo de cambio suele ser de días, no de semanas.
Cambios de alcance: son, en la práctica, un proyecto nuevo pequeño
Pedir que el agente empiece a hacer algo que no hacía antes —gestionar un canal nuevo, cubrir un tipo de caso completamente distinto, integrarse con un sistema al que no estaba conectado— no es un "ajuste sobre la marcha" en sentido estricto, es una ampliación del proyecto original, y merece tratarse con el mismo rigor de diseño y prueba que el despliegue inicial. Nombrarlo correctamente desde el principio evita la frustración de esperar que algo así se resuelva "en un par de días" cuando en realidad requiere una fase de diseño propia.
Cómo pedir bien un cambio para que se resuelva rápido
La forma en que se pide un cambio influye mucho en cuánto tarda en aplicarse. Pedir "que responda mejor a las quejas" da mucho menos que trabajar que pedir "cuando un cliente use estas dos palabras concretas, quiero que ofrezca directamente hablar con una persona en lugar de intentar resolverlo él mismo". Cuanto más concreto sea el ejemplo real que acompaña la petición —una conversación real donde el comportamiento actual no encajó—, más rápido se puede diagnosticar si el cambio es de los sencillos o de los que necesitan más cuidado.
Qué se prueba antes de aplicar un cambio en real
Un proceso de cambio serio no consiste en modificar directamente lo que está en producción. Lo habitual es aplicar el cambio en un entorno de prueba, comprobar con varios casos representativos —incluyendo los que ya funcionaban bien antes, para confirmar que el cambio no los rompe— y solo entonces activarlo para todos los clientes. Este paso final de comprobación no es burocracia innecesaria: es lo que evita que un ajuste pensado para resolver un caso concreto introduzca, sin que nadie lo note, un problema nuevo en otro caso que hasta entonces funcionaba perfectamente.
Esto no es lo mismo que corregir un proyecto que falla
Es importante no confundir pedir cambios normales de iteración con la situación de un proyecto que no está dando los resultados esperados y necesita un diagnóstico de fondo. Si lo que buscas es ajustar matices puntuales sobre un sistema que en general funciona bien, estás en el terreno de este artículo. Si el problema es más estructural —el agente falla de forma sistemática, no solo en casos puntuales—, el proceso correcto es otro, y lo explicamos en cómo ajustar un proyecto de IA que no está funcionando.
Quién debe poder pedir estos cambios dentro de tu empresa
Una duda frecuente es si estos cambios los debe canalizar siempre una única persona o si cualquiera del equipo puede pedirlos directamente al proveedor. Lo razonable es tener un único punto de contacto interno que centraliza las peticiones, las prioriza y evita que lleguen al proveedor cambios contradictorios pedidos por distintas personas sin coordinación entre ellas. Esta figura suele coincidir con la persona que ya tiene asignada la responsabilidad de supervisar cómo trabaja el agente día a día, algo que tratamos con más detalle en cómo formar a tu equipo para trabajar con agentes de IA.
Conclusión
Sí, se puede y se debe poder pedir cambios sobre la marcha a un agente de IA ya en funcionamiento: es parte normal de cómo mejora un sistema una vez que se enfrenta a casos reales, no una señal de que algo salió mal en el diseño inicial. Lo importante es entender qué tipo de cambio estás pidiendo, aportar ejemplos concretos, y aceptar que los cambios de reglas de negocio necesitan una validación breve antes de aplicarse a todos los clientes. En MG Solutions incluimos este proceso de iteración como parte del servicio, no como un extra que hay que negociar cada vez. Reserva una primera reunión si quieres saber cómo funcionaría en tu caso.