Claude Fable 5 no funciona con ZDR: la retención de 30 días es obligatoria

Si tu organización usa Claude bajo un acuerdo de retención cero de datos (ZDR), la primera petición a claude-fable-5 no devolvió una respuesta, sino un 400 invalid_request_error. No es una caída del servicio, sino una restricción de la política. Fable 5 es el primer modelo Claude con disponibilidad general que no puede utilizarse sin retener los datos durante 30 días. El requisito se aplica en todas las plataformas donde se ofrece el modelo: Claude API, AWS Bedrock, Google Vertex AI y Microsoft Foundry exigen aceptar expresamente la retención.

Para los equipos que consideraban que «no retenemos tus datos» era una propiedad consolidada de su stack de LLM, esto exige replantear la arquitectura. Este artículo explica qué establece la política, por qué existe ese plazo, cómo lo implementa cada cloud y qué cambia para los productos de consumo y los sectores que manejan datos sensibles.

TL;DR

• Claude Fable 5 no puede utilizarse sin retener prompts y respuestas durante 30 días. El requisito se aplica en Claude API, AWS Bedrock, Google Vertex AI y Microsoft Foundry (política vigente desde 2026-06-09).
• No hay opción de exclusión: las organizaciones con acuerdos de retención cero de datos reciben 400 invalid_request_error, y las condiciones ZDR existentes no se aplican a estos modelos.
• En Bedrock, Fable 5 requiere data_retention_mode: provider_data_share; sin este ajuste, el modelo aparece como no disponible.
• El contenido marcado por infringir la Usage Policy puede conservarse hasta 2 años, al margen del plazo de 30 días.

Los detalles de las políticas se contrastaron con la documentación publicada por Anthropic, AWS, Google y Microsoft el 2026-06-12. Las políticas cambian; comprueba las fuentes primarias enlazadas y tus propios contratos. Este artículo ofrece una perspectiva de ingeniería, no asesoramiento jurídico.

Qué establece exactamente la política

Anthropic clasifica Claude Fable 5 y Claude Mythos 5 como modelos sujetos a cobertura. Según la documentación sobre retención de datos de la API y el artículo sobre las prácticas de retención de los modelos de la clase Mythos (vigentes desde 2026-06-09):

• Los prompts y las respuestas se conservan durante 30 días y después se eliminan automáticamente, salvo que se hayan marcado para una investigación de seguridad activa o que la ley exija conservarlos.
• No hay opción de exclusión. La retención es una condición para utilizar el modelo. Si la configuración de retención de una organización no cumple el requisito, la petición devuelve 400 invalid_request_error.
• El acceso se limita deliberadamente. Los sistemas automatizados de seguridad analizan los datos. Solo un pequeño grupo de personas autorizadas puede revisar las conversaciones marcadas; no pueden exportarlas, copiarlas ni descargarlas, y cada acceso queda registrado en logs a prueba de manipulaciones.
• Los acuerdos ZDR existentes no se aplican al tráfico de los modelos sujetos a cobertura, tampoco cuando se accede a ellos mediante plataformas cloud.

Los planes para consumidores (Claude Free/Pro/Max) no se ven afectados porque ya se rigen por sus propias condiciones de retención. La política se dirige a la API comercial, justo donde suelen existir compromisos del tipo «nunca retenemos los datos».

Por qué existe un plazo de 30 días

El motivo que da el artículo sobre los modelos sujetos a cobertura es concreto: estos modelos ofrecen capacidades mucho más avanzadas en ingeniería de software, workflows con agentes y ciberseguridad, y «algunas formas de abuso solo pueden detectarse al analizar muchas peticiones». Los ejemplos citados, como el jailbreaking best-of-N y el espionaje patrocinado por Estados, son patrones de ataque en los que cada prompt parece inofensivo por separado y solo la secuencia permite identificar el abuso. Si se elimina cada petición, no es posible detectar esa secuencia.

Dos cosas que este plazo no es:

• No son datos de entrenamiento. Anthropic afirma que los datos retenidos nunca se utilizan para entrenar modelos sin permiso expreso. Su única finalidad es detectar abusos.
• La práctica no es nueva; lo nuevo es que sea obligatoria. Un plazo de unos 30 días para supervisar abusos lleva años siendo habitual en el sector: OpenAI conserva los logs de abuso de la API hasta 30 días, con ZDR sujeto a aprobación; Azure OpenAI almacena los prompts hasta 30 días, salvo que se apruebe un régimen modificado de supervisión de abusos. El cambio es que el plazo pasó a ser innegociable para una clase de modelos. Hasta ahora, todos los proveedores ofrecían alguna vía para no retener los datos.

