Treinta días es el tiempo que cada prompt y cada respuesta enviada a Fable 5 permanece almacenada en los servidores de Anthropic. No hay opt-out, sin importar si usas la API directa, Bedrock, Vertex o Foundry. Si tu organización opera bajo regulaciones estrictas de datos, ese número define si Fable 5 entra o no a tu stack.

¿Por qué Anthropic retiene tus datos durante 30 días?

La razón oficial es seguridad: detectar ataques distribuidos en muchos requests a lo largo del tiempo, como jailbreaks progresivos o intentos de destilación del modelo. Los datos no se usan para entrenar nuevos modelos [00:40].

Pero hay un asterisco que tu equipo legal va a subrayar. Si contenido retenido es flaggeado como violación de política, puede conservarse hasta dos años [00:51]. La frase que usa Anthropic es almost all cases respecto a la eliminación automática, y ese lenguaje no es una garantía de eliminación universal.

¿Cuánto tiempo retiene Anthropic los prompts enviados a Fable 5? Treinta días por defecto, sin opción de opt-out. Si el contenido se marca como violación de política, puede retenerse hasta dos años.

¿Qué pasa con Zero Data Retention si ya tengo un acuerdo?

La parte contraintuitiva está en el detalle. Si tu organización está configurada con ZDR en Claude Console, cada request a Fable 5 devuelve un cuatrocientos [01:16]. No es un bug, es una restricción a nivel de modelo.

Fable 5 y Mythos 5 están clasificados como Covered Models, y la política de treinta días anula cualquier acuerdo ZDR previo para estos modelos específicos.

Existe un workaround parcial. Si solo algunos workloads pueden aceptar los treinta días, puedes habilitar la retención a nivel de workspace individual dentro de Claude Console. El resto de tu organización mantiene ZDR y la exposición queda contenida [01:46].

¿Qué features quedan bloqueadas bajo HIPAA con BAA?

Para equipos bajo HIPAA con Business Associate Agreement, el path existe pero varias features quedan bloqueadas:

• Claude Code.
• Files API.
• Batch processing.
• Web fetch.
• Computer use.

Si necesitas que la retención la gobierne tu cloud provider y no Anthropic, Bedrock, Vertex y Foundry son las opciones donde AWS, Google o Microsoft ponen las reglas [02:09].

Piénsalo como un edificio de apartamentos. El propietario tiene una política de cámaras que graban treinta días. Puedes mudarte a otro edificio donde tu propio administrador maneje las grabaciones, pero no puedes vivir en este edificio y pedir que las cámaras no te graben.

¿Qué es Project Glasswing y para quién aplica?

La única diferencia entre Fable 5 y Mythos 5 es la capa de clasificadores [02:37]. Mismos pesos, misma inteligencia, mismo precio. Glasswing es el programa que da acceso a Mythos 5 para organizaciones cuyo trabajo legítimo colisiona constantemente con los safeguards.

Lo que Glasswing remueve son los clasificadores de ciberseguridad. Si mediste un refusal rate del ocho o nueve por ciento en tu workload de seguridad, Glasswing lo lleva a cero en esa categoría. Pero no remueve los clasificadores de biología ni el de destilación [03:06].

Las rutas de acceso son cuatro y ninguna es rápida:

• Partnership directa con Anthropic.
• Claude for Open Source para maintainers.
• El Cyber Verification Program, única opción self-serve con formulario público.
• El programa de biología, planificado pero no abierto.

¿Quién debería aplicar a Mythos 5? Equipos con un refusal rate alto y persistente en ciberseguridad. Para desarrollo estándar, Fable 5 ya funciona y Mythos no agrega beneficio práctico.

¿Qué fue el steering invisible y por qué importa hoy?

Aquí necesitas separar tres capas con precisión. Lo que Anthropic divulgó oficialmente: ciertos safeguards limitaban la efectividad del modelo de forma silenciosa, sin notificación, afectando aproximadamente cero punto cero tres por ciento del tráfico en tópicos de infraestructura de AI frontier [03:53]. Los usuarios no recibían señal alguna en la respuesta.

Lo que la comunidad interpretó iba desde AI desalineada hasta protección de mercado disfrazada de safety. Esas son opiniones, no hechos adicionales.

Lo que cambió: el once de junio de dos mil veintiséis, Anthropic reconoció que hizo el tradeoff equivocado [04:14]. La categoría frontier_llm ahora aparece como refusal estándar, detectable y manejable con las mismas rutas de fallback que ya conoces. Lo invisible se volvió visible.

¿Cómo detectas drift futuro en tu pipeline?

Con un canary eval: un set pequeño de prompts fijos que corres en schedule. Mezclas prompts de dominio sensible con un prompt de control neutral. Si el control está estable pero los de dominio caen, el cambio es localizado. Trackeas tendencias, no corridas individuales, con un rubric congelado que nunca cambias entre ejecuciones [04:54].

¿Cuál es el framework de decisión para adoptar Fable 5?

Cuatro factores evaluados en orden secuencial. Si el primero falla, no necesitas evaluar los demás.

• Retención: ¿tu org puede aceptar treinta días? Si estás en ZDR estricto sin posibilidad de workspace separado, Fable 5 no está disponible en la API first-party. Gate binario.
• Tasa de refusal para tu dominio. El promedio publicado es menos del cinco por ciento. En ciber y biología, ocho a nueve. Tu número depende de tu prompt mix. Mídelo antes de dimensionar.
• Cobertura de fallback: ¿cada parte de tu pipeline tiene un path de recovery configurado? Las requests sin fallback son las que tienen mayor probabilidad de ser rechazadas sin recovery.
• Costo ajustado por tarea completada. Los pre-output refusals son gratis. Más del noventa y cinco por ciento de sesiones no involucran fallback. Pero si tu success rate con Fable no justifica el premium sobre Opus, pinea Opus directamente [06:10].

Pregúntate ahora: ¿en cuál de estos cuatro factores tu organización tiene el mayor riesgo de fallar?

Cuando presentes esto a tu equipo, documéntalo como un Architecture Decision Record. Incluye contexto, evidencia testeada, tradeoffs aceptados, mitigaciones implementadas, plan de manejo de refusals y plan de monitoreo de drift. Lo que no incluyes: anécdotas no verificadas de usuarios. Solo lo que tus propios canary evals muestran, con fecha.

¿Tu equipo ya midió el refusal rate en su workload real? Cuéntalo en comentarios.