Retención de 30 días de Claude Fable 5: ZDR, HIPAA, COPPA

Si tu organización ejecuta Claude bajo un acuerdo de retención cero de datos (ZDR), tu primera solicitud a claude-fable-5 no devolvió una respuesta. Devolvió 400 invalid_request_error. Eso no es una interrupción del servicio — es política. Fable 5 es el primer modelo Claude de disponibilidad general que no puede utilizarse sin retención de datos de 30 días, y el requisito acompaña al modelo en cada plataforma: la API de Claude, AWS Bedrock, Google Vertex AI y Microsoft Foundry lo condicionan a una aceptación explícita de retención.

Para los equipos que trataban “no retenemos tus datos” como una propiedad establecida de su stack de LLM, esto es un evento arquitectónico. Esta publicación cubre lo que dice la política, por qué existe la ventana, cómo la implementa cada nube y qué cambia para los productos de consumo y los sectores con datos sensibles.

Los detalles de la política fueron verificados contra la documentación publicada de Anthropic, AWS, Google y Microsoft el 2026-06-12. Las políticas cambian; verifica con las fuentes primarias enlazadas y tus propios contratos. Esto es una descripción técnica de ingeniería, no asesoramiento legal.

Lo que dice realmente la política

Anthropic designa a Claude Fable 5 y Claude Mythos 5 como Modelos Cubiertos. Según la documentación de retención de datos de la API y el artículo sobre prácticas de retención para modelos de clase Mythos (vigente desde el 2026-06-09):

• Los prompts y las respuestas se retienen durante 30 días, y luego se eliminan automáticamente — salvo que estén marcados por una investigación de seguridad activa o lo exija la ley.
• No existe opción de exclusión. La retención es una condición para usar el modelo. Una solicitud de una organización cuya configuración de retención no cumple el requisito devuelve 400 invalid_request_error.
• El acceso es restringido por diseño. Los sistemas de seguridad automatizados analizan los datos; solo un pequeño grupo de personal autorizado 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 extienden al tráfico de Modelos Cubiertos — incluso a través de plataformas en la nube.

Los planes de consumo (Claude Free/Pro/Max) no se ven afectados — ya operan bajo sus propios términos de retención. Esta política apunta a la superficie de la API comercial, exactamente donde suelen vivir las promesas de “nunca retenemos datos”.

Por qué existe una ventana de 30 días

La justificación en el artículo de Modelos Cubiertos es específica: estos modelos tienen capacidades sustancialmente avanzadas en ingeniería de software, flujos de trabajo agénticos y ciberseguridad, y “algunas formas de uso indebido solo se vuelven detectables a través de muchas solicitudes.” Los ejemplos citados — jailbreaking de mejor de N, espionaje patrocinado por estados — son patrones de ataque en los que cada prompt parece benigno y solo la secuencia es diagnóstica. No puedes detectar una secuencia que ya has eliminado.

Dos cosas que la ventana no es:

• No son datos de entrenamiento. Anthropic declara que los datos retenidos nunca se usan para entrenamiento sin permiso expreso. El propósito es la detección de abusos, sin más.
• No es nueva en tipo — es nueva en aplicabilidad. Una ventana de monitoreo de abusos de ~30 días ha sido el estándar del sector durante años: OpenAI conserva los logs de abuso de la API hasta 30 días (ZDR por aprobación); Azure OpenAI almacena los prompts hasta 30 días salvo aprobación para monitoreo de abusos modificado. Lo que cambió es que la ventana se volvió no negociable para una clase de modelo — anteriormente, todos los proveedores ofrecían una vía de escape de retención cero.

Una advertencia preexistente que sorprende a muchos: incluso bajo ZDR, Anthropic retiene los resultados de los clasificadores de seguridad, y el contenido marcado por infracciones de la Política de Uso puede conservarse hasta 2 años. La retención cero de datos nunca ha significado cero datos — significa cero retención del contenido no marcado en el flujo normal.