Hay una excepción anterior que sigue sorprendiendo: incluso con ZDR, Anthropic conserva los resultados de los clasificadores de seguridad, y el contenido marcado por infringir la Usage Policy puede almacenarse hasta 2 años. Retención cero de datos nunca ha significado que no se conserve absolutamente nada, sino que el contenido no marcado no se retiene en el flujo normal.

El mismo requisito, tres clouds y tres mecanismos

La retención se aplica en cualquier plataforma donde se ejecute el modelo, pero cada una implementa la aceptación de forma distinta. Esas diferencias determinan quién procesa los datos y dónde se aplican los controles.

AWS Bedrock ofrece la implementación más explícita. La retención de datos se configura mediante un modo (default / provider_data_share / none) que se resuelve con esta prioridad: proyecto → cuenta → valor predeterminado del modelo. Fable 5 declara allowed_modes: ["provider_data_share"]: los prompts y las respuestas se comparten con Anthropic y se conservan hasta 30 días. Con cualquier otro modo:

{
  "id": "anthropic.claude-fable-5",
  "status": "unavailable",
  "status_reason": "This model is not available under data retention mode 'default'.",
  "data_retention": {
    "mode": "default",
    "source": "account",
    "allowed_modes": ["provider_data_share"]
  }
}

Nada cambia para los modelos anteriores a Fable 5. Además, un SCP sobre la clave de condición bedrock:DataRetentionMode permite aplicar la política a toda la organización, de modo que nadie pueda cambiar la cuenta discretamente para probar el modelo nuevo. En la inferencia entre regiones, la copia retenida se almacena en la región de destino, algo relevante si tienes compromisos de residencia de datos.

Google Vertex AI exige habilitar en el proyecto el intercambio de datos con Anthropic (setPublisherModelConfig con dataSharingEnabledProvider: "anthropic") y aceptar las condiciones en Model Garden, según la documentación de Google sobre Fable 5. El tratamiento general de los datos se rige por la política de gobernanza de datos de Vertex AI. En cargas con requisitos de residencia, los endpoints regionales y multirregionales de Vertex controlan dónde se ejecuta la inferencia y, ahora, también dónde se almacena la copia retenida.

Microsoft Foundry funciona de otra forma. La documentación de Microsoft sobre datos y privacidad deja claro que los modelos Claude son servicios de terceros ofrecidos en el marketplace: al desplegarlos se aceptan las condiciones de Anthropic, y Anthropic, no Microsoft, actúa como encargado del tratamiento. Los programas de ZDR y supervisión modificada de abusos de Azure OpenAI no se extienden a los despliegues de Claude. Las organizaciones que aplican ZDR en otros entornos suelen aislar el uso de los modelos sujetos a cobertura en una suscripción específica, de modo que el límite de retención quede definido por la arquitectura y no por un procedimiento.

El patrón común a las tres plataformas es que la clase de retención se ha convertido en un atributo explícito del modelo, legible por máquinas: un modo, un flag o una aceptación de condiciones, en lugar de un párrafo contractual. La infraestructura ya puede aplicar automáticamente la política de datos, y debería hacerlo.

Qué implica para los despliegues empresariales

Si no tienes un acuerdo ZDR, el funcionamiento no cambia: probablemente ya operabas con una retención cercana a 30 días, aunque no fueras consciente de ello. La tarea consiste en reflejarlo de forma explícita en la documentación del proveedor.

Si tienes un acuerdo ZDR, hay tres opciones:

1. No usar los modelos sujetos a cobertura. ZDR se mantiene de forma uniforme, pero renuncias al modelo. Es una opción válida si tus cargas no lo necesitan. Consulta nuestra evaluación de Fable 5 con mediciones para conocer su coste y sus diferencias.
2. Separar por workspace o proyecto. Todas las plataformas permiten aceptar la retención en un ámbito limitado: un workspace específico de Claude API (Console → Settings → Workspaces → Privacy controls), un proyecto de Bedrock con provider_data_share, un proyecto separado de Vertex o una suscripción distinta de Azure. Solo las cargas que admitan retención deben dirigirse allí.
3. Aceptar la retención en toda la organización. Es la opción más sencilla de operar, pero rebaja de forma silenciosa la garantía de todas las cargas, incluidas aquellas cuya sensibilidad justificaba ZDR. Debe decidirlo el responsable de protección de datos, no quien cambia la configuración.

