Plan ante interrupciones de un agente de IA: qué sigue funcionando
Plan ante interrupciones de un agente de IA para dueños de negocio: conserva cada solicitud, cambia al control humano y restablece el servicio sin perder registros del CRM ni el contexto del cliente.
Un plan para interrupciones de un agente de IA debe responder una pregunta antes de que algo falle: ¿qué puede seguir haciendo el negocio cuando el proveedor del modelo, el CRM, el calendario o la conexión de mensajería dejan de responder?
Mi respuesta nunca es “esperar al proveedor”. Las solicitudes nuevas deben conservarse, las acciones riesgosas deben detenerse y el dueño debe recibir una alerta clara con una forma de tomar el control desde su teléfono. La interrupción puede ser responsabilidad de un proveedor. El plan operativo sigue siendo responsabilidad del negocio.
Una interrupción no es una sola falla
Un plan útil para interrupciones separa el componente que falló del resto del flujo de trabajo. Si una conexión falla, toda la operación no debería quedar ciega, en silencio ni actuar de forma destructiva.
Un agente suele funcionar entre varios sistemas. Un cliente envía un mensaje. Un modelo lo interpreta. El agente consulta el contexto, escribe una nota en el CRM, revisa un calendario y envía una respuesta. Cualquiera de esos pasos puede fallar mientras los demás siguen funcionando correctamente.
Esa diferencia determina la respuesta.
Si el modelo no está disponible, el agente debe conservar la solicitud entrante y evitar inventar una respuesta. Si HubSpot no está disponible, puede guardar una nota estructurada en una cola persistente y escribirla más tarde. Si Google Calendar no está disponible, debe dejar de prometer horarios para citas. Si Telegram no está disponible, necesita una segunda vía de alerta en lugar de fingir que se notificó al dueño.
Una sola luz roja de estado no es suficiente. Quiero que la implementación identifique qué dependencia falló, cuándo falló y qué tareas están esperando que vuelva a funcionar.
¿Qué debería seguir funcionando durante una interrupción del proveedor de IA?
La recepción de solicitudes, las marcas de tiempo, los mensajes originales de los clientes y las alertas para personas deberían seguir funcionando siempre que la infraestructura circundante lo permita. Las nuevas acciones externas deberían pausarse cuando el agente no pueda verificar que sean seguras.
El mecanismo de respaldo es deliberadamente sencillo:
| Componente que falló | Lo que hace el agente | Lo que recibe el dueño |
|---|---|---|
| Proveedor del modelo | Almacena la solicitud; no envía respuestas inventadas | Una alerta junto con el mensaje original |
| CRM | Pone en cola la nota estructurada para volver a intentarlo | El contexto del cliente y una etiqueta de “CRM pendiente” |
| Calendario | Deja de ofrecer horarios | Una solicitud para reservar manualmente |
| Canal principal del dueño | Usa la vía de respaldo configurada | Información suficiente para tomar el control |
Esto forma parte de una configuración práctica de IA para pequeños negocios: conservar el trabajo, señalar la incertidumbre y dejar el criterio en manos de una persona. No es una excusa para construir un laberinto de respaldos para cada herramienta menor. El mecanismo de respaldo solo necesita proteger la conversación con el cliente y el registro del negocio hasta que vuelva el servicio normal.
La cola importa más que un modelo de respaldo ingenioso
Cambiar a un segundo modelo puede ayudar, pero los registros persistentes importan más. Un modelo de respaldo no sirve de nada si la solicitud original desapareció o si dos procesos completan la misma acción cuando vuelve el servicio.
Asigno un identificador a cada tarea entrante y registro su estado: recibida, en proceso, en espera, completada o entregada a una persona. Volver a intentar la misma tarea no debería crear una segunda cita, enviar dos veces el mismo mensaje de texto ni agregar notas duplicadas al CRM.
Ahí es donde muchas demostraciones de sistemas “siempre activos” se vienen abajo. Muestran un segundo modelo respondiendo después de que falla el primero, pero no muestran qué ocurre con las acciones que ya estaban en curso. ¿El primer modelo envió el correo electrónico antes de que se agotara el tiempo de espera? ¿El calendario aceptó la reserva aunque falló la confirmación? ¿La escritura en el CRM se completó, pero devolvió una respuesta incorrecta?
El sistema debe verificar antes de repetir una acción.
La toma de control por una persona necesita un límite claro
El dueño debería ver exactamente qué terminó el agente, qué sigue en cola y qué debe hacerse manualmente. Una notificación de error imprecisa genera más trabajo porque la persona tiene que reconstruir la conversación.
Para una consola del dueño, uso un canal como el Agente de IA para Telegram para mostrar la solicitud original del cliente, el último paso completado correctamente, la dependencia que falló y la siguiente acción segura. Si el propio canal de notificaciones falló, la implementación necesita una vía separada elegida con anticipación, generalmente correo electrónico o SMS.
La toma de control por una persona también necesita un paso de asignación. Una vez que el dueño se hace cargo de una tarea, el agente debe dejar de intentar completarla en segundo plano. Cuando vuelve el servicio, la cola debe distinguir el trabajo asignado a una persona de las tareas que pueden volver a intentarse de forma segura.
Esto está relacionado con el interruptor de emergencia controlado por el dueño, pero funciona en otra dirección. Un interruptor de emergencia permite que el dueño pause el sistema. Un plan para interrupciones le indica al sistema cómo limitar su comportamiento cuando una dependencia falla por sí sola.
La recuperación es una tarea de conciliación
Que el servicio vuelva no significa que todas las acciones en cola deban ejecutarse al mismo tiempo. La recuperación comienza comparando el trabajo en cola con los sistemas de registro y volviendo a intentar únicamente las acciones que aún son necesarias.
Quiero que la recuperación ocurra en este orden:
- Confirmar que el servicio que falló realmente está funcionando.
- Comparar las tareas pendientes con el CRM, el calendario, la bandeja de entrada u otro sistema de registro.
- Eliminar las tareas que una persona ya resolvió.
- Volver a intentar las escrituras seguras a un ritmo controlado.
- Marcar las tareas ambiguas para su revisión.
- Enviar al dueño un informe breve de recuperación.
El informe debe indicar cuánto tiempo estuvo fuera de servicio la dependencia, cuántas solicitudes quedaron en espera, cuántas se completaron después de la recuperación y cuáles todavía necesitan la intervención de una persona. Esos son datos operativos, no una novela sobre un incidente técnico.
Lo que exijo antes de considerar que un agente pertenece al cliente
Ser propietario significa que el cliente puede seguir operando, revisar los registros y cambiar de proveedores sin pedir permiso a una empresa de SaaS. No significa que todos los servicios externos estarán disponibles para siempre.
Antes de la entrega, quiero que el dueño sepa dónde se almacenan las solicitudes, cómo llegan las alertas, cómo tomar el control, cómo se concilia el trabajo en cola y qué credenciales o proveedores pueden reemplazarse. También quiero realizar una breve prueba de interrupción. Desactiva una conexión que no sea de producción, envía una solicitud de prueba y comprueba que aparezcan el registro y la alerta esperados.
Si nadie ha probado la ruta de falla, solo es un diagrama.
Instalo estos controles a mano porque un agente forma parte de la operación, no es una caja mágica colocada a su lado. Si quieres que la consola del dueño y las vías de respaldo se adapten a tus herramientas reales, comienza con la auditoría breve; te responderé con tu mapa de reemplazo con IA en un plazo de 24 horas.