El mismo requisito, tres nubes, tres mecanismos

La retención se aplica dondequiera que se ejecute el modelo, pero cada plataforma implementa el opt-in de forma diferente — y esas diferencias determinan quién procesa tus datos y dónde residen tus controles.

AWS Bedrock es el más explícito. La retención de datos es un modo configurable (default / provider_data_share / none), resuelto en orden 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 retienen hasta 30 días. Bajo 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 cambió para los modelos anteriores a Fable 5, y una SCP sobre la clave de condición bedrock:DataRetentionMode puede aplicar tu postura a toda la organización — nadie cambia silenciosamente la cuenta para probar el nuevo modelo. Nota: con inferencia entre regiones, la copia retenida reside en la región de destino, lo que importa si tienes compromisos de residencia de datos.

Google Vertex AI bloquea el modelo detrás de una configuración de compartición de datos con Anthropic a nivel de proyecto (setPublisherModelConfig con dataSharingEnabledProvider: "anthropic") más la aceptación de términos en Model Garden, según la documentación de Fable 5 de Google. El manejo general de datos sigue la política de gobernanza de datos de Vertex AI; para cargas de trabajo sensibles a la residencia, los endpoints regionales y multirregionales de Vertex controlan dónde se ejecuta la inferencia — lo que ahora incluye dónde reside la copia retenida.

Microsoft Foundry es estructuralmente diferente. La documentación de datos y privacidad de Microsoft es explícita en que los modelos Claude son servicios de marketplace de terceros: aceptas los términos de Anthropic en el despliegue, y Anthropic — no Microsoft — es el procesador de datos. Los programas ZDR y de monitoreo de abuso modificado de Azure OpenAI no se extienden a los despliegues de Claude. Las organizaciones con posturas ZDR en otros servicios suelen aislar el uso de Covered Models en una suscripción dedicada, haciendo que el límite de retención sea estructural en lugar de procedimental.

El patrón en las tres plataformas: la clase de retención se convirtió en un atributo del modelo de primera clase y legible por máquinas — un modo, un indicador, una puerta de términos — en lugar de un párrafo en un contrato. Tu infraestructura ahora puede aplicar tu postura de datos, y debería hacerlo.

Qué significa para los despliegues empresariales

Sin un acuerdo ZDR, nada cambia mecánicamente — ya estabas en una postura de estilo 30 días, posiblemente sin darte cuenta. El trabajo consiste en hacerlo explícito en tu documentación de proveedor.

Con un acuerdo ZDR, tienes tres opciones:

1. Omitir los Covered Models. El ZDR se mantiene uniforme; renuncias al modelo. Viable si tus cargas de trabajo no lo necesitan — consulta nuestra evaluación medida de Fable 5 para ver qué implica y en qué se diferencia.
2. Dividir por workspace o proyecto. Todas las plataformas admiten un opt-in con alcance limitado: un workspace designado de Claude API (Consola → Configuración → Workspaces → Controles de privacidad), un proyecto de Bedrock con provider_data_share, un proyecto de Vertex o suscripción de Azure separados. Enruta solo las cargas de trabajo tolerantes a la retención hacia allí.
3. Aceptar la retención a nivel de toda la organización. La opción más sencilla de operar, pero degrada silenciosamente la garantía para todas las cargas de trabajo — incluidas aquellas cuya sensibilidad justificó el ZDR. Esa es una decisión para el responsable de protección de datos, no un cambio de configuración.

Independientemente del proveedor: tu propio registro es una segunda superficie de retención. Si tu gateway o stack de observabilidad registra prompts completos, estás ejecutando una ventana más larga que la de tu proveedor, bajo tu propio techo. Las garantías del proveedor solo son tan significativas como la capa que tienen delante — la misma lógica de auditoría que aplicamos a las afirmaciones de caché aplica aquí.

Qué significa esto para los productos orientados al consumidor