Con independencia del proveedor, tus propios logs son otra superficie de retención. Si el gateway o el stack de observabilidad registra prompts completos, estarás aplicando un plazo mayor que el proveedor dentro de tu propia infraestructura. Las garantías del proveedor solo tienen valor si la capa anterior también las respeta. Aquí se aplica la misma lógica de auditoría que utilizamos para las afirmaciones sobre caché.

Qué implica para los productos de consumo

Si ofreces un producto a consumidores y envías su contenido a un modelo sujeto a cobertura, el cambio afecta a tus propias obligaciones jurídicas, tengas o no un acuerdo ZDR. Hay tres consecuencias concretas:

1. Probablemente debas actualizar el aviso de privacidad. La mayoría de los marcos normativos obligan a informar no solo de la recopilación, sino también de la retención. El artículo 13(2)(a) del RGPD exige indicar el plazo de conservación, o sus criterios, al recoger los datos. La CPRA de California exige que el aviso en el momento de la recopilación especifique la retención por categoría de información personal. Si tu aviso afirma o da a entender que los datos de las conversaciones no se conservan en ningún sitio, será incorrecto cuando un encargado mantenga una copia durante 30 días. Actualiza el aviso, el registro de actividades de tratamiento y el inventario de DPA.

2. No puedes ofrecer a los usuarios una opción de exclusión que tú no tienes. La retención no admite excepciones. Por tanto, no puedes crear un ajuste que excluya los prompts de un usuario y seguir utilizando el mismo modelo. La herramienta que sí controlas es el routing: un gateway que tenga en cuenta el consentimiento envía a modelos compatibles con ZDR el tráfico de los usuarios que rechacen compartir sus datos, y el resto al modelo sujeto a cobertura. Así, una restricción jurídica se convierte en una regla normal de routing. Es mucho mejor que ofrecer una casilla que no cambia nada.

3. Las solicitudes de supresión necesitan un flujo preciso. Las obligaciones de borrado, como el artículo 17 del RGPD, la supresión de la CPRA y sus equivalentes, también alcanzan a los encargados del tratamiento. Un plazo limitado con borrado automático en un máximo de 30 días suele ser una postura defendible para un encargado, pero el procedimiento para solicitudes de acceso del interesado debe indicarlo. No debe prometer un borrado inmediato en sistemas externos que no puedes ejecutar.

La dimensión global añade más requisitos: la misma lógica de información y encargados del tratamiento aparece en el RGPD del Reino Unido, la LGPD de Brasil y el creciente número de leyes estatales de privacidad de Estados Unidos. Para los usuarios de China, la PIPL añade dos restricciones más estrictas: facilitar información personal a otro encargado suele requerir consentimiento independiente, y enviar el contenido de usuarios chinos a un endpoint de LLM en el extranjero supone una transferencia internacional que necesita un mecanismo reconocido, como una evaluación de seguridad, un contrato estándar o una certificación. Cambiar de modelo y modificar quién retiene los datos, dónde y durante cuánto tiempo es precisamente el tipo de cambio que obliga a actualizar la documentación en estos marcos.

Sectores con datos sensibles: dónde más afecta el plazo de 30 días

Para la mayoría de los productos, el plazo del proveedor es un problema documental. En los sectores donde los propios datos están regulados, es un problema de arquitectura: la copia retenida constituye información regulada en reposo dentro de un proveedor, y las normas sectoriales determinan cómo debe tratarse.

Sanidad (HIPAA)

HIPAA no exige retención cero. Exige que cualquier proveedor que almacene información sanitaria protegida lo haga en virtud de un Business Associate Agreement (BAA) y con las salvaguardas adecuadas. La copia de los prompts conservada durante 30 días es PHI en reposo en un business associate; la cuestión es si el BAA la cubre. Los dos principales proveedores de API lo plantean de forma distinta, y ahora esa diferencia importa: el acceso a la API de Anthropic preparado para HIPAA no exige ZDR. Se basa expresamente en retención con salvaguardas: cifrado, controles de acceso, logs de auditoría y restricciones obligatorias de funciones. El BAA de OpenAI para la API cubre endpoints que admiten retención cero de datos. Un BAA limitado a endpoints ZDR no puede cubrir por definición un modelo que obliga a retener los datos.

