Nube privada o self-hosted: cómo elegir el despliegue de tus agentes de IA

La pregunta útil no es qué opción suena más moderna. Es dónde tiene que correr el agente: qué datos toca, quién lo opera de verdad, cuánto cuesta el conjunto y qué pide la norma. En un SaaS que vende en Europa, el sitio de despliegue no es un detalle de infraestructura. Es parte de la decisión de producto.

En este artículo comparamos tres opciones habituales: nube gestionada, nube privada y self-hosted para entender qué se gana, qué se cede y qué responsabilidades aparecen en cada una.

La pregunta no es cuál es más moderno

En una demo da igual el sitio donde esté desplegado el agente. En un entorno real sí importa: dónde se almacenan los datos, si la llamada al modelo sale de la red de la empresa o si, por la industria y la región en la que opera la compañía, se requieren auditorías, seguridad y confidencialidad específicas.

Si por querer ganar agilidad decimos que "en la nube es más rápido", en realidad estamos tomando una decisión estratégica y de infraestructura de forma apresurada. Tarde o temprano habrá que resolver dónde viven los datos, quién opera el sistema, qué nivel de control existe y qué requisitos debe cumplir el producto.

Tres sitios, tres intercambios

La nube gestionada

Otra empresa opera el modelo en sus propios servidores y entrega al cliente una cuenta, una clave API y unos términos y condiciones para poder utilizarlo. Encaja cuando lo que frena es el tiempo y no se dispone de un equipo interno especializado: el valor está en resolver el caso de uso, no en montar y mantener servidores.

El modelo, el registro y, en algunos casos, la memoria pueden vivir en las máquinas de ese proveedor. Antes de utilizarlo con datos de clientes conviene conocer la región donde se procesa la información, quién puede acceder a ella, cómo se gestiona el borrado y qué registros ofrece el servicio.

La nube gestionada proporciona velocidad y reduce la carga operativa, pero también implica ceder parte del control directo sobre la infraestructura. El contrato debe dejar claro qué ocurre con los datos, qué proveedores intervienen y cómo se responde ante incidentes.

La nube privada

En un SaaS, una nube privada suele ser una VPC: una red virtual aislada lógicamente, con reglas propias de acceso y salida, dentro de AWS, Google Cloud o Azure. Se siguen alquilando máquinas, pero la empresa puede controlar mejor quién entra, qué tráfico puede salir a internet y en qué región se ejecuta el sistema.

A cambio de tener un mayor aislamiento y seguridad, hay que asumir un esfuerzo adicional de mantenimiento, actualizaciones y gestión de la seguridad. Sin embargo, es habitual que las empresas de software opten por una solución híbrida: mantienen su aplicación desplegada en una nube privada y utilizan modelos frontera servidos por terceros como Anthropic, OpenAI o Gemini.

Esta decisión de arquitectura hace que únicamente quede protegido aquello que no sale de la red. Si las peticiones se envían a una API externa, el texto del cliente y el contexto necesario para generar la respuesta salen de esa red.

Cuando la confidencialidad y el control son prioritarios, una alternativa es recurrir a modelos desplegados también en una nube privada y servidos por el propio proveedor cloud, mediante productos como Amazon Bedrock, Google Vertex AI o Azure OpenAI Service. En este tipo de arquitecturas adquiere especial importancia la política de permisos e identidades, que debe determinar qué puede consultar o ejecutar cada componente del sistema.

En máquinas propias: self-hosted y on-premise

Self-hosted quiere decir que la empresa instala y opera el programa por su cuenta. Si el hardware está en sus propias instalaciones, se habla de on-premise. En este modelo la empresa decide dónde se almacenan los datos, cómo se protege el disco y quién tiene acceso a la infraestructura.

También asume las responsabilidades que la nube gestionada reduce: actualizaciones, capacidad, copias de seguridad, monitorización, respuesta ante incidentes y disponibilidad de un equipo que opere el sistema.

Para ejecutar modelos localmente existen herramientas como Ollama, LM Studio o Jan, que permiten descargar y servir determinados modelos en equipos propios. Son opciones interesantes para desarrollo, pruebas o casos en los que los datos no deben salir de la infraestructura de la empresa. En producción, además de elegir el modelo, hay que valorar su rendimiento, consumo de recursos, mantenimiento y capacidad de operación.

