Existe una tensión real en el mercado de herramientas de IA para empresas. Por un lado, los proveedores SaaS han simplificado enormemente la adopción: puedes tener flujos de automatización funcionando en horas sin tocar un servidor. Por otro lado, hay empresas que prefieren llevar la automatización a infraestructura propia —o construir desde ahí desde el principio— por razones que no son puramente técnicas.
Este artículo no es un argumento a favor de uno u otro modelo. Es un análisis de cuándo tiene sentido cada opción, con precios publicados por los propios proveedores, las limitaciones concretas de cada una y los criterios que conviene revisar antes de decidir.
Qué significa realmente "self-hosted" en 2026
Cuando hablamos de infraestructura propia para IA, no estamos hablando de construir modelos de lenguaje desde cero ni de mantener un rack de servidores en la oficina. Estamos hablando de desplegar software de código abierto o de código disponible en un servidor —típicamente un VPS en la nube— que controlas tú, con un proveedor de alojamiento que eliges tú. Ese proveedor actúa como encargado del tratamiento de los datos personales que haya en el servidor, igual que lo haría un SaaS; la diferencia es cuántos intermediarios hay y quién los decide.
El stack típico de este modelo incluye n8n como motor de automatización —una alternativa a Zapier que puede instalarse en un servidor propio, aunque también se vende en la nube, y que no es open source en sentido estricto: se distribuye bajo su propia Sustainable Use License—, PostgreSQL para persistencia de datos, Qdrant para búsqueda semántica si el caso de uso lo requiere, y acceso por API a modelos de lenguaje; si van a tratar datos personales, conviene un proveedor que los procese dentro de la UE (en nuestra propia infraestructura, el principal es Scaleway, en París). Un VPS de 8 GB de RAM y 100 GB de disco cuesta entre 8 y 15 € al mes sin IVA en un proveedor como Hostinger, pagando dos años por adelantado (plan KVM 2, precio de promoción y de renovación, consultado el 23 de septiembre de 2026). Si basta o no, no lo decide el número de workflows, sino cuántas ejecuciones corren a la vez y cuántos datos mueve cada una: el servidor se dimensiona midiendo.
La diferencia con el modelo SaaS no es que los LLMs estén en tu servidor —llamar a la API de Claude o Groq envía los datos al proveedor del modelo de todas formas— sino que la orquestación, el almacenamiento de datos, las credenciales y la lógica de negocio están en tu infraestructura, bajo tu control.
El argumento de los costes: cuándo el SaaS sale más caro
El coste del SaaS de automatización crece con el volumen, aunque no en proporción: se paga por uso y el precio unitario baja en los tramos altos (en el plan Team de Zapier, 10.000 tareas cuestan 169 $ al mes y 100.000 tareas, 599 $, con facturación anual; precios consultados el 23 de septiembre de 2026). Zapier cobra por "tareas" —cada acción completada en un flujo consume una, salvo sus herramientas internas, como filtros o formateadores—. Make cobra por "créditos", que sustituyeron a las "operaciones" el 27 de agosto de 2025. Ambos tienen un coste marginal por uso que no existe en n8n Community Edition instalado en un servidor propio.
Un ejemplo con precios publicados por los propios proveedores (consultados el 23 de septiembre de 2026). Diez mil ejecuciones al mes en Zapier no son necesariamente diez mil tareas: Zapier cobra cada acción completada, así que la factura depende de cuántas acciones tiene cada flujo. Con una acción por ejecución, el plan Team con 10.000 tareas cuesta 169 $ al mes con facturación anual; con cinco, son 50.000 tareas y 399 $ al mes. n8n Community Edition, instalado en un servidor propio, no cobra por ejecución: se paga el servidor —un VPS de 8 GB de RAM cuesta entre 8 y 15 € al mes sin IVA en Hostinger, pagando dos años por adelantado— y el tiempo de quien lo mantiene. Y no conviene confundir herramienta con forma de despliegue: el propio n8n en la nube cuesta 50 € al mes, con facturación anual, por 10.000 ejecuciones con pasos ilimitados.
El precio del servidor no es el coste total: alguien tiene que gestionarlo, actualizarlo y vigilarlo —tu equipo o un proveedor con un contrato de mantenimiento— y ese coste hay que sumarlo antes de comparar.
No hay un punto de inflexión universal: depende de cuántas acciones tiene cada flujo, de con qué servicio se compare y de cuánto cuesta el tiempo de mantenimiento. Con volúmenes bajos, el tiempo de configurar y mantener un servidor puede pesar más que la cuota del SaaS; con volúmenes altos, la cuota total sube —aunque el precio por tarea baje— y la cuenta cambia. Hay que hacerla con los precios del momento.
El argumento de los datos: RGPD, confidencialidad y control
El argumento de los costes es importante, pero el argumento de los datos suele ser más decisivo para ciertos sectores.
Cuando usas herramientas SaaS de automatización, tus datos de negocio pasan por los servidores del proveedor. Esto incluye los datos de tus clientes, tus oportunidades comerciales, tus comunicaciones internas y cualquier otra información que los flujos procesen. Proveedores como Zapier tienen sus servidores en Estados Unidos. Aunque firman DPAs (Acuerdos de Procesamiento de Datos) que cubren el RGPD, la transferencia de datos a terceros países sigue siendo un vector de riesgo legal y reputacional.
En sectores regulados —salud, finanzas, legal, educación— esto puede ser directamente un impedimento. En sectores no regulados, puede ser una cuestión de política corporativa o de exigencias de clientes enterprise. Y cuando tratas datos personales por cuenta de un cliente, no es solo política corporativa: el RGPD (art. 28.2) prohíbe que un encargado del tratamiento recurra a otro encargado sin autorización previa por escrito, específica o general, del responsable. Si tu flujo pasa sus datos por una plataforma de terceros, esa plataforma tiene que estar autorizada por tu cliente.
Con self-hosted, los datos de orquestación se quedan en un servidor que eliges y controlas tú. Salen los que envías a APIs externas y los que viajan a los servicios que conectes, como las copias de seguridad, y el proveedor del servidor sigue siendo un encargado del tratamiento. La ventaja es que esa lista la decides tú, y puedes diseñar los flujos para minimizar qué información se envía a cada servicio.
El argumento técnico: complejidad y personalización
Las plataformas SaaS están optimizadas para el caso de uso común. Son excelentes para conectar dos aplicaciones SaaS y mover datos entre ellas. Su editor visual es intuitivo para flujos lineales. Su biblioteca de integraciones preconstruidas es amplia.
Pero tienen límites técnicos concretos. El código que se ejecuta dentro de Zapier o de Make tiene topes de tiempo y de memoria que dependen del plan: en Make, 30 segundos por ejecución salvo en Enterprise (300 segundos), que es también el único plan que permite importar librerías propias; en Zapier, 30 segundos en los planes Professional y Team, ampliables hasta 10 minutos en los pasos de acción, y con paquetes de npm o PyPI en los planes de pago. Para guardar estado entre ejecuciones ofrecen sus propios almacenes (Storage y Tables en Zapier, data stores en Make).
n8n instalado en tu propio servidor permite ir más lejos, porque los límites los fijas tú: el nodo de código viene restringido por defecto, pero puedes permitirle módulos integrados de Node.js y paquetes externos de npm con variables de entorno —en la versión cloud de n8n no se pueden importar paquetes externos—; cada tarea de código tiene un tope configurable, de 300 segundos por defecto; y puedes gestionar estado en PostgreSQL o Redis. Los agentes de IA con memoria, la lógica condicional profunda o los bucles no son exclusivos del self-hosted —la versión cloud de n8n también los ofrece—; lo que el servidor propio añade es control sobre los límites, las dependencias y dónde quedan los datos.
Cuándo el SaaS es la respuesta correcta
Ser honesto sobre esto es importante: hay casos donde el SaaS es la respuesta correcta, y recomendarlo cuando corresponde es parte de hacer bien nuestro trabajo.
Si eres una empresa pequeña (menos de 10 personas), con un volumen bajo de automatizaciones, que no maneja datos especialmente sensibles, y que no tiene ni quiere tener ningún equipo técnico, el SaaS es la opción más pragmática. La curva de aprendizaje es menor, el soporte está incluido, y el coste en ese rango de volumen es manejable.
También hay casos donde la integración nativa importa más que el control. Si tu empresa usa Salesforce y necesitas una automatización que use funcionalidades específicas del ecosistema Salesforce, compara qué operaciones cubre cada integración: n8n tiene nodo propio de Salesforce, pero la integración de Zapier puede cubrir mejor alguna funcionalidad concreta y ser más fácil de mantener para un equipo sin perfil técnico.
El modelo híbrido es también válido: usar SaaS para las integraciones simples y sin datos sensibles, y self-hosted para los flujos complejos con datos críticos. No es una decisión de todo o nada.
La pregunta que hay que hacerse antes de decidir
En lugar de empezar por la tecnología, la pregunta correcta es: ¿cuál es el coste de que esta automatización falle, quede expuesta o cambie de precio?
Si el coste es bajo en los tres ejes —un fallo es recuperable, una exposición de datos no tiene consecuencias graves, y un cambio de precios del proveedor no afecta críticamente a la operación— el SaaS es probablemente suficiente. Si el coste es alto en alguno de los tres, la conversación sobre self-hosted tiene que ocurrir.
En RAXAR gestionamos nuestra propia infraestructura self-hosted no porque seamos puristas de la tecnología, sino porque es la decisión más sensata para la complejidad y la criticidad de los sistemas que operamos. Y cuando asesoramos a clientes, aplicamos el mismo criterio: la tecnología correcta para el problema correcto, sin dogmatismo.
Si estás en ese momento de evaluación —creciendo en volumen, con datos que empiezan a importar, o con necesidades técnicas que el SaaS no cubre bien— el primer paso es un análisis de situación. Cuántas ejecuciones, qué tipo de datos, qué complejidad técnica, qué presupuesto. Con esos números sobre la mesa, la decisión es casi siempre obvia.