Si prestas servicios a consumidores y enrutas su contenido a través de un Covered Model, el cambio se propaga hacia tu propia superficie legal, independientemente de si tienes un acuerdo ZDR o no. Tres consecuencias concretas:

1. Tu aviso de privacidad probablemente necesita una actualización. La mayoría de los marcos normativos exigen divulgar la retención, no solo la recopilación: el Artículo 13(2)(a) del GDPR requiere el período de almacenamiento (o los criterios para determinarlo) en el momento de la recopilación; la CPRA de California exige que el aviso en el momento de la recopilación indique la retención por categoría de información personal. Si tu aviso dice —o da a entender— que los datos de conversación no se retienen en ningún lugar, una copia de 30 días en manos de un procesador lo convierte en incorrecto. Actualiza el aviso, los registros de tratamiento y el inventario de DPA.

2. No puedes ofrecer a los usuarios una opción de exclusión que tú mismo no tienes. La retención no tiene ningún mecanismo de excepción, por lo que no existe ningún interruptor que puedas construir para eximir los prompts de un usuario mientras siga utilizando ese modelo. La palanca que realmente tienes es el enrutamiento: una pasarela con conciencia del consentimiento envía a los usuarios que rechazan el intercambio de datos hacia modelos con elegibilidad ZDR, y a todos los demás hacia el Covered Model — una restricción legal convertida en una regla de enrutamiento ordinaria. Mucho mejor que una casilla de preferencias que no hace nada.

3. Las solicitudes de eliminación necesitan una infraestructura precisa. Las obligaciones de supresión (Art. 17 del GDPR, eliminación según la CPRA y sus equivalentes) se extienden a los procesadores. Una ventana acotada que elimina automáticamente en 30 días es, en general, una postura defensible para un procesador — pero tu manual de DSAR debería indicarlo así, en lugar de prometer una eliminación inmediata en los sistemas posteriores que no puedes ejecutar.

La dimensión global agrava esto: la misma lógica de divulgación y procesador aparece en el UK GDPR, la LGPD de Brasil y la creciente familia de leyes de privacidad estatales de EE. UU. Para los usuarios en China, la PIPL añade dos aristas más afiladas: proporcionar información personal a otro procesador generalmente requiere un consentimiento separado, y enrutar el contenido de usuarios chinos hacia un endpoint de LLM en el extranjero constituye una transferencia transfronteriza que necesita un mecanismo reconocido (evaluación de seguridad, contrato estándar o certificación). Una actualización de modelo que cambia quién retiene qué, dónde y durante cuánto tiempo es exactamente el tipo de cambio que estos marcos normativos esperan que vuelvas a documentar formalmente.

Industrias con datos sensibles: donde los 30 días duelen más

Para la mayoría de los productos, la ventana del proveedor es un problema de documentación. Para las industrias cuyos datos están regulados en sí mismos, es un problema de arquitectura: la copia retenida es datos regulados en reposo en un proveedor, y las normas sectoriales gobiernan exactamente eso.

Sanidad (HIPAA)

HIPAA no exige retención cero — exige que cualquier proveedor que maneje información de salud protegida lo haga bajo un Acuerdo de Socio Comercial (BAA) con las salvaguardas adecuadas. La copia de 30 días de tus prompts es PHI en reposo en un socio comercial; la cuestión es si tu BAA la cubre. Los dos principales proveedores de API estructuran esto de forma diferente, y la diferencia ahora importa: el acceso a la API compatible con HIPAA de Anthropic explícitamente no requiere ZDR — se basa en retención con salvaguardas (cifrado, controles de acceso, registro de auditoría, restricciones de funciones aplicadas). El BAA de la API de OpenAI cubre los endpoints elegibles para retención cero de datos — y un BAA limitado a endpoints ZDR estructuralmente no puede cubrir un modelo que exige retención.

