𝗧𝘂 𝗽𝗿𝗼𝘃𝗲𝗲𝗱𝗼𝗿 𝗱𝗲 𝗜𝗔 𝗲𝘀 𝘂𝗻 𝗽𝘂𝗻𝘁𝗼 𝘂́𝗻𝗶𝗰𝗼 𝗱𝗲 𝗳𝗮𝗶𝗹𝗹𝗼
El viernes pasado, el Departamento de Comercio de EE. UU. envió una carta a Anthropic. Para esa misma noche, Fable 5 y Mythos 5 habían desaparecido.
No fueron marcados como obsoletos. No sufrieron una limitación de velocidad. Simplemente desaparecieron.
Las llamadas a la API devolvieron errores 404. Las sesiones en vivo fallaron a mitad de la conversación. Las aplicaciones que dependían de esos modelos dejaron de funcionar. Esto ocurrió tres días después del lanzamiento. No hubo advertencia ni ventana de migración.
Tuvimos suerte porque esos modelos eran nuevos. Nadie había construido dependencias profundas sobre ellos todavía. Imagina que esto le sucediera a un modelo que usas todos los días durante seis meses.
Si una carta del gobierno pudiera cerrar tu base de datos principal, ¿la operarías sin un failover? No lo harías. Sin embargo, la mayoría de los equipos hacen esto con la IA.
Muchos equipos tratan la IA como la electricidad. Pulsas un interruptor y esperas luz. No piensas en la fuente ni en lo que sucede cuando se corta la energía. Eliges un modelo, codificas un endpoint de forma fija y lanzas el producto.
Esto no es ingeniería. Esto es arquitectura basada en la esperanza.
Los modelos pueden desaparecer debido a:
- Razones regulatorias
- Cambios de política
- Problemas geopolíticos
La situación de Anthropic no fue un error o un fallo de infraestructura. Fue un interruptor de apagado regulatorio.
Debes integrar resiliencia en tu capa de modelos. Utiliza estos patrones:
- Abstrae tus llamadas a modelos. Usa una interfaz para que tu aplicación no dependa de qué proveedor sirva la respuesta.
- Usa múltiples proveedores. Cambiar de proveedor debería ser un cambio de configuración, no una reescritura total.
- Usa modelos de pesos abiertos (open-weight). Si ejecutas el modelo por tu cuenta, nadie puede apagarlo de forma remota. Estos modelos actúan como un generador cuando la red eléctrica falla.
- Implementa una degradación elegante (graceful degradation). Un modelo más pequeño o antiguo es mejor que una aplicación rota.
Monitorea tus tasas de error. Si se disparan, salta el interruptor y redirige el tráfico a tu fallback.
Trata tu IA como cualquier otra dependencia crítica de producción. Diseña para el fallo.
¿Tu arquitectura asume que tu proveedor fallará? Si no es así, estás en riesgo.
¿Has implementado un fallback multi-proveedor en tu stack? Cuéntame en los comentarios.
Source: https://dev.to/aws/your-ai-provider-is-a-single-point-of-failure-26i2
Optional learning community: https://t.me/GyaanSetuAi