Self-hosted tiene sentido cuando el dato no puede salir, cuando el comprador lo exige en el pliego o cuando la empresa ya opera sistemas parecidos. No tiene sentido como gesto: una infraestructura que nadie actualiza ni vigila es un riesgo con otra dirección.

Qué pide la norma y qué no elige por ti

El sitio no sustituye la norma, y la norma no dice que haya que usar una nube concreta. Lo importante es poder demostrar qué datos se tratan, quién accede, dónde se procesan, cómo se gestionan los incidentes y qué registro queda de las operaciones.

El AI Act, el RGPD, la normativa española de protección de datos, el ENS cuando resulte aplicable y marcos como ISO 27001 pueden introducir requisitos distintos según el caso de uso, el sector y el contrato. Una nube privada no convierte automáticamente un sistema en conforme, del mismo modo que self-hosted no garantiza por sí solo seguridad o confidencialidad.

La decisión debe analizarse con el equipo legal, de seguridad y de plataforma. Este artículo es una guía de producto e infraestructura, no asesoramiento jurídico.

Según el sector y la madurez del equipo

La madurez pesa tanto como el sector. Un equipo de plataforma puede operar el agente en su propia red. Una empresa de software pequeña, con el mismo tipo de dato, puede tener dificultades si empieza por gestionar toda la infraestructura. El dato marca el mínimo exigible y el equipo marca el máximo que se puede sostener.

El coste no es solo la factura del modelo

El precio por uso del modelo es la línea visible, no el coste completo del sitio. En la nube gestionada se paga el servicio y el modelo, pero también la revisión humana, la integración y el equipo que define el caso. En la nube privada se suman máquinas, observabilidad y horas de plataforma. En máquinas propias, el software puede ser abierto, pero la operación y la nómina no lo son.

La cuenta completa depende de cuánto cuesta una tarea bien hecha. Cambiar de sitio no siempre reduce el coste: a veces solo mueve la factura de una casilla a otra.

Dónde encaja Devic

Devic se ofrece como un producto SaaS para que el cliente no tenga que hacerse cargo de la infraestructura necesaria para operar un agente. El cliente puede centrarse en definir el caso de uso, las herramientas, las reglas y los permisos, mientras Devic proporciona el entorno gestionado.

El producto es compatible con modelos servidos por nubes públicas y con modelos desplegados en nubes privadas u entornos on-premise. Esto permite elegir el modelo de despliegue que mejor encaje con los requisitos de datos, seguridad, operación y cumplimiento de cada organización.

Cuando la prioridad es avanzar rápido y no existe un equipo dedicado a operar la infraestructura, el modelo SaaS permite poner en marcha el caso de uso sin montar servidores, gestionar actualizaciones ni mantener toda la capa de ejecución. El cliente conserva el control sobre el caso, las acciones y las reglas del agente.

Para organizaciones que necesitan más control sobre los datos o sobre los modelos, Devic también puede integrarse con modelos servidos desde una nube privada o desde la propia infraestructura del cliente. Además, su iniciativa open source permite que los usuarios que lo necesiten gestionen su propio harness sin ceder el control de la infraestructura.

En todos los modelos siguen siendo necesarios una correcta gestión de identidades, permisos y registros. El sitio donde se despliega el agente no proporciona por sí solo estas garantías: deben diseñarse y operarse como parte del producto.

Una lista para elegir

Si las respuestas aguantan, el siguiente paso es una prueba corta en el sitio que el dato permite, no en el que queda mejor en la diapositiva. Si fallan dos o más, el trabajo está en el caso, el contrato o el equipo. Mudar el agente de edificio no lo sustituye.

Conclusión

La nube gestionada suele ser la opción más rápida para validar un caso de uso. La nube privada ofrece más control sobre la red, los accesos y la región, pero exige más operación. Self-hosted y on-premise pueden ser necesarios cuando el dato no puede salir o el comprador lo exige, aunque trasladan toda la responsabilidad al equipo que los mantiene.

No existe un despliegue ganador en abstracto. La decisión correcta es la que permite proteger los datos, cumplir los requisitos aplicables y operar el agente de forma sostenible durante los próximos años.