El agente funciona hasta que se detiene una dependencia
Una empresa asigna a un agente de IA la lectura de solicitudes, la consulta del historial del cliente, la preparación de una recomendación y la actualización de un sistema empresarial. El flujo entra en la operación diaria. Luego el modelo se vuelve lento, la API del CRM devuelve errores o el índice documental queda desactualizado. El agente sigue conectado, pero el proceso ya no genera un resultado fiable.
Los gestores deben definir qué trabajo debe continuar, qué puede esperar, cuándo usar una alternativa limitada y cuándo devolver el control a una persona.
Defina el servicio mínimo antes de elegir una alternativa
Comience por el resultado de negocio, no por la tecnología. Identifique el servicio mínimo que aún protege a clientes, plazos y obligaciones regulatorias. En una operación de atención, ese mínimo puede ser recibir la solicitud, emitir un protocolo y conservar el contenido original, aunque la clasificación y la redacción de la respuesta no estén disponibles temporalmente.
Separe las dependencias críticas de las útiles. El identificador del cliente puede ser esencial, mientras que una sugerencia de tono puede ser opcional. Registre también la interrupción máxima aceptable, el volumen que puede acumularse y el responsable que decide si la operación degradada sigue siendo aceptable.
El manual del Marco de Gestión de Riesgos de IA de NIST recomienda planes posteriores al despliegue con monitoreo, anulación, respuesta a incidentes, recuperación y gestión de cambios. También propone considerar alternativas no basadas en IA o semiautomatizadas. Así, la continuidad se convierte en una decisión de gestión y no en un arreglo técnico improvisado.
Use cuatro respuestas controladas en lugar de reintentos infinitos
Un flujo resiliente suele combinar cuatro respuestas. Primero, fallar rápido cuando una dependencia está claramente indisponible, para no ocupar recursos esperando un resultado que no llegará. Segundo, reintentar solo fallos transitorios, con límite, intervalo y un presupuesto compartido por el servicio. Tercero, colocar el trabajo elegible en una fila duradera con identificador, hora, prioridad y estado actual. Cuarto, dirigir los casos críticos o vencidos a una ruta de recuperación manual con el contexto ya reunido.
Los reintentos exigen atención especial. La guía de Google SRE muestra cómo los reintentos en varias capas pueden convertir una solicitud en muchos intentos y empeorar una interrupción. La regla práctica es distinguir errores temporales de permanentes, limitar los intentos y evitar que cada capa repita de forma independiente la misma acción fallida.
Un modelo de respaldo o una API secundaria puede ayudar, pero no es automáticamente equivalente. Defina qué tareas puede ejecutar, qué umbral de calidad se aplica y qué acciones siguen bloqueadas. Si la alternativa produce un resultado más limitado, la interfaz y los sistemas posteriores deben marcar ese estado de forma explícita.
Conserve el estado para que la recuperación no duplique acciones
Cada ejecución interrumpida necesita un estado duradero. Registre el identificador del caso de negocio, los pasos terminados, las versiones de entrada, las respuestas de herramientas, las aprobaciones y la acción pendiente. La recuperación debe continuar desde un punto conocido y no repetir todo el flujo.
Use claves de idempotencia o controles equivalentes para acciones como crear un pedido, enviar un mensaje o modificar un registro. Antes de repetir una escritura, compruebe si el resultado previsto ya existe. Un plan que recupera disponibilidad pero duplica una acción financiera o frente al cliente genera un segundo incidente.
Ejemplo hipotético: alta de proveedores
Considere una empresa industrial hipotética, que no es un caso de cliente de NM Solutions. Un agente recibe documentos de proveedores, extrae datos de registro, verifica certificados obligatorios y prepara una ficha para aprobación. El flujo depende de un modelo de lenguaje, un repositorio documental y la API del ERP.
Si el modelo no está disponible, la empresa aún recibe el paquete, asigna un protocolo y guarda los archivos. El caso entra en una fila sin extracción automática. Si el repositorio responde pero el ERP está fuera de servicio, los datos validados quedan pendientes y no se crea el proveedor. Un alta prioritaria que podría detener la producción se dirige a un analista con los archivos, la lista de validación y el historial de errores.
Cuando vuelven los servicios, el proceso de recuperación continúa cada caso desde el último punto confirmado. Comprueba si el registro ya existe en el ERP antes de escribir, atiende primero los casos prioritarios y envía las extracciones dudosas a revisión. El ejemplo no garantiza un alta sin interrupciones, pero evita pérdidas silenciosas, repeticiones descontroladas y decisiones con datos incompletos.
Practique la recuperación y defina el retorno a la normalidad
Una ruta alternativa que nunca se ejercita es solo un diagrama. Pruebe con una frecuencia planificada la caída de dependencias, el crecimiento de la fila, el vencimiento de tareas, la transferencia manual y la restauración. Confirme que las alertas llegan al responsable adecuado y que las personas entienden el caso sin reconstruir el razonamiento del agente a partir de registros dispersos.
Defina criterios de salida para el modo degradado. Volver a la normalidad puede exigir latencia estable, un índice de datos actualizado, una muestra de verificaciones correctas y el procesamiento controlado del trabajo acumulado. Mantenga registro de lo automático, aplazado, completado manualmente o abandonado.
Reconozca los límites y ajuste la continuidad al riesgo
La redundancia aumenta costos y puede introducir comportamientos diferentes entre proveedores. Las filas retrasan el trabajo y requieren controles de privacidad, retención y capacidad. La recuperación manual puede sobrecargar a los especialistas, y un modelo alternativo puede no cumplir la calidad exigida en decisiones sensibles. Algunos procesos deben detenerse por completo cuando falta evidencia o no existe una alternativa segura.
La guía de agentes de OpenAI recomienda fijar umbrales de fallo y transferir el control a una persona cuando los intentos los superan. NM Solutions ayuda a mapear dependencias críticas, estados de recuperación, responsables y alternativas seguras alrededor del proceso de negocio. Un diagnóstico permite identificar dónde la continuidad necesita ingeniería y dónde basta un procedimiento operativo claro.