Anthropic suspende Fable 5 y Mythos 5: por qué un ERP no puede colgar de un solo modelo

El 12 de junio Anthropic retiró Fable 5 y Mythos 5 por controles de exportación, tras una técnica de evasión descubierta por Amazon. Si tu ERP depende de un único modelo, ese día te quedas sin presupuestos, sin fichas técnicas y sin explicaciones. Te contamos cómo está montada la plataforma de presupuestaIA para que eso no ocurra.

Lo que pasó el 12 de junio

Anthropic retiró Fable 5 y Mythos 5. El motivo: controles de exportación, después de que Amazon descubriera una técnica de evasión. No fue un aviso con seis meses de margen. Fue una suspensión.

Para un usuario particular, es una molestia. Cambias de modelo en el desplegable y sigues. Para un ERP que genera presupuestos, redacta memorias técnicas y clasifica facturas, es otra cosa. Si tu producto llama a un endpoint concreto de un proveedor concreto y ese endpoint devuelve 404, tu producto está caído. No degradado: caído.

Nosotros no nos enteramos por una incidencia. Nos enteramos leyendo la noticia. Y eso es exactamente el objetivo.

Por qué un ERP no puede colgar de un solo modelo

La diferencia entre una app de IA y un ERP con IA es la responsabilidad. Cuando un instalador emite una factura con Veri*Factu, hay un registro encadenado y una obligación fiscal detrás. Cuando un jefe de obra saca un presupuesto de 84.000 € para una comunidad, hay una oferta que se firma.

Nada de eso puede depender de que un proveedor decida el martes que un modelo deja de existir. Los motivos por los que un modelo desaparece son más de los que parece:

• Restricciones regulatorias o de exportación, como este caso.
• Deprecación planificada: el proveedor apaga la versión antigua para empujar la nueva.
• Cambios de precio que hacen inviable un flujo que antes salía a céntimos.
• Saturación: el modelo existe pero responde con latencias de minutos.
• Cambios de comportamiento sin cambio de nombre. El mismo modelo, otro resultado.

El último es el más traicionero. No hay error, no hay alerta. Simplemente las mediciones empiezan a salir peor y nadie sabe por qué.

Cómo está montada la plataforma por dentro

En presupuestaIA ninguna parte del producto llama directamente a un proveedor. Todas las llamadas pasan por una capa intermedia que decide qué modelo atiende cada tarea. Esa capa es lo que nos permite dormir cuando salen noticias como la del 12 de junio.

Las piezas son estas:

• Tareas, no modelos. El código pide "redactar partida de clima" o "clasificar asiento PGC", no pide un modelo por su nombre. La correspondencia entre tarea y modelo vive en configuración, no en el código.
• Varios proveedores activos a la vez. No uno principal y otro de adorno. Ambos reciben tráfico real todos los días, así que sabemos que funcionan.
• Cadena de respaldo por tarea. Si el primero falla o tarda demasiado, la petición cae al siguiente sin que el usuario vea nada distinto.
• Validación de salida. Una partida de presupuesto tiene que traer unidad, medición, precio y descripción. Si el modelo devuelve algo que no cumple el formato, se rechaza y se reintenta. Da igual quién lo haya generado.
• Registro de qué modelo hizo qué. Cada generación queda anotada. Cuando algo sale raro, sabemos con qué se hizo.

Lo importante no es tener un plan B. Es que el plan B esté encendido y probándose solo, todos los días.

Qué habrías notado tú ese día

Nada. Y eso es todo el trabajo.

Si una tarea que se atendía con un modelo retirado pierde su destino, la cadena de respaldo la recoge. En el peor caso, una generación tarda unos segundos más. En el caso extremo, en el que ninguna alternativa esté disponible, el módulo no se rompe: te avisa de que la asistencia no está operativa y te deja seguir a mano. Un presupuesto se puede escribir a mano. Un ERP que se queda en blanco, no.

Esto conecta con algo que ya explicamos en la arquitectura de 3 apps: separar responsabilidades no es un capricho de ingeniería. Es lo que te permite cambiar una pieza sin tirar el edificio.

La parte que aún no está resuelta

Seamos honestos: la redundancia tiene costuras.

Los modelos no son intercambiables al cien por cien. Cambiar de proveedor en la generación de partidas de obra da resultados equivalentes, pero no idénticos. La misma reforma de baño descrita con las mismas palabras puede salir con nueve partidas en un modelo y con once en otro. Ambas correctas. Distintas. Por eso insistimos en que el presupuesto que genera la IA es un borrador que tú revisas y firmas, no un documento cerrado.

En tareas más rígidas —clasificar un movimiento bancario contra el plan contable, extraer datos de una factura de proveedor— la diferencia es mínima, porque la salida está muy acotada y validada. En tareas de redacción larga, como una memoria técnica de RITE, se nota más el estilo.

Y hay un coste que asumimos: mantener dos proveedores activos es más trabajo que mantener uno. Hay que probar cada actualización dos veces. Lo pagamos con gusto.

Qué hacer ahora

Si eres cliente, no tienes que hacer nada. Entra en tu panel y sigue trabajando igual que ayer.

Si estás evaluando herramientas con IA para tu empresa —la nuestra o cualquier otra— hazle tres preguntas al comercial antes de firmar:

• ¿Qué proveedores de IA usáis y cuántos están activos hoy en producción?
• Si mañana desaparece uno, ¿qué deja de funcionar exactamente en mi cuenta?
• Cuando la IA no está disponible, ¿puedo seguir presupuestando y facturando a mano?

Si la respuesta a la tercera es que no, no es un ERP. Es un asistente con nombre de ERP. Y tus facturas no pueden depender de una decisión de exportación tomada al otro lado del Atlántico.

Seguimos con lo de siempre: el mes que viene habrá otro modelo estrella y otro modelo retirado. Nosotros a lo nuestro, que es que tu presupuesto salga y tu factura se registre.