Agentes de IA en local o en la nube: cómo decidirlo

Cuando un directivo me dice que quiere los agentes “en local”, casi siempre está mezclando tres cosas distintas: alojar el modelo en su propia infraestructura, mantener sus datos dentro de su perímetro, y contratar una API con garantías contractuales sobre esos datos. No son lo mismo, y la mayoría de las veces lo que de verdad importa —dónde acaban los datos y quién responde por ellos— se resuelve sin bajar el modelo a tus servidores. Aclarar esa confusión es el primer paso para decidir bien entre local y nube.

La respuesta corta: la nube da acceso a los mejores modelos con coste variable y sin que mantengas nada. Lo local da control máximo sobre el dato y el entorno a cambio de coste fijo, personal propio y renunciar a parte de la frontera de calidad. Cuál te conviene depende de qué datos manejas y qué exige tu cumplimiento, no de una preferencia ideológica por el control.

Qué significa de verdad “IA en local”

“En local” se usa como si fuera una sola cosa, y son tres decisiones separadas que conviene no confundir.

Qué controlas	Qué significa	Qué resuelve
El modelo autoalojado	Descargas los pesos de un modelo abierto y lo ejecutas en tu infraestructura	Ningún dato sale de tu entorno hacia un tercero; controlas la versión del modelo
Los datos en tu perímetro	El procesamiento ocurre dentro de tu red, aunque el modelo sea de un proveedor	El dato no se almacena ni se reutiliza fuera; reduce la superficie de exposición
La API con garantías	Usas un modelo de un proveedor por API, con contrato sobre tratamiento, residencia y retención del dato	Acceso a la frontera de calidad con compromisos legales sobre tus datos

La confusión más cara es creer que solo la primera opción protege los datos. En la práctica, una API con las garantías contractuales adecuadas cubre buena parte de los requisitos de cumplimiento sin obligarte a operar tu propia infraestructura de modelos. Autoalojar es la respuesta cuando el dato no puede salir del perímetro bajo ningún concepto, o cuando lo exige un marco regulatorio concreto. No es un requisito por defecto. Qué obliga cada caso lo desarrollo en IA y protección de datos.

Los trade-offs reales

Elegir entre local y nube es aceptar un intercambio, y conviene mirarlo de frente en lugar de decidir por instinto.

Control y cumplimiento frente a calidad de modelo. Autoalojar te da control total sobre el dato y el entorno, pero los modelos abiertos que puedes bajar suelen ir por detrás de la frontera que ofrecen los proveedores por API. Ganas soberanía, pero puede que pierdas capacidad en las tareas que más la exigen. La pregunta es si tus tareas necesitan esa frontera o se resuelven de sobra con un modelo autoalojable.

Coste fijo frente a coste variable. La nube es coste variable: pagas por uso y no mantienes infraestructura. Lo local es coste fijo: hardware, operación y personal que hay que sostener use quien lo use. A volumen bajo o irregular, la nube casi siempre sale a cuenta; a volumen muy alto y sostenido, lo fijo puede amortizar. La cuenta depende de tu volumen real, no de la tarifa de lista.

Quién mantiene. Este es el trade-off que más se subestima. Un modelo por API mejora solo y lo mantiene el proveedor. Un modelo autoalojado lo actualizas, lo parcheas y lo operas tú. Es una capacidad técnica nueva dentro de tu casa, con su coste y su riesgo de rotación. Si no tienes quién lo sostenga, “en local” no es control, es fragilidad.

Los híbridos habituales

En la práctica pocas operaciones son puras. El reparto que veo funcionar combina las tres opciones según la sensibilidad del dato y la exigencia de la tarea:

• Frontera por API para lo que exige criterio, con garantías contractuales sobre el tratamiento, cuando el dato admite ese marco.
• Autoalojado para lo que no puede salir del perímetro, aceptando un modelo quizá menos capaz a cambio de soberanía total.
• Datos sensibles tratados dentro de tu red antes de llamar a cualquier modelo: anonimizar, filtrar o enmascarar lo que no necesita salir reduce el problema sin renunciar a la calidad.

La clave del híbrido es que la decisión no se toma una vez para toda la empresa, sino tarea a tarea, según qué dato entra y qué exige el cumplimiento. Y solo es sostenible si el sistema está diseñado para que cambiar dónde se ejecuta cada modelo no obligue a reescribir el proceso. La misma sustituibilidad que hace intercambiables los modelos vale para el lugar donde corren. Ese principio de arquitectura lo trato en la arquitectura de agentes de IA.

Qué cuesta cambiar de sitio después

La decisión se presenta siempre como si fuera definitiva, y casi nunca lo es. El cumplimiento cambia, el volumen crece, un cliente grande exige que su dato no salga, o al revés: la tarea que pusiste en local resulta que necesita una capacidad que solo hay en la frontera. Así que la pregunta útil no es solo cuál elijo, sino cuánto me va a costar moverlo cuando cambie el motivo por el que lo elegí.

Lo que ata no es el modelo. El modelo es la pieza más fácil de sustituir de todo el conjunto. Lo que ata es lo que se construyó alrededor mientras nadie miraba:

