El 12 de noviembre Anthropic abrió en beta privada el autoalojamiento completo de Claude Managed Agents. Ya no son solo los sandboxes donde corren las herramientas: ahora puedes alojar el servicio entero (la API, el bucle del agente y el almacenamiento de agentes, sesiones e historial) en tu propia infraestructura. Para un producto regulado en la UE, eso quita un bloqueo real. Para casi todos los demás, añade una carga operativa que no necesitas.

Qué ha pasado

Hasta ahora Managed Agents tenía dos modos. El de por defecto corre todo en la nube de Anthropic. El segundo, los sandboxes autoalojados que salieron en mayo, movía a tu infraestructura solo la ejecución de herramientas; el bucle del agente, la gestión de contexto y el historial seguían en Anthropic, y esa configuración no era elegible para retención cero de datos (ZDR).

El 12 de noviembre llegó el tercer modo. Con self-hosted Claude Managed Agents alojas también el servicio: un servidor (cma-server) que sirve la API, ejecuta el bucle del agente y guarda agentes, sesiones e historial en una base de datos PostgreSQL que es tuya. Tus workers ejecutan las herramientas en tus sandboxes. Las llamadas al modelo salen al proveedor de inferencia que elijas: la Claude API por defecto, o Amazon Bedrock, Claude en Google Cloud, Microsoft Foundry o tu propio gateway. Es la única configuración de Managed Agents elegible para ZDR. El software se descarga pidiéndolo al equipo comercial de Anthropic y se licencia bajo un acuerdo propio; no es open source.

Qué implica para tu producto

Lee la letra pequeña antes de celebrarlo. «Autoalojado» aquí no significa que los datos se queden en casa por defecto. En cada llamada al modelo, tu servidor envía la conversación hasta ese punto, incluidas las entradas y salidas de las herramientas, al proveedor de inferencia, y ese proveedor es la Claude API salvo que lo cambies. La residencia real aparece solo cuando además apuntas la inferencia a Bedrock en tu región, a Google Cloud o a un gateway propio. El autoalojamiento del servicio resuelve dónde vive el historial; la inferencia la decides tú aparte.

Lo que sí resuelve es concreto. Si tu obstáculo era que los transcripts de las sesiones (los prompts, las respuestas, lo que el agente lee y escribe) no podían salir a un proveedor en Estados Unidos, ahora pueden quedarse en tu base de datos. Para un producto fintech bajo DORA o PSD3, uno de salud sujeto al EHDS o a la cuestión de dónde alojar datos de salud en España, o un proyecto de sector público bajo el ENS, eso pasa de «no podemos usarlo» a «podemos evaluarlo». Es el bloqueo que mata un proyecto en la fase de compliance, no en la técnica.

El coste es que te conviertes en el operador. Dejas de consumir un servicio y pasas a correr un servidor, su PostgreSQL y tus sandboxes, a instalar cada versión a mano y a asegurar un shell real: la herramienta bash del agente corre con los permisos del proceso worker, y el aislamiento lo pones tú. Algunas funciones solo existen en el servicio gestionado. Y sigue en beta privada, con acceso restringido y sin el rodaje que tendrá dentro de unos meses.

Nuestra recomendación

Es, en el fondo, una variante del dilema entre servicio gestionado y marco propio, ahora a nivel de infraestructura. Evalúalo si se cumplen dos cosas a la vez: tienes un requisito duro de residencia o soberanía sobre el historial de los agentes, y ya operas una plataforma (GCP o AWS, Postgres, Kubernetes) con un equipo que la mantiene. Es el escenario para el que está pensado, y en nuestros proyectos de backend en Go sobre Cloud Run es territorio conocido.

Para el resto, no lo autoalojes. Si lo único que necesitas es que las herramientas corran dentro de tu red, los sandboxes autoalojados ya lo hacían sin montar un servidor. Si no tienes una obligación concreta de compliance, el servicio gestionado es más simple y te lo quitas de encima. Y aunque encajes en el perfil, nosotros no lo pondríamos en producción todavía: está en beta privada, se licencia con condiciones propias y acabas de heredar la seguridad de un intérprete de comandos conectado a tus datos. Pruébalo en un entorno aislado, mide lo que cuesta operarlo y decide con esos números delante, no con la palabra «soberanía».

La pregunta útil no es si puedes autoalojarlo. Desde el día 12, casi siempre la respuesta es sí. Es si el requisito que lo justifica es real y tienes quién lo mantenga el año que viene.

Te ayudamos a decidir

En Dribba desplegamos agentes en entornos regulados, con residencia de datos en la UE y backend en Go sobre Cloud Run, en proyectos de fintech y salud. Si estás ante la decisión de autoalojar o no, la valoramos contigo. Hablemos.