La clase de retención de un modelo determina ahora si puede quedar cubierto por un BAA. Antes de enviar PHI al modelo, confirma por escrito que tu BAA cubre ese modelo concreto. La cadena también cambia según el cloud: en Bedrock, la plataforma es tu business associate; en Foundry, Anthropic procesa los datos directamente. Hay otro punto delicado: la PHI nunca debe aparecer en las definiciones de esquemas JSON para outputs estructurados, porque los esquemas almacenados en caché no reciben las mismas protecciones que el contenido de los mensajes.

Productos infantiles (COPPA)

El momento es poco oportuno: la COPPA Rule modificada de la FTC entró en vigor el 23 de junio de 2025, y el plazo para cumplir la mayoría de las disposiciones terminó el 22 de abril de 2026. El primer modelo con retención obligatoria en el proveedor llegó justo cuando los operadores acababan de implantar las nuevas obligaciones. Dos de ellas interactúan directamente con el plazo de 30 días: ahora es obligatoria una política pública y escrita de retención de datos (§312.10), que especifique qué datos infantiles se recogen, por qué y cuándo se eliminan; además, se prohíbe la retención indefinida, y el plazo debe limitarse a lo razonablemente necesario para la finalidad de la recogida.

Un plazo limitado de 30 días con borrado automático tiene una forma compatible. Sin embargo, el proveedor conserva los datos para su propia finalidad de confianza y seguridad, no para la finalidad por la que tú recogiste los datos del menor, y el aviso debe describir correctamente la relación con el encargado. En productos dirigidos a menores que adoptaron ZDR específicamente para reducir al mínimo el rastro de datos, la solución de routing tiene más importancia: el tráfico infantil debe permanecer en modelos compatibles con ZDR, o el plazo del modelo sujeto a cobertura debe incorporarse primero a la política exigida por §312.10.

El mismo patrón en otros sectores

Una vez identificada la estructura —datos regulados, una copia retenida en un proveedor y una norma sectorial que regula esa retención—, el patrón se repite:

• Biometría (BIPA de Illinois): los operadores necesitan un calendario de retención y unas directrices de destrucción, ambos por escrito y disponibles públicamente, para los datos biométricos. Si los prompts contienen identificadores biométricos, la copia de 30 días del proveedor debe figurar en ese calendario.
• Pagos (PCI DSS / GLBA): PCI DSS prohíbe almacenar datos confidenciales de autenticación después de autorizar la operación, sin importar dónde se almacenen. Los datos de una tarjeta pegados en un prompt se convierten en datos de tarjeta retenidos durante 30 días por un proveedor. La solución correcta es redactarlos antes de enviarlos, no generar documentación después.
• Educación (FERPA): los proveedores que tratan expedientes académicos bajo la excepción de funcionario escolar deben permanecer bajo el control directo del centro. Una copia retenida por motivos de seguridad a la que el centro no puede acceder ni borrar antes de tiempo encaja mal con ese requisito. Conviene consultarlo con el equipo jurídico antes de enviar tráfico EdTech a un modelo sujeto a cobertura.
• Servicios financieros: el caso inverso (SEC/FINRA): los broker-dealers deben conservar las comunicaciones empresariales conforme a las normas de libros y registros. Para ellos, el plazo del proveedor no es el problema; lo importante es capturar su propia copia conforme a la normativa. Es la misma cuestión de retención, pero en sentido opuesto.

El factor común es que las normas sectoriales regulan la retención en ambos sentidos, y cualquier plazo impuesto por el proveedor que no controles debe encajar con la dirección que marque tu sector.

Checklist para tomar una decisión

• ✅ Haz un inventario de los modelos por los que pasa realmente el tráfico. La clase de retención es ahora un atributo de cada modelo, no del proveedor en su conjunto.
• ✅ Si tienes ZDR, decide de forma explícita: no usar modelos sujetos a cobertura, separar por workspace/proyecto/suscripción o aceptar la retención en toda la organización. No permitas que ocurra de forma implícita.
• ✅ Aplica la política desde la infraestructura: SCP de Bedrock, controles de privacidad del workspace y proyectos cloud separados, no una página en la wiki.
• ✅ En B2C, actualiza los avisos de privacidad y los procedimientos para solicitudes de los interesados; envía a modelos compatibles con ZDR el tráfico de los usuarios que no consientan, en lugar de crear opciones de exclusión que no pueden funcionar.
• ✅ Para datos regulados, confirma por escrito la cobertura de cada modelo: BAA para PHI, política §312.10 para datos infantiles y calendarios de retención para datos biométricos, antes de enviar esos datos a un modelo con retención obligatoria.
• ✅ Audita tus propios logs. El plazo de 30 días del proveedor es irrelevante si el gateway conserva los prompts indefinidamente.