La clase de retención de un modelo es ahora una cuestión de elegibilidad para el BAA. Confirma por escrito que tu BAA cubre el modelo específico antes de enrutar PHI hacia él — y recuerda que la cadena cambia en la nube: en Bedrock la plataforma es tu socio comercial; en Foundry, Anthropic procesa los datos directamente. Un punto delicado: la PHI nunca debe aparecer en definiciones de esquemas JSON para salidas estructuradas — los esquemas en caché no reciben las mismas protecciones que el contenido de los mensajes.

Productos para menores (COPPA)

El momento es incómodo: la Regla COPPA enmendada de la FTC entró en vigor el 23 de junio de 2025, con cumplimiento en la mayoría de las disposiciones previsto para el 22 de abril de 2026 — el primer modelo con retención obligatoria del lado del proveedor llegó justo cuando los operadores terminaban de implementar las nuevas obligaciones de retención. Dos de ellas interactúan directamente con la ventana de 30 días: una política de retención de datos escrita y pública es ahora obligatoria (§312.10) — qué datos de menores se recopilan, por qué y cuándo se eliminan — y la retención indefinida está prohibida, limitándose la retención a lo razonablemente necesario para el propósito de la recopilación.

Una ventana acotada de 30 días con eliminación automática tiene la forma compatible — pero el proveedor retiene para su propósito de confianza y seguridad, no para el propósito con el que recopilaste los datos del menor, y tu aviso debe describir con precisión la relación con el procesador. Para los productos dirigidos a menores que adoptaron ZDR específicamente para minimizar el rastro de datos, la respuesta de enrutamiento aplica con mayor importancia: el tráfico de menores permanece en modelos elegibles para ZDR, o la ventana del Modelo Cubierto entra en tu política §312.10 primero.

El mismo patrón en otros sectores

Una vez que ves la estructura — datos regulados, copia retenida en un proveedor, norma sectorial que rige la retención — se repite:

• Biometría (Illinois BIPA): los operadores necesitan un calendario de retención escrito y disponible públicamente, así como directrices de destrucción para datos biométricos. La copia de 30 días del proveedor de prompts que contienen identificadores biométricos pertenece a ese calendario.
• Pagos (PCI DSS / GLBA): PCI DSS prohíbe almacenar datos de autenticación sensibles después de la autorización — en cualquier lugar. Los datos de tarjetas pegados en un prompt se convierten en datos de tarjetas retenidos en un proveedor durante 30 días. La respuesta limpia es la redacción en origen, no el papeleo posterior.
• Educación (FERPA): los proveedores que manejan registros de estudiantes bajo la excepción de funcionario escolar deben permanecer bajo el control directo del centro educativo. Una copia de retención por seguridad a la que el centro no puede acceder ni eliminar anticipadamente encaja mal con ese estándar — una cuestión para el asesor legal antes de que el tráfico EdTech llegue a un Modelo Cubierto.
• Servicios financieros — la inversión (SEC/FINRA): los intermediarios de valores deben retener las comunicaciones comerciales bajo las normas de libros y registros. Para ellos, la ventana del proveedor no es el problema; capturar su propia copia conforme sí lo es. La misma pregunta sobre retención, signo opuesto.

El hilo común: las normas sectoriales regulan la retención en ambas direcciones, y una ventana del lado del proveedor que no controlas debe mapearse en la dirección que apunte tu sector.

Una lista de verificación para la toma de decisiones

• ✅ Inventaría qué modelos toca realmente tu tráfico. La clase de retención es ahora un atributo por modelo, no por proveedor.
• ✅ Si tienes ZDR: decide deliberadamente — omite los Modelos Cubiertos, divide por workspace/proyecto/suscripción, o acepta la retención a nivel de organización. No dejes que ocurra de forma implícita.
• ✅ Aplica la postura en la infraestructura — SCPs de Bedrock, controles de privacidad de workspace, proyectos cloud separados — no en una página de wiki.
• ✅ B2C: actualiza los avisos de privacidad y los procedimientos de DSAR; enruta a los usuarios que no han dado su consentimiento hacia modelos elegibles para ZDR en lugar de construir mecanismos de exclusión que no pueden funcionar.
• ✅ Datos regulados: confirma la cobertura por modelo, por escrito — BAA para PHI, política §312.10 para datos de menores, calendarios de retención para biometría — antes de enrutar esos datos a un modelo que requiere retención.
• ✅ Audita tu propio registro. La ventana de 30 días de un proveedor es irrelevante si tu gateway registra los prompts indefinidamente.

