Llevas tres semanas con tu agente de IA funcionando y, de repente, responde mal a un cliente importante o se queda callado justo cuando más falta hacía. La pregunta que surge en ese momento no es teórica: ¿a quién escribo ahora mismo? Ya explicamos qué debería incluir un buen contrato de soporte antes de firmar en qué soporte hay tras implantar un agente de IA; este artículo va un paso más allá y responde a la pregunta práctica de qué hacer en el momento exacto en que algo falla, no antes.
Primero, identifica qué tipo de "no funciona" es
No todos los fallos son del mismo tipo, y confundirlos hace perder tiempo a las dos partes. Conviene distinguir entre tres situaciones bien distintas:
- Un bug técnico: el sistema se cae, tarda demasiado en responder, o falla algo que debería funcionar siempre igual (una integración que deja de sincronizar, un mensaje que no llega).
- Un caso no contemplado: el agente responde mal ante una situación real que nadie había previsto al diseñarlo, por ejemplo, una pregunta con una jerga muy específica de tu sector.
- Una expectativa mal calibrada: el sistema hace exactamente lo que se diseñó para hacer, pero no era lo que tú esperabas que hiciera, algo que suele salir a la luz en las primeras semanas de uso real.
Quién resuelve cada tipo y por qué canal
Un bug técnico va directo al canal de soporte técnico, con prioridad alta: es responsabilidad del proveedor y no debería esperar a la siguiente reunión de seguimiento. Un caso no contemplado va al equipo que ajusta el comportamiento del agente, normalmente a través del contacto de proyecto asignado, no de un ticket genérico, porque requiere entender el contexto de tu negocio, no solo reproducir un error. Una expectativa mal calibrada se resuelve mejor en una conversación que en un ticket: a veces el sistema funciona bien y lo que hay que ajustar es lo que se le pidió que hiciera desde el principio.
Qué información llevar preparada para que se resuelva más rápido
Cuanto más contexto lleves al primer mensaje, antes se resuelve. Es útil anotar la hora aproximada en la que ocurrió, una captura o copia exacta de la conversación o el proceso donde ha fallado, qué esperabas que pasara frente a lo que pasó realmente, y si es un caso aislado o se ha repetido más de una vez. Un simple "no funciona bien" obliga al proveedor a reconstruir el caso desde cero, mientras que estos cuatro datos suelen bastar para empezar a investigar en minutos.
Qué es razonable esperar en tiempos de respuesta
No todo requiere la misma urgencia. Un fallo que afecta a clientes en este momento debería tener una respuesta en horas, no en días. Un caso no contemplado que no bloquea nada, pero que conviene ajustar, puede esperar razonablemente a la revisión semanal o quincenal, según el volumen de tu proyecto. Si tu contrato de soporte no deja claro qué tiempo corresponde a cada tipo de incidencia, ese es precisamente el vacío que detallamos en el artículo sobre qué es un SLA en un servicio de agentes de IA.
Cuándo escalar
Si pasan más de dos o tres días sin respuesta a algo que afecta a clientes reales, o si el mismo problema se repite después de haberlo reportado como resuelto, es momento de escalar por encima del canal habitual, ya sea pidiendo hablar con un responsable del proyecto o revisando el contrato para ver qué compromiso concreto se ha incumplido. No es un gesto agresivo, es simplemente hacer valer lo que ya se pactó.
Si el fallo ya ha llegado a un cliente, qué hacer mientras se resuelve
Reportar la incidencia al proveedor no soluciona el problema en el momento en que un cliente tuyo ya ha recibido una respuesta equivocada o se ha quedado sin respuesta. Mientras se investiga y se corrige, tiene sentido activar en paralelo un plan mínimo: avisar al equipo humano que puede intervenir directamente con ese cliente concreto, y si el fallo afecta a un proceso que varios clientes pueden estar experimentando a la vez, valorar si conviene pausar temporalmente esa función del agente en lugar de dejar que siga repitiendo el mismo error mientras se investiga la causa. Esta decisión —pausar una función completa frente a dejarla activa mientras se corrige— depende del volumen de clientes afectados y de la gravedad del error, pero conviene tenerla decidida de antemano con el proveedor, no improvisarla la primera vez que ocurre.
Qué pasa si el "fallo" en realidad viene de tu lado
No todos los casos en los que algo "no funciona como esperabas" son responsabilidad del proveedor. Es habitual que una empresa cambie una política de envíos, actualice un precio o modifique un proceso interno sin avisar a quien mantiene el agente de IA, y luego se sorprenda de que el sistema siga dando la respuesta antigua. En ese escenario, quien tiene que iniciar el contacto sigue siendo tu empresa, pero el mensaje correcto no es "esto está roto", es "hemos cambiado esto, hay que actualizar el agente". Distinguir bien este caso evita fricciones innecesarias con el proveedor y acelera la solución, porque no se trata de una incidencia que investigar, sino de un ajuste que aplicar. Llevar un registro interno sencillo de qué cambios de proceso se han comunicado y cuándo ayuda a que este tipo de casos no se acumulen silenciosamente hasta convertirse en varios pequeños fallos a la vez.
Conclusión
Saber con quién hablar cuando algo no funciona como esperabas no debería ser algo que descubras por prueba y error el día que lo necesitas. Debería ser tan claro como saber a quién llamar si se avería la caldera de la oficina: un canal, una persona y un tiempo de respuesta conocidos de antemano. En MG Solutions asignamos una persona de contacto directa a cada proyecto, no un ticket genérico que se pierde en una cola. Reserva tu primera reunión y te explicamos exactamente cómo funcionaría el acompañamiento en tu caso.