Durante unas horas de la tarde del 2026-06-05, la API de Claude parece haber estado devolviendo respuestas que no pertenecían al usuario que las había solicitado. Envías una petición y recibes una salida que parece responder al prompt de otra persona.
La página de estado de Anthropic registró el evento como «errores elevados en muchos modelos de Claude», que afectaban a Opus 4.5 a 4.8 y a Sonnet 4.6. No describe, a fecha de hoy, una filtración de datos. La lectura de que hubo datos cruzados entre usuarios procede de capturas de pantalla que circulan y de informes de primera mano, así que conviene tomarla como una interpretación temprana, no como una brecha confirmada.
Lo interesante no es si un proveedor tuvo una mala tarde. Es la clase de fallo. Cuando ocurre algo así, casi siempre se debe a un estado mutable compartido bajo carga, y ese es un riesgo que hoy mismo arrastra cualquier proveedor de IA que escale rápido.
Qué parece haber ocurrido
Según la página de estado de Anthropic, la incidencia se extendió a lo largo de la tarde del 2026-06-05: la investigación se abrió alrededor de las 15:19 UTC, el problema se identificó hacia las 15:43 UTC y se marcó como resuelto sobre las 18:28 UTC. Los modelos afectados fueron Claude Opus 4.5, 4.6, 4.7 y 4.8, además de Sonnet 4.6. La etiqueta oficial fue «errores elevados», el cajón genérico que usan los proveedores para todo, desde tiempos de espera hasta respuestas mal formadas.
Los informes que llamaron la atención describen algo más concreto. Algunos usuarios dijeron que ciertas llamadas a la API devolvían contenido que no tenía nada que ver con su propio prompt y, en al menos un caso muy compartido, la tarea de una persona apareció dentro de la respuesta de un usuario completamente ajeno. Varias personas dijeron haber recibido lo que parecía la salida de inferencia de otro cliente, y que lo comprobaron con cuidado antes de concluir que era un error en el servidor y no un fallo de su lado.
Dos cosas son ciertas a la vez. Anthropic no ha confirmado una exposición de datos entre usuarios, y la evidencia pública es coherente con ella. Una lectura responsable sostiene ambas: esto parece una filtración de respuestas entre clientes (cross-tenant), y todavía no está confirmada oficialmente como tal. No reproduzco aquí las capturas filtradas, porque contienen el prompt y la salida de otro cliente, que son justo los datos que no deberían circular más.
La clase de fallo: estado mutable compartido bajo carga
La filtración entre clientes ocurre cuando los datos de un cliente afloran en la sesión de otro. Es uno de los errores más antiguos y peligrosos de los sistemas multiinquilino, y rara vez procede de una brecha espectacular. Suele venir de una pieza de estado compartido y mutable que debía aislarse por petición y que, en las condiciones equivocadas, no lo hizo.
Una API de IA moderna no es un único programa que responde a una petición cada vez. Es una pila de capas compartidas: balanceadores de carga, enrutadores de peticiones, gateways, colas, cachés en memoria y pools de conexiones, todos sirviendo a la vez a cada cliente para mantener baja la latencia y el coste. Cada una de esas capas guarda estado. Cada una es un lugar donde una petición puede recoger la respuesta equivocada si una clave de caché colisiona, una conexión se reutiliza después de que debería haberse descartado o una petición cancelada deja atrás un objeto obsoleto.
El síntoma es casi siempre el mismo: pides tus datos y recibes los de otra persona. La causa es casi siempre anodina: un pequeño error en cómo se reutiliza un objeto compartido, disparado por la carga o por un caso límite como una petición cancelada o con el tiempo de espera agotado.
Ya hemos visto este mismo patrón
El precedente más claro es OpenAI, en marzo de 2023. El 2023-03-20, un cambio en sus servidores provocó un pico de peticiones canceladas a Redis, que activó un fallo en la biblioteca cliente redis-py. Durante una ventana de ese día, algunos usuarios de ChatGPT pudieron ver los títulos de las conversaciones de otros usuarios activos y, en algunos casos, el primer mensaje de una conversación recién creada.
La misma incidencia expuso datos de facturación limitados. OpenAI notificó a alrededor del 1,2 % de los suscriptores de ChatGPT Plus que otro usuario podía haber visto su nombre y apellidos, dirección de facturación, tipo de tarjeta, fecha de caducidad y los últimos cuatro dígitos de la tarjeta. Los números completos de tarjeta nunca quedaron expuestos. Como informó Help Net Security en su momento, y como confirmó OpenAI en su propio análisis, la causa raíz fue una capa compartida de caché y conexiones que devolvía datos al cliente equivocado tras peticiones canceladas.
Esa es la misma clase de fallo que el síntoma descrito en los informes sobre Claude: una capa compartida y mutable que entrega los datos de un cliente a otro bajo carga. Distinta empresa, distinta biblioteca, misma forma.
Por qué escalar lo hace más probable, no menos
Aquí está la parte estructural incómoda. Los proveedores de IA están añadiendo capacidad más rápido que casi cualquier infraestructura en la historia de la informática. La demanda supera al hardware, así que los equipos siguen añadiendo capas para aguantar: más caché para recortar el coste de tokens, más enrutamiento para repartir la carga entre regiones y versiones de modelo, más proxies y gateways para gestionar cuotas y conmutación por error.
Cada una de esas capas es una mejora de rendimiento y un nuevo lugar por el que el estado puede filtrarse. Una caché que sirve la clave equivocada, un enrutador que reutiliza una conexión, un proxy que mezcla una respuesta en otro flujo: cada uno está a un solo fallo de provocar una filtración entre clientes. Cuanto más fuerte escala un proveedor, más de estas capas opera y más carga empuja a través de ellas.
Así que esto es menos una historia sobre Anthropic que una historia sobre todos. Los proveedores que más corren por añadir capacidad son justo los más expuestos a esta clase de fallo, porque la velocidad y la infraestructura compartida son la forma de servir millones de peticiones de forma barata. No es señal de que una empresa sea descuidada. Es una propiedad de la arquitectura sobre la que construye toda la industria.
Qué significa esto si construyes sobre APIs de LLM
La conclusión práctica es un cambio de mentalidad. La respuesta de una API de LLM no es un canal privado y de confianza entre tú y el modelo. Son datos que vuelven de un sistema enormemente compartido y en constante cambio y que, en un mal día, pueden ser erróneos, obsoletos o estar cruzados con otro cliente.
Trátalos así:
- Asume que una respuesta puede pertenecer de vez en cuando a la petición equivocada. No diseñes flujos en los que una sola respuesta cruzada corrompa en silencio el registro de un usuario o lo exponga a otra persona.
- No envíes a una API de LLM datos que no tolerarías ver aflorar en otro sitio, salvo que tu contrato y los controles del proveedor realmente lo cubran. Aquí importan las condiciones de retención cero y de aislamiento empresarial.
- Valida y limita las respuestas antes de actuar sobre ellas. Comprueba la forma, el tipo y la plausibilidad, igual que validarías cualquier entrada no confiable.
- Registra lo suficiente para detectar filtraciones. Si nunca guardas metadatos de petición y respuesta, no puedes distinguir entre un error del modelo y una respuesta que nunca fue tuya.
Hay una versión de esto en la capa del navegador que es fácil pasar por alto. Cada vez más aplicaciones vuelcan la salida del modelo directamente en la página: respuestas en streaming, HTML generado por IA, resultados de herramientas renderizados en línea. Si esa salida puede estar cruzada o inyectada, renderizarla a ciegas convierte un problema del backend en uno del lado del cliente. Puedes acabar mostrando el contenido de otro usuario al tuyo, o ejecutando marcado que no escribiste, dentro de una sesión en la que tu usuario ya está autenticado.
Qué hacer esta semana
- Mapea cada lugar por el que una respuesta de una API de LLM entra en tu sistema y marca cuáles se renderizan directamente en el navegador.
- Trata esas respuestas como entrada no confiable: valida la estructura, escapa todo lo que se renderice en la página y nunca inyectes HTML del modelo en bruto sin sanearlo.
- Decide de forma explícita qué datos estás dispuesto a enviar a cada proveedor y confirma las condiciones de retención y aislamiento que se aplican.
- Añade registro y alertas que distingan una respuesta mal formada de una que no coincide con la petición que enviaste.
- Vigila la capa del navegador, donde la salida de IA, los scripts de terceros y los datos del usuario coinciden ahora en la misma sesión.
Cómo encaja cside
cside no se ejecuta dentro del backend de Anthropic ni del de ningún proveedor, y no puede arreglar una caché que devuelve los datos del cliente equivocado. Lo que aborda es la misma clase de problema un paso más cerca de tu usuario: el navegador, donde las respuestas de IA, los scripts de terceros y las sesiones autenticadas comparten ahora la misma página.
cside ofrece visibilidad en tiempo de ejecución de lo que realmente se ejecuta en esa sesión del navegador: qué scripts se cargan, cómo cambian tras el despliegue, qué datos leen y a dónde los envían. A medida que más aplicaciones renderizan la salida del modelo directamente en la página, esa visibilidad es la forma de detectar las consecuencias en el lado del cliente de una respuesta errónea o cruzada, como contenido renderizado en la sesión equivocada o un script que busca datos que nunca debería tocar.
El punto más amplio es el que cside siempre ha defendido sobre los scripts de terceros, ahora generalizado a la infraestructura de IA. Cada capa que añades para ir más rápido es una capa por la que los datos pueden aflorar en el lugar equivocado. No puedes eliminar esas capas, pero sí instrumentar la más cercana a tu usuario.
Empieza con seguridad del lado del cliente para la monitorización de scripts en tiempo de ejecución, o con Privacy Watch para ver exactamente qué recopila y envía el código de tus páginas.
Lecturas recomendadas en cside
- Cómo los scripts de terceros comprometidos pueden inyectar prompts a los agentes de IA
- La inferencia en el dispositivo llega a tu stack de seguridad
- La IA está comprimiendo el ciclo de los exploits
- Buenas prácticas para asegurar los scripts de terceros
A fecha de 2026-06-05. Los detalles de la incidencia de la API de Claude reflejan la página de estado de Anthropic y los informes públicos de usuarios disponibles en esa fecha. Anthropic ha caracterizado el evento como errores elevados y no ha confirmado, a fecha de hoy, una exposición de datos entre usuarios.
