Resiliencia no significa reintentar todo

Los fallos forman parte de cualquier automatización que dependa de APIs, modelos o servicios externos. La diferencia entre un flujo frágil y uno resiliente está en cómo responde cuando algo deja de funcionar.

Un reintento puede ser adecuado ante un error temporal, pero no ante datos inválidos o una operación cuyo resultado quedó incierto. En esos casos, repetir a ciegas puede aumentar costos, saturar el servicio o producir duplicados.

También existen otras respuestas: utilizar un fallback seguro, degradar temporalmente una función o detener el proceso y solicitar revisión. La decisión debe proteger primero la consistencia del negocio.

Un punto especialmente delicado ocurre cuando un sistema externo pudo completar una escritura antes de devolver un timeout. La recuperación requiere idempotencia, verificación o reconciliación antes de ejecutar nuevamente.

La resiliencia no consiste en insistir hasta que algo funcione. Consiste en diseñar respuestas controladas para cada tipo de fallo.

Resiliencia no significa reintentar todo

Comentarios

Publicar un comentario

Entradas más populares de este blog

El LLM no debe ser la fuente de verdad

Imagen
Un modelo de lenguaje puede explicar una respuesta con gran claridad y, aun así, ofrecer un dato equivocado. Esa combinación es peligrosa: cuanto más convincente resulta el texto, más fácil es olvidar que el modelo quizá no consultó la información adecuada. Antes de incorporarlo a un proceso, conviene formular una pregunta sencilla: ¿dónde se encuentra la fuente de verdad para cada dato y cada decisión? La respuesta cambia según la consulta. Un horario vigente suele estar en una página oficial o una API; una regla de acceso puede estar en una política publicada; una disponibilidad en tiempo real debe venir del sistema que la registra. El modelo puede ayudar a entender la pregunta y redactar la respuesta, pero no debería sustituir a esas fuentes. Su habilidad para producir lenguaje no equivale a tener información actualizada ni autoridad para decidir. Pensemos en un sitio que ayuda a planificar la visita a un museo. Una persona pregunta si puede entrar el domingo, cuánto cuesta la entra...
Leer más

Un documento no debe convertirse en autoridad

Imagen
Los sistemas con IA suelen procesar contenido que no controlamos: correos, documentos, páginas web, mensajes o información recuperada mediante RAG. Ese contenido puede incluir instrucciones dirigidas al modelo y tratar de modificar su comportamiento. La defensa fundamental consiste en separar información de autoridad. Un documento puede aportar datos para responder una consulta, pero no debe adquirir permisos para cambiar reglas, ejecutar acciones o ampliar privilegios. Por ejemplo, un correo podría indicar que se ignore una política y se modifique un registro administrativo. El modelo puede analizar o resumir ese texto, pero la operación debe seguir dependiendo de permisos, reglas de negocio y, cuando corresponda, confirmación humana. Esto implica que la seguridad no puede descansar únicamente en un prompt que diga “ignore instrucciones maliciosas”. Las fronteras importantes deben implementarse fuera del modelo. La IA puede interpretar contenido no confiable. Lo que no debe hacer es p...
Leer más

Human-in-the-loop: dónde debe detenerse la IA

Imagen
Automatizar no significa eliminar siempre a la persona del proceso. En sistemas con IA, la intervención humana puede funcionar como un control deliberado cuando una decisión tiene suficiente riesgo, incertidumbre o impacto. El punto importante es elegir dónde colocar ese control. Pedir aprobación para cada paso aumenta latencia y carga operativa; no pedirla nunca puede permitir que un error probabilístico produzca consecuencias difíciles de revertir. Una arquitectura human-in-the-loop define criterios explícitos. Impacto, reversibilidad, confianza, permisos y costo del error pueden determinar si una acción continúa automáticamente, solicita aprobación o se detiene. Las tareas rutinarias y verificables pueden conservar autonomía. Las acciones sensibles, ambiguas o de alto impacto requieren un nivel de supervisión proporcional al riesgo. El objetivo no es mantener a una persona dentro de todos los flujos, sino utilizar su intervención donde realmente aumenta la confiabilidad del sistema.
Leer más