Limita el radio de impacto: decide qué puede romper una falla

Las cosas se van a romper. Una API externa va a tardar demasiado, un proveedor va a cambiar un campo sin avisar, un despliegue va a llevar un error, un modelo va a producir algo que nadie esperaba. No puedes evitar todo eso. Lo que sí puedes decidir, de antemano, es cuánto puede romper cada falla. Ese es el radio de impacto, y es una decisión de diseño, no suerte.

Cómo se vio en una capa de datos para profesionales

En la capa de datos de una plataforma de IA para profesionales del derecho y la salud, nos conectamos a muchos sistemas externos que limitan peticiones, tardan demasiado y devuelven datos inconsistentes. Cada llamada externa tenía reintentos y timeouts. Los patrones de circuit breaker y de límite de tasa hacían que una fuente que fallaba no pudiera tumbar a las demás: si un sistema dejaba de responder, las llamadas a él se cortaban rápido, y todas las otras fuentes seguían fluyendo. Los logs estructurados con IDs de correlación permitían seguir un solo registro y ver exactamente dónde se detuvo una falla.

El mismo criterio aplica a cualquier sistema que dependa de integraciones o de IA. Estas son las herramientas que usamos.

Aísla por fuente y por cliente

Una falla en una fuente, o en los datos de un cliente, debería quedarse ahí. En la práctica:

• colas, procesos o pools de conexiones separados por fuente externa, para que un sistema lento no agote recursos compartidos;
• un circuit breaker por fuente, no uno para toda la capa de integración;
• separación entre clientes aplicada en la capa de datos, para que un error al procesar los datos de un cliente no pueda leer ni escribir los de otro;
• registros defectuosos puestos en cuarentena para revisión en vez de detener toda la importación.

Solo lectura por defecto, credenciales acotadas siempre

La forma más barata de limitar el daño es hacerlo imposible. Si una integración solo necesita leer, dale acceso de solo lectura. Si necesita escribir, limita la credencial a los objetos y acciones que de verdad usa. Una credencial por integración, no una llave de administrador compartida, hace que una llave filtrada o mal usada abra una puerta en vez de todas, y que se pueda revocar sin detener todo lo demás.

Decide qué puede tocar una acción de IA

Las funciones de IA vuelven la pregunta más urgente. Un modelo que sugiere es de bajo riesgo; un modelo que actúa, no. Para cada capacidad de IA, deja por escrito:

• qué datos puede leer y cuáles nunca debe ver;
• qué acciones puede tomar por su cuenta, cuáles necesitan la aprobación de una persona y cuáles están prohibidas;
• lo máximo que puede hacer en una ejecución: registros modificados, mensajes enviados, dinero movido.

Aplica esos límites en el código alrededor del modelo, no en el prompt. Un prompt es una petición; una verificación de permisos es una regla.

Feature flags y botones de apagado

Cada integración nueva y cada función de IA debería salir detrás de una bandera que alguien pueda apagar sin desplegar. Un botón de apagado es la forma más rápida de achicar un radio de impacto que ya está creciendo: apagas la función, el resto del producto sigue funcionando, e investigas con calma.

Respaldos que degradan con elegancia

Cuando una dependencia falla, decide qué ve el usuario. Datos en caché con una nota clara de “última actualización”, una respuesta basada en reglas en vez de la del modelo, una petición en cola que se completa después. Un respaldo convierte una caída en una experiencia más lenta o más simple en vez de una página de error.

Lanzamientos por etapas

Lanza primero a un grupo pequeño: usuarios internos, un cliente, una parte del tráfico. Vigila errores, respaldos y correcciones, y luego amplía. Un problema encontrado en esa etapa afecta a pocas personas en vez de a todas, y la reversión es rutina en vez de emergencia.

Esto es parte de cómo diseñamos cada sistema; mira nuestro método para el resto.