Claude Managed Agents sale de la nube de Anthropic
Anthropic anunció el 12 de noviembre de 2026 la apertura, en beta privada, de una versión autoalojada de Claude Managed Agents, su servicio para construir y desplegar agentes de inteligencia artificial. La novedad es de calado para los equipos de ingeniería que trabajan en sectores regulados o con políticas estrictas sobre dónde se procesan sus datos: a partir de ahora, todo el servicio puede ejecutarse en una nube elegida por el cliente o directamente en sus propios servidores on-premises. Hasta este anuncio, la única pieza que las empresas podían alojar por su cuenta eran los sandboxes, los entornos aislados donde los agentes ejecutan código y herramientas.
El cambio no significa, sin embargo, que el modelo se descargue ni que Claude pase a funcionar dentro del centro de datos de la empresa. Lo que se traslada es la capa de orquestación: el servidor que coordina a los agentes, la base de datos que guarda su estado y los workers que ejecutan sus herramientas. Las llamadas al modelo siguen saliendo de la red del cliente hacia la API de Claude o hacia uno de los proveedores cloud compatibles. Esa distinción, que puede parecer un matiz técnico, es la clave para entender qué problemas resuelve esta modalidad y cuáles deja abiertos.
El acceso, por ahora, no es abierto. Las organizaciones interesadas deben solicitarlo a su equipo de cuenta en Anthropic, lo que indica que la compañía quiere acompañar de cerca a los primeros clientes antes de generalizar la oferta.
Del servicio gestionado al servicio que gestiona el cliente
Claude Managed Agents se presentó en abril de 2026 con una propuesta clara: ahorrar a los desarrolladores el trabajo de montar desde cero toda la infraestructura que rodea a un agente. Un agente útil en producción no es solo un modelo que responde mensajes. Necesita un bucle de ejecución que decida cuándo llamar a una herramienta, un lugar donde guardar el historial de cada sesión, un sistema para custodiar credenciales, mecanismos de memoria persistente y un entorno seguro donde ejecutar código. Quien haya construido un agente propio sabe que esa fontanería consume más tiempo que la integración con el modelo en sí, algo que ya se explicó con detalle al analizar cómo funcionan los agentes de IA más allá del modelo.
La versión alojada resolvía todo eso desde la infraestructura de Anthropic. El equipo de desarrollo definía sus agentes, sus skills y sus credenciales, y la plataforma se encargaba del resto. Esa comodidad, sin embargo, chocaba con un obstáculo recurrente en las grandes organizaciones: el estado de los agentes, sus registros y los secretos que usan para conectarse a sistemas internos vivían fuera del perímetro corporativo. Para un banco, una aseguradora, un hospital o una administración pública, esa sola circunstancia puede bloquear un proyecto durante meses de revisiones de seguridad y cumplimiento.
La primera respuesta de Anthropic fue permitir el autoalojamiento de los sandboxes. Así, el código que ejecutaban los agentes podía correr dentro de la red del cliente. Pero el plano de control, es decir, el componente que decide qué hace cada agente y guarda el rastro de lo que ha hecho, seguía en la nube de la compañía. La beta anunciada ahora completa ese movimiento y traslada al cliente todo el servicio.
Qué piezas pasan a manos del cliente
La arquitectura de la versión autoalojada se apoya en tres componentes que la organización debe operar por su cuenta.
El primero es el servidor, el núcleo del servicio. Es el que recibe las peticiones, coordina las sesiones de los agentes, gestiona el ciclo de vida de cada tarea y habla con el proveedor del modelo. En la práctica, cumple el papel que antes desempeñaba la infraestructura de Anthropic.
El segundo es una base de datos PostgreSQL. Ahí se almacena el estado persistente del servicio: definiciones de agentes, sesiones, historiales y el resto de información que el servidor necesita para funcionar de forma continuada. La elección de PostgreSQL no es casual. Se trata de un motor de código abierto ampliamente conocido por los equipos de operaciones, disponible como servicio gestionado en prácticamente cualquier nube y con un ecosistema maduro de herramientas de copia de seguridad, replicación y monitorización.
El tercero son los workers, los procesos encargados de ejecutar las herramientas que invocan los agentes. Cuando un agente decide leer un archivo, lanzar un comando, consultar un sistema interno o transformar datos, es un worker el que realiza esa acción. Al vivir dentro de la red del cliente, los workers pueden acceder a recursos internos sin necesidad de exponerlos a internet, una de las ventajas más tangibles de esta modalidad.
Con estas tres piezas bajo su control, el cliente puede decidir dónde se ejecuta cada una: en una nube pública que ya utilice, en una nube privada o en servidores físicos propios. La flexibilidad es amplia, pero también lo es la responsabilidad.
Lo que sigue fuera de la red corporativa
El punto que más conviene subrayar para evitar malentendidos es que el modelo no se autoaloja. Claude sigue ejecutándose fuera de la red del cliente. Cada vez que un agente necesita razonar, planificar o generar una respuesta, el servidor autoalojado envía una petición al modelo, y esa petición sale del perímetro corporativo.
Por defecto, esas llamadas se dirigen a la API de Claude. Como alternativa, el cliente puede encaminarlas a través de Amazon Bedrock, Google Cloud o Microsoft Foundry, o bien a través de una pasarela propia que la organización ya utilice para centralizar el tráfico hacia modelos de lenguaje. Esta última opción resulta especialmente interesante para empresas que han construido un gateway corporativo para aplicar políticas, registrar el consumo, filtrar contenido o repartir costes entre departamentos.
La consecuencia práctica es que el contenido de los prompts y de las respuestas sigue viajando hasta el proveedor del modelo. Lo que cambia es todo lo demás: dónde se guarda el estado, quién custodia las credenciales, dónde quedan los registros de actividad y desde qué red se ejecutan las herramientas. Para algunas organizaciones esa diferencia será suficiente para desbloquear proyectos; para otras, que necesitan que ningún dato abandone su red, la modalidad autoalojada no resolverá el problema de fondo.
Credenciales y registros: el argumento de seguridad
Uno de los mensajes centrales del anuncio tiene que ver con los secretos. En la versión autoalojada, las credenciales que usan los agentes permanecen en el entorno del cliente. Esto incluye las claves y tokens que un agente necesita para conectarse a repositorios, bases de datos, sistemas de tickets, herramientas internas o servicios de terceros.
Anthropic indica además que no tiene acceso remoto al servidor gestionado por el cliente ni a sus registros. Es una afirmación relevante desde el punto de vista del cumplimiento normativo, porque reduce el número de partes que pueden acceder a información operativa sensible. Los logs de un agente suelen contener mucho más de lo que parece: nombres de sistemas internos, rutas de archivos, fragmentos de datos procesados, errores con detalles de configuración o rastros de las decisiones que tomó el agente en cada paso.
Que esos registros se queden dentro del perímetro de la empresa facilita varias tareas que los equipos de seguridad conocen bien. Permite integrarlos con el SIEM corporativo, aplicar las políticas de retención que exige cada normativa, controlar quién puede consultarlos y responder a auditorías sin depender de un tercero. Para organizaciones con requisitos de residencia y soberanía de datos, este punto puede pesar más que cualquier otra característica del producto.
Conviene, aun así, no sobredimensionar la promesa. Que las credenciales y los logs se queden en casa no elimina la necesidad de proteger la información que se envía al modelo. Si un agente incluye datos sensibles en un prompt, esos datos saldrán hacia el proveedor elegido. La gobernanza del contenido que llega al modelo sigue siendo responsabilidad del equipo que diseña los agentes.
Las limitaciones de la beta
Como corresponde a una beta privada, la versión autoalojada llega con recortes importantes respecto al servicio alojado, y Anthropic los ha detallado de forma explícita.
La primera limitación afecta a la migración. Nada se copia automáticamente desde el servicio alojado. Una organización que ya utilice Claude Managed Agents en la nube de Anthropic y quiera pasar a la versión autoalojada deberá recrear desde cero sus agentes, sus skills, las credenciales almacenadas en el vault y los memory stores. No hay herramienta de exportación ni de importación. Para equipos con pocos agentes, el esfuerzo será asumible; para quienes hayan acumulado decenas de configuraciones y memorias, la transición exigirá planificación.
La segunda limitación tiene que ver con funciones que, sencillamente, no están disponibles en la modalidad autoalojada. No hay webhooks, lo que obliga a replantear cualquier integración que dependiera de notificaciones automáticas cuando un agente termina una tarea o cambia de estado. Tampoco hay ejecuciones programadas, así que los agentes que debían lanzarse de forma periódica tendrán que dispararse desde un planificador externo que gestione el propio cliente. La Files API tampoco está disponible, lo que afecta a los flujos que subían documentos para que los agentes trabajaran con ellos. Y, por razones evidentes, no se ofrecen los entornos cloud alojados, ya que la premisa de esta modalidad es precisamente que el cliente aporte su propia infraestructura.
Estas ausencias no son menores. En muchas arquitecturas de agentes, los webhooks y la programación de tareas son la columna vertebral de la automatización. Un equipo que evalúe la versión autoalojada debe revisar con cuidado qué partes de su diseño dependen de estas funciones y cuánto trabajo supondría sustituirlas con componentes propios.
El coste operativo que no aparece en la factura
La comparación entre la versión alojada y la autoalojada no puede limitarse al precio del servicio. Autoalojar significa asumir trabajo de operaciones que antes hacía otro.
Operar PostgreSQL en producción implica copias de seguridad verificadas, pruebas periódicas de restauración, actualizaciones de versión, gestión de conexiones, monitorización del almacenamiento y un plan de alta disponibilidad si los agentes son críticos para el negocio. Una base de datos que guarda el estado de los agentes es, a efectos prácticos, una base de datos de producción más, con todo lo que eso conlleva.
Los workers requieren su propia atención. Hay que dimensionarlos para la carga real, decidir cómo escalan cuando aumenta el número de tareas, aislarlos adecuadamente porque ejecutan acciones con efectos reales y vigilar su consumo de recursos. Si un agente ejecuta comandos o accede a sistemas internos, los workers se convierten en una superficie de ataque que el equipo de seguridad debe revisar con el mismo rigor que cualquier otro servicio con privilegios.
El servidor, por su parte, necesita despliegue, actualizaciones, observabilidad y gestión de incidencias. Cuando algo falla a las tres de la mañana, ya no es Anthropic quien recibe la alerta, sino el equipo de guardia del cliente. Esta es quizá la diferencia más importante con la versión alojada: la comodidad de no preocuparse por la disponibilidad se intercambia por control.
Para empresas con equipos de plataforma maduros, este coste puede ser marginal, porque ya operan decenas de servicios similares. Para organizaciones pequeñas o equipos sin experiencia en operaciones, el coste operativo de autoalojar puede superar con creces los beneficios, salvo que exista una exigencia regulatoria que no deje otra opción.
Alojado frente a autoalojado: diferencias clave
Visto en conjunto, las dos modalidades responden a necesidades distintas. La versión alojada ofrece el catálogo completo de funciones, incluidos webhooks, ejecuciones programadas, Files API y entornos cloud listos para usar, sin que el cliente tenga que operar nada. Es la opción natural para equipos que priorizan la velocidad de desarrollo y no tienen restricciones fuertes sobre dónde residen los datos operativos.
La versión autoalojada sacrifica parte de esas funciones a cambio de control. El estado de los agentes, las credenciales y los registros se quedan en la infraestructura del cliente, y los workers pueden alcanzar sistemas internos sin exponerlos. A cambio, el cliente asume la operación de todos los componentes y renuncia, al menos durante la beta, a varias capacidades.
En ambos casos, el modelo se consume desde fuera de la red corporativa. Esa constante conviene tenerla presente cuando se presenta la propuesta a un comité de seguridad: la modalidad autoalojada no convierte a Claude en un modelo local, sino que acerca al cliente todo lo que rodea al modelo.
Lista de comprobación para decidir si compensa
Antes de solicitar acceso a la beta, un equipo técnico puede hacerse una serie de preguntas que ayudan a aclarar si la modalidad autoalojada tiene sentido en su caso.
La primera es regulatoria: ¿existe una norma, contrato o política interna que exija que el estado de los agentes, sus registros o sus credenciales permanezcan dentro de la infraestructura propia? Si la respuesta es no, buena parte del atractivo desaparece.
La segunda se refiere al modelo: ¿es aceptable que el contenido de los prompts salga hacia la API de Claude, Amazon Bedrock, Google Cloud o Microsoft Foundry? Si la organización ya tiene acuerdos con alguno de esos proveedores, enrutar el tráfico a través de ellos puede simplificar la aprobación. Si ningún dato puede salir de la red, esta modalidad no cubre el requisito.
La tercera es operativa: ¿hay un equipo con experiencia para operar PostgreSQL en producción, gestionar workers que ejecutan acciones con privilegios y mantener un servidor con guardias y monitorización? Sin esa capacidad, el riesgo de incidencias crece.
La cuarta es funcional: ¿cuánto depende la arquitectura actual de webhooks, tareas programadas o la Files API? Si son piezas centrales, habrá que construir sustitutos o esperar a que la oferta madure.
La quinta tiene que ver con la migración: ¿cuántos agentes, skills, credenciales y memory stores existen en la versión alojada? Recrearlos manualmente puede ser trivial o un proyecto en sí mismo.
La sexta es de integración: ¿los agentes necesitan acceder a sistemas internos que hoy no pueden exponerse? Si es así, tener los workers dentro de la red puede ahorrar complejas configuraciones de conectividad y reducir la superficie expuesta.
La séptima es de observabilidad: ¿la organización quiere integrar los registros de los agentes con su SIEM y sus herramientas de auditoría? La versión autoalojada lo facilita de forma natural.
Si la mayoría de las respuestas apuntan a requisitos de control fuertes y a un equipo de plataforma con capacidad, la beta merece una evaluación seria. Si predominan las dudas sobre operación y la dependencia de funciones ausentes, probablemente compense seguir en la versión alojada por ahora.
Contexto: la carrera por los agentes empresariales
El movimiento de Anthropic se inscribe en una competencia cada vez más intensa por llevar los agentes de IA al entorno corporativo. Los grandes proveedores de nube y de modelos han pasado de ofrecer simples APIs de texto a vender plataformas completas para orquestar agentes, con memoria, herramientas, permisos y entornos de ejecución. Un ejemplo de esa tendencia es la propuesta de Amazon Web Services, que ha apostado por agentes que colaboran como un equipo, tal como se describió en el análisis sobre AWS y sus Kiro bots.
En esa carrera, la ubicación de los datos se ha convertido en un factor diferencial. Los proyectos piloto de agentes suelen arrancar con entusiasmo en los equipos técnicos, pero chocan después con los departamentos legales, de cumplimiento y de seguridad. Ofrecer una modalidad en la que el plano de control vive dentro de la infraestructura del cliente es una forma de reducir esa fricción sin renunciar a que el modelo se sirva desde la infraestructura del proveedor.
La decisión de Anthropic de permitir que las llamadas al modelo pasen por Amazon Bedrock, Google Cloud, Microsoft Foundry o una pasarela propia refuerza esa estrategia. Muchas empresas ya tienen contratos, acuerdos de procesamiento de datos y controles establecidos con alguno de esos proveedores. Poder reutilizarlos evita abrir una nueva negociación y acorta los plazos de aprobación.
Impacto para los equipos de desarrollo
Para los programadores que construyen agentes, el anuncio tiene implicaciones prácticas que van más allá de la infraestructura. La primera es que el diseño de los agentes debe tener en cuenta desde el principio la modalidad de despliegue. Un agente que depende de webhooks o de tareas programadas funcionará de forma distinta en cada entorno, y conviene abstraer esas dependencias para no quedar atado a una sola opción.
La segunda implicación es la gestión de secretos. Con las credenciales en el entorno del cliente, el equipo de desarrollo debe coordinarse con seguridad para definir cómo se cargan, rotan y auditan. Es una oportunidad para aplicar el principio de mínimo privilegio con más rigor: cada agente debería disponer solo de las credenciales imprescindibles para su función.
La tercera es la observabilidad. Tener los registros en casa permite construir paneles propios, alertas específicas y análisis de comportamiento de los agentes con las herramientas que el equipo ya conoce. Esto resulta útil para depurar decisiones erróneas, detectar bucles o identificar usos indebidos de herramientas.
Quienes ya trabajan con agentes en su día a día, por ejemplo programando con herramientas como las descritas en la guía práctica de Claude Code, reconocerán un patrón familiar: el valor de un agente depende tanto del modelo como del entorno en el que se ejecuta, de las herramientas a las que tiene acceso y de los límites que se le imponen. La versión autoalojada de Claude Managed Agents traslada al cliente la responsabilidad de definir y mantener ese entorno.
Riesgos y buenas prácticas para la evaluación
Quien participe en la beta debería abordarla como un proyecto de infraestructura y no solo como una prueba de producto. Algunas prácticas razonables ayudan a reducir riesgos.
Empezar con un caso de uso acotado, preferiblemente interno y de bajo impacto, permite conocer el comportamiento de los componentes sin comprometer procesos críticos. Separar desde el inicio los entornos de prueba y producción evita que credenciales reales acaben en configuraciones experimentales.
Aislar los workers con políticas de red restrictivas es especialmente importante. Un worker solo debería poder alcanzar los sistemas que sus agentes necesitan, y cualquier acceso adicional debería justificarse. Dado que estos procesos ejecutan acciones decididas por un modelo, el aislamiento estricto de los workers es una de las medidas con mejor relación entre esfuerzo y reducción de riesgo.
Tratar la base de datos PostgreSQL como un activo sensible también es clave. Contiene el estado de los agentes y, potencialmente, información derivada de su trabajo. Cifrado en reposo, control de acceso, copias de seguridad probadas y monitorización deberían estar presentes desde el primer día.
Por último, conviene documentar qué información sale hacia el proveedor del modelo. Aunque el plano de control esté en casa, el contenido de los prompts viaja fuera. Un inventario claro de qué datos se envían y por qué facilitará las conversaciones con los equipos de cumplimiento y evitará sorpresas en auditorías posteriores.
Situación actual
A fecha del anuncio, la versión autoalojada de Claude Managed Agents se encuentra en beta privada y solo está disponible para las organizaciones que la soliciten a través de su equipo de cuenta en Anthropic. El servicio completo, formado por el servidor, la base de datos PostgreSQL y los workers, puede desplegarse en la nube o en infraestructura on-premises del cliente, mientras que el modelo continúa ejecutándose fuera de su red y se consume a través de la API de Claude, Amazon Bedrock, Google Cloud, Microsoft Foundry o una pasarela propia.
Las credenciales de los agentes permanecen en el entorno del cliente y, según indica la compañía, Anthropic no tiene acceso remoto al servidor ni a sus registros. La migración desde la versión alojada exige recrear manualmente agentes, skills, credenciales del vault y memory stores, y durante esta fase no están disponibles los webhooks, las ejecuciones programadas, la Files API ni los entornos cloud alojados.
La versión alojada, lanzada en abril de 2026, sigue siendo la opción con el conjunto completo de funciones y sin carga operativa para el cliente. Ambas modalidades conviven, y la elección entre ellas depende de los requisitos de cada organización.
Conclusiones
La llegada de la versión autoalojada de Claude Managed Agents responde a una demanda concreta de las empresas: mantener dentro de su perímetro el estado de los agentes, sus credenciales y sus registros. Anthropic da ese paso trasladando al cliente el servidor, la base de datos PostgreSQL y los workers, y completa así un camino que había empezado con el autoalojamiento de los sandboxes.
El anuncio, sin embargo, no convierte a Claude en un modelo local. Las llamadas al modelo siguen saliendo de la red corporativa, aunque puedan encaminarse a través de proveedores cloud con los que la empresa ya trabaja o de una pasarela propia. Entender esa frontera es imprescindible para presentar la propuesta con honestidad ante los responsables de seguridad y cumplimiento.
Para los equipos de ingeniería, la decisión pasa por equilibrar control y comodidad. La modalidad autoalojada ofrece más soberanía sobre los datos operativos y una integración más natural con sistemas internos, pero exige operar componentes de producción y renunciar, por ahora, a funciones como webhooks, tareas programadas y la Files API. Las organizaciones con requisitos regulatorios fuertes y equipos de plataforma consolidados encontrarán en esta beta una opción a considerar; el resto probablemente obtendrá más valor de la versión alojada mientras la oferta madura.