Qué te ata	Cómo se nota el día de la mudanza
El camino del dato	Dónde vive, cómo se mueve y qué contratos permiten moverlo. Se descubre tarde y no lo arregla la ingeniería sola
Las primitivas del proveedor	Reglas, memoria o herramientas codificadas dentro de servicios concretos de una plataforma. Cada una hay que reescribirla
La línea base de calidad	Si mediste la calidad solo donde corría, no tienes contra qué comparar el destino y decides a ciegas
La competencia operativa	Si vas hacia el perímetro, necesitas quién lo sostenga. Si vienes de él, tienes gente y hardware que ya no encajan

Los cuatro se abaratan con lo mismo, y hay que hacerlo antes: que el proceso viva fuera del sitio donde se ejecuta. Las reglas, los permisos, los criterios de escalado y las trazas escritos como activos propios, y no como configuración dentro de una plataforma, son lo que convierte la mudanza en una tarea acotada. Ese es el argumento de fondo del modelo operativo como código, y aquí se cobra en dinero.

La batería de evaluación merece mención aparte, porque es la que hace la mudanza defendible ante un comité. Si tienes un conjunto de casos con respuesta conocida, mover una tarea de la nube al perímetro deja de ser un acto de fe: ejecutas la misma batería en el destino y ves qué pierdes y qué ganas antes de comprometerte. Sin ella, la discusión se decide por quien habla más alto. Cómo se monta está en evaluación de agentes de IA.

Nada de esto hace la mudanza gratis. Mover una tarea cuesta trabajo aunque esté todo bien hecho. Lo que se puede conseguir es que ese coste sea conocido y proporcionado al cambio, en lugar de un proyecto que nadie presupuestó y que acaba decidiendo que os quedáis donde estáis por inercia. La reversibilidad no es que salga gratis. Es que puedas ponerle precio antes de firmar.

Cómo lo decido

Mi orden de preguntas es siempre el mismo, y empieza por el dato, no por la infraestructura. Primero: qué datos entran en cada tarea y qué exige el cumplimiento sobre ellos. Segundo: si esa exigencia se cubre con garantías contractuales de API o obliga de verdad a autoalojar. Tercero: si la tarea necesita la frontera de calidad o se resuelve con un modelo autoalojable. Cuarto: si hay quién opere y mantenga lo que decida poner en local. Solo entonces sale la respuesta, y casi nunca es “todo local” ni “todo nube”.

Qué categorías de modelo entran en cada opción está en LLM para empresas, y el método para elegir el concreto de cada tarea, en qué modelo de IA elegir para cada tarea. Cuando el sistema necesita razonar sobre tu conocimiento propio, la técnica y sus implicaciones de dónde vive el dato están en RAG empresarial. Todo ello encaja en el panorama de agentes de IA para empresas.

Preguntas frecuentes

¿Qué significa tener agentes de IA en local?

Puede significar tres cosas distintas: alojar el modelo en tu propia infraestructura, procesar los datos dentro de tu perímetro aunque el modelo sea de un proveedor, o usar una API con garantías contractuales sobre el tratamiento del dato. Confundirlas lleva a decisiones equivocadas. Lo que suele importar es dónde acaban los datos, y eso no siempre exige autoalojar el modelo.

¿Es más seguro un modelo autoalojado que uno en la nube?

Autoalojar da control total sobre el dato y el entorno, pero seguridad no es lo mismo que control, y un modelo mal operado en tu infraestructura puede ser más frágil que uno por API con garantías y mantenimiento profesional. La opción más segura depende de tu marco de cumplimiento y de si tienes quién opere y actualice lo que pongas en local.

¿Cuándo compensa autoalojar el modelo?

Cuando el dato no puede salir de tu perímetro bajo ningún concepto o lo exige un marco regulatorio concreto, cuando el volumen es muy alto y sostenido y el coste fijo amortiza, y cuando tienes equipo para operarlo. Fuera de esos casos, una API con garantías contractuales suele cubrir los requisitos sin el coste de mantener infraestructura de modelos.

¿Puedo cambiar de local a nube (o al revés) más adelante?

Sí, y conviene dar por hecho que ocurrirá, porque el motivo por el que decides hoy cambia. Lo que decide si es una tarea o un proyecto es cuánto de tu proceso vive fuera del sitio donde se ejecuta: reglas, permisos, criterios de escalado y trazas como activos propios se mudan bien, y lo que se codificó dentro de servicios concretos de una plataforma hay que reescribirlo.

¿Qué me ata de verdad a una opción de despliegue?

El modelo no, que es lo más fácil de sustituir. Ata el camino del dato y los contratos que lo permiten, la lógica escrita dentro de las primitivas de una plataforma, no tener una línea base de calidad contra la que comparar el destino, y la competencia operativa que tengas o te falte en el sitio al que vas.

¿Local o nube para agentes de IA?

Rara vez es una elección única para toda la empresa. Se decide tarea a tarea según qué datos entran y qué exige el cumplimiento: frontera por API para lo que necesita máxima calidad y admite el marco contractual, autoalojado para lo que no puede salir del perímetro. La mayoría de las operaciones serias acaban en un híbrido.