Conclusión

La ventana de 30 días asociada a Fable 5 no es una recopilación de datos — es un monitoreo de uso indebido acotado y con propósito limitado, coherente con lo que la mayoría de la industria ya hace por defecto, que se vuelve obligatorio para una clase de modelo porque la detección de uso indebido entre solicitudes no funciona sobre datos eliminados. Para la mayoría de los equipos, el impacto en ingeniería es nulo y el impacto en gobernanza es un párrafo en una revisión de proveedor.

Pero para las organizaciones cuya postura de cumplimiento asumía retención cero — BAAs con alcance ZDR, avisos de privacidad que indican que nada persiste, productos para menores construidos sobre minimización de datos — Fable 5 es el momento en que esa suposición dejó de ser uniforme en todos los modelos. La solución no es evitar el modelo. Es convertir la clase de retención en un parámetro explícito por modelo en las decisiones de enrutamiento, de la misma manera en que ya se tratan el precio y la ventana de contexto.

Preguntas frecuentes

¿Puedo usar Claude Fable 5 bajo un acuerdo de retención cero de datos? No. Fable 5 y Mythos 5 son Modelos Cubiertos que requieren retención de 30 días; las organizaciones con ZDR reciben un error 400 invalid_request_error a menos que habiliten la retención de 30 días para un espacio de trabajo y enruten el tráfico de Fable 5 a través de él.

¿Pasar por AWS Bedrock, Vertex AI o Microsoft Foundry evita el requisito? No. Cada plataforma condiciona el acceso al modelo a su propio proceso de aceptación de retención: provider_data_share en Bedrock, compartición de datos con Anthropic más los términos de Model Garden en Vertex, y los términos de Anthropic al momento del despliegue en Foundry (donde Anthropic, no Microsoft, es el procesador de datos). Los acuerdos ZDR existentes no se transfieren en ninguna de ellas.

¿Pueden mis usuarios finales optar por no participar en la retención? No — no existe ningún mecanismo de exclusión. El control que tienes es el enrutamiento: envía a los usuarios que rechacen el intercambio de datos hacia modelos elegibles para ZDR. No implementes un selector de preferencias que no cambie nada.

¿Se usan los datos retenidos para entrenar modelos? Anthropic declara que los datos retenidos nunca se utilizan para entrenamiento sin permiso expreso. El propósito es la revisión de confianza y seguridad: cribado automatizado, con conversaciones marcadas revisables únicamente por personal autorizado que no puede exportar los datos, bajo registros de acceso a prueba de manipulaciones.

¿La retención de 30 días cambia el funcionamiento del almacenamiento en caché de prompts? No. Las entradas de caché siguen sus propios TTLs cortos (5 minutos o 1 hora) y el contrato de caché en Fable 5 no cambia — consulta nuestra evaluación detallada. La ventana de 30 días es una retención separada y paralela para revisión de seguridad.

Fuentes

• Anthropic — API and data retention
• Anthropic — Covered Models
• Anthropic — Data retention practices for Mythos-class models
• AWS — Amazon Bedrock data retention
• Google Cloud — Claude Fable 5 (partner models)
• Google Cloud — Vertex AI data governance
• Microsoft — Claude in Foundry: data, privacy, and security
• OpenAI — Enterprise privacy
• OpenAI — BAA for API services
• FTC — COPPA Rule amendments (press release)
• Federal Register — Children’s Online Privacy Protection Rule

Todo verificado el 2026-06-12. Las políticas cambian — verifica contra los documentos actuales y tus propios contratos. No constituye asesoramiento legal.

← Volver al blog