Conclusión

El plazo de 30 días asociado a Fable 5 no busca apropiarse de los datos. Es una medida limitada y destinada exclusivamente a supervisar abusos, coherente con lo que la mayor parte del sector ya hace por defecto. Para esta clase de modelos se vuelve obligatoria porque no es posible detectar abusos entre varias peticiones si los datos se eliminan. Para la mayoría de los equipos, el impacto técnico es nulo y el de gobernanza se limita a añadir un párrafo en la revisión del proveedor.

Para las organizaciones cuya postura de cumplimiento asumía retención cero, como los BAA limitados a ZDR, los avisos de privacidad que afirman que nada persiste o los productos infantiles diseñados según el principio de minimización, Fable 5 marca el momento en que esa premisa dejó de ser uniforme entre modelos. La solución no consiste en evitar el modelo, sino en incorporar la clase de retención como un dato explícito de cada modelo en las decisiones de routing, igual que ya se hace con el precio y la ventana de contexto.

Preguntas frecuentes

¿Puedo utilizar Claude Fable 5 bajo un acuerdo de retención cero de datos? No. Fable 5 y Mythos 5 son modelos sujetos a cobertura que exigen retener los datos durante 30 días. Las organizaciones con ZDR reciben 400 invalid_request_error, salvo que habiliten la retención de 30 días en un workspace y envíen por él el tráfico de Fable 5.

¿El uso de AWS Bedrock, Vertex AI o Microsoft Foundry permite evitar el requisito? No. Cada plataforma exige aceptar la retención mediante su propio mecanismo: provider_data_share en Bedrock; intercambio de datos con Anthropic y condiciones de Model Garden en Vertex; y condiciones de Anthropic al desplegar en Foundry, donde Anthropic, no Microsoft, actúa como encargado del tratamiento. Los acuerdos ZDR existentes no se aplican en ninguna de estas plataformas.

¿Pueden mis usuarios finales rechazar la retención? No hay ningún mecanismo de exclusión. Lo que sí puedes controlar es el routing: envía a modelos compatibles con ZDR el tráfico de quienes rechacen compartir datos. No publiques un ajuste que no cambie nada.

¿Se utilizan los datos retenidos para entrenar modelos? Anthropic afirma que los datos retenidos nunca se utilizan para entrenamiento sin permiso expreso. Su finalidad es la revisión de confianza y seguridad: un análisis automatizado seguido, en las conversaciones marcadas, de una posible revisión por personal autorizado que no puede exportar los datos. Todos los accesos quedan registrados en logs a prueba de manipulaciones.

¿La retención de 30 días cambia el funcionamiento del prompt caching? No. Las entradas de caché mantienen sus propios TTL cortos (5 minutos o 1 hora), y el contrato de caché de Fable 5 no cambia. Consulta nuestra evaluación con mediciones. El plazo de 30 días es una retención independiente y paralela para revisiones de seguridad.

Lecturas relacionadas: la guía completa sobre prompt caching explica el funcionamiento de la caché con el que interactúan las políticas de retención, y los precios de la plataforma muestran cuánto cuesta cada modelo según la tarifa oficial del proveedor.

Fuentes

• Anthropic: API y retención de datos
• Anthropic: modelos sujetos a cobertura
• Anthropic: prácticas de retención de datos para modelos de la clase Mythos
• AWS: retención de datos en Amazon Bedrock
• Google Cloud: Claude Fable 5 (modelos de partners)
• Google Cloud: gobernanza de datos de Vertex AI
• Microsoft: datos, privacidad y seguridad de Claude en Foundry
• OpenAI: privacidad empresarial
• OpenAI: BAA para los servicios de API
• FTC: modificaciones de la COPPA Rule (nota de prensa)
• Federal Register: Children’s Online Privacy Protection Rule

Todo se comprobó el 2026-06-12. Las políticas cambian; contrasta la información con los documentos vigentes y tus propios contratos. Este artículo no constituye asesoramiento jurídico.

← Volver al blog